Azure en libre-service (2/2)

Outre le code applicatif, les développeurs fournissent à Azure l’architecture de services à base de rôles et les paramètres de configuration. La création de l’application dans l’environnement VS 2008 familier constitue un avantage de taille, mais l’architecture de services Azure peut constituer un défi pour nombre de développeurs .NET. L’approche architecturale de Microsoft concernant Windows Azure se démarque sensiblement de celle retenue pour la construction des versions serveur et PC de Windows.

Azure est, à dessein, nettement plus rationalisé et possède un code nettement plus compact et plus rapide. « Lorsque Microsoft crée un système d’exploitation, il doit penser aux millions de combinaisons de périphériques matériels et de logiciels qu’il lui faudra gérer », indique Gillen. « Mais avec la plate-forme de services Azure, ils ont déclaré qu’il va y avoir ces deux ou trois plates-formes de stockage. Un point c’est tout. L’hyperviseur aura cet ensemble d’attributs. Fin de la discussion. »

Azure requiert une architecture spécifique. Votre site Web constitue un rôle et il y a également les rôles de type role), explique le grand gourou des technologies de Magenic Technologies Inc. Rockford Lhotka, lequel a visité la PDC et a assisté à de nombreuses sessions sur les technologies. « Les processus ouvriers sont les services, mais ils sont uniquement disponibles au sein de l’application. Bien que cette architecture existe depuis un certain temps, elle n’est pas très courante car elle est asynchrone et basée sur des messages. C’est la raison pour laquelle tout le monde parle de SOA, mais peu de personnes l’utilisent réellement.

Et c’est précisément ce que recouvre SOA. » Cette architecture se retrouve actuellement dans les grandes applications d’entreprises telles que Visa ou General Motors, selon Lhotka, où l’informatique doit créer les tâches de traitement par lots d’arrière-plan. « Et soudainement, tout du moins dans l’univers Microsoft, cet aspect est mis à la portée du plus grand nombre, même pour les petites applications. Aussi je pense qu’il va être intéressant d’imaginer de quelle manière l’utiliser efficacement », explique-t-il. « Si vous pensez à l’ensemble comme ayant trois parties, vous avez d’abord le client s’exécutant dans le navigateur et le rôle Web exécutant une application Web dans Azure.

Mais si le rôle Web doit effectuer une tâche d’arrière-plan, il la délègue à un processus ouvrier et, de votre point de vue de consommateur, ce processus reste en quelque sorte en coulisses. Mais, en fait, il s’agit d’un service, mais pas d’un service Web », ajoute-t-il. « Un autre scénario consiste à ce que le client soit une application entièrement différente qui appelle un service WCF hébergé dans Azure et s’exécutant dans le rôle Web, car il fait partie intégrante de l’interface utilisateur Web. Ce service pourrait avoir une tâche d’arrière-plan à exécuter, laquelle serait également accomplie par un processus ouvrier.

Et je crois que c’est cette partie processus ouvrier que la plupart des personnes ne font pas aujourd’hui. Je ne dis pas que cela concerne une majorité écrasante, mais je pense qu’il s’agit d’un domaine où les personnes devront apprendre à l’utiliser et à en tirer parti de manière efficace. » Jennings minimise le rôle des services existants pour les entreprises s’intéressant à Azure.

« Je pense que l’exploitation d’Azure sera probablement indépendante de l’utilisation des services Web par une entreprise car le service sera quelque chose de légèrement différent de l’actuelle architecture orientée services », explique-t-il. « C’est un peu comme Salesforce. Les clients font appel à Salesforce, lequel peut ne pas avoir d’autre développement basé sur les services Web. »