Cours Microsoft .NET Architecture et Services

3 Les Services Web

Indéniablement une innovation centrale de .NET, les services Web sont la brique de base de l’Internet de demain. Ils permettront d’agréger des informations provenant de nombreuses sources distinctes dans l’Internet, qu’elles soient des serveurs au sens fort du terme ou des pairs (peer-to-peer), sans se soucier de l’architecture matérielle ou logicielle de ces derniers. Un logiciel de messagerie instantanée nommé Jabber développe précisément ce concept, et il n’est que le précurseur.

Perl.

3.1 Le protocole SOAP

SOAP est un protocole en cours d'adoption par le W3C décrivant des appels de procédure à distance (remote procedure call – RPC). Officiellement, l’acronyme signifie Simple Object Access Protocol (protocole simple d’accès aux objets) mais la qualification de Services Oriented Architecture Protocol (protocole pour une architecture orientée-services) lui convient parfaitement.

La répartition des auteurs est très intéressante, en effet sur huit auteurs de la version 1.1, on peut compter quatre membres de Microsoft et deux d’IBM/Lotus (les deux derniers membres provenant de UserLand et DevelopMentor) ; de plus, IBM n’avait pas participé à la version 1.0. On le voit, Microsoft soutient activement SOAP, mais IBM a également compris l’intérêt du protocole.

Le seul poids de ces deux compagnies sur le monde informatique laisse à penser que le développement des services basés sur SOAP va devenir très important au cours des prochaines années.

3.1.1 Principes de fonctionnement

Pour résoudre les problèmes d’interopérabilité entre composants logiciels, de nombreux protocoles ont été conçus ces dernières années. Jusqu’à la création de SOAP, trois protocoles étaient plus particulièrement utilisés :

•   RMI (Remote Method Invocation). Ce protocole est très simple et très efficace, mais ne fonctionne que dans un environnement Java de bout en bout.

•   COM (Component Object Model) et DCOM (DistributedComponent Object Model). Ces protocoles ont été écrits par Microsoft pour faciliter la communication entre composants logiciels de Windows. Un portage UNIX a été réalisé par Software AG, mais en pratique ce protocole reste largement restreint au monde Windows et dans le contexte des Intranets.

On le voit, chaque protocole imposait une barrière à une véritable interopérabilité, qu’elle soit la plate-forme (Windows ou Java pour DCOM et RMI) ou tout simplement la complexité avec CORBA.

SOAP se différencie de ces protocoles par sa grande simplicité d’usage et sa neutralité. Les concepteurs de la norme se sont visiblement mis à la place des développeurs des services avec pour objectif de faciliter leur travail en supprimant les fonctionnalités les plus contraignantes de ses prédécesseurs.

XML a été choisi comme format d’échange, ce qui permet d’utiliser la norme XML Schema pour la sérialisation des données. Les types autorisés sont limités à des cas volontairement simples (essentiellement chaînes de caractères, entiers, flottants et listes de ces derniers) mais suffisants pour reconstruire la plupart des objets. A la différence de ces derniers protocoles dont le format est binaire, les données transportées sont lisibles telles quelles par le développeur et leur manipulation par le client en est grandement facilitée.

La structure choisie pour SOAP correspond à celle d’une enveloppe dans laquelle le message, les données, sont encapsulés, selon la figure suivante.

Figure 10.     L’enveloppe SOAP

SOAP peut ainsi être servi efficacement par les serveurs d’application capables de gérer le XML, ce qui est le cas de IIS (Microsoft) et de J2EE.

Le client retire également des avantages de SOAP. Le pré-requis sont peu nombreux et très répandus, à savoir HTTP et XML ; les nombreuses implémentations de SOAP déjà disponibles tendent à le démontrer. Selon une classification consacrée, le protocole SOAP appartient à la famille des « glues dynamiques », c’est-à-dire que le déploiement (clients et serveurs) est léger et rapidement évolutif, à la différence de CORBA ou de RMI où l’installation de binaires et de descripteurs de déploiement lourds sont nécessaires pour interopérer.

Pour qu’il reste simple, les concepteurs du protocole ont dû accepter des concessions importantes. SOAP n’inclut notamment pas dans sa spécification la gestion du cycle de vie des objets et les pointeurs vers des instances distantes d’objets, comme CORBA, COM ou RMI. La gestion des sessions et des transactions a été volontairement exclue de la norme.

Enfin, comme le souligne Jim Farley, auteur d’ouvrages Java pour O’Reilly, l’actuelle spécification (1.1) ne spécifie pas d’encodage par défaut des messages. Certes, un encodage est défini, mais il n’est pas obligatoire pour être conforme à la spécification. N'importe quel encodage peut être spécifié dans l'attribut encodingStyle du message ou de certaines parties du message. Si l'encodage défini dans la spécification a de fortes chances de devenir un standard de fait, il existe une menace à l'interopérabilité qui rappelle les erreurs de jeunesse de CORBA lorsqu’il n'avait pas spécifié un protocole d'échange standard.

En vérité, les services n’implémentent pas de sécurité par défaut. Les critiques du protocole négligent le fait que SOAP ne définit qu’une enveloppe pour véhiculer les données et que leur représentation est extensible grâce à XML. De plus, d’après les prévisions de Microsoft, la majorité des services à venir n’auront pas ou peu besoin de sécurité.

Microsoft propose une vision centrée sur ses produits dans MSDN. Nous nous attacherons à étudier la sécurité pour SOAP sur HTTP principalement, ce dernier étant le médium privilégié de SOAP. Nous considérerons la sécurité sous ses trois aspects, à savoir la confidentialité, l’authentification et l’autorisation, puis enfin la relation entre SOAP et les pare-feu.

3.1.2.1 La confidentialité

SOAP servira sans aucun doute à transporter des données plus sensibles que les services HTTP actuels. Le cryptage devient alors nécessaire pour s’assurer qu’un tiers malveillant ne peut pas, en écoutant le réseau, intercepter les informations.

Or, avec un chiffrement autorisé jusqu’à 128 bits, le protocole HTTPS (HTTP over SSL) répond parfaitement à ces attentes. Précisons que puisque HTTP est encapsulé dans SSL, le cryptage est complètement transparent pour l’implémentation des services SOAP, quoiqu’il entraîne une dégradation des performances et de la scalabilité de l’infrastructure.

Enfin, pour les autres protocoles comme SOAP sur SMTP, les messages peuvent aussi être cryptés en utilisant un mécanisme natif du protocole, comme S/MIME pour le mail signé et crypté.

L’authentification pour SOAP peut être effectuée de deux manières. La première consiste à utiliser le mécanisme de HTTP, la deuxième étend le protocole en lui apportant une extension.

3.1.2.2.1 Authentification HTTP

Par construction, SOAP peut utiliser les mécanismes du protocole sous-jacent utilisé, HTTP dans notre cas.

En excluant les extensions apportés à Microsoft pour un client Internet Explorer et un serveur IIS, HTTP et la RFC 2617 plus précisément fournit deux méthodes d’authentification, « Basic » et « Digest ». Ces méthodes ne supportent que le mécanisme login / mot de passe classique et peuvent être inadaptées selon les cas. De plus, HTTPS peut également fournir une authentification fiable à l’aide de certificats.

•   Basic. Utilisé pour une authentification non sécurisée ou semi sécurisée, car le login et le mot de passe sont envoyés en clair sur le réseau.

•   Basic sur SSL. Fonctionne comme « Basic » à l’exception que les données sont cryptées par SSL. La sécurité fournie par cette méthode est très bonne, mais affecte les performances du serveur.

