[Post Event] Windows 8 Dev Camp, Cluj-Napoca - September 29

Last Saturday we have the pleasure to organize in Cluj-Napoca, Windows 8 Dev Camp. In this great event we talked about the new operating system from Microsoft, Windows 8.  Almost 100 people attended to this event.
Different subject were approached from the developer perspective. Two sessions talked about the new functionalities of Windows 8 and also about how a Windows Store Application should look like and interact with the user. In another session we looked over the new HTML 5 and JavaScript support and how we can build native Windows Store Applications using them.
My session was the last one of Windows 8 Dev Camp and I talked about WinRT and the architecture of Windows 8 looks like. Different subject as components mixing, WinMD, JavaScript testing and automatic build were touched.  In the last part of the session I presented what a Windows Store Application package contains and how it should be build and validate.
Here are my slides from my session:
Some images from the event:

Special thanks to our sponsors and speakers.

Read More

Patterns in Windows Azure Service Bus - Resequencer Pattern

Today we will talk about another message pattern: Resequencer. In the last post I presented Recipient List Pattern. In comparison with this pattern, Resequencer Pattern is very different. The main scope of this pattern is to help us to put messages back in a specific order.
When we are talking about messages, we can talk about a stream of messages that need to be received in a specific order. It is very crucial for the receiver to retrieve the messages in the same order he receives.
Theoretically, in a simple case we will receive messages in the expected order. This is offer Service Bus by default. But what happen if an error occurs on the receiver and message is putted back in the queue. We will need to retry to consume that message one more time and not the next message.
Another case when the order can be broken is when we have more than one producer. For this case we can have two different situations.
In the first scenario, each producer will produce messages for different stream of messages. In this case we can very easily use the session id of the messages to be able to receive only messages for a specific stream. But we will still need a way to detect if the messages if the message that we expect. First step is to add two properties to each message. The first property will tell us how many messages are in this message stream and the other one will tell us the index of the current message. Base on this information, the receiver will know the index of the next message and will be able to validate it. If we will receive messages that don’t have a valid index id, we can throw them in the defer queue, from where we will be able to retrieve them anytime.
Producer:

QueueClient  queueClient = …
BrokekedMessage message = new BrokeredMessage();
message.Properties[“index”] = 1;
message.Properties[“count”] = 10;
message.SessionId = 123;
queueClient.Send(message);

Consumer:

MessageSession messageSession = queueClient.AcceptMessageSession(123);
int currentIndex = 1;
while(true)
{
    BrokeredMessage message = messageSession.Receive();
    if(int.Parse(message.Properties[“index”]) != currentIndex)
    {
        message.DeadLetter();
        continue;
    }
    …
    message.Complete();
    if(int.Parse(messsage[“count”]) == currentIndex)
    {
        break;
    }
    currentIndex++;
}

Next we need to take message that were marked as dead letters and moved automatically to the dead letter queue.

QueueClient deadLetterQueue = QueueClient.CreateConnectionString(
    connectionString,
    QueueClient.FormatDeadLetterPath(“FooQueue”));
while (true)
{
    BrokeredMessage message = deadLetterQueue.Receive();
    // same logic as in the normal queue.
    // we need to abandon the message and not to mark him as dead letter.
    // we already process the dead letter messages
}

The second scenario is a little more complicated. In the same queue, we have more than one producer that produce message for a specific stream. The chances to have messages in the expected order are very low. The solution is similar to the first one. We can add the index of each message and total number of messages as properties to the message that is added to the queue. The consumer can check this values and when the message index is wrong, the message will be added to the defer queue.
In the both solutions, the most time consuming is retrieving the message from the defer queue. The good part that usually the messages are in a kind of order, even if is not perfect (eq. 1 3 5 2 6 7 10 8 9). Because of this we will not need to “iterate” through the defer queue to many times.
This pattern can be used for cases when it is critical to process messages in a specific order. In a system that sells tickets for a baseball game this is not so critical. But for a system that receives commands using messages it is very important to execute the commands in the same order – for example a nuclear power station.
This is a pattern that is not very common. When you reach a case where you need this pattern, try to double check again if you need it, because this pattern can be very expensive – from the perspective of processing time and resources.
Last edit: A list of all patterns that can be used with Windows Azure Service Bus, that were described by me LINK.  

Read More

Patterns in Windows Azure Service Bus - Recipient List Pattern

I will continue the blog series of post about patterns that can be user with Service Bus of Windows Azure with Recipient List Pattern. Did you ever try to send an email to a list of users? Using Exchange Server is quite simple. We can create a group list and send an email to the specific group list. For example we can have groups of email for different products categories. One can be for TVs, another one for Notebooks and so on. If we create a complex system for a company that have different products that want to send we will need to be able to send notifications about new products that are available. To be able to do something like this we will need a system that permits us to send notifications to a “group” – to a list of subscribers. In a system that is based on messages we will not know the list of subscribers for each group. Because of this we can decorate each message with some meta-information about the groups should receive the message. In Windows Azure, we can implement this pattern using Service Bus Topics. For each message we can add a property to the message that specifies the groups of subscribers that will receive the message. This list of messages can be separate with a comma or any kind of character.

BrokeredMessage message = new BrokeredMessage();
message.Properties.Add(“Groups”,”Review, Test”);
…

Each subscriber will need to create a custom filter. For this purpose we can use the ‘LIKE’ operator of SqlFilter.

TopicClient topicClient = TopicClient.CreateFromConnectionString(
CloudConfigurationManager.GetSetting(
    "ServiceBusConnectionString"),
    "myFooTopic");
