You are now in FULL VIEW
CLOSE FULL VIEW

The Role of the Enterprise Service Bus
Recorded at:

by Mark Richards on Oct 23, 2006 |

Summary
Mark Richards tells us what an ESB is, its role, what capabilities it provides, and the various ways an ESB can be implemented. He takes a close look at the JBI specification (JSR-208) and explains what impact it will have with the ESB world. This will teach you how to determine your own specific requirements for an ESB and then match these requirements to the product space.

Bio

Developer, designer, architect, Mark Richards has significant experience and expertise in J2EE architecture and development, Object-oriented design and development,and systems integration. He is an IBM Certified Application Architect, a Sun Certified J2EE Business Component Developer, a Sun Certified J2EE Enterprise Architect, a Sun Certified Java Programmer and a Certified Java Instructor.

Related Editorial

Hello stranger!

You need to Register an InfoQ account or 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

Good Presentation by Ashley Aitken

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.

Re: Good Presentation by Floyd Marinescu

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).
Ashley, if you're interested in discussions on the definition of an ESB, you've GOT to check out the debates InfoQ hosted on this subject a couple of months ago:
ESB Roundup Part 1: Defining the ESB and Usecases for an ESB. Other ESB content can be found at infoq.com/esb.

Enjoy,

Floyd

Re: Good Presentation by James Strachan

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

Re: Good Presentation by Ashley Aitken

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.

Re: Good Presentation by John Harby

Be aware there have been those against the concept of ESB too: www.looselycoupled.com/blog/lc00aa00073.html

Re: Good Presentation by Mark Richards

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

Re: Good Presentation - Followup by Mark Richards

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

Article on ESB by Satadru Roy

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

Re: Good Presentation by Dave Macpherson

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

Re: Good Presentation by Jeevak Kasarkod

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?

Re: Good Presentation by Ashley Aitken

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.

Re: Good Presentation by James Strachan

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

do u hava text for the presentation? by lau kahon

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.

Ability to separate Business Services from Service Implementation by Peter Bona

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?

Re: Ability to separate Business Services from Service Implementation by Mark Richards

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?


Tough question - while it is true businesses are in a constant state of change due to mergers, acquisitions, industry trends, regulatory requirements, etc., generally the underlying technology implementation changes more than the business service. For example, in an insurance company biz services might be "CreateQuote", "CreatePolicy", "ProcessClaim". Regardless of changes, the company is still going to need these services. Now, yes, you are correct that one of the biggest challenges is the service contract. However, in my experience this has not changed nearly as much as the contract between implementation services. Also, please see the section on "Message Enhancement" in the presentation (about half way through). Here, the ESB can actually make changes to the incoming message to actually supplement data that would otherwise require changes to the client contract. Your point is well taken though, and just goes to show that there is no "Silver Bullet".

Mule misinformation by Travis Carlson

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

Re: Mule misinformation by Mark Richards

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.


When the presentation was recorded, I was really referring to Mule 1.0. I found it was a very fast messaging framework, but at that time it really wasn't referred to in the marketplace as an *ESB* (too bad!). I also found that as a messaging framwork I had to write many of the traditional *ESB Capabilities* myself. However, you make a valid point that the most recent version of Mule (1.3) has many more out-of-the-box features than the first release, and is much more sophisticated as well. Actually, now that things have increased in complexity in the open source ESB market, I rather miss the initial release of Mule! (Simplicity Rules!)

Thanks for the clarification - glad you enjoyed the talk.

Mark

JBI and ESBs going forwards by Peter Walker

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

TLA exhaustion by Nick Sharman

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 :-)

Re: Good Presentation by imran basha abdul hameed

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

Neat presentation. by Shankar Vaithianathan

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

Thanks
Shankar

is process choregraphy part of ESB by Kalimulla Shariff

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?

Re: is process choregraphy part of ESB by Sudha Durairaj

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


Mark, Its an excellent presentation and presented lot of details of an ESB, especially the capabilities are great!
One point though, I see Process Choreography as feature of Business Process Management tool rather than as ESB's feature.

I see Kalimulla has the similar question and would really appreciate your comments on this.

Re: is process choregraphy part of ESB by Mark Richards

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.

ESBs on the market by Frederic Sullet

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.

trivial process choreography ~= Message Processing ? by Doug Whitehead

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.

ESB coded in other language than Java. by Patrice Magnan

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.

ESB Presentation by Paramesh Renoldo

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


Thanks
Param

Re: Good Presentation by Jafar vali shaik

Very Good Explanation on ESB.

Re: Good Presentation by Jafar vali shaik

Came to know the importance of ESB in SOA.

Re: Good Presentation by Amanpreet Kaur

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

It is all about BizTalk by Leo Gan

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

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

32 comments
General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy