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)

( Télécharger le fichier original )
par Virginie ELIAS
CNAM Nantes - Pays de la Loire - Ingénieur 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
Un Protocole de transport unique et non sécurisé

Illustration 97 : Couche Transport

Le script actuel ne propose qu'une porte d'échange entre les différentes plateformes : le mode FTP. De plus, les comptes et mots de passe ainsi que les noms de machines et les répertoires sont stockés dans un fichier Csv non crypté. L'arrivée d'une nouvelle plate-forme dans le SI suppose, en cas de participation aux échanges, la modification de ce script et l'alimentation des fichiers de « paramétrage ».

Une architecture orientée services est avant tout une architecture de médiation permettant d'assurer l'interopérabilité au niveau des données mais aussi au niveau des techniques de transport telles que : HTTP, HTTPS, SOAP + WS-Security, SMTP, SMTPS, FTP, SFTP, RMI, etc ...), tout en sécurisant les échanges.

Pour cela, l'ESB joue un rôle de médiateur entre les différents systèmes, grâce à ses composants internes. Au moment de la génération du message, les consommateurs ne sont pas connus à l'avance. Le bus doit donc être souple, c'est à dire permettre à plusieurs systèmes hétérogènes de communiquer sans que le processus ne soit décliné autant de fois qu'il y a de technologies dans le SI. La spécification WS-Security (OASIS) vient renforcer la sécurité des échanges de messages.

Dans le cas présent, la cardinalité devrait être multiple, et le canal devraient, si possible, être sécurisé (SFTP au lieu de FTP tout au moins).

Un processus qui s'arrête trop tôt

Illustration 98 : Diagramme de séquence de la distribution

Actuellement, si un consommateur n'est pas disponible, alors le message (le fichier) est systématiquement mis en quarantaine, ce qui implique une action manuelle de la part d'un technicien d'exploitation. De plus, si une nouvelle application doit entrer dans le processus d'alimentation, cela suppose également un paramétrage spécifique et des modifications à plusieurs niveaux des scripts actuels. Ceci peut être source d'erreur et ne semble pas très « agile ». De plus, le processus actuel ne sait pas à quel moment tel ou tel fichier a été intégré. Il n'y a pas de retour du consommateur au superviseur quand un fichier a été consommé, ni lorsque que tout ou partie de ces enregistrements présentent des erreurs de codification. Aujourd'hui, les dernières branches du processus sont manuelles.

Les Données

L'organisation des données au sein d'un fichier Csv fragilise l'agilité du système, puisque tant pour l'extraction, que pour les N programmes de transformation et de chargement (ou d'intégration), il faudra opérer des adaptations plus ou moins coûteuses. De plus, la mise en lot des données de plusieurs tiers ne facilite pas le suivi unitaire, cette notion de lot n'étant pas réellement identifiée au niveau du Fournisseur.

Les règles de transformation ne sont pas connues de façon centralisée car elles sont réparties sur autant de systèmes Clients distants. Les mesures d'impact en cas de modification n'en sont pas aisées. Pour illustrer cette difficulté supplémentaire, nous pouvons citer le problème auquel nous avons dû faire face en début d'année : le nombre de positions (5 caractères numériques) qui permet d'identifier le code tiers n'était plus suffisant, au autrement dit : « la boucle était bouclée ». Il a fallu se rapprocher de chaque Chef de projet pour connaître la longueur et le type de code Tiers dans chaque application, puis se lancer dans une phase de recette complète pour mesurer l'impact de l'utilisation alphanumérique des 5 positions de ce code. Plusieurs semaines ont été ainsi nécessaires pour commencer à avoir certains retours sur un dossier pourtant jugé « urgent ».

Les agrégations de données sur des entités comme le tiers, pour lesquels il existe des tables de transcodification sur certaines applications, sont rendues très délicates : nulle-part, de façon centralisée, nous ne pouvons connaître l'ensemble des identifications d'un tiers. Invoquer des services sur des systèmes différents dans le but de réaliser un processus transverse (exemple : Suivi des montants des livraisons par Tiers) devient une chose difficile.

Le vocabulaire utilisé aujourd'hui n'est pas uniforme (chaque application consommatrice désigne l'adhérent selon son métier : « Fournisseur collecte », « Adhérent », « Coopérateur », « Eleveur »). La codification peut être propre à l'application (on l'a vu précédemment via une transcodification), ou identique ou presque. Quelques transformations (le sous-compte par exemple dans l'application Céréales est amputé du premier chiffre) sont parfois utilisées. Ces règles ne sont pas connues de façon centralisée.

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








"Il ne faut pas de tout pour faire un monde. Il faut du bonheur et rien d'autre"   Paul Eluard