Architecture orientée services - Définition

Le service

La définition des WebServices

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.

Les concepts

Concepts des SOA

Le service est l'unité atomique d'une architecture SOA. Une application est un ensemble de services qui dialoguent entre eux par des messages.

Le couplage entre services est un couplage lâche et les communications peuvent être synchrones ou asynchrones.

Le service peut :

• être codé dans n'importe quel langage ;
• s'exécuter sur n'importe quelle plate-forme (matérielle et logicielle).

Le service doit :

• offrir un ensemble d'opérations dont les interfaces sont publiées ;
• être autonome (disposer de toutes les informations nécessaires à son exécution : pas de notion d'état) ;
• respecter un ensemble de contrats (règles de fonctionnement),
• correspondre aux processus métier et fonctions mutualisables au niveau de l'entreprise afin d'aligner l'informatique aux changements des décisions stratégiques et tactiques.

Implémentations basées sur SOA

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

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.

A 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

On peut mentionner Qworum, décrit plus loin, comme exemple de technologie WOA.