Skip to main content

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.  

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP