Intelligent Enterprise

Reader interest in enterprise service bus systems is on the upswing, so we set off on a collaborative journey with our sister publication, Network Computing, to gain hands-on insight. Our coverage focuses on service-oriented modeling, mapping and registry integration, while Network Computing's coverage concentrates on IT needs and concerns.

The team at Network Computing's Green Bay, Wis., business applications lab installed and tested ESB suites from eight vendors: BEA Systems, IBM, Cape Clear, Fiorano Software, Oracle, Sonic Software, Software AG and TIBCO. Some 13 vendors were invited to participate, but Microsoft, PolarLake, Sun Microsystems and WebMethods declined, and Iona's Artix 4 wasn't released until after testing was completed.

To evaluate the products, we built a service orchestration that demanded integration with Oracle9i, which contained inventory data, an external JMS queue to integrate with our manufacturing systems, an external .Net Web Service to kick off the shipping process and an e-mail server to notify customers of their order status. The orchestration required simple, content routing based on inventory level to determine the next service to which a message should be routed; it also involved mapping of data (transformations) from service to service within the orchestration. After extensive testing, we put four ESBs on our shortlist for their minimal technical and coding demands and their user-friendly transformation and service orchestration capabilities.

The Low-Demand Ideal

A solid SOA infrastructure requires both service enablement and service orchestration to properly enable service-oriented business applications and BPM (business process management). The ESB is the service-orchestration layer, providing support for arranging atomic services (the service-enablement layer) into business services for use at the business process layer. Those handling service enablement must have technical competency and be able to write code, but an ESB should let nontechnical, noncoding users realize the advantages of the SOA. Applying SOA principles means using an open-standards approach and metadata-based description of the orchestration, not a hard-coded, tightly coupled solution that destroys the agility promised by the SOA.

The best ESB implementation will require no domain expertise in specific technologies, such as JMS (Java Message Service) or other messaging technology, but will instead require only technical competency in SOA-based languages and technologies, such as WSDL, XPath, SOAP and WS-Security. Although a standards-based modeling language would be a boon, it isn't a requirement as long as the product requires no code and fulfills the basic functions of an ESB, such as routing, transformation, integration of services over multiple protocols and exposing orchestrated services as a Web Service over HTTP or JMS.

Tied Up In Details

You shouldn't need to know about the inner workings of the messaging bus to orchestrate messages. We were generally pleased with the level of abstraction provided by most of the products we tested, but were disappointed by the offering from Sonic Software in its decision to expose the orchestrator of services to a heavy dose of messaging terminology and configuration options. Not only were we required to understand the notion of JMS endpoints, we had to pay careful attention to its implementation of QoS (quality of service) imposed on those endpoints lest our orchestration be deemed improperly configured.

Although all the products required some sort of messaging backbone and generally defaulted to a message queue or JMS implementation (particularly products from vendors with a heavy investment in messaging, such as TIBCO and IBM), none of them exposed us to the mechanical details in such a heavy-handed way as Sonic did.

Several products (those from Software AG, Sonic and TIBCO) required that we know a lot more about the inner workings of a WSDL (Web Services Definition Language) file to expose orchestrated services as a Web Service than we consider appropriate. TIBCO's product didn't require that we modify its default values for port-type, message parts and bindings, but it did overwhelm us by showing us these nitty-gritty details, which might lead to the temptation to modify the values without the required know-how. We preferred the autoexposure capabilities of the suites from Oracle, BEA and CapeClear to the products that required us to build a WSDL (those from Fiorano, Software AG and Sonic) before exposing our service to the outside world. And we certainly weren't excited by Fiorano's inclusion of domain specific data — JMS headers — in the WSDL creation process.

Cramping on Code

A codeless approach is a must at the service orchestration layer, and we evaluated each ESB on its ability to orchestrate a simple composite service without requiring code.

Orchestrating services without code means that only metadata is required when moving services from one environment to another and, optimally, would provide interoperability between bus implementations. But interoperability requires an accepted, standard-based metadata language — something that isn't going to emerge any time soon. Although BPEL (Business Process Execution Language) is leading the pack as an interoperable metadata language to describe service orchestrations, it's problematic because it isn't a standard and the version that is expected to be adopted as a standard (2.0) is radically different from the current 1.1 spec.

Only Oracle and Cape Clear use BPEL 1.1 as their orchestration language of choice, with Fiorano and TIBCO offering secondary support as part of their offerings. IBM and BEA view BPEL as a business process layer language, and though that view is a bit forward looking — BPEL 2.0 is expected to address the lack of human workflow in the 1.1 spec, a requisite component of BPM systems — we see their point. But without BPEL or some other accepted standard, we're left with a wide variety of proprietary metadata descriptions for orchestrating services that can't be easily migrated from one system to another. The end result is vendor lock-in.

Even without a standards-based metadata language, most of the products tested do, in fact, offer a codeless service orchestration environment. BEA's AquaLogic Service Bus is not only codeless, but also client-free, requiring only a Web browser to orchestrate services comprised of both internal and external atomic services. Other codeless orchestration environments are currently — or will be this year — Eclipse-based plug-ins.

Not all products are codeless, nor are all products purely metadata based. Cape Clear's ESB 6.5, for example, relies on a code-generating, Eclipse-based design-time environment and requires that code and associated libraries (JAR files) be deployed en masse to its ESB server. Cape Clear also requires that some technology — such as RDBMSs and e-mail — be coded into a service before they can be included in an orchestration. Sonic's SOA Suite requires JavaScript to perform simple content-based routing within an orchestration, and IBM's Message Broker 6.0 requires ESQL (Extended SQL) or Java to include RDBMSs and e-mail in a service orchestration.

And though all the products provide the means to end up with a SOAP-accessible Web Service from an orchestration, not all are as seamless as the automatic service enablement of orchestrations from BEA, Cape Clear and Oracle. Most products require you to add this capability to an orchestration, which in turn registers the service as available for external consumption. The process by which an orchestration is enabled as a Web Service varies from product to product, but all involve the generation of a WSDL and only one (Software AG's Enterprise Service Integrator) lets you define WS-Security requirements during that process.

A Transforming Experience

Messages entering the ESB are certain to leave at some point, but they aren't necessarily going to be in the same format as the original request. A purchase order entering the bus contains data that must be routed to both manufacturing and shipping, but it's likely that the amount and format of that data is different for both systems. That requires transformation, and in an XML world that means XPath and XSLT.