The Intelligent Intermediary Approach to Creating an Enterprise Services Bus

The primary purpose of an Enterprise Services Bus or ESB is to implement a layer of enterprise-class infrastructure that provides a standard way for an organization to expose services so that they can be discovered and executed by authorized users.

The services exposed by an ESB can be created by web-service enabling portions of existing applications, leveraging new web-services API’s provided by existing packaged apps or creating new web services from scratch.

The combination of development language, hardware platform or package vendor on which a service depends is not important to the ESB other than that the combination must provide a satisfactory level or service to consumers.

One approach for implementing ESB infrastructure is to create an “intelligent intermediary” (or fabric of intermediaries) through which all requests for services are routed.

Continued on the Conneva blog

“Creating a point-to-point mesh of web services invocations is just this generation’s way of re-inventing the wheel.”

Or (seeing as it’s getting close to lunchtime ) slathering a new flavor of sauce on your inter-application spaghetti!

Well said, Mark.

Very nice and timely article, Mark. We are just beginning to struggle with some of the issues you speak about.


I’ve seen a canonical adapter pattern discussed in some articles, but it seems to get lost in all the hype over standardization of the api/protocol.

Is anyone else noticing a tendcy towards re-coupling apps with web services that we had previously de-coupled?

I always felt that the best part of EAI was breaking the inter-application dependencies.

An intelligent intermediary-style ESB can also take on some other functions that don’t belong in the individual services. One of these is transformation, specifically transformation to and from canonical XML documents. In fact, we are doing exactly that on my current project.

A topic for a future article is just how much transformation belongs in your ESB? The first versions of Fabric (now ServiceNet) allowed some simple transformations via XSLT. However, XSLT is not well suited to looking up reference data from database tables or invoking other services in order to derive some value based on business rules. In addition, XSLT is hard for many developers and analysts to understand making ongoing maintenance more expensive.

Not being fond of reinventing circular transportation devices, my current project is leveraging the transformation capabilities of Integration Server for its inside-the-ESB transformation to and from canonical messages.



If you have the time, it would be great to see a “picture” of the components participating in the end-to-end message flow.

Good suggestion. It might take me a few days to have some availability to do this though. Rolling something out to QA testing this week.