なぜ人々はRMIを使用するのですか、またはいつRMIを使用する必要がありますか？オラクルのウェブサイトでRMIに関するチュートリアルを読みました。しかし、それは十分な実用的な例を提供していません。
私の理解では、ソフトウェアはそのモジュールを可能な限り「無関係で分離された」ものにする必要があります。RMIはどういうわけか私にとって高い結合の例のようです。なぜこれは悪いコーディング慣行ではないのですか？オブジェクトの実際の操作はすべてサーバーによって行われたのに対し、クライアントは命令のみを実行する必要があると思いました。
基本的には、レイアウトしたばかりの理由から、今日作成するアプリケーションにRMIを使用するべきではありません。
場合によっては（レガシーまたは「エンタープライズ」アプリケーションに飛び込む）、選択の余地がありません。
ただし、新しいプロジェクトを開始する場合、他のオプションは次のとおりです。
リモートサービスと通信するためのデファクトスタンダード。最大のメリットは、軽量でコンセプトがわかりやすいことです。
理論的には、使用可能なURL、各URLで受け入れられる動詞などを手動で作成する必要があるため、RMIよりも多くの作業が必要になります。実際には、RMIの定型文は実際には誰にも役立ちません。
Javaにこだわる、Jerseyは、独自のRESTfulWebサービスを作成するための優れたライブラリです。
Javaを使用したRESTfulWebサービス用のバッテリーを含むソリューションが必要な場合、YammerのナイスガイによるDropwizardは、ビジネスロジックをプラグインする準備ができた完全なサーバーとフレームワークを提供し、ロギング、データベース接続、シリアル化、リクエストルーティング、および箱から出して収集するメトリックさえ。
リモートサービスと通信するための以前の標準。あなたがそれを使う理由がない限り、私はRESTに固執するでしょう。
Thriftはクライアントとサーバーのスタブを作成し、基本的に多くの作業を行います。通信は効率的なバイナリプロトコルで行われます。「ビッグデータ」分野の多くのオープンソースプロジェクトで使用されているため、Javaの世界で人気が高まっています。例、Cassandra、HBase（Avroへの切り替え）。Scroogeは、scala用の慣用的な節約スタブを作成するためのTwitterプロジェクトです。
Akkaは、ScalaとJavaのアクターモデルを実装するフレームワークです。サービス間通信のプロビジョニングが含まれ、内部で詳細の多くを処理します。私
ニーズに応じて、他のものよりも適しているものもあります。
大規模な集中型コンピューティングパワーまたは高価なリソース（たとえば、巨大なデータベース）を必要とする機能があるが、そのようなワークロードをデプロイできない多くの場所で出力する必要がある場合は、リモートメソッド呼び出しを確認します。 。ウェブについて考えてみましょう。デスクトップに計算したい検索用のGoogleのコピーがなく、結果が必要な瞬間にGoogleのサーバーをリモートで呼び出します。RMIは、アプリケーションをサーバー間で分散し、そのコードの結果にアクセスする必要のあるクライアントを分離するためのプロトコル/システムです。
RMIは、アプリケーションの側面を保護する方法としても機能します（独自のアルゴリズムなど）。RMIだけがアプローチではなく、HTTP、SOAPなどを使用することもできます。これらの他のアプローチの多くは、真の言語の透過性、より簡単で効率的な実装、より優れたデカップリングなどの他のアプローチを提供します。
ドキュメントからのRMIの目標は次のとおりです。
Javaプログラミング言語で分散オブジェクトをサポートするための目標は次のとおりです。
- 異なる仮想マシン内のオブジェクトでのシームレスなリモート呼び出しをサポートする
- サーバーからアプレットへのコールバックをサポートする
- Javaプログラミング言語のオブジェクトセマンティクスのほとんどを保持しながら、分散オブジェクトモデルをJavaプログラミング言語に自然な方法で統合します
- 分散オブジェクトモデルとローカルJavaプラットフォームのオブジェクトモデルの違いを明確にする
- 信頼性の高い分散アプリケーションの作成を可能な限り簡単にします
- Javaプラットフォームのランタイム環境によって提供される型安全性を維持する
- リモートオブジェクトのさまざまな参照セマンティクスをサポートします。たとえば、ライブ（非永続的）参照、永続的参照、および遅延アクティベーション
- セキュリティマネージャとクラスローダーによって提供されるJavaプラットフォームの安全な環境を維持するこれらすべての目標の根底にあるのは、RMIモデルが単純（使いやすい）かつ自然（言語によく適合する）であるという一般的な要件です。
そうです、RMIは、サービスプロバイダーとサービスコンシューマーの間の緊密な結合の例です。そして、それは一見したところよりもさらに悪いです。クライアント側にプッシュされる可能性のある例外がわからないため、ClassNotFoundException発生した実際のエラーがマスクされます。RMI、および同様に、EJBは過去のテクノロジーであり、「透過的に分散されたオブジェクト」の妄想を信じていた過去です。
今日のリモートサービスは、RMIのアプローチとは正反対のRESTとJSONに基づいています。
RMIは、ローカルメソッド呼び出しのように見えるほどタイトなバインディングが必要な、まったく逆のケースです。それを望まないのなら、それを使わないでください。RMIに関する本を書いたとしても、RPCパラダイム全体は、私を含むすべての人に適しているわけではありませんが、すべてのツールにはその用途があります。たとえば、JavaEEはRMIモデルに基づいて構築されています。