Master Web Intelligence

Introduction aux Web Services

Rahee Ghurbhurn, mail : ghurbhurn@emse.fr

Contenu du cours

Partie I : Gnralits

Dfinitions Motivations Vue globale XML SOAP WSDL UDDI Une petite implmentation Les plate-formes Leur utilisation. Limites et volutions Positionnement par rapport aux agents.

Partie II : Les technologies

Partie III: Et dans la pratique ???

Partie IV : Le futur des Web Services

Partie I : Gnralits

Dfinitions

Quelques dfinitions

Les web services permettent linvocation de fonctions distantes, prsentes sur des systmes distribus et htrognes, grce au protocole HTTP et XML. les services web sont des applications auto-descriptives, modulaires et faiblement couples qui fournissent un modle de programmation et de dploiement dapplications, bas sur des normes, et sexcutant au travers de linfrastructure web Les Web Services, H.Kadima, Dunod 2003 Un service web est une application conue pour assurer une interoprabilit entre machines au travers dun rseau. Un web service est une interface qui dcrit un ensemble doprations accessibles via un rseau par des messages XML standards Un service web est un composant applicatif mis la disposition sur un rseau et disposant de mthodes que lon peut invoquer distance via lemploi de protocoles standards. Les services Web prsentent lavantage dtre faiblement coupls, indpendants des plateformes et rutilisables Livre Blanc :
Les Services Web, S.Bardet, 2003

Motivations: un contexte B2C

Le Business to Consumer (B2C)

Entreprise A

Client

HTTP

Entreprise D Entreprise C

Entreprise B

Motivations: un contexte B2B

Business to Business (B2B)

Envoi de bons de commandes Fournisseur A Traitements Envoi produits Entreprise A Clients

Envoi produits

Fournisseur B

Motivations: un contexte A2A

Intra entreprise ( intgration dapplications )

Calcul du fret / risque taux de change

MS Serv Fi SI DW Serv RH SAP Site B

Prop Serv Mkt SI

Site A SAP Serv Fi SI SI Serv Mkt IBM Prop Serv RH SI DW SI Serv Aht Oracle Ajout de salaris

SI Serv Aht IBM

Motivations: volution des middlewares

Quelle est la nouveaut dans les web services ? Pourquoi ne pas utiliser les technologies existantes?

Remote Procedure Call Message Oriented Middleware Objets Distribus Database Oriented Middleware

Motivations: volution des middlewares - RPC

Remote Procedure Call (RPC)

Principe dappel de procdure type client/serveur sexcutant sur une machine distante dans un environnement dapplications distribues. Un des plus vieux middlewares Fonctionne de manire synchrone Facile comprendre et coder Ncessite beaucoup de ressources Complexe administrer Pas de standards / Implmentation spcifique un vendeur Ne supporte pas la POO

Motivations: volution des middlewares - MOM (1/2)

Message Oriented Middleware

Utilisation de messages asynchrones pour faire communiquer les applications

10

Motivations: volution des middlewares - MOM (2/2)

Les avantages

Faible couplage Garantie de livraison Mcanisme de persistance Risque de surcharge du systme Implmentation propritaire ( msg + architecture) Plus le systme est grand et htrogne, plus ladministration est difficile Peu portable et peu interoprable

Les inconvnients

11

Motivations: volution des middlewares - CORBA (1/2)

Les objets distribus

CORBA

Norme de communication utilise pour l'change entre objets logiciels htrognes. Un langage, IDL (Interface Definition Language) dcrit les traitements effectus et les formats de donnes en entre et en sortie. Un bus applicatif, ORB (Object Request Broker) constitue le cur de CORBA par lequel les requtes sur les objets transitent.

12

Motivations: volution des middlewares - CORBA (2/2)

Les avantages de CORBA :

Indpendant du systme dexploitation et du langage de programmation. Permet lintgration des systmes propritaires grce lIDL Gestion des rfrences CORBA standardis par lOMG CORBA intgre les aspects mtiers. Incompatibilit entre les implmentations CORBA complexe apprhender et mettre en place. Prix lev Problme de pare-feu Scurit et administration Pas aussi simple quon pense, ncessite des changements dans les applications

Les inconvnients

13

Motivations: volution des middlewares - RMI (1/2)

Remote Method Invocation

Le but de RMI est de permettre l'appel, l'excution et le renvoi du rsultat d'une mthode excute dans une machine virtuelle diffrente de celle de l'objet l'appelant

14

Motivations: volution des middlewares - RMI (2/2)

Avantages

Plus simple que le dveloppement des sockets JAVA Supporte la POO Transparence dans les communications entre objets Gestion distribue des ressources Limit la plate-forme JAVA Architecture fortement couple Pas de gestion de session

Inconvnients

15

Motivations: volution des middlewares - COM/DCOM (1/2)

Component Object Model (COM/ DCOM)

Modle de Microsoft pour le dveloppement de composants logiciels rutilisables, orients objet et indpendants du langage de programmation.

16

Motivations: volution des middlewares - COM/DCOM (2/2)

Les avantages

Simple dutilisation. Portabilit binaire Spcifique Microsoft Problme de gestion des tats et de sessions Pas de portabilit de code-sources

Les inconvnients

17

Motivations: volution des middlewares - Composants (1/2)

Les composants

Un composant est un lment de base dans la construction d'applications.C'est une unit logicielle autonome offrant des interfaces spcifies permettant entre autre de configurer le composant lui-mme. Le composant dispose aussi de fonctionnalits additionnelles comme la gestion du dploiement,de la composition et sa gestion dynamique. Il a pour but

de diminuer la complexit des applications (notamment distribues ) d'augmenter la productivit d'amliorer la qualit logicielle Corba Component Model J2EE EJB

Deux trs utiliss

18

Motivations: volution des middlewares - Composants (2/2)

Intrt des composants

Indpendance des composants la Compilation Granularit: Faciliter la cration de grandes applications Rutilisation: Composants = boites noires indpendantes Programmation: Faciliter (parfois !) Extensibilit: Complter un composant sans effets de bord Excution: Matrise du cycle de vie

19

Motivations: positionnement des web services (1/3)

Les besoins des entreprises

Flexibilit et indpendance

La possibilit de rorganiser le systme de faon rapide, efficace et peu chre Entre partenaires, clients ou services Tout le monde na pas la mme organisation, les mme systmes Comment partager des applications si tout le monde est protg par un pare-feu ? Garantie de livraison

Partage dinformations/dapplications

Interoprabilit

Scurit et confidentialit

20

Motivations: positionnement des web services (2/3)

Les web services rpondent la question :

Peut-on combiner les caractristiques dune architecture distribue des protocoles de communication standards et des clients lgers ?

Construits partir des caractristiques de la problmatique dintgration dapplications et de partage dinformations entre plate-formes htrognes ( et pas comment je fais pour accder une mthode ?) Technologies acceptes par un grand nombre de fournisseurs de logiciels et dorganismes ( Microsoft, OMG, W3C, OASIS)

21

Motivations: positionnement des web services (3/3)

En Rsum

CORBA

Multi-langages, multi-plate-formes, multi-vendeurs Mono-langage, multi-plate-formes (JVM) Multi-langages, plate-forme win32

JAVA RMI

DCOM

22

Motivations: intrt des web services

XML est utilis pour lchange des donnes et messages. Ils permettent lintgration de plate-formes htrognes via le protocole HTTP Les dveloppeurs ont lembarras du choix en matire de langage de programmation : Java, C, C++, Perl, Python, C#, et/ou Visual Basic, Peu ou pas de modification des applications existantes Permet une intgration faible, les composants sont simples mais peuvent rsoudre des problmes complexes Lutilisation du protocole HTTP permet de passer les parefeu

23

Motivations: intrt des web services

Il nexiste pas de client propritaire Outils de dveloppement et de dploiement fournis par les principales plate-formes J2EE et Microsoft .NET Permet la localisation et linvocation dynamique dautres services partir de registres privs ou publics

24

Vue globale : scnario gnral dutilisation

Est-ce quil y a quelquun pour calculer le risque li au contrat ? Annuaire

Comment utilise-t-on le service ? Voici les spcifications

Fournisseur

Client Ok jai compris voil les donnes

25

Voil le rsultat

Vue globale : les technologies de bases

26

Partie II : Les Technologies

27

Les technologies : XML (1/2)

Extensible Markup Language (XML)

Norme du W3C depuis 1998 , XML reprend les qualits de SGML (et utilise sa syntaxe):
un balisage logique hirarchique. une description facultative du document; elle peut tre extrieure ou intgre au document. une portabilit quasi universelle.

Il permet de crer des pages Internet sophistiques, de structurer un document, de dcrire des donnes. Il est aussi utilis pour les changes entre machines et/ou programmes, mme trangers entre eux.

28

Les technologies : XML (2/2)

Comment XML facilite lutilisation de WS ?

La sparation du contenu dun document, de sa structure et de sa reprsentation facilite lchange dinformations entre les diffrents partenaires. Permet la composition de services plus complexes travers la dfinition des enchanements entre les services grce BPEL4WS Favorise lmergence de standards dindustrie dans la mesure o les structures de donnes sont rutilises et rutilisables.

29

Les technologies : XML -DTD

DTD

Document spcifiant la structure, la syntaxe et le contenu dun document XML Peut tre inclue dans le fichier XML, mais pour une meilleure rutilisabilit, la DTD est spare du document XML quelle reprsente Elle peut contenir des dclarations, des notations, des lments, des listes dattributs, des commentaires La DTD nest pas un document XML Difficile faire voluer Il ny a pas de limites sur les caractres La notion despace de nommage nexiste pas

Les limites

30

Les technologies : XML - Namespace

Les namespaces

Consiste regrouper les noms dlments et les noms dattributs dans une collection qui sera identifie par une URI. Cette technique permet dviter des conflits de noms dans un document XML et permet dadapter les traitements au contenu du document. Les namespaces favorisent la rutilisation des standards dj dfinis dans des domaines dactivits spcifiques. Permet de spcifier la syntaxe dune classe de documents XML en dfinissant les lments et attributs ainsi que les contraintes sur celleci. ( Mmes objectifs quune DTD).

