My company is investigating using a service bus. Currently we have running prototypes of NServiceBus and Microsoft Service Bus (on premise).

I'm quite happy with the pub-sub and topic messaging capabilities the bus provides but I'm getting lost in one of the requirements they are referring to.

For example: They want to query the service bus and "GetAccountInformation()" and expect a result back ala WCF service style and expect the bus to answer them sufficiently to display the result in a UI.

Now, with the above I mentioned the following :

  1. The bus cannot be used for querying as the inherit pattern involves a "high latency" as we cannot be guaranteed that any subscriber would be listening at that point.
  2. It sounds like they want to use the bus as a "hub" for all communications. To me that's sounds like they need WCF relays.

To complicate matters, the reason why they are looking into it, we need to be able deliver messages to (and query from) geographically dispersed sites some of which has absolute horrible connectivity issues. So, for this case messaging fits.

Also, all different sites have numerous WCF Soap and Web API services.

How to achieve this?


1 Answer 1


You may be conflating Reliable Messaging, Service Buses, and Pub-Sub. That's not too uncommon as they often get discussed together and I've yet to find a good definition for a Service Bus.

First, let's start with what seems to be the motivator in your situation: Connectivity issues.

In cases where connection reliability is bad but you need 100% reliable communication (and you're willing to sacrifice synchronous communication) you can resort to using Reliable Messaging technologies. A few I've looked into are MSMQ and RabbitMQ.

When you're simply publishing messages and you don't care about a response then this kind of asynchronous communication is useful.

Second, your question about Querying. Although your Service Bus may use Reliable protocols, that's not the main benefit of the Service Bus. I may be wrong here, because I've found many conflicting definitions of what SB are, but my understanding is as follows:

A Service Bus is a middleware system that acts as an abstraction layer for your inter-system communication. Instead of System A knowing about System B and it's communication protocols all System A needs to know about is the Service Bus.

Your Service Bus should expose all your System Services in an easy to use and system gnostic fashion. This ensures loose coupling between the systems in your network.

That said, your Service Bus should be able to offer you synchronous communication. So, your call to GetAccountInformation() would be just a regular webservice query.

Finally, I can't promise you if this is a recommended way of doing things, but in my last workplace we combined Reliable Message, Service Buses, and Pub-Sub in the following way:

  • We had a Service Bus acting as an abstraction layer around many of our system webservices.
  • The Service Bus also exposed a Messaging Service.
  • Whenever an application needed to Publish a message to the world it would do so by calling the Service Bus' Messaging Service.
    • Because it was absolutely vital that none of these messages got lost the communication to the Messaging Service was done using a Reliable Messaging Queue.
  • Our Service Bus was aware of all the Message (topic) Subscriptions and dutifully notified all the downstream systems (again, using a Reliable Messaging Queue)

Hopefully this helps... though I can't guarantee we didn't get it completely backwards!

  • "system gnostic" hmm mentioning loose coupling rather suggests "agnostic", do I miss something here?
    – gnat
    Apr 24, 2014 at 19:33
  • I'm not sure I follow. Can you expand?
    – MetaFight
    Apr 24, 2014 at 22:54
  • I was merely interested if "system gnostic" is a typo or not - if it is just what you intended to write, don't worry
    – gnat
    Apr 25, 2014 at 4:06
  • 1
    It wasn't a typo. I've seen many legacy systems expose webservices which, in turn, expose some of their internal types. So, if you have a system in charge of managing boat parts, the Part entity would be exposed via the SOAP webservice. This creates tight coupling between the service and the consumer. The Service Bus can loosen this coupling by re-exposing the service, but with a system-agnostic contract. So, if I decide to replace my Boat Part system down the road I won't need to update all the consumers of the webservice accordingly. I'll just need to write an adapter layer...
    – MetaFight
    Apr 25, 2014 at 9:48
  • ...between my new Boat Part system and the Service Bus.
    – MetaFight
    Apr 25, 2014 at 9:48

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.