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

Previous | Table of Contents | Next

### Polling, Pulling, and Notification

The terms polling, pulling, and notification are used to describe the ways that messages are taken off the queue by the receiving process. The word polling means that the process reads the queue (the receipt queue), but in reading it, its thread is not blocked; it can carry on working. The word pulling means that when the receiving process reads the receipt queue, its thread is blocked and it sits and waits until a message arrives.

The word notification means that the message queuing middleware actually notifies the process when a message does arrive by triggering it. Thus, notification does not mean the interruption in processing of a running server; it means that a dormant server is activated when the message actually arrives.

MSMQ supports all three methods of removing messages from a queue—polling, pulling, and notification. It is thus possible to devise servers that are dedicated to handling a specific type of message and pull that message from the queue, or a server could be designed that responded to multiple message types and polled various queues in turn to determine the processing it needed to follow.

### Message Prioritization

Normally messages are stored in FIFO order in flat files, but MSMQ also supports the prioritization of messages. Priorities of 0 to 5 are supported (5 being the highest priority). Message priorities 6 and 7 are reserved for internal use. Prioritization is used to transmit the message across the network—from transmission queue to transmission queue.

This latter point deserves some explanation. It is possible to use the prioritization at many stages of delivery—as the message is stored on the transmission queue, over the network, as it is removed from the transmission queue and placed on the receipt queue, and so on. What we are seeing in MSMQ is that the priority field is only used for transmission over the network.

### Message Content

Whereas DCOM uses a fixed format “message” because the ordering and type of parameters are determined by the interface definition, MSMQ messages can contain any information the developer wants. In principle, there is no restriction on what goes across the network. The developer packs these messages, and MSMQ adds the necessary header information to the message. In principle, there are also no limits to the size of messages used in MSMQ (the beta limited the size to 1 megabyte).

Data format conversion is a little more of a sticky problem, and for the short term, where MSMQ is being run on machines with different formats, you may have to do the data format conversion yourself, as (as far as we are able to make out) MSMQ doesn’t support automatic data format conversion of messages. You need to check this yourself, though, when you use the service, as it was such early days in the life of the product when I wrote this that they could have added it by the time you read this.

### Session Handling

Sessions are established between Routing servers, and as such from the applications point of view communication is essentially sessionless. MSMQ uses the concept of session concentration to reduce the number of actual sessions between nodes. Intrasite session concentration is used to reduce network bandwidth use and intersite concentration is used to reduce costs—these two approaches employ different methods to achieve their aims.

In addition to the session concentration, the administrator can use site gates as a means of funneling site traffic between two computers, thus providing another form of session concentration. Furthermore, he or she can use In-Routing and Out-Routing servers as a means of funneling request from or to the client via the server.

### Broadcasting and Multicasting

We came across the concept of a broadcast or multicast message in the chapter on COM. There we saw how the Outgoing interface could be used to provide a form of broadcast or multicast delivery which was not “reliable” because the messages were not stored en route. If a server process happened not to be available when the event was generated, it wouldn’t get the message.

I concluded that the Outgoing Interface was useful when you didn’t mind if the event was not delivered—for example, events that only had validity anyway at the time they were generated—but that MSMQ was a better solution if you wanted reliable delivery of events or messages to multiple servers. If you remember, I said that a broadcast of a message was delivery of a message to all the processes on the network where the sender did not need to know the recipients, their name, or address.

Multicast delivery of a message enabled a sender to output a message that was then sent to a selected number of processes on the network that had subscribed to receive the message. Again, the sender does not have to know who has subscribed; its only job is to send the message. It is the recipients that decide whether they need to know about the message or not.

Public queues can be used for simulating a form of “broadcast” or “multicast” of a message. In true broadcast and multicast, the message is placed on a single queue and applications can subscribe to receive the message. That message is then sent in turn to each (running) application registered until the last application registered has received the message.

In the approach used by MSMQ, applications don’t subscribe to receive a message; they have to read a specific queue to see if a message is there, but they can share a queue. So, for example, a single message could be sent by a client to a site queue that would then be “peeked at” by one or more applications at that site (thus ensuring the message was not removed when it was looked at). These applications could themselves be situated on different machines on the site.

Similarly, a message could be sent to an enterprise queue that was then duplicated across sites. At each site one or more applications could then peek at the replica copy or the master copy of this queue. The effect of this approach is pretty much identical to that achieved by broadcast or multicast messaging.

Previous | Table of Contents | Next