Paul Fremantle: Reclaiming the ESB

Home

News: Paul Fremantle: Reclaiming the ESB

  1. Paul Fremantle: Reclaiming the ESB (7 messages)

    Paul Fremantle of WSO2 has written "Reclaiming the ESB," saying that "The single most important aspect of SOA is ownership. The point of a service provider ... is that they take full ownership of the problem domain." It "forces a central ESB team to understand and deal with every different application, format and protocol in the enterprise." This is an interesting assertion, but his core point is that a SOA should not deal with standardizing message formats, but that should be the responsibility of the service providers.
    It is time to reclaim the idea of an ESB to what it should be, a distributed network of services which are universally accessible using standard protocols and well defined interfaces.
    So: what do TSS readers think? Should the ESB be responsible for managing message formats for specific services (the prevalent model mentioned in Paul's article) or should the services themselves manage their own messaging and rely on the ESB primarily for routing and related services?

    Threaded Messages (7)

  2. I would definitely agree with this, especially the comment in the article that states that the need for an ESB is as "some runtime infrastructure that supports your SOA". I think that properly scopes the purpose of an ESB. And it encourages thinking in terms of "What runtime infrastructure support do I really need?", which should lead to an informed choice for an ESB (which may be no ESB at all). I'd also say that what the author refers to as "the single most important aspect of SOA is ownership", that is, "ownership of the problem domain", is also the hardest aspect. My experience has been that this is where you need the people that really understand the domain to come to some agreements, and that can be difficult to do, particularly in domains where multiple terms are used to describe the same concept, or the same term is used by different people to describe slightly different concepts. That's the hard work, and I don't know of anything that vendors can sell to help with that.
  3. Good article[ Go to top ]

    Nice short article with good points. Glad that the author pointed out where his company's product should fit in. Tired of companies trying to sell SOA in a box and labeling it an ESB.
  4. I actually think Paul's main point is that the message formats ARE owned by the "ESB", but the transformations are not. He states: "The idea of a uniform communications system with every party talking in a common format where anyone could connect to anyone else – well of course that is a “bus”." He says the central ESB team should not be made to know every data format and protocol, but rather each system or application team should make their data available using the common format. I take this to mean that every team exposes services where data is exchanged using the common format. This sounds like the central ESB team owns the common format, but the application teams implement services which conform to the format.
  5. He says the central ESB team should not be made to know every data format and protocol, but rather each system or application team should make their data available using the common format. I take this to mean that every team exposes services where data is exchanged using the common format. This sounds like the central ESB team owns the common format, but the application teams implement services which conform to the format.
    Yeah, thats a nice idea, but I bet that this will clash with organisational issues in many large organisations. I.e. Integration to the bus is driven as an initiative with resources allocated to a central team, while the application team doesnt have time to participate because they have to take care of maintenance and new functional requirements. Also, this tends to involve new technology, and management will certainly not like to train the entire staff in this, thinking that it is better if a small group of "experts" does it all.
  6. Let us forget about XML, XSD,SOAP, WS for a minute. Let us talk about service. I have a valuable service, I speak some crazy language however, if you consume my service. I deliver your requirement expected from my service with high quality, Do you buy it?. Yes for sure that is the foundation of human civilization and that is base of TRADE, BROKER or anything we know close to integration of a consumer and provider of a service. So who care about common message format. An ESB should be a broker capable to understand different language, protocol using adaptors and connectors Provide transformation, translation and wiring based on contracts or agreements between service consumer and provider without getting involved with the business objective of the consumer and provider. Even though ESB is not a business system, it handle business data between consumer and provider, so it should support Transaction awareness to manage the integrity of the data inside the messages. When it come tom ESB, I think whether I like to consider it as a stand alone tool or I like to consider it as a part of a platform. In case if I decide to go with platform, I also think whether I can consider ESB as a plugable entity to my platform such as J2EE or .NET ESB is a fancy word today in IT industry, not really a real solution. However in near future we will see Plugable, standard based, light ESBs out there to support all duties expected from an ESB solution, so that I can include that as part of an enterprise solution where my old generation continue to do their business in traditional manner and new generation application can build based on common standards and technologies.
  7. best of both worlds[ Go to top ]

    I think the ESB could satisfy both mindsets by doing as follows: A service and the team of people offering that service continue focus on their individual problem domain. If they are dealing with a new project, then perhaps a more "common" interface and message format can be adopted from the get go. If it is a legacy service, leave the "proprietary" interface and messages as is. The ESB (product and team) develop a well-defined interface and messaging system that should be adopted by all future services and which establishes a "common" ideology for inter-service communication. The fundamental idea though, is that the ESB allows for pluggable adapters. A third team would be responsible for creating adapters for a given service into the ESB. This group could be a subset of the team normally involved with the legacy service, or it could be a new team of "specialists" brought in to adapt the legacy service interface to the "common" ESB one. Domain-specific knowledge is contained and the ESB/team is not bogged down with knowing every service application/protocol. The ESB simply needs to offer plug-in points for service-specific adapters.
  8. Interesting article[ Go to top ]

    I agree with many of the points Paul makes. It is refreshing to here someone wanting to make things simpler with well defined roles for the components in the enterprise infrastructure. Jon Weaver XAware Inc.