In Pursuit Of Agility 2In Pursuit Of Agility 2

Middleware Requirements

Figure 2: The ESB middleware architecture. the boxes down the center represent protocol stack levels; the dashed line represents the middleware boundry.

The ESB supports decentralized, loosely coupled messaging. From the ESB perspective, communications are from any to any. As a result, each sender must be able to communicate with each receiver in a way that the receiver can understand. Figure 2 depicts the ESB middleware architecture. The dashed line represents the middleware boundary.

ESB middleware is the interface between each business application and the network that links it to other business applications and services. The application interfaces to the ESB middleware should be industry standard so the applications aren't locked into specific vendor products.

The Protocol Stack

ESB middleware provides an adaptive interface. The boxes down the center of Figure 2 represent protocol stack levels. Each can be set to perform different protocols at its level. When the system wants to establish communications with a particular service or application, the middleware binds each of these levels according to the protocol requirements of that particular relationship. Different protocols may be used concurrently for different business transactions and relationships.

The typical message transport layer binding will be TCP/IP using HTTP; however, there may be alternatives to HTTP, and a new version of HTTP may require a different binding. The binding should enable using alternative transport facilities transparent to the applications.

The reliable messaging level ensures that a message is delivered once and only once. The binding capability should enable transparent use of alternative message-oriented middleware (for example, an EAI message broker) for the exchange of messages with legacy integration systems or to achieve improved performance.

Message packaging involves embedding the message payload in an appropriate envelope. This is typically a Simple Object Access Protocol (SOAP) envelope. However, variations in SOAP specifications will require alternative bindings.

The orchestration level implements the appropriate process for the sequence of exchange of messages to comply with the choreography specification. It's also the point of control for interaction with legacy applications where information must be submitted or retrieved to support the intended business transaction.

Transformation

A transformation function embedded within the local ESB middleware will achieve better performance with messages than a separate, loosely coupled service. In addition, the ESB middleware has access to both the original message and the transformed message so that it receives signed messages in their original form and can sign and send outgoing messages after they're transformed. However, a loosely coupled transformation service may provide greater flexibility in the management of transformations.

Routing and Subscriptions

The routing and subscriptions component determines the network destination addresses of messages. It's desirable for the business application to direct messages to logical destinations to be converted to the specific Uniform Resource Identifier (URI) by the routing component. The system may also route messages through the transformation service, depending on the source and target destination.

The routing and subscriptions component also determines the addresses of event messages. A subscriber subscribes to a topic, and the routing and subscriptions function will receive relevant subscriptions (and cancellations) from the event registry service. The routing function will direct an event message to all the subscribers for the associated message topic.

Rate of Adoption

The ESB architecture can provide flexibility for ad hoc exchanges and event-driven operations. However, for several reasons, adoption is still in the early stages. First, potential customers already have substantial investments in EAI technology, and conversion calls for another substantial investment. Second, organizations still use Web services primarily for exchanges within relatively small, closed communities where they can control protocols and coordinate changes carefully. Third, Web services protocols are evolving, so that without adaptive interface capabilities, applications built on these protocols will require continued revision by skilled people to keep up with the technology. Finally, for the past several years, most corporate IT organizations have been focused on cost reductions and gaining rapid return on investment. ESB implementation requires a long-term investment with speculative business value.

What will change these conditions? I see several developments to watch:

Realization of the full capabilities of an ESB infrastructure will require development of additional industry standards. A user of this technology shouldn't be locked into a single vendor, and it's unlikely that a single vendor will be able to respond quickly to all changes in protocols and adapt effectively to all legacy technologies.

In particular, standards are needed for the following:

With an adaptive Web services interface in place, the continued evolution of Web services standards won't be a barrier to expansion. Standards efforts will then shift to the definition of various business transaction protocols — particularly the messages exchanged and the choreographies for particular types of business transactions.

Until then, the potential for competitive advantage is limited. Most organizations will continue to implement Web services interfaces on a case-by-case basis and adapt their EAI infrastructures to immediate integration needs.

Fred A. Cummins, EDS Fellow, is a systems architect and consultant with EDS. He is chair of the Business Enterprise Integration Domain Task Force for the OMG, and has more than 30 years of experience in management consulting and information systems development.

Resources