Tout le monde a suivi la sortie d’Azure à la PDC en octobre dernier, mais je voudrais faire un peu de relecture des annonces en détaillant les principales briques pour une prise en main rapide des concepts et de l’implémentation. Pour les endormis, voici la slide technico-marketing reprenant les principales composantes d’Azure :
Ce premier article va gratter un peu autour du bus de services, pour comprendre son mode de fonctionnement et ses liens avec vos applications.
Une définition lapidaire du bus de services (ou ISB, pour Internet Service Bus)
L’ISB est une couche sécurisée de connectivité intermédiée, permettant d’exposer des canaux http et tcp sur Internet sans passer par une DMZ. Concrètement, n’importe quelle application (située sur un poste itinérant, sur un téléphone, ou dans une autre entreprise) peut bénéficier d’une connectivité directe avec n’importe quelle autre application (située sur un poste itinérant, un serveur, etc…).
Cette connectivité directe peut prendre plusieurs formes : canal TCP uni ou bidirectionnel, requête HTTP (web, web service, REST, etc.), streaming, et multicast.
Quel est le principe de fonctionnement de l’ISB ?
Comme souvent, les nouvelles techniques viennent des pratiques grand public. En l’occurrence, l’ISB trouve ses racines dans Msn Messenger et BitTorrent. Comme vous le savez probablement, un client BitTorrent a un rôle double : il est client pour récupérer les DVD (pleins de photos de vacances) que d’autres mettent à votre disposition, mais il est aussi serveur pour que ces précieuses photos soient récupérables chez vous en même temps que depuis les sources originales.
Oui mais voilà, autant être client tcp est simple, autant être serveur depuis sa connexion ADSL est délicat : les fournisseurs d’accès ne vous allouent plus d’adresse IP publique depuis belle lurette, ils utilisent une technique appelée NAT pour mutualiser les quelques adresses IPv4 mises à leur disposition, et votre machine pleine d’images est de ce fait incontactable depuis le monde extérieur, puisqu’elle n’a pas d’adresse publique ! 
Ce problème existe aussi en entreprise, où les machines de l’intérieur du réseau possèdent des adresses non routables : consulter votre site de recherche favori depuis l’intérieur de l’entreprise est (souvent) simple, mais consulter votre machine de bureau depuis chez vous est (presque) impossible. Là où l’entreprise règle le problème en installant quelques machines ayant des adtresses publiques (sur une DMZ), comment fait le particulier ?
Des services comme Messenger, LogMeIn ou Mesh ont développé une approche simple et efficace : ils proposent une batterie de serveurs publiquement accessibles, qui permettent de contourner le problème du serveur. La connexion entre client et serveur devient intermédiée : le serveur lorsqu’il se lance ouvre un canal bidirectionnel avec un serveur public. Le client ne contacte plus directement le serveur, mais appelle le serveur public. Le serveur public joue le rôle d’intermédiaire entre le client et le serveur, et règle au passage les problèmes de connectivité du serveur.
Les services sus-mentionnés font en réalité des choses plus complexes, mais peuvent se permettre un certain nombre de raccourcis puisque les cas d’utilisation et les natures de connexion sont déterminées de bout en bout. Lorsqu’on essaie de transposer cette approche dans le monde du développement, les problèmes à régler sont de trois ordres :
- Comment s’assurer que les services exposés par l’entreprise A ne seront pas appelés par erreur ou malveillance par des clients n’ayant rien à faire là ? Avant même de mettre en place une couche de sécurité, il faut proposer un annuaire de points de connexions et se prémunir contre les ambiguités de nommage ou d’adressage.
- Comment tenir la charge si la même infrastructure publique doit encaisser les demandes d’un nombre énorme de clients et serveurs ?
- Comment donner au développeur une façon simple de faire appel à cette infrastructure intermédiée ?
Structure détaillée de l’ISB
Les deux premiers points vont nous permettre une petite visite dans les entrailles de l’ISB, le troisième étant plutôt consacré à ce qui se passe aux extrémités de la chaîne. Voici donc la version Azure du schéma ci-dessus :