L’architecture orientée services (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 logiciel) avec une forte cohérence interne (par l’utilisation d’un format d’échange pivot, le plus souvent XML) et des couplages externes « lâches » (par l’utilisation d’une couche d’interface interopérable, le plus souvent un service web WS-*).

SOA

Ce terme est apparu au cours de la période 2000-2001 et concernait à l’origine essentiellement les problématiques d’interopérabilité syntaxique en relation aux technologies d’informatique distribuée 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.

Le service est une action exécutée par un « fournisseur" » (ou « producteur ») à l’attention 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 architectures 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), basés sur des plates-formes comme J2EE 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 se repose entièrement sur Internet est appelée la WOA (Web Oriented Architecture).

[singlepic id=15 w=680 h= float=]

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 : A 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 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 meta langage 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.

ESB

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, etc. 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.

[singlepic id=17 w= h= float=]

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.

• Interconnexion multi SI :
  • Invocation : Offres des interfaces de requêtage (Web Services, MQ/JMS, Fichiers, etc…)
  • Possède des connecteurs vers les sources de données (CTG, Web Services, MQ/JMS, fichiers, …)
• Ses rôles :
  • Respect des Enterprise Integration Patterns
  • Manipulation complexe de messages en gardant l'indépendance et la flexibilité des autres systèmes
  • Mapping : Transformer les données entre les interfaces de requête et les sources de données
  • Médiation : Agréger les données provenant de différentes sources
  • Point d'entrée unique sécurisé (HTTPS + habilitations)
  • Séparation des responsabilités : Masquer la complexité du SI
  • Orchestrer les macro processus organisationnels
  • Conserver les flux pour les rejouer
  • Monitorer les flux
  • Gérer la transcodification inter-référentiels
  • Identifiants personnes et contrats
  • Codes techniques (codes Pays OSCE -> ISO par exemple)

Sources :
Livre Blanc – Comprendre et savoir utiliser un ESB dans une SOA

Description de l'article Architecture orientée services de Wikipedia, utilisé sous licence CC-BY-SA, liste des contributeurs ici. Les pages communautaires ne sont pas affiliées ou avalisées par les personnes associées à ce sujet.