Tâche: Indiquer les messages de service
Cette tâche décrit les actions requises pour développer un modèle de conception de messages global (catalogue). Elle revient, en arrière-plan, sur les patterns d'échange de messages et sur la relation entre le modèle de domaine et le modèle de message. Des considérations liées à la conception sur la granularité et les performances des messages sont également présentées.
Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif: Externe:
  • Aucun
Sorties
Description principale
Les messages entre les services et les composants de communication constituent une partie essentielle d'une architecture SOA. Ces messages incluent non seulement les messages d'entrée et de sortie d'un appel de service donné mais également le format de message interne à utiliser dans l'entreprise lorsque le flux d'informations circule entre les couches de l'architecture de l'application.  Dans de nombreux cas, un format de message commun est recommandé.

Etant donné que les services incluent des messages d'entrée et de sortie, cette tâche met l'accent sur :

  • l'identification et la spécification du format et le contenu des messages d'entrée et de sortie d'un service,
  • sa relation aux modèles de données sous-jacents,
  • le format de message commun interne et les considérations, et
  • les décisions sur la méthode de mappage de ces messages entre eux.

La spécification de messages pour le modèle de services doit tenir compte des perspectives de l'architecture de l'entreprise/l'architecture de l'application, de l'architecture des données et de l'architecture de l'intégration. Cela inclut :

  • les normes de message définies au niveau de l'entreprise et de l'application
  • les métadonnées ou le modèle de données appropriés faisant partie d'une architecture de données
  • les normes de transformation de message faisant partie d'une architecture d'intégration.

Pendant la spécification, il est important de comprendre les normes d'une organisation, si elles sont disponibles, dans chacun des trois domaines de l'architecture. Les spécifications de message et les modèles de données sont étroitement liés. Le modèle de données est constitué d'entités sous-jacentes et de leurs relations dont un sous-ensemble peut être envoyé dans le cadre d'un message de sortie et reçu en tant qu'entrée dans un message entrant. Ainsi le mappage entre les formats de message et le modèle de données ou l'architecture de donnés sous-jacent sont une considération architecturale clé. Dans certains cas, les patterns et leur implémentation tel que le bus de service d'entreprise peuvent gérer la transformation (et l'acheminement) des messages. Dans de nombreux cas, un gestionnaire explicite peut être nécessaire pour transformer les messages à partir des modèles de données ou en modèles de données.

Dans la plupart des langages de programmation orientée objet, l'appel d'un comportement est basé soit sur les appels de méthode, soit sur les paradigmes de passage de messages. C++, par exemple, utilise des tableaux de pointeurs de fonction pour appeler la méthode appropriée. Inversement, Smalltalk passe des messages dont le récepteur est évalué au moment de l'exécution. Les solutions orientées services sont toujours basées sur les messages, et si les associations avec les langages de programmation peuvent présenter des interfaces à base de méthodes pour les clients, ce n'est pas le cas pour la communication avec ou entre les services. Un autre aspect des messageries de services est que de plus en plus de services sont développés avec des interfaces asynchrones, contrairement à la nature fondamentalement synchrone des appels de méthode.

Dans le domaine de l'intégration d'entreprise, un type de technologie a été utilisée avec succès pendant de nombreuses années : le middleware orienté message (ou MOM). Cet ensemble de technologies est très présent dans des produits comme les gestionnaires de files d'attente et les courtiers de messages. Il a permis aux organisations IT de bénéficier d'une méthode souple, évolutive et robuste pour les connexions des applications.

Il convient de souligner que l'architecture orientée services est une évolution du développement à base de composants. Sur certains aspects, cette solution prend en compte beaucoup des leçons apprises grâce au succès du MOM, par exemple sur la façon de coupler les systèmes de manière souple et efficace. Pour permettre aux systèmes d'évoluer de manière indépendante, l'infrastructure MOM a les caractéristiques suivantes :

  • Une file d'attente de messages, qui permet d'acheminer les messages de manière fiable, même en cas d'incidents sur le réseau ou dans le système.
  • L'acheminement des messages, aussi bien en termes d'acheminement sur le réseau au niveau de la fiabilité et des performances que d'acheminement avancé basé sur le contenu du message.
  • La transformation de messages, qui permet à un service d'appel de demander une requête pour un "produit" lorsque le service récepteur peut accepter les requêtes d'"éléments".
  • Des adaptateurs de messages, qui permettent aux systèmes n'ayant pas, à l'origine, été développés avec des interfaces MOM, d'être traités par des services MOM.
