Service Bus, Event Hubs, and Web Sockets


We make some good stuff in the Azure Service Bus team and we tend to make it fairly quickly (both as it operates and as we iterate). For both Messaging (Queues & Topics) and Event Hubs we favor the AMQP protocol because the performance it gives us - including things like flow control and a reusable channel. We do support HTTP for most functionality - but not all. We get a lot of asks for HTTP, but as we dig deeper what we often find is that people want to use an HTTP transport, but not REST itself. People like our .NET client and so do I - it's got some great features. Ultimately what people normally want is to not have to change their firewalls to accommodate the standard AMQP ports. Makes sense.

As a result we've lately had quite a few request for Web Sockets. If you're not familiar with those checkout that link. Cool info. The takeaway is that networks see these connections as an HTTP request and let them through and then the connection is upgraded to a two way TCP channel.

Yesterday someone asked about using Event Hubs from HTTP and this lead to they why question and when I got to the base of it the real ask was for Web Sockets. Well - it must be grant a wish Friday because we actually already implemented that.

When using the Service Bus .NET client simple make one call before opening any connections to Service Bus:

ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;

This will channel all AMQP connections, the default for Service Bus, over Web Sockets. This setting is in the Microsoft.ServiceBus namespace.

Enjoy!

Comments (4)
  1. Anonymous says:

    this is great, but what we really need is a way to work with these things over HTTP directly, without the need for any dot net client. Just think that we need to exchange data with an event hub from a mobile device, so the code needs to work from let's say a PCL library where such client is not available. Now imagine needing to use Xamarin so we can get such code to run from let's say an Android device.

    Does this put things into a new light ?

    To be fair I managed to do quite a lot with HTTP even though the documentation is pretty scarce. What I haven't figured out yet is how to write a subscriber for a topic.

  2. Anonymous says:

    man so much reinventing the wheel. AMQP prevents all of this. It really boggles my mind how much people want to waste time, effort, and money to create custom clients for random http messages over and over again.

  3. paolopat says:

    Andrei, there is the Azure SB Lite project (azuresblite.codeplex.com) that is based on the great portable library AMQP Net Lite (amqpnetlite.codeplex.com) that is able to work with almost all the platforms you me mentioned and use AMQP protocol. With Azure SB Lite you have same API of official SDK.

    AMQP protocol is always preferred for performance reasons.

  4. If I were using Android or iOS I would use Apache Qpid or Proton to communicate with Service Bus. Both work and the performance will be much better than HTTP. If you must use HTTP - it's better for send that for receive.

Comments are closed.

Skip to main content