Architecture soa (architecture orientée services)

2.5.3.6 Les Faiblesses (Vue approfondie)

L'objectif de ce chapitre est d'approfondir par le biais d'une modélisation adaptée, les noeuds qui concentrent certaines difficultés.

Intégrité des messages non respectée

Illustration 94 : Diagramme de séquence de l'activité d' « Attente de fin de transfert »

L'agent superviseur (Open Process) joue le rôle d'intermédiaire entre le fournisseur (émetteur) et le consommateur (récepteur) de fichier tiers. Le fichier est transmis de l'émetteur au superviseur (1^er flux), puis du superviseur au récepteur (2^nd flux) qui consommera le fichier. Un problème de synchronisation entre la fin du premier flux et le début du second peut parfois se produire. La raison est liée au fait que certains débits de réseaux de sites éloignés soient tels que les Taille1 et Taille2 restent identiques alors que le transfert (c'est-à-dire le premier flux) n'est pas terminé. Le fichier entrant qui est toujours en cours de transfert est alors aussitôt contrôlé et transféré au consommateur qui ne saura jamais qu'il ne dispose pas de l'intégralité des enregistrements.

Les ESB assurent la garantie d'acheminement des messages grâce au WS-ReliableMessaging (spécification OASIS). Ce dernier intègre dans les messages Soap les mécanismes classiques d'accusés de réception et permet de ré émettre le message en cas d'incident. Il est alors certain qu'un message Soap transporté sur HTTP est bien arrivé à destination. Dans le cas contraire, il est possible de le réémettre jusqu'à ce que la réception ait été correctement réalisée. La spécification WS-ReliableMessaging est en concurrence avec WS-Reliability (spécification SUN). IBM, dans son outil Websphere, propose le connecteur HTTP-R, qui décrit les mécanismes équivalents, directement au niveau HTTP.

Identification des messages compliquée et rigide

Illustration 95 : Diagramme de séquence de l'activité « Contrôle du contenant »

Cet algorithme rigide aurait pu être évité si l'on avait utilisé d'autres techniques d'identification. Le Hash-coding^145(*) fait partie de ces solutions.

Dans un ESB, l'identification des messages peut être réalisée sur la base des spécifications du WS-Addressing. SOAP qui intègre dans sa partie entête (header) un ID, une adresse pour l'accusé de réception et un destinataire du message.

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">

<S:Header>

Id Message

<wsa:MessageID>

uuid:6B29FC40-CA47-1067-B31D-00DD010662DA

</wsa:MessageID>

Destinataire de la réponse

<wsa:ReplyTo>

<wsa:Address>http://business456.example/client1</wsa:Address>

Destinataire du message

</wsa:ReplyTo>

<wsa:To> http://fabrikam123.example/Purchasing </wsa:To>

<wsa:Action>http://fabrikam123.example/SubmitPO</wsa:Action>

</S:Header>

Illustration 96 : Entête d'un Message SOAP

* ¹⁴⁵ Hash-coding : Technique logicielle permettant d'attribuer un emplacement de mémoire grâce à un calcul faisant intervenir directement l'Information à ranger ou à retrouver.