Les intercepteurs dans JBossDans JBoss, lorsqu’un EJB est appelé, il l’est généralement à distance, et en tout cas depuis une interface externe. Généralement, cet appel se fait à travers le mécanisme décrit ci-dessous :
Lorsqu’un client souhaite appeler la méthode faitCeci de l’objet serveur, il dispose généralement d’un proxy sur cet objet, qui lui permet à distance de manipuler l’interface de l’objet serveur. Ce proxy transfère tous les appels de méthodes, via le réseau, à un ServerObject qui fournit une encapsulation complète de l’objet serveur en tant qu’EJB. Dans le cas de Jboss, c’est l’objet ServerObject qui nous intéresse plus particulièrement. Celui-ci dispose en effet d’une liste d’intercepteurs à travers lesquels va passer l’appel de méthode avant qu’il n’atteigne l’objet serveur. Comme il est indiqué dans la figure ci-dessous, l’appel de la méthode va donc être traité d’abord par chaque intercepteur avant que l’EJB ne le reçoive, et, de la même manière, la valeur de retour de cet EJB sera traitée par chaque intercepteur avant que le client ne le reçoive.
Ces intercepteurs sont en fait une mise en oeuvre directe de la programmation orientée aspect au sein d’un programme Java. Ils se placent en effet entre le serveur d’application et l’objet censé être appelé pour fournir des fonctionnalités supplémentaires. Ceci prend tout son sens lorsqu’on sait que ces intercepteurs peuvent traiter de la sécurité de l’appel de méthode, de la mise en place de logs de bas niveau, et, mieux encore, de la persistance. En effet, lorsqu’un EJB persistant est chargé, l’un des intercepteurs qui lui sont associés permet de le persister en base. Celui-ci, à chaque retour de méthode, va vérifier que l’EJB est « clean » ou « dirty », et s’il est « dirty », il va le persister grâce à la gestion de la persistance de Jboss. Par ailleurs, il faut savoir que ces intercepteurs sont traités comme des objets sans état, et sont donc assignés sous forme d’un pool de traitement. L’ensemble des informations relatives à ces intercepteurs est stocké dans un objet de contexte qui, lui, est particulier à l’EJB. Ceci permet donc de marier de très bonnes performances, puisque les données sont stockées à l’endroit le plus utile, avec un très bon design, gage de réutilisabilité et de clarté du code. Enfin, l’utilisation de ces intercepteurs est totalement transparente pour l’utilisateur. Par exemple, la gestion de la sécurité des accès dans Jboss se fait par la modification du fichier ejb-jar d’une web-application, sans jamais avoir à préciser la présence ou non d’un intercepteur. On bénéficie donc ici d’un mécanisme modulaire de gestion des aspects transversaux de l’application, transparent pour l’utilisateur, très modulaire (puisque les intercepteur sont définis dans les fichiers de configuration), et facilement modifiable (puisqu’il n’y a qu’à implémenter un intercepteur spécifique pour modifier l’une de ces fonctionnalités, comme par exemple la sécurité). Il faut néanmoins noter que la mise en place de ces intercepteurs étant une fonctionnalité interne de Jboss, elle ne s’applique qu’au cas des EJBs. Auteur : Nicolas Delsaux
|
||
