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.
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.
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.
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 ?
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.
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.
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.
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.
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.
|