Organisation Web services: état de l art et perspectives de recherche. Plan. Contexte. 3 séances. Objectif. Pour me contacter.

Transcription

1 Organisation Web services: état de l art et perspectives de recherche Master Informatique, SDR 10/2005 Olivier Perrin LORIA 3 séances séance 1: services Web, motivations et concepts séance 2: standards séance 3: recherche Objectif connaître les standards, avoir une idée des recherches actuelles (et futures) Pour me contacter Olivier.Perrin@loria.fr Plan Contexte Contexte World Wide Web Services Web Projet ENQUIRE, 1990 Standards Recherche Conclusion Tim Berners-Lee Concepts Hypertexte Universal Document Identifier Premier navigateur, et serveur Web httpd

2 Contexte (2) Le Web actuellement assez éloigné de l outil hypertexte des débuts grande masse d informations encore plus grand dans ses entrailles outils de collaboration à travers le Web applications intranet, indépendance vis-à-vis de la plateforme killer apps: Knowledge Management, EAI, ecommerce Contexte (3) Statique 500 millions d utilisateurs plus de 3 milliards de pages WWW URI, HTTP, HTML Le futur Le futur (2)! Le Web est un grand succès quantité d informations disponible la croissance du nombre d utilisateurs De plus en plus présent dans notre vie de tous les jours La clé? la simplicité HTML et HTTP sont simples et permettent de diffuser facilement de l information Mais cette simplicité devient un frein pour les nouveaux développements Actuellement, ce que nous connaissons du Web est la version 1 La prochaine version sera encore plus étendue et puissante

3 Le Web sémantique Le Web sémantique (2) Statique Problèmes pour:!la recherche d informations!l extraction d informations!la représentation des informations!l interprétation des informations la gestion des informations WWW URI, HTTP, HTML Web sémantique XSD, RDF, OWL La vision de T. Berners-Lee: les informations ont une sémantique qui peut être appréhendée par la machine une multitude de services capables de raisonner offrent la possibilité d atteindre un résultat de manière automatique Notion d ontologie spécification consensuelle et formelle de concepts fournit un sens commun et partagé d un domaine (humains et applications) concepts et leurs relations Services Web Services Web (2) Dynamique Services Web SOAP, WSDL, UDDI Se servir de la machine pour calculer et exécuter Permettent de connecter des machines au dessus d Internet et d échanger des données et de les combiner Concepts: dynamicité, couplage faible, réutilisation de composants Statique WWW URI, HTTP, HTML Web sémantique XSD, RDF, OWL Notion de flux de services vs. applications (telles que nous les connaissons)

4 Services Web (3) Services Web sémantiques Effort pour construire une plateforme distribuée pour le Web Tâches à prendre en compte pour rendre les services exécutables par les machines découverte: comment trouver un service? composition: comment combiner des services? exécution: comment exécuter un service? surveillance: comment vérifier l exécution? Dynamique Statique Services Web SOAP, WSDL, UDDI WWW URI, HTTP, HTML l objectif ultime! Services Web sémantiques Web sémantique XSD, RDF, OWL Services Web sémantiques (2) Services Web sémantiques (3) SOAP, WSDL, UDDI sont des pièces importantes Mais, couches basses de la pile L objectif est de permettre de manière automatique la découverte, la sélection, la médiation, la composition Pour obtenir des services complexes Combinaison des technologies services Web et du Web sémantique Automatisation pour le passage à l échelle découverte composition invocation Objectifs visés: réaliste, maturité Pré-requis indispensables pour les applications visées

5 Services Web sémantiques (4) Un support (le plus) automatisé (possible) pour trouver et comparer sémantique analysable par une machine Un support (le plus) automatisé (possible) pour gérer de nombreux formats hétérogènes ontologies pour standardiser et transformer Un support (le plus) automatisé (possible) pour gérer les nombreuses logiques métiers médiation pour compenser les différences et coopérer efficacement Services Web sémantiques (5) Selfdesc. doc. Fusionner la dimension Web sémantique et la dimension services Web Data Unicode Data Rules Logic Ontology vocabulary RDF + rdfschema XML + NS + xmlschema Proof URI Trust Digital signature UDDI Registry Service Consumer Demande le service Pointeur vers la description Pointeur vers le service SOAP Communication à base de messages SOAP WSDL Web Service Décrit le service Applications visées KM Knowledge Management Enterprise Application Integration ecommerce Gestion des informations et de la connaissance Actuellement le travail concerne l information et la connaissance la compétition entre les entreprises se base sur ces points la complexité nécessite beaucoup d informations le remplacement du savoir informel par des méthodes plus automatiques le turn-over oblige à compenser la perte des connaissances

6 KM (2) Deux aspects gestion de l information sous cet angle, possibilité qu un ordinateur gère l information et la connaissance sur cette information plus intégration des différentes sources d informations gestion des personnes EAI Intégration de systèmes Process Integration Application Integration Information Integration Process & workflow modeling business logic Rule-based transaction, routing, application adapters, messaging Federation, extraction, metadata, data management EAI (2) ecommerce Vue unifiée de toutes les données Gestion des méta-données Analyse fine des données Stockage Infrastructure Transformation entre les modèles de données C est de l EAI avec des entreprises concurrentes B2C B2B Problèmes identiques hétérogénéité des produits, documents, catalogues hétérogénéité des infrastructures intégration données + outils Standardisation Web sémantique + technologies services Web

7 Plan Services Web Contexte Motivation Services Web Concepts Standards Origines Recherche Technologies Conclusion Standards Exemples Le Web aujourd hui La suite Conçu pour les interactions entre humains et applications partage d information commerce B2C interactions B2B manuelles Faiblesses construit sur deux standards principaux: HTTP, HTML modèle d interaction simple: nécessité d avoir une intervention humaine pratiquement tout le temps Ubiquité Applications visées B2B automatique Business Process Integration Resource sharing Approches actuelles: ad-hoc formulaires HTML Objectif: permettre des interactions entre les applications sur le Web de manière systématique et standardisée

