Skip to main content

Patterns in Windows Azure Service Bus - Message Splitter Pattern

In one of my post about Service Bus Topics from Windows Azure I told you that I will write about a post that describe how we can design an application that can route messages for a house which is controlled remotely. Before we can talk about this we need to see some design patterns that can be used in combination with Service Bus. I will write a series of post about this.
We will start with Splitter pattern. This pattern refers to the ability to have a collection of messages parts that form one message or an entity for us. This pattern gives as the ability to receive and process messages from the related messages separately. In this way all the messages that belong to that message part will be sent to the same consumer.
 
How we can use this pattern in Service Bus? Hmm, is pretty simple. We can use SessionId property of a message for this. In this way, when a client (consumer) start to receive a message with a given session id, we can specify to receive only messages with the given id. Service Bus guarantees that the messages from the given session will be received in the same order they were added.
When a client start to receive messages of a specific session, the session is automatically locked. Only that client will be able to receive messages with the given session id. This action is a transactional action. Because of this, if something will happen with the consumer (crash for example), all the messages for the specific session will be received, even if the client that consumed a part of the messages from that session crashed.
To be able to lock the messages from Service Bus to be consumed only by the client that started to receive messages with a given session id we need to the RequiresSession property of the QueueDescription or SubscriptionDescription. This is the only configuration that needs to be done on the Service Bus. On the consumer don’t forget to use the AcceptMessageSession() method to receive a reference to a session from ServiceBus. This method can be found under the abstract class MessageClientEntity that is implemented by all the crucial classes that are used to receive messages from Service Bus:
  • QueueClient
  • TopicClient
  • SubscriptionClient
  • MessageSender
  • MessageReceiver
  • MessagingFactory
Because of this we can write the same code that will be used when we use queues or topics. More information about how you can write code that can consume Service Bus Queues and Service Bus Topics can be found on the following link: www.vunvulearadu.blogspot.com/2012/08/service-bus-topic-how-we-can-migrate.html
In the next example I will get a reference to MessageSession from a queue, a topic and a MessageReceiver.
MessageReceiver
// Service Bus Queue
QueueClient queueClient =QueueClient.CreateFromConnectionString(
     myFooConnectionString, 
     "FooQueue");
MessageSession sessionFromQueue = queueClient.AcceptMessageSession();
// Service Bus Topic
SubscriptionClient subscriptionClient = SubscriptionClient.CreateFromConnectionString(
     CloudConfigurationManager.GetSetting(
          "ServiceBusConnectionString"),
          "myFooTopic",
          "seccondSubscription");
MessageSession sessionFromSubscriber = subscriptionClient.AcceptMessageSession();
// MessageReceiver
Uri serviceAddress = ServiceBusEnvironment.CreateServiceUri("sb", “myFooNamspace”, string.Empty);
MessagingFactory messagingFactory  = MessagingFactory.Create(serviceAddress, credentials);
MessageReceiver messageReceiver = messagingFactory.CreateMessageReceiver(“myFooQueueName”);
MessageSession sessionFromMessageReceiver = messageReceiver.AcceptMessageSession();
Don’t forget to activate the session support from the queue or topic of the Service Bus.
QueueDescription queueDescription = new QueueDescription("FooQueue");
queueDescription.MaxSizeInMegabytes = 5120;
queueDescription.DefaultMessageTimeToLive = new TimeSpan(0, 10, 30);
queueDescription.RequiresSession = true;
if (!namespaceManager.QueueExists("FooQueue"))
{
    namespaceManager.CreateQueue(queueDescription);
}

Once we have the reference to MessageSession we can consume messages with the same session id using Receive method of the MessageSession (as a hint: the base class of this class is MessageReceiver).
while ( true )
{
     BrokeredMessage message = session.Receive();
     ...
     message.Complete();
}
This pattern can be used when we the messages are a specific order that is important for the received. We want to be able to specify where the messages need to be sent. As an example we can imagine a hyper-market that sell a lot of things. Based on the type of the product we have different services that need to consume these messages and process this. For this case, each session can be a different product category. Another case when slitter pattern is very useful is for the case when we want to send content that is too big for a message. For this case we need to use a splitter.
Tomorrow we will continue with another pattern where Windows Azure Service Bus can be used.
Last edit: A list of all patterns that can be used with Windows Azure Service Bus, that were described by me LINK

Comments

  1. Interesting!
    There is a very good book on this subject:
    http://www.amazon.com/Enterprise-Integration-Patterns-Designing-Deploying/dp/0321200683

    ReplyDelete

Post a Comment

Popular posts from this blog

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…