AOS : des architectures très hétérogènes

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. '

1 - Un point d'entrée unique
Une AOS offre un point d'entrée unique à toutes les applications d'un SI. Elle permet la modification ou le remplacement rapide de l'un des éléments de ce SI, sans impacter l'ensemble. Les services Web, à la base d'une AOS, apportent une réponse adaptée à un besoin particulier. Ils évitent de développer des processus complexes abordant une problématique trop générale.

2 - Un système d'information évolutif
L'architecture orientée services permet de bâtir un nouveau système d'information à partir des éléments existants, en centralisant les processus métier à la base de l'activité de l'entreprise. La mise en place d'une AOS est souvent à l'origine de réductions budgétaires, car elle est plus simple à maintenir et plus souple à faire évoluer que des progiciels monolithiques.

3 - Une mise en ?"uvre complexe
L'entreprise doit se livrer à l'étude de ses processus métier pour les coder ensuite dans l'infrastructure technologique. Cela peut engendrer de considérables frais d'étude et d'intégration. Cette complexité nécessite un transfert de compétences entre l'intégrateur et les équipes internes. Il est nécessaire de former les futurs utilisateurs qui auront à se familiariser avec de nouvelles interfaces clients.

4 - Administration indispensable
La complexité technique d'une architecture orientée services nécessite une plate-forme de supervision réseau ainsi qu'un mécanisme d'administration de services Web, comme en propose, par exemple, AmberPoint. La description du rôle et du mode de fonctionnement de ces services Web est indispensable.

Quelques solutions techniques

Retour d'expérience : Stéphane Cresto (SPIR Communication) : ' Les services nous ont fait gagner du temps '

Faire évoluer les blocs fonctionnels

' Suite à un changement de convention collective, nous avons dû complètement modifier le SI de notre filiale Adrexo, chargée de la distribution des journaux. Étaient concernées les applications de vente, de distribution et même de RH, dont les traitements allaient devenir très complexes, explique Stéphane Cresto. Nous avons choisi une approche à base de services métier, développés avec l'architecture.NET de Microsoft. ' Stéphane Cresto et ses équipes ont progressivement bâti une gestion de la distribution des imprimés, un datawarehouse et un portail Web SAP qui communique avec les applications. ' Nous avons délibérément cherché la simplicité. Il nous a fallu développer des services métier et non pas des applications monolithiques car nous savions que nous aurions à redévelopper les pièces qui ne marchaient pas. Il nous fallait des blocs fonctionnels que nous pouvions faire évoluer sans tout changer et suivre au jour le jour. La mise en place de la SOA a imposé certaines contraintes de développement. Chaque service doit bénéficier d'une vue fonctionnelle pour pouvoir être réécrit dans un délai raisonnable. Ils doivent être supervisés continuellement pour réagir vite en cas de perte de performances ou de trop grande consommation de ressources. '

SPIR Communication

Retour d'expérience : Vincent Bonnet (Pernod Ricard) : ' Nous avons supprimé nos silos applicatifs '

Homogénéiser les processus métier

Pernod a refondu son SI pour bénéficier de processus métier homogènes, partagés par toute l'entreprise. ' Au départ, nous désirions faire communiquer notre nouveau progiciel logistique avec l'application utilisée pour calculer les droits sur les transports d'alcool, explique Vincent Bonnet. Cela nous a donné l'occasion de constater l'état de notre SI, entièrement constitué de silos applicatifs ; nous avions pas moins de six progiciels pour gérer l'ensemble du processus de commande : un pour les stocks, un pour la prise de commande, d'autres encore pour la facturation, les livraisons... ' Ces outils ayant fait leurs preuves, décision est prise de les interfacer au moyen d'une plate-forme centrale. ' Nous avons fait appel à Vistali, un intégrateur qui a commencé par nous faire décrire nos processus métier, notamment ce qu'était pour nous une commande. Puis, nous avons choisi BizTalk, l'EAI de Microsoft, dans lequel l'intégrateur a codé nos méthodes. Faute de connecteurs pour certaines applications anciennes, nous avons imaginé d'autres méthodes de dialogue avec BizTalk, basées par exemple sur des appels à des procédures stockées qui vont chercher les données métier. ' Pour Vincent Bonnet, le nouveau système constitue bien une AOS. ' Les progiciels ne communiquent pas directement entre eux, ils font circuler des processus. Nous pourrons, grâce à BizTalk, ajouter un nouveau progiciel pratiquement sans rien changer au système. Nous avons gagné en souplesse et en productivité. '

Pernod Ricard

Avis d'intégrateur : Marc Boullier (Vistali) : ' Une conception fonctionnelle des échanges applicatifs '

Les AOS sont-elles une évolution des EAI ?
Comme lors de la vague EAI du début 2000, il s'agit d'utiliser une technologie à base de processus pour masquer la complexité de l'architecture applicative. Cependant, à la différence de l'EAI, l'AOS introduit une conception fonctionnelle des échanges. Il ne s'agit plus de discuter avec SAP R/3, mais avec le domaine de la facturation.

L'architecture des EAI a-t-elle évolué ?
Oui. Le moteur central a tendance à disparaître au profit de run-time placés sur les serveurs applicatifs, reliés par un ESB qui prend en charge le routage des messages. Les règles de sécurité, en revanche, comme les métadonnées, doivent être centralisées.

Assiste-t-on à l'arrivée de services vraiment réutilisables ?
Absolument. Il faut cependant respecter les standards XML et Soap. Il y a plus de 78 spécifications sur les services Web. Certaines sont utilisées aujourd'hui par les différents éditeurs du marché. On ne connaît pas leur niveau de maturité, WS-Security commence seulement à s'affirmer. Mieux vaut employer WS-Basic, la première spécification à la base des services Web.

Vistali