La mise en place d’une solution Middleware (telle qu’un MOM, « Message Oriented Middleware » et un ESB, « Enterprise Service Bus ») permet principalement d’assurer le découplage des applications et progiciels du SI. Ces solutions sont alors responsables de l’acheminement des données et offrent les avantages suivants:

• Une application n’a pas besoin de connaître l’emplacement des autres (nom d’hôte, port, composition cluster, etc.) et a uniquement besoin de connaître l’emplacement de la brique Middleware (emplacement du MOM hébergeant les files de message).
• Une application n’a pas besoin d’utiliser les formats de données ou protocoles de communication des autres (généralement spécifiques et propriétaires) et a uniquement besoin de connaître les formats de données pivots ou protocoles d’échanges standards (JMS, web services, etc.).
• Une application ne dépend pas forcément de la disponibilité des autres mais uniquement de celle de la brique Middleware disponibilité du MOM hébergeant les files de message).

L’introduction d’une couche supplémentaire apporte toutefois des risques: un bus de service ne doit par exemple pas perdre de messages ou encore les dédoubler en essayant de les diffuser dans le SI. C’est dans ce sens que cet article montre comment utiliser Oracle Service Bus (OSB) et Java Transaction API (JTA) pour garantir un routage fiable des messages entre applications.

Transactions globales (XA)

Cette problématique relative à la fiabilité des échanges peut facilement être adressée avec l’utilisation de transactions XA. Ces transactions:

• Sont des transactions globales regroupant chacune plusieurs ressources (ex: lecture d’une première ressource et écriture d’une seconde ressource).
• Nécessitent un coordinateur de transactions (ex: serveur d’applications J2EE).
• Nécessitent que les ressources supportent les transactions globales (accès base de données via driver JDBC XA, accès file de messages JMS via fabrique de connexions XA, utilisation connecteur JCA, etc.).

Ainsi, l’utilisation de transactions globales entre des files JMS (par exemple) en entrée et en sortie de votre bus de service procure les avantages suivants:

• Le message dans la file JMS en entrée du bus n’est pas dépilé en cas d’erreur lors de la transformation de celui-ci ou de l’écriture en sortie. Ainsi, le message en entrée ne sera dépilé qu’en cas de succès et la non perte des messages est alors garantie.
• Dans le cadre d’une écriture multiple en sortie (1 message en entrée pour N messages en sortie) si une erreur se produit alors aucun message ne sera réellement envoyé (la transaction étant annulée). Ainsi, les écritures en sortie seront toutes réalisées en même temps (ou pas du tout) et le non dédoublonnage des messages est garanti.

Attention, l’utilisation de transactions globales peut avoir un fort impact négatif sur les performances d’une application (en fonction de la volumétrie manipulée par celle-ci). Elles ne doivent donc être utilisées que si nécessaires et pour des traitements de durée courte et maîtrisée:

• Les transactions globales ne sont pas toujours adéquates pour des traitements à connotation fonctionnelle (durée généralement variable et relative aux actions d’un utilisateur).
• Les transactions globales se prêtent bien aux traitements purement techniques et relativement courts (comme le routage d’un bus de service: read > transform > write).

Transactions globales dans OSB:

• Les transactions XA sont supportées dans OSB via l’implémentation JTA du serveur Weblogic sous jacent et la mise à disposition de driver JDBC XA ou de fabrique de connexion JMS XA dans celui-ci.
• La gestion des transactions dans l’OSB est implicite:
  • Une transaction est automatiquement ouverte à l’arrivée d’un message dans un proxy service avec transport JMS, Local ou JDBC.
  • La transaction est maintenue tant que le message est routé dans un proxy service avec transport Local ou un business service JMS/JDBC.
  • La transaction est validée (commit) à la fin du traitement OSB si aucune erreur n’a été rencontrée.
  • La transaction est annulée (rollback) en cas d’erreur du traitement OSB.

Voici enfin les conditions à respecter pour pouvoir utiliser des transactions globales dans OSB:

• Lecture d’un message via un proxy service JMS (avec fabrique de connexion XA) ou JDBC (driver de connexion XA) avec l’option « Is XA Required » activée
• Routage des messages (publish, service callout ou route) avec qualité de service fixée à « Exactly Once ». La qualité de service est à précisée au travers d’une action « Routing Options »
• Routage des messages vers des proxy services avec transport Local ou des business services JMS (avec fabrique de connexion XA) ou JDBC (driver de connexion XA)

Conclusion

En conclusion, l’utilisation de transactions globales dans OSB est relativement simple et garantie un routage fiable des messages entre applications. A noter que depuis la version 11.1.1.7 d’OSB l’utilisation de transactions XA avec MQ a été rendue possible au travers d’un nouveau type de ressource « MQ Connection ».