ローカルのGlassfish3 インストールで実行される Java EE 6 エンタープライズ アプリケーションに取り組んでいます。私の EJB の 1 つは、インターネット上のどこかにあるリモートJMS ブローカにメッセージを送信する必要があります。
残念ながら、インターネット接続は信頼性が低いため、最初にメッセージをローカルのGlassfish 独自の JMS ブローカーに送信することを考えています。その後、ローカルブローカーはメッセージをリモートブローカーに転送します。インターネット接続が利用できない場合、ローカルブローカーは接続が復旧するまで待機します。
これが機能すると仮定するのは正しいですか？もしそうなら、私はどのように始めるかについていくつかのアイデアを高く評価します.
このアプローチは、この状況 (リモート エンドポイントが常に利用できるとは限らない場合) に完全に有効であり、「ストア アンド フォワード」メッセージングとして知られています。実際、WebLogic と彼のストア アンド フォワードサービスなど、多くのアプリケーション サーバーがこれをそのままサポートしています。
SAF サービスにより、WebLogic Server は、複数の WebLogic Server インスタンスに分散されたアプリケーション間でメッセージを確実に配信できます。たとえば、SAF サービスを使用すると、ローカルの WebLogic Server インスタンスで実行または接続するアプリケーションは、リモート サーバに存在するエンドポイントにメッセージを確実に送信できます。ネットワークの問題またはシステム障害が原因で、メッセージの送信時に宛先が使用できない場合、メッセージはローカル サーバー インスタンスに保存され、使用可能になるとリモート エンドポイントに転送されます。
Open MQ (GlassFish の JMS 実装) の場合、 Store and Forward メッセージングが機能計画にあることを知っていました ( 2007 年のこのプレゼンテーションを参照)。しかし、これについて正確なステータスを見つけるのは困難です (このようなメッセージでは状況が明確になりません)。確かなことは、GlassFish v3 が Open MQ 4.4 を使用し、 Open MQ 4.4には JMS ブリッジ (ストア アンド フォワードに必要) があり、ブローカー間の通信に使用できる可能性があることです。構成方法については、この最近のブログ投稿を参照してください(Open MQ 4.4 のドキュメントが見つかりませんでした!!)。個人的には、dev メーリング リストにメッセージを投稿します。
これが本当に明確でない場合、または満足のいく答えが得られない場合は、メッセージを消費して別のブローカーに転送するカスタム アプリケーションを作成することが常に可能であり、それほど複雑ではありません。基本的に、メッセージのストア アンド フォワードとは、アプリケーションに「ローカル」永続キューを使用し、MDB を使用してメッセージを消費し、リモート JMS 宛先に (単一のトランザクションで) 送信することを意味します。これにはさらにテストが必要ですが、JMS クライアントとして、転送を処理する MDB はリモートの宛先に透過的に再接続できる必要があります。
JMS は、クライアント(プロデューサーまたはコンシューマー) が信頼できない場合に適していますが、ブローカー自体が信頼できない場合は問題になります。
「ステージング」ブローカーの再配信パラメーター (タイムアウト、再試行回数など) を試してみることができます。ただし、フォアウェアとして機能するダミー MDB が必要な場合: 開始ブローカーは、外部ブローカーに接続しようとするダミー MDB に配信を試みます。それができない場合、トランザクションは失敗し、メッセージはステージング ブローカーに残ります。状態のブローカーは、後でメッセージをダミーの MDB に再配信しようとします。
「ステージング」ブローカーの再配信機能は、MDB が「外部」ブローカーにメッセージを転送できない場合に接続の問題を管理するのに役立ちます。ただし、設定によっては、ある時点でメッセージが「ステージング」ブローカーのデッド メッセージ キュー (DMQ) に移動したり、破棄されたりする可能性があることに注意してください。
しかし、これはまだ私には少し奇妙に聞こえます...