Description syntaxique

Etat de l’Art

2.3 Composition de services . . . . 60 2.3.1 Description de la composition . . . 61 2.3.2 Aspect transactionnel . . . 65 2.3.3 Notion de contexte . . . 66 2.3.4 Composition automatique . . . 67 2.4 Discussion . . . . 71 33

La recherche dans le domaine du mod`ele orient´e service a accord´e une attention significative `a trois aspects principaux que nous pr´esentons dans ce chapitre. D’abord dans la section 2.1, nous ´etudions les mod`eles de description des services. Nous mettons un accent particulier sur les constructions syntaxiques de repr´esentation des services et leurs extensions s´emantiques. Ensuite dans la section 2.2, nous ´etudions la d´ecouverte des services permettant de localiser les services et de les comparer. Nous d´ecrivons en particulier les structures de publication de services et les architectures de d´ecouvertes et leurs techniques de correspondances associ´ees. Finalement dans la section 2.3, nous ´etudions la composition de services. Nous d´ecrivons la coordination entre deux ou plusieurs services en mettant l’accent sur les mod`eles de description de l’interaction entre services dans la cadre de processus complexes et sur les mod`eles de composition automatique.

2.1 Description de services

La description d’un service consiste `a d´efinir une interface exposant les op´erations accomplies par le service et `a lier chaque op´eration `a sa r´ealisation. Dans cette section nous pr´esentons les mod`eles de description des services. Nous d´etaillons d’abord le mod`ele de description syntaxique WSDL qui est devenu le standard incontournable pour les services web. Nous pr´esentons ensuite les diverses approches s´emantiques visant `a pr´eciser la description d’un service en mettant l’accent sur les approches d’annotation s´emantique et sur les ontologies de services. Nous exposons ensuite les mod`eles de description comportementale d’un service. Finalement nous r´esumons d’autres approches ne s’inscrivant pas dans la classification propos´ee.

2.1.1 Description syntaxique

Le Web Service Description Language (WSDL) [29] est devenu le standard actuel pour la d´efinition des services. Par le biais d’un document XML, il d´ecrit un ser-vice `a travers une interface pr´esentant un ensemble d’op´erations et leurs param`etres d’entr´ee et de sortie respectifs. Nous consid´erons par exemple un service d’infor-mation m´et´eo qui donne la temp´erature dans une ville `a une date pr´ecise. L’inter-face WSDL de ce service, fournie en annexe A.1, est un document XML d´ecrivant une op´eration qui prend en entr´ee une ville et une date et qui fournit en sortie une temp´erature. L’interface WSDL d´ecrit la fonctionnalit´e accomplie par le ser-vice (ce que le serser-vice fait) mais il ne d´ecrit pas les modalit´es d’accomplissement de

!"#$%&'$() *+,"() -"((./") ,'0*1+,") 2%$!%$/) ("03%4") )5678)9:;) 1+,"() <$*"0=.4") >%$!%$/) 6"03%4") ,'0*) ?$!,'%$*)

Figure 2.1: ´El´ements de description d’une interface WSDL d’un service

cette fonctionnalit´e (comment le service le fait). Un document WSDL est un fichier XML constitu´e de cinq ´el´ements principaux : <types>, <message>, <portType>, <binding> et <service>. La figure 2.1 illustre la structure d’une interface d´ecrite en WSDL avec les ´el´ements suivants :

– <types>, illustr´e par la figure 2.2a, est un conteneur d´efinissant les donn´ees figurant dans les messages ´echang´es par le service. Il d´efinit `a travers un sch´ema XML les types de ces donn´ees. Les donn´ees peuvent ˆetre simples comme par exemple une temp´erature qui prend une valeur d´ecimale ou complexes comme par exemple l’entr´ee TemperatureRequest d’un service d’information m´et´eo. Cette entr´ee est un donn´ee de type complexe qui est constitu´ee d’un ´el´ement location et d’un ´el´ement date tel illustr´e par la figure 2.2a.

– <message>, illustr´e par la figure 2.2b, d´efinit les messages ´echang´es par le service. Il est compos´e d’un ensemble de <part>. Un <part> est associ´e `a une donn´ee d´ecrite dans <types>. Par exemple, le message GetTemperatureInput de la figure 2.2b est compos´e d’un ´el´ement part reli´e `a TemperatureRequest d´efini dans <types>.

