JSR220(EJBCore)3.2.3.ローカルとリモートクライアントビューの選択
ここではエンタープライズビーンとしてローカルアクセスとリモートアクセスのどちらを使用すべきか決定する方法について述べます。
- リモートプログラミングモデルは、デプロイされた環境におけるコンポーネントの分配(配置)に関してロケーション独立性と柔軟性を提供します。
- リモート呼び出しは値渡しを意味します(引き起こします)。このsemanticsのコピーは呼び出し元と呼び出し先の間の階層分離を提供します。そしてデータの不正な(? nadvertant訳無し)変更を防ぎます。クライアントとビーンはこのパラメータコピーを想定してプログラミングされるべきです。
- リモート呼び出しは潜在的に高価(expensive)です。これはネットワーク遅延やクライアントやサーバソフトウェアスタックのオーバーヘッド、引数コピーなどを引き起こします。リモート呼び出しは典型的に、クライアントとビーン間で少ないインタフェースを用いた粒度の荒い(coarse-grained)マナーでプログラミングされます。
- リモート呼び出しにおいてパラメータとして引渡されるオブジェクトはserializableでなければなりません。
- EJB2.1とそれ以前のリモートホームインタフェース及びリモートコンポーネントインタフェースが使われている場合、リモートタイプを狭めるためにはJava言語のキャストではなくjavax.rmi.PortableRemoteObject.narrowを使用する必要があります。
- リモート呼び出しは、ローカル呼び出しでは予期しなかったコミュニケーションつまり他のサーバによるリソースの使用のためにエラーケースを引き起こす可能性があります。EJB2.1とそれ以前の利ほーとホームインタフェース及びリモートコンポーネントインタフェースを使用している場合、クライアントはjava.rmi.RemoteExceptionをハンドリングする明確な プログラミングを行わなくてはいけません。
- リモートプログラミングモデルのオーバーヘッドのゆえに、比較的粒度の荒いコンポーネントアクセスのために典型的に使われるでしょう。
- ローカル呼び出しは参照渡しを意味します(引き起こします)。クライアントとビーンは参照渡しsemanticsに依存して(信頼して)プログラミングされるでしょう。例えば、クライアントはビーンに引渡し、ビーンを通過して変化させたい大きなドキュメントを持っているかもしれません。ローカルプログラミングモデルにおいては状態の共有が可能です。一方、ビーンがデータ構造をクライアントへ戻したいけれどもクライアントが変化させてしまいたくない場合、ビーンはデータを戻す前にそのデータ構造を明確にコピーしなくてはなりません。他方リモートプログラミングモデルではシステムがコピーしてくれるのでビーンはコピーしなくてもよいのです。
リモートクライアントとエンタープライズビーンの結びつきはリモートビジネスインタフェースまたはリモートコンポーネントインタフェースを通してコンテナの呼び出しオーバーヘッドを軽減させることができますが、このような呼び出しはローカルインタフェースを用いた呼び出しよりも効果が少ない(というのも結びつきにおけるどんな最適化も透過的であるべきだから)ことに注意すべきです。
このローカル及びリモートのプログラミングモデルの選択は、Beanプロバイダがエンタープライズビーンをデプロイする際に行うデザイン上の決定です。
エンタープライズビーンとしてリモートクライアントビューとローカルクライアントビューの両者を提供することが可能な場合、より典型的な片方を提供することでしょう。
