De l'AF vers l'AT,
De l'AT vers l'AF,
une affaire de projections

[Architecture]

Principes d'architecture
    Ce qui suit peut guider tout passage d'un type d'architecture à l'autre.
    Ces principes sont valables pour l'architecture du "système logiciel" (notion introduite dans l'article sur définition de l'architecture) concerné, à savoir pour une architecture globale, et non selon un point de vue particulier comme "fonctionnelle" ou "technique".
Ces principes se déclinent ainsi :
-définir l'architecture du système logiciel dans un processus dynamique. En effet, 2 facteurs externes au système évoluent et peuvent engendre des ruptures en matière de conception et réalisation lors de l'intégration de ces évolutions. Il s'agit (1) des besoins de l'entreprise et (2) des nouvelles technologies. La notion de guide d'architecture prend alors tout son sens ;
- analyser précisément les besoins pérennes avant de faire des choix technologiques (or, tout fan de java ou de telle ou telle techno est tenté de réfléchir d'abord selon ce point de vue avant de s'intéresser aux véritables besoins!) ;
- adopter autant que possible le paradigme objet (pour son pouvoir d'abstraction et d'encapsulation) de manière systématique comme cadre pour structurer et modéliser le système logiciel (cf. l'activité structurante de l'Analyse) ;
- concevoir le système logiciel comme un système ouvert, décentralisé qui s'appuie sur des structures réutilisables métier correspondant aux processus importants de l'entreprise. Cette ouverture suppose la publication d'interfaces du système, l'utilisation de formats d'échanges et de protocoles communs reposant sur des standards de droit ou de fait (cf. par exemple http, html, XML).
    On remarquera que ce qui précède constitue un bon plaidoyer pour l'emploi du "paradigme composant" (un article est prévu sur l'approche composant). Son pouvoir d'encapsulation lui permet de faire cohabiter des technos objet et non-objet (exemple, java et COBOL).
    fausses bonnes idées en matière d'architecture
    - considérer très tôt le problème uniquement sous l'angle technologique (à savoir le sous point de vue "technologique" de l'AT) ;
    - préconiser de façon trop rigide des technologies présentées comme universelle par des commerciaux convaincants mais "mal informé" sur les besoins réels du client : il n'y a pas aujourd'hui (et il n'y aura peut-être jamais) de technique adaptée aux besoins de toutes les applications d'un "gros" système logiciel ;
    - préconiser des technologies spécifiques pour résoudre des problèmes généraux (il faut toujours rajouter des services complémentaires... et le coût d'adoption s'en trouve faussé) ;
    - préconiser des technologie sans les situer dans l'évolution dynamique du système logiciel, par exemple sans estimer leur coût d'introduction puis surtout d'abandon, si elles se révèlent non conformes avec les besoins identifiés par le système "cible" visé.
    vraies bonnes idées en matière d'architecture
    - subordonner tous les choix technologiques à l'analyse des besoins (pérennes et dont l'impact est global) ;
    - identifier les services généraux transversaux techniques utiles (transaction, sécurité, persistance, ... ces composants techniques sont détaillés dans l'article sur l'Architecture Technique) ;
    - toujours considérer dans le choix d'une technologie le coût d'introduction mais aussi d'abandon de cette technique ;
    - préconiser l'interopérabilité des solutions différentes (d'où l'importance croissante des EAI, couplés aux formats de type XML).

Projection : mécanisme de passage d'une architecture à l'autre
    Le principe de la projection consiste a associer au contrat technique d'un composant les services techniques issus de l'architecture technique identifiée du point de vue de l'ingénierie, puis à projeter ces services sur l'architecture technique concrète, identifiée du point de vue technologique.

     Le schéma ci-dessus illustre le passage de l'AF à l'AT et illustre le fait que, d'un point de vue méthodologique "strict", l'architecture technique s'obtient par 
- projection de l'architecture fonctionnelle sur des technologies logicielles (les services techniques) et des ressources matérielles (comme la base de données, sans préciser encore de quelle techno - Oracle, Sybase, ... - il s'agit) : il s'agit de l'architecture applicative (détaillé dans la Sphère Architecture Applicative), puis ;
- par projection sur des choix d'implémentation (J2EE, JTA pour la gestion des transaction, base de donnée Oracle, ...) et en tenant compte de l'hétérogénéité technique décrite dans l'article Pourquoi l'Architecture ?.

Infrastructure supportant l'abstraction et assurant l'interopérabilité
    Chaque composant satisfait, comme c'est rappelé en début d'article, 2 contrats, un fonctionnel et un technique. Il est essentiel de distinguer l'interface de l'implémentation pour chacun de ces 2 contrats.
    L'implémentation du contrat fonctionnel est de la responsabilité du développeur du composant. Il fournit également à l'infrastructure d'exécution une description du contrat technique à implémenter (le quoi, mais pas le comment).
    C'est de la responsabilité de l'infrastructure d'exécution, générique ouverte et inter opérable d'implémenter le contrat technique. 
