M2 TIW : Intergiciels et Services
Mettre en pratique les patterns IoC, Annuaire et Contexte afin de mieux comprendre le fonctionnement d'un framework. Mettre en place un outil configurable et capable de gérer le cycle de vie de ses composants.
Vous créerez un projet forge dans lequel vous travaillerez pour tout ce TP. N'oubliez pas de nous mettre (Emmanuel Coquery et moi) reporters de votre projet. Pour le rendu, vous indiquerez l'URL de base, complète, de votre projet forge sur la page Tomuss de l'UE (case "Rendu_TP_conteneurs").
Vous allez travailler sur une application de gestion de calendriers électroniques, dont une implémentation basique est accessible sur la forge, à : https://forge.univ-lyon1.fr/LIONEL.MEDINI/tiw-is-2017-container-base. La fonction main de l'application est située dans la classe d'interface utilisateur (CalendarUI), qui instancie une classe contrôleur (Calendar), laquelle instancie à son tour les autres classes de l'application, et notamment la classe d'accès aux données (DAO).
Clonez ce projet et modifiez, dans les classes CalendarUI et TestCalendarBuilder, le chemin du calendar où vous allez enregistrer les données.
Compilez et exécutez le projet. Logiquement, il doit donctionner avec un DAO en XML. Au besoin, corrigez les problèmes de persistance, et lancez les tests. Vous pouvez aussi tester "à la main", en lançant CalendarUI. Cela vous permettra de regarder, en cours d'exécution, le comportement de vos supports de persistance.
Durant ce TP, vous allez modifier la structure de cette application pour qu'elle implémente les principes de l'inversion de contrôle, du contexte, de l'injection de dépendances et de la gestion du cycle de vie.
Lien vers la dernière version de PicoContainer.
Vous allez maintenant mettre en place un conteneur. Pour cela, créez une classe Serveur qui masque au client l'ensemble des objets côté serveur en lien avec le calendar et placez ces objets dans un conteneur.
Ressortez les objets métiers du package serveur de l'application et rangez-les dans des packages métier, à votre guise. Modifiez enfin les classes main et cliente pour que le client puisse contacter le serveur et appeler la méthode de service.
À ce stade, vous avez inversé le contrôle de vos objets métier en les plaçant dans un serveur (i.e. un framework) qui se charge d'instancier, de gérer et d'utiliser ces objets.
Bien entendu, vous ne pouvez pas laisser le client accéder directement à l'instance du calendar créée dans le conteneur. Pour cela, vous allez implémenter le paradigme requête-réponse :
Remarquez que la classe ServeurImpl masque désormais complètement l'implémentation du traitement des requêtes par les objets métier. Il suffit au client de connaître son API pour utiliser le calendar.
Plutôt que d'avoir un objet Calendar qui répond à différentes requêtes, vous allez créer plusieurs objets sur le même modèle, mais traitant chacun un type de requête spécifique. Pour cela :
Cycle de vie des composants : Normalement, votre application ne doit pas fonctionner et vous renvoie une liste d'événements vide à chaque opération. Vous constatez également que les instances du DAO sont différentes dans les messages d'initialisation des calendars des méthodes de gestion du cycle de vie.
Cela vient du fait que bien que les classes CalendarXMLDAO et ArrayList soient des dépendances communes de tous les calendars du conteneur, par défaut, celui-ci résout les dépendances en instanciant un objet différent pour chaque instance de Calendar. Toutefois, vous pouvez indiquer que vous souhaitez procéder autrement, c'est-à-dire qu'il "cache" les instances. Vous pouvez résoudre ce problème à deux niveaux :
Si vous choisissez la seconde solution, les calendars seront cachés également, et vous n'aurez plus besoin dus stocker dans une variable globale. Par ailleurs, comme indiqué dans le warning du début de la page sur la gestion du cycle de vie des composants, les méthodes start(), stop(), etc. sont conçues pour fonctionner avec des composants cachés, et vous pourrez appelez directement la méthode start() du conteneur pour qu'il démarre tous les composants qui implémentent Startable en même temps...
Mise en place des couches de sérialisation : Maintenant, vous avez plusieurs classes terminales Calendar, et vous ne pouvez pas garder les mappings JAXB sur la classe abstraite. Les classes dérivées de celle-ci sont des composants métier, et il n'est pas intéressant dus sérialiser (et cela conduirait à reproduire les mappings dans toutes ces classes, ce qui contredit le pattern DRY). Vous devez donc séparer les données à sérialiser des traitements métier. Pour cela, créez une classe CalendarEntity qui représente la partie données du calendar et encapsule les données à persister.
Si vous appliquez les annotations JAXB directement sur cette classe, celle-ci sera dépendante de la méthode de sérialisation choisie (ici XML). Pour rendre CalendarEntity générique par rapport à sa méthode de sérialisation, vous pouvez :
À ce stade, vous avez réalisé un outil équivalent à un conteneur de servlets. Il pourra fonctionner avec n'importe quelle classe d'implémentation correspondant à l'API du calendar, à partir du moment où celle-ci est déclarée dans le serveur et correspond à une commande reconnue.
Dans cette partie, vous allez rajouter un niveau d'indirection entre le conteneur (et ses composants) et les objets de type CalendarDAO. Pour cela, vous allez implémenter une classe qui permettra à chaque instance de Event créée d'accéder à ce DAO en respectant le pattern Context présenté en cours. Cela permettra par exemple d'utiliser un DAO instancié à l'extérieur du serveur (cas d'une connexion à un SGBD), ou de modifier par configuration le DAO utilisé pour gérer la persistence des données de l'application.
Créez une interface "CalendarContext", de façon à ce que :
En clair, il s'agit d'un objet qui stocke une référence sur un DAO et possède deux accesseurs sur ce champ.
Créez une classe d'implémentation "CalendarContextImpl" de cette interface, instanciez-la dans votre serveur et ajoutez-la en tant que composant de votre conteneur.
Vous allez modifier les composants du conteneur ayant une dépendance sur un objet CalendarDAO pour qu'ils dépendent de CalendarContext.
Enfin, dans le serveur, mettez en place les méthodes correspondantes du contexte de façon à ce que ses clients (calendars) puissent définir et récupérer une référence sur le DAO (setDAO(), getDAO() ?) .
Faites tourner et testez votre application. Vous pouvez ensuite par exemple vous servir du contexte pour filtrer les appels au DAO et ne renvoyer la bonne référence que si la méthode est appelée par un calendar (voir ici ou là pour des exemples de code sur comment trouver la classe appelant une méthode).
Remarque : dans ce cas, supprimez l'appel à la méthode toString() de l'instance du DAO dans l'affichage de la méthode start() des calendars.
Actuellement, votre contexte n'est capable que de gérer un DAO. Modifiez-en l'API pour qu'il puisse stocker des références à tous les types d'objets et que ces objets soient accessibles par un nom (String).
Testez ce contexte générique en lui injectant aussi le calendar entity et en forçant le passage par le contexte pour permettre aux calendars de communiquer avec cette liste.
Votre serveur a désormais une responsabilité supplémentaire : en plus de fournir un conteneur de composants métier, il gère un contexte pour l'isolation des composants du conteneur. Le contexte est accessible à l'intérieur du conteneur pour permettre et contrôler l'accès par les composants aux éléments externes tels que le DAO. Vous avez mis en place les principaux éléments d'un framework applicatif, que vous allez perfectionner dans la suite.
Encapsulez le contexte dans une structure de type annuaire (cf. cours). Un annuaire sera une hiérarchie de contextes, spécifiques à différents éléments de votre conteneur et de vos applications. Ces éléments correspondront aux différents types d'objets à isoler (les calendars, la liste d'événements et le DAO). Faites en sorte que votre annuaire soit capable de décomposer les noms de la manière suivante : nom de contexte + "/" + nom d'objet stocké.
Vous allez maintenant commencer à remplir votre annuaire :
Remarque : les bindings dans l'annuaire s'effectuent avec des références à des instances déjà créées. Ces instances peuvent donc être créées par le conteneur, l'annuaire étant uniquement un moyen de permettre les accès entre ces objets.
Modifiez les classes principales de votre application pour que votre Main démarre séparément l'annuaire, le serveur et le client, et passe aux deux derniers une référence sur l'annuaire. Faites en sorte qu'au démarrage, le client "découvre" le serveur en passant par l'annuaire.
Vous venez de construire quelque chose de similaire à un annuaire JNDI, qui pernet aux composants d'accéder à des références sur des objets interne au conteneur ou distants. L'avantage de cette méthode est qu'elle fonctionne quelles que soient les implémentations du conteneur et du composant, et qu'elle permet d'utiliser plusieurs implémentations différentes d'un objet pour une même interface.
Actuellement, vos objets interrogent l'annuaire pour récupérer des références à d'autres objets. Cependant, il peut arriver qu'une référence sur un objet change, par exemple parce qu'un objet n'est plus disponible ou qu'une nouvelle version a été implémentée. Vous allez donc mettre en place un système à base d'événements qui permettra aux objets clients de s'abonner aux changements des références dans l'annuaire et de donc faire une nouvelle requête à l'annuaire à chaque notification.
Pour cela, modifiez l'implémentation de votre annuaire :
Cette stratégie de mise à jour dynamique d'une référence sur un objet est celle utilisée dans les frameworks à composants dynamiques, comme OSGi. Bien entendu, cette stratégie fonctionnera d'autant mieux si le client s'attend à trouver une implémentation d'une interface et non une instance d'une classe.
Dans cette partie, vous allez rendre votre serveur générique et permettre de lui faire exécuter diféfrentes applications.
Écrivez un fichier de configuration en XML et stockez-y les dépendances de valeurs (type d'objet DAO, nom du fichier de stockage) et les types d'objets Calendar correspondant à chaque commande (à la manière des fichiers web.xml utilisés dans un container de servlets). Ci-dessous un exemple de fichier de configuration :
Remarque : dans le fichier de configuration, vous pouvez également indiquer :
Utilisez ces données dans la classe Serveur lors de l'instanciation des éléments des conteneurs et du contexte. Vous devrez utiliser l'API Reflection (et probablement Class.forName()) pour récupérer le .class défini par une chaîne de caractères.
Éventuellement, vous pouvez spécialiser vos classes Calendar et définir différents types de composants :
Pour mettre en oeuvre cette spécialisation, vous pouvez soit faire hériter chaque type d'une interface spécifique, soit les annoter en fonction d'annotations définies en conséquence.
De la même manière, pour prendre en compte cette spécialisation au niveau du serveur, vous pouvez soit modifier ce serveur (et son mode de configuration) pour que les fichiers XML mentionnent la nature des composants, et que le serveur la "comprenne", soit rajouter un composant intermédiaire qui intercepte toutes les requêtes et s'appuie sur son propre mode de configuration pour instancier et rediriger les requêtes sur ces composants.
À ce stade, vous avez réalisé un serveur d'applications, composé d'un serveur et d'un framework capable de mettre en place et de faire tourner différents types d'applications. Si vous avez réalisé la partie 5.2 en modifiant le serveur, vous avez créé un serveur qui fonctionne d'une manière proche des serveurs Java EE. Si vous l'avez réalisée par ajout d'une couche supplémentaire entre le serveur de la question 4 et l'application, votre serveur se rapproche plus d'un conteneur Spring inclus dans un conteneur de servlets.
Dans cette partie, vous allez changer l'implémentation de la liste de Events gérée par les calendars en remplaçant le composant ArrayList du conteneur par une classe implémentant l'interface List mais dérivant la classe DefaultPicoContainer. Par conséquent, cette liste sera à la fois un composant et un conteneur fils du conteneur existant. D'autre part, vos objets Event deviendront des composants de ce conteneur fils : il va y injecter les dépendances et gérer leur cycle de vie. Vous devrez donc éventuellement modifier la classe Event pour qu'elle soit compatible avec cette nouvelle implémentation.
Dans la classe Serveur, remplacez l'ArrayList qui contient les objets Event par un nouveau conteneur, fils du premier (voir partie "Container hierarchies" de l'introduction sur le site picocontainer). Tant qu'à faire, le conteneur fils utilisera un autre type d'injection de dépendances que le premier : l'injection par annotation de champs. Vous pouvez utiliser deux méthodes pour créer le conteneur fils :
Dans tous les cas, il faut construire le fils en lui passant une référence sur le père (fait dans les exemples ci-dessus) ET ajouter le fils comme composant du père : voir ici (à faire).
Remarque : si l'on veut que le conteneur père puisse résoudre les dépendances des calendars vers le conteneur fils, il faut ajouter ce dernier en tant que component et non en tant que child container dans le père. Contrairement à ce qui est marqué dans la doc, l'appel à la méthode start() du fils sera cascadée correctement.
En tant que composant, faites en sorte que Event implémente l'interface Startable (vous vous servirez de la méthode start() plus tard). Pour cela, il faut que le conteneur fils possède également le comportement "Caching". Modifiez la création du fils en conséquence.
Dans Event, supprimez le constructeur prenant les différents champs en paramètre et précédez la déclaration des champs de la classe Event d'une annotation @Inject (de org.picocontainer.annotations).
Dans cette question vous allez faire en sorte que votre conteneur fils reproduise le même comportement que celui de l'ArrayList utilisée dans les questions précédentes. Par conséquent, le serveur instanciera et gèrera dans ce deuxième conteneur autant de composants Event qu'il y en a dans le calendar. En plus des modifications de la classe Event, il faut modifier les méthodes de service des différents calendars en fonction des règles suivantes :
Ensuite, il faut faire attention à des problèmes spécifiques pour chaque calendar :
Actuellement, votre application gère une liste (conteneur fils) d'événements, qui crée des instances de Event et les rajoute dans le conteneur en fonction des besoins de l'application. Cependant, votre application n'accède jamais à toutes les instances de Event en même temps. Par conséquent, chaque objet Event est instancié, passe la majeure partie de sa vie dans la liste en étant peu utilisé, et est garbage collecté une fois supprimé de la liste. Dans cette partie, vous allez améliorer votre framework pour lui permettre de mieux gérer le cycle de vie des instances de Event pour qu'elles représentent alternativement différents événements stockées sur le support de persistance et se synchronisent avec celui-ci quand c'est nécessaire. Pour cela, vous allez utiliser les méthodes de gestion du cycle de vie des composants pour leur injecter les valeurs issues du support de persistance avant chaque utilisation, et les sauvegarder ensuite.
À ce stade, vous avez dans votre application une arborescence de conteneurs gérant des dépendances entre leurs composants, en utilisant plusieurs types d'injection. Le conteneur père est plutôt destiné aux objets métier de l'application et le conteneur fils aux objets de données. Le conteneur fils tire parti des méthodes de gestion du cycle de vie des composants pour les sérialiser / désérialiser quand ils ne sont pas utilisés. Ainsi, il est capable d'économiser les ressources en n'instanciant qu'un faible nombre d'objets de données et en les réutilisant, plutôt que d'en créer et d'en détruire inutilement.
Si vous avez utilisé la méthode d'injection utilisant le pattern DTO, votre conteneur fils doit être suffisamment générique pour pouvoir gérer des pools d'instances d'une autre classe que Event, pour peu que le DTO injecté soit approprié. À quelques détails près, les éléments qui composent votre serveur sont donc tous génériques. Si le travail de gestion des types de composants, duur dépendances et duur persistance dans un fichier de configuration a été fait jusqu'au bout, vous devriez pouvoir vous resservir de votre framework pour une toute autre application que le calendar.
Vous allez à présent faire de votre conteneur fils un gestionnaire d'entités (similaire à un EntityManager de l'API JPA, en version simplifiée), dédié aux événements. On considérera que le titre d'un événement permet de l'identifier. Pour cela, créez une classe GestionnaireEntite (qui dérive de PicoContainer), et remplacez votre conteneur fils par une instance de cette classe. Il aura accès au DAO (En fonction de votre implémentation du contexte, pensez à lui donner les droits pour appeler la méthode getDao()...) et exposera les méthodes suivantes :
Remarques:
Enfin, modifier les méthodes métier du calendar pour utiliser le gestionnaire d'entités.
Utilisez vos résultats du TP2 pour faire en sorte que votre serveur et votre client communiquent en RMI...