Architecture soa (architecture orientée services)

2.5 Modélisation de la problématique Terrena

Modéliser est en quelque sorte représenter la réalité d'un système et des objets qui le constituent.

L'Architecture Orientée Services s'articule principalement autour du concept de processus métier. Ce dernier est constitué d'une séquence de services indépendants (on parle de couplage faible) et interopérables gérés le plus souvent par un annuaire UDDI. Un service répond à un besoin du métier. A cette fonction, dite de « grosse maille », est attaché un contrat qui régît la relation « Consommateur-Fournisseur ». Il est important de rappeler que les Web Services ne sont qu'une implémentation des services, et qu'il est possible de parler de SOA sans mise en oeuvre de Web Services. Autrement dit, la problématique Terrena doit être perçue au travers de plusieurs vues complémentaires : informationnelle, processus, services et qualité de service.

2.5.1 L'objectif

La question que l'on doit se poser avant tout est : Quelle est la stratégie que le Groupe Terrena souhaite atteindre au travers de cette expression de besoin ? Pour répondre à cette question un diagramme en forme d'arrêtes de poisson peut servir d'illustration. Ce diagramme a pour vocation de définir les causes et les effets. La flèche au centre rappelle l'objectif principal. Les causes sont représentées par les flèches transverses orientées vers l'axe central. Les effets s'imbriquent sur ces flèches obliques. Les causes placées au-dessus de l'axe central concernent les métiers, et celles placées sous l'axe central correspondent à celles de la D.S.I.

Fluidifier les flux

Eviter les ressaisies

Automate au fil de l'eau

Offrir des solutions de type Web Service

Homogénéiser les pratiques

Objectif stratégique

Sécurisation, Fluidification Clarification des flux Tiers

Tracer les

Messages

Format pivot

Optimiser les pratiques,

Trouver des plans alternatifs

Maîtriser les flux et règles métiers Tiers

Sécuriser des outils informatiques utilisés

Assurer le plan de Reprise d'activité

Illustration 81 : Diagramme Causes-Effets d'Ishikawa^140(*)

2.5.2 La conceptualisation de notre monde clos

