Enterprise Library and Azure – What do you want to see?

I'm currently working with the team in Microsoft's patterns & practices group who are in the early stages of a project to create a Windows Azure Integration Pack for Enterprise Library. We're currently looking for feedback about the proposed content (or indeed suggestions for content we haven't thought of), so if you're developing applications for Windows Azure or using Enterprise Library in a current project, go and take a look at what's on the list, and cast your vote for what you'd like to see included here.

Encrypting Connection Strings in Windows Azure Applications

Following on from my previous blog post that talked about data encryption in Windows Azure storage, I now want to take a look at the encryption issues around using SQL Azure, and in particular, connection strings.

Before looking at encrypting connection strings, a reminder of some SQL Azure specific security considerations.

SQL Azure Firewall

You can use the SQL Azure firewall to restrict access to your SQL Azure server, either by specifying a range of IP addresses for external access, or by limiting access to other Windows Azure services only. However you should be aware that limiting access to Windows Azure services still means that anyone who knows your SQL Azure credentials could access your database from their own deployed Windows Azure applications. Restricting access to Windows Azure services doesn’t restrict access to just your subscription.

SQL Azure Authentication

SQL Azure only supports SQL Server Authentication, not Windows Authentication. This means that the username and password you use to connect to SQL server will be stored in the connection string in your Web.config or App.config files.

Vulnerabilities

The focus of this blog post is on what you can do to protect your SQL Azure credentials and your SQL Azure databases from unauthorised access.

There are three locations where someone could potentially discover your SQL Azure credentials from your application’s Web.config or App.config files:

1. From your code base before the application is deployed to Windows Azure.
2. From your deployed Windows Azure application. If someone gains unauthorized access to your Windows Azure account, they may be able to read the contents of your Web.config or App.config files.
3. From a disk drive that has left a Windows Azure datacenter.

If someone gains unauthorized access to your Windows Azure account, they will only be able to read the contents of your Web.config and App.config files if you have already deployed your application with Remote Desktop Access enabled. Remember that you can't add the Remote Desktop Access feature to an application after it has been deployed, and it's unlikely you'd want to use the Remote Access feature in a production environment anyway.

In the previous blog post I referred to Microsoft's policies and procedures that relate to hardware disposal. These policies are designed to ensure that all hard disks from Windows Azure datacenters are either securely wiped or securely destroyed at the end of their life.

The key vulnerability in respect of connection strings in your Web.config and App.config files is therefore before you deploy your application to Windows Azure.

Mitigations

There are two ways that you could mitigate the risk of someone discovering your SQL Azure credentials from your application's source code before it gets deployed to Windows Azure.

• You can implement a process that replaces any connection strings for test and development databases with a connection string for your production database as part of a secure build and deployment process. This way, developers and testers don't need to know the connection string for your production database. Developers and testers can work with test databases that use different credentials from the production database.

• You can use the Pkcs12 Protected Configuration Provider. This enables your SQL administrator to encrypt the connection string in the Web.config or App.config file before giving it to the developers and testers. With this approach, no one other than the SQL administrator needs to know the SQL Azure credentials; this might be important of the person responsible for managing deployment to Windows Azure is different from the SQL Azure administrator. This has the additional advantage that the connection string cannot be read even if someone gains access to the configuration file through either Remote Access or by obtaining a physical disk that has not been wiped or destroyed.

Its important to note that both of these approaches depend on correctly designed and executed procedures for developing, testing, and deploying code to Windows Azure. You should also have procedures in place to ensure that all code (and especially data access code) is fully reviewed before it's deployed to your production system to verify that it doesn't inadvertently expose any secure data when it shouldn't.

Encrypting Data in Windows Azure Storage

A question that seems to keep cropping up is "How to encrypt data in Windows Azure storage?" There some specific factors that determine how (and why) you should do this in Windows Azure.

Before discussing data encryption in Windows Azure, I wanted to recap some background information about Windows Azure storage.

Windows Azure storage

Windows Azure storage includes these three storage types:

• Blob Data
• Table Data
• Queue Data

For the purposes of this article I want to focus on Table and Blob storage. I'm also assuming that the data is going to be used by your Windows Azure application — code running in Worker role or a Web role.

Levels of protection

By default, all data in Windows Azure storage is private. This means that you need a key to get read/write access to the data. Blob storage supports a couple of additional options; you can mark a blob container as "public" so that anyone who knows the URL has read only access, you can also use Shared Access Signatures (SAS) that are special URLs that allow temporary read only access to private blobs without the client needing to know the storage key. For the remainder of this discussion I'm going to assume that we're dealing with private data.

Blob data	Private (default) - needs a storage key for read/write access SAS - generates a temporary, anonymous URL Public - data can be read by anonymous requests
Queue data	Private - needs a storage key for read/write access
Table data	Private - needs a storage key for read/write access

Access to storage keys

To be able to access private data, you need to know the storage key. You can obtain the key from your Windows Azure portal (or by using the Windows Azure Management API). There are in fact two keys: a primary key, and a secondary key. You can use either, but two are provided so that if you want to generate new keys on a regular basis, you can cycle them and ensure that your applications have uninterrupted access to your data.

Each Windows Azure storage account has it's own keys, and you can create a limited number of storage accounts with a single Windows Azure subscription.

If you have a valid key, you have read/write access to your Windows Azure storage from within a Windows Azure role, or from outside (for example, from an on-premises application).

Vulnerabilities

If you are not encrypting data in your Windows Azure storage, you should be aware of the following vulnerabilities and take steps to minimize the risk of someone gaining unauthorized access to your data.

Vulnerability #1

If access to your portal is compromised (someone discovers the Live ID user name and password, or a Management API key), then the storage access keys are discoverable, and all your data is accessible. You should bear in mind that the portal Administrator, all the portal Co-admins, and anyone with a copy of a portal Management API key will have full access to your portal, your storage keys, and your data. There is no granular permissions system in the Windows Azure portal.

You must carefully manage access to your Windows Azure portal; limit access to those who need it, make sure that passwords and Management API keys are changed frequently, and that you enforce strict password policies. For most organizations it will make sense to have multiple Windows Azure subscriptions, with different people having access to each one. For example, you might have Production, Test, and Development subscriptions.

Vulnerability #2

The source code of any application that accesses private Windows Azure storage will also include the storage key — typically the key is placed in a configuration file. This implies that anyone with access your source code will be able to discover the keys and therefore will be able to access your data.

You should carefully control who has access to the storage keys. Ideally, you should use deployment scripts that substitute the storage key values in the application's configuration files in a secure build/deployment scenario. Developers and testers should only have storage keys that enable them to access test data and not production data.

Vulnerabilty #3

If there is a hardware failure in a Windows Azure datacenter, it may be that the hard disk with your data is replaced and the old one disposed of. In this case it's theoretically possible that an unauthorized person might obtain this disk.

However, hardware disposal is governed by Microsoft's Global Foundation Services policy that details procedures for wiping or destroying drives and securely disposing of hardware from Windows Azure datacenters. These policies are designed to minimize the risks of anyone obtaining hardware containing data. See: http://blogs.technet.com/b/gfs/archive/2009/05/27/securing-microsoft-s-cloud-infrastructure.aspx.

Encrypting data

As an additional level of security, you may want to encrypt the data in your Windows Azure storage tables and blobs, so that if someone gained unauthorized access to your portal, your storage keys, or the hard disks that contained your data, then they wouldn't be able to decrypt your data.

Options for encrypting data

• Use symmetric key encryption - you need a single key to encrypt/decrypt data.
• Use asymmetric key encryption - encrypt with public key, decrypt with private key.

Whichever encryption technique is used, your Windows Azure code in the web or worker role will need access to the key. Therefore the key must be stored somewhere in Windows Azure - in a blob, in the code or a configuration file, or in the certificate store.

Vulnerabilities

The vulnerabilities associated with an unauthorized person being able to access and decrypt data from your Windows Azure storage are different from the vulnerabilities associated with simple, unauthorized access.

Vulnerability #1

If the portal is compromised because someone discovers your Windows LiveID credentials or Management API key, then anything stored in a blob or the certificate store is accessible and they will be able to access your encryption key and decrypt your data. However, it doesn't appear to be possible to access the code and configuration files associated with a deployed application in Windows Azure, so storing your private encryption keys in an App.config or Web.config file appears to be the best option.

There are two exceptions to bear in mind: first, the ServiceConfiguration.csfg file is accessible to anyone with access to your portal, so don’t store encryption keys here; second, all your code and configuration files are accessible if you have configured Remote Desktop Access: however, Remote Desktop Access must be configured at deploy time, you can't configure it after you have deployed the application, so you should not enable Remote Desktop Access if you are concerned about unauthorized access to your data.

Vulnerability #2

If someone obtained the physical disk that contains your data because they could easily read any encryption keys in configuration files or blobs, and the encrypted data; in this case you must rely on Microsoft's procedures for protecting the Windows Azure datacenters and for wiping and destroying disks that have been removed from a Windows Azure datacenter.

Vulnerability #3

If you choose to store your encryption key in a Web.config or App.config file, you must also address the issue of how to protect the encryption key before it is deployed to Windows Azure. Anyone with access to the source code will have access to the encryption keys and therefore to the encrypted data. Ideally, your build and deployment process should replace any test or development encryption keys with production keys just prior to deployment in a secure build environment. This way, you can limit who has access to the production encryption keys.

Vulnerability #4

A final issue to consider is that a developer could inadvertently (or maliciously) deploy code that accesses your encrypted data and exposes in way that you didn’t intend. If your build and deployment process replaces test or development encryption keys with production encryption keys, then any deployed code could still access the decryption keys at run time and access the encrypted data. There are a number of steps you should take to mitigate this risk:

• Ensure that all code changes are traceable to individuals.
• Ensure that all code is reviewed before it is deployed.

Writing Secure Code for Windows Azure

This blog post has focused specifically on issues relating to Windows Azure storage and encryption; for a more general discussion of writing secure applications for Windows Azure see "Security Best Practices For Developing Windows Azure Applications."

You should also take a look at the Security Development Lifecycle (SDL).

Summary

If you decide to encrypt your data in Windows Azure storage, then to minimize the risk of someone gaining unauthorised access to your encrypted data, you should store the encryption key in the Web.config or App.config file in your application. However, you should make sure that your development and deployment processes are designed to minimize the risk of someone discovering your encryption keys before you deploy your application to Windows Azure.

Testing Applications that use the AppFabric Caching Service in the Compute Emulator

One of the recent additions to the set of cloud services available as part of the Windows Azure Platform is the AppFabric Caching Service, and one of the interesting features of the AppFabric Caching Service is an ASP.NET session state provider. This is interesting because it offers a web-farm friendly session state provider, so if you deploy multiple instances of your Windows Azure web role, you now have a working, out-of-the-box, production quality session state provider (previously, if you deployed multiple instances, you had to implement your own, web-farm aware session management in your web role).

Using the AppFabric Caching Service session state provider in your Windows Azure application is simple. First, you need to set up a cache namespace using the Windows Azure portal:

Second, you must modify your application’s Web.config file with the necessary configuration to point to your new cache. This is easy to do, because you can copy and paste the necessary XML from the portal — just click on the View Client Configuration button:

That’s it, no code changes are necessary for your application.

Once you’ve created your cache and updated your Web.config file, you’ll want to test it out. Probably, you’ll want to initially test it out using the local Compute Emulator rather than deploying your application to Windows Azure — so make sure that you configure two or more instances of your web role, and try it out. Unfortunately, you’ll find that it doesn’t work: when the local Compute Emulator switches to another instance, your session state disappears (and reappears if you are switched back to the original instance). It may help to display the current instance id somewhere in your UI to keep track of what’s happening, for example:

Instance: <%=RoleEnvironment.CurrentRoleInstance.Id  %>

It turns out that that the problem lies with the local Compute Emulator and the default settings for the session state provider. By default, the session state provider uses the value of HttpRuntime.AppDomainAppId when it builds its cache keys, and each instance in the local Compute Emulator has a unique value. If you add an additional attribute, applicationName, to your configuration, the session state provider uses this value instead of the value of HttpRuntime.AppDomainAppId and now everything works as it should:

<sessionState mode="Custom" customProvider="AppFabricCacheSessionStoreProvider">
   <providers>
      <add name="AppFabricCacheSessionStoreProvider"
          type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache"
          cacheName="default"
          applicationName="MyAppName"
          useBlobMode="true"
          dataCacheClientName="default" />
   </providers>
</sessionState>

This problem only manifests itself in the local Compute Emulator, you don’t need to use the applicationName attribute when you deploy your application to Windows Azure, although it doesn’t do any harm if it is there.

Another Cloud

Windows Azure and Amazon EC2

Having spent some time working with Windows Azure, I wanted to take a look at some of the other cloud environments out there to get a feel for how they work and how they differ in approach. The first platform I decided to take a look at was the Amazon Elastic Compute Cloud (EC2).

Amazon’s cloud offering is a little different from Microsoft’s — where Windows Azure is a platform and a specially designed framework that allows you to run specially written applications in the cloud, Amazon EC2 allows you to run standard operating systems virtual environments on Amazon’s servers. So two trade-offs spring immediately to mind:

1. Windows Azure offers you a single fixed environment as against EC2’s almost completely free choice of operating systems (including Windows). Note that the latest Windows Azure release also includes Virtual Machine Roles in addition to the existing Web and Worker roles, so that you can run your own virtual machines in the cloud.
2. The Windows Azure platform manages all the scalability issues for you (because of the features built in to the platform), whereas with Amazon EC2 you have to do a lot of the work if you want to build a scalable application that can run across multiple virtual machines. Although Amazon does offer an auto scaling service that can start up (or shut down) virtual machine instances for you based on demand, and a MapReduce service (for a description of the MapReduce algorithm and how to implement it in Windows Azure, see here) that’s designed to process large amounts of data on demand.

That said, there are a lot of similarities between the two platforms as I’ve outlined in the following table:

Windows Azure	Amazon Web Services	Notes
Content Delivery Network (CDN)	Amazon CloudFront	Both provide high-speed edge caches for static data, used for example to host video or other media for your cloud application.
Windows Azure Table Service	Amazon SimpleDB	Schema-less table storage.
SQL Azure	Amazon Relational Database Service (RDS)	SQL Azure is SQL Server in the cloud, Amazon RDS is MySQL in the cloud.
AppFabric Service Bus	Amazon Simple Queue Service and Amazon Simple Notification Service	Hosted queue services enabling  computers to exchange data through a cloud-hosted message hub.
Windows Azure Connect	Amazon Virtual Private Cloud	Creating virtual private networks that connect on-premises computers with your cloud instances.
Windows Azure Blob Storage	Amazon Simple Storage Service (S3)	Facility to allow you to store arbitrary data in the cloud.
Windows Azure Drive	Amazon Elastic Block Store	Storage that can be formatted and used like hard drives by your cloud application.

 

Daily News

Earlier this year I purchased a Kindle ebook reader which has been fantastic as a way to carry around books and reference material. However, one area that I was slightly disappointed with was the subscriptions to newspapers and journals that are available on the Amazon site. I soon found that I could generate my own news digests from just about any source by using an open source tool called Calibre. Once I customized the news feeds that I wanted to read on my Kindle, I can use Calibre’s command line interface to generate the file containing my news and email it direct to the Kindle. This is all great, except for the fact that I need to have the machine that generates the Kindle news feed using Calibre running. Most of the time it is running, but if on occasion I’m away from home without my laptop, it would still be great to get my daily fix of news delivered to my Kindle.

Calibre is very smart in the way that it generates ebooks containing news if you don’t mind doing a bit of python scripting, so I wanted to carry on using Calibre. Running Calibre on an Amazon EC2 virtual machine seemed like a good way to automate sending out daily news from an always on machine, so this gave me a reason to investigate how easy this would be to achieve with Amazon EC2.

Setting up my Cloud Machine with Amazon EC2

After signing up for EC2, the first decision was what operating system to use. Amazon currently has an AWS Free Usage Tier offer, which is only free if you use a Linux operating system, so Linux it was. However I was then faced with choice of several hundred different base virtual machines of various different flavours of Linux. Ubuntu seemed to be the most popular, and a bit of googling soon revealed which were the “official” Ubuntu machine images.

Running my instance of Ubuntu on Amazon’s servers was a simple as selecting the base machine image and clicking the launch button in the web console (making sure I used a micro instance to make sure I stayed on the free usage tier). The Public DNS value is the machine’s DNS name.

The next step was to connect to my virtual machine, which involved some security configuration. First of all I needed a key and this was generated for me when I launched the virtual machine, secondly I needed to open up the virtual machine’s firewall to allow me administrative access so I added an entry on the Security Group page to enable SSH.

My only stumbling block came when I tried to connect to the virtual machine using Putty as an SSH client in Windows in that Putty didn’t recognize the key that EC2 had generated for me when I launched the virtual machine. It turned out that I needed to convert the key to a different format by using Puttygen. With that sorted out I could run a command shell on the virtual machine, and copy files to and from the virtual machine using PSCP.

Installing Calibre on Ubuntu turned out to a single command:

sudo apt-get install calibre

Finally I could set up a scheduled command using crontab to generate and email my Kindle newsfeed every day at 6am.

Conclusions

To summarize what I learnt from my first use of Amazon EC2:

• Setting up a virtual machine in the cloud is very straight-forward with the Amazon Web Services web-based management console. It also looked as if would be quite simple using the command line tools.
• Choosing a suitable base operating system is more difficult. Someone else has installed the OS and a selection of software before you start, you really need to know your way round the OS to be sure that it’s secure and properly configured. In fact you probably want to install it yourself, which is possible, but a bit more complicated. Also, it’s down to you to make sure everything is kept up to date with patches etc.
• Given the choice of operating systems available, you can run just about any piece of software you like (even applications with GUIs if you use technologies like Remote Desktop or VNC). However, there’s no guarantee that it will scale — in order for an application to scale it must be able to run in multiple virtual machines simultaneously, and probably be designed to use one or more of the scalable storage services like Amazon SimpleDB or Amazon Simple Storage Service.

Where Next with the Cloud?

I’ve spent most of this year embedded with a team run by Eugenio Pace in the patterns & practices group at Microsoft working on three books (with more to come). The first two have already been published — see the links on the right. You can also view the content on MSDN: Moving Applications to the Cloud on the Microsoft Windows Azure Platform Developing Applications for the Cloud on the Microsoft Windows Azure™ Platform The first book includes an introduction to the Windows Azure Platform, and then describes how the fictional Adatum company migrates its existing ASP.NET expense reporting application to the cloud. The book looks at the mechanics of how Adatum performs the migration as well as examining the significant design decisions made by Adatum, the trade-offs it had to consider, and the cost implications. For example, the original, on-premises application used SQL Server as its data store. Adatum had to decide whether to go with SQL Azure for the cloud-based version of the application, which would be simple to implement, or expend more development effort to port the storage functionality in the application to Windows Azure table and blob storage. The second book describes a “green field” scenario where the fictional Tailspin company is developing an online surveys application. With a new application, Tailspin in not constrained by any existing design decisions or implementation choices, but can chose which features of the Windows Azure platform to use. The design decisions addressed in the book include how to make the Surveys application a multi-tenant cloud application, and how to make the application scale on demand (for example to handle a customer creating a survey that they expect to get a million responses to in the week before Christmas). The Tailspin Surveys application will make a reappearance in a forthcoming book on Windows Phone 7 development, where a Windows Phone 7 device will become a client application enabling users to complete surveys on their phone. Both books also have companion, downloadable code that you can use to explore exactly how these two companies chose to implement their applications for the Windows Azure platform, and hands-on labs that will guide you through some of the specific areas of the the implementations. Next year, there will be third book on Windows Azure that will provide coverage of some of Windows Azure platform functionality not used by Adatum and Tailspin, for example the Access Control Service, and bring things up to date with some of the new features appearing in in the Windows Azure platform.

Live Mesh Part 2

In my previous entry about Live Mesh I mentioned that you could use it to transfer data to and from the cloud in addition to straightforward file-sync operations.

To develop Mesh enabled applications you need to sign up to the Mesh developer site, but this is straightforward. You do need to remove the Live Mesh client to install the Live Framework Client and connect to https://developer.mesh-ctp.com rather than http://www.mesh.com, but presumably this will be rectified for final release You can download the SDK from here.

In the Live Framework SDK there are samples to demonstrate Mesh functionality. The Live Folders sample creates, edits and deletes files from the Mesh. These files and folders appear exactly the same as the synchronized folders created with Live Mesh. I would expect that long term you could synchronize with these folders, but at the moment the Live Framework Client is sandboxed and does not support the synchronization or remote control features of Live Mesh.

The following code creates a Live Mesh folder and you can see that the resource type is LIVE_MESH_FOLDER:

public static string CreateRootFolder(Mesh mesh, string title)

{

// Check if a folder with the same name exists.

foreach (MeshObject oneObject in mesh.MeshObjects.Entries)

{

if (oneObject.Resource.Title.Equals(title))

{

return "Folder already Exists!!!";

}

}

// Create folder object

MeshObject meshObject = new MeshObject(title);

// It is a mesh folder

meshObject.Resource.Type = MeshConstants.LIVE_MESH_FOLDER;

// Add folder to collection of mesh objects

mesh.MeshObjects.Add(ref meshObject);

// Create feed for files (required)

DataFeed fileDataFeed = new DataFeed(MeshConstants.LIVE_MESH_FILES);

// Set type and handler type (required)

fileDataFeed.Resource.Type = MeshConstants.LIVE_MESH_FILES;

fileDataFeed.Resource.HandlerType = MeshConstants.FILE_HANDLER_TYPE;

// Add new data feeds to collection

meshObject.DataFeeds.Add(ref fileDataFeed);

//this.LoadMeshObjects();

return "Root folder " + title + " created successfully";

}

There is also a Project Manager sample in the SDK. This is a simple application to create projects and milestones. It creates non-standard objects in Mesh. As you can see in the project code below, you can create your own class of object and are not constrained by standard folders and files:

///

/// UUID of the parent MeshObject
///
[DataMember]
public string MOID { get; set; }
///

/// Title of the milestone (during save/update, this matches MeshObject.Resource.Title,
/// but is stored here when the custom object is databound instead of the resource)
///
[DataMember]
public string Title { get; set; }
///

/// Date when project will be started
///
[DataMember]
public DateTime KickOffDate { get; set; }
///

/// Estimated Date for Completion
///
[DataMember]
public DateTime CompletionDate { get; set; }
///

/// Date when project was shipped
///
[DataMember]
public DateTime ShippedDate { get; set; }
///

/// Description of Project
///
[DataMember]
public string Description { get; set; }

When you deploy a Mesh application it appears both on the users Live Mesh website and also as a shortcut on their desktop. In this way, a user can just run the app without any knowledge of Live Mesh. Furthermore, because the data is synchronized between the local machine and the cloud, they can run the application when they are disconnected and it will automatically synchronize when connected although there is no conflict resolution built in.

This does come with some caveats. This is currently CTP and is not fully functional. As previously mentioned the developer environment does not currently integrate with the Live Mesh client. Also every time I tried to run an application from the desktop it said it was waiting for me to sign in with no opportunity for me to do so and regardless of whether I was signed in or not. There is also a risk that this is a solution waiting for a problem. It looks interesting, it’s quick and straightforward to Mesh enable applications, but there needs to be a compelling requirement for this to go beyond the trying out samples stage and into developing real applications.

In the code samples above, these are just snippets of the complete solution, but you can see that Live Mesh has both straightforward user file and folder synchronization, as well as an API to enable you to create a cloud-based solution.
As a final note, I looked into this as a way to synchronize favorites in IE8. You can now do this by signing up to SkyDrive and reinstalling the Live Toolbar.

Live Mesh

I came across a new Windows Live component the other day called Live Mesh
when searching for a way to synchronize my favorites. In IE7 you could synchronize favorites with Live Favorites. It worked pretty well, although by no means perfectly. This functionality was removed from IE8, which annoyed me somewhat. I work from home most of the time, but occasionally go into the office and take a laptop. Virtually all documents I use are checked into SharePoint, so I don’t lose any data when I switch machines, however there are always useful bits and pieces that I pick up on the Web and I usually just add these to favorites. This is where the upgrade to IE8 is giving me problems. Not insurmountable, obviously, but I want everything to work smoothly. A blogger called Laurent Duveau has used Live Mesh to do just this. Looking further into Live Mesh made me realise its other capabilities. It interested me through a connection with the Azure Services Platform, of which it is a part, and through its data synchronization and remote control functionality.
Live Mesh allows you to synchronize folders with the cloud. You set up a device and then simply right click a folder to begin synchronizing data. This sounds a bit like functionality already provided by Live Sync and SkyDrive, however Live Sync requires both computers to be connected at the same time and SkyDrive is just online storage with no more advanced functionality.

So what more does Live Mesh offer? Well, for a start, the whole process is automatic and painless. You add a folder and the folder is synched. You can add another device and keep the data synched across multiple devices. These devices will include Windows Mobile and Apple Macs in the future. The data is both held locally, so that it can be accessed offline, and in the cloud, so that it can be accessed anywhere. This solved my favorites problem, but also made me curious as to the capabilities of Live Mesh.

Other features include remote desktop. Now not only do I have all my data synchronized, I can also connect to my desktop PC from anywhere. So far, these are all features available with the use of a few tools, but there is another trick up the Live Mesh sleeve. There is a Live Framework with various APIs including .NET, Silverlight and JavaScript to use Live Mesh services. This not only allows you to share folders as you normally would with Live Mesh, but also allows any data to be stored and synchronized between devices. I’ll leave the Live Framework for another day, but it appears to offer interesting possibilities.

Of course, this is a beta, but when the minor errors are ironed out this could be a valuable data synchronization tool.

The Service Bus

The Service Bus is one of the three .NET services available as part of Azure Services platform. At first sight there seemed to be a slightly daunting array of options for using the Service Bus, so here is a first attempt to try and pull the most significant elements together (with some notes after the table). For more detail check the original documentation which can be found here.

