|
A good place to start is whether the ESB is simply a web services veneer on top of an EAI broker or an Application Server. Another thing to look for is whether the ESB actually has a good reliable messaging layer. If it does have a reliable messaging layer, is there the notion of the separation of the reliable messaging layer from the rest of the ESB? The reason for needing that is the independent scalability of the individual parts of the ESB. As you begin to increase the service request traffic across a SOA infrastructure, the performance and scalability bottlenecks can occur in multiple places. Two important potential bottlenecks are in the processing of the service request itself—the service implementation, or in the heavy lifting involved in performing the reliable message delivery. A third place for bottlenecks are in mediation services such as XML transformation. If the ESB implementation is based on a monolithic stack that lumps all of these categories of processing together, then your options for scaling and relieving bottlenecks can be somewhat limiting.
Even implementations of WS-ReliableMessaging can vary drastically from product to product. If the WS-RM implementation requires that an Oracle or SQL server database be installed at each endpoint in order to do the message persistence, then that can also become a deployment challenge.
Another important point to consider is what is the ESB's support for fault tolerance and continuous availability? Does it rely on hardware clustering and shared disk resource? In the event of a failure in hardware or disruption in network operation, does it rely on rolling back to a previously saved transaction and doing a manual roll-forward recovery? Does it require a 2-phase-commit protocol resolution across multiple relational databases? How much effort is required to recover operation, and how long can your business afford to be down while that's happening?
When Sonic introduced the first ESB product in March of 2002, we worked with the analyst community and the journalist community to socialize the concepts and terminology of what it meant to be an ESB. At that time Gartner produced the first ESB report and described the base definition of an ESB as combining Message Oriented Middleware (MOM), Web Services, intelligent routing based on content, and data transformation. Since that time, the product category has grown into something very substantial with vendors such as IBM, Microsoft, TIBCO, BEA, webMethods etc. getting "on the bus" so to speak. If you look under the covers of the different vendor offerings you will find that the implementations vary drastically whether the vendor has its roots as an EAI broker, a messaging broker, an application server, a basic web services toolkit, or in some cases a combination of those diverse technology approaches.
The unfortunate part of this vendor diversity is the IT folks who are evaluating ESB implementations have a real hard time understanding where to begin with regard to the moving parts they should be evaluating and comparing between vendors.
The analyst community has done their part in adding clarity to the ESB product category. Comprehensive reports on ESBs have come out from Gartner, Forrester, IDC, etc which further define and also subdivide the ESB product category into various buckets such as those with a messaging layer and those without, or single-protocol vs multi-protocol.
There is also, of course, a very good O'Reilly book on the subject of ESB. The ESB book is intended to be a generic treatment of the technology subject, and in the introduction I give an open invitation that any vendor implementing an ESB may choose to use this book as a guide.
Sonic has further added clarity to the definition of an ESB by providing an "ESB Architecture and Lifecycle" document which is intended to be a reference architecture for ESB implementations. It is based on the notion that when you look inside an ESB there are very distinct architectural components and moving parts that are all there for a specific reason, and that is to provide a flexible uniform backbone for a SOA infrastructure. Examples of such architectural components are a lightweight service container for hosting mediation components such as transformation and routing, or for hosting application adapters. Other examples include process control mechanisms such as itinerary based routing, messaging components, abstract endpoint definitions, and connectivity capabilities for linking applications, application server platforms, and advanced web services through the bus.
The document is intended to be both definitive and comparative, meaning that it should be used as a tool in building criteria for evaluating ESB implementations. There are many UML diagrams in it that describe the relationships between the ESB architectural components. It is also intentionally devoid of marketing benefit statements, as it is purely intended for architects who are trying to understand the core architecture. The document also covers more than just the runtime infrastructure but also the whole lifecycle of process design through repository based configuration and deployment.
|
