Gros plan sur la conférence ApacheCon NA 2010

Début novembre s’est tenue la 11ième édition de la conférence ApacheCon North America 2010 à Atlanta (GA). Cet évènement incontournable dans le milieu de l’open-source a eu lieu dans un des hôtels les plus imposants de la ville. Se sont réunis des membres de la Fondation Apache, des commiters, des contributeurs ou simplement des utilisateurs désireux de connaître les dernières nouveautés. Les projets ou les technologies phares comme Tomcat, Lucene ou NoSQL ont bien évidemment été présentés mais également les tous derniers projets Apache encore au stade d’incubation.

En plus d’être sur place pendant les trois jours de la conférence, j’ai eu le plaisir de présenter un sujet autour de l’intégration OSGi/Flex.

La fondation Apache en quelques mots

Plus qu’une infrastructure hébergeant des projets open-source, l’ASF (Apache Software Foundation) est une communauté de développeurs et d’utilisateurs partageant des valeurs communes. Le dénominateur entre tous ces projets est bien sûr la licence Apache (Apache Software License).
En quelques chiffres, la Fondation compte 330 membres et plus de 2500 commiteurs. Les commiteurs participent aux développements des projets et à la rédaction de la documentation. Les membres sont eux mêmes des commiteurs qui ont un pouvoir décisionnel. Ils participent notamment aux élections permettant d’introduire de nouveaux commiteurs.
Il y a actuellement une centaine de projets open-source considérés comme « Apache Top-level Projects (TLP) ». Qui n’a jamais entendu parler d’Apache HTTP Server, de Tomcat, de Subversion ou encore de Maven ?

Programme de la conférence

Les présentations se sont succédées sur trois jours, avec pour chaque jour, plusieurs sessions dédiées à un projet ou une technologie particulière. Voici une partie des sujets qui ont été abordés tout au long de la conférence et auxquels j’ai pu assister.

NoSQL

Ce thème permet de se familiariser avec les bases de données distribuées Cassandra et HBase (nouvellement TLP) qui permettent de mieux répondre à des problématiques de montée en charge et de réplication par rapport aux bases de données relationnelles.
A noter la présentation du projet Solandra comme étant la combinaison du moteur de recherche Solr et de Cassandra. Les bénéfices résultant d’une telle intégration sont la prise en charge de la réplication des indexes, de la gestion du fail-over et de la haute disponibilité.
Encore assez peu connue ou parfois considérée comme une tendance, la technologie NoSQL est une vraie réalité avec des acteurs majeurs comme Google, Facebook ou encore Twitter pour ne citer qu’eux qui l’emploient pour stocker et analyser des millions d’informations en temps réel. Ce sont ces mêmes acteurs qui contribuent aux projets open-source.

Content Technologies

Ce thème introduit un certain nombre de projets ayant pour objectif de faciliter la structuration des données et leur accès. On peut citer la présentation du projet Apache Sling qui est un framework web basé sur OSGi permettant d’organiser du contenu en s’appuyant sur la spécification JCR (Java Content Repository). La lecture ou l’insertion de données dans le dépôt se fait au travers d’une API REST. Par défaut, l’implémentation de la JCR qui est utilisée est Apache Jackrabbit.
Dans un tout autre registre, si vous cherchez à lire ou produire des documents Microsoft Office (Excel, Word ou PowerPoint), le projet Apache POI répond peut-être à votre besoin. L’équivalent pour les fichiers PDF s’appelle Apache PDFBox.

Hadoop

Apache Hadoop permet de développer des applications hautement disponibles, supportant le passage à l’échelle et le calcul distribué. Durant les présentations, quelques problématiques pouvant être traitées avec Hadoop ont été abordées.

Tuscany

Apache Tuscany est une implémentation de la spécification SCA (Service Component Architecture). Le but de ce standard est de déléguer la gestion des communications entre les différents modules métiers d’une application ou entre plusieurs applications. L’application est ainsi découpée en plusieurs composants qui requièrent ou exportent des services. Le protocole utilisé pour lier les composants entre eux est spécifié dans la configuration (WS, JMS, REST, JSON, JCA, …). Il est également possible de définir la qualité de service, de sécuriser les échanges ou encore de travailler dans un environnement transactionnel.
Dans la perspective de construire des applications qui gèrent nativement le Cloud, la notion de service est primordiale tout comme la possibilité de distribuer facilement l’application.

Mahout

