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

2.5.2.2 La coordination

Dans le cadre de notre SI hétérogène, l'objectif est de pouvoir répondre à des buts communs et transversaux aux différents blocs applicatifs, qui le constituent. Deux modes de coordination sont envisageables : soit la planification est collective et centralisée (elle repose alors sur un agent coordinateur), soit elle est distribuée et répartie sur plusieurs systèmes (où chaque agent construit son plan de solutions de façon indépendante puis tente de le synchroniser avec ceux des autres agents). En quelque sorte, ces agents nous renvoient au concept des services WEB dont la modélisation peut être prise en charge par OWL-S. Il fait partie d'un ensemble avec lequel il se trouve en interaction. Chacun des agents joue un ou plusieurs rôles dans le système. Chaque rôle accède à un certain nombre de méthodes et chaque méthode fait appel à des opérations conditionnées.

Illustration 87 : Diagramme de classes de l'Agent, réalisé sous magicdraw

Quatre rôles distincts ont été déterminés précédemment : la préparation, la détection-transformation d'un message, la transmission et la consommation d'un message. Le « Fournisseur » prépare le message. Le « Consommateur » est le nom donné au système cible qui attend le message afin de l'intégrer à son rythme dans son propre référentiel de données. L' « orchestrateur » exécute un script d'exploitation basé sur la détection puis la transformation (d'un contenu Oracle vers un format fichier CSV), suivie de la transmission du fichier. Mais avant de proposer ce diagramme d'activité, encore faut-il modéliser la communication actuelle.

2.5.2.3 La Modélisation de la communication actuelle

Les deux diagrammes suivants (de communication et de classes) représentent la structure spatiale de la communication actuelle. Ils décrivent l'échange de fichiers entre un système dit « le Fournisseur » et un autre, appelé « le Consommateur ». Le premier diagramme (de communication) est composé de :

q agent émetteur/ agent récepteur : dans la réalité les agents prennent les deux rôles,

q agent superviseur : dans notre cas ce superviseur est l'outil de coordination, notre orchestrateur OPEN PROCESS dont le comportement est guidé par des scripts d'exploitation,

q agent observateur : il n'existe pas en tant que tel aujourd'hui mais dans l'absolu il peut représenter toute personne (du service exploitation ou autre) souhaitant être informée des différentes étapes d'un fichier,

q objet de la communication : cela représente les informations Tiers à transmettre au(x) consommateur(s),

q message : les messages échangés dans ce processus sont des fichiers au format fixe Csv,

q code : le code utilisé ici représente la structure de message échangé entre les deux partenaires. Le format de message doit être connu des deux protagonistes,

q canal : le canal utilisé pour véhiculer le message entre les deux partenaires, ici FTP RFC959,

q localisation : la localisation du message est l'emplacement où est positionné le fichier.

Ainsi cet échange est orchestré par un outil de planification. Ce dernier est appelé « Open Process ». Il joue un rôle de « superviseur » de façon distribuée (en ce sens qu'il n'est pas localisé que sur le système central, mais il est réparti sur l'ensemble des systèmes protagonistes de cet échange). Il détecte l'arrivée de nouveaux fichiers tiers au format Csv assimilables, dans la représentation, à des messages. Les appels FTP gérés par Open Process donnent au fournisseur et au consommateur un rôle d'« émetteur » et de « récepteur » d'informations. L'agent récepteur dispose d'une boite à outils, puisqu'une fois reçu, le message doit être transformé et intégré. L' « observateur » représente le technicien d'exploitation amené à traiter manuellement des fichiers rejetés par le superviseur.

Illustration 88 : Diagramme de communication, réalisé sous Magicdraw

Le diagramme de classe quant à lui présente la structure du modèle actuel :

Illustration 89 : Diagramme de classes, réalisé sous Magicdraw

Le premier constat est peut être l'aspect rigide de cette communication (un seul canal, des règles de transformations non intégrées au processus de communication, seule la dernière version de code du message peut entrer dans le processus, des interventions manuelles sont requises pour traiter les rejets etc...). Mais avant de poursuivre davantage l'analyse des faiblesses, il faut présenter les différentes vues afin de rendre lisible le SI, un peu à la façon d'un urbaniste qui souhaiterait faire évoluer ou moderniser tout ou partie d'un système d'information.

précédent sommaire suivant