Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


WCF and MSMQ—Take a Message

Queues provide a useful isolation layer between a service and a caller (or vice-versa) and become a place for messages waiting to be processed.

he inherent advantages to introducing queues into an application architecture are well understood. Queues, when used properly, can:
  • Increase application robustness, as clients can send messages even when services are not running.
  • Increase application scalability, because multiple service instances can be used to process messages from a single queue.
  • Improve client responsiveness, which eliminates the need for clients to wait for a response from the service.
  • Reduce decencies between client and services, because all communication is indirect via queues.
  • Ensure the durability of messages, because they can survive service and system failures.
These are just a few of the advantages. Queues have been and will continue to be an essential component of effective application architectures.

If the basic concepts of a message and a service sound familiar, it's because they happen to sync with WCF quite nicely. If you think of a message as a contract, the introduction of queues into a WCF-based design is a natural fit. Through the MsmqIntegrationBinding and NetMsmqBinding bindings, WCF has baked-in integration with Microsoft Message Queuing (MSMQ). Once again, WCF makes building applications simple. There are two scenarios in which you can use the integration between WCF and MSMQ:

  1. A WCF-client application can communicate with an existing MSMQ-based application using the MsmqIntegrationBinding binding. In essence, you can use a WCF-based client to place messages directly into an MSMQ queue. Another application can then process the message (you can call this process a service for the sake of simplicity).
  2. A WCF service or client can use an MSMQ queue as a message store via NetMsmqBinding. The WCF endpoints are unchanged. The key differentiator is that messages are placed into queues to await processing, rather than sent directly into the WCF runtime.
The first scenario is basically legacy integration, while the second is a full-on WCF solution that happens to use MSMQ. The remainder of this article explores the first scenario. The second scenario will be covered in a future article.

To explore leveraging MSMQ from a WCF client, it makes sense to start with a standard MSMQ application. Via the System.Messaging namespace, developers can use MSMQ to pass messages into queues. These messages are nothing more than serialized objects. Different applications can retrieve these serialized objects from the queue and rehydrate them for useful purposes. A typical message class might look something like this:

public class ApplicationMessage { private string _message = string.Empty; private DateTime _validUntil; public string Message { set { _message = value; } get { return _message; } } public DateTime ValidUntil { get { return _validUntil; } set { _validUntil = value; } } }

Essentially, the message class is a set of properties. No special MSMQ code is required. The class simply encapsulates a set of data that one application or component wishes to pass to another.

A client application could place an instance of this ApplicationMessage message class into an MSMQ queue using the following code:

public void SendMessage() { System.Messaging.MessageQueue queue = new MessageQueue(@".\Private$\testqueue"); ApplicationMessage msg = new ApplicationMessage(); msg.Message = "Hello World"; msg.ValidUntil = DateTime.Now; System.Messaging.MessageQueueTransaction trans = new MessageQueueTransaction(); trans.Begin(); queue.Send(msg, trans); trans.Commit(); queue.Close(); }

Figure 1. Computer Management Console: Queues can be created manually using the Computer Management Console.
The code assumes that a private, transactional queue was created on the local system. The queue can be constructed either through code or by using the Message Queueing section of the Computer Management Console (see Figure 1).

Finally, a server application could retrieve and process the message from the queue as follows:

public static void ReceiveMessage() { MessageQueue queue = new MessageQueue(@".\Private$\TestQueue"); queue.Formatter = new XmlMessageFormatter(new Type[] { typeof(ApplicationMessage) }); Message message = null; message = queue.Receive(); ApplicationMessage msg = (ApplicationMessage)message.Body; queue.Close(); //Do some actual work with the message here System.Console.WriteLine(msg.Message); System.Console.WriteLine(msg.ValidUntil); System.Console.ReadLine(); }

The code above represents a traditional MSMQ application (albeit somewhat simplified). By introducing WCF and the MsmqIntegrationBinding binding, a developer can actually create a WCF-based client application to communicate with the existing MSMQ-based server application. No changes to the service application are required. Because there is no existing WCF service endpoint, there is no way to automatically generate a proxy class. This means that you have to create the class manually. The first step is creating the contract:

[System.ServiceModel.ServiceContractAttribute(Namespace = "http://SendMessage")] public interface ISendMessage { [OperationContract(IsOneWay = true)] void SubmitMessage(MsmqMessage<ApplicationMessage> message); }

Comment and Contribute






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