M2TIW : Intergiciels et Services
Expérimenter une architecture à base de composants téléchargeables dynamiquement.
Dans ce TP, vous utiliserez :
GlassFish est basé sur une implémentation d'OSGi nommée Felix. Lancer GlassFish, démarrer le domaine (domain1 par défaut), puis utiliser la commande osgi-shell pour démarrer le shell Felix.
Utiliser la documentation située ici pour démarrer. Par exemple, taper "lb" (list bundles) pour avoir la liste des bundles installés par défaut.
Explorer le Oscar Bundle Repository. Choisir et télécharger un ou plusieurs bundle(s), installer, lancer et stopper ce(s) bundle(s) comme indiqué là. Normalement, vous devez voir s'exécuter les méthodes de gestion du cycle de vie start() et stop(), d'implémentation de l'interface BundleActivator.
Vous allez maintenant réaliser vous-même un bundle OSGi, en suivant le tutoriel situé ici. Une fois les fichiers recopiés et les jars faits, suivre la même procédure que précédemment pour les déployer et les démarrer. Vous devrez démarrer les bundles suivants (dans "annotations/hello.felix.annotations/target/bundle") : org.apache.felix.ipojo-1.12.1, hello.service-1.12.1, hello.impl.annotations-1.12.1 et hello.client.annotations-1.12.1.
Vous allez maintenant utiliser le serveur d'applications GlassFish pour faire tourner vos bundles.
La première chose à faire est de télécharger, dézipper et démarrer le serveur, comme indiqué ici : https://glassfish.java.net/download.html. Vous trouverez la documentation complète sur l'administration de GlassFish ici https://glassfish.java.net/docs/4.0/administration-guide.pdf et sur l'utilisation d'OSGi dans GlassFish là : https://glassfish.java.net/public/GF-OSGi-Features.pdf.
Lancer le serveur (pour cela, ouvrir un shell et lancer la commande asadmin) ; le prompt doit indiquer "asadmin". Lancer ensuite un domaine (start-domain). Pour ouvrir une console Felix, taper la commande osgi-shell. Pour taper vos commandes Felix dans cette console, vous pouvez :
Installer la console Web OSGi et vérifier son fonctionnement sur http://localhost:8080/osgi/system/console/bundles. Vous pourrez vous y connecter avec l'utilisateur "admin/admin". Pour cela, télécharger la dernière version du zip du module ici, prendre les 3 jars et les installer dans la console gogo de Glassfish
Vous allez maintenant déployer les bundles que vous avez réalisés. Pour cela il faut d'abord modifier les fichiers manifest.mf car ceux des tutoriels de Felix n'utilisent pas la même version du langage de définition des manifest. Vous devez :
Cela fait, installer et démarrer vos bundles. Normalement, vous devriez les voir apparaître dans la liste des bundles déployés. Dans tous les cas, vous avez dû voir le rapport de déploiement dans la console.
Aller ensuite dans la console d'administration de GlassFish, cliquer sur le "Bundle-SymbolicName" de votre composant et cliquer sur "Install/Update...". Attribuer à ce composant un startLevel de 3 et valider. Normalement, vous devriez le voir apparaître comme "Active". Vous pouvez donc désormais appeler les méthodes de gestion du cycle de vie et de service de ce composant de la même manière que s'il était dans un autre type de conteneur.
De la même manière que dans les TP précédents, vous allez reprendre votre application d'agenda après la partie "uniformisation" du TP1. Créer trois bundles contenant :
Packager sous forme de Web Application Bundle (WAB) - Aide : http://coding.alasdair.info/2011/01/creating-web-application-bundle-using.html et http://www.javabeat.net/writing-an-osgi-web-application/ - et déployer dans GlassFish. Tester.
Vous allez maintenant "sortir" les agendas du serveur et les placer dans des bundles séparés. Vous n'avez donc plus besoin d'un conteneur dans le serveur. Créer les bundles suivants :
Indication : issue de la page d'accueil d'OSGi, à propos du fait que vos agendas implémentent la même interface.
What happens when multiple bundles register objects under the same interface or class? How can these be distinguished? The answer is properties. Each service registration has a set of standard and custom properties. A expressive filter language is available to select only the services in which you are interested. Properties can be used to find the proper service or can play other roles at the application level.
Réaliser un autre composant qui implémente l'interface de l'agenda, et qui renvoie une réponse de type "service non disponible". Donner à ce composant un numéro de version inférieur à celui des agendas "fonctionnels". Modifier le fonctionnement de votre serveur pour qu'il cherche l'agenda correspondant à une commande donnée et qu'il switche sur cette implémentation par défaut quand il ne trouve pas cette commande dans les agendas disponibles (par exemple, avec un OR dans le filtre que la propriété indiquant la commande).
Simuler une panne en déployant et supprimant un service fonctionnel, sans arrêter le framework, et l'interroger entre temps avec le client. Vérifier que le framework vous renvoie bien la dernière version du service demandé.
Modifier l'interface Web pour qu'elle permette d'envoyer au serveur toutes sortes de commandes et de paramètres correspondant à son interface. En clair, rajouter un champ texte qui permettra de taper une commande.
Côté serveur, récupérer cette commande et la passer en paramètre de l'appel de service. Suite au mécanisme de fallback de la question précédente, vous devez obtenir le message d'erreur générique.
Déployer un service fonctionnel correspondant à cette commande, sans arrêter le framework. Ré-interroger ce service avec le client et vérifier son fonctionnement.
Vous devez maintenant pouvoir déployer n'importe quel composant et l'interroger avec votre client Web.
Ce TP est à rendre pour le 6 décembre 2016 à 23h59.