Architecture orientée services

L'architecture orientée services ou AOS (calque de l'anglais service-oriented architecture, SOA) est une forme d'architecture de médiation qui est un modèle d'interaction applicative qui met en œuvre des services (composants logiciels) :

• avec une forte cohérence interne (par l'utilisation d'un format d'échange pivot, le plus souvent XML ou JSON) ;
• des couplages externes « lâches » (par l'utilisation d'une couche d'interface interopérable, le plus souvent un service web WS-*).

Ce terme est apparu au cours de la période 2000-2001^[1] et concernait à l'origine essentiellement les problématiques d'interopérabilité syntaxique en relation avec les technologies d'informatique utilisées en entreprise. Cette conception a évolué pour désigner maintenant le sous-ensemble particulier d'architecture de médiation en fonction de la technologie disponible.

Dans la vie de tous les jours, un fournisseur offre un service à un client le consommant dans une relation de confiance établie entre les deux parties. En général, le client s’intéresse uniquement au résultat produit du service sans avoir le besoin ni le souci de savoir comment ce dernier est obtenu. La SOA suit ce même principe. Le service est une action exécutée par un « fournisseur » (ou « producteur ») à l'intention d'un « client » (ou « consommateur »), cependant l'interaction entre consommateur et producteur est faite par le biais d'un médiateur (qui peut être un bus) responsable de la mise en relation des composants. Le service étant à grandes mailles, il englobe et propose les fonctionnalités des composants du système. Ces systèmes peuvent aussi être définis comme des couches applicatives. L'architecture orientée services est une réponse très efficace aux problématiques que rencontrent les entreprises en termes de réutilisabilité, d'interopérabilité et de réduction de couplage entre les différents systèmes qui implémentent leurs systèmes d'information. Les SOA ou AOS ont été popularisées avec l'apparition de standards comme les Services Web dans l'e-commerce (commerce électronique) (B2B, inter-entreprise, ou B2C, d'entreprise à consommateur), fondés sur des plates-formes comme Java EE ou .NET. Elles mettent en application une partie des principes d'urbanisation. Au sein de l'architecture orientée services, on distingue les notions d'annuaire, de bus, de contrat et de service, ce dernier étant le noyau et le point central d'une architecture orientée services. La déclinaison ou plus précisément la mise en œuvre de la SOA qui repose entièrement sur Internet est appelée la WOA (Web-oriented architecture).

Historique

Au cours de la décennie 1980-1990, la problématique de l'interopérabilité des systèmes d'information, particulièrement complexe lors de la fusion ou de l'acquisition d'entreprises, a donné naissance au domaine de recherche de l'interopérabilité des données ; c'est à cette époque que l'on distingua l'interopérabilité syntaxique de l'interopérabilité sémantique des données. Ces recherches aboutirent aux systèmes multibases, aux développements des bases de données réparties et à l'architecture fédérée. En raison de nombreux problèmes insolubles, l'architecture fédérée fut pratiquement abandonnée^[2].

Les deux principales exigences fonctionnelles qui se sont dégagées au cours de cette période sont :

1. Les différents producteurs d'information doivent pouvoir continuer à utiliser leur système de façon transparente. Par exemple, un trust réalisant une acquisition ne doit pas handicaper son nouveau membre en imposant un changement brutal de système informatique ;
2. L'organisation doit pouvoir obtenir une synthèse de l'information produite par ses différents membres. Il s'agit ici d'information en lecture seule, la synthèse s'effectuant toujours du bas vers le haut.

Ces exigences fonctionnelles se cristallisèrent avec l'invention par Gio Wiederhold de l'architecture de médiation en 1990-1992^[3] :

1. Les usagers finaux sont séparés des sources de données par une couche de médiation (couche de services) permettant une synthèse dynamique de l'information ;
2. Les différents médiateurs (services) peuvent communiquer entre eux pour transformer et combiner l'information provenant de différentes sources ;
3. Les différents médiateurs (services) communiquent en utilisant un langage offrant une grande capacité d'expression sémantique et de transformation.

La recherche sur la médiation de données porta alors sur la création d'architecture générique comme le ARPA I3 où apparurent les cinq grandes familles de services (Adaptation, Transformation, Extension, Management et Coordination), le développement de langages à haute expressivité sémantique comme KQML et les outils de transformation sémantique de l'information comme les ontologies^[4].

Parallèlement, le développement de la technologie Web rendit progressivement les autres technologies d'informatique distribuée de moins en moins attrayantes. L'arrivée en 1996 d'XML provoqua un engouement pour ce langage dans le milieu de la recherche et les langages ad-hoc ou plus complexes comme KQML furent pratiquement abandonnés, du moins pour ce type d'architecture. L'industrie développa de nombreux produits sous l'impulsion de la recherche fondamentale, par exemple, on compte plus de 150 Ph.D. en ligne directe de Wiederhold^[5], la plupart ayant participé activement au développement de cette technologie chez IBM, Oracle, Sun, Microsoft, Cisco, Samsung, LG, Bell Laboratories, Silicon Graphics, Kodak, Google, Napster et autres ; comme James Duncan Davidson qui fut le créateur de Tomcat (Java Servlet et JavaServer Pages) ainsi que de Ant. À la fin de la décennie 1990-2000, on trouvait un nombre considérable de ce type de technologies dont l'interopérabilité était parfois extrêmement problématique, du moins sans recette logicielle pour la réaliser^[6].

Concepts

Une architecture orientée service se conforme à divers principes de gestion des services influençant directement le comportement intrinsèque d’une solution logicielle et le style de sa conception :

• L’encapsulation des services.
• Le faible couplage des services avec la maintenance d’une relation réduisant les dépendances.
• Le contrat de service adhère à un accord de communication, collectivement défini avec un ou plusieurs documents de description.
• L’abstraction des services dissimulant la logique du service à l’extérieur.
• La réutilisation des services partageant la logique entre plusieurs services avec l’intention de promouvoir la réutilisation.
• La composition des services.
• L’autonomie des services.
• L’optimisation des services.
• La découverte des services depuis leur description extérieure.

L’architecture orientée service représente un moyen technique d’intégration des divers systèmes d’information de l’entreprise considérant chaque ressource informatique comme un service. Elle permet de construire les buildings blocks qui composeront l'urbanisme du système d'information^[7].

La notion d’interface est importante dans l’approche orientée service. En effet, elle représente le point d’entrée unique vers les fonctionnalités de la solution logicielle et assure la communication grâce à l’échange de messages. Chaque message est porteur de la sémantique particulière à la solution logicielle. De plus ce message est rédigé dans un langage compréhensible aux deux parties en présence. Les services proposés d’une architecture agile décrivent la structure des messages qu’ils attendent du client.

L’architecture orientée service est une solution logicielle distribuée. Elle propose un mécanisme d’échange de messages sécurisé entre les systèmes d’informations sous-jacents en employant des protocoles de communication standardisés. Cette approche offre à l’architecture une opportunité d’ouverture sur un large éventail de solutions logicielles existantes.

Service

Le service est un composant clef de l'architecture orientée services. Il consiste en une fonction ou fonctionnalité bien définie. C'est aussi un composant autonome qui ne dépend d’aucun contexte ou service externe. Il est divisé en opérations qui constituent autant d'actions spécifiques que le service peut réaliser. On peut faire un parallèle entre opérations et services d'une part, et méthodes et classes dans le mode orienté objet d'autre part.

Une architecture orientée services consiste essentiellement en une collection de services qui interagissent et communiquent entre eux. Cette communication peut consister en un simple retour de données ou en une activité (coordination de plusieurs services).

Un service est une entité de traitement qui respecte les caractéristiques suivantes :

• Large granularité (coarse-grained) : les opérations proposées par un service encapsulent plusieurs fonctions et opèrent sur un périmètre de données large au contraire de la notion de composant technique.
• Interface : un service peut implémenter plusieurs interfaces, et aussi plusieurs services peuvent implémenter une interface commune.
• Localisable : avant d’appeler (bind, invoke) un service, il faudra le trouver (find).
• Instance unique : à la différence des composants qui sont instanciés à la demande et peuvent avoir plusieurs instances en même temps, un service est unique. Il correspond au design pattern Singleton.
• Couplage faible (loosely-coupled) : les services sont connectés aux clients et aux autres services via des standards. Ces standards assurent le découplage, c'est-à-dire la réduction des dépendances. Ces standards sont des documents XML comme dans les web services.
• Synchrone ou asynchrone.

Une déclinaison du service est par exemple le service Web qui utilise WSDL (un métalangage XML) comme langage de description, un annuaire UDDI pour en permettre la localisation et un protocole de transport comme HTTP dans l'architecture REST et SOAP pour l'architecture SOA.

Il existe une hiérarchie des services correspondant aux différentes couches techniques de l'architecture d'une solution :

• Les services de présentations ou de référencement vers les informations affichées et les formulaires de saisies de données.
• Les processus métiers composés de tâches décrites et faisant appel éventuellement à d’autres services.
• Les services de gestion et d’accès aux bases de données.
• Les services d’intégration chargés de la messagerie ou de l'échange de données tant à l’intérieur que vers l’extérieur comme la gestion des courriers électroniques.

Annuaire de services

L'annuaire de services référence l'ensemble des services (et des contrats associés) disponibles au sein du SI, il participe ainsi activement à la mise en œuvre d'une cartographie dynamique du SI. Dans un modèle de bus, l'annuaire peut être autoalimenté par le service (enregistrement). Les annuaires UDDI forment aujourd'hui le standard de référencement des services.

Implémentations basées sur SOA

Bus de service

L'implémentation la plus commune de SOA est celle basée sur un bus de services. Ce bus a un rôle de médiateur (middleware) entre le consommateur et le producteur du service, il permet ainsi de réaliser le couplage lâche. Le bus peut aussi fournir une gamme de services :

• sur la base des patterns EIP (enterprise integration pattern), fournir des fonctionnalités de fractionnement, combinaison permettant de construire l'appel sur plusieurs services ;
• des fonctionnalités de gestion de version de service ;
• des fonctionnalités de supervision et contrôle (avec SLA) des services.

On parle généralement d'ESB (Enterprise Service Bus), outil de nouvelle génération pour l'IAE (Intégration d'Applications d'Entreprise, EAI) construit sur des standards comme XML, JMS (Java Message Service) ou encore les services web. La différence majeure avec l'IAE réside dans le fait que l'ESB propose une intégration complètement distribuée grâce à l'utilisation des conteneurs de services. Ces "mini-serveurs" contiennent la logique d'intégration et peuvent être déposés n'importe où sur le réseau. L'ESB est principalement un outil d'échange asynchrone disposant d'interfaces standardisées (SOAP, JMS…) ou intégrées (JBI…). Il peut aussi offrir des services à valeur ajoutée (traduction, transformation…) activés par des événements.

WOA (Web-oriented architecture)

Une autre possibilité pour mettre en place SOA au sein d'un SI consiste à utiliser le web comme unique support de service (et non un bus). Cette approche est rendue possible par le fait que le web contient d'ores et déjà les qualités nécessaires à une SOA (routage, sécurité…).

Cependant, une telle architecture impose que tous les services soient exposés sur le web (ce qui signifie accessible depuis un URL), privilégiant ainsi les services web (rappelons que les services web ne sont pas le seul moyen d'exposer des services sur le web). L'avantage de cette conception est que le support des messages d'invocation de service (le web donc) est vraiment universel et ne nécessite aucune configuration, maintenance, évolution… Mais cette solution est actuellement assez dépréciée dans les situations où les performances sont un critère discriminant (cf. inconvénients des services web).

Cette solution semble, en termes de pure architecture (considérations techniques mises à part), vraiment plus conforme aux principes de SOA^[8].

À l'heure où ce paragraphe a été écrit (été 2008), WOA est encore jeune et sans véritable formalisme, elle suscite encore de nombreux débats. Ainsi il est nécessaire de prendre tout le recul nécessaire quant à la description présentement faite de WOA

Qworum est un exemple de technologie WOA.

Protocoles et normes

Les architectures SOA se reposent principalement sur l’utilisation d’interface d’invocation (SOAP, ancien acronyme de Simple Object Access Protocol) et de vocabulaire de description de données (WSDL, Web Services Description Language et XML, Extensible Markup Language) qui doivent être communs à l’ensemble des agents (fournisseurs de services et utilisateurs de services).

Ce dispositif permet de réutiliser les applicatifs métiers, le but étant de permettre à l’entreprise de s’adapter rapidement à un nouveau contexte de marché.

En termes d'intéropérabilité, les architectures SOA reposent en partie sur les normes décrites à travers le WS-I.

Parmi les différentes couches de normes et protocoles qui permettent de bâtir de telles architectures, on relève :

• la gestion d'un annuaire de services (quels sont les services mis à disposition et par qui) avec : UDDI (Universal Description Discovery and Integration) normalisé par l'OASIS ;
• la description des interfaces des services (quelles sont les données nécessaires à l'exécution du service, que fournit-il en retour...) avec : WSDL recommandé par le W3C ;
• l'invocation (ou l'appel) du service (la requête transmise au service) avec : SOAP recommandé par le W3C ;
• le format des données échangées avec : XML recommandé par le W3C ;
• et enfin, le transport des données avec les protocoles internet : HTTP et TCP/IP qui sont des recommandations RFC.

Une architecture SOA pourra être complétée par :

• la gestion de la sécurité avec : SSL (Secure Sockets Layer), XML Signature, XML Encryption, SAML (Security Assertion Markup Language) ou encore XKMS (XML Key Management Specification, qui gère les infrastructures à clé publique ou PKI) ;
• l'orchestration (on parle également de chorégraphie) des services pour constituer des processus métier avec : BPEL4WS (Business Process Execution Language For Web Services) devenu WS-BPEL et qui est un dérivé à la fois de WSFL (Web Services Flow Language) d'IBM et de XLang de Microsoft qu'il a remplacés, devenant de fait le standard de l'orchestration des services web. On peut aussi citer WSCI (Web Services Choregraphy Interface). L'orchestration suppose l'existence d'un chef d'orchestre (WS-BPEL est un langage d'orchestration), tandis que la chorégraphie implique des interactions pair-à-pair. WS-CDL (Web Services Choregraphy Description Language) est un exemple, le plus récent, d'un tel langage ;
• la gestion transactionnelle (gestion du protocole de validation à deux phases, two-phase commit, pour la mise à jour contrôlée de plusieurs bases de données réparties entre plusieurs fournisseurs de services : la transaction « attend » de recevoir l'acquittement (le commit) des différents serveurs sollicités et en cas de problème avec l'un d'eux, est en mesure de demander aux autres serveurs de « défaire » les mises à jour partielles effectuées afin de maintenir l'intégrité des données) : WS-Transaction d'IBM, XAML (Transaction Authority Markup Language) ou encore BTP (Business Transaction Protocol).

Organisme de normalisation

OASIS^[9] (Organization for the Advancement of Structured Information Standards) est un consortium à but non lucratif qui pilote le développement, la convergence et l'adoption des standards "OPEN" pour les architectures de systèmes d'information.

Technologies basées sur les principes de SOA

• Service Component Architecture (SCA) est une technologie d'assemblage de composants dans laquelle on considère que tout composant peut exposer des services et que toute dépendance est un lien vers un autre service. Ainsi, créer une application devient un simple assemblage de services, et on peut très aisément publier notre application comme un service sous divers formats (JBI, WS, RMI…).
• Qworum^[10] est une plate-forme qui permet de construire des applications web en combinant des services accessibles par le réseau. Ces services sont interactifs : chaque service peut interagir avec l'utilisateur final par le biais de pages web. Chaque service peut également être composé d'autres services.
• MentDB Weak^[11] est une plateforme où tout ce qui est programmé est automatiquement un service web. Il ne reste plus qu'à les connecter ensemble pour bénéficier pleinement de l'organisation SOA. Mais le système va plus loin que de simples échanges de données, son langage de programmation est volatile. En isolant du code dans un tunnel (à condition d'avoir les droits), le code source peut être exécuté sur un serveur distant. Il devient simple d'imaginer un système d'information ou le code source ne serait présent que sur une seule machine: pas de déploiement à faire sur tout un parc. Tout en gardant les accès aux données sécurisés, même si ces données proviennent de différentes sources, tout est vu comme si elles provenaient d'une seule et unique source.

Évolutions et tendances

Aux alentours de 2013 un certain nombre d’entreprises, tel Netflix^[12], ont appliqué les patterns de la SOA en prenant en compte les évolutions technologiques (conteneurisation, kubernetes, kafka…) de l'époque. Les retours d’expérience précédents ont permis d’affiner certains des principes, notamment la granularité des services^[13], d’où l'appellation de « Microservices ». De ce point de vue, on peut considérer les microservices comme une évolution de la SOA^[14].

Exemples

La SNCF a mis en place une architecture de type SOA pour son système de réservation (recherche d'horaire, demande de tarif, réservation…) qui prend en charge à la fois les terminaux des guichets des agences et gares, et les sollicitations de son site web de commande en ligne Voyages-sncf.com.

Le groupe Air France-KLM a lui aussi décidé en juillet 2008 de choisir une architecture orientée service pour son SI (architecture à base de web services, elle remplacera à terme l'architecture SOA « maison » qui est en place depuis les années 1990). L'entreprise opte pour cette architecture dans le but de « rendre son SI à la fois évolutif et réactif » ^[15].

Enfin, l'administration française se modernise également à travers la rénovation de l'infrastructure technique dans certains ministères, dont la Défense et les anciens combattants. Par exemple, l'équipe de projet du prochain système d'information ministériel des achats envisage de recourir à une architecture de services reposant sur un ESB. En effet, ce SI HA ministériel devra échanger avec de nombreux autres. Ainsi, la SOA lui permettra de s'intégrer dans un paysage contraint par un fort besoin d'interopérabilité.

Références

Voir aussi

Bibliographie

• Service-Oriented Architecture Compass - Business Value, Planning and Enterprise Roadmap IBM Press Books by Pearons plc. (ISBN 0-13-187002-5)
• Berg (Martin van den), Bieberstein (Norbert),Ommeren (Erik van), SOA for Profit : guide du manager pour une SOA réussie, Sogeti et IBM, 2007
• Manager avec les ERP, architecture orientée services (SOA), de Jean-Louis Lequeux, Editions d'organisation, Paris, Avril 2008. (ISBN 978-2-212-54094-9)
• Birol Berkem, Why SOA services need to be based on the Business Motivation Model (BMM) ?, June 2008
• SOA , microservices et API management, 4e édition, Xavier Fournier-Morel, Pascal Grojean, Guillaume Plouin, Cyril Rognon, Collection InfoPro, Dunod, 2017

Articles connexes

• Architecture de médiation
• Architecture ARPA I3
• Urbanisation
• Service Component Architecture (SCA)
• Service Web
• Liste des spécifications des Services Web WS-*
• Architecture orientée évènements
• Client-serveur
• Architecture trois tiers
• Web-oriented architecture
• Détection d'anti-patrons de conception dans les architectures orientées services
• Microservices