Le site

La page du livre AOPSYS AOP-Alliance

R. Pawlak - J.-P. Retaillé - L. Seinturier : La POA répond au besoin de mieux maîtriser les coûts et la maintenance des applications fondées sur la POO en améliorant la séparation et l'intégration des préoccupations au sein des applications. Un premier niveau de séparation et d'intégration consiste à traiter les problématiques techniques et les problématiques métiers indépendamment puis de les intégrer à l'aide de frameworks le plus souvent centrés sur des conteneurs de composants. Ce premier niveau n'est adressé que partiellement par les solutions actuelles comme les EJB tant du point de vue du périmètre fonctionnel couvert que du point de vue de l'étanchéité de la séparation. De plus, la lourdeur de mise en place de ces solutions et leur complexité rend aussi leur accès difficile aux projets de taille modeste.

Quels sont alors les besoins auxquels la POA répond ?
En proposant des mécanismes de séparation des préoccupations génériques et programmables, la POA démocratise une nouvelle dimension de modularisation des applications. Elle permet de modulariser sous formes d'aspects tout type de problématique transversale à une application et permet d'atteindre des niveaux de réutilisation supérieurs à celui des approches par objets ou par composants. Les bibliothèques et frameworks actuels seront les premiers bénéficiaires de la POA car elle leur permettra de s'intégrer aux applications utilisatrices de manière encore moins intrusive, mais aussi et surtout d'étendre leur périmètre fonctionnel à d'autres types de préoccupations pour l'instant peu réceptives aux solutions d'intégration classiques.

La POO a été mise au point dans les années 1960 et semble enfin acceptée par la plupart des développeurs. La POA étant conçue "sur" la POO, pensez-vous que son adoption sera plus rapide ? Nécessitera-t-elle de gros changements d'habitudes ?
Nous pensons que l'adoption de le POA sera indéniablement plus rapide que celle de la POO. Les premiers travaux de recherche sur la POA datent du milieu des années 90, et on commence à en parler en dehors du monde de la recherche seulement depuis 2-3 ans. Sur cette période, plusieurs acteurs importants du monde informatique comme IBM ou BEA ont clairement affiché leur intérêt pour cette technologie et ont contribué au développement d'outils pour la POA. Contrairement à ce qui s'est passé avec le passage à la POO, le passage à la POA peut se faire en douceur.

L'utilisation de la POA nécessite un ticket d'entrée nettement moins élevé que celui exigé pour la POO"

