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
 

Create a Durable and Reliable WCF Service with MSMQ 4.0 : Page 4

Developers have to ensure that their Windows Communication Foundation (WCF) endpoints are durable and reliable, because transactions depend on them. Learn how to bullet proof your WCF services with MSMQ 4.0.


advertisement
MSMQ 4.0 Specifics and Transaction Scope
The following are the binding properties of NetMsmqBinding:

<netMsmqBinding> <binding name="OrderServiceMsmqBinding" durable="true" exactlyOnce="true" maxReceivedMessageSize="2147483647" maxRetryCycles="1" receiveErrorHandling="Drop" receiveRetryCount="20" retryCycleDelay="00:05:00" useMsmqTracing="true"> <readerQuotas maxStringContentLength="2147483647" /> </netMsmqBinding>

  • Transactional Remote Receive. Consider a scenario when a message has been read from a queue, and an error occurs when processing the message (e.g., write to the database fails). This is where the transactional remote receive feature comes in. Transactional remote receive enables a message to be put back on the queue within the same transaction if an error occurs during processing. MSMQ 4 supports it out of the box; previous versions don't. In order to benefit from this feature, make sure the Allow Inbound and Allow Outbound options are turned on when installing DTC.
  • Controlling the number of times the queue is read on error. When errors happen, you want the service to automatically retry. This feature is controlled with the receiveRetryCount property of the netMsmq.
  • Order. Order is not guaranteed for the message processing, so you may have messages being processed in any order.
  • Deliver Once. If the message has to be delivered only once, then the exactlyOnce property has to be set to true.



Figure 9 shows a sequence of how the transaction flows through the MSMQ WCF stack.

Click to enlarge

Figure 9. Transaction Flow Through the MSMQ WCF Stack:
Here is a sequence of how the transaction flows through the MSMQ WCF stack.

The code sample in the following listing shows how to commit the transaction:

using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required)) { //process whatever needs to be done scope.Complete(); } else { }

The scope here is required, as the transaction has already started in the messaging server.

Providing Failover and Guaranteeing Delivery
If you take a look back at Figure 1, a number of things can fail—for which you will need to test:

  • The MSMQ cluster node dies. This scenario should never happen unless all the hardware on Node A and B completely melts down. The Gateway Service or the Order Service may be trying to write to the queue. If a failure is detected, WCF automatically writes it to a local queue. Hence, you will have to install a MSMQ service on the service hosting the gateway and the order service.
  • The gateway service dies. This is an acceptable scenario. It may happen only if the service is a single instance or if the load balancer dies on a web farm. This is okay because the client that is trying to place the order will get an immediate response. An analogy to this is not being able to give a FedEx package to the courier.
  • The order service dies. The queue server keeps trying to deliver the message as soon as the service comes back. If it never comes back, it writes it to the dead letter queue.
  • One of the nodes on the cluster dies. Because the queue is physically being persisted to a SAN or a NAS (Network Attached Storage), the other node should automatically perform the failover.
  • The database or some other external dependency is down. The Order Service is trying to process the message (e.g., write to the database) and the database is down. In this case, the transaction scope is rolled back and the message is put back on the queue.

Testing becomes a very complicated effort for a set up like this, but it is lots of fun. The scenarios above are hard to test but become necessary to make sure the infrastructure is working. Once built, tested, and deployed, an infrastructure like this will provide the durable and reliable services critical to many types of enterprise services today.



Vibhu Srinivasan is an Architect and Agile coach working in Seattle. He coaches teams on developing systems with .NET, Java, and Agile technique. He has 12+ years of enterprise software development experience building large-scale systems and he recently has been a chief architect for an online gaming infrastructure initiative.
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