LES WEB SERVICES AUTEUR : ALBERT RITCH HEG GENÈVE DÉPARTEMENT D'INFORMATIQUE DE GESTION LABORATOIRE DE TECHNOLOGIES OBJET PROFESSEUR : PETER DAEHNE

Transcription

1 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

2 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

3 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

4 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

5 Table des matières 1. Introduction aux Web Services Fonctionnement de base XML Syntaxe XML Syntaxe d'un document XML XML Schema Liens XML Parsing de documents XML Architecture et normes des Web Services Spécifications des Web Services SOAP Structure d'un message SOAP Exemples de base de messages SOAP (SOAP 1.2) Chaînes d'acheminement Typage Gestion des erreurs Attachements WSDL Structure d'un fichier WSDL Utilisation d'un document WSDL UDDI Structure de documents UDDI Accès à un annuaire UDDI Publication d'un Web Service Les Web Services et les protocoles d'applications distribuées Les protocoles de communication dans les architectures distribuées RMI EJB COM NET Remoting Corba Autres technologies (Janeva) Corba et les Web Services Avantage des Web Services par rapport à CORBA Avantages de CORBA CORBA ou les Web Services? Les Web Services et les technologies d'intégration (EAI) Intégration point à point EAI Middleware Convergence entre les EAI et le e-business ESB (Enterprise Service Bus) Plates-formes et outils de développement La plate-forme.net Plate-forme J2EE Récapitulatif des outils pour la mise en oeuvre des Web Services 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

6 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

7 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

8 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 de Web Services Albert Ritch Les Web Services Page 8 novembre 2003 v1.0

9 Abréviations et symboles API B2B B2C CLR COM COM+ CORBA CRM DCOM DOM EDI EJB ERP ESB IDL IIOP JAXP JCA JVM MOM ORB RMI RPC SOA SOAP UDDI URI WSDL Application Programming Interface Business To Business Business To Consumer Common Language Runtime Component Object Model Component Object Model plus Common Object Request Broker Achitecture Customer Relationship Management Distributed Component Object Model Document Object Model Échange de Données Informatisé Enterprise Java Bean Entreprise Resources Planning Enterprise Service Bus Interface Definition Language Internet Inter-ORB Protocol Java API for XML Processing J2EE Connector Architecture Java Virtual Machine Message-Oriented Middleware Object Request Broker Remote Method Invocation Remote Procedure Call Service Oriented Architecture Simple Object Access Protocol Universal Description, Discovery and Integration Uniform Ressource Identifier Web Service Description Language Albert Ritch Les Web Services Page 9 novembre 2003 v1.0

10 Glossaire Applet Broker de messages Business To Business Business To Consumer Common Language Runtime B2B B2C CLR Petit programme Java destiné a être téléchargé et utilisé au niveau client dans un navigateur Web Dans un environnement orienté objet, un broker de messages sert à réguler les messages entre objets Commerce entre deux entreprises Commerce entre une entreprise et les consommateurs 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) COM Standard de gestion d'objets distribués Component Object Model plus Connecteur Courtier de messages COM+ Version améliorée de COM Logiciel interfaçant une application et le broker de messages d'un EAI Voir broker de messages Customer Relationship Management Distributed Component Object Model Document Object Model CRM DCOM DOM Progiciel de la relation client Extension du protocole COM, permettant de supporter les objets répartis sur le réseau 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 ESB Nouvelle génération d'eai s'appuyant sur des standards comme les JCA et les Web Services Entreprise Resources Planning ERP Progiciel de gestion Albert Ritch Les Web Services Page 10 novembre 2003 v1.0

