| Backgrounder: |
SOA middleware may seem an oxymoron. SOA is meant to free organizations from the tyranny of tightly coupled implementations, which in my mind includes creating dependences on middleware, not just application and platform-level dependencies.
With support for Web Service protocols embedded in the Application Servers, and WS-STAR1 providing support for federated, secure, reliable, transactions between endpoints, why should there be a need for additional middleware?
We first considered the role of the Enterprise Service Bus (ESB) in a previous report “Time to board the Enterprise Service Bus” . Since then end-user interest in ESB and vendor hype has continued to grow. I sometimes think a better expansion of the abbreviation might be “Everyone’s Silver Bullet”, such is the perception that all you need to buy is an ESB and all your SOA problems are solved.
In that report we identified that there was no commonly agreed definition of an ESB, or a set list of functionality one might expect to find. Consequently, so called ESB products offer a spectrum of capability.
As well as being suitable for hosting Service endpoints for certain layers, the ESB is also particularly suitable for delivering certain SOA benefits patterns that we looked in the recent CBDI Journal report. |
Home