Cette plate-forme devra supporter :
- le bon niveau d'abstraction utilisé en modélisation (comme le paradigme objet qui regroupe les notions d'encapsulation, d'héritage et de polymorphisme) ;
- l'interopérabilité entre des implémentations différentes (en terme de langages, systèmes d'exploitation, matériel, ...), ce qui permet de prendre en compte l'existant (legacy) et de l'intégrer au système logiciel dans son ensemble.

    La communication avec les applications existantes consiste à offrir une vision objet (s'il s'agit bien du paradigme utilisé dans la modélisation du système logiciel), via des API procédurales. Il existe 2 techniques pour assurer cette communication :
- la migration vers l'objet d'une application non-objet se traduit réingénieirie totale de l'application qui s'apparente en fait à la conception et réalisation d'une nouvelle application ;
- l'intégration consiste à fournir des objets wrappers (on parle aussi "d'accesseurs") dont le rôle consiste à :
    1/ obtenir des interfaces porteuses des méthodes pour accéder aux services que l'application encapsulée doit fournir à son environnement ;
    2/ gérer un état, en assurant la traduction entre un modèle qui manipule des objets (auxquels sont associés des états) et le modèle du système encapsulé... cela est un problème souvent très difficile à résoudre.

Exemple de projection technique : la persistance
    La persistance des informations du niveau "Métier" nécessite des adaptation technique pour :
- contrôler et limiter l'impact lié à une modification de la structure physique des données (modifications inéluctables dans le cadre d'un processus de dénormalisation du modèle) ;
- prendre en compte l'hétérogénéité technique des sources de données existantes (base de données relationnelle et hiérarchiques, fichier plat, ..) ;
    C'est pourquoi, dans le cadre d'une projection technique du niveau fonctionnel "Métier", on le divisera en 3, obtenant ainsi une projection technique à 5 niveaux, ce que représente le schéma suivant dans le cadre du point de vue "ingénierie" de l'architecture technique. Il reste à associer à ces 5 niveaux des choix technologiques précis.
    Cette décomposition en niveaux représente une des activités majeures mises en oeuvre par la sphère Architecture Applicative. On y trouvera d'ailleurs un paragraphe sur l'activité de 'layering' qui fait allusion à un autre service technique à découper en niveau: la sécurité du réseau.
Attention, il s'agit ici d'identifier des tiers applicatifs, en partant de couches fonctionnels (layer)
    On notera également que chacun de ces niveaux nécessite un assemblage précis et une intégration entre chacun de ces niveaux.
 

    On trouve dans ces 5 tiers (niveaux) :
- le tier présentation qui reste le plus découplé possible de l'application ;
- le tier application contenant les composants qui gèrent la logique applicative ;
- le tier "Métier sans persistance" contient la représentation objet des objet processus et entités. Il s'agit de la projection technique des objets métiers sur une infrastructure d'exécution qui n'assure pas toute seule la persistance. Il utilise le niveau "Accès aux ressources" pour synchroniser ses informations avec celles stockées dans les engins de persistances ;
- le tier "Ressources" désigne les techniques de stockage des données utilisées dans le système logiciel. On n'y accède que par le niveau "Accès aux ressources" ;
- le tier "Accès aux ressources" permet d'isoler les problèmes de "mapping" entre la représentation des informations manipulées par le niveau technique "métier sans persistance" et la représentation persistante dans les bases de données, fichiers, etc... (dont on a précisé ci-dessus que la structure physique change par rapport au modèle logique). Il permet également d'intégrer des services externes accessibles via des protocoles propriétaires en les rendant disponibles via des interfaces adaptées aux besoins de l'application. Ce niveau peut dans certains cas être extrêmement léger voir inexistant, si le système logiciel n'utilise qu'une base de données objet, par exemple.
Le rôle de ce niveau s'apparente à un système de fédération des différentes ressources physiques utilisées (comme un EAI). Mais il ne faut pas se laisser tromper et "tout" intégrer dans ce niveau "Accès aux ressources" : les conversions de paradigme objet/relationnel font rarement parti de ce niveau. 
De fait, un système de fédération pourra être considéré comme une ressource à part entière.
Par exemple, un EAI (justement) qui se connecte et traduit en objet des ressource non objet pourra être lui même considéré comme une ressource lue à partir d'un composant situé dans le niveau "Accès aux ressources". On accède à la ressource "EAI" sans même savoir qu'il y a conversion de paradigme objet/relationnel.