Patterns in Windows Azure Service Bus - Message Aggregator Pattern

In the last post I talked about Message Filter Pattern that can be used on Windows Azure Service Bus. Today I will describe how we can use Message Aggregator Pattern. From some points of view, this pattern is the opposite pattern in comparison with Message Splitter Pattern.
Do you remember when Message Splitter Pattern can be used?… when we want to split messages based on some rules. Message Splitter Pattern does the opposite thing. This pattern can be used when we want to aggregate different messages.
This pattern can be used with success in cases when we send some information in more messages. For example if send GPS position of cars based on the type. Until the car will reach the destination it will send a lot of messages. We will need to mark with a custom property the last message that is send by the cars of a given type – or to define a timeout period. When the last message will be received we will be able to process the data – for example to calculate the total distance and the speed of the car.
Using Windows Azure Service Bus we have two possibilities to implement this pattern. The first one is to use sessions. I already described a solution based on session in the following post: http://vunvulearadu.blogspot.hu/2012/08/service-bus-queues-from-windows-azure_20.html
This is not the only way to implement this pattern. If we are using Windows Azure Service Bus Topic we can use with success CorrelationFilterExpression.
Why to use CorrelationFilterExpression and not session? Because usually this pattern is used when we work with a lot of messages that need to be aggregate. The correlation id is stored in a hash table and the matching is faster. In comparison, the session id comparison is not hashed and is not optimized for 1 to 1 match – we only compare two strings using a SQL expression filter. From this perspective, using CorrelationFilterExpression is better.
Let’s see how we can use CorrelationFilterExpression to make our life easier. For this solution we will need to use Service Bus Topics. On the client side we will need to set the correlation id. Every BrokeredMessage has a property named “CorrelationId” that can be set to our specific value.

BrokeredMessage message = new BrokeredMessage();
…
topicClient.Send(message);

Remember one thing and this is very important when we want to use the CorrelationFilterExpression. We specify the correlation id in the moment when we create the subscription, through the rule that we are creating. Because of this a subscription will be only for one correlation id. This is the cause why the session id is preferred when we don’t have many messages from the same “group” (session). If you remember the example with the cars and GPS location we will have a lot of messages from different cars type that will be grouped based on the car type. In our case this will represent the correlation id. This id can be any string, we are not limited to a int or some values.

namespaceManager.CreateSubscription(
     “myTopic”,
     “sedanSubscription”,
     new CorrelationFilterExpression(“sedan”));

This is the only thing that we need to do from the configuration perspective. Usually there is not a problem with the subscription that is “glued” to a specific correlation id because from this perspective, the ids should not change in time. Also there will be a constant flow of messages.
As a conclusion let’s see when we can use Messaging Aggregation Pattern. We can use it when we need to aggregate messages based on a specific flag. From the performance perspective it is recommended to use the CorrelationFilterExpression that hash the id that is specified.
Last edit: A list of all patterns that can be used with Windows Azure Service Bus, that were described by me LINK.