Service Bus Topic – How we can migrate from Service Bus Queue

Yesterday we saw different methods that give us the ability to communicate with Service Bus Topics and all spin around the HTTP/S.
Today we will reach a more sensible topic. How we can write a client and a server that at begging use Service Bus Queues and after a while be begin use Service Bus Topics. We want to achieve this with a minimal effort time. Also when the transition is done from queues to topics we want minimal changes in our code.
I think that we already observed that this two services are very similar. The API are almost the same, not only this, but also the message that is send and received from the services has the same time, BrokeredMessages. Until now, on all examples we used QueueClient and TopicClient classes to communicate with queues and topics. This is very good; those are the basic classes that should be used for normal situation. But if we look in these two classes we will discover a powerful property named “InternalSender”.
This class returns a “MessageSender” object. We have a similar way to get “MessageReceiver”. These are the base classes used by the framework to send and receive messages to and from Service Bus. We can imagine the QuequeClient and TopicClient as wrappers classes over two base classes that can make our life easier.
Using this two base class we will not need to know if we use a queue or a topic. These classes are configured based on a URL that can target a queue or a topic.
Before looking over the examples please check my last post where I presented how does a URL of a topic (subscription) or queue looks like. To have easier life, Windows Azure has a helper class available to use that help us to generate the URLs for topics and queues. But if you want to write them from scratch it will work without any problem.
First step is to create the base service URL (it starts with sb:// and contain the namespace of our service). This namespace is a generic namespace; don’t specify that the URL represent a queue or a topic.

Uri serviceAddress = ServiceBusEnvironment.CreateServiceUri("sb", “myFooNamspace”, string.Empty);

The last parameter represents the service path. Out of the box we don’t need to specify any value to this parameter. After this step, MessagingFactory class will help us to create URL where we include our credentials also:

MessagingFactory messagingFactory  = MessagingFactory.Create(serviceAddress, credentials);

Based on this MessagingFactory we can create MessagingReceiver and MessagingSender on the fly based on the entity path.

MessageReceiver qmr = messagingFactory.CreateMessageReceiver(“myFooQueueName”);
MessageReceiver tmr = messagingFactory.CreateMessageReceiver(“myFooTopic/subscriptions/subscriptionName1”);
MessageSender qms = MemessagingFactory.CreateMessageSender(“myFooQueueName”);
MessageSender fms = messagingFactory.CreateMessageSender (“myFooTopic”);

As you can see for the subscriptions of a topic we need to specify also the subscription name. But for the sender we don’t need to do something like this. Or course we have some helper methods like CreateTopicClient, CreateQueueClient, CreateTopicSubscription and so on, but this will not help us to make the code to be more easily ported from Service Bus Queues to Service Bus Topics.
The MessageSender and MessageReceiver classes have method as Send, Receive and all the methods that we can find in the QueueClient and TopicClient. Using this we can do the same thing. When the time will come to migrate from queue to client the only thing that we will need to do is to change the paths that specify the queues and topics.
Here you can find all the code that we need to communicate with a queue (or topic):

Uri serviceAddress = ServiceBusEnvironment.CreateServiceUri("sb", “myFooNamspace”, string.Empty);
MessagingFactory messagingFactory  = MessagingFactory.Create(serviceAddress, credentials);
MessageReceiver qmr = messagingFactory.CreateMessageReceiver(“myFooQueueName”);
BrokeredMesssage brokeredMesssage = new BrokeredMessage();
…
qmd.Send(brokeredMesssage);

Simple, clean and smart. This is what I like at this implementation. The code remains simple and easy to understand in this way also. In this way we can migrate from queues to topics and back to the queues only by changing the configuration file.

Read More

Service Bus Topic - Different ways to create and manage it

In the last post, we saw how easily we can integrate Service Bus Topic with WCF. Today topic is simple. There are times when we need to create topics and subscriptions that are valid for one day or two. Not only this, this task can sometimes be done by various persons of applications. Let’s see what our options are.
Of course the most powerful tool is the code. From code we can create topics, subscriptions and configure them in any way we want. When we create a topic we can set the default TTL value of messages that will be send to the topic, but we will not be able to set a property that specify the TTL of the topic (delete after 2 days for example). But, beside this we can set others values like the maximum size of the topic, enable or disable the batch operations and if the message duplication detection is activated. Similar configurations can be made to a subscription using SubscriptionDescription.

TopicDescription topicDescription = new TopicDescription()
{
 RequiresDuplicateDetection = true;
}

In this moment we cannot specify from configuration file (or any kind of XML) a new topic or a new subscription or to reconfigure one of them. If we need something like this we can very easily create a small application for this purpose.
The last way to create topics and subscriptions is from Windows Azure portal. This can be created from the portal using only the mouse. All the main properties can be configures from here. We need to go the Service Bus tab. In this tab we will have buttons than give us the ability to create topics and subscriptions. The only limitation is on subscriptions, we cannot create filters and actions for them. Because of this a subscription created from the portal will receive all the messages.

Another way to create them (that I don’t enjoy) is by HTTP requests. Yes, using simple HTTP request we can create and manage Service Bus. The assembly that we use from the code to create a topic is only a wrapper over HTTP requests. Because the topic is quite complex, please find more information about this in the following link: http://msdn.microsoft.com/en-us/library/windowsazure/hh780752.aspx
We saw that we can create and manager topics in various ways. Because all the commands can be executed over HTTP/HTTPS we can create any configuration tool (and also use Service Bus) from any language and platform. This can be great when we want to integrate it in a big and old system that is written in Perl or from COBOL (that use a library like Libcurl).

Read More

Service Bus Topics - Using with WCF services

If in my last post I talked a little about the limitations of Service Bus Topics, I think that this is the moment to see one of the greatest features of this service. Service Bus Topics has a lot in common with Service Bus Queues. In one of my posts I describe how we can integrate WCF with Service Bus Queues, but this can be done with Service Bus Topics as well.
In a large system, we have a lot of services that communicate between them and there are cases when a WCF service do more than one thing because the endpoint of that WCF service is the entry point and this is the only way how we can ensure that a couple of actions are executed when the services is called by a specific client. Because of this is not very easy to add, remove some behaviors to an endpoint and also the load balancing in this case can be nightmare.
Using WCF services exposed using Service Bus Topics can be our solution. Very easily a client can call a service that is only a façade to more than one service. Based on subscribers’ filters we can specify what messages to be received by our service.
The step that needs to be done to integrate Service Bus Topics in our WCF services is very simple. Basically we need to change only the configuration files. I will start from scratch, creating the WCF service also.
The first step is to create the Service Bus namespace from Windows Azure portal, if we don’t have already a namespace created. Topics can create in different way using Windows Azure portal (we cannot add filters to subscriber, from configuration files and from code.

var namespaceManager =
    NamespaceManager
        .CreateFromConnectionString(CloudConfigurationManager.GetSetting("ServiceBusConnectionString"));

if (!namespaceManager.TopicExists("myFooTopic"))
{
    namespaceManager.CreateTopic("myFooTopic");
}

namespaceManager.CreateSubscription(
    "myFooTopic1",
    "retriveAllMessagesSubscriber");
namespaceManager.CreateSubscription(   
    "myFooTopic2",
    "valueIs10Subscriber",
    new SqlFilter("Id > 2000"));

We create a topic named “myFooTopic” and two subscribers “myFooTopic1” and “myFooTopic2”. The second one has a filter. Next we defined the service contract, data contract and the implementation of our WCF service.

[ ServiceContract ]
public interface ICarService
{
    [ OperationContract ( IsOneWay = true ) ]
    void Open(Car car);
    void Close(Car car)
}

[ DataContract ]
public class Car
{
    [ DataMember ]
    public int Id { get; set; }
  
    [ DataMember ]
    public string Number { get; set; }  
}
public class CarService : ICarService
{
    public void Open(Car car)
    {
        ...
    }
  
    public void Close(Car car)
    {
        ...
    }
}

We have two services, because of this I will write a second implementation of our service. The two services don’t need to be hosted on the same server or to know one each other. All the magic is made by the Service Bus Topics from the configuration file.

public class CarService2 : ICarService
{
    public void Open(Car car)
    {
        ...
    }
  
    public void Close(Car car)
    {
        ...
    }
}

In the configuration file of our services we need to add a new binding extension named “netMessagingBinding”. This binding will be used when we specify the endpoint, where we will need to specify the address of our topic and the subscription address.
Both address are simple and have the following format:

• sb://[serviceBusNamespace].servicebus.windows.net/[topicName] – topic address
• sb:// [serviceBusNamespace].servicebus.windows.net/[topicName]/subscriptions/[subscriptionName] – subscription address

The endpoint configuration will contain our secret key that I used for authentication. The configuration file for our first service would look something like this:

 <system.serviceModel>
    <extensions>
      <bindingElementExtensions>
        <add name="netMessagingTransport" type="Microsoft.ServiceBus.Messaging.Configuration.NetMessagingTransportExtensionElement, Microsoft.ServiceBus"/>
      </bindingElementExtensions>
      <bindingExtensions>
        <add name="netMessagingBinding" type="Microsoft.ServiceBus.Messaging.Configuration.NetMessagingBindingCollectionElement, Microsoft.ServiceBus"/>
      </bindingExtensions>
      <behaviorExtensions>
        <add name="transportClientEndpointBehavior" type="Microsoft.ServiceBus.Configuration.TransportClientEndpointBehaviorElement, Microsoft.ServiceBus"/>
      </behaviorExtensions>
    </extensions>
    <behaviors>
       <endpointBehaviors>
        <behavior name="myBehavior">
          <transportClientEndpointBehavior>
            <tokenProvider>
              <sharedSecret issuerName="[accountOwner]" issuerSecret="[secretKey]" />
            </tokenProvider>
          </transportClientEndpointBehavior>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <bindings>
      <netMessagingBinding>
        <binding name="queueBinding" closeTimeout="00:10:00" openTimeout="00:10:00"
               receiveTimeout="00:10:00" sendTimeout="00:10:00" sessionIdleTimeout="00:01:00"
               prefetchCount="-1">
          <transportSettings batchFlushInterval="00:00:05" />
        </binding>
      </netMessagingBinding>
    </bindings>
    <services>
  <service name="Demo.CarService">
        <endpoint name="CarService"
                  address="sb://myNamespace.servicebus.windows.net/myFooTopic"
          listenUri="sb://myNamespace.servicebus.windows.net/myFooTopic/subscriptions/retriveAllMessagesSubscriber"
                  binding="netMessagingBinding"
                  bindingConfiguration=" queueBinding "
                  contract="Demo.ICarService"
                  behaviorConfiguration="myBehavior" />
      </service>
    </services>
  </system.serviceModel>

As you can see it is almost identical with the configuration that we done to our WCF service that was integrated with Service Bus Queue. We only need to specify the subscription address in our configuration. The good part of all this is that we don’t need to change the code at all. Because of this any WCF service can be upgraded to Service Bus Topics.
When we specify the client we will do the same thing. The difference is in the client node of the configuration. When we need to specify the endpoint we will need to specify the address of the topic. In comparison with the service configuration we don’t have to specify the listenUri, because the message added to the topic will be send to all subscribers.
In the end what we should remember when we need to change a WCF service to use Service Bus Topics:

• The client point to the topic address (URL)
• The server contains not only the topic address but also the subscription address
• The differences two different services that point to the same topic is the subscription
• The properties of data contract can be accessed from subscription filters as a BrokeredMessage property

The service can have as many endpoints we want
In conclusion Service Bus Topics can be very easy integrated to our WCF service without changing our code. It is a powerful feature that can help us in large applications.

Read More

Java Script code refactoring - hands on code

Let's see how we can create a mechanism that based on some flags; it will able to determine the status of some objects. The first version of code would look like this:

ItemStatus = {
    Status1: "Status1",
    Status2: "Status2",
    Status3: "Status3"
}();

ItemTypes = {
    Item1: "Item1",
    Item2: "Item2",
    Item3: "Item 3"
}();

var ItemConfiguration = function () {

    function ItemConfiguration() {

    }

    ItemConfiguration.prototype = function () {
        getItemConfiguration: function (itemTypes, flag1, flag2, flag3, flag4) {
            switch (itemTypes) {
                case ItemTypes.Item1:
                    if (flag1 && flag2) {
                        return ItemStatus.Status1;
                    } else if (flag3 || flag4) {
                        return ItemStatus.Status2;
                    }
                    break;
                case ItemTypes.Item2:
                    if (flag3 || flag2) {
                        return ItemStatus.Status3;
                    } else if (flag1 || flag2) {
                        return ItemStatus.Status1;
                    }
                    break;
                case ItemTypes.Item3:
                    if (flag3 || flag1 && flag3) {
                        return ItemStatus.Status1;
                    } else if (flag2 && flag4) {
                        return ItemStatus.Status3;
                    }
                    break;
            }
        }
    };
   
    return ItemConfiguration;
} ();

First problem is related to default values. If the flags combination from switch doesn’t return any value, that we should notify one way or another user about this issues. We end up throwing an expectation.

var ItemConfiguration = function () {

    function ItemConfiguration() {

    }

    ItemConfiguration.prototype = function () {
        getItemConfiguration: function (itemType, flag1, flag2, flag3, flag4) {
            switch (itemType) {
                case ItemTypes.Item1:
                    if (flag1 && flag2) {
                        return ItemStatus.Status1;
                    } else if (flag3 || flag4) {
                        return ItemStatus.Status2;
                    }
                    break;
                case ItemTypes.Item2:
                    if (flag3 || flag2) {
                        return ItemStatus.Status3;
                    } else if (flag1 || flag2) {
                        return ItemStatus.Status1;
                    }
                    break;
                case ItemTypes.Item3:
                    if (flag3 || flag1 && flag3) {
                        return ItemStatus.Status1;
                    } else if (flag2 && flag4) {
                        return ItemStatus.Status3;
                    }
                    break;
            }

            throw {
                message: "No flags matching for " + itemType + "with the flags combination"
                + "flag1: " + flag1 + ", "
                + "flag2: " + flag2 + ", "
                + "flag3: " + flag3 + ", "
                + "flag4: " + flag4 + ", "
            };
        }
    };

    return ItemConfiguration;
} ();

Almost okay we think. When we look over the requirements we notify that the user will need the status for all items. Because of this he will need to make 3 different calls. For each call he would need to add all the parameters over and over again. We can have two possible solutions. One is to create an object that has all this flags. The other option is to change our method to return the status for all our item types. I would go with the second approach.

var ItemConfiguration = function () {

    function ItemConfiguration() {

    }

    ItemConfiguration.prototype = function () {
        getItemsConfiguration: function(flag1, flag2, flag3, flag4) {
            var itemsStatus = new Object();
            itemsStatus[ItemTypes.Item1] = _getStatusForItem1(flag1, flag2, flag3, flag4);
            itemsStatus[ItemTypes.Item2] = _getStatusForItem2(flag1, flag2, flag3, flag4);
            itemsStatus[ItemTypes.Item3] = _getStatusForItem3(flag1, flag2, flag3, flag4);

            return itemsStatus;
        },

        _getStatusForItem1:function(flag1, flag2, flag3, flag4) {
            if (flag1 && flag2) {
                return ItemStatus.Status1;
            } else if (flag3 || flag4) {
                return ItemStatus.Status2;
            }

            _noStatusHandler();
        },

        _getStatusForItem2:function(flag1, flag2, flag3, flag4) {
            if (flag3 || flag2) {
                return ItemStatus.Status3;
            } else if (flag1 || flag2) {
                return ItemStatus.Status1;
            }

            _noStatusHandler();
        },

        _getStatusForItem3:function(flag1, flag2, flag3, flag4) {
            if (flag3 || flag1 && flag3) {
                return ItemStatus.Status1;
            } else if (flag2 && flag4) {
                return ItemStatus.Status3;
            }

            _noStatusHandler();
        },

        _noStatusHandler:function() {
            throw {
                message: "No flags matching for " + itemType + "with the flags combination"
                + "flag1: " + flag1 + ", "
                + "flag2: " + flag2 + ", "
                + "flag3: " + flag3 + ", "
                + "flag4: " + flag4 + ", "
            };
        }
    };

    return ItemConfiguration;
} ();

For each item type we extracted a method that calculates the item status. In the case for the input flags we cannot retrieve a status we throw an exception. In our public method, we create an object that contains our item types and status. In this way we removed the switch and the code looks better.
The thing that has a smell is the 4 parameters that are send each time in our private method. We could create an internal object with these 4 parameters and send it as parameter for each private method. Another option is to create 4 private fields and each private method can use them. Because we don’t have any problem with thread concurrency in JavaScript we can go with the second approach without any problem.

var ItemConfiguration = function () {

    var flag1, flag2, flag3, flag4;
   
    function ItemConfiguration() {

    }

    ItemConfiguration.prototype = function () {
        getItemsConfiguration: function(flag1, flag2, flag3, flag4) {
            this.flag1 = flag1;
            this.flag2 = flag2;
            this.flag3 = flag3;
            this.flag4 = flag4;
           
            var itemsStatus = new Object();
            itemsStatus[ItemTypes.Item1] = _getStatusForItem1();
            itemsStatus[ItemTypes.Item2] = _getStatusForItem2();
            itemsStatus[ItemTypes.Item3] = _getStatusForItem3();

            return itemsStatus;
        },

        _getStatusForItem1:function() {
            if (this.flag1 && this.flag2) {
                return ItemStatus.Status1;
            } else if (this.flag3 || this.flag4) {
                return ItemStatus.Status2;
            }

            _noStatusHandler();
        },

        _getStatusForItem2:function() {
            if (this.flag3 || this.flag2) {
                return ItemStatus.Status3;
            } else if (this.flag1 || this.flag2) {
                return ItemStatus.Status1;
            }

            _noStatusHandler();
        },

        _getStatusForItem3:function() {
            if (this.flag3 || this.flag1 && this.flag3) {
                return ItemStatus.Status1;
            } else if (this.flag2 && this.flag4) {
                return ItemStatus.Status3;
            }

            _noStatusHandler();
        },

        _noStatusHandler:function() {
            throw {
                message: "No flags matching for " + itemType + "with the flags combination"
                + "flag1: " + flag1 + ", "
                + "flag2: " + flag2 + ", "
                + "flag3: " + flag3 + ", "
                + "flag4: " + flag4 + ", "
            };
        }
    };

    return ItemConfiguration;
} ();

It seems that the code looks cleaner in this way and is easier to read. For the private method, I would let the user to specify all the parameters because is more clear for him and he don’t need to create a new object to send the parameters and use it only in one place.
One thing that came to my mind is to create an object or a dictionary that contains the private functions for each item type. But it would be to complex and I don’t know if is worth it.
What do you think? Do you see another way to implement it?

Last edit: Another option is to create a mapping based on the flags (for example each combinations of flag has a unique key that point to an object that has our item types configuration –ex: flag1*2^0+flag2*2^1+flag3*2^3 in base 10 or we could use a mapping in base 2). What is my concern for this solution is the complexity of the code increase, even if the numbers of line are less and we don’t have the IF statements anymore.

 

Read More