When IBM first created WebSphere it was an application server. But soon ''WebSphere'' came to be an encompassing brand name for all manner of tools in the company's middleware portfolio. The depth of integration of these tools, at first, was minimal – it was as if IBM had simply put a WebSphere label on a big box of toys. The integration has improved over the years for sure, but as the company continues to acquire properties, WebSphere middleware remains something of a constant work in progress.
In the wider industry, the enterprise service bus (ESB) is similarly a bit of a chameleon, taking on any aspect of integration middleware that might be required. ESBs are adding message queuing capabilities at a rapid clip. That is not surprising as the message queue has long been included in the typical ESB implementation. Even orchestration is an attribute being added. We've seen
Tools and IDEs are key to the future of ESBs. As ESBs add features, IDEs will garner new attention. Whenever you have to step out of one IDE and into another you know you are in the realm of partial integration. That could happen more and more as ESBs add features. Development managers must gauge their ESB moves as carefully as ever, in order to achieve open services architecture.
Let's face it: SOA came into being because Web services alone were not successfully providing interoperability. But the building out of SOA services did not occur on a green field – legacy mainframes and message queuing, Java servers and SQL databases, even FTP transfers for that matter, all had to be handled. The enterprise service bus came into being to spur on services while handling whatever other integration means were needed.
Back in the day, the savvy ESB implementers tried to create their architectures so that services could meld disparate data, events and processes. That still should be the guiding compass for ESB integration today.