Let the bus go

Any Enterprise Services Bus on the market is capable of doing application integration from native adapters. Some ESBs are built on a service bus topology and some on a hub and spoke. Some are modified EAI products with web services support. Almost everyone can manage routing, transformation, logging, and other mediation services. Some have integrated rules support, but should all those features be managed as one single unit as in this picture?



Let's separate things out into a better logical architecture. First, a EAI product mainly support publish and subscribe funtonallity, which is not part of a true SOA. Let the EAI product do what it's supposed to do (i.e. integrate applications natively) and expose required functions as web services.

Secondly, break out rules, process, and service registry and make them accessable through web services. Expose web services from the master data and use a common mediation layer in between all enterprise services and the consumer layer. This way you will virtualize any application (including your EAI product) and keep all physical services under one umbrella.



Using mediation will get rid of the service bus architecture, which really is a questionable topology. With mediation, agents will not be necessary because the physical service will need no management. The mediation controls all traffic and will be the place for manage versioning, enrichment, etc.