Etapes
Utiliser les normes de message
Lors de la définition de spécifications de messages pour des services identifiés, il est important de tenir compte des normes de messages d'une entreprise, lorsqu'elles existent. Lorsque les normes de message ne sont pas définies, il est conseillé d'en développer. Lorsque des schémas de message du secteur d'activité existent, il est recommandé de les exploiter.  Par exemple, des spécifications de messages XML ont été définies pour les secteurs d'activité de la finance, du gouvernement, des voyages (OTA XML [Open Travel Alliance, http://www.opentravel.org/online_schema.cfm]) et des communications.  En outre, des schémas plus généraux sont disponibles sur le site d'OAGIS [Open Applications Group, http://www.openapplications.org/index.htm].

Format de message commun

Les messages communs désignent des messages transférés sur les niveaux d'une architecture à n niveaux.  Généralement, les informations d'interface utilisateur sont capturées, envoyés via un niveau de contrôleur, traitées dans les couches métier ou application, puis transmises à une couche de persistance ou à un système dorsal existant.  Durant chacun de ces transferts, un message est échangé entre les niveaux qui peuvent chacun avoir un format différent.  La clé est de se conformer à une norme pour un format de message commun au sein de l'entreprise de manière à surmonter les temps système de conversion de format, lorsqu'un bus de service d'entreprise n'est pas utilisé ou lorsque son utilisation est considérée comme coûteuse en termes de conversion de format.  L'utilisation d'un bus de service d'entreprise permet de prendre en charge la plupart de ces médiations, transformations et acheminements.  Il s'agit de la couche intégration telle qu'elle est décrite dans le modèle d'organisation en couches SOA.

Dans certains cas, il suffit de déterminer des formats de messages sortant et entrant.  Le problème d'un format de message commun est une décision architecturale clé : vous pouvez choisir de créer votre propre format comme indiqué ici, d'adopter des modèles de secteur d'activité tels que le format OTA XML du secteur des voyages ou d'adopter des modèles plus généraux tels que ceux définis par OAGIS.  Dans certains cas, la décision portera sur l'utilisation d'un format de message d'entreprise commun qui met à jour les zones dans le message et transmet ce dernier au niveau suivant pour traitement.  Si un schéma commun n'est pas réalisable en raison de facteurs politiques, des adaptateurs convertissant les messages en un format de message commun interne peuvent être développés.  Ils peuvent également être optimisés dans le cadre d'un bus de service d'entreprise.

Considérations liées aux ISV : Des attributs de données peuvent être ajoutés aux messages qui appellent des services réalisés dans des packages ISV afin de répondre aux contraintes du modèle de données du package ISV.  Des données élémentaires de ce type peuvent être identifiées par l'analyse du service réalisé dans le composant du package ISV ou peuvent également être identifiées via l'analyse de service ascendante du package ISV.  Etant donné que ces attributs peuvent ne pas être identifiés jusqu'à la réalisation des services, il peut être nécessaire de les replacer dans le message commun une fois qu'ils sont identifiés.

Format de message commun et architecture de données

En général, les services ne doivent rien indiquer sur les modèles de données sous-jacents.  Ils doivent être utilisés pour encapsuler les modèles de données sous-jacents dont les magasins de données sont exploités par les composants de service qui réalisent les services.  Ainsi, les services qui sont des opérations d'affichage, d'édition, de suppression, d'ajout, de recherche et autres, sur une base de données peuvent ne pas être de bons candidats de services mais peuvent être utilisés en tant qu'opérations de composant sous-jacentes comme ils sont utilisés aujourd'hui.

Les architectures de données existantes qui définissent des modèles de données conceptuels, logiques ou physiques sont des sources obligatoires dans la définition de formats de message communs.  Les définitions de formats de message communs doivent être coordonnées avec les efforts d'architecture de données et les modèles de données.  Cette analyse assure la disponibilité des magasins et des schémas de données appropriés pour les composants de service qui vont réaliser de nouveaux services.  L'architecture de données existante sera optimisée pour être adaptée aux nouveaux services si de nouvelles données doivent être ajoutées aux systèmes sous-jacents.

Dans de nombreuses entreprises, les systèmes existants reflètent souvent l'existence de silos et d'îles de données qui collobarent via des traitements par lots.  La migration depuis des magasins de données isolés est possible via les services.  L'identification des sources de données d'un fournisseur de services est effectuée pendant la réalisation des services.

Considérations liées aux ISV : Le modèle de données logique doit s'adapter aux modèles de données prédéfinis, souvent implicites, intégrés aux packages ISV.  Ainsi le transfert de messages entre les applications intégrées et les modèles de données existants doit avoir lieu.  Il est souvent effectué via des API offertes par les ISV. Dans une architecture SOA, les adaptateurs vers ces modèles de données ISV deviennent importants, notamment si l'ISV n'expose pas ses données sous-jacentes et ses fonctionnalités via des services.

Notez que dans certains cas où le modèle de données ISV est accessible, il est possible de personnaliser le modèle afin de l'adapter aux messages requis pour prendre en charge les services identifiés.  Inversement, si le modèle de données n'est pas accessible, la messagerie de service peut être limitée par le modèle de données contenu dans l'ISV.  Un mécanisme de médiation peut également être utilisé pour limiter ce problème.  La médiation comme celle fournie par un bus de service d'entreprise peut être utilisée dans ce contexte pour prendre en charge l'interfaçage avec les packages ISV.  Le modèle de données ISV peut également imposer des attributs supplémentaires qui sont obligatoire, outre ceux requis pour implémenter le service.

Format de message commun avec tous les services pertinents

Les formats de message communs doivent être synchronisés avec les messages entrants/sortants de chaque service, ils sont donc associés et affectés afin de permettre aux services appropriés de les utiliser et de les mettre à jour de manière appropriée.  Il est possible que les services doivent extraire des informations ou attendre un résultat du format de message d'entreprise commun.  Ils sont documentés dans le canevas de format de message commun du service.
Réutilisation du modèle de domaine

Dans le Concept : Conception de domaine, la notion de modélisation de domaine a été définie, identique à la notion de modèle d'analyse ou de modèle d'analyse métier pour la représentation des concepts clés du domaine de l'entreprise, indépendamment de la technologie. Il est évident que les messages utilisés par les services sont sensibles à la technologie (s'ils ne sont pas spécifiques à la technologie comme le schéma XML utilisé pour les services Web), de la même façon que le schéma de base de données utilisé pour conserver les données est spécifique à la technologie dans le service. En fait, on peut envisager les relations suivantes :

