EJB 3.0セッションBeanに個別のリモートインターフェースとローカルインターフェースが必要な理由
EJB 3.0セッションBeanにリモートインターフェースとローカルインターフェースを分離する必要があるのはなぜですか。ほとんどの場合、両者は同じ契約を定義していると思います。なぜ私は共通のインターフェースを持つことができず、私のBeanでこのBeanにリモートおよび/またはローカルでアクセスできるようにしたいだけなのでしょう。
ありがとうビカス
これはEJB仕様が言うことです：
ローカルとリモートのプログラミングモデルの選択は、エンタープライズBeanの開発時にBeanプロバイダーが行う設計上の決定です。
エンタープライズBeanにリモートクライアントビューとローカルクライアントビューの両方を提供することは可能ですが、より一般的にはどちらか一方のみが提供されます。
したがって、Beanを作成するときにクライアントが誰かを考える場合、ローカルクライアントがリモートメソッドと同じメソッドまたは同じBeanを必要とすることはほとんどありません。
設計時にリモートとローカルを簡単に変更できるものとして扱う必要があることには同意しません。
まず、リモート呼び出しにはオーバーヘッドがあるため、リモートインターフェースを設計するときは、粒度とパラメーターサイズが適切かどうかを慎重に検討する必要があります。したがって、注意点これは比較的高価になりますはデザイナーとして役立ちます。
また、リモートインターフェースのパラメーターは値で渡され、ローカルインターフェースのパラメーターは参照で渡されるため、2つのケースの間には基本的な意味上の違いがあるため、2つのインターフェースを別々に設計することを選択できます。
「場所の透明性」の概念は危険なアンチパターンです。設計では、多くの理由で（エラー処理とパフォーマンスが最も明白である）、ローカルコールかリモートコールかを知る必要があります。
リモート呼び出しでのみ発生する可能性のあるネットワーク関連のエラーに対応するには、例外の署名が異なる必要があるため、リモートEJBインターフェースは、ローカルの対応するインターフェースとは異なります。 （EJB 1の場合のように）リモート処理の手荷物をローカルインターフェースに追加すると、コードは恐ろしくなります。 EJB 2では、ローカルであったEJBのプログラミングを簡素化するために、個別のローカルインターフェースが導入されました。
クライアントは、Beanのインターフェースを介してセッションBeanまたはエンティティBeanにアクセスします。 EJBコンテナーは、この動作を実施および管理するためのインターフェース実装を生成し、クライアントとBean間の通信の導管として機能します。 EJB 2.0仕様の前のバージョンでは、すべてのBeanが分散リモートコンポーネントとして定義および実装されていました。その結果、Beanに必要な2つのインターフェースは、ホームインターフェース（一般にライフサイクルメソッドを定義する）とリモートインターフェース（一般に機能ビジネスメソッドを定義する）と呼ばれていました。
Internally, J2EE uses the Java Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) to enable remote, distributed method calls and applications. While this approach provides many benefits, it also generates a large amount of overhead, with a corresponding performance hit as stubs are referenced, parameters go through the marshaling process, and objects are tossed around the network.
Considerations of performance, practicality, and typical usage in the field resulted in the introduction of local interfaces in the EJB 2.0 specification. As noted, prior terminology referred to the home interface and the remote interface; at this point, depending on which approach is used, local interface and local home interface or remote interface and remote home interface are better terms. Either of the local home or remote home interfaces is referred to as the home interface; either of the local or remote interfaces is referred to as the component interface. This tutorial refers to the interfaces in these terms and uses these conventions for names.
When using J2EE technologies, it is normal to focus on distributed, or remote, beans, but you should keep the local option in mind, when applicable. It may be surprising to learn that a bean can have local interfaces, remote interfaces, or both. However, the client must write to a specific (that is, local or remote) interface. There are some issues to keep in mind when using local interfaces:
Beanは同じVMで実行する必要があります。結局のところ、ローカルです。リモートインターフェースやオブジェクトの場合のように、パラメーターはコピーされるのではなく、参照によって送信されます。予期しない副作用により、この区別を無視し、それに応じてコーディングしない場合の結果通常、ローカルアクセスとリモートアクセスのどちらを使用するかは、次の影響を受けます。
クライアントのタイプ—クライアントが常にWebコンポーネントまたは別のBeanであると予想しない限り、リモートアクセスを選択します。
Beanが密結合であるか疎結合であるか— Beanが相互に依存し、頻繁に対話する場合は、ローカルアクセスを検討してください。
スケーラビリティ—リモートアクセスは本質的にスケーラブルであり、スケーラビリティが重要な要素である場合に使用する必要があります。 EJB 2.0仕様でのローカルインターフェースの出現により、ほとんどのソースは、エンティティBeanがほとんど常にローカルアクセスに基づいていることを推奨しています。ローカルインターフェイスを使用すると、非常にきめの細かいデータアクセスに関するほとんどのパフォーマンスの問題がなくなります。クライアントがリモートの場合、標準の設計パターンでは、クライアントはリモートインターフェースを使用してセッションBeanにアクセスします。セッションBeanは、エンティティBeanへの連絡役として機能します。セッションBeanは、ローカルインターフェースを介してエンティティBeanと通信します（パターンの観点から、この手法はセッションファサードと呼ばれ、リモートまたはローカルのコンテキストで実際に使用できます）。
あなたのビジネスがローカルのすべてのメソッドを必要とするとき、リモートクライアントにも公開する必要があると私は信じています。
- メソッドでローカルインターフェースを定義します。
- リモートインターフェイスを空にして、ローカルインターフェイスを拡張する
- ローカルにすべての実際のビジネスロジックとその他の実装がある
- リモートBeanの実装をローカルBeanの実装に委譲する
このアプローチは、同じインターフェースに対して@Localと@Remoteを実現するための回避策になる可能性があります。同じメソッドに、必要に応じてローカルで、必要に応じてリモートでアクセスでき、パフォーマンスのオーバーヘッドはありません。
これが私の考えです。誰かがこれを検証するためのあなたの考えを教えてください。
その理由は、EJBのインターフェースを介してアクセスするためです。このようにして、リモートインターフェースを使用する場合は値でパラメーターを渡し、ローカルインターフェースを使用する場合は参照でパラメーターを渡します。そして、なぜあなたはこの振る舞いを知っていますか？それは理にかなっています。おそらく、リモートアプリケーションがビジネスオブジェクトにアクセスしたい場合や、参照渡しがネットワークの待ち時間を短縮するためです。注意：リモートアクセスには、オブジェクトをバイトストリームに変換するプロセス（マーシャリング）と、バイトストリームをオブジェクトに変換するプロセス（アンマーシャリング）が含まれます。この追加のステップ（マーシャリングとアンマーシャリング）により、アプリケーションのパフォーマンスが低下します。