Les services Web Jeremy Fierstone Email fierston essi

Les services Web Jeremy Fierstone Email : fierston@essi. fr SAR 5 – Novembre 2002 Merci à Mireille Blay-Fornarino, Didier Donsez Michel Riveill, Microsoft, Sun … pour leurs slides 1

Les services Web n n n Généralités Architecture SOAP WSDL UDDI Implémentations n n Les APIs Java (JAXP, JAX-RPC, JAXM, JAXR, JAXB) Implémentation avec JAX-RPC Apache SOAP, Apache Axis Conclusion 2

Les services Web Généralités 3

Un Service Web, c’est quoi ? n n Un service Web est une « unité logique applicative » accessible en utilisant les protocoles standard d’Internet Une «librairie» fournissant des données et des services à d’autres applications. Un objet métier qui peut être déployé et combiné sur Internet avec une faible dépendance vis-à-vis des technologies et des protocoles. Combine les meilleurs aspects du développement à base de composants et du Web. 4

Un Service Web, c’est quoi ? n Caractéristiques: n n Réutilisable Indépendamment de n la plate-forme (UNIX, Windows, …) n l’implémentation (VB, C#, Java, …) n l’architecture sous-jacente (. NET, J 2 EE, Axis…) 5

Evolution du Web HTML, XML Generation 1 Generation 2 Generation 3 Static HTML Web Applications Web Services 6

Exemple 7

Le Web 3ème génération In-house systems Un site Web fournie des pages HTML - pas de structure - impossible à fusionner avec d’autres pages Demain Un site Web est un composant fournissant des services en XML - structure / sémantique - fusion possible Web service site File DB Web Web service site “The Firewall” Aujourd’hui Web Server Browser 8 “Dynamic Pages”

Pourquoi faire ? n Les services Web permettent d’interconnecter : n n Différentes entreprises Différents matériels Différentes applications Différents clients n n n Distribuer et intégrer des logiques métiers Vers le Web sémantique n n Pas uniquement des butineurs Pas uniquement le Web purement interactif Les services Web sont faiblement couplés 9

Modèle client / serveur Service Web L M X XML XML Service Web Site XML Service Web ML HT Client XML Client 10

Quels objectifs ? n n n Remplacer les protocoles actuels (RPC, DCOM, RMI) par une approche entièrement ouverte et interopérable, basée sur la généralisation des serveurs Web avec scripts CGI. Faire interagir des composants hétérogènes, distants, et indépendants avec un protocole standard (SOAP). Dédiés aux applications B 2 B (Business to Business), EAI (Enterprise Application Integration), P 2 P (Peer to Peer). 11

Et plus concrètement ? n Une nouvelle technologie des objets distribués ? n n Basés sur des standards XML n n Invocation distante des services Web : SOAP (~IIOP) Description des services Web : WSDL (~IDL) Enregistrement et découverte de services Web : UDDI (~Name. Service) Standards du W 3 C : XML, SOAP, WSDL Standards industriels : UDDI, eb. XML Propriétaires : DISCO, WSDD, WSFL, ASMX, … Implémentations actuelles : n n Microsoft. Net Sun Java. ONE : J 2 EE + Web services (WSDP = JAXP, JAX-RPC, JAXM…) Apache SOAP / Axis, IBM WSTK Oracle, Bea, Iona, Enhydra … 12

Les services Web Architecture 13

Cycle de vie d’utilisation Annuaire UDDI 2 : J’ai trouvé! Voici le serveur hébergeant ce service web 1 : Je recherche un service WEB 3 : Quel est le format d’appel du service que tu proposes? Contrat SOAP 4 : Voici mon contrat (WSDL) XML Client XML Serveur 5 : J’ai compris comment invoquer ton service et je t’envoie un document XML représentant ma requête XML 14 6 : J’ai exécuté ta requête et je te retourne le résultat

Cycle de vie complet n Etape 1 : Déploiement du service Web n n Etape 2 : Enregistrement du service Web n n Dépendant de la plate-forme (Apache : WSDD) WSDL : description du service Référentiels : DISCO (local), UDDI (global) Etape 3 : Découverte du service Web Etape 4 : Invocation du service Web par le client 15

1: Déploiement du WS 16

2: Enregistrement du WS 17

3: Découverte du WS 18

4: Invocation du WS 19

Architecture globale 20

Les services Web SOAP : Simple Object Access Protocol Merci à Michel Riveill et Didier Donsez 21

Le Web et le client serveur n n Proposition Web actuelle insuffisante Autres plates-formes client / serveur n Java RMI n mono-langage : Java, multi-plateforme (JVM), SUN n n Pas réaliste pour une application industrielle (performance, sécurité, …) CORBA / IIOP n Multilangage, multi-plateforme, Multi-vendeurs, OMG n Installation « coûteuse » si on doit acheter un ORB n n Mais les open-sources sont gratuits et souvent plus complet n www. objectweb. org DCOM n multi-langages, plateforme Win 32, Propriétaire Microsoft n protocole orienté connexion n n Échange de nombreux paquets pour créer/maintenir une session Faible diffusion n n Pas disponible sur Mac. OS, NT 3. 51, Win 95, Win. CE 2 Coûteux sur UNIX, MVS, VMS ou NT 22

Le bilan… n Approche insatisfaisante : n Protocoles sophistiqués n n n Coût d’installation (faite par un administrateur, consomme des ressources : machines, personnels, …) Difficile à porter sur d’autres plates-formes Règles de fonctionnement strictes en environnement ouvert (le Net) n n Environnement sécurisé (intérieur d’un intranet) Incapacité à fonctionner en présence de pare-feu (utilisation impossible sur Internet) n Les nouvelles version de Co. RBA peuvent ouvrir un port sur un parefeu comme le port 80 d’HTTP 23

… et ses conséquences n Le Web a besoin d’un nouveau protocole n n Multi-langages, multi-plateformes Respectant les formats d’échanges du Web n n Facile à implémenter sur différents protocoles de transport n n ATTENTION : on perd le contrôle d’accès à faible granularité Avec une spécification non propriétaire garantie par un organisme indépendant n n RPC, HTTP ou autre MOM Permettant de franchir les « firewalls » n n Réponses et requêtes en XML W 3 C La réponse : SOAP (Simple Object Access Protocol) 24

La philosophie S. O. A. P n SOAP codifie simplement une pratique existante n n Utilisation conjointe de XML et HTTP SOAP est un protocole minimal pour appeler des méthodes sur des serveurs, services, composants, objets n n n Ne pas imposer une API ou un runtime Ne pas imposer l’utilisation d’un ORB (CORBA, DCOM, …) ou d’un serveur web particulier (Apache, IIS, …) Ne pas imposer un modèle de programmation n Plusieurs modèles peuvent être utilisés conjointement Et “ne pas réinventer une nouvelle technologie” SOAP a été construit pour pouvoir être aisément porté sur toutes les plates-formes et les technologies n n Vous pouvez écrire votre 1 er appel SOAP en moins d’une heure !! Il vous a fallu combien de temps en CORBA, RMI, DCOM ? 25

Les 3 aspects d’un appel SOAP n SOAP peut être vu comme un autre RPC Objets n n n SOAP peut être vu comme un protocole d’échange de “message” n n n La requête contient un seul message (appel sérialisé d’une méthode sur un objet) La réponse contient un seul message (retour sérialisé d’un appel de méthode sur un objet) SOAP peut être vu comme un format d’échange de documents n n n Les requêtes contiennent les paramètres IN et INOUT Les réponses contiennent les paramètres INOUT et OUT La requête contient un document XML Le serveur retourne une version transformée Ces vues ne sont pas imposées par le protocole 26

En résumé n SOAP = HTTP + XML Serveur Station ASP Browser client universel Application partie -cliente Client HTTP requêtes SOAP (XML) Réponses SOAP (XML) Serveur HTTP ISAPI CGI Application partie-serveur Servlets 27

Pourquoi utiliser HTTP ? n n HTTP (Hyper. Text Transfer Protocol) est devenu de facto le protocole de communication de l’Internet HTTP est disponible sur toutes les plates-formes – très rapidement HTTP est un protocole simple, qui ne requière que peu de support pour fonctionner correctement HTTP est un protocole sans connexion n Peu de paquets sont nécessaires pour échanger des informations HTTP offre un niveau de sécurité simple et effectif HTTP est le seul protocole utilisable à travers des pare-feu 28

Fonctionnement d’HTTP n n HTTP utilise un protocole requête/réponse basé sur du texte La première ligne de la requête contient 3 éléments n n La première ligne de la réponse contient 2 éléments n n Verbe : POST/GET/HEAD URI : /default. htm Protocole : HTTP/1. 0 - HTTP/1. 1 État : 200, 402 Phrase : OK, Unauthorized Les lignes suivantes contiennent un nombre arbitraire d’entête Le “contenu” suit une ligne d’entête vide n Utilisé essentiellement pour les réponses et pour les requêtes POST 29

Fonctionnement d’HTTP Request GET /bar/foo. txt HTTP/1. 1 ou or POST /bar/foo. cgi HTTP/1. 1 Content-Type: text/plain Content-Length: 13 HTTP Response 200 OK Content-Type: text/plain Content-Length: 12 Hello, World Goodbye, World 30

Pourquoi utiliser XML ? n Utilise du texte (peut être lu et écrit directement) n n Construire correctement du texte XML est simple n n n Pas d’éléments qui se recouvrent (uniquement des imbrications) Les attributs sont clairement identifiés (dir=“in”) Les caractères “<“, “>”, “&” doivent être précédés d’un caractère d’échappement (ou il faut utiliser CDATA) XML est aujourd’hui adopté par tous les acteurs de l’Internet : plates-formes, éditeurs, … XML permet une extensibilité aisée par l’utilisation d’espaces de nommage (namespaces et URIs) XML permet d’ajouter du typage et de la structure à des informations n n n ATTENTION : le texte est globalement peut lisible et vite complexe pour un humain L’information peut être sauvegardée n’importe où sur le Net Les données fournies par de multiples sources peuvent être agrégéees en une seule unité Chaque partie à sa propre structure XML Chaque partie peut définir des types spécifiques W 3 C n’impose pas un API mais en recommande un (DOM) n D’autres sont utilisés : SAX, strcat 31

Exemple de requête utilisant HTTP n Demande de cotation à un serveur POST /Stock. Quote HTTP/1. 1 Host: www. stockquoteserver. com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV: Envelope xmlns: SOAP-ENV= "http: //schemas. xmlsoap. org/soap/envelope/" SOAP-ENV: encoding. Style= "http: //schemas. xmlsoap. org/soap/encoding/"> <SOAP-ENV: Body> <m: Get. Last. Trade. Price xmlns: m="Some-URI"> <symbol>DIS</symbol> </m: Get. Last. Trade. Price> </SOAP-ENV: Body> </SOAP-ENV: Envelope> 32

Exemple de réponse utilisant HTTP/1. 1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV: Envelope xmlns: SOAP-ENV= "http: //schemas. xmlsoap. org/soap/envelope/" SOAP-ENV: encoding. Style= "http: //schemas. xmlsoap. org/soap/encoding/"/> <SOAP-ENV: Body> <m: Get. Last. Trade. Price. Response xmlns: m="Some-URI"> <Price>34. 5</Price> </m: Get. Last. Trade. Price. Response> </SOAP-ENV: Body> </SOAP-ENV: Envelope> 33

Eléments de SOAP n L’enveloppe (enveloppe) n n Les règles d’encodage (encoding rules) n n Définit le mécanisme de sérialisation permettant de construire le message pour chacun des types de données pouvant être échangés Fonctionnement en modèle client / serveur (RPC representation) n n Définit la structure du message Définit comment sont représentés les appels de procédure et les réponses Proposer une mise en œuvre sur HTTP (HTTP Extension Framework) n n RFC 2774 Définir l’échange de message SOAP sur HTTP 34

SOAP Message Structure HTTP Headers Le message SOAP Complet Entête standard HTTP et entête SOAP HTTP SOAP Envelope Enveloppe SOAP Message SOAP Headers SOAP Body Method Call & Data Entête individuelle Corps qui contient les appels de méthodes SOAP Appel de méthode et description en XML de données 35

Modèle de message n SOAP permet une communication par message n n d’un expéditeur vers un récepteur Structure d’un message n Enveloppe / Envelope n n n Élément racine Namespace : SOAP-ENV http: //schemas. xmlsoap. org/soap/envelope/ Entête / Header n n Élément optionnel Contient des entrées non applicatives n n Transactions, sessions, … Corps / Body n Contient les entrées du message n n Nom d’une procédure, valeurs des paramètres, valeur de retour Peut contenir les éléments « fault » (erreurs) 36

Entête d’un Message n Contient des entrées non applicatives n n Transactions, sessions, … L’attribut must. Understand n Si absent ou = 0 n n Si =1 n n n l’élément est optionnel pour l’application réceptrice l’élément doit être compris de l’application réceptrice Si ce n’est pas le cas, le traitement du message par le récepteur doit échouer Exemple <SOAP-ENV: Header> <t: Transaction xmlns: t="some-URI" SOAP-ENV: must. Understand="1"> 5 </t: Transaction> </SOAP-ENV: Header> 37

Corps d’un Message n Contient des entrées applicatives n Encodage des entrées n Namespace pour l’encodage n SOAP-ENC http: //schemas. xmlsoap. org/soap/encoding/ n xsd : XML Schema 38

Principes des règles d’encodage n Décrit dans la section 5 pour les types de base n n Règles par défaut L’encodage est de type : element-normal-form n n Un élément par champ, le nom de l’élément est celui du champ Les règles d’encodage définissent un système de type n n n Il est compatible avec le langage SDL de XML (XML Schema Definition language) Les types SOAP peuvent être décrit en utilisant XSD SOAP utilise les conventions XSD pour associer les instances aux types <foo xmlns: xsi="http: //www. w 3. org/1999/XMLSchema-instance" xsi: type="time. Instant"> 1999 -11 -12 T 09: 43 </foo> n Les tableaux et les références sont typés de manière spécifique en utilisant XSD 39

Règles d’encodage § Types primitifs § Structures § Enumération <element name="price" type="float"/> <element name="greeting" type="xsd: string"/> <element name="Book"><complex. Type> <element name="author" type="xsd: string"/> <element name="title" type="xsd: string"/> </complex. Type></element> <element name="color"> <simple. Type base="xsd: string"> <enumeration value="Green"/> <enumeration value="Blue"/> </simple. Type> </element> <price>15. 57</price> <greeting id="id 1">Hello</greeting> <e: Book> <author>J. R. R Tolkien</author> <title>A hobbit story</title> </e: Book> <color>Blue</color> 40

Règles d’encodage § Références <element name="salutation" type="xsd: string"/> <salutation href="#id 1"/> <e: Book> <title>My Life and Work</title> <firstauthor href="#Person-1"/> <secondauthor href="#Person-2"/> </e: Book> <e: Person id="Person-1"> <name>Henry Ford</name> <address xsi: type="m: Electronic-address"> <email>mailto: henryford@hotmail. com</email> <web>http: //www. henryford. com</web> </address> </e: Person> <e: Person id="Person-2"> <name>Samuel Crowther</name> <address xsi: type="n: Street-address"> <street>Martin Luther King Rd</street> <city>Raleigh</city> <state>North Carolina</state> </address> </e: Person> 41

Règles d’encodage § Tableaux <SOAP-ENC: Array id="id 3" SOAP-ENC: array. Type=xsd: string[2, 2]> <item>r 1 c 1</item> <item>r 1 c 2</item> <item>r 2 c 1</item> <item>r 2 c 2</item> </SOAP-ENC: Array> § Tableaux d’octet <picture xsi: type="SOAP-ENC: base 64"> a. G 93 IG 5 v. Dy. Bicm 73 bi. Bjb 3 c. NCg== </picture> § Tableaux creux <SOAP-ENC: Array id="array-1" SOAP-ENC: array. Type="xsd: string[10, 10]"> <item SOAP-ENC: position="[2, 2]">Third row, third col</item> <item SOAP-ENC: position="[7, 2]">Eighth row, third col</item> </SOAP-ENC: Array> 42

Valeurs empaquetées et valeurs indépendantes n SOAP permet d’encoder les données de différentes manières n n Par exemple dans foo. doit(obj 1, obj 1) On peut vouloir préciser que les deux paramètres effectifs sont identiques n n n Définition d’une valeur indépendante n n Passage par référence dans les langages de programmation Utilisation de valeurs indépendantes Elle apparaît dans l’entête (soap: Header) ou dans le corps (soap: Body) Elle a un attribut unique (soap: id) Elle est généralement encodée comme un élément typé Utilisation d’une valeur indépendante n Utilise l’attribut précédemment défini (soap: href) 46

Valeurs empaquetées et valeurs indépendantes <soap: Envelope xmlns: soap=‘uri for soap’> <soap: Body> <calculate. Area xmlns=‘interface. URI’> <origin><x>23</x><y>34</y></origin> <corner><x>23</x><y>34</y></corner> </calculate. Area> </soap: Body> </soap: Envelope> <soap: Envelope xmlns: soap=‘uri for soap’> <soap: Body> <calculate. Area xmlns=‘interface. URI’> <origin soap: href=‘#id 1’ /> <corner soap: href=‘#id 1’ /> </calculate. Area> <Point soap: id=‘id 1’ xmlns=‘some. URI’> <x>23</x><y>34</y> </Point> </soap: Body> </soap: Envelope> 47

Le retour d’erreurs (faults) n 4 éléments n Faultcode (obligatoire) n n Faultstring (obligatoire) n n Détail de l’erreur non lié au Body du message Autres n n Erreur en cours de cheminement du message (firewall, proxy, MOM) Detail n n Explication lisible d’un humain faultactor (optionel) n n Code d’erreur utilisé par le logiciel (switch(faultcode) { case … D’autres éléments qualifiés par un namespace peuvent être ajoutés Faultcode n 4 groupes de code d’erreur n n Client, Server, Must. Understand, Version. Mismatch Ex: Client. Authentication 48

Le retour d’erreurs (faults) n Must. Understand HTTP/1. 1 500 Internal Server Error Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV: Envelope xmlns: SOAPENV="http: //schemas. xmlsoap. org/soap/envelope/"> <SOAP-ENV: Body> <SOAP-ENV: Fault> <faultcode>SOAP-ENV: Must. Understand</faultcode> <faultstring>SOAP Must Understand Error</faultstring> </SOAP-ENV: Fault> </SOAP-ENV: Body> </SOAP-ENV: Envelope> 49

Le retour d’erreurs (faults) n Erreur sur le corps HTTP/1. 1 500 Internal Server Error Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV: Envelope xmlns: SOAP-ENV="http: //schemas. xmlsoap. org/soap/envelope/"> <SOAP-ENV: Body> <SOAP-ENV: Fault> <faultcode>SOAP-ENV: Server</faultcode> <faultstring>Server Error</faultstring> <detail> <e: myfaultdetails xmlns: e="Some-URI"> <message> My application didn't work </message> <errorcode>1001</errorcode> </e: myfaultdetails> </detail> </SOAP-ENV: Fault> </SOAP-ENV: Body> </SOAP-ENV: Envelope> 50

SOAP sur HTTP n n Utilise le modèle POST Requête/Réponse Requête n n Type MIME : text/xml Champs d’entête supplémentaire de la requête n n n SOAPAction : URI SOAPAction: "http: //electrocommerce. org/abc#My. Message" SOAPAction: "myapp. sdl" SOAPAction: "" SOAPAction: Envelope SOAP Réponse n Status n n n 2 xx : le récepteur a correctement reçu, compris et accepté le message inclus 500 (Internal Server Error): le récepteur n’accepte pas le message Envelope SOAP n n La réponse Le détail des erreurs 51

Un exemple d’échange POST /path/foo. pl HTTP/1. 1 Content-Type: text/xml SOAPAction: interface. URI#Add Content-Length: nnnn <soap: Envelope xmlns: soap=‘uri for soap’> <soap: Body> 200 OK <Add xmlns=‘interface. URI’> Content-Type: text/xml <arg 1>24</arg 1> Content-Length: nnnn <arg 2>53. 2</arg 2> </Add> <soap: Envelope </soap: Body> xmlns: soap=‘uri for soap’> </soap: Envelope> <soap: Body> <Add. Response xmlns=‘interface. URI’ > <sum>77. 2</sum> </Add. Response> </soap: Body> </soap: Envelope> 52

Types de message SOAP n SOAP définit trois types de message n n n Appel (Call) - obligatoire Réponse (Response) - optionnel Erreur (Fault) - optionnel 53

Appel simple POST /Stock. Quote HTTP/1. 1 Host: www. stockquoteserver. com Content-Type: text/xml Content-Length: nnnn SOAPMethod. Name: Some-Namespace-URI#Get. Last. Trade. Price <SOAP: Envelope xmlns: SOAP="urn: schemas-xmlsoap-org: soap. v 1”> <SOAP: Body> <m: Get. Last. Trade. Price xmlns: m="Some-Namespace-URI”> <symbol>DIS</symbol> </m: Get. Last. Trade. Price> </SOAP: Body> </SOAP: Envelope> 54

Réponse HTTP/1. 1 200 OK Content-Type: text/xml Content-Length: nnnn <SOAP: Envelope xmlns: SOAP="urn: schemas-xmlsoap-org: soap. v 1”> <SOAP: Body> <m: Get. Last. Trade. Price. Response xmlns: m="Some-Namespace-URI”> <return>34. 5</return> </m: Get. Last. Trade. Price. Response> </SOAP: Body> </SOAP: Envelope> 55

Erreur <SOAP: Envelope xmlns: SOAP="urn: schemas-xmlsoap-org: soap. v 1> <SOAP: Body> <SOAP: Fault> <faultcode>200</faultcode> <faultstring> SOAP Must Understand Error </faultstring> <runcode>1</runcode> </SOAP: Fault> <SOAP: Body> </SOAP: Envelope> 56

Autres éléments de SOAP sur HTTP n n Le type MIME d’une requête SOAP est text/xml Toutes les requêtes SOAP doivent pouvoir être reconnues comme telles par un serveur HTTP Utilisation d’un entête HTTP spécifique n. SOAPAction: interface. URI#methodname n n n Les erreurs HTTP utilisent l’infrastructure HTTP Les erreurs SOAP/app utilisent les éléments SOAP PDU n n n Modèle standard pour toutes les erreurs Extensible pour prendre en compte les exceptions Il est possible d’utiliser des règles d’encodage spécifiques <foo soap: encoding. Style=‘myuri’ > Here is some random XML!! </foo> 57

Sécurité n Basé sur la sécurité dans http n n Les Firewalls peuvent filtrer les messages facilement Pas de transfert de code applicatif n n n HTTPS Certificats X. 509 Uniquement des données Chaque développeur, choisi de rendre visible telle ou telle méthode Les paramètres sont typés lors du transport 58

Portée de SOAP n SOAP est simple et extensible n n n Il permet de réaliser des appels de méthode sur le Web Indépendant des OS, des modèles objets, des langages Transport des messages par HTTP + XML on the wire Fonctionne avec l’infrastructure Internet existante Permet l’interopérabilité entre OS, langages et modèles objets Ce n’est pas un système réparti à objets Il ne couvre donc pas les fonctions suivantes : n n Pas de ramassage des miettes Pas de contrôle de types, pas de gestion de version Pas de dialogue entre deux serveurs HTTP Pas de passage d’objets par référence n n Nécessite ramassage des miettes en réparti et HTTP bi-directionnel Pas d’activation n Nécessite passage d’objets par référence 59

Autres Extensions n Transport n SOAP sur SMTP/FTP/POP 3/IMAP 4/RMI-IIOP n n n Voir implémentation IBM/Apache SOAP sur MOM (JMS) Encodage n XMI (UML) n n Voir implémentation IBM/Apache Litteral XML n n DOM org. w 3 c. dom. Element sérialisé Voir implémentation IBM/Apache 60

Un peu d’historique § Septembre 1999 : SOAP 0. 9 • Spécifications par Microsoft et Develop. Mentor § Décembre 1999 : SOAP 1. 0 • Soumission des spécifications à l’IETF • Association de User. Land § Mai 2000 : SOAP 1. 1 – Soumission au W 3 C • Nombreuses associations : IBM, HP, Lotus, Compaq, Intel … • XIDL : rapprochement de Corba § Septembre 2000 • Groupe de travail W 3 C pour la standardisation de SOAP • Corba/Soap Interworking RFP => SCOAP 61

Implémentation de SOAP n On peut installer SOAP dans un ORB n n On peut installer SOAP dans un serveur Web n n Nouveau, Orbix 2000, Voyager, COM Apache, ASP/ISAPI, JSP/Servlets/Web. Sphere On peut construire des composants acceptant des requêtes SOAP n Brique de base n n n Canal de communication (channel) sérialisation / dé-sérialisation (serializer) Aiguilleur (dispatcher) 62

Implémentations de SOAP See http: //www. Soapware. org n n n n JAXM, JAX-RPC RI Apache SOAP 2. 2 Apache AXIS Soap. RMI SOAPDirect Instant. XML. Net. . . 63

soap implementation techniques Java [De]serializer Url. Connection Channel libwww Channel Perl [De]serializer Win. Inet Channel C++/COM [De]serializer Servlet Dispatcher ASP Dispatcher ISAPI Dispatcher CGI Dispatcher Legend C++ Java Perl C++/Perl Apache Dispatcher 64

Comparaison RMI RPC DCOM CORBA SOAP Qui SUN/OSF Micro. Soft OMG W 3 C Plate-formes Multi Win 32 Multi Langages de Programmation Java C, C++, … C++, VB, VJ, OPascal, … Multi Langages de Définition de Service Java RPCGEN ODL IDL Réseau TCP, HTTP, IIOP TCP, UDP customisable Firewall IP/IPX Tunneling HTTP Nommage RMI, JNDI, JINI IP+Port Transaction Non Extra Chargement dynamique des classes Non XML GIOP, IIOP, RPC, HTTP Pluggable Transport Layer SNMP HTTP Tunneling HTTP CORBA Firewall IP+Nom COS Naming COS Trader IP+Port, URL MTS OTS, XA Extension applicative dans le header Services Communs Services Sectoriels 65

Open issues with SOAP n n Lack of semantic definitions of Business processes Insufficient message transfer functionality that would be required for business transactions n n n Security and Reliability eb. XML Message Service complements SOAP Low performance 66

SOAP 1. 2 n n Nouvelle spécification pratiquement achevée Basé sur les Infoset n n n indépendant de XML 1. 0 Avec les Attachments Codes d’erreurs hiérarchiques Nouveaux namespaces … 67

Les services Web WSDL : Web Services Description Language Merci à Didier Donsez 68

WSDL n Spécification (09/2000) n n n Objectif n n Décrire les services comme un ensemble d’opérations et de messages abstraits relié (bind) à des protocoles et des serveurs réseaux Grammaire XML (schema XML) n n Ariba, IBM, Microsoft TR W 3 C v 1. 1 (25/03/2001) Modulaire (import d’autres documents WSDL et XSD) Séparation entre la partie abstraite et concrète 69

WSDL Interface Implementation <definitions> <import> <types> <service> <message> <port. Type> <binding> 70

Éléments d’une définition WSDL n <types> n n Contient les définitions de types utilisant un système de typage (comme XSD). <message> n Décrit les noms et types d’un ensemble de champs à transmettre n n <porttype> n n Spécifie une liaison d’un <porttype> à un protocole concret (SOAP 1. 1, HTTP 1. 1, MIME, …). Un <porttype> peut avoir plusieurs liaisons ! <port> n n Décrit un ensemble d’opérations. Chaque opération a zéro ou un message en entrée, zéro ou plusieurs message de sortie ou de fautes <binding> n n Paramètres d’une invocation, valeur du retour, … Spécifie un point d’entrée (endpoint) comme la combinaison d’un <binding> et d’une adresse réseau. <service> n Une collection de points d’entrée (endpoint) relatifs. 71

Élément <types> n n Contient les définition de types utilisant un système de typage (comme XSD). Exemple  <types> <xsd: schema target. Namespace="urn: xml-soap-address-demo" xmlns: xsd="http: //www. w 3. org/1999/XMLSchema"> <xsd: complex. Type name="phone"> <xsd: element name="area. Code" type="xsd: int"/> <xsd: element name="exchange" type="xsd: string"/> <xsd: element name="number" type="xsd: string"/> </xsd: complex. Type> <xsd: complex. Type name="address"> <xsd: element name="street. Num" type="xsd: int"/> <xsd: element name="street. Name" type="xsd: string"/> <xsd: element name="city" type="xsd: string"/> <xsd: element name="state" type="xsd: string"/> <xsd: element name="zip" type="xsd: int"/> <xsd: element name="phone. Number" type="typens: phone"/> </xsd: complex. Type> </xsd: schema> </types> 72

Élément <message> n Décrit les noms et types d’un ensemble de champs à transmettre n n Paramètres d’une invocation, valeur du retour, … Exemple  <message name="Add. Entry. Request"> <part name="name" type="xsd: string"/> <part name="address" type="typens: address"/> </message> <message name="Get. Address. From. Name. Request"> <part name="name" type="xsd: string"/> </message> <message name="Get. Address. From. Name. Response"> <part name="address" type="typens: address"/> </message> 73

Élément <porttype> n n Décrit un ensemble d’opérations. Plusieurs types d’opérations n One-way n n Request-response n n Le point d’entrée reçoit un message (<input>) et retourne un message corrélé (<output>) ou un ou plusieurs messages de faute (<fault>). Solicit-response n Le point d’entrée envoie un message (<output>) et recoit un message corrélé (<input>) ou un ou plusieurs messages de faute (<fault>). n n Notification n n Binding HTTP : 2 requêtes HTTP par exemple Le point d’entrée envoie un message de notification (<output>) Paramètres n Les champs des messages constituent les paramètres (in, out, inout) des opérations 74

Élément <porttype> n Exemple  <port. Type name="Address. Book"> <!– One way operation --> <operation name="add. Entry"> <input message="Add. Entry. Request"/> </operation> <!– Request-Response operation --> <operation name="get. Address. From. Name"> <input message="Get. Address. From. Name. Request"/> <output message="Get. Address. From. Name. Response"/> </operation> </port. Type> 75

Élément <binding> n Exemple de binding sur SOAP et HTTP  <binding name="Address. Book. SOAPBinding" type="Address. Book"> <soap: binding style="rpc" transport="http: //schemas. xmlsoap. org/soap/http"/> <operation name="add. Entry"> <soap: operation soap. Action=""/> <input> <soap: body use="encoded" namespace="urn: Address. Fetcher 2" encoding. Style="http: //schemas. xmlsoap. org/soap/encoding/"/> </input> <output> <soap: body use="encoded" namespace="urn: Address. Fetcher 2" encoding. Style="http: //schemas. xmlsoap. org/soap/encoding/"/> </output> </operation> <operation name="get. Address. From. Name"> <soap: operation soap. Action=""/> <input> <soap: body use="encoded" namespace="urn: Address. Fetcher 2" encoding. Style="http: //schemas. xmlsoap. org/soap/encoding/"/> </input> <output> <soap: body use="encoded" namespace="urn: Address. Fetcher 2" encoding. Style="http: //schemas. xmlsoap. org/soap/encoding/"/></outp ut> </operation> 76 </binding>

Élément <binding> n Exemple de binding avec SOAP et SMTP <definitions. . . > <types> <schema target. Namespace="http: //stockquote. com/stockquote. xsd" xmlns="http: //www. w 3. org/2000/10/XMLSchema"> <element name="Subscribe. To. Quotes"> <complex. Type><all><element name="ticker. Symbol" type="string"/></all></complex. Type></element> <element name="Subscription. Header" type="uri. Reference"/> </schema> </types> <message name="Subscribe. To. Quotes"> <part name="body" element="xsd 1: Subscribe. To. Quotes"/> <part name="subscribeheader" element="xsd 1: Subscription. Header"/> </message> <port. Type name="Stock. Quote. Port. Type"> <operation name="Subscribe. To. Quotes"> <input message="tns: Subscribe. To. Quotes"/> </operation> </port. Type> … 77

Élément <binding> … <binding name="Stock. Quote. Soap" type="tns: Stock. Quote. Port. Type"> <soap: binding style="document" transport="http: //stockquote. com/smtp"/> <operation name="Subscribe. To. Quotes"> <input message="tns: Subscribe. To. Quotes"> <soap: body parts="body" use="literal"/> <soap: header message="tns: Subscribe. To. Quotes" part="subscribeheader" use="literal"/> </input> </operation> </binding> <service name="Stock. Quote. Service"> <port name="Stock. Quote. Port" binding="tns: Stock. Quote. Soap"> <soap: address location="mailto: subscribe@stockquote. com"/> </port> </service> </definitions> 78

Élément <service> n n Une collection de points d’entrée (endpoint) relatifs Exemple : <? xml version="1. 0" ? > <definitions name="urn: Address. Fetcher" target. Namespace="urn: Address. Fetcher 2" xmlns: typens="urn: xml-soap-address-demo" xmlns: xsd="http: //www. w 3. org/1999/XMLSchema" xmlns: soap="http: //schemas. xmlsoap. org/wsdl/soap/" xmlns="http: //schemas. xmlsoap. org/wsdl/"> …  <service name="Address. Book. Service"> <port name="Address. Book" binding="Address. Book. SOAPBinding"> <soap: address location="http: //www. mycomp. com/soap/servlet/rpcrouter"/> </port> </service> </definitions> 79

WSDL n n n Open – allows for other namespaces and thus highly extensible Ability to import other schemas & WSDL Provides “recipe” for Web Services Provides both interface and implementation details Allows for separation of the two 80

Outils n n n Générateur WSDL à partir de déploiement SOAP ou EJB, … Générateur de proxy SOAP à partir de WSDL Toolkits (Wsdl 2 Java / Java 2 Wsdl, …) n Propriétaires (non normalisés) 81

Génération WSDL 82

Les services Web UDDI : Universal Description, Discovery and Integration 83

UDDI n Spécification (09/2000) n n Ariba, IBM, Microsoft +260 autres sociétés Objectifs n n annuaire mondial d'entreprises pour permettre d'automatiser les communications entre prestataires, clients, etc. plusieurs entrées indexées : nom, carte d'identité des sociétés, description des produits, services applicatifs invocables à distance (références des connexions) n n Indexation des catalogues propriétaires (eb. XML, Rosetta. Net, Ariba, Commerce One, etc. ) Grammaire XML (schéma XML) n Soumission/interrogation basées sur SOAP et WSDL 84

UDDI n Worldwide directory of companies, services, products. . . n n Green pages n n White pages, Yellow pages, Green pages Namespace to describe how to use the service, etc. . . Identifier of who published the service Unique identifier (t. Model. Key) of this service for registration Accessing web services n Bindings declared in directory entries: n n for example, (t. Model. Key, URL) associations UDDI directories, search engines n xmethods. net, soapware. org, salcentral. com, soap-wrc. com, … 85

White, yellow and green pages n « White pages » n n address, contact, and known identifiers « Yellow pages » n industrial categorizations n n Industry: NAICS (Industry codes - US Govt. ) Product/Services: UN/SPSC (ECMA) Location: Geographical taxonomy « Green pages » n technical information about services 86

UDDI : The vision Advanced Discovery via Portals and Marketplaces Marketplace UDDI Registries and Protocol Marketplace Search Portal Business Users Technical Users 87

UDDI Information Model Provider: Information about the entity who offers a service t. Model: Descriptions of specifications for services. 1…n 0…n Service: Descriptive information about a particular family of technical offerings 0…n Binding: Technical information about a service entry point and construction specs Bindings contain references to t. Models. These references designate the interface specifications for a service. 88

UDDI Schema Interface Implementation <business. Entity> <business. Service> <t. Model> <binding. Template> 89

How UDDI Works: t. Model n n n t. Model = Technology Model Generic meta-data structure to uniquely represent any concept or construct Also includes interface protocol definitions Powerful abstraction modeling system Examples: WSDL files, XML schema, namespaces, categorization schemes 90

UDDI : <t. Model> n <t. Model> represents meta-data and interfaces <t. Model xmlns="urn: uddi-org: api" t. Model. Key="UUID: AAAA-AAAAAAAA"> <name>microsoft-com: creditcheck</name> <description xml: lang="en">Check credit limits</description> <overview. Doc> <overview. URL>http: //schema. com/creditcheck. wsdl </overview. URL> </overview. Doc> <category. Bag> <keyed. Reference t. Model. Key="UUID: CD 153257 -086 A-4237 -B 336 -6 BDCBDCC 6634" key. Name="Consumer credit gathering or reporting services" key. Value="84. 16. 01. 00"/> <keyed. Reference t. Model. Key="UUID: C 1 ACF 26 D-9672 -4404 -9 D 70 -39 B 756 E 62 AB 4" key. Name="types" key. Value="wsdl. Spec"/> </category. Bag> </t. Model> 91

Providers, Services And Bindings n Providers n n Services n n Examples: Accounting Department, Corporate Application Server Name, Description, Contact Information Categorization and Identification Information Examples: Purchase Order services, Payroll services Name, Description(s) Categorization Information Bindings n n Description(s), access points, parameters Examples: Access Point (http: //. . . ) for Web Service 92

<binding. Template> n <binding. Template> represents data and implementation details <binding. Template service. Key="33 c 3 d 124 -e 967 -4 ab 1 -8 f 51 -d 93 d 95 fac 91 a" binding. Key="48 f 2 bc 6 b-a 6 de-4 be 8 -9 f 2 b -2342 aeafaaac"> <access. Point URLType="http"> http: //localhost/Hello. World/Service 1. asmx </access. Point> <t. Model. Instance. Details> <t. Model. Instance. Info t. Model. Key="uuid: 64 c 756 d 13374 -4 e 00 -ae 83 -ee 12 e 38 fae 63“/> </t. Model. Instance. Details> </binding. Template> 93

Important UDDI Features n n n Neutral in terms of protocols – as a registry, it can contain pointers to anything Can search by business, service, Web Service (t. Model), binding Usage of Globally Unique Identifiers (GUIDs) Specification allows public and private nodes Delineation between interface and implementation 94

Les services Web Implémentations : Les APIs Java : JAXP, JAX-RPC, JAXM, JAXR, JAXB 95

Les APIs Java pour les SW n Service Description (WSDL) n n n Service Registration and Discovery (UDDI, eb. XML Reg/Rep) n n JSR 110 (Java API for WSDL) JAX-RPC (Java ™ API for XML-based RPC) JAXR (Java ™ API for XML Registry) Service Invocation (SOAP, eb. XML Message Service) n JAXM (Java ™ API for XML Messaging), JAX-RPC 96

Les APIs Java pour les SW n Electronic business framework n n JAXM with eb. XML Message Service (TR&P) profile JAXR with eb. XML Registry/Repository JSR-157: Java API for eb. XML CPP/CPA J 2 EE TM Web Services Framework n n n JSR 151: J 2 EE 1. 4 JSR 109: (Enterprise Web services) JAXM, JAX-RPC 97

Les APIs Java pour les SW n XML document management n n n JAXP (Java API for XML processing) JAXB (Java API for XML data-binding) Security n XML Encryption (JSR 106) n XML Digital Signature (JSR 105) n XML Trust Service (JSR 104) n Web services security assertions (JSR 155) 98

Les services Web Implémentation avec JAX-RPC From Sun … 99

JAX-RPC : cycle de développement n n n 1. Service endpoint definition 2. Service endpoint implementation 3. Service endpoint deployment 4. Service description 5. Service publication and discovery 100

1. Service Endpoint Definition n Specified in Service Definition Interface n n Could be generated from WSDL document using a tool or Could be written in Java programming language directly No assumption about type of client that would use this service definition interface Exemple : Hello. IF. java package hello; import java. rmi. Remote. Exception; public interface Hello. IF extends Remote { public String say. Hello(String s) throws Remote. Exception; } 101

2. Service Implementation n n Service implementation class is an ordinary Java class Invocation done inside the servlet container n n n JAX-RPC defines Servlet-based Endpoint model Other endpoint models (e. g. stateless session beans) will be defined in J 2 EE 1. 4, JSR 109, EJB 2. 1 Optional Service. Lifecycle interface for initialization and destruction callbacks 102

Example: Service Implementation Hello. Impl. java : package hello; public class Hello. Impl implements Hello. IF { public String message = new String("Hello "); public String say. Hello(String s) { return new String(message + s); } } 103

3. Service Deployment n n Deployed on JAX-RPC runtime system Generates of container specific artifacts (skeleton or tie class) based on the service definition interface Configures one or more protocol bindings for the JAX-RPC service Creates one or more service ports (or endpoints) for this JAX-RPC service 104

4. Generate Service Description n JAX-RPC service endpoint mapped to WSDL service description WSDL enables export of a JAX-RPC service endpoint across heterogeneous environments JAX-RPC specifies the standard mapping between WSDL and Java: n n Mapping between service endpoint interface and WSDL definitions Binding to a specific protocol and transport 105

5. Service Publication n Publish the JAX-RPC service to a registry n WSDL document of a service along with meta data 106

Simple Client package hello; public class Hello. Client { public static void main(String[] args) { try { // Get Stub instance Hello. IF_Stub stub = (Hello. IF_Stub) (new Hello. World_Impl(). get. Hello. IF()); // Set endpoint address stub. _set. Property(javax. xml. rpc. Stub. ENDPOINT_ADDRESS_PROPERTY, args[0]); // Make method invocation System. out. println(stub. say. Hello("Duke!")); } catch (Exception ex) { ex. print. Stack. Trace(); } 107

A few things on this simple client n n Instead of getting service implementation "Hello. World_Impl()" object directly, it could get Service interface "Hello. IF" object from Service object, which in turn can be obtained from Service. Factory Instead of using Stub "Hello. IF_Stub" for invoking a remote method, it could use Service interface "Hello. IF" Service service = Service. Factory. new. Instance(). create. Service(. . . ); Hello. IF hello= (Hello. IF)service. get. Port(Hello. IF. class); hello. say. Hello(); 108

Client: DII Invocation Model Service. Factory factory = Service. Factory. new. Instance(); Service service = factory. create. Service(new QName(qname. Service)); QName port = new QName(qname. Port); Call call = service. create. Call(); call. set. Port. Type. Name(port); call. set. Target. Endpoint. Address(endpoint); call. set. Property(Call. SOAPACTION_USE_PROPERTY, new Boolean(true)); call. set. Property(Call. SOAPACTION_URI_PROPERTY, ""); call. set. Property(ENCODING_STYLE_PROPERTY, URI_ENCODING); QName QNAME_TYPE_STRING = new QName(NS_XSD, "string"); call. set. Return. Type(QNAME_TYPE_STRING); call. set. Operation. Name(new QName(BODY_NAMESPACE_VALUE, "say. Hello")); call. add. Parameter("String_1", QNAME_TYPE_STRING, Parameter. Mode. PARAM_MODE_IN); String[] params = { new String("Duke!") }; String result = (String)call. invoke(params); System. out. println(result); 109

Apache SOAP n n Open-source implementation of the SOAP v 1. 1 and SOAP Messages with Attachments Not JAXM and JAX-RPC compatible yet n Apache SOAP node should interoperate with JAXM node n Latest version is v 2. 2 n http: //xml. apache. org/soap 110

Apache Axis n n Ground-up re-architecture and implementation of SOAP 1. 1 and W 3 C XMLP (SOAP 1. 2) effort Based on configurable chains of message handlers n n SAX-based XML processing n n n Flexible, Modular, User-extensible Fast Transport framework JAX-RPC compliant (Technology Compatibility Kit) Axis 1. 0 available (7 0 ctober 2002) http: //xml. apache. org/axis 111

L’architecture d’Axis 112

Les services Web Conclusion 113

Et on boucle la boucle ! Annuaire UDDI 2 : J’ai trouvé! Voici le serveur hébergeant ce service web 1 : Je recherche un service WEB 3 : Quel est le format d’appel du service que tu proposes? Contrat SOAP 4 : Voici mon contrat (WSDL) XML Client XML Serveur 5 : J’ai compris comment invoquer ton service et je t’envoie un document XML représentant ma requête XML 114 6 : J’ai exécuté ta requête et je te retourne le résultat

Les services Web n n La 3ème génération du Web Technologies Standards du Web n n n SOAP 1. 1 (puis SOAP 1. 2) WSDL Technologies non standardisées n n n UDDI, DISCO GXA (Global XML Architecture) WSDD, WSFL, ASMX, … 115

Références n Services Web : n n n SOAP : n n n Spécification SOAP 1. 1 : http: //www. w 3 c. org/TR/SOAP Spécification SOAP 1. 2 : http: //www. w 3 c. org/TR/soap 12 Implémentations : http: //www. soapware. org Exemples en ligne : http: //soapclient. com/soaptest. html UDDI : n n n Spécifications officielles : http: //www. w 3 c. org Documentations et exemples en ligne : http: //www. xmlbus. com Spécification : http: //www. uddi. org Serveur UDDI : http: //uddi. microsoft. com et http: //uddi. ibm. com Cours : n n Didier Donsez, Web Services Michel Riveill, SOAP 116