We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Is ESB Still More Useful Than SOA in Certain Situations? What Are They?

Vote 0 Votes
Was reading this blog by ebizQ Editor Jack Vaughan, ESB Management on Tap for Mulesoft Middleware, which raises the question: Are there still some settings where ESB is more useful than SOA for an organization?  If so, what are they?

8 Replies

| Add a Reply
  • ESB is a technology. SOA is an architecture. ESBs are often deployed as part of a SOA strategy. Are you asking if it is useful to deploy technology to implement a specific business solution even if you do not have a full architecture strategy in place? Duh! Happens all the time. A more useful questions is how to you evaluate when it is worth investing in an architectural approach?

  • I dont think ESB is a technology. Some companies call their products as ESB. But fundamentally ESB is an architectural pattern too. I dont think ESB and SOA should be looked as one or the other. ESB as an architectural patterns solves specific integration problems. SOA is much wider (of course it depends on how wide you want to make this in an enterprise) and drives an enterprise's ability to provide its offerings as services.

  • Unfortunately, ESB is a pattern and technology, and both do not fit with Business Services due to their mediation nature.

    I am going to publish an article where I argue that if an ESB does not take business responsibilities on itself, it may not be used to separate business consumers from business services. An alternative for the ESB in the business services world is to become a part of the service or a part of the consumer, but not in between.

    Also, as Badari said, ESB is about solving integration problems that may have nothing to do with service orientation.

  • I've heard ESBs compared to a "one-day fly," serving some mysterious, but temporary purpose. In other words, an ESB may serve some tactical purpose, while SOA is focused, theoretically, on long-term transformation.

  • ESB is an integration technology. Integration Patterns could be useful for ESB as well as for other Integration technologies and styles. SOA is an abstract architecture, which is deployed by usage of concrete technologies. ESB is one of the most important technologies in SOA deployment, but not necessarily, the first stage of SOA deployment. ESB is not more useful than SOA. According to my experience, deploying ESB without clearly defining SOA is not useful. It is harmful. The entities, which are integrated are called Services, but most of them are not SOA Services. Applying SOA afterwards is very difficult due to confusing SOA Services with other entities. Read more in my post: ESB for an orphan http://avirosenthal.blogspot.com/2009/02/esb-for-orphan.html

  • I would suggest that it very much depends. The idea of a ESB from which data is collected and and to which data is presented on a logical level makes a lot of sense. However, when organizations use so called ESB products, they sometimes end up building objects in their ESBs using a little bit of data from here and a little bit of data from there. This generally means that the underlying data structure is not very good in the first place but instead of addressing the underling issue, they compound it by building more services on top of existing data models that don't accurately reflect what the business requires. At the end of the day, sometimes tactically it's necessary to do this but it should only be short term. Alas, we all know that short terms solutions can live for ever ! To answer the actual question, I believe an ESB can be implemented in a SOA fashion but the value really depends on what you are doing with it.

  • This is definitely an apples versus oranges question, and if an organization is asking this question, they need help. There is no either-or question to be answered between SOA and ESB. A better question to discuss is: "How is an ESB's potential value to an organization impacted by the organization's SOA strategy, or lack thereof?"

    At one extreme, let's suppose there is no SOA strategy, and there are simply people building services in the organization. It is likely that this camp will have a very integration-focused view of the world, and try to use an ESB in the same way as an EAI platform. Is there potential value? Sure. Is it required? Possibly. If I can't modify either endpoint, but I need to make them talk, I have to put something in the middle to mediate, and that could be an ESB. What's my risk level? Pretty high. EAI found out that in a hub and spoke approach, the more processing you push into the hub, the more of a bottleneck it becomes. At another extreme, someone could say, "We're building services, we must have an ESB." Traffic is funneled through it by mandate, but no one every really figures out why, or it only provides added capability (e.g. a transformation) for 5% of the service traffic.

    At the opposite extreme, let's suppose you have the best SOA strategy on the planet. If you do, there's a good chance that you've properly separated out run-time operational concerns configured by policy, from business logic concerns addressed through programming. You should also understand your needs for service traffic management. The list goes on. If you understand where you have cross-cutting concerns, where things need to be configured versus coded, the impact of change and whether mediation is needed, where black boxes exist and where you have full control, you should be able to make better decisions on where you may need to use a gateway pattern or a mediation pattern, both of which can be handled by an ESB (among other products). You may also decide that you don't need an ESB at all. An ESB is not a requirement for a successful SOA.

    Where do most organizations lie? I'm not an analyst, but my gut and first hand experience makes me think most organizations fall a lot closer to the first example. It is very easy to generate examples to justify a purchase of any technology using hypothetical scenarios that are real scenarios at other organizations. I may purchase an ESB for a particular project need which is valid, and as a result, may mandate that all service traffic goes through an ESB. To get value, the organization must be confident that other projects will have similar needs and not just pass through the ESB without any useful policy enforcement, mediation, or instrumentation. That confidence should be backed by analysis, but too often it is backed by intuition which has a higher risk of unwise technology investments.

  • The ESB, both as an integration pattern and as a product, is a direct evolution of the old EAI hub-and-spoke concept.

    The EAI hub-and-spoke was not intended to connect business services consumers and providers, just to connect any piece of functionality with any other piece of functionality (whether today we would call that functionality a business service or not). Unfortunately many projects today still use the ESB along those lines, with no attempt to rationalize its use according to SOA concepts.

    In its most naive interpretation, the EAI hub-and-spoke was deployed as a non-distributed monolithic piece of equipment, suffering from the well known single-point-of-failure problem. (Many EAI vendors actually went past that naive interpretation and provided fully physically distributed hub-and-spoke products). Unfortunately many projects today still use ESB products as a single monolithic piece of equipment, suffering the same single-point-of-failure problem.

    ESB products could effectively be used in a true SOA deployment, but their configuration should be distributed and their logical role should be as implementation components for the SOA service consumer and/or provider, under the same domain of control of the consumer/provider. The implementation role for the ESB inside the provider should be to facilitate the exposure of the same core business functionality under various interfaces and bindings. The implementation role for the ESB inside the consumer should be to facilitate the adaptation of the core client functionality to the various interfaces and bindings expected by service providers.

Add a Reply

Recently Commented On

Monthly Archives