Un système d’exploitation ne répond à aucun besoin fonctionnel de l’utilisateur tant que ce dernier n’a pas installé des applications. En revanche, les développeurs peuvent s’appuyer sur les API de l’OS pour ne pas avoir à réinventer la gestion de l’affichage ou le déplacement de la souris lorsqu’ils conçoivent leurs programmes. Les serveurs d’applications remplissent exactement le même rôle au-dessus de l’OS : exécuter des applications et faciliter la vie du développeur par le biais d’une API homogène de services. En cela, il se transforme de plus en plus en véritable plaque tournante des nouvelles applications de l’entreprise. D’autant que l’architecture interne de ces outils converge peu à peu : une ” machine virtuelle ” – JVM, CLR ou Zend Engine – se charge de compiler un code intermédiaire avant de l’exécuter et de gérer la mémoire à la place du développeur.
L’architecture orientée services fait l’unanimité
Les trois technologies se focalisent aussi sur un développement par agrégation de composants afin de favoriser la réutilisation de la logique métier, d’accélérer les développements et de faciliter la maintenance des applications. “Cette architecture orientée services n’est pas particulièrement neuve. À la fin des années quatre-vingt, l’OMG soulignait déjà que seule une architecture distribuée de services – Corba [Common Object Request Broker Architecture, Ndlr] – résoudrait les problèmes récurrents d’intégration d’applications”, rappelle Jean-Marie Chauvet, associé chez Dassault Développement.La pression des logiciels libres et des standards a contribué à banaliser le serveur d’applications. La plate-forme J2EE possède, par exemple, d’excellentes implémentations open source telles que JBoss ou Jonas. Certains éditeurs tel HP, arrivés tardivement sur le marché et contraints d’affronter les leaders que sont IBM et BEA, ont abandonné la bataille commerciale. Le serveur d’applications est plus ou moins relégué au rang de simple socle technique au profit de plates-formes complètes intégrant outils de développement, d’intégration d’applications et de présentation. Novell fournit gratuitement une plate-forme open source (Apache, MySQL, PHP) avec la solution NetWare 6. Microsoft va proposer Windows .NET Server, tandis qu’IBM et BEA utilisent les appellations WebLogic Platform et WebSphere Platform pour désigner leurs offres constituées d’un serveur d’applications, d’un outil d’intégration et d’une infrastructure de portail.Restait à assembler ces trois briques – portail, serveur d’applications et outil d’intégration -, autour d’une architecture adaptée. Sur ce point, l’architecture orientée services fait, elle aussi, l’unanimité chez tous les éditeurs. Elle consiste à assembler plusieurs services de tailles différentes afin de construire une application. Les bases de données, les applications de GRC, les PGI, etc., sont en effet découpés sous la forme de composants logiciels. Par exemple, les fonctions SAP liées à la prise d’une commande peuvent être interfacées grâce à des connecteurs propriétaires, des connecteurs JCA ou bien encore des services web. Ainsi exposés de façon homogène, ces services sont directement accessibles depuis le serveur d’applications. Comme l’explique Sami Jaber, architecte chez Valtech : “99 % des entreprises ont un existant qu’il faut réutiliser en l’exposant sous forme de services.”
Vers l’uniformisation des dialogues entre services
Le serveur d’applications fournit de son côté des services techniques (connectivité, sécurité, messagerie, etc.), qui facilitent cette reprise de l’existant et sur lesquels les développeurs peuvent construire des services métier, comme l’ajout d’une commande dans le PGI par exemple. Il existe donc trois niveaux de services : les applications et les données existantes, les services techniques et les nouveaux services métier encapsulés dans des composants COM+, des classes PHP ou des EJB. Les services du serveur d’applications dialoguent avec ceux du back office par l’intermédiaire de protocoles de transport tels que JMS, IIOP ou HTTP et ce, en fonction de l’architecture – synchrone ou asynchrone – retenue. Les entreprises qui veulent privilégier l’évolutivité de leur système d’information se sont généralement lancées dans des projets d’urbanisation et s’appuient sur une architecture asynchrone qui permet de découpler les services. Un MOM (Middleware Orienté Messages) associé à un courtier de messages route les informations entre applications hétérogènes selon un dialogue événementiel de type publication-abonnement. Cette architecture propre aux outils d’EAI fait aujourd’hui partie intégrante des offres des éditeurs de serveurs d’applications tels qu’IBM (WebSphere MQ), BEA (Integrator), Novell (Composer) ou Iona (XMLBus). “Les services web promettent d’uniformiser le dialogue entre services grâce à des échanges RPC Soap transitant sur HTTP”, précise Éric Didier, fondateur de Soamaï. Le positionnement hybride du serveur Iona illustre bien cette nouvelle tendance : “L’objectif de notre serveur d’applications est de faciliter la migration de notre base installée sur Corba vers J2EE et .NET. Nous avons donc ajouté un bus asynchrone, qui s’appuie sur des services web pour faciliter le dialogue entre le serveur d’applications et l’existant”, explique Dominique Thomas, directeur technique EMEA d’Iona. Le serveur étend ainsi son champ d’action : “On parle plutôt de serveur d’intégration, car les recoupements entre plate-forme d’intégration d’applications et serveur d’applications sont de plus en plus nombreux avec une architecture orientée services”, constate Sami Jaber, consultant chez Valtech. Certains éditeurs préconisent de réaliser l’assemblage des services au niveau de leurs outils d’orchestration des processus métier (BPM – Business Process Management), d’autres cantonnent leur couche BPM à la transformation des données et conseillent donc de coder la logique métier dans des services métier de grosse taille. Ainsi, plusieurs départements d’une même entreprise peuvent assembler les mêmes composants métier génériques en fonction des processus qui leur sont propres pour bâtir une application.
Le portail est chargé de présenter la logique métier
Une fois assemblés les services métier doivent à leur tour être accessibles depuis une interface utilisateur – PDA, web, client-serveur, etc. – ou directement utilisés par d’autres programmes tels que des services web ou des passerelles B-to-B. C’est le rôle du portail d’exposer la logique métier. Chaque service est enveloppé dans un portlet qui gère la couche graphique ainsi que les droits d’accès et les interactions avec les utilisateurs. Si l’entreprise veut développer ses interfaces, elle peut recourir à des outils tels que Struts ou Turbine dans le monde J2EE ou Smarty dans le monde PHP. Visual Studio .NET de Microsoft s’appuie, lui, sur des WinForms et WebForms.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
