Il m'a été donné de poursuivre la précédente mission. Lors de cette phase, j'ai eu l'occasion d'être impliqué de plus en plus dans un processus de qualité. A cet effet, j'ai été chargé de la mise en place et de l'animation de réunions hebdomadaires visant à définir des critères de qualité à différents niveaux :

• la lisibilité, maintenabilité, mise en commun et documentation du code-source,
• la systématisation d'écriture de tests unitaires (notamment via JUnit et CppUnit),
• la mise en place d'indicateurs techniques : utilisation de jMetra pour la métrique, Simian pour la redondance,
• l'intégration continue appuyée par la compilation de nuit (j'ai mis en place cette compilation via les buildfiles Ant présents désormais sur tous les composants, et j'ai eu l'occasion de me familiariser avec AntHill),
• le processus de livraison des composants,
• la prise en compte des besoins et des contraintes des équipes de production, l'aide aux clients.

J'ai pris à ma charge l'extraction d'un cadre de travail Java désormais utilisé sur tous les composants, sous la forme d'une bibliothèque versionnée : cela permet une approche par composant et a permis d'éradiquer une duplication de code-source très coûteuse en terme de fiabilité et de s'affranchir largement du problème de maintenance.

J'ai développé et mis en place un cadre de travail en XML/XSLT permettant de produire des documents sur l'intranet, mais également de produire des notes de livraison : ce dernier est désomais utilisé sur l'ensemble des composants. Pour améliorer la communication sur le projet, j'ai eu l'occasion de mettre en place et d'administrer un serveur Plone V1.0.1, afin de permettre à l'équipe de publier de l'information directement. J'ai d'ailleurs eu l'occasion de développer un produit Plone à l'aide de Archetypes permettant d'intégrer le cadre de travail précédent.

Parallèlement à ce travail, j'ai continué à travailler sur ce projet de migration : j'ai développé des clients autour des nouveaux services afin d'automatiser la mise à jour du référentiel au travers de procédures destinées à l'équipe de production. Par ailleurs, j'ai utilisé l'API Java SSL Foundation Classes afin d'enrichir les services proposés sur la partie temps-réel.

Le projet se déroule dans une équipe en charge de certaines applications de salle de marché, et plus particulièrement les application traitant du marché des options. Les développements se font à part égale entre le C++, au travers de l'EDI Visual C++ V6.0, et Java, au travers de Together Control Center V6 et IDEA V3.

