BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

ESB: A Modest Proposal

by Miko Matsumura on Nov 08, 2006 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

"centralized" 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

ESB proposal 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

Re: ESB proposal 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?

A more distributed solution? 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.

Service Bus Router 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!

Re: Service Bus Router 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

Re: A more distributed solution? 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

Still assumes "one" of something 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.

Re: Still assumes "one" of something 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 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.

Re: Still assumes "one" of something 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.

Re: Still assumes "one" of something by John Harby

What I see as silly is when I look at the diagram at 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?

Re: Still assumes "one" of something 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.

Re: Still assumes "one" of something 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.

Re: Still assumes "one" of something 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

What is wrong with a centralized router component? 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...

What is ESB 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.

Re: What is wrong with a centralized router component? 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?

Re: What is wrong with a centralized router component? 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..

Re: Still assumes "one" of something 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.

Re: A more distributed solution? 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.

Re: A more distributed solution? by John Harby

I think you can use constructs from BPEL and WS-Addressing for this:

blogs.oracle.com/matt/2006/08/23

Re: A more distributed solution? 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.

Re: What is wrong with a centralized router component? 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)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

23 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT