We’ll start in the usual way, by defining a few terms.
The whole MSMQ network is referred to as an enterprise. This might comprise every single computer in a global organization (although each host has to have a different name, so you’ll have to be careful with your naming convention) or maybe just one or two servers in selected key positions. An enterprise is divided up into connected networks, in which every computer communicates with every other one using the same protocol (TCP/IP or IPX/SPX for example). An enterprise is also subdivided into sites. All the computers in a site are assumed to be physically close, and connected by a LAN rather than a WAN, in similar fashion to an NT domain. A connected network may span more than one site; for example, it might include sites in Chicago, Seattle and Orlando.
This hierarchical topography is used by MSMQ in determining the most efficient route for each message.
One server is designated as the Primary Enterprise Controller (PEC), and this maintains the enterprise configuration database. Within each site, one server is designated as the Primary Site Controller (PSC); this maintains a local copy of the configuration. In a very small enterprise (like mine!) the PEC and PSC can be the same machine. There can also be one or more Backup Site Controllers (BSC). All Site Controllers and the PEC itself require a minimal installation of SQL Server to be installed prior to MSMQ in order to hold (copies of) the enterprise configuration database. In addition to this, other server machines can be designated as Routing Servers. The PEC, PSCs and BSCs are also de facto routing servers. The routing servers are responsible for passing messages through the enterprise. Connector Servers handle connections to foreign (in other words, non-Windows) systems, via systems like Level8’s FalconMQ for Unix.
MSMQ clients are either Dependent or Independent. Dependent clients cannot function without a synchronous connection to a routing server, which carries out all the MSMQ operations on its behalf. Independent clients, on the other hand, can function whilst disconnected from the enterprise. Any messages that they send are saved until they next reconnect (which can put quite a substantial load on the system – particular if there’s a lengthy server outage).
A message queue is a repository for messages. It resides on one machine only (which can either be a routing server or an independent client), and you can think of it in similar terms to a mailbox. However, it can be read by any machine in the network, provided that they have read access (we’ll talk about security in general in Chapter 9). There can be many different queues in an enterprise, or indeed on a single machine.
So then, that’s the theory. Now here’s the practice.