Proven Code Patterns in Windows Azure
This topic describes as many of the proven code patterns that you should use where appropriate when building applications that use Windows Azure services. Code-level patterns include recommended patterns for code regardless of the language, such as asynchronous execution patterns, retry efforts, and other common code activities that prove extremely important to increase performance, scalability, and manageability of applications on Windows Azure. Most of these code patterns contain examples or references to examples in .NET languages, but the patterns are recommended no matter what language or platform is being used on or with Windows Azure services.
The scenarios in this topic are updated as more proven patterns emerge from customers and the community. The initial patterns are ones that have immediately appeared critical to building solid and performant Windows Azure applications.
Proven Coding Patterns
Asynchronous Service Calls
Recommendation: Calls to services in Windows Azure should be asynchronous.
Exceptions: Any situation in which the goal of the application is to take a request, start a longer process, and return immediately may not benefit much from asynchronous calls. A good example is an application that triggers very heavy computing work that will take some time – for example, a single Web role instance may present a button on a web page to request video graphics to render in many parallel worker role instances overnight. The user may not need to do more computing work while she waits for a synchronous call to return and indicate that the overnight rendering process has begun.
Suggested Asynchronous Examples
Because of the latencies involved in distributed applications an especially in cloud platforms like Windows Azure, calls to services should be asynchronous, so that the calling application can continue to do work while waiting for the call to return a response. In more cases that in local networks or desktop applications the call may fail to return due to timeouts or other network interruptions that occur on the internet; in the case of call failure, synchronous calls will hold up other work for the entire operation to timeout. The recommendation for asynchronous calls is even more important when working with small devices like phones and any device that has a weak or intermittent internet connection.
|You can check current latencies at Matthew Rosoff’s Azure Statistics application.|
It may seem that asynchronous calls are always recommended – for examples, see the .NET Framework topics on the Event-Based Asynchronous Pattern, WCF Synchronous and Asynchronous Operations, and this recent discussion of Asynchronous Programming in MSDN Magazine – but the increasing computing abilities in desktop systems often make this unnecessary, as synchronous behavior is easier to code – which means faster, typically – and provides satisfactory results.
Unfortunately, bringing a synchronous approach to a Windows Azure application is likely to lead to disappointing results unless the natural interaction with the application is synchronous and latencies are not an issue.
There are two proven implementations you should examine using asynchronous service and client methods.
Asynchronous Service Implementations
The following implementations are proven examples of libraries that make sending and receiving messages straightforward ane efficient, enabling asynchronous work without the overhead of handling or wrapping begin and end methods.
Best Practices for Leveraging Windows Azure Service Bus
Another proven implementation for using Service Bus queues – as well as other Windows Azure services like storage -- uses the Understanding and Using the CloudFx Framework library created by the Windows Azure Customer Advisory Team working directly with customers. For the basic example of asynchronous message sending and receiving to and from a Service Bus topic and subscription, see How to: Use CloudFx to Send and Receive Messages Asynchronously with a Service Bus Topic.