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.
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.