0

通常、人々はこのレイヤーの上で作業するだけですが、私は現在、PUB/SUB 多対多メッセージング関係を IPC または TCP インフラストラクチャにマップする必要があるこのレイヤーで作業しています。アドレスごと。

私が考えることができる代替案には、それぞれ独自の欠点があります。

  1. デーモンを追加してメッセージをルーティングします。これにより、単一障害点が追加されるだけでなく、メッセージング中にレイヤーが追加されます。
  2. レジストリの追加。単一障害点が追加され、新しく開始されたプロセスに通知できなくなります。
  3. 同じトピックで複数のパブリッシャーを許可しない - アーキテクチャの配置に関する柔軟性がいくらか失われます。
  4. ポート範囲と IPC アドレス範囲を事前に定義すると、すべてのプロセスがそれらへの接続を定期的に再試行します。サービス検出に遅延を追加し、すべてのポートが OS から利用可能である必要があります。

では、JMS や LBM などの最新のメッセージング ソフトウェア パッケージはどのようにこれを行っているのでしょうか? Tibco RV と Reuters がアプローチ 1) を行っていることは知っていますが、とにかく、そのようなデーモン プロセスを回避できますか?

問題があればJavaを使用しています。

ありがとう。

4

1 に答える 1

1

各マシンにローカル デーモンを作成し、jms をローカルでスポークしてから永続性を提供することで、要件に対処しようとしました。

既知のポートへの TCP ブロードキャストを使用して、トピックとキューの関連付けを IP アドレスとポートにアドバタイズします。次に、アドバタイズされたポートへの直接接続を確立して、トランザクションでメッセージをパブリッシュまたはサブスクライブできます。

于 2014-12-11T19:46:33.647 に答える