ESB: A Modest Proposal

Posted by Miko Matsumura on Nov 08, 2006 08:28 AM

Community

SOA

Topics

ESB

Tags

Criticism

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.

Complete article is available here.

1. Back to top

   "centralized"

   Nov 8, 2006 8:44 AM by miko matsumura

   (full disclosure: I work at Infravio/webMethods) I agree with this architectural model, and find that the figure 2 diagram shows a logically centralized registry model. This is very much in line with our customer experience and the federation of heterogeneous intermediaries (which include ESB but also lightweight WS intermediaries and XML gateway appliances) seems to be almost a requirement for large scale enterprise and multi-enterprise projects. What's not obvious from the diagram is that the registry (registry repository) is federated, which means that in the case of Infravio that it is logically centralized (provides a system of authority for policy and lifecycle management), but topologically distributed. This means that there's not a classical "single point of failure", but at the same time the system maintains the integrity of policy across heterogeneous systems and policy environments. Miko

   Reply

2. Back to top

   ESB proposal

   Nov 8, 2006 12:38 PM by Paul Fremantle

   Firstly, my disclosure, I work at WSO2 and am a committer on Apache Synapse. I agree with a lot of what this article says. Those who have seen me present on Apache Synapse recently - at ApacheCon and Colorado Software Summit will have seen some pictures very similar to those John draws. In fact the model we are promoting for building ESBs with Synapse is a set of routing and broking nodes that draw their routing tables and other metadata from a logical central registry. I think this model will resonate with people as making the term ESB a little more real. So I'm definitely +1. Paul

   Reply

3. Back to top

   Re: ESB proposal

   Nov 8, 2006 4:34 PM by Jeevak Kasarkod

   Wow...Im a little overwhelmed because I havent yet dealt with heterogenous federated deployments. Does this architecture also facilitate service choreography across ESBs? How does message correlation work between ESBs from different vendors? Do the buses have to be atleast JBI compliant? What is the exact role of the registry and does this architecture necessitate a runtime policy engine for enforcement?

   Reply

4. Back to top

   A more distributed solution?

   Nov 10, 2006 8:04 AM by Mark Richards

   I titled my reply as such because I think that was the overall spirit of your article. While I think your ideas are interesting, your diagram illustrating the registry taking some of the responsibility means that the registry component must handle routing, message transaformation, security, protocol transformation, and possibly message enhancement, all of which are also handled by the ESB. Thus, you end up having components within the architecture that basically are doing the same sort of infrastructure capabilities. I am not sure I agree with your statement:

   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

   Centralization may in fact be a necessary evil if we want true decoupling of services from clients. If not, we might end up with the same "spaghetti architectures" we have today, with clients having to know too much about the services and being tightly bound to those services (comments?). I agree with you that the registry plays an important role in the ESB world. However, in contrast to your diagram I think it should have responsibility for implementation service lookup (endpoint management and service location transparency), authorization (can this client invoke this service?), and also act as a catalog (if I change this interface, what clients are affected?). In my mind it is more part of the core ESB than a separate component. That said, I really like the notion of *some sort of component* to act as a traffic cop / router for federated ESB's. I am not sure this problem has really been addressed in the industry yet, and your diagram and solution point to a simple and elegant solution towards this issue. I would love to see more work in this area.

   Reply

5. Back to top

   Service Bus Router

   Nov 10, 2006 8:50 AM by Mark Richards

   John, After re-reading your article I believe I got the idea of what you were trying to get across, and I rather like it. My problem is with semantics - using the traditional *service registry* as the central bus router. I took your diagram and replaced the service registry with a *Service Bus Router*, and removed the links to direct services (again because of the capability cross-over I described in my prior reply). The Service Bus Router decides what ESB to forward the request to. In the past I have implemented this concept using MQ, but the problem remained that the client needed to know what queue manager to connect to and post to. In your example the client is *futher* abstracted from the implementation by not having to know what queue manager to write to - that is taken care of by the service bus router component. It can also handle failover, context routing, etc. I like the concept in that context. Good proposal!

   Reply

6. Back to top

   Re: Service Bus Router

   Nov 11, 2006 4:26 AM by Paul Fremantle

   Mark There is a difference between the registry and the router. The router is a runtime agent that may have multiple instances running. The registry is a source of the metadata. Logically the behaviour is exactly as you describe, because the routers are using the config from the registry to make the routing decisions. If you are interested, I can describe how this works with Synapse. Paul

   Reply

7. Back to top

   Re: A more distributed solution?

   Nov 11, 2006 7:21 PM by miko matsumura

   To answer Jeevak's question, above:

   Does this architecture also facilitate service choreography across ESBs? How does message correlation work between ESBs from different vendors? Do the buses have to be atleast JBI compliant? What is the exact role of the registry and does this architecture necessitate a runtime policy engine for enforcement?

   The architecture certainly enables choreography across ESBs, provided that there is a means of enforcing a degree of policy consistency from the registry service. As to message correlation, I'd need to get more about what you mean by that term... The busses are sufficiently isolated by this model that they dont neccesarily need to all support JBI--in fact in "the wild" the common patter is for these "ESB" entities to be made up of a combination of homebrew transports, lightweight WS "fabric", XML gateway appliances, integration hubs and "ESB" products. So picture the multiple ESBs as being heterogeneous. What is the exact role of registry and is there a need for policy enforcement engine... In my view, the registry in this scenario takes on a role as a federated policy system of record via an integrated repository. In terms of policy enforcement in this model, design time policies as well as lifecycle management policies are enforced in the registry repository, while runtime policies are enforced in the various ESB systems. My 2 cents, YMMV Miko

   Reply

