Les grandes entreprises fournissent souvent leurs services dans plusieurs pays. Il s’agit parfois de prestations standards, régies par des règles métiers universelles, à l’instar des services bancaires. Les outils informatiques destinés à des structures d’une telle taille doivent être pensés et optimisés afin de faciliter leur utilisation, leur déploiement, leur extensibilité et leur maintenance. Dans cette optique, le concept d’optimisation doit être vérifié tout au long du cycle de vie d’une application informatique. Par Benamar Berrabah, Expert J2EE, Administrateur WebSphere et Ingénieur Tests de Performance, Gfi Informatique.

L’optimisation est une des notions les plus anciennes de l’industrie informatique. Initialement liée à la programmation, elle se définit comme la pratique qui consiste à réduire le temps d’exécution d’une fonction (élément de base dans un module informatique).

Avec l’évolution des systèmes d’informations et leur urbanisation, l’optimisation s’est naturellement élargie aux autres aspects des applications ; elle concerne maintenant tout le cycle de vie des composants d’un produit informatique. En génie logiciel, elle traite les phases d’expression des besoins, de conception, de déploiement et d’intégration dans le système d’information. En architecture applicative, elle s’applique au découpage (physique ou logique) de l’application, d’une simple fonction informatique, d’un programme, d’un module, d’un produit tout entier ainsi que ses interactions avec le système d’information existant.

Ce témoignage sur l’importance de l’optimisation dans un contexte international issu de l’expérience vécue lors de l’intégration d’une application d’Agenda dans un portail bancaire. Il avait été décidé que l’utilisation de ce produit serait généralisée pour la gestion des rendez-vous clientèle dans tous les sites de la banque.

A première vue, le produit semblait bien structuré, avec une architecture en 3-tiers J2EE suivant le modèle MVC, un modèle d’architecture en 3 couches qui comprend le Modèle de données, la vue (pour interaction avec l’utilisateur) et contrôle (logique des événements). L’installation a été réalisée avec le support de l’éditeur, quelques feedbacks ont été remontés à l’équipe d’intégration pour remettre à jour ses notes d’installation.

L’intégration du produit dans le portail bancaire implique l’extension des deux couches applicatives (IHM et services), en utilisant deux concepts différents. Au niveau de l’IHM (Interface Homme Machine) c’est le mécanisme d’authentification qui était sujet d’extension ; or au niveau services une structure XML était fournie afin d’implémenter un web service compatible.

Pour avoir vécu une expérience de référent technique, la méthode d’extension proposée dans la couche IHM semblait correcte, une API Java fournissant des interfaces (filtres J2EE) paramétrables via un fichier de configuration. Ce qui impliquait un faible couplage entre l’agenda et le module à créé. En génie logiciel, le couplage étant le degré d’interaction et donc de dépendance entre deux modules informatiques.

Le problème était situé au niveau de la couche services, qui s’est voulu être un middleware en traitant divers types de services, XML, SOAP, connecteur JMS … Or, le mécanisme d’extension se limite à un fichier WSDL (un fichier descripteur de syntaxe de web services). L’implémentation d’un web service, sous ces contraintes, complique le respect des standards propres à l’équipe utilisatrice.

Il est évident que le principe de découplage logiciel n’était pas respecté, le module à développer étant étroitement lié au module consommateur des web services. Le support de l’équipe d’intégration était indispensable pour répondre aux problématiques rencontrées lors du développement du nouveau module d’extension. Le retard était inévitable, et des anomalies ont été découvertes dans un framework maison utilisé par l’Agenda. Sachant que l’application était déjà utilisée dans quelques sites, nous avons difficilement convaincu l’équipe propriétaire du framework en question à nous fournir un patch corrigeant l’anomalie.

Il est naturel que si un API avait été fourni également pour la couche service, à l’instar de la couche IHM, l’équipe utilisatrice du produit aurait eu plus de liberté pour développer son Adapter d’appel à ses propres services, et plus de souplesse pour respecter ses standards de développement.

Cet expérience montre les effets néfastes des produits développés sans respect des concepts du génie logiciel. Les produits optimisés sont eux prévus pour éviter les problèmes d’extensibilité et ainsi faciliter leur intégration dans les systèmes d’information de grande taille.

Au niveau international, la présence d’une telle faille dans un logiciel est très difficile à corriger, des régressions peuvent pénaliser la production d’autres sites qui jouissent de leur propre architecture ; de plus, des versions différentes pour chaque site d’un produit universel font perdre le concept d’universalité, ce qui embarrasse la gestion des versions logiciels et surtout accroît la charge au niveau de l’équipe propriétaire du produit.

Les principes et méthodologies logicielles sont au service des systèmes complexes. S’en servir en amont, durant les phases de conception et développement des framework génériques facilite leur utilisation par les clients, et exempte le support de traiter les problématiques liées aux développements spécifiques.

Benamar Berrabah, Expert J2EE, Administrateur WebSphere et Ingénieur Tests de Performance, Gfi Informatique