Diagramme décrit dans le contenu textuel.

Ce diagramme illustre la relation entre le modèle de domaine utilisé pour découvrir les éléments de domaine clés et le modèle des messages lorsque la réalisation du modèle de domaine en tant qu'ensemble d'éléments passe dans les services et en revient.

Diagramme décrit dans le contenu textuel.

Le diagramme suivant est un modèle Java/composant classique dans lequel on peut voir la séparation de l'interface et de la classe, ainsi que l'ajout des fonctions d'"accès" pour obtenir et définir la valeur des variables d'état. Il s'agit d'une approche très courante, mais elle présente pourtant un inconvénient : si le client et le composant se trouvent dans des espaces adresse différents ou sur des machines différentes, le coût lié à la communication de chaque appel est élevé en termes d'accès à l'intégralité de l'état d'un composant.

Diagramme décrit dans le contenu textuel.

Un autre problème est la relation entre les composants ; le fait qu'un compte ait un ensemble de clients est difficile à développer dans ce style et se termine généralement par la gestion de listes d'identifiants utilisés pour supprimer des objets individuels.

Pour développer un modèle de services , on peut utiliser l'identification des services conditionnée par les données entraînant la spécification d'un service de gestion des comptes et d'un service de gestion des réunions. La première spécification de service est l'emplacement central de la gestion des comptes et des contacts. En fait, le modèle de données principal pour les solutions de gestion de la relation client a été élaboré notamment à l'aide de ce service. Le deuxième service a été séparé parce qu'il peut être utilisé par les solutions de gestion de la relation client et par d'autres solutions pour prévoir des réunions et il interfacera avec les applications de logiciel de groupe de travail de l'entreprise.

Le diagramme suivant est un échantillon tiré du modèle, il indique les spécifications du service. Les messages peuvent être tirés du modèle de domaine ci-dessus.

Diagramme décrit dans le contenu textuel.

Comprendre les patterns d'échange de messages