8 Les services Web Les services Web doivent permettre de construire une plateforme distribuée pour le Web Mais, ce n est pas nouveau! CORBA RMI.NET Besoins Objectifs interopérabilité adoption rapide, ubiquité liaison dynamique à l échelle d Internet (SOA) support d environnements ouverts (Web) et plus restreints (entreprise) Besoins standards infrastructure raisonnable intégration «simple» des applications orientation messages et documents vs API Définition À quoi cela sert? Définitions Loosely coupled, reusable software components that encapsulate discrete functionality and are distributed and programmatically accessible over standard Internet protocols, The Stencil Group Web service applications are encapsulated, loosely coupled Web components that can bind dynamically to each other, F. Curbera Web Services are a new breed of application. They are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web Services perform functions, which can be anything from simple request to complicated business processes, The IBM Web Services tutorial Points communs composants qui fournissent une fonctionnalité, distribués, accessibles sur le Web WS vus comme une technologie permettant des interactions de machine à machine au-dessus des applications, des entreprises, dans les limites du Web Les applications sont (dans l idéal) des assemblages de services sélectionnés Vus comme des RPC au-dessus du Web Opérations sans états Les flux de contrôles et de données sont définis séparément

9 Origines IPC: Inter Process Communication communication entre processus pour transférer de l information pour éxécuter une action dans un processus distant RPC: Remote Procedure Call représentation IPC à un niveau supérieur métaphore de l appel de procédure (cf langages) appel d une procédure dans un autre processus Appel de procédure Mécanisme des langages impératifs Défini par une interface qui spécifie: le type des résultats retournés le nom de l opération les paramètres de l opération ex: string traduire (string msg, integer langue) Un niveau d abstraction doit cacher la communication au programmeur Le langage de définition d interface doit être commun et indépendant du langage de programmation Difficultés Difficultés (2) Transparence Hétérogénéité Concurrence Liaison Transparence cacher au programmeur si l appel est local ou distant, et sur quelle machine Hétérogénéité RPCs entre processus sur des machines différentes OS différents, représentations des données différentes, langages différents,

10 Difficultés (3) Concurrence un RPC possède deux thread l appelant l appelé durant le RPC, le thread appelant peut être bloqué (synchrone) continué son exécution (asynchrone) Liaison appel local: adresse de la procédure en distant: localisation, nom, contexte? cf. objets distribués Services Web Il sont décrits grâce à des fichiers WSDL (Web Service Definition Language) stockés dans un répertoire UDDI (Universal Description, Discovery, and Integration) et ils communiquent grâce au protocole SOAP (plus d acronyme) Architecture Technologies Fiabilité des messages WSBPEL, WSCI, BPML SOAP XML, encodages Sécurité: WS-Security, WS-Policy WSDL, OWL-S Statique et manuel Transport: HTTP, SMTP, Jabber Transactions Coordination Autres protocoles Procédés Qualité de service Description Messages Transport Web: URIs, HTTP, HTML URIs permettent de définir des identificateurs pour les ressources sur le Web HTML permet de définir le contenu HTTP permet de définir le protocole pour accéder à une ressource Services Web: infrastructure identique basée sur UDDI, WSDL, SOAP UDDI WSDL SOAP URI (DNS) HTML HTTP

11 Technologies (2) Technologies (3) Standards pour les différents niveaux Demande le service UDDI Registry Pointeur vers la description Pointeur vers le service WSDL Décrit le service transport: protocole commun message: syntaxe des messages commune description: description des interfaces commune publication/découverte: répertoire commun pour trouver les services Service appelant SOAP Communication à base de messages SOAP Web Service description des procédés: standards communs pour définir les protocoles d interaction, les flots de contrôle et de données futur: sécurité, confiance (trust) Standards Standards (2) Transport HTTP: HyperText Transfer Protocol SMTP: Simple Mail Transfer Protocol FTP: File Transfer Protocol Message idée: utiliser un format basé sur XML au-dessus de HTTP SOAP Description WSDL un document WSDL définit des services comme une collection de ports (network endpoints) pas d information sur ce que fait le service, ni comment il le fait Types Message Port type Operation Binding Service Port Interface endpoint

12 Standards (3) Découverte UDDI est un répertoire et une API pour localiser et rechercher des services classification des services en fonction de taxonomies Exemple conceptuel Fonctionnement Recherche manuelle Invocation Service appelant 2. Get HTTP 3. Fichier WSDL 4. Requête SOAP 5. Réponse SOAP Répertoire UDDI Description WS 1. Liaison WS publié Web service Acheter un livre Exemples réels Répertoire UDDI Google Services de vente de livre 2. Get HTTP 3. Fichiers WSDL Info. vendeur Vente livre Amazon.com Xmethods 1. Liaison Invocation Service appelant 4. Requête SOAP 5. Réponse SOAP Vente livre Info. vendeur Amazon.com

13 Amazon.com Google XMethods Plan Contexte Services Web Standards Recherche Conclusion

14 Services Web Différentes vues possibles Les WS vus comme une architecture les WS permettent de relier des machines en utilisant Internet pour échanger des données et les combiner composants dynamiques, faiblement couplés, réutilisables déploiement/diffusion simplifiés Services Web (2) Les WS vus comme un concept pour le travail coopératif sur le Web les services sont décentralisés et distribués sur Internet accessibles par une grande diversité de périphériques Internet devient une plateforme globale permettant à des personnes et/ou des organisations de réaliser des activités communes, de manière dynamique Services Web (3) Services Web (4) Les WS vus comme une technologie de programmation les WS sont des RPC au-dessus d Internet architecture distribuée classique (RPC, CORBA, RMI, DCOM) problèmes liens codés en dur firewall interopérabilité! Java C++ Perl Python IDL ORB IIOP TCP IP Les WS vus comme une technologie de programmation (suite) architecture WS: SOAP, WSDL, UDDI Java C++ Perl Python WSDL SOAP requêtes HTTP Serveur Web/application publication/ découverte invocation UDDI

