Impératifs techniques

A l'origine les bornes Oscar étaient uniquement destinées à assouvir les besoins de l'application CAMIPRO, c'est-à-dire qu'elles devaient permettre aux heureux possesseurs de telles cartes de les revalider et d'en visualiser les droits, ainsi que d'en changer le code secret (NIP).

Il devait donc être possible de:

• communiquer avec un lecteur de cartes à puce;
• communiquer avec la base de données Oracle de CAMIPRO, qui contient les droits à jour correspondants à toutes les cartes CAMIPRO en circulation.

Il est vite apparu qu'une borne n'ayant que ces fonctionnalités serait de beaucoup sous-utilisée et il a été décidé d'y adjoindre quelques autres possibilités:

• un accès au bottin téléphonique;
• un accès au mémento des manifestations;
• un petit module d'orientation (destiné à devenir grand dans le futur).

Cela entraînait quelques contraintes supplémentaires, la possibilité de:

• interroger un serveur LDAP;
• visualiser des pages HTML;
• visualiser des images.

Matériel et logiciel

Devant ce problème, il y avait deux voies possibles:

• chercher dans le vaste monde un logiciel de borne interactive tout fait et essayer d'y faire rentrer notre problème;
• utiliser le vaste potentiel technique intellectuel présent dans l'EPFL pour créer un outil répondant parfaitement à nos besoins et sur lequel nous aurions toute la maîtrise pour le développement des applications futures.

La contrainte de communication avec un lecteur de carte CAMIPRO aurait sans doute rendu très difficile la première solution. La seconde a donc été choisie.

Restait le choix des matériels/logiciels à utiliser. Ces deux choix étant très liés, il était important de choisir un logiciel nous laissant plusieurs possibilités pour le matériel. Le choix s'est donc naturellement porté sur l'environnement Java, qui est ouvert, portable et de bon aloi. La solution la plus élégante pour le matériel était donc un Network computer Java. Malheureusement, ce type de matériel n'était pas disponible aisément à cette époque et nous nous sommes tournés vers des PC, mais il faut voir qu'il est possible à tout moment de changer et d'installer une nouvelle borne avec un matériel différent.

Lecteur de cartes à puce

Là encore, nous avons fait le choix de garder le maximum de maîtrise sur l'objet que nous allions créer. Les bornes sont appelées à évoluer et il faut que nous soyons à tout moment en mesure de contrôler cette évolution. La création et le développement du lecteur a donc été confié au Laboratoire de Microinformatique du Département Informatique (LAMI) qui dispose de tous les outils et connaissances pour cette tâche.

Structure de la chose

La particularité d'une borne interactive, c'est qu'elle est multipliée et ses exemplaires sont répartis dans la nature, loin des personnes qui doivent en assurer la maintenance. Il faut avoir le minimum de choses sur la borne elle-même, tout ce qui est susceptible de nécessiter des modifications ou corrections doit se trouver en un point central, sur un serveur.

Il a donc fallu choisir une structure modulaire, où seul un noyau de petite taille se trouvait physiquement sur les bornes, le reste étant mis sous forme de modules téléchargés automatiquement lors de leur utilisation.

L'utilisation de Java qui est naturellement orienté réseau et permet de charger dynamiquement des classes à l'exécution a permis de mettre aisément en place cette structure.

Ce qu'il y a sur la borne

• JRE: Java Runtime Environnement;
• Oscar.jar: contient toutes les classes du noyau Oscar.

Ce qu'il y a sur le serveur

• les fichiers de configurations généraux (ce qu'il y a sur la page d'accueil, les modules utilisés, etc.);
• les classes Java des modules;
• les fichiers de configurations des modules.
  

Il est donc aisé de rajouter des modules ou d'en modifier, on met les fichiers nécessaires sur le serveur et on redémarre Oscar (à travers le réseau, sans intervention locale). Le noyau contient tout l'environnement qui permet de faire fonctionner les modules, un peu à la manière du support offert par un Web browser à des applets.

Télémaintenance