11 Fat client Interface Definition Language Internet Inter-ORB Protocol J2EE Connector Architecture Java API for XML Processing IDL IIOP JCA JAXP Client lourd (application créée avec les bibliothèques graphiques comme Swing ou les MFC) Langage de description des services orientés objets distribués sous CORBA Protocole CORBA permettant à deux bus ORB de communiquer ensemble Interface d'accès aux applications Java. Utilisé comme connecteur dans les ESB API Java pour la manipulation de documents XML Java Virtual MachineJVM Machine virtuelle Java permettant d'exécuter un programme Java Logiciel adaptateur voir connecteur Message-Oriented Middleware middleware Object Request Broker Remote Method Invocation Remote Procedure Call Service Oriented Architecture Servlet MOM ORB RMI RPC SOA Mécanisme asynchrone d'échange de messages entre applications Logiciel transportant les informations échangées par des applications distribuées Broker permettant de faire communiquer des objets sous CORBA Mécanisme de Sun servant à utiliser des objets distribués Un protocole RPC gère les interactions du client et du serveur dans le cas d'environnements distribués 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 Simple Object Access Protocol Thin client SOAP Protocole d'échange de messages des Web Services s'appuyant sur XML Client léger (browser Web) Uniform Ressource Identifier Web Service URI Localisateur d'un document distant sur Internet 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

12 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'oasis 1 (Organization for the Advancement of Structured Information Standards ). Des briques additionnelles servent à la sécurité et aux transactions. 1. URL : Albert Ritch Les Web Services Page 12 novembre 2003 v1.0

13 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

14 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 SGML 2. 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 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' on peut écrire : < ></ > Equivalent à : < /> 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>< >dupont@mail.com</ ></autresinfos> Mais celui ci-dessous est incorrect : < ><autresinfos>dupont@mail.com</ ></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

15 <?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 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

16 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=" 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=" 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

17 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> fractiondigit Permet de définir le nombre de décimales autorisées length Permet de spécifier le nombre exact de caractères (ou d'octets) maxexclusive Spécifie une valeur maximale qui ne peut être atteinte maxinclusive Spécifie une valeur maximale qui peut être atteinte maxlength Permet de spécifier le nombre maximum de caractères (ou d'octets) minexclusive Spécifie une valeur minimale qui ne peut être atteinte mininclusive Spécifie une valeur minimale qui peut être atteinte minlength Permet de spécifier le nombre minimum de caractères (ou d'octets) pattern 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}"/> totaldigits Spécifie le nombre exact de chiffres whitespace Définit l'interpretation des espaces 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

18 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=" 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

19 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> 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=" xlink:type="simple" xlink:href=" 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 novembre 2003 v1.0 Fig. 2-1 : Parsing de document XML

20 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 JAXP 3 de Sun ou Xerces 4 de Apache sont disponibles. 3. JAXP : 4. Xerces : Albert Ritch Les Web Services Page 20 novembre 2003 v1.0

21 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 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 sur le site du WS-I et pour les spécifications de SOAP 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) : 6. Spécifications SOAP 1.2 (site du W3C) : Albert Ritch Les Web Services Page 21 novembre 2003 v1.0

22 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 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=" ">.... </env:envelope> 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=" <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

23 <env:envelope xmls:env=" <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 = " + options.getport() + "/axis/calculator.jws";...en : String endpoint = " 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=" xmlns:xsd=" xmlns:xsi=" <soapenv:body> <add soapenv:encodingstyle=" <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=" xmlns:xsd=" xmlns:xsi=" <soapenv:body> <addresponse soapenv:encodingstyle=" <addreturn xsi:type="xsd:int">7</addreturn> </addresponse> Albert Ritch Les Web Services Page 23 novembre 2003 v1.0

24 </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 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 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=" 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

25 Exemples de type Java avec leur correspondance SOAP : int a = 15; <a xs:type="xs:int">15</a> float x = ; <x xs:type="xs:float">3.1415</x> java.lang.string s = "Bonjour"; <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> 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=" <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

26 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> 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 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

27 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 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=" xmlns:apachesoap=" xmlns:impl="urn:exchange" xmlns:intf="urn:exchange" xmlns:soapenc=" xmlns:wsdl=" xmlns:wsdlsoap=" xmlns:xsd=" 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

28 <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=" <wsdl:operation name="enfranc"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="enfrancrequest"> <wsdlsoap:body encodingstyle=" ing/" namespace="urn:exchange" use="encoded"/> </wsdl:input> <wsdl:output name="enfrancresponse"> <wsdlsoap:body encodingstyle=" namespace="urn:exchange" use="encoded"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="eneuro"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="eneurorequest"> <wsdlsoap:body encodingstyle=" namespace="urn:exchange" use="encoded"/> </wsdl:input> <wsdl:output name="eneuroresponse"> <wsdlsoap:body encodingstyle=" 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=" </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

29 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 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

30 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 Axis 7 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