Implémentations commerciales JMS/MOM avec prise en charge client non-Java?

Question

Jusqu'ici j'ai vu la prise en charge des clients non-Java uniquement pour les courtiers de messages open source comme Apache ActiveMQ, JBoss HornetQ et Open Message Queue (OpenMQ). Y a-t-il aussi des produits fermés comme WebSphere, WebLogic ou Tibco qui offrent un accès non-Java à leurs courtiers MOM, en utilisant un protocole filaire documenté (opposé à une bibliothèque client binaire fermée) qui permet d'écrire des clients dans autres langues? Cela devient de plus en plus intéressant car des produits (comme WebLogic) sont disponibles dans le cloud (EC2) afin que les développeurs puissent utiliser l'instance cloud pour développer et tester une application client sans devoir acheter et installer la version complète.

Answer 1

Je n'ai pas de réponse définitive car je me spécialise exclusivement dans WMQ. Cependant, je crois que la réponse est «non» pour la plupart. (Plus d'informations dans un instant.)

À propos de WMQ IBM propose des points de sortie pour personnaliser le comportement des canaux, des appels API et des autorisations. Les sorties sont très bien documentées et exécutent des fonctions étroites dans le cadre d'une action particulière - c'est-à-dire recevoir un message, initier une connexion, etc. Elles sont écrites en C et, plus récemment, en Java. Pour la plupart, ils sont inutilisés et les clients auxquels je parle citent généralement la complexité. Ils veulent quelque chose de personnalisable grâce à la configuration et non via un code de bas niveau. Je soupçonne que d'autres fournisseurs de MOM rencontrent des exigences similaires de la part des clients.

Qu'est-ce que cela a à voir avec votre question? Mon point de vue est que si les clients sont réticents à coder des exits avec une fonction limitée, il semble farfelu qu'ils coderaient un client complet et robuste qui prend en charge la livraison fiable des messages, la validation en une et deux phases, le client ... les sorties secondaires, les diagnostics et toutes les autres fonctionnalités fournies par les canaux WMQ.

En supposant que cette tâche ait été entreprise par une équipe open-source capable de ce niveau de code, qui la supporterait? les fournisseurs MOM offrent actuellement un support de bout en bout lorsqu'ils utilisent leurs clients propriétaires. La notion de comment un ticket d'incident peut être résolu lors de l'utilisation d'un client tiers pris en charge par la communauté est un peu effrayant pour de nombreux clients. Par exemple, IBM fournit des modules complémentaires pour WMQ appelés SupportPacs. Bien qu'il existe des SupportPacs entièrement pris en charge et considérés comme des extensions de produit, certains des SupportPac sont fournis tels quels. Beaucoup de mes clients ne fonctionneront pas comme le code même s'il est fourni par le fournisseur.

Enfin, il y a la notion de contrat d'interface. WMQ supporte quelques verbes avec beaucoup d'options. Le protocole de canal sous-jacent est BEAUCOUP plus complexe. Lorsque WMQ v7 est sorti, les canaux ont eu une nouvelle fonctionnalité et un réglage considérables. cela a été possible à cette échelle parce que les composants internes ne sont pas exposés aux clients et IBM a donc pu effectuer des changements massifs sans craindre d'impact négatif sur les clients tiers. Exposer tout cela créerait des dépendances sur une commande ou sur deux ordres de grandeur supérieurs à ceux qui existent avec seulement les API exposées. Donc, selon ma théorie (je ne prétends pas parler ici pour l'équipe de développement de MQ), les grands fournisseurs de MOM ont un intérêt direct dans et non exposant leurs protocoles de canaux à des développeurs indépendants. La nouvelle ride ici est AMQP à laquelle j'ai fait allusion ci-dessus. Il définit le protocole filaire et permet à chaque fournisseur de coder un produit conforme. Bien que ce soit l'occasion que vous décrivez pour les solutions Open Source, la capacité d'une implémentation à améliorer le produit est limitée par le fait qu'elle ne possède pas le protocole. Pour le moment, je ne m'attends pas à ce que vous trouviez l'un des grands fournisseurs de MOM exposant leurs protocoles de câblage pour le développement de tiers. Cela dit, ce n'est qu'une supposition et si je me trompe, je suis sûr que quelqu'un ici interviendra et fournira le contre-exemple.