15 Les standards état de l art SOAP spécification pour les échanges de messages sous la forme de documents XML définit comment utiliser HTTP comme protocole de communication WSDL définit l interface du service, les protocoles d accès, et la collection de ports un port est défini comme l association d une adresse réseau et d un binding (protocole et format de messages) Les standards état de l art (2) UDDI mécanisme permettant au client de rechercher des services Web peut-être vu comme un DNS pour les services Web équivalent au trader de CORBA SOAP SOAP WSBPEL, WSCI, BPML Procédés SOAP est un protocole basé sur XML qui permet aux applications d échanger des messages Fiabilité des messages Sécurité: WS-Security, WS-Policy Transactions Coordination Qualité de service Protocole pour accéder à un service Web Protocole one-way et asynchrone Recommandation du W3C WSDL, OWL-S Description version 1.2, Juin 2003 SOAP XML, encodages Autres protocoles Messages Transport: HTTP, SMTP, Jabber Transport

16 Concepts de base Un message SOAP est un document XML qui contient les éléments suivants: un élément enveloppe (obligatoire) qui identifie le document XML comme étant un message SOAP qui définit le début et la fin du message un élément header (optionnel) qui contient des attributs du messages point intermédiaire ou final Concepts de base (2) suite un élément body (obligatoire) qui contient toutes les informations de l appel et de la réponse données XML un élément fault (optionnel) qui fournit les informations à propos des erreurs survenues lors du traitement du message Concepts de base (3) Exemple de message Tous les éléments sont déclarés dans l espace de nommage pour l enveloppe SOAP et les encodages et données dans Voyage Enveloppe SOAP Header SOAP Bloc Header: réservation Bloc Header: passager Body SOAP Bloc sous-élément: itinéraire Bloc sous-élément: hôtel

17 SOAP Envelope Le message en entier est contenu dans l élément Envelope L enveloppe ne contient qu un seul élément Body qui est obligatoire L élément Body peut contenir autant de nœuds enfants que nécessaire Le contenu de l élément Body forme le message Si une enveloppe contient un élément Header (un seul, optionnel), ce doit être le premier fils de l élément Envelope SOAP Envelope (2) Les contenus du Header et du Body dépendent de l application encodingstyle permet d indiquer comment les données vont être sérialisées/désérialisées SOAP Header SOAP Header (2) Chaque élément du Header est appelé un bloc contient généralement des informations pour traiter le message les informations peuvent être destinées à des intermédiaires l attribut role next: le bloc doit être traité par l intermédiaire suivant none: pas de traitement du bloc ultimatereceiver: le bloc doit être traité par le dernier receveur du message chaque intermédiaire (application réceptrice) doit vérifier qu il peut jouer un rôle. Si c est le cas, il supprime le bloc, sinon, il le passe au suivant l attribut mustunderstand spécifie que l application doit comprendre ce que le bloc signifie (sinon, erreur) <?xml version="1.0"?> <env:envelope xmlns:env=" env:encodingstyle=" <env:header> <m:reservation xmlns:m=" env:role=" env:mustunderstand="true"> <m:reference>uuid:093a2da1-q r-ba5d-pqff98fe8j7d</reference> <m:dateandtime> t13:20: :00</m:dateandtime> </m:reservation> <n:passenger xmlns:n=" env:role=" env:mustunderstand="true"> <n:name>john Q. Public</n:name> </n:passenger> </env:header>... </env:envelope>

18 SOAP Body Le Body est supposé être traité par le dernier service récepteur Hypothèse implicite: le récepteur comprend le message La spécification ne dit rien sur les éléments du Body d un message SOAP Body (2) <env:body> <p:itinerary xmlns:p=" <p:departure> <p:departing>new York</p:departing> <p:arriving>los Angeles</p:arriving> <p:departuredate> </p:departuredate> <p:departuretime>late afternoon</p:departuretime> <p:seatpreference>aisle</p:seatpreference> </p:departure> <p:return> <p:departing>los Angeles</p:departing> <p:arriving>new York</p:arriving> <p:departuredate> </p:departuredate> <p:departuretime>mid morning</p:departuretime> <p:seatpreference/> </p:return> </p:itinerary> <q:lodging xmlns:q=" <q:preference>none</q:preference> </q:lodging> </env:body> SOAP Fault SOAP Fault (2) Toutes les erreurs doivent apparaître dans un élément Fault unique dans le Body Il contient les sous-éléments suivants Code: le code permettant d identifier Reason: explication de l erreur Node: l élément à l origine de la faute Role: qui est à l origine de la faute Detail: information spécifique sur l erreur pour l application Le schéma soap-envelope définit: VersionMismatch MustUnderstand DataEncodingUnknown Sender Receiver

19 SOAP Fault (3) <?xml version="1.0"?> <env:envelope xmlns:env=" xmlns:rpc=" <env:body> <env:fault> <env:code> <env:value>env:sender</env:value> <env:subcode> <env:value>rpc:badarguments</env:value> </env:subcode> </env:code> <env:reason> <env:text xml:lang="en-us">processing error</env:text> </env:reason> <env:detail> <e:myfaultdetails xmlns:e=" <e:message>name does not match card number</e:message> <e:errorcode>999</e:errorcode> </e:myfaultdetails> </env:detail> </env:fault> </env:body> </env:envelope> Sérialisation SOAP La spécification SOAP fournit une méthode pour sérialiser les données Pour envoyer du XML, on l envoie tel quel Une valeur représente soit une donnée unique, soit une composition Un accesseur représente un élément qui donne accès à la valeur <nom>toto</nom> nom est l accesseur, Toto la valeur Sérialisation SOAP (2) Que pensez-vous de: Sérialisation SOAP (3) Avec du typage <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body>! <m:unemethode xmlns:m=" <param1>ou812</param1>!! <param2>2005</param2>!! <param3> </param3>! </m:unemethode> </soap:body> </soap:envelope> <soap:envelope xmlns:soap=" soap:encodingstyle=" xmlns:xsi=" xmlns:xsd=" <soap:body>! <m:unemethode xmlns:m=" <param1 xsi:type="xsd:string">ou812</param1>!! <param2 xsi:type="xsd:integer">2005</param2>!! <param3 xsi:type="xsd:double"> </param3>! </m:unemethode> </soap:body> </soap:envelope>

