Les services

Les services effectuent des op´erations de calcul en ex´ecutant des actions, ils obtiennent ´egalement des informations au moyen d’´echanges de messages avec les autres services. Pour ex´ecuter les actions ou communiquer avec les autres services, des conditions peuvent ˆetre exig´ees. Ces conditions peuvent porter sur la valeur d’une variable interne au service ou sur la valeur d’un attribut d’un des certificats du client. Une fois que l’action est ex´ecut´ee il est possible que des modifications se produisent sur les variables internes au service ou sur les attributs d’un certificat dans le cas o`u on consid`ere que les services peuvent ˆetre des autorit´es de certification [CGM06]. Dans la litt´erature, diff´erents formalismes ont ´et´e utilis´es pour repr´esenter les ser- vices. Parmi ces formalismes nous citons les r´eseaux de Petri [HB03], les automates d’entr´ees/sorties [PTB05] et les automates communicants condi- tionnels [BCG+_{05]. Pour plus de d´etail voir le Chapitre 2.}

Avec les hypoth`eses que nous consid´erons, les r´eseaux de Petri et les au- tomates communicants conditionnels sont les plus adapt´es pour repr´esenter les services. Etant donn´e que notre travail s’inspire de [BCG+_{05] et que nous}

consid´erons une probl´ematique similaire `a la leur, nous avons choisi d’utili- ser les automates communicants conditionnels pour repr´esenter les services. Pour les d´etails concernant les d´efinitions et rappels sur les automates com- municants conditionnels, voir le Chapitre 3

Nous pr´esentons maintenant notre mod`ele formel des services. Dans ce mod`ele, nous consid´erons certaines restrictions, pour simplifier l’analyse du probl`eme. Une de ces restrictions consiste `a ne pas consid´erer la structure des messages envoy´es par les services ni leur contenu. Il est suffisant de dire qu’un service donn´e a envoy´e/re¸cu un message dans un port donn´e, sans pr´eciser de

quel message il s’agit. De plus, nous consid´erons que les variables locales des services et les attributs des certificats sont des propositions bool´eennes. De ce fait, nous ne tenons compte d’aucune structure alg´ebrique. Notre mod`ele est ainsi une abstraction d’un mod`ele r´ealiste.

D´efinition 4.1.1 (Certificat). Un certificat est une structure C = (Attr, Se) telle que :

– Attr est un attribut (nom, pr´enom, date de naissance, etc) et – Se est le service qui a ´emis le certificat.

L’ensemble de tous les certificats est not´e Cert. Bien entendu, dans la pratique les certificats peuvent avoir plusieurs attributs. Pour simplifier le mod`ele, nous n’avons consid´er´e qu’un seul attribut1_.

Exemple 4.1.2. Consid´erons l’ensemble des certificats Cert tel que C1 =

(MasterCr, SGBanque) et C2= (V isaCr, CLBanque). Ces certificats sont

des cartes bancaires. Elles ont comme attribut le type de la carte et comme service ´emetteur une banque. Dans cet exemple, la premi`ere carte est de type Master Card, ´emise par la banque SGBanque. La seconde carte et de type Visa Card, ´emise par la banque CLBanque.

Remarque 4.1.3. Les services qui peuvent ´emettre les certificats peuvent ne pas appartenir `a la communaut´e de services.

Dans notre repr´esentation formelle des services, nous utilisons un en- semble fini d’actions Σ, un ensemble fini de ports P ort et un ensemble fini de formules atomiques At. L’ensemble Σ repr´esente toutes les actions qu’un service peut effectuer, ces actions sont diff´erentes des actions de communi- cation. L’ensemble P ort repr´esente tous les ports qu’un service peut utiliser pour communiquer avec un autre service. Les actions de communication seront repr´esent´ees par l’ensemble {!, ?} × P ort. L’ensemble At repr´esente les formules atomiques dont les litt´eraux seront les conditions ou les effets des transitions d’un service. Plus pr´ecis´ement, l’ensemble At contient tous les attributs et les ´emetteurs des certificats ainsi que toutes les variables bool´eennes que les services peuvent utiliser.

Exemple 4.1.4. On s’int´eresse `a l’achat et `a la livraison de livres. L’en- semble des actions Σ = {VerifierDispo, Paiement, Annuler, Finaliser} est tel que :

– VerifierDispo : v´erifier la disponibilit´e de l’ouvrage.

1_{Consid´erer un nombre fini d’attributs ne change pas nos r´esultats, car At restera un}

– Payment : accepter le paiement. – Annuler : annuler la transaction. – Finaliser : finaliser la transaction.

L’ensemble des ports P ort = {ChoisirPr, InfoO, EnvoiPrix, PrixO, RepA- chat, ConfAchat, Echec, EchecO, Reussit, Descrption, InfoL, PrixLivraison, PrixL, RepLivraison, ConfL, SucsLivraison} tel que les ports sont utilis´es pour :

– ChoisirPr, InfoO : envoyer/recevoir l’identifiant de l’ouvrage. – EnvoiPrix, PrixO : envoyer/recevoir le prix de l’ouvrage.

– RepAchat, ConfAchat : envoyer/recevoir la confirmation de l’achat d’un ouvrage.

– Echec, EchecO : envoyer/recevoir un message d’´echec de transaction. – Reussit : envoyer/recevoir un message de r´eussite de transaction. – Descrption, InfoL : envoyer/recevoir le type du produit `a livrer, la date

et le lieu de sa livraison.

– PrixLivraison, PrixL : envoyer/recevoir le prix de livraison d’un pro- duit.

– RepLivraison, ConfL : envoyer/recevoir la confirmation d’acceptation du prix.

– SucsLivraison : envoyer/recevoir un message de r´eussite de la tran- saction.

On consid`ere les certificats de l’exemple 4.1.2 ainsi que l’ensemble des for- mules atomiques At = {Dispo, Acpt, MasterCr, VisaCr, SGBanque, CL- Banque, Encaisse, AcptLivraison} tels que :

– Dispo : vaut ”vrai” si l’ouvrage est disponible.

– Acpt : vaut ”vrai” si le client accepte de payer l’ouvrage.

– MasterCr : vaut ”vrai” si le client a une carte de type Master Card. – VisaCr : vaut ”vrai” si le client a une carte de type Visa Card. – SGbanque : vaut ”vrai” si l’´emetteur de la carte est la banque SG-

Banque.

– CLbanque : vaut ”vrai” si l’´emetteur de la carte est la banque CL- Banque.

– Encaisse : vaut ”vrai” si le paiement de l’ouvrage est accept´e. – AcptLivraison : vaut ”vrai” si le client accepte de payer la livraison. D´efinition 4.1.5 (Service). Un service est un automate communicant conditionnel Ac = (Q, q0, δ) surΣ ∪ ({!, ?} × P ort) et At.

Le lecteur remarquera que l’ensemble des ´etats finaux ne figure pas parmi les composantes de l’automate communicant conditionnel. La raison de cette omission est la simplification des preuves de d´ecidabilit´e et d’ind´ecidabilit´e,

q1 0 q11 q21 q₃1 q1₄ q₅1 (∅, ?ChoisirP r, ∅) (∅, V erifierDispo, ∅)

({Dispo}, !EnvoiP rix, ∅) (∅, ?RepAchat, ∅) ({Acpt, MasterCr, SGBanque}, P aiement, {Encaisse})

({¬Dispo}, !Echec, ∅)

({¬Acpt}, !Echec, ∅) (∅, !Reussit, ∅)

Fig. 4.1 – Service VenteDeLivre

dans les sections suivantes. Cependant, les preuves restent applicables dans le cas g´en´eral.

Exemple 4.1.6. Consid´erons un service qui propose des livres `a vendre et qui est intitul´e V enteDeLivre. Nous repr´esentons ce service par l’au- tomate communicant conditionnel Ac1 _{sur Σ ∪ ({!, ?} × P ort) et At de}

l’exemple 4.1.4. L’automate communicant conditionnel est repr´esent´e dans la Figure 4.1. Dans le service V enteDeLivre, pour ex´ecuter certaines tran- sitions des conditions, sont `a satisfaire et des effets sont `a consid´erer. Par exemple, pour ex´ecuter l’action P aiement, il est n´ecessaire que le client soit d’accord pour payer, qu’il poss`ede une carte bancaire de type Master Card et que l’´emetteur de cette carte soit la banque SGBanque. C’est `a dire que les formules atomiques Acpt, MasterCr et SGBanque soient satisfaites. Une fois le paiement accept´e, la formule atomique Encaisse devient vraie.