JMS at the Core of an EAI SolutionSonicMQ 2000.1 Enterprise Edition
- By Michael Harry, Andrei Mitran
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
||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.
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.
|Review in a Nutshell
Amazingly simple installation. Works extremely well in a single-hub implementation, but falls a bit short in a multihub implementation. Overall performance more than met our needs.
Operating System Requirements:
- Microsoft Windows NT 4.0 (with SP5), Microsoft Windows 2000, and Sun Solaris 2.8
Supported JVM Platforms SonicMQ Server:
- IBM 1.1.8 (for Windows NT and Windows 2000) and JavaSoft 1.2
- Windows NT and 2000: IBM 1.1.8, JavaSoft 1.1.8, and JavaSoft 1.2
- Solaris: JavaSoft 1.1.8 and JavaSoft 1.2
- Oracle 8i and Microsoft SQL Server 7.0
Pricing and Availability:
SonicMQ version 3.0 is available today, and comes in three editions:
- SonicMQ Developer Edition is a free version available for download at www.sonicmq.com. This edition allows developers to build and test simple messaging applications.
- SonicMQ Professional Developer Edition is priced at $1,200 per user. This edition is designed for complex development and testing environments.
- SonicMQ E-Business Edition is priced at $5,000 per CPU, and is a fully featured deployment product.
|GXS Gets the Message Across With SonicMQ 3.0
|Michael Hickman is the global product manager at GE Global Exchange Services (GXS), Gaithersburg, MD. (GXS is part of GE Information Services Inc., a wholly owned subsidiary of the General Electric Company.) GXS operates one of the largest B2B e-commerce networks in the world, with more than 100,000 trading partners conducting one billion transactions annually, representing $1 trillion in goods and services. The company's e-commerce products include integration, interchange, and marketplace solutions. Hickman works with the Integration Solutions Group, which provides software that permits business applications to send and receive information among other business applications.
Java™ Report: Why did you need a messaging middleware product like SonicMQ?
Michael Hickman: I was brought on board specifically to be the product manager for a new set of intelligent adapters we are building for our integration brokers. These intelligent adapters run remotely from the integration broker and close to the application, like SAP or Siebel. We needed some middleware technology to provide data communications between the adapters and the broker.
JR: What kinds of middleware did you evaluate?
MH: Our engineering team looked at a number of technologies, not just messaging, but also RMI, COM, and DCOM. Among the messaging software, we looked at JMS, MSMQ, MQ Series, and CORBA; we also considered doing some internally developed socket-based mechanism.
JR: Why did you settle on JMS?
MH: The adapters were being built in Java, so using some Java-based middleware would clearly ease that job. And [JMS] has a standard interface, so we could substitute products if needed. It also made the interface between the adapters and the integration broker very straightforward and [put it] in a format we understood very well: messages. If we had used something like RMI or CORBA, we would have been going from a messaging environment to an object-passing environment, and back into messaging. Using a messaging protocol makes all of that cleaner. Also, we felt JMS would help to enhance our products from a technology standpoint, because it's something that is being fairly widely adopted.
JR: How many JMS products did you evaluate?
MH: We looked at three products: SonicMQ, FioranoMQ, and Softwired's iBus product.
JR: What were the factors that led you to choose SonicMQ?
MH: SonicMQ had a lot of great qualities. It measured high on a lot of our criteria. Also, Progress was the only public company in the group. We're GE, and we felt more comfortable with a bigger organization.
JR: What qualities in particular sold you on SonicMQ?
MH: Scalability and performance were very important, but also the capabilities SonicMQ has from an Internet messaging standpoint. Our integration brokers are used in a lot of B2B exchange environments. Some small countries run their e-commerce infrastructures using our servers. So, [the product's] ability to do secure messaging over the Internet was of definite interest to us.
JR: Did you know anything about the products before beginning your evaluations?
MH: I was familiar with SonicMQ, which I had used at my previous job at SAGA Software. In fact, I've been working with the product since it came out of beta, [which] I think [was] in March 1999.
JR: How important was your personal history with Progress in making your decision?
MH: Well, I'm very comfortable with the company. I think they have an incredible development staff. They have a huge performance-testing lab, and I think they are a quality software development organization. Even if they weren't technically superior—which I believe they are—I think this was a good decision for [GE] from a business standpoint. I believe Progress is an organization you can rely on.
JR: What do you like most about SonicMQ?
MH: I like a lot of things about the product, but I'd have to say it's the Internet messaging that clinched it for me. I think [Progress has done] an excellent job with that. I also like the clustering capabilities and scalability features, the multidomain queuing, and the security. I also like being able to do message- or connection-based security. [Progress has] been smart about what they've implemented and the way they've implemented it.
JR: What would you like to see improved in the next version?
MH: We'd like to see multidomain publish-and-subscribe in an upcoming version. The multidomain queuing is great, but we use the multidomain features in our architecture.