How does one deliver messages to (and query from) sites with possibly bad connectivity, having numerous WCF Soap and Web API services?

Question

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?

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!