Enterprise service buses hit the road

See correction at end of article

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.

On the plus side, I drilled down easily through process-activity lists to examine run-time conditions and intervene to give stuck processes a manual push. Thanks to support for XPath and XQuery, which allow dynamic routing based on both document header and body content, Cape Clear handled complex routing and errors without a hitch.

Specifying XSLTs (XSL Transformations) proved straightforward using the included graphical mapper, a wizard-driven tool made for quick and easy mapping of unstructured data and Excel documents, hiding much of the underlying complexity in data translation.  I did run into a minor bug in a date-transformation function, however.

Security mechanisms are good but not spectacular. Cape Clear can handle SOAP digital signatures and client-side certificate authorization as well as SAML. Tapping LDAP and Windows NT domain controllers for authorization is not a problem, and JAAS (Java Authentication and Authorization Service) can be plugged in as well. It would be great to see Cape Clear round out the security choices in a future release.

Good load balancing and fail-over management, as well as integration with SNMP and JMX (Java Management Extension)-ready management platforms, make a good case for enterprise deployment. Cape Clear could further strengthen the case by beefing up the management tools and adding some industry-specific process templates or best-practice workflows, such as those in Fiorano.

Nevertheless, with solid links to J2EE and provisions for ORB (object request broker)-protocol integration, Cape Clear presents a finely wrapped, pure-play ESB package suitable for boutique and midsize integration projects.

Cordys 4.2
Founded by Jan Baan, Nordic creator of the once-innovative Baan ERP system, Cordys is the only vendor in our roundup to incorporate a collaborative portal in its suite. Formerly known as the Cordys Business Collaboration Platform, Cordys 4.2 also includes integration middleware, an orchestration engine, and a design studio for developing business rules and modeling processes and workflow.

In addition to being the window into graphical activity monitoring, the portal serves as a foundation for centralized content development and e-learning, thanks to a WebEx plug-in. (No surprise; WebEx is a company in which Baan also has a hand.) Although the portal is a nice touch, the specific KPI (key performance indicator) templates and business intelligence capabilities still have room to grow.

Unlike the other vendors here, Cordys requires you to supply your own Web server (Microsoft IIS or Apache) and database (Oracle Database or Microsoft SQL Server), increasing up-front licensing costs. Cordys also requires you to set up a central LDAP registry for storing configuration information. The Cordys Admin Repository Server (based on OpenLDAP) is provided, but Netscape Directory Server 4 may also be used.

Cordys’ browser-based interface offers access to centralized management and development tools, including run-time monitoring and debugging. The IDE provides good graphical tools for process and application modeling, easy configuration and deployment of applications, and standard mapping for XML data transformations. On the downside, process simulation is absent and Cordys’ WSDL format is proprietary.

The Cordys IDE allows development from several vantages, focusing either on value chain, business context, or straightforward process modeling. Although modeling is currently based on BPML (Business Process Modeling Language), Cordys indicates that BPEL import is forthcoming with eventual migration to full native support.

Architecturally, deployment used to require that each SOAP-processing end point be configured in its own JVM. With this release, Cordys allows you to reduce resource overhead by running multiple processors in a single virtual machine. Caveat deployer, however: Doing so would also make it possible for one nasty bug or system restart to bring down your entire system.

All of the Cordys platform’s functions are extended as Web services and reachable through SOAP calls. Cordys’ message bus also supports Microsoft MQ and includes fair provisions for fail-over. Cordys also offers a JMS connector, but it has not been certified as compliant with the Sun spec and it has never been tested in a customer deployment.

The basic security features include support for Windows-based authentication and ACLs (access control lists). The bundled ACL editor is a nice touch.

Cordys’ ESB shows good promise. Despite various shortcomings, the components of the suite are surprisingly mature for a five-year-old company. The absence of provisions for enterprise management systems (SNMP or JMX), and overdependence on third-party adapters for business-to-business and mainframe integration may limit its appeal in certain circles.

FioranoESB Suite 3.7
Fiorano Software steps into the ESB arena with a Java-based integration stack that combines JMS messaging (FioranoMQ), BPM, and SOA adaptability. Although Fiorano has come to refer to its architecture as “brokered peer-to-peer,” the reality is that — in the absence of a WS-* spec like WS-ReliableMessaging, which Fiorano does not yet support — ensuring the reliability and integrity of transactions will require deploying FioranoMQ (or a similar middleware component) centrally or at the end point.

Fiorano’s Event Process Orchestrator, a NetBeans-based IDE, presented a great palette of prebuilt components that could be modified, saved, and inserted into my flows. From flow controls, database adapters, and MOM connectors to Web-services call-outs, XML transformations, and data-aggregation services, developers gain some good tools to construct intricate processes fairly easily.

The development interface goes a step further with support for real-time simulation, and the debugger enabled capturing and inspecting message-queue contents on the fly. I viewed the flow of transaction data among components, while simple plug-in adapters offered display services that simplified real-time message inspection and even the capability to chat with other admins and troubleshooters.

Not that the IDE couldn’t be improved. The terribly inefficient drawings quickly became convoluted without manual reorganization, and the inability to specify start and end points in the event process -- allowing data flows, in theory, to start at any point along the chain -- proved disorienting. In the plus column, Fiorano’s XSLT mapper, which graphically depicts its Funclets (functions you insert into translations) for easy manipulation, was one of the easiest I’ve used. And the content-based routing capabilities are finely grained.

In addition to Fiorano’s own orchestration, BPEL development is offered to a lesser degree. BPEL is not completely implemented, resulting in limited transaction management and fault- and event-handling capabilities.

Administration and service-specific management also need improvement. For example, although you can easily view active sessions, the queue manager interface makes it difficult to trace past ones.

Furthermore, although Fiorano’s messaging subsystem is hardy, the bus and related components remain light on features. Not all system components can be exposed as Web services without programming, and supported transports don’t go beyond the basics (HTTP, FTP, e-mail). Fiorano doesn’t support JMX-based management systems or integrate with LDAP for access control. Security features do include programmatic support for JAAS and JSSE (Java Secure Socket Extension), but not good options for federated security, for example. Finally, performance can be sluggish, although the inclusion of FioranoMQ 8 in the next release will likely provide a boost.