•   Digest. Utilise un algorithme de hachage pour transmettre le login et le mot de passe qui offre également une protection contre les « replay attacks », c’est-à-dire le fait de rejouer l’authentification avec les mêmes données pour entrer dans le système sans connaître le mot de passe.

•   Certificats. Cette méthode nécessite que les deux parties aient obtenu un certificat d’un tiers certificateur (payant), et connaît un développement plutôt lent. Toutefois, elle est reconnue comme très sûre.

Le choix est déterminé par les besoins de chaque service, il faut garder simplement à l’esprit que « Basic » offre une protection très faible et qu’il est donc à proscrire si l’enjeu du service est important.

3.1.2.2.2 Authentification par extension

Le IBM Resarch Center de Tokyo a élaboré une extension légale de SOAP presque équivalente aux certificats SSL. L’extension utilise l’entête SOAP pour transmettre l’information d’authentification et pour garantir l’intégrité des données.

Microsoft, VeriSign et WebMethods ont de leur côté annoncé une spécification pour le XML sécurisé fondé sur les signatures digitales et le cryptage nommée XML Key Management Specification (XKMS). D’après VeriSign, XKMS est une spécification pour la gestion des clés publiques pour permettre de signer ou de crypter, ou autres applications des clés publiques. Il est prévu pour interopérer avec le standard de signature XML préparé par l’IETF (Internet Engineering Task Force) et le W3C.

Il est ainsi démontré que la sécurité peut être implémentée en utilisant l’extensibilité de SOAP et justifie, s’il était besoin de le faire, de garder le protocole aussi simple que possible.

3.1.2.3 SOAP et les firewalls

Microsoft présente le fait que le protocole SOAP sur HTTP ne soit pas refusé par les pare-feu comme une fonctionnalité, et il est vrai qu’ils constituaient un obstacle dans les déploiements hors Intranets de CORBA, COM ou RMI. Or, le rôle des pare-feu n’est pas de bloquer les protocoles utiles mais bien de protéger un réseau contre des attaques extérieures malveillantes. SOAP par HTTP (port 80) pose de réels problèmes de sécurité pour l’administrateur réseau comme pour le dirigeant d’entreprise, lequel n’aimerait pas entendre que son coûteux pare-feu ne peut pas le protéger contre des attaques RPC distantes par SOAP.

Le risque peut être prévenu de deux manières :

•   Configurer le pare-feu pour détecter les entêtes SOAP. Le protocole SOAP spécifie les entêtes des messages SOAP de telle sorte qu’un pare-feu peut être configuré pour les bloquer, pourquoi pas en conjonction avec d’autres règles comme le blocage de certaines adresses IP ou de certains services SOAP destinés à l’Intranet uniquement.

3.2 Les Web Services et .NET

3.2.1 Vue d’ensemble de l’architecture

Microsoft a incontestablement fourni un effort remarquable pour que la conception des clients comme des serveurs SOAP soit extrêmement simple depuis Visual . Ce dernier intègre désormais le logiciel Visual InterDev dans une nouvelle interface, assez déroutante de prime abord mais l’impression disparaît à l’usage comme pour la plupart des outils Microsoft.

Les Web Services sont servis par le serveur IIS 5.0 de Windows 2000 et à ce titre bénéficie des fonctionnalités particulières de ce dernier.

•   Le déploiement d’un service est exactement le même que pour les pages ASP à l’aide des extensions de publication FrontPage. Ces extensions définissent un protocole de mise à jour et de téléchargement de données entre un client habilité à modifier ou ajouter une page et le serveur destiné à l’héberger. Elles sont très répandues pour publier simplement des pages par Internet aujourd’hui, le serveur libre Apache implémentant également le protocole sous la forme d’un module. Visual prévoit la publication simultanée vers plusieurs miroirs et/ou une ferme de serveurs à l’aide des « deployment projects » qui contiennent les options de déploiement. Notons qu’il est également possible d’écrire un simple fichier .asmx contenant tout le code, dans n’importe quel langage supporté, et de le copier à l’emplacement désiré dans le répertoire wwwroot d’IIS.

Figure 11.    L’extension serveur FrontPage en action

o   Sur un GET HTTP simple, IIS sert une page de présentation simple du service. En un coup d’œil, le consommateur prend connaissance en langue humaine (Anglais uniquement pour l’instant) du contenu du service.

o   Sur un POST SOAP, IIS interprète la requête SOAP, l’exécute et sérialise le résultat vers le client.

o   Si le client demande la page avec le paramètre ?SDL, la description SDL du service est renvoyée.

o   Enfin, si une erreur survient pendant une requête, IIS renvoie, en mode de débuggage, une page HTML détaillant l’erreur avec un message en Anglais clair et bien sûr l’état de la pile.

Les images suivantes illustrent notre propos sur un exemple simple.

Figure 12.       La page HTML d’auto description générée par

Figure 15. L’affichage d’une erreur par IIS Figure 14. La description SDL (en ajoutant ?SDL à l’URL)

On le voit, la mise en œuvre est facilitée à l’extrême grâce à l’environnement Visual dont l’interaction étroite avec IIS et permet un développement rapide des services.

3.2.2 Le service

Nous allons implémenter un service simple en C# pour illustrer sa puissance. A cet effet, nous créons un nouveau projet C# « Web Service ».

Un wizard, très classique dans le monde Windows, nous demande quelques informations simples puis crée plusieurs fichiers dont un source .asmx décrivant le service. Nous recommandons l’affichage du « Solution Explorer » (onglet View).

Figure 16.     Implémenter un service Web avec Visual

Sur la capture d’écran ci-dessus, on peut voir la simplicité et la puissance de l’environnement. Il suffit d’ajouter le code du service dans le source .cs, de construire (build) le projet et de cliquer bouton droit sur le fichier .asmx dans le « Solution Explorer » et de sélectionner « View in Browser » pour afficher la page HTML d’auto description vue précédemment.

Nous avons simplement ajouté :

[WebMethod]

{

int index = fullname.IndexOf(' ');

    Name nom = new Name(fullname.Substring(0, index), fullname.Substring(index+1));     return nom;

}

[WebMethod]

public string HelloWorld()

{

return "Hello World !"; }

L’attribut [WebMethod] indique une méthode qui doit être exportée pour les classes filles de .Services.WebService. Une grande puissance de C# est l’auto description du comportement du service dans son source et son code. C# élimine les fichiers de description ou de déploiement additionnels auxquels Java nous avait habitués. Ces derniers peuvent être découplés du service qu’ils décrivent, ce qui devient ingérable lorsque la complexité augmente. Avec .NET et les attributs, le code sait dès la compilation comment se comporter au déploiement, ce qui autorise les prouesses comme l’auto description dont nous avons parlé avec le SDL.

La classe Name a été définie dans le même fichier par simplicité. Nous la présentons car elle illustre la sérialisation des objets. La contrainte dans .NET est exactement la même qu’en Java avec les JavaBeans. En effet, pour être sérialisable, et donc utilisable dans une requête SOAP, la classe doit avoir les caractéristiques suivantes :

•   Posséder un constructeur sans arguments.

•   Toutes ses propriétés et membres publics doivent être également sérialisables.

Précisons qu’il s’agit, comme pour les JavaBeans, d’un contrat moral avec l’application parce que le compilateur ne peut pas vérifier qu’un objet sérialisé ainsi ne sera pas « cassé » lors de la récupération puisque certaines données privées peuvent manquer.

Nous avons écrit le code suivant pour Name, dont on remarquera l’ajout d’un constructeur vide sans arguments :

