Instructions: Médiation de services
Ces instructions décrivent la façon dont la communication entre consommateurs et services incompatibles est rendue possible par le biais de la médiation, en transformant les requêtes des consommateurs ou les protocoles de manière à ce que les fournisseurs les comprennent.
Relations
Description principale

Introduction

La médiation correspond au fait d'intervenir entre des parties en conflit afin d'obtenir une conciliation ou un compromis. Trois formes de conciliation sont nécessaires pour les systèmes répartis en général, et plus spécifiquement pour les solutions orientées services.

  • La médiation d'interface : dans l'interface des systèmes à base de composants ou d'objet, la médiation correspond à l'échange de définitions d'opérations entre l'expéditeur et le récepteur. Dans une solution orientée services, cela est considérée comme une disparité entre le contenu et le schéma du message de l'expéditeur et du récepteur.
  • La médiation de protocole : les solutions à base de composants ou d'objets les plus courantes sont généralement basées sur un protocole ou un ensemble de protocoles communs pour la communication. Dans les solutions orientées services, il y a souvent un mélange de protocoles au sein de l'intégralité de la solution, c'est l'un des avantages de cette architecture. Pour communiquer entre des services, les messages devront couvrir plusieurs protocoles entre l'expéditeur et le récepteur.
  • La médiation d'opération : cette forme de médiation peut sembler familière aux développeurs de logiciel. Elle est proche du pattern de stratégie. Un composant est capable de choisir entre l'ensemble d'implémentations d'un service spécifique et une opération basée sur les paramètres d'exécution ou le contenu d'une requête. On appelle aussi cela le routage à base de contenu.

Il est important de remarquer que de plus en plus de plateformes middleware fournissent des fonctions pour la médiation avancée sans avoir à développer des composants de médiation explicites. Dans ce cas, comme le middleware détecte les disparités dans la structure des données ou dans les protocoles de communication, il peut effectuer la médiation lors de son exécution. Ces plateformes peuvent également fournir des médiateurs qui fonctionnent comme des commutateurs basés sur le contenu du message et les règles métier pour choisir la bonne implémentation ou une requête de consommateur donnée.

Médiation de données dans les activités

Pour connecter des services pour lesquels la définition des messages est incompatible ou si les messages impliquent une transformation entre l'expéditeur et le récepteur, il est possible d'utiliser une fonction fournie par les activités UML 2.0 pour notifier la transformation entre l'expéditeur et le récepteur. Cette fonction, l'association d'un comportement UML 2.0 et d'un flux d'objet entre deux actions, permet l'identification d'un comportement de transformation réutilisable pouvant transformer un message en un autre message (en particulier dans la spécification UML 2.0 qui change ou remplace des données circulant à la périphérie).

Comme nous l'avons déjà évoqué, la transformation est un élément réutilisable. Elle peut être donc identifiée pour transformer un type de message en un autre type, puis être utilisée à chaque fois qu'il le faut pour procéder à la médiation de messages entre un service émetteur et un service récepteur. Bien que le langage UML fournisse un ensemble d'actions permettant de naviguer sur une structure ou bien de l'afficher et de la mettre à jour, ces actions sont assez complexes et leur utilisation peut s'avérer trop difficile dans le cadre de la définition des transformations. Les transformations sont censées donner une représentation plus compacte (comme le langage XSLT) ou une nouvelle façon d'exprimer les besoins des actions UML devant être satisfaits.

La médiation de données peut aussi être traitée comme un pattern concret d'itération de service. Par exemple, il existe un service de médiation explicite responsable de l'implémentation d'une ou de plusieurs transformations de données. Dans ce cas, le médiateur doit répondre aux messages envoyés par le consommateur, les transformer et les transmettre au service, comme l'illustre le diagramme ci-dessous.

Diagramme décrit dans le contenu textuel.

Médiation de protocole pour les passerelles de service

La médiation de protocole est bien comprise et prise en charge de manière explicite par le modèle. Les informations du protocole sont définies comme étant la liaison d'un canal de service, il est donc possible d'ajouter soit des <<services>> supplémentaires, soit des éléments de modèle <<passerelle de service>> qui changent la spécification du protocole. Par exemple, dans le diagramme de structure composite suivant, on peut voir deux partitions, une pour les services Web-facing et une pour les services internes. Il existe également un canal de service entre les partitions avec une liaison "HTTP-SOAP", ce qui est courant pour les services Web-facing.

Diagramme décrit dans le contenu textuel.

Le problème est que, pour prendre en charge le niveau requis de performances et les autres exigences non fonctionnelles, toutes les communications à l'intérieur de la partition interne ont lieu sur les protocoles spécifiques à la plateforme. Le diagramme suivant montre la façon dont un service est connecté à une passerelle de service "Port : ISvcTwo" grâce au protocole Java RMI ; mais comment se fait-il que la partition Web se connecte à la même passerelle en utilisant HTTP-SOAP ?

Diagramme décrit dans le contenu textuel.

Cela est dû au fait que la passerelle du service peut elle aussi adapter le protocole en changeant les structures et les appels des messages d'un format à l'autre. C'est une fonctionnalité courante généralement fournie par des objets middleware comme Object Request Brokers (ORB) ou Message Brokers. En fait, il est possible de générer ce type de middleware à partir du modèle ci-dessus si nécessaire ou de faire du "Port : ISvcTwo" un service à part entière recevant des appels de la partition Web et les renvoyant aux services appropriés.

Là encore, la médiation peut explicitement être modélisée comme un service, plutôt que comme la passerelle d'un service, exposant l'interface correcte avec la liaison côté client et déléguant l'implémentation au service fournisseur avec une association différente.

Médiation d'appel à l'aide de composition de services

Comme nous l'avons vu dans l'introduction, il est courant de définir une structure dans laquelle un service dépend d'un autre service pour certaines opérations. Toutefois, le service réel qui sera appelé pour une requête particulière dépend des détails contenus dans la requête, du requérant et des règles métier appliquées en utilisant ces informations. L'exemple couramment utilisé pour illustrer ce cas est une requête client, le service récepteur pouvant choisir l'une des deux implémentations selon le niveau du client. Par exemple, les clients qui font de grosses commandes peuvent bénéficier d'un traitement préférentiel.

Diagramme décrit dans le contenu textuel.

Comme nous l'avons vu plus tôt, il est important dans ce type de médiation d'essayer d'externaliser les règles utilisées pour choisir un ou plusieurs fournisseurs de l'implémentation d'opération réelle. Dans le diagramme ci-dessus, cela est illustré par un composant "règle" joint au service médiateur. On peut bien entendu construire une solution comme un ensemble de services où le médiateur, les règles et tous les implémenteurs sont des services distincts. Le diagramme ci-dessous illustre cette situation.

Diagramme décrit dans le contenu textuel.

Comme vous pouvez le voir, le composant de médiation possède la spécification des services réalisés, mais aussi une spécification des services nécessaires pour être implémenté par tous les services qu'il adapte. Cela permet de définir à la fois la structure composite du service (illustrée ci-dessus) et le comportement dynamique indiqué ci-dessous. Remarquez que, dans la structure ci-dessus, la partie représentant les services se distingue par son interface requise et est affichée avec une multiplicité illimitée.

Diagramme décrit dans le contenu textuel.

Encore une fois, il est possible que ce type de routage de messages à base de contenu ou de règles soit accompli par la plateforme middleware choisie comme faisant partie de l'architecture de la solution.