20 Sérialisation SOAP (4) Sérialisation SOAP (5) Typage: 3 méthodes xsi:type référence vers un schéma XML qui définit le type de données référence vers un document qui contient une définition du type de données xsi:type <s:envelope xmlns:s=" xmlns:xsi=" xmlns:xsd=" <s:body> <ns1:affiche> <param xsi:type="xsd:string">hello</param> </ns1:affiche> </s:body> </s:envelope> Référence vers un schéma XML <s:envelope xmlns:s=" xmlns:xsi=" xmlns:xsd=" <s:body> <ns1:affiche xmlns="monschema.xsd"> <param>hello</param> </ns1:affiche> </s:body> </s:envelope> Référence vers un document <s:envelope xmlns:s=" <s:body> <ns1:affiche xmlns="urn:un_namespace"> <param>hello</param> </ns1:affiche> </s:body> </s:envelope> Sérialisation SOAP (6) Encodage types simples énumération structures et tableaux structures tableaux tableaux multi-dimensionnels tableaux creux références Synthèse SOAP Un message SOAP doit être encodé en XML Un message SOAP doit utiliser le namespace Envelope de la spécification Un message SOAP doit utiliser le namespace Encoding de la spécification Un message SOAP ne doit pas contenir de DTD Un message SOAP contient: un élément Envelope (obligatoire) un élément Header (optionnel) un élément Body (obligatoire) un élément Fault (optionnel)

21 Synthèse SOAP (2) Problèmes SOAP est devenu plus un protocole de bas niveau pour implanter les files de messages plutôt qu un protocole d accès à un service pas de fiabilité pas de sécurité pas de transactions SOAP et les types de données complexes (images, documents, ) attachements (comme avec SMTP), mais MIME n est pas la panacée WS-Attachements WSDL Fiabilité des messages WSBPEL, WSCI, BPML SOAP XML, encodages Sécurité: WS-Security, WS-Policy WSDL, OWL-S Transport: HTTP, SMTP, Jabber Transactions Coordination Autres protocoles Procédés Qualité de service Description Messages Transport WSDL WSDL (2) Web Service Description Language WSDL est un langage basé sur XML pour décrire les interfaces des services Web et comment accéder à ces services La description comprend quelles sont les opérations fournies par le service quels sont les paramètres nécessaires quels sont les valeurs retournées quel est le protocole de communication ou de transport supporté par le service Un document WSDL définit les services comme une collection de ports (endpoints) Rappels WSDL ne dit rien sur ce que le service Web peut faire WSDL ne dit rien sur comment le service Web le fait Types Message Port type Operation Binding Service Port Interface endpoint

22 WSDL: ports et services WSDL: ports et services (2) Ports les ports sont utilisés pour exposer un ensemble d opérations (ou port types) les opérations peuvent être regroupées pour un ou plusieurs bindings Services un service englobe une ou plusieurs opérations il inclut des ports <service>! <port>! <port>! <port> fournit implante <binding>! SOAP <binding>! CORBA <binding>!.net formats & protocoles comment invoquer une opération comment encoder un message supporte <porttype>! <operation>! <operation>! <operation> input output <message> Request <message> Response WSDL: un fichier de base WSDL: types de données <definitions>! <types>!! définition des types - XML schema types! </types>! <message>!! définition d un message! </message>! <porttype>!! définition d un ensemble d opérations! </porttype>! <binding>!! définition des protocoles de communication! </binding>! <service>!! une liste de ports (individual endpoint) et de bindings! </service> </definitions> Types simples XSD Nouveaux types en utilisant la syntaxe XML schema <types>! <schema...>!! <complextype name= "Commande">!!! <element name="produit" type="xsd:string"/>!!! <element name="prix" type="xsd:integer"/>!! </complextype>!!...! </schema> </types>

23 WSDL: messages Les types de données sont utilisés dans les messages Les messages peuvent être envoyés et reçus par le service Web Un message possède une ou plusieurs parties <message name= RequeteCommande >! <part name= CommandeNoel type= xsd1:commande > </message> WSDL: port types Un port type est un groupe d opérations C est l élément le plus important dans une description WSDL Il définit le service, en terme d opérations qui peuvent être exécutées, et de messages impliqués Peut être vu comme une classe en Java par exemple WSDL: types d opérations WSDL: one-way Une opération est un ensemble de messages qui sont échangés pour réaliser le service Il existe 4 types d opérations: One-way: un message est reçu par le service, et aucune réponse n est générée Request-Response: un message est reçu par le service, et ce dernier produit une réponse Solicit-Response: le service envoie un message, et reçoit une réponse Notification: le service envoie un message, et ne reçoit pas de réponse <message name="newtermvalue">! <part name="term" type="xsd:string"/>! <part name="value" type="xsd:string"/> </message> <porttype name="glossaryterms">!! <operation name="setterm">!!! <input name="newterm" message="newtermvalue"/>!! </operation> </porttype>

