The Role of the Enterprise Service Bus

A good explanation of what an ESB is. Recommended.

I find it a bit unfortunate though that people (including the presenter) aren't willing to (or cannot) precisely define ESB (the presenter shows some product marketing text and an attempt by Gartner).

A definintion can be general enough to include variations that are still ESBs.

Something along the lines of "an extra layer in an Enterprise architecture to provide additional abstraction of the underlying services as well as additional functionality, such as (but not limited to) transformation and translation of request)."

Now, I didn't even watch the full presentation but that seems like a good starting point for me.

Cheers,
Ashley.

I find it a bit unfortunate though that people (including the presenter) aren't willing to (or cannot) precisely define ESB (the presenter shows some product marketing text and an attempt by Gartner).

Agreed - its a great presentation, highly recommended.

ESB is like many other things in IT, its rapidly lost most of its meaning like object, component based, even SOA. Though I like the presenters approach to the issue, by focussing clearly on the capabilities people need from an ESB rather than trying to come up with a single paragraph that accurately describes a complex and powerful set of quite different capabilities.

I think the 10 capabilities Mark mentions in the talk are a pretty good definition of what an ESB is.

James
LogicBlaze
Open Source SOA

Thanks Floyd, I will check them out.

I must say my statement about definitions was mostly a general whinge though - I am not a fan of those who say that some things just can't be defined when usually it means they don't want to spend the effort trying or even worse they don't understand the domain well enough. Without reasonably clear definitions useful communication becomes rather difficult.

I actually thought that the presenter had given me a good understanding of what an ESB was but I didn't see/hear him provide a definition. I don't believe it was due to either of the points I mentioned enough (he clearly understands what he is talking about and put a lot of effort into his presentation). I think it may have been more like "Gartner had tried and hadn't got very far so who am I to try ..."

Again, no offence to Mark, I enjoyed the presentation and I am grateful to InfoQ, Mark and NFJS conference for sharing that.

Cheers,
Ashley.

Ashley,

I purposely did not provide my own *formal* definition of an ESB. Too many times in this industry we get carried away with buzzwords and their definition, and that leads to a more confusion than clarity. This was precisely my point of the whole session - if we understand something, we don't need a formal, written definition. The actual definition comes from an *understanding* of the concept rather than from a vendor website.

One of the fun things I do in the session is show various definitions - notice how they are all different and have a different spin on things? And I only show 4! Imagine if I showed them all...It is all a matter of context and perspective and spin.

Glad you enjoyed the presentation. It was a challenge to do that one in a little over an hour!

Mark

One more thing - God help our industry if we run out of TLA's (Three Letter Acronyms)!

I wrote an article sometime back on how ESBs play a key role as a mediation framework in an SOA infrastructure stack - www.soamag.com/I1/default.asp

Mark, really, an excellent presentation. I really enjoyed it and found it extremely helpful for my understanding of the capabilities that I should be looking for an ESB to provide.

Dave

Its an excellent presentation and I appreciate it more after having the experience to work on a ESB offering. Since JBI is java centric that wouldnt help if I needed to plug in a .NET based BC or SE or are there tweaks/hacks to get around that in current ESBs?

Hi Mark,

Thanks for your post (and the seminar as I said before).

I am happy to agree to disagree but I do disagree that one shouldn't define terms. I agree that the vendor definitions were full of buzzwords and lead to more confusion than clarity - but that is their goal, they are using the definitions to assist their sales.

On the other hand (from what I saw) I think you went very close to providing a nice and neat definition of ESB - as an extra layer of abstraction that provides various functionality in a Service Oriented Architecture. I think such a definition (without buzzwords, assuming now that people have a clear definition of SOA).

Just because the vendors put context, perspective and spin on their definitions, it doesn't mean that everyone has to.

I guess it is the part academic in me ;-)

Best regards,
Ashley.

Some background here but basically JBI can communicate with any components in any language/OS/platform, there just needs to be a BC to communicate with it in some protocol. So it could talk CORBA, WS, JMS or some binary protocol etc. Or the pure Java ESB could be hosted on .Net via IKVM :)

James
LogicBlaze
Open Source SOA

I prefer text,and i'm sorry for my listening cuz i'm from china.Or,can I download the swf from somewhere? sometimes I want to watch it offline.

Excellent presentation, thanks.
For me, the main 'take away' was the answer to the 'why do we need ESB at all?'. You are saying that with ESB we are able to 'separate Business Services from Service Implementation', so we can still provide the same Business Service while we can change the underlying implementation. But isn't the business service that changes frequently? If so, we have to change not only the implementation but the business contract. Then is the usefulness of ESB justified?

Excellent presentation, thanks.
But isn't the business service that changes frequently? If so, we have to change not only the implementation but the business contract. Then is the usefulness of ESB justified?

Mark,
I enjoyed your presentation very much, I found it was very thorough and presented all the aspects that are generally desired of an ESB.

I would like to set the record straight on Mule, however. It is completely untrue that you need to write code in order to use Mule. The full distribution includes dozens of standard transports and protocols out-of-the-box and ready to use for integrating your systems. Indeed, the illustration on the front page of the Mule website (mule.mulesource.org) looks amazingly similar to the ESB illustration from your presentation. There is even preliminary support for using jBPM and JBoss Rules with Mule.