public class Name

{    string _firstname; string _lastname;

public string firstname

   {         set

        {

             _firstname = value.Trim();

   }     public string lastname

   {         set

        {

             _lastname = value.Trim();

        }          get {              return _lastname; }

   }

   // Le vrai constructeur

public Name(string first, string last)

   {

        _firstname = first;

        _lastname = last;

   }

   // Un constructeur vide pour permettre la sérialisation (// JavaBeans)    public Name()

   {

   }

}

Enfin, la sécurité du service se définit très simplement selon les règles énoncées page 37 à l’aide de l’outil d’administration de IIS (dans « Panneau de configuration » puis « Outils d’administration » comme illustration en Figure 17).

Figure 17.    La sécurité sous Internet Information Server

3.2.3 Le consommateur

Le fichier SDL permet de créer un client pour le Web Service. Nous n’avons pas trouvé d’outil, s’il existe, intégré dans Visual , mais il existe un utilitaire en ligne de commande livré avec le .NET Framework SDK nommé WebServiceUtil. Nous avons enregistré le fichier SDL de notre projet dans un répertoire de travail puis lancé la commande :

WebServiceUtil /command:proxy /language:CSharp

Nous obtenons alors le fichier suivant, auquel nous avons simplement ajouté la classe Client pour effectuer un appel au service « HelloWorld ».

using .Serialization; using .Services.Protocols; using .Services; using System;

public class Serveur : .Services.Protocols.SoapClientProtocol {     public Serveur() {         this.Url = "";

    }

