L’acronyme MOM (pour « Message Oriented Middleware ») désigne les solutions d’intégration à base de messages: Oracle AQ (Advanced Queueing), Websphere MQ (anciennement MQSeries), Active MQ (Apache), MSMQ (Microsoft), etc. Ces produits permettent principalement d’assurer les échanges asynchrones au sein du SI et de garantir un couplage faible entre applications.
Dans le cadre de nos projets SOA (généralement une refonte progressive ou partielle du SI), la mise en place d’un système de messaging est de plus en plus courante. En effet, ce type de produit adresse admirablement bien les problématiques inhérentes aux architectures distribuées et/ou hétérogènes. Choisir la bonne solution à mettre en place n’est jamais facile à la vue des nombreux produits présents sur le marché. Ce billet vise justement à introduire comment WebLogic Server peut-être utilisé en tant que MOM. Car bien que très répandu en entreprise, ce serveur d’applications n’est pas forcément connu ou utilisé dans ce rôle.
Pourquoi utiliser WebLogic Server en tant que MOM ? Voici plusieurs bonnes raisons de franchir le pas !

1) Compatibilité JMS :

WebLogic Server est complètement compatible avec le standard JMS 1.1. Il s’agit de l’API standard J2EE pour interagir avec un MOM en Java (permettant ainsi aux développeurs de s’affranchir de l’implémentation utilisée). JMS défini notamment des notions communes de Queue, Topic, Consumer et Producer. Ainsi, le portage d’un développement pour passer d’un autre MOM à WebLogic Server se résume souvent uniquement à une modification de configuration JNDI (adresse serveur, utilisateur et mot de passe). A noter que les outils de type ESB ou ETL reposent également sur ces API pour profiter du même niveau d’abstraction vis-à-vis du MOM utilisé. L’intégration d’un MOM WebLogic au sein de votre architecture J2EE se fait donc sans douleur.

2) Intégration WebLogic :

Les services JMS sont complètement intégrés à WebLogic Server. Ce serveur d’application peut ainsi être utilisé en tant que MOM sans aucune installation/licence supplémentaire. Ces fonctionnalités étant natives, vous n’êtes donc pas contraints d’introduire une nouvelle brique logicielle dans votre SI si vous possédez déjà développement Server. A noter que vous pourrez ainsi administrer et superviser vos ressources JMS via la console et les API WebLogic standards. Enfin, au même titre que les autres composants du serveur, les actions associées sont entièrement scriptables en WLST (« WebLogic Scripting Tool »): pause, purge, déplacement, injection, etc. Cet aspect vous permet donc de capitaliser sur vos compétences WebLogic et votre outillage existants.

3) Extensions JMS :

WebLogic Server étend le standard JMS pour adresser les problématiques non couvertes par la spécification qui reste relativement haut niveau: transmission différée des messages (« Time To Deliver »), diffusion avec garantie d’ordre (« Unit Of Order »), notion de lot de messages (« Unit Of Work »), etc. L’utilisation de ces fonctionnalités n’est pas forcément recommandée mais parfois requise par pragmatisme (ou nécessité). Enfin, tous les produits de type MOM n’implémentent pas ces fonctionnalités.

4) Transactions :

WebLogic Server est de base complètement transactionnel et est compatible avec toute application supportant également le standard JTA. Le standard XA et les transactions distribuées sont également supportés. Aussi, WebLogic Server peut remplir lui-même le rôle de Transaction Manager le rendant autonome. Cet aspect fait de WebLogic Server un MOM robuste et fiable en permettant de garantir la non perte des messages (les messages expirés ou en erreur pouvant être rejoués ou redirigés dans une file d’erreur).

5) Persistance des messages :

WebLogic Server offre deux types de persistance des messages: sur fichiers ou en base de données. Dans le premier cas, les performances sont meilleures et vous ne dépendez pas d’une base de données. Dans le second cas, vous profitez de votre base de données, des outils associés et de vos DBA 🙂 A noter, sans surprise de la part d’Oracle, l’existence d’un type spécial de source de données WebLogic intégré et optimisé pour l’utilisation d’une base Oracle RAC (GridLink Data Source). WebLogic Server constitue ainsi la solution idéale pour intégrer de manière transparente et profiter pleinement des capacités de votre RAC.

6) Haute disponibilité :

Les services JMS sont hautement disponibles au travers d’un cluster WebLogic. L’ajout de nouveaux nœuds à chaud assure la scalabilité (pour les montées en charge) tandis que l’équilibrage de charge et le failover entre nœud garantissent la disponibilité et les performances de votre système. Ceci est possible grâce aux Uniform Distributed Destinations (queue ou topic) où une file logique est constituée d’une file physique par nœud du cluster. WebLogic Server gérant implicitement la notion de cluster, ces files de messages s’administrent et s’utilisent comme une simple file habituelle.

En conclusion, WebLogic Server est une solution MOM hautement disponible (via la notion de cluster héritée du serveur d’applications) et fiable (grâce à sa nature transactionnelle et l’éventuelle base de données sous-jacente).
En espérant avoir attiré votre attention sur ces fonctionnalités moins connues, je ferai un focus sur chacune d’entre elles dans de futures publications. A bientôt !