There have been many recent discussions pertaining to the Enterprise Service Bus (ESB) concept in Service Oriented Architecture. The ESB is becoming prevalent in vendor offerings and has some tempting features. All services can connect to the bus and benefit from a host of common messaging and other generic services. Figure 1 illustrates this scenario albeit in a very simplified manner.
Figure 1
Basically service consumers make requests which are routed to various services. The Enterprise Service Bus (ESB) contains a mechanism for service orchestration and workflow and also handles service-to-service requests as well. Various common services such as security and policy can also be applied by the ESB infrastructure. This yields a centralized approach to SOA.
However several issues may invoke concern with respect to this solution. One objection would be that the ESB is taking too much responsibility. Many requests will be serviced by infrastructure features that they do not need. This sort of problem arose in the J2EE container world. Many wanted to use alternate persistence services such as Hibernate rather than the persistence provided by the container ergo the birth of the lightweight container.
A second issue involves what some call an "Architectural Stovepipe". As with the general "Stovepipe" antipattern, this implies that like Message Oriented Middleware (MOM) platforms, a strong selling point of an ESB is centralization. All activity of all applications passes through the bus with possible exceptions of reporting systems that interface with data warehouses. But this can imply that every project the department undertakes must interface with the bus. In MOM days this meant writing complex adapters even if your app was only doing some CRUD operations on a simple database.
Finally, although most ESBs are claiming to be standards based, vendor lock-in is an obvious consequence of adopting them. That lock-in also mandates cooperation of any vendors used for building and buying all services, consumer frameworks, etc. Even when providing standardized interfaces, the risk introduced is obvious.
So what is the alternative? Obviously the asynchronous messaging and routing services provided by service buses are essential in many use cases. So it seems reasonable to conceptually separate the registry from the bus. The registry can remain centralized and buses can be employed only where necessary. The role of exactly what this registry provides can be configurable.
