ESB Roundup Part two: ESB Use Cases

Posted by Miko Matsumura on Jul 12, 2006 |

In part one of this series, we began with the basic definition of an Enterprise Service Bus (ESB) on the Wikipedia.

One of the points of general agreement seemed to be that an ESB was distinct from orchestration and Business Process Management belonged in a seperate class of product. In addition, there was a healthy debate on whether an ESB was a product or pattern.

In part two of this series, InfoQ examines the purpose of an ESB--what are the use cases and requirements for an ESB?

Dave Chappell from Sonic kicked off the debates in the previous article, part one of this series with a suggestion that Sonic Software might in fact try to standardize a set of UML based patterns that essentially define the reference architecture of an ESB.

Stuart Charleton (Enterprise Architect for BEA Systems' Strategic Consulting Services, in Toronto, Canada) offered the following examples of uses:

  • A consumer talks HTTP/S based authentication, a producer uses WS-Security
  • A consumer talks HTTP/RSS, a producer uses WebSphere MQ or JMS
  • A consumer talks HTTP/REST and URIs, a producer talks SOAP/WSDL
  • A consumer has one set of credentials, a producer has another set (keychain mapping).
  • An FTP site is the "service interface" for one end, but the files are broken up into JMS messages on the other end
  • A message may need enrichment before routing to a destination, so I can perform callouts to gather extra information
  • Protocol independent load-balancing and/or failover is required for a producer
  • Messages need to stored and forwarded, retrofitting reliability onto an unreliable service

And augmenting these themes, Paul Fremantle  (Co-founder and vice president of technology at WSO2) added:

So an ESB is a communications infrastructure that enables mediation. What topology should an ESB have? I think the topology should be flexible: you can build an ESB as a single big broker in the middle, or as lots of smart endpoints. Of course the topology affects the manageability, but as long as their is a central registry/repository to configure the ESB then it works fine. The key to this is that an ESB should be driven by policy not by writing code. 

Anne Thomas Manes of The Burton Group has said:

" ESB is especially good for bridging to legacy applications, and therefore it is a useful component in a services infrastructure. Many ESBs also support reliable messaging, asynchronous messaging, and pub/sub exchange patterns. These capabilities can also be pretty useful--but probably not in the initial stages of a SOA project. (Every organization has lots of projects to choose from that don't require these capabilities.) At a later stage in a SOA project, you might also want an orchestration engine, and most ESBs supply one--but that definitely isn't where an organization should start a SOA initiative. All of these capabilities are things that you don't need when first getting started. Therefore an ESB should be a later-stage purchase."

Which emphasizes the use of an ESB as a bridge for legacy applications. A recent study by Network Computing had survey respondents grade a set of statements about ESB technology using a scale that went from "Strongly agree to Strongly disagree". The top four statements which respondents most strongly agreed to were:

  1. ESBs must provide adapters to enterprise data sources (SAP, Peoplesoft, Oracle, SQL Server)
  2. ESBs must support at least rudimentary business process management
  3. Open standards (JMS, Web services) support is/was a requirement for our ESB implementation
  4. An ESB must integrate smoothly with existing enterprise application integration (EAI) and message-oriented products. 

This suggests that legacy data sources such as ERP and EAI systems are important interfaces for the ESB, and that they should expose those layers as standards based messages. The interesting finding was that end users seemed to agree that "at least rudimentary" business process management was something that an ESB "must support".

On a final note, Steve Jones from CapGemini suggested that in fact, the ESB problem was actually three seperate and unrelated problems, Integration, Build and Business:

.. One challenge is leveraging the current estate and getting functionality out (Integration), the second is building new applications (Build) and the final is managing the interactions between these new applications (Business). I blogged on it a while back.

Integration products have very different requirements and drivers from ones that aim to enable interaction in a more standards oriented space, and I'm not sure why it makes sense to confuse the two domains. Equally building new applications (in process or OO languages) requires different skill sets and approaches.

An Integration Bus will be measured on its power, a Business Service Bus on its simplicity and an Application Development solution by its flexibility. And any reasonably sized business will not have one solution that fits all their needs.

Part two of the ESB roundup hopes to help define the use cases that customers call for when they require an ESB. The general agreement that business process tooling was distinct from ESB coupled with the contradictory interest in this capability from end users suggests that there may be several product categories conflated into one.

For this discussion, please focus on the use cases appropriate for ESB.



Rate this Article


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
Community comments

Steve's distinctions by Stuart Charlton

Steve Jones makes a good distinction between the variety of cases out there. There are at least three classes or "audiences" for the what's needed to manage services.

I liken it to a gradient of "exposure". Business service interaction requries simplicity and a very coarse-grained approach, and a metaphor that analysts can understand, similar classic swim-lane activity modeling in Visio.

Service integration tends to be about focusing on adaptation and mediation -- one is not trying to build an application, so they don't need to be exposed to all of the nitty gritty details (but they can call out or access them if need be). This problem calls for a metaphor that enables a variety of interfaces & representations to "slot into" something that makes formats & protocols malleable, without a lot of fuss & detailed coding. It should make the operations, data format, transfer or transport protocol irrelevant, as they're all mechanisms with a variety of qualities and capabilities, but don't provide the core value-add of the service. The metaphor or "style" that works here, in my opinion, is similar to uniform pipes & filters.

Finally, there's application development, which can require a mix of front and back-end work, requires a productive interface but also needs to "get out of the way" to get things done. A process programming environment can work here, in combination with a user interface framework for screen flow & assembly.

When we speak of ESBs, I think most vendors are focused on the latter two problem spaces, and less on the first audience. An important question is whether an ESB is a glorified process programming environment, or should it provide more abstraction?

I was trying to explain the role of an ESB to a business person once, who was somewhat technically savvy (but not a technologist), and they had a great way of describing the benefit of an ESB: It's an embedded hygiene layer. Instead of providing too much freedom to allow developers to do what they want (the last case), it constrains you to respect the service contract. Everything that an ESB talks to should have a clearly defined service boundary, with well understood side-effects and implications when crossing that boundary.

What about INVALID use cases? by Paul Fremantle

One interesting question is what should you not do with an ESB?

I've seen some customers using an ESB layer to implement stuff like:

  • Complex transformations

  • Data enhancement

  • Stateful workflow management

  • Business logic

These things seem really dangerous to me, and in one instance where did all this was done, they ended up junking the whole approach because they couldn't manage it. Fundamentally they had moved their business logic from the applications down into the bus. And in my opinion, the bus is the wrong place for business logic.

So what are "good" use cases:

  • Logging, tracing, monitoring, managing message interactions

  • Routing, supporting different versions of standards, URL virtualization

  • Switching protocols: RM->JMS, SOAP->REST, WSS->HTTPS, Eventing->RSS

  • "Standard transformations" - for example JSON->XML

  • dumb transformations - e.g. supporting a switch from v1 to v2, changing namespaces, simple XSLTs, are also very valuable

  • QoS processing - e.g. terminating WSRM, WSSec connections, or initiating then so as to deal with those outside the application server

Re: What about INVALID use cases? by Demed L'Her

(disclaimer: I work in the Integration product management team at Oracle).


You said "dumb transformations". Would it be fair to rephrase that and say that an ESB should only be used for transformations from one syntax to another. Anything involving semantics (and I include data enrichment here) should be done outside of an ESB.

I liked Joost de Vries' reference to OSI-like layers and "separation of concerns" in part One. And that ties into Steve Jones' post that separates Integration from Business. In my opinion, a good way to keep an ESB honest would be to say that it is to be designed and operated by an IT department (yes, it's a bit of an oversimplification but it's a convenient reference).

Re: What about INVALID use cases? by Stuart Charlton

I think transformations are a hard one, as they're the area most in need of productivity. Fairly complex XQueries and XSLT's can be executed in an ESB in a productive and manageable way, and I don't see why they'd be more manageable outside of the ESB.

Similarly, data enhancement/enrichment's another case where configuring it into an ESB flow can make sense, though likely it would have to be simple. Parallel splits & joins likely aren't meant for an ESB (though you'd be surprised how many customers ask for this).

I do agree that stateful workflow management and business rules likely should be externalized.

Re: What about INVALID use cases? by Demed L'Her

Indeed, transformations are a hard one - mostly because the tools are getting so easy to use that it's very tempting to do one alteration here, another one there.

I don't think that anyone will object to the idea that business processes need to be shielded from each others' native data formats, to avoid the domino effect that a change in one application might create. Some kind of buffer is needed.

The ideal buffer is the canonical data model, a published, enterprise-wide, data model. All owners of business processes would normalize their data to a published canonical model before putting them on the bus. This would ensure that business owners (say the CRM group) only need to know about two models: their own and the canonical one. Only transformations left to the ESB would then be wire-level, "impedance matching" ones - from version translation to protocol-driven format changes. Similarly, an ESB could do syntax validation on inbound messages - to prevent invalid data to propagate too far downstream (while semantic validation is best done by the people who understand it: the business owners).

Another potential buffer is actually to use the ESB as the central transformation facility - at least it provides a convenient single repository to operate on when something changes. But the manageability (versioning, multiplication of mappings, etc.) and organizational challenges (who is in charge, who is accountable?) of this approach makes it questionable.

So it's really not a tooling question. All sort of transformations certainly can be, and are, done in an ESB (after all, the tools in an ESB are often the same ones that you find in BPM engines - XQuery, XPath..). But it goes back to the separation of concerns, internal policies and ultimately best practices.

(Side note: I don't think the ESB vendors, category that I belong to, should dictate any approach - they need to be aware of the multiple possible patterns, and flexible enough to embrace them all. We all know that the one-size-fits-all doesn't really exist here, no matter how many books will be published on the subject.)

Re: What about INVALID use cases? by Demed L'Her

I would add one item to Paul's "good" ESB use cases:

  • ESB as a gatekeeper to enforce security policies at the messaging level. Encryption, authentication and entitlements. These policies can be parallel and layered above business-specific ones. I said enforce (vs design and enforce) on purpose. These security requirements are not specific to an ESB - the rest of the business shares the same. So ideally the ESB should just be able to consume externally-defined policies and enforce them.

Re: What about INVALID use cases? by Paul Fremantle

Firstly I keep forgetting to acknowledge my disclaimer - my apologies - I'm VP of technology at WSO2 and heavily involved in the development of Apache Synapse.

Secondly - yes your rephrasing is actually spot on what I was trying to capture. I think that syntactic transformation is great. Semantics - including enrichment - is likely to cause trouble.

Just think of the original term "bus". The first "busses" in this sense were big blocks of metal with transformers attached switching down to the right voltage. That's a nice example of dumb transformation.

Re: What about INVALID use cases? by Paul Fremantle

I would add one item to Paul's "good" ESB use cases:

  • ESB as a gatekeeper to enforce security policies at the messaging level. Encryption, authentication and entitlements. These policies can be parallel and layered above business-specific ones. I said enforce (vs design and enforce) on purpose. These security requirements are not specific to an ESB - the rest of the business shares the same. So ideally the ESB should just be able to consume externally-defined policies and enforce them.

+1 from me

Improving existing software by Eric Newcomer

SOA is popular today because it is the right time for it. An ESB provides essential SOA infrastructure by improving what already exists.

The goal of working with legacy systems is to help them participate in a commmon architecture and approach that addresses current IT challenges.

For the most part, IT departments have the features and functions they need in their existing applications. They have the operating systems, application servers, and database management systems they need. Evidence of this is seen in how quickly open source is beginning to commoditize these types of software systems.

An interesting phenomenon associated with the ESB is how quickly it is also starting to commoditize via open source. Instead of simply commoditizing well-established software system types, open source projects related to the ESB and SOA infrastructure are well underway at Apache, Sun, Red Hat, and ObjectWeb.

But back to the main point - that the major use case for an ESB has to be adding that little bit of software to existing applications and systems that standardizes them and allows them to play well with other software regardless of operating system, programming language, communications protocol, or data format.

Other Use Cases by Kris Huggins

1. A central point to implement Business Activity Monitoring
2. A layer of abstraction that can insulate consumers from some changes to producers.
3. A central point to enforce governance rules.

Service creation and orchestration by James Pasley

An ESB should be about the Services and not just emphasis the Bus. If the services have been created appropriately, then it should be possible to contact them directly. This means that a very important use case for an ESB is the creation of Services from existing systems.

At one level this involves solving a number of integration issues such as transport switching, transformation of legacy message formats to XML, etc. This is typically the portion solved by exposing systems as Web services.

However, it's not sufficient to stop there. Services need to conform to the principles of SOA. Principles such as interoperability and compliance to standards, use of a contract will of course be addressed by the use of Web services technologies. Going beyond this may require the definition of a new contract and result in the need for service orchestration. This is particularly true if you need to address SOA principals such as granularity and reusability. In this use case, the integration issues are solved on the ESB by exposing existing systems as Web services. Then, creating a service that conforms to the remaining SOA principals is achieved by orchestrating such Web services into a new service with the appropriate granularity and easy of reuse.

CTO - Cape Clear Software.

Re: What about INVALID use cases? by Steve Jones

1 on these from me. This (to me) talks about a business focused, or at least "above" application focused bus rather than an integration, or even worse application development attempt.

I'd like to add one "good" use case

The ability to delegate decision making (policy

Re: Service creation and orchestration by Steve Jones

I'm not sure why orchestration would be part of an ESB, as soon as you start doing that you are building new application logic which means the ESB ceases to be about policy and starts to be about logic.

For me I'd put orchestration into one of Paul's "Bad" Use Cases.

Re: What about INVALID use cases? by Dave Chappell

I also am a believer in the canonical data model. It reduces the level of complexity in the sheer number of transformations from a n-squared problem to more of a n-linear problem. In fact most of our customers do it that way.

The ownership problem of transformations exists anyhow if you are building an enterprise-wide SOA, as you are likely building composite applications based on service invocations that span application silos. That's an organizational issue that needs to be solved regardless of how you are doing transformation.

I don't necessarily buy-into the idea that an ESB should be a "central" transformation engine, unless of course you are treating the word very abstractly to mean that is a core capability of the bus. In fact if the transformation capabilities are themselves capable of being distributed rather than being bound to a centralized model, then the ownership of the transforms can keep kept closer to the team with the domain expertise of the individual application that is being brought into the SOA through the ESB. They own the connection and interface (WS-*, adapters, FTP, etc) to the ESB and the responsibility of managing the transforms to and from the canonical data formats.

Re: What about INVALID use cases? by Dave Chappell

I would add one item to Paul's "good" ESB use cases:

  • ESB as a gatekeeper to enforce security policies at the messaging level. Encryption, authentication and entitlements. These policies can be parallel and layered above business-specific ones. I said enforce (vs design and enforce) on purpose. These security requirements are not specific to an ESB - the rest of the business shares the same. So ideally the ESB should just be able to consume externally-defined policies and enforce them.

1 from me

Agreed. Although I would add the caveat that this is also the realm of a Web Services Management platform. There is some overlap there in the roles and responsibilities. The way I view it is an ESB can enforce policies for the things that are "on the bus"--meaning, the service interactions that it is helping to connect, mediate, and orchestrate. It may even be able to define them too. However, once a service invocation goes "off the bus" (into an appserver, or into haphazard web service calls) then that is more the realm of responsibility of a Web Services Management or SOA governance platform to enforce policy based security.

Re: Other Use Cases by Dave Chappell

1. A central point to implement Business Activity Monitoring
2. A layer of abstraction that can insulate consumers from some changes to producers.
3. A central point to enforce governance rules.

This is another instance where this falls more into the realm of a Web Services Management platform. An ESB can help to lay some groundwork to help enable BAM, in that it can provide value added services such as XML persistence to be used for siphoning off relevant business data to be fed into a BAM solution.
Regarding #3 I don't think we should attribute centralized enforcement of governance rules to core functionality of an ESB. That also falls more into WSM. I don't think we're ready to say that ESB subsumes WSM. They play different roles.

Re: Service creation and orchestration by Dave Chappell

I didn't have time to get into it in the previous discussion, but I'll say it now. I'm in agreement with James, and also with the the Networking Computing findings on this -- that an ESB should include some kind of service orchestration, even if its rudimentary.
Delegating orchestration or processing logic to the ESB is a smart thing to do. There's a huge difference between general business logic and process control logic that's used to coordinate the interaction between services.

Migrating from Batch to Realtime SOA by Dave Chappell

A very popular use case for adopting an ESB is to enable the migrating from batch processing toward a more realtime sharing of information through SOA enablement.

The latency and error recovery problems associated with nightly (or weekly) batch processing can severely limiting businesses in their ability to react to business exceptions. The enablement of a SOA allows business logic to be combined and executed in ways that weren't before possible and live data to be exchanged in a more realtime fashion than ever before. This is another enabler of BAM (per previous discussions).

These are generic virtues of adopting SOA. What an ESB helps with in this area is the means for getting the batch data onto the bus, then disseminated in more efficient and reliable ways through ESB provided mediation and process control.
For starters, an ESB can provide a "better FTP" by chunking up bulk data and sending it across the bus using reliable messaging techniques. Once on the bus, mediation may be applied to split the data up into its constituent parts, transform it into the appropriate canonical data format, enrich it as necessary, and route it appropriately to the various services that need to process the data. If you are in the camp that believes that an ESB should support process control, then business process coordination logic may be added to better control the flow of information.


An article on ESB use cases by Stuart Charlton

There's an article by Kenny Shin on ESB use cases over on dev2dev that also looks like interesting input.

Re: Service creation and orchestration by James Pasley

We all agree that one of the purposes of the ESB is message routing. My experience with customers is that requirements expressed as the need for "routing" cover a range from simple routing all the way to process orchestration. Once you go past content based routing, you often hear something like this: "I want to split the message into several messages, send them off to separate services. Then aggregate the response messages that come back into a single message to be forwarded to another destination." And that?s before things like error conditions are considered.

This is much more eloquently expressed in Message Routing chapter of Enterprise Integration Patterns which outlines a scale from Content-Based Router to Process Manager. This is why I believe that in order to cover the full range of message routing patterns an ESB will require both a simple light weight router with features like content based routing and a BPEL engine for the complex scenarios.


Re: Service creation and orchestration by Steve Jones

Why not delegate that logic to another engine that is attached to the bus? The line between process control logic and general business logic looks pretty blurred to me, and I've get to see implementations that have made that distinction so clearly. If the ESB can do these things then someone can start building fully fledged applications in that area (and certain vendors have been known to encourage that) meaning the ESB turns into an application server. If the ESB doesn't have these things then that can't happen.

Functionality wise there might be a question of design time v runtime with separation at design time being much more important. But I struggle to see why it would be "better" to put orchestration into the Bus rather than having an orchestration engine attached to the bus delivering a new service to the bus.

The moment you start splitting messages, firing them off and collating the results you are (IMO) building a business service, which shouldn't be in the Bus.

An Article on an ESB Use Case from a Customer by Dave Chappell

I thought I would bring it up a level and mention some of he broader cases for adopting an ESB in support of a SOA.

The current issue of Government Computer News features a profile on Washington, D.C.?s adoption of Sonic ESB

This article talks about having ubiquitous access to property information for housing inspectors and tax purposes, but the broader DCStat program also encompasses an emergency response system for the city of DC and the surrounding areas.

A common characteristic of organizations adopting ESB is that they have disparate datacenters that need to operate autonomously, yet work together in a larger federated environment. Sonic ESB was designed to do this, and to even allow the creation of process flows that can seamlessly span the physical locations across IT boundairs. The city of DC fits very well into this use case. There are 66 unique "lines of business" within the city of DC which all have their own way of doing things in their own IT datacenters.

What they needed was a common Services Bus to span those 66 datacenters and allow the applications to integrate into the SOA using the interface technology and protocol that is most appropriate for each platform -- be it web services, ftp, specialized adapters, file pickup, etc.

In fact, I just looked at one of their presentations that they presented publicly at the last InfoWorld SOA executive Forum conference where they showed their vision for an ESB and listed the capabilities that they need for it (note: top of the list is "Process flow") -
  • Process flow

  • Transform

  • Load Balance

  • Routing

  • Validate

  • Security

  • Publish/Subscribe

  • Exception Handling

  • Federated Management

  • There are currently 3 projects that I know of that have been implemented - 1) The property information app mentioned in the article 2) An emergency response system that links together 911 call centers all around the DC area, doing pattern detection to look for things that could indicate a terrorist activity 3) Reducing crime rates by better linking together and providing visibility into call center reports for abandoned vehicles. Once the system was in place they reportedly discovered over a thousand around the city, that were being used a based of operations for drug dealers.

    In order to implement these three very different projects, they needed a common infrastructure in support of their SOA that was capable of being brought into each of the IT departments, easily integratable with whatever is there, and also capable of seamlessly linking into the other ESB nodes in other data centers to form a broader SOA backbone.

    You can't do that with just a "proxy".

    Re: Service creation and orchestration by Dave Chappell

    Ah yes. We are getting into subleties as to what's "on the bus" vs whats "off the bus". Certainly an orchestration engine as a bus enabled service is a valid use case (and one Sonic ESB supports as well).

    BTW, I use the term "bus enabled service" to describe something that has standards based interfaces like any other service, yet someone has done the additional work to preconfigure the standards-based hooks into the ESB's management console and configuration repository, and also possibly integrated with the ESB's SOA workbench (with perhaps an Eclipse plugin).

    That being said, there is a different variation on process control that we call Itinerary Based Routing. It is akin to "Routing Slip" pattern described in the Enterprise Integration Patterns book that James mentioned.

    With Itinerary Based Routing, a service request carries with it a set of instructions, attached to the underlying message as XML metadata, that get evaluated by each remote node of the ESB. The itinerary tells the ESB which service to send the message to next after completing the current invocation. Itinerary based routing is one of the things that contributes to the highly distributed nature of the ESB in that there is no centralized rules engine that has to be referred back to for each step in a process. It is inherently part of the bus fabric rather than a separate service.

    Itineraries also provides a degree of higher availability since parts of the ESB can go down or become temporarily unavailable while other parts of the ESB can continue to operate with their self-directed service requests (Other more advanced deployment configurations provide continuous availability, which also eliminate the likelyhood that any part of the ESB infrastructure will be unavailable).

    Itineraries are most appropriate for stateless operations, although some simple state passing can be carried with the process. In my ESB book I talk about SOA patterns that use splitter, fanout, and aggregator services combined with itineraries to do branching and merging of execution paths. When more stateful orchestration with long duration processing is required, then an orchestration engine may be layered in as a service as you point out. You may even combine the techniques--create stateful orchestrations that call out to highly distributed stateless itineraries to do some of their steps.

    Whether the person doing the modeling of the process choses itinerary based or stateful orchestration server based, the SOA Workbench may provide visual modeling tools to describe the process flow with the same familiar look and feel.

    The concept of itineraries is mostly valuable if the ESB implementation is capable of supporting distributed nodes that know about each other and are capable of cooperating with each other across departmental or datacenter boundaries. If it is hub-and-spoke based then its kind of a moot point.

    Re: Improving existing software by Tiberiu Fustos

    While I understand most of the people posting in this thread are working on product development, I allowed myself to add this post from a "potential customer" point of view and re-state what Eric Newcomer is saying: most of the companies have the technology pieces they need for SOA. They need maybe some additional components, but (for the sake of the industry maybe I'm wrong) - it will be a hard sell trying to make companies buy brand new stacks for their SOA needs.

    Many companies for example have already (internally) stadardised MOM, have invested in some kind of BPM tool, have had their (good or not so good) experiences with the "enterprise canonical data model" and so on. I think one trap for the industry is now to jump in and say "you need a completely new MOM, a completely new service development model (see SCA), another BPM tool" etc. etc.

    I am not sure it will be that easy to justify ROI if the required investments are too high, or too much to swallow from an organizational point of view. I think the winners will be the more nimble players, who can provide adaptable solutions that focus on some key points that the customers need and then try to upsell once the solution is proven.

    My wish would be to identify the core responsibilities of an ESB and deliver those well. (this just reminds me a discussion from the BPM community if Rule Engines should be part of a BPM solution or an external service). But maybe the success of a vendor in the new space will be finding customers that buy most of the add-ons and there is a race to show which product has most of the features.

    I don't want to be cynical but the slow pace of reaching agreements on the key WS-standards and their overlap somewhat reflects the lessons learned from the rapid comoditisation of J2EE...or maybe the time is not right to standardise these things yet - it's simply too early.

    Re: Service creation and orchestration by Steve Jones

    I've looked at this as an approach around Vendor Managed Inventory, the solution we looked at was to use a BPEL as part of the message payload and enable its execution to be distributed, again this would have been off bus execution. Now of course this does require the software vendors to play a bit nicer than today, but I can't really see why itinerary based routing couldn't be done off Bus as a standard approach within the payload of the message so the end point then queries for next response and sends on.

    One other challenge is the last line where you talk about ESBs co-operating, its definitely an issue right now with everyone having homogenous rather than heterogenous solutions. The reality is that most organisations will have several different ESB products, which is why have common base of what an ESB should do would be better than having a series of different all singing all dancing solutions.

    Re: What about INVALID use cases? by Ozawa Hitoshi

    (disclaimer: I work as a consultant at OGIS

    I agree with having a canonical data model. I've been
    experimenting with having a wrapper do the transformations
    so the service owner and the service user
    only needs to know about their own model and the person
    responsible for service orchestration only needs to know the
    canonical data model.
    I think the transformation, data enhancement, and service
    orchestration are OK as long as they are for integration
    purposes and not to implement business application logic.

    I think it more of how these features are used rather than
    whether ESB supports them or not that causes many problems.

    Re: Service creation and orchestration by Naren Chawla

    Look at the workflow patterns mentioned here -- In my mind, amost all integration solutions can be solved using one or more of this patterns.

    The questions is which of these patterns actually belong to the bus and which don't (and belong to off-bus orchestration engine). Currently, all vendors don't seem to agree on division of patterns between bus and off-bus orchestration engine and it is confusing the hell out of customers.

    Customer's understanding of capabilities of ESB is driven primarily by whom they talk first in their evaluation. IMO, this is really impacting the growth of ESB market-place.

    Now my opinion on division of patterns between the ESB and off-bus Orchestration Engine. I think I will point to the architectural principle of seperation of concerns. I will start with analogy in real-world by pointing to difference between a car and a plane. Generally, speaking car is ideal for making short-trips and plane is ideally suited to make really long-trips. Similarly, I see seperation of concerns between ESB and off-bus Orchestration engine. ESB is ideally suited for short-duration stateless use-cases (routing, transformation, protocol-switching, security processing) and off-bus Orchestration engine is perfect for handling long-running complex stateful types of scenarios.

    So if go back to the workflow patterns mentioned at the start of the message - the only pattern thaat ESB can/should handle is the sequence, while rest are the domain of off-bus orchestration engine.

    That might seem under-whelming, however, the real value-prop for the ESB comes from acting as proxy engine/intermediary that handles routing (all varities - transport header-based, soap-header based, paylod/content-based, dynamic routing), centralized places to perform transformation (xml-to-xml and non-xml to xml), protocool-bridging (jms to http, file to jms, etc.) and security gateway (act as entry point into your services network and do security processing in ESB layer, so every service in your network doesn't have to worry about it).

    As somebody said - "All problems can be solved with one more layer of abstraction". ESB is nothing but exactly one more layer of abstraction in your integration architecture that handles routing, transformation, protocol-briding and security. And doing so injects the magic-bullet into your SOA that will help achieve one of the key goals of SOA - business agility. Because ESB layer, makes all of the following a reality - flexibility (by enabling true loose-coupling), extensibility (easy to add new services or version existing services), composability (easy to build composite applications) and maintainability (policy-driven; management/monitoring capabilities in the bus; transformations centralized;configuration-driven).

    Another interesting aspect of ESB is that it crosses the boundary between development and operations departments with its capabilities. IMO, it is blessing for operations folks, since they can manage change very easily using the ESB. I always think of how I can connect to my network router and make changes if my IP changes or I add new subnet), the model is similar with ESB. If there is M&A activity or infrastructure changes, operations folks can fire up browser to talk to ESB router and change policies in run-time on produtions systems.

    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

    27 Discuss
    General Feedback
    Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
    Privacy policy

    We notice you're using an ad blocker

    We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.