Schma XML

31

Les technologies : SOAP

Simple Object Access Protocol

SOAP permet une normalisation des changes de donnes. Les donnes sont encodes en XML et changes par des appels de procdures distance (RPC) en utilisant HTTP/SMPT/POP comme protocole de communication. Standard W3C Simple, extensible et permet le diagnostic des erreurs Message unidirectionnel Fonctionne de manire synchrone et asynchrone. Indpendant de la plate-forme et du langage Nest pas perturb par les pare-feu

32

Les technologies : SOAP- fonctionnement

Fonctionnement
Requte SOAP Nom + paramtres Dcodage + Appel de mthodes Excution de la mthode

HTTP

Client

Listener

Service Methods

DB

Rponse SOAP

Encodage en SOAP

Rcupration rponse DB

33

Le mme processus de dcodage et dexcution du ct client

Les technologies : SOAP - structure (1/6)

Structure des messages SOAP

Enveloppe

Permet de spcifier version de SOAP utilise Optionnel, permet de spcifier certaines directives pour le traitement du message Contient les donnes Permet lenvoi de donnes non-XML

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soapenvelope"> <env:Header> <n:alertcontrol xmlns:n="http://example.org/alertcontrol"> <n:priority>1</n:priority> <n:expires>2005-01-26T10:30:00-11:00</n:expires> </n:alertcontrol> </env:Header> <env:Body> <m:alert xmlns:m="http://example.org/alert"> <m:msg>Pas de Pause !!!! </m:msg> </m:alert> </env:Body> </env:Envelope>

Entte

Corps

Pices jointes

34

Les technologies : SOAP - structure (2/6)

Lenveloppe
<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/ soap:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/'> <! Entte et corps--> </soap:Envelope>

lment obligatoire dans un message SOAP Permet de spcifier la version de SOAP utilise, en utilisant un espace de nom http://www.w3.org/2003/05/soap-envelope Permet aussi de spcifier les rgles dencodage (srialisation et dsrialisation) mises en uvre dans le message (encodingStyle)

35

Les technologies : SOAP - structure (3/6)

LEntte

lment optionnel Contient des lments spcifiques lapplication Peut contenir trois types dlments

Actor
<m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:actor="http://www.w3schools.com/appml/">

Permet de prciser le destinataire final du message (message path) MustUnderstand (0,1)

<m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:mustUnderstand="1">234</m:Trans>

Spcifie que le rcepteur du message doit obligatoirement comprendre cet lment. Si ce nest pas le cas, le rcepteur arrte tout traitement Encodingstyle Mme dfinition que pour lenveloppe.

36

Les technologies : SOAP - structure (4/6)

Le corps

Contient les donnes ( paramtres) utilises pour un appel de procdure distante effectu par le destinataire final Ce ne sont pas des lments SOAP, mais des lments spcifiques lapplication.

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <m:GetPrice xmlns:m="http://www.w3schools.com/prices"> <m:Item>Apples</m:Item> </m:GetPrice> </soap:Body> </soap:Envelope>

37

Les technologies : SOAP - structure (5/6)

Les rponses SOAP

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices"> <m:Price>1.90</m:Price> </m:GetPriceResponse> </soap:Body> </soap:Envelope>

SOAP Fault

Fait partie du corps dun message SOAP. Envoy lmetteur de lappel, lui indiquant les raisons de lchec Il existe 4 descripteurs

38

Les technologies : SOAP - structure (6/6)

Les descripteurs derreurs

Faultcode

Version Mismatch MustUnderstand Client Server

Le namespace donn ne permet pas de valider le message Llment de lentte na pas t compris Le message na pas t correctement form ou il manque certaines informations Serveur non accessible ou erreur de dcodage du message

FaultString FaultActor Detail

Permet de prciser la nature de lerreur Information sur la localisation de lerreur Erreur spcifique lapplication lie aux donnes prsentes dans le corps du message

39

Les technologies : SOAP - exemple

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:encodingStyle="http://schemas.xmlsoap.org/ soap/ encoding/"> <soap:Body> <soap:Fault> <faultcode>soap:MustUnderstand</faultcode> <faultstring>Mandatory Header error.</faultstring> <faultactor>http://www.wrox.com/heroes/endpoint.asp</ faultactor> <detail> <w:source xmlns:w="http://www.wrox.com/"> <module>endpoint.asp</module> <line>203</line> </w:source> </detail> </soap:Fault> </soap:Body> </soap:Envelope

40

Les technologies : WSDL

Web Services Description Language

41

Une description en XML des services web. Il dcrit de manire abstraite et indpendante du langage de programmation, lensemble des fonctionnalits offertes par un service. Il permet de connatre les protocoles, les serveurs, les ports, le format des messages, les entres, les sorties, les exceptions possibles et les oprations ralises par un service web.

Les technologies : WSDL

Historique

