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

Previous | Table of Contents | Next

### Message Routing

We have already seen that messages can be routed across multiple machines and that MSMQ supports routing of messages across multiple nodes. In fact, routing occurs when a session cannot be directly established between sender and receiver, or when in-routing or out-routing servers are being used, or when site gates are being used. So how does MSMQ do its routing?

MSMQ uses two type of routing—intrasite routing and intersite routing.

Intrasite routing-MSMQ makes the assumption that intrasite routing is fast and inexpensive and bases its routing algorithms on this. MSMQ measures intrasite routing in “hops”—the number of routing servers a message must pass through before it reaches its destination. The route is then chosen to minimize the hops.

Figure 14.15 Intrasite routing

For example, a message going from Machine A to Machine D would go from Machine A to Machine B and on to Machine D.

Intersite routing-MSMQ makes the assumption that intersite routing is slow and expensive and bases its routing algorithms on this. Where intersite routing is being used, the routing is based on the concept of a SiteLink. SiteLinks are (as the name implies) communication links between two sites and the administrator assigns relative numbers (representing cost and speed) to the SiteLinks, which are used at runtime by the routing module to decide which route to take.

Numbers between 0 and 999,999 can be allocated, and it is entirely up to the administrator how he or she allocates the numbers. High value numbers are used to denote undesirable links (slow or expensive); low value numbers are the more desirable links (less expensive and faster).

The administrator might typically balance the cost with the delay (the speed of one link versus another). The administrator sets up the SiteLink values when he or she installs new sites. Thus, for example, if he or she had only two sites, any value above zero could be chosen (zero means not connected). Once three or more sites existed he or she would need to start thinking about using different numbers. An example is provided below.

A message needing to go from Site A to Site C would go first to Site B, then Site D, then site C. The SiteLink concept thus not only defines the topology of the network but priority routes. But the information is clearly “static,” not based on traffic or line availability.

Figure 14.16 Example of intersite routing

Other useful functions in MSMQ

It is worth noting that MSMQ does have some additional useful functions to help the developer during program testing. Messages can be tracked to keep a record of the route taken, and the tracking can be done at the application level or for all applications. As messages pass the Routing server, a message is sent to a report queue indicating which server the message passed through, the source address, destination address, a hop count, and the times. Where application level reporting is required, the application sets a message property to indicate tracing is to take place. Where all applications are to be traced, the administrator enables monitoring; tracing does not have to be set by the application. MSMQ Explorer can then be used to view the report queues.

MSMQ also has some debugging capabilities. MSMQ can be used with Visual C++. The developer gets two debug windows—one showing the debug messages for the MSMQ process and the other showing debug messages for the application. Only errors are displayed in the windows, but the developer can trace other information by changing defaults during setup. It is also possible to dump the entire contents of the MSMQ database to detect problems.

### In Summary

What an interesting and useful service MSMQ is. For a new release it has some quite advanced features—features only found currently on the more mature MOM products such as BEAmessageQ, MQSeries, and VCOM.

It is chock full of functions—guaranteed delivery, deferred delivery, broadcast, multicast, notification, polling and pulling, message prioritisation, and so on. I think most developers can see that potentially it has an enormous number of uses.

But it is worth noting two small notes of warning. The first note is about platform support. Remember that MSMQ is essentially a Windows NT-based product with client access from other platforms. The other MOM products on the market cover many more platforms and are not restricted to client only access from those platforms. A product like BEAmessageQ can link SunOS, Solaris, AIX, HP-UX, Digital UNIX, OS/2, Windows NT, OpenVMS, Ultrix, 88000 Delta, DG-UX, and NCR Unix. It can also provide access from OpenVMS to MVS/CICS and MVS/IMS via LU6.2 services.

The second note of warning concerns the change to the Active Directory. MSMQ may need to undergo some quite extensive adaptation when Windows NT version 5 is released, as this release should include the move to the Active Directory. At the moment MSMQ uses its own Directory. But in the future, MSMQ’s Information Store will probably be replaced by the Active Directory.

Furthermore, MSMQ’s Information Store is also used to store its public queues, so the move to the Active Directory is not just going to affect the Information Store itself but also the queues themselves. Finally, MSMQ’s private queues are stored in the old Registry used by Windows NT 4.0, so the move to the Active Directory will affect the private queues too. I don’t expect the functionality of MSMQ to change, but I would be prepared for the fact that the changes needed will affect its stability for a while.

Previous | Table of Contents | Next