    [.Services.Protocols.SoapMethodAttribute(";)] public Name Slice( string fullname) {

        object[] results = this.Invoke("Slice", new object[] {fullname});         return (Name)(results[0]);

    }

public System.IAsyncResult BeginSlice(string fullname, System.AsyncCallback callback, obje ct asyncState) {

    }     public Name EndSlice(System.IAsyncResult asyncResult) {         object[] results = this.EndInvoke(asyncResult);         return (Name)(results[0]);

    }

    [.Services.Protocols.SoapMethodAttribute(";)] public string HelloWorld() {         object[] results = this.Invoke("HelloWorld", new object[0]);         return (string)(results[0]);

    }     public System.IAsyncResult BeginHelloWorld(System.AsyncCallback callback, object asyncStat e) {         returnthis.BeginInvoke("HelloWorld", new object[0], callback, asyncState);

    }     public string EndHelloWorld(System.IAsyncResult asyncResult) {         object[] results = this.EndInvoke(asyncResult);         return (string)(results[0]);

    }

}

[.Serialization.XmlRootAttribute("result", Namespace=";, IsNullab le=true)] public class Name {

    [.Serialization.XmlElementAttribute("firstname", IsNullable=true)] public string Firstname;

    [.Serialization.XmlElementAttribute("lastname", IsNullable=true)] public string Lastname;

}  public class Client {

public static void Main(string[] args) {         Serveur exemple = new Serveur();

        Console.WriteLine(exemple.HelloWorld());

        Name test = exemple.Slice("Jean Dupont");

    }

}

Nous pouvons à l’aide du code mieux comprendre le mécanisme de sérialisation. Le fichier SDL fournit une description de Name qui se voit reconstitué ici, limité à ses attributs firstname et lastname. Une méta-donnée indique qu’il s’agit d’une classe obtenue à partir d’une description de sérialisation pour permettre de substituer la définition originale si elle est fournie.

WebServiceUtil permet également de générer un fichier SDL à partir d’un fichier source C# équivalent, mais l’usage est moins pratique que le paramètre ?SDL dans l’URL.

csc ;;

Les fichiers DLL proviennent du .NET Framework SDK et peuvent être trouvés dans

C:\WINNT\\Framework. Nous obtenons alors un fichier exécutable – à la différence de Java – qui affiche bien « Hello World ! » sur la console.

Regardons à l’aide de l’utilitaire de débuggage de Apache-SOAP présenté plus loin l’échange qui a lieu pour la ligne Name test = exemple.Slice("Jean Dupont"). Pour se faire, nous modifions l’URL du service en écrivant localhost:8080 plutôt que localhost – les requêtes pourront alors être interceptées par l’utilitaire d’Apache qui les renverra sur le port 80 d’IIS.

Figure 18.    Un avantage de SOAP : les échanges sont compréhensibles par un être humain

3.2.4 Zoom sur l’API des Web Services .NET

Cette API est fournie par le SDK dans l’espace de nommage .Services. La présence dans le SDK est important, car il semblerait probable que Microsoft le distribue gratuitement, certes pour les seuls utilisateurs de Windows.

•   WebServiceAttribute. C’est un attribut global pour une classe héritée de WebService. Il permet notamment de préciser l’espace de nommage du service, qui l’identifie de manière unique dans l’Internet. Par défaut, Microsoft utilise ce qui explique pourquoi il apparaît dans les échanges SOAP. Par

exemple, l’attribut [WebService Namespace=" ")] permet de spécifier un espace non ambigu pour des services développés pour ce mémoire.

•   WebMethodAttribute. Cet attribut est associé aux méthodes qui doivent être exportés par le service. Il permet également de commenter et de préciser très finement le comportement de la méthode, dans l’esprit des attributs, c’est-à-dire éviter les fichiers de description en incluant les informations directement dans le source directement.

•   WebServicesConfiguration, WebServicesConfigurationSectionHandler. Ils fournissent des informations à l’environnement d’exécution.

•   Description. Il permet de fournir un message décrivant le service pour l’utilisateur. Ce dernier sera visible dans le fichier SDL et la page de présentation du service.

•   EnableSession (boolean). Cet attribut permet de préciser à IIS de transmettre et de conserver l’état de la session pour cette méthode. La session est activée par défaut, mais la désactiver pour les méthodes ne le nécessitant pas permet d’améliorer les performances.

•   MessageName. Cet attribut permet de distinguer deux méthodes ayant le même nom. Le fichier SDL ajoute le message comme une propriété dans la description XML du service, ce qui permet de distinguer les deux méthodes.

•   TransactionMode. Puisque le protocole HTTP est sans état, s’il y a transaction, le service est toujours l’initiateur de celle-ci. Activer le mode transaction permet en revanche de travailler avec des objets COM au sein d’une transaction.

Les attributs s’écrivent de la manière suivante :

[WebMethod(MessageName="Slice", Description="Separe nom et prenom.")] public Name Slice(string fullname)

Notons enfin l’existence du fichier , généré automatiquement par Visual - si le service est décrit directement à l’aide d’un éditeur de texte, les valeurs par défaut sont utilisées.

Dans ce fichier XML, on trouve des paramètres supplémentaires, exclus du source ce que déroge à la règle des attributs. Outre des paramètres de débuggage, qui doit être désactivé en production, le fichier permet de configurer la sécurité, la journalisation, la gestion de la session et l’internationalisation.

 <!--  

SECURITY 

This section sets the security policies of the application. Possible modes are

"Windows", "Cookie", "Passport" and "None"

-->

  <security>

<authentication mode="None" />

</security>

<!--  

APPLICATION-LEVEL TRACE LOGGING

-->

<trace enabled="false" requestlimit="0" pageoutput="false" tracemode="SortByTime" /> 

<!--  

SESSION STATE SETTINGS

By default ASP+ uses cookies to identify which requests belong to a particular session. If cookies are not available, a session can be tracked by adding a session identifier to the URL. To disable cookies, set sessionstate cookieless="true".

-->

<sessionstate inproc="true" usesqlserver="false" cookieless="false" timeout="20" server="localhost" port="42424" /> 

<!--  

GLOBALIZATION

This section sets the gloablization settings of the application.  -->

<globalization requestencoding="utf-8" responseencoding="utf-8" />

Comme nous l’avons exposé en page 22, Microsoft souhaite louer la gestion de la sécurité des services Web à l’aide de Passport, ce qui explique sa présence dans la liste des paramètres possibles de sécurité. Le paramètre « Windows » indique une sécurité Basic, Digest ou le module intégré d’authentification Windows de IIS comme décrits en page 37.

3.2.5 Le proxy ROPE (Soap Toolkit)

Ce proxy a un intérêt pour mettre en ligne des objets COM existants puisqu’il agit en intermédiaire (proxy signifie délégué) qui transforme les requêtes SOAP entrantes en requêtes COM et traduit la réponse COM reçue en réponse SOAP. La description du service se fait soit à partir d’un fichier SDL existant soit en choisissant des méthodes COM à exposer.

Figure 19.    L’architecture ROPE pour exposer les objets COM (source )

3.2.6 Notre avis

La rapidité d’écriture et de déploiement d’un Web Service n’a pas d’égal avec Visual . L’environnement a su faire ses preuves pour les applications classiques et offre un véritable plus au développeur Web grâce à sa puissance et, ce qui peut également être considéré comme un désavantage, sa forte intégration avec les autres produits Microsoft.

3.3  Les Web Services et Java

Une pléthore d’outils pour Java commence à apparaître sur Internet. Ceux-ci sont souvent commerciaux comme le serveur CapeClear J2EE offrant un pont Entreprise JavaBeans vers Web Services ou l’initiative SunONE/iPlanet, mais des implémentations libres sont également très avancées. En raison de sa qualité et de sa pérennité, nous avons retenu l’implémentation libre d’Apache et les outils qui lui sont associés.

•   Apache-SOAP (version testée 2.1). Livré sous la forme d’un JAR nommé , Apache-SOAP offre une implémentation Open Source libre de droits, c’est-à-dire sous licence Apache, du protocole SOAP 1.1. Cette implémentation, pour la partie serveur, nécessite un serveur d’application Java comme WebSphere, Apache Tomcat, BEA WebLogic ou encore JRun. Apache-SOAP fournit par ailleurs un débuggeur SOAP agissant comme un tunnel HTTP, comme nous le verrons plus loin.

•   Apache Tomcat (version testée 3.2). Issu du projet Apache Jakarta pour lequel Sun a fourni son implémentation des JSPs, ce serveur a acquis une solide réputation en termes de stabilité et de performances. Nous l’avons choisi car, comme ApacheSOAP, il est libre de droits et ses sources sont disponibles.

•   WSDL Toolkit (version testée 1.1). Fourni par IBM et disponible sous une licence limitée à 90 jours d’AlphaWorks, cette utilitaire permet de générer le squelette du serveur et du client d’un Web Service à l’aide de sa description WSDL.

•   Web Services Toolkit (version testée 2.2). Egalement fourni par IBM sous licence AlphaWorks, il contient notamment Apache-SOAP et le WSDL Toolkit. Il facilite l’installation de SOAP sur Tomcat et WebSphere à l’aide d’une interface graphique et offre le support UDDI à SOAP. De plus, WSTK fournit un outil permettant de servir un composant Microsoft COM dans l’architecture SOAP-Java.

•   Java Development Kit (version testée 1.3 de IBM). Sous Linux, le JDK d’IBM est recommandé pour ses performances exemplaires.

Nous avons également mené les tests sous architecture Windows pour tester la compatibilité avec .NET en boucle locale. Comme nous pouvions l’espérer, le fonctionnement est rigoureusement le même sur les deux plates-formes grâce à Java. On pourra déplorer la licence AlphaWorks qui empêche l’utilisation de WSTK et WSDL en production, mais nous verrons qu’il est parfaitement possible de s’en affranchir. Nous ne pouvons que souhaiter qu’IBM incorpore à terme au moins le WSDL Toolkit et l’interface de création d’un service à Apache-SOAP.

Nous ne nous intéresserons pas à l’intégration UDDI, qui sera discutée plus loin, car elle n’existe pas encore dans .NET. Tous les tests sont effectués en boucle locale, mais peuvent fonctionner en environnement distribué à condition de bien préciser au client l’adresse du serveur – rôle de UDDI le cas échéant.

3.3.1 Vue d’ensemble de l’architecture

L’installation de Tomcat et de Apache-SOAP pose essentiellement des problèmes liés au

CLASSPATH de Java. Nous recommandons de mettre tous les JAR nécessaires à ApacheSOAP dans un même répertoire. La documentation fournie avec Apache-SOAP explique la marche à suivre pour interfacer Tomcat et SOAP.

Figure 20.    Le serveur d’application Apache Tomcat 3.2.1

Si l’installation s’est bien déroulée, une page d’accueil est disponible à l’adresse http://127.0.0.1/soap/admin/ .

Figure 21.     La page d’accueil de Apache-SOAP

Comme on pourra le constater, le rôle d’IBM dans Apache-SOAP se voit aussi dans la documentation que dans les titres des pages.

Cliquer sur « Deploy » ouvre la page suivante :

Figure 22.     Interface de déploiement d’Apache-SOAP

Nous le remplissons avec les paramètres attendus par l’exemple samples.addressbook fourni avec Apache-SOAP.

Il est possible de s’affranchir de l’interface graphique en utilisant le descripteur de déploiement XML fourni dans le même répertoire dont voici le contenu :

   <isd:service xmlns:isd="" id="urn:AddressFetcher">

   <isd:provider type="java" scope="Application" methods="getAddressFromName addEntry getAllListings putListings">

<isd:java class="samples.addressbook.AddressBook" static="false" /> 

</isd:provider>

<isd:faultListener>.server.DOMFaultListener</isd:faultListener> 

  <isd:mappings>

<isd:map encodingStyle="" xmlns:x="urn:xmlsoap-address-demo" qname="x:address" javaType="samples.addressbook.Address" java2XMLClassName=".encoding.soapenc.BeanSerializer" xml2JavaClassName=".encoding.soapenc.BeanSerializer" />

<isd:map encodingStyle="" xmlns:x="urn:xmlsoap-address-demo" qname="x:phone" javaType="samples.addressbook.PhoneNumber" java2XMLClassName=".encoding.soapenc.BeanSerializer" xml2JavaClassName=".encoding.soapenc.BeanSerializer" /> </isd:mappings>

</isd:service>

La ligne de commande à utiliser est la suivante :

$ java .server.ServiceManagerClient http://localhost:8080/soap/servl et/rpcrouter deploy

Par curiosité, nous pouvons voir sur l’outil débuggeur quelles enveloppes SOAP ont été échangées pour effectuer le déploiement.

Le serveur Tomcat écoute par défaut sur le port 8080, nous avons placé le débuggeur en écoute sur le port classique HTTP (80). Ceci permet de ne plus mentionner le numéro de port dans nos requêtes. L’adresse virtuelle du routeur RPC dans ce contexte devient plus simplement http://localhost/soap/servlet/rpcrouter.

La commande pour rediriger le port 8080 vers 80 est la suivante :

# java .TcpTunnelGui 80 127.0.0.1 8080

Notons que sous Linux, il faut avoir les droits d’administration pour effectuer cette manipulation, ou choisir un port non réservé (supérieur à 1024) à la place du port 80. Après lancement du déploiement par la méthode ligne de commande en utilisant l’adresse virtuelle du routeur RPC, les enveloppes s’affichent dans la Figure 23.

Figure 23.     Les enveloppes SOAP de déploiement d’Apache-SOAP

Après déploiement, nous pouvons nous assurer que le service est bien enregistré dans la base à l’aide du bouton « List » de la page d’administration.

Figure 24.     Liste des services déployés par Apache-SOAP

Cette liste s’obtient également par ligne de commande :

$ java .server.ServiceManagerClient http://localhost:8080

/soap/servlet/rpcrouter list Deployed Services:

        urn:AddressFetcher

Les descripteurs du service peuvent s’obtenir par ligne de commande ou en cliquant sur un service nous donne les détails de ce dernier, un peu à la manière du SDL de .NET.

$ java .server.ServiceManagerClient http://localhost:8080

/soap/servlet/rpcrouter query urn:AddressFetcher

Figure 25.     Informations de déploiement d’un service Web sous Apache-SOAP

Nous voyons que les détails du service reprennent dans leur quasi-totalité les paramètres de déploiement contenus dans le fichier XML.

o    page / request : une nouvelle instance est créée à chaque appel à rpcrouter (lequel n’effectue pas de forwarding). Cette méthode n’est pas recommandée pour des raisons de performances.

o    session : une instance est créée pour la durée complète de la session.

o    application : toute page au sein de l'application peut accéder à l’objet. Des invocations successives au service appartenant à différentes sessions vont notamment partager la même instance de l'objet. Ce paramètre a un impact important sur la sécurité, alors que page et request assurent l'isolation des appels successifs. La portée application implique au contraire que les JavaBeans SOAP sont partagés par les différents utilisateurs du serveur.

•    Les correspondances de type (type mappings) qui permettent au routeur RPC de sérialiser/désérialiser de Java vers XML et réciproquement. Les JavaBeans contenant les méthodes SOAP ne sont donc pas conscients de l’enveloppe SOAP, entièrement gérée par le routeur RPC.

Il est bien sûr possible d’enlever un service SOAP du référentiel à l’aide de Undeploy ou encore de la ligne de commande.

Figure 26.     Désactiver un service avec Apache-SOAP

Les exemples SOAP fournissent également des clients Java. Nous choisissons GetAddress car ce dernier attend un paramètre.

$ java samples.addressbook.GetAddress http://localhost:8080/soap/servlet/ rpcrouter "John B. Good"

123 Main Street

Anytown, NY 12345

(123) 456-7890

La Figure 27 montre le résultat d’une redirection sur l’outil de visualisation.

Figure 27.     L’échange SOAP entre le client et le service

Maintenant que nous avons étudié l’architecture proposée par IBM, nous allons examiner son API pour regarder comment la mettre à profit. Nous utiliserons la terminologie du WSTK pour désigner les acteurs.

Nous avons vu précédemment que le service peut se présenter sous la forme d’un JavaBean grâce à la simplicité de SOAP. Rappelons qu’un JavaBean est un objet Java qui expose ses propriétés avec des accesseurs get et set, utilisés pour l’introspection, et qui fournit un constructeur vide, afin de reconstruire l’objet. Voici le code très simple que nous souhaitons mettre en ligne :

public class RenvoieChaineService {

  // Méthode à exporter   public String getMe(String message) {     return "J'ai reçu : "+message;

  } }

Il nous faut préciser le déploiement de ce code dans le fichier . Nous proposons le descripteur suivant, en choisissant urn:RenvoieChaine comme identifiant de notre service :

<isd:service xmlns:isd="" id="urn:RenvoieChaine">

<isd:provider type="java" scope="Application" methods="getMe"> <isd:java class="RenvoieChaineService" />

</isd:provider> <isd:faultListener>.server.DOMFaultListener</isd:faultListener>  </isd:service>

Nous prendrons garde à mettre le fichier .class dans un répertoire du CLASSPATH. Notons que si plusieurs méthodes étaient choisies, il suffit de les séparer par un espacement dans methods. Le service peut alors être déployé.

On le voit, rien n’est plus facile que de mettre le service SOAP en ligne. C’est donc bien le client qui est difficile à écrire.

Nous n’avons pas besoin d’IDL puisque nous avons programmé le serveur et que les types utilisés sont simples. Le code du client génère le XML de la requête. Sa complexité apparente réside dans la liberté de codage que SOAP offre. Tout est réglé par défaut dans notre exemple.

import .*; import .*; import .*; import .*; import .*; import .*;  public class Client {   static XMLParserLiaison xpl = new XercesParserLiaison ();    public static void main (String[] args) throws Exception {     if (args.length != 2         && (args.length != 3 || !args[0].startsWith ("-"))) {

      .println ("Usage: java " + Client.class.getName () +

                          " [-encodingStyleURI] SOAP-router-URL message");

      (1);

    }

     // Lecture des arguments.     int offset = 3 - args.length;     String encodingStyleURI = args.length == 3

                              ? args[0].substring(1)

                              : Constants.NS_URI_SOAP_ENC;

    URL url = new URL (args[1 - offset]);     String message = args[2 - offset];

     // Construction de l'appel.     Call call = new Call ();

    call.setTargetObjectURI ("urn:RenvoieChaine"); call.setMethodName ("getMe");

    call.setEncodingStyleURI(encodingStyleURI);     Vector params = new Vector ();

params.addElement (new Parameter("message", String.class, message, null));     call.setParams (params); 

    // Appel : l'actionURI est vide car rpcrouter n'en a pas besoin

    // Toutefois, le SOAP Toolkit de Microsoft attendrait

    // ";

    Response resp = call.invoke (/* router URL */ url, /* actionURI */ "" );

     // Vérification du résultat.     if (resp.generatedFault ()) {       Fault fault = resp.getFault ();

      .println ("Erreur d'appel : ");

    } else {       // Récupération de la réponse.

      Parameter result = resp.getReturnValue ();

      .println (result.getValue ());

    }

  }

}

Ce client a été écrit pour admettre un paramètre optionnel d’encodage. On voit que ce code est réutilisable, seule les sections « construction de l’appel » et « récupération de la réponse » changent selon l’appel.

3.3.4 Fonctionnalités de l’environnement

3.3.4.1 Apache-SOAP

Apache-SOAP fournit une implémentation presque complète de SOAP 1.1 et immédiatement opérationnelle.

•   Il est possible d’utiliser trois encodages : SOAP 1.1, XML pur et XMI, mais nous ne retiendrons que SOAP puisque Microsoft ne supporte que ce dernier.

•   L’application cliente et le routeur RPC implémentent la sérialisation des types primitifs, des chaînes de caractères, des JavaBeans (via l’introspection), des vecteurs, des énumérations et des matrices unidimensionnelles de ces types.

•   Trois moyens de transport sont proposés : HTTP, HTTPS et SMTP. Il est en effet possible d’effectuer des appels par e-mail (d’où l’usage de du CLASSPATH). La classe GetQuoteSMTP des exemples illustre cette fonctionnalité. La présence de HTTPS nous rassure sur la gestion de la sécurité à partir de Apache-SOAP.

•   Il est également possible d’écrire les services dans un langage de script, dont JavaScript, à l’aide du Bean Scripting Framework (BSF), également développé par IBM puis donné à la communauté.

Pour illustrer ce dernier point, examinons l’exemple Calculator que l’on trouvera dans le répertoire samples. On n’y trouve que le code du client et le descripteur de déploiement. En effet, le code du serveur est directement inclus dans ce dernier.

<?xml version="1.0" ?> 

<isd:service xmlns:isd="" id="urn:xml-soap-democalculator">

<isd:script language="javascript">function plus (x, y) { return x + y; } function minus (x, y) { return x - y; } function times (x, y) { return x * y; } function divide (x, y) { return x / y; }</isd:script> 

</isd:provider>

<isd:faultListener>.server.DOMFaultListener</isd:faultListener>  </isd:service>

La        classe .server.InvokeBSF          de        Apache-SOAP            se         charge de l’encapsulation des appels à BSF. Les JAR et doivent être inclus dans le CLASSPATH pour permettre l’utilisation des scripts dans Apache-SOAP.

3.3.4.2 Web Services Toolkit (WSDL Toolkit inclus)

Outre quelques bonnes surprises comme l’intégration COM, WSTK fournit surtout le support WSDL qui manque cruellement dans Apache-SOAP. Il est essentiel de disposer d’une définition réellement neutre des services pour l’interopérabilité.

Dans WSTK proprement dit, une application graphique nommée serviceWizard produit automatiquement à partir d’un objet Java Bean ou un EJB la description WSDL associée aux méthodes choisies. L’intérêt essentiel réside dans la gestion des équivalences (mappings) de types.

Figure 28.     WSTK transforme les classes Java en services Web

Comme on le voit, l’interface graphique demande les quelques paramètres pertinents de l’application, dont l’adresse du rpcrouter, son urn et les méthodes exposées par le Web Service (un statut rouge indique que la sérialisation est « complexe » – ici, les classes Address et Element n’ont pas de mapping par défaut dans SOAP alors que c’est le cas pour long et void).

L’outil génère deux fichiers WSDL (implémentation et interface). Dans le fichier impl, Nous retrouvons notamment les descriptions complètes des types AddressBook et Element qui sont bien ce que nous attendions.

-  <types>

-  <xsd:schema targetNamespace="" xmlns="">

-  <xsd:complexType name="PhoneNumber">

<xsd:element name="areaCode" type="xsd:int" /> 

<xsd:element name="exchange" type="xsd:string" /> 

<xsd:element name="number" type="xsd:string" /> 

</xsd:complexType>

-  <xsd:complexType name="Address">

<xsd:element name="streetNum" type="xsd:int" /> 

<xsd:element name="streetName" type="xsd:string" /> 

<xsd:element name="city" type="xsd:string" /> 

<xsd:element name="state" type="xsd:string" /> 

<xsd:element name="zip" type="xsd:int" /> 

<xsd:element name="phoneNumber" type="tns:PhoneNumber" />  </xsd:complexType>

</xsd:schema>

</types>

Dans le WSDL Toolkit, nous trouvons un utilitaire ligne de commande qui génère les souches d’un client et d’un serveur Java à partir de la définition WSDL du service. Sa syntaxe est simple, et il autorise la création, au choix, de souches EJB ou Java Bean. Il faut également noter que l’outil ne supporte pour l’instant que les types simples de XML Schema.

L’architecture du WSTK ajoute un niveau d’abstraction sur celle de Apache-SOAP en proposant de distinguer le service de son fournisseur (service provider) et de l’entité qui fournit son interface (service interface provider). De plus, IBM introduit la notion de répertoire de service (service registry) que nous aborderons plus loin avec UDDI. Ce type de séparation a des connotations J2EE qui ne sont pas fortuites.

Figure 29.     Le modèle IBM des services Web

Cette architecture est considérée comme plus évolutive que celle Microsoft .NET en ce qu’elle offre les avantages suivants :

•   Un tiers normalisateur peut définir un service pour une tâche, activité, secteur ou application donnés par son interface. Chacun peut alors proposer le service avec une implémentation différente tout en restant compatible.

Le modèle actuel de Microsoft fait la confusion entre le service, son fournisseur et son interface, mais est bien plus aisé à mettre en œuvre puisqu’un service est essentiellement égal à une URL et que chacun peut directement interroger le service pour obtenir son interface. De plus, Microsoft participe à l’élaboration de UDDI et supportera donc ce protocole dans la version finale de .NET.

Notons enfin qu’IBM va bientôt commercialiser un environnement graphique complet de développement nommé Web Services Development Environment (WSDE) ; l’environnement sera intégré dans WebSphere 4.0 qui sera disponible à la fin du mois de juin 2001. D’après 01net, le support par IBM des services Web comportera :

•   WebSphere Application Server 4.0 : Invocation de services Web via SOAP ; interfaçage avec un annuaire UDDI ; proxy WSDL. • WebSphere Studio Technology Preview for Web services : Permettra notamment de transformer un composant existant en service Web.

•   WebSphere Business Integrator : Intégration B to B. Transport de SOAP sur MQSeries ; création de WSFL (Web Services Flow Language), un langage de description du workflow d'intégration issu d'un échange collaboratif.

•   DB2 7.2 : Interfaçage à un annuaire UDDI. Un service Web accédera à des données DB2 via SOAP. 

•   Tivoli Web Services Manager : Administration des performances des services Web.

•   Lotus Web Services Enablement Kit : Ce kit permettre d'exposer les fonctions de collaboration des outils Lotus selon le langage WSDL et de les accéder via SOAP.

3.3.4.3 La sérialisation des objets Java

Apache-SOAP fournit une classe .encoding.soapenc.BeanSerializer qui implémente les interfaces Serializer et Deserializer. Cette classe permet de créer une représentation XML d'un JavaBean et réciproquement de transformer une représentation XML valide en une instance du JavaBean.

Pour le serveur, aucun effort particulier n'est nécessaire. Le client, en revanche, doit créer une instance du BeanSerializer pour reprendre le code. Notons que dans le cadre de ApacheSOAP, le client doit disposer au préalable de l'interface ou du code de la classe visée. Microsoft .NET peut créer une classe équivalente, réduite aux propriétés.

Le WSDL Toolkit de IBM permet d’obtenir les classes Java à partir du fichier WSDL du serviceWizard.

public class Address{

