This Content Component encountered an error
The Enterprise Service Bus [ESB] has been intrinsic to many SOA programs in recent years. You can say you are doing SOA and not have done an ESB. But there is a high likelihood a successful SOA program includes successful ESBs.
Much of the earliest ESB efforts rode on the back of the Java Messaging System [JMS], a standards-based competitor to what was once called IBM MQ. The ESB's goals have been to improve on point-to-point EAI-style integrations and bring forward a more holistic approach to the corporate system integration challenge, so that meant somehow incorporating several diverse middleware types.
Because software architects were trying to rationalize all their middleware types, the ESB quickly became more than just a shell for a JMS product. In fact, the varieties of middleware encompassed by an ESB soon made the ESB something of a 'grab bag' – not unlike the earliest versions of WebSphere, which became IBM's middleware smorgasbord. Data transformation, routing, protocol conversion, Web services and SLAs all became part of the ESB mix, and the ESB came to stand as something of a pinnacle of enterprise computing.
In a way, an ESB is a set of best practices. It represents decisions you have made about how to connect the dots of your legacy with the dots of your new strategic systems. As such, a three-ring binder could represent an ESB. But the magic of software, of course, is to turn thoughts into actions.
The ESB is more than a mere practice, and has become an authentic product category. What has been startling, given the complexity of what it is trying to accomplish, is that it has become a product category that is highly influenced by the open-source software movement.
It is not difficult to begin to evaluate open-source ESB software. Development teams can readily download basic trial versions. It is important, however, not to declare success after connecting two applications. You really don't know how the ESB works for you until you have done a more full-fledged integration.
To really test out the software, you need to see if you can integrate one of the dinosaurs in the shop. This is where you may find you need professional assistance. Commercial providers of open-source ESBs can often add value in addressing such issues. The vendors of open-source ESBs must be very actively updating their implementations as needs of customers evolve.
Open-source ESBs have either grown organically, or been ceded to the open source movement by individual vendors. An ESB is a complicated mechanism supporting a broad set of features and protocols – both of which are constantly changing. There is comfort in the open-source route, as it can guard somewhat against lock-in. Avoiding lock-in was a major driver for Web services and SOA, and it is the same these days with ESB-related development.
Dig deeper on SOA, XML and Web Services Development Tools