We have a central server that sends and recieves messages from a number of PCs that are located on client networks in various locations. To facilitate this, currently I'm using WCF with TCPNetBindings, using duplex communication secured with certificates.

Now, we have a number of issues with this - mainly that we are being asked to support "disconnected mode" (we need to be fault tolerant). From what I know, there is no simple way to do this using the WCF stack - we'd need to implement something and perhaps use msmq. I've been looking at NServiceBus lately, and from I can see it seems to fit the bill well - fault tolerance, messages can be sent over the internet via a simple http gateway, etc. I know it's well respected in the community, and I can see why from looking into it.

So, my question is...Does employing NServiceBus sound like a sensible idea, or does anyone have any other suggestions / real world experience that relate to this? I guess I'm worried of introducing a new tech that I know relatively little about, and facing problems with things like securing it, setting everything up in a reliable way, gotchas along the way.. I'm also wary of "gold-plating" the architecture, and choosing something shiny that will end up bogging me down in implementation versus sticking with WCF and just making it work for me..


  • 1
    >support "disconnected mode" (we need to be fault tolerant) Aren't you still going to have to build a lot of the fault tolerance on the client side yourself? MSMQ's fault tolerance on the server is great for restoring state in case of a problem, but I still see that being a huge head ache on the client no matter what you chose.
    – brian
    Commented Jun 18, 2012 at 14:09
  • 1
    Well what I need to support is the "guarantee" that the client will send a message to the server and the server will get it eventually - so if we're offline we need to keep trying until we get there. That's what NSB does "for free", whereas as a WCF solution (I think) would require code.. Commented Jun 18, 2012 at 14:32
  • I agree partially with Brian. MSMQ, if configured properly in the recent versions gives you pretty good disconnected mode out of the box as long as you configure the queue and the message to behave that way. The client can persist the messages in the local outgoing queue and resend when the server is again available on a remote queue.
    – Bill
    Commented Jun 18, 2012 at 14:48
  • WCF has MSMQ bindings... I'm intimately knowledgeable of several large scale successful applications that make use of this. That said, I also like nServiceBus, but it does a different thing.
    – Kyle
    Commented Jul 18, 2012 at 16:47

2 Answers 2


My suggestion, if you need to be quick about this and only need something simple to facilitate durable (disconnected) operation with WCF, is to look in to the WCF - MSMQ bindings. If you need something in a larger environment, look at nServiceBus.

In my mind, nServiceBus would really begin to shine in a larger distributed environment. Take, for instance, the following example (that would be hell on earth with WCF but simple with nServiceBus):

  • Infrastructure made up of app server tier, cache server tier, read only database tier, read/write database tier
  • Any time the client submits a new entry, you'd really like all of these tiers updated at once
  • In WCF, you'd need to expose separate services at each tier level and have the client push to all of them (or have some central orchestration doing the same thing for you)
  • In nServiceBus you'd have each tier be a subscriber to this information, and the client would publish it once, allowing the service bus to take care of the rest

WCF has MSMQ Bindings

If you need to mostly stick with WCF, however (short timelines, need other WCF features), I'd suggest you check out this article at MSDN. It shows you how to use the WCF bindings for MSMQ, and then shows you how to migrate one service from HTTP to MSMQ. Along the way it shows you some of the problems with this scenario (and useful solutions to these problems).

Both of these suggestions make heavy use of MSMQ, so a note about that: unlike Apache MQ, RabbitMQ, and other popular queueing systems, MSMQ is not a typical broker based queue architecture, it is instead a distributed queue. This means that if your WCF client sends a message over an MSMQ transport while it cannot connect to the remote server that hosts the queue, the client machine will enqueue the message in what is referred to as an "Outgoing Queue" locally instead. The message will stay there safely until such time as the client's MSMQ service detects that it can connect to the remote MSMQ service again. At that point the message will flow from the client to the end destination.

There is at least one caveat to the above - if the remote server is offline for too long (check your documentation for MSMQ) the client will give up and move the message from outgoing to the dead letter queue. Messages transferred to the dead letter queue cannot be re-sent automatically, they must be re-constructed.

If you require encryption and don't have ActiveDirectory, on this blog entry, Sergey Sorokin details the steps necessary to encrypt communication of MSMQ using WCF without Active Directory.


They aren't a 1 for 1 replacement -- many times you'll use NServiceBus to feed messages into or take messages from a WCF endpoint.

In any case, handling disconnected mode scenarios like this is where message queues really, really shine. NServiceBus is a good place to start. There are a number of other options out there. I'll note many of them do actually wrap MSMQ at the end of the day -- MSMQ is a very solid back end and is probably worth using when it is made accessible.

  • Thanks. Point taken, although I'm seeing as a 1:1 replacement in my case because most of my WCF comms is there to support comms between these pcs and the server - nsb seems to take care of all this for me, hence it's a swap-out for me. Commented Jun 18, 2012 at 14:31
  • Gotcha, then it should work pretty well for you. Commented Jun 18, 2012 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.