新しいプロジェクトのために、生活を少し楽にしてくれるテクノロジーを探しています。私の新しいプロジェクトは、基本的に 2 つのクライアントとサーバーです。client1 はメッセージ 1 をサーバーに送信し、サーバーはメッセージ 1 をクライアント 2 に送信し、クライアント 2 はメッセージ 1 で何かを行います。
これは、プレーンな Java ソケットまたは RMI または同様の手法で実行できます。しかし、ここに問題があります。プロセス全体がトランザクションである必要があります。つまり、client2 が message1 を処理できない場合、client1 とサーバーはこれを認識し、実行されたアクションをロールバックする必要があります。
私の最初のアイデアは、クライアント 2 からクライアント 1 にメッセージを送信し、その結果をサーバーに送信することでした。
jms、jta、jca などのテクノロジーについてはすでに調べましたが、すべてに少し圧倒されました。そして、もっと簡単な方法があるのではないかと思います。
分散トランザクションでさえ、アプリケーション間ではなく、JMS ブローカーとデータベースなどのトランザクション リソース間であるため、JTA または JMS だけで問題が解決するかどうかはわかりません。
あなたの場合、JMSなどのトランザクショントランスポートを引き続き使用します。これにより、「保証された配信」が可能になり、エラー処理が簡素化される可能性があります。
1 c1 -> jms -> server -> jms -> c2 2
4 c1 <- jms <- server <- jms <- c2 3
これを正しく行うと、c1 (およびサーバー) が最終的に c2 から良いか悪いかの「結果」を確実に受け取ることができます。
処理中に C2 がクラッシュし、結果の jms メッセージの送信に失敗した場合、トランザクションは c2 でローカルにロールバックされ、c2 は再試行する必要があります。
このソリューションの欠点は、メッセージが「スタック」する可能性があることです。たとえば、c2 でまったく処理できない場合、メッセージが失われることはありません。同期要求 (soap、RMI、単純な tcp など) をルーティングすると、応答が失われ、C2 がメッセージを処理したかどうかを C1 が認識できない状況に直面する可能性があります。これは、C2 を冪等にすることである程度回避でき、しばらくしても応答がない場合は C1 がトランザクションを再試行できるようになります。
私が見ているように、「黄金の解決策」はありませんが、どのオプションでもかなりうまくいくでしょう。幸運を
サーバー コンポーネントについては、 JBoss AS のような本格的な Java EE サーバーでメッセージ駆動型 Beanを使用してみることができます。その場合、クライアントは JMS を使用してサーバーと通信します。