10g リリース2（10.1.2）
B15634-02
 目次 |
 索引 |
| Oracle® Application Server Containers for J2EE Enterprise JavaBeans開発者ガイド 10g リリース2（10.1.2） B15634-02 |
|
この章では、J2EE仕様で完全に指定されているEnterprise JavaBeans（EJB）の概要について説明します。このマニュアルの他の章では、EJBの開発に必要な作業についてのみ説明します。
この章で説明する概要の詳細および例は、Sun社による、EJBおよびJ2EE Blueprint Architectureの推奨について説明されている文献を参照してください。
この章には、次の項目が含まれます。
次の各項では、EJB 2.0の新機能について説明します。
Oracle Application Serverは、ローカル・インタフェースを完全にサポートしています。
クライアントは、Beanのインタフェースに定義されているメソッドによってのみ、Session BeanまたはEntity Beanにアクセスできます。これらのメソッドは、Beanのクライアントのビューを定義しています。Beanに関する他の局面（メソッドの実装、デプロイメント・ディスクリプタ設定、抽象スキーマ、データベース・アクセス・コール）は、モジュール性とカプセル化を提供するためにクライアントからはアクセスできません。適切に設計されたインタフェースは、ビジネス・ロジックの複雑さからクライアントを解放し、クライアントに影響を与えずにEJBの内部的な変更も可能にするため、J2EEアプリケーションの開発とメンテナンスを簡素化します。EJBでは、リモートおよびローカルの2つのタイプのクライアント・アクセスをサポートしています。
Enterprise Beanのリモート・クライアントには次の特性があります。
ローカル・クライアントには次の特性があります。
Entity Beanがコンテナ管理の関連のターゲットの場合は、ローカル・インタフェースが必要です。また、EJB間に双方向の関連がある場合は、両方のBeanにローカル・インタフェースが必要です。また、Entity Beanではローカル・アクセスが必要であるため、コンテナ管理の関連に含まれるEntity Beanは同じEJBコンテナに存在する必要があります。このような局所性の主な利点はパフォーマンスの向上にあります。通常、ローカル・コールはリモート・コールより高速です。
ローカル・アクセスとリモート・アクセスのどちらを可能にするかは、次の要因によって決定します。
OrderEJBとLineItemEJBの2つのBeanは密結合されます。密結合のBeanは、ローカル・アクセスに適しています。密結合のBeanは、1つの論理ユニットとして組み合され、相互に頻繁にコールする可能性があるため、ローカル・アクセスよるパフォーマンスの向上が期待できます。
ホーム・インタフェースのビジネス・メソッドは、Entity Beanの永続データを使用しないパブリック・メソッドで使用します。特定のBeanに関連付けられていない作業を実行するメソッドを指定する場合は、ホーム・インタフェースのビジネス・メソッドによってメソッドを公開できます。
EJB 2.0 Message-Driven Beanは、Oracle JMSを使用して実装できます。詳細な例は、第9章「Message-Driven Bean」で説明します。
EJB QLでは、コンテナ管理の永続性を使用してEntity Beanのfinderメソッドとselectメソッドの問合せを定義します。SQL92のサブセットであるEJB QLには、Entity Beanの抽象スキーマに定義されている関連へのナビゲーションを可能にする拡張機能があります。抽象スキーマは、Entity Beanのデプロイメント・ディスクリプタの一部で、Beanの永続フィールドと関連を定義します。「抽象」という用語によって、このスキーマは基礎となるデータ・ストアの物理的なスキーマと区別されます。EJB QL問合せの有効範囲には、同じEJB JARファイルにパッケージされている関連のEntity Beanの抽象スキーマが含まれるため、抽象スキーマ名はEJB QL問合せで参照されます。コンテナ管理の永続性を使用するEntity Beanの場合、EJB QL問合せはすべてのfinderメソッド（findByPrimaryKeyを除く）について定義する必要があります。EJB QL問合せによって、finderメソッドの起動時にEJBコンテナで実行される問合せが決まります。
Oracle Application Serverでは、EJB QLを次の重要な機能とともにサポートしています。
詳細および例は、第7章「EJB問合せ言語」を参照してください。
EJB 2.0仕様では、Entity Bean間の関連を指定できます。Entity Beanは、他のEntity Beanと関連を持つように定義できます。たとえば、プロジェクト管理アプリケーションでは、プロジェクトが一連のタスクで構成されているため、ProjectEJB BeanとTaskEJB Beanを関連付けることができます。Bean管理の永続性を使用するEntity Beanに対しては、コンテナ管理の永続性を使用するEntity Beanとは異なる方法で関連を実装します。Bean管理の永続性を使用する場合は、記述するコードによって関連が実装されます。コンテナ管理の永続性を使用する場合は、EJBコンテナが関連を実装します。このため、コンテナ管理の永続性を使用するEntity Beanでの関連は、コンテナ管理の関連と呼ばれます。
ProjectEJB Beanは複数のTaskEJB Beanが属していることを認識し、各TaskEJB BeanはProjectEJB Beanに属していることを認識している場合、これらのBeanには双方向の関連があります。単方向の関連の場合、
詳細は、第4章「CMP Entity Bean」、第6章「エンティティ関連（E-R）のマッピング」および第7章「EJB問合せ言語」を参照してください。
Oracle Application Serverには、単純なマッピング（1:1）と複雑な関連のマッピング（1:n、m:n）の両方を提供する、Entity Bean用の独自の永続マネージャが最初から用意されています。Oracle Application Serverは、EJB 2.0 O-Rマッピング仕様を完全にサポートしています。
詳細は、第6章「エンティティ関連（E-R）のマッピング」を参照してください。
Oracle Application Serverは、TopLink for Javaなどの代表的なO-Rマッピング・ソリューションとEJBコンテナを統合します。TopLinkによって、開発者は、影響を最小限に抑えながら、オブジェクトとEnterprise JavaBeansをリレーショナル・データベース・スキーマに柔軟にマップできます。TopLink for Javaは拡張マッピング機能を備えています。たとえば、Bean/オブジェクト識別マッピング、タイプと値の変換、関連のマッピング（1:1、1:n、m:n）、オブジェクトのキャッシュとロック、バッチの記述、拡張された動的な問合せ機能などです。TopLinkは、GUIマッピング・ツールであるTopLink Mapping Workbenchを提供しています。これによって、J2EEコンポーネントをデータベース・オブジェクトにマッピングする処理が簡素化されます。TopLinkは、EJB 2.0サポート、（自動的な、または開発者の構成による）双方向の関連のメンテナンス、XMLを使用した（自動的な、または開発者の構成による）キャッシュ同期セッションの管理、および最適読取りロックを提供します。また、Oracle Application Serverは、市販されている他の代表的なO-Rマッピングとも統合されています。
TopLinkの詳細は、『Oracle Application ServerTopLink スタート・ガイド』を参照してください。
RMI-over-IIOPはJ2EE 1.3仕様の一部で、次の2つの重要な利点があります。
Oracle Application Serverは、RMI-over-IIOPをサポートし、次の重要な機能を提供します。
詳細は、『Oracle Application Server Containers for J2EEサービス・ガイド』のRMIと相互運用性の章を参照してください。
リリース2（9.0.3）でのデフォルト値は、次のように変更されました。
-DassociateUsingThirdTable=trueシステム・プロパティを指定してOC4Jを起動し、前の動作をリストアすると、デフォルトで関連表を使用できます。
trans-attributeのデフォルト値は、Requiredに変更されました。詳細は、『Oracle Application Server Containers for J2EEサービス・ガイド』のJTAの章を参照してください。
max-tx-retriesのデフォルト値は0（ゼロ）です。詳細は、『Oracle Application Serverパフォーマンス・ガイド』のEJBの項を参照してください。
max-instancesのデフォルト値は0（ゼロ）に設定されています。
Enterprise JavaBeans（EJB）には、Session Bean、Entity BeanおよびMessage-Driven Beanの3種類があります。
次の項では、各EJBタイプについて説明します。
Session Beanは、1つ以上のビジネス・タスクを実装します。Session Beanには、リレーショナル表内のデータの問合せおよび更新を実行するメソッドを含めることが可能です。Session Beanは、サービスの実装によく使用されます。たとえば、アプリケーション開発者は、データベース内の在庫データを取得および更新するSession Beanを1つ以上実装することがあります。
Session Beanは、サーバー・クラッシュやネットワーク障害が発生すると存続できないため、一時的です。サーバーのクラッシュ後、以前存在していたBeanをインスタンス化しても、以前のインスタンスの状態はリストアされません。状態は、Entity Beanの場合のみリストア可能です。
Session Beanは、javax.ejb.SessionBeanインタフェースを実装します。定義は次のとおりです。
public interface javax.ejb.SessionBean extends javax.ejb.EnterpriseBean { public abstract void ejbActivate(); public abstract void ejbPassivate(); public abstract void ejbRemove(); public abstract void setSessionContext(SessionContext ctx); }
Session Beanは、javax.ejb.SessionBeanインタフェースで指定されているように、最低、次のメソッドを実装する必要があります。
Session Beanの開発方法の詳細は、第3章「Session Beanの実装」を参照してください。
このメソッドを使用して、Beanのコンテキストの参照を取得します。Session Beanには、コンテナによって維持され、Beanから使用可能なセッション・コンテキストが存在します。Beanは、セッション・コンテキスト内のメソッドを使用して、コンテナへのコールバック・リクエストを送信できます。
コンテナは、Beanをインスタンス化した後、setSessionContextメソッドを起動して、Beanからセッション・コンテキストを取得できるようにします。コンテナは、トランザクション・コンテキストからはこのメソッドをコールしません。この時点でBeanがセッション・コンテキストを保存しなかった場合、Beanは二度とセッション・コンテキストにアクセスできなくなります。
コンテナはこのメソッドをコールする際、SessionContextオブジェクトの参照をBeanに渡します。Beanは、この参照を後の使用のために格納できます。次の例では、Beanがセッション・コンテキストをsessctx変数に格納するところを示します。
import javax.ejb.*; import oracle.oas.ejb.*; public class myBean implements SessionBean { SessionContext sessctx; void setSessionContext(SessionContext ctx) { sessctx = ctx; // session context is stored in // instance variable } // other methods in the bean }
javax.ejb.SessionContextインタフェースの定義は次のとおりです。
public interface SessionContext extends javax.ejb.EJBContext { public abstract EJBObject getEJBObject(); }
また、javax.ejb.EJBContextインタフェースの定義は次のとおりです。
public interface EJBContext { public EJBHome getEJBHome(); public Properties getEnvironment(); public Principal getCallerPrincipal(); public boolean isCallerInRole(String roleName); public UserTransaction getUserTransaction(); public boolean getRollbackOnly(); public void setRollbackOnly(); }
Beanは、表1-1に示された操作を実行する際、セッション・コンテキストを必要とします。
Session Beanには2種類あります。
Session Beanの開発方法の詳細は、第3章「Session Beanの実装」を参照してください。
ステートレスSession Beanは、クライアントの状態を維持しません。1回のみ起動可能なBeanです。特定のクライアントに固有ではない、再利用可能なビジネス・サービスで使用されます。たとえば、一般的な為替換算、ローン金利の計算などに使用されます。ステートレスSession Beanには、クライアントから独立した、コール間に渡る読取り専用の状態が格納される場合があります。その後のコールは、プール内の他のステートレスSession Beanによって処理されます。情報は、1回の起動中にのみ使用されます。
EJBコンテナは、複数のクライアントを処理するために、これらのステートレスなBeanのプールを維持しています。クライアントがリクエストを送信すると、プールからインスタンスが取得されます。Beanの情報を初期化する必要はありません。パラメータを持たない単一のcreate/ejbCreateのみ実装されており、これらのメソッド内にはBeanの初期化は含まれていません。remove/ejbRemove、ejbPassivate、ejbActivateおよびsetSessionContextメソッド内でアクションを実装する必要はありません。さらに、これらのメソッドは、ステートレスSession Bean内では使用する必要がありません。かわりに、これらのメソッドは主に、状態を持つEJB、つまりステートフルSession BeanおよびEntity Beanで使用されます。したがって、これらのメソッドは空であるか、または非常に単純になります。
Session Beanの開発方法の詳細は、第3章「Session Beanの実装」を参照してください。
ステートフルSession Beanは、メソッド・コール間で状態を維持します。したがって、各クライアントに対し、ステートフルSession Beanのインスタンスが1つずつ作成されます。それぞれのステートフルSession Beanには、個別のクライアントの識別情報と、1対1のマッピングが含まれています。このタイプのBeanの状態は、複数のコール間で維持されます。これは状態のシリアライズ化によって行われ、非アクティブ化と呼ばれます。そのため、非アクティブ化する状態はシリアライズ可能である必要があります。ただし、システム・クラッシュが発生した場合、この情報は維持されません。
プール内の複数のステートフルBeanの状態を維持するために、最近使用されていないステートフルBeanの対話状態が、2次記憶装置にシリアライズ化されます。Beanのインスタンスがクライアントによって再びリクエストされると、プール内のBeanの状態がアクティブ化します。このようにして、すべてのリソースが高パフォーマンスで使用され、状態は失われません。
保存される状態のタイプには、リソースは含まれません。コンテナによりBean内のejbPassivateメソッドが起動され、Beanがリソースのクリーン・アップを行います。これらのリソースには、保持されたソケット、データベース接続、および静的情報が含まれているハッシュテーブルなどがあります。これらのリソースは、すべてejbActivateメソッド中に再割当ておよび再作成可能です。
Beanのインスタンスでエラーが発生すると、Bean内で継続的に状態を保存するアクションを実行していないかぎり、状態が失われます。ただし、フェイルオーバーに備えて常に状態を保存する必要がある場合、実装にEntity Beanを使用することをお薦めします。または、SessionSynchronizationインタフェースを使用して、状態をトランザクションによって維持することも可能です。
たとえば、ステートフルSession Beanは、ショッピング・カート・オンライン・アプリケーションのサーバー・サイドを実装可能です。このアプリケーションには、購入可能な商品のリストを返し、アイテムを顧客のショッピング・カートに入れ、発注を行い、顧客のプロファイルを変更するなどの作業を行うためのメソッドが含まれます。
Session Beanの開発方法の詳細は、第3章「Session Beanの実装」を参照してください。
Entity Beanは、複合的なビジネス・エンティティです。Entity Beanは、ビジネス・エンティティをモデル化するか、またはビジネス・プロセス内の複数のアクションをモデル化します。Entity Beanは、データを使用するビジネス・サービスの提供、およびそのデータの計算によく使用されます。たとえば、アプリケーション開発者が、発注されたアイテムを取得し計算するEntity Beanを実装する場合があります。Entity Beanで、必要なタスクの実行中に複数の依存性のある永続オブジェクトを管理できます。
Entity Beanはリモート・オブジェクトで、永続データの管理および複雑なビジネス・ロジックの実行を行います。複数の依存性のあるJavaオブジェクトを使用可能で、主キーによって一意に識別可能です。Entity Beanは、複数のファイングレインな永続Javaオブジェクト内に格納されている永続データを使用するため、通常は、コースグレインな永続オブジェクトです。
Entity Beanは、サーバー・クラッシュやネットワーク障害が発生しても存続し続けるため、永続的です。Entity Beanが再びインスタンス化されると、以前のインスタンスの状態が自動的にリストアされます。
Entity Beanの作成方法の詳細は、第5章「Entity Bean」を参照してください。
各Entity Beanには、永続的な識別情報が関連付けられています。つまり、主キーを保有している場合に取得可能な一意の識別情報が含まれています。主キーがあれば、クライアントはEntity Beanを取得可能です。Beanが使用不可の場合、コンテナはBeanをインスタンス化し、永続データを再移入します。
一意のキーのタイプは、Beanプロバイダによって定義されています。
Beanが非アクティブ化された際に状態を保持し、フェイルオーバーが発生した際に状態をリカバリできるよう、Entity Beanのデータは永続性があります。データがコンテナによってデータベースなどのデータ記憶域システムに永続的に格納されるため、Entity Beanは存続可能です。Entity Beanは、次のいずれかの方法により、ビジネス・データを永続的にします。
Entity Beanは、コールバック・メソッドによってデータの永続性を維持します。これは、javax.ejb.EntityBeanインタフェースで定義されています。BeanクラスにEntityBeanインタフェースを実装する場合は、選択した永続性のタイプ（Bean管理の永続性またはコンテナ管理の永続性）で指定されているコールバック関数をそれぞれ作成します。コンテナは、指定されたタイミングでコールバック関数を起動します。
javax.ejb.EntityBeanインタフェースの定義は次のとおりです。
public interface javax.ejb.EntityBean extends javax.ejb.EnterpriseBean { public abstract void ejbActivate(); public abstract void ejbLoad(); public abstract void ejbPassivate(); public abstract void ejbRemove(); public abstract void ejbStore(); public abstract void setEntityContext(EntityContext ctx); public abstract voic unsetEntityContext(); }
コンテナでは、これらのメソッドに次のような機能を設定します。
ejbCreateなどの特定のコールバック・メソッドが特定のときに起動されるため、Entity BeanとSession Beanは似ています。Entity Beanは、永続データ、主キーおよびコンテキスト情報の管理にコールバック関数を使用します。次の図に、Entity Beanの作成時にコールされるメソッドを示します。
Entity Beanのインスタンスは、このメソッドを使用して、コンテキストへの参照を維持します。Entity Beanには、コンテナによって維持され、Beanから使用可能なコンテキストが存在します。エンティティ・コンテキスト内のメソッドを使用して、セキュリティおよびトランザクションのロールなどのBeanに関する情報の取得が、Beanによって行われる場合があります。Beanに関してコンテキストから取得可能なすべての情報は、Sun社のEnterprise JavaBeans仕様を参照してください。
コンテナは、Beanをインスタンス化すると、setEntityContextメソッドを起動して、Beanからコンテキストを取得できるようにします。コンテナは、トランザクション・コンテキストからはこのメソッドをコールしません。この時点でBeanがコンテキストを保存しなかった場合、Beanは二度とコンテキストにアクセスできなくなります。
コンテナはこのメソッドをコールする際、EntityContextオブジェクトの参照をBeanに渡します。Beanは、この参照を後の使用のために格納できます。次の例では、Beanがコンテキストをthis.ctx変数に格納するところを示します。
public void setEntityContext(EntityContext ctx) { this.ctx = ctx; }
クライアントがremoveメソッドを起動すると、コンテナは図1-2に示されているメソッドを起動します。
さらに、永続データの管理のために、ejbStoreおよびejbLoadメソッドがコールされます。Bean管理による永続的なBeanでは、これらは最も重要なコールバック・メソッドです。コンテナ管理による永続的なBeanの場合、永続性はコンテナが管理するため、これらのメソッドは空で構いません。
ejbStoreメソッドは、オブジェクトが非アクティブ化される前、またはトランザクションが終了する直前に、コンテナによってコールされます。永続データを、データベースなどの外部リソースに格納します。
ejbLoadメソッドは、オブジェクトがアクティブ化する前、トランザクションの開始後、またはEntity Beanのインスタンス化の後に、コンテナによってコールされます。特定のBeanインスタンスに対する永続データのリストアを行います。
コンテナによってBeanの永続データを管理するよう選択できます。この場合、コンテナにより、永続データのデータベースへの格納およびリロードが行われるため、Beanのデータの永続性を管理するための一部のコールバック・メソッドを実装する必要がありません。コンテナ管理の永続性を使用する場合、コンテナが永続的マネージャ・クラスを起動し、これによって永続的管理ビジネス・ロジックが提供されます。さらに、主キー用の管理を提供する必要がありません。コンテナによってBeanのキーが提供されます。
次の表に、Beanクラスのコールバック関数の実装要件を示します。
Session BeanとEntity Beanの主な違いは、Entity Beanでは、永続データ管理用のフレームワーク、永続識別情報および複雑なビジネス・ロジックが使用される点です。次の表に、Session BeanとEntity Beanで異なるインタフェースを示します。これら2種類のEJBの違いは、Beanクラスと主キーにあります。永続データ管理は、すべてBeanクラス・メソッド内で行われます。
Message-Driven Bean（MDB）は、JMSのみを使用する場合よりも簡単な、非同期通信を実装するための手段を提供します。MDBは、非同期JMSメッセージを受信するために作成されました。このコンテナにより、JMSのキューおよびトピックに必要な設定のほとんどが処理されます。すべてのメッセージが、関連するMDBに送信されます。
以前のEJBでは、JMSメッセージの送受信ができませんでした。EJBタイプのオブジェクトの場合、JMSメッセージを受信するには、MDBを作成する必要がありました。これにより、他のJavaオブジェクトと同期を取ることが可能なエンタープライズ・オブジェクトに、すべての非同期および公開、サブスクライブ機能が備わります。
MDBの目的は、プール内に存在し、JMSキューからの受信メッセージを受け取り、処理することです。コンテナは、キューからBeanを起動して、キューからの受信メッセージを処理します。MDBを直接起動するオブジェクトはありません。MDBの起動は、すべてコンテナから指示されます。いったんコンテナがMDBを起動すると、他のEJBまたはJavaオブジェクトを起動して、リクエストを続行することが可能です。
MDBは、対話状態を保存せず、複数の受信リクエストの処理に使用される点において、ステートレスSession Beanに似ています。MDBは、クライアントから直接受信したリクエストを処理するのではなく、キューに入れられたリクエストを処理します。図1-3に、このように、クライアントがリクエストをキューに入れる様子を示します。コンテナは、キューからリクエストを取り出し、そのリクエストをプール内のMDBに渡します。
MDBは、javax.ejb.MessageDrivenBeanインタフェースを実装します。また、これはjavax.jms.MessageListenerメソッドを継承します。これらのインタフェース内で、次のメソッドを実装する必要があります。
コンテナは、JMSメッセージの取得および確認の処理を行います。MDBには、JMSの詳細は関係ありません。MDBは、既存のJMSキューに関連付けられます。いったん関連付けられると、コンテナがメッセージのデキューおよび確認の送信を処理します。コンテナは、onMessageメソッドを通じてJMSメッセージを通信します。
EJBには、クライアントがEJBを作成し、使用するための2つのクライアント・インタフェースがあります。
クライアントは、Beanのメソッドを起動する際、両方のインタフェースを使用します。
図1-4に、ステートレスSession Beanを示します。これは、次のステップに対応しています。
createメソッドを起動します。これにより、Beanインスタンスが作成され、Beanのコンポーネント・インタフェース（リモートまたはローカル・インタフェース）への参照が返されます。
removeメソッドを起動することにより、Beanのインスタンスを破棄できます。ステートレスSession Beanなど、一部のBeanでは、removeメソッドをコールできません。このような場合、コンテナによってBeanが削除されます。
ステートレスSession Beanの実装例は、「Session Beanの開発」を参照してください。
EJBを開発する場合は、次の4つの主要コンポーネントを作成します。
次の項では、EJBを開発する際の注意点について説明します。
Beanは、SessionBean、EntityBeanまたはMessageDrivenBeanインタフェースのいずれかでメソッドを実装します。実装には、ホーム・インタフェースで定義されたライフ・サイクル・メソッド、コンポーネント・インタフェース（リモートまたはローカル）で定義されたビジネス・メソッド、およびSessionBean、EntityBeanまたはMessageDrivenBeanインタフェースで定義されたコンテナ・コールバック関数のロジックが含まれています。
Beanの各タイプの詳細は、次の章を参照してください。
EJBを実装する場合、またはEJBメソッドをコールするクライアント・コードを作成する場合、EJBで使用されるパラメータの受渡し規則に注意する必要があります。
Beanメソッドに渡すパラメータ、またはBeanメソッドからの戻り値には、シリアライズ可能なすべてのJavaタイプを使用可能です。int、doubleなど、Javaのプリミティブ型は、シリアライズ可能です。java.io.Serializableインタフェースを実装する非リモート・オブジェクトは、すべて受渡し可能です。パラメータとしてBeanに渡されるかBeanから返される非リモート・オブジェクトは、参照渡しではなく、値渡しされます。たとえば、次のようにBeanメソッドをコールしたとします。
public class theNumber { int x; } ... bean.method1(theNumber);
この場合、Bean内のmethod1()は、theNumberのコピーを受信します。BeanによってサーバーのtheNumberオブジェクトの値が変更されても、値渡しのセマンティクスを使用しているため、クライアントにはこの変更は反映されません。
非リモート・オブジェクトが複合的である場合（複数のフィールドが含まれているクラスなど）、非静的で非一時的なフィールドのみコピーされます。
リモート・オブジェクトをパラメータとして渡す場合、リモート・オブジェクトのスタブが渡されます。パラメータとして渡されるリモート・オブジェクトは、リモート・インタフェースを拡張する必要があります。
次の項では、Beanへのパラメータの受渡しと、戻り値としてのリモート・オブジェクトについて説明します。
EmployeeBean getEmployeeメソッドはEmpRecordオブジェクトを返すため、このオブジェクトをアプリケーション内で定義しておく必要があります。この例では、EmpRecordクラスは、EJBインタフェースと同じパッケージに含まれています。
クラスはpublicとして宣言されており、シリアライズされたリモート・オブジェクトとしてクライアントに値を返せるよう、java.io.Serializableインタフェースを実装する必要があります。次のように宣言します。
package employee; public class EmpRecord implements java.io.Serializable { public String ename; public int empno; public double sal; }
EJBを使用するメリットの1つは、EJBコンテナによってセキュリティ・サービスとトランザクション・サービスが提供されることです。これらのサービス、RMI/IIOP、JNDI、データ・ソースおよびJMSについては、次のマニュアルで説明しています。
|
 Copyright © 2005 Oracle Corporation. All Rights Reserved. |
|