SqlFilter sqlFilterReviewGroup = new SqlFilter(“Groups LIKE ‘%Review%’”);
topicClient.AddSubscription(“ReviewSubscription”, sqlFilterReviewGroup);
SqlFilter sqlFilterTestGroup = new SqlFilter(“Groups LIKE ‘%Test%’”);
topicClient.AddSubscription(“ReviewSubscription”, sqlFilterTestGroup);

Even if this solution will work without any kind of problem, we should be aware that we use the “LIKE” operator. From performance perspective we know that this is not the fastest solution. If we don’t have a lot of messages that are send on the wire that this is not a reals issue. For better performance we can find different solutions, from complicated one that use bits to simpler one like adding different property for each group. In this way the subscriber of a filter will only need to check if the property is set or not. For this purpose we can use the “EXISTS” operator or SqlFilter.

SqlFilter sqlFilterReviewGroup = new SqlFilter(“EXISTS Review”);
topicClient.AddSubscription(“ReviewSubscription”, sqlFilterReviewGroup);

If you don’t want to have a lot of properties you can a prime numbers. The only problem with this solution is related to how easy the code can be read and maintain. Each prime number can represent a different group. And a message should be received by a subscription if the group property can be divided to the prime number that represents our group. We could imagine another solutions also.
To be able to use this pattern we need to define the list of recipients. This list can be a static list of can be created dynamically and can be change on runtime. Using Service Bus Topics from Windows Azure the list can be dynamically created and changing the list will not require changing the code that send or receive the messages. All this can be done in the configuration files.
The important thing that we need to remember about Recipient List Pattern is when we need to use it and Windows Azure Service Bus supports an implementation of this pattern.
Last edit: A list of all patterns that can be used with Windows Azure Service Bus, that were described by me LINK.  

Read More

ListView - make selected item visible don't work in all cases

Did you ever try to use the ListView for Windows 8 Applications? If you had a more complicated scenario where you need to ensure that the selected item from your code is visible maybe you had the following problem… How can I make the selected item visible? If I have a lot of items in my scroll list than the selected item will not be visible when we select it.

listView.set(i).done();

In this way we select the ‘i’ element of the list. Also the set() method unselect the rest of the items that were selected already. To be able to show it in the visible part of the list we need to call the ensureVisible() method after we set it.

listView.set(i).done();
listView.ensureVisible(i);

But in more complicated cased you will notify that this will not work. Even if the ensureVisible() method is called nothing will happen. Usually this case appears when the method is called in a “callback” or in a complete, error or progress of a promise. Even if you try o the ensureVisible in a msSetImmediate it will not work:

listView.set(i).done();
msSetImmediate(function(){ listView.ensureVisible(i); });

A fix for this problem is using the indexOfFirstVisible. This property of the list view gives us the possibility to set the index of the first visible element. The working code would look like this:

listView.set(i).done();
msSetImmediate(function(){ listView.indexOfFirtsElement = i; });

I hope that I could help you.

Read More

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.  

Read More

Patterns in Windows Azure Service Bus - Message Filter Pattern

In the last post I tacked about Splitter Pattern.Today we will continue with Message Filter Pattern. This pattern can be used with success with Windows Azure Service Bus.

As the name says, all the messages are filtered based on specific rules. Any message that will reach the consumer will be filter based on this rules. All the producers will use the same entry point where they will add messages. They don’t have to know that messages are filtered based on same rules. In this way, the message system will create a decoupling between the producer and the consumer. This pattern is used to be able to control the messages that where not routed to any subscriber.

Windows Azure Service Bus Topics can be used for this purpose. It gives us the ability to define rules that can check the messages content based on meta-information. These rules will be added to each subscriber and will specify if the messages will be accepted or not.

SqlFilter myCustomFilter =
    new SqlFilter("grade < 5");
namespaceManager.CreateSubscription(
               "StudentsGradesTopic",
               "StudentsWithProblemsSubscription",      
               myCustomFilter);  

 In the following example I created a subscription that accept messages that have the grade under 5. For more information about defining custom rules: http://www.vunvulearadu.blogspot.hu/2012/08/service-bus-topics-how-to-use-it-part-2.html

When we are using this pattern, consumers will only receive and process messages that where filtered. Because of this, we can have messages in the system that will not pass any filter. This messages need to be tracked in one way or another. For these situations we can define a custom rule in Service Bus Topic that will receive messages that didn’t pass the rest of the rules of the subscribers. The name of the filter expression is “MatchNoneFilterExpression”. In the following example we setup a rule that accept messages that didn’t pass the rest of the rules.

RuleDescription notConsumedMessagesRule = new RuleDescription()
{
     FilterAction = new SqlFilterAction(“set isNotConsumed = true;”),
     FilterExpression = new MatchNoneFilterExpression()
};
subscription.Add(notConsumedMessagesRule);

For more information about this time type filters: http://www.vunvulearadu.blogspot.hu/2012/09/service-bus-topics-define-custom-rules.html

This pattern can be used with success when we need to control what kind of messages is received by each consumer. We can imagine that we need to manage grades from a university. For this purpose each department want to receive information related to them. The history department doesn’t want to receive grades from the mathematic department. For this case the Message Filter Pattern can help us a lot because it created only one entry point for the applications and services that add these messages.
Last edit: A list of all patterns that can be used with Windows Azure Service Bus, that were described by me LINK.  

Read More

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. 

Read More