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

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


WCF and MSMQ—Take a Message : Page 2

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.




Application Security Testing: An Integral Part of DevOps

The Service Contract

The service contract for communicating with a MSMQ-hosted queue contains only a single send operation. This is a limitation specific to the MsmqIntegrationBinding binding. The single submit operation takes an MsmqMessage initialized with the type ApplicationMessage, which is the message class you created earlier. Also notice that the contract is set to one-way, indicating that no output message is expected. It is worth noting at this point that MsmqIntegrationBinding does not support message-level security. This makes sense because the MSMQ-based service, not being WCF or SOAP aware, would have no way to interpret the necessary information for message-based security. Transport-level security is supported.

After the contract is created, you can write WCF code directly, open a channel, and submit a message:

MsmqIntegrationBinding binding = new MsmqIntegrationBinding(); binding.Security.Mode = MsmqIntegrationSecurityMode.None; EndpointAddress address = new EndpointAddress(@"msmq.formatname:DIRECT=OS:.\private$\TestQueue"); ChannelFactory<ISendMessage> channelFactory = new ChannelFactory<ISendMessage>(binding, address); ISendMessage channel = channelFactory.CreateChannel(); ApplicationMessage message = new ApplicationMessage(); message.Message = "Hello from WCF!"; message.ValidUntil = DateTime.Now; MsmqMessage<ApplicationMessage> msmqMsg = new MsmqMessage<ApplicationMessage>(message); using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required)) { channel.SubmitMessage(msmqMsg); scope.Complete(); }

As expected, the MsmqIntegrationBinding is used. Take special note of the format used for the endpoint address. This is what actually points WCF to the proper queue. Much like in the legacy MSMQ client, a new MsmqMessage is initialized with your ApplicationMessage message class. The key difference is that instead of using an MsmqTransaction, a System.Transactions.TransactionScope is used. You must use a transaction because the queue is transactional. By default, MsmqIntegrationBinding sets TransactionScopeRequired and TransactionAutoComplete to true. There is an alternative to the abundance of WCF client code. A service client that extends ClientBase can be created and the WCF settings can be moved into the configuration file:

public class SendMessageClient : System.ServiceModel.ClientBase<ISendMessage>, ISendMessage { public void SubmitMessage(MsmqMessage<ApplicationMessage> message) { base.Channel.SubmitMessage(message); } public void SubmitMessage(ApplicationMessage message) { MsmqMessage<ApplicationMessage> msmqMsg = new MsmqMessage<ApplicationMessage>(message); SubmitMessage(msmqMsg); } }

Notice the additional overload of SubmitMessage. This new overload, while not required, allows the caller to use the WCF/MSMQ service without having to actually construct a MsmqMessage, further isolating it from the specific implementation details. The caller simply needs to instantiate an ApplicationMessage and the WCF client handles packaging it up into a MsmqMessage. The caller need never know that the ultimate destination for the message is a MSMQ queue.

The final step when extending ClientBase is moving the configuration out of code and into the application configuration file (see Listing 1).

Depending on the needs of the developer, either method (code or configuration based) can be used to create the WCF client. The MSMQ-based service application requires no changes. The advantage to this approach is that the client application is completely isolated from the details of the service. It has knowledge only of the contract. If, at some point, the MSMQ-based service were to be replaced with a WCF-based service, only the WCF-client configuration would need to change. The client application itself would remain the same. At this point, you have successfully isolated the things that change from the things that do not.

The next article in the series will explore how the MSMQ-based service created here can be transformed into a WCF-based service that uses queues.

Steve Stefanovich has spent over a decade with RDA Corporation as a developer and principal architect focusing on custom application development using Microsoft .Net and SharePoint technologies. Steve is a frequent contributor to RDA's Architecture and Collaboration blogs.
Comment and Contribute






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



By using this site, you agree to the Privacy Policy
Thanks for your registration, follow us on our social networks to keep up-to-date