Enterprise Requirements for ESB

ESB supports the concepts of SOA implementation by:

• Decoupling technical aspects of service interactions
• Integrating and managing services in the enterprise
• Map service requests from one protocol and address to another Transform data formats
• Support a variety of security and transactional models between service consumers and service providers and distinguish that consumers and providers might support or require different models
• Aggregate or disaggregate service requests and responses
• Support communication protocols between multiple platforms with suitable qualities of service
• Provide messaging capabilities for instance message correlation and publish/subscribe to support different messaging models, such as events and asynchronous request/response

Because the ESB removes the direct connection between service consumer and providers, an ESB enables the replacement of one service implementation by another with no effect to the consumers of that service. Thus, an ESB allows the reach of an SOA to extend to non-SOA-enabled service providers. It can also be used to carry migration of the non-SOA providers to using an SOA approach without impacting the consumers of the service.

Support for multiple interaction patterns:

• To fully support the variety of interaction prototypes that are required in a comprehensive service-oriented architecture (for example, request/response, publish/subscribe, and events)
• The WebSphere ESB must support in one infrastructure the three major styles of Enterprise Integration. The ESB is emerging as a middleware infrastructure component that supports the implementation of SOA within an enterprise.

Decoupling the consumer’s view of a service from the actual implementation of the service:

These concepts are achieved by substitute direct connections between service consumers and providers with a hub and spoke architecture

Use the ESB to perform some of the following middleware functions:

Enterprise requirements for an ESB: 

An ESB to implement an SOA has a number of advantages. In an SOA, services should, by definition, be reusable by a number of different consumers, so that the benefits of reduced connections are attained. In addition the ESB: 

ropes high volumes of individual interactions. 

Supports more established integration styles, such as message-oriented and event-driven integration, to expand the reach of the SOA. The ESB should allow applications to be SOA-enabled either directly or through the use of adapters.

Supports centralization of enterprise-level qualities of service and manageability requirements into the hub.

Mediation support 

The ESB is more than just a transport layer. It must provide mediation support to facilitate service interactions (for example, to find services that provide capabilities for which a consumer is asking or to take care of interface mismatches between consumers and providers that are compatible in terms of their capabilities). It must also support a variety of ways to get on and off the bus, such as adapter support for existing applications or business connections that enable external partners in business-to-business communication scenarios.

To provide mediation support, it must support service interaction with a wide variety of service endpoints. It is likely that each endpoint will have its own integration techniques, protocols, security models, and so on. This level of complexity should be hidden from service consumers.They need to be offered a simpler model. The ESB is required to mediate between the multiple interaction models that are implicit by service providers and the simplified view that is provided to consumers.

Protocol independence

Services can be offered by a variety of sources. Without an ESB infrastructure, any service consumer that needs to appeal to a service needs to connect directly to a service provider using the protocol, transport, and interaction pattern that is used by the provider. With an ESB, the infrastructure shields the consumer from the details of how to connect to the provider.

In an ESB, there is no direct connection between the consumer and provider. Consumers access the ESB to invoke services and the ESB acts as an intermediary, passing the request to the provider using the appropriate protocol, transport, and interaction pattern for the provider. This mediation enables the ESB to shield the consumer from the infrastructure details of how to connect to the provider. The ESB should support several integration mechanisms, all of which could be described as invoking services through specific addresses and protocols, even if in some cases the address is the name of a CICS transaction and the protocol is a J2EE resource adapter that integrates with the CICS Transaction Gateway. By using the ESB, the consumers are unaware of how the service is invoked on the provider.

• SOAs in which applications communicate through reusable services with distinct, explicit interfaces. Service-oriented interactions leverage underlying messaging and event communication models.

• Message-driven architectures in which applications send messages through the ESB to receiving applications.

• Event-driven architectures in which applications generate and consume messages independently of one another.