Une architecture orientée services est un paradigme fondé sur la description de services et sur la description de leurs interactions [3]. Les caractéristiques principales d’une architecture orientée services sont le couplage faible entre les services, l’indépendance par rapport aux aspects technologiques et la mise à l’échelle. La propriété de couplage faible implique qu’un service n’appelle pas directement un autre service. En e et, les interactions sont gérées par une fonction d’orchestration [4]. La réutilisation d’un service est alors plus facile, du fait qu’il n’est pas directement lié aux autres services de l’architecture dans laquelle il évolue. L’indépendance par rapport aux aspects technologiques est quant à elle, obtenue grâce aux contrats d’utilisation associés à chaque service. En e et, ces contrats sont indépendants de la plateforme technique utilisée par le fournisseur du service. En n, la mise à l’échelle est rendue possible grâce à la découverte et à l’invocation de nouveaux services lors de l’exécution. Pour ce concept, les définitions sont nombreuses et nous retiendrons les suivantes :
– “L’architecture orientée services est un paradigme permettant d’organiser et d’utiliser des savoir-faire distribués pouvant être de domaines variés. Cela fournit un moyen uniforme d’offrir, de découvrir, d’interagir et d’utiliser des savoir-faire pour produire le résultat désiré avec des pré-conditions et des buts mesurables “(établie dans le modèle de référence OASIS) [5] ;
– “L’architecture orientée services permet l’intégration d’applications et de ressources de manière flexible en : représentant chaque application ou ressource sous la forme d’un service exposant une interface standardisée, permettant à un service d’échanger des informations structurées (messages, documents, objets métier), coordonnant et en organisant les services a n d’assurer qu’ils puissent être invoqués, utilisés et changés efficacement ” [6].
De ces deux définitions, nous ressortons une idée principale, à savoir la notion d’organisation des services offerts par des fournisseurs. Malgré le manque de spécification officielle pour définir une architecture orientée services, trois rôles clés sont communément identifiés :
– Le rôle de producteur de services,
– Le rôle de répertoire de services,
– Le rôle de consommateur de services.
Le producteur a pour fonction de déployer un service sur un serveur et de générer une description de ce service. Cette dernière précise à la fois les opérations disponibles et leur mode d’invocation. Cette description est publiée dans un répertoire de services, aussi appelé annuaire. Les consommateurs peuvent découvrir les services disponibles et obtenir leur description en lançant une recherche sur un répertoire. Ils peuvent ensuite utiliser la description du service ainsi obtenue pour établir une connexion avec le fournisseur et invoquer les opérations du service souhaité.
On peut avoir donc le schéma récapitulatif suivant :
Fig. 1.1 Les architectures orientées services
A ce type d’architecture, s’associe un concept déterminant qui est celui de couplage faible. Tout comme le paradigme SOA, le concept de couplage faible ne donne pas lieu à une définition officielle qui fasse l’unanimité. L’objectif communément admis est cependant d’introduire le minimum de dépendances entre les services pour permettre d’assembler ceux-ci aisément. Il s’agit notamment de favoriser la réutilisation de services existants et déjà déployés, ainsi que leur combinaison, a n de répondre rapidement et à faible coût à de nouveaux besoins métier. Pour atteindre cet objectif, un certain nombre de règles d’ingénierie, spécifiques ou non au paradigme SOA, ont été identifiées comme favorisant le couplage faible et la réutilisation. Ces différentes règles que nous allons présenter sont spécifiques aux SOA [7] :
Une interface simple et ubiquitaire doit être fournie par tout service, cette interface doit de plus, être accessible universellement par tout fournisseur et tout client de services. L’interfaçage est fondamentalement important. En e et, une interface générique permet d’interconnecter n’importe quels services et faire transiter n’importe quels messages entre les différentes interfaces. Le maître mot est ici le “découplage”, cette notion pouvant prendre diverses connotations [8] :
– Réduire le couplage entre modules pour une meilleure réutilisation,
– Réduire le couplage vis à vis de l’infrastructure et de la plateforme d’implémentation, pour une meilleure interopérabilité,
– Réduire le couplage entre le client d’un service et une implémentation spécifique de ce service, pour une meilleure évolutivité.
Les messages délivrés par un service ne doivent pas contenir la logique métier, ils doivent au contraire être restreints au transport de simples structures de données d’un service à un autre. Cela permet entre autres de modifier ou d’ajouter des services sans impacter les autres services de l’architecture.
En toute rigueur, un service bien formé est sans état, il reçoit les informations nécessaires dans la requête d’un client dont il ignore l’existence à priori. Cette règle, qui peut sembler très contraignante, doit être nuancée. Il est recommandé que la conservation des états (gestion de contextes) ainsi que la coordination des actions (transactions) soient localisées dans une fonction spécifique de l’architecture SOA, telle que l’orchestration.
C’est donc cette dernière qui dispose d’un état et non pas les services orchestrés (la notion d’état est donc gérée à un plus haut niveau d’abstraction). L’application d’une telle règle favorise la réutilisation, le passage à l’échelle et la robustesse des services.
Un service doit offrir une certaine cohésion. La cohésion est une règle délicate à définir, elle traduit le degré de proximité fonctionnelle des opérations exposées par un service. En d’autres termes, elle vise à favoriser la facilité de compréhension et la réutilisation d’un service en y regroupant des opérations homogènes constituant une unité métier.
Un service devrait être idempotent. L’idempotence permet d’ignorer les réceptions multiples d’une même requête. Le service est donc rendu correctement, que la requête arrive une ou plusieurs fois. L’utilisation d’un tel service permet de relâcher les hypothèses de fiabilité sur la couche de communication.
On notera que, si certaines règles sont bien maîtrisées, d’autres sont plus contraignantes (l’idempotence par exemple) et à ce titre moins appliquées.