Les concepts et les offres de la SOA

Télécharger le supplément spécial du Monde informatique (inclus le panorama de l'offre et le guide des solutions)

Les éditeurs, les prestataires de services et même la presse ne se lassent pas de vanter les mérites de l'architecture orientée service ou SOA (Service Oriented Architecture). Véritable phénomène de mode, cet acronyme s'inscrit en lettres d'or sur toutes les offres, comme un Saint-Graal de l'informatique. Mais qu'en est il en réalité ? SOA n'est ni une révolution ni une solution exempte de problèmes. Convergence de tendances qui ne datent pas d'hier, SOA n'est pas une technologie mais un concept qui devrait permettre d'aboutir à des systèmes d'information plus flexibles, plus ouverts et moins coûteux à concevoir ou entretenir. Avec la promesse, en tâche de fond, d'une informatique moins technoïde, plus au service des hommes et de la stratégie de l'entreprise... Pour bien comprendre les implications de SOA sur le système d'information, il convient de faire le distinguo entre les technologies et les principes. En soi, SOA n'est qu'un principe d'architecture qui préconise la structuration d'applications par assemblage de composants et non plus, comme par le passé, sur la base d'écriture d'un programme en bloc, approche connue sous le nom d'application monolithique. Baptisés « services », les composants peuvent être de type technique (accès aux données, système de reprise sur erreur, etc.) ou métier (commande, facture, etc.). Autonome, chaque service peut être combiné à un autre au sein d'un processus pour constituer une application « composite ». Enfin, SOA préconise également une séparation des traitements en couche, la couche de présentation, par exemple, ne devant pas être mêlée à la logique métier. Cette approche présente deux avantages immédiats : des économies en développement et une plus grande réactivité. L'entreprise s'épargne en effet la réécriture systématique de fonctions communes à plusieurs applications, tel l'accès aux données, en concevant un service qui pourra être réutilisé par toutes les applications du système. En parallèle, évoluer ne signifie plus faire table rase de la totalité d'une application mais seulement d'un ou plusieurs composants, ce qui permet bien entendu d'aller plus vite. En poussant même le concept de SOA plus loin, l'entreprise peut constituer une nouvelle application en orchestrant simplement une nouvelle combinaison de services. Cette approche n'est pas foncièrement nouvelle, les architectures distribuées telles que Corba (dans le monde Unix) et DCOM (dans le monde Windows), ainsi que le développement orienté objet, préconisaient déjà le découpage des applications en services réutilisables à volonté. En remontant même plus loin, les architectures mainframes utilisaient déjà la notion de services consommés par des terminaux. Jugés trop complexes, Corba et DCOM n'ont pas connu le succès escompté tandis que l'essor d'Internet, notamment, jetait le discrédit sur les technologies propriétaires et coûteuses des acteurs du mainframe. En d'autres termes, les idées étaient bonnes mais les technologies inadaptées. [[PAGE]] Un rêve enfin accessible grâce aux standards Ce qui change avec SOA, c'est que les technologies ont fortement évolué, notamment en termes d'interopérabilité. Qu'elles s'appellent EAI (Enterprise Application Integration) ou ESB (Enterprise Service Bus), les solutions de middleware pour interfacer les services et orchestrer leur dialogue sont aujourd'hui plus matures. Leur rôle, en outre, est facilité par des standards dont ceux des services Web. Trop souvent assimilés, services Web et SOA ne sont pas mariés : on peut mettre en place une architecture orientée service sans jamais utiliser de services Web. Mais le fait est que ces composants applicatifs, parce qu'ils reposent sur des standards ouverts, facilitent la démarche SOA. Surtout quand les applications ne sont pas cantonnées aux seuls usages internes à l'entreprise, comme le souligne Didier Girard, directeur technologique de la SSII Improve : « Exposer des services Cobol en IMS n'est pas contraire à la démarche SOA. Nombre d'entreprises le font et capitalisent ainsi sur leur existant et leurs compétences humaines. Elles pourraient même partager ce service IMS avec un partenaire pour peu qu'il soit également capable d'interpréter IMS, et là encore, la démarche reste SOA. Le seul apport du service Web, certes considérable, est que tous les éditeurs et donc toutes les applications sont désormais capables d'interpréter cette technologie. L'entreprise n'est donc plus freinée par des barrières technologiques dans l'assemblage ou le partage de ses services. » [[PAGE]] Mais le rêve peut se transformer en cauchemar Il ne s'agit pas non plus d'une recette miracle. Une approche SOA comporte aussi ses risques. Découpé en services utilisés et réutilisés au sein de processus divers et variés, le système d'information se transforme en un amalgame de « liens » qu'il faut superviser à la fois aux niveaux technique et métier. Pire, la moindre modification d'un service peut avoir des répercutions sur tous les processus qui l'utilisent. En d'autres termes, l'informatique « spaghetti », si décriée par les acteurs du secteur, fait un retouren force avec SOA. Pour Jean-Christophe Cimetière, chef de produit plate-forme .NET de Microsoft,« les spaghettis étaient nocifstant qu'ils étaient de toutes les couleurs. Avec les services Web, les problèmes de technologies hétérogènes et d'interopérabilité disparaissent ». Un raccourci facile, sur fond d'amalgame entre services Web et SOA. De fait, cette gestion des services mais également de la bonne exécution des processus constitue aujourd'hui un enjeu majeur. Des solutions existent mais elles manquent de maturité. Cette administration des spaghettis, mais aussi des services, n'est d'ailleurs pas la seule difficulté à laquelle les entreprises sont confrontées. Définir la granularité des composants, mettre en place une politique de sécurité adaptée sont également des chantiers complexes pour lesquels l'entreprise devra avant tout faire preuve de rigueur, méthodologie et pragmatisme. Mais le jeu en vaut la chandelle car tendre vers SOA, c'est tendre vers une informatique moins coûteuse (grâce à la mutualisation et à la réutilisation), capable d'évoluer au rythme des besoins de l'entreprise (en recomposant plus rapidement de nouvelles applications à partir des services existants) et surtout plus au service de ses utilisateurs, car focalisée sur les besoins et les processus métiers.

Très friand de statistiques, le Gartner Group a estimé qu'en 2008, 80 % des projets informatiques se construiraient sur la base de SOA, et que les entreprises devraient augmenter leur taux de réutilisation du code de plus de 100 %. Une perspective alléchante, car synonyme de réduction significative des coûts en développement et en délais de livraison des applications, mais qui laisse dubitatif. En effet, pour la plupart des experts, la réutilisation des services, surtout au niveau métier, reste difficile. Un service est un composant dont la première caractéristique est de décorréler le fournisseur du service de son consommateur. Pour permettre au consommateur d'utiliser le service, ce dernier expose ses traitements dans une interface. Elle peut être propriétaire ou standardisée (IDL - Interface Definition Language -, en Corba ou WSDL - Web Service Definition Language -, pour les services Web). Un service peut être utilisé par plusieurs consommateurs, pour un traitement batch massif, un traitement à la demande d'un utilisateur ou même un autre service. Définir une bonne granularité n'est pas aisé Il existe deux principales catégories de services : métier et d'infrastructure. Les premiers couvrent une fonction métier (conversion de monnaie, gestion d'une commande), les seconds s'intéressent aux fonctions techniques transverses du système (création d'une session, accès aux bases de données, etc.). La granularité d'un service varie de « très fine » (fonction unitaire élémentaire) à « grosse » (bloc applicatif constitué de plusieurs services qui masque la logique interne en exposant l'ensemble sous la forme d'un seul service). La réutilisation d'un service dépend de sa granularité. Côté infrastructure, les services récurrents sont en général identifiés et souvent fournis par les éditeurs dans leur atelier de développement. Côté métier, pas de la recette miracle. Un service métier n'est réutilisable par plusieurs consommateurs que si tous les départements de l'entreprise partagent la même définition du client, du contrat, etc. C'est rarement le cas et le consensus n'est pas toujours facile à trouver. En outre, « sur le terrain, la plupart des entreprises élaborent leurs services au coup par coup, explique Jean-Christophe Cimetière, chef de produit plate-forme .NET de Microsoft. Résultat, le service conçu pour un projet n'est pas forcément adapté à un autre ». De plus, la moindre modification d'un service pour l'adapter aux besoins d'une nouvelle application peut provoquer des dégâts en chaîne. « Si vous apportez des modifications à un PGI, toute migration devient un cauchemar car il faut redévelopper toutes les fonctions personnalisées, explique Gérald Karsenti, directeur général adjoint de Sogeti France. Pour éviter d'en arriver là avec les services, il vaut mieux éviter d'empiler les modifications, quitte à concevoir un nouveau service ou faire l'impasse sur des fonctions pour réutiliser l'existant tel quel. » Didier Girard, directeur technique d'Improve, se veut rassurant : « Il n'existe pas de méthode universelle pour découper et gérer ses services. Couvrir un périmètre restreint pour l'étendre à d'autres applications reste la meilleure approche, mais à condition de bien documenter ses services et surtout de gérer les versions. » UDDI, une grande idée pour des résultats encore médiocres Pour aider les entreprises, les éditeurs ont donné naissance à un standard, UDDI, ou l'annuaire universel capable de référencer les services pour les exposer au reste du monde. Le projet était si ambitieux qu'il oubliait de répondre aux besoins basiques. La version 3 d'UDDI devrait se recentrer sur le référencement et la gestion des services des entreprises. En attendant, ces dernières ont mis en place des solutions pragmatiques en s'appuyant sur de simples fichiers textes ou bases de données dont le contenu est publié dans un portail. Chaque fonctionnel et informaticien dispose ainsi d'une vue sur l'ensemble des services disponibles dans l'entreprise. Une solution somme toute efficace.

