読者です 読者をやめる 読者になる 読者になる

スケのブログ

Java, Java EE, OpenAMなどの情報を記述していきます。

StackoverflowのEJB's - when to use Remote and/or local interfaces?を翻訳

間違い指摘歓迎します!

質問

JavaEE初心者です。LocalインターフェースとRemoteインターフェースの概念について学んでいます。この概念の大きな利点は拡張性が高くなることだと思っています。つまり、様々なコンポネントを様々なサーバにデプロイすることができるという考えです。
RemoteとLocalインターフェースはどこでどのような役割を担うのでしょうか?様々なコンポネントを様々なサーバに配置するためにRemoteインターフェースが使用されるのでしょうか?アプリが一つのサーバだけに配置される場合にLocalインターフェースが使用されるのでしょうか?
もし、私の解釈が正しいのであれば、新しいアプリを開発するときLocalインターフェースかRemoteインターフェースのどちらをどのように選択すればよいでしょうか?アプリでのトラフィック量はどのくらいになりますか?(?)
Localインターフェースから使用し始め、徐々にRemoteインターフェースへアップグレードを行うのでしょうか?

回答、助言ありがとうございます。

回答

JavaEE初心者です。LocalインターフェースとRemoteインターフェースの概念について学んでいます。

初期バージョンのEJB定義では、EJBはRemoteコンポネントとして使用し、起動にはRMIを使用し、Remoteから呼び出す方法を想定していました。
all the overhead it implies (a network call and object serialization for every method call)(?)
たとえEJBコンテナとクライアントが同じ仮想マシンに併置するときであっても、EJBクライアントはこのパフォーマンスへの代償を払わなければなりませんでした。

後ほど、サン・マイクロシステムズは、ほとんどの業務アプリが実際はEJBを分散化していないということを理解しました。そこで、EJBコンテナと同じJVMに併置されているEJBクライアントが、RMIの使用やそれに関するオーバーヘッドを回避して直接メソッドを起動してEJBを呼び出すという概念をEJB2.0に修正定義しました。

この概念の大きな利点は拡張性が高くなることだと思っています。つまり、様々なコンポネントを様々なサーバにデプロイすることができるという考えです。

Java EEのは拡張できます。しかし、拡張するということは必ずしもコンポーネントを分散化するという意味ではありません。Web層とEJB層を分離することなく、クラスター上のWebとEJBアプリケーションを実行することができます。

様々なコンポネントを様々なサーバに配置するためにRemoteインターフェースが使用されるのでしょうか?アプリが一つのサーバだけに配置される場合にLocalインターフェースが使用されるのでしょうか?

上記は次のように言い換えることができます:EJBクライアントがEJBコンテナと同じJVMに存在しない場合(これは単一のサーバ/JVMのみを使用するという意味ではないです)、Remoteインターフェースを使用する

(...) Localインターフェースから使用し始め、徐々にRemoteインターフェースへアップグレードを行うのでしょうか?

Localインターフェースから開始すべきであると思います。そして、すでに示唆した通り、Remoteインターフェースへ変更することは必須ではありません。(併置構造をクラスタ化することができます)(?)

下記のリソースを確認することをお勧めします。( 上2つはかなり古いが、関連性があります。下2つはより最近のです)

リソース

Specification Release Review by Tyler Jewell
Under the Hood of J2EE Clustering by Wang Yu
Scaling Your Java EE Applications by Wang Yu
Scaling Your Java EE Applications -- Part 2 by Wang Yu


http://stackoverflow.com/questions/3807662/ejbs-when-to-use-remote-and-or-local-interfaces