8. Back to top

   Still assumes "one" of something

   Nov 12, 2006 6:29 AM by Steve Jones

   The only issue I'd take with this is that it still thinks there should be "one" of something. Why not have a registry per bus with other registries detailing what is available at different layers of granularity. Or enabling two companies that have independent SOA infrastructures to share only what they wish to share via a "virtual" registry. biggest lie in IT is "Enterprise" so I'd say that if you are assuming one uber registry to bind everything then you are going to have almost as many issues as a single bus. Think about the way DNS works from top level to sub level and I'd say that this is a good model to go for.

   Reply

9. Back to top

   Re: Still assumes "one" of something

   Nov 12, 2006 10:33 AM by John Harby

   Thanks to everyone for the great feedback on this article and also to Miko for responding. I think Steve has an excellent point concerning the registry. The motivation for writing this came from some of the blog entries at http://www.looselycoupled.com/blog where Phil Wainewright and others were discussing the notion of the "Enterprise Services Network" a couple of years ago. Certainly such a concept would prescribe multiple registries so this makes perfect sense to me. I think as Jeevak pointed out as well though there is always the cost of interoperability to consider and one would have to assume that registries from different vendors supported some type of underlying standard for integration.

   Reply

10. Back to top

    Re: Still assumes "one" of something

    Nov 12, 2006 11:32 AM by Eric Newcomer

    Well this really all assumes the sort of brain-dead definition of an ESB that most vendors use - that of one tied to a single type of messaging infrastructure or other centralized service. An SOA is distributed by definition so these centralized ESBs are fundamentally broken. The best approach is to use a truly distributed architecture like the one we at IONA use, one that does not impose topological constraints onto an SOA design. The distributed endpoints or agents can find and talk directly to each other using this architecture, which should eliminate all this silly talk about federated buses and registries.

    Reply

11. Back to top

    Re: Still assumes "one" of something

    Nov 12, 2006 11:47 AM by John Harby

    What I see as silly is when I look at the diagram at http://www.iona.com/solutions/soa/prodsol and imagine how many unnecessary operations are performed on a request originating from the portal consumer. Wasn't the emergence of Spring in the J2EE arena a lesson enough?

    Reply

12. Back to top

    Re: Still assumes "one" of something

    Nov 12, 2006 12:03 PM by Eric Newcomer

    No, that's a misunderstanding of the diagram. It's not a runtime diagram and that's not a portal. The GUI is the Eclipse SOA Tool and the arrows are provisioning arrows, not execution or runtime arrows. The diagram is intending to show how a service can be designed, deployed, and updated dynamically. Also this has absolutely nothing to do with Spring or JEE - this is showing how a distributed, configurable microkernel works.

    Reply

13. Back to top

    Re: Still assumes "one" of something

    Nov 12, 2006 12:20 PM by Eric Newcomer

    To be clear, my comment is not a criticism of the article. I'm suggesting that the article would be different had the industry settled on a better definition of an ESB. In particular, one that was not tied to things like a specific technology such as an existing JEE server or an existing MOM. The point of an ESB should not be to sell more of those things but to tie things like that together better, and for reasonable cost. An ESB should be an improvement to existing infrastructure not a new way to sell the old stuff. Because the definition of the ESB tends to be whatever helps sell more of the old JEE and MOM stuff, we end up with centralized deployment architectures when we should have distributed ones.

    Reply

14. Back to top

    Re: Still assumes "one" of something

    Nov 13, 2006 4:32 AM by Michael Poulin

    My 1 penny. This is not that unusual idea about splitting not only communication infrastructure into a federation of busses but the registry as well. I have not considered exactly "a registry per bus" but well-known (forgotten) CORBA Object Trading Service defined trader registries in federation (Link Interface) from the very beginning. Plus, it had/has quite detailed rules for federation navigation as for the provider as for the consumer (the downside was, obviously, a weak management of the name-space federation, i.e. problems with ?the same? names expressed in different words). - Michael Poulin

    Reply

15. Back to top

    What is wrong with a centralized router component?

    Nov 13, 2006 6:49 AM by Mark Richards

    I like the idea of distributed, federated ESB's and the corresponding registries specific to each ESB, but I still maintain that in an enterprise architecture it is good to have a central registry/router to direct traffic. Such a router can certainly scale and be replicated for failover, so the bottleneck argument goes away. In the enterprise we typically use security in this fashion, so why not a central registry/router? I am just not seeing why it is such a bad idea...

    Reply

