Comme il a ´et´e expliqu´e dans la section2.4.3, les interfaces statiques des services web, telles que d´ecrites par les fichiers WSDL, sont indispensables pour faciliter l’uti- lisation des technologies `a base des services. Effectivement, elles offrent un m´ecanisme essentiel pour l’interop´erabilit´e entre les divers intervenants. N´eanmoins, ces interfaces restent insuffisantes, et il y a un besoin r´eel d’abstractions de haut niveau au del`a des simples ”format de donn´ees et noms des messages”. En effet, dans un environnement r´eel les clients n’invoquent pas de simples op´erations qui sont ind´ependantes de leur contexte, plutˆot ils ex´ecutent un ensemble d’op´erations dans un ordre bien d´efini afin de r´ealiser des processus m´etiers. Il devient alors imp´eratif de prendre en consid´eration les aspects comportementaux des services web. A ce titre, il existe un consensus sur la n´ecessit´e de pr´eciser ´egalement l’interface dynamique des services [10, 57, 58, 59]. En particulier, le comportement ext´erieur et visible d’un service est important pour ´
eviter des conversations incorrectes entre le service et ses clients [1, 10].
A titre d’exemple, un service peut offrir les deux op´erations suivantes : ajouter des produits `a un panier ´electronique et proc´eder au paiement. Un document WSDL d’un tel service doit expliciter les noms des messages associ´es (par exemple, ajouter-produits et paiement), ainsi que leur sch´ema XML (type, port types, noms d’op´erations, messages, . . . ). Il est ´evident qu’une description aussi simpliste demeure insuffisante pour r´ealiser de vrais processus m´etiers. Par exemple, la suite d’op´erations : payement suivie de de l’op´eration ajouter-produits n’exprime pas souvent un processus m´etier r´eel. Par cons´equent, les op´erations offertes par un service web ne peuvent ˆetre ex´ecut´ees dans un ordre al´eatoire, et il est rare que ces op´erations soient invoqu´ees ind´ependamment les unes des autres. En effet, les interactions entre les clients et les services sont structur´ees en termes d’un ensemble d’op´erations qui doivent ob´eir `a des contraintes `a respecter par les clients afin qu’ils puissent r´ealiser les proc´edures d´esir´ees [10].
Dans cette section, nous rappelons le concept de protocole de service et son utilit´e, apr`es nous discutons des diff´erents mod`eles existants pour leur repr´esentation.
CHAPITRE 2. LES SERVICES WEB ET LES PROTOCOLES DE SERVICES
2.6.1
Notion de protocole de service
Un protocole de service est un mod`ele abstrait tr`es utile pour capturer le com- portement externe et visible d’un service web. Il explicite un ensemble de contraintes `
a satisfaire par les clients qui invoquent le service [10, 11]. En ce sens, il sp´ecifie les conversations qu’un service peut supporter afin que les demandeurs potentiels sachent comment ´eviter d’invoquer des conversations invalides [60]. Dans [10], des contraintes sur l’ordre des messages que le service web peut accepter ont ´et´e sp´ecifi´ees. Les travaux pr´esent´es dans [61] se focalisent sur les contraintes temporelles (dur´ee de validit´e) impos´ees `a chaque activit´e du protocole. Un enrichissement des deux types de contraintes pr´ec´edentes a ´et´e propos´e dans [62] pour permettre la prise en compte des contraintes transactionnelles.
Exemple 2.1 La figure 2.4 montre un exemple simple d’un protocole d’un service
web d’achat en ligne qui pourra ˆetre d´eploy´e par un fournisseur de service pour g´erer les commandes clients relatives au commerce ´electronique. Le protocole est repr´esent´e sous forme d’un automate d’´etats fini d´eterministe, o`u les ´etats correspondent aux dif- f´erentes ´etapes par lesquelles passe le processus d’achat ´electronique (Connect´e, Com- mandeConfirm´ee, CommandePay´ee ; . . . ) et les transitions entre ´etats correspondent aux noms des op´erations invoqu´ees (Commander, Payer, Annuler . . . ).
Connecté EntrainDeCommander CommandeConfirmée CommandePayée CommandeAnnulée CommandeLivrée Fin FinInscription Debut Inscr iption Connexi on Confirmation Commander Paye r Livraison Inscrit Confirmation Ann uler Sortir Sortir Commander Commander
Figure 2.4 – Potocole du service web Achat en ligne
La logique m´etier v´ehicul´ee par ce protocole stipule que le client doit tout d’abord se (Connecter), ou s’(Inscrire) s’il ne l’est pas d´ej`a. Puis, il pourra (Commander) des
CHAPITRE 2. LES SERVICES WEB ET LES PROTOCOLES DE SERVICES
articles, tout en restant dans l’´etat (EntrainDeCommander). Apr`es confirmation (Confir- mation), il a la possibilit´e, soit d’(Annuler)) sa commande soit de la (Payer). Si la com- mande a ´et´e confirm´ee alors la marchandise sera livr´ee (op´eration :Livraison). Enfin, le service transite `a l’´etat final, suite `a l’ex´ecution de l’op´eration (Sortir) pour atteindre l’´etat final (Fin).
Il est a noter que dans le mod`ele pr´esent´e ci-dessus, les noms des ´etats n’ont pas le mˆeme degr´e d’importance et de signification que les transitions. En fait, ces derni`eres sont plus importante, car elle expriment les messages `a ´echanger entre les clients et les fournisseurs.
2.6.2
Utilit´e des protocoles de service
Les protocoles de service web sont des outils tr`es utiles dans plusieurs contextes d’analyse relatifs aux phases de d´eveloppement et d’ex´ecution des services [11,60]. Ils sont, particuli`erement, incontournables dans les situations suivantes :
– V´erification de la conformit´e des protocoles des fournisseurs : s’assurer que la mise en œuvre effective d’un service r´epond `a un cahier des charges qui est fourni aux clients (par exemple, dans la documentation).
– V´erification de la compatibilit´e des protocoles fournisseurs avec des normes stan- dards, telles que RosettaNet PIPs [63].
– Pour le client, v´erifier que son propre protocole est en conformit´e avec la logique m´etier du fournisseur. Dans le cas contraire, le client sera oblig´e d’effectuer les adaptations n´ecessaires de fa¸con `a rendre son protocole compatible avec celui du fournisseur, et ´eviter, par cons´equent, les erreurs d’ex´ecution.
– Il existe plusieurs situations dans lesquelles le service web aura besoin d’ˆetre rem- plac´e (cas de panne du service, lors des ´evolutions des proc´edures, . . . ). Dans de telles sc´enarios, l’analyse de la rempla¸cabilit´e du service, bas´ee sur les proto- coles de service [11, 64], permettra d’identifier de nouveaux services potentiels pouvant remplacer le service d´efaillant.
2.6.3
Les mod`eles de repr´esentation des protocoles de ser-
vices web
Vue l’importance du concept de protocole m´etier une panoplie de mod`eles dot´es de niveaux d’expressivit´e vari´es, a ´et´e propos´ee dans la litt´erature pour les repr´esenter. Certains mod`eles sont formels, tels que les automates ou les r´eseaux de Petri [52] [65]. D’autres mod`eles sont plutˆot graphiques, comme les diagrammes de s´equences ou les diagrammes d’activit´es d’UML [66]. Par ailleurs, mˆeme certains langages int`egrent dans leurs sp´ecifications des primitives et des outils pour d´ecrire le comportement des protocoles de services ou des processus m´etiers. C’est le cas par exemple de BPEL [54] et de BPMN [67].
A titre d’illustration, nous exposons dans les figures 2.5 et 2.6 deux protocoles de services utilisant des mod`eles de repr´esentations diff´erents. Le premier exemple de la figure 2.5 est un mod`ele bas´e sur les r´eseaux de Petri qui repr´esente le protocole de service R´eservation en ligne d’un vol.
CHAPITRE 2. LES SERVICES WEB ET LES PROTOCOLES DE SERVICES
Démarrage Réservation
Système Accédé Demande Info Vols
Infos Vols Fournies
Vol Sélectionnés Choisir Vols
Demander tarifs
Prix Communiqués
Confirmation Annulation
Réservation Confirmée Réservation Annulée
Figure 2.5 – Potocole de R´eservation en ligne en r´eseaux de Petri
Le deuxi`eme exemple de la figure2.6 sch´ematise un diagramme de s´equences UML [68] qui illustre le protocole de r´eservation d’un vol par l’interm´ediaire d’une agence de voyage (fournisseur ). Ce mod`ele met en ´evidence les rˆoles (colonnes) et les mes- sages (fl`eches ´etiquet´ees) comme ´el´ements conceptuels de base. Quant aux contraintes d’ordre, elles sont exprim´ees par la chronologie temporelle descendante.
D’une mani`ere g´en´erale, nous pouvons classer les mod`eles de repr´esentation des protocoles des services web en trois grandes familles.
1. les mod`eles `a base d’´etats : sont rencontr´es dans plusieurs contexte pour d´ecrire les abstractions comportementales d’un syst`eme. Particuli`erement, les mod`eles UML [68] contiennent diff´erentes abstractions qui permettent de d´ecrire diff´erentes aspects d’un syst`eme en fonction du type d’information qu’on d´esire captur´e. Ainsi, les diagrammes de s´equence, les diagrammes d’activit´es et les diagrammes d’´etats repr´esentent diff´erents comportements d’un syst`eme. 2. les mod`eles `a base d’activit´es : sont utilis´ees pour repr´esenter un syst`eme
dans sa forme ex´ecutable (e.g, workflow ). Les ´etats repr´esentent les activit´es et les transitions sont d´eclench´ees quant les activit´es sont achev´ees. Dans certains de ces mod`eles, les transitions v´ehiculent des flux de donn´ees.
3. les mod`eles `a base de r`egles :[69] sp´ecifient le comportement d’un syst`eme par le biais d’un ensemble de r`egles. Une r`egle est d´eclench´ee lorsqu’un ´ev´enement donn´e se produit, ou lorsqu’une condition est v´erifi´ee. La r`egle est ´ecrite dans un langage sp´ecifique et elle d´efinit une action `a ex´ecuter. Les mod`eles `a base de r`egles ont ´et´e largement utilis´es lorsque le comportement du syst`eme exige des mises `a jour fr´equentes `a partir de l’expertise du domaine.
CHAPITRE 2. LES SERVICES WEB ET LES PROTOCOLES DE SERVICES
Client Fournisseur Compagnie Tierce
Accés Système Demander Info Vols
Rechercher Vols Vérifier places disponibles Vols proposés
Demander tarifs Confirmer réservation Procéder au paiement
Demander réservation Demander détails réservation
Confirmer réservation
Confirmer réservation
Figure 2.6 – Diagramme de s´equences du potocole de R´eservation en ligne