Recorded at:

The Role of the Enterprise Service Bus

Posted by Mark Richards on Oct 23, 2006 04:00 PM

Community

Java,

SOA

Topics

ESB

Tags

Mule,

No Fluff Just Stuff Symposiums,

Websphere,

ServiceMix,

JBI

RelatedVendorContent

SpringSource Launches New Application Server without Java EE

A Technical Introduction to Terracotta

Snapshots from SOA Governance: Artifacts, People, Processes, Repositories

Rational Model Driven Development eKit: Examples, Tutorials, Webcasts

Hibernate without Database Bottlenecks

Related Sponsor

Announcing the SpringSource Application Platform - an enterprise Java appserver that redefines the way in which Java applications are deployed and run. >> Download beta here

1. Back to top

   Good Presentation

   Oct 23, 2006 10:21 PM 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.

   Reply

2. Back to top

   Re: Good Presentation

   Oct 24, 2006 7:58 AM 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 http://infoq.com/esb. Enjoy, Floyd

   Reply

3. Back to top

   Re: Good Presentation

   Oct 24, 2006 9:13 AM 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

   Reply

4. Back to top

   Re: Good Presentation

   Oct 24, 2006 9:15 AM 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.

   Reply

5. Back to top

   Re: Good Presentation

   Oct 24, 2006 9:53 AM by John Harby

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

   Reply

6. Back to top

   Re: Good Presentation

   Oct 24, 2006 10:07 AM 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

   Reply

7. Back to top

   Re: Good Presentation - Followup

   Oct 24, 2006 10:09 AM by Mark Richards

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

   Reply

8. Back to top

   Article on ESB

   Oct 24, 2006 11:24 AM 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 - http://www.soamag.com/I1/default.asp

   Reply

9. Back to top

   Re: Good Presentation

   Oct 24, 2006 11:48 AM 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

   Reply

10. Back to top

    Re: Good Presentation

    Oct 24, 2006 1:59 PM 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?

    Reply

11. Back to top

    Re: Good Presentation

    Oct 24, 2006 7:50 PM 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.

    Reply

12. Back to top

    Re: Good Presentation

    Oct 24, 2006 11:29 PM 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

    Reply

13. Back to top

    do u hava text for the presentation?

    Oct 25, 2006 10:14 PM by kahon lau

    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.

    Reply

14. Back to top

    Ability to separate Business Services from Service Implementation

    Oct 26, 2006 11:06 AM 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?

    Reply

15. Back to top

    Re: Ability to separate Business Services from Service Implementation

    Oct 27, 2006 10:24 AM 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".

    Reply

16. Back to top

    Mule misinformation

    Oct 27, 2006 8:50 PM 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 (http://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 http://mule.mulesource.org/wiki/display/MULE/Transports+Guide for a listing of transports/connectors available or http://mule.mulesource.org/wiki/display/MULE/User+Guide for the general Mule Users Guide. Other than that, a fantastic presentation! Travis

    Reply

17. Back to top

    Re: Mule misinformation

    Oct 30, 2006 9:18 PM 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

    Reply

18. Back to top

    JBI and ESBs going forwards

    Oct 31, 2006 1:05 PM by Peter Walker

    Mark, Nice preso and expose of ESB capabilities and JBI. Readers may also like to access the following... The spec thru http://jcp.org/en/jsr/detail?id=208 and our open source impl at https://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

    Reply

19. Back to top

    TLA exhaustion

    Nov 3, 2006 9:24 AM 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 :-)

    Reply

20. Back to top

    Re: Good Presentation

    Nov 29, 2006 12:59 AM 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

    Reply

21. Back to top

    Neat presentation.

    Dec 27, 2006 12:33 AM by Shankar Vaithianathan

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

    Reply

22. Back to top

    is process choregraphy part of ESB

    Feb 13, 2007 8:12 AM 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?

    Reply

23. Back to top

    Re: is process choregraphy part of ESB

    Feb 22, 2007 12:35 PM 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.

    Reply

24. Back to top

    Re: is process choregraphy part of ESB

    Mar 8, 2007 6:21 AM 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.

    Reply

25. Back to top

    ESBs on the market

    Mar 20, 2007 4:27 AM 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 (http://java.sun.com/javaee/5/docs/tutorial/doc/), particularly figure 1.1 on page called "Distributed Multitiered Applications" in chapter 1. Cheers. Frederic.

    Reply

26. Back to top

    trivial process choreography ~= Message Processing ?

    Apr 27, 2007 9:25 AM 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.

    Reply

27. Back to top

    ESB coded in other language than Java.

    May 2, 2008 11:37 AM 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.

    Reply

• Older >