Concept: Composition et chorégraphie des services
Ce concept décrit la façon dont les services peuvent être combinés afin de produire des structures composites et collaboratives fournissant des services orientés métier de plus haut niveau.
Relations
Description principale

Introduction

Un des aspects essentiels de l'architecture SOA est que les services peuvent être composites, ce qui signifie qu'un nouveau service est souvent composé comme une collaboration entre plusieurs services existants. Par bien des aspects, cela est aussi vrai pour les techniques à base de composants et orientées objet, mis à part que certaines fonctions du logiciel intermédiaire (middleware) utilisées pour développer des solutions orientées services permettent l'exécution du reste de ces collaborations à l'aide de standards comme le Langage d'exécution du processus métier pour les services Web (BPEL4WS, WS-BPEL ou simplement BPEL). C'est cette possibilité de composer la structure des services, c'est-à-dire de définir les dépendances d'utilisation entre les services, mais aussi de composer les services en fonction des comportements, qui rendent l'architecture axée services et la stratégie informatique si intéressantes pour de nombreuses organisations.

De plus en plus d'organisations prennent conscience de la nécessité d'améliorer leur réactivité vis-à-vis des changements des environnements métier, que ce soit à cause de la pression liée à la globalisation, des nouveaux marchés et des nouveaux canaux ou encore des nouveaux concurrents utilisant la technologie de manière plus efficace. Ces organisations considèrent le développement orienté services et les solutions orientées services comme un moyen d'organiser leurs équipements informatiques, afin de gérer les exigences actuelles et de fournir une infrastructure de fonctions correspondant à l'entreprise et pouvant être réutilisée, reconfigurée et recombinée de manière efficace pour gérer les exigences futures.

Composer les services de cette manière permet aussi d'ajouter facilement aux nouvelles solutions aussi bien des équipements informatiques existants que des équipements plus récents. Par exemple, des équipements existants, même s'ils ont été développés pour les plateformes de grands systèmes, peuvent être présentés comme des services ayant des produits middleware et être intégrés de la même façon que les nouveaux services développés à l'aide de J2EE, IBM WebSphere ou Microsoft .NET. Malheureusement, la plupart des équipements existants sont développés avec des interfaces qui ne tiennent pas compte des conseils que nous mettrions en oeuvre pour les nouveaux services. Il est donc utile de créer des services composites qui n'englobent pas seulement ces services existants, mais qui fournissent des interfaces différentes, correspondant mieux à l'entreprise et qui tirent partie des fonctions existantes en les regroupant et en les organisant de manière à produire une fonction de niveau supérieur.

Chorégraphie des services

Revenons brièvement sur le terme chorégraphie. Ce terme est utilisé dans de nombreux produits middleware pour dénoter l'exécution gérée d'un script, signifiant la présence d'un flux de procédés dont les participants sont des services et les tâches des messages échangés. Pour certains produits, le terme orchestration est utilisé. Si certains analystes et technologues du domaine décrivent les différences existant entre le sens de ces mots et la façon dont ces termes sont utilisés dans les standards, pour la plupart des utilisateurs ces différences ont beaucoup moins d'intérêt que les similitudes.

En termes de standards, une façon commune de représenter la chorégraphie des services Web est apparue tardivement, après que la plupart des fournisseurs principaux de middleware ont introduit leurs propres solutions. Le standard actuel utilisé dans le domaine est le langage BPEL (Business Process Execution Language) pour les services Web (BPEL4WS ou BPEL). Pour plus d'informations sur BPEL4WS, consultez le site OASIS WSBPEL ou le site IBM BPEL.

Les services en tant que structures composites

