Questions for an Enterprise Architect
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
Presentation
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
The Role of the Enterprise Service Bus
Presented by
Mark Richards
on
Oct 23, 2006
Length 01:07:43
How would you like to view the presentation?
In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
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.
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.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
Good Presentation
by
Ashley Aitken
Posted
Re: Good Presentation
by
Floyd Marinescu
Posted
Re: Good Presentation
by
Ashley Aitken
Posted
Re: Good Presentation
by
John Harby
Posted
Re: Good Presentation
by
Mark Richards
Posted
Re: Good Presentation
by
Dave Macpherson
Posted
Re: Good Presentation
by
Jeevak Kasarkod
Posted
Re: Good Presentation
by
James Strachan
Posted
Re: Good Presentation
by
Ashley Aitken
Posted
Re: Good Presentation
by
imran basha abdul hameed
Posted
Re: Good Presentation - Followup
by
Mark Richards
Posted
Article on ESB
by
Satadru Roy
Posted
TLA exhaustion
by
Nick Sharman
Posted
Re: Good Presentation
by
James Strachan
Posted
Re: Good Presentation
by
Jafar vali shaik
Posted
Re: Good Presentation
by
Jafar vali shaik
Posted
Re: Good Presentation
by
Amanpreet Kaur
Posted
It is all about BizTalk
by
Leo Gan
Posted
do u hava text for the presentation?
by
lau kahon
Posted
Ability to separate Business Services from Service Implementation
by
Peter Bona
Posted
Re: Ability to separate Business Services from Service Implementation
by
Mark Richards
Posted
Mule misinformation
by
Travis Carlson
Posted
Re: Mule misinformation
by
Mark Richards
Posted
JBI and ESBs going forwards
by
Peter Walker
Posted
Neat presentation.
by
Shankar Vaithianathan
Posted
is process choregraphy part of ESB
by
Kalimulla Shariff
Posted
Re: is process choregraphy part of ESB
by
Sudha Durairaj
Posted
Re: is process choregraphy part of ESB
by
Mark Richards
Posted
ESBs on the market
by
Frederic Sullet
Posted
trivial process choreography ~= Message Processing ?
by
Doug Whitehead
Posted
ESB coded in other language than Java.
by
Patrice Magnan
Posted
ESB Presentation
by
Paramesh Renoldo
Posted
-
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).
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 -
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. -
Be aware there have been those against the concept of ESB too: www.looselycoupled.com/blog/lc00aa00073.html
-
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?
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". -
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.
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 -
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?
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. -
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
32 comments
Watch Thread Reply