私はJava EEに非常に慣れていないので、ローカルインターフェースとリモートインターフェースの概念を理解しようとしています。Java EEの大きな利点の1つは、拡張が容易であることです（つまり、さまざまなサーバーにさまざまなコンポーネントをデプロイできるということです）。リモートとローカルのインターフェースはどこにあるのですか？アプリケーションのサーバーごとにコンポーネントが異なることが予想される場合は、リモートインターフェイスを使用することになっていますか？アプリケーションが1つのサーバーにのみ存在する場合は、ローカルインターフェイスを使用しますか？
上記の私の仮定が正しい場合、新しいアプリケーションにローカルインターフェイスとリモートインターフェイスのどちらを使用するかをどのように選択しますか？ローカルインターフェイスを使用して開始し、該当する場合はリモートインターフェイスに徐々にアップグレードしますか？
説明と提案をありがとう。
回答:
私はJava EEに非常に慣れていないので、ローカルインターフェースとリモートインターフェースの概念を理解しようとしています。
EJB仕様の初期バージョンでは、EJBはリモートコンポーネントであると「想定」されていました。EJBを呼び出す唯一の方法は、RMIセマンティクスとそれが意味するすべてのオーバーヘッド（すべてのネットワークコールとオブジェクトのシリアル化）を使用してリモートコールを行うことでした。メソッド呼び出し）。EJBクライアントは、EJBコンテナと同じ仮想マシンに配置されている場合でも、このパフォーマンスのペナルティを支払う必要がありました。
その後、Sunはほとんどのビジネスアプリケーションが実際にはEJBを別の層に配布していないことを認識し、ローカルインターフェースの概念を導入して（EJB 2.0で）仕様を修正しました。直接メソッド呼び出し、RMIセマンティクス（および関連するオーバーヘッド）を完全にバイパスします。
Java EEの大きな利点の1つは、拡張が容易であるということです（これは、さまざまなサーバーにさまざまなコンポーネントをデプロイできることを意味します）。
Java EEはスケーリングできますが、これは必ずしもコンポーネントの配布を意味するものではありません。Web層とEJB層を分離せずに、Web + EJBアプリケーションをクラスターで実行できます。
アプリケーションのサーバーごとにコンポーネントが異なることが予想される場合は、リモートインターフェイスを使用することになっていますか？アプリケーションが1つのサーバーにのみ存在する場合は、ローカルインターフェイスを使用しますか？
私は次のように言います。クライアントが同じJVMにない場合はリモートインターフェースを使用します（これは、1つのサーバー/ JVMのみを使用することを意味するものではありません）。
（...）ローカルインターフェイスを使用して開始し、該当する場合はリモートインターフェイスに徐々にアップグレードしますか？
おそらくローカルインターフェイスを使用することから始めます。また、すでに示唆したように、リモートインターフェイスへの切り替えは必ずしも必須ではありません（連結構造をクラスター化できます）。
下記のリソースを確認することをお勧めします（最初の2つはかなり古いですが、まだ関連性があり、他の2つはより新しいものです）。
It seems like there are a couple ways of scaling a web application (...) and I suppose you could use a combination of both?はい、それだけです。Do you, by chance know of good books on this topic?残念ながら、いいえ、「ZE」という絶対的なリソースがあれば、わかりません。いくつかの参考文献を参考にして、さらにリソースを追加しました。
上記の内容のほとんどに同意しますが、「開始方法」のアイデアを少し洗練させたいと思います。
あなたに私の提案は決してすることです今まであなたのコード内のEJBインタフェースに直接プログラミングします。常に通常のビジネス指向のインターフェースを使用し、それにプログラムして（つまり、コードがビジネス指向のインターフェースでメソッドを呼び出すようにします）、EJBの「接着」コードをプラグ可能な実装として提供します。プログラムは、EJBなどの実装の詳細ではなく、ビジネスロジックに重点を置く必要があります。
そうすることで、リモート実装とローカル実装を簡単に切り替えることができます。また、SpringなどのIoCコンテナーを使用する場合は、構成のみで実行できます。
ローカルからリモートへの切り替えに関する特別な注意：2つの間にいくつかの意味上の違いがあることに注意してください。たとえば、「リモートインターフェース」を介してEJBメソッドを呼び出すと、値によって引数が渡され、「ローカルインターフェース」を介して呼び出すと、参照によって引数が渡されます。これは大きな違いです。したがって、「ローカルから始める」場合は、「リモート」のセマンティクスも考慮するようにシステムを設計してください。
渡されたオブジェクトを変更するEJBメソッドに依存する設計の場合、後で「リモートに切り替える」のは難しいでしょう。おそらく不可能です。
幸運を。
EJB仕様3.2によると、EJBはローカルまたはリモートのいずれかにすることができます。ビジネスインターフェースは、ローカルとリモートの両方になることはできません。
@Local 注釈付きBeanは、同じアプリケーション内にある場合にのみアクセスできます。
@Remote 注釈付きBeanは、さまざまなアプリケーションにまたがって、さまざまなjvmにあるか、アプリケーションサーバーにまたがってアクセスできます。
したがって、覚えておくべき重要なことは次のとおりです。
@Remoteアノテーションが含まれている場合、実装されているすべてのインターフェースはリモートになります。@Local注釈が指定されている場合、実装されているすべてのインターフェースはローカルであると見なされます。@Local別のアプリケーション（JAR、WAR、EAR）でも同じJVMでEJBを呼び出すために使用できますか？
これはあなたの懸念に答えるかもしれません：
一般に、分散Java環境でBeanを使用する場合、Enterprise Java Beanにはリモートクライアントビューが必要です。具体的には、これを使用するクライアントが別のJava仮想マシン（JVM）にある場合です。リモートクライアントビューの場合、リモートホームインターフェースやリモートコンポーネントインターフェースからのメソッドの呼び出しは、リモートメソッド呼び出し（RMI）を介して処理されます。
EJBがローカルクライアントビューを使用できるのは、他のエンタープライズBeanまたはクライアントが単一のJVM内のBeanのみに対処することが本当に保証されている場合のみです。この場合、そのようなアクセスは、RMIではなく直接メソッド呼び出しで実行されます。
出典：http : //www.onjava.com/pub/a/onjava/2004/11/03/localremote.html?page=last&x-showcontent=text