Les services peuvent facilement être développés grâce aux fonctions fournies par les autres services de manière récursive, comme l'indique le diagramme ci-dessous, où les services peuvent identifier les services dont ils dépendent. Dans ce cas, un service composite utilise les services passerelles de saisie de demande et d'échange de données informatisé. Les services composites sont souvent utilisés lorsque l'organisation habituelle des fonctions de services identifie des fonctions communes pouvant être fournies dans plus d'une situation. Pour certains services dont le rôle consiste à fournir des fonctions de l'infrastructure (comme le service d'échange de données informatisé ci-dessous), cela est relativement simple à identifier. Dans les autres cas, des collaborations de services détaillées identifieront le besoin de diviser un service candidat plusieurs services réels.

Diagramme décrit dans le contenu textuel.

Les services composites servent aussi à rassembler les fonctions réalisées dans les éléments existants. Dans la plupart des cas, on accédera à ces fonctions par des connecteurs ou des interfaces de programmation fournis par l'élément lui-même et un nouveau service sera développé, dépendant donc de ces éléments. Cependant, pour permettre à un composant d'évoluer de manière plus souple et à l'élément existant d'être déplacé lors d'une implémentation différente, une autre stratégie peut être utilisée : chaque fonction existante est présentée comme un service indépendant ; ces services indépendants sont ensuite utilisés par le service composite, ce qui permet une évolution indépendante de l'élément existant et des services composites.

On peut aussi utiliser les services composites lorsqu'on ne sait pas à l'avance quelle partie des services réels sera optimisée par un service composite. Par exemple, dans un service de gestion des commandes, il peut être nécessaire de séparer la validation des commandes comme étant un ensemble à part de services de règles métier indépendants, de façon à ce que de nouvelles règles puissent être ajoutées par la suite. Pour plus de renseignements sur ce sujet, consultez les Instructions : Médiation de services.

Naturellement, cette approche a des avantages, mais aussi des inconvénients. Si les services de niveau inférieur ne peuvent être exposés que par le biais de protocoles IP comme SOAP ou HTTP, il est probable qu'ils soient moins fiables et que leurs performances soient moins bonnes que si on pouvait y accéder par une interface de programme d'application native ou par un connecteur. Ces compromis doivent faire partie de l'ensemble des décisions architecturales prises et documentées dans le cadre de la conception du service.

Pour plus d'informations sur l'accès aux ressources existantes et sur la relation entre les services potentiels et réels, consultez l'Activité : Analyse des actifs existants.

Collaborations de services

Lors de la modélisation du comportement des services composites, nous utilisons la notion d'Artefact : Contrat de service pendant les phases d'identification et de conception.

  • Lors de l' Activité : Analyse des actifs existants, nous utilisons la collaboration comme un outil pour décrire les rôles et les responsabilités des services potentiels. Par exemple, nous pouvons identifier la nécessité de distinguer les services de validation de commande et de gestion des commandes ; mais comment communiquent-ils et de quelles informations sont-ils responsables ? Une collaboration de services est utilisée comme un outil pour décrire cette communication et nous pouvons identifier les échanges de messages nécessaires à partir du modèle obtenu.
  • Pendant la Tâche : Spécification de service, nous utilisons la collaboration pour décrire le comportement concret d'un service donné ou d'une opération sur un service. L'exemple de la validation de commande pourrait être décrit de manière concrète comme un ensemble de messages envoyés à un ensemble de services de règle de validation.

De cette manière, il est possible de voir qu'une collaboration de services dans la tâche de conception de service est directement liée à la notion de chorégraphie en termes de services Web. Cela représente une description du flux externalisé et configurable organisant un ensemble d'échanges de messages entre les services. Dans la plupart des chorégraphies d'implémentation middleware, le flux est décrit dans un langage de type XML comme le langage BPEL. Ce type de langage peut être généré grâce à la collaboration de services décrite dans l'Artefact : Modèle de services lorsque le flux lui-même est décrit avec des activités ou des interactions UML 2.0.

La collaboration a une structure composite indiquant la vue des collaborateurs et de leurs connexions, ainsi qu'un comportement précisant les messages échangés et leur organisation. Le diagramme ci-dessus indiquant un fournisseur composite a lui aussi une structure composite, tout comme le schéma de validation de commande ci-dessous.

