Java で分散アプリケーションを設計する場合、同じ種類の問題に対処するテクノロジがいくつかあるようです。Java Remote Method InvocationとJava Message Serviceについて簡単に読んだことがありますが、その違いを実際に理解するのは困難です。Java RMI は、JMS が非同期通信を使用するため、JMS よりも緊密に結合されているように見えますが、それ以外には大きな違いは見られません。
また、 Web サービスとCORBAも同じ問題に対処していると思います。
メソッド呼び出しについては既にご存知でしょう。メソッドを呼び出したいオブジェクトが別のコンピューターにある場合はどうなるでしょうか。RMI を使用して、あるコンピューター (クライアント) から別のコンピューター (サーバー) に呼び出しを送信します。クライアントは、結果がサーバーから返されるまで待機(または「ブロック」) します。これを同期操作と呼びます。
JMS は異なります。電子メールのように、あるコンピュータから別のコンピュータにメッセージを送信できます。最初のものは、応答を待つ必要はありません。必要な作業を続けることができます。返事すら来ないかもしれません。2 つのコンピューター システムは必ずしも正確に同期して動作するとは限らないため、これは非同期と呼ばれます。
違いについての別の考え方: RMI は電話をかけるようなものであり、JMS はテキスト メッセージを送信するようなものです。
RMI は JMS より少し古いですが、それはあまり関係ありません。この 2 つの概念は、Java よりもはるかに古いものです。
複雑さには大きな違いはありません。それぞれのチュートリアルを試してみるとよいと思います。RMIとJMS
プロジェクトを最初から開始していて、どちらを使用すればよいかわからない場合は、おそらく同期/非同期の問題が最良の決定要因です。既存のシステムで作業している場合は、あまり多くの新しいテクノロジを導入しないことをお勧めします。そのため、すでに使用している場合は、おそらくそれを使い続けることをお勧めします.
リンゴとオレンジの 2 つを実際に比較することはできません。
RMI はリモート プロシージャ コール (RPC) の一種です。これは軽量な Java 固有の API であり、通信時に発信者と受信者が利用できることを期待しています。
JMS は信頼できるメッセージング API です。JMS プロバイダーは、さまざまなメッセージング システム用に存在します。プロバイダーがそれを実装していれば、パーティの 1 つが利用できない場合でも、メッセージを渡すことができます。私がよく知っているのは、TIBCO と IBM MQ の 2 つです。
RMI は保証された配信または非同期応答を処理しません。プロバイダによっては、JMS が処理する場合があります。
JMS では、可用性という意味での疎結合が可能です。「Web サービス」は、プロトコルとデータの意味での疎結合を可能にしますが、信頼できるメッセージングの方法についてはあまり指定しませんが、これを含む実装 (Windows Communication Foundation) と含まない実装があります。
編集済み: コメントごとに改訂。2010 年にこの回答を書いたとき、私の経験は実際には 1 つの JMS プロバイダーだけであり、実際にはデフォルトの JMS プロバイダーがないことを知りませんでした。