If you are experienced enterprise developer who targets the Microsoft platform, you have probably at least once in your have a requirement to share some state across different instance of an application.
But, if you are hobby developer or any other professional developer, who possible do not focus distributed systems, you will might find the term “State” in context of persistence a pure theory thing.
So who ever you are, let’s start with a simple theory thing.
Imaging you have in theory a trivial application (today I call such applications simply “apps”). Assume this is an app running on smart phone or any other mobile device. This app has a variable ‘A’ and value assigned to this variable ‘1’. This value is not the default value. It is rather the value which user has assigned at some point of time.
Now, imagine the application crashes and you start it again. The value of variable A is obviously lost. If you want to keep this value somewhere, so it can be loaded even if application crashes. We call that usually persistence. Depending on application and your skill, there are several ways to persists the value of an variable. For example you can use any kind of local cache, like a file system.
But what if your application has to survive the hardware damage? Or what if your application is consisted multiple clients which have to share the same value? In this case you will have to use some kind of database.
As long you are in control of your infrastructure (means application is deployed in your enterprise) you can use some database to persist the value. The good example of this is Workflow Foundation. Long running processes require by default the state persistence.
Unfortunately we have more often scenarios where applications are distributed across the web. In such cases the only sharing artifact between such applications is the cloud. Following picture shows how two apps (or applications) share their state through the cloud.
This is a nice theoretical case which is practically a horror to implement. I strongly believe that today we are implicitly preparing for dominance of devices in the web. In this hypothetical scenario both devices (see picture above) should act as services to be able to share their state. If you are distributed application or integration developer you know that connectivity us such scenarios is a big, big issue. Or simply, it is the fact, devices in the web have a private IP address and because of that they are not reachable by anybody. So if the microscope on the left cannot reach the smart-phone on the right, the state from left to right cannot be propagated and vice versa.
If this to theoretical to you, imagine just a service which is running distributed across cloud. This might be WCF service, Windows Service (running in SCM) or even Web Api based service. Whatever technology you peek, it does not matter. The only important thing is that you want run multiple instances of the service, but on two machines which are not in the same environment (if they are in the same environment even better). So that means, independent on a case, devices or services or both, we have the same requirement:
1. Sharing of the state between applications distributed in the web
2. Persisting of the state without database.
You believe or not, this problem can be solved by using Windows Azure Service Bus, which in this case plays a role of cloud artifact. To illustrate how this can work, take a look on following example.
This is a console application in C#. The state which should be shared and persisted across many applications is stared in variable State.
| class Program{ public static WebState<string> State { get; set; } static void Main(string[] args)
{ State = new WebState<string>(ConfigurationManager.AppSettings["SbConnStr"], "BusinessDomain", ConfigurationManager.AppSettings["Node"]);
State.StateChanged += State_StateChanged;
Console.WriteLine("I'm node with name: " + ConfigurationManager.AppSettings["Node"]); Console.WriteLine("Running with state: {0}", State.Value); while (true)
{
State.Value = Console.ReadLine();
}
} static void State_StateChanged(object sender, WebStateEventArg<string> e)
{
Console.WriteLine("State changed by {0} at value: {1}", e.InstanceName, e.NewValue);
} } |
As you see this variable is of type WebState, which is implemented by me. When you start this application, enter some text on the console. The text will be immediately persisted in the cloud after following line of code is executed:
State.Value = …
Now stop the application gracefully and start it again. You will notice that application write out the value which was as last one persisted. In fact event with one participant in the system you have achieved the persistence.
The magic behind this is implemented on top of Windows Azure Service Bus queues. Each time the value is changed, the WebState implementation receives the existing message from the queue and put back the new message in the queue which basically holds the serialized value of variable State, and so on. Because access to the queue is session based, Service Bus guaranties that no any other applications which shares this value, will access the queue in the same time. I don’t want to call this distributed transaction, but it behaves in persistence this scenario like it would be one. In fact the WebState class uses the Queue as a unit of storage. By reading and immediate writing back of the new value, it is guarantied that the queue holds one and only one message all the time.
Following picture illustrate this. Each time the value i changed the old value is stored in the queue as a message. The old value is received from queue and the new message with new value is sent to the queue. At the end the old one is completed, because PeekAndLock receive is used.When the new instance of the State is created (for example when application is started) the same cycle with receive/send is done. This is how multiple applications obtain there actual state.
Additionally the implementation of the WebState takes a care about state sharing. For this purpose there is a topic used to share state changes. All participants in this distributed system have to create a subscription on that topic.
In this case (see picture below) the new value is published as a message to the topic. After that all subscribers can receive the message with the new value. The publishing process additionally updates the new value in the persistence queue from previous example.
Because topic-subscriptions are used, the application which was not running for a while, will automatically receive all state changes which have happened in the mean time.
This examples shows how complex patterns can be implemented by using connectivity service in Windows Azure. I know that majority of people out there still think a..bout cloud as an old thing. There is also a group of people who thinks that cloud is unsafe think to keep the data. If you are one them them please rethink your thinking. The scenario and solution shown above is a new way of thinking and using cloud services. And the nice think here is that practically no real data is stored in the cloud.
As you see, the cloud is more than solely putting of some application online. :)
The code for this will be published soon.
Posted
Apr 22 2013, 03:00 PM
by
Damir Dobric