Integrating messaging in .Net
Microsoft's .Net architecture offers lots of advantages. This tip, excerpted from InformIT, discusses the ability to allow for applications
Got a developer tip of your own? Why not send it in? We'll post it on our Web site, and we'll enter you in our tips contest for some neat prizes.
One of the particularly effective ways to increase the scalability and reliability of a distributed application is to move from a model where application requests are processed synchronously to one where some or all of the requests are processed asynchronously. Microsoft includes the Microsoft Message Queue (MSMQ) product as a service in their server operating systems to provide the queueing infrastructure for applications to create and manipulate queues in addition to sending to and receiving messages from those queues.
MSMQ is not installed by default in Windows 2000 Server. You can do so by using the "Configure Your Server" utility found in the Administrative Tools group and looking under the Advanced option.
Not surprisingly, the Services Framework provides a namespace, System.Messaging, that encapsulates the functionality of MSMQ. This section will examine the System.Messaging namespace, first in how queues are programmatically referenced and administered and secondly in how messages are serialized, sent, and received by application programs.
Although the System.Messaging namespace contains over 20 classes, the central class is MessageQueue. This class contains both shared and instance methods to allow you to query for queues contained on a particular machine or across the network in addition to manipulating individual queues.
At the most basic level, the set of shared members include Create, Delete, Exists, and several methods prefixed by Get that allow you to query for queues.
For example, the following code uses the Exists method to determine if a queue identified by the mstrPath variable exists and if not creates it. In either case the queue is then referenced by creating an instance of MessageQueue and passing in the identifier of the queue:
If Not MessageQueue.Exists(mstrPath) Then MessageQueue.Create(mstrPath, False) End If Dim oQueue As MessageQueue oQueue = New MessageQueue(mstrPath, False)
Note that in the Create method, the second argument indicates whether the queue should be transactional, in other words use the Microsoft Distributed Transaction Coordinator (MSDTC) service to ensure message delivery. And, in the constructor of the MessageQueue object, the second argument specifies whether the first application to access the queue receives exclusive access to it. Note that creating a new MessageQueue object using the New keyword does not create a new queue, it simply references one that already exists.
You'll notice that the path passed into these methods is simply a string that identifies the queue. In fact, the string can take one of three forms:
The path to the queue as returned by the Path property of the MessageQueue object. This is the typical approach in the form MachineNameQueueName. For private queues, it is MachineNameprivate$QueueName. System queues such as Deadletter$ and Journal$ can also be accessed this way.
The format name returned by the FormatName property prefixed with "FormatName:" This is typically used for offline access to queues.
The label of the queue as returned by the Label property prefixed with "Label:" The Label property can be set for a queue to provide a description. Using the Label is not recommended since labels are not required to be unique and can thus cause exceptions to be thrown when sending messages or referencing a queue.
In addition to creating and deleting queues, the MessageQueue class also provides query and enumeration methods to list the queues on a machine and the message within the queue.
To read this entire tip, click over to InformIT. You have to register there, but the registration is free.
Did you like this tip? Email to share your opinion.
This was first published in September 2001