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.

Let’s end the confinement of ESB and EAI solutions and free the service endpoints!

This entry was posted in SOA. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s