Myth of the ESB?

September 14, 2007

Many in the industry consider SOA as hype and ESB as another, both related, nonetheless. Is it a hype or a matter of failure of understanding? Agreed the hype is fostered by promises of either(or both) being a panacea for all your systems woes.

Lets get to simple descriptions of the two entities : SOA is an architectural approach and a methodology while the ESB is a pattern/logical group of capabilities that are employed to realize the SOA. This means that you are unlikely to find the ultimate SOA/ESB product that addresses all your architectural concerns, no matter what the product vendor says. I am sure all of us have seen the SOA triad of provider, client and broker depicted like below:

SOA - triad of provider, consumer and broker

Also you would have seen the ESB “silver bullet” depicted as below :

esb.jpg

Before I go further, let me clarify that I am a great fan of SOA and the ESB. I have employed both and seen clients benefit from it.

The title of this post was suggested by a client project manager, who along with his organization – a large airline, was entirely sold out on SOA and a commercial ESB offering. It took a 3 month consulting assignment to establish the Why and How of SOA and determine what an ESB could provide.

I will first list a few busted myths about SOA and ESB, in no particular order:

  • Writing a few web services does not mean you have embraced SOA
  • SOA is not an IT initiative alone and involves Business and Operations just as much.
  • Neither SOA or ESB are silver bullets for your organization and not everything can/must be a service.
  • Service reuse does not always translate to using the service in a hosted mode.
  • Web services are not the only way to implement services in a SOA.
  • There is a big difference between Process Orchestration(BPM through BPEL) and Service Orchestration aka Composite Services(an invocation like Service A –> Service B –> Service C within a shared context say transaction or process).
  • ESB provides certain infrastructure for your SOA. On a case-by-case basis you would still need the following: Service Container, Service Registry, Service Repository, Service Orchestration.

Do all of the above erode away the promise of SOA and an ESB? The answer is “no”. The key is to clearly establish your SOA adoption (see my post Methodology for SOA Adoption ) and use a capability model(see IBM redbook on “Implementing an SOA using an ESB”) to evaluate the need and features of an ESB. You will then see that pictures like the ones above are not myths but reality.

About these ads

3 Responses to “Myth of the ESB?”

  1. facts daily Says:

    The main thing i’m enjoying while reading your blog is the way you write, you are a really charismatic person and your posts are wonderful, keep it up!


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: