COM+ and Serviced Components within Windows Azure

This post is the first in a series that discuss running COM+/Serviced Components within Windows Azure.

The primary reason for even bringing up this topic is COM+/MTS has been around for a VERY long time and we are well aware that there is a lot of existing code investments that companies do not want to just “throw away”. Having said that it is important to point out that Windows Azure is very different from the typical environment that most COM+ applications were originally designed for.

Data Access

The number one thing to consider when considering moving COM+ to the cloud is your data. Where will it live? Moving your data to the cloud with SQL Azure will likely be your first choice. Consider though that SQL Azure does not currently support distributed transactions (For Reference). Many people used COM+ specifically for handling distributed transactions so this will require some careful thought as to whether you should change your transaction model from [AutoComplete] or SetComplete/SetAbort to using SqlTransactions and some manual transaction handling for other resources. Other options are building hybrid models where the data access is handled on premises and accessed through Windows Azure Connect or Windows Azure AppFabric Service Bus.

Authentication

In Windows Azure by default there is no Active Directory. So if you are currently performing role based authorization in COM+ then you will want to look into using Windows Azure Connect to domain join the roles that are hosting your COM+ package.

Deployment

Deploying COM+ objects to the cloud can be tricky. At a minimum you will be deploying an msi file if you are deploying a native COM+ object. If you are deploying managed code you will likely be scripting out regsvcs.exe on your assembly. If you are deploying remotely to a worker role and calling from a web tier you will be deploying the application proxy AND the COM+ object. Not to mention there will be some firewall configuration needed. I’ve written a PowerShell script that makes this easier that I will post shortly. I’m 100% positive it will not cover all scenarios but it might be a good start.

Deploying a ServicedComponent in Windows Azure

Topology

In an enterprise environment it is pretty easy to code against a remote object because you know ahead of time what the server name or the IP address will be. In the cloud this is not the case. Instances come and go so changing your client code to dynamically discover where your objects live will be important.

Queued Components

MSMQ is not currently supported in Windows Azure due to the lack of durability of disks. So queued components is another scenario that currently is not suitable to run up in the cloud. Alternatives for queued components are Windows Azure Queues and AppFabric Service Bus queues. Depending on the level of functionality needed one should suit your purpose.