– <portType>, illustr´e par la figure 2.3a, d´esigne un ensemble d’operations. Une <operation> est une description abstraite d’une action accomplie par le ser-vice. Elle contient un sous-´el´ement <input> et un sous-´el´ement <output>. Ils d´ecrivent les param`etres d’entr´ee et de sortie de l’op´eration. Un <input> ou un

!"#$%& !"#$%&%'()*+,*$-"$".,)/* !"0)1'()*+,*2()*/34,* <types>! ...! <xs:element name="TemperatureRequest">! ! <xs:complexType>! ! ! <xs:sequence>!

! ! ! <xs:element name="location" type="xs:string"/>!

! ! ! <xs:element name="date" type="xs:date"/>!

! ! </xs:sequence>!

! </xs:complexType>!

</xs:element>! ...!

(a) Illustration de l’´el´ement WSDL <types>

!"##$%"&

!"#$%&'#(%)$%*+,*,-#$.%/#%.'("#&

<message name="GetTemperatureInput">!

! <part name="body" element="TemperatureRequest"/>! </message>!

<message name="GetTemperatureOutput">!

! <part name="body" element="TemperatureValue"/>! </message>!

(b) Illustration de l’´el´ement WSDL <message>

Figure 2.2: Illustration des ´el´ements WSDL <types> et <message>

<output> poss`ede un attribut message qui r´ef´erence un ´el´ement <message>. Par exemple dans la figure 2.3a, le TemperaturePortType d´ecrit l’op´eration GetTemperature `a travers le message d’entr´ee GetTemperatureInput et le mes-sage de sortie GetTemperatureOutput.

– <binding>, illustr´e par la figure 2.3b, reprend les op´erations de l’´el´ement <portType> et leurs associe un protocole de transfert de message. Concr`etement, le <binding> d´ecrit comment les messages seront ´echang´es. Il sp´ecifie un seul protocole d’´echange mais il ne pr´ecise pas les adresses entre lesquelles les messages seront ´echang´es. La sp´ecification WSDL d´ecrit le <binding> avec les m´ethodes GET et POST du protocole HTTP et pr´esente un protocole d’´echange plus ´elabor´e pour HTPP, le protocole SOAP [18]. Par exemple la figure 2.3b illustre le <binding> de TemperaturePortType du service d’information m´et´eo avec le protocole SOAP. L’´el´ement <binding> poss`ede deux attributs. L’attribut name d´efinit le nom du binding. Il est ´egal `a TemperatureSoapBinding dans cet exemple. L’attribut type indique le <portType> pour qui le <binding> a lieu. Il est ´egal `a tns :TemperaturePort-Type dans cet exemple. L’´el´ement soap :binding poss`ede aussi deux attributs. L’attribut style qui peut ˆetre ´egal `a rpc ou document. Il pr´ecise si l’´echange a lieu `a travers un appel `a une proc´edure distante ou `a travers un envoi -r´eception d’un document. Dans cet exemple un document est utilis´e.

L’attri-but transport d´efinit le protocole r´eseau qui va v´ehiculer les messages SOAP. Dans cet exemple HTTP est utilis´e.

– <service>, illustr´e par la figure 2.3c, pr´ecise l’adresse ou les adresses aux-quelles se trouve le service. Un <service> est un ensemble de <port>. Un <port> sp´ecifie une adresse pour un <binding> donn´e. Par exemple, la figure 2.3c d´efinit le service TemperatureService `a travers un port, TemperaturePort, associ´e au binding tns :TemperatureSoapBinding. Elle pr´ecise l’adresse de Tem-peraturePort qui a comme valeur “http ://example.com/temperature”. En r´esum´e, les <portType> d´ecrivent les op´erations du service en terme d’entr´ees et de sorties. Les <binding> d´ecrivent concr`etement les messages ´echang´es par les op´erations `a travers un protocole choisi. Le <service> associe `a chaque <binding> une adresse `a laquelle se trouve l’impl´ementation.

Chronologiquement IBM, Microsoft et Ariba ont d´evelopp´e WSDL 1.0 en 2000. WSDL 1.1 est publi´e en mars 2001 comme une note W3C [30]. WSDL 1.2 est une nouvelle version simplifi´ee, mais n’a pas ´et´e `a ce jour valid´ee par W3C. En juin 2007, le WSDL 2.0 est publi´e comme une recommandation W3C. WSDL 2.0 n’est autre que la sp´ecification WSDL 1.2 dont le nom a chang´e vu les diff´erences majeures qui le d´emarque de WSDL 1.1. Nous retenons les changements suivants : (i) <portType> est devenu <interface>, (ii) <port> est renomm´e en <endpoints>, (iii) <message> n’est plus utilis´e, un <xs :element> suffit pour d´efinir les donn´ees ´echang´ees.