Avalon - Présentation
				12 Octobre 2003
				Version 1.0
				Par Sébastien MERIC
				Remerciements : Stefan Bertholon

Introdution

Je vous présente dans cette série de 4 tutoriels un petit cours sur le Framework Avalon, un framework de développement de composants serveurs pour développement en java. Avant de présenter le framework lui-même, je présente quelques-uns des concepts de l'architecture logicielle sous la forme d'une rapide FAQ Architecture Objet. Attention, cette série de tutoriels forme un cours théorique sur les concepts objets utilisés dans Avalon et non une description complète sur l'utilisation du framework. Pour me motiver à me lancer dans un descriptif plus complet, n'hésitez pas à me contacter, si de nombreux membres de la communauté developpez.com font preuve d'un véritable intérêt pour Avalon, je partirai dans un cours plus technique sur l'utilisation d'Avalon.

Généralités

Qu'est-ce qu'un framework ?

Puisqu'on va se concentrer sur la présentation d'un framework, que le terme est un anglicisme et que ce n'est pas nécessairement une notion comprise de tous, je vous fournis une définition de ce terme tel qu'il est en général compris par nos collègues qu'ils soient développeurs, décideurs, architectes, ... Je reprend la définition rapide que je vous avais donné à l'occasion de l'article sur les framework de tests et particulièrement sur la série JUnit, DUnit, NUnit, etc. :

Un framework est une infrastructure logicielle qui facilite la conception des applications par l'utilisation de bibliothèques de classes ou de générateurs de programmes, soit dit en quelques mots : un cadre de développement.

Voyons un peu plus en détail de quoi il s'agit, et commençons par citer quelques frameworks, rien de tel que quelques exemples pour comprendre une notion :

• Struts est un framework java d'interfaçage homme machine pour applications web.
• SWING est un framework java d'interfaçage homme machine pour une application fenêtrée.
• Les MFC sont un framework C++ d'interfaçage d'une application avec le sytème d'exploitation windows.
• la GTK est un framework C d'interfaçage homme machine avec une application fenêtrée, conçu à l'origine pour les systèmes unix et porté sur windows.
• OJB est un framework java de mapping objet/relationnel gérant la persistance d'objets dans un SGBD.
• ...

Il apparaît qu'il existe des framework de divers types, et que ceux-ci peuvent être complémentaires. Les frameworks présentés ci-dessus ne sont pour autant pas suffisants pour permettre de développer une application complète. Pour ce faire, il faut alors fabriquer un framework plus complet. Ce sera en général un assemblage de divers frameworks complémentaires qui fourniront ensemble, le cadre de développement de vos applications.

Maintenant que nous avons réussi à nous faire une idée sur la notion, il devient possible de la formaliser un peu : un framework réunit l'ensemble des implémentations récurentes de nos développements. Les avantages en sont :

• éviter de recoder encore et toujours les mêmes bouts de codes, qui sont d'ailleurs généralement rébarbatifs,
• agir en un point unique pour modifier l'ensemble du comportement applicatif (Par exemple le "look and feel") faisant profiter toutes les applications des avancées du framework,
• assurer la robustesse de ces parties du code qui, puisqu'elles sont répétitives, sont essentielles.

Qu'est-ce qu'une API ?

Une API est un point de jonction entre un logiciel et l'extérieur de celui-ci. C'est un peu la partie public d'un programme complet. Ainsi l'API JDBC est le point de jonction entre java et les SGBD, Sun y a défini la manière d'accéder à une base de données depuis java et les divers éditeurs de SGBD ont étendu le langage java grâce à cette API pour permettre aux développeurs d'accéder à leurs bases de données. De la même manière, les éditeurs d'EDI proposent toujours une API qui permet à des développeurs indépendants de fournir des modules d'extension. On retiendra donc que l'API est un module d'accès à un logiciel qui définit l'interface (au sens purement objet du terme) d'extension de celui-ci.

Mais alors SAX et DOM ne rentrent pas dans cette définition, pourtant on parle bien d'API ? Si, SAX et DOM sont des API de très haut niveau qui régissent l'accès à une information formatée en XML. Il existe diverses implémentations de ces API dans tous les langages, qu'ils soient Objet ou qu'il ne le soient pas. Java connait plusieurs implémentations, C et C++ aussi etc.

Qu'est-ce qu'un composant ?

