les web services - serveur campus des écoles hes genevoises
publicité
LES WEB SERVICES AUTEUR : ALBERT RITCH HEG GENÈVE DÉPARTEMENT D'INFORMATIQUE DE GESTION – LABORATOIRE DE TECHNOLOGIES OBJET PROFESSEUR : PETER DAEHNE Albert Ritch – Les Web Services Page 1 novembre 2003 – v1.0 Préface Les Web Services sont récents dans les architectures distribuées. Permettant l'interopérabilité des systèmes distribués, ils permettent de s'affranchir d'un langage de programmation ou d'une plate-forme de développement précise. Apportant une brique importante aux architectures orientées services (SOA), ils sont une technologie passionnante à découvrir. Objectif L'objectif de ce travail est de brosser un panorama général des Web Services, en étudiant les normes et standards sur lesquels ils sont basés, notamment XML, SOAP, WSDL et UDDI. L'objectif est également de comprendre leur déploiement et fonctionnement dans une architecture distribuée à l'aide de mises en oeuvres, notamment avec l'architecture J2EE. Structure du document Tout d'abord, une partie théorique va présenter XML, le langage maternel des Web Services. Ensuite, les trois briques de bases des Web Services à savoir SOAP, WSDL et UDDI vont être présentées. Puis, les Web Services vont être étudiés dans le contexte des architectures distribuées et des technologies d'intégration. Enfin, la fin de la partie théorique va terminer par une présentation des plates-formes .NET et J2EE qui intègrent toutes deux les Web Services, ainsi qu'un récapitulatif général présentant quelques API et outils de mise en oeuvre. La partie pratique va comporter l'installation et la mise en oeuvre d'exemples à l'aide d'Axis et de Sun One Studio. Remerciements Je remercie tout particulièrement M. Peter Daehne, mon maître de diplôme, pour m'avoir guidé et conseillé durant ce travail. Je remercie également ma famille pour m'avoir soutenu durant mes études. Albert Ritch – Les Web Services Page 2 novembre 2003 – v1.0 Introduction Trop souvent, les systèmes d'information sont liés et évoluent en fonction de contraintes techniques alors qu'ils devraient être conçus en services métiers indépendant d'une technologie précise. Les Web Services apportent une brique importante à la conception d'architectures orientées services (SOA) en permettant de construire des applications réutilisables et indépendantes vis à vis d'une technologie utilisée. Ils permettent notamment d'encapsuler des services métiers et de les rendre disponibles via des protocoles standards indépendants de tout langage ou d'une plate forme technologique définie. Présentant un faible couplage, les Web Services sont une technologie peu intrusive pour les systèmes d'information qui les utilisent. Autorisant les connexions de type synchrone (RPC) ou asynchrone, les Web Services permettent une importante flexibilité d'utilisation ainsi que de nombreuses possibilités de mise en oeuvre dont notamment dans les technologies d'intégration ou dans l'ouverture vers les partenaires de type B2B (Business To Business). Les protocoles et normes qui sous-tendent les Web Services, tous basés sur XML, sont devenus suffisamment mûrs pour une utilisation dans des grands projets. D'ailleurs, la grande majorité d'éditeurs de logiciels proposent à l'heure actuelle des solutions intégrant les Web Services. C'est le cas des éditeurs de progiciels, de serveurs d'application ou de logiciels d'intégration. Les Web Services seraient-ils alors la technologie miracle qui devrait réussir là ou les technologies comme CORBA auraient échouées ? Albert Ritch – Les Web Services Page 3 novembre 2003 – v1.0 Résumé Les Web Services sont basés sur trois briques principales que sont SOAP (Simple Object Access Protocol), WSDL (Web Service Description Langage) et UDDI (Universal Description, Discovery and Integration). Le langage utilisé qui sous-tend ces protocoles est XML, ce qui rend les Web Services indépendants des plates-formes et des langages de programmation. SOAP est un protocole de transmission de messages permettant l'échange unidirectionnel ou bidirectionnel de messages entre le consommateur du service et le serveur. WSDL décrit quand à lui le Web Service de manière indépendante à tout langage de programmation et UDDI permet de référencer les Web Services tout en proposant également les indications commerciales utiles sur les entreprises. Le champ d'utilisation des Web Services est vaste. Il comprend par exemple les technologies d'intégration dans le cadre de nouveau EAI nommés ESB (Enterprise Service Bus) qui se basent sur des standards comme les connecteurs JCA de SUN. Les échanges B2B profitent également de l'apparition des Web Services. Ainsi, une entreprise peut directement ouvrir des parties de son système d'information à ses partenaires sous forme de services. Les éditeurs de solutions logicielles tels que les fournisseurs de progiciels, de serveurs d'application ou d'environnement de développement intègrent maintenant les Web Services dans leurs solutions. Microsoft et IBM sont à l'origine de la majorité des normes utilisées dans les Web Services. Même si ils ont proposé très tôt des outils de développement de Web Services, la majorité des entreprises les ont rattrapés. Albert Ritch – Les Web Services Page 4 novembre 2003 – v1.0 Table des matières 1. Introduction aux Web Services ....................................................................................................................12 1.2 Fonctionnement de base ........................................................................................................................13 2. XML .............................................................................................................................................................14 2.1 Syntaxe XML ........................................................................................................................................14 2.1.1 Syntaxe d'un document XML .......................................................................................................14 2.1.2 XML Schema ................................................................................................................................15 2.1.3 Liens XML....................................................................................................................................19 2.2 Parsing de documents XML..................................................................................................................19 3. Architecture et normes des Web Services ....................................................................................................21 3.1 Spécifications des Web Services...........................................................................................................21 3.2 SOAP.....................................................................................................................................................21 3.1.1 Structure d'un message SOAP.......................................................................................................22 3.1.2 Exemples de base de messages SOAP (SOAP 1.2) ......................................................................22 3.1.3 Chaînes d'acheminement...............................................................................................................24 3.1.4 Typage...........................................................................................................................................24 3.1.5 Gestion des erreurs........................................................................................................................25 3.1.6 Attachements.................................................................................................................................26 3.3 WSDL ...................................................................................................................................................27 3.3.1 Structure d'un fichier WSDL.........................................................................................................27 3.3.2 Utilisation d'un document WSDL .................................................................................................29 3.4 UDDI.....................................................................................................................................................32 3.4.1 Structure de documents UDDI ......................................................................................................32 3.4.2 Accès à un annuaire UDDI ...........................................................................................................33 3.4.3 Publication d'un Web Service .......................................................................................................37 4. Les Web Services et les protocoles d'applications distribuées .....................................................................38 4.1 Les protocoles de communication dans les architectures distribuées....................................................38 4.1.1 RMI ...............................................................................................................................................38 4.1.2 EJB ................................................................................................................................................39 4.1.3 COM+ ...........................................................................................................................................39 4.1.4 .NET Remoting .............................................................................................................................39 4.1.5 Corba.............................................................................................................................................39 4.1.6 Autres technologies (Janeva) ........................................................................................................39 4.2 Corba et les Web Services.....................................................................................................................39 4.2.1 Avantage des Web Services par rapport à CORBA ......................................................................40 4.2.1 Avantages de CORBA ..................................................................................................................40 4.2.2 CORBA ou les Web Services ?.....................................................................................................40 5. Les Web Services et les technologies d'intégration (EAI) ...........................................................................41 5.1 Intégration point à point ........................................................................................................................41 5.2 EAI ........................................................................................................................................................41 5.2.1 Middleware ...................................................................................................................................42 5.3 Convergence entre les EAI et le e-business ..........................................................................................43 5.4 ESB (Enterprise Service Bus) ...............................................................................................................44 6. Plates-formes et outils de développement ....................................................................................................45 6.1 La plate-forme .NET .............................................................................................................................45 6.3 Plate-forme J2EE .............................................................................................................................47 6.3 Récapitulatif des outils pour la mise en oeuvre des Web Services .......................................................49 6.1.1 API pour le développement de Web Services (client ou serveur).................................................49 Annexe A : Installation et configuration de Tomcat et d'Axis .........................................................................52 A.1. Obtenir les softwares ...........................................................................................................................52 A.2. Installation et configuration de Tomcat...............................................................................................52 A.2.1 Lancement et arrêt de Tomcat :....................................................................................................52 A.3. Installation et configuration d'Axis ..........................................................................................................54 A.3.1 Lancement et arrêt de Axis...........................................................................................................54 Albert Ritch – Les Web Services Page 5 novembre 2003 – v1.0 A.4. Installation de Axis (API) au niveau client .........................................................................................55 A-5 Installation de Sun One Server.............................................................................................................56 Annexe B : Mises en oeuvres ...........................................................................................................................57 B.1. Déploiement d'un Web Service simple................................................................................................57 B.2 Déploiement d'un service de convertisseur de devises .........................................................................59 B.2.1 Introduction ..................................................................................................................................59 B.2.2 Mise en place du Web Service .....................................................................................................59 B.2.2 Création du client en VBA ...........................................................................................................63 B.2.3 Intégration dans MS Office ..........................................................................................................65 B.3 Client C# avec Visual Studio................................................................................................................70 B-5 Scénario de e-banking ..........................................................................................................................73 B-5.1 Création du Web Service d'informations bancaires .....................................................................74 B-5.2 Création de la partie informations boursières du client................................................................77 B-5.3 Création de la partie banque GBS ................................................................................................81 B-5.4 Fin de la partie client....................................................................................................................82 Albert Ritch – Les Web Services Page 6 novembre 2003 – v1.0 Illustrations et tableaux Illustrations Figure 1-1 Architecture globale des Web Services Figure 1-2 Consommation d'un Web Service Figure 2-1 Parsing de document XML Figure 3-1 Enveloppe SOAP Figure 3-2 Interception de l'invocation du service Calculator Figure 3-3 Représentation schématique d'un fichier WSDL avec XMLSPY Figure 3-4 Représentation schématique du fichier WSDL pris en exemple (XMLSPY) Figure 3-5 Structure de document UDDI Figure 3-6 Recherche dans l'annuaire UDDI d'IBM Figure 3-7 Résultats de la recherche Figure 3-8 Description de l'entreprise Figure 4-1 Requête à un objet distant Figure 5-1 Intégration point-à-point Figure 5-2 Broker d'intégration Figure 5-3 Intégration avec les partenaires Figure 5-4 ESB (Enterprise Service Bus) Figure 6-1 La plate-forme .NET Figure 6-2 Architecture des Web Services avec .NET Figure 6-3 Plate-forme J2EE Figure 6-4 Architecture des Web Services avec J2EE Figure A-1 Page de démarrage de Tomcat Figure A-2 Fenêtre de démarrage d'Axis Figure B-1 Mise en oeuvre 1 : exécution de CalcClient Figure B-2 Mise en oeuvre 2 : exécution de Java2WSDL Figure B-3 Notre Web Service est déployé Figure B-4 Résultat de l'exécution du clientFigureB-5 : Création de la feuille Excel Figure B-5 Création de la feuille Excel Figure B-6 Editeur VBA Figure B-7 Résultat après invocation du Web Service Figure B-8 Utilisation du Web Service en tant que fonction Figure B-9 Création de la feuille Excel Figure B-10 Ajout du Web Service Figure B-11 Recherche du fichier de description WSDL Figure B-12 Les méthodes sont trouvées Figure B-13 Interface graphique en C# Figure B-14 Résultat Figure B-15 Schéma du scénario Figure B-16 : Classes serveur Reuters Figure B-17 : Plate-forme J2EE Figure B-18 : Génération du Web Service Figure B-19 : Package ReutersServeur Figure B-20 : La maquette de la fenêtre des titres Figure B-21 : Les titres reçus du serveur Reuters Figure B-22 : Diagramme de classe de la banque Figure B-23 : Choix d'un titre Figure B-24 : Validation de l'achat Figure B-25 : Paramètres d'achat Figure B-26 : L'ordre est passé Albert Ritch – Les Web Services Page 7 novembre 2003 – v1.0 Tableaux Tableau 2-1 facettes avec leur description Tableau 3-1 Les requêtes accessibles prévues dans l'API Tableau 6-1 Outils de mise en oeuvre Albert Ritch – Les Web Services Page 8 de Web Services novembre 2003 – v1.0 Abréviations et symboles API Application Programming Interface B2B Business To Business B2C Business To Consumer CLR Common Language Runtime COM Component Object Model COM+ Component Object Model plus CORBA Common Object Request Broker Achitecture CRM Customer Relationship Management DCOM Distributed Component Object Model DOM Document Object Model EDI Échange de Données Informatisé EJB Enterprise Java Bean ERP Entreprise Resources Planning ESB Enterprise Service Bus IDL Interface Definition Language IIOP Internet Inter-ORB Protocol JAXP Java API for XML Processing JCA J2EE Connector Architecture JVM Java Virtual Machine MOM Message-Oriented Middleware ORB Object Request Broker RMI Remote Method Invocation RPC Remote Procedure Call SOA Service Oriented Architecture SOAP Simple Object Access Protocol UDDI Universal Description, Discovery and Integration URI Uniform Ressource Identifier WSDL Web Service Description Language Albert Ritch – Les Web Services Page 9 novembre 2003 – v1.0 Glossaire Applet Petit programme Java destiné a être téléchargé et utilisé au niveau client dans un navigateur Web Broker de messages Dans un environnement orienté objet, un broker de messages sert à réguler les messages entre objets Business To Business B2B Commerce entre deux entreprises Business To Consumer B2C Commerce entre une entreprise et les consommateurs Common Language CLR Runtime Machine virtuelle faisant partie de framework .NET permettant l'exécution de programmes (C#, VB.NET, J#, ...) Common Object Request Broker Achitecture Component Object Model CORBA Standard de gestion d'objets distribués permettant à des applications de langages différents de communiquer (voir ORB et IDL) Component Object Model plus COM+ Version améliorée de COM COM Standard de gestion d'objets distribués Connecteur Logiciel interfaçant une application et le broker de messages d'un EAI Courtier de messages Voir broker de messages Customer Relationship Management Distributed Component Object Model Document Object Model CRM Progiciel de la relation client DCOM Extension du protocole COM, permettant de supporter les objets répartis sur le réseau DOM Spécification du W3C dont les implémentations permettent de parser des documents XML en créant un arbre en mémoire Enterprise Java Bean EJB Objets distribuées Java Enterprise Service Bus Nouvelle génération d'EAI s'appuyant sur des standards comme les JCA et les Web Services ESB Entreprise Resources ERP Planning Albert Ritch – Les Web Services Progiciel de gestion Page 10 novembre 2003 – v1.0 Fat client Client lourd (application créée avec les bibliothèques graphiques comme Swing ou les MFC) Interface Definition IDL Language Langage de description des services orientés objets distribués sous CORBA Internet Inter-ORB Protocol IIOP Protocole CORBA permettant à deux bus ORB de communiquer ensemble J2EE Connector Architecture JCA Interface d'accès aux applications Java. Utilisé comme connecteur dans les ESB Java API for XML Processing JAXP API Java pour la manipulation de documents XML Java Virtual Machine JVM Machine virtuelle Java permettant d'exécuter un programme Java Logiciel adaptateur voir connecteur Message-Oriented Middleware MOM middleware Mécanisme asynchrone d'échange de messages entre applications Logiciel transportant les informations échangées par des applications distribuées Object Request Broker ORB Broker permettant de faire communiquer des objets sous CORBA Remote Method Invocation RMI Mécanisme de Sun servant à utiliser des objets distribués Remote Procedure Call RPC Un protocole RPC gère les interactions du client et du serveur dans le cas d'environnements distribués Service Oriented Architecture SOA Architecture où les processus métiers de l'entreprises sont vus comme des services réutilisables et indépendants de toute technologie Applet étant exécutée sur le serveur et non pas chez le client SOAP Protocole d'échange de messages des Web Services s'appuyant sur XML Servlet Simple Object Access Protocol Thin client Client léger (browser Web) Uniform Ressource URI Identifier Localisateur d'un document distant sur Internet Web Service Composants logiciels se localisant sur Internet et dont les protocoles de communication utilisent des standards comme HTTP et XML Albert Ritch – Les Web Services Page 11 novembre 2003 – v1.0 1. Introduction aux Web Services [DON02] Technologie innovatrice, les Web Services ne sont pas une révolution mais plutôt une évolution car ils se basent sur des technologies connues et éprouvées. XML qui est la langue maternelle des Web Services, apporte une grande souplesse d'utilisation. En effet, les fichiers sont lisibles directement par un humain, ce qui facilite le déboguage par exemple. On peut définir les Web Services comme des composants logiciels se localisant sur Internet (architectures distribuées) et dont les protocoles de communication utilisent des standards reconnus comme HTTP et XML. Les Web Services supportent les modes d'utilisation synchrone ou asynchrone et présentent un faible couplage par rapport aux applications client. Trois briques de base constituent les Web Services. Il s'agit tout d'abord de SOAP (Simple Object Access Protocol) qui est le protocole de communication fondé sur XML utilisé dans les Web Services. Il permet de décrire les informations transitant via le réseau, de manière simple et efficace. L'invocation de méthodes distantes (RPC) se fait grâce à SOAP qui contient les appels des méthodes invoquées ainsi que leurs arguments. Fig. 1-1 : Architecture globale des WS La deuxième brique est WSDL (Web Service Description Langage) qui permet de décrire un Web service et de le localiser afin que le client connaisse les caractéristiques des méthodes à invoquer et de leurs paramètres. La troisième brique se nomme UDDI (Universal Description, Discovery and Integration ) qui est une norme d'annuaires permettant de répertorier des Web Services. Actuellement à la version 2.0, la spécification UDDI est validée par l'OASIS1 (Organization for the Advancement of Structured Information Standards ). Des briques additionnelles servent à la sécurité et aux transactions. 1. URL : http://www.oasis-open.org/home/index.php Albert Ritch – Les Web Services Page 12 novembre 2003 – v1.0 1.2 Fonctionnement de base Les Web Services fonctionnent suivant une architecture client/serveur. La demande de service et sa réponse sont transportés via le réseau à l'aide des protocoles HTTP et TCP/IP et toutes les requêtes effectuées, que se soit par le serveur ou le client, se font via SOAP. L'utilisation de protocoles standards, ouverts et maîtrisés par les acteurs du marché est une des raisons de l'engouement actuel pour les Web Services. Le client peut être indifféremment un « fat client » (C++, C#, Java, ...) ou un « thin client » (browser, PDA). Il peut également s'agir d'un progiciel, d'un élément d'une suite bureautique, etc. Le serveur quand à lui peut être un serveur d'applications J2EE, .NET, etc. Il est tout à fait possible de créer des Web Services à partir d'une combinaisons d'autres Web Services, afin de proposer une solution métier complète. Recherche et consommation d'un Web Service : 1. Après avoir créé et déployé ses Web Services, le serveur publie les documents WSDL correspondants auprès d'un annuaire UDDI. 2. Le client, pour invoquer un Web Service, va le rechercher sur un annuaire UDDI. 3. Une fois trouvé, il va télécharger le document WSDL correspondant. Les documents WSDL contiennent les spécifications des Web Services proposés par le serveur. 4. Le client invoque le Web Service. 5. Le serveur exécute le code du Web Service et en renvoie le résultat. Fig. 1-2 : Consommation d'un Web Service Albert Ritch – Les Web Services Page 13 novembre 2003 – v1.0 2. XML [01I01], [MAE03] XML est un standard régi par le W3C qui est un consortium regroupant les principaux acteurs du marché (Microsoft, Sun, Oracle, ...). HTML et XML ont tous deux la même origine à savoir le SGML2. En fait, XML est un sous-ensemble de SGML. Cependant si HTML se contente de permettre la mise en forme de pages Internet, XML décrit les données afin qu'une mise en forme spécifique leur soit appliquée. On dit de XML que c'est un méta-langage. C'est à l'utilisateur de construire des balises personnalisées et de gérer la sémantique. En décrivant les données et leur relations entre-elles, il peut être utilisé comme support pour véhiculer ces données via le Web. 2.1 Syntaxe XML Les règles syntaxiques sont peu nombreuses mais un document XML doit parfaitement s'y conformer afin qu'un outil de visualisation (browser, ...) puisse l'interpréter. 2.1.1 Syntaxe d'un document XML Balises Un document XML doit commencer par une ligne de déclaration : <?xml version="1.0"?> La même mais avec la spécification d'encodage des données : <?xml version="1.0" encoding="UFT-8"?> Les éléments du document doivent être encadrés par des balises ouvrantes et fermantes : <nom>Dupont</nom> Attention, les balises sont sensibles à la casse. Il faut donc qu'elles soient identiques de part et d'autre. Par exemple la balise de fermeture ci-dessous est incorrecte : <nom>Dupont</Nom> Des balises encadrant un élément vide peuvent être « factorisées ». Par exemple si la personne Dupont n'a pas d'e-mail on peut écrire : <email></email> Equivalent à : <email/> A l'inverse des balises en HTML, la disposition des balises doivent être disposées strictement en paires imbriquées (comme les parenthèses ouvrantes et fermantes). Par exemple l'exemple ci-dessous est correct : <autresinfos><email>[email protected]</email></autresinfos> Mais celui ci-dessous est incorrect : <email><autresinfos>[email protected]</email></autresinfos > Un document XML est construit de manière arborescente. Le premier élément du document en étant la racine. Exemple : 2. SGML (Standard Generalized Markup Language) : Métalangage permettant de définir des documents hypertexte de tous types. XML et HTML sont des sous ensembles de SGML. Albert Ritch – Les Web Services Page 14 novembre 2003 – v1.0 <?xml version="1.0" encoding="UFT-8"?> -<client> <nom>Dupont</nom> <prenom>Jean</prenom> -<adresse> <numero>3</numero> <rue>rue des Chênes</rue> <code_postal>1202</code_postal> <ville>Genève</ville> </adresse> </client> Des espaces ne doivent pas figurer dans une balise comme dans l'exemple ci-dessous : </ adresse> De même, il ne peut y avoir d'espaces entre les caractères inclus dans une balise : <adresse personnelle> Un chiffre ne peut être utilisé comme premier caractère d'une balise <1234adresse> Les commentaires sont écrits ainsi : <!-- un commentaire --> Attributs Les attributs sont des éléments additionnels permettant de décrire des informations. <taille unite="cm">175</taille> Namespaces Les namespaces permettent de qualifier les éléments ou attributs en permettant de les différencier sémantiquement. <mesureMeteo> <echelle>Pression</echelle> <bars>2</bars> <echelle>Degrés</echelle> <temperature>25</temperature> </mesureMeteo> Comment connaître la signification de l'échelle ? Est-ce des bars ou une température ? On va utiliser une qualification d'espaces de noms : <mesureMeteo xmlns:ns1="bars" xmlns:ns1="temperature"> <ns1:echelle>Pression</ns1:echelle> <bars>2</bars> <ns2:echelle>Degrés</ns2:echelle> <temperature>25</temperature> </mesureMeteo> Avec ce namespaces, on peut ainsi différencier les deux types d'échelles. 2.1.2 XML Schema XSD ou XML Schema Definition succède aux DTD qui étaient lourdes et non écrites en XML. XML Schema permet de décrire la structure d'un document XML et sert également au typage des données. Albert Ritch – Les Web Services Page 15 novembre 2003 – v1.0 Un schéma fait de préférence partie d'un document annexe (réutilisable) plutôt que d'être inclus dans le document XML qu'il décrit. Le typage des données est nettement amélioré avec XML Schema par rapport aux DTD. Les types de bases sont tous représentés (string, long, int, date, ...) et il est possible de créer des types dits complexes. Un document XSD commence par un élément schema. Exemple : <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> Si les document XSD sont des fichiers de description, les instances sont les fichiers XML décrits par les documents XSD : <element name="Automobile" type="Automobile"/> <typeComplexe name="Automobile"> <element name="modele" type="xsd:string"/> <element name="marque" type="xsd:string"/> <element name="annee" type="xsd:int"/> </typeComplexe> Voici l'instance correspondante à cette fraction de schéma : <uneVoiture xsi:type="Automobile"> <modele>Corvette</modele> <marque>Chevrolet</marque> <annee>2000</annee> </uneVoiture> Un fichier de description XSD peut donner lieu à un nombre quelconque d'instances. Autre exemple : <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xsd:element name="client" type="TypeClient"/> <xsd:complexType name="TypeClient"> <xsd:sequence> <xsd:element name="nom" type="xsd:string"/> <xsd:element name="prenom" type="xsd:string"/> <xsd:element name="dateNaissance" type="xsd:date"/> <xsd:element name="adresse" type="TypeAdresse"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="TypeAdresse"> <xsd:sequence> <xsd:element name="numero" type="xsd:int"/> <xsd:element name="rue" type="xsd:string"/> <xsd:element name="codePostal" type="xsd:string"/> <xsd:element name="ville" type="xsd:string"/> </xsd:sequence> <xsd:attribute name="pays" type="xsd:string"/> </xsd:complexType> </xsd:schema> Un élément element permet de représenter un élément dans un document XSD <xsd:element name="numero" type="xsd:int"/> Albert Ritch – Les Web Services Page 16 novembre 2003 – v1.0 Les éléments attribute sont des compléments des éléments element dans la spécification de types. Les éléments element peuvent être des types complexes alors que les éléments attribute ne peuvent qu'être des types simples. <xsd:attribute name="pays" type="xsd:string"/> Les facettes ou restrictions servent à définir des valeurs simples en précisant un intervalle de valeurs ou une exepression régulière par exemple. Exemple : la facette enumeration permet d'énumérer des valeurs autorisées. Les facettes d'un document XSD (ou restrictions) peuvent être classées en trois catégories : 1. la facette whiteSpace s'applique à l'espace normalisé et lexical des types string et normalizedString 2. la facette pattern s'applique qu'à l'espace lexical 3. les autres facettes s'appliquent à l'espace des valeurs Tab 2-1 : facettes avec leur description Facette Description enumeration Sert à spécifier les valeurs autorisées. Exemple : <xsd:simpleType name="DebutListeNombresPremiers"> <xsd:restriction base="xsd:int"> <xsd:enumeration value="2"/> <xsd:enumeration value="3"/> <xsd:enumeration value="5"/> <xsd:enumeration value="7"/> </xsd:restriction> </xsd:simpleType> Permet de définir le nombre de décimales autorisées Permet de spécifier le nombre exact de caractères (ou d'octets) Spécifie une valeur maximale qui ne peut être atteinte Spécifie une valeur maximale qui peut être atteinte Permet de spécifier le nombre maximum de caractères (ou d'octets) Spécifie une valeur minimale qui ne peut être atteinte Spécifie une valeur minimale qui peut être atteinte Permet de spécifier le nombre minimum de caractères (ou d'octets) Définit un modèle à respecter grâce à des expressions régulières. L'exemple ci-dessous de pattern implique que l'élément doit être un nombre de 5 chiffres. <xsd:pattern value="[0-9]{5}"/> Spécifie le nombre exact de chiffres Définit l'interpretation des espaces fractionDigit length maxExclusive maxInclusive maxLength minExclusive minInclusive minLength pattern totalDigits whiteSpace Types Dans les documents XML Schema, les types peuvent soit être simples soit complexes. Les types simples caractérisent la valeur d'un élément ou d'un attribut alors que les types complexes caractérisent la structure et le modèle de contenu. Ils concernent donc plus des types précis de documents que les types simples qui peuvent concerner des documents ayant même des schémas différents. Types simples Les types simples sont définis à partir de la facette simpleType. Un schéma XML est accompagné de types basiques (string, long, date, ...) qui sont comparables aux types de base des langages de programmation. Les types simples sont des restrictions des types basiques. Ils comportent donc obligatoirement des facettes en plus. Cette application de restriction se fait par dérivation par exemple. Il existe plusieurs types de dérivations et la manière de dériver est différente pour un type simple et un type complexe. Albert Ritch – Les Web Services Page 17 novembre 2003 – v1.0 Dérivation par restriction Exemple de type simple en dérivant par restriction: <xsd:element name="codeBancaire" fixed="1"> <xsd:simpleType> <xsd:restriction base="xsd:string" <xsd:pattern value="[0-9]{4}\-[0-9]{6}\-[0-9]{4}"> </xsd:restriction> </xsd:simpleType> </xsd:element> Si un type simple est déclaré dans un type complexe, il est local. Sinon il est global et peut être réutilisé. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xsd:element name="codeBancaire"> <xsd:simpleType> <xsd:restriction base="xsd:string" <xsd:pattern value="\d{4}\-\d{6}\-\d{4}"> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="cordonnesBancaires"> <xsd:element name="banque" type="xsd:string"> <xsd:element ref="codeBancaire" fixed="1"> </xsd:element> </xsd:schema> Dérivation par union Il est également possible de créer des types composés à partir de types simples en appliquant l'opérateur union : <xsd:union memberTypes="typeSimple1 typeSimple2"> La dérivation d'un type simple peut être empêchée en la rendant final <xsd:union meberTypes="typeSimple1 typeSimple2" final=#all> Expressions régulières Les expressions régulières permettent d'ajouter des contraintes aux types de bases d'un type simple en définissant un motif auquel devra s'adapter un élément comme un chaine de caractères par exemple. C'est la facette pattern qui permet d'appliquer des expressions régulières à des éléments. Les caractères permettant de créer des expressions régulières sont notamment : • les caractères spéciaux (\n pour nouvelle ligne, \r pour retour de chariot, \\ pour le caractère \, ...) • les caractères génériques qui permettent de remplacer n'importe quel caractère • les classes de caractère qui sont issues des langages Perl et Unicode plus une série d'ajouts Albert Ritch – Les Web Services Page 18 novembre 2003 – v1.0 Types complexes Les types complexes définissent les types des éléments et la structure des éléments les composant. Exemple : <xsd:complexType name="TypeAdresse"> <xsd:sequence> <xsd:element name="numero" type="xsd:int"/> <xsd:element name="rue" type="xsd:string"/> <xsd:element name="codePostal" type="xsd:string"/> <xsd:element name="ville" type="xsd:string"/> <xsd:element name="pays" type="xsd:string"/> </xsd:sequence> </xsd:complexType> 2.1.3 Liens XML Les liens XML permettent de pointer d'un document vers un autre tout comme les liens HTML. Deux méthodes sont disponibles pour gérer les liens : XLink et XPointer. XLink est équivalent aux liens HTML pour naviguer de page en page alors que XPointer est équivalent aux ancres qui permettent de naviguer à l'intérieur du document. En plus de reprendre les caractéristiques des liens HTML, les liens XML apportent des fonctions supplémentaires comme par exemple la possibilité de pointer vers plusieurs documents ou d'utiliser n'importe quelle balise XML comme lien alors que HTML impose la balise <a></a>. Exemple de lien simple : <nom xmlns:xlink="http://www.w3.org/1999/xlink/" xlink:type="simple" xlink:href="http://www.site.com" xlink:title="Titre du lien"> Dupont </nom> 2.2 Parsing de documents XML Le parsing est la transformation d'un document XML en code source. L'application accède aux services proposés par l'API pour parser le document XML afin d'accéder, de créer et de mettre à jour un document XML. Le parsing peut se comparer à la compilation. Le parser vérifie tout d'abord que le document XML est bien construit et si ce n'est pas le cas il s'arrête à la première erreur. Le parsing de documents XML peut se faire de deux manières : Avec DOM (Document Object Model) qui est une spécification standardisée par le W3C ou avec SAX (Simple API for XML) qui est une spécification opensource non standardisée mais étant devenue une norme de fait. Albert Ritch – Les Web Services Page 19 Fig. 2-1 : Parsing de document XML novembre 2003 – v1.0 Alors qu'un parser DOM « compile » un fichier XML en générant un arbre d'objets en mémoire, SAX déclanche des événements correspondants aux ouvertures / fermetures de balises du document. Implémentations Il existe des implémentations des spécifications DOM et SAX pour tous les langages. Par exemple, MSXML est l'implémentation de DOM incluse dans Microsoft Internet Explorer. Dans le monde Java, les implémentations JAXP3 de Sun ou Xerces4 de Apache sont disponibles. 3. JAXP : http://java.sun.com/xml/jaxp/ 4. Xerces : http://xml.apache.org/ Albert Ritch – Les Web Services Page 20 novembre 2003 – v1.0 3. Architecture et normes des Web Services 3.1 Spécifications des Web Services Les spécification des éléments des Web Services sont établies par deux organismes, le W3C (World Wide Web Consortium) et le WS-I (Web Services Interoperability Organization). Le W3C, organisme de définition des éléments du Web travaille en collaboration avec le WS-I qui a été créé par Microsoft, IBM et BEA afin de promouvoir les Web Services. On peut citer également l'OASIS, organisme de spécification des annuaires des Web Services, UDDI. Les spécifications consistent en des règles soumises à différents niveaux d'obligations comme par exemple MUST pour obligatoire, SHOULD pour recommandé, OPTIONAL pour optionnel, SHOULD NOT pour non recommandé ou MUST NOT pour interdit. En juin 2003, le W3C annonce la disponibilité des spécifications de la version 1.2 de SOAP qui passe à l'état de recommandation, ce qui en fait un standard. Cette évolution très attendue permet de corriger un grand nombre d'erreurs et d'améliorer la représentation des données (par schémas XML) ainsi que leur codage. Etant donné que les spécifications de la version 1.2 sont récentes, ce chapitre va également traiter la version 1.1 de SOAP. Concernant WSDL, la version actuelle est la 1.1 et la 1.2 devrait apparaître en 2004. Cependant le W3C confirme qu'il est tout à fait possible d'utiliser SOAP 1.2 avec WSDL 1.1. On peut trouver les spécifications de SOAP 1.15 sur le site du WS-I et pour les spécifications de SOAP 1.26 sur le site du W3C (documents « SOAP Version 1.2 Part 0: Primer », « SOAP Version 1.2 Part 1: Messaging Framework », « SOAP Version 1.2 Part 2: Adjuncts » et « SOAP Version 1.2 Specification Assertions and Test Collection »). Note : dans ce travail les version 1.1 et 1.2 de SOAP seront les deux utilisées mais avec une annotation. 3.2 SOAP [MAE03], [CHA102], [ENG03], [SOA203], [SOA103] SOAP (Simple Object Access Protocol) est un protocole de transmission de messages basé sur XML. Il définit le format des messages qui sont utilisés pour des requêtes unidirectionnelles et plus généralement bidirectionnelles de type RPC qui permettent d'invoquer des méthodes distantes. Indépendant des systèmes d'exploitation ou des langages de programmation, SOAP utilise principalement HTTP comme protocole de transport à travers les réseaux bien qu'il puisse utiliser d'autres protocoles comme SMTP ou FTP. Les implémentations de SOAP doivent donc obligatoirement supporter HTML. Historiquement, très peu de temps après la publication de la première spécification XML en 1998 par le W3C, un groupe de développeurs met au point un protocole d'appel de procédures distantes de type RPC nommé XML-RPC. Ensuite apparaissent des outils de manipulation de XML de plus en plus performants pour des langages divers. C'est à partir de XML-RPC que SOAP va être élaboré. 5. Spécifications SOAP 1.1 (site du WS-I) : http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.html 6. Spécifications SOAP 1.2 (site du W3C) : http://www.w3.org/2000/xp/Group/ Albert Ritch – Les Web Services Page 21 novembre 2003 – v1.0 Grâce à SOAP il est possible, par exemple, d'invoquer des méthodes d'EJB à partir d'un client écrit en C#. En effet, SOAP est un protocole d'échange Web qui se doit d'être indépendant des environnement d'exécution, des langages et des systèmes d'exploitation. 3.1.1 Structure d'un message SOAP Un message SOAP est encapsulé dans une enveloppe. Cette enveloppe contient une en-tête qui est facultative et un corps. Fig. 3-1 : Enveloppe SOAP Voici la structure d'une enveloppe SOAP (SOAP 1.2) : <?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope "> .. .. </env:Envelope> 3.1.2 Exemples de base de messages SOAP (SOAP 1.2) Voici un message SOAP très simple correspondant à la figure 3-1 : <?xml version="1.0" ?> <env:Envelope xmls:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> <h:DonneHeureCourante xmlns:h="Horloge"> <h:format>hhmmss</h:format> </h:DonneHeureCourante> </env:Body> <env:Envelope> Et voici la réponse : <?xml version="1.0" ?> Albert Ritch – Les Web Services Page 22 novembre 2003 – v1.0 <env:Envelope xmls:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> <h:DonneHeureCourante xmlns:h="Horloge"> <h:heure>14:34:20</h:heure> </h:DonneHeureCourante> </env:Body> <env:Envelope> Prenons un autre exemple plus concret. Axis comprend un utilitaire nommé tcpmon qui permet d'intercepter les messages SOAP, agissant comme un intermédiaire entre le client et le Web Service. Il écoute sur un port d'entrée, intercepte les messages SOAP et les renvoie au port correspondant au Web Service. Prenons pour exemple le Web Service très simple de l'annexe B.1. Pour pouvoir passer par tcpmon, il faut légèrement modifier le code du client, à savoir le fichier CalcClient2.java issu du fichier renommé CalcClient.java. Modifions la ligne comportant le string de localisation du Web Service de : String endpoint = "http://192.168.1.33:" + options.getPort() + "/axis/Calculator.jws"; ...en : String endpoint = "http://192.168.1.33:8070/axis/Calculator.jws"; En fait le port du serveur Axis est bien le 8080, mais changeons le en 8070 qui sera le port d'entrée de tcpmon. Après compilation (se référer à l'annexe B.1) de CalcClient2.java, lancer tcpmon : java org.apache.axis.utils.tcpmon Puis invoquer le Web Service. java meo1/CalcClient2 add 4 3 Voici le message SOAP (SOAP 1.1) envoyé au serveur : <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <add soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <op1 xsi:type="xsd:int">4</op1> <op2 xsi:type="xsd:int">3</op2> </add> </soapenv:Body> </soapenv:Envelope> Et voici la réponse : <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <addResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <addReturn xsi:type="xsd:int">7</addReturn> </addResponse> Albert Ritch – Les Web Services Page 23 novembre 2003 – v1.0 </soapenv:Body> </soapenv:Envelope> On constate bien le codage des paramètres dans l'enveloppe SOAP ainsi que le résultat retourné. On peut également voir les types. On peut également constater dans la figure ci-dessous l'interception du message par tcpmon. Fig 3-2 : Interception de l'invocation du service Calculator Header (entête) L'entête est facultative mais si elle est présente, elle doit avoir la forme suivante : <env:Header> <\env:Header> Les header servent à ajouter des éléments utilisés dans les transactions, la sécurité ou les chaînes d'acheminement. 3.1.3 Chaînes d'acheminement Le transfert d'un message SOAP se fait généralement directement, de l'expéditeur au récepteur. Cependant, il est également possible qu'une série d'intermédiaires se situent entre l'expéditeur et le récepteur, formant une chaîne d'acheminement. Un intermédiaire appellé noeud intermédiaire, doit donc être en mesure de recevoir le message et de le renvoyer. Le but d'une chaîne d'acheminement est d'offrir des fonctionnalités supplémentaires comme la mise en cache, le cryptage et également la mise en place d'un routeur de services. 3.1.4 Typage Le typage des données de SOAP peut se faire soit en utilisant un XML Schema (XSD) externe, soit en incluant le typage dans le message. Dans le cas de l'utilisation d'un XML Schema externe (voir chap. 2), on va indiquer une référence à ce schéma. <c:codepostal xmlns:ens="http://www.site.com/schema.xsd"> CH-1234 </c:codepostal> Le fichier XML Schema va alors contenir le type de codepostal : <xs:element name="codepostal" type="xs:string"/> Dans le cas de l'inclusion directe du type dans le message, on utilise l'attribut xs:type : <c:codepostal xs:type="xs:string">CH-1234</ens:codepostal> Albert Ritch – Les Web Services Page 24 novembre 2003 – v1.0 Exemples de type Java avec leur correspondance SOAP : int a = 15; float x = 3.1415; java.lang.String s = "Bonjour"; <a xs:type="xs:int">15</a> <x xs:type="xs:float">3.1415</x> <s xs:type="xs:string">Bonjour</s> On peut également générer des tableaux avec des valeur composées : int[3] tableau = {100, 200, 300}; <tableau xs:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xs:int[3]"> <val>100</val> <val>200</val> <val>300</val> </tableau> 3.1.5 Gestion des erreurs Lors d'envoi de messages SOAP, des erreurs peuvent survenir lorsque la sémantique ou la syntaxe du message est incorrecte. Il est possible également que le récepteur ne puisse traiter le message. Une erreur SOAP est identifiée comme telle lorsque la connexion au service à bien été effectuée, que le message a bien été envoyé et que le message d'erreur ait été reçu en retour. Exemple de faute SOAP (SOAP 1.2) : <env:Envelope xmls:env="http:schemas.xmlsoap.org/soap/envelope/"> <env:Body> <env:Fault> <faultcode>env:Client</faultcode> <faultstring>Erreur Client</faultstring> <reason> <h:detailsfauteheure xmlns:h="Horloge"> <message>Le format jjmmaa est incorrect</message> <errorcode>1234</errorcode> </h:detailsfauteheure> </reason> </env:Fault> </env:Body> <env:Envelope> Certains langages de programmation tels que Java ou C++ possèdent un mécanisme de traitement des erreurs nommé exceptions. Lorsqu'une erreur survient dans un Web Service écrit par exemple en Java, une exception est levée. L'exception sera alors utilisée pour traiter le contenu du message SOAP d'erreur. Elément faultcode L'élément code (faultcode pour SOAP 1.1) est un sous élément de l'élément fault. Il permet au récepteur d'identifier la faute et d'agir en conséquence. Exemple : <code>env:Client</code> L'élément code peut contenir quatre types de codes caractérisant la faute. • VersionMismach est un code signalant que les balises de structure ne sont pas conforme à SOAP. • MustUnderstand signale que le récepteur n'a pas été en mesure de traiter un message qu'il se Albert Ritch – Les Web Services Page 25 novembre 2003 – v1.0 devait de traiter (MustUnderstand=1). Sender (Client avec SOAP 1.1) signale que le message est incorrect sémantiquement ou syntaxiquement, ou que l'information à traiter contenue dans le message est erronée ou absente. L'expéditeur est alors dans l'obligation de réécrire le message. • Receiver (Server avec SOAP 1.1) signale que l'erreur n'est pas due à l'expéditeur mais à un problème technique lié à un des noeuds intermédiaires ou au récepteur. Le message pourra être renvoyé tel quel. • DataEncodingUnknow (apparu avec SOAP 1.2) signale que le contenu du message ne peut être décodé. • Ces codes ne peuvent être autres que ceux énoncés ci-dessus (aucun code personnalisé ne peut apparaître). Elément faultstring L'élément faultstring permet d'ajouter un texte lisible par une personne. Exemple : <faultstring>Erreur Client</faultstring> Elément faultactor L'élément faultactor est facultatif mais si il est présent, il désigne le responsable de la faute. Exemple : <faultactor>http://www.service.com/unservice</faultactor> Elément detail L'élément detail donne des informations concernant les fautes. Si la faute n'est pas due à l'élément body alors l'élément detail ne doit pas être inclus. Elément reason L'élément reason donne des informations sur la faute et est lisible par un humain. Il est requis. 3.1.6 Attachements Les attachements de pièces jointes permettent de joindre un fichier tel qu'une image, un document pdf ou un fichier XML Schema par exemple. Il faut noter que ces fichiers joints seront encodés en binaire. Albert Ritch – Les Web Services Page 26 novembre 2003 – v1.0 3.3 WSDL [MAE03], [CHA102], [ENG03] WSDL (Web Service Description Language) permet de décrire de manière abstraite les opérations et messages d'un Web Service. Ce langage permet de développer la partie client de l'application invoquant le Web Service. Sans WSDL cela impliquerait que le client et le serveur soit connu et gérés par le même développeur. Ce cas de figure contraindrait à une faible réutilisabilité du Web Service. 3.3.1 Structure d'un fichier WSDL Pour illustrer l'analyse de la structure d'un fichier WSDL, prenons à nouveau un exemple pratique mis en oeuvre dans l'annexe B-2, à savoir un calculateur de Francs en Euro (et inversement). Cet exemple va nous permettre tout d'abord d'analyser la structure du document, puis d'étudier l'utilité d'un document WSDL en analysant le résultat de la création, à partir du document WSDL, des fichiers nécessaires au client et au serveur du Web Service. <?xml version="1.0" encoding="UTF-8"?> Definitions et espaces de noms <wsdl:definitions targetNamespace="urn:Exchange" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="urn:Exchange" xmlns:intf="urn:Exchange" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> Messages <wsdl:message name="enEuroRequest"> <wsdl:part name="franc" type="xsd:double"/> </wsdl:message> <wsdl:message name="enFrancRequest"> <wsdl:part name="euro" type="xsd:double"/> </wsdl:message> <wsdl:message name="enEuroResponse"> <wsdl:part name="enEuroReturn" type="xsd:double"/> </wsdl:message> <wsdl:message name="enFrancResponse"> <wsdl:part name="enFrancReturn" type="xsd:double"/> </wsdl:message> Ports types (opérations) <wsdl:portType name="Exchange"> <wsdl:operation name="enFranc" parameterOrder="euro"> <wsdl:input message="impl:enFrancRequest" name="enFrancRequest"/> <wsdl:output message="impl:enFrancResponse" name="enFrancResponse"/> </wsdl:operation> Albert Ritch – Les Web Services Page 27 novembre 2003 – v1.0 <wsdl:operation name="enEuro" parameterOrder="franc"> <wsdl:input message="impl:enEuroRequest" name="enEuroRequest"/> <wsdl:output message="impl:enEuroResponse" name="enEuroResponse"/> </wsdl:operation> </wsdl:portType> Bindings <wsdl:binding name="ExchangeSoapBinding" type="impl:Exchange"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="enFranc"> <wsdlsoap:operation soapAction=""/> <wsdl:input name="enFrancRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encod ing/" namespace="urn:Exchange" use="encoded"/> </wsdl:input> <wsdl:output name="enFrancResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:Exchange" use="encoded"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="enEuro"> <wsdlsoap:operation soapAction=""/> <wsdl:input name="enEuroRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:Exchange" use="encoded"/> </wsdl:input> <wsdl:output name="enEuroResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:Exchange" use="encoded"/> </wsdl:output> </wsdl:operation> </wsdl:binding> Service <wsdl:service name="ExchangeService"> <wsdl:port binding="impl:ExchangeSoapBinding" name="Exchange"> <wsdlsoap:address location="http://192.168.1.33:8080/axis/services/Exchange"/> </wsdl:port> </wsdl:service> </wsdl:definitions> Définitions Les définitions sont l'élément racine du document. Il comprend les espaces de noms et le corps du document. Messages Les messages décrivent de manière abstraite les types des données échangés entre le client et le serveur. Albert Ritch – Les Web Services Page 28 novembre 2003 – v1.0 Opérations Chaque opération est composé de messages d'entrée et de sortie qui constituent une unité. PortType Un type de port est une liste d'opérations du Web Service décrit. Les ports types sont des descriptions abstraites. Binding Décrit de manière concrète les implémentations du Web Service. Lie un PortType à un protocole comme SOAP, HTTP, ... . Un PortType peut avoir plusieurs binding. Services Définit l'adresse à laquelle le service pourra être invoqué. Certains logiciels comme XMLSPY permettent entre autre de créer / éditer un fichier WSDL et de le visualiser sous forme graphique. Cape Clear propose WSDL Editor qui est un logiciel gratuit permettant de créer / éditer des fichiers WSDL. Ci-dessous un exemple inclus dans le logiciel mettant en évidence les PortTypes notamment. Fig 3-3 : Représentation schématique d'un fichier WSDL avec XMLSPY 3.3.2 Utilisation d'un document WSDL Une entreprise voulant utiliser un Web Service d'un partenaire par exemple, va se servir du fichier WSDL décrivant le Web Service en question, afin de développer la partie client, en utilisant n'importe quel langage. Dans le cas de la création simultanée du Web Service et du client, il suffit de créer une interface du Web Service, de générer à partir de celle-ci le fichier WSDL correspondant et de le mettre à la disposition du développeur de la partie client afin qu'il puisse développer celle-ci indépendamment. Albert Ritch – Les Web Services Page 29 novembre 2003 – v1.0 Prenons un cas concret, par exemple un Web Service de simple addition nommé « Additionneur » dont voici l'interface (Java) : public interface Additionneur { public double add(double arg1, double arg2); } Admettons donc que le client et le Web Service soient écrits en Java et prenons par exemple l'utilitaire java2WSDL fournis avec Axis7 qui fait partie du package org.apache.axis.wsdl. C'est grâce à lui, comme son nom l'indique, que nous allons créer le fichier WSDL à partir de l'interface java du Web Service (Additionneur.class). Seconde étape, il faut générer les classes java utiles pour le client et le serveur. C'est l'utilitaire WSDL2java qui va nous permettre d'effectuer cette opération et créer les fichier suivants : Additionneur.java (classe interface serveur) C'est une nouvelle version de l'interface créée précédemment qui va en plus étendre la classe java.rmi.RemoteException. Bien que nous n'utilisions pas RMI, ceci va permettre de gérer les exceptions et de créer une faute incluse dans le message d'erreur SOAP en cas d'erreur et donc de levée d'exception. AdditionneurService.java Ce fichier est une interface permettant d'obtenir un objet Additionneur du Web Service (en fait un Stub). AdditionneurServiceLocator.java (classe client) Factory implémentant l'interface AdditionneurService.java. Le client ne va pas instancier directement le stub. La classe client (par exemple AdditionneurClient) va donc instancier AdditionneurServiceLocator afin de pouvoir utiliser ses méthodes pour obtenir une instance de la classe AdditionneurSoapBindingStub à partir des méthodes de laquelle l'invocation du service pourra être faite. AdditionneurSoapBindingStub.java (classe client) Classe concrète implémentant la nouvelle interface Additionneur.java. C'est la partie cliente qui permet de faire la connexion avec le Web Service en générant un message SOAP contenant le nom de la méthode du Web Service avec ses paramètres. Il sert également à décoder le message SOAP afin de transformer le résultat en paramètres lisibles par le client. AdditionneurSoapBindingSkeleton.java (classe serveur) Classe concrète implémentant la nouvelle interface Additionneur.java. C'est la partie serveur qui permet de décoder / encoder le message SOAP faisant le lien entre le service écrit en Java et le XML du message SOAP. AdditionneurSoapBindingImpl.java (classe serveur) C'est l'implémentation du Web Service. Il faut le compléter afin qu'il contienne la méthode concrète servant à additionner. 7. Axis est un projet du groupe Apache permettant de mettre en oeuvre des Web Services Albert Ritch – Les Web Services Page 30 novembre 2003 – v1.0 Fig 3-4 : Représentation schématique du fichier WSDL pris en exemple (XMLSPY) A travers cet exemple, on constate l'utilité d'un fichier de description d'un Web Service WSDL. Il permet de générer tout ce dont ont besoin le client et le serveur. En utilisant Axis, nous avons pu suivre pas à pas la génération des fichiers utiles à la création d'un Web Service et de son client. La création des fichiers utiles aux parties client et serveur se font de manière plus ou moins transparente en fonction des environnement de développement. Par exemple avec .NET Visual Studio, la création des fichiers de la partie client (stub, ...) se fait de manière totalement transparente pour le développeur (voir partie client C# annexe B-2). Il suffit d'indiquer la localisation du fichier WSDL et l'IDE en déduit automatiquement les services disponibles sous forme de méthodes. Remarque 1: la traduction française de stub et de skeleton est « souche ». Dans d'autres langages ces souches se nomment différemment : • .NET (DCOM) client : proxy serveur : stub • Java (RMI) client : stub serveur : skeleton • Web Services client : service proxy serveur : service implementation template Remarque 2 : Avec Corba, RMI ou DCOM, le principe du stub et skeleton est semblable. Albert Ritch – Les Web Services Page 31 novembre 2003 – v1.0 3.4 UDDI [MAE03] UDDI (Universal Description, Discovery and Integration) est apparu en 2000 sous l'impulsion de trois entreprises : Microsoft, Aribas et IBM. C'est le groupement UDDI Community qui a géré son évolution jusqu'à la version 2 en ralliant de grandes entreprises comme Sun ou HP. C'est dorénavant OASIS, un organisme spécialisé dans les spécifications XML qui va gérer le développement de UDDI. UDDI est la troisième brique des Web Services et offre un moyen de les localiser. En fait, UDDI fait plus que cela. Il est tout d'abord un annuaire général permettant d'avoir de nombreuses informations sur les entreprises répertoriées. Il comporte 3 types de pages qui sont chacune dédiées à de l'information précise. Les pages blanches sont une fiche signalétique comportant des informations générales de l'entreprise (téléphone, contact, mail, ...). Les pages vertes comportent les descriptions techniques de l'entreprise comme l'accès à son service après vente, produits vendus, etc. Les pages jaunes quand à elles référencent les différents Web Services proposés par l'entreprise ainsi que le moyen d'y accéder. 3.4.1 Structure de documents UDDI Fig. 3-5 : Structure de document UDDI BusinessEntity (entité commerciale) Cet élément qui est la racine du document UDDI, décrit le référencement d'un Web Service. Il indique notamment les coordonnées de l'entreprise (nom, adresse mail, description, ...). BusinessService (description des services) Il décrit les Web Services par leur nom, description, catégorie, clé de recherche et liaisons (binding templates). Albert Ritch – Les Web Services Page 32 novembre 2003 – v1.0 BindingTemplate (liaisons) Il regroupe les liens d'accès du Web Service ainsi que le protocole à utiliser. Tmodel (modèles de données) Il inclut des liens vers les fichiers de description (WSDL) du Web Service. 3.4.2 Accès à un annuaire UDDI L'accès aux annuaires UDDI peut se faire de deux manières différentes. Via un browser pour comme tout site Web normal ou par programmation en utilisant les API d'accès comme par exemple UDDI4J qui est une implémentation Java de la spécification UDDI. Accès via un browser Nous allons voir comment accéder à un serveur UDDI, via l'annuaire d'IBM8. Nous allons accéder à un service de météo aux USA. Fig 3-6 : Recherche dans l'annuaire UDDI d'IBM Nous allons rechercher les entreprises (business) portant sur la météo en entrant « weather » dans le champ « Starting with » et cliquer sur « Find ». 8. Addresse : https://uddi.ibm.com/ubr/registry.html Albert Ritch – Les Web Services Page 33 novembre 2003 – v1.0 Fig 3-7 : Résultats de la recherche Une série d'entreprises sont trouvées et nous allons choisir « WeatherService » qui indique la météo aux USA en fonction du code postal. On constate, qu'une série d'informations caractérise l'entreprise. Outre son nom, sa description, ses coordonnées, etc, on constate qu'un fichier WSDL est présent ainsi qu'un code nommé key qui identifie l'entreprise de manière unique. Fig 3-8 : Description de l'entreprise Cette recherche peut se faire avec d'autres outils comme UDDI Browser, un utilitaire inclus dans WSDL Editor (voir plus haut). Chaque service proposé par l'entreprise possède également une clé unique d'identification. Accès via la programmation L'accès via un browser implique obligatoirement un intervention humaine alors qu'il est souvent utile Albert Ritch – Les Web Services Page 34 novembre 2003 – v1.0 d'accéder à un annuaire UDDI de manière automatisée. Pour cela, il faut utiliser une implémentation de l'API OASIS. On peut trouver les spécifications de l'API d'accès à un annuaire UDDI sur le site de l'organisme OASIS9. Tab 3-1 : Les requêtes accessibles prévues dans l'API Fonction But Message retourné find_binding find_business find_relatedBusiness es find_service find_tModel get_bindingDetail get_businessDetail Recherche d'un binding spécifique à partir d'un service business précis. Recherche des informations d'une entitié business Recherche des informations d'une entitié business à partir d'une autre entité business dont la clé d'identification est passée en paramètre Recherche d'un service d'une entité business Recherche d'un service type Recherche d'une liaison d'un service. Recherche les informations d'une entité business d'une entreprise ou organisation get_bindingDetailExt Recherche d'un information étendue sur une entité business get_serviceDetail Recherche des informations détaillées sur une entité business get_tModelDetail Recherche des informations sur un service type bindingDetail businessList relatedBusinessesL ist serviceList tModelList bindingDetail businessDetail businessDetailExt serviceDetail tModelDetail Pour illustrer la programmation de requêtes vers un annuaire UDDI, nous allons utiliser UDDI4J, l'implémentation IBM de l'API UDDI. Nous allons mettre en oeuvre la fonction find_business. Les packages utilisés sont UDDI4J10, xmlParserAPIs, jaxrpc et commons-loggin (voir installation de Axis annexe B1) package meoUddi; import org.uddi4j.client.*; import org.uddi4j.datatype.Name; import org.uddi4j.response.*; import org.uddi4j.transport.TransportFactory; import java.util.Vector; public class UDDIGetBusinessMeo5 { /** Creates new UDDIGetBusinessMeo5 */ public UDDIGetBusinessMeo5() { } public static void main (String args[]) throws Exception { // Création du stub UDDI client à l'aide de la factory UDDIProxy et // .. choix du serveur UDDI System.setProperty(TransportFactory.PROPERTY_NAME, "org.uddi4j.transport.ApacheAxisTransport"); UDDIProxy proxy = new UDDIProxy(); // le point d'entrée pour la demande d'information est celui d'IBM proxy.setInquiryURL("http://www3.ibm.com/services/uddi/inquiryapi"); // nom du Business recherché : Weather // remarque : on peut ajouter des Name au vecteur, par exemple "IBM" ce // .. qui produit la recherche de "Weather" et "IBM" Vector termes = new Vector(); 9. http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm 10. UDDI4J : http://www-124.ibm.com/developerworks/oss/uddi4j Albert Ritch – Les Web Services Page 35 novembre 2003 – v1.0 termes.add(new Name("Weather")); // on pourrait très bien ajouter des noms de recherche au vecteur BusinessList bList = new BusinessList(); bList = proxy.find_business(termes, null, null, null, null, null, 0); // Listing du résultat BusinessInfos bInfos = new BusinessInfos(); bInfos = bList.getBusinessInfos(); if (bInfos.size() == 0) { System.out.println("Aucune entité business trouvée"); } else { System.out.println(bInfos.size() + " entité(s) business trouvée (s) :\n"); Vector temp = bInfos.getBusinessInfoVector(); for (int i = 0; i < bInfos.size(); i++) { System.out.println(((BusinessInfo)temp.elementAt(i)). getDefaultNameString()); System.out.println(" " + ((BusinessInfo)temp.elementAt (i)).getBusinessKey()); System.out.println ("-----------------------------------------"); } // else } // if } // main } // UDDIGetBusinessMeo5 Le résultat retourné liste bien l'entité business que nous avions trouvée plus haut avec le browser. 8 entité(s) business trouvée(s) : Calibre Software Solutions C3C56585-99FF-494D-8EFD-E63C0655DE77 ----------------------------------------Weather Provider 85FC4F5A-AB34-4AB6-97ED-3607E1847840 ----------------------------------------Weather in Powell 811233F0-C677-11D6-883C-000629DC0A53 ----------------------------------------WeatherBusinessTest 92BF57B3-4FFB-4B8E-8102-E84ED794DCAB ----------------------------------------WeatherService 840CCF43-DA21-48C2-AE95-A0D3415B7E5E ----------------------------------------Weatherbee Consulting 90C0E220-32CE-11D6-87CE-000C0E00ACDD ----------------------------------------Weatherly's Technical Writing and Consulting, Inc. (dba) JTWC, Inc. 682738F0-BF78-11D6-905B-000629DC0A53 ----------------------------------------weather 69AEEC70-46FD-11D6-9B35-000C0E00ACDD ----------------------------------------- Albert Ritch – Les Web Services Page 36 novembre 2003 – v1.0 3.4.3 Publication d'un Web Service Les annuaires UDDI peuvent être publics comme celui d'IBM ou privé, par exemple pour une entreprise et ses différents secteurs. Albert Ritch – Les Web Services Page 37 novembre 2003 – v1.0 4. Les Web Services et les protocoles d'applications distribuées Les architectures distribuées actuelles sont toutes inféodées à la spécificité de leur plate-forme. Chaque éditeur proposant des logiciels permettant de créer des architectures distribuées se base sur des protocoles de communication qu'il a créés mais qui sont très souvent incompatibles avec ceux d'autres plates-formes. Par exemple les EJB (Enterprise Java Bean) de Sun ne peuvent communiquer directement avec des logiciels distribués aux normes COM+ de Microsoft. Si la qualité et la puissance des EJB ou de COM+ sont reconnues, ils leur manque un pont technologique afin qu'ils puissent communiquer dans le cas d'architectures distribuées hétérogènes. C'est la raison pour laquelle des technologies intermédiaires comme CORBA ont vu le jour. CORBA a été mis au point par un groupement d'éditeurs dans le but de palier aux problèmes d'interopérabilité. Néanmoins CORBA a ses limites, notamment dues à la complexité de mise en oeuvre et à sa lourdeur. Les Web Services permettent d'apporter une solution à ce problème en permettant notamment de s'affranchir de la contrainte de la plate-forme ou du langage de programmation. Il est alors possible d'utiliser des EJB avec un client écrit avec C#. De même, il sera possible pour un Web Service de faire office de connecteur dans le contexte des EAI. On peut alors légitimement se demander si les Web Services vont remplacer les technologies comme CORBA. Après un panorama des protocoles d'accès à distances nous allons tenter de répondre à cette question. Les Web Services peuvent donc être utilisés, entre autres, dans de nombreux contextes : • • • • EAI (ESB) Applications B2B (Ex : banque et organisme de carte de crédit) Applications client serveur hétérogènes (Ex : client C# et serveur J2EE) Liaison entres serveurs hétérogènes Ce chapitre va aborder l'utilisation des Web Services dans le contexte des architectures distribuées, alors que le chapitre suivant portera sur l'utilisation des Web Services dans les technologies d'intégration (EAI). 4.1 Les protocoles de communication dans les architectures distribuées [OMG03], [SUN03] 4.1.1 RMI RMI (Remote Method Invocation) est une API permettant de communiquer avec des objets distants Java. On parle de RMI/IIOP car RMI se base sur IIOP depuis la version 2 de Java. IIOP est un protocole de communication normalisé par l'OMG et qui est également utilisé par CORBA. Fonctionnement : Lorsque le client désire accéder à des méthodes d'un objet distant il passe par l'intermédiaire du stub qui, comme nous l'avons vu plus haut est une représentation de l'objet distant. Le stub (proxy) sérialise l'invocation de la méthode distante (marshalling) et le skeleton la déserialise au niveau du serveur. Les données (résultat) sont retournées par le chemin inverse. Afin de trouver un service distant, le client utilise un service de nommage (rmiregistry). Albert Ritch – Les Web Services Page 38 novembre 2003 – v1.0 4.1.2 EJB Les EJB (Enterprise Java Bean) sont des objets distribués dans la plate forme J2EE dont l'accès se fait avec RMI. Les EJB sont des composants réutilisables qui s'exécutent dans un conteneur d'EJB. 4.1.3 COM+ COM+ (Component Object Model) est la version Windows de gestion des objets distribués. C'est une version améliorée de COM intégrant en plus la gestion des transaction, la sécurité et un protocole semblable à IIOP de CORBA nommé DCOM. 4.1.4 .NET Remoting Pour pouvoir communiquer avec ses objets distribués, Microsoft à mis au point .NET Remoting qui peut s'apparenter à RMI. Avec .NET Remoting, les données peuvent transiter soit en binaire, soit avec SOAP. 4.1.5 CORBA L'OMG (Object Management Group) est un consortium qui regroupe des acteurs du monde informatique (constructeurs, éditeurs de logiciels, ...). CORBA est globalement un bus logiciel à travers lequel des objets peuvent communiquer. Fig. 4-1 : Requête à un objet distant L'interopérabilité entre bus ORB (inter-ORB) est réalisé à l'aide du protocole IIOP. Il définit donc une architecture client-serveur où les objets sont distribués. CORBA est censé supporter tous les langages de programmation, cependant à l'heure actuelle seuls C, C++, Ada, SmallTalk, Cobol, Ada 95, Perl, Eiffel et Java le sont. 4.1.6 Autres technologies (Janeva) Janeva est un pont technologique qui permet aux applications .NET de communiquer avec les composants J2EE ou CORBA. Cette initiative de Borland qui propose des outils de développement aussi bien pour J2EE que pour .NET, montre le besoin des éditeurs de faire communiquer différentes plates-formes entre-elles. 4.2 CORBA et les Web Services On peut trouver de nombreuse affirmations sur les forums ou sur des sites web qui opposent CORBA Albert Ritch – Les Web Services Page 39 novembre 2003 – v1.0 aux Web Services. Souvent ces affirmations sont sans réel fondement et essaient de démontrer la supériorité de CORBA sur les Web Services ou inversement. Mais qu'en est-il réellement ? Les Web Services vont-ils détrôner CORBA, en devenir complémentaires ou tout simplement devenir une technologie de plus, comme un simple effet de mode ? 4.2.1 Avantage des Web Services par rapport à CORBA Devant l'utilité de faire communiquer des systèmes incompatibles, CORBA a vu le jour. On peut constater le parallèle avec l'introduction des Web Services. Tout comme les Web Services, CORBA est un standard permettant d'être indépendant de plate-formes ou de langages et de nombreuses entreprises soutiennent ce standard. Un langage de définition permet de décrire les objets distants, il s'agit de l'IDL (Interface Definition Language). Par rapport à CORBA, les Web Services présentent une flexibilité et une simplicité de mise en oeuvre très intéressante. De plus, ils ne sont pas forcément liés à la programmation objet, permettant à des langages non objets ou à des éléments de suite bureautique par exemple de consommer des Web Services. De plus, les Web Services sont à l'aise dans le cas d'ouverture vers Internet, car ils sont basés sur HTTP. Néanmoins on peut créer des applications Web avec CORBA en utilisant des applications CGI, ou des servlets par exemple. 4.2.1 Avantages de CORBA CORBA présente des performances supérieures aux Web Services. Ceci peut poser, pour les Web Services, des problèmes importants sur des architectures dont une forte réactivité est indispensable. Randy Heffner11 du Gigagroup met en avant ce problème « If an application requires response time of three seconds or less, one is well advised to examine the situation very closely before committing to Web Services as part of the architecture. It is no surprise that HTTP, Extensible Markup Language (XML) parsing and longer message lengths make Web Services slower than binary protocols such as CORBA and Java remote method invocation (RMI). But when XML’s slowing effect is exacerbated by other factors such as network latency and poor application design, performance can degrade more quickly than anticipated. » On le constate, CORBA prend l'avantage lorsque les performances sont critiques. 4.2.2 CORBA ou les Web Services ? En fait les deux ! Chacune des deux technologies présente des avantages et inconvénients qui les rendent complémentaires. On pourra donc utiliser les Web Service dans les cas d'intégration dans l'entreprise ou CORBA lorsque les performances sont importantes, et utiliser les Web Services dans les échanges de services avec les partenaires (échanges B2B). Malgré les allégations de ses détracteurs, de nombreux cas de réussite on été constatés dans l'implantation de CORBA par des entreprises12. 11. Randi Heffner – Gigagroup : « Web Services Performance: Be Careful When Three Seconds Is Too Slow » 25 juin 2003. 12. Le site suivant : http://www.corba.org/success.htm, présente des cas de « success stories » avec CORBA Albert Ritch – Les Web Services Page 40 novembre 2003 – v1.0 5. Les Web Services et les technologies d'intégration (EAI) [DHE01], [FER01], [CRO102], [JEA01], [01N03], [DHE02] Lors de la multiplication des applications incompatibles en entreprise (ERP, CRM, développement spécifique, ...) les groupes de recherche (Gartner Group, ...) ont constaté que les développements spécifiques des EAI au sein de l'entreprise posent de nombreux problèmes. Par exemple, les projets d'intégration sont très chers à développer et le dépassement en temps est chose fréquente. C'est pourquoi, dès les années 90, les entreprises on fait appel aux produits des éditeurs tels que IBM ou BEA. Néanmoins, ces EAI sont également très chers et complexes à mettre en oeuvre. Des EAI, dits légers, ont fait leur apparition mais sans percer, leur couverture fonctionnelle étant trop faible. C'est au vu de ces problèmes que se profile actuellement une nouvelle génération d'EAI qui se basent sur les technologies récentes dont notamment les Web Services. 5.1 Intégration point à point C'est le premier type d'intégration d'applications apparu. Les types d'intégration évoluent en fonction des besoins de l'entreprise et de la complexité d'intégration des applications. Dans le cas de l'apparition d'un progiciel dans l'entreprise par exemple, l'intégration aux autres applications peut se faire point à point (ou « network centric »). C'est à dire que des connecteurs sont développés spécifiquement pour chaque application, d'une application à l'autre (structure en étoile). L'avantage de ce type d'intégration se présente par des prix réduits et un développement fait à la demande. En revanche, lors d'un nombre trop élevé d'applications ou d'une complexification de l'intégration, il devient vite fastidieux et cher de développer de cette manière. Fig. 5-1 : Intégration point-à-point 5.2 EAI Une autre approche consiste en l'utilisation d'une plate-forme d'intégration sur laquelle les applications sont connectées. On l'appelle broker d'intégration (EAI) et c'est lui qui gère les communications entre les applications connectées. Cette structure facilite grandement l'intégration de nombreuses applications et permet d'en intégrer de nouvelles plus facilement. Par exemple dans le cas d'acquisition d'un progiciel, il suffira simplement d'acquérir un connecteur pour faire la liaison avec l'EAI. On parle d'interopérabilité des applications. Le middleware représente un élément des EAI, à savoir la transmission des données entre les applications. Albert Ritch – Les Web Services Page 41 novembre 2003 – v1.0 Les EAI sont structurés en plusieurs modules : • Les connecteurs Les connecteurs sont chargés de traduire les messages délivrés par le broker de messages à l'application et inversement. • le transport des informations entre les différentes De type « bus », ceci est réalisé par le middleware • le routage Ceci est réalisé par le broker de messages • la gestion des processus (gestion métier) Modélise le cycle de vie des messages gérés par le broker de messages, à savoir le flux interapplicatif • le repository (référentiel) et les règles de routage Consiste en une définitions des données entrant et sortant des applications (méta-données) et étant encapsulées dans les messages. Les règles de routages intervient au niveau du broker de messages • le module d'administration de Le centre de pilotage de l'EAI permettant de gérer et contrôler la sécurité, ... applications des de l'entreprise informations l'EAI Fig 5-2 : Broker d'intégration 5.2.1 Middleware Les middlewares des broker d'intégration sont principalement basés sur les architectures MOM (Middleware Oriented Message) ou ORB (Object Request Broker). Cependant il existe d'autres architectures tels que les RPC (Remote Procedure Call) ou les serveurs d'application Les MOM sont de type asynchrones et peuvent donc stocker les messages jusqu'à ce que l'application destinataire soit disponible. Dans les MOM on peut citer JMS de SUN ou MQ Series d'IBM. En oposition, les architectures de type synchrone relient directement les applications et la réception/renvoi du message est immédiate. Par exemple, les architectures à objets distribués sont de type synchrone. Albert Ritch – Les Web Services Page 42 novembre 2003 – v1.0 5.3 Convergence entre les EAI et le E-business Alors que les EAI traditionnels intègrent les applications dans l'entreprise, les serveurs d'application permettent d'ouvrir l'entreprise vers l'extérieur en proposant des services aux partenaires. Un serveur d'applications connecté à l'EAI, permet de partager les informations entre le système d'information de l'entreprise et ses partenaires. Maintenant que le serveur d'applications est relié au broker d'intégration, on peut se demander quelle sera l'intégration des partenaires avec notre système. C'est là que les Web Services interviennent. Par l'intermédiaire du serveur d'applications relié à au système, ils proposent des services aux partenaires de l'entreprise. Fig. 5-3 : Intégration avec les partenaires Albert Ritch – Les Web Services Page 43 novembre 2003 – v1.0 5.4 ESB (Enterprise Service Bus) [MAU203], [FAR03] Les ESB (Enterprise Service Bus) représentent une nouvelle génération d'EAI. Bâtis autour de standards comme les connecteurs JCA et les Web Services, les ESB ainsi baptisés par le Gartner Group, sont proposés jusqu'à un cinquième du prix des EAI traditionnels. L'avènement des ESB est lié à l'établissement de nouveaux standards tels que .NET, J2EE et les Web Services. Fig. 5-4 : ESB (Enterprise Service Bus) Dans le cas d'EAI traditionnels, il fallait faire appel aux connecteurs propriétaires des entreprises fournissant l'EAI multipliant ainsi les types de connecteurs. Avec les ESB, les connecteurs sont standards. Albert Ritch – Les Web Services Page 44 novembre 2003 – v1.0 6. Plates-formes et outils de développement [BUR203] , [LEO03], [VAW01] Les outils et plates-formes de développement dans la mise en place de Web Services étant très nombreux, il est utile de faire un comparatif des plus importants. On peut distinguer deux principales plates-formes permettant de déployer des Web Services : • La plate-forme J2EE • La plate-forme .NET Il faut également noter que les éditeurs Open Source propose des outils libres pour toutes platesformes confondues. Par exemple, Perl ou PHP disposent maintenant de plusieurs API pour les Web Services (par exemple nuSoap). 6.1 La plate-forme .NET La plate-forme .NET est constituée de plusieurs éléments dont : • le framework .NET qui est le pilier de base de la plate-forme • l'environnement de développement Visual Studio • les architectures serveur (Windows Server 2003) Fig. 6-1 : La plate-forme .NET Comme on peut le constater (voir fig 6-1), le framework .NET peut supporter de nombreux langages grâce à la CLR qui est une machine virtuelle ressemblant à celle de SUN. Un langage intermédiaire, le byte-code est interprété à la volée par la machine virtuelle. Albert Ritch – Les Web Services Page 45 novembre 2003 – v1.0 Les Web Services sont bien intégrés dans le framework .NET. En effet, Microsoft s'est très vite investi dans les Web Services, comme on a pu le voir précédemment. Fig. 6-2 : Architecture des Web Services avec .NET Peu d'éditeurs proposent d'IDE de développement pour la plate-forme .NET. Seul Borland, l'éditeur dont la réputation n'est plus à faire, propose C# Builder, un IDE permettant de développer en C#. On peut également citer une initiative intéressante de la communauté Open Source qui consiste en une implémentation du framework de développement .NET sous Linux portant le nom de projet Mono13. 13. Projet Mono : http://www.go-mono.com/ Albert Ritch – Les Web Services Page 46 novembre 2003 – v1.0 6.3 Plate-forme J2EE SUN s'est intéressé relativement tard dans les Web Services. En effet, SUN a été peu motivé d'adopter des standards proposés, en majorité, par ses concurrents. Même si SUN à doté sa plate forme d'outils performants (JWSDP) c'est en retard par rapport aux offres Microsoft qu'ils ont apparus. Fig. 6-3 : Plate-forme J2EE Actuellement les Web Services sont bien intégrés dans J2EE. Ils s'appuient à l'heure actuelle sur les servlets, mais les EJB devraient bientôt être utilisables directement en tant que Web Services. L'offre de SUN pour la création et le déploiement de Web Services consiste en un serveur d'applications, Sun One Server, et un IDE, Sun One Studio. Cependant de nombreux concurrents de SUN proposent des outils semblables qui respectent la norme J2EE. On peut citer IBM avec WebSphere Application Server et WebSphere Studio, BEA avec WebLogic Server et WebLogic Workshop, Borland avec Enterprise Server et Borland JBuilder, etc. Le monde Open Source apporte également ses solutions comme les serveurs d'application J2EE JBoss et JOnAS ainsi que les IDE de développement Eclipse et NetBeans. Une contribution également importante du monde Open Source est Tomcat, un serveur d'applications proposant un conteneur de servlets. Albert Ritch – Les Web Services Page 47 novembre 2003 – v1.0 Fig. 6-4 : Architecture des Web Services avec J2EE Albert Ritch – Les Web Services Page 48 novembre 2003 – v1.0 6.3 Récapitulatif des outils pour la mise en oeuvre des Web Services Les outils de mises en oeuvre sont très nombreux. En effet presque chaque entreprise propose ses outils. Tab 6-1 : Outils de mise en oeuvre de Web Services Type composant Serveurs d'applications deJ2EE .NET WebSphere application server Framework .NET (IBM) Sun One Server (SUN) Open Source ou autre JBoss (implémentation J2EE) Jonas (implémentation J2EE) Enhydra (implémentation J2EE) WebLogic Server (BEA) Tomcat (Apache – JSP, Servlets) Oracle 9iAS (Oracle) Mono (implémentation libre et open source de .NET) Enterprise Server 5.1 (Borland) Environnements d'exécution JVM CLR Utilisation de la JVM, CLR ou autre Environnements complets de développement intégrant le développement de Web Services XDE (IBM) Visual Studio .NET (Microsoft) Eclipse (J2EE) Sun One Standard Edition (SUN) JBuilder (Borland) WebSphere Studio (IBM) JWSDP (Java Web Services API pour le Developer Pack) développement de Web Services (client ou serveur) C# Builder (Borland .NET) NetBeans (J2EE) Delphi (Non libre - Borland) Kylix (Non libre – Borland) Matrix (Outil gratuit de Microsoft pour le Mono (.NET) développement de site en ASP.NET) Microsoft Soap Toolkit (.NET) Axis (Java) NuSoap (PHP) Soaplite (Perl) JWSDP (Non libre - Java Web Services Developer Pack) 6.1.1 API pour le développement de Web Services (client ou serveur) Les API proposées par les éditeurs de solutions Web Services, sont généralement incluses dans leurs environnements de développements (IDE). Voici le détail de quelques API proposées par de grands éditeurs. JWSDP ( Java Web Services Developer Pack) : [HAN03] Cette API proposée par SUN se compose des éléments suivants : JAXP (Java API for XML Processing) API Java permettant de parser des documents XML au moyen d'API DOM ou SAX (Xerces-J en est une implémentation) JAXB (Java Architecture for XML Binding) API Java servant à automatiser la conversion d'objets Albert Ritch – Les Web Services Page 49 novembre 2003 – v1.0 Java en XML et inversement. JAXB se fonde sur les W3C XML Shema pour définir la structure des documents XML. Le traitement d'un document XML avec JAXB aboutit à la création d'objets java auxquels il suffit d'accéder pour manipuler les informations du document XML. JAXR (Java API for XML Registries) API permettant l'accès à des registres standards (UDDI) JAX-RPC (Java API for Xml-based RPC) API Java pour appels RPC avec XML JAXM (Java API for XML Messaging) API Java permettant d'écrire et d'envoyer des messages XML via Internet JSTL (Java Standard Tag Library) Ensemble de tags proposant des fonctionnalités similaires aux JSP JSSE (Java Secure Socket Extension) Package permettant de faire communiquer un client Java avec un serveur HTTPS (HTTP sécurisé) SAAJ (SOAP with Attachments API for Java) API permettant l'envoi et la réception de messages respectant la spécification SOAP et SOAP with Attachment Outils compris dans le pack : • Apache Tomcat • Java WSDP Registry Server (serveur UDDI) • Web application development tool • Apache Ant (cf. make pour C++) Axis Axis est un ensemble d'outils libres permettant de créer et de déployer des Web Services. Couplé avec Tomcat, il permet de délivrer des Web Services à partir de servlets. Il propose des utilitaires permettant de générer les fichiers utiles pour le client, serveur, ainsi que pour le déploiement du Web Service. Il s'agit notamment de : java2WSDL Il permet de créer le fichier de description WSDL correspondant à l'interface du Web Service. WSDL2Java Il permet de générer automatiquement, à partir d'un document WSDL, un fichier Java qui encapsule les appels au Web Service. Les fichiers créés sont détaillés dans le chapitre 3.3 dédié à WSDL. Il est à noter que les utilitaires WSDL2Java et Java2WSDL existent en tant que plug-in pour Eclipse. Axis est une évolution de Apache SOAP qui lui-même a été développé à partir des utilitaires SOAP4J et WSDL4J offerts au groupe Apache par IBM. Albert Ritch – Les Web Services Page 50 novembre 2003 – v1.0 Microsoft SOAP Toolkit Cette API permet de développer des clients de Web Services en VBA (Visual Basic for Applications). Il est donc possible de rendre un logiciel de la suite Office cliente d'un Web Service. UDDI4J Cette API, proposée par IBM, permet d'accéder via la programmation à un annuaire UDDI. Il permet d'exécuter des requêtes de recherche ou de publication d'un Web Service. NusOAP NuSOAP est une API destinée à PHP. PHP étant un langage très populaire de scripts pour le Web, les nombreux développeurs l'utilisant vont pouvoir développer et consommer des Web Services via cette API. Les browser Web Les browsers phares du marché peuvent maintenant directement accéder à des Web Services en tant que clients. A l'aide de JavaScript et des composants spécifiques qu'ils intègrent, ils évitent de passer par un serveur de scripts. Il suffit alors d'écrire une page Web locale qui intègre les appels aux Web Services codés avec JavaScript. Albert Ritch – Les Web Services Page 51 novembre 2003 – v1.0 Annexe A : Installation et configuration de Tomcat et d'Axis [ROU02], [ROU03] A.1. Obtenir les softwares Remarque : les fichiers ci-dessous sont utilisables sous Windows et Linux. Axis Download d'Axis http://ws.apache.org/axis/ Version utilisée dans les mises en oeuvre : version 1.1 Tomcat Download de Tomcat http://jakarta.apache.org/site/binindex.cgi Version utilisée dans les mises en oeuvre : version 4.1.27 Lien direct du package http://sunsite.cnlab-switch.ch/www/mirror/apache/dist/jakarta/tomcat-4/tomcat-4.1.27.zip A.2. Installation et configuration de Tomcat Tomcat est un serveur d'applications faisant partie du projet Jakarta initié par le groupe Apache. Tomcat n'implémente pas complètement les spécifications J2EE mais uniquement les spécifications des JSP (Java Server Pages) ainsi que des servlets. Remarque : L'installation suivante de Tomcat (puis de Axis au point 3) est l'installation au niveau serveur. Comme pré requis il faut un JDK installé sur le serveur hébergeant Tomcat (jdk 1.3.0 ou supérieur). Puis, downloader Tomcat sur le site du projet Jakarta du groupe Apache et le décompresser dans un répertoire (ici : d:\users\tomcat-4.1.27). A.2.1 Lancement et arrêt de Tomcat : Afin de préciser les variables d'environnement locales telles que la JVM et l'emplacement de Tomcat, on peut créer des fichier batch de lancement / d'arrêt pour Tomcat. On peut placer ces fichiers dans le répertoire de Tomcat (d:\users\tomcat-4.1.27). A.2.1.1 Fichier de lancement Créer un fichier batch (.bat) nommé tomcatStartup.bat et y insérer les lignes suivantes : set JAVA_HOME=d:\java\jdk1.3.1 set TOMCAT_HOME=d:\users\tomcat-4.1.27 @%TOMCAT_HOME%\bin\startup Sous Linux : (tomcatStartup.sh) #! /bin/sh # startup.sh echo "------- Définition des chemins ---------" TOMCAT_HOME=/home/al/jakarta-tomcat-4.1.27 export TOMCAT_HOME echo "------- Lancement d'Axis ---------" $TOMCAT_HOME/bin/startup.sh Albert Ritch – Les Web Services Page 52 novembre 2003 – v1.0 A.2.1.2 Fichier d'arrêt Créer un autre fichier batch nommé tomcatShutdown.bat et y insérer les lignes suivantes : @%TOMCAT_HOME%\bin\shutdown Sous Linux (tomcatShutdown.sh) : $TOMCAT_HOME/bin/shutdown.sh A.2.1.3 Test du fonctionnement Pour vérifier que Tomcat est bien installé et fonctionne correctement, lancer le fichier tomcatStartup.bat et ouvrir l'URL suivante dans un browser : http://localhost:8080 La page suivante devrait apparaître : Fig. A-1 : Page de démarrage de Tomcat Albert Ritch – Les Web Services Page 53 novembre 2003 – v1.0 A.3. Installation et configuration d'Axis Télécharger Axis et le décompresser dans un répertoire temporaire. Axis contient un sous-répertoire webapps qui contient un autre sous-répertoire nommé axis. Décompresser ce sous-répertoire et le placer dans le répertoire TOMCAT_HOME\webapps Copier le fichier TOMCAT_HOME\common\endorsed\xercesImpl.jar TOMCAT_HOME\webapps\axis\WEB-INF\lib dans le répertoire Ajouter au fichier tomcatStartup.bat les lignes en rouge afin de mettre à jour le CLASSPATH en tenant compte de Axis : set JAVA_HOME=d:\java\jdk1.3.1 set TOMCAT_HOME=d:\users\tomcat-4.1.27 set AXIS_HOME=%TOMCAT_HOME%\webapps\axis set AXIS_LIB=%AXIS_HOME%\WEB-INF\lib set CLASSPATH=%CLASSPATH%;%AXIS_LIB%\axis.jar set CLASSPATH=%CLASSPATH%;%AXIS_LIB%\commons-discovery.jar set CLASSPATH=%CLASSPATH%;%AXIS_LIB%\commons-loggin.jar set CLASSPATH=%CLASSPATH%;%AXIS_LIB%\jaxrpc.jar set CLASSPATH=%CLASSPATH%;%AXIS_LIB%\saaj.jar set CLASSPATH=%CLASSPATH%;%AXIS_LIB%\log4j-1.2.8.jar set CLASSPATH=%CLASSPATH%;%AXIS_LIB%\xml-apis.jar set CLASSPATH=%CLASSPATH%;%AXIS_LIB%\xercesImpl.jar set CLASSPATH=%CLASSPATH%;%AXIS_LIB%\xmlParserAPIs.jar @%TOMCAT_HOME%\bin\startup Sous Linux (tomcatStartup.sh) : #! /bin/sh # startup.sh echo "------- Définition des chemins ---------" TOMCAT_HOME=/home/al/jakarta-tomcat-4.1.27 export TOMCAT_HOME AXIS_HOME=$TOMCAT_HOME/webapps/axis; export AXIS_HOME AXIS_LIB=$AXIS_HOME/WEB-INF/lib; export AXIS_LIB CLASSPATH=$CLASSPATH:AXIS_LIB/axis.jar CLASSPATH=$CLASSPATH:AXIS_LIB/axis-ant.jar CLASSPATH=$CLASSPATH:AXIS_LIB/commons-discovery.jar CLASSPATH=$CLASSPATH:AXIS_LIB/commons-logging.jar CLASSPATH=$CLASSPATH:AXIS_LIB/jaxrpc.jar CLASSPATH=$CLASSPATH:AXIS_LIB/saaj.jar CLASSPATH=$CLASSPATH:AXIS_LIB/log4j-1.2.8.jar CLASSPATH=$CLASSPATH:AXIS_LIB/wsdl4j.jar CLASSPATH=$CLASSPATH:AXIS_LIB/xercesImpl.jar CLASSPATH=$CLASSPATH:AXIS_LIB/xmlParserAPIs.jar export CLASSPATH echo "------- Lancement d'Axis ---------" $TOMCAT_HOME/bin/startup.sh A.3.1 Lancement et arrêt de Axis Arrêter puis redémarrer Tomcat avec les nouveaux paramètres que nous venons d'ajouter. Pour vérifier que Axis soit bien installé, ouvrir l'URL suivante avec un browser : http://localhost:8080/axis Albert Ritch – Les Web Services Page 54 novembre 2003 – v1.0 La page suivante devrait apparaître : Fig. A-2 : Fenêtre de démarrage d'Axis En affichant la page http://localhost:8080/axis/happyaxis.jsp, on va pouvoir vérifier que toutes les bibliothèques nécessaires sont installées. A.4. Installation de Axis (API) au niveau client Afin de pouvoir créer des clients de Web Services avec Java, on utilise l'API Axis au niveau client. Cette API consiste en une série de packages (.jar) qu'il faut importer dans les classes clientes. Ces packages se situent dans le répertoire axis-1_1\webapps\axis\WEB-INF\lib de l'archive Axis téléchargée auparavant (voir point 1). Copier simplement ces packages (ici dans le répertoire p:\_travailDiplome\travailDiplome\code\axis) puis ajouter leur localisation au classpath local. Pour automatiser la mise à jour du classpath local, on peut créer un fichier batch qui comprend les lignes suivantes : @echo off set JAVA_HOME=d:\java\jdk1.3.1 set PATH=%PATH%;%JAVA_HOME%\bin set AXIS_HOME=p:\_travailDiplome\travailDiplome\code\axis set CLASSPATH=%CLASSPATH%;%AXIS_HOME%\axis.jar set CLASSPATH=%CLASSPATH%;%AXIS_HOME%\axis-ant.jar set CLASSPATH=%CLASSPATH%;%AXIS_HOME%\commons-discovery.jar set CLASSPATH=%CLASSPATH%;%AXIS_HOME%\commons-logging.jar set CLASSPATH=%CLASSPATH%;%AXIS_HOME%\jaxrpc.jar set CLASSPATH=%CLASSPATH%;%AXIS_HOME%\log4j-1.2.8.jar set CLASSPATH=%CLASSPATH%;%AXIS_HOME%\saaj.jar set CLASSPATH=%CLASSPATH%;%AXIS_HOME%\wsdl4j.jar Albert Ritch – Les Web Services Page 55 novembre 2003 – v1.0 set CLASSPATH=%CLASSPATH%;%AXIS_HOME%\xerces.jar set CLASSPATH=%CLASSPATH%;%AXIS_HOME%\xmlParserAPIs.jar set CLASSPATH=.;%CLASSPATH%;p:\_travailDiplome\travailDiplome\code Ce fichier sera placé dans notre cas dans : P:\_travailDiplome\travailDiplome\code\classpath\axisClientSetClasspath.bat Sous Linux (setClasspath.sh) : #/bin/sh # setClasspath.sh AXIS_HOME=/data/icks/_travailDiplome/travailDiplome/code/axis export AXIS_HOME CLASSPATH=$CLASSPATH:$AXIS_HOME/axis.jar CLASSPATH=$CLASSPATH:$AXIS_HOME/axis-ant.jar CLASSPATH=$CLASSPATH:$AXIS_HOME/commons-discovery.jar CLASSPATH=$CLASSPATH:$AXIS_HOME/commons-logging.jar CLASSPATH=$CLASSPATH:$AXIS_HOME/jaxrpc.jar CLASSPATH=$CLASSPATH:$AXIS_HOME/log4j-1.2.8.jar CLASSPATH=$CLASSPATH:$AXIS_HOME/saaj.jar CLASSPATH=$CLASSPATH:$AXIS_HOME/wsdl4j.jar CLASSPATH=$CLASSPATH:$AXIS_HOME/xerces.jar CLASSPATH=$CLASSPATH:$AXIS_HOME/xmlParserAPIs.jar CLASSPATH=$CLASSPATH:/data/icks/_travailDiplome/travailDiplome/code/ export CLASSPATH A-5 Installation de Sun One Server Une version d'évaluation (à 60 jours) de Sun One Server est mise à disposition par SUN sur son site : http://wwws.sun.com/software/download/app_dev.html Télécharger le package comprenant Sun One Server et Sun One Studio. Télécharger également le Java2SDK Enterprise Edition version 1.4.2. Installer le Java2SDK puis le package comprenant Sun One Server et Sun One Studio. Albert Ritch – Les Web Services Page 56 novembre 2003 – v1.0 Annexe B : Mises en oeuvres B.1. Déploiement d'un Web Service simple Pour cette première mise en oeuvre nous allons mettre en place un Web Service très simple. En effet, Axis permet deux types de déploiement dont un déploiement simple ou il suffit de copier la classe Java utilisée en changeant son extension en .jws. Pré requis : • Tomcat et Axis sont installés (voir Annexe A – Installation de Tomcat et Axis) • Tomcat est lancé Remarque : Cet exemple est conforme aux chemins d'installation de Tomcat et Axis vu à l'annexe A. Au niveau serveur Nous allons prendre l'exemple Calculator.java qui se trouve dans le répertoire axis\samples\userguide\example2 et directement le mettre dans le répertoire d:\users\tomcat4.1.27\webapps\axis en changeant son extension en .jws (java web service). On a donc : d:\users\tomcat-4.1.27\webapps\axis\Calculator.jws Axis compile automatiquement les classes portant l'extension .jws. La classe Calculator devient donc un Web Service dont les méthodes publiques sont à disposition des clients. Au niveau client Au niveau client, nous avons besoin uniquement des bibliothèques contenues dans le répertoire lib de axis (axis.jar, saaj.jar, ...). En fait Axis transforme les requêtes faites au serveur de Web Services. Nous allons utiliser la classe client CalcClient.java (située au même endroit que Calculator.java) et paramétrer l'adresse du serveur à la place de localhost. Sous Windows Ouvir un shell et se positionner sous : P:\_travailDiplome\travailDiplome\code Lancer le fichier de configuration du classpath de Axis : classpath/setClasspath Sous Linux Ouvrir un shell et se positionner sous : /data/icks/_travailDiplome/travailDiplome/code/ Lancer le fichier de configuration du classpath de Axis : . meo1/setClasspath.sh Remarque : pour pouvoir profiter du classpath dans la session courant que nous avons ouverte, utiliser ". " et non pas "./" ce qui évite que le classpath soit configuré dans un processus fils. Compiler la classe CalcClient.java : javac meo1/CalClient.java Exécuter CalcClient avec les arguments : Albert Ritch – Les Web Services Page 57 novembre 2003 – v1.0 java meo1/CalcClient add 4 4 On obtient bien : Fig. B-1 : Mise en oeuvre 1 : exécution de CalcClient Albert Ritch – Les Web Services Page 58 novembre 2003 – v1.0 B.2 Déploiement d'un service de convertisseur de devises [MIC02] La mise en oeuvre précédente est très simple mais ne permet pas le déploiement de Web Services à partir de classes compilée ou de packages (jar). Pour déployer un Web Service sous Axis, il faut utiliser un descripteur de déploiement WSDD (Web Service Deployment Descriptor) propre à Axis qui est utilisé lors du déploiement. Il s'agit d'un fichier XML portant l'extension wsdd. B.2.1 Introduction Au niveau serveur Le Web Service que nous allons mettre en oeuvre utilisera Axis au niveau serveur. Nous allons utiliser également : java2WSDL utilitaire permettant de générer le fichier de description du Web Service (WSDL) à partir de l'interface Java de la classe que nous allons déployer. WSDL2Java utilitaire qui va nous permettre de créer les stub et skeleton ainsi que les fichiers de déploiement deploy.wsdd et undeploy.wsdd tcpmon utilitaire se plaçant entre le client et le serveur qui permet de voir les messages SOAP échangés (déboguage, ...) Voir le chapitre portant sur WSDL ou le résultat de l'invocation de ces utilitaires est détaillé. Remarque : pour invoquer ces diverses commandes, on va se placer dans le répertoire code, et créer le répertoire meo2 dans lequel va se trouver la classe que nous voulons déployer et les fichiers générés. Au niveau client Nous allons utiliser au niveau client le MS SOAP Toolkit v2.0 qui fait partie de Visual Studio .NET, mais qui peut être téléchargé individuellement. Pour coder le fichier VBA, on peut utiliser un éditeur de texte conventionnel ou l'éditeur VBA compris dans toute application MSOffice (Excel par exemple). B.2.2 Mise en place du Web Service 1. Création de la classe java que nous voulons déployer La classe Java que nous allons déployer contient deux méthodes : public double enFranc(double euro) public double enEuro(double franc) Remarque : il faut que les méthodes soient publiques afin de pouvoir y accéder. La classe en question : package meo2; public class Exchange { /** Creates new Exchange */ Albert Ritch – Les Web Services Page 59 novembre 2003 – v1.0 public Exchange() { } /** * Conversion d'Euro en Francs * @param euro Le montant en Euro * @return Le montant en Francs */ public double enFranc(double euro) { return euro * 6.55957; } /** * Conversion de franc en Euro * @param francs Le montant en franc * @return Le montant en Euro */ public double enEuro(double franc) { return franc / 6.55957; } } 2. Créer le fichier WSDL de description du Web Service. L'outil qui nous permet de créer le fichier WSDL est Java2WSDL En invoquant dans la ligne de commande : java org.apache.axis.wsdl.Java2WSDL on obtient les options disponibles avec la commande : Albert Ritch – Les Web Services Page 60 novembre 2003 – v1.0 Fig B-2 : Mise en oeuvre 2 : exécution de Java2WSDL Pour invoquer cette commande, il faut d'abord avoir configuré le classpath (voir B1) en lançant le fichier (depuis le répertoire code) : . classpath/setClasspath.sh Remarque : la configuration du classpath peut être automatisée sous Linux en complétant le fichier .bash_profile et sous Windows en utilisant l'utilitaire de configuration des variables d'environnement. Pour créer le fichier WSDL, invoquer : java org.apache.axis.wsdl.Java2WSDL -o Exchange.wsdl l"http://192.168.1.33:8080/axis/services/Exchange" -n urn:Exchange -p"meo2" urn: meo2.Exchange Options : -o spécification du fichier de sortie -l localisation de notre Web Service -n -p path pour déterminer où se trouve le fichier source Erreurs possibles : The <class-of-portType> was not specified. Î ne pas mettre urn ... entre guillemets On constate alors que le fichier Exchange.wsdl a été généré et se trouve dans le répertoire courant. Albert Ritch – Les Web Services Page 61 novembre 2003 – v1.0 3. Création des fichiers de déploiement et éventuellement stub et skeleton WSDL2Java permet de générer le fichier de déploiement (wsdd) et le skeleton pour le serveur ainsi que le stub (pour un éventuel client Java). Au niveau client, il permet de créer une encapsulation de l'appel du Web Service afin de rendre le codage de la partie client simple. Une interface correspondant à notre classe Exchange.java va être également générée sous le même nom et donc écraser notre classe. Renommer donc notre classe Exchange.java en Exchange.java.orig Puis utiliser WSDL2Java en invoquant : [al@galeon code]$ java org.apache.axis.wsdl.WSDL2Java -o . --skeletonDeploy true -p meo2 Exchange.wsdl Options : -o --skeletonDeploy true -p où se trouve le fichier wsdl force la génération du skeleton path où mettre les fichiers On constate alors que les 8 fichiers ont été générés (voir le chapitre 3.3 portant sur WSDL pour leur description) : deploy.wsdd undeploy.wsdd ExchangeService.java ExchangeServiceLocator.java ExchangeSoapBindingImpl.java ExchangeSoapBindingSkeleton.java ExchangeSoapBindingStub.java Modifier le fichier ExchangeSoapBindingImpl.java (modifications en rouge) : package meo2; public class ExchangeSoapBindingImpl implements meo2.Exchange{ public double enFranc(double euro) throws java.rmi.RemoteException { return euro * 6.55957; } public double enEuro(double franc) throws java.rmi.RemoteException { return franc / 6.55957; } Et enfin, compiler tous les fichiers : [al@galeon code]$ javac meo2/*.java 4. Déploiement du Web Service Créer un répertoire meo2 dans le répertoire Axis (serveur) : file:/home/al/jakarta-tomcat-4.1.27/webapps/axis/WEB-INF/classes On a donc maintenant le répertoire file:/home/al/jakarta-tomcat-4.1.27/webapps/axis/WEB-INF/classes/meo2 Copier les fichiers suivants dans le répertoire créé: ExchangeSoapBindingSkeleton.class ExchangeSoapBindingImpl.class Albert Ritch – Les Web Services Page 62 novembre 2003 – v1.0 ExchangeService.class Exchange.class Déploiement du Web Service : [al@galeon code]$ java org.apache.axis.client.AdminClient meo2/ws/deploy.wsdd Relancer Axis (=> Tomcat) => shutdown puis startup On constate bien que le Web Service est déployé : Fig B-3 : Notre Web Service est déployé On peut également constater que l'URL du fichier WSDL est : http://192.168.1.33:8080/axis/services/Exchange?wsdl B.2.2 Création du client en VBA Télécharger et installer MSSOAP Toolkit 2.0 : Téléchargement du Microsoft Office XP Web Services Toolkit 2.0 - Français http://www.microsoft.com/downloads/details.aspx?FamilyID=4922060f-002a-4f5b-af74978f2cd6c798&DisplayLang=fr Créer un fichier source VBA (avec Excel par exemple) nommé client.vbs Option Explicit Dim soapClient Set soapClient = CreateObject("MSSOAP.SoapClient") On Error Resume Next Call Albert Ritch – Les Web Services Page 63 novembre 2003 – v1.0 soapClient.mssoapinit("http://192.168.1.33:8080/axis/services/Exchange?wsdl ") If Err <> 0 Then wscript.echo "initialization failed " + Err.Description End If wscript.echo soapClient.enFranc(10) If Err <> 0 Then wscript.echo wscript.echo wscript.echo wscript.echo wscript.echo End If Err.Description "faultcode=" + soapClient.faultcode "faultstring=" + soapClient.faultstring "faultactor=" + soapClient.actor "detail=" + soapClient.detail wscript.echo soapClient.enEuro(100) If Err <> 0 Then wscript.echo wscript.echo wscript.echo wscript.echo wscript.echo End If Err.Description "faultcode=" + soapClient.faultcode "faultstring=" + soapClient.faultstring "faultactor=" + soapClient.actor "detail=" + soapClient.detail Remarque : Il suffit du fichier WSDL pour que le MSSOAP Toolkit puisse utiliser le Web Service. Lancer le client avec : cscript client.vbs Et on obtient : Fig B-4 : Résultat de l'exécution du client Albert Ritch – Les Web Services Page 64 novembre 2003 – v1.0 B.2.3 Intégration dans MS Office A partir du client VBA, on peut utiliser le Web Service directement à partir d'un élément de la suite MS Office. Nous allons utiliser Excel. 1. Intégration en tant que macro VBA dans Excel Créer un nouveau document Excel et y intégrer un bouton nommé btFrancsEuro. Nommer la cellule B9 « don » et la cellule B11 « res ». Se mettre en mode édition et double cliquer sur le bouton afin d'afficher l'éditeur VBA. Renommer la feuille 1 en « Interface » et créer un module nommé « Convertisseur » comme dans la figure B-6. Fig. B-5 : Création de la feuille Excel Albert Ritch – Les Web Services Page 65 novembre 2003 – v1.0 Compléter le module avec le code suivant : Option Explicit Dim soapClient Private Sub CnxWs() Set soapClient = CreateObject("MSSOAP.SoapClient") On Error Resume Next Call soapClient.mssoapinit("http://192.168.1.33:8080/axis/services/Exchange?wsdl ") If Err <> 0 Then MsgBox ("initialization failed " + Err.Description) End If End Sub 'wscript.echo soapClient.enEuro(10) Sub CalcEuro(donnee As Long) CnxWs Interface.Range("res").Value = soapClient.enEuro(donnee) If Err <> 0 Then MsgBox (Err.Description) MsgBox ("faultcode=" + soapClient.faultcode) MsgBox ("faultstring=" + soapClient.faultstring) MsgBox ("faultactor=" + soapClient.actor) MsgBox ("detail=" + soapClient.detail) End If End Sub Commentaires : Création du client pour le Web Service Fig B-6 : Editeur VBA Albert Ritch – Les Web Services Page 66 novembre 2003 – v1.0 Set soapClient = CreateObject("MSSOAP.SoapClient") Récupération du fichier de description WSDL. Call soapClient.mssoapinit("http://192.168.1.33:8080/axis/services/Exchange?wsdl") Compléter la feuille « Interface » avec le code suivant : Private Sub btFrancsEuro_Click() Convertisseur.CalcEuro Interface.Range("don").Value End Sub Fig B-7 : Résultat après invocation du Web Service En insérant une valeur en Francs dans la cellule B9 et en cliquant sur le bouton on obtient la conversion par le Web Service en Euro dans la cellule B11. 2. Intégration en tant que fonction Excel Il est également possible d'intégrer simplement le Web Service en tant que fonction dans Excel. Ceci permet donc à un utilisateur qui n'a pas de connaissances de VBA d'utiliser le Web Service en toute transparence. Pour cela, il faut modifier le code VBA en le transformant en fonction : Option Explicit Dim soapClient Private Sub CnxWs() Set soapClient = CreateObject("MSSOAP.SoapClient") Albert Ritch – Les Web Services Page 67 novembre 2003 – v1.0 On Error Resume Next Call soapClient.mssoapinit("http://192.168.1.33:8080/axis/services/Exchange?wsdl ") If Err <> 0 Then MsgBox ("initialization failed " + Err.Description) End If End Sub Public Function EnEuro(donnee As Long) As Long Dim temp As Long CnxWs temp = soapClient.EnEuro(donnee) If Err <> 0 Then MsgBox (Err.Description) MsgBox ("faultcode=" + soapClient.faultcode) MsgBox ("faultstring=" + soapClient.faultstring) MsgBox ("faultactor=" + soapClient.actor) MsgBox ("detail=" + soapClient.detail) End If EnEuro = temp 'résultat retourné par la fonction End Function La fonction sera alors automatiquement intégrée dans les fonctions personnalisées d'Excel. Fig. B-8 : Utilisation du Web Service en tant que fonction On constate bien (Fig B-6) que la fonction (EnEuro) fait bien partie des Fonctions personnalisées. Il suffit seulement de chercher la fonction dans la liste, ou la taper directement dans la barre des fonction (Fig. B-7). Albert Ritch – Les Web Services Page 68 novembre 2003 – v1.0 Fig. B-9 : Création de la feuille Excel Albert Ritch – Les Web Services Page 69 novembre 2003 – v1.0 B.3 Client C# avec Visual Studio Pour faire un client C# pour notre Web Service (voir B.2), il faut tout d'abord installer Visual Studio . Net de Microsoft. Attention : certains pré-requis sont nécessaires, comme un service-pack récent. Créer un nouveau projet Windows (C#). Ajouter une référence au Web Service en cliquant avec le bouton droit sur le répertoire « Références ». Fig. B-10 : Ajout du Web Service Insérer l'URL du fichier WSDL du Web Service : Fig B-11 : Recherche du fichier de description WSDL Puis cliquer sur « Aller à ». Albert Ritch – Les Web Services Page 70 novembre 2003 – v1.0 Les méthodes trouvées sont alors listées. Fig B-12 : Les méthodes sont trouvées Il faut maintenant créer l'interface graphique pour notre client. Fig. B-13 : Interface graphique en C# Nommer les labels : lbFr et lbEur Nommer les champs de saisie : tfFr et tfEur Albert Ritch – Les Web Services Page 71 novembre 2003 – v1.0 Nommer le bouton : btCalc Double-cliquer sur le bouton afin de voir apparaître le code correspondant au click et ajouter : private void btCalc_Click(object sender, System.EventArgs e) { double valeur; t1.ExchangeService.ExchangeService Calculateur = new t1.ExchangeService.ExchangeService(); valeur = Calculateur.enEuro(double.Parse(tbFr.Text)); tbEur.Text = valeur.ToString(); } Il faut alors compiler le projet et lancer l'exécutable. Mettre une somme en francs et en cliquant sur « Calculer ». Fig. B-14 : Résultat Albert Ritch – Les Web Services Page 72 novembre 2003 – v1.0 B-5 Scénario de e-banking [SUN103] Dans cette mise en oeuvre, un logiciel de e-banking (très simplifié) en C# va utiliser les services d'un prestataire d'informations (comme Reuters) ainsi que les services d'une banque pour passer les ordres d'achat de titres. Le scénario sera implanté en deux phases. Tout d'abord il s'agira d'implanter la partie serveur du prestataire d'informations boursières et de créer une fenêtre servant à afficher les titres reçus. Ensuite, la partie bancaire sera implantée, permettant de choisir un titre dans la liste de la fenêtre et de passer un ordre d'achat. Reuters Sun One Server Banque GBS Axis Fat client C# Fig. B-15 : Schéma du scénario Albert Ritch – Les Web Services Page 73 novembre 2003 – v1.0 B-5.1 Création du Web Service d'informations bancaires La première partie consiste à créer le Web Service d'informations bancaires sous Sun One Server avec Sun One Studio. Pour l'installation de Sun One Server, se référer à l'annexe A-5. Comme on peut le voir ci-dessous, les classes métier consistent en une classe Bourse et une classe Titre inclues dans un package nommé ReutersServeur. Fig B-16 : Classes serveur Reuters Voici un extrait de la classe bourse. La méthode getTitre permet de retourner un tableaux d'objets comportant les attributs du titre demandé. La méthode getNbTitres retourne quand à elle le nombre de titres présent dans la bourse. Nous allons donc déployer les méthodes getNbTitres et getTitre comme Web Services. package ReutersServeur; public class Bourse { ... public int getNbTitres() { return titres.size(); } public Object[] getTitre(int i) { Object[] titre = new Object[8]; titre[0] = new Integer(((Titre)titres.elementAt(i)).getCode()); titre[1] = new String(((Titre)titres.elementAt(i)).getNom()); titre[2] = new String(((Titre)titres.elementAt(i)).getAbrev()); titre[3] = new Double(((Titre)titres.elementAt(i)).getValeur()); titre[4] = new Double(((Titre)titres.elementAt(i)).getBid()); titre[5] = new Double(((Titre)titres.elementAt(i)).getAsk()); titre[6] = new Integer(((Titre)titres.elementAt(i)).getVolume()); return titre; } } Albert Ritch – Les Web Services Page 74 novembre 2003 – v1.0 Création du Web Service Reuters 1. Compiler le packages puis, pour créer un nouveau Web Service à partir du package Reuters, cliquer dessus et dans le menu déroulant cliquer sur « Web Service ». Fig. B-17 : Plate-forme J2EE 2. Sur la fenêtre qui s'affiche, mettre un nom pour le Web Service. Cliquer sur « Java Methods » ainsi que sur « Web Centric ». 3. Cliquer sur « Next > » et sélectionner les deux méthodes (getNbTitres et getTitre) après avoir déroulé l'arborescence de la classe Bourse.java. Un nouvel élément apparaît avec l'extension xms. Il s'agit du Web Service créé. 4. Cliquer ensuite sur le Web Service (ReutersSMX.xms) avec le bouton droit de la souris et cliquer sur « Generate Web Service Files » (voir fig. B-18). Fig B-18 : Génération du Web Service Comme on peut le constater (fig. B-19) les fichiers nécessaires au Web Service sont créés. Albert Ritch – Les Web Services Page 75 novembre 2003 – v1.0 Fig. B-19 : Package ReutersServeur Déploiement du Web Service Reuters Cliquer sur le Web Service (ReutersSMX.xms) avec le bouton droit de la souris et cliquer sur « Deploy » Le Web Service est actuellement fonctionnel. Albert Ritch – Les Web Services Page 76 novembre 2003 – v1.0 B-5.2 Création de la partie informations boursières du client Le diagramme de classe de la partie client est identique à celle du serveur Reuters. Seule une vue sur la classe Portefeuille a été ajoutée. Créer un nouveau projet C# sous Visual Studio .NET. Créer une fenêtre principale et une fenêtre secondaire selon la copie d'écran ci-dessous. Cette fenêtre doit contenir un DataGrid (équivalent d'une JTable en Java) pour l'affichage des titres. Fig B-20 : La maquette de la fenêtre des titres Les classes créées sont donc : MainWindow.cs fenêtre principale MDI Titre.cs la classe titre Bourse.cs la classe bourse qui regroupe les titres BourseVue.cs la fenêtre ci-dessus (fig. 5-5) qui est une vue de la classe Bourse Voici ci-dessous un extrait de la classe MainWindow qui fait les actions suivantes : • Création de l'objet Reuters qui est le Web Service • Création d'un objet Bourse • Invocation du Web Service Reuters qui envoie les attributs des titres de la bourse suisse (SWX). • Création des objets Titre avec les paramètres reçu du Web Service • Ajout dans la classe Bourse des titres instanciés • Création par l'objet Bourse d'ouvrir une vue sur lui même (Singleton) Albert Ritch – Les Web Services Page 77 novembre 2003 – v1.0 private void menuItem3_Click(object sender, System.EventArgs e) { // un objet correspondant au type retourné par le Web Service object[] titre; // le nombre de titres int nbTitres; // les attributs des titres int code; string nom; string abrev; double valeur; double bid; double ask; int volume; // création de l'objet Reuters ReutersFinance.ReutersFinance Reuters = new ReutersFinance.ReutersFinance(); //récupération du nombre de titres nbTitres = Reuters.getNbTitres(); // la fenêtre affichée est un singleton if (singleton) { } else { singleton = true; // création de la Bourse Bourse pf = new Bourse(1); // création des titres for (int i = 0; i < nbTitres; i++) { // récupération du titre i titre = Reuters.getTitre(i); // affectation des attributs code = (int)titre[0]; nom = titre[1].ToString(); abrev = titre[2].ToString(); valeur = (double)titre[3]; bid = (double)titre[4]; ask = (double)titre[5]; volume = (int)titre[6]; // création du titre avec les attributs Titre t = new Titre(code, nom, valeur, abrev, bid, ask, volume); pf.addTitre(t); } // on demande à la classe bourse de créer une vue sur elle-même // .. en lui donnant en parametre la vue principale pf.createView(this); } // if } // menuItem3_Click } // classe MainWindow Voici ci-dessous un extrait du code de la classe BourseVue.cs qui remplit le DataGrid à partir des Albert Ritch – Les Web Services Page 78 novembre 2003 – v1.0 informations des titres public void initializeElements() { // c'est ici que les vidgets vont être initialisés this.setTitres(this.pfeuille.getTitres()); // Creation d'un DataSet dsTitres = new DataSet("dsTitres"); // Creation de la DataTable "Titres" DataTable dtTitres = new DataTable("Titre"); // Création des colonnes correspondant aux titres dtTitres.Columns.Add(new DataColumn("Num ISIN", Type.GetType("System.Int32"))); dtTitres.Columns.Add(new DataColumn("Nom", Type.GetType("System.String"))); dtTitres.Columns.Add(new DataColumn("Abreviation", Type.GetType("System.String"))); dtTitres.Columns.Add(new DataColumn("Valeur", Type.GetType("System.Double"))); dtTitres.Columns.Add(new DataColumn("Bid", Type.GetType("System.Double"))); dtTitres.Columns.Add(new DataColumn("Ask", Type.GetType("System.Double"))); dtTitres.Columns.Add(new DataColumn("Volume", Type.GetType("System.Int32"))); for (int i = 0; i < this.pfeuille.getTitres().Count; i++) { object obj = this.pfeuille.getTitres()[i]; int num = ((Titre)obj).getNum(); string nom = ((Titre)obj).getNom(); string abv = ((Titre)obj).getCode(); double val = ((Titre)obj).getValeur(); double bid = ((Titre)obj).getBid(); double ask = ((Titre)obj).getAsk(); int volume = ((Titre)obj).getVolume(); dtTitres.Rows.Add(new Object[] {num, nom, abv, val, bid, ask, volume}); } dsTitres.Tables.Add(dtTitres); this.dataGrid1.DataSource = dsTitres.Tables["Titre"]; // affichage du nombre de titres this.tbNbTitres.Text = this.pfeuille.getTitres().Count.ToString(); /* this.dataGrid1.DataSource = (ArrayList)this.pfeuille.getTitres(); this.dataGrid1.Refresh(); */ } Après invocation du Web Service, on remplit le DataGrid des titres reçus de Reuters. Albert Ritch – Les Web Services Page 79 novembre 2003 – v1.0 Utilisation de la partie client Lors de l'ouverture de la fenêtre des titres, le Web Service Reuters fournit les titres avec leurs paramètres à partir desquels, le DataGrid est rempli. Fig B-21 : Les titres reçus du serveur Reuters Albert Ritch – Les Web Services Page 80 novembre 2003 – v1.0 B-5.3 Création de la partie banque GBS La banque GBS doit permettre de passer un ordre d'achat (fictif). Pour simplifier le code, on considère que le client possède qu'un seul portefeuille et un seul compte. Fig. B-22 : Diagramme de classe de la banque L'ordre d'achat passé, le titre acheté est ajouté au portefeuille du client, puis le solde du compte est renvoyé. Voici le service d'achat de titres. public double achatTitre(int numIsin, int nombre, Date dateMax, double prixMax) { this.cli.getPortefeuille().achatTitre(numIsin, nombre, dateMax, prixMax); this.cli.getCompte().setSolde(nombre * this.cli.getPortefeuille().getBourse().getTitre(numIsin).getValeur()); return this.cli.getCompte().getSolde(); } Albert Ritch – Les Web Services Page 81 novembre 2003 – v1.0 B-5.4 Fin de la partie client Il faut maintenant compléter la partie achat de titre du client. Pour cela, en mode édition, doublecliquer sur le bouton « Achat » de la fenêtre « BourseVue » afin de pouvoir coder l'événement d'achat. Voici le code ajouté correspondant au bouton « Achat ». private void btAchat_Click(object sender, System.EventArgs e) { int realIsin; realIsin = this.selectedRow + 1; if (MessageBox.Show("Voulez-vous bien acheter le titre n°ISIN " + realIsin.ToString() + " ?", "", MessageBoxButtons.YesNo)== DialogResult.Yes ) { // a faire en cas de oui : msgb = new MsgBox(this); msgb.ShowDialog(); if (msgb.etat) { // utilisation du portefeuille //this.brs.getPort().achatTitre(this.selectedRow, this.nombre, this.dateMax, this.prixMax); double solde; GBSBWS.GBSBWS Gbsb = new GBSBWS.GBSBWS(); solde = Gbsb.achatTitre(this.selectedRow, this.nombre, this.dateMax, this.prixMax); MessageBox.Show("Votre ordre a été passé\n Le solde de votre compte se monte à " + solde + " CHF"); } // } else { // on ne fait rien } } Une fenêtre supplémentaire (modale) est également créée, servant à la saisie des paramètres d'achat du titre. Utilisation de la partie client Le choix du titre à acheter se fait en cliquant dans la marge. On voit sur la figure ci-dessus que le titre « Clariant » à été choisit. L'utilisateur doit ensuite cliquer sur « Achat ». Fig. B-23 : Choix d'un titre Albert Ritch – Les Web Services Page 82 novembre 2003 – v1.0 Fig. B-24 : Validation de l'achat Après une validation, l'utilisateur doit entrer les paramètres d'achat, à savoir le nombre de titres qu'il veut acheter, le prix maximum d'achat et la date de péremption de l'ordre. Fig. B-25 : Paramètres d'achat Une fois l'ordre passé, il reçoit un message de confirmation avec le nouveau solde de son compte (solde d'origine : 2000 CHF) Fig. B-26 : L'ordre est passé Albert Ritch – Les Web Services Page 83 novembre 2003 – v1.0 Conclusion Les Web Services apportent des avantages indéniables dans les technologies d'intégration et en terme d'ouverture des entreprises vers ses partenaires en offrant des services directement issus de leur système d'information. En effet, je ne pense pas que les Web Services soient un effet de mode comme prétendent ses détracteurs. Si ils ne remplacent pas directement les technologies existantes comme CORBA, ils ont le mérite de donner une nouvelle impulsion à la réflexion concernant la réutilisabilité et l'interopérabilité des système d'information. Les développeurs pourront alors d'avantage se concentrer sur la conception et le développement des processus métier du système d'information plutôt que sur les problèmes techniques liés à l'intégration et l'interopérabilité. Albert Ritch – Les Web Services Page 84 novembre 2003 – v1.0 Bibliographie Livres [CHA102] Services Web avec Jean-Marie ISBN : 2-212-11047-2 SOAP, [ENG03] Java et Robert ISBN : 2-84177-230-6 [MAE03] Services Web Libero Maesano, ISBN : 2-212-11067-7 avec WSDL, UDDI, ebXML SOAP – J2EE Christian et .NET Bernard, – Eyrolles 2002 CHAUVET O'Reilly – Xavier 2003 ENGLANDER Eyrolles Le 2003 Galles [01I01] Xml La Synthese – 01 Informatique 2001 Anelyse Boukhors, Alexandre Kaszycki, Jérôme Laplace, Sandrine Munerot, Laurent Poublan ISBN : 2-10-008180-2 Documents Internet [01N03] Les services web à 01NET http://www.01net.com/article/214646.html la rescousse de l'intégration [BUR203] Plate-forme J2EE: cinq critères pour faire le bon choix Carole BURET http://www.zdnet.fr/techupdate/infrastructure/imprimer.htm?AT=2135287-39020938t-39000766c [CRO102] Les serveurs d'applications en Antoine http://solutions.journaldunet.com/0210/021003_serveurs.shtml 7 questions CROCHET-DAMAIS [DHE02] Panorama EAI: du BPM à l'intégration Cyril http://solutions.journaldunet.com/0202/020211_comparo_eai_notions.shtml [DON02] Panorama Didier sur les Web B to B DHENIN Services DONSEZ http://www-adele.imag.fr/~donsez/cours/webservices.pdf [FAR03] Les Enterprise Albert Ritch – Les Web Services Service Page 85 Bus novembre 2003 – v1.0 Nicolas http://www.ib-com.ch/pages/archives/03.04/0304tribune.html FARGES [FER01] "Les projets d'intégration passeront par un changement Guy http://solutions.journaldunet.com/itws/010914_it_fermon.shtml profond des mentalités" FERMON [HAN03] Créer un service web avec Jeff http://www.zdnet.fr/builder/architecture/services_web/0,39021055,2136920,00.htm [JEA01] Architectures distribuées et Fabrice http://www.webatrium.com/services/download/ServeurAppli.pdf serveurs [LEO03] Développer un webservice en PHP, un client en PHP, Grégory http://www.labo-dotnet.com/labo-dotnet/?target=showonearticle&ID=32 [MAU203] L'ESB rebâtit l'EAI Laurent http://www.01net.com/article/214645.html sur Tomcat [ROU02] Le Guide d'installation de Patrick http://www.apachefrance.com/Articles/6/imprime/ Tomcat [SOA103] SOAP SOAPUSER http://www.soapuser.com/fr/server1.html [SOA203] Bases SOAPUSER http://www.soapuser.com/fr/basics1.html [SUN103] Building Web Services – SUN Albert Ritch – Les Web Services d'application JEAN-FRANCOIS et un client .Net. LEOCADIE les [MIC02] Office XP Web Services MICROSOFT http://www.microsoft.com/office/developer/webservices/toolkit.asp [ROU01] Le Guide d'installation de Patrick http://www.apachefrance.com/Articles/5/imprime/ JWSDP HANSON standards MAURY Toolkit Tour pour Windows ROUMANOFF pour Linux ROUMANOFF Côté-Serveur SOAP Sun One Page 86 Studio Programming Series novembre 2003 – v1.0 http://docs-pdf.sun.com/817-2324/817-2324.pdf [VAW01] J2EE vs. Microsoft.NET - A comparison of building XML-based Chad VAWTER, Ed http://www.theserverside.com//resources/article.jsp?l=J2EE-vs-DOTNET Albert Ritch – Les Web Services Page 87 web services ROMAN novembre 2003 – v1.0
