 |
4.では，エンタプライズJavaBeans規定の概要について説明する。
エンタプライズJavaBeansは，コンポネントを基本とした分散計算の体系とする。 エンタプライズビーンは，分散トランザクション指向の企業アプリケーションのコンポネントとする。
エンタプライズビーンの本質的な特徴は，次のとおりとする。
エンタプライズBean体系は非常に柔軟であり，次のような部品を実装できる。
遠隔からアクセス可能なコンポネントであるエンタプライズビーンは，比較的粗粒度のビジネスオブジェクトを意図している(例えば，注文書，従業員記録)。 細粒度オブジェクト(例えば，注文書の行項目，従業員の住所)は，遠隔からアクセス可能なエンタプライズビーンコンポネントよりも，局所的にアクセス可能なエンタプライズビーン又はエンタプライズビーンの依存クラスとしてモデル化する方がよい。
エンタプライズJavaBeans体系によって定義される状態管理プロトコルは単純だが，エンタプライズBean開発者にBeanの状態管理における多大な柔軟性を提供する。
4.2では，エンタプライズJavaBeans契約の概要について説明する。 この契約は，本規定の後の章で詳細に述べる。
クライアントビュー契約は，クライアントとコンテナとの間の契約とする。 このクライアントビュー契約は，エンタプライズBeansをコンポネントとして使用するアプリケーションに対して一様な開発モデルを提供する。 この一様なモデルによって，より高水準の開発ツールの使用が可能となり，コンポネントの再利用化がさらに進む。
エンタプライズビーンのクライアントは，同一又は別のコンテナの中で別のエンタプライズビーンとして配備できる。 又は，それはアプリケーション，アプレット，又はサーブレットのような任意のJavaプログラムとすることができる。 エンタプライズビーンのクライアントビューは，JavaTMプログラム言語で記述されていないCORBAクライアントのような非Javaクライアント環境に割り当てることもできる。
セション又は実体ビーンのクライアントは，遠隔クライアント (remote client)でもよく，又はそのクライアントは局所クライアント (local client)でもよい。
エンタプライズビーン遠隔クライアントビューは遠隔操作できる，つまり，局所プログラム及び遠隔プログラムは，同じ遠隔ビューを使用するエンタプライズビーンにアクセスできる。 この遠隔クライアントビューのインタフェースを実装したオブジェクトは，遠隔Javaオブジェクトであり，クライアントから遠隔オブジェクト呼出しの標準JavaTM API経由でアクセス可能とする[3]。
エンタプライズビーンに遠隔クライアントビュー及び局所クライアントビューの両方を提供することができるが，通常はどちらか一方だけが提供される。
エンタプライズBean提供者及びコンテナ提供者は，エンタプライズビーンのクライアントビューを作成するために協力する。 局所クライアントビューと遠隔クライアントビューの両方は，次を含む。
遠隔クライアントビューはさらに次を含む。
エンタプライズビーンのホームインタフェースは，実体ビーンのホームビジネスメソッド(ある特定のビーンインスタンスに固有でないビジネスメソッド)と同様に，同じ型のEJBオブジェクト(例えば，それらが同じエンタプライズビーンによって実装されている)を作成，削除，及び見つけるためにクライアントにメソッドを定義する。 ホームインタフェースは，Bean提供者により指定され，コンテナは，そのホームインタフェースを実装したクラスを作成する。 遠隔クライアントビューを提供するエンタプライズビーンは，遠隔ホームインタフェースを提供し，局所クライアントビューを提供するエンタプライズビーンは局所ホームインタフェースを提供する。 遠隔ホームインタフェースは，jvax.ejb.EJBHomeインタフェースを拡張し，局所ホームインタフェースは，javax.ejb.EJBLocalHomeインタフェースを拡張する。
クライアントは，標準のJava命名ディレクトリインタフェースTM (Java Naming and Directory InterfaceTM，以降JNDI。) APIを通じて，エンタプライズBeanホームインタフェースを配置することができる。
EJBオブジェクトは，エンタプライズビーンのコンポネントインタフェース経由でアクセス可能とする。 このコンポネントインタフェースは，クライアントが呼び出すことができるビジネスメソッドを定義する。 このコンポネントインタフェースは，Bean提供者によって指定され，コンテナはそのコンポネントインタフェースを実装したクラスを作成する。 このコンポネントインタフェースは，遠隔インタフェースか局所インタフェースのどちらかとする。 遠隔インタフェースは，javax.ejb.EJBObjectインタフェースを拡張する。 javax.ejb.EJBObjectインタフェースは，クライアントがEJBオブジェクトの識別性にアクセスして，そのEJBオブジェクトの永続的なハンドルを作成できるようにするための操作を定義する。 局所インタフェースは，javax.ejb.EJBLocalObjectインタフェースを拡張する。 javax.ejb.EJBLocalObjectインタフェースは，クライアントがEJBオブジェクトの識別性にアクセスできるようにするための操作を定義する。
各EJBオブジェクトはホームの中に生存し，そのホームの内部に一意な識別性をもつ。 セションビーンについては，コンテナが各セションオブジェクトに新しい一意な識別子を生成することに責任をもつ。 この識別子は，クライアントには公開されない。 しかし，クライアントは二つのオブジェクト参照が同じセションオブジェクトを参照しているかを検査してもよい。 実体ビーンについては，Bean提供者が実体オブジェクト生成時に主キーを提供する責任を持ち[1]，コンテナはその主キーをそのホームの内部の実体オブジェクトを識別するために使用する。 クライアントは，実体オブジェクトの主キーをjavax.ejb.EJBObjectインタフェース又はjavax.ejb.EJBLocalObjectインタフェース経由で取得してもよい。 このクライアントは，二つのオブジェクト参照が同じ実体オブジェクトを参照しているかどうかを検査してもよい。
遠隔オブジェクトは，エンタプライズビーンのメタデータインタフェースを取得してもよい。 このメタデータインタフェースは，一般的にエンタプライズビーンの動的呼出しを実行することが必要なクライアントによって使用される(エンタプライズクライアントビューを提供するクラスがそのクライアントプログラムがコンパイルされた時に利用できない場合に，動的呼出しを必要とする)。
メッセージ駆動ビーンは，ホームインタフェース又はコンポネントインタフェース，さらにこのセションの意味のクライアントビューを持たない。 クライアントは， 標準のJNDI APIを使用してメッセージ駆動ビーンに配送されるメッセージを送信するJMS Destinationを配置することができる。
4.2.2は，エンタプライズBeanとそのコンテナの間の契約を記述する。 この契約の主な必用条件は，次の通りとする(これは本規定によって定義される必用条件の部分リストにすぎない)。
ejb-jarファイルは，EJBツールが宣言情報と共にエンタプライズBeansをパッケージ化するために使用する標準フォーマットとする。 ejb-jarファイルは，アプリケーション組立て及び配備ツールによって処理されることを意図している。
ejb-jarファイルは，Bean提供者とアプリケーション組立て者，及びアプリケーション組立て者と配備者の間で使用される契約とする。
ejb-jar契約は，次を含む。
図4.1は，エンタプライズJavaBeans契約を示す。
|
図4.1は，コンテナ外部で実行する遠隔クライアントだけを示すが，同じコンテナに配備されたエンタプライズBeansである局所クライアント及び遠隔クライアントにもクライアントビューAPIが適用できることに注意。
エンタプライズJavaBeans体系は，エンタプライズBeansの三つの型を定義する。
通常のセションオブジェクトは，次の特性をもつ。
通常のEJBコンテナは，数多くのセションオブジェクトを並行に実行するために，拡大可能な実行環境を提供する。
セションビーンは，有状態を意味する。 EJB規定は，セションビーンの特別な場合として無状態セションビーンも定義する。 有状態(正規)セションビーンと無状態セションビーンの間には，APIに少し違いがある。
通常の実体オブジェクトは，次の特性をもつ。
通常のEJBコンテナ及びEJBサーバは，並行して活動する数多くの実体オブジェクトに対して，拡大可能な実行環境を提供する。
通常のメッセージ駆動オブジェクトは，次の特性をもつ。
通常のEJBコンテナは，数多くのメッセージ駆動オブジェクトを並行に実行するために，拡大可能な実行環境を提供する。
複数の製造元からのシステムを含むEJB環境の相互運用性を確保するために，EJB 2.0規定は， セションBeans及び実体BeansのJ2EEクライアントからの遠隔ホーム及び遠隔インタフェース経由の遠隔呼出しに対して，CORBA/IIOPを基にしたプロトコルのサポートに適合した実装を要求する。 実装は，IIOP以外に他の遠隔呼出しプロトコルをサポートしてもよい。
19.は，EJB 2.0の分散サポートと相互運用性要件を要約する。
[1] ある状況下では，主キー型を配備時に規定することができる (10.8.3を参照)。