|< BACK  NEXT >|
The whole MSMQ network is referred to as an enterprise. Figure 9.2 shows the logical view of an enterprise.
An enterprise might be comprised of every computer in an organization, or just those computers that wish to participate in message queuing.
Normally, an organization would have just one enterprise, although it is possible to have multiple enterprises and pass messages between them.
An enterprise is further subdivided into sites. A site consists of machines that generally have fast and reliable links between them. Often, physically close machines (such as machines within a building) are grouped together as a site. Machines within a site are connected by a LAN rather than a WAN.
A site is connected to another site by one or more links. Each link has an associated cost that MSMQ can use to efficiently route messages between the sites.
An enterprise can also be logically subdivided by connected networks (not shown in the figure). A connected network defines a set of machines that communicate directly by using the same protocol (IP or IPX for example). A connected network may mirror a site, but it doesn t have to. It may span more than one site.
All the machines within an MSMQ enterprise are classified as MSMQ servers or MSMQ clients.
An enterprise is built as a hierarchical topography of sites. One computer forms the root of this hierarchy and is designated as the Primary Enterprise Controller (PEC). The PEC is an MSMQ server that stores, among other things, the details of all the queue locations within an enterprise and the costs of the site links. It uses Active Directory to store this information.
Within each site, one server is designated as the Primary Site Controller (PSC). The PSC maintains a local copy (read-only) of PEC s database.
A site may also contain one or more Backup Site Controllers (BSC). When a PSC fails, the BSC temporarily fills in for the server.
A PEC is also a PSC for the site in which it is located.
An MSMQ server can also be set up as a Connector Server. A connector server is a bridge between MSMQ and non-Microsoft queuing systems.
Some MSMQ servers can be designated as Routing Servers (RS). The routing servers are responsible for passing messages through the enterprise. The PECs, PSCs, and BSCs are all de facto routing servers.
An MSMQ server can be installed only on a Windows 2000 Server or a Windows 2000 Advanced Server machine.
MSMQ client machines are either Dependent or Independent.
A dependent client requires a reachable network connection to an MSMQ server. All the MSMQ operations are actually carried out on the server on the client s behalf.
An independent client maintains its own queues. Thus, messages can be created (and queued) even when it is disconnected from the network. Laptops and notebook computers are good candidates for being independent clients.
A message queue is a repository for messages. It resides on one machine only, but can be read by any machine in the enterprise, as long as the reader has read-access to the queue.
There can be many different queues on a single machine. These queues can be seen and administered through the Computer Management snap-in provided with Windows 2000. Figure 9.3 shows a snapshot of MSMQ queues present on my machine.
Queues can be divided into two groups: application queues and system queues. Application queues are created by applications. System queues are created by MSMQ.
Application queues are created by applications. Once created, applications can send messages to and receive messages from the queue.
There are three types of application queues message, response, and administration.
A message queue is a queue where messages are normally sent to and read by applications.
A response queue is a message queue that is used to store the return messages from the reader, primarily directed towards the sender.
Administration queues are specialized queues to hold ACK or NACK messages.
When created, an application queue can be designated as a public queue or a private queue.
A public queue is registered in the Active Directory. The properties of a public queue are replicated throughout the enterprise; any application can use MSMQ lookup APIs to locate them.
A private queue is registered on the local machine and typically cannot be seen by other applications. An application that creates a private queue must somehow distribute the location of the queue to the receiving applications.
As private queues do not use the directory services, they are faster to create, have no latency, and no replication. As creating the queue does not require the directory service to be available, the private queues are useful for offline operations.
System queues are created by MSMQ. Only MSMQ can send or receive messages on system queues.
There are two types of system queues journal queues and dead-letter queues.
A journal queue is automatically created each time an application queue is created. A journal queue can be used to keep track of messages sent or retrieved from its corresponding application queue. However, an application has to explicitly request journaling capability. To save a copy of a message sent from the computer, source journaling needs to be enabled. This is done by specifying a property when a message is being sent. If a copy of a message that is being retrieved from a queue needs to be saved, target journaling needs to be enabled. This is done by setting the journaling level property of the queue, either during creation time or later.
Dead-letter queues are used for storing messages that cannot be delivered. A message specifies a time limit for it to reach the queue, the default being a value LONG_LIVED. A typical value for LONG_LIVED is 90 days, but this can be adjusted by a system administrator. If a message cannot be delivered within the specified time, it is moved to the dead-letter queue.
MSMQ maintains two dead-letter queues on each MSMQ server or independent client one for transactional messages and one for non-transactional messages.
Besides system and dead-letter queues, MSMQ also creates a third type of queue called the outgoing queue. These queues are used internally for routing purposes and cannot be manipulated by an application.
Enough with the overview! I am itching to write some code (and you must be too). There are some excellent references at the end of this chapter to get a better understanding of MSMQ architecture.
There is just one more thing that deserves some attention from a programming perspective: how can you identify a queue uniquely?
A queue is uniquely identified by a name. Two types of names are used: a pathname and a format name.
The pathname of a queue is similar to a file name. Table 9.1 shows some examples of a pathname.
A publicqueue MyPubQueue on machine MyPC
A publicqueue MyPubQueue on the local machine
A private queue MyPrivQueue on machine MyPC
A private queue MyPrivQueue on the local machine
A pathname is represented as a string of UNICODE characters.
The maximum length of a queue pathname is 124. Do not exceed this limit.
A format name also uniquely identifies a queue. While the pathname is used primarily to create a queue, the format name is used for most other operations on the queue, including sending and receiving messages.
When a queue is created, MSMQ generates the format name for the queue. The following VBScript code snippet creates a queue and displays its format name:
set qi = CreateObject ("MSMQ.MSMQQueueInfo") ' Set Queue Information qi.PathName = ".\PRIVATE$\TestQueue" qi.Label = "Test Queue" ' Create the queue qi.Create ' Display the format name for the newly created queue msgbox qi.FormatName
The output of the program is shown in Figure 9.4.
MSMQ defines many kinds of format names.
A public format name is used for public queues. When a public queue is created, MSMQ generates a queue identifier that is a GUID. This identifier can be viewed by bringing up the properties dialog box for a public queue through the Computer Management snap-in.
A public format name has the following syntax:
A private format name identifies a private queue. Its syntax is:
Here, MachineGUID is the GUID of the machine where the private queue resides and the QueueNumber is a hexadecimal number generated to identify the private queue.
A direct format name is useful to send or retrieve messages directly from a queue in one step (no routers involved), or to open a queue that is not in the current enterprise. Some examples of the direct format names are:
DIRECT=OS:MyPC\MyPubQueue DIRECT=OS:MyPC\Private$\MyPrivQueue DIRECT=TCP:220.127.116.11\MyPubQueue
Now let s get on with the programming. We will pick some more information as we go along.
|< BACK  NEXT >|