[This article was contributed by the AppFabric team.]

In the Windows Azure AppFabric May 2011 CTP, we released enhancements to Service Bus including the new message-oriented middleware features around Queues and Topics. More details regarding these features can be found here: Introducing the Windows Azure AppFabric Service Bus May 2011 CTP. These enhancements will go live with an update to the commercially available service in a few months.

Currently we have two versions of the Access Control service in our production environment: the January 2010 version and the April 2011 version. More details regarding this can be found here: Windows Azure AppFabric April release now available featuring a new version of the Access Control service!.

Until the production Service Bus is updated it continues to use the January 2010 version of the Access Control service. But once Service Bus is updated it will also be able to use the new April 2011 version of the Access Control service. Once the Service Bus update goes live we strongly recommend to customers to update their Service Bus solutions to use the new version of the Access Control service for two reasons:

1. Service Bus will cease to use the older version of the Access Control service at some point in the future. In compliance with our lifecycle support policies for Windows Azure, we will provide you with 12 month notice before this event.
2. The April 2011 version of Access Control has great benefits as noted in the blog post referenced in the above.

Following are explanations on the current state, what will change once Service Bus gets updated, and how you can prepare.

Current state in the production environment

In the Windows Azure AppFabric Management Portal, the two versions of Access Control are labeled ACSV1 for the January 2010 release and ACSV2 for the April 2011 release.

Today when you create a new Service Bus namespace, a matching ACSV1 namespace is automatically created with the namespace suffix “–sb”. This ACSV1 namespace is used by Service Bus.

The two versions of the Access Control service support the same protocol and authorization token format that is expected by Service Bus today (OAuth WRAP SWT), and are fully compatible for all runtime operations. However, ACSV2 supports a new, richer management service protocol based on OData. While the two services are runtime-compatible, they are not compatible for code performing automated setup of access control rules and service identities via the management service.

Following the Service Bus update

For backwards-compatibility with existing applications, Service Bus namespaces that exist in the production environment at the time of the update will not be automatically switched over to ACSV2, and will continue to use ACSV1. You will need to migrate these namespaces from ACSV1 to ACSV2 on your own, coordinated with updates to your code that calls the management service.

As we update the service in a few months, we will provide tooling and step-by-step guidance for how to perform the migration from ACSV1 to ACSV2.

While we will provide detailed guidance as we release the update, the migration process will generally involve the following test-then-migrate sequence of steps:

• First, you will create a brand-new, temporary Service Bus namespace that will automatically come paired with an ACSV2 namespace. This namespace will be used for end to end testing of your application with ACSV2, including your updated code to call the management service.
• Using a to-be-provided command line tool, you will copy the state of your production ACSV1 namespace into the temporary ACSV2 namespace. Your production Service Bus namespace and corresponding ACSV1 namespace will remain untouched during this process. You can now test your application and updated code against the temporary Service Bus and ACSV2 namespace to ensure everything works as expected.
• After you have verified that your application works as expected, you will use the to-be-provided command line tool to change the DNS name of the temporary ACSV2 namespace to be the name of the ACSV1 namespace associated with your production Service Bus – effectively swapping the V2 namespace into the place of the existing V1 namespace. This completes the migration.

Running applications should not experience any service disruption resulting from this switch.

The version differences and migration will mostly affect applications that automatically provision rules in ACSV1 using the management service. Since the management service differs between ACSV1 and ACSV2, the guidance will suggest a process that can be outlined as follows:

• As you prepare for the switchover, you should have a mode in your application, or a procedure in your operations process, that allows you to temporarily suspend automated creation of rules. This may be a simple notice to operations staff or may require some work in your application.
• Immediately before you copy rules to the temporary namespace for the final time before making the DNS name change, you should engage this suspension mode so that no new rules are created in the ACSV1 namespace that end up being orphaned after the data migration.
• After you have switched to ACSV2, you can resume automated creation of rules by having your code target the new ACSV2 management service.
• We suggest that you have both, the ACSV1 and the ACSV2 client code existing in your application side-by-side and that you switch between the code paths using a simple check against an HTTP URL. If a simple GET request against the ACSV2 management endpoint https://tenant.accesscontol.windows.net/v2/mgmt/service yields an HTTP status code 404, the application runs against ACSV1, otherwise it already runs against ACSV2.

How to prepare

Our LABS environment at already includes the enhancements to Service Bus, as well as the new version of Access Control. Hence, you can use this environment, free of charge, to start planning your migration and test it.

In the LABS environment already today, when customers create new Service Bus namespaces the system will generate a new Access Control namespace with the “-sb” suffix, but that namespace is created in ACSV2. This will be the production experience when we release the update to Service Bus in a few months.

You can immediately start developing this new management code path creating rules against ACSV2 against the versions of Service Bus and Access Control that are available in the May 2011 CTP environment at .

 

As always, if you have any questions or feedback feel free to visit the Connectivity for the Windows Azure Platform forum.

The AppFabric Team.