Concepts fondamentaux SOA

Service Oriented Architecture ou SOA était le buzzword à la mode il y a encore quelques temps et semble maintenant rentré dans les moeurs même si je pense que sa définition peut encore être assez floue malgré la littérature foisonnante sur ce sujet. Cet article revient sur les concepts fondamentaux des architectures orientées services.

Service

Un service est une représentation logique d’une activité répétable qui produit un résultat précis. En clair, un consommateur demande à un producteur d’agir afin de produire un résultat.

C’est bien sûr l’élément de base d’une architecture SOA. Ex: fournir les données météo, demander un financement. Comme dans le monde réel, ex :

• En tant que particulier (consommateur)
• Je poste mon courrier (demande)
• Afin que les services postaux (producteur)
• Acheminent mon courrier à l’adresse indiquée (résultat).

Le terme « agir » est important car il implique que le nommage du service contienne un verbe et un complément d’objet pour savoir sur quoi agit ce verbe. Le terme ‘logique » utilisé dans la définition signifie que la représentation du service ne comporte pas la description de la manière dont il s’exécute. Les caractéristiques attendues d’un « bon » service sont :

• il est encapsulé : pas de détails sur son fonctionnement interne
• il est auto-suffisant : pas besoin de lui fournir un environnement d’exécution pour qu’il s’exécute
• il est sans états : son exécution ne dépend pas de l’invocation préalable d’autres services, l’ensemble du contexte qui est fourni lors de l’invocation par le consommateur suffit au service pour exécuter ses actions

Structures de données

Le second concept, qui semble évident d’un premier abord mais est essentiel est …la donnée ou plus précisement la structure de données car une donnée vient rarement de manière isolée. Un service sans données en entrée et en sortie est inutilisable. Les structures de données ont beaucoup évolué sur le fond et la forme ces dernières années.

Sur le fond :

• Les structures hiérarchiques (le XML à la base) laissent la place à des structures en graphe (même si le format est toujours du XML et ce grâce aux références utilisant les identifiants)
• Les données sont parfois sans structure : données non structurées du web (vidéo) ou semi-structurées (Word, Excel, PDF, page HTML)
• L’intégration de méta-données concernant le temps par exemple avec les flux Atom et la modification de données avec AtomPub, permettant surtout de standardiser les opérations de bases. Ou encore l’intégration de données medias avec les opérations associées (OData = AtomPub + des données Media + des opérations de service et leurs méta-données)

Sur la forme :

• Le XML reste fondamental mais le JSON le supplante sur le web pour ses aspects pratiques (pas de binding avec le javascript, meilleure lisibilité tout comme le YAML)
• De même les microformats visent à rendre extrêmement pratique la structure des données en utilisant des conventions avec du simple HTML

Au final, le service est un concept permettant aux différents systèmes composant le système d’information de communiquer entre eux et donc d’échanger des données : bref, une partie du paradigme SOA est lié aux protocoles de communication permettant ensuite de structurer le SI.

Qu’est ce qu’un protocole de communication ?

Parler des aspects essentiels de la communication entre systèmes est important avant de continuer sur cette notion de service. Alors, allons y !

Un protocole de communication définit les éléments permettant à deux systèmes de communiquer, c’est à dire d’échanger de la donnée. Plus précisément, que doit permettre un protocole de communication ?

• Initier la conversation : localisation de l’interface, sécurité
• Communiquer = action + données (en entrée et en sortie), soit verbe + complément
  • Quel format ? Quelle sémantique ?
  • Connaître l’interface : méta-données sur l’utilisation du service et ses caractéristiques (est- il safe ? c’est à dire inclu -t-‘il un changement d’état dans le système hôte ? est- il idempotent ? c’est à dire l’invocation multiple du même service avec les mêmes données en entrée aboutit- elle au même résultat ?)
  • Quel style ? synchrone, asynchrone, orienté action, orienté ressources (REST)
  • Aspects avancés : fiabilité des échanges, transaction
  • Gérer les erreurs, les versions

Schéma et exemple pour illustrer cela :

 

L’interopérabilité a pour objet de faciliter cette communication à priori et c’est là que les standards interviennent afin de formaliser ces différents aspects : comment décrire les opérations (WSDL), la sécurité (basic auth.), les opérations et leurs données (XML Schéma ? RPC, etc.), etc.

Le service est donc décrit par l’action et les données permettant une communication centrée sur l’action.

La composition de service

La composition aboutit à un service composite de plus haut niveau invoquant plusieurs services et qui surtout possède lui-même les caractéristiques d’un service (self-contained, stateless, safe et ou idempotent).

