Enterprise service buses hit the road

See correction at end of article

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell Return to special report DOWNLOAD PDF Click here to download InfoWorld's special report Enterprise service bus

EAI (enterprise application integration) has come a long way since our early ancestors fashioned the first custom connectors out of wood, shell, and stone. Back then, the goals were modest, the work was difficult, and the results were brittle. They were also costly to maintain. Change required starting over from scratch.

Today we know that IT systems must adapt more quickly to business needs, and there’s no shortage of middleware vendors promising to make that happen. The magic ingredients are SOA (service-oriented architecture) -- an integration paradigm that prescribes open standards and lightweight, distributed components -- and the ESB (enterprise service bus), a newfangled integration platform designed to support the SOA paradigm and tie into legacy assets.

The golden dream behind the ESB is to replace proprietary integration brokers with open communication layers through which distributed services and business processes are readily exposed and easily managed. The immediate reality, however, is that it may be too soon to leave the old messaging subsystems behind.

Regardless of the underlying messaging core, an ESB must somehow -- through open standards or by proprietary means -- create a foundation for reliable messaging. Until WS-* specifications for reliable messaging fall into place, that reliability continues to come from the likes of JMS (Java Message Service), homegrown messaging engines, proprietary MOM (message-oriented middleware), and J2EE servers.

Among the seven ESB packages in this roundup, all but two incorporate an old-school messaging subsystem; Fiorano Software and Sonic Software are based on proprietary messaging middleware. Iona Technologies extends its legacy EAI architecture. PolarLake and FusionWare take a server-centric, connector-based approach. Only Cape Clear Software and Cordys use a truly open and distributed SOA.

What else must an ESB suite provide? It should have tools that streamline development, a data-transformation engine, intelligent message routing, and a management interface supporting real-time monitoring and exception handling, as well as deployment and management of actual services. Most of the products reviewed here meet all of these requirements to varying degrees.

Additional features may include process orchestration and management, BAM (business activity monitoring) and QoS capabilities, support for enterprise management systems such as HP OpenView and IBM Tivoli, and the inclusion of ready-made adapters for quick integration of enterprise apps, data sources, application servers, alternative transports, etc. These were all key differentiators among the products tested. Further, not all of these suites support service discovery and re-use, accelerate XML processing, or offer content-based message routing. In short, each of the products offers a distinct set of strengths. Not all of them, however, would meet the challenges of large, complex integration projects.

Cape Clear 6.1
Born from members of team Iona, Cape Clear made its name as an early pioneer in Web-services platform infrastructure. Cape Clear 6 is a well-equipped Java-based ESB suite that combines Web-services messaging with content-based routing and data-transformation capabilities, BPEL (Business Process Execution Language)-driven orchestration and workflow, and a battery of wizard-driven helpers and administrative tools for monitoring and managing system health.

Striving for completely standards-based integration, Cape Clear eschews the need for proprietary messaging subsystems, like Sonic’s, in favor of open WS-* specifications. Cape Clear also has opted not to supply a J2EE/JMS messaging backbone, choosing instead to mesh with those from BEA Systems, IBM, Sonic, Tibco Software, and others. This approach will change July 26, when Cape Clear 6.2 ships with a fully integrated version of the JBoss JMS.

Version 6.0 supports the WS-ReliableMessaging protocol, a QoS mechanism for building delivery assurances between end points. Version 6.0 also ushered in a BPEL orchestration engine and an Eclipse-based orchestration toolbox for building composite applications from process flows.

The Version 6.1 update makes some notable orchestration enhancements including support for the missing Wait action — necessary to support multibranching, asynchronous processes — and auto-generation of BPEL variables. It also improves the orchestration engine’s ability to recover from system failures, adding database persistence that allows the orchestrator to resume processes exactly where they were left off.

The WS-ReliableMessaging specification has yet to be officially locked down, but Cape Clear is firmly committed to its support. Using a plug-in adapter, Cape Clear can also speak with JMS transports such as SonicMQ and WebSphere MQ.

The Orchestration Studio’s BPEL scripting toolkit is one of the best I’ve used. Using the drag-and-drop building blocks, it was a cinch to define and build up workflows. Debugging and simulation capabilities could use a kick-start, however.

Cape Clear’s monitoring and management tools are sufficient for smaller deployments, but they’re not up to the task of managing large numbers of distributed servers as a group. The admin interface shows a general overview of running processes but offers limited reporting and BI insights. The built-in monitoring and alerting cover the essentials, but they’re inadequate for keeping a close eye on QoS. Services management is also very basic, with no change-management or dependency-checking features.