My post before Christmas sparked an excellent thread on the SOA Yahoo! Group around whether an Enterprise Service Bus was really a “keystone product in a SOA strategy” as I claimed . What the discussion highlighted for me was the importance of balance between the need to strive to design reusable services and the need to be pragmatic and fix service definition mismatches when they inevitably occur.

Anne Thomas Mane contributed to this discussion with points that I would at least partially agree with (A statement that she may find surprising as she identified herself as one of the "remaining hold-outs who continue to argue strongly that ESBs are irrelevant or transitory" who I referred to in the original posting.) Her points were:

1. “[An ESB] provides a means to expose legacy application functionality as services, and it supports mediation (although not efficiently) and sometimes orchestration”. Most ESBs provide good support for accessing existing applications, manipulating message formats and doing the work required to covert one or more existing systems into a black box service implementation which consumers can access without worrying about what is going on inside the box. I certainly agree with these statements.

2. “not all messages must flow through an ESB. Only those messages that require the services of the ESB should flow through the ESB.” To a degree, I agree with this one as there will be cases where the ESB provides little value beyond the acting as a common infrastructure through which all messages can flow – the value of which commonality must be judged on a case-by-case basis.

3. Anne’s third point is that by relying so strongly on an ESB – with its integration capabilities – it can undermine the focus on getting the service definitions right. In effect because an ESB can fix deficiencies with your service definitions on the fly, organizations can get away with poor service design – initially at least. Again I have sympathy with this but I feel it is like shooting the messenger. The SOA message is that the service definitions are crucial to getting the reuse/sharing which drives the economic argument. It is absolutely the case that adopting an ESB or any other product should not be used as a way of avoiding that architectural investment. Using an ESB without investing in service design is simply using an updated EAI product to do old style EAI!

Which brings me back to a favorite question: is it possible to create services which are capable of being used by all potential consumers now or in the future without some mediation (such as transformation orchestration) between the service implementation and consumer? I simply do not believe it is. Even if you can design the service to suit all possible needs today without mediation, there will be unforeseeable changes in the future.

The answer could be to refactor the service but the experience of many years of attempting to build large scale data models (which is effectively what you are trying to do – build a shared model between service definition and all the consumers) tells us that this gets more and more difficult to achieve as the scale (the number and diversity of clients in this case) increases. Therefore, the only alternative is to accept that to some degree there will be a need for mediation as the service definition will not be perfect for every consumer. The only remaining issue is whether individual ESB products provide sufficient mediation capabilities. And again I tend to agree with Anne when she criticizes the three ESB vendors that she name checks (IBM, Sonic and BEA) as these do not provide great mediation capabilities within their ESB products. However, current product deficiencies should not (yet) lead to the ESB baby being thrown out with the bath water.

Ronan

Posted by rbradley in Enterprise Service Bus • SOA concepts | Permalink | Comments (0) | TrackBacks (0)