May CTP of Service Bus introduced tons of new messaging capabilities including Queuing and Topic based pub/sub messaging. Check out Clemens post for an overview.

The usage of Service Bus messaging entities (Queues, Topics) is divided across two namespaces – a ‘Management Namespace’ and a ‘Runtime Namespace’. Management namespace is used to create/define messaging entities while the Runtime Namespace is used to do the actual messaging operations using the already defined ‘messaging entities’. The management namespace is exposed using as a REST service and Service Bus SDK also provides with a client library which hides the HTTP based interface behind a nice object oriented API.

So once a messaging entity (for example a Queue) is created and is ready you can use the Runtime API to send/receive messages. May CTP comes with two flavours of runtime APIs.

  • A low level MessagingFactory based API: Which is the native, high fidelity Service Bus API exposing all the Service Bus messaging features.
  • A higher level WCF binding: Which internally uses the MessagingFactory API and integrates the Service Bus messaging with WCF programing model.

There are already few blogs posts which talks about the MessagingFactory API so I’m not going to repeat that here. Let’s see how can I use Service Bus queues a communication mechanism between my WCF client & service. I’ll start with creating a usual one-way service as you would do for MSMQ or any other queuing technology.

    [ServiceContract]
    public interface IHelloService
    {
        [OperationContract(IsOneWay = true)]
        void SayHello(string input);
    }

    public class HelloService : IHelloService
    {
        public void SayHello(string input)
        {
            Console.WriteLine("Says: " + input);
        }
    }

 

Following snippet create a queue (line 6) using the management API. I’m using the wrapper class provided with the SDK for the REST based management service.

I then create a binding instance and specify ACS credentials on it. All the operations on Service Bus requires a valid token from ACS and these credentials would be used to acquire an ACS token for SB operations.

Finally I added an endpoint specifying the queue location as the endpoint address.

  1. static void Main(string[] args)
  2. {
  3.     const string baseAddress = "sb://soundbyte.servicebus.appfabriclabs.com";
  4.     var credential = TransportClientCredentialBase.CreateSharedSecretCredential("owner",
  5.                                                                                 "zYDbQ2wM1k7J32323232323VdbBukWJTF6Y=");
  6.     CreateQueue(baseAddress, credential,"q1");
  7.  
  8.     var serviceBusBinding = new ServiceBusMessagingBinding();
  9.     serviceBusBinding.MessagingFactorySettings.Credential = credential;
  10.  
  11.     var sh = new ServiceHost(typeof (HelloService));
  12.     sh.AddServiceEndpoint(typeof (IHelloService), serviceBusBinding, baseAddress + "/q1");
  13.     sh.Open();
  14.  
  15.  
  16.  
  17.     Console.WriteLine("Host ready...");
  18.  
  19.     var cf = new ChannelFactory<IHelloService>(serviceBusBinding, baseAddress + "/q1");
  20.     var proxy = cf.CreateChannel();
  21.     for (int i = 0; i < 10; i++)
  22.     {
  23.         proxy.SayHello("Hi " + i);
  24.     }
  25.  
  26.     Console.ReadLine();
  27. }

 

My client is a standard WCF proxy (line 19-23) which is sending messages to the same endpoint address (queue location) using the same ServiceBus binding.

The above produces following expected output. Easy isn’t it?

image

By integrating Service Bus messaging with WCF programing model, we can reuse all of the WCF goodness with Service bus messaging. For example I can secure messages while they are traveling through queues/topics by just changing the binding.

Next time I’ll show how to do pub/sub using the WCF programing model.