Apache Mahout fait parti des « Apache TLP » et propose une bibliothèque extensible pour le « machine learning » (apprentissage automatique) à partir de gros volumes de données. La distribution des traitements sur des clusters, le classement et le filtrage basé sur des batches collaboratifs sont implémentés grâce au projet Apache Hadoop. Concrètement, Mahout permet de faire des suggestions à partir des habitudes des utilisateurs ou de grouper des documents de même sujet. Dès lors qu’un certain nombre de documents sont catégorisés, il est ensuite possible de classer d’autres documents sans sujet explicite en parcourant leur contenu.

Geronimo

S’agissant des sessions liées au serveur d’applications Apache Geronimo, l’une d’elle, donnée par Jarek Gawor, détaillait la version 3.0 du serveur qui s’appuie désormais sur un noyau OSGi, tout comme la majorité des serveurs d’applications open-source tels que JOnAS 5, GlassFish 3, etc.
Cette dernière version implémentera la plupart des spécifications OSGi Enterprise qui ont pour objectif d’offrir aux applications OSGi une palette de services techniques issus du monde JavaEE tels que les services de persistance, de transaction, de nommage (pont entre JNDI et le Service Registry d’OSGi), ou encore d’administration du conteneur OSGi via JMX.
Comme le cœur du serveur est basé sur OSGi, cela offre également la possibilité de faire cohabiter des applications JavaEE avec des applications OSGi, voire même d’exploiter des services OSGi au sein d’applications JavaEE. Il est donc possible de développer des applications d’entreprise à la fois modulaires, dynamiques et robustes.

Tomcat

Plusieurs présentations ont traité de la nouvelle version de Tomcat, dont celle de Tim Funk qui a présenté les principales nouveautés présentes dans Tomcat 7.

• Détection des fuites mémoires et prévention de plusieurs cas possibles (connexions JDBC, threads non stoppés, ressources jamais fermées, …). Cette solution est décrite comme non optimale mais est sensée faire gagner du temps aux développeurs en phase de développement.
• Possibilité de faire référence à des ressources statiques (sur le disque) depuis le contexte de l’application. Jusqu’à présent, cela nécessitait l’utilisation d’un serveur HTTP Apache qui rendait disponible les ressources du système. Désormais l’attribut alias de l’élément Context permet de décrire ce mapping.
• Facilité de développement avec le support des servlets 3.0
  • Le fichier web.xml devient optionnel et peut être remplacé par des POJOs annotés
  • Utilisation des Web fragments pour séparer les descripteurs de déploiement des bibliothèques embarquées dans le WAR (web-fragment.xml) du descripteur de déploiement de l’application web (web.xml).
  • Extension de l’API ServletContext afin de définir programmatiquement des servlets ou des filtres.
  • Traitement asynchrone des Servlets afin de ne pas rendre bloquant l’accès à certaines ressources telles qu’une base de données ou un Web service.
• Meilleur support du lanceur Tomcat embarqué
• Amélioration de la sécurité

OSGi

Durant la dernière journée de la conférence, un slot était entièrement consacré à OSGi.

Building complex and modular applications with OSGi and Flex

Ma présentation propose une architecture permettant de construire des applications riches et modulaires en intégrant les technologies OSGi et Flex. La mise en œuvre d’une telle solution comporte deux parties distinctes.
La première chose à étudier est le moyen par lequel l’application Flex (côté client) va communiquer avec le backend OSGi. Flex fournit une API permettant d’accéder à des services distants, comme par exemple des Web services ou des services accessibles au travers du protocole AMF (protocole binaire initialement créé par Adobe et qui est devenu un standard). L’idée étant de rendre disponible les services OSGi à l’application Flex et également d’établir un pont entre les évènements Flex et OSGi. Concernant ce deuxième cas de figure, un évènement émis par un bundle OSGi doit pouvoir être reçu par un consommateur Flex et inversement.
Le support des communications entre OSGi et Flex est apporté par l’utilisation d’une brique logicielle tierce : AMF3 for OSGi. Ce projet rend possible l’exposition de services OSGi au travers du protocole AMF. Le pattern publish/subscribe est également pris en charge afin d’être capable d’émettre et de recevoir des messages sur un topic donné, à la fois côté client et côté serveur.
La seconde partie concerne la modularisation complète de l’application. Flex dispose d’une solution de modularisation d’applications : les modules. Ce sont des sous parties de l’application qui peuvent être chargées ou déchargées à chaud. Dans cette perspective, un bundle OSGi correspondant à l’application globale est nécessaire. L’interface graphique qu’il contient (fichier SWF) décrit le squelette de l’application. Il enregistre également un service OSGi retournant l’ensemble des modules Flex disponibles sur la plate-forme. A l’activation de ce bundle, l’ensemble des ressources qu’il contient sont publiées au travers du service HTTP.
Les modules Flex disponibles sont embarqués dans des bundles séparés et contiennent leur propre logique métier. Ils sont pris en charge par le bundle principal afin d’être enregistrés auprès du service HTTP. Une fois cette action réalisée, l’application Flex est notifiée du départ ou de l’arrivée d’un module afin de déclencher son chargement ou son déchargement.
Ma présentation se conclue par une démonstration d’un système de supervision. Un module permet de récupérer des informations générales sur la JVM, tandis que deux autres modules affichent la consommation CPU et mémoire de la JVM. Un dernier module affiche la liste des bundles du runtime OSGi. Chacun de ses modules enregistre des services OSGi qui sont accédés par le client Flex.
Je présenterai très prochainement ce sujet lors d’une conférence dans les locaux de Zenika. En attendant, vous pouvez d’ores et déjà récupérer les slides de la présentation.

