The first scenario can came from the world of hyper-markets, where we can have 50,60 or 70 cash machine. As a manager I’m interested to know the stock of my products all around the country. Based on this I can move goods from one deposit to another, or from a hyper-market to another. I don’t want to see the stock in real-time. A delay of 5-10 minutes is acceptable, but is very important for me to not lose items that are sold (I need to see the real-stock and not some estimations). Also even if this information is very important for me, I don’t want to invest a lot of money in an application and on servers that need to be maintained.
For this case, we can imagine a solution that use for communication Service Bus Queue. The cash machine sends to the queue the list of products that were sold. A central server has all the time from the world to consume products list and update the stocks. If we have a rush hour is not a problem for us because all the messages will be process in the end, without losing any messages. But what about holidays, for example Christmas, when is very important to know the stock in real time (we don’t want to be out of soda or sugar in December 22th. In this case we can scale and add more servers on the consumer side. If we are on Windows Azure with this then this is piece of cake.
Another interesting solution here is to use WCF and Service Bus Queue. In this way we will not rely on Windows Azure Services and it will be very easy to move from cloud to on-premises or to integrate another solution.
The second scenario put us in the educational system. We need to create a system that is able to centralize all the grades of students at the end of each trimester. Teachers can add data to this system in any moment of time, but because we need this information only at the end of trimester we don’t want to waste money on a server/s that run all the time to permit teachers to add this data. Also we should be able to store them until the end of trimester when we centralize them.
For this case, it would be very easily to create an application that sends this data to the queue. Because the TTL of a message from Service Bus Queue can be unlimited, we can persist this data very easily (and cheap). At the end of the trimester we can start a machine that consumes this data generating an output and creating an archive.
One great idea here. We can create a Metro Application for a Windows 8 Tablet where teacher can add this data. From the tablet the data is send directly to the queue. Because we have ACS claims and role-based access control on Service Bus Queue, all 3 of AAA can be satisfied.
In the last scenario we have a big restaurant chain that makes delivery at home. We want to be able to process the commands in the order that were submitted, we don’t want to lose any message.
For this scenario we can create a Service Bus namespace and create a queue for each work point. Based on the address from where the command is submitted we can add the command to the most appropriate restaurant. Service Bus Queue guarantees that each message will be processed in the order that he was added to the queue and also we will not lose any messages (this is a scenario where Service Bus Topics can be used with success also – but we will talk with another occasion).
What is important to know about Service Bus Queues?
Service Bus Queues can be a great solution when we want:
- Loose coupling (consumer and producer don’t need to know each other – upgrades or changing one of the part can be made very easily)
- Load leveling (we don’t have to run the consumer all the time)
- Load balancing (we can add consumers or producer very easily)
- Temporary decoupling (producer or consumer can be offline)
0 comments:
Post a Comment