Service Bus Bindings (1)	.NET 3.5 WCF Equivalent Binding (2)	Optional HTTP connectivity mode (3)	Multicast Event Distribution	One-way Binding	Default Settings	Uri Scheme (8)	Client (Sender) Channels	Service (Listener) Channels	Data Channel Protection SecurityMode options	Client and Service Authentication (6)	Reliable Messaging
BasicHttpRelayBinding	BasicHttpBinding				SOAP 1.1 WS-I Basic profile 1.1	http https	80 443	Pair of secure socket connections to the cloud listener (5)	Transport TransportWithMessageCredential	Yes	No
NetEventRelayBinding	N/A	Yes	Yes N publishers M listeners	Yes	SOAP 1.2 over TCP .NET Framing .NET Binary Serialization	sb	808 or 828 SSL	828 SSL or HTTP (3)	Transport TransportWithMessageCredential	Yes	No
NetOnewayRelayBinding	N/A	Yes		Yes	SOAP 1.2 over TCP .NET Framing .NET Binary Serialization	sb	808 or 828 SSL	828 SSL or HTTP (3)	Transport TransportWithMessageCredential	Yes	No?
NetTcpRelayBinding	NetTcpBinding				SOAP 1.2 over TCP .NET Framing .NET Binary Serialization	sb	SSL protected only in Relayed mode (7) Choice of connectivity modes: Relay, Hybrid, Direct (9)	SSL protected only in Relayed mode (7) Choice of connectivity modes: Relay, Hybrid, Direct (9)	Transport TransportWithMessageCredential	Yes	Yes (CTP version doesn't support this for Hybrid and Direct)
WebHttpRelayBinding	WebHttpBinding				Plain HTTP messages Support for XML and Raw (binary) message encodings - supports REST	http https	80 443	Pair of secure socket connections to the cloud listener (5)	Transport	Yes	No
WS2007HttpRelayBinding	WS2007HttpBinding				SOAP 1.2 Latest OASIS standards for Reliable Message Exchange and Security	http https	80 443	Pair of secure socket connections to the cloud listener (5)	Transport TransportWithMessageCredential	Yes	Yes
WSHttpRelayBinding	WSHttpBinding				SOAP 1.2 Draft WS-* standards for Reliable Message Exchange and Security as available at release of WCF 3.0	http https	80 443	Pair of secure socket connections to the cloud listener (5)	Transport TransportWithMessageCredential	Yes	Yes

Service Bus Bindings (1)

These are currently the available bindings in the .NET Services December 2008 CTP. Recommended binding is NetTcpRelayBinding.

.NET 3.5 WCF Equivalent Binding (2)

For the most part the 'Relay' bindings work in the same way as their standard WCF counterparts, except that the listeners are created in the cloud.

Optional HTTP connectivity mode (3)

Features the ability for a receiver to operate using just ports 80 and 443 if connectivity is locked right down. It implements a polling system to check for new messages.

ConnectivityMode

• ConnectivityMode.Tcp: In this mode, all one-way and event communication is relayed over outbound TCP ports 828 and 808. SSL-secured traffic uses port 828, while unsecured traffic uses port 808.
• ConnectivityMode.Http: In this mode, all one-way and event communication is relayed over outbound ports 80 and 443 using HTTP or HTTPS. This mode is the backup communication option for environments where outbound communication is constrained to HTTP/HTTPS, where outbound ports 808 and 828 are not available, or where the service/client cannot resolve external DNS names.
• ConnectivityMode.AutoDetect: This mode automatically selects between the ConnectivityMode.Tcp and ConnectivityMode.Http, and favors TCP if it is available.

Listener Connection (5)

The SSL-protected control channel is using outbound TCP port 828, and the data channel is using outbound port 818. The data channel is SSL-protected if the endpoint URI scheme is "https" and the Security.Mode property is set to one of the EndToEndBasicHttpSecurityMode values Transport or TransportWithMessageCredential.

Security.Transport.RelayClientAuthenticationType (6)

This property controls whether clients of a service are required to present a security token issued by the Access Control service to the Service Bus service when sending messages. Services (listeners) are always required to authenticate with the Access Control service and present an authorization token to the Service Bus. If the service (listener) wants to take over the responsibility of authenticating/authorizing clients, it can opt out of the integration between Access Control and Service Bus by setting this property to RelayClientAuthenticationType.None. The default value is RelayClientAuthenticationType.RelayAccessToken.

Transport Channel Protection (7)

The transport channel protection guards all traffic to and from the Relay, but the data is visible to (but not observed by) the Service Bus infrastructure at the socket relay point. You can employ message security (Security.Mode=EndToEndSecurityMode.Message) to ensure that payload data is protected end-to-end without ever becoming visible to a third party (including the Service Bus infrastructure) at any waypoint.

Uri Scheme (8)

• sb implies WCF on the client.
• http/https support non-WCF clients.

Choice of connectivity modes (9)

1. TcpConnectionMode.Relayed: In this mode, all communication is relayed through the Service Bus cloud. The SSL-protected control connection is used to negotiate a relayed end-to-end socket connection that all Client-Service communication flows through. After the connection is established, the Service Bus infrastructure acts much like a socket forwarder proxy relaying a bidirectional byte stream.
2. TcpConnectionMode.Hybrid: In this mode, communication is relayed through the Service Bus infrastructure while the Client and Service endpoints negotiate a direct socket connection to each other. The coordination of this direct connection is governed by the Service Bus cloud service. The direct socket connection algorithm is capable of establishing direct connections between two parties that sit behind opposing Firewalls and NAT devices. The algorithm uses only outbound connections for Firewall traversal and relies on a mutual port prediction algorithm for NAT traversal. Since the NAT traversal algorithm is dependent on a very narrowly timed coordination and a best-guess prediction about the expected NAT behavior, the algorithm tends to have a very high success rate for Home and Small Business scenarios with a small number of clients and degrades in its success rate with larger NATs. If a direct connection can be established, the relayed connection is automatically upgraded to the direct connection without message or data loss. If the direct connection cannot be established, data will continue to flow through the Service Bus Relay.
3. TcpConnectionMode.Direct: This mode is identical to TcpConnectionMode.Hybrid in the .NET Services December 2008 CTP. In a future release, this mode will use the direct connection only once and, if established, never relay any application data through the Service Bus Relay.