Managing an OSGi Framework with Apache Felix Web Console

Chaque conteneur OSGi est distribué avec son propre shell (ligne de commande) permettant d’administrer la plate-forme. Des initiatives comme le projet Apache Felix Gogo implémente la RFC 147, un standard visant à homogénéifier les commandes d’administration.
Felix Meschberger a présenté le projet Apache Felix Web Console qui a pour but de fournir une console d’administration web extensible. Elle permet de visualiser l’ensemble des bundles et services de la plate-forme, d’agir sur leur état, d’installer de nouveaux bundles à partir de l’OBR (OSGi Bundle Repository), de créer des configurations, etc. A cet ensemble de fonctionnalités existantes, il est également possible de créer ses propres modules d’administration qui apparaitront comme de nouveaux onglets.
Parmi les fonctionnalités intéressantes, il y a la gestion i18n, la possibilité d’extraire la configuration courante sous forme d’une archive ou encore la personnalisation du style et le bandeau de l’application.

OSGi Design Patterns and Best Practices

Une présentation particulièrement intéressante a été faite par Marcel Offermans sur les bonnes pratiques de développement d’applications OSGi. Voici quelques unes des recommandations qu’il est bon d’avoir en mémoire.
Bien que l’utilisation d’OSGi apporte une réelle architecture modulaire, il faut faire attention à ne pas tomber dans l’exagération. Pour minimiser la complexité, il est préconisé de réduire les dépendances, de limiter chaque bundle à une partie de l’application qui pourra évoluer indépendamment des autres, quitte à embarquer les bibliothèques dans les bundles qui les utilisent si elles ne sont pas partagées. Il est fortement recommandé de versionner tous les packages exportés. La politique de numérotation des versions est également très importante car elle détermine le degré de compatibilité entre chaque version.
Depuis la version 4.2 de la spécification OSGi (Launcher API), une section décrit l’instanciation et le démarrage du framework à partir d’une configuration afin de ne pas dépendre directement de l’implémentation sous-jacente. Lors du démarrage, il est déconseillé de se baser sur l’ordre des bundles et ne pas hésiter à tester un ordre aléatoire. La suppression du cache du framework à chaque redémarrage est également une mauvaise pratique car elle peut masquer des dysfonctionnements de l’application et on perd le bénéfice du temps de création du cache ainsi que l’état dans lequel on se trouvait avant d’arrêter le framework.
La notion de service est également importante car elle permet de découpler les modules entre eux. L’interface doit être pensée pour pouvoir coller autant que possible aux futures implémentations. De plus, la gestion des dépendances de services devrait toujours être prise en charge par des frameworks à composant (iPOJO, SCR, Blueprint, …).
Cette présentation s’est terminée par un aperçu de quelques design patterns qui facilitent la conception d’applications modulaires comme par exemple le Whiteboard Pattern (« don’t call us, we call you ») ou le Null Object Pattern qui permet d’éviter de conditionner son code en fonction de la disponibilité ou non de certaines dépendances.

Conclusion

Pour aller plus loin, vous pouvez consulter le programme complet de la conférence ApacheCon NA 2010 et également récupérer l’intégralité des slides sous forme d’une archive.
La conférence s’est donc achevée avec un grand nombre de présentations intéressantes, souvent données par les leaders des projets eux-mêmes. Je suis toujours autant étonné par les synergies qui existent entre les projets Apache. Ces derniers privilégient l’intégration avec d’autres projets de la Fondation ce qui profite à tous les projets et accentue les collaborations et les contributions. C’est probablement une des raisons pour laquelle les projets Apache sont si populaires.