Oscar peut être contrôlé à distance. Les actions suivantes (entre autres) sont commandées à travers le réseau:

• redémarrage;
• chargement d'un module;
• mise à jour de logiciel embarqué sur le lecteur de carte à puce;
• examen des différents compteurs (nombre de pages visitées, nombre d'erreurs, nombre de mises à jour de droits CAMIPRO, etc.);
• examen des logs d'erreurs;
• etc.

Gestion des pannes

Une borne interactive doit fonctionner en permanence. En cas d'erreur fatale, elle doit se réinitialiser automatiquement, en cas d'erreur non fatale, elle doit prévenir d'elle-même qui de droit du problème et repasser dans un mode normal de fonctionnement.

Donc, si une coupure de courant survient ou si la machine virtuelle Java plante (c'est possible), Oscar redémarre automatiquement. Pour toutes les autres anomalies (le lecteur de carte n'est plus accessible, une carte est oubliée par l'utilisateur, etc.) Oscar envoie un e-mail à la personne chargée de la maintenance qui doit entreprendre les actions nécessaires.

Technologies utilisées

Pour faire tout ça, il a été nécessaire de mettre en place différentes technologies Java, en voici quelques unes:

• Java DataBase API (JDBC): pour la communication avec la base de données CAMIPRO (Oracle).
• HotJavaBean: pour la visualisation des pages HTML.
• Java Communications API (JavaComm): pour la communication avec le lecteur de carte, via le port série.
• Java Naming and Directory Interface (JNDI/LDAP): pour la communication avec le Serveur LDAP de l'EPFL (interrogation du bottin).
• JavaMail: pour l'envoi des e-mails de maintenance.
  

Performances

Java à la réputation (fausse) d'être lent. Les performances d'Oscar sont tout à fait bonnes. Les 2 opérations un peu lentes, sont la mise à jour des droits CAMIPRO qui nécessite l'interrogation de la base Oracle à travers une interface (lente) fournie pas la société Sopra, et le chargement de pages HTML (par exemple pour le mémento), l'outil HotJavaBean utilisé est assez lent pour des raisons que j'ignore.

Portabilité

Comme dit précédemment, le matériel actuel de la borne est un PC sous Windows NT, bien que le logiciel puisse tourner sur tout ce qui supporte Java. C'est regrettable (NT est beaucoup trop complexe et mal foutu pour ça), dans le futur j'espère qu'on pourra remédier à cela et mettre des machines Java. De telles machines permettraient en particulier de n'avoir absolument rien en local sur les bornes, même le noyau serait téléchargé.

La suite

Oscar est un écrin qu'il va falloir remplir de joyaux. Le module d'orientation actuel est (pour rester poli) faible. Le département de Génie Rural est en train de réfléchir à un module beaucoup plus complet.

Le fait de disposer d'un lecteur de carte à puce sur les bornes permet d'envisager des tas d'applications nécessitant l'authentification. Pourquoi pas autoriser les demandes de changement d'adresses, les inscriptions à des cours, les ouvertures de comptes e-mails,... le champ ouvert est immense.

Le développement de l'application

Initialement, le mandat pour l'écriture du code d'Oscar avait été confié à la société Netf@ce (à l'exception du code lié au lecteur de carte à puce).

Différents problèmes (pas suffisamment confortables pour que je m'étende dessus) ont conduit l'EPFL à rompre le contrat et reprendre elle-même ce développement. La totalité du code a donc été développé au SIC, à l'exception du code lié au lecteur de carte qui a été pris en charge par le LAMI.

Pour vous donner une idée du volume de code, le noyau comprend un peu plus de 5000 lignes de Java, l'accès au lecteur de carte (développé au LAMI) environ 2000 lignes, et les modules de base (Camipro, annuaire et orientation), environ 2200 lignes (hors commentaires).

L'utilisation de Java a permis de développer la totalité du code sur une station de travail Unix.

Quelques adresses

• description du projet : http://admwww.epfl.ch/si/oscar.html
• remarques et suggestions: mailto:oscar@epfl.ch