Interopérabilité des services Web de type « Contract First

Interopérabilité des services Web de type « Contract First »
(priorité au contrat) entre Microsoft .NET et IBM WebSphere
Eric Cherng
Vertigo Software, Inc.
James Duff
Vertigo Software, Inc.
Dino Chiesa
Microsoft Corporation
28 octobre 2004
Public visé :
Architectes et développeurs
Télécharger l'exemple d'interopérabilité pour cet article
Introduction
Contenu de l'exemple d'interopérabilité
Conditions et configuration logicielle requises
Pourquoi des services Web ?
Service Web 1 : Addition
Service Web 2 : Évaluations et rapports
Service Web 3 : Recherche de produits
Conclusion
Recommandations/Astuces
Remerciements
Liens utiles
Introduction
Tandis que les services Web attirent de plus en plus d’adeptes, les fournisseurs s’efforcent
d’ajouter de nouveaux standards et fonctionnalités dans leurs infrastructures pour enrichir et
consolider la communication entre systèmes. Les organisations, qui investissent de plus en plus de
temps et d’argent dans la recherche de l’optimisation des services Web et de leurs technologies de
base, doivent connaître les forces et les limites de ces technologies, notamment en matière de
savoir-faire du développeur, de facilité de maintenance et d’interopérabilité. Le présent article est
consacré à l’interopérabilité ; il définit comme point de départ l’interopérabilité entre Microsoft .NET
Framework et IBM WebSphere via les services Web. L’objectif de ce livre blanc et de l’exemple qui
l’accompagne est d’expliquer aux développeurs de chaque plate-forme comment intégrer l’autre
plate-forme. Bien que notre étude soit focalisée sur les plates-formes .NET de Microsoft et
WebSphere d’IBM, les exemples illustrent des techniques et principes de base pouvant être
réutilisés dans tous les projets exigeant une interopérabilité entre plates-formes via des services
Web.
Contenu de l’exemple d’interopérabilité
Cet exemple contient :
1. L’exemple de code de service Web :
 Il s'agit de services Web et de clients des services Web écrits en Java et en C#
pour trois interfaces de service différentes :
1. Service Web 1 : il s'agit d'un service Web effectuant une simple addition dont
l’objectif est de vous familiariser avec les outils et les plates-formes utilisés.

2. Service Web 2 : ce service montre comment faire passer des types d’objet
complexes d’une plate-forme à l’autre.
3. Service Web 3 : ce service met en évidence un modèle de conception pour créer
des services Web extensibles, capables de gérer les modifications dans les
mappages de données.
 Chaque service Web fait preuve d’une interopérabilité hétérogène. Il suffit de
modifier un paramètre sur le client du service Web pour que celui-ci puisse
communiquer soit avec le service Web .NET, soit avec le service WebSphere.
 Dans cet exemple simple, il n’est pas nécessaire d’avoir accès à la base de données
pour exécuter un service Web et un client.
 Dans ce document, nous étudierons en détail la création du service Web 1 à partir
des principes de base. Nous n’approfondirons pas autant l’analyse des services Web 2
et 3.
2. Ce livre blanc, qui décrit en détail les différents services Web et leur conception.
Les techniques et concepts abordés dans cet article sont généraux et peuvent donc s’appliquer à
toute connexion entre deux plates-formes de fournisseurs différents. Néanmoins, les exemples ont
été développés et testés uniquement avec les kits de développement (SDK) de services Web de
.NET Framework et d’IBM WebSphere.
Conditions et configuration logicielle requises
Cet article sur l’interopérabilité (et l’exemple associé) considère que le lecteur connaît les bases de
.NET Framework, d’ASP.NET et du serveur d’application WebSphere d’IBM. Le service Web 1
s’adresse aux développeurs qui n’ont jamais créé de services Web ou qui ne connaissent pas l’une
des deux plates-formes. Même si vous êtes familiarisé avec les services Web et avec les deux
plates-formes en question, nous vous conseillons de consulter au moins la partie concernant le
service Web 1 car elle contient des trucs et astuces utiles qui ne figurent pas dans les sections
traitant des services Web 2 et 3.
Configuration logicielle requise
Nous avons utilisé les logiciels suivants pour créer et tester les exemples.
 Microsoft Windows XP Professionnel SP1
 Microsoft Internet Information Services 5.1
 Kit de développement (SDK) de Microsoft .NET Framework, version 1.1
 SDK de Sun Java, version 1.4
 Kit de développement pour services Web de WebSphere (WSDK), version 5.1
 Kit des développeurs de services Web Java (JWSDP), version 1.3