Refer to mule.mulesource.org/wiki/display/MULE/Transport... for a listing of transports/connectors available or
mule.mulesource.org/wiki/display/MULE/User+Guide for the general Mule Users Guide.

Other than that, a fantastic presentation!

Travis

Mark,
I enjoyed your presentation very much, I found it was very thorough and presented all the aspects that are generally desired of an ESB.

I would like to set the record straight on Mule, however. It is completely untrue that you need to write code in order to use Mule.

Mark, Nice preso and expose of ESB capabilities and JBI.

Readers may also like to access the following...
The spec thru jcp.org/en/jsr/detail?id=208 and our open source impl at open-esb.dev.java.net/

I'd love to get your and others thoughts about where JBI should go next. What additions do you think JBI 2.0 should include? Feel free to get in touch directly too.

Peter Walker
Co-speclead, JBI (JSR 208)
Peter.Walker@Sun.COM

Someone has remarked that this is the next major crisis after Y2K: after all, there are only 26**3 of them. The solution will be Extended Three-Letter Acronyms, or ETLAs - of which ETLA is one :-)

Dear Sir,
I am imran from INDIA, can u please send me the document or materials regarding Enterprise Service Bus (ESB).

Please let me know if you need further details!..
Thanks & Regards,
Imran Basha .A.H

Cleared almost all my black spots in defining an ESB. Great work Mark.

Thanks
Shankar

Hi mark,

It was a lovely presentation. I have worked on ebXML MHS and to my understanding process choreography must stand out of ESB. is this a right thought?

I have worked on ebXML MHS and to my understanding process choreography must stand out of ESB. is this a right thought?

I do not consider process choreography part of an ESB, if we consider an ESB as a high-speed messaging middleware. However, I do consider process choreography part of the ESB *platform*. Fortunately most ESB vendors separate out these major components into different products, but package them under a consolidated ESB offering. So, in the strictest sense of the word, no, I would not consider it as part of an ESB. It is a related capability.

Hi Mark,

thanks for this clear and efficient presentation, it opened me the door of the architecture world ;)
Would you consider Java EE server as an ESB ? I doubt it but still it came to my mind while reading Java EE 5 Tutorial (java.sun.com/javaee/5/docs/tutorial/doc/), particularly figure 1.1 on page called "Distributed Multitiered Applications" in chapter 1.

Cheers.

Frederic.

Mark,
I found the presentation very useful. Thanks you.

You mention vendors tend to put the process choreography engine between the ESB and the client, and that the best strategy is to make the ESB route to the process choreography engine. However, in your prefered arrangement, you need a "Message Processing" step to handle the client thread, etc.

I would suggest that a trivial process choreography workflow IS, in effect, your "Message Processing". I would further suggest the reason process choreography engines are slow and ESB is fast, is a function of what it is trying to do. A typical process choreography engine needs to log its state to survive failure, be managed externally, etc. It is unclear whether these services are required for your "Message Processing" (my guess is probably).

Your point about not wanting to create BPEL just for initiating a request is a good one. I don't know if reusing a standard client request BPEL would work, but this kind of reminds me of the whole EJB home/remote interfaces horse-hockey before they figured out how to make the developer's life easier with annotations.

Hi Mark, very good presentation. I was surprised to see a presentation matching perfectly with one of our system that we created and implemented 13 years ago. This system serves us very, very well. By using this “concept” (because I’m now able to put a real name on it: ESB), we are seen as marginal by our colleagues working in others sectors and regions of our company. They are not familiar with this concept. So, after all, it seems that we are not marginal … or maybe we are still, our ESB is coded on … our mainframe in… surprise!! … Cobol (using SOA). Your domain is more Java et cie. Based on your comments in the presentation, you are not a fan of Cobol and cie. However, the ESB principle is the same. We are looking to migrate on Java, somewhere in the future. So, I’m happy to see that this concept is well supported by Java. The migration process should then be easier. I will refer my collegues to InfoQ, they will maybe convert to ESB.

Its really good, Its really helpful for our current project. We are planing to use Bea Aqualogic .


Thanks
Param

Very Good Explanation on ESB.

Came to know the importance of ESB in SOA.

really nice presentation... came to know the actual role of ESB and under what conditions to use it.

What streaked me, the presentation is so fit to the BizTalk description. Precisely, word by word. Choreography unfortunately means Orchestration in BizTalk :) Choreography as a Service Engine? Exactly.
Unfortunately it is not modular. I'd like to see the "modular BizTalk". It is for some level but... But all other stuff. Mediators, routing, ...? All on the place.

Thanks! Great presentation. Highly recommended

Hey a well done presentation. I watched this recently and came back to pass-on the link to a colleague. In looking at the date, this is 2015 -- 9 years on, the same topics are still 'live'.

I can't help but wonder that this is the case because people still have a fuzzy idea of what "it is". I imagine a blog or wider circulation of the slides and this information over the last 6 to 8 years would help in the rest of the decade ... One thing in today's trends seems to be slotting in an ESB like approach with a reactive model. Both have their place, and it is up to practitioners, the industry and researchers to define those niches, imho.

Regards, Will