Il arrive souvent que les messages soient simplement considérés comme les paramètres des opérations. Cela est notamment dû au fait que la représentation UML des services utilise des opérations avec des paramètres et que le WSDL 1.1 (Web Services Description Language) utilise le même type d'approche. Cependant, concernant les services et les spécifications de service, il est plus pratique d'envisager les messages comme des éléments réutilisables étant soit produits, soit utilisés/consommés par une opération de service. Pour les services, l'opération n'est qu'un échange de message, ou plutôt un échange nommé sur un service que l'on peut distinguer des autres échanges qui pourraient utiliser le même message d'entrée ou de sortie.

La notion de pattern d'échange de messages a longtemps été étudiée dans le monde des services Web, dans le cadre de l'analyse de l'utilisation des services pour le développement des standards prenant en charge leur spécification. Un pattern d'échange de messages nomme une combinaison spécifique de messages produits, utilisés ou consommés entre deux services (ou entre un service et un client) et fournit un vocabulaire commun aux concepteurs du service pour décrire les opérations sur les spécifications de service.

Les patterns d'échange énumérés ci-dessous peuvent être utilisés pour la définition des spécifications de service. Ces patterns sont généralement définis lors de la modélisation des collaborations de services.

Requête/Réponse synchrones : il s'agit d'un appel de méthode traditionnel par lequel le client du service envoie un message à un service, puis attend qu'une réponse soit envoyée par le service.

Diagramme décrit dans le contenu textuel.

Message à sens unique : dans ce cas, le client envoie simplement un message au service, sans attendre de réponse spécifique. Ce pattern peut être considéré comme un appel de méthode asynchrone sans type de réponse, ce qui signifie que le client du service poursuit l'exécution une fois le message envoyé, plutôt que d'attendre que le service ait traité le message.

Diagramme décrit dans le contenu textuel.