Une fois conçus et déployés, les services sont prêts à être assemblés pour créer de nouvelles applications. Dans les faits, cet assemblage doit être pensé dès la première phase du projet. C'est également à ce stade que l'entreprise devra déterminer les niveaux de service, un processus pouvant appeler un emboîtement de services de granularité plus fine. Dans ce cadre, il existe des spécifications et des frameworks (cadres applicatifs structurants) pour aider l'entreprise dans sa démarche tels que SCA (Service Component Architecture) ou encore Spring. Un standard pour la modélisation des processus Il existe deux façons d'assembler des services : avec du code pour un processus statique, ou graphiquement selon un scénario d'appel, opération réalisée avec les outils d'orchestration. Le processus statique est surtout adapté à des projets internes incluant peu de services. Sa mise en oeuvre est aussi classique que celle des composants des différents langages, tels qu'un EJB en Java, une classe PHP ou des « assemblies » de .NET. Plus complexe, le processus selon un scénario d'appel suppose des transactions longues pour lesquelles il faut notamment prévoir la gestion de l'asynchronisme, la reprise sur erreur, le mapping des interfaces ou encore la gestion des contrats entre services, etc. Aujourd'hui, des offres complètes connues sous le nom d'ESB (Enterprise Service Bus) couvrent l'ensemble de ces besoins : modélisation, orchestration, intégration (connecteurs, routage des messages, etc.) et même optimisation (BPM - Business Process Management). Les outils de modélisation proposent généralement une interface graphique pour concevoir le processus sous forme de schéma, ce dernier étant ensuite traduit dans un langage exécuté par le moteur ESB. Aujourd'hui, la plupart des éditeurs ont adopté le standard BPEL (Business Process Execution Language), un processus pouvant ainsi en théorie être exécuté par différents moteurs (dans la pratique, l'interopérabilité est plus aléatoire). Toutefois, comme le rappelle Henry Peyret, analyste senior de Forrester Research, « SOA n'implique pas forcément un processus, le service pouvant, par exemple, être directement consommé par un portail ». Didier Girard, d'Improve, va même plus loin en rappelant que le concept de client riche pourrait changer la façon dont les entreprises vont consommer leurs services : « Les utilisateurs pourront assembler les services directement sur leur poste de travail pour se constituer des interfaces sur mesure, répondant réellement à leurs besoins. » L'administration reste le maillon faible Dans tous les cas de figure, l'administration du processus devra être prévue dès le départ. Elle suppose deux niveaux de supervision : technique et métier. En effet, comme dans toute architecture fortement distribuée, le processus fait intervenir différentes briques du système d'information : base de données, applications, moteur d'exécution, etc. Il est donc indispensable de connaître l'état de ces briques, mais également de superviser le déroulement de la globalité du processus du point de vue du service métier rendu. Les outils de BPM couvrent à la fois la modélisation des processus, les simulations et la supervision. Le BAM (Business Activity Monitoring), pour sa part, mesure les performances d'un processus. Mais pas plus l'un que l'autre ne couvre la supervision technique. En d'autres termes, ces outils sont conçus pour surveiller le processus d'un point de vue métier, pas les briques techniques sous-jacentes. Dès lors, si on sait où un processus bloque, on aura plus de mal à déterminer la cause technique. Des éditeurs tels qu'Amberpoint, Tibco ou encore WebMethods se sont rapidement rendu compte du besoin de corrélation entre supervision technique et métier en mettant en place des interfaces pour récupérer les informations en provenance d'outils d'administration classiques tels que HP OpenView, Unicenter de Computer Associates, Patrol de BMC ou encore l'offre Tivoli d'IBM. Toutefois, pour Pascal Grojean, directeur du pôle consulting de SQLI, « cette offre manque encore de maturité, beaucoup de fonctions telles que le filtrage, l'historisation ou encore la gestion de statistiques étant absentes des consoles BAM et de BPM. Dans la plupart des projets, nous sommes obligés de compléter par des développements spécifiques ».

