Inscrivez-vous gratuitement à la Newsletter BFM Business
L'architecture orientée services recouvre différentes réalités techniques. Les entreprises y voient un moyen de masquer la complexité applicative au profit de services fonctionnels.
Apparue il y a un an, la notion d'architecture orientée services (AOS) recouvre encore des mises en ?"uvre très diverses. A l'origine, l'AOS consistait à relier des applications entre elles pour en combiner les fonctions, qui
deviennent alors des services offerts aux utilisateurs. Bus interapplicatifs ESB (Enterprise Service Bus), EAI, services Web ou Workflow sont employés pour orchestrer et réguler les transferts d'informations entre progiciels.Même schéma en ligne : l'internaute qui vient d'acheter un article verra la validité de sa carte bleue vérifiée par un service Web relié au réseau bancaire. Un autre transmettra sa commande aux progiciels de gestion de clientèle,
de facturation et de gestion des stocks. Quelle que soit l'option technique choisie, l'AOS décolle. Une enquête réalisée par ebizQ aux Etats-Unis, en octobre dernier, montrait que 65 % des entreprises interrogées poursuivent activement la mise
en place de ce type d'architecture. La plupart d'entre elles ont commencé avec un petit nombre de services puis les ont augmentés de manière progressive. 64 % des responsables informatiques interrogés apprécient la souplesse que peut apporter
une AOS. Les autres avantages fréquemment mentionnés sont la réutilisation des actifs informatiques et l'optimisation des processus métier.
L'utilisation : gagner en efficacité
Les Européens ne sont, pour une fois, pas en retard en la matière. Jacques Guigui, directeur technique du parc des expositions de Paris-Nord Villepinte, a choisi l'approche AOS pour mieux faire communiquer ses sites Web.
' Nous avons déployé l'EAI iBolt de Magic Software pour relier nos sites et les connecter à nos progiciels de back office. Grâce à ce dispositif, nos clients disposent d'un point d'accès unique pour
leurs achats. Je compte bien, grâce à cette nouvelle architecture, atteindre les 40 % de commandes en ligne. ' La nouvelle architecture est conçue pour apporter des services aux clients : ' Un
client peut choisir de faire installer une ligne téléphonique sur son stand ou de le couvrir de moquette. Il commandera directement la prestation sur notre site et le prestataire responsable verra la commande lorsqu'il se connectera en
extranet. 'Jacques Guigui a développé pour cela plusieurs services Web qui correspondent aux grandes fonctions applicatives. ' Nous utilisons un service Web pour le paiement en ligne. Il est partagé par six applications
différentes. Si le protocole bancaire change, nous modifierons simplement ce service. ' La SMABTP (société mutuelle du BTP) gère pour sa part des contrats d'assurances très complexes et le SI a dû être revu afin d'automatiser
au maximum la production. ' Nous possédions une informatique comptable où les tâches manuelles étaient nombreuses. Nous avons opté pour des applications, placées sur des serveurs, capables de composer automatiquement des
traitements complexes ', explique Jean-Michel Detavernier, le directeur informatique adjoint. La mise en ?"uvre fait appel à plusieurs composants, dont le moteur de règles JRules. Il accueille les règles métier de toutes
les applications (recouvrement, sinistres et clients).Ces dernières sont reliées par le bus de messages WebSphere MQ, qui transporte les données au format XML. C'est le moteur de règles qui orchestre les actions des logiciels. ' Le fait d'avoir déporté les
règles métier des progiciels vers un moteur spécialisé nous procure beaucoup plus de souplesse pour les créer, les modifier et surtout les adapter aux besoins. ' L'AOS fait partie du modèle économique de la société suisse
PubliGroupe, un intermédiaire de vente de publicité pour des journaux et des sites Web. ' Notre AOS nous est indispensable, explique Charles Lentz, responsable architecture et standards. Nous fournissons
grâce à elle des sites Web en marque blanche utilisés par un journal pour publier des petites annonces. Nous avons développé plusieurs services Web pour stocker les annonces dans un référentiel centralisé et les transmettre vers les sites de nos
clients. ' Ces annonces proviennent des PGI des clients ou de sites spécialisés dans l'immobilier, l'emploi ou la vente de véhicules.
La mise en ?"uvre : repenser son métier
Une architecture orientée services ne se met pas en place en un instant. Le nouveau système va structurer tout le SI. ' Nous avons procédé à l'analyse complète de notre ancien système, application par
application, avant de déployer notre moteur JRules, précise Jean-Michel Detavernier. Nous avons également fait intervenir les utilisateurs métier. Le système s'est révélé complexe à mettre en ?"uvre. Nous avons dû modéliser
les services métier dans un atelier UML et nous avons écrit les nouvelles applications en Java en créant notre propre framework pour ce langage. 'Pour Christophe Lemée, DSI et responsable des nouvelles technologies de Home Shopping Service (groupe M6), la mise en ?"uvre n'a pas posé de problème. ' Il nous fallait adapter notre PGI Adonix à nos nouvelles
activités, beaucoup de développements spécifiques ont, en effet, été réalisés autour de lui. Nous avons installé le middleware Convertigo de Twinsoft et tout s'est passé facilement : Convertigo est relié à Adonix par un
connecteur Telnet et communique avec les nouveaux applicatifs en XML à travers des services web hébergés par Convertigo. Les écrans Web utilisateurs ont été développés en PHP et invoquent directement les services. 'Même principe chez ThyssenKrupp Ascenseurs, où Frédéric Godet, le DSI Europe, a relié tous ses progiciels de calcul salariaux au nouveau PGI Oracle eBusiness Suite. Cela, à l'aide d'un autre outil d'Oracle, le BPEL Process Manager,
préféré à WebSphere Integrator ou à BizTalk pour son nombre de connecteurs. ' Nous avons programmé des échanges complexes avec calcul de données et changement de sémantique. C'est un outil très souple, qui nous donne une
architecture dynamique. Lorsqu'une donnée change dans un logiciel de RH, ce changement est répercuté dans le PGI. Nous avons aussi développé une dizaine de services spécialisés. L'un calcule le prix d'un contrat, un autre recherche les informations
de maintenance des ascenseurs dans un SGBD. Ils interagissent, chacun apportant une réponse à un besoin précis. Plus besoin de développer des processus monolithiques qui prennent en compte des problématiques beaucoup trop
générales. '
La supervision : décrire les paramètres des services Web
Pas facile de gérer au quotidien une architecture orientée services. Les services distribués doivent faire l'objet d'une supervision minutieuse pour en garantir le bon fonctionnement. Jean-Michel Detavernier a choisi une voie
originale :
' Nous utilisons les outils de supervision fournis par Staffware, notre workflow collaboratif. Ils sont suffisants pour prendre en charge les échanges entre les différents
systèmes ', précise-t-il. La gestion des services Web pose néanmoins des problèmes spécifiques. Il faut les lister, décrire leurs paramètres techniques dans un référentiel pour les faire évoluer, définir les droits d'accès
des applications et documenter ces droits, etc.Dans ce domaine, curieusement, beaucoup de choses restent à faire. Les annuaires UDDI proposés par les éditeurs pourraient effectuer cette tâche, mais sont rarement utilisés. ' Nous n'avons qu'une trentaine de
services, un fichier Excel suffit pour les décrire, explique Jacques Guigui. Notre architecture n'a pas l'envergure pour nécessiter un annuaire UDDI. Nous avons préféré nous équiper d'un serveur de monitoring réseau et d'un
logiciel documentaire qui contient la documentation de nos applications. De toute façon, l'administration des services est facile à voir. Il n'y a qu'à regarder ceux qui sont lancés ou pas ! 'Même approche au groupe M6, où Christophe Lemée avoue ne pas avoir besoin d'annuaire UDDI : ' Avec une architecture beaucoup plus distribuée, nous nous serions certainement penchés sur le
problème ', nuance-t-il. Lorsqu'ils gardent la trace de leurs services, certains le font de manière traditionnelle, dans un référentiel de code. ' Nous utilisons pour cela la solution de
PSNext ', indique Frédéric Godet chez ThyssenKrupp. Pas encore d'annuaire UDDI non plus pour Charles Lentz, qui lui préfère la solution Service Level Manager d'AmberPoint. ' Dès le départ, notre
objectif était d'assurer une surveillance en amont. AmberPoint nous permet de vérifier et de présenter à nos clients la disponibilité de nos services Web, les taux d'erreurs ainsi que les temps de réponse, le tout en quasi-temps
réel. '
Les écueils : répondre à des contraintes techniques et de formation
Le passage à une architecture orientée services est un challenge pour de petites équipes, ou lorsque le SI s'appuie sur un mainframe. L'équipe de Thyssen-Krupp a dû s'adapter à l'existant par le biais de services
Web uniquement techniques. ' Difficile d'interfacer tout ce qui est VAX ou VMS, souligne Frédéric Godet. Nous avons donc développé des services Web qui consulteront un fichier indexé provenant du grand
système pour voir si celui-ci n'a pas subi de modifications. 'Pour Charles Lentz, la mise en place de la nouvelle AOS a représenté un vrai défi. ' Il nous a fallu quelque 20 années/hommes de développement. Elle nous a permis d'intégrer de manière efficace des sites Web à
notre référentiel central ainsi qu'à notre mainframe IBM. Il nous a fallu construire des interfaces purement techniques pour assurer les échanges de données et pour opérer des transactions Cobol sur notre
mainframe. ' Jacques Guigui a dû s'adapter au nouveau système. ' Une formation de huit à quinze jours a vraiment été indispensable. 'Autre problème, la résolution d'incidents. Ainsi, Sylvain Luce, responsable du service informatique de Trapil, un gestionnaire d'oléoducs français, s'est frotté à la traque des bugs. L'entreprise a, en effet, morcelé son application
monolithique de gestion des temps de travail en plusieurs services applicatifs disponibles sur l'intranet par le middleware EntireX de Software AG et le serveur d'applications WebSphere d'IBM. Lors des premiers tests, le débogage a été
difficile : ' Dans une application classique, il est facile de localiser un bug, c'est plus difficile dans une architecture à plusieurs niveaux. Nous avons dû travailler dur pour trouver l'origine des erreurs HTTP que
nous rencontrions. C'est inévitable lorsque l'on fait appel à des bases de données, à un progiciel réécrit, ou à des serveurs Apache ou Web-Sphere. '
Les gains : évoluer en souplesse
L'AOS apporte une souplesse certaine au SI. La logique applicative ne réside plus uniquement dans les progiciels et permet des modifications très rapides : ' Une modification demande moins d'une journée.
C'est un avantage certain face à un codage en dur dans un logiciel ', explique Jean-Michel Detavernier. ' Créer un nouveau service ne demande que quelques minutes ou quelques heures, selon le degré de
complexité, souligne Christophe Lemée. Le tout sur une plate-forme de production dont le coût est inférieur à 50 000 euros, matériel, formation, licences et développement des premiers services Web avec Twinsoft
compris. ' La nouvelle architecture a été source d'économies chez Thyssen-Krupp. ' Elle nous a permis d'éviter la personnalisation pays par pays de notre PGI, ce qui aurait entraîné des frais énormes.
Grâce à elle, nous avons combiné le meilleur des deux mondes, l'ancien et le nouveau. '
Votre opinion