Si vous n’avez aucun logiciel Java, vous devez impérativement installer les logiciels requis dans
l’ordre suivant :
1. SDK Sun Java 1.4
2. Eclipse 2.1.3

3. WSDK 5.1
4. JWSDP 1.3
5. Eclipse nécessite le SDK Java, lequel est inclus dans le WSDK mais pour installer le WSDK,
Eclipse doit déjà être installé !
6. Vous trouverez des informations complémentaires sur l’installation dans le fichier README
à télécharger avec les exemples d’interopérabilité.
Pourquoi des services Web ?
Les services Web en tant que technologie applicative existent depuis de nombreuses années. Bien
avant que les organisations et les sociétés ne créent les standards de services Web, les analystes
d’entreprise, les architectes et les ingénieurs en logiciel avaient compris que les données
d’entreprise étant dispersées sur de nombreux systèmes, il fallait que ces derniers puissent
communiquer entre eux. Les premières tentatives de liaison des applications entre elles à l’aide des
technologies d’appel de procédure distante (RPC), comme RMI, DCOM et d’autres mécanismes
d’interconnexion spécifiques à certaines plates-formes, ont généralement échoué en raison de la
diversité des fournisseurs et des plates-formes utilisées dans les organisations. Ces approches ont
aussi avorté parce que leur usage n’était pas adapté à Internet, d’où la lenteur, voire l’absence de
réponses sur ce réseau. D’autres solutions, qui utilisaient les files d’attente de messages, les
verbes PUT/GET et l’ordonnancement manuel des messages, posaient des problèmes de
maintenance et de productivité en matière de programmation. C’est pourquoi les développeurs ont
opté pour des standards et protocoles courants : XML et HTTP.
Lorsque les ingénieurs se sont lancés dans la création d’applications capables de communiquer
entre elles, ils ont choisi XML parce que ce langage est utilisé et pris en charge par toutes les
plates-formes. Le protocole HTTP a été retenu en raison de son utilisation étendue et de sa
capacité à traverser les pare-feu. Les fournisseurs comme Microsoft ou IBM ont commencé à créer
des infrastructures pour soutenir ces efforts de développement et faciliter le travail des
développeurs. Pour cela, ces infrastructures éliminaient la charge que représentent la sérialisation
et la désérialisation du XML et fournissaient des éléments structurels communs comme le code
requis pour établir des connexions entre systèmes. La naissance des services Web a été accueillie
comme une promesse de simplification de l’intégration entre systèmes et applications hétérogènes.
Les fournisseurs, utilisant les services Web comme catalyseur, se rallient maintenant autour du
concept d’architecture orientée services qui permet d’interconnecter des solutions individuelles,
éventuellement créées (en toute légitimité) à l’aide de protocoles RPC propriétaires comme RMI ou
DCOM. Les données peuvent ainsi circuler en temps réel dans toute l’entreprise.
Les bénéfices et le potentiel en termes d’intégration sont donc réels, mais dans la pratique, les
développeurs estiment pour la plupart que la création de services Web interopérables est plutôt
complexe. La création de services Web même très simples recèle de nombreux risques comme les
conflits de types ou l’absence de prise en charge de certaines fonctions. Notre premier exemple
présente un service Web interopérable. Nous vous expliquerons les différentes étapes du processus
de conception et de création d’un tel service.
Service Web 1 : Addition
Le premier exemple explique les bases d’un service Web interopérable. Il s’agit d’un service qui
effectue une simple addition. Il accepte deux entiers de la part du client et renvoie la somme de
ces deux nombres.