24 WSDL: request-response WSDL: exemple port types <message name="gettermrequest">! <part name="term" type="xsd:string"/> </message> <message name="gettermresponse">! <part name="value" type="xsd:string"/> </message> <porttype name= CommandePortType >! <operation name= GestionCommande >!! <input message= Commande name= MaCommande >!! <output message= ResultatCommande!!! name= ResultatMaCommande >! </operation> <porttype name="glossaryterms">! <operation name="getterm">!! <input message="gettermrequest"/>!! <output message="gettermresponse"/>! </operation> </porttype>! <operation name= AnnulationCommande >!! <input message= AnnulationCommande!!! name= AnnulationMaCommande >!! <output message= ResultatAnnulationCommande!!! name= ResultatAnnulationMaCommande >! </operation> </porttype! > WSDL: bindings WSDL: bindings (2) Les types, messages et port types décrivent ce que fait un service en terme de messages échangés L élément binding décrit le format des messages et le protocole pour interagir avec le service Pour un binding avec SOAP, on dispose de deux attributs style: document style ou RPC style transport: HTTP Document on envoie un message qui contient les données, et uniquement les données (pas de méthodes) le service sait comment traiter les données, et il répond avec un autre message et ainsi de suite c est du transfert d informations RPC on envoie le nom de la méthode, les paramètres et les types de retour

25 WSDL: bindings (3) Protocoles HTTP: le plus courant traverse bien les firewalls sur le port 80 SMTP les messages peuvent être le texte du mail, ou en attachement WSDL: bindings (4) <binding name="stockquotesoapbinding" type="tns:stockquoteporttype"> <soap:binding!!!! style="rpc"!!!! transport=" <operation name="gettradeprices">!! <soap:operation soapaction=" <input>!!!! <soap:body use="encoded"!!!!! namespace=" encodingstyle=" </input>!!! <output>!!!! <soap:body use="encoded"!!!!! namespace=" encodingstyle=" </output>! </operation> </binding> WSDL: exemple complet <?xml version="1.0"?>! <definitions name="getsolde"!! targetnamespace=" xmlns:tns=" xmlns:xsd=" xmlns:xsd1=" xmlns:soap=" xmlns:soapenc=" xmlns=" <message name="getsoldeentree">!! <part name="numcartecredit" type="xsd:string"/>! </message>! <message name="getsolderesultat">!! <part name="resultat" type="xsd:string"/>! </message>! <porttype name="getsoldeporttype">!! <operation name="getsoldeactuel"!!!!! parameterorder="numcartecredit">!!! <input message="tns:getsoldeentree"/>!!! <output message="tns:getsolderesultat"/>!! </operation>! </porttype> WSDL: exemple complet (2) <binding name="getsoldesoapbinding" type="tns:getsoldeporttype"> <soap:binding style="rpc"!! transport=" <operation name="getsoldeactuel">! <soap:operation soapaction=" <input>!!! <soap:body use="encoded"!!! namespace=" encodingstyle=" </input>!! <output>!!! <soap:body use="encoded"!!! namespace=" encodingstyle=" </output>! </operation> </binding> <service name="getsoldeservice">! <documentation>service banquedefrance.fr.</documentation>! <port name="getsoldeport" binding="tns:getsoldesoapbinding">! <soap:address location=" </port> </service> </definitions>

26 Synhtèse WSDL WSDL décrit uniquement la façon d accèder à un service WSDL ne prend pas en compte la structure des conversations (i.e. le protocole au niveau métier) UDDI Universal Description, Discovery, and Integration C est un registre Pour publier et rechercher des services UDDI utilise les standards du W3C XML, HTTP, DNS Il utilise WSDL pour décrire les interfaces des services Ce que permet UDDI Ce qu offre UDDI Services rendus par UDDI trouver le bon service parmi ceux disponibles définir comment interagir avec le service décrire les services et les procédés de manière semiautomatique bénéficier d un environnement ouvert, sécurisé, et unique Un modèle de données pour décrire les services dans un registre informations sur l organisation (business entity) services offerts par cette organisation informations techniques sur ces services APIs pour accéder/interroger le registre ensemble de messages SOAP pour interroger le registre Remarque: sous sa forme actuelle, plutôt orienté vers recherche manuelle que automatique

27 UDDI: le modèle de données UDDI: businessentity 5 types de données businessentity l entité qui a enregistré les informations businessservice nom et description du service publié bindingtemplate informations sur le service (adresse pour accéder au service) tmodel informations sur la spécification du service (pour rechercher) publisherassertion une relation entre plusieurs businessentity (sous-traitant, ) UDDI: businessservice UDDI: bindingtemplates

28 UDDI: tmodel UDDI: API Se résume essentiellement à une recherche basée sur des mots-clés find_binding find_business find_relatedbusinesses find_service find_tmodel get_bindingdetail get_businessdetail get_operationalinfo Synthèse UDDI WSBPEL Pas forcément très convaincant, mais on n a pas mieux pour l instant WSBPEL, WSCI, BPML Procédés Futur orientation sémantique taxonomies/ontologies Fiabilité des messages Sécurité: WS-Security, WS-Policy Transactions Coordination Qualité de service recherche sémantique vs. syntaxique WSDL, OWL-S Description intégration des politiques de sécurité/autorisations SOAP XML, encodages Autres protocoles Messages Transport: HTTP, SMTP, Jabber Transport

29 WSBPEL Web Services Business Process Execution Language Motivations intégration, ce n est pas simplement des invocations de messages interactions complexes pour spécifier des procédés besoin de définir le comportement en cas d échec WSBPEL construit au-dessus de WSDL langage de définition de procédés basé sur XML Besoins pour l intégration de procédés Interactions synchrones et asynchrones Transformation de données Logique du procédé Notion de transaction (compensation, ) WSBPEL WSBPEL (2) Spécification d un workflow qui modélise le comportement des services Web dans le contexte d un procédé Langage basé sur XML pour décrire le flot de contrôle Permet de définir comment envoyer des messages aux services réceptionner les messages, événements, exceptions manipuler les données (flot de données) définir le flot de contrôle (séquence, parallèle, choix, ) annuler des fragments du procédés en cas d exception Interpétable et exécutable par un moteur d orchestration contrôlé par un des participants Deux possibilités pour modéliser à un niveau abstrait (Abstract processes) au niveau exécution (Executable processes)

30 Comportement et procédés Publique/privé Comportement échange de séquence d événements envoi d une commance réception de la commande définition du comportement visible d un partenaire procédé publique définition des erreurs Procédés logique (gestion des événements) )*+&##',-&+".$*%'/0%1"01&'2*)' invocation d autres procédés +&#'7!(,/8359 états, données, définition du procédé interne!"#$%&'(('&$)*&$+,-.&/0/1%$23,$4*%/. +$2*$.**&+/1'2,$7,0$-,&8/.,-$/1$'$9&*.,--$)4*7 Procédés publiques et privés Publique visible et observable à l extérieur Privé visible en interne =%-/>?%"79%@?ABC%D<0E=F<D%F"7#G"#$4 79%$I$3G8$9%.J%"7%<03K$480"82<7%$7#27$ Processes 8K%$I$3G8".F$%!0<3$44$4%"79%.G427$44%!0<8<3<F4 Abstract processes M <0%."423%" $4 -$. /$0123$ /$WG$782"F%>F<D = ne montre pas les détails internes 0$!FJ données concernant le protocole /8$!%* %0<F$4 / 79 valeurs non confidentielles P"0"FF$F%>F<D 0$3$21$ %H;4%8< masque les aspects /8$! privés/8$! /8$! -$. &A &O &R 4248$73$ /$0123$ Executable processes 0$!FJ 27# 5I3$!82<7 T0"74"382<74 4%4G!!<08 # composition d autres services OP5?+-/%P0<3$44%>F<D comportement, basé sur les messages échangés, 0$3$21$ visible par les différents /8$!%Q partenaires (publique) 271<E$ -/;? U<F$4%"79 P$04248"73$%"79 -$. S"79F27#%"79 comportement du partenaire pour l interaction (privé) P"087$04 V"02".F$4 271<E$ /$0123$ structures de contrôle: séquence, choix, -$.%/$0123$4%56$0#27#%/8"79"094 -/;? 271<E$ -$. /$0123$ -$. /$0123$!"#$%&' Concepts process une description BPEL modélise un procédé partners dans un procédé, tous les services externes utilisés variables pour stocker les résultats, et les rediriger (flot de données) correlation sets pour relier un ensemble d opérations à une instance particulière d un service (interactions asynchrones, état de l interaction, corrélation des messages)

31 Concepts (2) activities le workflow est modélisé comme un ensemble structuré d activités (flot de contrôle) fault handlers, compensation handlers gestion des erreurs, transactions partnerlinktype extension de WSDL définit le rôle que joue un service dans un process partnerlinktype Extension de WSDL... <porttype name="purchaseorderpt">! <operation name="sendpurchaseorder">!! <input message="pos:pomessage"/>!! <output message="pos:invmessage"/>!! <fault name="cannotcompleteorder"!!!!!! message="pos:orderfaulttype"/>! </operation> </wsdl:porttype>... Un service qui fournit le porttype pos:purchaseorderpt (WSDL) peut jouer le rôle purchaseservice <partnerlinktype name="purchasinglt"! xmlns:plnk=" <plnk:role name="purchaseservice">!! <plnk:porttypename="pos:purchaseorderpt"/>! </plnk:role> </plnk:partnerlinktype> Concepts (3) Process link décrit une conversation entre deux rôles plusieurs messages peuvent être échangés dans une conversation partner: un service Web avec un rôle donné La liaison peut être dynamique théorie pour l instant, pas clair nécessite WS-Adressing <partnerlinks> définit les différents partenaires qui interagissent dans le procédé <variables> les variables utilisées par le procédé <faulthandlers> les activités à exécuter lorsqu il y a une erreur le reste c est le flot de contrôle du procédé

32 Définition des procédés Activités primitives <invoke>: une opération d un service Web <receive>: attend une invocation <reply>: réponse <wait>: un délai <assign>: calcule et copie dans une variable <throw>: une exception <terminate>: arrête l instance du service <empty>: no-op Définition des procédés (2) Constructeurs pour le flot de contrôle <flow>: une ou plusieurs activités concurrentes <sequence>: une séquence d activités <switch>: conditionnelle <while>: boucle <pick>: bloque et attend qu un message particulier arrive (event-based) <scope>: groupe les activités pour gérer les transactions Exemple (fragment) WSBPEL: état actuel rôles et <partnerlinks> partenaires! <partnerlink name="customer"!!! partnerlinktype="lns:loanapprovelinktype"myrole="approver"/> variables pour! <partnerlink name="approver" la persistence!!! partnerlinktype="lns:loanapprovallinktype" partnerrole="approver"/> </partnerlinks> <variables> flot! séquentiel <variable name="request" messagetype="loandef:creditinformationmessage"/> requête! <variable name="approvalinfo" messagetype="apns:approvalmessage"/> receive </variables> en WSDL <sequence>! <receive name="receive1" partner="customer" porttype="apns:loanapprovalpt"!!! operation="approve" variable="request" createinstance="yes"></receive> invocation d un WS! <invoke envoi d une name="invokeapprover" réponse partner="approver"!! porttype="apns:loanapprovalpt" operation="approve"!! inputvariable="request" outputvariable="approvalinfo"></invoke>! <reply name="reply" partner="customer" porttype="apns:loanapprovalpt"!! operation="approve" variable="approvalinfo"></reply> </sequence> Actuellement, WSBPEL est utilisé pour composer de manière semi-automatique des services Web création d un workflow (manuel) recherche des descriptions WSDL (automatique + manuel) chargement du procédé et des descriptions WSDL dans un moteur WSBPEL (manuel) exécution du procédé/composition de services (automatique)

33 WSBPEL: conclusion Un langage de workflow pour les services Web Permet de définir le comportement externe et interne des procédés Pas de sémantique (construit au-dessus de WSDL) Pas de dynamicité: les implantations actuelles exécutent les procédés exécutables mais codés en dur (correlation sets) Plan Contexte Services Web Standards Recherche Conclusion Services Web sémantiques Services Web sémantiques (2) Motivations passer d une collection statique d informations à un espace dynamique dans lequel différents composants peuvent être assemblés à la volée SOAP, WSDL, UDDI facilitent la publication,la description et l invocation de services Web, mais ils ne précisent pas ce que font les services, ni comment ils le font WSBPEL (&co) permettent de composer des services, mais cela reste syntaxique et statique Motivations (suite) Il n y a pas à l heure actuelle de sémantique, et la découverte, la composition, et même l exécution sont faites à la main L objectif est de minimiser les tâches manuelles et de pouvoir composer des services de manière la plus automatique possible

34 La vision générale Utilisation "Semantic differences remain the primary roadblock to smooth application integration, one which Web Services alone won't overcome. Until someone finds a way for applications to understand each other, the effect of Web services technology will be fairly limited. When I pass customer data across [the Web] in a certain format using a Web Services interface, the receiving program has to know what that format is. You have to agree on what the business objects look like. And no one has come up with a feasible way to work that out yet--not Oracle, and not its competitors..." Oracle Chairman and CEO Larry Ellison Scénario d utilisation découverte + sélection + composition + médiation + exécution + support (surveillance, compensation, remplacement) Découverte de services Web Sélection de services Web Location of services that abides to the service requester specification for a concrete task [Arroyo et, al. 2004] Exemple «trouve moi un service qui résout des équations du second degré» contraintes fonctionnelles: comment le service est rendu contraintes non fonctionnelles: temps d exécution, coût, UDDI + ontologies? Choice among discovered services, based on functional and non-functional attributes, of those that better suit the user requirements Exemple un service coûteux, sûr, fiable vs. un service gratuit, mais pas forcément fiable Algorithmes de ranking pour sélectionner le service le plus approprié

35 Composition de services Web Assembly of services based on its functional specifications in order to achieve a given task and provide a higher order of functionality [Arroyo et, al. 2004] Exemple composer les services disponibles pur résoudre les équations du type ((a*b)+c)-d implanter la multiplication par plusieurs appels à service addition fiable Médiation de services Web Arbitration of interacting Services in terms of domain knowledge used to describe the Services, data exchanged in the interaction (types used, and meaning of the information), business models of the different parties and, protocol used in the communication Médiation entre données: résultats, inputs attendus protocoles: Message Exchange Patterns procédés: alignement de différents modèles/flots de contrôle Exécution de services Web Support d exécution: surveillance Invocation of aconcrete set of services, arranged in a particular way following programmatic conventions that realize a given task [Arroyo et, al. 2004] Exemple calculer l expression suivante sans utiliser de service de multiplication ((3*3)+4-1 exécution multiple du service addition Supervision of the correct execution of services and dealing with exceptions thrown by composed services or the composition workflow itself Exemple le service d addition échoue à la troisième invocation le deuxième service d addition échoue pour incompatibilité de types Médiation, compensation, dynamicité

36 Support d exécution: compensation Support d exécution: remplacement Reparation of the operations involved in a transaction in case of failure, so unwanted side effects are rolled back or at least mitigated Exemple le calcul doit être effectué complètement, mais chaque appel à un service sera facturé annuler les effets non attendus Substitution of Services by equivalent ones, which solely or in combination can realize the same functionality as the replaced one, in case of failure while execution Exemple le service de soustraction échoue, comment le remplacer? nouvelle recherche état courant de la composition (contexte) médiation du nouveau service composition de services pour atteindre le résultat Standards actuels Demande le service UDDI Registry Service appelant Pointeur vers la description Pointeur vers Syntaxique le service! SOAP Communication à base de messages SOAP WSDL Besoin d annotations sémantiques Web Service Décrit le service Besoin de modèles formels pour composer, valider et exécuter Objectifs Simplifier et/ou automatiser les services Web découverte composition invocation surveillance Problème centre d intérêt aujourd hui étant donné un ensemble de services S1,,Sn et une requête T, construire automatiquement un schéma de composition SC qui satisfait T en orchestrant S1,,Sn

37 Questions Trois questions importantes comment modéliser les services et leur composition? comment automatiser une composition? comment analyser une composition? Croisée de plusieurs disciplines Conception workflow systèmes réactifs algèbres de processus vérification IA agents planning Bases de données XML transactions Anatomie d une composition Composition de services Découverte/ description But(s) Activités Orchestration, surveillance Pas de modèle unifié BPEL: orchestration, partage de données OWL-S: buts, activités, découverte Partage de données (messages) modèle Romain : activités, orchestration Synthèse d une composition entrée requête du client ensemble de services disponibles sortie spécification du service composé Orchestration entrée spécification du service composé sortie coordination des services suivant le schéma de composition surveillance des flots de données et contrôle

38 Quelques propositions actuelles WSBPEL permet de spécifier des compositions de services Web les procédés sont vus comme des interactions coordonnées de services Web permet de modéliser à la fois des procédés abstraits et des procédés exécutables influences modèles traditionnels de workflow programmation structurée repose sur les ports WSDL standard via OASIS Quelques propositions actuelles (2) Web Service Conversation Language (WSCL) Idée de base sur la composition interactions entre plusieurs services WSCL spécifie une conversation comme un graphe étiqueté nœuds: interactions, unités fournissant des réponses arcs: transitions, séquencement des interactions étiquettes: conditions sur les transitions commande? stockepuisé cmde acceptée paiement invalide Quelques propositions actuelles (3) Parenthèse: les MEP ([Alonso ICDE 05]) WS Choreography: proposition du W3C Inspirée du "-calcul Modèle global pour représenter une composition interactions choreography (WS-CDL) Éléments participants et roles: quels services sont impliqués? channels: où, comment les messages sont envoyés? interactions: Message Exchange Patterns activities et structures de contrôles: séquencement choreography: description globale de la composition Message Exchange Patterns Client input input Service Client fault Service in-only (no faults) robust in-only (message might trigger a fault) fault output Client Service Client output Service out-only (no faults) robust out-only (message might trigger a fault)

39 Parenthèse: les MEP (2) 1) input Client 2) output 2 ) fault Service in-out (fault replaces message) 2 ) fault Client 2) input Service 1) output out-in (fault replaces message) Client input?) output Service fault in-optional-out (message triggers fault) Client fault?) input Service output out-optinal-in (message triggers fault) D!EFG". G".H)*A<-0 >I/EFG: Quelques propositions actuelles (4)! "#$%&%'()#($*+,#-,'-$+.$,--$*%&,#+)/* OWL-S (Ontology Web Language) 0 "#$122%'$.#+.3.(4$5.'$-%*/')6)#($2'.2%'+)%*$7$ /,2,6)3)+)%*.5$8%6$9%':)/%*$1*)#($;8< Pour ajouter de la sémantique! =#,63%,1+.&,+).#$.5$:,').1*$,/+):)+)%*$>%?(?@$ propriétés et capacités des services *%':)/%$-)*/.:%'4$7$*%3%/+).#A - input types - output types - preconditions - effects - process flow - composition hierarchy - process definitions - communication protocol (RPC, HTTP, ) B5'.& C"D<E9F - port number!!!"#$$%"&'()*+,-"./,0"1$2"#$$%"3 45+6,2"7,8,9:" ;<*,*=+2"><"?+,@)A)2"/<@<--, BC - marshalling/serialization Quelques propositions actuelles (5) Quelques propositions actuelles (6) OWL-S Service Profiles Pour définir ce que le service fournit niveau fonctionnel: IOPE (Input, Output, Preconditions, Effects) niveau non-fonctionnel: nom, catégorie, QoS, Calcul de situation comme modèle formel pour les préconditions et les effets Raisonnement basé sur ces préconditions/effets Possibilité d organiser hiérarchiquement les profils (spécialisation) OWL-S Process Model Pour définir le procédé composé séquence concurrence: split, split+join, choix conditionnel boucles Flot de données pas de variables explicites prédicats

