SOA and EAI (continued...)

I was recently speaking to someone heavily involved in EAI projects about the relative advantages of SOA over EAI. I found his initial reaction rather curious. It was his view that SOA was an architectural approach that was applicable only in "green fields" contexts. That is, where services are built from scratch and existing IT assets are simply discarded.

This misconception is understandable. How can applications participate in an SOA if they were not designed to do so? Well this is indeed true to some extent. They certainly cannot participate in an SOA without help. I touched on this briefly when discussing COTS applications in the context of service boundaries.

This view is somewhat compounded by criticism that SOA involves too much theory and not enough pragmatism. This view to some extent derives from reports of SOA projects that got caught up in "analysis paralysis" and never really delivered anything.

EAI practitioners sometimes claim that the EAI camp is all about just getting the job done, while SOA practitioners are purists by nature and get too wound up in theory.

While it is true that some SOA initiatives have ended up this way, it is by no means a problem with the architectural style. Merely a problem with how that style was applied. That is, it is a failure of the SOA practitioners involved, not the principals underlying SOA in general.

So how do we leverage existing IT assets in support of an SOA? We use a service wrapper. A service wrapper is effectively a layer of abstraction between new and existing IT assets that support a service, and the service boundary. We already have a well established approach for achieving this - EAI.

We do not want to suggest that SOA replaces EAI. Not at all. We just want to limit the scope of EAI to the service rather than the enterprise. We do not want to directly connect applications that sit in different services. To do so would violate our service boundaries.

All the existing EAI toolsets and principals are applicable in this context. In fact, many ESBs ship with EAI capabilities - including process orchestration engines and a suite of adapters for plugging into common legacy systems.

A message arrives at the service boundary, and the orchestration engine coordinates the activities of the various systems behind the service boundary appropriately. Orchestrations can also be initiated in response to events which are detected inside systems supporting a service. An orchestration can also send or publish messages back out onto the service bus as necessary.

So EAI is just as important as it ever was. We just limit the scope at which it is applied from the enterprise to the service.