用語集のリンク: A - B - C - D - E - F- H - I - J- L - M - P - R- S
A
Attached Object - EJB 3.0 - エンティティ Bean のインスタンスを指す。データは、現在エンティティマネージャーが管理するデータベースから抽出。
B
Bean クラス - EJB 1.x, EJB 2.x, EJB 3.0 - Bean クラスは、ビジネスロジックのインプリメンテーションを保持する EJB コンポーネントのアーティファクト。オブジェクト指向の表記法では、このクラスは実装クラス（CustomerImpl など）とみなされる。EJB では、Bean クラスという用語が使われる（CustomerBean など）。
Bean-管理による持続性- EJB 2.x, EJB 3.0 - エンティティ Bean の 2 つの持続性メカニズムのうちの 1 つ。エンティティ Bean では、Bean 管理による持続性（BMP）を利用して、開発担当者は持続性ロジックを実現する必要がある。これは、エンティティ Bean の持続的な属性を持続性層に適切にマッチングさせる必要があるということを主に意味している。そのためには、Bean クラスの持続性層（JDBC を利用したデータベースや JCA を利用したレガシーシステムなど）のアクセスロジックを実現する必要がある。
- EJB コンテナは、事象の発生時期を決定する。
- 開発担当者は発生する事象の内容を決定する。
注意: EJB 3.0 では、Bean 管理による持続性は、現在は存在しない。
BMP - EJB 2.x, EJB 3.0 - Bean 管理による持続性（Bean-managed Persistence）を表す略語。
ビジネスインターフェイス- EJB 3.0 - ビジネスインターフェイスには、EJB コンポーネントのビジネスメソッドの宣言が記述されている。また、EJB 3.0 における POJI タイプのインターフェイスを表す用語でもある。EJB 2.x のコンポーネントとは逆に、これらのビジネスインターフェイスは javax.ejb.EJB[Local]Object を拡張することはできない。EJB コンポーネントのローカルのビジネスインターフェイスとリモートのビジネスインターフェイスに、同一のビジネスインターフェイスを使うことはできない。
メッセージ駆動型型 Bean には、使用する電子通信のタイプ（javax.jms など）に応じた（ビジネス）インターフェイスが必要である。EJB 3 では、メッセージ駆動型型 Bean のこのインターフェイスもビジネスインターフェイスと呼ぶが、これは機能的なインターフェイスというよりも技術的なインターフェイスである。EJB 3 のエンティティでは、ビジネスインターフェイスを示す必要はない。
C
コールバックメソッド - EJB 2.x, EJB 3.0 - With EJB 2.x では、Bean のタイプ（javax.ejb.SessionBean、javax.ejb.MessageDrivenBean または javax.ejb.EntityBean）に応じて、Bean クラスでコールバックインターフェイスを実装する必要がある。まず、これらのインターフェイスによって、自分の所有している EJB のタイプがわかる。次に、これらのインターフェイスがコールバックメソッドを宣言し、EJB コンテナがそれを呼び出して EJB コンポーネントのライフサイクルを管理する。開発担当者は、Bean クラスにおいて、インターフェイスで宣言したコールバックメソッドを実装する必要がある。
EJB 3.0 では、Bean クラスが上述のコールバックインターフェイスを実装する必要はなくなった。開発担当者は、コールバックメソッドの実装を強要されないため、開発に要する時間が短縮され、開発の労力も軽減される。定義付けされたコメントの集合があるので、今でも EJB コンポーネントのライフサイクル管理に飛び込むことができる。任意のメソッドをマークできるため、使用したコメントに応じて、定義した時間ポイントで実行することができる。このコメントは、すべてのタイプの EJB で使用できる。@PostConstruct、@PreDestroy、@PostActivate、@PrePassivate の各コメントは、セッション Bean とメッセージ駆動型 Bean に適用できる。EJB 3 のエンティティについては、@PrePersist、@PostPersist、@PreRemove、@PostRemove、@PreUpdate、@PostUpate、@PostLoad といったコメントが適用できる。
CMP - EJB 2.x, EJB 3.0 - コンテナ管理による持続性（Container-managed Persistence）の略語。
コンポーネントインターフェイス - EJB 1.x, EJB 2.x, EJB 3.0 - コンポーネントインターフェイスとは、EJB コンポーネントのビジネスインターフェイスのこと。ロジカルインターフェイス（同一のプロセス内でしかアクセスできない --> 「ローカルインターフェイス」を参照）とリモートインターフェイス（マシン全体とプロセスの範囲全体でアクセス可能 --> リモートインターフェイスを参照）の 2 つの形態がある。コンポーネントインターフェイスは、javax.ejb.EJB[Local]Object を拡張できる必要がある。
例外による設定（Configuration by Exception） - EJB 3.0 - 例外による設定は、EJB 3.0 で導入された手法。この手法の目的は、EJB コンポーネントの設定や開発に要する時間と労力を短縮、軽減することである。
開発担当者は、例外的なケース以外では、EJB コンポーネントに設定やランタイム操作情報を与えないようにすること。例外的なケースとは、目的の動作が特定のタイプの EJB コンポーネントの定義済み動作や所定の標準動作と異なる場合である。目的は、EJB コンポーネントの一般的に予想される動作の設定パラメータや EJB コンテナに対する要件を明示的に示す必要性を軽減することである。
具体的に言うと、EJB 3.0 では、EJB コンポーネントに数多くの機能や動作がデフォルトであらかじめ設定されているということである。このデフォルトの動作は、EJB コンポーネント（やそれぞれの EJB タイプ）の一般的な用途のほとんどをカバーするものである必要がある。標準動作が要件プロファイルを満たしていない場合は、開発担当者はこのようなデフォルトの値や標準動作を簡単に無効にすることができる。
コンテナ管理による持続性（Container-Managed Persistence） - EJB 2.x, EJB 3.0 - エンティティ Bean の 2 つの持続性メカニズムのうちの 1 つ。コンテナ管理による持続性（CMP）を利用している場合は、エンティティ Bean と持続性層を同期させるためのコードを記述する必要はない。コードは、アプリケーションサーバーのツールが生成する。開発担当者が行なう作業は、持続属性とさまざまなエンティティ Bean の関係を宣言することだけである。実行時の同期は、EJB の特別な部分（いわゆる「持続性マネージャー」）が実行する。
D
DD - EJB 1.x, EJB 2.x, EJB 3.0 - 配備記述子（Deployment Descriptor）を表す略語。
分離エンティティ（Detached Entity）- EJB 3.0 - 「分離オブジェクト（Detached Object）」を参照。
分離オブジェクト（Detached Object）- EJB 3.0 - EJB 3 のエンティティのインスタンスを指す。現在は、持続されたり取得されたりした持続性の状況とは関連付けられていない。したがって、現在は、データとデータベースの同期はできない。このようなオブジェクトは、エンティティマネージャーで管理されない。アプリケーションは現在でも、分離オブジェクトを使うことができる。利用可能な状態にアクセスして変更を実行することはできるが、変更は追跡されない。
分離オブジェクトは、さまざまな状況から発生する可能性がある。たとえば、EJB 3 エンティティのシリアル化を行なっている場合に発生する。シリアル化によって、EJB 3 エンティティは分離オブジェクトになる。
依存性の注入（Dependency Injection） - EJB 3.0 - 依存性の注入（DI）という用語は、制御パターンの逆転の特殊な形態を表す。Martin Martin Fowler がこのことばを作った（http://martinfowler.com/articles/injection.html を参照）。現在の軽量なコンテナやフレームワークでの制御の逆転の使われ方は、オブジェクトやクラスへの参照の注入として特徴付けられる傾向があるからである。
DI を EJB 3 に導入した理由は、EJB コンポーネントがリソースを容易に参照できるようにするためである。現在、EJB コンポーネントには、JNDI API コードは不要である。ただし、ユーザーは JNDI API コードを自由に使用できる。
EJB テクノロジーにおける DI とは、開発担当者が JNDI API を利用したリソースの参照を行なうためにコードを実装する必要がなくなることを意味する。その代わり、開発担当者は、EJB コンポーネントのどちらかのインスタンス変数または setter メソッドにコメントを付けたり、対応する XML でこのような依存性の指定を宣言したりすることによって、コンテナのリソースの参照を要求する。そして、実行時にコンテナはリソースに対して必要なまたは要求される参照を EJB コンポーネントに注入してから、EJB コンポーネントのメソッドの 1 つを実行する。つまり、EJB コンポーネントは周囲を取り囲むコンテナを積極的に要求してリソースの参照を求めなくなったが、コンテナによってそれらを注入してもらうようになったということである。
コメントの使用は、XML を使用するよりも格段に便利であり、EJB 3 に好ましい変種になる。ここでは、DI は JNDI コンテキストにアクセスして参照を取得するための単なる簡易化メカニズムである。
配備記述子（Deployment Descriptor）- EJB 1.x,EJB 2.x, EJB 3.0 - 配備記述子は、EJB コンポーネントを生成し実行するためのコンパイル情報やランタイム情報を記述した XML ファイルである。これは、宣言プログラミングと呼ばれている。開発担当者は、コードを 1 行も記述せずに、単に配備記述子で特定のキーワードを宣言することによって、特定の機能のそれぞれの動作を実装するからである。たとえば、EJB コンポーネントの処理動作はこのように制御される。
E
Eager Load - EJB 3.0 - eager load は、Java Persistence API で定められた 2 つのフェッチ戦略の 1 つである。簡単に言うと、eager load は、EJB 3.0 のエンティティが直ちにデータベースから完全に読み込まれ、EJB 3.0 のエンティティのインスタンスの該当する属性に書き込まれることを意味する。EJB 3.0 エンティティ内の参照されているすべての持続エンティティ（EJB 3.0 エンティティまたは埋め込み可能なオブジェクト）も同様にロードされる。実際に、eager load の実装の実際の機能は、ベンダーのそれぞれの実装によって異なる。
eager load の利点は、データが一気に 1 回でフェッチされることである。アプリケーションが属性にアクセスすると、データがすでにそこにある。大規模な持続オブジェクトのネットやオブジェクトのツリーで eager load を使うことの欠点は、ロード時間が長くなったり、メモリの消費が大きくなったりする可能性があることである。
EJB - EJB 1.x, EJB 2.x, EJB 3.0 - .Enterprise JavaBeans を表す略語。JAVA EE プラットフォームのサーバーサイドコンポーネントの名称。
EJB 3.0 エンティティ- EJB 3.0 - エンティティは、軽量の持続ドメインオブジェクトである。Java Persistence API では、これを持続的なエンティティと呼んでいる。後者の理由は、Java Persistence API は現在では Java EE だけでなく、Java SE でも使用できないためである。
EJB コンポーネント- EJB 1.x, EJB 2.x, EJB 3.0 - EJB コンポーネントは、EJB のすべてのタイプを対象とした一般的な用語である（--> 「EJB タイプ」を参照）。
EJB タイプ - EJB 1.x, EJB 2.x, EJB 3.0 - EJB 2.x において、EJB の仕様では以下の 3 つの EJB のタイプを定めている。
- セッション Bean（ステイトフルとステイトレスという 2 つの特性がある）
- メッセージ駆動型 Bean
- エンティティ Bean
EJB 3 では、以下の EJB タイプが定められている。
- セッション Bean（ステイトフルとステイトレスという 2 つの特性がある）
- メッセージ駆動型 Bean
- EJB 3 エンティティ
注意: EJB 3 では、セッション Bean とメッセージ駆動型 Ben は一般的にエンタープライズ Bean と呼ばれる。軽量の持続ドメインオブジェクトは、明示的に EJB 3 エンティティまたは持続エンティティと呼ばれる。
EJB QL - EJB 1.x, EJB 2.x - EJB 問い合わせ言語（EJB Query Language）を表す略語
EJB 問い合わせ言語 - EJB 1.x, EJB 2.x - EJB QL は、Enterprise JavaBeans コンポーネントアーキテクチャの問い合わせ言語である。SQL とよく似ているが、オブジェクトに焦点を当てている。EJB 3.0 で強化されたが、EJB 3.0 では、Java Persistence 問い合わせ言語（Java Persistence QL）と呼んでいる。
埋め込み可能なオブジェクト（Embeddable Object） - EJB 3.0 - EJB 3 エンティティではないため持続的な ID を持たない POJO は、属性として EJB 3 エンティティに埋め込むことができる。このようなオブジェクトは、埋め込み可能なオブジェクトと呼ばれる。このような埋め込み可能なオブジェクトの属性は、取り囲んでいる EJB 3 エンティティと関連付けられているデータベーステーブルからのデータで埋められている。
たとえば、EJB 3 エンティティを持つあるデータベーステーブルとこのエンティティによって埋め込まれた POJO をマッピングして、非正規化されたデータベーステーブルをオブジェクトネットに投影することもできる。
@Entity
@Table(name="CUSTOMER")
public class Customer implements java.io.Serializable {
private int id;
private Address address; private String lastName; private String firstName;
public Customer(String lastName, String firstName,String street, String city) { this.address = new Address(street, city); this.lastName= lastName; this.firstName = firstName; } ... @Embedded
@AttributeOverrides(
@AttributeOverride(name="street", column=@Column(name="STREET")),
@AttributeOverride(name="city",column=@Column(name="CITY")) })
public Address getAddress()
return address;
}
public void setAddress(Address address) {
this.address = address;
}
@Column(name="LASTNAME")
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
...
Embeddable Object
@Embeddable public class Address implements java.io.Serializable { private String street; private String city; ... }
エンタープライズ - EJB 3 - より一般的なレベルでは、セッション Bean とメッセージ駆動型 Bean はエンタープライズ Bean である。EJB 3 エンティティは、エンタープライズ Bean とは呼ばれないことに注意。この一般的な用語は、EJB 3 エンティティについては使用できない。EJB 3 エンティティは、Java SE 環境でも使用できるからである。
エンティティ - EJB 2.x - EJB 2.x では、持続的なエンティティの EJB タイプはエンティティ Bean と呼ばれる。
エンティティマネージャー - EJB 3.0 - Java EE と Java SE の新しい要素。EJB 3.0 で導入されたもの。（JDO やHibernate と同様）中央の持続性マネージャー。エンティティマネージャーには、エンティティ（POJO）の持続性マッピングを行なう役割がある。データベースに持続エンティティを作成し、それをロード、保存、削除、検索する。また、エンティティへの同時アクセスの一貫性（同時処理）も管理している。
F
フェッチ戦略- EJB 3.0- EJB 3.0 で指定された JAVA PERSISTENCE API では、遅延ロードと eager load の 2 つのフェッチ戦略が定められている。Hibernate やTopLink のような持続性プロバイダーと比べると、この 2 つの戦略とその特性は、単なるごくわずかなオプションである。おそらく、将来の仕様では、フェッチ戦略の詳細化や強化が計画されるだろう。
ほとんどの場合、Java Persistence API では、eager load 戦略がデフォルトとしてあらかじめ設定されている。遅延ロードは、開発担当者が明示的に記述しているとき以外は使用されない。持続性プロバイダーランタイム（Hibernate など）は、eager load メカニズムの実装と提供を強要されている。遅延ロードの場合は、持続性プロバイダーランタイムの実装者には、単なるヒントとなる。遅延ロードメカニズムの実装方法については、EJB 3 の仕様ではこれ以上の詳細は定めていない。現時点では、遅延ロードメカニズムの厳密な実装については、持続性プロバイダーランタイムの実装者に任されている。したがって、分散アーキテクチャやさまざまなベンダーによる技術実装を起因とする相互運用性の欠如など、多くのリスクが伴う。
H
Home Interface - EJB 1.x, EJB 2.x - ホームインターフェイス - EJB 1.x、EJB 2.x - EJB コンポーネントのホームインターフェイスには、EJB コンポーネントのインスタンスを作成、削除、ロードするメソッドが搭載されている。クライアントは、マシン全体やプロセス範囲で、EJB コンポーネントのインスタンスを直接作成、削除、ロードすることができないため、それぞれの EJB コンポーネントのホームインターフェイスを使わざるをえない。ホームインターフェイスによって、それぞれの機能を実現する。ホームインターフェイスを使うことで、EJB コンポーネントとクライアントの分離が実現する。ホームインターフェイスは、設計パターン「Factory Method」を表している。ホームインターフェイスには、以下の 2 つの特色がある。
- マシン全体とプロセス範囲でリモートアクセスを実現するリモートホームインターフェイス(サイト･英語)
- プロセス間の呼び出しによってローカルアクセスを実現するローカルホームインターフェイス(サイト･英語)
EJB 3.0 では現在、セッション Bean のホームインターフェイスは必須ではない。つまり、実装する必要はないということである。しかし、仕様では、ホームインターフェイスがなくなるとは定めていない。現在、EJB 3 エンティティにはホームインターフェイスは実装されていない。
I
インターセプター - EJB 3.0 - EJB 3.0 では、長期にわたってインターセプターが幅広く使われている CORBA を基盤としたシステムと同様に、ビジネスメソッドに対する呼び出しをインターセプトすることができる。必要に応じて、パラメータの解析や操作ができ、ビジネスメソッドの実行を有効にも無効にもできる。インターセプターメカニズムによって、局面指向のプログラミングは、少なくとも初期段階では EJB を基盤とした開発になる。インターセプターを利用すると、技術的な機能（ログ記録、追跡、セキュリティなど）をトランスペアレントにビジネスメソッドにインターレースできる。インターセプターの開発者は、動作中のインターセプターが EJB に対するメソッドの呼び出しをインターセプトするときに実行される任意のコードを実装できる。
制御の逆転（Inversion of Control）- EJB 3.0 - 制御の逆転（IoC）は、フレームワークの一般的な特性であり、一般的にはハリウッド原理（「私たちを呼び出さないでください。私たちがあなたを呼び出します」）と言い換えられる。これは、プログラム実行中の責任は、コンポーネントではなくフレームワークにあるということを表している。つまり、コンポーネントが構築されているフレームワークは、コンポーネントが特定のコールバックメソッドを実装していることをコンポーネントに要求するということである。次に、フレームワークは実行時にコールバックメソッドを利用して、情報を注入したり、決定された動作を引き起こしたりする。
EJB 3.0 においては、「IoC」と「依存性の注入」は、細かい部分においては意味論的な相違はあるが、この 2 つのことばは同義語として使われている（「依存性の注入」を参照）。EJB 3.0 で使われているのは、特殊な形態の「制御の逆転」であり、「依存性の注入」と呼ばれている。
J
Java Persistence API - EJB 3.0 - Java Persistence API は、EJB 3.0（Java コミュニティプロセスの JSR220）で開発されたものである。Java Persistence API は、Java EE と Java SE の標準的な持続性モデルになる。Java Persistence API の重要な特性は、任意の POJO に使えること、そして EJB コンポーネントだけに限定されていないことである。このように、Java Persistence API は、アプリケーションで EJB コンポーネントを使う必要がない開発担当者も利用することができる。Hibernate、TopLink、JDO、EJB 持続性ソリューションのトップクラスの持続性の専門家が、Java Persistence API の開発に関わっていた。
Java Persistence QL - EJB 3.0 - Java Persistence問い合わせ言語（Java Persistence Query Language）を表す略語。
Java Persistence 問い合わせ言語 Language - EJB 3.0 - Java Persistence問い合わせ言語は、Enterprise JavaBeans コンポーネントアーキテクチャの問い合わせ言語。SQL と似ているが、オブジェクトに焦点を当てた言語である。EJB QL と比較すると、Java Persistence問い合わせ言語は広範囲にわたって強化されている。Java Persistence問い合わせ言語には、EJB QL に備わっていなかった多くの機能が実装されている。EJB QL よりも格段に豊富な機能を有し、Hibernate HQL と似ている点も少しある。
L
遅延ロード（Lazy Load）- EJB 3.0 - ほかの持続性ソリューションと同様、持続エンティティとその属性へのアクセスが実際に行なわれる場合、データベースの持続エンティティ（EJB 3.0 エンティティ）の持続的データを読み込む戦略を遅延ロードも指定している。遅延ロードのおかげで、マークされた属性やほかの持続エンティティとの関係は、このような属性や関係への専用アクセスが行なわれる場合は、データベースからちょうど間に合ってロードされる。遅延ロード実装の実際の機能は、ベンダーのそれぞれの実装によって異なる。
遅延ロードの利点は、属性や関係へのアクセスが行なわれる場合以外は、データがフェッチされないことである。したがって、メモリの消費が少なくなる。デメリットは、持続データのこのジャストインタイムのフェッチによって、アプリケーションの速度が遅くなる可能性があることである。
ローカルホームインターフェイス（Local Home Interface） - EJB 2.x - ローカル的なホームインターフェイスは、ローカルホームインターフェイスと呼ばれている。EJB コンポーネントのクライアントが同一のコンテナやプロセス内に存在する場合しか使われないため、いわゆる高速のホームインターフェイスである。リモートホームインターフェイスと同様、ローカルホームインターフェイスを使って EJB コンポーネントを作成、削除、ロードする。ローカルホームインターフェイスは、リモートホームインターフェイスよりも直線的である。これは、RMI 上で呼び出すことができず、ネットワーク上で配列したり、配列を解除したり、送信したりする機能がないためである。クライアントと EJB コンポーネントの間の通信はインプロセスであるため、リモートホームインターフェイスよりも高速である。ローカルホームインターフェイスは、リモートメソッドの呼び出しを受け取ることはできない。
EJB 3.0 では、セッション Bean のホームインターフェイスは必須ではなくなった。つまり、実装する必要はないということである。ただし、ホームインターフェイスがなくなったことは、仕様には明記されていない。現在、EJB 3 エンティティには、ホームインターフェイスは実装されていない。
ローカルインターフェイス - EJB 2.x, EJB 3 - ローカル通信のみ可能な、EJB コンポーネントのビジネスインターフェイス（EJB 3）またはコンポーネントインターフェイス（EJB 2.x）の技術的な変形体は、ローカルインターフェイスと呼ばれる。クライアントとコンポーネントの間のインプロセス通信のみを許可する。EJB コンポーネントにローカルインターフェイスのみが実装されていて、リモートインターフェイスが実装されていない場合、そのコンポーネントにはリモートアクセスはできない。
M
管理エンティティ・管理オブジェクト（Managed Entity/ Managed Object）- EJB 3.0 - 管理エンティティは、EJB 3.0 エンティティのインスタンスであり、現在持続性コンテキストに関連付けられているために、エンティティマネージャーに管理されている持続性 ID がある。
メッセージ駆動型 Bean（Message-driven Bean） -EJB 2.x, EJB 3.0 - メッセージ駆動型 Bean（MDB）を使って、J2EE や Java EE アプリケーションの非同期ワークフローを実現する。メッセージブローカのメッセージコンシューマである。MDB は、これらから非同期メッセージを受信して処理することができる。したがって、電子通信システムの場合、メッセージ駆動型システムは、メッセージエンドポイントの役割を果たす。
メッセージ駆動型 Bean は、ホームインターフェイス、コンポーネントインターフェイス（EJB 1.x、2.x）、ビジネスインターフェイス（EJB 3）を保持しない。注意: EJB 3 の仕様では、メッセージ駆動型 Bean にはビジネスインターフェイスも必要であるとしている。具体的には、このビジネスインターフェイスは、使用している特定の電子通信のタイプ（javax.jms など）に応じたインターフェイスである。EJB 3 では、メッセージ駆動型 Bean のこのインターフェイスもビジネスインターフェイスと呼ぶが、機能的なインターフェイスというよりも技術的なインターフェイスである。MDB には本当のビジネスインターフェイスが実装されていないため、メッセージ駆動型 Bean にはクライアント可視性がある。つまり、MDB には直接アドレスできないということである。
メタコメント- EJB 3.0 - メタコメントは、Java プログラミング言語に対する動的な言語拡張。JSR 175 とともに、JDK 5.0（a.k.a Java 1.5）に導入された。コメントによって、コンパイル時と実行時の両方で評価できる Java コードのメタ情報に適応できる。このようなメタ情報を利用して、コードを生成したり、オブジェクトや EJB コンポーネントの実行時の動作を操作したりできる。
マルチテーブルマッピング - EJB 3.0 - マルチテーブルマッピングとは、複数の物理的なデータベーステーブルにマッピングできる EJB 3.0 の能力を指す。EJB 2.x では、Bean 管理の持続性を利用して明示的にプログラミングしないかぎり、この機能は利用できない。EJB 3.0 では、EJB 3.0 エンティティは、データベースのテーブルを単純に 1 対 1 で表したものではない。むしろ、論理的なビジネスオブジェクトの技術的なラッパーであり、データは複数のテーブルに分散することができる。EJB 3.0 エンティティのコメント内では、該当するデータのソースとなるテーブルやフィールドを指定するだけでよい。XML でo/r マッピングを指定することも可能である。エンティティマネージャーは、実行時にリレーショナルモデルを解決し、データを EJB 3.0 エンティティに挿入する（イラスト参照）。
3 つのデータベーステーブルにマッピングされた EJB 3.0 エンティティ
@Entity
@Table(name="CUSTOMER")
@SecondaryTables({
@SecondaryTable(name="ADDRESS")
@SecondaryTable(name="TYPE") }) public class Customer implements java.io.Serializable { private int id; private String firstName; // from table "CUSTOMER" private String lastName; // from table "CUSTOMER" private String street; // from secondary table "ADDRESS" ... // Attribute from main table „CUSTOMER“
@Column(name="LASTNAME")
public String getLastName() { return lastName; } ... // Attribute from secondary table "ADDRESS"
@Column(name="STREET", table="ADDRESS")
public String getStreet() { return street; } ... // if no @Column annotation is specified, // it is assumed that column name equals attribute name public String getFirstName() { return firstName ; } }
P
持続性プロバイダーランタイム（Persistence Provider Runtime） - EJB 3.0 - 「持続性プロバイダーランタイム」という用語は、Java Persistence API の持続性実装のランタイム環境を指す。Java EE では、Java EE コンテナが持続性プロバイダーランタイムの場合もあり、統合された持続性が実装されたり、サードパーティ製の持続性プロバイダーの実装が統合されていたりする。Java SE では、独立したサードパーティの持続性プロバイダーの実装（Hibernate など）である。
平易な旧式の Java インターフェイス（Plain Old Java Interface）- EJB 3.0 - 2004 年に、機関紙やオンライン雑誌で使われ始めたことば。「平易な旧式 Java インターフェイス」ということばは、インフラなどの技術面に関連するコードで「汚されて」いないシンプルな Java インターフェイスを指す。この用語は、EJB 3.0 の世界にも導入された。EJB 3.0 の核となる考え方は、EJB コンポーネント（ここではビジネスインターフェイス）が、使い方およびマイクロアーキテクチャにおいて、複雑性が少なくなるため、ビジネスインターフェイスが、インフラや技術面に関するコードで「汚される」ことはないが、機能的なメソッドの宣言しか記述されていないということである。
平易な旧式の Java オブジェクト（Plain Old Java Object） - EJB 3.0 - 2004 年に、機関紙やオンライン雑誌で使われ始めたことば。「平易な旧式の Java オブジェクト（POJO）」ということばは、シンプルな Java クラスを指す（POJC と呼ぶべきかもしれない）。一般的には、もっと複雑なコンポーネントで発生するため、インフラなどの技術面に関するコードで「汚されて」いない。この用語は、EJB 3.0 の世界にも導入された。EJB 3.0 の核となる考え方は、EJB コンポーネント（ここではビジネスインターフェイス）が、使い方およびマイクロアーキテクチャにおいて、複雑性が少なくなるという考え方である。目的は、簡素化して、POJO として特徴付けできるようにすることである。
POJI - EJB 3.0 - 平易な旧式の Java インターフェイス（Plain Old Java Interface）を表す略語。
POJO - EJB 3.0 - 平易な旧式の Java オブジェクト（Plain Old Java Object）を表す略語
R
リモートホームインターフェイス - EJB 1.x, EJB 2.x - リモートホームインターフェイスによって、リモートのクライアントがネットワーク上で EJB のインスタンスを作成、ロード、削除することができる。クライアントは、RMI/IIOP プロトコルを使ってリモートメソッド呼び出しを行ない、リモートホームインターフェイスとやり取りを行なう。このやり取りは、インプロセス通信よりも低速で行なわれる。分散システムにおいて、ネットワークの任意のマシンに存在するクライアントに EJB が提供される場合に、リモートホームインターフェイスを使う必要がある。
EJB 3.0 では、セッション Bean のホームインターフェイスは必須ではなくなった。つまり、実装する必要がないということである。しかし、ホームインターフェイスがなくなったことは、仕様では明示されていない。現在、EJB 3 エンティティには、ホームインターフェイスは実装されていない。
リモートインターフェイス - EJB 1.x, EJB 2.x - EJB コンポーネントのビジネスインターフェイス（EJB 3）またはコンポーネントインターフェイス（EJB 1.x、2.x）の技術的な変形体で、リモート通信が可能なものをリモートインターフェイスと呼ぶ。EJB コンポーネントがリモートインターフェイスを実装している場合、ほかのプロセスのクライアントは、プロセス全体やマシンの範囲内で、コンポーネントを呼び出すことができる。この通信は、RMI/IIOP を使って行なわれる。クライアントと EJB コンポーネントが同じプロセスに存在し（クライアント自体が EJB コンポーネントの場合など）、クライアントがリモートインターフェイスを使っている場合でも、通信は RMI/IIOP を使って行なわれる。この場合、通信速度を不必要に低下するが、これはコンポーネントのローカルインターフェイスを使って改善でき、その結果性能が向上する。
S
SFSB - EJB 1.x, EJB 2.x, EJB 3.x - ステートフルセッション Bean（Stateful Session Bean）を表す略語。
SLSB - EJB 1.x, EJB 2.x, EJB 3.x - ステートレスセッション Bean（Stateless Session Bean）を表す略語。
原文はこちらです：http://www.infoq.com/articles/EJB-Glossary
（このArticleは2006年7月13日にリリースされました）