ESB - Enterprise Service Bus

Basic functions of ESB

• Providing interaction interfaces
• Sending messages and routing
• Data translation
• Sensors of events
• Management of politicians
• Virtualization

Architecture of ESB

The basis of architecture of ESB  is the idea of use of the general integration infrastructure all corporate applications based on message exchange. All applications interact through one point which, in case of need, ensures safety of addresses, data translation and transactions. At the same time the purpose of integration of the application is creation of the only module (or the adapter) which is responsible for "connection" of the annex to ESB. Executes postprocessing of messages and their routing in other systems, ESB on the basis of the set business rules independently. This approach provides excellent flexibility, simplicity of scaling and transfer therefore in case of replacement of one of applications connected to the bus, it is not necessary to recustomize the others.

Merits and demerits

ESB is advantages:

• The organization of placement of the existing systems is performed quicker and cheaper.
• Increase in flexibility.
• ESB is based on the conventional standards.
• Existence of a large number of a configuration for integration.

Carry to number of shortcomings of ESB:

• Complexity of implementation
• Requires big resources.

Development of Enterprise Service Bus

Distinctive feature of Web services is that the consumer has an opportunity dynamically to contact provider of service. All this occurs thanks to two main functionality:

• Detectability. In automatically supported directories providers of Web services can be brought together. Thus, the consumer is given an opportunity to browse such directory to find provider of the necessary service.
• Self-description. The web service is capable to describe itself by method, convenient for machine reading. So, it is possible to recognize two or more providers of the same service even if they are executed absolutely differently as their descriptive interfaces answer the same description.

Such functional capacities of Web services cardinally differ from the existing approaches to integration in which interfaces were defined in compilation time and during communication of the consumer with providers. The message formats were expressed not descriptively. They could not force to follow this format therefore were based on the internal arrangement therefore the receiver could not process the structure created by the sender.

The self-description of Web services facilitated integration using the declaration of interfaces which needed to be followed. Thanks to dynamic detection of service, the consumer was exempted from dependence on specific provider with a certain address, however, and this opportunity created own problems. It was rather heavy to resolve an issue of communication of the consumer with provider once and for all in compilation time and potential search of new provider by each call during execution. Then ESB suggested other option  — to give the chance to the consumer once dynamically to contact proxy service, having at the same time an opportunity to use several providers and providers who can appear in the future, through this proxy service. All this says that ESB makes services consumers, available to their call, and gives the chance to consumers to find services a program method.

Gateway of services

The so-called gateway of services is a cornerstone of synchronous ESB. He mediates between providers and consumers of services, rendering at the same time assistance in processing of synchronous calls using the broker. This gateway opens access to all known services and proxy services of each of them therefore it is some kind of "single window" for the consumer wishing to call any service of any provider who is known to the gateway. When Web services are coordinated by the gateway, they have capability to the self-description. Each service provides the interface using WSDL which consists of the following four parts:

• Types of ports  — a set of transactions which are executed by Web service.
• Messages  — i.e. a format of requests and answers
• Types  are Data types which are used by Web service
• Communications  — the address for a transaction call

Web services of the gateway, to be exact their proxy services are also detected. The gateway gives such chance in the form of UDDI service. To find the address of a call of service the consumer sends a request in UDDI service of the gateway the list of providers of necessary WSDL transaction and receives back the address of proxy service of the gateway for this transaction.

Bus of messages

The Message Bus template (Sheena of messages) is a basis of asynchronous ESB. The bus of messages  is a set of channels of messages which are configured as couple of channels a request answer. Each pair represents service which the consumer using the bus can cause. The consumer sends the message to queue of requests of service and after that listens to queue of answers for obtaining result. The consumer actually does not know about the one who provides service. Providers of services are also connected to the bus of messages and wiretap it on existence of messages of requests. In the presence of several providers of service, between them there is a competition as between consumers for receiving a specific request. The system of messages executed by the bus of messages functions as the manager of messages and sends requests to providers of services, optimizing this mailing depending on a load scale, cross-network delays  , etc. After the provider received a request, it executes service and enters result to the message in queue of answers, i.e. the provider and the consumer never know about each other location. This bus of messages is also an entity of ESB.

See Also

SOA

SOAP

WSDL

UDDI

Links

IBM: ESB in practice

developers need Enterprise Service Bus?

World: WebSphere Enterprise Service Bus (source codes)

Enterprise Service Bus  — Wikipedia