BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or get video-only pass to recordings.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage Articles ESB Alternative - Article removed at the author's request

Development
Building an Efficient Cloud Application Architecture (Live Webinar June 22, 2023) - Save Your Seat

ESB Alternative - Article removed at the author's request

Bookmarks

Nov 08, 2006 less than one minute

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more

This article was removed from InfoQ at the author's request.

InfoQ respects the moral rights of any author, therefore the authors will retain the copyright for any content produced while InfoQ will retain the distribution rights.

InfoQ will remove any article if the author requests that InfoQ do so.

Rate this Article

Adoption
Style

This content is in the Enterprise Architecture topic

Related Topics:

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.

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

Community comments

  • "centralized"

    by miko matsumura,

  • A more distributed solution?

    by Mark Richards,

  • Service Bus Router

    by Mark Richards,

  • Still assumes "one" of something

    by Steve Jones,

    • "centralized"

      by miko matsumura,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      (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

      Back to top
    • ESB proposal

      by Paul Fremantle,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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

      Back to top
    • Re: ESB proposal

      by Jeevak Kasarkod,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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?

      Back to top
    • A more distributed solution?

      by Mark Richards,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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.

      Back to top
    • Service Bus Router

      by Mark Richards,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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!

      Back to top
    • Re: Service Bus Router

      by Paul Fremantle,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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

      Back to top
    • Re: A more distributed solution?

      by miko matsumura,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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

      Back to top
    • Still assumes "one" of something

      by Steve Jones,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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.

      Back to top
    • Re: Still assumes "one" of something

      by Eric Newcomer,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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.

      Back to top
    • Re: Still assumes "one" of something

      by Eric Newcomer,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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.

      Back to top
    • Re: Still assumes "one" of something

      by Eric Newcomer,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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.

      Back to top
    • Re: Still assumes "one" of something

      by Michael Poulin,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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

      Back to top
    • What is wrong with a centralized router component?

      by Mark Richards,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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...

      Back to top
    • What is ESB

      by Boris Lublinsky,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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.

      Back to top
    • Re: What is wrong with a centralized router component?

      by Eric Newcomer,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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?

      Back to top
    • Re: What is wrong with a centralized router component?

      by miko matsumura,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      Some decently pithy conversation here.

      I think the happy medium is Federating, which creates logical centralization but topological distribution.

      My 2 centimes..

      Back to top
    • Re: A more distributed solution?

      by Jeevak Kasarkod,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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.

      Back to top
    • Re: A more distributed solution?

      by miko matsumura,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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.

      Back to top
    • Re: What is wrong with a centralized router component?

      by Naren Chawla,

      Your message is awaiting moderation. Thank you for participating in the discussion.

      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)

      Back to top

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

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

BT