JMS at the Core of an EAI SolutionSonicMQ 2000.1 Enterprise Edition

• By Michael Harry, Andrei Mitran
• February 24, 2001

Messaging middleware has become an essential component of nearly every modern enterprise. Whether they're trying to cope with multitiered software architectures, interoperate with business partners, or just do a little business over the Internet, companies are finding that to stay in business they need to find ways to integrate and exchange business-critical data efficiently and effectively across multiple, heterogeneous platforms.

Enter Progress Software Corp. and its flagship JMS-based messaging product, SonicMQ. IBM has the best-established messaging middleware in its MQ Series, but Progress has staked out its own niche, what it calls the "e-business messaging" territory (EBM). EBM, the vendor says, is "a rapidly growing category of messaging middleware architected to meet the unique requirements of information integration and exchange over the Internet." Progress claims its EBM products can tackle everything from business-to-business integration and e-marketplaces, to peer-to-peer networking.

SonicMQ is based on the JMS spec, which provides a common set of interfaces, messaging concepts, and programming strategies. Progress began shipping version 3.0 of the product in December 2000, but Michael Harry and Andrei Mitran have been working with SonicMQ since March 2000. Harry, director of IS application development at BuildNet Inc., a Research Triangle Park, N.C.-based software provider to the construction industry, and Mitran, co-founder of Cary, N.C.-based consultancy IVC Inc., evaluated JMS tools for a large EAI project that began in the spring of 1999. They settled on SonicMQ Enterprise Edition. We asked them to give Java Report readers the benefit of their evaluation and experience.

—John K. Waters
Product Review Editor
[email protected]

	Version Reviewed: SonicMQ 2000.1 Enterprise Edition Current Version: SonicMQ 3.0
	CUP RATING SYSTEM: 5 Outstanding 4 Very Good 3 Acceptable 2 Has Potential 1 Poor

THE RECENT DEMISE of money-losing "dot-com" companies is a pattern that is being repeated by money-losing, proprietary EAI vendors whose stock prices are beginning to nose-dive in an all-too-familiar pattern. Choosing products based on industry standards affords a level of insulation from these problems and provides a foundation for robust, supportable systems. JMS specifies and provides reliable point-to-point and publish-and-subscribe messaging services that we decided to use as the core of an EAI solution.

IVC was awarded a subcontract by Strategic Technologies to integrate several back-office systems, including Billing, CRM, Security, Web application, ERP, and others for BuildNet, a major B2B and software provider to the construction industry. We evaluated a number of the leading EAI solutions providers and JMS toolset vendors. The EAI vendors were dismissed because of exorbitant pricing, proprietary technology, shaky financials, weak documentation, and a long learning curve. When the JMS evaluation was completed early in the spring of 1999, it was clear SonicMQ from Progress Software was a winner. SonicMQ extends basic JMS capabilities to include support for XML messages, scalability and failover through clustering, and an administrative console for control over the JMS server(s). The current SonicMQ revision is Version 3. The version we used was 2000.1 Enterprise Edition.

SonicMQ was the only package we evaluated that was up and running in less than 10 minutes from the time we downloaded the evaluation copy. What was even more amazing was that the sample code actually ran and made sense. It is our opinion that the installation was so simple that those having difficulties should consider getting into a new line of work. While this was true for the standard release running on Cloudscape, we will admit to a combination of user errors and inadequate documentation issues getting SonicMQ working with Oracle.

We were able to connect multiple test clients to the hub before the end of the first day. We were also able to complete the project with only two calls to the Progress support line. The first call was to check the response time in order to complete due diligence; the second call was related to a performance issue on Solaris, which turned out to be a Java rather than a SonicMQ issue. We were especially pleased to find that SonicMQ adhered to the JMS standard and that extensions were noted as extensions. During the four-month development phase of the project we did not encounter a single issue with our test hub running on Microsoft Windows NT 4.0. The performance also more than met our needs.

On the downside, however, we found the administration tool to be clunky, flaky and only marginally useful. Furthermore, it didn't address all the administrative and management requirements facing today's EAI developers. As the number of clients attached to a JMS server proliferate, administration issues become more complex by a geometric factor. With that in mind, IVC extended the existing administrative and failover features for our JMS clients known as "Adapters" or "Application Wrappers" in EAI terminology.

As part of our EAI engagement, we created a supportable, long-term solution to address client administration and management issues. Specifically, we felt the following capabilities were needed to effectively run BuildNet's SonicMQ-based EAI environment:

Monitoring and Control
We created a Java-based administrative interface that allows systems administrators to view and control the state of all Adapters using these basic adapter framework capabilities:

• Heartbeat—Application adapters send out a heartbeat based on a configurable interval. Heartbeats can be monitored from an administrative console. Failure to receive a heartbeat at the designated interval is clearly visible in the console and is logged to a central logging facility.
• Ping—Adapters respond with a heartbeat to on-demand messages sent from an administrative console.
• Start—Adapters can be started remotely from an administrative console.
• Stop—Adapters can be stopped remotely from the administrative console.
• Reconfigure—Configurable adapter parameters can be set remotely from an administrative console at runtime. Configurable adapter parameters are stored in a central LDAP server where they are read prior to starting.

Monitoring and Control messages are handled on a separate thread and Queue so that they do not interfere with the real work of delivering data messages efficiently.

Robust Response to Failure
With the large number of applications, adapters, and other components of a complete EAI solution, it is necessary to respond to failures in an intelligent manner. As part of the solution, we constructed an adapter framework with the following key features:

• Detect loss of connectivity—The framework detects loss of connectivity to an application or the SonicMQ hub.
• Automatic SonicMQ hub reconnection—The framework automatically reconnects to an alternative hub if one is available, or reconnects to the original hub once service is restored.
• Automatic application reconnection—The framework automatically reconnects to a data source or des-tination when service has been restored.

Error Handling
We recognized that status and error logging needed to be centrally managed. Dispersed error logs bury key information from support personal during crisis resolution and impair the visibility of issues that can be proactively resolved before a crisis arises. To resolve this, we created a centralized error log with the following characteristics:

• Logging to an RDBMS for more powerful sorting, searching, and filtering than ordinary files.
• Standardized error levels.
• Standardized error types.
• Automatic time stamping.
• Automatic source stamping.
• Support for user-defined messages.
• Configurable filtering by severity level and type.
• Parallel routing of the log stream to the administrative console.

The admin tools we developed in the beginning of this project proved to be invaluable for testing and troubleshooting resources. Deploying them provided us with an immediate ROI of almost 2-to-1. These tools also played a direct role in our meeting the customer's aggressive timetables, and allowed us to deliver a higher quality system. And that is in addition to the long-term payback BuildNet should reap over the lifetime of the system.

The bottom line? SonicMQ 2000.1 Enterprise Edition works extremely well in a single hub implementation. With a little work, it can be turned into the backbone of an EAI solution. In a multihub implementation, failover is not transparent and requires additional effort. Depending on the kinds of transactions involved, this could be a significant issue for some apps. Version 3 of SonicMQ has just been released and, based on the marketing literature, it appears to address some of the shortcomings of the release reviewed.