La POA reste donc proche de la POO...
Avec la POA, les applications continuent à être construites en termes de classes : on leur ajoute un ou plusieurs aspects qui viennent enrichir leurs fonctionnalités techniques et/ou métier. Il est ainsi facile de choisir les fonctionnalités à implémenter sous forme d'aspects et de se limiter à un nombre restreint d'aspects stratégiques (sécurité, contrôle de l'intégrité des données, etc.). De ce fait, et une fois les concepts nouveaux introduits par la POA (aspect, coupe, point de jonction, code advice) maîtrisés, il n'y aura pas de changement majeur dans les habitudes de développements. Ainsi, l'utilisation de la POA nécessite un ticket d'entrée nettement moins élevé que celui exigé pour la programmation orientée objet qui impliquait une refonte totale des applications existantes pour bénéficier de ses avancées technologiques.

Les méthodes de développement actuelles, telles que UML, sont-elles compatibles avec la POA ?
Dans le cadre de la mouvance MDA, UML et les outils qui la supportent sont désormais suffisamment ouverts et extensibles pour pouvoir intégrer la POA. Plusieurs équipes de recherche ont montré qu'il est possible de définir des profils UML pour la conception d'une application comprenant des classes et des aspects. Ces profils se fondent essentiellement sur des stéréotypes nouveaux pour l'expression des aspects et des coupes et peuvent être implantés dans des outils MDA tels que l'atelier Objecteering de la société Softeam. Nous pensons que la POA et la MDA peuvent s'entendre dans une symbiose extrêmement efficace. La POA permet en effet à la MDA de simplifier l'écriture des transformations des modèles vers les implémentations (et inversement), alors que la MDA permet à la POA de remonter certains outils de séparation et d'intégration des préoccupations au niveau de l'analyse et de la conception. Les prototypes existants doivent cependant encore montrer leur applicabilité dans le cas d'études de cas significatives issues de l'industrie.

Des applications concrètes ont-elles déjà vu le jour ?
L'atelier de développement UMLAF (UML Aspect Factory) fait partie des exemples concrets qui montrent que la POA et UML peuvent être mis en oeuvre conjointement. UMLAF est construit autour du framework JAC et est proposé par la société AOPSYS. Il offre aux développeurs la possibilité d'exprimer graphiquement des diagrammes d'analyse UML et d'exprimer la conception de l'application à l'aide de configurations d'aspects. L'application générée est directement exécutable, réduisant ainsi l'écriture de code Java et les risques d'erreurs de programmation au minimum.

AspectJ/Eclipse est de plus en plus souvent utilisé comme outil pour améliorer la maintenance et le contrôle des applications via l'intégration d'aspects de trace ou de vérification de contraintes. Les applications entièrement orientées aspect sont encore rares mais on peut noter quelques projets Internet et Intranet de taille conséquente menés par la société AOPSYS sous l'environnement JAC/UMLAF (entièrement POA). Pour les clients qui ont optés pour la POA avec AOPSYS, les applications ont été développées et validées avec succès et sont actuellement pour les plus avancées en phase de mise en production.

Pensez-vous qu'il y aura une "révolution POA" comme la POO a pu en être une ?
Nous préférons parler d'évolution plutôt que de révolution car la POA ne remet pas en cause les autres paradigmes de programmation. Elle s'insère plutôt dans la révolution commencée avec les premiers modèles de composants dont l'objectif de favoriser l'intégration et la réutilisation par rapport au développement spécifique.

En fait, la POA propose un modèle générique de séparation des préoccupations, problématique déjà adressée de manière partielle et spécifique par les systèmes à base de composants comme les EJB dont l'objectif était de séparer les deux préoccupations que sont les problématiques techniques et métiers des composants d'entreprise.

Quel est l'atout de ce modèle générique ?
En offrant un modèle générique de la séparation des préoccupations, la POA favorise l'émergence de nouveaux conteneurs de composants beaucoup plus légers et flexibles que ceux disponibles actuellement. Ces nouveaux conteneurs pourront bénéficier d'une offre d'aspects très riche leur permettant de s'adapter facilement aux besoins des utilisateurs contrairement aux serveurs d'applications à l'approche beaucoup plus monolithique. Par ailleurs, les utilisateurs ne trouvant pas sur le marché d'aspect adapté à leur besoin auront la possibilité de les développer eux-mêmes de la même façon qu'ils développent des composants actuellement.

Mis à part AspectJ, existe-t-il d'autres langages qu'un développeur puisse aujourd'hui utiliser pour "faire la POA" ?
Les développeurs peuvent tout simplement utiliser le langage Java. AspectJ a introduit de nouveaux mots-clés pour couvrir les différents concepts de la POA. Cependant, ces concepts peuvent être couverts sans étendre le langage Java. C'est la position adoptée par plusieurs frameworks comme JAC, JBoss AOP ou AspectWerkz. Au lieu de définir de nouveaux mots-clés, ils fournissent une API permettant de manipuler ces concepts de manière efficace.

Pourquoi avez-vous senti que c'était le moment de faire un livre sur la POA ?
La POA est encore une technologie jeune puisque les premiers outils permettant de l'utiliser concrètement sont apparus à la fin des années 90 avec AspectJ et JAC.

Cependant, ses principes fondateurs sont maintenant bien formalisés et sortent du cadre de la recherche pour celui des applications industrielles. Les principaux éditeurs du monde J2EE ne s'y trompent pas et investissent autour de la POA pour rendre Java plus efficace. Le monde .Net, bien qu'ayant un léger retard sur le sujet, commence aussi à mettre au point des outils de POA (on citera le projet AspectDNG par exemple). L'adhésion de l'industrie du logiciel à ce nouveau paradigme ainsi qu'un intérêt certain de la part des développeurs nous ont encouragés à écrire ce livre.

Et pourquoi se "limiter" à Java/J2EE ?
Plusieurs livres américains sur l'outil AspectJ existant déjà, il nous a semblé opportun d'avoir un ouvrage avec un spectre plus large en couvrant les frameworks de POA 100% Java et les problématiques des applications d'entreprises fondées sur J2EE. Notre livre n'est d'ailleurs en aucun cas centré sur les bonnes pratiques à utiliser dans tel ou tel outil ou langage POA, mais plutôt sur une analyse précise des problématiques couramment rencontrées par les architectes et les développeurs et qui peuvent être résolues de manière plus efficace avec la POA, exemples à l'appui.

Nous espérons ainsi faire profiter nos lecteurs d'une vision globale de ce nouveau paradigme et d'un guide de mise en oeuvre de la POA sur des problématiques concrètes.