It wasn't that long ago when the enterprise service bus was fighting for hearts and minds inside the application integration market. It wasn't easy to convince people that the point-to-point integration method of EAI software wasn't a wise solution. For all the architectural headaches it created, EAI worked. Also users and vendors had invested plenty of time and money in EAI.
Money and entropy can be daunting adversaries, but the ESB concept, the idea of one-to-any integration, triumphed. During 2004 and 2005, the ESB became the must-have offering for vendors in the integration space. Old line EAI vendors rebuilt their hub-and-spoke models and even vendors like IBM, who questioned whether more integration middleware was the way to tackle service-oriented architecture, came up with ESB products.
Yet, almost as soon as the ESB conquered the world, its appeal began to erode. The marketing push behind the ESB had equated it with SOA. As the logic went, you needed an ESB to build an SOA. Many had mistakenly come to believe that the ESB was SOA, causing those folks to view SOA as some sort of middleware product rather than as a modular, agile enterprise architecture. In fact, that misperception still lingers.
When IT shops began to realize that SOA would require a lot more than an ESB, it changed the game. Last year saw a flurry of activity around the registry/repository and SOA governance. Users also began to approach SOA as a discipline rather than as a technology. Still, the ESB persists, mainly because it embodies the discipline of SOA.
All those application silos that need integrating still exist. IT shops still need to make disparate collections of code work together. Just because SOA is more than just an ESB, it doesn't mean the ESB plays no role in SOA.
Our main story today will focus on Cape Clear Software's release of version 7 of its ESB. Our SOA Advisor tip this week will be from Maja Tibbling, lead enterprise architect at Con-Way Inc., and she will discuss how to use an ESB to simplify complexity inside your SOA, particularly in the areas of reliability, scalability, security and extensibility.
For those of you interested in SOA governance the first lesson in our SOA School: Service Orientation for Architects is now live. It includes a Webcast with Everware-CBDI principal analyst Lawrence Wilkes on the architecture of governance, a written tip from Citigroup senior architect Mark Temple-Raston on operational risk and WS-Policy and a podcast with Dan Foody, CTO for Actional products at Progress Software and longtime SearchWebServices.com site expert on SOA, on the hidden risks of SOA governance. Other lessons in the school will follow in the coming weeks.