       //instance variables   public int streetNum_Elem;  public .String streetName_Elem;     public .String city_Elem; public .String state_Elem;  public int zip_Elem;  public PhoneNumber phoneNumber_Elem;

       //constructors        public Address () { }

       public Address (int streetNum_Elem, .String streetName_Elem, .String city_Elem, .String state_Elem, int zip_Elem, PhoneNumber phoneNumber_Elem) {

              this.streetNum_Elem = streetNum_Elem;         this.streetName_Elem = streetName_Elem;             this.city_Elem = city_Elem;            this.state_Elem = state_Elem;          this.zip_Elem = zip_Elem;            this.phoneNumber_Elem = phoneNumber_Elem;

         }

}

La classe PhoneNumber est également crée.

public class PhoneNumber{

       //instance variables   public int areaCode_Elem;  public .String exchange_Elem;       public .String number_Elem;

       //constructors        public PhoneNumber () { }

       public PhoneNumber (int areaCode_Elem, .String exchange_Elem, .String number_Elem) {

              this.areaCode_Elem = areaCode_Elem;         this.exchange_Elem = exchange_Elem;               this.number_Elem = number_Elem;

         }

}

public class Address

{ 

  public Address()     public Address(int streetNum, String streetName, String city, String state,                  int zip, PhoneNumber phoneNumber)