SOA ne rime pas forcément avec big bang. Dans bien des cas d'ailleurs, les entreprises ont tout intérêt à capitaliser sur leur existant pour mettre en place de nouvelles applications composites. En effet, systèmes centraux et applications client-serveur, très fortement décriés d'un point de vue technologique, n'en sont pas moins de véritables mines d'or en termes de formalisation d'un savoir-faire métier. Nombre de fonctions rodées par le temps y existent et il serait dommage de redévelopper cet existant quand on sait que SOA s'en accommode très bien. Rester pragmatique Pour entreprendre une telle démarche, il faut tout de suite oublier les approches des extrémistes de la SOA. On ne va clairement pas saucissonner l'application sur système central en services et tout réorchestrer en processus. L'opération aurait d'ailleurs peu d'intérêt vu que cette application fonctionne en général très bien et continue à rendre le service pour lequel elle a été mise en place. La réutilisation de l'existant s'inscrit plutôt dans une démarche de création de nouvelle application ou d'ouverture à des tiers. Le principe est relativement simple : on isole une fonction de l'application monolithique et on la passe à la moulinette d'une interface (WSDL, IDL ou propriétaire) pour en faire un service réutilisable. Dans la pratique toutefois, l'opération est un peu plus complexe. Il n'est en effet pas rare que la logique métier soit mêlée à la gestion de la présentation dans les applications monolithiques, y compris sur mainframe, où métier et invocation d'un écran 3270 sont parfois mélangés. Pour éviter une intrusion dans un code existant que l'on ne maîtrise plus toujours afin de réécrire proprement la fonction, les acteurs du Web-to-Host, notamment, proposent une solution beaucoup plus simple : l'encapsulation des écrans existants en composants COM, EJB ou encore en services Web. Moins « propre » d'un point de vue purement SOA, cette approche présente toutefois l'avantage de l'efficacité, le service ainsi créé étant dès lors invocable à distance. Cette démarche pourrait également s'appliquer aux applications de type client-serveur si ce modèle de développement ne prévoyait pas souvent une répartition des traitements entre le serveur et le client. La réunification pour concevoir un service digne de ce nom est souvent plus laborieuse que la réécriture pure et simple de la fonction. En outre, un objet COM, par exemple, prévu pour le poste client ne dispose pas forcément des méthodes adaptées pour devenir un composant serveur, capable de gérer des accès distants, parallèles, etc. Là encore, une épuration du code existant est souvent indispensable, opération qui comporte des risques et ne constitue pas forcément la meilleure approche. «Le redéveloppement de la fonction est parfois plus simple et économique, l'application existante continuant à vivre sa vie de son côté », estime-ton chez IBM et Microsoft. Cartographier et analyser avant d'attaquer son existant Dans tous les cas de figure, toute intrusion dans un existant pour récupérer des fonctions sous forme de services suppose un travail préalable d'inventaire et de cartographie du parc applicatif afin d'en comprendre le fonctionnement, la sémantique, les transactions, etc. Une transaction CICS, IMS ou un composant COM pouvant être présents sous différentes formes dans le système, il faut également dans un premier temps déterminer lequel va être utilisé, encapsulé et invoqué à distance. Ces décisions doivent être prises en fonction de critères de développement (facilité à récupérer la fonction sous forme de service), mais également en tenant compte des ressources matérielles : impact de la nouvelle application utilisant le service sur la machine qui héberge l'existant, bande passante disponible, etc.

