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.3.5 Les Faiblesses (Vue générale)

Deux colonnes sont utilisées pour expliciter ces faiblesses. La colonne de gauche « Observation réduite au cas d'utilisation » met en lumière la problématique de notre modèle d'alimentation. Et la colonne de droite, « Observation générale », tente de donner plus de hauteur et propose une réponse vue de l'Architecture SOA, constituant ce qui est appelé les « bonnes pratiques »

Observation réduite au cas d'utilisation

Observation générale (bonnes pratiques)

Entre le moment où le tiers est créé ou modifié, il peut parfois se passer une heure avant que le processus d'alimentation ne commence. De plus, certaines applications consommatrices ne traitent les fichiers que la nuit ce qui repousse à J+1 la mise à disposition de l'information

Les zones tampons doivent être limitées.

Un ESB fonctionne dans un mode au fil de l'eau. Les liaisons inter-applicatives DEVRAIENT être de type Bus (ESB).

Cette tâche d'extraction n'est pas publiée car intégrée dans un script Python sans réelle pré et post condition. La réutilisation est en rendue moins évidente.

Les services (dans le sens générique) DOIVENT pouvoir être invoqués grâce à une interface d'accès de la famille des Services Web.

Les tiers sont extraits en Lot et rassemblés dans un même fichier à plat. Sans recherche manuelle, il n'est pas possible de savoir dans quel fichier se trouve la modification de tel ou tel tiers.

Xquery permet d'interroger aisément le contenu d'un document XML. Une couche d'administration peut être construite par ce biais. XQUERY DEVRAIT être utilisé pour les recherches dans les documents / Base de données XML.

Si le système d'information GCAT s'enrichit au niveau du référentiel tiers, la tâche d'extraction doit être retravaillée afin d'intégrer les nouveautés.

L'utilisation de formats de balisage (XML) est moins impactante en termes de maintenance qu'un format fichier. Le format d'échange DOIT être construit en XML.

La copie sur le FTP n'est pas sécurisée (RFC-959). Les comptes et mots de passe peuvent être aisément captés sur le réseau.

FTP propose une version davantage sécurisée : SFTP. De plus les protocoles SOAP, WSDL et UDDI renforçant la sécurité. Le mode sécurisé DOIT être préféré au mode non sécurisé.

Le fichier est très difficilement lisible sans accès à la description formelle. Le contenu du fichier n'est pas contrôlé avant qu'il ne soit transmis au consommateur.

Le contenu d'un document XML est compréhensible grâce aux balises utilisées. Ce contenu est contrôlé par un Schéma XML qui constitue la « grammaire » des informations transmises. Le format d'échange DOIT utiliser XML.

La transmission est mono-protocole. Quel que soit le consommateur, il n'est pas possible de transmettre le message d'une autre manière qu'en FTP.

Un système hétérogène peut rassembler potentiellement divers protocoles (FTP, SFTP, HTTP ...). Un des rôles de l'ESB est de transformer des protocoles (rôle de médiation). Les liaisons inter-applicatives DEVRAIENT être de type bus ESB.

L'algorithme d'attente est basé sur la comparaison d'une taille de fichier photographié deux fois, à 5 secondes d'intervalles. Dans les faits, cela fonctionne dans 99% des cas. Mais il arrive que certains noeuds du réseau soient saturés. Dans ce cas la photo est identique alors que le transfert de fichier n'est pas achevé.

Cf diagramme de séquence

En mode fichier : Il faudrait procéder à un nommage intermédiaire de telle façon à ce qu'il ne soit pas récupérable par l'automate le temps du transfert. Une fois achevé, le renommage du fichier le rendrait visible aux yeux de l'automate car il en retourne de la responsabilité de l'émetteur.

En mode message le problème de se pose pas car l'ESB garantit le bon acheminement et n'enchaîne une nouvelle tâche qu'une fois la précédente terminée. La spécification WS-ReliableMessaging appliquée à SOAP garantit le bon acheminement des messages. Dans le cadre des Services, SOAP DOIT être utilisé.

L'algorithme de test est complexe et ne concerne que le nom du fichier, c'est-à-dire le contenant et non le contenu. Les 2 premières positions du nom, puis les 3, les 4, les 5, les 6, les 7 et les sont comparées avec une liste de racines, stockée dans un fichier ascii non crypté. De cette chaîne est déduite l'application consommatrice vers qui il faut transférer le fichier. Cf diagramme de séquence

Les règles de routage internes à un ESB DOIVENT répondre à cette problématique. Le routage doit se faire sur le contenu (CBR) et non pas sur le contenant.

L'archivage consiste aujourd'hui à copier le fichier dans un répertoire d'historisation. Tout traitement ultérieur sur la base de ces fichiers est purement manuel et donc sujet à erreur.

