Dans la CTP Windows Azure AppFabric de mai 2011, nous avons apporté des améliorations au Service Bus dont les nouvelles fonctionnalités de middleware orienté messages autour de thèmes et de files d'attente. Plus de détails au sujet de ces caractéristiques se trouve ici : introduction au Service Bus d'AppFabric de mai 2011.

Actuellement, nous avons deux versions de la fonction de contrôle d'accès dans notre environnement de production : la version de janvier 2010 et celle d'avril 2011. Plus de détails à ce sujet ici : Windows azure AppFabric maintenant disponible mettant en vedette une nouvelle version de la fonction de contrôle d'accès!.

Jusqu'à ce que la production de Service Bus soit mise à jour, elle continue d'utiliser la version de janvier 2010 de la fonction de contrôle d'accès. Mais une fois que le Service de Bus est mis à jour il sera également en mesure d'utiliser la nouvelle version d'avril 2011 de la fonction de contrôle d'accès. Une fois la mise à jour du Service Bus disponible nous recommandons fortement aux clients de mettre à jour leurs solutions de Service Bus à utiliser la nouvelle version de la fonction de contrôle d'accès pour deux raisons :

  1. Service de Bus cessera d'utiliser l'ancienne version de la fonction de contrôle d'accès à un certain moment dans le futur. Conformément à nos politiques de soutien du cycle de vie pour Windows d'azur, nous vous fournirons avec 12 mois de préavis avant cet événement.
  2. La version d'avril 2011 de contrôle d'accès a grands avantages tel qu'indiqué dans le message de blog référencé ci-dessus.

Voici des explications sur l'état actuel, ce qui va changer une fois que le Service de Bus est mis à jour et comment vous pouvez vous préparer.

État actuel dans l'environnement de production

Dans le portail de gestion de Windows Azure AppFabric, les deux versions du contrôle d'accès sont étiquetées ACSV1 pour la version de janvier 2010 et le ACSV2 pour la version d'avril 2011.

Aujourd'hui lorsque vous créez un nouvel espace de noms de Service Bus, un espace de noms ACSV1 correspondante est automatiquement créé avec le suffixe d'espace de noms « –sb ». Cet espace de noms ACSV1 est utilisée par le Service de Bus.

Les deux versions de la fonction de contrôle d'accès soutiennent le même protocole et format jeton autorisation qui est prévu par le Service Bus aujourd'hui (OAuth envelopper SWT) et sont pleinement compatibles pour toutes les opérations de runtime. Cependant, ACSV2 prend en charge un protocole de service de gestion des nouveaux, plus riche basé sur OData. Alors que les deux services sont compatible avec le runtime, ils ne sont pas compatibles pour effectuer une installation automatisée des règles de contrôle d'accès et des identités dans le service via le service de gestion de code.

Suite à la mise à jour du Service Bus

Pour la rétro-compatibilité avec les applications existantes, les Service Bus Namespace qui existent dans l'environnement de production au moment de la mise à jour ne seront pas automatiquement convertis à ACSV2 et continuera d'utiliser ACSV1. Vous devrez migrer ces espaces de noms de ACSV1 vers ACSV2 manuellement, en coordination avec les mises à jour de votre code qui appelle la fonction de gestion.

Comme nous mettons à jour le service en quelques mois, nous donnera des conseils outillage et étape par étape pour savoir comment effectuer la migration de ACSV1 à ACSV2.

Tandis que nous fournirons des indications détaillées sur la mise à jour, le processus de migration impliquera généralement la séquence d'étapes test-migration suivante :

  • Tout d'abord, vous allez créer un namespace Service Bus flambant neuf, temporaire qui entrera automatiquement apparié avec un espace de noms ACSV2. Cet espace de noms sera utilisé pour l'essai de bout en bout de votre application avec ACSV2, y compris votre code mis à jour pour appeler le service de gestion.
  • À l'aide d'un outil de ligne de commande à-être fourni, vous copierez l'état de votre espace de noms ACSV1 de production dans l'espace de noms ACSV2 temporaire. Votre production Bus Service espace de noms et l'espace de noms ACSV1 correspondant restera intactes au cours de ce processus. Vous pouvez à présent tester votre application et mis à jour le code contre le namespace temporaire de Service Bus et ACSV2 pour s'assurer que tout fonctionne comme prévu.
  • Après avoir vérifié que votre application fonctionne comme prévu, vous utiliserez l'outil de ligne de commande à-être fourni pour changer le nom DNS de l'espace de noms ACSV2 temporaire pour être le nom de l'espace de noms ACSV1 associé à votre production Service Bus – échanger efficacement l'espace de noms V2 dans la place de l'espace de noms V1 existant. Ceci termine la migration.

L'exécution d'applications ne devrait pas expérience toute interruption de service résultant de ce commutateur.

Les différences de version et de la migration affectera surtout cette disposition automatiquement les règles en ACSV1 en utilisant le service de gestion des applications. Puisque le service de gestion diffère entre ACSV1 et ACSV2, le guide vous proposera un processus qui peut être décrite comme suit :

  • Comme vous préparer pour le passage au numérique, vous devriez avoir un mode dans votre application ou d'une procédure de votre processus d'opérations, qui vous permet d'en suspendre temporairement la création automatisée des règles. Cela peut être un simple avis au personnel des opérations ou exige certains travaillent dans votre application.
  • Immédiatement avant que vous copiez règles dans l'espace de noms temporaire pour la dernière fois avant de prendre le nom DNS à changer, vous devez s'engager ce mode suspension afin qu'aucune nouvelles règles ne sont créés dans l'espace de noms ACSV1 qui finissent par être orphelins après la migration de données.
  • Après que vous avez passé à ACSV2, vous pouvez reprendre la création automatisée des règles en ayant votre cible de code le nouveau service de gestion de la ACSV2.
  • Nous suggérons que vous avez à la fois, le ACSV1 et le ACSV2, le code client existant dans votre application côte-à-côte et que vous basculez entre les chemins de code à l'aide d'une simple vérification contre une URL HTTP. Si un simple obtenir demande contre les rendements de.accesscontol.windows.net/v2/mgmt/service de ACSV2 gestion de terminaison https://locataireun code d'état HTTP 404, l'application s'exécute contre ACSV1, sinon il déjà s'exécute contre ACSV2.

Comment préparer

Notre environnement LABS à http://portal.appfabriclabs.com comprend déjà les améliorations apportées à Bus de services, ainsi que la nouvelle version du contrôle d'accès. Par conséquent, vous pouvez utiliser cet environnement, gratuitement, pour commencer à planifier votre migration et de le tester.

Dans l'environnement LABS déjà aujourd'hui, lorsque clients créer de nouveaux espaces de noms de Service Bus le système générera un nouvel espace de noms de contrôle d'accès avec le "-sb" le suffixe, mais que l'espace de noms est créé dans ACSV2. Ce sera l'expérience de production lorsque nous libérer la mise à jour du Service Bus dans quelques mois.

Vous pouvez immédiatement commencer à développer ce nouveau chemin de code de gestion créer des règles contre ACSV2 contre les versions de Service de Bus et de contrôle d'accès qui sont disponibles dans le mai 2011 CTP environnement au http://portal.appfabriclabs.com