La problématique n'est pas tant de mutualiser ou de rationaliser des fonctionnalités qui seraient réparties sur plusieurs systèmes (la richesse fonctionnelle de ce processus est somme toute relative), mais clairement de coordonner de façon optimisée des systèmes autonomes, ici au nombre de 18, afin de limiter les désynchronisations de codification entre les différents blocs applicatifs. Nous en profiterons pour construire une architecture, qui permette également de répondre aux besoins transversaux nécessitant un référentiel métier. Ce souci d'une meilleure coordination est une problématique qui se trouve souvent au centre des systèmes dits « multi agent »^141(*). Ce concept « SMA » a été introduit en 1980. Un agent y est défini comme une entité autonome qui interagit avec d'autres agents pour le compte d'un groupe d'utilisateurs. Il est constitué d'une connaissance partielle et peut accéder à des données ou à des ressources. SMA^142(*) semble approprié lorsqu'il s'agit d'aborder le sujet de la tolérance aux pannes, les problèmes de disponibilité réseau etc ... Il bénéficie d'informations du monde clos^143(*) qui l'entoure (« perception planning »), et interagit (« motion planning ») avec ce dernier. Les agents communiquent entre eux par le biais de messages asynchrones. Pour que SMA soit assimilable à une architecture SOA, il doit être déterministe dans le sens où dans un contexte donné, l'agent produit toujours la même action (les connaissances de l'agent restant identiques). Un agent combine des observations obtenues par ces capteurs (indicateurs : nombre de messages dans la pile par exemple) avec des actions spécifiques à un contexte donné (pré et post conditions). La prise de décision conduit à une séquence d'actions dans le but de réaliser un objectif.

Ces systèmes multi-Agents font l'objet d'une modélisation propre appelée : AUML (UML for Agent). Elle repose sur des diagrammes UML tels que : le diagramme de Classes d'Agent, le package pour ce qui touche aux protocoles, les diagrammes d'Activités, de Séquence, de Collaboration et d'Etats-Transitions pour tout ce qui concerne les échanges entre agents. Malgré les failles d'AUML (notion d'historique non gérée, descriptions temporelles difficilement traduisibles ...), cette approche est intéressante car l'agent est autonome comme l'est le composant d'un ESB. Par ailleurs le concept d' « Agent » est apparu dans la spécification SOAml parue le 13 janvier dernier (extrait ci-dessous).

Illustration 82 : Extrait SOAml

(Source : http://www.omg.org/docs/ad/08-11-01.pdf, page 43)

Connaissances

Pré et Post Condition => Liste ordrée d'actions

Agent

Objectif

N Actions

Observations

Système

Évènements

Illustration 83 : Architecture logicielle de l'agent

L'illustration à venir montre un système de transition d'états impliquant les objets suivants : un message qui peut prendre plusieurs formes, une file d'attente capable de recevoir et de supprimer le message, des agents capables de transporter le message, de le transformer après détection sur certains lieux (répertoires) dans un périmètre d'intervention (bloc applicatif). Notre système d'information est constitué de plusieurs blocs applicatifs qui communiquent entre eux par échange de messages.

q L'ensemble S est un ensemble fini et énumérable d'états. Il est noté :

S = {S0, S1, S2, S3, S4, S5}

q L'ensemble des actions A est un ensemble fini et énumérable d'activités ou actions noté :

A= {préparer, supprimer, détecter, transformer, transmettre, ignorer, consommer}

q L'ensemble des évènements E est initialement vide. Il représente un ensemble fini et récursivement énumérable : E = {}

L'illustration suivante met en évidence les différents états dans lesquels se trouve l'objet message. Elle précise les « compensations^144(*) », c'est-à-dire l'action à mettre en oeuvre pour défaire ce qui a été fait précédemment et ainsi "revenir" dans un état stable.

File F2

Agent 4

Agent 3(Prépare)

Agent 3

Lieu L1

Lieu L2

S2

S3

Message M1

M2

File F1

File F1

Lieu L1

Agent1(Ignorer)

Agent1(Détecter)

File F1

S4

S5

M2

M2

File F1

Lieu L1

Lieu L2

Lieu L2

S0

S1

Message M1

File F1

Lieu L2

Lieu L1

Lieu L1

Lieu L2

File F1

Lieu L2

Agent 4

Agent 2

Agent 3

Agent 2

Agent 1

Agent 1

Agent3(Supprimer)

File F2

File F2

Agent 4

Agent 4

Agent1(Transformer)

Agent 3

Agent 2

Agent 2

Agent 1

Agent1(Transformer)

Agent2(Transmettre)

Agent2(Transmettre)

File F2

File F2

Agent 4

Agent 3

Agent 2

Agent 2

Agent 1

Agent4(Consommer)

File F2

Agent 3

Agent 1

Agent4(Détecter)

Agent 3

Agent 4

Agent 1

Lieu L1

Agent4(Ignorer)

Agent4(Supprimer)

Illustration 84 : Système de transition d'états appliqué à notre échange de fichier Tiers

Nous nous apprêtons ainsi à modéliser le processus actuel d'alimentation de tiers. Il devrait s'agir en quelque sorte d'une communication coordonnée entre plusieurs agents. A partir de cette représentation, il va être possible de souligner les faiblesses ou les éventuels manques. De ce constat, il faudra ensuite être capable de proposer des solutions alternatives, tout en gardant à l'esprit que cette approche de modélisation devrait être transposable à une toute autre problématique.

2.5.2.1 Les concepts

Les objets

q Message : dans le sens générique, ici il s'agit de différentes structures de fichiers,

q Lieu : base de données, répertoires,

q File d'attente : Zone tampon, utilisée pour stocker provisoirement les messages (le premier qui entre est aussi le premier qui peut ressortir de la file d'attente),

q Agent : automate évoluant dans différents lieux, à l'écoute des états dans son monde clos, et prêt à effectuer une séquence d'actions.

* ¹⁴⁰ Kaoru Ishikawa (Ishikawa Kaoru, Tôkyô, 1915 - 16 avril 1989), ingénieur chimiste japonais précurseur et un des théoriciens pour la gestion de la qualité. On lui doit notamment le diagramme de causes et effets qui est un des outils fondamental pour assister les cercles de qualité.

* ¹⁴¹ SMA (systèmes multi-agent) : ensemble d'agents situés dans un certain environnement et interagissant selon une certaine organisation. Un agent est une entité caractérisée par le fait qu'elle est, au moins partiellement, autonome. Ce peut-être un processus, un robot, un être humain, etc...

* ¹⁴² Cf. Rapport de Stage Master 2 de J. GUITTON. « Planification multi-agent pour la composition dynamique de Services Web » [GUI-PMA].

* ¹⁴³ Le Monde clos : Hypothèse selon laquelle tout ce qui n'est pas dit est faux.

* ¹⁴⁴ Notion de compensation : mécanisme de retour arrière par exemple lorsqu' un traitement de virement échoue en cours de route. Si un mouvement de débit a déjà été créé sur le compte d'origine, alors la compensation sera de créditer de la même somme le compte.