ユース ケース : 1 つまたは 2 つの C++ プロセスを含む 1 つの Java プロセスが、常に同じマシン上にある。双方向、バイナリ、非永続通信が必要です。C++ プロセスの 1 つは、他のプロセスのインスタンス化を担当します。
XML/JSON-RPC、Protocol Buffers、Thrift、zeromq などを見て回りました。
できれば移植性があればいいのですが、Windows XP/7 が必要です。
質問する
3420 次
2 に答える
12
一般に、設計ではメッセージ トランスポートとメッセージのデシリアライゼーションを分離し、それらを可能な限り直交させておく必要があります。つまり、データ (メッセージ) フローの動作をメッセージ コンテンツから切り離します。
- メッセージ指向のトランスポート フレームワークがいくつかあり、スレッド、プロセス間でクライアント/サーバー通信の特定の動作パターン (要求/応答、発行/購読、プッシュ/プルなど) に対してニュートラル ペイロード データ (メッセージ) を送受信できます。クライアントおよびサーバー インスタンスとしてのネットワーク サービス。
- トランスポート ニュートラルな方法でペイロード (メッセージ) データのデシリアライゼーション/シリアル化を提供するフレームワークが多数あります (たとえば、マシンのエンディアンに関係なくネイティブの整数データを交換するためのワイヤ形式を提供する)。
特定のユースケースに最適な組み合わせの選択は、設計上の決定に対する多くの要件と制約によって異なります。
- スレッド、プロセス、またはサーバー/プロセスとしてのクライアント/サーバー処理ユニットのスケーラビリティ
- 全体的なパフォーマンスとメッセージの待ち時間
- 処理ユニットのリソース要件 (ヒープ メモリやコード サイズなど)
- ネットワーク リソースへの影響 (ネットワーク インターフェイス経由で送信されるもの)
- など ...
考えられる解決策: Google Protobufメッセージ フレームワークと組み合わせ
たZMQ メッセージング フレームワークは、ユース ケースに実行可能なソリューションを提供できると思います。C++とJavaの言語バインディングがあり( ZMQ Java bindingを参照)、プロセス間およびスレッド間通信用に最適化された実装が得られます。ZMQ 接続はソケットのような方法で設計されており、双方向 (リクエスト/応答) の通信パターンと単方向 (パブリッシュ/サブスクライブ、プッシュ/プル) をサポートしています。
前述のように、メッセージ コンテンツの形式は自由ですが、Google Protobufは、C++ および Java 言語バインディングでサポートされている内部定義のメッセージ プロトコルに適している場合があります。Google ProtobufはRPC サービス インターフェースを定義するメカニズムも提供しますが、クライアント/サーバー実装用の具体的なメッセージ トランスポート プロトコルを提供する必要があります。ZMQ トランスポートを使用してこれを実装したことはありませんが、必要に応じて可能になるはずです。
XML/JSON-RPC は、公開された (たとえば、REST サービスを介した) プロトコルと見なされる場合があります (ブリッジは ZMQ を使用するとかなり簡単です)。
あなたの要件を考慮すると、後者のプロトコル形式オプションは必須ではないと思いますが、Java/C++ 参加者で使用する予定のフレームワークによっては便利かもしれません。
AFAIK ZMQ は、Windows XP/7 プラットフォームに関する移植性の制約に一致します。確かではありませんが、Windows システムではスレッド間通信に制限がある可能性があります。しかし、それはあなたが説明したシナリオには当てはまらないようです。
代替トランスポート フレームワーク:
- アクティブMQ
- Boost asio (C++ でラップされたネイティブ ソケット。Java 側についてはわかりません。お気軽にこの情報を強化してください)
代替メッセージ エンコーディング/デコーディング フレームワーク:
于 2013-01-25T20:29:40.090 に答える
1
質問のコメントからの情報によると、プロトコルバッファは考慮すべきものだと思います-ネットワーク上でバイナリ形式を持ち、シンプルなAPIを持ち、永続化などの冗長なものを提供しません。
于 2012-05-08T20:45:03.977 に答える