Should I swap from WCF to NserviceBus

communicationnetwcf

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..

Thanks!

Best Answer

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.

Related Topic