Free the Service Endpoints- SOA vs. EAI & ESB

From the mid 1990s through 2002, centralized middleware that used an Enterprise Application Integration (EAI) product was the silver bullet for managing a heterogeneous IT infrastructure. The Enterprise Service Bus (ESB) is a Web Services aware reincarnation of traditional EAI solutions. EAI and ESB are a driving force for centralization. This article discusses how a Service Oriented Architecture (SOA) can revert previous centralization and free the service endpoints.

EAI and ESB- Wardens of Services?

EAI products are essentially the same as ESB products. The difference between them is ESB's addition of and emphasis on Web Services. Both EAI and ESB share the idea of a centralized point of control and try to reduce everything to a common denominator. The architecture of ESB and EAI middleware is almost the same. As you can see in these EAI architecture diagrams and ESB architecture diagrams

Figure 1: Typical EAI architecture

Hidden Service Endpoints

As you can see from Figure 1 and the diagrams, IT landscapes were split into service consumers and service providers. The service consumers lived in front of the middleware and the providers were locked away behind the middleware, only accessible through the interfaces provided by the middleware.

Depending on the EAI product's philosophy, either document-oriented messaging (DOM) or remote procedure calls (RPC), are used for communication. If a client and the corresponding backend use a different communication model, then the integration platform function calls have to be converted into messages and vice versa. For example, access to a document-based Product Data Management (PDM) system had to go through an Enterprise JavaBeans (EJB)-based middleware. One solution was to pass entire documents as function parameters. As a consequence, solutions that worked during testing and pilot phases failed in production due to scalability issues.

To compose a service comprised of multiple services, each service call had to go through the EAI middleware. Each time, the middleware made security checks and transformations which resulted in huge overhead. As a consequence, the reuse of services was very limited. Figure 2 shows a compound service and how it communicates with its components over an ESB .

Figure 2: Compound service

Liberation of the Endpoints

SOA has the philosophy to expose the endpoints as equal and free members of the IT landscape. Each endpoint is visible and addressable. Endpoints can enforce security or transactions by providing a policy containing corresponding assertions.

A very promising specification for the endpoints is WS-Addressing which was recently submitted to W3C by BEA, IBM, Microsoft, SAP and Sun Microsystems. With WS-Addressing, service endpoint references can be described in the headers of SOAP messages. Now, a SOAP request can contain a reply reference to an endpoint that enables a target service to send replies once the original request has terminated. This is a breakout from the traditional client/server architecture. Service endpoint references expressed in WS-Addressing can also be passed from service to service. This is a major building block to establish coordination which is necessary for an SOA-compliant transaction and security infrastructure.

Moving the Infrastructure into a Service Grid

ESB and EAI middleware provide infrastructure services like transactions, security, routing and transformation. These infrastructure services are necessary to operate a large interconnected network of systems like those found in mid-sized and large companies. Some of the services, like transactions and security, need centralization. But, is it necessary to route every call through a proprietary ESB with its own architecture, features and limitations? Alternatively, an independent grid of services can provide crucial centralized functions without hiding the endpoint.

Figure 3: Service grid

Summary

EAI and ESB products are valuable tools to expose backend functions as Web Services. But, these tools shouldn't impose a rigid architecture. As more and more backends provide Web Services interfaces by themselves, and as more Web Services enablers are deployed at the backends, the influence of EAI and ESB middleware should diminish and give way to a Service Oriented Architecture.