I recently had the honor of delivering a presentation entitled ‘Build Hybrid Applications Using the Azure AppFabric Service Bus’ at the Richmond and Philly.NET Code Camps. Virtually no one in either of the sessions had any previous experience with Windows Azure or the components of the AppFabric. In this series of blog posts, I will expand upon the presentation in an effort to introduce the AppFabric and take a deeper dive into the code and practical application of the Service Bus messaging patterns.
One of the most common comments I get lately is ‘my organization is not interested in re-architecting our applications just to host them in the cloud’. While I agree with the root argument of not re-writing applications, there is a viable middle ground to utilize features of cloud computing without going ‘all-in’ or refactoring legacy applications just for the cloud. The decision to utilize cloud computing, regardless of the provider, should not be an all or nothing proposition. Gartner forecasts that by 2015, most private or limited cloud computing use will evolve into hybrid cloud computing featuring a mix of cloud software, platforms and infrastructure, much of which will be virtualized in a public cloud. Given the public perception that cloud computing is hype and rife with instability, I believe the Windows Azure AppFabric Service Bus exposes an opportunity for organizations to maintain control of their on-premise resources while capitalizing on the benefits of cloud computing and hybrid/distributed architectures.
Within the Windows Azure platform, Microsoft has provided a set of building blocks for developing connected applications known as the Windows Azure AppFabric. The AppFabric contains capabilities such as Access Control for authentication and authorization, Caching for a highly-distributed caching mechanism and the Service Bus. The Azure AppFabric Service Bus lets you connect your on-premise systems securely into the Azure environment, while allowing your data and your information to traverse network and application boundaries. The Service Bus facilitates the creation of hybrid applications by:
- Enabling the rapid provisioning and self-service of secure endpoints in the cloud
- Eliminating the overhead and administration of custom VPNs, firewall rules, reverse proxy and other brittle network configurations
- Connecting internal resources to external consumers
- Providing secure messaging capabilities for distributed architectures
The two primary messaging patterns provided by the Service Bus are “relayed” and “brokered”. The Relayed Messaging pattern utilizes a centralized, load-balanced relay service running in the cloud that supports a variety of different transport protocols and Web services standards, including SOAP, WS-*, and REST. Relayed messaging is only possible when the message sender and receiver are both online at the same time. As an alternative, the Brokered Messaging pattern utilizes Queues, Topics and Subscriptions and Rules as a way to facilitate decoupled, asynchronous messaging via a cloud-based broker. Since the messaging infrastructure reliably stores messages until the consumer is ready to receive them, the message sender and the message receiver do not need to be online at the same time. In both patterns, the messaging capability is provided for WCF and .NET Framework programmers and also via REST.
This completes the high-level overview for the Azure AppFabric Service Bus. In the next post, I will lead you through the implementation of the Relayed Messaging pattern and discuss how to apply the pattern in a sample scenario. In the meantime, if you would like to take a deeper look at the Azure Platform, the following links are an excellent source of information:
Quick Guide to the Windows Azure Platform
http://msdn.microsoft.com/en-us/library/dd163896.aspx
Windows Azure AppFabric September 2011 Release
http://msdn.microsoft.com/en-us/library/hh394904.aspx
AppFabric Service Bus REST API Reference
http://msdn.microsoft.com/en-us/library/windowsazure/gg278338.aspx