Network Computingwww.networkcomputing.com

While messaging technology represents a vast improvement over having applications deal directly with IPX, NetBIOS, SNA (LU 6.2), or TCP/IP to send point-to-point messages, messaging isn't yet sophisticated enough to run without occasional human intervention. In fact, as we discovered first-hand, the planning, design and configuration of a messaging environment accounts for more than 90 percent of the work; programming the transfer of messages between applications was a relatively minor part of the project. Even in the testing phase, we spent much of our time adjusting and redoing our configuration of message queues and other MOM components.

To explore the easily overlooked but critical issues related to messaging middleware implementation, we tested IBM Corp.'s MQSeries 5.0 and Microsoft Corp.'s MSMQ 1.0 in our network lab. Our three test application components exchanged messages at the presentation and business logic levels of a three-tier architecture. For example, we triggered the business logic tier with a message when the presentation tier had finished collecting data.

Our Setup On a network of two 100-Mbps Fast Ethernet LANs connected by Larscom CSU/DSU units and Cisco Systems routers, we used TCP/IP to send messages from within our test application. We wanted to use the SNA LU 6.2 (APPC) protocol, but MSMQ doesn't yet support it.

Among our 25 messaging clients were Windows NT Workstation, Windows95, Windows98, OS/2 Warp and Macintosh System 7 platforms. We used Network Associates' Sniffer protocol analyzer, running on a Dolch PAC63 computer, to examine the content and timing of messages as they traveled over the wire. We also used three message servers: two Gateway 2000 NS-8000 computers with dual 333-MHz Pentium II processors, 512 MB of RAM, and three 9-GB SCSI RAID drives, and a Gateway 2000 NS-7000 computer with a single 333-MHz Pentium II, 512 MB of RAM and three 4-GB SCSI RAID drives. We installed NT Server on these messaging servers. While MQSeries runs on several platforms, MSMQ is available only as an integral component of NT Server 4 with Option Pack 3.

Messaging technology also presents a slew of new terms and acronyms. After scaling the MOM learning curve for both MQSeries and MSMQ, we faced two huge challenges in our messaging project--planning and performance.

Minding Ps and Qs Several flavors of queues are available to MOM-aware applications. Network administrators define each type of queue, along with many other messaging configuration objects, such as channels and channel agents. Queue managers and agents handle message routing to and from each type of queue.

The common, vanilla type is a message queue that applications use to exchange data. In contrast, an event queue receives and distributes event messages. These are issued by an application trying to notify others of a particular occurrence, such as a change in a monitored instrument. An initiation queue holds trigger messages, which instruct trigger monitor applications to launch a program, while a transmission queue carries messages to a remote destination. A request message that elicits a response from an application can have a corresponding reply-to queue that lets the targeted application know where to send its response. Dead-letter queues contain undeliverable messages resulting from full queues, unauthorized use of a destination queue and nonexistent destination queues. A command queue carries management and configuration commands to the messaging software. Finally, system default queues act as templates for queue attributes to apply across a network.