Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

MSMQ for .NET Developers, Part 2 : Page 3

Learn how to use MSMQ to send messages with complex messages types (not just strings), send MSMQ messages over HTTP, and explore several more useful queue and message properties as well as a few invaluable MSMQ tips and pitfalls.


advertisement
Internet Messaging
One of the more highly acclaimed features in MSMQ version 3.0 is the ability to send messages over the Internet—a feature known as Internet Messaging. The nature of the message does not change, except that MSMQ formats the message as a SOAP message. The feature is useful because it allows sending applications to route messages through firewalls over port 80. Further, by using SSL you automatically gain the advantages of the high-grade security built into the transport, alleviating the need for a VPN to ensure payload security.

To send a message using Internet Messaging, the server must have MSMQ HTTP Support installed using the Windows Component Wizard. Figure 1 shows the Windows Component Wizard with the Message Queuing details window open.

 
Figure 1: Installing MSMQ HTTP Support: You must install MSMQ HTTP support to be able to send and receive MSMQ messages via the Internet.
When installed, MSMQ adds a new Virtual Directory in IIS named MSMQ. MSMQ uses this directory to install a new handler to receive MSMQ SOAP messages—it receives messages and forwards them to the local MSMQ service. Assuming the appropriate firewalls have been configured to allow SOAP traffic on port 80 to your IIS server, there is only one more step, changing the format name.

To use Internet Messaging, simply change the format name, instructing MSMQ to use HTTP (or HTTPS). For example, to send a message to a private queue named DevXTestQueue on a server named MyServer, use the following format name: DIRECT=HTTP://MyServer/MSMQ\private$\DevXTestQueue.

One caveat: you cannot listen on remote queues using Internet Messaging. Listening still uses port 1801, and you will get an MSMQ error if you attempt to open a queue for reading using an Internet Messaging format name. You should also be warned that remote reads are rarely a good idea, regardless of whether you attempt to use Internet Messaging or not.

More Useful Message Properties
In my previous article, I stated that MSMQ provides a prioritized first-in-first-out (FIFO) queuing system. It was probably clear that messages are processed in a FIFO manner, but that doesn't explain the issue of how MSMQ deals with prioritization. MSMQ provides a facility to modify the priority of messages, causing messages with a higher priority to be placed in the receive queue ahead of other lower priority messages (even if the lower priority messages arrived first).

The Priority property is of type MessagePriority, which is a .NET enumeration that provides eight strongly typed values that you can assign to a message. Message priority can range from 0, the lowest priority, to 7, the highest priority. The default message priority is 3. The equivalent MessagePriority enumeration named values range from Lowest and VeryLow to VeryHigh and Highest—the default is Normal. You set the message's priority before sending it. The code sample below demonstrates how to set the priority on a message object to High.

myMessage = New System.Messaging.Message() myMessage.Priority = MessagePriority.High

The Recoverable Property
In its default mode, MSMQ delivers messages in a mode intended to deliver high-performance at the cost of an increased risk that some messages could get lost if the machine hosting the message queues were to lose power (or if the MSMQ service were restarted). The messages are stored in a memory structure, without explicitly being written to disk. If your application architecture requires a higher level of certainty that a message will be delivered, you can set the Recoverable property for messages to True (the default is False). As described in a previous article, Nine Tips to Enterprise-proof MSMQ, you will incur a performance penalty for making messages recoverable. The code below demonstrates setting the Recoverable property for a message.

myMessage = New System.Messaging.Message() myMessage.Recoverable = True

The UseDeadLetterQueue Property
The dead letter queue is a special-purpose queue designed to store messages that could not be delivered. The idea is that your application could periodically poll the dead letter queue for errant messages and handle them appropriately. By default, MSMQ deletes messages that cannot be delivered, but by setting a message's UseDeadLetterQueue property to True (the default is False), any messages that reach the end of either TimeToReachQueue or TimeToBeReceived will be moved to the dead letter queue. Unless it is important—and even then only if you have an automated task patrolling the dead letter queue—I would discourage you from using the dead letter queue. Unchecked message volumes can grow and cause problems with MSMQ on the machine. If you must use it, the code sample below demonstrates setting the UseDeadLetterQueue property on a message.



myMessage = New System.Messaging.Message() myMessage.UseDeadLetterQueue = True

The UseJournalQueue Property
Journaling is a feature of MSMQ that creates a debug trace of all messages sent or received. When you set the UseJournalQueue property for a message, MSMQ places a copy of the message in the journal queue (in the System Queues folder of Computer Management) when it sends the message. To journal messages received from a queue, set the queue's UseJournalQueue property to True. Note that to journal messages as they are sent, you set the property on the message object, but to journal messages as they are received from a queue, you set the property on the queue object. Exercise caution when using journaling, because (like the dead letter queue) it can quickly and stealthily add tremendous volumes of messages to queues on your MSMQ server. The code sample below demonstrates setting the UseJournalQueue property on a message.

myMessage = New System.Messaging.Message() myMessage.UseJournalQueue = True

The DefaultPropertiesToSend Class
Often, messages sent to a queue will have the same properties set (such as Priority, Recoverable, etc.). MSMQ provides a facility for automatically setting the properties on all messages sent using the same queue object, so you can easily send messages with the same properties and simplify messaging development by avoiding manual message creation.

Here's how to use the DefaultPropertiesToSend class. Create an instance of the DefaultPropertiesToSend class and set all the properties that you would normally set on each message, and then set the DefaultPropertiesToSend property on the queue object to the DefaultPropertiesToSend object that you just populated. Despite the fact that the names of the class and queue property are the same, the use of the object should be fairly self explanatory. The code sample below demonstrates setting each of the properties covered above using the DefaultPropertiesToSend property.

Dim objDefProps As New System.Messaging.DefaultPropertiesToSend objDefProps.Priority = MessagePriority.High objDefProps.Recoverable = True objDefProps.UseDeadLetterQueue = True objDefProps.UseJournalQueue = True myReceiveQueue.DefaultPropertiesToSend = objDefProps myReceiveQueue.Send("Test Message")

MSMQ and its plethora of features has been the subject of entire books. Rather than try to cover all its features, this two-part article demonstrated several of the most widely useful features supported by MSMQ. I encourage you to do more MSMQ exploration and experiment with its many features before building an application framework around it.



Michael S. Jones is the Director of Systems Architecture for Passport Health Communications, Inc., a national healthcare technology provider connecting hospitals, physician clinics and outpatient centers with payer and patient information to facilitate and improve their revenue cycle process. Michael, his wife, and three children live in Franklin, Tennessee where he spends his spare time reading and enjoying time with his family outdoors. .
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date