Les règles de routage internes à un ESB DOIVENT répondre à cette problématique. La définition d'un Processus métier intègre les actions correspondant aux plans alternatifs en cas de plantage ou de rejet. Cette gestion DEVRAIT être davantage intégrée au processus métier d'alimentation des Tiers.

De façon générale, il n'existe aucune statistique automatique permettant de visualiser les « pics » de transfert, les performances des différentes actions...

Les indicateurs SAM et BAM permettent d'avoir une première idée de la réalité des échanges. Un outil BAM PEUT être mis en place pour donner ce premier niveau d'information.

Chaque consommateur gère ses transformations. Le vocabulaire tout comme les règles de transformation ne sont pas visibles de façon centralisée.

Un format pivot permettrait de centraliser les règles de transformation ainsi que la sémantique des informations Tiers des applications consommatrices. C'est aussi le rôle du « Repository » qui DEVRAIT être mis en place.

Les tiers qui n'auraient pas pu être intégrés par une application consommatrice ne sont pas connus de façon centralisée sans une recherche approfondie.

Les liaisons inter-applicatives DEVRAIENT être de type ESB du début à la fin du processus.

La réponse du consommateur se limite à la bonne réception ou non du fichier sur le répertoire d'accueil. Si le consommateur n'est pas accessible le fichier est mis en quarantaine ce qui supposera ultérieurement une manipulation du service exploitation. De plus, ce répertoire, vu du SI, est une boite noire : après recherche manuelle en lisant les fichiers trace, on peut savoir ce qui a été transmis, mais il est extrêmement difficile de savoir à quel moment un tiers lambda a été intégré à l'application consommatrice. Se pose là un des problèmes de mise en oeuvre d'un PRA (plan de reprise d'activité).

Dans un ESB le message a comme attribut une durée de vie qui lui permet d'attendre un certain temps avant d'être déposé dans une file d'attente dite « de fin de vie ».

En gérant tout le processus d'alimentation via un ESB, la connaissance des messages est réelle depuis leur création jusqu'à leur intégration par le consommateur. Dès lors il est plus aisé de rejouer les messages entre deux instants T dans le but de synchroniser plusieurs noeuds du système d'information. Les liaisons inter-applicatives DEVRAIENT être de type ESB.

Le processus est limité dans le sens où seul l'événement de saisie utilisateur déclenche une alimentation des applications consommatrices. Or, nous traversons une phase de réorganisation. Dans le cas où le référentiel Terrena deviendrait le référentiel de l'ensemble des filiales il faudrait que les tiers puissent aussi être transmis électroniquement (au format XML par exemple) d'une filiale par exemple à l'application centrale qui deviendrait cette fois une application consommatrice.

L'évènement déclencheur est aujourd'hui de type timing dans le sens où c'est le temps qui fait qu'une extraction des modifications et créations Tiers se déclenche. Le fichier, résultant de cette extraction, est ensuite travaillé par le processus actuel. Demain, le déclencheur pourrait être plus proche des évènements perçus par le Système. Ainsi, à chaque saisie d'un utilisateur, un service constituerait un message qui serait l `élément déclencheur du processus. Cette nouvelle porte pourrait aussi être empruntée par les filiales qui souhaiteraient transmettre leurs informations au système central GCAT. L'évènement déclencheur DEVRAIT être choisi parmi les objets en lien direct avec le processus ce qui rend plus aisée l'articulation entre plusieurs processus.

Seuls les tiers nouvellement créés ou modifiés alimentent les applications consommatrices. Il n'est pas possible aujourd'hui de procéder à un rafraîchissement qui fonctionnerait à la demande (via un Web Service).

Un ESB offre la possibilité d'accéder aux informations de diverses manières. Les Web Services font partie de cette offre.

Un tiers ne se définit pas seulement par ses informations générales, ses RIB et ses Adresses. L'ensemble des données de sa relation commerciale et financière avec la Coopérative fait partie de son identité. Aujourd'hui, les gestions commerciales, consommatrices de l'interface de Tiers, n'ont pas accès à cette vue complète.

Un ESB offre la possibilité d'accéder aux informations de multiples systèmes Fournisseurs.

Le référentiel de Structure, c'est à dire l'identification des ressources (Serveurs, répertoires, authentification) au travers du SI est géré dans des fichiers Csv non cryptés.

Un référentiel de la structure DEVRAIT être intégré à l'architecture et être sécurisé.

La liaison inter-applicative est de type « Point à Point ».

Les liaisons inter-applicatives NE DOIVENT PAS être de « point à point » mais DEVRAIT être de type ESB dans le sens « un message pour N applications consommatrices abonnées au processus ».

Le référentiel Client, c'est à dire l'identification des tiers au travers de tout le SI n'existe pas en tant que tel. Il est dispersé dans autant d'applicatifs qui constituent le SI.

Un référentiel métier DEVRAIT être intégré à l'architecture.

Tableau 9 : Bonnes pratiques SOA

précédent sommaire suivant