web-dev-qa-db-ja.com

EJB-リモートおよび/またはローカルインターフェイスを使用する場合

私はJava EEが初めてであり、ローカルインターフェイスとリモートインターフェイスの概念を理解しようとしています。 Java EEの大きな利点の1つは、簡単に拡張できることです（異なるサーバーに異なるコンポーネントをデプロイできることを意味すると思います）。リモートとローカルのインターフェースはどこにあるのですか？アプリケーションが異なるサーバー上に異なるコンポーネントを持っていることが予想される場合、リモートインターフェイスを使用することになっていますか？また、アプリケーションが1つのサーバーにのみ存在する場合は、ローカルインターフェイスを使用しますか？

上記の私の仮定が正しい場合、トラフィックの量が不明な場合に、新しいアプリケーションにローカルインターフェイスを使用するかリモートインターフェイスを使用するかをどのように選択しますか？ローカルインターフェイスを使用して開始し、必要に応じてリモートインターフェイスに徐々にアップグレードしますか？

明確化と提案をありがとう。

javajava-eeejb
177
Brian DiCasa

私はJava EEが初めてであり、ローカルインターフェイスとリモートインターフェイスの概念を理解しようとしています。

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

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

Java EEの大きな利点の1つは、簡単にスケーリングできることです（異なるサーバーに異なるコンポーネントをデプロイできることを意味すると思います）

Java EEはスケーリングできますが、これは必ずしも分散コンポーネントを意味するわけではありません。 Web層とEJB層を分離せずに、クラスターでWeb + EJBアプリケーションを実行できます。

アプリケーションが異なるサーバー上に異なるコンポーネントを持っていることが予想される場合、リモートインターフェイスを使用することになっていますか？また、アプリケーションが1つのサーバーにのみ存在する場合は、ローカルインターフェイスを使用しますか？

クライアントが同じJVMにない場合、リモートインターフェイスを使用します（これは、1つのサーバー/ JVMのみを使用することを意味しません）。

（...）ローカルインターフェイスを使用して開始し、必要に応じてリモートインターフェイスに徐々にアップグレードしますか？

おそらく、ローカルインターフェイスを使用することから始めます。また、既に示唆したように、リモートインターフェイスへの切り替えは必ずしも必須ではありません（collocated構造をクラスター化できます）。

下記のリソースを確認することをお勧めします（最初の2つは非常に古いものですが、まだ関連性があり、他の2つは最近のものです）。

資源

179
Pascal Thivent

上記の内容の大部分には同意しますが、「開始方法」のアイデアを少し洗練したいと思います。

あなたへの私の提案は、決してeverコード内のEJBインターフェースに直接プログラムしないことです。常に通常のビジネス指向のインターフェイスを使用し、それにプログラムします（つまり、ビジネス指向のインターフェイスでコードを呼び出します）。プラグイン可能な実装としてEJB「接着」コードを提供します。プログラムは、EJBなどの実装の詳細ではなく、ビジネスロジックに焦点を当てる必要があります。

そうすれば、リモート実装とローカル実装を簡単に切り替えることができます。また、SpringなどのIoCコンテナーを使用している場合は、構成のみで実行できます。

ローカルからリモートへの切り替えに関する特別な注意：2つの間に意味的な違いがあることに注意してください。たとえば、「リモートインターフェイス」を介してEJBメソッドを呼び出すと、値によって引数が渡されますが、「ローカルインターフェイス」を介して呼び出すと、参照によって引数が渡されます。これはmajorの違いです。したがって、「ローカルで開始」する場合は、「リモート」セマンティクスも考慮に入れるようにシステムを設計してください。

設計が、渡されたオブジェクトを変更するEJBメソッドに依存している場合、後で「リモートに切り替える」のは難しいでしょう。おそらく不可能です。

幸運を。

47
Isaac

EJB Spec 3.2によると、EJBはlocalまたはremoteのいずれかになります。ビジネスインターフェイスは、同時にローカルとリモートの両方にすることはできません。

@Local注釈付きBeanは、同じアプリケーション内にある場合にのみアクセスできます。

@Remote注釈付きBeanは、さまざまなアプリケーション間、さまざまなjvm内またはアプリケーションサーバー間でアクセスできます。

したがって、留意すべき重要なことは次のとおりです。

  1. Beanクラスに@Remote注釈が含まれている場合、実装されているすべてのインターフェースはリモートになります。
  2. Beanクラスに注釈が含まれていない場合、または@Local注釈が指定されている場合、実装されているすべてのインターフェースはローカルであると見なされます。
  3. インターフェースを含まないBeanに対して明示的に定義されているインターフェースは、@ Localとして宣言する必要があります。
  4. EJB 3.2リリースは、ローカルおよびリモートのインターフェースを明示的に定義する必要がある状況に対して、より細かく提供する傾向があります。
15
Pritam Banerjee

これはあなたの懸念に答えるかもしれません：

通常、Enterprise Java Beanは、分散環境でBeanを使用する場合にリモートクライアントビューを必要とします。具体的には、これらは、それと連携するクライアントが異なるJava Virtual Machine（JVM）にある場合です。リモートクライアントビューの場合、リモートホームインターフェイスやリモートコンポーネントインターフェイスからメソッドを呼び出すと、リモートメソッド呼び出し（RMI）によって処理されます。

EJBがローカルクライアントビューを使用できるのは、他のエンタープライズBeanまたはクライアントが単一のJVM内のBeanのみに対処することが本当に保証されている場合のみです。この場合、そのようなアクセスは、RMIの代わりに直接メソッド呼び出しで実行されます。

ソース： http://www.onjava.com/pub/a/onjava/2004/11/03/localremote.html?page=last&x-showcontent=text

7
Abdulaziz