I. Introduction

Depuis quatre ans, les applications de guichet pour le traitement des transactions commerciales du groupe d'assurances Münchener Verein sont développées sur la base d'applications Internet riches (Rich Internet Applications, RIA). Elles offrent ainsi un degré d'interactivité et une ergonomie comparables aux interfaces utilisateur standards. De plus, ces applications fonctionnent également sur des PC portables en mode déconnecté destinés aux collaborateurs externes. Ces modes (connecté et déconnecté) à priori incompatibles sont possibles grâce à la mise en place d'une architecture orientée services (SOA) et à l'utilisation du composant UltraLightClient de l'entreprise bâloise Canoo. Cette solution permet l'exécution du code d'application dans les deux modes en découpant le code d'opération en composants d'infrastructure configurables.

II. Problématique

Image non disponible
Figure 1 : Interface utilisateur des nouvelles applications frontales

L'introduction de nouvelles applications « Front-office » dans le groupe d'assurances Münchener Verein visait à homogénéiser les systèmes existants et à supporter les processus de travail tout le long du cycle de vie de la relation client. Tous les produits d'assurance automatisables doivent être traités par les nouvelles applications. Une IHM standardise les processus (figure 1). D'abord, l'utilisateur sélectionne un produit et une transaction correspondante. La combinaison spécifique entre ces sélections et le rôle de l'utilisateur déclenche les processus métiers. La figure 1 montre la capture des données pendant la composition d'une offre pour un produit d'assurance-vie. Les figures 2 et 3 montrent chacune une représentation de prestations d'assurance accessible depuis l'écran de la figure 1.

Image non disponible
Figure 2 : Représentation tabulaire des prestations d'assurance
Image non disponible
Figure 3 : Représentation graphique des prestations d'assurance

La technologie nécessaire pour cette nouvelle génération d'applications devait répondre à des exigences contradictoires. D'une part, il était souhaitable d'employer une architecture J2EE afin de pouvoir créer des applications à la fois faciles à installer et accessibles par Internet aux collaborateurs externes. D'autre part, il était nécessaire de développer des IHM interactives et efficaces, car ces applications seraient utilisées intensivement. Et enfin, il fallait qu'une partie des applications fonctionne aussi en mode déconnecté pour les collaborateurs en déplacements clientèle. Seule la technologie des applications Internet riches (RIA) permettait de couvrir l'ensemble de ces fonctionnalités.

III. Solution

Dans la technologie RIA, on distingue essentiellement trois différentes technologies côté client qui peuvent être employées dans une architecture J2EE : JavaScript, Flash et Java (Marc Domenig: Rich Internet Applications and AJAX - Selecting the best product). Le choix s'est arrêté sur Java :

  • l'emploi de la même technologie de base pour le client et pour le serveur conduit à un modèle de programmation homogène et, par conséquent, relativement peu complexe, ce qui simplifie le développement et la maintenance ;
  • Java est un standard, on peut donc être confiant sur sa pérennité ;
  • l'UltraLightClient de Canoo exploite habilement l'infrastructure de la plate-forme Java pour proposer une architecture RIA évolutive.

Une caractéristique essentielle d'ULC est qu'elle intègre Swing - la bibliothèque Java standard pour interfaces utilisateur graphiques - dans une architecture Web en transférant l'interface de programmation de Swing du client au serveur (Bernhard Wagner: Server-Side Swing for Rich Internet Applications). Le développeur est ainsi à même d'employer Swing dans un modèle de programmation côté serveur sans devoir s'occuper de la division de l'application en une partie client et une partie serveur. La division ainsi que l'intégration dans l'architecture J2EE sont effectuées par la bibliothèque. Cette approche simplifie considérablement le développement et permet d'installer des applications dans différentes configurations et sur différentes plates-formes sans qu'il soit nécessaire de modifier le code. C'est cette flexibilité qui a facilité la réalisation d'applications qui fonctionnent aussi bien sur un serveur que sur des PC déconnectés.

La capacité de fonctionner en mode déconnecté peut être réalisée en combinant l'architecture et la flexibilité d'ULCUltraLightClient avec une architecture back-end appropriée. La caractéristique la plus importante de l'architecture réside dans le concept du « client léger » avec un « moteur de présentation » basé sur Java. Dans cette architecture, la limite entre le client et le serveur devient, pour ainsi dire « mobile ». Dans une configuration J2EE typique, le seul élément à tourner sur le client est le moteur de présentation (un navigateur par exemple) qui est indépendant de toute application spécifique. L'application elle-même, y compris la logique de présentation, tourne sur le serveur (figure 4). Dans une configuration sur un PC en mode déconnecté, aussi bien le moteur de présentation que l'application tournent sur une seule machine virtuelle Java, tandis que l'interaction client-serveur n'est que simulée (figure 5).

Image non disponible
Figure 4 : Configuration d'une application UltraLightClient en mode client-serveur
Image non disponible
Figure 5 : Configuration d'une application UltraLightClient en mode déconnecté

Pour profiter avec succès de cette flexibilité de configuration, il est indispensable d'avoir une architecture back-end qui supporte, elle aussi, le mode client-serveur et le mode déconnecté. La figure 6 montre la solution choisie par le groupe d'assurances Münchener Verein : une architecture orientée services (SOA) avec des composants portables. L'avantage décisif de cette architecture réside dans le fait que la plupart des composants peuvent être installés, sans aucune modification, aussi bien sur le serveur que sur un PC. Seuls l'adaptateur de l'application, l'adaptateur de ressources, les applications standards et les applications anciennes ont besoin d'être adaptés au fonctionnement sur PC. En remplaçant, si nécessaire, les applications standards et anciennes par des versions migrées, chaque application peut aussi, en principe, être rendue disponible sur PC autonome.

IV. Conclusion

Image non disponible
Figure 6 : Architecture orientée services des nouvelles applications frontales

Au bout de quatre ans de développement par une équipe de dix personnes, plus de la moitié des nouvelles applications envisagées sont en production. Il y a deux ans, les premières applications ont été installées en mode serveur pour les collaborateurs internes. Depuis six mois, des applications utilisables en mode autonome sont mises à la disposition des quelque 6000 courtiers et collaborateurs au service extérieur. Toutes ces applications fonctionnent aussi bien en mode connecté que déconnecté.

Les expériences montrent que la technologie des applications Internet riches (RIA) est parfaitement apte à répondre à ce type d'exigences. Elle permet non seulement le développement d'applications Web avec des IHM plus interactives et ergonomiques, mais aussi le fonctionnement de ces applications sur des PC déconnectés du réseau. La bibliothèque RIA UltraLightClient, avec son modèle de programmation homogène et simple et le concept de la limite « mobile » entre le client et le serveur, s'est avérée être une base solide. Son architecture purement Java est le complément idéal d'une architecture orientée services telle qu'elle est montrée dans la figure 6.

V. Note et remerciement du gabarisateur

Cet article a été mis au gabarit de developpez.com. Voici le lien vers le PDF d'origine (300 ko) : ulc1.pdf.

Le gabarisateur remercie Fabien pour sa correction orthographique.