| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

## Chapter 14
MSMQ (Falcon)

• Message queuing service • Supports mesage prioritization, guaranteed delivery, deferred deliverym, polling, pulling, notification, broadcast/multicast, time expiration of messages • Primarily Windows NT with Windows 95 client access • Other client platform access being provided by Level 8—HP-UX, MVS/CICS, AIX, Solaris, possibly OS/2, and Open VMS

MSMQ is a message queuing service. Message queuing is not the same as mail messaging—a service with which it is often confused. Whereas mail messaging (or just “messaging”) is used by people to send mail messages to other people and communication is directly between people, message queuing is a service used to enable messages to be sent between processes. Thus, a client process could send a message, with data in it about an order, to a server process for that process to act on the order.

Message queuing products and services can support asynchronous processing of communicating processes. The sending process hands the message to the message-queuing service and can then carry on working; it doesn’t have to wait for a reply. In order to achieve this, the products use a store and forward-like approach to handle interprocess communication at runtime. When one process sends another process or processes a message, the middleware stores the message on queues along the route the message takes.

Processes which use message queuing services are actually acting in a peer-to-peer way—process A can send process B a message and in turn, process B can also send process A a message.

Figure 14.1 MSMQ

Figure 14.2 Store and forward queuing

### Message Passing vs. Message Queuing

You may have heard the terms message queuing and message passing. A message passing service or product enables one process to send another process a message by addressing the message directly to the receiving process—SEND MESSAGE nnnn TO PROCESS B. In this case, the sending and receiving process know very little about the existence of the queues; they are there simply to provide a useful storage place to keep messages on the route. The queues are known only to the middleware services—the processes can neither access them nor control them.

In a message queuing service or product, the processes do know about the existence of the queues and address the message specifically to a queue—SEND MESSAGE nnnnn TO QUEUE X. By using message queuing, the vendors of these products provide more options to the developer. The vendor can allow a queue to be read by more than one process at the other end—perhaps sharing messages or alternatively taking messages off the queue in a round-robin fashion.

Internal queues may still be used, for example, a transmission queue at the sending end, intermediate receipt/transmission queues en route, and a receipt queue at the receiving end. But the final queue is a known queue—one the processes can access:

Figure 14.3 Message queuing

Message content

The next obvious question most people ask is what goes in the message—what sort of data content can it have? The answer is that, in general, you can put anything you like in the message—blobs, structured data, sound, images, and so on, even instructions such as a list of SQL commands if you really want. The only restriction might be the length (some products do restrict the length of the message).

But there is a down side to this apparently unlimited freedom of data content. We saw that in order to send a message over the network, the middleware has to translate the data formats between machines—ASCII to EBCDIC, little endian to big endian. The way it did this in DCOM was by using the interface definition, which defined the content of the data going across the network. But message middleware does not use an interface to define data content—the message content is defined within the program—all the middleware knows is that a block of data is passed to it with an unknown content, but a defined length. All it does then is add a header to it to give it an address, priority, and so on.

Some message products do not do data format translation because they do not know the contents of the message, but those that do employ several cunning ways of doing it. Some get you to provide a dictionary with the message contents defined; some get you to tag the fields with a name and then hold information about the name and its format in libraries which you set up. Whatever solution is used, the idea is that you, at some stage, will have to give the middleware details about the content of the message so that it can do the data format translation for you.

Previous | Table of Contents | Next