The queuing model stores message in a queue, so only one proces needs to be active. This model works best when dealing with sending or recieving processes that may not be active.
We all know middleware is the glue that binds client/server and intranet applications together. However, the difficult task is deciding which type and brand of middleware to choose for your next client/server or intranet development project. The task is critical, but unfortunately many of the application development project failures are attributable to bad middleware decisions. Sometimes I think application architects are selecting middleware using "eenie, meenie, minie, moe" rather than a sound research and selection process.
Truth be told, selecting the right middleware product was always difficult for me. The technology changes so quickly that it's difficult to reuse the same approaches from one project to the next. For instance, the database middleware approach for Java applets or applications built just a year ago would not be a good choice for the applications of today. The same goes for Windows-based client/server applications and popular packages such as SAP AG and PeopleSoft Inc.
So what's an application architect to do? The name of the game is keep up, keep things in perspective, and above all, keep your sense of humor. Remember that it's only software. This month, let's take a walk through the hottest message-oriented middleware (MOM) products, continuing my crusade to reach those of you who are still selecting middleware through an office pool. Specifically, let's look at Microsoft Corp.'s first attempt at the MOM market, Microsoft Message Queue Server (MSMQ), and IBM Corp.'s MQSeries. Because MSMQ is so new, I'll spend some additional time on a quick tour of its features and functions.
I covered MOM a few issues ago (see Application Architect September 1997 DBMS) as part of a broader middleware survey, so I won't go into a lot of redundant technical detail here, but it's helpful to understand the advantages. MOM provides asynchronous access to any number of resource servers, including databases. The beauty of using MOM is that the resource server or remote application does not have to be up and running when you are submitting a request. MOM will keep the request (a message) in a queue and move it to the resource server or application when it's available. MOM is able to do this little miracle, and at the same time, guarantee that either the request will work or it will let you know that it did not.
Typical MOM applications include any client/server or intranet application that requires access to any number of other homogeneous or heterogeneous application or resource services. For example, I built a MOM-enabled application for a retail organization a few years back. The client used the MOM API to send messages to an IBM mainframe, a Unix-based database server, and a TP monitor, all at the same time. MOM came in handy with that application because, in many instances, one, two, or all of the resource and application services were not running. However, that did not stop the client application from collecting orders for customers. When the resource servers came back online, the messages were processed on the receptive resource servers. Using MOM, I was able to build redundancy into the system as well, routing around network failures and even building in some lightweight transaction processing features.
There are two basic types of MOM: process-to-process messages and message queuing. The process-to-process model needs both the sending and receiving process to be active in order to exchange messages. This is very much like the traditional interprocess communications (IPC) and remote procedure call (RPC) model, and it lacks the asynchronous features that add to the value of using the MOM. The queuing model stores messages in a queue, so only one process needs to be active. (See Figure 1) This, of course, is the better model for sending to or receiving from processes that may not be active.
So when do you apply MOM? First of all, as you may have guessed, MOM is a good fit for store-and-forward communications or when dealing with applications that are not expected to be reachable at the same time. Second, MOM makes sense for defensive communications or when the network between applications frequently fails. Third, MOM is handy for journaled communication or when you need to log communications between processes. Finally, MOM provides concurrent execution features, processing more than one request at the same time.
MSMQ, in Beta 2 at press time, is a Windows NT-based and COM-enabled MOM product as well as a key product for Microsoft's new foray into the enterprise computing arena. MSMQ joins Microsoft Transaction Server (MTS), Internet Information Server (IIS), SQL Server, and Microsoft's Active Platform strategy in creating an impressive array of products, technology, and tools that finally allow Microsoft to scale.
What's new with MSMQ is ActiveX support. MSMQ provides a set of ActiveX components that implements an API to all MSMQ features. The use of ActiveX components allows access to MSMQ services from MTS, Active Server Pages, and IIS. You can also access MSMQ services from traditional Windows applications such as Excel or Word, or through Windows client/server applications built with Delphi, PowerBuilder, Visual Basic, or any ActiveX-enabled development tool.
MSMQ is able to guarantee delivery of messages using disk-based intermediary storage of messages and log-based recovery techniques. This is an optional feature for the developer. Bear in mind that logging will cost you performance. MSMQ leverages most popular network protocols including IPX/SPX and TCP/IP. You can even mix and match protocols, using MSMQ as the common translation mechanism.
MSMQ supports transactions. Transactions either work or they recover completely, never leaving the participating system in an unstable state. A rollback operation assures the developer that all participants are not left in an unstable or inaccurate state. For instance, in a database update operation any abort condition will cause the database updates to roll back by stopping the send operation. As with TP monitors, operations are never complete until the transaction is committed. MSMQ is also tightly integrated with MTS. When MTS is present, MTS services automatically participate in the MSMQ transaction.
MSMQ administrators work through the MSMQ Explorer. MSMQ Explorer is able to manage all machines in the MSMQ environment from a single administrator workstation. Explorer uses a shared and replicated directory service to manage the configuration information. MSMQ is able to layer into the Windows NT security subsystem, leveraging the NT Access Control List facility.
Other MSMQ features of note include one-time in-order delivery, message routing services, notification services, message priorities, and journaling. One-time in-order delivery assures developers that messages are delivered to their destinations only once and in the order in which they were sent. A common complaint I hear about primitive MOM products is that messages are out of order when they hit another application or resource server. For instance, a line item of a catalog order will hit the database before the customer's address, causing the update to fail.
Message routing services give your client/server application the ability to send messages to their destination using least-cost routing. The administrator only needs to define the cost of each route, and MSMQ will automatically calculate the most economical path for the message. Moreover, routing is able to eliminate single points of failure. Thus, MSMQ can reroute around network problems. This is very helpful if you're dealing with large unreliable networks, such as an enterprise WAN or the Internet.
MSMQ notification services inform the sender that the message was received and processed. They also handle messages that time out, which gives developers the chance to take corrective action when such events occur. Message priorities allow developers to assign priorities to messages -- thus, higher-priority messages are placed ahead of lower priority messages in the queue. For example, an order processing system may process larger orders, or orders from preferred customers, at a higher priority.
Finally, the journaling subsystem maintains copies of messages moving through the system. Developers are able to select messages and queues for the journal. The idea is to allow developers to recover from failures by bringing the messages into synch with the journals.
Building a client/server application using MSMQ is easier than you might think. When an application needs to place a message on the queue, the application uses the MSMQ Open API. There is an ActiveX control wrapped around the API. You need to pass in the name and destination queue, which creates the queue handle. The handle allows MSMQ to identify the destination queues to the MSMQ server sending the message.
Next, you create a message by allocating local memory and adding information to the message. Here is where you have an option to add parameters, such as timeout values, names of response queues, and priorities. The message is sent through the MSMQ Send API (MQSendMessage), and the application closes the queue handle using the MSMQ Close API (MQCloseQueue). If additional messages are to go out later, you can leave the queue handle open. If you open and close queues often, application performance suffers.
The receiver application needs to use the Open API, along with queue identification information, to create the queue handle. When calling the MSMQ Receiver API, MSMQ will pass back a pointer to the message with control information (such as the name of the response queue). After receiving the information, the application closes the connection to the queue. Figure 2 depicts the architecture of MSMQ and the foundation for this process.
MSMQ supports blocking and nonblocking receives. Blocking receives do not return control back to the requester until the message is processed. Nonblocking returns control back to the requester before the message is processed. The idea is to allow the receiving application to continue processing in parallel.
For those of us looking for Internet/intranet application integration, MSMQ is ready for those types of applications as well. You can access an MSMQ queue directly from IIS using Active Server Page (ASP) scripts. Or, you can use CGI and more traditional APIs for C and C++.
Now the kicker: MSMQ won't be available as a standalone product. It will be included with Windows NT Server Standard Edition and Windows NT Server Enterprise Edition.
What is most notable about MQSeries is the number of platforms it supports. At press time you can buy MQSeries for IBM MVS, Pyramid, Open VMS, IBM AIX, NCR Unix, UP-UX, Solaris, OS/2, Windows NT, SCO Unix, and MacOS, just to name a few.
MQSeries supports all of the features of MSMQ including support for transactions and journaling, message routing, and priorities. MSMQ also gives you a common API for use across a variety of development environments on a variety of platforms.
MQSeries products provide you with a single, multiplatform API. Thus, you can send a message from your Windows 95 Workstation and route that message through Unix, VMS, or even a mainframe before reaching the final destination. The platforms running MQ can work together to assure that messages are delivered to their destination, and they can even route around network and system failures. MQ can also be used as a mail transport mechanism, assuring the delivery of messages and transactional recovery. For instance, there is a version of MQ for Lotus Notes.
MQ supports what IBM calls an advanced message framework consisting of three layers: the customer application options, trusted messaging backbone, and comprehensive communication choices. The customer application options give you such services as basic messaging, transactional messaging, workflow computing, mail messaging, option messaging, cooperative processing, data replication, and mobile messaging. With transactional messaging, developers can coordinate message flow with updates to other resource managers. For instance, you can update several databases on different platforms at the same time. The mail messaging feature allows any Vendor Independent Messaging (VIM) or Mail API (MAPI) application to leverage the power of MQ's messaging infrastructure to transmit email securely and reliably. MQ also supports messaging between distributed objects, and it facilitates cooperative processing between two or more processes.
MQ's trusted messaging backbone assures you that messages are delivered to their destinations and that the information encapsulated in those messages is secure. The comprehensive communication choices refer to MQ's ability to leverage any number of protocols and networks for message traffic. MQ will run you $1,595 to $4,995, depending on your platform. This does not include tools, training, or additional software for more than a single server.
As with all middleware, there are several tradeoffs with these products. MSMQ, a freebie with NT, obviously offers the lesser cost. You'll need a sizable investment in MQ to get it into your applications. However, MQ is not that expensive when compared to similar products such as NEONet from New Era of Networks Inc. (NEON), which starts at $75,000. You must consider the total cost of the development effort. Considering only the cost of the MOM product could be very misleading.
You also must consider that you can mix and match both MSMQ and MQ through a gateway being created by Level8 Systems Inc. Level8 will offer an API that will connect MSMQ to non-Windows platforms, as well as a second product that will provide the translation services between MQ and MSMQ.
MSMQ provides the best tool support out of the gate. Its ability to layer easily into most Windows-based development tools means that those of you using native Windows client/server applications will find the least resistance with MSMQ, especially if you're already a Microsoft development shop. MQ, while it works with most development environments, is not as easily integrated with popular client/server development products. This is largely because of MQ's need to be all things to all platforms.
While MSMQ has command of tools and price, MQ clearly has an advantage in scalability, maturity, and platform support. MQ's ability to work with a great number of hosts, servers, and workstations means that developers can support the standard hodgepodge of platforms in organizations and tie all of those platforms together to form client/server applications. Although there are some third-party attempts (such as Level8's) to port MSMQ to non-Windows platforms, right now MSMQ is homogeneous Windows. With the platform support comes scalability. Since MQ is able to support larger, more powerful platforms, you'll have a better opportunity to scale to higher processing and user loads. What's more, MQ wins out when considering fault tolerance, message delivery, time-of-day dispatching, databases access, and broadcasting. MQ should get extra comparison points for being a mature and well-tested product on most platforms.
Considering the tradeoffs and past client/server application architect and developer behavior, I think that MSMQ has the best chance for success for the low-end client/server development marketplace -- which is where most application development occurs. Microsoft's strategy of giving products away and the popularity of Windows NT mean that most IT managers looking for MOM will select MSMQ simply because it's already there. We've already seen this with IIS and Internet Explorer. MQ will continue to dominate the high-end heterogeneous market.
Of course, there are other MOM products on the market and those are certainly worth a look if you're comparing products. However, I believe that these two products will dominate the MOM market in 1998. Write me, and let me know what you think.
|
