Are you a startup?
Get BizSpark cloud access
Get up to $3,700 of cloud benefits
Don’t have MSDN?
Here’s cloud access
Glassboard is a mobile service for sharing privately with groups. With Glassboard, you create 'boards' which are groups of people around a common interest where you can share messages, comments, photos, videos, and even your location (when appropriate).
When the Glassboard team was developing Glassboard, they looked for a platform that offered scale, worry-free operation, replicated data, and privacy for their apps on Windows Phone, iPhone, Android, and Office 365. The Glassboard team chose the Windows Azure platform for these capabilities.
This article provides and overall architecture of the Glassboard backend in Azure.
The architecture of Glassboard includes native smartphone and desktop applications, a Web Service to handle requests, a data store to hold the messages and videos, and a notification service to alert users of incoming messages.
Each mobile platform has a native application. The Windows Phone 7 app is in the Windows Phone Marketplace, the Android & iPhone apps are available in their respective stores, and the Silverlight desktop client is available through the Office 365 Marketplace. Each of these clients makes calls directly to the custom Glassboard backend built in Azure.
Each of the phone applications talk to Web Services hosted in Windows Azure. The connections are all made over SSL, and they use digest authentication. Authorization is provided by a custom-built service of user names and passwords. Once the user is authenticated through the Web Service, a token is returned to the device that is attached to subsequent service requests.
The Web Service is written using REST on Windows Communications Foundation (WCF) that is part of .NET 4. WCF services receive and validate the user log in, and receives the messages, pictures, and videos. The Web Service is hosted in a Windows Azure Web Role. You can think of a Web Role as Windows Server virtual machine that includes Internet Information Services (IIS).
Incoming messages from the apps are stored in Windows Azure Table Storage as entities
The message is encrypted prior to writing the data into the table store. The Glassboard team used Azure Table Encryption by Attribute that is available in CodePlex. A single attribute is used to transparently encrypt and decrypt data when saving or reading data from Azure Table storage. The technique ensures that "data at rest" will be encrypted. This means no external parties can read your content – not the authorized infrastructure personnel at your company, the Glassboard team, nor anyone at Microsoft will not be able decrypt this data. Incoming pictures and videos are stored in Azure Blob Storage in the same way.
Videos need to be encoded so they can be seen on each of the other devices. The Web Role receives the incoming media file and stores the file in Windows Azure Blob Storage. Then it places an item in Windows Azure Queue Storage to alert the Worker Role that encoding is needed. The Worker Role queries to queue, which acts as a "to do" list tasks that can take several minutes.
Think of a Worker Role as a service that runs in a never-ending loop. When the Worker Role cycles, it checks for an item in the queue. The item in the queue points to the location in blob storage that needs to be encoded. The Worker Role picks up the item, marks the item in the queue as being in progress, and begins its work. If for some reason the encoding fails, the item in the queue is set back to restart the encoding. Or when the encoding is completed, the Worker Role removes the item from the queue.
As the Worker Role completes encoding each video, it places the media into Windows Azure Blob Storage that can then be sent in chunks to the users.
Notifications are also handled by the Worker Role. When the Worker Role detects that an new notification is to be sent, the notification is made to the smartphone provider. In Windows Phone, the notification is sent using Push Notification Services.
For Windows Phone devices, the Glassboard app running on the phone intially requests to receive a push notification URI from the Push client service. Through a negotiation with the Push service, it receives a URI that identifies the device. The client software sends that URI to the Glassboard Web Service.
Glassboard maintains a list of these URIs in Windows Azure Table Storage. When it comes time to notify each device, the service walks through the user network, gets the URI for each member's device, and sends a push notification to the Microsoft Push Notification Service, which in turn routes the push notification to the application running on a Windows Phone device.
For Windows Phone, the notification is delivered as raw data to the Phone application, the application's Tile is visually updated, or a toast notification is displayed. The Microsoft Push Notification Service sends a response code to your web service after a push notification is sent indicating that the notification has been received and will be delivered to the device at the next possible opportunity. However, the Microsoft Push Notification Service does not provide an end-to-end confirmation that your push notification was delivered from your web service to the device.
Other devices have a similar service.
Because the primary interface into the Glassboard service is a Web Service, Glassboard messages can be integrated into other applications. For example, you can access Glassboard messages from within NewsGator Social Sites. NewsGator integrates Glassboard into Social Sites so users can see mico-blogging messages and links from within an enterprise.
With this architecure, Windows Azure provides advantages of storage replications, scale and provides service guarantees.
Windows Azure Blobs, Tables and Queues stored on Windows Azure are replicated three times in the same data center for resiliency against hardware failure. No matter which storage service you use, your data will be replicated across different fault domains to increase availability and be fault-tolerant.
Windows Azure Blobs and Tables are also geo-replicated between two data centers hundreds of miles apart from each other on the same continent, to provide additional data durability in the case of a major disaster, at no additional cost.
The loosely coupled architecture provides the ability to scale. When many users connect Glassboard can increase the number of Web Roles to process the incoming messages. When the number of videos and notification out paces the ability for the Worker Role to do the encoding, additional Worker Roles can be enabled.
Because the architecture is loosely coupled, compute cycles can be added as needed.
Conversely, during late evenings when messages and videos are fewer, the system can scale back to a small number of compute instances ready to receive the next message.
Using Windows Azure Queue allows decoupling of different parts of a cloud application, enabling cloud applications to be easily built with different technologies and easily scale with traffic needs.
Security on Windows Azure is a shared responsibility. Glassboard provides a high degree of security for the individual messages because it takes advantage of application best practices. Traffic between phones and the Web Service are encrypted using https and confidential data is encrypted prior to storage.
Glassboard users can provide location information and photos without sharing those details with others, even the Glassboard staff has no access.
Windows Azure operates in the Microsoft Global Foundation Services (GFS) infrastructure, which is ISO 27001-certified. ISO 27001 is recognized worldwide as one of the premiere international information security management standards. Windows Azure is in the process of evaluating further industry certifications. In addition to the internationally recognized ISO27001 standard, Microsoft Corporation is a signatory to Safe Harbor and is committed to fulfill all of its obligations under the Safe Harbor Framework.
For iPhone, Android, and Windows Phone 7.
Also see Building a Massively Scalable Platform for Consumer Devices on Windows Azure in MDSN Magazine.
Special thanks to Walker Fenton and Brian Reischl.
Bruce D. Kyle ISV Architect Evangelist | Microsoft Corporation