Tâche: Conception de messages |
|
 |
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. |
Disciplines: Analyse et conception |
|
Relations
Rôles | Exécutant principal:
| Exécutant supplémentaires:
|
Entrées | Obligatoire:
| Facultatif:
|
Sorties |
|
Utilisation des processus |
|
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 :
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.
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.
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.
|
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.
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.
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.
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.
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.
|
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.
|
|
Plus d'informations
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|