Day 11 - Windows Azure Platform - Azure AppFabric Caching

by Kev Ritchie 11. December 2010 00:01

 

On the 11th day of Windows Azure Platform Christmas my true love gave to me the Windows Azure AppFabric Caching Service.

What is the Windows Azure AppFabric Caching Service?

The Caching Service is a collection of distributed in-memory caches that contain frequently accessed data from your Windows Azure application, the key being to improve application performance.

So how do you use it?

Well, to be able to use caching you first need to store data, to do this you need to programmatically insert the data into the caches using the Caching API.  With your frequently accessed data stored in the cache, you use a pattern called cache-aside to access it.  What this means is that you first check the cache for data before going to the database to retrieve it; here’s our performance improvement Smile.  What if the data isn’t in the cache?  Easy, retrieve it from the database and store it in the cache, so the next time your application needs the data, it gets it directly from the cache.

The great thing about using the Caching Service is that because it’s in the Cloud, your cache is distributed to multiple Windows Azure Instances giving you scalability, availability and fault tolerance, all of which is automatically configured and administered for you.  Less Work! Smile

Caching is not a new concept, but the provision of caching through the Cloud is and is a welcome feature to the increasingly popular Platform as a Service.

Tomorrow’s installment:  The Azure Marketplace, links and stuff

P.S. If you have any questions, corrections or suggestions to make please let me know. 

Day 10 - Windows Azure Platform - Azure AppFabric Access Control

by Kev Ritchie 10. December 2010 00:01

 

On the 10th day of Windows Azure Platform Christmas my true love gave to me Windows Azure AppFabric Access Control.

What is Windows Azure AppFabric Access Control?

It’s very common these days to have an application that integrates with other services like Facebook, Google, Windows Live ID, AD FS (Active Directory Federation Services) 2.0 and Yahoo.  The complexity of this comes in when you have to control the different types of identity tokens that the Identity Service Providers of these services return when you attempt to log in.  The Access Control Service was provided to allow your application to have a single point of sign on and authorisation, so that you don’t have to worry about the different types of tokens provided by these Identity Service Providers.

So how does it work?

Let’s say you’ve developed an application that integrates with Facebook.  The first thing your application would do is authenticate itself with the Facebook Identity Service Provider with the e-mail address and password you provided.  The Facebook Identity Service Provider would then pass back a token to your application which would then be passed on to the Access Control Service.  When Access Control receives the token, it validates it to make sure that it did come from Facebook, it then; based on rules defined by the application’s administrator in the Access Control Rule Engine, creates a new token which is passes to your application.  Finally, your application processes this token to make sure that it was sent from Access Control and completes the sign on process.

This does seem like a more complicated process, but what’s key here is that regardless of Identity Service Provider, Access Control will serve up one familiar defined token to your application.  As a developer, that is sooo much better! Smile  Think of all that complexity that’s just been removed.

For a bit more information and some samples, why not visit CodePlex

Tomorrow’s installment: Windows Azure AppFabric - Caching 

P.S. If you have any questions, corrections or suggestions to make please let me know. 

Day 9 - Windows Azure Platform - Azure AppFabric Service Bus

by Kev Ritchie 9. December 2010 00:08

 

On the 9th day of Windows Azure Platform Christmas my true love gave to me the Windows Azure AppFabric Service Bus.

What is the Windows Azure AppFabric Service Bus?

Before I jump in and waffle on about the Service Bus.  I’ll mention a little bit about Windows Azure AppFabric; what it is and what it does.

Windows Azure AppFabric is a platform made up of three services; Service Bus, Access Control and Caching.  The purpose of this platform is to provide you with a way of building and managing, reliable, secure applications that run on Windows Azure.

So, back to today’s topic; Service Bus.

It’s quite common these days to expose services to the internet that allow applications; that either you or a third-party has created, to access data within a secure network.  To allow this kind of infrastructure to work you would need to set up your service on a public facing server with ports and holes punched through a firewall and maybe some NAT policies to allow connections in and out.

The Service Bus was built to relieve the aches and pains of setting up such an infrastructure.   So, how does it work?

Let’s say for an example you want to expose data using a WCF Service.  First, you would register an endpoint between your service and the Service Bus.  When this endpoint is created, the Service bus automatically creates its own corresponding endpoint.  The Service Bus then assigns you a URI (Uniform Resource Identifier) root, below which you can create any hierarchy you like.  This allows your endpoints to be assigned specific discoverable URIs.

Now, if an application; either in the Cloud or somewhere else, contacts the Service Bus with a specific endpoint URI, the Service Bus takes that URI and finds the appropriate endpoint registered with your service.  This request process uses the Atom Publishing Protocol (http://bitworking.org/projects/atom/rfc5023.html) which returns an AtomPub service document with references to the endpoints the Service Bus exposes.  Once the application has this document it can invoke calls to the Service Bus which in turn relays these calls through to the appropriate service; the WCF Service registered at the start of this example

This all sounds great, but how does this get past setting up firewalls etc.?

The service that you register with the Service Bus opens a TCP connection with the Service Bus (this is important).  This connection is then held open by the Service Bus, which fixes two issues raised earlier; NAT and Firewalls.  NAT is no longer an issue because traffic on the open connection with Service Bus will always be routed to the service/application.  Firewalls are no longer an issue because the connection was initiated from inside the network; an important point made earlier.

For all you security peeps out there, the Service Bus only exposes one IP Address which means you don’t have to expose multiple addresses, limiting the surface for attacks.

In this post I’ve talked about using WCF Services to expose data to the outside world, but you can also use other technologies like Java to expose data or application functionality; you just need to make sure you communicate with TCP, HTTP or HTTPS.  Simples Smile

The Service Bus also provides a message buffer service, which allows the queuing of messages up to 256 kilobytes, which are persisted to disk and can be read by the service at a later point; they’re also replicated which means fault tolerance, a major feature of the Windows Azure Platform.

Exposing services or applications is never a simple task, but what I’ve tried to show you is that it’s very simple to implement with the Service Bus.  This is the one feature that keeps appearing in each component of the Windows Azure Platform; simplicity!  It’s there to make your job simpler, so all you focus on as a developer is the application.

Tomorrow’s installment: Windows Azure AppFabric – Access Control

P.S. If you have any questions, corrections or suggestions to make please let me know.

Powered by BlogEngine.NET 2.5.0.6
Theme by Mads Kristensen | Modified by Mooglegiant