La notion dinterface a t introduite en 1994 avec la spcification du RPC. Adopt par OMG pour CORBA, par Microsoft pour les objets COM ( COM ODL et IDL). Ces implmentations ne sont pas quivalentes, donc pas interoprables Avec la plate-forme .NET de Microsoft, une nouvelle version dinterface a t dveloppe : le CLR (Common Language Runtime). Le CLR permet dencapsuler les meta donnes directement dans les composants, ce qui rend inutiles les IDL. IBM a dvelopp le langage Network Accessible Service Specification Language (NASSL) Microsoft SOAP Contract Language ( evolution de SDL) WSDL correspond la fusion de SCL et de NASSL

42

Les technologies : WSDL - structure (1/8)

La structure dun document WSDL

Dfinitions

Il contient le nom du service dcrit et les namespaces faisant rfrence aux types utiliss dans le document.

<definitions name="GetStockQuote targetNamespace="http://advocatemedia.com/GetStockQuote.wsdl" xmlns:myns = "http://advocatemedia.com/GetStockQuote.wsdl" xmlns:myXsd = "http://advocatemedia.com/GetStockQuote.xsd" xmlns:soap = "http://schemas.xmlsoap.org/wsdl/soap" xmlns="http://schemas.xmlsoap.org/wsdl/"> </definitions>

Types

Permet la dfinition des lments abstraits prsents dans le document WSDL Utilise gnralement la grammaire XSD car cette dernire supporte un grand nombre de type de donnes. Ne peut tre prsent quune fois, mais peut contenir plusieurs dfinitions.

43

Les technologies : WSDL - structure (2/8)

<types> <schema targetNamespace=http://advocatemedia.com/GetStockQuote.xsd xmlns="http://www.w3.org/2000/10/XMLSchema"> <element name="StockQuoteRequest"> <complexType> <all> <element name="symbol" type="string"/> </all> </complexType> </element> <element name="StockQuoteResponse"> <complexType> <all> <element name="price" type="float"/> </all> </complexType> </element> </schema> </types>

44

Les technologies : WSDL - structure (3/8)

Message(name,(part()))

Deux types de message IN et OUT. Si aucun argument nest ncessaire, il ny a pas de messages IN. Dfinition abstraite des messages changs entre deux nuds Peut tre compos de plusieurs parties (Parts) correspondant aux paramtres passs aux fonctions. Il peut tre dfini comme un type ( simple ou complexe) ou un lment. Lordre des parts dpend de la signature de la mthode Un lment implique une dfinition obligatoire de ce dernier dans les types.

Part(nom, type ou element)

<message name="GetStockQuoteRequest"> <part name="body" element="myXSD:StockQuoteRequest"/> </message> <message name="GetStockQuoteResponse"> <part name="body" element="myXSD:StockQuoteResponse"/> </message>

45

Les technologies : WSDL - structure (4/8)

portType(name, operation(name,(input msg, output msg)))

Correspond une interface IDL en CORBA. Il contient les classes accessibles. Si le service propose diffrentes classes, leur nom doit tre diffrent. A chaque portType sont associes des oprations, correspondant aux mthodes. Pour chaque mthode on dfinit le message dentre et de sortie. Les oprations peuvent tre de natures diffrentes : unidirectionnelle, requte/rponse, sollicitation/rponse et notification.
<portType name="GetStockQuotePort"> <operation name="GetStockQuote"> <input message="myns:GetStockQuoteRequest"/> <output message="myns:GetStockQuoteResponse"/> </operation> </portType>

46

Les technologies : WSDL - structure (5/8)

