III.2 Architecture MSL (Modèle - Service - Liaison)

1. Résumé du noyau de MSL-POJO

Si nous faisons la synthèse des présentations déjà faites, ce qu'il faut retenir à propos du noyau de base de l'API MSL-POJO sont:

• Les composants identifiés de notre système seront modélisés à l'aide des classes POJOs des plus simples, ne précisant alors que la définition des caractéristiques statiques de ces composants.
• Le noyau de base de l'API MSL-POJO n'offre alors à ces composants que des services bas niveau de manipulations des caractéristiques de ces composants, sans tenir compte encore de leur interactions entre eux au sein du système, ou vis à vis de l'extérieur.

2. Fondement de l'architecture MSL

Maintenant, essayons de voir un peu la technique d'approche adopté par l'utilisation de MSL, pour construire un SI donné !

L'idée de base s'inspire de l'architecture à 3 niveaux (3 tiers) adopté dans beaucoup de modèle de construction actuel :

• La couche de persistance dont la tâche principale est d'assurer la permanence et disponibilité de toutes les données intervenant au sein du système dans son contexte de mise en oeuvre.
• La couche de présentation dont la tâche est d'offrir une interface conviviale, intuitive et pratique du système construit, par rapport à l'extérieur et particulièrement les utilisateurs humains du système.
• La couche métier ou la logique applicative qui est la couche la plus importante, car sa tâche sera d'implémenter la spécialisation du fonctionnement du système, pour atteindre l'objectif prédéfini dicté par les besoins des clients ou utilisateurs du système.

Architecture 3 niveaux (3 tiers)	Architecture MSL (cas 3 couches)
Présentation Logique métier Persistance	Logique métier Persistance Présentation

Par contre sans vouloir bousculer la bonne pratique régissant le modèle de construction en couche préconisé par les littératures, nous avions ramené quasiment cette vision emboîtée de la construction en couches à une vision éclatée, ne tenant en compte que comme couche centrale en dessus de toutes les autres d'ailleurs, la couche métier ou la logique applicative. 

Volontairement cette vision déformée du modèle de construction selon MSL, malgré son inspiration née du schéma de l’architecture en couche, avait été motivé par la suggestion de proposer déjà même au stade de la conception, une prémisse à une solution d’implémentation.

En effet avec ce schéma selon MSL, on peut imaginer déjà, que les composants identifiés dans les couches alignées sous le niveau de la couche métier, pourront être implémentés par des classes d’objets encapsulant des hiérarchies de services, donc des services propre à chaque couche identifiée. Ces services pourront même être fournis par d’autres API tiers selon leur spécialisation dans les briques de la construction.

Pour la couche métier, elle-même placé en dessus de toutes les autres couches, elle est conçue de telle sorte que selon les exigences de la logique applicative, les objets des autres couches devront être à portée de collaboration de l’objet principal matérialisant cette couche métier. Ce mécanisme de liaison d’objets pour les besoins de la logique applicative du système sera donc le point-clé de la pratique de l’API MSL et MSL-POJO en particulier pour Java, lors d’une construction informatique.

Parlant encore des couches autres que la couche métier, nous tenons à noter que le nombre des couches alignées pourra être étendu selon le découpage fonctionnel identifié et effectué sur notre système. Par exemple dans le cas de cette architecture à 3 niveaux, nous avions seulement identifié la découpe de la couche de Présentation et celle de la couche de Persistance. Ces 2 couches sont contraintes de collaborer avec la couche de la logique applicative.

3. Evolution de MSL-POJO 

Si nous regardons la genèse de MSL-POJO, c'est-à-dire dans sa première version :

Intégration de l'API Click : 

• Et dans la dernière version nouvellement modifiée, nous avions fait appel à l’API fourni par le framework Click pour remplacer l’implémentation de la couche de présentation par des classes POJOs héritant de la classe Page de ce framework.

L’approche de ce framework correspond parfaitement à notre vision, étant donné que Click adopte une conception orientée composants et pages, tandis que MSL place comme pièce centrale de son approche une construction basée sur des modèles de composants, dans l’analyse d’un système à monter. 

Dans la suite de cette présentation, nous parlerons donc des implémentations de la couche de Persistance de MSL-POJO.

… suivre …