Dans un premier temps, j'ai eu l'occasion de reprendre une application C++ permettant d'exporter et d'importer des données de marché sous le format XML. A cet effet, une grammaire d'export, comparable à SQL, a été définie puis, grâce à ANTLR, puis son analyseur syntaxique correspondant est généré en C++ : cet analyseur permet d'interprêter une requête conforme à la précédente grammaire. Quant à l'import de fichiers XML, il a nécessité le recours à la norme DOM implémentée par Xerces C++ V1.7.0. De plus, afin de valider les fichiers XML d'import, j'ai fait appel à la partie validatrice de Xerces C++ V1.7.0. Certains fichiers XML devant être transformés, j'ai eu recours à l'API de Xalan C++ V1.3 afin d'appliquer des transformations XSLT. Enfin, étant donné que cette application est soumise à une gestion de version forte, j'ai eu l'occasion de développer des scripts Ant permettant sa reconstruction complète (depuis la GCL jusqu'à la construction d'un exécutable d'installation produit par InstallShield Express V3.5, en passant par la compilation et les tests de non régression).

Mon rôle consiste également à la consolidation de services CORBA permettant de manipuler les données de marché : l'implémentation des services se fait de manière complémentire en C++ et en Java, et le bus retenu est ORBIX V3.0.1. Cette consolidation des services est également passée par l'uniformisation des exceptions CORBA renvoyées, au travers de l'ensemble du code d'implémentation. Afin de valider ces services, j'ai eu l'occasion de développer un cadre de travail permettant de tester les services un à un : j'ai eu recours à CppUnit V1.6.2 pour la partie spécifique de test, et à Log4Cpp V0.2.7 pour ce qui est de l'enregistrement sous format XML des résultats. Ce cadre de travail permet de tester la non régression des services d'une version à la suivante, mais également de tester le comportement des services sous la contrainte d'une forte montée en charge (plusieurs clients connectés en même temps). Le fait de produire les résultats en XML permet un traitement ultérieur mettant en relief les problèmes techniques (base de données, CORBA, exceptions non traitées) inhérents aux services, au travers d'une transformation XSLT produisant un compte-rendu complet en HTML. Ces tests étaient bien entendu administrés par un script Ant.

Le projet a eu pour objectif de valider lors d'une phase d'intégration, une application web d'activation de services pour les Virtual Internet Services Provider (VISP) (clients de Siris).

Les services proposés par cette application concernent l'hébergement de pages, la boîte-aux-lettres, la consultation de la boîte-aux-lettre via internet, la déclaration d'un nom de domaine vers les DNS. Afin de bien cerner la problématique du projet, il m'a fallu comprendre plus en détail la manière dont fonctionne le système DNS.

L'application écrite en Java V1.3 a été développée autour de la plate-forme J2EE V1.3 : la partie graphique s'appuie sur cadre de travail Struts, tandis que la partie métier utilise les EJB V1.1. Le serveur d'application n'est pas monolithique, car il est constitué d'une part d'un ensemble de deux serveurs iPlanet Application Server V6.0 configurés en grappe (uniquement pour la partie serveur web et conteneur de Servlet/JSP), d'autre part de différents conteneurs d'EJB V1.1 implémentés par le produit JBoss V2.4.0. Le serveur d'application iPlanet Application Server V6.0 fait massivement appel à un annuaire LDAP  implémenté par iPlanet Directory Server V4 : c'est la raison pour laquelle j'ai dû me familiariser avec la norme LDAP . L'ensemble des développements utilise l'outil Log4j afin de permettre un meilleur suivi de l'application en mode d'exécution. De plus, j'ai eu l'occasion d'utiliser l'outil Ant V1.3 afin de pouvoir automatiser le déploiement de ces services sur les différentes machines physiques hébergeant les conteneurs d'EJB V1.1.

De plus, afin de valider cette application, j'ai eu l'occasion de développer une autre application web permettant d'initialiser et de manipuler la base de donnée de l'application d'activation des services pour les VISP : cette application a été développée et testée sur le conteneur de Servlet/JSP Tomcat V4. Elle utilise la norme JDBC afin de s'interfacer à cette base de données, elle s'appuie sur le Modèle Vue-Contrôleur (MVC) Struts, utilise également le système de trace Log4j, et l'administration de cette application web est réalisée au travers d'un script Ant.

Ce projet, pendant lequel j'ai eu l'occasion d'encadrer trois collègues, a permis de produire un prototype pour un éventuel client. Ce prototype devait mettre en valeur le savoir-faire de la société en matière de conception d'une application web permettant aux employés d'une compagnie d'assurance, d'accéder aux données relatives aux assurés et à leurs contrats d'assurance. Le client souhaitait incorporer à cette application la technologie J2EE V1.3, ainsi que JMS afin de pouvoir réaliser une migration progressive de base de données depuis un système de base de données hérité (système de fichiers "à plat") sur AS400 vers une base de données Oracle V8.

Le prototype a été développé (en Java V1.3) autour de la plate-forme J2EE V1.3. Le conteneur de Servlet/JSP était Tomcat V5.0 lors du développement. Quant au déploiement, c'est le conteneur d'EJB V1.1 WebLogic V6.0 qui a été utilisé. Le bus JMS V1.0 retenu était Sonic MQ V3.5; l'annuaire LDAP  utilisé était iPlanet Directory Server V4. La partie graphique cliente Servlet/JSP a été développée au-dessus du cadre de travail Struts. L'ensemble des développements a été réalisé en utilisant l'outil de traçage Log4j, que ce soit pour la partie Servlet/JSP ou pour la partie EJB V1.1. L'ensemble du projet a été administré à l'aide de scripts Ant partagés par l'ensemble des développeurs. La GCL a été assurée par CVS V1.11.

Afin de répliquer les modifications des utilisateurs dans les deux systèmes de base de données, il a fallu mettre en œuvre un système permettant d'impacter les deux bases à la fois : pour cela, chaque système s'abonne à une queue JMS sur laquelle les messages d'accès aux bases sont envoyés par les EJB V1.1 : à cet effet, les objets sont sérailisés sous forme de Java Beans. Pour ce qui est de l'accès à la base de donnnées Oracle, nous avons utilisé le cadre de travail Castor V0.9.3 qui permet de réaliser très rapidement une surcouche de base de données relationnelle. Afin de pouvoir relier certains messages JMS et de les transformer en requètes vers la base de données, nous avons évalué openadaptor.

Il s'agissait de développer les services CORBA permettant d'accéder aux données dites "référentielles" de la société, afin que les applications existantes n'aient plus à maintenir leurs propres bases de données, mais qu'elles viennent puiser ces données via les services développés.

Le développement s'est majoritairement déroulé sous Windows NT et les déploiements sous UNIX HP : c'est la raison pour laquelle l'outil Ant V1.3 a été massivement utilisé afin d'automatiser les recompilations des sources Java. D'ailleurs, les commandes ClearCase (GCL) étaient naturellement intégrées dans ces scripts.

Le développement s'est articulé autour de la définition des IDL, puis autour de la programmation en C++ et en Java V1.2 des services CORBA sous-jacents. A cette occasion, un générateur de code écrit en Java a été developpé : ce générateur prend en entrée un fichier de descriptions des objects métier en XML, puis, en utilisant l'API JAXP V1.0, il génère les fichiers IDL de définition des services, leur implémentation en majeure partie écrite en C++ mais aussi en Java, puis les serveurs CORBA. Il est à noter que le code C++ généré concernant l'implémentation des services CORBA a recours à la bibliothèque PowerTier V6 : cette dernière réalise ainsi un mapping objet de la base de données (Oracle V8). Ce générateur produit également les fichiers de type Makefile permettant de tout recompiler sous UNIX.

Dans un premier temps, les services CORBA développés s'appuyaient sur ORBIX V3.0.1, puis une migration sur ORBIX 2000 V1.2 a été réalisée : le générateur de code s'est avéré très efficace lors de cette migration. De plus, les spécifications n'étant pas figées, le générateur de code a permis de réagir au plus vite pour s'adapter au jour le jour au modèle des objets métier. Ce dernier était saisi dans Rational Rose puis exporté, transformé à l'aide d'un analyseur syntaxique développé autour de ANTLR, puis transformé en XML.

Le but du projet sur lequel j'ai travaillé était de concevoir un prototype d'application simulant la régulation du trafic aérien pour un jour donné. Mais avant tout, tâchons de comprendre ce qu'est la régulation du trafic aérien.

D'un côté, toute compagnie affrétant un vol qui entre sur le territoire européen doit au préalable informer indirectement Eurocontrol de sa route. D'un autre côté, la zone européenne est découpée en un ensemble de régions, appelées secteurs. Un secteur est contrôlé par au moins un contrôleur aérien. Afin de rendre son contrôle efficace et de diminuer les risques, il est nécessaire de limiter à n'importe quel moment le nombre d'avions traversant chaque secteur; plus précisément, on doit s'assurer que le nombre maximum d'avions ayant traversé un secteur pendant la dernière heure (ce que l'on appelle la capacité) n'est pas dépassé.

Il y avait un système temps-réel en production qui réalisait cette régulation. Ce système, au lieu d'autoriser un appareil à décoller à son horaire prévu, impose du retard afin qu'il n'y ait pas de conflit de capacité sur les secteurs européens. Cela implique que certains vols auront du retard par rapport à leur horaire de décollage, d'autres non. Quoi qu'il en soit, on mesure la qualité du système de régulation selon deux critères : la somme totale des retards des plans de vol, le confort qu'il apporte aux contrôleurs aériens. Mais alors, à quoi sert ce nouveau prototype ?

En fait, nous avons développé ce prototype afin de prouver qu'il existait un mode de régulation plus pertinent, à savoir qu'au lieu de prendre comme mesure le nombre d'avions étant entrés dans un secteur pendant la dernière heure (la capacité), il vallait mieux prendre comme mesure le nombre instantanné d'avions présents dans ce secteur (ce que nous appelons charge). Nous souhaitions montrer que cette méthode réduit la somme totale des retards induite par notre système, comparée à l'ancien système.

Nous avons développé ce prototype grâce à la technologie de Programmation Par Contraintes (PPC). Le prototype a été totalement développé en C++, et il permet de visualiser la demande ainsi que la régulation au travers de l'analyse de graphiques.