これまでのところ、Java以外のクライアントは、Apache ActiveMQ、JBoss HornetQ、Open Message Queue（OpenMQ）などのオープンソースメッセージブローカーのみをサポートしています。
他の言語でクライアントを作成できる文書化されたワイヤープロトコル（クローズドソースのバイナリクライアントライブラリの反対）を使用して、MOMブローカーへの非Javaアクセスを提供するWebSphere、WebLogic、Tibcoなどのクローズドソース製品もありますか？
開発者がフルバージョンを購入してインストールしなくてもクラウドインスタンスを使用してクライアントアプリケーションを開発およびテストできるように、製品（WebLogicなど）が（EC2）クラウドで利用できるようになると、これはさらに興味深いものになります。
私はWMQを専門としているため、明確な答えはありません。しかし、ほとんどの場合、答えは「いいえ」だと思います。（これについては後ほど詳しく説明します。）
WMQに関して、IBMは、チャネル、API呼び出し、および許可の動作を調整するための出口点を使用可能にします。出口は非常によく文書化されており、特定のアクションの範囲内で狭い機能を実行します。つまり、メッセージの受信、接続の開始などです。これらはCで記述されており、最近ではJavaで記述されています。ほとんどの場合、これらは未使用であり、私が話す顧客は一般的に複雑さを引用しています。彼らは、低レベルのコードではなく、構成によってカスタマイズ可能なものを求めています。他のMOMベンダーも顧客から同様の要件を経験していると思います。
これはあなたの質問と何の関係がありますか？私の考えでは、顧客が機能が制限された出口をコード化することに消極的である場合、信頼性の高いメッセージ配信、1フェーズおよび2フェーズコミット、クライアントをサポートするフル機能の堅牢なクライアントをコード化することは非常に難しいようです。サイド出口、診断、およびWMQチャネルが提供する他のすべての機能。
このタスクがそのレベルのコードが可能なオープンソースチームによって行われたと仮定すると、誰がそれをサポートしますか？MOMベンダーは現在、独自のクライアントを使用する際にエンドツーエンドのサポートを提供しています。コミュニティでサポートされているサードパーティのクライアントを使用するときにトラブルチケットがどのように解決されるかという概念は、多くのお客様にとって少し怖いものです。たとえば、IBMはSupportPacsと呼ばれるWMQ用のアドオンを提供しています。完全にサポートされ、製品拡張と見なされるSupportPacsがありますが、一部のSupportPacsは現状のまま提供されます。私の顧客の多くは、ベンダーから提供されたとしても、そのままのコードを実行することはありません。
最後に、インターフェースコントラクトの概念があります。WMQは、多くのオプションを備えたいくつかの動詞をサポートしています。基盤となるチャネルプロトコルは、はるかに複雑です。WMQ v7がリリースされたとき、チャネルにはかなりの新しい機能とチューニングがありました。これは、内部がクライアントに公開されていないため、この規模で可能でした。そのため、IBMは、サードパーティのクライアントに悪影響を与えることを恐れずに大規模な変更を行うことができました。これらすべてを公開すると、APIだけを公開した場合よりも1〜2桁高い依存関係が作成されます。
したがって、私の理論によれば（ここでは、MQ開発チームについて話すふりをしません）、大手MOMベンダーは、チャネルプロトコルを独立した開発者に公開しないことに強い関心を持っています。ここでの新しいしわは、上記で触れたAMQPです。ワイヤプロトコルを定義し、各ベンダーが準拠製品をコーディングできるようにします。これはオープンソースソリューションについて説明する機会を提供しますが、製品を改善するための1つの実装の能力は、それらがプロトコルを所有していないという事実によって制限されます。現時点では、サードパーティの開発用にワイヤプロトコルを公開している大手MOMベンダーはないと思います。とはいえ、これは単なる推測であり、私が間違っている場合は、ここの誰かが飛び込んで反例を提供すると確信しています。