非Javaクライアントサポートを備えた商用JMS/ママの実装？

Question

これまでのところ、Apache ActiveMQ、JBoss HornetQ、Open Message Queue（OpenMQ）などのオープンソースメッセージブローカーに対してのみ、Java以外のクライアントサポートがサポートされています。

また、WebSphere、Weblogic、またはTIBCOなどのクローズドソース製品は、他の言語でクライアントを書くことができる文書化されたワイヤプロトコル（クローズドソースバイナリクライアントライブラリの反対）を使用して、ママブローカーに非Javaアクセスを提供しますか？

（Weblogicなど）が（EC2）クラウドで利用できるため、これはより興味深いものになっているため、開発者はクラウドインスタンスを使用してフルバージョンを購入およびインストールする必要なくクライアントアプリケーションを開発およびテストできます。

Answer 1

私はWMQのみを専門としているので、私は決定的な答えを持っていません。しかし、私は答えがほとんどの部分で「いいえ」だと思います。 （詳細については1分で。）

WMQに関して、IBMは、チャネル、API呼び出し、および承認の動作を調整するために利用可能な出口ポイントを作成します。出口は非常によく文書化されており、特定のアクションの範囲内で狭い関数を実行します - つまり、メッセージを受け取り、接続を開始します。これらはCおよび最近ではJavaで書かれています。ほとんどの場合、これらは未使用であり、私が話している顧客は一般的に複雑さを引用しています。彼らは、低レベルのコードではなく、構成を通じてカスタマイズ可能なものを望んでいます。他のママベンダーは、顧客から同様の要件を経験していると思います。

これはあなたの質問と何の関係がありますか？これについての私の見解は、顧客が機能が限られている出口をコードアップすることに消極的である場合、信頼できるメッセージ配信、一段階および2フェーズのコミット、クライアント - をサポートするフル機能で堅牢なクライアントをコーディングすることは、はるかに取得されているように見えることです。サイド出口、診断、およびWMQチャネルが提供する他のすべての機能。

このタスクは、そのレベルのコードができるオープンソースチームによって行われたと仮定して、誰がそれをサポートするでしょうか？ママベンダーは現在、独自のクライアントを使用する際にエンドツーエンドのサポートを提供しています。コミュニティがサポートしているサードパーティのクライアントを使用するときに、トラブルチケットがどのように解決されるかという概念は、多くの顧客にとって少し怖いです。たとえば、IBMは、supportPacsと呼ばれるWMQのアドオンを供給します。完全にサポートされ、製品拡張と見なされるSupportPacsがありますが、一部のSupportPacsはそのまま提供されます。私の顧客の多くは、AS-ISコードを実行しません ベンダーから供給されている場合でも.

最後に、インターフェイス契約の概念があります。 WMQは、多くのオプションを備えたいくつかの動詞をサポートしています。基礎となるチャネルプロトコルははるかに複雑です。 WMQ V7が出てきたとき、チャネルにはかなりの新しい機能とチューニングがありました。これは、内部がクライアントにさらされていないため、この規模で可能でした。そのため、IBMはサードパーティのクライアントにマイナスの影響を恐れることなく、大規模な変更を加えることができました。それをすべて公開すると、APIの公開だけで存在するよりも1つまたは2つの高い大きさに依存関係が生成されます。

だから、私の理論によれば（私はここでMQ開発チームのために話すふりをしていません）、大きなママベンダーは既得の関心を持っています いいえ チャネルプロトコルを独立した開発者に公開します。ここの新しいしわは、上記でほのめかしたAMQPです。ワイヤプロトコルを定義し、各ベンダーが準拠した製品をコーディングできるようにします。これは、オープンソースソリューションの機会を提供しますが、製品を改善するための1つの実装の能力は、プロトコルを所有していないという事実によって制限されます。当面は、サードパーティの開発のためにワイヤープロトコルを公開している大きなママベンダーのいずれかが見つかるとは思わないでしょう。とはいえ、これは単なる推測であり、私が間違っているなら、ここにいる誰かが飛び込んで反論を提供すると確信しています。