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.

Windows Azure AppFabric Cache Released (April 29th 2011)

Download the April Update for the SDK here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=39856a03-1490-4283-908f-c8bf0bfad8a5

More detals can be found here on the Windows Azure Blog:

http://blogs.msdn.com/b/windowsazureappfabric/archive/2011/04/10/windows-azure-appfabric-caching-availability-announced.aspx

Internal Endpoints and Firewall Rules with Windows Azure

I’ve learned a new lesson this past week on how Windows Azure configures firewall rules on the guest firewalls.

Configuring an internal endpoint creates the following rule in the guest OS:

•         NetTcpActivator
•         System
•         NetTcpPortSharing
•         CIS:{some-guid-representing-your-worker-role}

 Remote IP’s allowed are all of the role instances in your deployment.

The rule is configured to allow traffic for whatever port or port range you specified as the internal endpoint.

Many people have seen that “sometimes” the internal endpoint doesn’t work like they believe it does and that they have to manually open the port use netsh advfirewall firewall ……

The answer is the rule created by specifying the internal endpoint only applies to processes created from the role itself.

 So if you are creating a service and another process outside of the worker role is starting it you will not be able to access that service from the specified endpoint. In scenarios like this use the ServiceController class (in an elevated role of course) to start the service. http://msdn.microsoft.com/en-us/library/sywbez17(v=vs.71).aspx 

For regular processes use the Process.Start() method. Both methods will allow other roles to access your endpoint without additional firewall configuration steps.

If you can’t control the starting of the service (such as COM+) you might have to open up some ports on the guest firewall through an elevated startup task – something like:

netsh advfirewall firewall add rule name=”YourRuleName” dir=in action=allow protocol=TCP localport=<yourport>