40 Synthèse Rappel étant donné un ensemble de services S1,,Sn et une requête T, construire automatiquement un schéma de composition SC qui satisfait T en orchestrant S1,,Sn Pour modéliser une composition, il faut modéliser la requête du client modéliser les services composants modéliser la composition (interactions complexes) orchestrer le service composé Modèles Passer d une conversation à un système à transitions (1) prix? (2) commande Client Service prix (3) confirmation demandé (4) paiement [confirmation(false)] articles commandés [requête prix] [commande] [paiement] [confirmation(true)] commande confirmée Orchestration Deux types pair à pair (P2P) hub (médiateur) (o)rder1 store (r)eceipt1 warehouse 1 store r o1 WH1 (p)ayment1 k o b1 r1 (a)uthorize (b)ill1 a p1 o(k) (r)eceipt2 hub (o)rder2 bank (p)ayment2 (b)ill2 warehouse 2 bank k a p b b2 r2 p2 o2 WH2 Modèles présentés Mealy/Conversation composition automates, basé sur les messages Romain composition automates, basé sur les activités Calcul de situation composition FOL, basé sur les activités Commitments composition contraintes, basé sur les messages

41 Modèle Mealy [Bultan et al, WWW 2003] Un schéma de composition est vu comme un triplet (P, C, M) où P: ensemble fini de services (peers) C: ensemble fini de canaux (channels) entre les services M: ensemble fini de classes de messages Supposition: domaines finis cela permet de modéliser plus facilement Définition Un peer est un FSA M = (T, s, F,! in,! out, ") T: ensemble d états s: état initial F: ensemble d états finaux! in : messages input! out : messages output " : relation de transition qui consomme un message (s1,?m, s2), ou produit un message (s1,!m, s2), ou effectue une transition vide (s1, #, s2) Modèle Mealy (2) Modèle Mealy (3) Deux possibilités pour les peers Black box: langages avec signature WSDL: signatures input/output OWL-S pre et post-conditions centré sur les séquences de messages transmis ou les actions White box: langages de composition/ implantation WSBPEL OWL-S process diagrammes de flux avec synchronisation, scopes, variables, événements, Un service individuel est une machine à état fini messages input et output contrôle des états de terminaison Décrit des signatures de comportement?o2!r2!b2!b2!r2?p2?p2!r2 warehouse 2

42 Communication asynchrone Exécution et surveillance Basée sur l utilisation de files de messages Asynchrone store o1 WH1 store Le store produit la lettre a et l envoie à la banque!a?k!o1 a?b1?a!k...!o2 bank Les files sont FIFO, pas de contrainte sur la taille On peut simuler des communications synchrones et aussi dimensionner les files warehouse 1 La banque consomme a warehouse 2 Exécution et surveillance (2) Exécution et surveillance (3) L exécution d une composition se termine lorsque tous les services sont dans un état final lorsque toutes les files sont vides Surveillance un moniteur enregistre tous les messages envoyés a k o1 o2 b1 p1 r1 r2 b2 p2 une conversation est une séquence de messages que le moniteur a enregistré langage de conversations: toutes les conversations possibles État et conversation L état d une composition est basée sur l état de chaque peer le contenu des files de messages Une conversation, c est l activation d un procédé global (un schéma de composition) on peut avoir des sous-conversations