[解決済み] EJB - リモートおよび/またはローカルインターフェイスを使用するとき？

質問

私はJava EEを使い始めたばかりで、ローカル・インターフェイスとリモート・インターフェイスの概念を理解しようとしています。Java EEの大きな利点の1つは、スケールが容易であることだと聞いています（これは、異なるコンポーネントを異なるサーバーにデプロイできることを意味すると思います）。そこで、リモートインタフェースとローカルインタフェースが登場するのでしょうか。アプリケーションが異なるサーバーに異なるコンポーネントを配置することを想定している場合、リモート・インターフェースを使用することになっているのでしょうか？そして、アプリケーションが1つのサーバーにしか存在しない場合は、ローカルインターフェースを使用するのでしょうか？

もし、上記の仮定が正しいのであれば、新しいアプリケーションで、トラフィックの量がわからない場合、ローカルインターフェースとリモートインターフェースのどちらを使うか、どのように選択すればよいでしょうか。まずローカルインタフェースを使用し、必要に応じて徐々にリモートインタフェースにアップグレードしていくのでしょうか？

明確な説明と提案に感謝します。

解決方法は？

私はJava EEを使い始めたばかりで、ローカル・インターフェイスとリモート・インターフェイスの概念を理解しようとしているところです。

EJB仕様の初期バージョンでは、EJBはリモートコンポーネントであると仮定され、それらを呼び出す唯一の方法は、RMIセマンティクスとそれが意味するすべてのオーバーヘッド（メソッド呼び出しごとにネットワーク呼び出しとオブジェクトシリアライズ）を使用して、リモートコールを行うことでした。EJBクライアントは、EJBコンテナと同じ仮想マシンに配置されている場合でも、このパフォーマンス上のペナルティを支払わなければなりませんでした。

その後、Sunはほとんどのビジネスアプリケーションが実際にはEJBを別の層に分散していないことに気づき、EJBコンテナと同じ仮想マシンに配置されたクライアントがRMIセマンティクス（および関連するオーバーヘッド）を完全に回避して直接メソッド呼び出しができるように、ローカルインターフェースの概念を導入して仕様を（EJB 2.0で）修正しました。

Java EEの大きなメリットの1つは、スケールが容易なことだと聞いています（異なるコンポーネントを異なるサーバーにデプロイできるという意味だと思います）。

Java EEは拡張可能ですが、これは必ずしも以下のことを意味しません。 分散 コンポーネントを使用します。Web層とEJB層を分離しなくても、Web+EJBアプリケーションをクラスタ上で実行することができます。

アプリケーションが異なるサーバーに異なるコンポーネントを持つことを想定している場合、リモートインターフェースを使用することになっているのでしょうか？そして、アプリケーションがひとつのサーバーにしか存在しない場合は Local インターフェイスを使用するのでしょうか？

私はこのように表現します：クライアントが同じJVMにない場合、リモートインターフェースを使用します（これは1つのサーバー/JVMだけを使用するという意味ではありません）。

(...) 最初はローカルインタフェースを使用し、必要に応じて徐々にリモートインタフェースにアップグレードしていきますか？

私なら、まずローカルインターフェースを使いますね。そして、すでに示唆されているように、リモートインターフェイスへの切り替えは必ずしも必須ではありません( コロケーション の構造)。

以下のリソース（最初の2つはかなり古いものですが、まだ関連性があり、他の2つはより新しいものです）をチェックすることをお勧めします。

リソース

• J2EEクラスタリングの裏側 by 王瑜
• Java EEアプリケーションのスケーリング by 王瑜
• Java EEアプリケーションのスケーリング -- Part 2 by 王瑜