1. Bonjour Olivier, peux-tu te présenter ?
Olivier Gattaz, fondateur d'une jeune entreprise innovante grenobloise qui s'appelle isandlaTech dont l'objet est de promouvoir le développement d'applications à base de components-based software engineering. Pour cela, nous déployons et développons une plate-forme, Cohorte, qui a pour principale caractéristique d'être une solution pour bâtir des logiciels à composition dynamique.
2. De façon générale, comment fonctionne Cohorte ?
En fait, nous sommes partis d'un principe qui nous a paru simple. Pour fabriquer une application sûre, il s'agit de ne pas créer un monolithe, mais au contraire un ensemble de composants qui se rendent mutuellement service, et qui ensemble rendent le service fonctionnel escompté. Une fois que l'on a dit ça, la problématique derrière est donc comment le faire le plus simplement et automatiquement possible. C'est là qu'intervient Cohorte. Cohorte est avant tout un outillage pour déployer des compositions que l'on aura conçu préalablement avec une méthodologie connue, en l'occurrence SCA. En effet, nous pouvons voir Cohorte comme un conteneur SCA dynamique, versus ce qui existe aujourd'hui et qui est plutôt à tendance statique.
Nous sommes grenoblois, et le laboratoire informatique de Grenoble est un pôle OSGi important. De ce fait, de nombreux travaux sont sortis de l'université, ainsi qu'un certain nombre d'individus, qui font de façon implicite que Cohorte aie été bâti au dessus d'OSGi. La problématique que l'on a rencontrée assez rapidement c'est lorsque l'on a voulu construire des logiciels à composants qui devaient s'exécuter sur des plateformes un peu contraintes, telles que des plateformes ARM ou low resource, le coût de la VM Java devenait incompatible avec ces plateformes. Grâce à la présence des bonnes personnes, au bon endroit, au bon moment, une idée est née et nous avons pu partir sur une implémentation complète d'un framework OSGi équivalent à Felix en Python. Et au dessus de ce framework appelé Pelix, nous avons bien entendu implémenté un SOCM [NdR: Service-Oriented Component Model] ersatz de iPojo avec les mêmes principes, les mêmes mécanismes et des annotations complètement similaires. En l'occurrence, c'est l'objet de notre présence ici à Ludwigsburg [NdR: à l'EclipseCon Europe 2013]. Thomas a pu présenter les grands principes et l'état actuel de Pelix et iPopo dans le cadre des Lightning Talks qui ont eu lieu mardi soir.
L'intérêt d'être présent sur une conférence c'est d'annuler les distances, même si nous travaillons très régulièrement par le biais de moyens électroniques. La mise en présence d'individus facilite les choses. Nous avons pu rencontrer Luminis qui travaille sur Celix, également des personnes d'IS2T qui travaillent sur des implémentations Java faible empreinte, ou encore des personnes d'ECF [NdR: Eclipse Communication Framework], Markus entre autres, pour finalement envisager l'utilisation des mêmes protocoles dans toutes ces implémentations de Remote Services pour que l'on puisse inter-opérer beaucoup plus facilement que l'on ne le fait aujourd'hui. Typiquement, aujourd'hui, l'implémentation Cohorte de Remote Services est complètement opérationnelle entre nos mondes Python et nos mondes Java, avec des échanges de bin, etc. Par contre, nous ne sommes pas capables de dialoguer avec Celix, ni de dialoguer avec un autre framework OSGi qui aurait utilisé ECF. Donc l'idée est de promouvoir au moins un protocole implémenté sur chacune des plateformes (protocole de transport et protocole de découverte) pour que l'on puisse inter-opérer et faciliter encore l'usage des plateformes OSGi, quelles qu'elles soient.
5. Et sur Cohorte lui-même, en termes de roadmap, comment vois-tu les choses ?
Cohorte aujourd'hui, nous pouvons considérer qu'il y a déjà une version 1 en cours d'utilisation. A Grenoble, il y a le laboratoire PREDIS G2Elab qui l'utilise pour refondre totalement un système de SCADA, en l'occurrence d'instrumentation de laboratoires. Cela fonctionne bien. Nous passons à l'échelle, nous instancions des dizaines de milliers de composants, ce qui est tout à fait satisfaisant. Maintenant que cette plate-forme existe, il s'agit maintenant de vraiment prendre à bras le corps l'intérêt de Cohorte comme le comportement autonomique, c'est à dire l'auto-configuration et l'auto-recomposition en fonction d'évènements extérieurs tels que la disparition d'un noeud, etc… Voilà ce qui va vraiment venir durant l'année et qui va se traduire par l'apparition de briques puisque nous fonctionnons par briques que l'on offre à la communauté. Par exemple, des briques comme Pelix, iPopo, Cohorte Remote Services sont en Apache v2 et disponibles sur GitHub. Pour Cohorte et Remote Services, cela va être fait dans les semaines qui viennent. Nous avons juste une petite problématique de licence avec un sous-composant, et a priori nous avons trouvé la solution ici. d'où l'intérêt encore de la conférence!