6

JMS を内部的に使用し、外部の Java ソフトウェアと通信する Java に特化したツールを使用します。ここで、C# アプリケーションへの新しいインターフェイスをセットアップする必要があります。私たちの JMS プロバイダーは C# の実装を提供していますが、これは機能するはずですが、この場合に JMS が適しているかどうかは完全にはわかりません。実装の詳細とクライアントのサポートの両方について、C# アプリケーションに新しいベンダー固有の依存関係が導入されます。

STOMP は、複数の JMS 対応メッセージ ブローカー (hornetq、activemq など) によってサポートされている確立されたワイヤ レベルのプロトコルのようですが、C# (および Java からある程度）。あまり深く掘り下げないと、「テキスト」の強調がどこで機能するのか完全にはわかりませんか? バイナリオブジェクトをサポートしていませんか?

別の解決策は、別のワイヤーレベルのプロトコルである AMQP である可能性がありますが、1.0 仕様はまだリリースされておらず、4 年前の 0.9.1 仕様の実装にうんざりしています。

セキュリティ、サポート、トランザクション性、標準への準拠、移植性などを考慮して、言語間非同期メッセージングに最適なソリューションはどれでしょうか... 適切な WS-* を使用した SOAP は、この特定のインターフェイスのオプションではないことに注意してください。

EDIT1 :クロスプラットフォーム、クロス言語メッセージング システムなどの質問を見たことがありますか? しかし、彼らは複数の言語で動作する特定のツールに焦点を合わせているようです. 私は実際に、複数のベンダーによって実装されている、または実装できる標準準拠のプロトコルを探しています。

4

2 に答える 2

1

オプションとして、C# クライアントを基礎となる特定の通知プロトコルから抽象化し、共通の相互運用アダプター (リレーショナル データベース、 Web サービス、特定のフォルダー内の xml ファイル。

アダプターを提供し、アダプターとメッセージング サブシステム間のブリッジを提供するのはユーザーの責任ですが、明確な利点があります。エンタープライズ環境間の相互の義務は、非常に共通のレベルで定義されます。いつの日かメッセージング サブシステムを交換して、すべての入出力ポートを保持することもできます。つまり、C# クライアントは、JMS を別のメッセージング インフラストラクチャに置き換えたことにさえ気付かないということです。これは、同じ一連のアダプターからデータを引き続き送受信するためです。

于 2012-10-08T09:40:52.930 に答える
1

あなたの質問を正しく理解できたかどうかわかりませんが、 RabbitMQは AMQP 実装であり、C# と Java のバインディングがあります。

「C# アプリケーションにおける新しいベンダー固有の依存関係」を防ぐために、Spring.Net フレームワークのメッセージング コンポーネントと、関連する .Netプロジェクトの AMQP を確認することをお勧めします。これにより、POCO とビジネス ロジックをメッセージング ミドルウェアとインフラストラクチャから分離できます。

于 2012-10-08T09:41:32.160 に答える