So this post is a little delayed due to all of the excitement around the BizTalk sessions. However the sessions were that good that I wanted to still publish the post.
Azure Service Bus Solution Patterns -Clemens Vasters and Abhishek Lal
Another session by Clemens and Abhishek. This time around it was a very practical session based upon some Customer Use Cases and how to implement some popular integration design patterns based upon the “Integration Bible” - Enterprise Integration Patterns. To view the actual session on Channel9, click here.
Some of the Use Cases included:
- Web Services For Retailers
- Company from Italy
- Provide SAAS solution for Retail Stores
- Seed local retail outlets with Catalogue and Pricing information
- Push out to retail stores
- Use Topics to distribute information to each retail store
- SaaS with Dynamic Compute Workload
- High Performance Computing (HPC) scenario
- Command and Control messages sent in from Service Bus
- ISV specialized dynamic compute capacity provider
- Consumer Web Site
- Web site that searches for data about people – credit check, criminal check etc.
- Their challenge was back end data co-ordination
- Different profiles for users who have different access to to back end services
- Queues for decoupling the web layer from middle-tier services
Scaling things out
Next Clemens walked us through a scenario that Microsoft has been working on with a particular customer. The solution was related to remote controlling air conditioners. The idea is that a consumer would have the ability to manually control it but also power providers could *potentially* control it to prevent rolling brown-outs from occurring. Instead of instituting wide spread rolling brown-outs, each customer could alter their consumption. Collectively these savings add up and prevent demand from exceeding supply. I am a little skeptical about a power company(I work for one) controlling someone’s air conditioner but in theory it makes a lot of sense.
The requirements for this solution includes:
- Pair devices, such as air conditioner, to local Wi-Fi connection
- Users need the ability control the device
- Control requests could be made from back yard or across the world
- Service Bus makes these control requests possible from anywhere that has an internet connection.
- Devices will then send consumption data to Azure where the data can be viewed on a mobile device. This data will make its way to Azure via Service Bus. The premise behind this is if customers are more aware of their consumption patterns, then they may try to alter them. This is something that my organization has also been investigating.
So a question remains, these types of consumer devices will not have the .Net Service Bus bindings installed so how will they actually communicate? The answer is really HTTP. You can send HTTP requests to the Service Bus and in this case Clemens introduced a concept that he likes to call “N-HTTP”. It is a similar to the “NoSQL” movement but in this case is related to HTTP. HTTP in many cases includes HTTP Headers but also an entity body. The entity body could include JSON content, XML content etc. The challenge with entity bodies is that you need a parser to package the information up in requests or un-package it when receiving responses. This would further complicate things as these parsers would need to be loaded into these consumer devices. What’s interesting is HTTP Headers is they are well understood, across devices, systems, technology stacks etc, and do not require parsers. So if you can get away with sending key/value pairs when sending or receiving messages then this solution should work for you.
Receiving messages from Service Bus generally includes using ‘long polling’ when waiting for messages. Using long polling sockets isn’t a great use of power resources for devices that do not have permanent power sources (devices that rely on batteries). With this in mind, Microsoft has been working with other industry leaders on the AMQP (Advanced Message Queuing Protocol). AMQP is a popular queuing technology that is used in financial brokerage settings. Another benefit of using AMQP is that it has a quieter socket profile which results in lower battery consumption. So this is an area that Microsoft is investing in that will have wide spread benefits….Cool Stuff!!!
Message Channel Patterns
Abhishek was back on point and walked us through some popular messaging patterns including:
- Pub-Sub
- Accomplished via Topics
- Content Based Router
- Using Topics based upon a Subscription Rule
- Recipient List
- Sender wants to send the message to a list of recipients
- Common use-cases
- Order processing systems – route to specific vendors/departments
- “Address LIKE ‘%First%’
- Message Routing
- Session re-sequencer – receiving messages out of order and then using the defer method to postpone processing the next message until you receive the next message that is “in order”
I must admit, when I learn more about the Service Bus I do get a little giddy. I just see it as such an enabling technology. It facilities building applications that just wouldn’t be possible or cost prohibitive in years gone by. Whether it is submitting SAP timesheets remotely or reporting customer power outages it is an amazing technology the opportunities are endless when it comes to bridging data center boundaries.
Mobile + Cloud: Building Mobile Applications with Windows Azure – Wade Wagner
Wade Wagner, a former Microsoft Azure Evangelist, put together a pretty interesting session related to Windows Phone and Azure. To watch this session on Channel 9 click here. In the past I have followed some of the work he did with the Mobile toolkits for the different mobile platforms, but just haven’t had the time to take a closer look.
This session focused primarily on Windows Phone 7 and how it interacts with some of the Azure services (Storage, SQL Azure, Tables, ACS). Personally, I think these technologies complement each other very well. Especially in the area of bridging mobile devices with on-premise LOB solutions and leveraging the Access Control Service (ACS) for authentication.
Three reasons for Device + Cloud
- Allows for new application scenarios
- The cloud levels the playing field
- The cloud provides a way to reach across device platforms and a larger pool of resources from which to pull
Why Azure?
- PaaS you build it, Windows Azure runs it
- Automatic O/S patching
- Elasticity and Scale
- Utility Billing
- Higher-level services
- ACS, Caching, CDN (cache static content), Traffic Manager (route traffic across Azure datacenters based on locale)
Wade then demonstrated a scenario really lends itself well to this technology. A mobile application that will take advantage of Social Identity providers(Windows Live, Google, Yahoo) for authentication via the Access Control Service. Wade demonstrated that this isn’t as complicated as it sounds. With the help of a Nuget package and adding a STS reference we can get this working in the matter of a minutes. Wade then added some additional functionality to consume a ASP.Net Web API. Most presenters would have left their demo there. Giving people the information to build the services but then leaving out some “real world” gaps around security. Wade did take his demo one step further and then showed we can use the ACS service to authorize user requests as well. Before the ASP.Net WebAPI method is called, we can intercept this request and validate that the token that has been included as part of the HTTP Request is a valid ACS token. Provide the token is valid, the appropriate data will be returned.
Wade then wrapped up his session demonstrating how we can use the Azure Push Notification service to serve up “toast notifications”. Another set of useful information that I hope to play with soon.
If you are into mobile apps, you definitely owe it to you to watch this session so you can learn about all of the Azure services that you and your customers can benefit from.
. Basically any new UIs that need to be created will follow the Metro styling but other than that don’t expect many updates to previous tools. 
