All about Azure Service Bus -messaging services

  • [アーティクル]

Recently I had a chance to read about various Azure Application Services(Messaging) like Azure Queues, Azure Service Bus – Queues, Topics, Relay, Event Hub and Notification hubs.

I was curious to know “what is all this” from an Architect’s perspective. As a dev, one can start quickly with samples from official documentation. But I was trying to understand when to use what – key differentiator and competitor offerings etc.. I have tried few samples some time back but never bothered to compare and learn. Coming to documentation, I have to appreciate our Azure content team for their excellent documentation and easy information dissemination. Learning path(diagrams) is something which is easy to follow and understand the contents in high level. DISQUS comment integration also add's lot of value to the reader – one can interact with the author,fellow reader and also report any issues. Kudos guys.

One can consume these service/offerings from Azure management portal as below. You may not find them in preview portal as of now – but you will be redirected if they have not supported yet.

      clip_image002

For majority of these service, Microsoft.ServiceBus.dll is the important assembly to refer. You can get it from Nuget easily by simply running the below command in your Visual Studio > Tools > Nuget Package Manager >Package Manager Console. You should have corresponding project created say Console application and then run this. You would notice the relevant assemblies added behind the scene automatically downloaded from net. For detailed assembly reference please check this link - Service Bus .NET

PM> Install-Package WindowsAzure.ServiceBus

Let us start checking one by one..

1) Service Bus Queues 

  • if you’ve worked earlier with MSMQ, then this is the same except the message is stored in/read from Cloud with features like Auto scale, backup etc.
  • offers one-directional – FIFO communication; designed to read sequentially. We just insert them-> process and delete. (1 MESSAGE : 1 READ/RECIEVER)
  • a sender sends a message to a <Service Bus queue> and a receiver picks up that message at some later time/offline processing
  • message can be sent from ‘n’ senders but picked by one receiver(1 message/receiver). For multicast service – we should consider "Topics”(below) instead Queue
  • message has two parts: a set of properties, each a key/value pair, and a binary message body. It can be considered for implementing state machine.

 

          clip_image004

2) Service Bus Topics 

  • similar in many ways to a queue, provides one-directional communication using subscriptions-a single topic can have multiple subscriptions; use a filter to receive only messages matching the declared criteria.
  • big difference is that topics let each receiving application create its own subscription by defining a filter.
  • Ex: In the below pic, Sub1 using a filter Seller =“AVA” receives only such matching message. Single message sent to a topic can be received by multiple subscribers ( ( ONETOPICS CAN HAVE MANY RECIEVERS )
  • this publish and subscribe model can considered for multiple app interested in the same messages.

 

          clip_image006

· 3) Relays

  • provides bi-directional communication, doesn't store in-flight messages, it just passes them on to the destination application.
  • each application establishes an outbound TCP connection with Service Bus, then keeps it open.
  • to use Service Bus relays, applications rely on WCF. Service Bus provides WCF bindings that make it straightforward for win applications to communicate with relays.
  • it is perfect for enabling communication between different application over cloud to an on premise datacenter.
  • it gets deleted when the connection goes off or closing the host
  • mainly recommended for exposing WCF from a corporate n/w to public cloud without opening firewall connection.

          clip_image008

Service Bus messaging is a brokered communication mechanism. Similar to a postal service in the physical world. The messaging service ensures that the information is delivered even if the two parties are never both online at the same time. Service Bus supports two distinct messaging patterns: relayed messaging and brokered messaging. Earlier one provides many benefits, but requires both to be online at the same time in order to send and receive messages. In contrast to the relayed messaging scheme, brokered messaging can be thought of as asynchronous, or "temporally decoupled.” – both parties do not have to be online at the same time. 

4) Event Hubs 

  • highly scalable publish-subscribe event ingestor that can asynchronously intake millions of events per second. It act as a "front door" for an event pipeline, often called an event ingestor.
  • supports HTTP POST or via an AMQP 1.0
  • best suits for processing and analyzing the massive amounts of data produced by IOT devices or any other connected apps
  • some real world scenarios:
  • IOT devices sending thousands of message/second which is processed, stored and displayed in live dashboard’s,
  • behavior tracking in mobile apps or traffic information from web farms, or data collected from machines or vehicles

            clip_image010

Let us see how easy to create a WCF Relay(this blog sample-download here) - referred from this blog here.

=================================================

Interface:

[ServiceContract(Namespace = "urn:ps")]

interface IProblemSolver{

[OperationContract]

int AddNumbers(int a, int b);

}

interface IProblemSolverChannel : IProblemSolver, IClientChannel { }

Server:

========

static void Main(string[] args) {

var cf = new ChannelFactory<IProblemSolverChannel>(new NetTcpRelayBinding(),

new EndpointAddress(ServiceBusEnvironment.CreateServiceUri("sb", "HelloWCFServiceThroughAzure", "solver")));

cf.Endpoint.Behaviors.Add(new TransportClientEndpointBehavior {

TokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider("RootManageSharedAccessKey", "yourkey")

});

Console.WriteLine("Azure Service Relay Client- Started ");

using (var ch = cf.CreateChannel()) {

Console.WriteLine(ch.AddNumbers(4, 5));

}

Console.ForegroundColor = ConsoleColor.Yellow;

Console.WriteLine("Azure Service Relay Client- Finished Reading. ENTER to close the client");

Console.ReadLine();

}

class ProblemSolver : IProblemSolver {

public int AddNumbers(int a, int b) {return a + b; }

}

Client:

=======

static void Main(string[] args) {

var cf = new ChannelFactory<IProblemSolverChannel>(new NetTcpRelayBinding(),

new EndpointAddress(ServiceBusEnvironment.CreateServiceUri("sb", "HelloWCFServiceThroughAzure", "solver")));

cf.Endpoint.Behaviors.Add(new TransportClientEndpointBehavior {

TokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider("RootManageSharedAccessKey", "yourkey")

});

Console.WriteLine("Azure Service Relay Client- Started ");

using (var ch = cf.CreateChannel()) {

Console.WriteLine(ch.AddNumbers(4, 5));

}

Console.ForegroundColor = ConsoleColor.Yellow;

Console.WriteLine("Azure Service Relay Client- Finished Reading. ENTER to close the client");

Console.ReadLine();

}

Output:

=======

Both are console application, required nuget assemblies(service bus assemblies) installed. Run the server application first which will create the relay name in the Azure Portal. Once after the name, you can your client application. When you stop the server, then the relay gets deleted automatically. 

In Action:

==========

clip_image012

Links to start : https://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-queues/

See you next time with various cloud patterns associated with messaging..

//happy messaging