Architecture soa (architecture orientée services)

2.5.3.3 La Vue Informationnelle

Cette troisième vue met en lumière l'information qui se trouve au centre du processus décrit précédemment. Elle est très importante à la démarche, car elle doit répondre à la question du « Quoi ? ». Pour cela les informations manipulées doivent être décrites qu'elles soient structurées ou non.

En annexe, sont représentées les structures des Tiers, Rib et Adresses.

Ces informations proviennent de tables de l'application GCAT (le Fournisseur) et sont ventilées dans trois fichiers (ou enveloppes) séparés. Le Superviseur contrôle chaque nom d'enveloppe (chaque fichier) et décide s'il faut transférer l'enveloppe au consommateur ou la mettre en quarantaine (ce qui correspond à un rejet du fichier). Nous portons le focus sur les applications consommatrices qui reçoivent toutes la même structure de message. Ces dernières ont aujourd'hui la responsabilité de la transformation de ces données, avant leur intégration définitive. Les informations listées pèle mêle dans le fichier TIERS ne sont pas simples à organiser. Lors de la construction de la médiation cible, nous reviendrons certainement au concept d'ontologie, c'est-à-dire, à la définition d'une hiérarchie de classes et des propriétés de celles ci. Rappel : La couche OWL, dédiée aux ontologies s'appuie sur la couche XML. OWL est le fruit d'un travail du W3C.

2.5.3.4 La Vue Applicative, fonctionnelle ou Vue Services

La cartographie actuelle est le point d'entrée de l'analyse de la problématique sous l'angle applicatif. A partir de celle ci, un diagramme d'activités présentera les différentes actions et rôles mis en oeuvre afin d'atteindre l'objectif. Le diagramme d'activité doit être le moyen à partir duquel il va être possible d'illustrer les plans alternatifs en cas de panne diverses (réseau ou serveur indisponible etc ...) ainsi que les manques du processus actuel. Ainsi le diagramme à venir représente la situation actuelle des flux d'alimentation des tiers pour ce qui est des transferts de fichiers à plat. Rappel : il en existe d'autres, tels que des transferts base à base pour la comptabilité ainsi que de la saisie directe par les utilisateurs. Ces derniers sont écartés de l'analyse de l'existant, sans que cela ne rende impossible leur prise en compte dans le modèle cible. A partir de ce diagramme d'activités, nous allons donc étudier les manques et faiblesses du système actuel afin de construire ce modèle futur, permettant lui, de répondre à la stratégie précédemment énoncée. Ce chapitre doit faire ressortir un certain nombre de préconisations et de conseils, ce que l'on appelle communément des « bonnes pratiques ». Afin de déterminer le niveau d'importance du respect de ces bonnes pratiques, la terminologie RFC 2119 (qualifiant les différents niveaux d'exigence depuis 1997) sera utilisée en français dans le mémoire :

q MUST, SHALL : DOIT (exigence absolue de la spécification.)

q MUST NOT, SHALL NOT : NE DOIT PAS (prohibition absolue de la spécification.)

q REQUIRED : EXIGE (nécessite)

q SHOULD : DEVRAIT (c'est à dire qu'il peut exister des raisons valables, dans certains cas, pour ignorer cet item particulier. Les conséquences doivent être bien étudiées.)

q SHOULD NOT : NE DEVRAIT PAS (signifie que cela est interdit mais qu'il peut toutefois exister des raisons valables, dans certains cas, pour ne pas suivre cette recommandation. Les conséquences doivent être bien étudiées.)

q RECOMMENDED : RECOMMANDE

q MAY : PEUT (FACULTATIF)

q OPTIONAL : FACULTATIF Terminologie RFC 2119.

(Source : www.ietf.org/rfc/rfc2119.txt)

Illustration 93 : Diagramme d'activité actuel