MSMQ runs as a service under Windows, and exposes a set of objects that client applications and components can use to create messages and queues, and to send the messages to the appropriate queue. It also provides methods that can find and search through message queues, and retrieve messages from queues. This is the basic functionality required to work with message queuing.
The MSMQ objects also provide methods for encrypting messages, acknowledging their receipt, and securing the queues. Finally, there are tools and samples available that allow you to set up, test, monitor and administer the service as a whole. We'll be using some of these tools later in this chapter. First, however, we'll look at the architecture and structure of MSMQ.
The MSMQ Architecture
MSMQ depends on a hierarchical structure of servers and clients. At the root is the Primary Enterprise Controller, which stores details of the queue locations and the other servers and clients that have access to the queues and messages. When you first install MSMQ you have to provide a location and name for the enterprise as a whole. Normally you will have only one enterprise that contains all the systems that you wish to communicate with, although it is possible to pass messages between enterprises.
The Enterprise Controller supplies information about the entire enterprise to all other systems when they need to locate or work with a queue, and is responsible for the routing of messages between queues. MSMQ also defines the concepts of sites and connected networks. Within the enterprise are sites, which consist of machines that have generally fast and reliable links between them. Often sites are defined by physical boundaries, such as all the machines within one building. The links that connect each site can also have 'costs' defined for each one, which provide information that MSMQ uses to efficiently route messages between sites. We'll come back to this aspect later.
A connected network defines a set of machines that can communicate directly using the same protocol (either IPX or IP). A connected network may mirror a site, but doesn't have to. It's also possible to connect machines using Remote Access Services (RAS) to pass messages between them, providing they are not using the NetBEUI protocol.
The Enterprise Controller And Other Servers
Once an Enterprise Controller is available, other servers and clients can connect to it. An MSMQ server can only run on Windows NT Server. You can also install MSMQ as a Primary Site Controller, a Backup Site Controller, or a Routing Server. If you need to communicate with machines that run different operating systems, you can also set up an MSMQ Server as a Connector Server, where it acts as a bridge between native and foreign queues. The Primary Enterprise Controller also provides the services of a Primary Site Controller for the site it's located in, and a Routing Server within that site.
Site Controllers hold read-only copies of the parts of the enterprise information store that relate to their own site, and each site can contain both a Primary and a Backup Site Controller. All other MSMQ Servers are Routing Servers, which can provide intermediate queuing of messages as well as routing them to their final destination. You must have a Primary Enterprise Controller installed and available before you can install any other MSMQ Servers. Primary and Backup Site Controllers also provide the services of a Routing Server.
Routing Servers don't hold any site information, and are used only to route messages between queues. They allow computers using different protocols to communicate, and can send messages between other MSMQ Servers and MSMQ Clients.
The MSMQ Administrator's Guide (installed with MSMQ and available from the MSMQ section of the Start menu) provides a full description of each type of Server, as well as valuable information on how you should partition a large enterprise in order to maximize performance.
Dependent and Independent Clients
MSMQ Clients can be installed on Windows NT or Windows 9x, and require a Primary Enterprise Controller to be available when they are installed. Dependent Clients can only communicate with MSMQ synchronously (i.e. they have to wait for communication to complete when accessing the message queue) while Independent Clients can communicate asynchronously.
What this means in essence is that a Dependent Client can only send and receive messages while it is connected to, and can access, its site controller. This is because they use DCOM to access the functions of the MSMQ Server to which they connect, and have no facilities to create queues or store information locally.
In order to provide connectionless (or disconnected) messaging, an Independent Client—which can store messages in a local queue and synchronize them when a connection becomes available—must be used. This connection can be made through the LAN in the normal way, using IP or IPX protocols, or through RAS to a remote MSMQ Server.
An Independent Client can even move from one site to another, and it is automatically configured by MSMQ to allow messages to be sent from it while it is connected to the new site. However, it cannot receive messages while connected to the new site unless it has previously specified details of the new site, while still connected to its original site and before moving to the new one. You can think of it as having to tell your local post office to redirect your mail while you're away.
How The Messages Are Stored
In its simplest form, a message queue is just a bucket for holding messages that are in transit or waiting for collection. In MSMQ, they can be implemented either as disk-based (recoverable) or RAM-based (express) queues. Using memory to hold the queue provides high performance, but, for a robust application the queue needs to be stored on disk. In mission-critical applications, this will be protected by backups, and possibly fault-tolerant disk systems, to allow reliable recovery in the event of a failure.
The message themselves are stored in native format—as text and/or binary data—and as separate disk files in the case of disk-based queues. This gives maximum performance. If you implemented MSMQ through the Windows NT4 Option Pack, you'll also have to have Microsoft SQL Server available. However, this is only used to store details of where each queue is located—and not the contents of the messages. In NT5, the details of the queue locations are stored in the Active Directory Service, and SQL Server is not required.
Queues can be specified as public or private queues, and MSMQ also provides special queues that act as the journal, dead letter, transactional dead letter, administration, system, and report queues. It's also possible to specify the maximum size of a queue, or the total size limit for all queues on a machine.
How The Messages Are Routed
The diagram we used earlier to show the topology of an MSMQ enterprise included connections between the various computers that indicated the hierarchy, with the Primary Enterprise Controller at the root. However, in most networks, there are multiple communication paths between computers, both within a site and between sites. This is also the case with the Internet, where packets can be routed in many different ways to reach the same destination.
Obviously it makes sense to use the 'cheapest' route between two machines. However 'cheapest' is not always 'shortest', so there has to be some way of defining the suitability of a route for messages so that they can be delivered with the maximum efficiency and speed, and the least cost. MSMQ does this by allowing administrators to allocate a cost to each route between computers. For machines within the same site there is generally no cost, because they are connected by a fast and reliable network—probably Ethernet at 10 MB/s or more. Between sites, however, it may be a 28.8 KB/s modem over normal telephone lines. Site link costs can be set to any number between zero (no cost) and 999,999 (highest cost).
The following diagram shows the original connections we defined in the previous diagram, but adds some new connections in darker lines. You can see that, despite there being a direct connection between them, the cheapest way to get a message from Site C to Site B is via Site A. For example, this route via a permanent leased line, while the direct route is a dial-up Internet link.
The Message Queue Object
Before you can send a message you need to have a queue available, either an existing one or one you create specifically. This is one area where message queuing differs from traditional email. When you send email, you address it to one or more individual recipients. Even email to a named group of people, such as a mailing list, is only delivered to one place—where it is replicated and delivered to all the appropriate recipients. When you receive mail, you can only access your own mailbox, or those declared as being public on the mail server.
In MSMQ, your application can search for and access any public queue, and write, read and remove the messages there. To prevent unauthorized access, queues can be assigned permissions in a similar way to files and directories on a disk. We'll be looking at these aspects in more detail in a later chapter of this book.
The physical location of each queue can also be specified. It can be on the Primary Enterprise Controller, another MSMQ Server, or an Independent Client—either at the sender's or the recipient's end of the network, or somewhere in between. Queues cannot be created on Dependent Clients, which themselves demand a permanent connection to the enterprise.
The Message Object
MSMQ messages are implemented by creating an instance of a
object, and setting its properties. Once the message is complete it is sent to the appropriate queue where it resides either until another application collects it, or until it expires. The conditions for expiry and the time-out period can be set when the message is being created.MSMQMessage
One of the major advantages of message queuing in MSMQ is that an acknowledgment from the recipient can be requested. The sender simply specifies the queue that is to be used for the reply, and MSMQ looks after all the details. Recipients can also reply with custom acknowledgments if required.
About Transactional Messaging
In Chapter 3 we looked at the concept of a Distributed Transaction Coordinator (DTC). This is a software component which ensures that a transactional process completes, and it is controlled by the transaction server—in our case MTS. MSMQ contains its own DTC, allowing compliant applications to send messages under transactional control.
By setting a flag on the message, and sending it to a queue that is defined to support transactions, the DTC can provide full support for a transacted process. If the message is delivered correctly, MSMQ will allow the transaction to succeed. If not, the transaction will be aborted, along with all the other processes that were part of it. Alternatively, if another component within the transaction causes it to abort, the DTC ensures that any messages relevant to the transaction are removed from the queue without being sent. MSMQ can thereby guarantee both delivery of a message, and that it has been delivered exactly once. It can also guarantee that multiple messages arrive in the correct order.
The standard Microsoft DTC also supports MSMQ messaging, using a two-phase commit mechanism. In other words, an acknowledgment message from the recipient is used by MSMQ to provide evidence of success. This method is known as a coordinated transaction, and is usually slower and less efficient than the native MSMQ technique.
Transactional messaging is not supported on Windows 95 with Independent Clients. However, Windows 95 Dependent Clients can use the MS DTC Proxy, which is installed along with the Dependent Client software, to achieve transactional messaging.
So MSMQ can provide several useful services to our distributed application, including translation between different operating environments, disconnected messaging for network links that are slow or not always available, and support for transactions via Microsoft Transaction Server.