Dès lors qu'on travaille avec des environnements distribués, il faut gérer des problèmes de sécurité particuliers, estime le directeur technologie & sécurité chez Microsoft France. Avec la SOA, cette sécurisation des architectures est d'autant plus primordiale que chaque service est indépendant des autres. Il faut donc prévoir la sécurité dès la phase de modélisation pour spécifier quel service a le droit de dialoguer avec un autre sans oublier les interactions avec les utilisateurs. » Ainsi, la multiplication des services imbriqués dans un processus accroît la complexité des procédures de sécurité à mettre en oeuvre, mais sur le fond, les solutions reposent sur des recettes classiques : authentification, chiffrement et habilitations. Des standards ouverts pour WSOA Dès 2004, sur proposition d'IBM, Microsoft et Verisign, l'Oasis, consortium en charge de la standardisation des services Web, sortait les spécifications d'un nouveau langage pour sécuriser les architectures WSOA, WS-Security, qui regroupe plusieurs normes assurant le chiffrement des données et l'authentification. Le principe est assez simple : chaque message SOAP intègre une en-tête dans laquelle les règles de sécurité applicables au service Web sont spécifiées en XML sous forme de métadonnées. Cette politique de sécurité s'appuie sur l'échange préalable de jetons (certificats X-509, tickets Kerberos, etc.) entre services Web qui autorisent ou non le dialogue. Ce mécanisme prévoit aussi l'utilisation de normes du W3C telles que XML Signature (pour authentifier un service ou un utilisateur) et XML Encryption (pour chiffrer les données). Par la suite, de nouvelles normes sont venues enrichir WS-Security, dont WS-Trust, qui décrit les conditions de transmission et d'exploitation des paramètres de sécurité par les organismes certificateurs et les tiers de confiance. Plus global, WS-SecurityPolicy permet de décrire les politiques de sécurité entre deux éléments constitutifs d'un processus. Ces échanges pris en charge par le protocole SOAP s'appuient sur une infrastructure globale de sécurité, le mécanisme prévoyant, par exemple, l'interrogation d'un annuaire pour vérifier que l'utilisateur mentionné dans l'en-tête est bien habilité à utiliser un service. Une profusion de métadonnées pour fiabiliser les échanges Pour Didier Girard, directeur technique d'Improve, cette approche de la gestion de la sécurité par des messages sous forme de métadonnées glissées dans le service s'applique à n'importe quelle autre technologie de services propriétaires ou non : « Je ne vois pas comment on pourrait faire autrement, dès lors qu'on travaille avec des services indépendants, susceptibles de dialoguer avec n'importe quel autre service, que d'intégrer le code de sécurité dans le service lui-même sous forme de métadonnées. A moins, bien entendu, d'établir des couplages de services statiques, ce qui ne va pas dans le sens de SOA, qui préfère les couplages lâches. Dans tous les cas, il faudra prévoir, comme avec WSSecurity et SOAP, un middleware pour gérer le contexte des échanges, lire les métadonnées, etc. » Cette profusion de métadonnées dans les architectures SOA n'est d'ailleurs pas limitée à la seule sécurité. En mettant en place des processus transverses, les entreprises sont en effet amenées à piocher dans des bases de données, applications existantes, etc. qui ont été structurées selon des besoins spécifiques. La définition du client dans un PGI n'a par exemple rien à voir avec celle d'un progiciel de GRC ou même une application développée sur mesure. Toucher à la modélisation de la base existante est quasi impossible car cela reviendrait à redévelopper tout ou partie de l'application qui l'utilise. Dès lors, pour créer un processus de type SOA entre ces deux applications, il faudra passer par des métadonnées descriptives du contexte sémantique utilisé par chacune. En d'autres termes, les architectures distribuées, et SOA en particulier, provoquent un véritable retour sur la sémantique. Si l'homme peut associer un mot à un contexte pour lui donner un sens, ce malheureux ordinateur dénué d'intelligence reste en effet encore un supercalculateur cantonné à une compilation de 0 et de 1, capable d'associer des carottes et des choux sans pour autant faire une bonne soupe...