Remarque : dans ce cas, le service est responsable de l'envoi d'un message de notification au client (en général, c'est un autre service qui gère cela). Pour ce faire, le client doit s'être enregistré auprès du service, de façon à ce que le service sache où envoyer le message de notification.

Diagramme décrit dans le contenu textuel.

Requêtes/réponses asynchrones : ce pattern est une combinaison du message à sens unique et de la notification. Le client du service envoie un message incluant une adresse à laquelle répondre. Lorsque le service a terminé son traitement, il rappelle l'émetteur. Le fait que les clients du service envoient le premier message de manière asynchrone les oblige à garder une trace de toutes les requêtes envoyées de façon à ce que les réponses, une fois reçues de la part des services, puissent être associées à la requête appropriée.

Diagramme décrit dans le contenu textuel.

Souscrire/publier : il s'agit de nouveau d'une combinaison. Un client du service manifeste son intérêt pour un "sujet" avec un service de publication. Les autres services ou clients du service publient des messages (envoient des messages) au service de publication qui identifient le sujet associé au message. Si le sujet correspond à un sujet précédemment notifié par un client, ce dernier est informé de l'existence du nouveau message. Dans ce cas, il est possible de coupler de façon très souple les services participants. Les clients ou les diffuseurs n'ont qu'à connaître l'emplacement du service de publication et de nouveaux clients peuvent être ajoutés à la solution sans demander d'importants efforts.

Diagramme décrit dans le contenu textuel.

Gérer la granularité des messages

Les services sont conçus pour fournir des opérations à haute granularité. Les messages qui entrent et sortent des opérations ont donc aussi tendance à avoir une granularité élevée. Ce problème a été souligné au début du déploiement des solutions de service Web lorsque l'utilisation de HTTP comme protocole de transfert, de SOAP comme protocole et de XML comme format WF entraînait des réponses lentes et des exigences de bande passante élevées. Prenons par exemple une requête de cotation en bourse émanant d'un service. Une cotation en bourse simple était souvent prise en exemple dans les premiers de l'existence des services Web. L'action est symbolisée par quatre caractères et la réponse est un chiffre décimal. Avec un appel de procédure à distance et un protocole binaire, on peut s'attendre à ce que l'identificateur de message ajoute du temps système, environ 8 octets, et on peut donc s'attendre à environ 8+4 pour la requête et 8+8 (pour une grande précision décimale) en réponse. Avec HTTP/SOAP, cela aurait eu à peu près cette forme :

Requête Réponse
  ActionSOAP : "http://www.webservicex.net/Quote"
Agent d'utilisateur : MyAgent 1.0
Type de contenu : text/xml; charset=UTF-8
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:tns="http://www.webservicex.net/">
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<tns:Quote>
<tns:Symbol>IBM</tns:Symbol>
</tns:Quote>
</soap:Body>
</soap:Envelope>
  HTTP/1.1 200 OK
Optimisé par : ASP.NET
Connexion : fermé
Longueur du contenu : 522
X-Version-AspNet : 1.1.4322
Date : Lundi, 21 Mars 2005 00:34:21 GMT
Type de contenu : text/xml; charset=utf-8
Serveur : Microsoft-IIS/6.0Cache-Control: private, max-age=0
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<QuoteResponse xmlns="http://www.webservicex.net/">
<Quote><Last>89.28</Last>
</Quote>
</QuoteResponse>
</soap:Body>
</soap:Envelope>

Les premiers utilisateurs des services Web sont arrivés à deux conclusions. Tout d'abord, les services étaient optimisés pour un petit nombre d'opérations fournissant des données sous forme de documents plutôt que comme des modèles de composant traditionnels plus complexes. Cela avait l'avantage de limiter le temps système des protocoles au sein d'une charge de données plus importante. Cela permettait également de choisir des associations de protocoles plus petites et plus simples entre les services d'une entreprise, ou du moins entre les services d'une même solution, et HTTP/SOAP étaient réservés aux situations où ils étaient indispensables, par exemple lors de l'interfaçage avec des services en dehors de l'entreprise.

Cette notion n'est pas nouvelle. Même dans le monde des composants, le pattern Objet valeur ou la façade de service J2EE sont des approches permettant de réduire le nombre de communications aller-retour entre le client et le serveur. Ces deux approches envoient une copie complète de l'état du composant au client au lieu d'utiliser les fonctions d'accès habituelles. Il faut également prendre en compte le fait qu'on développe des services plus étroitement liés aux modèles métier, particulièrement les modèles de processus métier. Les messages reflètent donc les documents métier habituels de la même façon que les ensembles de transactions EDI (échange de données informatisé) représentent les documents métier comme les commandes, les factures, les avis de livraison, etc.

Gérer les performances d'échange des messages

En général, les messages volumineux améliorent les performances des communications, même s'il arrive que les messages comportant un grand nombre de données soient problématiques. Par exemple, dans le message SOAP ci-dessus, on a pu voir que la taille du message, avec HTTP, SOAP et XML augmentait de manière importante la taille des données. C'est un des problèmes posés par les premiers systèmes construits à l'aide des technologies de services Web. Ces problèmes nous ont cependant permis d'apprendre des choses intéressantes, notamment que la prise en compte des performances en termes de performance de code, de conception de messages et de choix de protocoles doit constituer l'une des premières activités de conception.

Un aspect important à prendre en compte est que, étant donné que l'on déplace de grandes quantités d'état depuis le service jusqu'à l'utilisateur ou jusqu'au service, ces messages représentent en fait un instantané de l'état du service. Il faut donc gérer le fait que cet instantané soit "daté" en identifiant le moment auquel les données peuvent être considérées comme fiables ou bien le "prêter" au client ;dans ce cas, il expirera après un certain temps. Pour plus d'informations, consultez le livre blanc Utilisation de l'architecture SOA et du développement à base de composants pour construire des applications de service Web.

Il faut aussi penser à la mise en cache du contenu. La mise en cache est généralement traitée comme l'optimisation des performances pour les applications mais, dans une solution orientée services, la communication étant de nature répartie et basée sur les messages, elle se prête à l'insertion de caches entre les clients et les services. Ces caches ne sont pas des caches de base de données typiques utilisés pour optimiser les requêtes ; ils s'apparentent plus à des caches utilisés dans les serveurs Web et les proxys Web. En fait, lorsque des services Web utilisent HTTP et SOAP, ces proxys peuvent servir de caches pour séparer les réponses des services dans certaines situations.

Cependant, concernant l'utilisation des caches, la question est de savoir comment ils comprennent les règles utilisées pour prendre en charge le contenu du cache, ainsi que la façon dont un service peut l'invalider. L'infrastructure technique utilisée pour héberger et gérer les services déployés doit avoir des fonctions de mise en cache. Nous reviendrons ultérieurement sur un autre secteur des règles des services, à savoir l'approvisionnement en informations relatives à la gestion des caches.

Propriétés
Prédécesseur
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Plus d'informations