Diagramme décrit dans le contenu textuel.

Il ne s'agit pas de la structure du fournisseur de la validation lui-même, mais de la structure de la collaboration de services, comme l'indique le diagramme ci-dessous.

Diagramme décrit dans le contenu textuel.

Spécification du comportement du service

Comme nous l'avons déjà vu, les activités ou les interactions UML 2.0, et plus particulièrement les diagrammes de séquence, sont souvent utilisés pour décrire le flux des messages entre différents services collaborant. Le diagramme ci-dessous est un diagramme d'activité UML 2.0 indiquant le comportement du service de validation de commande. Pour une commande spécifique, le service qui enregistre la validation donne une liste des opérations de validation à consulter.

Diagramme décrit dans le contenu textuel.

Ce type de comportement peut être identifié pour un service entier ou pour une opération spécifique selon les besoins du service. Dans ce cas, l'activité au sein de la collaboration est liée à l'opération Validate () (via la spécification/l'association de méthode dans UML 2.0).

Spécification des associations de service

Comme nous l'avons déjà vu, les associations (à savoir les protocoles physiques réels et les codifications de messages) utilisées pour communiquer entre les services sont identifiées comme appartenant à l'Artefact : Canal de service dans la vue de composition. Les associations effectives utilisées entre les services ont un réel impact sur les exigences non fonctionnelles comme la performance, la fiabilité et la sécurité. Les choix disponibles doivent donc être documentés avec les conséquences de chaque exigence identifiée dans l'architecture générale du système. Par exemple, il est possible que l'une des utilisations de l'Artefact : Partition de service soit de représenter les associations autorisées ou nécessaires entre les services à l'intérieur de la partition, une exigence commune étant que les services situés dans des zones logiques communiquent en utilisant des performances de niveau supérieur mais des associations qui leur sont propres, tandis que les communications avec les services se trouvant en dehors de la zone utilisent des performances inférieures mais des associations standardisées.

Les gens se demandent souvent si les capacités requises pour assurer les performances, la fiabilité et l'évolutivité des services Web peuvent être fournies par une architecture HTTP ou SOAP, qui sont des protocoles à la fois lents et peu fiables. Il convient tout d'abord de définir la double notion de "lents et peu fiables" et de réaliser que même des vecteurs fiables reposent finalement sur des moyens peu fiables. Par exemple, lorsqu'on utilise SOAP sur HTTP, il est toujours possible de construire des protocoles et des interactions au niveau de l'application, qui offrent des fonctions supplémentaires pour les accusés de réception de messages et la sécurité. Néanmoins, si nous considérons que certains services communiquent dans le même contexte de sécurité ou d'application, nous pouvons envisager d'utiliser un autre vecteur que HTTP.

Il est très important de réaliser que, même si les services Web présentent un modèle simple et un ensemble de protocoles simples et flexibles, vous n'êtes pas limités à ces choix. Tout comme WSDL a déjà des associations à la fois pour GET/PUT SOAP et HTTP, il est essentiel d'offrir aux demandeurs des choix supplémentaires. Par exemple, un service spécifique peut exposer un message en utilisant une association avec une file d'attente de messages et une association avec SOAP, de façon à ce que le demandeur puisse choisir l'association la plus appropriée. Dans ce cas, le fournisseur peut aussi mettre en place des mesures incitatives, comme un niveau de service garanti si la file d'attente de messages est utilisée, mais pas de garantie de service pour une conversation HTTP.

Grâce à l'exemple de validation de commande développé plus haut, on peut voir la façon dont les associations sont liées au stéréotype Artefact : Canal de service et représentées sur le diagramme ci-dessous.

Diagramme décrit dans le contenu textuel.

Lors de la conception et du développement de solutions à l'échelle de l'entreprise, il faut toujours garder à l'esprit les exigences fonctionnelles et non fonctionnelles et s'assurer que les bons compromis sont faits et que les bonnes décisions sont prises pour atteindre les objectifs de l'entreprise.