ESB: a misconception brings to wrong architectures

Few terms in IT are more unfit than the ESB one.
ESB means
• Enterprise (only one for the whole enterprise)
• Service (brings web services calls)
• Bus (a common facility, like Ethernet or electric system).
Is it a correct definition? Lets start with “enterprise”. How many ESB will enterprises use in their future? There are many reasons why the majority of organizations will use more than one brand of ESB:
1. some ESBs come with COTS packages, i.e. SAP Netweaver or Oracle Fusion
2. appliances can be used instead of an ESB in presence of critical performance constraints
3. Merges & Acquisitions brings new ESBs in your IT department
4. sometimes you don’t have much budget an open source ESB could let you save money
5. a partner wants you to use its B2B solution, that includes an ESB
6. your preferred vendor has been acquired and your preferred ESB is no longer viable
7. …
Even when you succeed to install only a brand of ESB you could be forced to deploy more than one instance. Some applications will have specific throughput requirements that require separate ESB instances. Moreover your Kazak and Bolivian subsidiaries will unlikely use your centralized ESB instance for their local communications.
It is important to anticipate the case of having many instances of ESBs, possibly coming from different vendors.
The concept of “Enterprise Service Bus” (only one in your organization) is unrealistic and risky because it can bring to bottlenecks and hinder the adoption of the most adequate and efficient choices to be made case by case, for example:
• the choice of the most suited package, regardless the internal middleware solution
• the possibility to bypass the central “Enterprise Service Bus” when it does not offer added value; the number of not necessary hops can quickly grow, particularly in case of orchestrations and compositions

an ESB can by bypassed when it does not bring value

an ESB can by bypassed when it does not bring value

  • a world-wide distribution of a SOA connectivity can bring to an unfeasible or expensive centralized solution
  • some applications require features than the selected ESB products does not provide


How to gain SOA Governance in presence of more than one ESB?

Actually several Governance functions must be centralized, if possible at Enterprise level:



          Web Service Management (WSM) / Policy Management (PM),

          Semantic reconciliation,

          Late binding

If, as seen before, you cannot have only one ESB, you must entrust this task to other tools that must be

4     unique at enterprise level and

4     independent from the technologies of your ESBs


The “WS-Fabric”

If you use Web Services standards you actually have a point of centralization, this is not the ESB but the place in which SOAP messages are moved over a standard transport layer, I use a term caught from Jim Webber: WS Fabric.

the ESBs implement intermediaries

the ESBs implement intermediaries

 If the WS-Fabric is the center of the SOA communication which is the role of an ESB? In my opinion the ESBs are tools that have an important role for the generation of intermediaries and can be placed both on consumer and in provider sides. Anyway, a piece of WS-Fabric must be placed in front of every service end-point.

Intermediaries can be functional (i.e. can offer message transformations, service compositions, publishing, routing, adapters) or technical (access control, monitoring,  policy enforcers…).


0 Responses to “ESB: a misconception brings to wrong architectures”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: