WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Architecture SOA (Architecture Orientée Services ). Quelle source de valeur pour le Groupe Terrena?

( Télécharger le fichier original )
par Virginie ELIAS
Conservatoire des arts et métiers de Nantes - Pays de la Loire - Ingénieur CNAM en informatique 2009
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

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

précédent sommaire suivant