Terme à la mode, l'architecture orientée services (SOA) ne désigne pas une technologie, mais plutôt un cadre conceptuel, composé d'un ensemble de bonnes pratiques d'architecture logicielle. Elle permet aux directions fonctionnelles d'assembler des briques logicielles ­ les services ­ dans le cadre de processus métier. Pour tenir cet engagement, les applications sont découpées, puis exposées sous forme de services. « Plug & play » et faiblement couplés, ces derniers proposent une interface métier entre le système d'information et les directions fonctionnelles.

« La SOA est la traduction directe des démarches d'urbanisation », synthétise Cyril Dhénin, responsable de la veille stratégique chez Dreamsoft. Cette architecture cible s'intercale entre les besoins métier exprimés par les directions fonctionnelles et les choix technologiques des directions informatiques.

Une SOA garantit que le système d'information pourra évoluer facilement et qu'il restera ouvert quelle que soit la technologie retenue. « Cette architecture tente de corriger les erreurs du passé sans remettre en cause l'existant. C'est un outil pour améliorer le patrimoine applicatif », confirme Jean-Claude Gomes de Miranda, fondateur de l'éditeur De Gamma. Contrairement aux architectures d'objets distribués, essentiellement motivées par des contraintes technologiques, la SOA suit une approche métier consistant d'abord à formaliser les processus, et seulement ensuite à créer les services indispensables à leur bon déroulement.

« L'un des avantages d'une SOA est qu'elle prend en compte dès le début les problématiques d'intégration et de coopération », ajoute Marc Gardette, responsable du groupe architectes chez Microsoft. Les sources de données et les composants logiciels sont, en effet, enrobés d'une couche d'abstraction standard : le service. Si bien qu'il n'est plus nécessaire de savoir de quel logiciel provient l'information pour incorporer le service au sein des processus.

Si l'on associe souvent les services web à une SOA, c'est que Corba, DCOM et les autres tentatives de standardisation d'architectures distribuées ont échoué là où les services web font l'unanimité. De PHP à C++ en passant par .Net et J2EE, toutes les technologies supportent aujourd'hui WSDL et Soap. Ces deux standards se distinguent donc, faisant de SOA un modèle d'architecture indépendant des choix d'implémentation. « En éliminant les dernières barrières technologiques, les services web prouvent la faisabilité et la pertinence de la SOA », synthétise Jean-Philippe Moresmau, directeur technique de l'éditeur Soamai. Gartner prédit ainsi que 75 % des projets SOA s'appuieront sur des services web d'ici à 2008.

Un service est une façade qui se positionne devant le composant ou l'objet pour le standardiser. « Un service est une fonction qui reçoit des messages et les restitue après un traitement », décrit Didier Girard, directeur technique d'Improve. A chaque service est attaché un contrat définissant l'interface du service : formats des messages en entrée et en sortie, point d'accès ( « endpoint » ), etc. Cette approche est identique à celle des mondes Corba et DCOM. Hormis le fait qu'un contrat SOA s'appuie sur WSDL (Web Service Description Language), seul format aujourd'hui reconnu par toutes les plates-formes. Cette spécificité garantit que n'importe qui peut découvrir le service ­ et donc son interface ­ pour peu qu'il soit enregistré dans un annuaire public. Grâce à cette couche d'abstraction, le composant sous-jacent est isolé du monde extérieur et peut ainsi être modifié à volonté tant que son interface reste identique. De même, les règles métier du système d'information peuvent évoluer sans avoir un impact sur le service. Ce couplage faible garantit un bon niveau de réutilisabilité et d'interopérabilité des services.

Les services web et les objets Corba ou les composants COM et les EJB sont donc plus complémentaires que concurrents. Un service expose les méthodes des composants sous-jacents en les agrégeant. Un service « CommandeClient » sera, par exemple, constitué des méthodes « Créer-CommandeClient, » « CréerLigne-CommandeClient » , « Valider-CommandeClient » , etc. fournies par un EJB, un Enterprise Service .Net ou une classe PHP. Un service peut être vu comme un « concenrateur de méthodes » .

D'un côté, le service dialogue avec l'extérieur à l'aide d'un document XML standard de grosse granularité. De l'autre, le ou les composants sous-jacents exposent des méthodes de plus faible granularité. Une couche de « mapping » est donc nécessaire pour relier la façade aux composants sous-jacents. Ne serait-ce que pour convertir les types de données.

La standardisation des formats de messages participe au découplage et garantit à l'entreprise la possibilité de mailler ses services avec ceux de ses partenaires. On peut ainsi voir un service comme un émissaire proposant différents niveaux d'accès au système d'information. Plus le tiers qui consomme le service est distant, plus il devra se contenter d'une interface standard et faiblement couplée. Un partenaire s'appuiera, par exemple, sur l'échange d'un document XML « CommandeClient » asynchrone via HTTP. Inversement, le PGI de l'entreprise pourra accéder à la méthode « CréerLigneCommandeClient » via IIOP. Des initiatives telles que Web Services Invocation Framework (WSIF), de la fondation Apache, facilitent ce genre d'implémentation.

Bien que ces deux types de communication ­ RPC et orientée document ­ soient possibles, la plupart des experts privilégient des échanges entre services basés sur des données plutôt que des appels de méthodes. « Les données sont facilement standardisées par un schéma, alors que c'est impossible pour des appels de méthodes », explique Clemens Vasters, directeur technique de Newtelligence. « Les progiciels proposent aujourd'hui souvent plus de cinq cents méthodes accessibles via des services web. Mais est-ce la bonne approche ? Un processus utilisant des documents métier ­ facture, bon de commande, etc. ­ est bien plus facile à manipuler qu'une API, aussi standard soit-elle », constate Tanguy Crusson, consultant chez Intalio. L'objectif ultime d'une SOA est de faciliter l'agrégation de services. Cet assemblage s'effectue grâce à une couche d'orchestration de processus. Associée à la standardisation des contrats et des messages, cette approche permet de découpler le processus métier des différents services, rendant une fois encore le système d'information plus souple et pérenne. D'autant que de nombreux standards, tels BPEL (Business Process Execution Language), BPMN (Business Process Modeling Notation) ou BPML (Business Process Modeling Language) garantissent à l'entreprise que ses processus pourront être modélisés et exécutés avec les outils de différents éditeurs. « En s'appuyant sur un référentiel de processus et de documents métier, les architectures orientées services se distinguent notablement des modèles proposés par Corba ou DCOM. De ce point de vue, la SOA est davantage une démarche métier qu'une technologie, » constate Sami Jaber, architecte chez Valtech.

Les processus sont d'ailleurs formalisés par des profils fonctionnels, tandis que les services (façade et composants sous-jacents) sont développés par des équipes techniques. C'est ensuite à l'architecte de connecter les services aux processus. Contrairement aux architectures distribuées traditionnelles, la SOA propose donc une répartition des rôles simple et facile à mettre en oeuvre. La capacité des équipes à modéliser les processus métier et à définir le bon niveau de granularité des services reste primordiale dans une démarche SOA. Des services trop gros ou trop fins peuvent, en effet, devenir aussi difficiles à réutiliser que des objets fortement couplés. « Le recours aux services web n'élimine aucunement ce risque », prévient Gartner.