Topics

Featured in Development

Peter Alvaro talks about the reasons one should engage in language design and why many of us would (or should) do something so perverse as to design a language that no one will ever use. He shares some of the extreme and sometimes obnoxious opinions that guided his design process.

Featured in AI, ML & Data Engineering

Today on The InfoQ Podcast, Wes talks with Katharine Jarmul about privacy and fairness in machine learning algorithms. Jarul discusses what’s meant by Ethical Machine Learning and some things to consider when working towards achieving fairness. Jarmul is the co-founder at KIProtect a machine learning security and privacy firm based in Germany and is one of the three keynote speakers at QCon.ai.

Featured in Culture & Methods

Organizations struggle to scale their agility. While every organization is different, common patterns explain the major challenges that most organizations face: organizational design, trying to copy others, “one-size-fits-all” scaling, scaling in siloes, and neglecting engineering practices. This article explains why, what to do about it, and how the three leading scaling frameworks compare.

The Role of the Enterprise Service Bus

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.

Good Presentation

Your message is awaiting moderation. Thank you for participating in the discussion.

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.

Re: Good Presentation

Your message is awaiting moderation. Thank you for participating in the discussion.

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.

Re: Good Presentation

Your message is awaiting moderation. Thank you for participating in the discussion.

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.

Re: Good Presentation

Your message is awaiting moderation. Thank you for participating in the discussion.

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!

Re: Good Presentation

Your message is awaiting moderation. Thank you for participating in the discussion.

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

Your message is awaiting moderation. Thank you for participating in the discussion.

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.

Re: Good Presentation

Your message is awaiting moderation. Thank you for participating in the discussion.

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

Ability to separate Business Services from Service Implementation

Your message is awaiting moderation. Thank you for participating in the discussion.

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

Your message is awaiting moderation. Thank you for participating in the discussion.

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

Your message is awaiting moderation. Thank you for participating in the discussion.

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.

Re: Mule misinformation

Your message is awaiting moderation. Thank you for participating in the discussion.

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

Re: is process choregraphy part of ESB

Your message is awaiting moderation. Thank you for participating in the discussion.

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

Your message is awaiting moderation. Thank you for participating in the discussion.

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

Your message is awaiting moderation. Thank you for participating in the discussion.

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.

trivial process choreography ~= Message Processing ?

Your message is awaiting moderation. Thank you for participating in the discussion.

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.

Your message is awaiting moderation. Thank you for participating in the discussion.

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.

It is all about BizTalk

Your message is awaiting moderation. Thank you for participating in the discussion.

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.

still relevant!

Your message is awaiting moderation. Thank you for participating in the discussion.

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.