Le schéma fonctionnel suivant décrit l’architecture de ce service Web :
Figure 1. Architecture fonctionnelle du service Web 1.
Qu’est-ce qui vient en premier, l’implémentation ou l’interface ?
La technique de création de services Web la plus courante, la plus avérée et la mieux prise en
charge par les outils consiste à « inférer » une interface de service Web à partir d’une
implémentation existante. Le développeur rédigera le code suivant :
public int Ajouter(int x, int y) { return x+y; }
Dans ASP.NET, il est très simple d'exposer ce code en tant que service Web : il suffit d’ajouter au
code l’attribut WebMethod. Cette technique est souvent appelée « Implementation First »
(priorité à l’implémentation) ou « Code First » (priorité au code) car l’interface de service Web,
décrite de façon formelle dans un document WSDL (Web Service Description Language), est
dérivée de l’implémentation.
Figure 2. Développement d’un service Web par la méthode « Implementation First »
(priorité à l’implémentation).
La technique de développement de services Web appelée « Implementation First » consiste à écrire
d’abord le code du service Web (voir étape nº 1 de la figure 2). Après compilation, l’infrastructure
des services Web utilise ce code pour générer de façon dynamique un fichier WSDL (étape nº 2).
Lorsque les clients demandent la définition du service Web, ils récupèrent le fichier WSDL généré et
créent le proxy client à partir de cette définition (étape nº 3).
Par exemple, dans ASP.NET, le fichier WSDL peut être généré de façon dynamique à partir d’une
implémentation avec URL comme celle-ci :
http://hostname:port/Service1.asmx?WSDL
Lorsque le runtime de .NET détecte le paramètre WSDL dans la requête, il effectue une réflexion
sur le code doté de l’attribut WebMethod pour générer de façon dynamique une opération de
description du service sous-jacent dans le fichier WSDL.
Cette technique d’implémentation est très simple et fonctionne très bien, mais elle génère quelques
problèmes, notamment en cas de services Web utilisés pour connecter des systèmes hétérogènes.
Par exemple, si l’on commence par l’implémentation, il n'est pas possible d’inclure dans le service
Web des types spécifiques à une plate-forme. Les types de jeux de données .NET et de vecteurs
Java sont spécifiques à une plate-forme et sont difficiles à représenter sur d’autres plates-formes.
En effet, il n’existe pas encore de mappage unique et bien défini entre ces types spécifiques et

XML. Ce n’est pas parce qu’un client .NET est capable de reconnaître dans un Blob de XML un jeu
de données, qu’un client de service Web écrit en Java peut faire la même chose. Nous sommes
donc confrontés à des problèmes d’interopérabilité.
Le schéma XML standard W3C définit des types de données intégrés dont, entre autres, les chaînes
(string), les entiers de différentes tailles (integer), les variables booléennes (Boolean), les variables
représentées en virgule flottante (float) en simple et double précision ou les données de date et
d’heure (DateTime). Chaque plate-forme applicative prend également en charge son propre jeu de
types de données. L’intersection entre ces jeux de types de données définit les types qui offriront la
meilleure interopérabilité entre plates-formes. Si vous commencez par des types appartenant au
schéma XML, il est facile de les mapper vers les types spécifiques à la plate-forme, mais si vous
commencez par ces derniers, le mappage inverse n’est pas forcément possible. Par exemple le
mappage des types integer, string, Boolean et float du schéma XML vers les types de données
correspondant dans .NET ou Java est facile. En revanche, les types de vecteurs (Vector) ou de
tables de hachage (Hashtable) sont natifs des différentes plates-formes et ne font donc pas partie
des types officiels du schéma XML. Pour plus d’informations sur les types de données pris en
charge, consultez les spécifications (en anglais) des types de données du schéma XML.
Les runtimes de la plupart des services Web (y compris le runtime intégré à .NET Framework et à
WSDK) sont capables d’effectuer un mappage entre les primitives du schéma XML et les primitives
spécifiques à la plate-forme. Ainsi, une chaîne du schéma XML sera mappée vers le type
System.String dans .NET et vers le type java.lang.String dans Java. Avec les primitives du schéma XML
et les structures et tableaux générés à partir de ces primitives, il est possible de créer des types de
données plus complexes, décrits dans le schéma XML, qui pourront être mappés de façon très
fidèle d’une plate-forme à l’autre. Ces types de données peuvent alors figurer dans les documents
WSDL à utiliser dans le service Web.
Cela représente l’essence de la méthode appelée « WSDL first » (priorité au WSDL) : si vous
utilisez les types du schéma XML pour définir les types de données utilisés dans le service Web,
vous avez plus de chance de pouvoir mapper ces types de données entre plates-formes.
Cette technique qui consiste à créer d’abord le fichier WSDL est aussi appelée parfois « Schema
First » (priorité au schéma). Si ces deux appellations sont généralement employées
indifféremment, elles renvoient en fait à deux concepts légèrement différents. Dans cet article,
nous souhaitons amener les architectes et les développeurs à créer le contrat à partir des
définitions WSDL, avant de créer le code sous-jacent du service. Pour créer le fichier WSDL, les
développeurs peuvent soit créer des définitions de schéma XML spécifiques à l’interface avec
laquelle elles seront utilisées (« WSDL First »), soit utiliser les schémas XML déjà définis dans leur
domaine d’application (« Schema First »). Cet article utilisera la terminologie du concept « WSDL
First ».
Figure 3. Développement d’un service Web par la méthode « WSDL First » (priorité au
WSDL).