Binding(name, type, (?:binding, style, transport),(operation(?:operation, ? :action (input(?:boby, encodingStyle, namespace, use), output(?:boby, encodingStyle, namespace, use))

Permet de spcifier quel protocole dinvocation utiliser HTTP GET/POST, SOAP, SMTP, FTP. Un portType(classe) nest pas forcment invoqu par un seul protocole Nom unique parmi tous les autre binding (portType+protocole+binding) Le type permet de spcifier le portType( classe) auquel on fait rfrence ?:binding permet de dterminer le protocole dinvocation utilis (soap:binding, http:binding) Style permet de prciser si le message( body de soap) contient des donnes ou un document xml Transport spcifie le protocole dinvocation. ?:action prcise le contenu de lentte du message dinvocation SOAP ?:body prcise la forme des messages parts prsents dans le corps du message SOAP. Use est utilis pour spcifier la forme des donnes, un namespace (encoded) ou des paramtres (literal)

47

Les technologies : WSDL - structure (6/8)

<binding name="GetStockQuoteBindingName" type="GetStockQuotePort "> <soap:binding style="rpc" transport=" http://schemas.xmlsoap.org/soap/http"/> <operation name="GetStockQuote"> <soap:operation soapAction="http://advocatemedia.com/GetStockQuote"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding>

48

Les technologies : WSDL - structure (7/8)

Service(name, port(name, binding,?:address(location)), documentation())

Permet de spcifier le nom, o se trouve la documentation concernant le service mais aussi o envoyer les messages dinvocation. Port spcifie ladresse (URI) laquelle un service peut tre invoqu. Llment binding permet dassocier le nom du port au binding du fichier wsdl. ?:address (soap:address, http:address) spcifie ladresse du service Documentation permet aux dveloppeurs dapporter plus de prcisions sur le service.

Des importations de fichiers XSD permettent limportation de types dj dfinis

<import namespace=uri location=uri)

49

Les technologies : WSDL - structure (8/8)

<service name="AdvocateMediaGetStockQuotes"> <documentation>Simple Web Service to Retrieve a stock quote</documentation> <port name="GetStockQuotePort" binding="myns:GetStockQuoteBindingName"> <soap:address location="http://advocatemedia.com/GetStockQuote"/> </port> </service>

50

Les technologies : WSDL - limites

Limitation de WSDL

Incapacit de dcrire des organisations complexes. Les web services sont des tches simples, il sera donc ncessaire de dfinir des enchanements plus ou moins complexes pour raliser des tches labores. Dautres standards ebXML, Business Process Specification Schema (BPSS), and Web Services Choreography Interface (WSCI).

51

Les technologies : UDDI

Universal Description, Discovery and Integration

Standard de l Organisation for the Advancement oF Structured Information Standard (avril 2003) UDDI permet aux fournisseurs de services de sinscrire et de rpertorier les services quils proposent. UDDI ne contient que des rfrences associes des services, et non les services eux-mmes Il peut tre public ou priv

Les annuaires publics sont hbergs par des socits comme IBM ou Microsoft. Les annuaires publics sont moins dvelopps que les annuaires privs parce quils ne sont pas suffisamment scuriss. Les annuaires privs peuvent tre hbergs par une socit quelconque sur un rseau priv ou sur internet.

52

Les technologies : UDDI - structure (1/9)

Lannuaire UDDI est compos de

Pages blanches Contiennent des informations sur lentreprise comme le nom de la socit, ladresse Pages jaunes Contiennent la description des services web, au format WSDL, dploys par lentreprise. Pages vertes Contiennent les informations techniques dtailles sur les services fournis (processus mtier, description de service.)

53

Les technologies : UDDI - structure (2/9)

UDDI

54

Les technologies : UDDI - structure (3/9)

BusinessEntity (pages blanches)

Dcrites sous la forme dun schma XML. Elles contiennent les lments relatifs lentreprise qui propose le service (nom, coordonnes, secteur dactivit, ladresse du site web)

55

<element name="businessEntity" type="uddi:businessEntity" /> <complexType name="businessEntity"> <sequence> <element ref="uddi:discoveryURLs" minOccurs="0" /> <element ref="uddi:name" maxOccurs="unbounded" /> <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" /> <element ref="uddi:contacts" minOccurs="0" /> <element ref="uddi:businessServices" minOccurs="0" /> <element ref="uddi:identifierBag" minOccurs="0" /> <element ref="uddi:categoryBag" minOccurs="0" /> </sequence> <attribute name="businessKey" type="uddi:businessKey" use="required" /> <attribute name="operator" type="string" use="optional" /> <attribute name="authorizedName" type="string" use="optional" /> </complexType>

Les technologies : UDDI - structure (4/9)

BusinessService (pages jaunes)

Dcrites aussi sous la forme dun schma XML Cest un ensemble de services proposs rpondant un besoin mtier spcifique Contiennent des informations relatives au mtier de lentreprise. Contiennent aussi la description des services web proposs par ce dernier (nom du service, description, code) Une entreprise peut avoir plusieurs mtiers et donc plusieurs businessService.

56

Les technologies : UDDI - structure (5/9)

exemple

<element name="businessService" type="uddi:businessService" /> <complexType name="businessService"> <sequence> <element ref="uddi:name" minOccurs="0" maxOccurs="unbounded" /> <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" /> <element ref="uddi:bindingTemplates" minOccurs="0" /> <element ref="uddi:categoryBag" minOccurs="0" /> </sequence> <attribute name="serviceKey" type="uddi:serviceKey" use="required" /> <attribute name="businessKey" type="uddi:businessKey" use="optional" /> </complexType>

57

Les technologies : UDDI - structure (6/9)

bindingTemplate (pages vertes)

Contiennent les informations techniques sur un service web. Contiennent aussi les rfrences aux tmodels (spcification des interfaces des services web)

<element name="bindingTemplate" type="uddi:bindingTemplate" /> <complexType name="bindingTemplate"> <sequence> <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" /> <choice> <element ref="uddi:accessPoint" /> <element ref="uddi:hostingRedirector" /> </choice> <element ref="uddi:tModelInstanceDetails" /> </sequence> <attribute name="serviceKey" type="uddi:serviceKey" use="optional" /> <attribute name="bindingKey" type="uddi:bindingKey" use="required" /> </complexType>

58

Les technologies : UDDI - structure (7/9)

Les tModels

Reprsents par un schma xml Ils contiennent des informations permettant de connatre les normes que respectent le service web, le format des messages, le protocole de transport Permet didentifier la catgorie laquelle appartient le service. Ces catgories sont ceux du :

North American Industry Classification System ( NAICS) Universal Standards Products and Services Classification (UNSPSC) ISO 3166, standards pour la localisation gographique

59

Les technologies : UDDI - structure (8/9) Exemple

<element name="tModel" type="uddi:tModel" /> <complexType name="tModel"> <sequence> <element ref="uddi:name" /> <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" /> <element ref="uddi:overviewDoc" minOccurs="0" /> <element ref="uddi:identifierBag" minOccurs="0" /> <element ref="uddi:categoryBag" minOccurs="0" /> </sequence> <attribute name="tModelKey" type="uddi:tModelKey" use="required" /> <attribute name="operator" type="string" use="optional" /> <attribute name="authorizedName" type="string" use="optional" /> </complexType>

60

Les technologies : UDDI - structure (9/9)

PublisherAssertion

Introduite dans la version 2.0 Reprsente un ensemble de rgles contractuelles dinvocation de services sous forme de protocoles entre deux partenaires mtier Pour quune assertion soit publie, les deux partenaires doivent publier les mmes informations.

<element name="publisherAssertion" type="uddi:publisherAssertion" /> <complexType name="publisherAssertion"> <sequence> <element ref="uddi:fromKey" /> <element ref="uddi:toKey" /> <element ref="uddi:keyedReference" /> </sequence> </complexType>

61

Les technologies : UDDI dcouverte

UDDI et la dcouverte de services

Les standards UDDI sont implments dans des API, permettant laccs et la manipulation Il existe deux types dAPI

API dinterrogation

Find_business, find_service, get_serviceDetail, get_tmodelDetails Save_business, save_tmodel, delete_business, delete_service

API de publication

La communication avec les registres UDDI se fait par des messages XML encapsuls dans des enveloppes SOAP.

62

Relation entre WSDL et UDDI (1/2)

Le wsdl contient deux parties

La description de linterface du service La description de limplmentation du service

La description de linterface dun service correspond aux informations techniques du service, cest en quelque sorte une classe abstraite qui sera utilise pour implmenter un ou plusieurs autres services. Elle regroupe

types, import, message, portType, binding

La description de limplmentation du service correspond aux informations relatives lendroit o est publi le service. Elle regroupe

Documentation, import, service, port

63

Relation entre WSDL et UDDI (2/2)

Linterface du service -> TModel Limplmentation du service -> Business Service

64

Architecture Oriente Service.

Service Client SAP Gestion Stock SI Oracle Gestion Des achats SI IBM Gestion Facturation SI WS Service Client WS Service Client WS Service Client

Quest ce qui empche de faire du point point ?

65

Principe dune Architecture Oriente Service

WS management SAP Gestion Stock SI Oracle Gestion Des achats SI IBM Gestion Facturation SI SOA Layer WS WS WS WS Discovery Quality of Service Service Level Agreement Failover Policy-based routing Loose coupling Service Client Service Client Service Client Service Client

Les Web Service ne dbouchent pas sur une architecture oriente service. Ils permettent leur dveloppement dune manire standardise.

66

Les briques dune Architecture Oriente Service

WS management

Gestion des versions, denregistrement, monitoring La publication de service ne suffit pas si personne ne sait quil est publi. Dlais de rponse, taux dchecs contrat sur le service offert Que se passe-t-il en cas de panne ? Politique dautorisation, niveau de cryptage, mthode de transport

WS Discovery

Quality of Service

Service Layer Agreement

Failover

Policy-Based Routing

67

Architecture distribue vs. Architecture Oriente Service

Architecture distribue Oriente fonctionnalit labore pour durer Processus de dveloppement long Centre sur la rduction des cots Organise au sein dune application Systme fortement coupl Orient objet Technologie homogne Architecture Oriente Service Oriente processus labore pour grer le changement Processus de dveloppement court Centre sur le support aux mtiers Permet lorchestration et la composition Faible couplage, agile Orient message Technologie htrogne

Limplmentation doit tre connue Limplmentation reste abstraite

68

La gouvernance des SOA : une autre logique

Les architectures orientes service impliquent une vision globale. Le service informatique est considr comme un support aux autres mtiers de lentreprise. Il est donc ncessaire de comprendre ces mtiers et leur fonctionnement. La mise en place dune telle architecture ncessite limplication de tous les services.

69

La gouvernance en quelques questions.

Les questions critiques :

Qui dfinit et modifie les services ? Qui peut y accder ? Quelle est la qualit que les services doivent offrir ? Qui paie pour ces services ? Qui est responsable de linfrastructure ? Qui gre les interdpendances entre les services ? Comment exposer les services aux entreprises partenaires ?

70

Le Service Oriented Computing

71

Service Oriented computing M. Papazoglou, P. Traverso

Partie III : Et dans la pratique alors !!!!!

72

Les plate-formes: .NET 1/3

.NET

Commercialis en 2000 par MicroSoft. Caractristiques

logiciels distribus et cooprants, les services Web XML. fournit des services intgrs, centrs sur lui, accessibles depuis tous ses priphriques, tout moment et en tout lieu. fond sur des standards de l'industrie (http, XML, SOAP, WSDL), un moyen simple pour normaliser la coopration des services logiciels entre eux (services Web XML), quelle que soit leur localisation, leur implmentation technique, qu'ils soient internes ou externes, existants ou inventer.

73

Les plate-formes: .NET 2/3

Les composants principaux :

Common Language Runtime (CLR) est un environnement d'excution scuris et robuste qui supporte du code crit dans diffrents langages (C++, VB, C#, Pascal, Cobol ...) et simplifie le dveloppement, la gestion et le dploiement d'applications. On peut le comparer la Java Virtual Machine (JVM) ou au Runtime Visual Basic 6 (msvbvm60.dll). Common Interface Layer (CIL): le code .NET est compil dans un langage de bas niveau appel Intermediate Language ou Microsoft Intermediate Language (MSIL) : ce code IL est ensuite compil dans du code natif au moment de l'excution. Ce qui signifie que quel que soit le langage utilis dans votre programme, vos excutables et DLL seront toujours dploys sous la forme de code IL ; il n'y a donc aucune diffrence entre un composant crit en C# et en VB .NET.

74

Les plate-formes: .NET 3/3

75

Les plate-formes : .NET OpenSource

MONO

Mono, cest du .NET OpenSource mais multi plate-formes (Linux, Windows, Solaris, FreeBSD, HP-UX and MacOSX). Version pure sans Passport, software-as-service Mono implmente que les standards et donc ne correspond pas a 100% a .NET Lobjectif est dlaborer des outils gratuits pour le dveloppement dapplications partir des spcifications du CLI

.GNU

76

Les plate-formes : JAVA

JAVA

Java Web Service Development Pack (JWSDP)

un ensemble d'outils et d'API qui permettent de faciliter le dveloppement des services web et des applications web avec Java. http://java.sun.com/webservices/. Soit utiliser lAPI fournie par Sun avec JWSDP, soit installer et configurer sparment Facilite le dveloppement et le dploiement de services Web en java. Il permet de gnrer automatiquement le fichier WSDL partir d'une classe java et le code ncessaire l'appel du service web.

Tomcat 5.0

Axis (Apache eXtensible Interaction System)

77

Implmentation simple - JWSDP

Contenu de JWSDP

Les API

Java XML Pack : Java API for XML Processing (JAXP), Java API for XML-based RPC (JAX-RPC), Java API for XML Messaging (JAXM), Java API for XML Registries (JAXR) Java Architecture for XML Binbing (JAXB) JavaServer Pages Standard Tag Library (JSTL) Java Secure Socket (JSSE) SOAP with Attachments API for Java (SAAJ) Apache Tomcat Java WSDP Registry Server (serveur UDDI) Web application development tool Apache Ant

Les Outils

78

Les UDDI

Microsoft

http://www.ibm.com/services/uddi/testregistry/ http://test.ud di.microsoft.com/. Projet du groupe Apache Implmentation java dun registre UDDI Ncessite un serveur dapplications de type Tomcat Permet lenregistrement de services dans une base de donnes.

IBM

JUDDI

79

Utilisation de JUDDI

Juddi permet de dfinir deux URL pour la publication de services et la recherche. Linteraction avec JUDDI partir de java se fait grce lAPI UDDI4J. Elle met disposition des mthodes pour lenregistrement et la recherche telles que

Find_business, find_service, get_serviceDetail, get_tmodelDetails Save_business, save_tmodel, delete_business, delete_service

Afin dexcuter lenregistrement ou la suppression de services, il est ncessaire de prciser le protocole dchange de messages.

Java -Dorg .uddi4j.TransportClassName=org.uddi4j.transport.ApacheAxisTransport

80

Utilisation de MONO

Afin de dployer un Web Service, il est ncessaire dannoter le code. Dfinir que la classe contient un web service, dire quel port il est disponible et donner ventuellement une description

[WebService(Namespace="http://195.83.83.72:8088/", Description="effectue la somme de deux nombres.")] [WebMethod (Description="Adds two numbers")]

Dfinir les mthodes qui sont accessibles

Le web service doit tre compil en un DLL et pas un excutable (option t:library)

81

Utilisation de MONO 2/2

Indiquer au serveur (XSP) par un fichier .asmx quun web service est disponible.

<%@ WebService Class="WSServ.webservice" %> Wsdl http://IP:Port/nomService.asmx

La gnration dun client se fait par la commande suivante

Le rsultat est un fichier Proxy.cs quil faut compiler comme un dll Le client dun web service doit tre compil avec le proxy

Mcs r:System.Web.Services client.cs Proxy.cs

82

Implmentation JAVA/AXIS 1/4

Axis

Permet trois mthodes de dploiement

JWS
Consiste renommer le fichier java (.java) en jws et le mettre dans le rpertoire webapps de Axis Linconvnient principal est quil est ncessaire davoir les fichiers sources, ce qui nest pas tout le temps le cas.

WSDD ( Web Service Deployment Descriptor)

Ncessite la compilation du code Ncessite la cration dun fichier .wsdd dcrivant les mthodes accessibles

Le dploiement partir de mta annotations

Les annotations ressemblent ceux utilises par .NET et MONO @WebService pour definir un weservice @WebMethod pour dfinir la methode exposer Compilation avec ant pour dployer le service comme un .war

83

Implmentation JWSDP/AXIS 2/4

Utilisation du WSDD

<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <service name="MyService" provider="java:RPC"> <parameter name="className" value="samples.userguide.example3.MyService"/> <parameter name="allowedMethods" value="*"/> </service> </deployment>

A partir du fichier, il est possible de dire Axis quun nouveau service est disponible avec la commande suivante java org.apache.axis.client.AdminClient -p NoPort MonServiceWebAxis2.wsdd Attention ne pas oublier le classpath avec les librairies Axis

84

Implmentation JWSDP/AXIS 3/4

Une fois le fichier wsdl gnr par Axis, il est ncessaire de crer les classes de liaison.

java org.apache.axis.wsdl.WSDL2Java http://localhost:8080/axis/services/monServiceWebAxis2?wsdl

Le rsultat contient quatre fichiers java

monServiceWebAxis2 monServiceWebAxis2Service monServiceWebAxis2ServiceLocator monServiceWebAxis2SOAPBindingStub

Les 3 premiers doivent tre inclus dans le client

85

Implmentation JWSDP/AXIS 4/4

Il est aussi possible d'invoquer le web service sans crer de classes de liaisons. Pour ce faire on utilise on crer une instance de org.apache.axis.client.Service Sur cet objet on va crer un nouvel appel de service en appelant la mthode createCall() On spcifie les paramtres savoir :
Le point d'accs Les paramtres ncessaire (s'il y en a) Le type de revoie (s'il y en a)

Il ne reste plus qu'a invoquer le service.

86

Axis2

Une nouvelle version d'axis est disponible : Axis2 Elle introduit une nouvelle faon de grer les messages AXIOM (AXIs Object Message) Le dploiement se fait par une archive .aar Cette archive est un fichier jar avec un fichier XML qui dcrit le dploiement du web service

87

Partie IV : Le futur des Web Services

88

Limites

Les web services ne traitent que la syntaxe et pas la smantique. Lutilisation dXML permet de structurer et spcifier les tapes dans la construction dun document. Ils ne permettent pas de spcifier le sens donner au document. Les web service ne sont quun mcanisme de transfert de donnes/ dinformations dun systme lautre. Les web services napportent, en aucun cas, plus de valeurs linformation dj possde. Il permettent juste une meilleure diffusion auprs des clients et des fournisseurs. Il est difficile de composer des services complexes avec dautres services existants.

89

Limites

Scurit et confiance, la prsence dun fournisseur dans les pages jaunes nest pas forcment une garantie de qualit, dhonntet. La consommation automatique de services pour des fonctions critiques peut tre nfaste pour lentreprise Les web services ne remplacent pas les dmarches commerciales effectues auprs des partenaires de la socit. La dcouverte et la consommation dune relation commerciale de faon automatique sapparente la science fiction. Les avantages comptitifs des web services sont indniables, sil existe une vritable problmatique dintgration dapplications ou dintgration verticale. Mais il ne sert rien de partager des informations dont personne ne veut.

90

volution - ESB

Enterprise Service Bus

Bas sur les web services SOAP/HTTP, WSDL, UDDI. Garantie de livraison : HTTPR, WS-Reliability, ebXML Messaging Service Interface graphique : WSUI, WSIA, WSRP Cryptage : XML Encryption, WS Security Signature : XML digital Signature, WS Security Liste de contrle d'accs : XACML Transactionnel : BTP, XAML, WS-Transaction, WS-Coordination Gestion de cls publiques/prives : XKMS (XKISS, XKRSS) Reprsentation de processus : BPEL, BPML, XLANG, WSFL, WSCI, WS Choregraphy Dialectes XML de processus mtiers : RosettaNet, etc

Mais aussi

91

volution - ESB

92

Web services et Agents

Points communs

Registre (MiddleAgent) / UDDI Invocation ACL/SOAP Coopratifs Standardis / Pas de normes Invocation /Autonomie Simplet / Intelligent Tches Simples / Tches Complexes Adresse Fixe / Mobile

Divergences

93

Liens

http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm http://www.w3schools.com/ http://ws.apache.org/axis/ http://ws.apache.org/axis2/ http://beehive.apache.org/docs/1.0m1/wsm/tutorial_wsm.html http://today.java.net/pub/a/today/2005/05/10/axiom.html http://java.sun.com/webservices/jwsdp/index.jsp http://go-mono.org Building Web Wervices with JAVA, making sense of XML, SOAP, WSDL and UDDI, S.Graham, D.Davis XML and Web Services Unleashed, R.Schmelzer, T. Vandersypen Les Web Services, H.Kadima, V. Monfort Next Generation Application Integration, D.S. Linthicum

94