Un composant est le couple formé d'une interface définissant la structure objet nécessaire à la réalisation d'un travail et de son implémentation. Ceci est certes un peu abstrait, reprenons donc une description qui part de l'élément le plus atomique de vos langages, et remontons rapidement jusqu'au composant. De manière atomique, en UML nous disposons sur le diagramme de classes, d'attributs, de méthodes, de relations. L'attribut représente un état, la méthode définit une dynamique et les relations indiquent la syntaxe (l'articulation). Pour réunir ces divers éléments atomiques, nous disposons de classes d'interfaces, de packages. Pour réunir ensemble des classes ayant des comportements agissant dans le même sens, nous réunissons donc diverses classes, interfaces, etc. au sein de composants. Les divers composants communiqueront d'ailleurs par le biais d'une façade.

Qu'est-ce que le cycle de vie ?

Le cycle de vie d'un objet est évidemment la gestion de sa naissance, de sa vie et de sa mort. Mais c'est aussi beaucoup plus que ça, la naissance par exemple d'un objet est toujours subordonnée à l'apparition d'un événement (au sens large). A sa naissance, il peut aussi se produire un ensemble de choses comme son initialisation, la récupération de l'état dans lequel il se trouvait avant de mourir la dernière fois (persistance). Il en est évidemment de même au moment de sa mort, il peut nécessiter de rendre son état persistant, de fermer des connections réseaux ouvertes, etc. Enfin l'objet peut avoir besoin de se reconfigurer à tout moment (prenez l'exemple d'un fichier de configuration web.xml s'il est modifié, le serveur web se reconfigure pour prendre en compte les nouvelles données). Le cycle de vie d'un objet ou d'un composant est donc l'ensemble des méta-états, relatifs à son existence, qu'il peut prendre et des transitions qui lui permettent de passer d'un état à l'autre. Parmi les méta-états de vitalité de l'objet nous pouvons citer rapidement : configurer, initialiser, vivant, mort, ...

Qu'est-ce que le développement en couches ?

Tout le monde a au moins entendu parler des couches du protocole TCP IP qui régit tout nos échanges sur internet. Le principe est assez simple mais très efficace, 7 couches ont été définies pour le protocole, des couches les plus basses c'est-à-dire physiques aux couches les plus hautes comme par exemple le SMTP qui achemine nos emails. Ce concept permet d'utiliser un câble coaxial, un réseau WIFI, de la fibre optique (couche la plus basse) en ne modifiant que cette couche. Le même logiciel de transport de mails est utilisable sur tous ces supports sans la moindre modification.

Ce concept peut être appliqué à tous nos développements, et on cherche aujourd'hui à séparer ceux-ci en diverses couches afin d'être indépendants de chaque implémentation de ces couches. Un logiciel développé sur 4 couches : SGBD/Mapping/metier/affichage aura l'avantage de permettre de changer tant le SGBD que le choix d'affichage (WEB ou fenêtré etc.) sans pour autant redévelopper intégralement celui-ci.

Pour que ce concept soit réellement puissant, il est important de suivre le principe suivant : une couche a accès à la couche immédiatement inférieure et uniquement celle-ci par le biais d'une interface stable. Ceci lève trois points importants : le sens des dépendances est toujours du haut vers le bas (une couche ne connait absolument rien des couches supérieures), la dépendance aux couches inférieures est strictement limitée à celle directement inférieure. L'interface de discussion entre couches doit être stable, elle doit quasiment être définitive et doit donc faire l'objet d'une attention particulière au moment de l'analyse de l'architecture logicielle.

Présentation d'Avalon

Qu'est-ce qu'Avalon ?

Un petit historique s'impose pour vous parler d'Avalon par respect et pour remercier les auteurs de cet outil et de la réflexion qui l'entoure. A l'origine d'Avalon, se trouve Apache JServ, un serveur de servlets duquel un certain nombre de patterns ayant servis à son développement sont apparus suffisamment génériques pour construire un framework d'application serveur. A l'origine de ce projet, se trouve donc Stefano Mozzocchi, Fedirico Barnieri et Pierpaolo Fumagalli. Vous trouverez les informations originales sur ce framework sur le site d'apache : avalon.apache.org

J'ai déjà un peu dévoilé ce que contient Avalon en vous annonçant que c'est un framework. C'est en fait plus qu'un framework, c'est le père d'un ensemble de 5 sous-projets : le framework lui même, Excalibur, LogKit, Phoenix et Cornerstone. La partie qui nous intéressera dans cette série d'articles est évidemment le framework et surtout les idées qui ont permis de mettre en place celui-ci. Que vous décidiez d'utiliser le framework ou que vous partiez sur d'autres frameworks ne vous empêchera pas de garder en tête les excellentes réflexions sousjacentes à son développement.

Le coeur ou le framework

Quand on entend parler d'avalon, c'est souvent à ce coeur que l'on pense, il contient un ensemble de patterns à même de transformer fondamentalement notre manière de concevoir une application (au moins pour les applications serveur). C'est cette partie d'Avalon que je vous propose de découvrir dans ce cours qui se présentera sous la forme d'une série de tutoriels.

Excalibur

Excalibur regroupe un ensemble de composants déployables côté serveur parmi lesquels on trouvera des pools d'objets, la gestion de connection base de données et la gestion d'implémentations de composants.

Logkit

Un ensemble d'outils de log compatible JDK 1.2 basé sur les mêmes concepts que Log4J ou le package logging inclus dans le jdk 1,4.

Phoenix

Phoenix est le noyau de gestion du déploiement et de l'exécution de services.

Cornerstone

Cornerstone quant à lui implémente une collection de services déployables dans Phoenix. On y trouve en particulier la gestion de socket, un timeScheduler, un service de publication de services à distance via SOAP, un SAX Factory, un système de persistance d'objets transparents, etc.