   public void setStreetNum(int streetNum)   public int getStreetNum()

  public void setStreetName(String streetName)   public String getStreetName()

   public void setCity(String city)   public String getCity()

   public void setState(String state)   public String getState()

   public void setZip(int zip)   public int getZip()

   public void setPhoneNumber(PhoneNumber phoneNumber)   public PhoneNumber getPhoneNumber()

}

3.3.5 Notre avis

Apache-SOAP est un très beau cadeau d’IBM pour la communauté. L’architecture suit un modèle éprouvé dans le monde Java et l’implémentation est hors de tout soupçon quant à la qualité. De fait, Apache-SOAP a même une petite longueur d’avance sur son concurrent plus médiatique pour l’adhérence aux standards. Les utilisateurs de Java pourront continuer à s’interfacer avec le monde extérieur en gardant leurs infrastructures et leurs outils, ce qui était le but avoué d’IBM dont le soutien de J2EE dans la gamme WebSphere est important.

Le point noir du tableau est l’absence des outils WSDL décrits précédemment dans la distribution Apache. Les intentions d’IBM à leur sujet ne sont pas claires, il est en effet tout à fait possible qu’ils soient inclus à Apache-SOAP à terme. Heureusement, d’autres membres de la communauté implémentent avec des licences GPL et LGPL des outils comparables à WSDL Toolkit, le plus avancé en Java étant Idoox.

Nous regrettons principalement trois fonctionnalités de :

•   La simplicité de déploiement et de test des applications à partir de l’environnement Visual . Certes des scripts en ligne de commande peuvent faciliter la publication des Web Services Java, mais force est de constater que n’a pas besoin de descripteur de déploiement complexe.

Pour déroger à certaines habitudes, nous constatons qu’il est ainsi plus facile d’écrire un client Java pour accéder à un serveur Microsoft que l’inverse.

3.4 Interopérabilité

Contrairement aux idées reçues, la solution libre Apache-SOAP 2.1 implémente la majeure partie de la spécification SOAP 1.1, alors que la version de Visual dont nous disposons (la plus récente) n’implémente que SOAP 1.0. Le SOAP Toolkit 2.0 pour Visual Studio 6.0 implémentant SOAP 1.1 est depuis peu disponible au téléchargement à l’adresse , mais malheureusement ne fonctionne pas avec Visual . Il semble probable en revanche que Microsoft va l’inclure dans la bêta 2.

Ceci a pour conséquence d’empêcher l’interopérabilité entre ces deux logiciels.

3.4.1 Web Service Definition Language (WSDL)

va supporter dès la version bêta 2 un langage de description des services standardisé nommé WSDL (Web Service Description Language), comparable au SDL de la bêta 1. Pour ce standard, Microsoft s’est entendu avec IBM et Ariba, ce qui permet de penser qu’il va s’imposer dans le monde des services Web.

Son rôle est exactement identique à celui des interfaces IDL de CORBA, c’est-à-dire fournir une description complète et neutre des services afin de permettre de créer un client ou un serveur dans le langage et l’architecture choisie. Comme un compilateur IDL, WebServiceUtil et WSDL Toolkit génèrent les souches des clients et des serveurs, ce qui simplifie le développement pour le programmeur. Nous ne pouvons qu’espérer que des versions libres seront disponibles, car ces outils deviennent rapidement indispensables.

Microsoft, IBM et Hewlett Packard proposent déjà un annuaire sur leurs

sites comme le montre la Figure 30.

L’objectif visé par UDDI est de favoriser le commerce B2B (Business-to-business, c’est-àdire inter-entreprise) en proposant trois annuaires dont le rôle est de décrire (Description), de découvrir (Discovery) les services Web et d’y accéder (Integration) :

•   Les « pages blanches » (businessEntity) décrivent l’entreprise par sa raison sociale (nom, adresse, téléphone).

•   Les « pages jaunes » (businessService) donnent sa classification, son activité notamment.

•   Les « pages vertes » (bindingTemplate) fournissent la description des services de l’entreprise – sa page d’accueil, d’emplois mais surtout ses services Web.

L’annuaire sera proposé par plusieurs entreprises sur leurs propres sites, mais sera régulièrement synchronisé pour garantir son unicité. Seule l’interface pourra donc éventuellement différer.

On le voit, UDDI devrait permettre à terme aux entreprises d’échanger des services plus facilement. D’après Marc Gardette, le responsable marketing développeurs de Microsoft France, « UDDI est à comparer à un serveur DNS : il s’agit d’un service de base, qui doit donc rester gratuit ». Ce dernier facteur pourrait bien lui assurer un succès immédiat dès le déploiement des services Web.

Figure 30.     L’annuaire UDDI de Microsoft

4 Conclusion

4.1 Une critique de la « vision »

La tentation est grande de voir dans .NET un moyen pour Microsoft, comme pour l’industrie informatique, d’avoir de nouvelles architectures, de nouveaux logiciels, de nouveaux composants à vendre et très prochainement à louer.

En effet, certains aspects de la vision de Microsoft exposée en page 6 nous paraissent discutables. Si l’initiative .NET se développe comme le souhaite Microsoft, les questions de propriété, de liberté et de vie privée reviendront au goût du jour. Aujourd’hui, l’utilisateur de Word possède physiquement ses documents sur son disque dur ou une disquette, mais qu’en sera t-il demain ? Où seront-ils, à qui seront-ils vraiment et à quels risques de piratage il s’expose ? Est-ce que son ordinateur sera inutilisable sans connexion au réseau ? La communauté du logiciel libre s’inquiète à juste titre de l’enfermement des données personnelles dans les formats propriétaires comme .doc ; le risque est que demain il faille payer pour en faire usage et qu’elles soient confinées dans un serveur distant, restreintes à un service donné.

Ces questions méritent d’être posées car nous ne devons pas céder au déterminisme technologique, qui pose en principe que la technologie induit nos besoins, et non l’inverse.

4.1.1 Le contre-exemple (fictif) de

Après Office 95, 97 puis 2000, il semblait difficile d’annoncer de nouvelles fonctionnalités réellement novatrices ou nécessaires dans Office XP et bientôt . Nous sommes peu convaincus de l’intérêt de louer une application telle que Word et encore moins de devoir être connectés en permanence pour que tout fonctionne normalement. A quoi vont servir les giga hertz des processeurs x86 actuels si le PC devient un Minitel amélioré ? Que se passe t-il si le réseau est engorgé ou que des serveurs essentiels tombent en panne ?

Dans leurs discours, Microsoft et Sun, avec StarPortal notamment, mettent en avant plusieurs arguments :

•   Réduction des coûts de déploiement et de maintenance. Certes, il faut du personnel pour installer Office et parfois pour résoudre ses pannes, ce qui a un coût dans toute entreprise aujourd’hui, mais il restera nécessaire de conserver des techniciens pour gérer les postes clients, le réseau et également régler les erreurs commises sur le serveur par les employés.

•   Possibilité de payer en fonction de ses besoins. La location promet d’importantes économies aux petits consommateurs, mais son modèle semble plutôt favorable finalement aux éditeurs, qui en tirent un abonnement, qu’aux utilisateurs, lesquels ne possèdent plus leur outil de travail.

Certes il faut relativiser, il est en effet fort probable que seuls certains services facultatifs nécessiteront une location et une connexion permanente, mais il n’en reste pas moins que la tendance de fond de l’industrie penche en faveur de la location et que les services Web sont un moyen de la mettre en œuvre.

4.1.2 HailStorm : un portail de services hégémonique ?

HailStorm est, pour Microsoft, la première incarnation de sa stratégie .NET. HailStorm est une plate-forme destinée à offrir des services aux particuliers. Comme dans sa stratégie Windows, Microsoft souhaite posséder l’infrastructure en fournissant la « plomberie »

(plumbing) nécessaire, à charge pour des tiers de déployer leurs services à l’aide des outils Microsoft. Ainsi que nous l’avions déjà annoncé, le service Web Passport jouera un rôle déterminant dans le dispositif.

Figure 31.    L’authentification par Passport est centrale (illustration Microsoft)

Microsoft s’appuie sur son portail MSN, dont Hotmail, pour déployer rapidement HailStorm. La plate-forme est prévue pour être ouverte, au sens où elle communiquera uniquement par

SOAP et où des serveurs « externes » pourront facilement s’interfacer. L’objectif de Bill Gates est de fournir du contenu pour tous les terminaux envisageables, afin d’atteindre une part de marché des transactions sur Internet importante et faire de Microsoft l’acteur dominant des services Web.

4.1.3 La croissance du haut débit est présupposée

Rien n’indique que l’Internet haut débit va réellement se développer étant donnés les goulets d’étranglements qu’il engendrera avec sa croissance. Ainsi, le volume d’upload vers les serveurs est actuellement limité par les opérateurs câblés avec un profil d’utilisation actuel bien moindre que ce que Microsoft espère demain. Les opérateurs pourront-ils suivre en maintenant le montant de la facture raisonnable ?

La mise en ligne d’applications pour mobiles posera également le problème de la double facturation. D’une part, il faut payer Microsoft ou un partenaire pour le service et d’autre part, il faut payer l’opérateur de téléphone mobile pour la connexion, qui devrait être facturée au volume de données pour le GPRS et l’UMTS, et non plus à la durée comme aujourd’hui. L’avalanche des factures à la fin du mois, déjà conséquente à la fin du XX^ème siècle, pourraient bien décourager de nombreux utilisateurs et entreprises à l’aube d’un troisième millénaire friand de location.

.NET répond en effet à certaines attentes importantes du marché que la concurrence n’avait pas tout à fait comblé :

•   Les services Web. Microsoft innove réellement avec la première plate-forme intégrant SOAP et des outils XML de première classe.

•   Un environnement de développement Web puissant mais simple d’utilisation. Nous avons déjà évoqué tout le bien que nous pensons de Visual , qui devrait intéresser de nombreuses PME notamment.

•   Des outils intégrés pour Windows adaptés à nouvelles exigences des développements Web. Java supporte Windows, mais rend inutilisables le serveur IIS, l’Active Directory, COM+ ou encore Windows DNA, de telle sorte que Windows est souvent utilisé comme plate-forme de développement Java, le déploiement étant ensuite effectué sur UNIX ou Linux, ce qui était d’ailleurs un objectif stratégique de Sun. Les entreprises utilisant exclusivement Microsoft, souvent pour des raisons de simplicité et de coût, avaient besoin d’outils à jour pour affronter les problématiques de demain.

•   Le support de nombreux langages de programmation. Le geste fait par Microsoft en faveur des autres langages pourrait lui attirer la sympathie des développeurs marginalisés par Java. Il faut toutefois relativiser le support multilingue en raison du poids du CLS d’une part, et de la complexité de maintenir un projet écrit en plusieurs langages d’autre part.

•   Le goût de la nouveauté. Il ne faut pas négliger le « cool effect », qui met en valeur les derniers produits disponibles, surtout quand ils se font tellement attendre et qu’ils demeurent largement mystérieux.

De .NET, nous retiendrons trois innovations majeures qui nous semblent mériter les louanges. Nous souhaitons de tout cœur pouvoir les retrouver sur d’autres plates-formes, voire dans une implémentation libre sur la base des soumissions à l’ECMA :

•   Visual . L’environnement simplifie réellement les développements Web en permettant de les considérer comme des applications classiques, avec toute la puissance et l’expressivité que l’on peut attendre.

•   Les services Web. Leur programmation et leur déploiement à l’aide des attributs et des assemblages sont intuitifs et s’intègrent à la plate-forme facilement.

•   Le langage C#. Reprenant le meilleur de Java et de C++, C# est très expressif, souple et élégant. Bien qu’il ne soit pas au goût de certains puristes, il nous a séduit.

Bibliographie et liens utiles

•   « C# et .NET » par Gérard Leblanc, Eyrolles (ISBN : 2-212-09278-4). Livre en français par l’auteur d’un excellent ouvrage sur C++ Builder de Borland. Des chapitres importants sont gratuitement téléchargeables à l’adresse ;artid=9

•   Le site de Microsoft () propose des présentations généralistes de .NET exposant la vision et les principes. Une FAQ très intéressante est notamment disponible. 

•   Beaucoup de ressources développement .NET sur MSDN (Microsoft Developer Network) à l’adresse et (site géré par Microsoft)

•   Le portail eServices de Office XP :

•   Article             de        synthèse          intitulé             «          Applying         .Net     to         Web             Services           » :

•   Spécifications complètes soumises à l’ECMA (C#, CLI, base class library) 

•   Portail francais sur .NET réunissant de nombreux articles à

•   Article technique sur Eiffel# :

•   La liste exhaustive des changements entre la version bêta 1 et la bêta 2 sur le site

123ASPX :

•   La spécification de la SOAP 1.1 à l’adresse

•   La        sécurité            des       services           Web     selon    Microsoft       

•   Les Web Services dans SunONE :

•   Les ressources XML pour Apache

•   Le site AlphaWorks d’IBM consacré aux services Web (un PDF de présentation est inclus à WSDL)

•   L’article          de        Clay     Shirky sur       HailStorm      

Table des illustrations

Figure 1.        Le portail eServices de Office XP 8

Figure 2.       Un exemple fictif de distribution de composants (source : ) . 9

Figure 3.        L’architecture fonctionnelle de .NET .. 11

Figure 4.        Le contenu de mscorlib .. 13

Figure 5.       Le processus de compilation et d’exécution (source MSDN) . 15

Figure 6.        Global assembly cache (GAC) 17

Figure 7.       Les spécifications soumises à l’ECMA (source : ) .. 18

Figure 8.        Le modèleur UML intégré de Visual 24

Figure 9.        Les bases de données en ligne grâce à XML et HTTP (source MSDN) 25

Figure 10.      L’enveloppe SOAP .. 35

Figure 11.      L’extension serveur FrontPage en action .. 39

Figure 12.      La page HTML d’auto description générée par 40

Figure 13.      La réponse de à une requête effectuée « à la main » . 40

Figure 14.      La description SDL (en ajoutant ?SDL à l’URL) . 40

Figure 15.      L’affichage d’une erreur par IIS . 40

Figure 16.      Implémenter un service Web avec Visual .. 41

Figure 17.      La sécurité sous Internet Information Server .. 43

Figure 18.      Un avantage de SOAP : les échanges sont compréhensibles par un être humain .. 45

Figure 20.      Le serveur d’application Apache Tomcat 3.2.1 .. 49

Figure 21.       La page d’accueil de Apache-SOAP 49

Figure 22.      Interface de déploiement d’Apache-SOAP .. 50

Figure 23.      Les enveloppes SOAP de déploiement d’Apache-SOAP .. 51

Figure 24.      Liste des services déployés par Apache-SOAP .. 52

Figure 25.      Informations de déploiement d’un service Web sous Apache-SOAP . 52

Figure 26.      Désactiver un service avec Apache-SOAP 53

Figure 27.       L’échange SOAP entre le client et le service .. 54

Figure 28.      WSTK transforme les classes Java en services Web 57

Figure 29.      Le modèle IBM des services Web . 58

Figure 30.       L’annuaire UDDI de Microsoft .. 63

Figure 31.      L’authentification par Passport est centrale (illustration Microsoft) 65

---