Le service est l’élément unitaire qui va être utilisé, combiné et composé afin de produire des services de plus haut niveau. Le principe de composition est donc essentiel dans une architecture SOA. Les approches objet ont apporté une vision essentiellement structurelle de ce principe, le style SOA en apporte une vision dynamique avec l’orchestration de service à travers les processus et le style architectural dit « Pipe-and-Filter« . Bien sûr cela implique la conservation du contexte et la gestion de transactions, éventuellement longues.

Cette notion est vraiment fondamentale, à tel point que les applications utilisant une architecture orientée service ou un portail sont maintenant dénommées applications composites afin de bien souligner que leur construction se fait à base de composition de services.

Le processus métier

Un processus est un enchaînement d’activités réalisées par un acteur, déclenché par un événement et qui aboutit à un livrable précis.

Les activités du processus peuvent invoquer un ou plusieurs services. Le processus utilise des concepts très différents de celui du service : activité, synchronisation, branche, etc. Le processus est avec état ou autrement dit conversationnel parfois même sur des durées très longues (semaines, mois), alors que le service est sans état. Je trouve d’ailleurs que la séparation entre l’état conversationnel et le service unitaire sans état proprement dit est une des grandes force du SOA.

L’événement

Un événement constate un changement intervenu.

Ce changement peut avoir eu lieu à l’intérieur (événement interne) ou l’extérieur (événement externe) du système, ou simplement constater un instant dans le temps (événement temporel, qui peut alors être absolu, le 22 juillet 2011 à 17H, ou relatif, 1H après la réception de cet événement).

A côté de la demande d’action au service représentée par un verbe (« payer commande ») se trouve la notification de l’événement constatant ce changement sur le domaine représenté par un participe passé (« commande payée »). Un événement contient également des données qui lui sont associées, dans notre cas l’événement « commande payée » contient les données du paiement en plus de la référence à la commande. D’ailleurs il est souvent préférable de priviliégier dans les événements un passage par référence plutôt que par valeur avec appel ultérieur à un service afin d’éviter les données dépassées (« stale data »).

Le traitement de l’événement est fondamentalement asynchrone par rapport à son émission, ce traitement pouvant ensuite lui-même invoquer des service d’actions non-safe entrainant d’autres événements et ainsi de suite.

Ces cinqs concepts sont pour moi les fondamentaux d’une architecture orientée service : le service, la structure de données, le processus, la composition et l’événement. A leurs côtés vont co-exister des principes et mécanismes qui vont enrichir ces blocs de construction.

Les standards

Un autre aspect fondamental, situé ici au niveau physique, concerne l’utilisation des standards d’échange (HTTP, XML, WS-*, etc.), notamment au niveau du protocole de communication. Quel que soit le standard, qu’il soit adapté ou non est un débat à part entière (SOAP vs REST, ou protocole orienté action vs protocole orienté ressource), l’objectif étant ici d’offrir une bonne interopérabilité en se détachant de la technologie d’implémentation. Il est bien sûr possible de faire du SOA avec des protocoles non standardisés et non XML pour des raisons de performance. Demandez à Google ou facebook s’ils utilisent du XML et s’ils ont des caractéristiques dites « SOA » dans leur architecture….voir Thrift et Protocol Buffer à ce sujet. Comme toujours, tout est question de contexte d’utilisation et de besoin.

Mécanismes secondaires

Des mécanismes secondaires sont à l’oeuvre en pratique quand l’architecture SOA devient mature (sur le sujet de la maturité voir le modèle de maturité de l’Open Group ou tout simplement lorsque elle se généralise : le premier mécanisme nécessaire très rapidement est le registre de service qui consiste dans un premier temps à une simple description des services et conditions d’utilisation du service (interface des services même si ce n’est qu’un document Word, heure d’ouverture, niveau de service, disponibilité, etc.). Ensuite le moteur de règles (éventuellement avec une forme déclarative) est un mécanisme permettant de séparer les responsabilités entre l’orchestration et les règles utilisées pour cette orchestration. Enfin les mécanismes de surveillance et de gestion des services sont essentiels pour favoriser une bonne exploitabilité de l’ensemble du système (performances, erreurs, sécurité, optimisation, etc.).

Conclusion

Une architecture SOA utilise à minima les concepts de niveau logique (service, données, processus, composition et événement) et physique (standards pour l’interopérabilité) décrits ci-dessus en plus de quelques mécanismes pratiques (registre, moteurs de règles et monitoring). Cet article vise donc en premier lieu à clarifier la notion d’architecture orientée service, les articles suivants permettront ainsi d’aborder les bénéfices métiers qu’entraîne une bonne maturité SOA.

Liens

SOA Book de l’Open Group

Praxeme, la méthode libre française, très exhaustive et complète.