Passer au contenu

La CAF et la Coface passent au serveur d’applications en douceur

Les limites des applets Java en termes de performances et de portabilité ont incité la Caisse d’allocations familiales et la Coface à se tourner vers un serveur d’applications.

Trois ans après leur apparition, on présente les serveurs d’applications Java comme le centre névralgique des actuelles infrastructures transactionnelles internet. Ils tiennent une place d’autant plus stratégique qu’ils se rattachent désormais au standard Java 2 Enterprise Edition (J2EE), là où les moniteurs transactionnels d’antan s’appuyaient sur des technologies propriétaires. L’évolution technique fulgurante de ces produits s’accompagne d’un matraquage médiatique sans précédent. Lequel finit par payer, y compris en France, où les fournisseurs – à commencer par les deux leaders IBM (WebSphere) et BEA (WebLogic) – peuvent enfin afficher leurs premières références. IBM et BEA sont crédités par le Giga Group (étude prévisionnelle publiée en juin 2000) de 24 % de parts sur un marché évalué à 1,64 milliard de dollars pour l’an 2000 (contre 585 millions en 1999). Or, si les directions informatiques ont bien assimilé l’étendue du potentiel des serveurs d’applications, elles décident de n’exploiter que partiellement leurs capacités, reportant ainsi l’usage de composants EJB (Enterprise JavaBeans).

Le site de la CAF fait appel aux servlets de Websphere

La Caisse d’allocations familiales (CAF), qui s’est intéressée à internet dès 1996, a choisi cette méthode. Le Centre régional de traitements informatiques (Certi) Alpes-Méditerranée de la CAF a démarré par une application pilote (AL Etudiant) – destinée à la gestion sur le web de l’allocation logement des étudiants – avant d’édifier son site institutionnel, Caf. fr. Ouverte à la rentrée universitaire 1998, AL Etudiant permet de remplir en ligne son formulaire de demande d’allocations, de l’imprimer, puis de l’envoyer par courrier à sa caisse régionale. Pour cette saisie, le Certi de la région a développé une applet Java qui se télécharge sur le navigateur de l’intéressé. Problème : “Nous devons maintenir plusieurs versions d’applets en raison des différences de comportement des machines virtuelles Java enfouies dans les navigateurs “, indique Franck Schwartz, chef de projet au Centre national d’études et de développements informatiques (Cnedi) de la CAF.Dès fin 1998, cette difficulté a incité le Certi Alpes-Méditerranée à s’orienter, pour le site Caf. fr, vers une nouvelle architecture internet à base de serveurs d’applications Java. Cette division du Certi, équipée, comme celles du Mans et de Paris, de matériels et logiciels IBM – les cinq autres étant dotées de grands systèmes Bull GCOS 8 – a logiquement opté pour le produit du même constructeur. S’est alors posée la question de savoir sur quelle plate-forme exécuter WebSphere, sachant que Cristal, le système informatique de production de la CAF, tourne sur un mainframe OS/390. “Les exploitants de Cristal n’ont une culture ni NT, ni AIX, constate Franck Schwartz. En leur confiant la surveillance du web, nous étions sûrs qu’ils le chouchouteraient.” La version OS/390 de WebSphere a donc été retenue.La saisie en ligne d’un dossier d’allocataire, bientôt proposée par l’application Caf. fr, relève d’un enchaînement de pages dynamiques, générées par un couple technique formé de servlets (des applets côté serveur) et de pages JSP (Java Server Pages). “La gestion de session, lors d’une connexion, est prise en charge par les servlets de WebSphere “, avise André Ribiollet, architecte en systèmes d’information chez IBM France. La paire servlets/ JSP répond si bien aux besoins que Franck Schwartz va jusqu’à affirmer sans détour : “Les EJB ne nous intéressent pas pour l’instant. La méthode de distribution de composants EJB sur différentes plates-formes est un concept génial. Mais il demeure pour l’instant une petite usine à gaz à son niveau actuel de maturité.”

La Coface a retenu la solution Weblogic

La Coface (Compagnie française d’assurance pour le commerce extérieur), qui protège les entreprises des risques liés à leurs échanges commerciaux et à leurs investissements internationaux, n’est pas si catégorique. Elle a failli céder aux EJB à la mi-1999. A cette époque, l’application Cofanet, permettant à ses clients d’accéder sur internet à une série de services (gestion de portefeuille, recherche d’informations sur un acheteur, etc. ), rencontrait des problèmes de traversée de pare-feu. Ces services sont invoqués sur le navigateur web via une applet Java couplée à Jolt, le module de BEA autorisant des appels Java aux traitements régis par le moniteur transactionnel Tuxedo. Celui-ci tient une place essentielle au c?”ur du système de la Coface. Or, le protocole d’accès à Tuxedo via Jolt ne traverse pas les pare-feu. Une parade consistait à recourir aux EJB du serveur d’applications WebLogic de BEA. Mais “la taille de l’applet qui embarquait les appels aux EJB était beaucoup trop grande – de l’ordre de 800 Ko “, déclare Eric Robin, chef de projet à la Coface. Finalement, la solution retenue utilise bien WebLogic. Mais elle ne sollicite que ses servlets, qui ne servent dans Cofanet qu’à transporter sur HTTP – en mode tunneling – les données utiles à l’invocation des services Tuxedo. Egalement dédiée aux clients, l’application Cofacerating (demande de notation en ligne des partenaires commerciaux potentiels des clients de l’assureur) repose, elle aussi, sur des servlets Java exécutées par WebLogic. Mais tandis que, dans Cofanet, la gestion de session pour chaque connexion HTTP reste à la charge de l’applet, dans Cofacerating (exempte d’applets), elle incombe aux servlets.

La compagnie passera aux ESB en douceur

Avec Cofacerating, “nous nous orientons de plus en plus vers le commerce interentreprises, signale Eric Robin. Ce service a déjà suscité l’intérêt de plusieurs places de marché internationales. Nous leur diffusons les résultats d’une demande de notation sous forme de flux HTML ou XML.” Dans une optique d’industrialisation de ses échanges collaboratifs sur internet, la Coface se penche actuellement sur la solution ad hoc de BEA, WebLogic Collaborate. Laquelle se présente sous la forme de composants EJB régentés par le serveur d’applications Java de l’éditeur. “Ce serait une bonne manière de se confronter en douceur à la complexité de la technologie des EJB “, avoue Eric Robin.“La norme Java 2 Enterprise Edition est encore en pleine genèse. Les serveurs d’applications sont neufs et ne demandent qu’à mûrir “, confesse André Ribiollet. Au vu des choix de la CAF et de la Coface, les entreprises semblent basculer vers ces produits avec prudence, en évitant de griller les étapes et en ne retenant qu’une petite partie de leur spectre fonctionnel. Pour elles, le serveur d’applications est un élément de rationalisation des précédents développements logiciels pour internet.De la même façon que le client-serveur a connu deux générations, le développement d’applications web transactionnelles quitte tout juste sa première phase, émaillée d’applets Java – le client lourd du ” network computing ” -, pour entrer dans une étape où le serveur d’applications – symbole de la percée de Java côté serveur – est roi.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Stéphane Parpinelli