1.4.6.2 Généralités
Caractéristiques du Service
Couplage faible 
La communication directe entre deux services est interdite
sauf si ces derniers appartiennent à la même
« catégorie » ou « domaine »,
concept étudié plus loin. Cette fonction est à la charge
du moteur d'orchestration. L'activation est réalisée à
partir des messages XML. 
S2 
S1 
S2 
S3 
S4 
S1 
Orchestration 
         XML 
S3 
           
   XML 
S4 
          XML  
          
XML  
  
          Illustration 24 :
Couplage fort                          
                                                       
                                       Illustration
25 : Couplage faible 
Un des avantages du couplage faible est d'alléger le
service en règles de pré-condition car elles sont prises en
charge par le moteur d'orchestration. Cela permet d'augmenter la
réutilisabilité du service car il devient plus
« standard ». Les messages XML sont
constitués : 
q  d'une entête (données d'infrastructure :
adressage comme l'identité complète du consommateur et du
fournisseur, sécurité, version, qualité et
transport),  
q  d'un corps (données applicatives), 
q  d'attachement(s) (données binaires : images par
exemple). 
 
 
 Asynchronie 
  
 Un service est asynchrone puisqu'il ne monopolise pas le
consommateur pendant qu'il s'exécute. Ceci est intéressant pour
diminuer les goulets d'étranglement et ainsi améliorer la
performance et la robustesse. 
  
 
 Exposition un contrat
d'utilisation 
  
 Deux volets (le premier volet est dit
« abstrait » et le
second « concret ») constituent ce contrat :  
q  un premier volet qui définit le nom du traitement et
les paramètres du message d'entrée et de réponse, ainsi
que les « pré » et « post »
conditions, 
q  un second volet qui précise le format technique des
messages et leur protocole de transport. 
  
Pour illustrer ce concept de contrat, l'exemple des conditions
de services64(*) de la
société de livraison UPS, décrit les
éléments qui définissent à la fois
l'authentification des intervenants, la garantie de livraison des paquets et
l'information de bonne exécution dans un délai
contractualisé (« Destinataire »,
« Expéditeur »,  « Trois tentatives
de livraison », « Suivi et Preuve de la Livraison») .
On y trouve tout autant les éléments constituant la
qualité de service (« disponibilité des
services », « Nombre de jours ouvrés de
livraison », « Nombre de tentative de
livraison ») que ceux énonçant les conditions du
service (« Ramassage quotidien »,
« Ramassage sur appel », « Limites de
dimensionnement et de poids», « conditions de
facturation », « Restrictions de service »).  
  
  
  
  
  
  
  
  
  
 Erreur consommateur                Erreur fournisseur        
 Pré-condition 1a 
 Post-condition 1 
  
 Pré-condition 1b 
  
  
 Post-condition 2 
  Requête 
 Pré-condition 2 
 Réponse 
  
  
  
  
Illustration 26 :
Pré et post conditions d'un service 
  
  
Les erreurs sont intégrées à la structure
des échanges entre le consommateur (le Client) et le fournisseur.  
  
 <?xml version='1.0' ?> 
 <env:Envelope
xmlns:env="http://www.w3.org/2003/05/soapenvelope"> 
<env:Header/> 
 <env:Body> 
 <env:Code> 
<env:Value>env:Receiver</env:Value> 
 </env:Code> 
 <env:Reason> 
 <env:Text xml:lang="fr-FR">Le compte est
débiteur</env:Text> 
 <env:Text xml:lang="en-GB"> The account is debtor
</env:Text> 
 </env:Reason> 
 </env:Body> 
 </env:Envelope> 
  
  
  
  
  
  
Illustration 27 : Erreur
véhiculée dans un message SOAP 
  
 Les types d'erreurs SOAP <env:Value> sont : 
q  env:VersionMismatch, 
q  env:MustUnderstand, 
q  env:DataEncodingUnknown, 
q  env:Sender, 
q  env:Receiver. 
  
   
Les pré et post conditions peuvent être
exprimées en Object Constraint Language65(*) (OCL) Uml et
permettent de définir en quelque sorte le banc de test du service. 
  
 Illustration 28 :
Pré et post conditions d'un service 
  
 Dans le cas d'une opération
« débiter », la somme doit être positive pour
que le service puisse se déclencher. Puis, le nouveau solde doit
être calculé (solde avant l'invocation du service soustraite de la
somme débitée). Ces contraintes permettent de traduire des
réalités pas toujours simples à modéliser
(Exemple : il est tellement plus facile dans un diagramme de classes
d'utiliser OCL pour préciser qu'un candidat, au moment de l'examen du
permis de conduire, doit avoir sa majorité). Ces contraintes sont
ensuite traduites dans le code Java ou en XML. 
  
  
   
Illustration 29 : Traduction XML des contraintes via
MagicDraw 
 
*  64 Cf. Guide des
services UPS :
http://www.ups.com/media/en/service_guide_fr_08.pdf 
 
*  65 Cf.
Spécifications OCL :
http://www.omg.org/docs/ptc/03-10-14.pdf 
 
 |