ESBs Move to Differentiate
When many people hear the acronym "ESB," they think of cutting-edge products just emerging onto the technology scene. Probably the last word that comes to mind is "commodity," but thats exactly what ESBs, or Enterprise Service Buses, are becoming.
This may come as a surprise to many IT managers because ESBs arent that old. You need to go back just a few years to find only one vendor (Sonic Software) claiming to have an ESB product. Whats more, unlike most commodity products, ESBs are extremely complex, striving to openly connect a wide diversity of Web services, back-end corporate processes and data-driven applications.
But it is the very open connectivity nature of ESBs that has made them subject to quick commoditization. All ESBs are heavily based on open Web and XML standards, and they use open methodologies to provide a connective layer to multiple endpoints.
What this means is that there really is no "secret sauce" when it comes to ESBs. Everything an ESB does functionality-wise is open and easily re-created. This has led to a situation where, in just a few years, we have gone from only one ESB vendor to a whole host of vendors offering ESB products. These include very large enterprise IT companies, such as IBM, Sun and BEA, as well as open-source projects.
The result is an environment typical for any commodity IT product. Vendors are now finding that they have to differentiate themselves on the margins through better developer-oriented tools or easier integration with common back-end enterprise systems, or aggressive support of early drafts of proposed Web service and integration standards.
Three of the earliest providers of ESBs have recently updated their systems, and eWEEK Labs evaluated them to see how the ESB landscape is changing. We tested Cape Clear Softwares Cape Clear ESB, Iona Technologies Artix and the granddaddy of the category, Sonic Softwares Sonic ESB.
All three of these products vendors have their origins in Web service management and integration, and their ESB systems are understandably strong in those areas. But the similarities dont end there: All three products also now base their tool sets on the Eclipse development platform, and they all have very similar support for core SOA (service-oriented architecture) standards.
This means that choosing an ESB will come down to the nitty-gritty issues that enter into all commodity decisions, including support options, cost and ease of deployment into your specific enterprise infrastructure.
Most enterprise-level ESBs will support the standards that matter for 90 percent of connectivity tasks. However, there are several new and emerging standards that these products are working to support as early as possible. In fact, the level of standards support for these and competing products increases regularly and will probably change by the time you read this review.
When considering an ESB, IT managers also should look into the bundled connectivity options. All ESBs will support standards such as JMS (Java Message Service) and HTTP, but a list of the standards needed to support your specific implementation needs should be prominent in any ESB RFP (request for proposal).
Like many enterprise products today, all of the ESBs we tested are available in free trial versions on their vendors respective Web sites. We recommend that you download these trial versions and use them to learn the interfaces and development and configuration quirks of the products. The trial versions also will allow you to determine whether an ESB will integrate well with your particular systems, processes and applications.
Labs Director Jim Rapoza can be reached at email@example.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.