Queuing in Oneway Wcf Messages Using Windows Service and SQL Server

queuing requests with WCF service

I do this currently in an application I created. A WCF service is hosted as an HTTP Service on IIS. It accepts calls, and packets of data, I take that data, validate it (tell the caller it's wrong or not) then send the data to another WCF service that is using netMSMQ binding, that service then does the final writing to the database. The good thing about this is it will queue up on one MSMQ and the WCF Service that is bound to this MSMQ pops off one message at a time and processes it. The HTTP WCF service can then handle as many requests as it wants and does not have to worry about pooled up messages as that's the job of the WCF/MSMQ-bound service. The common name for this pattern is a Bridge framework.

ETA: the second service (the MSMQ-bound WCF Service) is run as a Windows service always on. It also handles separation of concerns. The HTTP service validates and does not care about the database, the other service handles writing to the Database.

WCF and Queuing calls

This sounds like the perfect use case for a publish/subscribe service bus such as NServiceBus. Basically you dispatch a message from your website endpoint (using NServiceBus on top of MSMQ). Another endpoint makes some decisions based upon the message received from the website and then publishes the results of that decision in the form of an event to all interested subscribers.

How should I handle queuing wcf messages?

Could you possibly use MSMQ ? That's the classic message-queueing system, and it's supported by WCF.

You could receive the message from that third-party service and then just put it in the MSMQ for later processing.

As for message vs. deserialized object: both will work ok, but I think having a real .NET object is a bit easier to deal with.

Some more info:

How to: Exchange Messages with WCF Endpoints and Message Queuing Applications
WCF Sample Starter Project on CodeProject
WCF and MSMQ—Take a Message
Tom Hollander: MSMQ, WCF and IIS: Getting them to play nice

how to Store messages at client side when server goes down using wcf?

MSMQ does exactly what your first sentence says - when you send an MSMQ message, if it can't get the remote queue then it stays with the client and the built-in MSMQ service retries in the background. That way your message, once sent, is "safe." It's going to reach its destination if at all possible. (If you have a massive message volume and messages need to be stored for a long time then storage capacity can be an issue, but that's very, very unlikely.)

Configure WCF to send/receive MSMQ messages

I'd only do this if it's necessary. It involves modifying both the service and the client, and the documentation isn't too friendly.

Here's the documentation for MsmqBinding. Steps 3 and 4 for configuring the WCF service are blank. That's not helpful! When I selected the .NET 4.0 documentation those details are filled in.

I looked at several tutorials, and if I was going to look at this I'd start with this one. I find that a lot of tutorials muddy concepts by explaining too many things at once and including unnecessary information about other parts of the writers' projects.

The client queues its messages locally

If you don't to make lots of modifications to your service to support MsmqBinding. You could just implement the queuing locally. If the WCF service is down, the client puts the message in a local MSMQ queue and then at intervals reads the messages back from that queue and tries sending to the WCF service again. (If the WCF service is still down, put the message back in the queue.)

I'd just send messages straight to the queue and have another process dequeue and send to WCF. That way the client itself just "fires and forgets" if that's okay.

That way you don't have to deal with the hassle of modifying your service, but you still get the benefit. If your message can't go to the WCF service then it goes someplace "safe" where it can even survive the client app terminating or the computer restarting.

Sending and receiving messages in a local queue is much easier to configure. Your client can check to see if the queues exist and create them if needed. This is much easier to work with and the code samples are much more complete and on-point.

MSMQ vs. SQL Server Service Broker

I have used both, in different situations, equally well. My preference is really pretty basic: use SQL Service Broker if message sending event is triggered from a database event; Use message queue if event is in code. That preference is based just that it easier to setup on the same platform that will trigger the event.