This blog includes:
Source Code
http://brunoblogfiles.com/zips/WeatherBillboard.zip
One of the difficult problems to solve for developers is dealing with client computers that are not always connected. Although connectivity and reliability continues to improve, there are many scenarios where we want a “buffer in the cloud.”
These buffers waits in the cloud for the client to connect. At that point, when a client connects, message can finally be read by the client. These message can expire and don’t necessarily need to stick around forever. Afterall, some message lose their relevance with the passage of time, like weather, for example.
Because message buffer contents are stored in active memory, there are no strong fault tolerance or reliability guarantees. If the server hosting a message buffer crashes, you may lose messages. In the event of a server crash, you will not necessarily lose the buffer itself: knowledge of the buffer, including policy settings, is distributed across multiple servers and may be recovered. However, any messages in your buffer at the time of the crash will be lost. Therefore, if you are designing an application that needs a high degree of message reliability, it is recommended that you provide for message redundancy and recovery through other means.
It is important to realize that a Service Bus message buffer application is not designed like a WCF application: there is no host, or explicitly defined channel, or strong service/client paradigm. Instead, an application simply calls CreateMessageBuffer on an endpoint, and then either sends messages to it, or pulls messages from it. In addition, as mentioned above, the message buffer can be managed and accessed by non-Windows applications through REST only.
In order to work with the code and a live example, there are a few things you need to do:
To make things more concrete, envision this scenario. Consider the weather billboards below. The weather billboards are occasionally disconnected and therefore need a way to have message waiting in a buffer in the AppFabric Service Bus.
In the diagram below the Weather Billboard User is interested in securely reading waiting messages in the cloud. The user might be on a wireless network, going through a router and firewall.
Figure 1 : Example of Listeners – the Weather Billboard
Let’s take a look at a sample implementation for the Weather Billboards. Another way to think about it is who is the “publisher” and who is the “consumer?” So the point of this blog is to walk you through the mechanics of doing this.
I want to demonstrate how to use the Windows Azure platform AppFabric Service Bus and its message buffer feature.
The Weather Billboard application creates the message buffer and then retrieves messages from it that are sent by the Weather Station. Creating a message buffer requires the credentials for the endpoint, the message buffer URI, and the message buffer policy. The Weather Billboard creates these prerequisite objects.
Note the two projects here that have both a Service Bus and User Interface code component. CredentialInfo.cs holds all the Shared Secret keys that you got from the web portal.
Code PrintOut – WeatherBillboard::CredentialInfo.cs
You must now go to the web portal. This is the screen you are looking for:
Go to the web portal for:
Note: The key line is line 10, where you need to choose the right service name. Lines 11 and 12 also need to be filled out using the information in the immediate screen above.
Code PrintOut – WeatherBillboard::MessageBuffer.cs
Code PrintOut – WeatherBillboard::MainWindow.xaml
Code PrintOut – WeatherBillboard::MainWindow.xaml.cs
Code PrintOut – WeatherStation::CredentialInfo.cs
It is the same as WeatherBillboard::CredentialInfo.cs
Code PrintOut – WeatherStation::MessageBuffer.cs
Code PrintOut – WeatherStation::MainWindow.xaml
Code PrintOut – WeatherStation::MainWindow.xaml.cs
References
This part is important. Make sure Microsoft.ServiceBus points to
C:\Program Files\Windows Azure platform AppFabric SDK\V1.0\Assemblies\Microsoft.ServiceBus.dll
When you read a message you can do it two ways:
Method 1 : A destructive read
Method 2 : Peek/Lock
*Note*
Automatic Lock Release if Timeout
More on this later. I will add some more code commentary. But you have enough here to implement your own. In my next blog entry, I will get the Weather Station to read data from the National Weather Service.