16. Back to top

    What is ESB

    Nov 13, 2006 12:10 PM by Boris Lublinsky

    There is a profound difference between ESB concept (pattern) and ESB products. An article seems to mix the two. It seems to start with the pattern but then the majority of considerations seem to be about the products. If we will agree that the pattern is the topic of the discussion, then figures one and two are more or less identical. Fig 2 is just partitioning of the ESB implementation into 3 instances - 2 labeled as buses 1 and 2 and the third one is not clearly defined. The registry in fig 2 is not a router, but rather a data provider for the router, which, in this case has to be implemented by every consumer. If this implementation is standardized, it becomes a third ESB.

    Reply

17. Back to top

    Re: What is wrong with a centralized router component?

    Nov 13, 2006 5:17 PM by Eric Newcomer

    I like the idea of distributed, federated ESB's and the corresponding registries specific to each ESB, but I still maintain that in an enterprise architecture it is good to have a central registry/router to direct traffic. Such a router can certainly scale and be replicated for failover, so the bottleneck argument goes away. In the enterprise we typically use security in this fashion, so why not a central registry/router? I am just not seeing why it is such a bad idea...

    Well the problem is that centralizing anything in a distributed system introduces difficulties when it comes to evolving the system. If you need to introduce a new service, or update an existing service, with a central hub you might have to take down all services. Also let's say the central hub runs out of resources for some reason - it is very difficult then to partition and replicate the data and the system. When you have a central point of control at runtime it introduces a dependency that affects all of the service endpoints. If you can use a distributed system instead, in which the endpoints are responsible for discovering and interacting directly with each other, you have a much more flexible system that's easier to evolve and change. Could you imagine a central point of control on the Web?

    Reply

18. Back to top

    Re: What is wrong with a centralized router component?

    Nov 13, 2006 5:24 PM by miko matsumura

    Some decently pithy conversation here. I think the happy medium is Federating, which creates logical centralization but topological distribution. My 2 centimes..

    Reply

19. Back to top

    Re: Still assumes "one" of something

    Nov 14, 2006 7:13 PM by John Harby

    Ok, fair enough. But that's a bit confusing because the diagram specifically states "Portals & Dashboards" as example consumers. One area of concern I have seen in the field pertaining to ESB's and their prior MOM's is that an IT department will attempt to standardize on these universal solutions. But then projects will come along like a simple portal interacting with a database that will have to fit in to this monster infrastructure. This is why I drew the analogy to Spring since their view of declarative services was to provide only what was necessary where it was necessary. I would agree that simple routing, monitoring and certain security aspects certainly apply across the board.

    Reply

20. Back to top

    Re: A more distributed solution?

    Nov 17, 2006 6:31 AM by Jeevak Kasarkod

    Miko for long running, asynchronous workflows the messages that are sent across would need to be tied to a particular instance of this long running workflow. This is generally done through message ids(generated using simplistic generators like sequence etc) within an ESB and they term it message correlation. I am not aware of how that works across heterogenous ESBs.

    Reply

21. Back to top

    Re: A more distributed solution?

    Nov 17, 2006 9:38 AM by John Harby

    I think you can use constructs from BPEL and WS-Addressing for this: http://blogs.oracle.com/matt/2006/08/23

    Reply

22. Back to top

    Re: A more distributed solution?

    Nov 21, 2006 4:37 PM by miko matsumura

    Tough to make that particular pattern work across multiple ESB unless implemented as a stateful service that visits all the remote services as a consumer.

    Reply

23. Back to top

    Re: What is wrong with a centralized router component?

    Nov 23, 2006 6:49 PM by Naren Chawla

    I like the model of "registry per bus". As Mark pointed out in his excellent presentation, an ESB provides capabilities - mediation, service mapping (registry), rules engine and orchestration. From my experiences, we need to keep ESB stateless and optimized for high-performing mediation capabilities (think milliseconds or like a Cisco router). Routing being the core of mediation. Orchestration engines on the other hand are optimized to handle stateful long-running processes (think minutes/days or weeks). So, IMO, Orchestration should remain outside the bus. Regarding rules engine, most of the customers I have visited, prefer to use JRules or Drools or some external rules engine, so we just need to make a service call-out from the bus to evaluate rules. So this leaves two capabilites in the bus - Mediation and Service-mapping (registry). I think both of this capabilities form the core functionality of the ESB. As John Harby, correctly pointed out, enterprises will require multiple federated buses - one bus per domain or department. Each single bus will cater to a department and will also provide discovery capabilities to localized services in that particular department. However, it will be aware of ESB in it's nieghbourhood either using a peer-to-peer architecture or rely on one centralized enterprise-wide bus. Peer-to-peer topology will improve resilency and scalability, however, it will make management more complex. However, I would like to draw attention to centralized repository as a place where we model and store policies, metadata and other articacts for design-time governance. This repository will sync themselves with this individual buses (containing registries) with data relevant to each bus, so that bus can act as policy enforcement point. So the model I am proposing is multiple ESB's and each ESB containing a light-weight run-time registry that synchronizes itself with a centralized repository. The ESB topology could be either peer-to-peer or using centralized enterprise-wide router bus. This is similar to Gnutella (that uses P2P file-sharing) vs Napster (that relies on central server)

    Reply

• Older >