It is time now to understand "Service" in ESB. Why don't we call it Enterprise Component Bus?

Services are exposed functionalities which are clearly defined, self contained, and which will not depend on the state and context of peer services. As shown in the following figure, the service has a service description (similar to WSDL) and it is this description which is exposed. It is never necessary to expose the implementation details, and in fact, we shouldn't expose them. It is this hidden nature of the implementation which helps us to replace services with similar services. Thus, service providers expose the service description and service consumers find them.

Once the service description is found service consumers can bind to it. Moreover, it is during the time of actual binding, we need more information like transport protocols. As we know, we can handle with transport details with the help of protocol adapters. Intelligent adapters are required if we need to route messages based on content or context. These adapters are of a different kind like splitters and content based routers. ESB is all about a run-time platform for these kinds of adapters and routers, which are specifically designed for hosting and exposing services.

Almost all OOP languages support interface-driven development and hence this is not a new concept. Separating interface from implementation abstracts the Service Consumer from the implementation details from a Service Provider perspective. But, what about abstracting out this interface itself? If the Service Consumer interacts directly with the Service Provider, both these parties are tightly coupled and it may be difficult to change the interface. Instead, a service bus can effectively attach itself to a service registry. This means, a consumer can even be unaware of the service interface.

Now, just in time, the consumer can selectively choose an appropriate interface from a registry, then bind to a suitable implementation through an ESB, and invoke the service at run time. Such kinds of flexibility come at the cost of design time or compile time type checking, which can be error prone during service invocation using conventional tools. An ESB with its set of tools and design primitives helps developers to effectively address this.

The key value of aggregation, here, is not so much in being able to provide core services, which developers have to build anyway. It is to facilitate an arbitrary composition of these services in a declarative fashion, so as to define and publish more and more composite services. Business Process Management (BPM) tools can be integrated over ESB to leverage service aggregation and service collaboration. This facilitate reuse of basic or core (or fine grained) services at the business process-level. So, granularity of services is important which will also decide the level of reusability.

Coarse Grained or Composite Services consume Fine Grained Services. Applications which consume Coarse Grained Services are not exposed to the Fine Grained Services that they use. Composite Services can be assembled from Coarse Grained as well as Fine Grained Services.

To make the concept clear, let us take the example of provisioning a new VOIP Service for a new customer. This is a Composite Service which in turn calls multiple Coarse Grained Services such as validateOrder, createOrVerifyCustomer, and checkProductAvailability. Now, createOrVerifyCustomer, the Coarse Grained Service in turn call multiple Fine Grained Services like validateCustomer, createCustomer, createBillingAddress, and createMailingAddress.

As is shown in the above figure, a Composite Services is an aggregate of other Composite Services and/or Coarse Grained Services. Similarly, Coarse Grained Services are again aggregates of other Fine Grained Services. Whereas, Fine Grained Services implement minimum functionality and are not aggregates of other services. ESB here acts as a shared messaging layer for connecting applications and other services throughout the enterprise, thus providing a workbench for service aggregation and composition.

Services can be designed but if left alone they will sit idle. The idea behind true SOA is not just service definition or implementation, but also service enablement. By service enablement, we mean enabling, configuring, tuning, and attaching QOS attributes to services, so that they are accessible, as per SLA irrespective of formats or transport protocols.

Using today's techniques like Aspect Oriented Programming (AOP), Annotations and byte code instrumentation, service enablement can be done without any dependency on the services framework. An ESB does exactly this. It is to be noted that a JBI-based ESB will do this API-less. It is not completely API-less, in the sense that there is always a dependency on an XML configuration or annotation. The differentiating factor is that this dependency is externalized so that they are not cemented to the service implementation.

Service consolidation is an important step to eliminate redundant information and data. As a part of service consolidation, we may have to first consolidate IT infrastructure and data assets in the network. There should be clear ownership for these two entities, so that we know who or which applications are changing which sectors of the data assets. Once this is done, the next step is to do application portfolio analysis and do direct mapping between services and data operations (business-level CRUD).

A point to be noted here is that I am not talking about exposing simple Create, Read, Update, and Delete operations to be exposed as services, since they are not (coarse grained) services at all. They are just functions to alter the constants of data model and if we expose them as services, we are trying to expose our internal data modeling, which is going to impact internal agility. Instead, what we have to expose is our coarse grained business operations (processes) which carry out useful business functions on behalf of client applications. When we do that, we can map which services need to be invoked to finish an online retailing experience, and which other services are responsible for realizing the retail booking in the back office systems.

Thus services are named, labeled, and all the more indexed. And you look at the index for a particular service similar to the way you look at a book index, to find a particular subject. Thus, we effectively pool services and consolidate unused capacity formerly spread over many connected systems and servers.

Message bus facilitates service sharing as compared to service reuse. In fact service sharing is one of the key aspects of SOA.

In service reuse, the same service is hosted in different deployment environments due to various reasons. Even though the component or the code behind the service is reused here, there is significant overhead in terms of deployment, management, and maintenance. The Service reuse scenario is as shown in the following figure:

Service sharing is, in contrast, the true sharing of a service itself. This means the service hosting environment is configured for different scenarios and consumers access the same service instance through multiple channels or formats. SOA web services can be leveraged to achieve this, and this is further enabled using a message bus as shown in the following figure:

Microsoft SQL Server has the ability to query remote database objects as if they were local to the server. Linked servers are useful in deployments, where the data can be split by functional area into databases with very little coupling as a means of scale out strategy. This means that a scaled out database can look like a single large database to an application. Similar to this, ESB can be seen as a means to link services. Binding to remote end points is synonymous to linking to remote databases—an application code can interact with the linked services as if they were local to the invoking code.

By service virtualization, I mean dividing the organization's information assets into "Virtual Services" without regard to the transport or binding protocol of the actual implementation components. Corporate network assets (information) can reside in multiple places like in a centralized mainframe or distributed across multiple systems implemented using DCOM, RMI, IIOP, remoting, or SOAP protocols.

Service wrapping and service aggregation are two methods by which we can virtualize them to be exposed in a consistent way to external or internal clients. Thus, virtualization is closely related to "black box" reuse of services by providing a different interface at the same abstraction-level. The ESB abstracts behind the scene addressing, translations, and aggregation.

Well-defined interfaces facilitate development of interacting software systems not only in different LOBs, but also at different times, thus providing a suitable abstraction for any consumers of the service. But abstraction has a negative side too—software systems, components, or services designed for one interface will not work with those designed for another interface. This, in fact, is an interoperability issue which can be a concern, especially in a world of networked computers where the trend is to move data and information freely.

Service virtualization is a way to circumvent this issue by mapping the visible interface of a service onto the interface and resource of an underlying, possibly different, real service.

This figure depicts the concept of Service Virtualization, where we make use of core ESB features like Aggregation, Routing, and Translation to republish the existing service assets. These are explained in detail in subsequent chapters.

We, integration people, need to learn lessons from the way network architects organize their network channels. When using fiber, network architects have three network topologies. For the fibre channel option, we have three network topologies via any from the following list:

In the fabric topology, there are one or more hardware switches in addition to ports on each device to network. Comparatively, in ESB we have intelligent adapters. Multiple clients can hit the ESB fabric, and intelligent adapters at the ESB edge are responsible for dynamic binding of client requests to appropriate concrete service implementations. Thus, ESB services fabric functions as the virtualization layer. In other words, the ESB provides infrastructure capabilities and application plug-in points for an SOA fabric for the whole enterprise.