Oracle® Fusion Middleware

Oracle WebLogic Server Enterprise JavaBeansの開発

12c (12.2.1.2.0)

E82896-01(原本部品番号:E77964-02)

2016年11月

このドキュメントは、Java Platform, Enterprise Editionを使用してWebLogic Server Enterprise JavaBeans (EJB)を含むアプリケーションを開発するソフトウェア開発者を対象としています。

Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansの開発, 12c (12.2.1.2.0)

E82896-01

Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved.

原本著者:

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- WebLogic Serverに関するEJBドキュメント

- EJBに関するその他の情報

- EJB開発者向けの包括的なサンプル

- EJB 3.2のサンプル

- EJB 3.1のサンプル

- EJB 3.0のサンプル

- このリリースでの新機能と変更された機能

2 Enterprise JavaBeansの理解

- EJBの新機能と変更された機能

- EJB 3.2の新機能と変更された機能

- EJB 3.1の新機能と変更された機能

- EJB 3.0の新機能と変更された機能

- EJBコンポーネントの理解

- セッションEJBによるビジネス・ロジックの実装

- ステートフル・セッションBean

- ステートレス・セッションBean

- シングルトン・セッションBean

- メッセージドリブンBeanによる疎結合ビジネス・ロジックの実装

- EJBの構造と環境

- EJBの構成要素

- EJBコンテナ

- EJBメタデータ・アノテーション

- オプションのEJBデプロイメント記述子

- EJBのクライアントおよび通信

- EJBへのアクセス

- EJBの通信

- EJBのセキュリティ

3 Enterprise JavaBeansの単純なサンプル

- EJB 3.xの単純なJavaサンプル

- インタフェースなしの単純なステートレスEJBのサンプル

- 単純なビジネス・インタフェースを使用するステートレスEJBのサンプル

- 単純なステートフルEJBのサンプル

- インターセプタ・クラスのサンプル

- WebLogic Serverでパッケージ化されたEJB 3.2のサンプル

- EJB 3.2: セッションBeanライフサイクルを使用するサンプル

- EJB 3.2: メソッドのないリスナーを使用するメッセージドリブンBeanのサンプル

- WebLogic Serverでパッケージ化されたEJB 3.1のサンプル

- EJB 3.1: シングルトン・セッションBeanのサンプル

- EJB 3.1: 非同期メソッドEJBのサンプル

- EJB 3.1: カレンダベース・タイマーEJBのサンプル

- EJB 3.1: 単純化されたインタフェースなしのプログラミングおよびWARファイルでのパッケージ化

- EJB 3.1: EJBでポータブル・グローバルJNDI名を使用するサンプル

- EJB 3.1: Java SEで組込み可能なEJBコンテナを使用するサンプル

- EJB 3.0: セッションBeanからエンティティを呼び出すサンプル

4 Enterprise JavaBeansの反復的な開発

- EJB開発プロセスの概要

- ソース・ディレクトリを作成する

- JARをパッケージ化するためのディレクトリ構造

- WARをパッケージ化するためのディレクトリ構造

- アノテーション付きEJBクラスのプログラミング

- EJBインタフェースのプログラミング

- インタフェースなしのクライアント・ビューを使用したEJBへのアクセス

- ビジネス・インタフェースを使用したEJBへのアクセス

- ビジネス・インタフェース・アプリケーション例外

- EJBでのジェネリックスの使用

- ビジネス・オブジェクトのシリアライズとデシリアライズ

- インターセプタのプログラミング(省略可能)

- EJBタイマー・サービスのプログラミング(省略可能)

- タイマー・サービスの概要

- カレンダベースのEJBタイマー

- 自動作成されるEJBタイマー

- 非永続タイマー

- クラスタ化EJBタイマー・サービスとローカルEJBタイマー・サービス

- クラスタ化EJBタイマー・サービス

- ローカルEJBタイマー・サービス

- クラスタ化EJBタイマーの構成

- Javaプログラミング・インタフェースを使用してタイマー・オブジェクトをプログラミングする

- EJB 3.2タイマー関連プログラミング・インタフェース

- WebLogic Server固有のタイマー関連インタフェース

- EJBクライアントへのアクセスのプログラミング

- リモート・クライアント

- ローカル・クライアント

- クライアントからのEJBのルックアップ

- 依存関係インジェクションの使用

- JNDIポータブル構文の使用

- JNDI名のカスタマイズ

- URLにリクエストを送信するようにEJBを構成する

- URLによるHTTPリソースの指定

- JNDI名によるHTTPリソースの指定

- BeanコードからのHTTPリソースへのアクセス

- EJBのネットワーク通信の構成

- トランザクションのプログラミングと構成

- コンテナ管理によるトランザクションのプログラミング

- コンテナ管理トランザクションの自動的な再試行の構成

- Bean管理のトランザクションのプログラミング

- 複数のEJBで分散されるトランザクションのプログラミング

- クライアントのトランザクション・コンテキストから複数のEJBを呼び出す

- EJB「ラッパー」を使用してEJB間トランザクションをカプセル化する

- Javaソースをコンパイルする

- デプロイメント記述子の作成と編集(省略可能)

- EJBのパッケージ化

- JARでのEJBのパッケージ化

- WARでのEJBのパッケージ化

- EJBのデプロイメント

5 アノテーション付きEJBクラスのプログラミング

- メタデータ・アノテーションとEJB Beanファイルの概要

- Beanファイルのプログラミング: 要件およびEJB 2.xからの変更点

- Beanファイルの要件とEJB 2.xからの変更点

- Beanクラス・メソッドの要件

- Beanファイルのプログラミング

- Beanファイルをプログラミングする際の一般的な手順

- ビジネス・インタフェースとその他のインタフェースを指定する

- ビジネス・インタフェースを指定する

- インタフェースなしのビューを指定する

- Beanタイプ(ステートレス、シングルトン、ステートフル、メッセージドリブン)を指定する

- 変数またはセッター・メソッドにリソース依存性を注入する

- 3.0エンティティを呼び出す

- メタデータ・アノテーションを使用して永続性コンテキストを注入する

- EntityManager APIを使用してエンティティを検索する

- EntityManagerを使用してエンティティを作成および更新する

- ビジネス・メソッドまたはライフサイクル・コールバック・イベントのインターセプタを指定する

- ビジネス・インターセプタまたはライフサイクル・インターセプタを指定する:一般的な手順

- インターセプタ・クラスをプログラミングする

- ビジネス・メソッド・インターセプタ・メソッドをプログラミングする

- 非同期ビジネス・メソッドをプログラミングする

- ライフサイクル・コールバック・インターセプタ・メソッドをプログラミングする

- デフォルト・インターセプタ・メソッドを指定する

- InvocationContext APIを使用してインターセプタ間で状態を保存する

- アプリケーション例外をプログラミングする

- EJBへのアクセスにセキュリティを設定する

- トランザクション管理とトランザクション属性を指定する

- メタデータ・アノテーションの機能別一覧

- Beanタイプを指定するためのアノテーション

- ローカル・インタフェースまたはリモート・インタフェースを指定するためのアノテーション

- EJB 2.xクライアント・ビューをサポートするためのアノテーション

- 3.0エンティティBeanを呼び出すためのアノテーション

- トランザクション関連のアノテーション

- インターセプタを指定するためのアノテーション

- ライフサイクル・コールバックを指定するためのアノテーション

- セキュリティ関連のアノテーション

- コンテキスト依存性アノテーション

- タイムアウトと例外のアノテーション

- タイマーとスケジューリングのアノテーション

6 Enterprise JavaBeansのデプロイメント・ガイドライン

- EJBをデプロイする前に

- デプロイメント・タスクの理解と実行

- EJBデプロイメントのガイドライン

- エンタープライズ・アプリケーションの一部としてのスタンドアロンEJBのデプロイメント

- Webアプリケーションの一部としてのEJBのデプロイメント

- お互いに呼出しあう複数のEJBの同じアプリケーションでのデプロイメント

- プロトコル切替えの制限

- 依存関係インジェクションを使用するEJBのデプロイメント

- クラスタへの均一なデプロイメント

- EJBのクラスタへのデプロイメント

- EJBの再デプロイメント

- FastSwapデプロイメントによるデプロイメントの最小化

- 警告メッセージの理解

- EJBデプロイメントの警告メッセージの無効化

7 Oracle WebLogic Serverでの組込みEJBコンテナの使用方法

- 組込み可能なEJBコンテナの概要

- 組込みEJBコンテナでサポートされるEJB Liteの機能

8 Oracle WebLogic Serverでの永続性プロバイダの構成

- Oracle TopLinkの概要

- 永続性プロバイダの指定

- ドメインのデフォルト・プロバイダの設定

- アプリケーションでの永続性プロバイダの指定

- Oracle WebLogic ServerでのOracle TopLinkの使用方法

A EJBメタデータ・アノテーション・リファレンス

- EJB 3.xアノテーションの概要

- ステートレスBean、ステートフルBean、メッセージドリブンBeanのアノテーション

- javax.ejb.AccessTimeout

- 説明

- 属性

- javax.ejb.ActivationConfigProperty

- 説明

- 属性

- javax.ejb.AfterBegin

- 説明

- javax.ejb.AfterCompletion

- 説明

- javax.ejb.ApplicationException

- 説明

- 属性

- javax.ejb.Asynchronous

- 説明

- javax.ejb.BeforeCompletion

- 説明

- javax.ejb.ConcurrencyManagement

- 説明

- 属性

- javax.ejb.DependsOn

- 説明

- 属性

- javax.ejb.EJB

- 説明

- 属性

- javax.ejb.EJBs

- 説明

- 属性

- javax.ejb.Init

- 説明

- 属性

- javax.ejb.Local

- 説明

- 属性

- javax.ejb.LocalBean

- 説明

- javax.ejb.LocalHome

- 説明

- 属性

- javax.ejb.Lock

- 説明

- 属性

- javax.ejb.MessageDriven

- 説明

- 属性

- javax.ejb.PostActivate

- 説明

- javax.ejb.PrePassivate

- 説明

- javax.ejb.Remote

- 説明

- 属性

- javax.ejb.RemoteHome

- 説明

- 属性

- javax.ejb.Remove

- 説明

- 属性

- javax.ejb.Schedule

- 説明

- カレンダベースのスケジュールの要素

- 要素値でサポートされる形式

- スケジュール指定の要素のその他のルール

- 属性

- javax.ejb.Schedules

- 説明

- 属性

- javax.ejb.Singleton

- 説明

- 属性

- javax.ejb.Startup

- 説明

- javax.ejb.StatefulTimeout

- 説明

- 属性

- javax.ejb.Stateless

- 説明

- 属性

- javax.ejb.Timeout

- 説明

- javax.ejb.TransactionAttribute

- 説明

- 属性

- javax.ejb.TransactionManagement

- 説明

- 属性

- インターセプタの構成に使用するアノテーション

- javax.interceptor.AroundInvoke

- 説明

- javax.interceptor.ExcludeClassInterceptors

- 説明

- javax.interceptor.ExcludeDefaultInterceptors

- 説明

- javax.interceptor.Interceptors

- 説明

- 属性

- エンティティBeanとの対話に使用するアノテーション

- javax.persistence.PersistenceContext

- 説明

- 属性

- javax.persistence.PersistenceContexts

- 説明

- 属性

- javax.persistence.PersistenceUnit

- 説明

- 属性

- javax.persistence.PersistenceUnits

- 説明

- 属性

- EJB 3.xで使用する標準JDKアノテーション

- javax.annotation.PostConstruct

- 説明

- javax.annotation.PreDestroy

- 説明

- javax.annotation.Resource

- 説明

- 属性

- javax.annotation.Resources

- 説明

- 属性

- EJB 3.xで使用するセキュリティ関連の標準JDKアノテーション

- javax.annotation.security.DeclareRoles

- 説明

- 属性

- javax.annotation.security.DenyAll

- 説明

- javax.annotation.security.PermitAll

- 説明

- javax.annotation.security.RolesAllowed

- 説明

- 属性

- javax.annotation.security.RunAs

- 説明

- 属性

- WebLogicアノテーション

- weblogic.javaee.AllowRemoveDuringTransaction

- 説明

- weblogic.javaee.CallByReference

- 説明

- weblogic.javaee.DisableWarnings

- 説明

- 属性

- weblogic.javaee.EJBReference

- 説明

- 属性

- weblogic.javaee.Idempotent

- 説明

- 属性

- weblogic.javaee.JMSClientID

- 説明

- 属性

- weblogic.javaee.JNDIName

- 説明

- 属性

- weblogic.javaee.JNDINames

- 説明

- 属性

- weblogic.javaee.MessageDestinationConfiguration

- 説明

- 属性

- weblogic.javaee.TransactionIsolation

- 説明

- 属性

- weblogic.javaee.TransactionTimeoutSeconds

- 説明

- 属性

はじめに

ここでは、このガイド『Oracle WebLogic Server Enterprise JavaBeansの開発』で使用されるドキュメントのアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この章では、このガイド『Oracle WebLogic Server Enterprise JavaBeansの開発』の内容と構成について説明します。

この章の内容は次のとおりです。

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- EJB開発者向けの包括的なサンプル

- このリリースでの新機能と変更された機能

ドキュメントのスコープと対象読者

このドキュメントは、WebLogic Server Enterprise JavaBeans (EJB)を利用したアプリケーションを開発するソフトウェア開発者を対象としています。このドキュメントは、Java EEおよび基本的なEJBプログラミングの概念に精通している読者を対象としています。

このドキュメントの大部分は、EJB 3.2プログラミング・モデルの解説に割かれています。具体的には、メタデータ・アノテーションを使用して開発を簡略化する方法について説明します。このドキュメントでは、バージョン2.xと3.xで異なっているEJBに関するトピック(設計上の考慮事項、コンテナ・アーキテクチャ、エンティティBean、デプロイメント記述子の使用など)は取扱いません。また、プロダクション段階における管理、モニター、パフォーマンス・チューニングなどについても説明しません。これらのトピックに関するWebLogic Serverのドキュメントとリソースへのリンクについては、「関連ドキュメント」を参照してください。

2.1 EJBのプログラミングおよびパッケージ化の詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』を参照してください。

このドキュメントの手引き

- この章「概要とロードマップ」では、このドキュメントの構成を紹介します。

- 「Enterprise JavaBeansの理解」では、EJB 3.1の新機能について概説し、EJB 3.1と3.0の相違点について簡単に説明します。

- 「Enterprise JavaBeansの単純なサンプル」では、EJB 3.x仕様のメタデータ・アノテーションを使用したEJBプログラミングのサンプルを紹介します。

- 「Enterprise JavaBeansの反復的な開発」では、EJBの実装プロセスを説明し、EJBをWebLogic Serverで実行する方法について説明します。

- 「アノテーション付きEJBクラスのプログラミング」では、メタデータ・アノテーションを含むEJB Beanクラスをプログラミングする際の要件と一般的な手順について説明します。

- 「Enterprise JavaBeansのデプロイメント・ガイドライン」では、EJB固有のデプロイメントの問題と手順を説明します。

- 「Oracle WebLogic Serverでの組込みEJBコンテナの使用方法」では、Oracle WebLogic Serverで組込み可能なEJBコンテナを使用する方法について説明します。

- 「Oracle WebLogic Serverでの永続性プロバイダの構成」では、Oracle WebLogic Serverを使用したOracle TopLinkアプリケーションの開発の概要について説明します。

- 「EJBメタデータ・アノテーション・リファレンス」では、EJB 3.xメタデータ・アノテーションのリファレンス情報と、EJBで使用する標準的なメタデータ・アノテーションに関する情報を提供します。

関連ドキュメント

このドキュメントでは、EJB 3.2固有の開発に関する情報を取扱います。また、セッションBeanとメッセージドリブンBeanに関する情報のみ提供します。EJBの設計とアーキテクチャ、EJB 3.xでも完全にサポートされているEJB 2.xのプログラミング・モデルに関する一般情報は、次のドキュメントを参照してください。

WebLogic Serverに関するEJBドキュメント

WebLogic Serverを使用したEJBの開発およびデプロイの詳細は、次を参照してください。

- 『Oracle WebLogic Serverの理解』のEnterprise Java Beans (EJB)に関する項。

- 分割ディレクトリ環境でWebLogic Server EJBを配置してビルドする方法については、Oracle WebLogic Serverアプリケーションの開発の分割開発ディレクトリ環境の作成を参照してください。

- 2.x EJBのプログラミングおよびパッケージ化の詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』を参照してください。

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』は、開発および本番環境でのWebLogic Serverアプリケーションのデプロイメントについての主要な情報源です。

EJBに関するその他の情報

この章は、Java EE のプログラミングおよびEJB の概念と機能に精通している読者を対象としています。エンタープライズBeanの利点、エンタープライズBeanの種類、ライフサイクルなどの基本的なEJBの概念を学習するには、次のWebサイトを参照してください。

- Enterprise JavaBeans 3.2仕様(JSR-345)(http://jcp.org/en/jsr/summary?id=345)

- Java EE 7チュートリアル(http://docs.oracle.com/javaee/7/tutorial/partentbeans.htm#BNBLR)の「エンタープライズBean」の章

- Java EE 6プラットフォームの概要: パート3 (EJB Technology, Even Easier to Use)(http://www.oracle.com/technetwork/articles/javaee/javaee6overview-part3-139660.html#ejbeasy)

EJB開発者向けの包括的なサンプル

WebLogic Serverの配布キットには、このドキュメント、および「Enterprise JavaBeansの単純なサンプル」で説明する基本的なサンプルに加え、開発者向けの包括的なサンプルも含まれています。

サンプル付きのWebLogic Server完全版をインストールした場合、サンプル・ソース・コードはEXAMPLES_HOMEディレクトリにあります。デフォルト・パスは、ORACLE_HOME\wlserver\samples\serverです。このディレクトリからサンプルのソース・コードおよびインストラクション・ファイルにアクセスでき、サンプル・ドメインを設定する必要がありません。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションとコード例に関する項を参照してください。

EJBを使用して独自のアプリケーションをプログラミングする前に、このサンプルを実行することをお薦めします。

EJB 3.2のサンプル

次のようなJava EE 7のサンプル(EJB 3.2の新機能のデモ)が用意されています。

- EJB 3.2: セッションBeanライフサイクルを使用するサンプル

- EJB 3.2: メソッドのないリスナーを使用するメッセージドリブンBeanのサンプル

詳細は、WebLogic Server配布キットのEJB 3.2サンプルEXAMPLES_HOME/examples/src/examples/javaee7/ejbを参照してください。EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

EJB 3.1のサンプル

次のようなJava EE 6のサンプル(EJB 3.1の新機能のデモ)が用意されています。

- EJB 3.1: シングルトン・セッションBeanのサンプル

- EJB 3.1: 非同期メソッドEJBのサンプル

- EJB 3.1: カレンダベース・タイマーEJBのサンプル

- EJB 3.1: 単純化されたインタフェースなしのプログラミングおよびWARファイルでのパッケージ化

- EJB 3.1: EJBでポータブル・グローバルJNDI名を使用するサンプル

詳細は、WebLogic Server配布キットのサンプルEXAMPLES_HOME/examples/src/examples/javaee6/ejbを参照してください。EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションとコード例に関する項を参照してください。

EJB 3.0のサンプル

EJB 3.0永続性サービスのサンプル「EJB 3.1: Java SEで組込み可能なEJBコンテナを使用するサンプル」もあります。ここには、実際のビジネス・コードが含まれ、主要なEJB 3.0の開発タスクの実際の実行方法を説明しています。具体的には、EJB 3.xで以下を使用する方法が例示されています。

- Java Persistence API

- ステートレス・セッションBean

- メッセージドリブンBean

- JavaScriptベースの非同期のブラウザ・アプリケーション

このサンプルでは、エンティティEJB用の永続ドメイン・モデルが使用されています。詳細は、WebLogic Server配布キットのサンプルEXAMPLES_HOME/examples/src/examples/ejb/ejb30を参照してください。EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションとコード例に関する項を参照してください。

このリリースでの新機能と変更された機能

このリリースのWebLogic Serverで導入されたEJB 3.1の新機能の一覧は、「EJB 3.2の新機能と変更された機能」を参照してください。

2 Enterprise JavaBeansの理解

この章では、EJB 3.2の新機能とプログラミング・モデルについて説明します。また、EJBのコンポーネント、構造および機能の基本的な概要も示します。

この章の内容は以下のとおりです。

- EJBの新機能と変更された機能

- EJBコンポーネントの理解

- EJBの構造と環境

- EJBのクライアントおよび通信

- EJBのセキュリティ

EJBの新機能と変更された機能

これらの項では、EJB 3.2、3.1と3.0、およびEJB 2.xと3.xとの間のEJBプログラミングのモデルおよび要件に関する変更点をまとめています。

EJB 3.2の新機能と変更された機能

Java EE 7では、密接した統合プラットフォームを備え、簡素化したアプリケーション・アーキテクチャを提供して、引き続き開発しやすさに焦点を当てています。また、ボイラープレート・コードを削減し、アノテーションの用途を拡大して効率が向上しました。

次に、以前のEJB APIと比較してEJB 3.2で新しく追加された主な機能および簡素化された機能の概要を示します。

- 拡張メッセージドリブンBean – すべてのパブリック・メソッドをメッセージ・リスナー・メソッドとして公開するように、メソッドなしのメッセージ・リスナー・インタフェースを備えたMDBコントラクトを拡張しました。また、標準JMS MDBアクティブ化プロパティのリストも拡張しました。

- EJB Lite – ローカル非同期セッションBeanの呼出しと非永続EJBタイマー・サービスを含めるように、EJB Liteグループを拡張しました。また、EJB Liteコンテナが他のAPIグループをサポートするクリア・ルールを定義しました。

- EJBタイマーの拡張 – EJBモジュール内のすべてのアクティブ・タイマーにアクセスするように、TimerService APIを拡張しました。また、Bean内でのみ参照を使用する必要があったjavax.ejb.Timerおよびjavax.ejb.TimerHandleの制約が取り除かれました。

- ステートフル・セッションBeanの拡張 – ライフサイクル・コールバック・メソッドのトランザクション属性で判定されるトランザクション・コンテキストで実行するために、ステートフル・セッションBeanのライフサイクル・コールバック・インターセプタ・メソッドのオプションを追加しました。また、ステートフル・セッションBeanのパッシブ化を無効にするオプションも導入しました。

- セキュリティの拡張 – 実際のロール名とは関係なく、認証されたコール元を示す"**"という名前の、コンテナで提供されたセキュリティ・ロールを追加しました。また、EJBデプロイメント記述子を使用したセキュリティ・ロールの定義の要件を簡素化しました。

- Java Persistence 2.1のサポート – JPA 2.1には、Criteria Bulk Update/Delete、ストアド・プロシージャ、JPQL汎用関数、インジェクション可能なエンティティ・リスナー、TREAT、コンバータ、DDL生成およびエンティティ・グラフなどの機能に対する新しいサポートまたは拡張が含まれます。JPA 2.1の完全な仕様は、「JSR-000338 Java Persistence 2.1 (Final Release)」(http://jcp.org/aboutJava/communityprocess/final/jsr338/index.html)を参照してください。

- テクノロジ・プルーニング – 今回のリリースで、次の機能のサポートが選択できるようになりました。

- コンテナ管理による永続性のためのEJB 2.1以前のエンティティBeanコンポーネント・コントラクト

- Bean管理による永続性のためのEJB 2.1以前のエンティティBeanコンポーネント・コントラクト

- EJB 2.1以前のエンティティBeanのクライアント・ビュー

- EJB QL: コンテナ管理による問合せメソッドの問合せ言語

Java EE 7におけるEJBの新機能と変更点の包括的なリストは、Enterprise JavaBeans 3.2仕様(JSR-345)(http://jcp.org/en/jsr/summary?id=345)を参照してください。

EJB 3.1の新機能と変更された機能

EJB 3.1の仕様では、プログラミングおよびパッケージ化モデルの変更が簡素化されています。前のバージョンのJavaインタフェースを使用する必要がなくなり、プレーンな従来型Javaオブジェクトに注釈付けし、EJBコンポーネントとして使用できるようになりました。EJBコンポーネントをWebアプリケーションの内部に直接配置できるようになり、簡素化はさらに進みました。これにより、WebコンポーネントおよびEJBコンポーネントを格納するアーカイブを個々に作成して、それらをEARファイルに結合する必要はなくなりました。

次に、以前のEJB APIと比較してEJB 3.1で新しく追加された機能および簡素化された機能の概要を示します。

- シングルトン・セッションBean: シングルトン・セッションBeanは、セッションBeanが特定のJava Virtual Machine (JVM)でアプリケーションごとに1回インスタンス化され、それはアプリケーションのライフサイクルにわたって存在することを保証する正式なプログラミング構成メンバーとして機能します。シングルトンでは、エンタープライズBeanコンポーネントの複数のインスタンス間、またはアプリケーションの複数のエンタープライズBeanコンポーネント間で状態を容易に共有できます。

- 単純化されたインタフェースなしのクライアント・ビュー - インタフェースなしのローカル・クライアント・ビュー・タイプでは、個別のローカル・ビジネス・インタフェースを必要とすることなく、ローカル・セッションBeanへのアクセスを提供して、コンポーネントでEJB Beanクラス・インスタンスを直接注入させることで、EJBの開発を単純化しています。

- WARファイルでの直接的なEJBディレクトリのパッケージ化およびデプロイメント - EJB 3.1ではEJBコンポーネントを直接Webアプリケーション・アーカイブ(WAR)ファイルの中に配置する機能を使用することで、アーカイブを生成してWebコンポーネントとEJBコンポーネントを保存し、それらをエンタープライズ・アーカイブ(EAR)ファイルで結合する必要がなくなりました。

- ポータブル・グローバルJNDIネーミング - EJB 3.1のポータブル・グローバルJNDIネーミング・オプションでは、一般的でよく知られているネームスペースを多数提供し、そのネームスペースでjava:global[/<アプリケーション名>]/<モジュール名>/<Bean名>というパターンを使用して、EJBコンポーネントを登録およびルックアップできます。これにより、EJBコンポーネントをJNDIに登録する方法および場所、およびそれらをアプリケーションでルックアップおよび使用する方法を標準化します。

- 非同期セッションBeanの呼出し - EJB 3.1セッションBeanでは、非同期クライアント呼出しセマンティクスでメソッドを公開できます。EJBクラスまたは特定のメソッドで@Asynchronousアノテーションを使用すると、メソッドが呼び出されたときに、クライアントに即座に制御を戻すようにEJBコンテナに指示します。メソッドはfutureオブジェクトを返して、クライアントにメソッド呼出しのステータスをチェックさせて、非同期に生成される結果の値を取得できます。

- EJBタイマーの機能向上 - EJB 3.1タイマー・サービスでは、カレンダベースのEJBタイマー式をサポートします。このスケジューリング機能では、CRONスタイルのスケジュール定義という形式をとっています。これは、EJBメソッドに配置され、定義されたスケジュールに応じてメソッドを自動的に呼び出せます。また、EJB 3.1では、Beanクラスまたはデプロイメント記述子のメタデータに基づくタイマーの自動作成もサポートします。これによりBean開発者は、Bean呼出しに依存せずにタイマーをスケジューリングし、プログラムでいずれかのTimer Serviceタイマー作成メソッドを呼び出すことができます。自動作成されるタイマーは、アプリケーション・デプロイメントの結果としてコンテナで作成されます。

- 組込み可能なEJBコンテナ - EJB 3.1では、Java SE環境の中でEJBコンポーネントを実行する組込み可能なAPIをサポートします。従来のJava EEサーバーベースの実行とは異なり、組込み可能なものを使用することで、クライアント・コードとそれに対応するエンタープライズBeanを同じ仮想マシンおよびクラス・ローダー内で実行できます。これにより、テスト、オフライン処理(バッチ・ジョブなど)、およびデスクトップ・アプリケーションのEJBプログラミング・モデルの使用に対するサポートが向上します。

- JPA 2.1のサポート - Oracle EclipseLinkは、Oracle WebLogic Serverに付属するデフォルトのJPA 2.1永続性プロバイダです。WebLogic ServerはサーバーのclasspathのJPA 2.1 JARで実行されます。JPA 2.1はJPA 2.0および1.0と上位互換性がありますが、JPA 2.1では、OpenJPAインタフェース内の既存のシグネチャと競合するいくつかのメソッドが、既存のJPAインタフェースに導入されました。
このため、以前のリリースのWebLogic ServerでKodo/JPAを永続性プロバイダとして使用するアプリケーションは、リコンパイルする必要があります。詳細は、WebLogic Server 12.1.3用の『Oracle WebLogic Server Enterprise JavaBeansの開発』の競合を解決するためのアプリケーションの更新に関する項を参照してください。

詳細は、「Oracle WebLogic Serverでの永続性プロバイダの構成」を参照してください。

EJB 3.0の新機能と変更された機能

次に、以前のEJB APIと比較してEJB 3.0で新しく追加された機能および簡素化された機能の概要を示します。

- EJBデプロイメント記述子ファイル(ejb-jar.xmlなど)を作成する必要がなくなりました。Beanファイル自体の中で、メタデータ・アノテーションを使用してメタデータを構成できます。ただし、必要であれば、引続きXMLデプロイメント記述子を使用することもできます。衝突が発生した場合は、デプロイメント記述子の値でアノテーションの値がオーバーライドされます。

- Beanファイルで必須となるメタデータ・アノテーションは、記述するEJBのタイプを指定するアノテーション(@javax.ejb.Stateless、@javax.ejb.Stateful、@javax.ejb.MessageDriven、または@javax.persistence.Entity)のみです。それ以外のアノテーションのデフォルト値は、EJBの典型的かつ標準的な用途を反映したものになっています。これにより、典型的なEJBをプログラミングする場合であればBeanファイルに記述するコードが減り、デフォルト値が適切でない場合にのみアノテーションを追加するだけで済みます。

- Beanファイルとして、POJO (Plain Old Java Object)を使用できます。javax.ejb.SessionBeanやjavax.ejb.MessageDrivenBeanを実装する必要はありません。

- javax.ejb.SessionBeanやjavax.ejb.MessageDrivenBeanを実装する必要がなくなった結果、BeanファイルにejbCreateやejbPassivateなどのライフサイクル・コールバック・メソッドを実装する必要もなくなりました。ただし、これらのコールバック・メソッドを実装したい場合は、たとえば@javax.ejb.PostActivateのように、それらのメソッドに任意の名前を付けて適切なアノテーションとして追加できます。

- セッションBeanはビジネス・インタフェースを介してクライアント・ビューを公開できます。ビジネス・インタフェースは、セッションBeanで明示的に実装するか、@javax.ejb.Remoteまたは@javax.ejb.Localアノテーションを使用して指定できます。

- ビジネス・インタフェースはPlain Old Java Interface (POJI)です: javax.ejb.EJBObjectやjavax.ejb.EJBLocalObjectを拡張しないようにする必要があります。

- ビジネス・インタフェースがjava.rmi.Remoteを拡張していない場合は、ビジネス・インタフェース・メソッドからjava.rmi.RemoteExceptionが送出されない可能性があります。

- Beanファイルで、依存関係インジェクションがサポートされるようになりました。依存関係インジェクションでは、Beanコンテキスト内の別のEJB、リソース、環境エントリへの参照が、EJBコンテナによってBeanファイル内の変数またはセッター・メソッドに自動的に提供(注入)されます。

- Beanファイルでインターセプタがサポートされるようになりました。インターセプタは、EJBでアスペクト指向プログラミングを使用するための標準的な方法です。

- 2種類のインターセプタ・メソッドを構成できます。ビジネス・メソッドをインターセプトするメソッドと、ライフサイクル・コールバックをインターセプトするメソッドです。

- 特定の順序でチェーンとして実行する複数のインターセプタ・メソッドを構成できます。

- JARファイルに含まれるすべてのEJBで実行するデフォルト・インターセプタ・メソッドを構成できます。

EJB 3.xプログラミング・モデルは非常にシンプルであるため、EJB 3.x BeanにおいてEJBGenタグおよびコード生成ツールをサポートしないことになりました。このツールは、2.x Beanでのみ使用できます。詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のEJBGenリファレンスに関する項を参照してください。

EJBコンポーネントの理解

Enterprise JavaBeans (EJB) 3.2テクノロジは、Java EE 7のサーバー側コンポーネント・アーキテクチャです。EJB 3.2テクノロジを使用することで、Javaテクノロジに基づいて、安全でポータブルな分散トランザクション・アプリケーションを迅速かつ容易に開発できます。

セッションEJBによるビジネス・ロジックの実装

セッションBeanは、ビジネス・ロジックを実装します。セッションBeanには、ステートフル、ステートレス、およびシングルトンの3種類があります。ステートフル・セッションBeanおよびステートレス・セッションBeanは一度に1つのクライアントとして機能します。一方、シングルトン・セッションBeanは並列して呼び出すことができます。

セッションBeanの種類およびそれらを使用するタイミングの詳細は、Java EE 7チュートリアル(http://docs.oracle.com/javaee/7/tutorial/index.html)の「エンタープライズBean」の章のセッションBeanの内容に関する項を参照してください。

ステートフル・セッションBean

ステートフル・セッションBeanは、特定のクライアントとの対話を反映する状態情報をメソッドやトランザクションをまたがって維持します。ステートフル・セッションBeanは、クライアントと他のエンタープライズBeanの対話を管理するか、ワークフローを管理できます。

例: 社員が個人のプロファイル情報を表示して更新できる、ある会社のWebサイトでは、ステートフル・セッションBeanを使用して他の様々なBeanを呼び出し、ユーザーがページ上でデータの表示をクリックした後にユーザーが必要とする次のようなサービスを提供できます。

- JSPからログイン・データを受け付け、そのログイン・データを検証する別のEJBを呼び出す

- 認可の確認をJSPに送信する

- 認可されたユーザーのプロファイル情報にアクセスするBeanを呼び出す

ステートレス・セッションBean

ステートレス・セッションBeanは、呼出し間でセッションやクライアントの状態の情報を格納しません。唯一格納されることのある状態はクライアントに固有のものではなく、キャッシュされたデータベース接続や別のEJBの参照などです。ステートレス・セッションBeanが状態を格納できるのは、長くてメソッド呼出しの期間だけです。メソッドが完了すると、状態情報は維持されません。

ステートレス・セッションBeanのインスタンスはすべて、どのクライアントにもサービスを提供できます(どのインスタンスも機能は同じ)。ステートレス・セッションBeanは、ステートフル・セッションBeanよりもパフォーマンスが優れています。その理由は、各ステートレス・セッションBeanが複数のクライアントをサポートできるからです(ただし一度に1つ)。ステートレス・セッションBeanのクライアントは、Webサービス・エンドポイントにできます。

例: 訪問者が「連絡先」リンクをクリックして電子メール送信できるインターネット・アプリケーションでは、ステートレス・セッションBeanを使用して、JSPによってユーザーから収集された送信先と送信元の情報に基づいて電子メールを生成できます。

シングルトン・セッションBean

シングルトン・セッションBeanでは、セッションBeanが特定のJava仮想マシン(JVM)のアプリケーションごとに1回のみインスタンス化され、そのアプリケーションのライフサイクルで存在することを保証する正式なプログラミング構造を提供しています。シングルトンでは、エンタープライズBeanコンポーネントの複数のインスタンス間、またはアプリケーションの複数のエンタープライズBeanコンポーネント間で状態を容易に共有できます。

シングルトン・セッションBeanはステートレス・セッションBeanと同様の機能を提供します。ただし、ステートレス・セッションBeanではそのプールでクライアント要求に応答するのに対して、シングルトン・セッションBeanはアプリケーションごとに1つしかありません。シングルトン・セッションBeanは、ステートレス・セッションBeanと同様に、Webサービス・エンドポイントを実装できます。シングルトン・セッションBeanではクライアントの呼出し間でその状態を保持しますが、サーバーのクラッシュまたは停止時にはその状態を保持する必要はありません。

例: ApacheのWebサイトでは、「Simple Singleton: ComponentRegistry」のサンプルが提供されています。この例では、シングルトンBeanでContainer-Managed Concurrencyを使用して、読取り(@Lock(READ))機能(Beanへのマルチスレッド・アクセスが可能)と書込み(@Lock(WRITE))機能(Beanへのシングルスレッド・アクセスを強制)を利用する方法を説明しています。

メッセージドリブンBeanによる疎結合ビジネス・ロジックの実装

メッセージドリブンBeanは、リクエストに対するレスポンスが即時である必要のない疎結合(非同期)のビジネス・ロジックを実装します。メッセージドリブンBeanは、JMSキューまたトピックからメッセージを受信し、そのメッセージの内容に基づいてビジネス・ロジックを実行します。それは、EJBとJMSの間の非同期インタフェースです。

MDBインスタンスはそのライフサイクルを通じて、同時にではありませんが複数のクライアントからのメッセージを処理できます。特定のクライアントの状態は維持されません。メッセージドリブンBeanのインスタンスはすべて同じ機能であり、EJBコンテナはどのMDBインスタンスにもメッセージを割り当てることができます。コンテナは、それらのインスタンスをプールしてメッセージのストリームの並行処理を可能にします。

EJBコンテナは、必要に応じてBeanのインスタンスを作成し、JMSメッセージをインスタンスに渡すことによってメッセージドリブンBeanと直接対話します。コンテナは、デプロイメント時にBeanのインスタンスを作成し、メッセージのトラフィックに基づいて作動時にインスタンスを追加および削除します。

詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』を参照してください。

例:顧客から注文を受けるプロセスがサプライヤへの発注プロセスを引き起こすオンライン・ショッピング・アプリケーションでは、サプライヤへの発注プロセスをメッセージドリブンBeanで実装できます。顧客の注文が必ずサプライヤへの発注につながる一方で、そのステップは疎結合になります。その理由は、顧客の注文を確定する前にサプライヤへの発注を生成する必要はないからです。関連するサプライヤへの注文が発行される前に顧客の注文が「蓄積」されるのは問題なく、有益なことです。

EJBの構造と環境

以下の節では、各Beanタイプで必須のクラス、EJB実行時環境、およびBeanの実行時の動作を管理するデプロイメント記述子ファイルについて簡単に説明します。

- EJBの構成要素

- EJBコンテナ

- オプションのEJBデプロイメント記述子

EJBの構成要素

BeanタイプごとにBeanクラスが必要になります。表2-1では、各タイプのEJBを構成する際にサポートされるクライアント・ビューと、追加で必要なクラスを定義しています。

注意:

EJB 2.1以前のAPIでは、ローカルおよびリモート・クライアントが、セッションBeanのローカルまたはリモート・ホームおよびローカルまたはリモート・コンポーネント・インタフェースによって、ステートフルまたはステートレス・セッションBeanにアクセスする必要がありました。これらのインタフェースはEJB 3.xでも使用し続けることができますが、EJB 2.1のリモートおよびローカル・クライアント・ビューは、シングルトン・セッションBeanではサポートされません。

詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のEJBのクラスとインタフェースの作成に関する項を参照してください。

表2-1 EJB 3.2でサポートされるクライアント・ビュー

クライアント・ビュー

セッションBeanのタイプ

追加で必要なクラス

リモート・クライアント

ステートフル、ステートレスおよびシングルトン・セッションBean

Beanのビジネス・メソッドとライフサイクル・メソッドを定義するリモート・ビジネス・インタフェース。

ローカル・クライアント

ステートフル、ステートレスおよびシングルトン・セッションBean

Beanのビジネス・メソッドとライフサイクル・メソッドを定義するローカル・ビジネス・インタフェース。

ローカル・インタフェースなし

ステートフル、ステートレスおよびシングルトン・セッションBean

Beanクラスのみ必要とします。

Webサービス・クライアント

ステートレスおよびシングルトン・セッションBean

JAX-WSまたはJAX-RPCクライアント・ビューAPIを使用してJAX-WSまたはJAX-RPCサービス・エンドポイントとしてアクセスされるWebサービス・エンドポイント。

EJBコンテナ

EJBコンテナとは、アプリケーション・サーバーにデプロイされたBeanの実行時コンテナです。このコンテナはアプリケーション・サーバーの起動時に自動的に作成され、Beanと以下のような実行時サービスの間のインタフェースとして機能します。

- ライフサイクル管理

- コード生成

- セキュリティ

- トランザクションの管理

- ロックと同時実行性制御

EJBメタデータ・アノテーション

WebLogic Server EJB 3.2プログラミング・モデルでは、Java EE 7メタデータ・アノテーション機能を使用して、アノテーション付きEJB 3.2 Beanファイルを作成し、標準Javaコンパイラでクラスをコンパイルします。生成されたクラスは、デプロイメント用のターゲット・モジュールにパッケージ化できます。実行時に、WebLogic Serverはアノテーションを解析して、必要な動作のアスペクトをBeanファイルに適用します。

詳細は、「アノテーション付きEJBクラスのプログラミング」を参照してください

オプションのEJBデプロイメント記述子

EJB 3.0以降では、EJBデプロイメント記述子ファイル(ejb-jar.xmlなど)を作成する必要がなくなりました。ただし、必要に応じて、引き続きXMLデプロイメント記述子を使用することはできます。競合がある場合、デプロイメント記述子の値がアノテーションの値をオーバーライドします。

EJB実装で引き続きデプロイメント記述子を使用する場合は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のEJBデプロイメント記述子に関する項を参照してください。

WebLogic Server EJBコンテナでは、次の3つのデプロイメント記述子がサポートされます。

- ejb-jar.xml: 標準Java EEデプロイメント記述子です。ejb-jar.xmlは、EJBを定義してEJBの標準的な構成設定を指定する際に使用できます。ejb-jar.xmlでは、一緒にデプロイされる複数のBeanを指定できます。

- weblogic-ejb-jar.xml: クラスタリング、キャッシング、トランザクションといったWebLogic Serverの機能と関連する要素を格納するWebLogic Server固有のデプロイメント記述子。このファイルは、BeanがWebLogic Server固有の機能を利用する場合は必須です。ejb-jar.xmlと同じように、weblogic-ejb-jar.xmlでは一緒にデプロイされる複数のBeanを指定できます。

- weblogic-cmp-jar.xml: エンティティBeanのコンテナ管理による永続性に関連する要素を格納するWebLogic Server固有のデプロイメント記述子。コンテナ管理による永続性を使用するエンティティBeanは、weblogic-cmp-jar.xmlファイルに指定する必要があります。

WebLogic Server EJBデプロイメント記述子の詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のデプロイメント記述子スキーマおよび文書型定義リファレンスに関する項を参照してください。

EJBのクライアントおよび通信

EJBは、サーブレット、Javaクライアント・アプリケーション、他のEJB、Webサービス、非Javaクライアントなどのサーバー側またはクライアント側オブジェクトからアクセスできます。EJBのクライアントは、アプリケーションが同じか別かに関係なく同じ方法でEJBにアクセスします。WebLogic Serverは、リモートで機能できるEJBのリモート・ホーム・インタフェースおよびリモート・ビジネス・インタフェースの実装を自動的に作成します。

EJBへのアクセス

クライアントは、インタフェースなしのビューまたはビジネス・インタフェースを介してエンタープライズBeanにアクセスします。エンタープライズBeanのインタフェースなしのビューでは、エンタープライズBean実装クラスのパブリック・メソッドをクライアントに公開します。エンタープライズBeanのインタフェースなしのビューを使用しているクライアントは、エンタープライズBean実装クラスまたはその実装クラスの任意のスーパークラスの任意のパブリック・メソッドを呼び出すことができます。ビジネス・インタフェースは、エンタープライズBeanのビジネス・メソッドを含む標準のJavaプログラミング言語インタフェースです。

エンタープライズBeanのクライアントは、エンタープライズBeanのインスタンスへの参照を取得します。そのためには、Javaプログラミング言語のアノテーションで依存関係インジェクションを使用するか、エンタープライズBeanインスタンスを検索するJNDI構文を使用してJNDIルックアップを実行します。

エンタープライズBeanインタフェースを取得する最も簡単な方法は、依存関係インジェクションです。Java EEサーバー管理対象の環境、JavaServer Faces Webアプリケーション、JAX-RS Webサービス、その他のエンタープライズBean、またはJava EEアプリケーション・クライアントの中で実行されるクライアントは、javax.ejb.EJBアノテーションを使用した依存関係インジェクションをサポートします。

Java SEアプリケーションなど、Java EEサーバー管理対象の環境外で実行されるアプリケーションは、明示的ルックアップを実行する必要があります。JNDIでは、Java EEコンポーネントを識別して明示的ルックアップを単純化するグローバル構文をサポートします。詳細は、「JNDIポータブル構文の使用」を参照してください。

ネットワークのオーバーヘッドのため、Beanにはリモート・クライアントからアクセスするよりも同じマシン上のクライアントからアクセスする方が効率的であり、クライアントが同じアプリケーションにあればさらに効率的です。

クライアントによるEJBへのアクセスのプログラミングの詳細は、Java EE 7チュートリアル(http://docs.oracle.com/javaee/7/tutorial/index.html)の「エンタープライズBean」の章のエンタープライズBeanへのアクセスに関する項を参照してください。

EJBの通信

WebLogic Server EJBは、以下のプロトコルを使用します。

- T3 - リモート・オブジェクトとの通信に使用します。T3は、Remote Method Invocation (RMI)プロトコルを実装するWebLogic独自のリモート・ネットワーク・プロトコルです。

- RMI - リモート・オブジェクトとの通信に使用します。RMIを使用すると、アプリケーションはネットワークの他のどこかにあるオブジェクトの参照を取得し、同じJVMでクライアントと共存しているかのようにそのオブジェクトのメソッドをクライアントの仮想マシンからローカルで呼び出すことができます。リモート・インタフェースのあるEJBはRMIオブジェクトです。WebLogic RMIの詳細は、『Oracle WebLogic Server RMIアプリケーションの開発』を参照してください。

- HTTP - EJBは、java.net.URLリソース接続ファクトリを使用してWebLogic Server環境外のWebサーバーとのHTTP接続を取得できます。詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のEJBの構成によるURLへのリクエストの送信に関する項を参照してください。

EJBが使用するネットワーク接続の属性は、EJBをWebLogic Serverカスタム・ネットワーク・チャネルにバインドすることによって指定できます。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・リソースの構成に関する項を参照してください。

EJBのセキュリティ

デフォルトでは、EJBのパブリック・メソッドはどのユーザーでも呼び出すことができます。そのため、EJBへのアクセスを制限する場合は、セキュリティ関連アノテーションを使用して、すべてのメソッドまたはメソッドのサブセットを呼び出すことができるロールを指定します。これは、「EJBへのアクセスにセキュリティを設定する」で説明します

また、セキュリティ・ロールを作成し、ロールにユーザーをマッピングするには、WebLogic Server管理コンソールでセキュリティ・レルムを更新します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理を参照してください。

セキュリティおよびEJBの追加情報は、以下を参照してください。

- Oracle WebLogic Serverセキュリティの理解のセキュリティの基礎に、認証、認可など、セキュリティ関連の基礎的な情報があります。

- WebLogicセキュリティ・サービスによるアプリケーションの開発のEnterprise JavaBeans (EJB)の保護では、EJBの認証と認可を構成する手順について説明されています。

- 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』には、WebLogic Server管理コンソールを使用してEJBの認証と認可を構成する手順が含まれています。

3 Enterprise JavaBeansの単純なサンプル

この章では、バージョン3.xのプログラミング・モデルを使用するEJBのJavaサンプルについて説明します。

この章の内容は以下のとおりです。

- EJB 3.xの単純なJavaサンプル

- WebLogic Serverでパッケージ化されたEJB 3.2のサンプル

- WebLogic Serverでパッケージ化されたEJB 3.1のサンプル

EJB 3.xの単純なJavaサンプル

次の項では、新しいメタデータ・アノテーション・プログラミング・モデルを使用するEJBの単純なJavaサンプルについて説明します。このガイド内のEJBをプログラミングする方法について説明しているいくつかの項では、これらのサンプルを参照する場合があります。

- インタフェースなしの単純なステートレスEJBのサンプル

- 単純なビジネス・インタフェースを使用するステートレスEJBのサンプル

- 単純なステートフルEJBのサンプル

- インターセプタ・クラスのサンプル

インタフェースなしの単純なステートレスEJBのサンプル

EJB 3.1のインタフェースなしのローカル・クライアント・ビュー・タイプでは、個別のローカル・ビジネス・インタフェースを必要とすることなく、ローカル・セッションBeanへのアクセスを提供して、コンポーネントでEJB Beanクラス・インスタンスを直接注入させることで、EJBの開発を単純化しています。

次に、ServiceBeanステートレス・セッションEJBのインタフェースなしの単純なビューのコードを示します。

package examples;
@Stateless
public class ServiceBean {
public void sayHelloFromServiceBean() {
System.out.println("Hello From Service Bean!");
}
}

このサンプル・コードで注目すべき主な点は以下のとおりです。

- このビュー以外にクライアント・ビューが公開されておらず、Beanクラスのimplements句が記述されていないので、EJBはこのインタフェースなしのビューを自動的に公開します。

- ServiceBean Beanファイルは、プレーンJavaファイルであるため、EJB固有のインタフェースを実装する必要はありません。

- クラス・レベルの@Statelessメタデータ・アノテーションは、EJBのタイプがステートレス・セッションであることを指定しています。

単純なビジネス・インタフェースを使用するステートレスEJBのサンプル

次に、ServiceBeanステートレス・セッションEJBの単純なビジネス・インタフェースのコードを示します。

package examples;
/**
* Business interface of the Service stateless session EJB
*/
public interface Service {
public void sayHelloFromServiceBean();
}

このコードは、Serviceビジネス・インタフェースに、1つのメソッドsayHelloFromServiceBean()が含まれていることを示します。このメソッドは、パラメータを取らず、voidを返します。

次に、上のServiceインタフェースを実装するBeanファイルのコードを示します。太字部分については、後ほど解説します。

package examples;
import javax.ejb.Stateless;
import javax.interceptor.ExcludeDefaultInterceptors;
/**
* Bean file that implements the Service business interface.
* Class uses following EJB 3.x annotations:
*   - @Stateless - specifies that the EJB is of type stateless session
*   - @ExcludeDefaultInterceptors - specifies any configured default
*      interceptors should not be invoked for this class
*/
@Stateless
@ExcludeDefaultInterceptors
public class ServiceBean
implements Service
{
public void sayHelloFromServiceBean() {
System.out.println("Hello From Service Bean!");
}
}

このサンプル・コードで注目すべき主な点は以下のとおりです。

- 標準のimport文を使用して、Beanファイルで使用するメタデータ・アノテーションをインポートしています。

import javax.ejb.Stateless;
import javax.interceptor.ExcludeDefaultInterceptors

EJB 3.1にのみ適用されるアノテーションは、javax.ejbパッケージに含まれています。他のJava EEバージョン6コンポーネントで使用できるアノテーションは、より一般的なパッケージ(javax.interceptor、javax.annotationなど)に含まれています。

- ServiceBean Beanファイルは、Serviceビジネス・インタフェースを実装するプレーンJavaファイルで、EJB固有のインタフェースを実装する必要はありません。つまり、Beanファイルには、2.xプログラミング・モデルでは必須だったライフサイクル・メソッド(ejbCreate、ejbPassivateなど)を実装する必要はないということです。

- クラス・レベルの@Statelessメタデータ・アノテーションは、EJBのタイプがステートレス・セッションであることを指定しています。

- クラス・レベルの@ExcludeDefaultInterceptorsアノテーションは、ejb-jar.xmlデプロイメント記述子ファイルでデフォルト・インターセプタが定義されている場合でも、このEJBのメソッド呼出しに対しては、そのデフォルト・インターセプタを呼び出さないことを指定しています。

単純なステートフルEJBのサンプル

次に、AccountBeanステートフル・セッションEJBの単純なビジネス・インタフェースのコードを示します。

package examples;
/**
* Business interface for the Account stateful session EJB.
*/
public interface Account {
public void deposit(int amount);
public void withdraw(int amount);
public void sayHelloFromAccountBean();
}

このコードは、Accountビジネス・インタフェースに3つのメソッド(deposit、withdraw、およびsayHelloFromAccountBean)が含まれていることを示します。

次に、上のAccountインタフェースを実装するBeanファイルのコードを示します。太字部分については、後ほど解説します。

package examples;
import javax.ejb.Stateful;
import javax.ejb.Remote;
import javax.ejb.EJB;
import javax.annotation.PreDestroy;
import javax.interceptor.Interceptors;
import javax.interceptor.ExcludeClassInterceptors;
/**
* Bean file that implements the Account business interface.
* Uses the following EJB annotations:
*    -  @Stateful: specifies that this is a stateful session EJB
*    -  @Remote - specifies the Remote interface for this EJB
*    -  @EJB - specifies a dependency on the ServiceBean stateless
*         session ejb
*    -  @Interceptors - Specifies that the bean file is associated with an
*         Interceptor class; by default all business methods invoke the
*         method in the interceptor class annotated with @AroundInvoke.
*    -  @ExcludeClassInterceptors - Specifies that the interceptor methods
*         defined for the bean class should NOT fire for the annotated
*         method.
*    -  @PreDestroy - Specifies lifecycle method that is invoked when the
*         bean is about to be destoryed by EJB container.
*
*/
@Stateful
@Remote({examples.Account.class})
@Interceptors({examples.AuditInterceptor.class})
public class AccountBean
implements Account
{
private int balance = 0;
@EJB(beanName="ServiceBean")
private Service service;
public void deposit(int amount) {
balance += amount;
System.out.println("deposited: "+amount+" balance: "+balance);
}
public void withdraw(int amount) {
balance -= amount;
System.out.println("withdrew: "+amount+" balance: "+balance);
}
@ExcludeClassInterceptors
public void sayHelloFromAccountBean() {
service.sayHelloFromServiceBean();
}
@PreDestroy
public void preDestroy() {
System.out.println("Invoking method: preDestroy()");
}
}

このサンプル・コードで注目すべき主な点は以下のとおりです。

- 標準のimport文を使用して、Beanファイルで使用するメタデータ・アノテーションをインポートしています。

import javax.ejb.Stateful;
import javax.ejb.Remote;
import javax.ejb.EJB;

import javax.annotation.PreDestroy;

import javax.interceptor.Interceptors;
import javax.interceptor.ExcludeClassInterceptors;

EJB 3.1にのみ適用されるアノテーションは、javax.ejbパッケージに含まれています。他のJava EE 6コンポーネントで使用できるアノテーションは、より一般的なパッケージ(javax.interceptor、javax.annotationなど)に含まれています。

- AccountBean Beanファイルは、Accountビジネス・インタフェースを実装するプレーンJavaファイルで、EJB固有のインタフェースを実装する必要はありません。つまり、Beanファイルには、2.xプログラミング・モデルでは必須だったライフサイクル・メソッド(ejbCreate、ejbPassivateなど)を実装する必要はないということです。

- クラス・レベルの@Statefulメタデータ・アノテーションは、EJBのタイプがステートフル・セッションであることを指定しています。

- クラス・レベルの@Remoteアノテーションは、EJBのリモート・インタフェースの名前(ここでは、ビジネス・インタフェースと同じAccount)を指定しています。

- クラス・レベルの@Interceptors({examples.AuditInterceptor.class})アノテーションは、Beanファイルに関連付けるインターセプタ・クラスを指定しています。通常、このクラスには、ビジネス・メソッド・インターセプタ・メソッドとライフサイクル・コールバック・インターセプタ・メソッドが含まれます。このクラスの詳細については、「インターセプタ・クラスのサンプル」を参照してください。

- フィールド・レベルの@EJBアノテーションは、アノテーション変数serviceに、依存先であるServiceBeanステートレス・セッションBeanのコンテキストを注入することを指定しています。注入されるフィールドのデータ型はServiceです。これは、ServiceBean EJBのビジネス・インタフェースです。sayHelloFromAccountBeanメソッド内の次のコードは、依存先であるServiceBeanのsayHelloFromServiceBeanメソッドを呼び出す方法を示しています。

service.sayHelloFromServiceBean();

- メソッド・レベルの@ExcludeClassInterceptorsアノテーションは、sayHelloFromAccountBeanメソッドに対しては、関連付けられているインターセプタ・クラス(AuditInterceptor)で指定されている@AroundInvokeメソッドを呼び出さないことを指定しています。

- メソッド・レベルの@PreDestroyアノテーションは、EJBコンテナがAccountBeanのインスタンスを破棄する前にpreDestroyメソッドを呼び出すことを指定しています。ビジネス・メソッドおよびライフサイクル・コールバックのインターセプタ・メソッドは、インターセプタ・クラスを関連付ける方法だけでなく、このようにBeanファイル自体の中で指定することもできます。

インターセプタ・クラスのサンプル

次に、インターセプタ・クラスのサンプル・コードを示します。このAuditInterceptorクラスは、上のサンプルで示したAccountBeanステートフル・セッションBeanから@Interceptors({examples.AuditInterceptor.class})アノテーションで参照しているインターセプタ・クラスです。太字部分については、後ほど解説します。

package examples;
import javax.interceptor.AroundInvoke;
import javax.interceptor.InvocationContext;
import javax.ejb.PostActivate;
import javax.ejb.PrePassivate;
/**
* Interceptor class.  The interceptor method is annotated with the
*  @AroundInvoke annotation.
*/
public class AuditInterceptor {
public AuditInterceptor() {}
@AroundInvoke
public Object audit(InvocationContext ic) throws Exception {
System.out.println("Invoking method: "+ic.getMethod());
return ic.proceed();
}
@PostActivate
public void postActivate(InvocationContext ic) {
System.out.println("Invoking method: "+ic.getMethod());
}
@PrePassivate
public void prePassivate(InvocationContext ic) {
System.out.println("Invoking method: "+ic.getMethod());
}
}

このサンプル・コードで注目すべき主な点は以下のとおりです。

- これまでのサンプルと同様に、ファイル内で使用するメタデータ・アノテーションをインポートしています。

import javax.interceptor.AroundInvoke;
import javax.interceptor.InvocationContext;
import javax.ejb.PostActivate;
import javax.ejb.PrePassivate;

- インターセプタ・クラスはプレーンJavaクラスです。

- このクラスには、次のような空のコンストラクタが含まれています。

public AuditInterceptor() {}

- メソッド・レベルの@AroundInvokeは、ビジネス・メソッド・インターセプタ・メソッドを指定しています。このアノテーションは、1つのインターセプタ・クラス内で一度だけ使用できます。

- メソッド・レベルの@PostActivateおよび@PrePassivateアノテーションは、EJBコンテナがBeanを再アクティブ化した後とBeanをパッシブ化する前に呼び出すメソッドをそれぞれ指定しています。

注意:

これらのライフサイクル・コールバック・インターセプタ・メソッドは、ステートフル・セッションBeanにのみ適用されます。

WebLogic Serverでパッケージ化されたEJB 3.2のサンプル

次の項では、Oracle WebLogic Serverに付属するパッケージ化されたJava EE 7のサンプル(EJB 3.2の新機能のデモ)について説明します。

- EJB 3.2: セッションBeanライフサイクルを使用するサンプル

- EJB 3.2: メソッドのないリスナーを使用するメッセージドリブンBeanのサンプル

EJB 3.2: セッションBeanライフサイクルを使用するサンプル

このサンプルは、@AroundConstructおよび@AroundInvokeを含む、新しいセッションBeanライフサイクル・コールバック・インターセプタ・メソッドAPIを示します。

WebLogic Serverをインストールすると、次のディレクトリにサンプルがインストールされます。

EXAMPLES_HOME/examples/src/examples/javaee7/ejb/lifecylce

EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

EJB 3.2: メソッドのないリスナーを使用するメッセージドリブンBeanのサンプル

このサンプルは、メソッドのないリスナー・インタフェースを実装するメッセージドリブンBeanを示します。メソッドのないインタフェースを実装するBeanは、java.lang.Objectを除き、メッセージ・リスナー・メソッドとして、Beanクラスおよびスーパークラスのすべての非静的パブリック・メソッドを公開します。

WebLogic Serverをインストールすると、次のディレクトリにサンプルがインストールされます。

EXAMPLES_HOME/examples/src/examples/javaee7/ejb/no-method-listener

EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

WebLogic Serverでパッケージ化されたEJB 3.1のサンプル

次の項では、Oracle WebLogic Serverに付属するパッケージ化されたJava EE 6のサンプル(EJB 3.1の新機能のデモ)について説明します。

- EJB 3.1: シングルトン・セッションBeanのサンプル

- EJB 3.1: 非同期メソッドEJBのサンプル

- EJB 3.1: カレンダベース・タイマーEJBのサンプル

- EJB 3.1: 単純化されたインタフェースなしのプログラミングおよびWARファイルでのパッケージ化

- EJB 3.1: EJBでポータブル・グローバルJNDI名を使用するサンプル

- EJB 3.1: Java SEで組込み可能なEJBコンテナを使用するサンプル

- EJB 3.0: セッションBeanからエンティティを呼び出すサンプル

EJB 3.1: シングルトン・セッションBeanのサンプル

このサンプルは、EJB 3.1シングルトン・セッションBeanの使用方法を示しています。これはアプリケーション開発者に、特定のJava仮想マシン(JVM)のアプリケーションで、セッションBeanが一度インスタンス化されることが保証される正式なプログラミング構造を提供します。このサンプルで、@SingletonセッションBeanは、中央カウンタ・サービスを提供します。カウンタEJBは、Javaクライアントから呼び出され、それが使用されていることを示します。クライアントが複数回呼び出されると、カウントはそのたびに1ずつ増分されます。

WebLogic Serverをインストールすると、次のディレクトリにサンプルがインストールされます。

EXAMPLES_HOME/examples/src/examples/javaee6/ejb/singletonBean

EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

EJB 3.1: 非同期メソッドEJBのサンプル

このサンプルは、EJB 3.1の非同期メソッドの呼出しの使用方法について示します。@AsynchronousアノテーションをEJBクラスまたは特定のメソッドに追加すると、メソッドが呼び出されたときに、クライアントに即座に制御を戻すようにEJBコンテナに指示します。メソッドはFutureオブジェクトを返し、これによりクライアントはメソッド呼出しのステータスをチェックして、非同期に生成される結果の値を取得できます。

このサンプルでは、@Stateless Beanはクラス・レベルでアノテーションが付けられます。@Asynchronousはそのメソッドがすべて非同期であることを示し、それぞれのメソッドで長時間の計算をシミュレートします。サーブレットを使用して様々な非同期メソッドをコールし、呼び出しと完了回数を追跡して、メソッド・コールの非同期の動作を示します。

WebLogic Serverをインストールすると、次のディレクトリにサンプルがインストールされます。

EXAMPLES_HOME/examples/src/examples/javaee6/ejb/asyncMethodOfEJB

EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、Oracle WebLogic Serverの理解のサンプル・アプリケーションとコード例を参照してください。

EJB 3.1: カレンダベース・タイマーEJBのサンプル

このサンプルは、EJB 3.1の豊富なスケジューリング機能を示しています。このスケジューリング機能は、EJBメソッドに配置できるCRONスタイルのスケジュール定義という形式をとり、定義されたスケジュールに応じてメソッドが自動的に呼び出されます。このサンプルは、メソッドがコールされたときのタイムスタンプを生成して保存する、@SingletonセッションBeanのメソッド用に定義された@Scheduleアノテーションの使用方法を示しています。対応するサーブレットが提供され、その中にTimerBeanが注入されて、ブラウザに表示されるタイムスタンプのリストが取得されます。

WebLogic Serverをインストールすると、次のディレクトリにサンプルがインストールされます。

EXAMPLES_HOME/examples/src/examples/javaee6/ejb/calendarStyledTimer

EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

EJB 3.1: 単純化されたインタフェースなしのプログラミングおよびWARファイルでのパッケージ化

このサンプルは、EJB 3.1で提供された単純化されたプログラミングおよびパッケージ化モデルの変更を示しています。前のバージョンではJavaインタフェースを使用する必要がありましたが、EJB 3.1ではその必要性がなくなったので、古いプレーンJavaオブジェクトにアノテーションを付けてEJBコンポーネントとして使用できます。EJBコンポーネントを直接Webアプリケーションの中に配置する機能によりさらに単純化が進んだので、WebコンポーネントとEJBコンポーネントを保存するアーカイブを生成して、それらをともにエンタープライズ・アーカイブ(EAR)ファイルに組み込む必要がなくなりました。

このサンプルでは、@Statelessアノテーションを古いプレーンJavaクラスに指定し、これをEJBセッションBeanとして公開します。これはさらに、@EJBアノテーションを使用して@WebServletクラスに注入されることで、それがEJBモジュールとして使用されていることが示されます。EJBセッションBeanとサーブレット・クラスは、ともに単一のWARファイルにパッケージ化されてデプロイメントされます。これにより、Java EE 6で使用できる単純化されたパッケージおよびデプロイメントの変更について説明します。

WebLogic Serverをインストールすると、次のディレクトリにサンプルがインストールされます。

EXAMPLES_HOME/examples/src/examples/javaee6/ejb/noInterfaceViewInWAR

EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

EJB 3.1: EJBでポータブル・グローバルJNDI名を使用するサンプル

このサンプルは、EJB 3.1で使用可能な、ポータブル・グローバルJNDIネーミング・オプションの使用方法を示しています。ポータブル・グローバルJNDIでは、一般的でよく知られているネームスペースを多数提供し、そのネームスペースでjava:global[/<アプリケーション名>]/<モジュール名>/<Bean名>というパターンを使用して、EJBコンポーネントを登録およびルックアップできます。これにより、EJBコンポーネントをJNDIに登録する方法および場所、およびそれらをアプリケーションでルックアップおよび使用する方法を標準化します。このサンプルでは、サーブレットでポータブルJNDI名java:module/HelloBeanを使用してEJBセッションBeanをルックアップします。

WebLogic Serverをインストールすると、次のディレクトリにサンプルがインストールされます。

EXAMPLES_HOME/examples/src/examples/javaee6/ejb/portableGlobalJNDIName

EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

EJB 3.1: Java SEで組込み可能なEJBコンテナを使用するサンプル

このサンプルは、EJB 3.1で使用可能な組込み可能なEJBコンテナを使用することで、クライアント・コードとそれに対応するエンタープライズBeanをJava EEサーバーにデプロイしなくてもJava SE環境で実行できるようにする方法を示しています。

このサンプルでは、組込み可能なWebLogic EJBコンテナを使用して、Java SE環境から呼び出されるすべてのユーザー・オブジェクトを表示します。アノテーション@Startupおよび@PostConstructを使用してアプリケーションを起動すると、シングルトン・コンポーネントInitBeanの即時初期化時にすべてのユーザー・オブジェクトが事前定義されます。EJBContainerのインスタンスがJavaクライアントUserClientで作成され、セッションBean参照UserBeanをルックアップし、アプリケーションでビジネス・メソッドviewUsersを呼び出します。

サンプルの実行後、クライアント・クラスが自動的に実行され、サンプルが作成されたコマンド・シェルに実行時メッセージが出力されます。すべての既存のユーザー・オブジェクトがサンプル・データベースから取得され、コマンド・シェルにその詳細が表示されます。

WebLogic Serverをインストールすると、次のディレクトリにサンプルがインストールされます。

EXAMPLES_HOME/examples/src/examples/javaee6/ejb/embeddableContainer

EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

EJB 3.0: セッションBeanからエンティティを呼び出すサンプル

セッションBeanからエンティティを呼び出すサンプルについては、配布キットに含まれているEJB 3.0のサンプルを参照してください。WebLogic Serverをインストールすると、次のディレクトリにサンプルがインストールされます。

EXAMPLES_HOME/examples/src/examples/ejb/ejb30

EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

4 Enterprise JavaBeansの反復的な開発

この章では、EJB 3.2の一般的な実装プロセスを説明し、EJBをWebLogic Serverで実行する方法について説明します。

この章の内容は次のとおりです:

- EJB開発プロセスの概要

- ソース・ディレクトリを作成する

- アノテーション付きEJBクラスのプログラミング

- EJBインタフェースのプログラミング

- インターセプタのプログラミング(省略可能)

- EJBタイマー・サービスのプログラミング(省略可能)

- EJBクライアントへのアクセスのプログラミング

- トランザクションのプログラミングと構成

- Javaソースをコンパイルする

- デプロイメント記述子の作成と編集(省略可能)

- EJBのパッケージ化

- EJBのデプロイメント

EJB開発プロセスの概要

この節では、EJB 3.2の開発プロセスを簡単に説明します。主な実装タスクと関連する結果について説明します。

次の項の大部分では、EJB 3.2プログラミング・モデルについて説明しています。EJB 3.xとEJB 2.xでのプログラミング・モデルの相違点については、一部で簡単に触れているのみです。EJB 2.xに精通しており、2つのモデルの相違点について詳しく知りたい場合は、「EJBの新機能と変更された機能」を参照してください

表4-1 EJB開発タスクと結果

#

手順

説明

結果

1

ソース・ディレクトリを作成する

Javaソース・ファイルのディレクトリ構造を作成し、必要に応じてデプロイメント記述子を作成します。

ローカル・ドライブ上のディレクトリ構造

2

アノテーション付きEJBクラスのプログラミング

インタフェースを実装するJavaファイルを作成し、EJBの動作を記述するEJB 3.2メタデータ・アノテーションを含めます。

.javaファイル

3

EJBインタフェースのプログラミング

EJBを記述するインタフェースなしのビューまたはビジネス・インタフェースを作成します。

各インタフェースの.javaファイル

4

インターセプタのプログラミング(省略可能)

必要に応じて、ビジネス・メソッド呼出しやライフサイクル・コールバック・イベントをインターセプトするインターセプタを記述したインターセプタ・クラスを作成します。

各インターセプタ・クラスの.javaファイル

5

EJBタイマー・サービスのプログラミング(省略可能)

必要に応じて、タイマー・オブジェクトが時限イベントの時刻を過ぎたときに発生するコールバックをスケジューリングするタイマーを作成します。

メタデータの変更(自動タイマーの場合)またはクラスの変更(プログラムによるタイマーの場合)。

6

EJBクライアントへのアクセスのプログラミング

依存関係インジェクションまたはJNDIルックアップを使用してEJBの参照を取得します。

メタデータの変更(アノテーションの設定やデプロイメント記述子の設定)またはクライアントに対するコード変更。

7

トランザクションのプログラミングと構成

コンテナ管理のトランザクションまたはBean管理のトランザクションをプログラミングします。

メタデータおよび場合によっては例外を処理するためのロジック(再試行ロジックまたはsetRollbackOnlyの呼出し)。

8

Javaソースをコンパイルする

ソース・コードをコンパイルします。

各クラスおよびインタフェースの.classファイル

9

デプロイメント記述子の作成と編集(省略可能)

必要に応じて、EJB固有のデプロイメント記述子を作成します。この手順は、EJB 3.2プログラミング・モデルを使用する場合は不要です。

- ejb-jar.xml

- weblogic-ejb-jar.xml (WebLogic Server固有の機能を制御する要素が格納されます)。

10

EJBのパッケージ化

コンパイル済みのクラス(および、必要に応じてデプロイメント記述子)をデプロイメント用にパッケージ化します。

状況によっては、ファイルをアーカイブせずにディレクトリ形式で展開しておくことも可能です。

アーカイブ・ファイル(EJB JARまたはエンタープライズ・アプリケーションEAR)、または対応する展開済みディレクトリ

11

EJBのデプロイメント

選択したステージング・モードに従って、アーカイブまたはアプリケーション・ディレクトリのターゲットとして目的の管理対象サーバーまたはWebLogic Serverクラスタを設定します。

デプロイしたEJBでサービスを呼び出せます。

ソース・ディレクトリを作成する

EJB 3.2モジュールをアセンブルするソース・ディレクトリを作成します。

ソース・ファイルと出力ファイルを並列ディレクトリ構造に分離する分割開発ディレクトリ構造をお薦めします。分割ディレクトリ構造を準備し、EJB 3.2をエンタープライズ・アプリケーション・アーカイブ(EAR)としてパッケージ化する方法については、Oracle WebLogic Serverアプリケーションの開発の分割開発ディレクトリ環境の概要を参照してください。

JARをパッケージ化するためのディレクトリ構造

EJBをJARファイルにパッケージ化してデプロイする場合は、クラス・ファイル用のディレクトリを作成します。EJBデプロイメント記述子(EJB 3.2プログラミング・モデルでは、オプションですがサポートはされています)も使用する場合は、それをMETA-INF/ejb-jar.xmlとしてパッケージ化できます。

詳細は、「JARでのEJBのパッケージ化」を参照してください

例4-1 JARをパッケージ化するためのディレクトリ構造

myEJBjar/
META-INF/
ejb-jar.xml
weblogic-ejb-jar.xml
weblogic-cmp-jar.xml
foo.class
fooBean.class

WARをパッケージ化するためのディレクトリ構造

EJBは、EJBクラスをWEB-INF/classesという名前のサブディレクトリに入れるか、WEB-INF/libディレクトリ内のJARファイルに入れることで、Webアプリケーション・モジュール(WAR)に直接パッケージ化することもできます。必要に応じて、EJBデプロイメント記述子も使用する場合は、それをWEB-INF/ejb-jar.xmlとしてパッケージ化できます。

注意:

EJB 2.1エンティティBeanおよびEJB 1.1エンティティBeanは、WARファイル内ではサポートされません。これらのコンポーネント・タイプは、スタンドアロンのejb-jarファイルまたはEARファイル内でパッケージ化されたejb-jarファイル内でのみパッケージ化する必要があります。

詳細は、「WARでのEJBのパッケージ化」を参照してください

例4-2 WARをパッケージ化するためのディレクトリ構造

myEJBwar/
WEB-INF/
ejb-jar.xml
weblogic.xml
weblogic-ejb-jar.xml
/classes
foo.class
fooServlet.class
fooBean.class

アノテーション付きEJBクラスのプログラミング

EJB Beanクラスは、EJBプログラミングの主要なアーティファクトで、EJBビジネス・インタフェースを実装し、EJBメタデータ・アノテーションを含みます。EJBメタデータ・アノテーションの用途としては、EJBコンテナへのセマンティクスおよび要件の指定、コンテナ・サービスの要求、アプリケーション・デプロイヤやコンテナ・ランタイムへの構造情報および構成情報の提供などがあります。

EJB 3.2プログラミング・モデルで必須なアノテーションは、EJBのタイプを指定する@javax.ejb.Stateful、@javax.ejb.Stateless、または@javax.ejb.MessageDrivenのいずれか1つのみです。他にもさまざまなアノテーションを使用してEJBを細かく構成できますが、それらのアノテーションには一般的なデフォルト値が設定されているため、デフォルト以外の動作を設定したい場合を除けば、Beanクラス内で明示的にそれらのアノテーションを使用する必要はありません。このようなプログラミング・モデルにより、一般的な動作を実行するEJBのプログラミングが非常に簡単になっています。

Beanクラスのプログラミングの詳細やサンプルについては、「アノテーション付きEJBクラスのプログラミング」を参照してください。

EJBインタフェースのプログラミング

クライアントは、インタフェースなしのビューまたはビジネス・インタフェースを介してエンタープライズBeanにアクセスします。

インタフェースなしのクライアント・ビューを使用したEJBへのアクセス

EJB 3.2のインタフェースなしのローカル・クライアント・ビュー・タイプでは、個別のローカル・ビジネス・インタフェースを必要とすることなく、ローカル・セッションBeanへのアクセスを提供して、コンポーネントでEJB Beanクラス・インスタンスを直接注入させることで、EJBの開発を単純化しています。

インタフェースなしのビューは、EJB 3.0ローカル・ビューと同様に動作します。たとえば、参照渡しのコールのセマンティクスおよびトランザクションやセキュリティ伝播などの機能をサポートします。ただし、インタフェースなしのビューでは、個別のインタフェースは必要ありません。つまり、Beanクラスのすべてのパブリック・メソッドは、コール元に自動的に公開されます。デフォルトでは、空のimplements句を持ち、他のローカルまたはリモート・クライアント・ビューを定義しないセッションBeanは、インタフェースなしのクライアント・ビューを公開します。

次のリンクにアクセスして、インタフェースなしのクライアント・ビューのコード・サンプルを検索できます。

- インタフェースなしの単純なステートレスEJBのサンプル

- EJB 3.1: 単純化されたインタフェースなしのプログラミングおよびWARファイルでのパッケージ化

- EJB 3.2: メソッドのないリスナーを使用するメッセージドリブンBeanのサンプル

インタフェースなしのクライアント・ビューの実装の詳細は、Java EE 7チュートリアル(http://docs.oracle.com/javaee/7/tutorial/index.html)の「エンタープライズBean」の章のインタフェースなしのビューを使用したローカル・エンタープライズBeanへのアクセスに関する項を参照してください。

ビジネス・インタフェースを使用したEJBへのアクセス

EJB 3.2ビジネス・インタフェースは、EJBのすべてのビジネス・メソッドの完全なシグネチャを記述するプレーンJavaインタフェースです。たとえば、Account EJBが顧客の当座預金口座を表す場合であれば、そのビジネス・インタフェースには顧客がその口座を管理するためのメソッド(withdraw、deposit、balanceなど)を含めます。

ビジネス・インタフェースは、他のインタフェースを拡張できます。メッセージドリブンBeanの場合であれば、ビジネス・インタフェースはメッセージ・リスナー・インタフェースにするのが一般的です。どのメッセージング・リスナー・インタフェースにするかは、そのBeanで使用するメッセージングの種類によって決まります。たとえば、JMSの場合はjavax.jms.MessageListenerになります。セッションBeanのインタフェースには、このような明確な種類はありません。ビジネス・ニーズに合わせて、どのようなインタフェースでも使用できます。

注意:

EJB 3.2ビジネス・インタフェースの唯一の要件は、EJB 2.xと同様に、javax.ejb.EJBObjectまたはjavax.ejb.EJBLocalObjectを拡張してはいけないことです。

ステートレスおよびステートフル・セッションBeanによって実装されたビジネス・インタフェースのサンプルについては、「単純なビジネス・インタフェースを使用するステートレスEJBのサンプル」および「単純なステートフルEJBのサンプル」を参照してください。

ビジネス・インタフェースの指定に関する詳細やサンプルは、「ビジネス・インタフェースとその他のインタフェースを指定する」を参照してください。

ビジネス・インタフェース・アプリケーション例外

EJBのビジネス・メソッドを設計する場合は、EJBのビジネス・インタフェースのメソッドのthrows句にアプリケーション例外を定義できます。「アプリケーション例外」とは、Beanクラス内に作成したプログラムからクライアントに、アプリケーション・レベルの異常な状態を警告するための例外です。たとえば、顧客が当座預金口座の引出し可能額を超える金額を引き出そうとしたときに、その口座を表すAccount EJBのwithdraw()メソッドからアプリケーション例外を送出できます。

アプリケーション例外は、システム例外とは異なります。システム例外は、データベース管理システムが利用できないなど、システム・レベルの例外をクライアントに警告するためにEJBコンテナからスローされる例外です。システム・レベルのエラーが、アプリケーション例外として報告されないようにしてください。

また、インタフェースがリモート・ビジネス・インタフェースである場合や、Beanクラスに@WebService JWSアノテーションが含まれている場合、およびメソッドに@WebMethodアノテーションが含まれている場合でも、ビジネス・メソッドがjava.rmi.RemoteException例外を送出しないようにする必要があります。唯一の例外は、ビジネス・インタフェースがjava.rmi.Remoteを拡張している場合です。EJBコンテナでプロトコル・レベルの問題が発生すると、基底のRemoteExceptionをラップしたEJBExceptionが送出されます。

注意:

@WebServiceおよび@WebMethodアノテーションは、javax.jwsパッケージに含まれています。これらのアノテーションは、EJBにWebサービスを実装すること、およびEJBビジネスをパブリックなWebサービス操作として公開することを指定するために使用します。これらのアノテーションの詳細、およびWebサービスのプログラミング全般については、『Oracle WebLogic Server JAX-WS Webサービスの開発』を参照してください。

EJBでのジェネリックスの使用

EJB 3.2プログラミング・モデルでは、ビジネス・インタフェースにおいてクラス・レベルでジェネリックスを使用できます。

ジェネリックスを使用する場合のベスト・プラクティスとしては、まずジェネリックスを使用するスーパーインタフェースを定義し、実際のビジネス・インタフェースでは特定のデータ型を使用してこのスーパーインタフェースを拡張することをお薦めします。

次に、この方法のサンプルを示します。まず、ジェネリックスを使用するスーパーインタフェースをプログラミングします。

public interface RootI<T> {
public T getObject();
public void updateObject(T object);
}

次に、実際のビジネス・インタフェースをプログラミングし、特定のデータ型でRootI<T>を拡張します。

@Remote
public interface StatelessI extends RootI<String> { }

最後に、実際のステートレス・セッションBeanをプログラミングしてビジネス・インタフェースを実装します。メソッドの実装では、指定したデータ型(この場合はString)を使用します。

@Stateless
public class StatelessSample implements StatelessI {
public String getObject() {
return null;
}
public void updateObject(String object) {
}
}

ビジネス・インタフェースまたはクラスで型変数を定義しても削除されます。この場合、ビジネス・インタフェースがBeanクラスによって他のジェネリック情報ではなくその型パラメータの上限値でパラメータ化されている場合のみ、EJBアプリケーションを正常にデプロイすることができます。たとえば、次の例の上限値はObjectです。

public class StatelessSample implements StatelessI<Object> {
public Object getObject() {
return null;
}
public void updateObject(Object object) {
}
}

ビジネス・オブジェクトのシリアライズとデシリアライズ

ビジネス・オブジェクトのシリアライズとデシリアライズは、以下のインタフェースでサポートされます。これらのインタフェースは、すべてのビジネス・オブジェクトで実装されます。

- weblogic.ejb.spi.BusinessObject

- weblogic.ejb.spi.BusinessHandle

BusinessObject._WL_getBusinessObjectHandle()メソッドを使用して、ビジネス・ハンドル・オブジェクトを取得し、シリアライズします。

ビジネス・オブジェクトをデシリアライズするには、ビジネス・ハンドル・オブジェクトをデシリアライズし、BusinessHandle.getBusinessObject()メソッドを使用してビジネス・オブジェクトを取得します。

インターセプタのプログラミング(省略可能)

インターセプタは、ビジネス・メソッドの呼出しやライフサイクル・コールバック・イベントをインターセプトするメソッドです。

インターセプタ・メソッドは、実際のBeanクラス内に定義できますが、Beanクラスとは別にインターセプタ・クラスをプログラミングして@javax.ejb.InterceptorアノテーションでBeanクラスに関連付けることもできます。

インターセプタを使用するBeanクラスのプログラミングについては、「ビジネス・メソッドまたはライフサイクル・コールバック・イベントのインターセプタを指定する」を参照してください。

EJBタイマー・サービスのプログラミング(省略可能)

WebLogic Serverは、EJB 3.2仕様で定義されているEJBタイマー・サービスをサポートしています。EJBタイマー・サービスは、EJB 3.2仕様のとおり、時間ベースのイベントに対してコールバックをスケジュールできるコンテナ管理によるサービスです。コンテナは、時限イベントに関する信頼性の高いトランザクション通知サービスを提供します。タイマー通知は、カレンダベースのスケジュールに応じて、特定の時刻、特定の経過時間後、または特定の反復間隔で発生するようにスケジュールできます。

タイマー・サービスは、EJBコンテナで実装されます。エンタープライズBeanは、EJBContextインタフェースを介して、またはJNDIネームスペースのルックアップを介して、依存関係インジェクションによってこのサービスにアクセスします。

タイマー・サービスは、大まかなタイマー・サービスとして使用するように設計されています。大量のタイマー・オブジェクトを使用してデータ・セットに対して同じタスクを実行するより、少数のタイマーを使用して大量のタスクを実行することをお薦めします。たとえば、従業員の経費レポートを表すEJBがあるとします。各経費レポートは、マネージャの承認を受けてから処理されなければなりません。この場合、1つのEJBタイマーを使用してすべての未決の経費レポートを定期的に検査し、担当のマネージャに対して、承認待ちのレポートを決裁するように促す電子メールを送信できます。

タイマー・サービスの概要

タイマー・サービスは、タイマーのプログラムによる作成およびキャンセルのほか、Beanに関連付けられているタイマーの検索のためのメソッドを提供します。タイマーは、Beanクラスまたはデプロイメント記述子のメタデータに基づいて、デプロイメント時にコンテナにより自動的に作成することもできます。タイマー・オブジェクトは、ステートレス・セッションBean、シングルトン・セッションBean、メッセージドリブンBean、および2.1エンティティBean用に作成できます。タイマーは、ステートフル・セッションBeanでは作成できません。

注意:

2.1エンティティBeanでは、カレンダベースのタイマー、自動で作成されるタイマー、および非永続タイマー機能はサポートされません。

タイマーは、時限コールバックをスケジューリングするために作成されます。タイマー・サービスを使用するエンタープライズBeanのBeanクラスでは、次のようなタイムアウト・コールバック・メソッドを1つ以上を提供する必要があります。

- プログラムによるタイマー - プログラムで作成されたタイマーの場合、このメソッドはTimeoutアノテーションの付いたメソッドになります。Beanでjavax.ejb.TimedObjectインタフェースを実装することもできます。javax.ejb.TimedObjectインタフェースは、単一のメソッド、タイマー・コールバック・メソッドejbTimeoutを備えています。

- 自動タイマー - 自動で作成されるタイマーの場合、タイムアウト・メソッドは、Scheduleアノテーションの付いたメソッドになります。

- 2.1エンティティBeanタイマー - 2.1エンティティBean用に作成されるタイマーは、エンティティBeanのIDと関連付けられます。ステートレス・セッションBeanまたはメッセージドリブンBean用に作成されるタイマーのタイムアウト・コールバック・メソッド呼出しは、プールされた状態で任意のBeanインスタンスで呼び出すことができます。

カレンダベースのEJBタイマー

EJB 31。タイマー・サービスでは、カレンダベースのEJBタイマー式をサポートします。このスケジューリング機能では、CRONスタイルのスケジュール定義という形式をとっています。これは、EJBメソッドに配置され、定義されたスケジュールに応じてメソッドを自動的に呼び出せます。

注意:

EJB 2.xエンティティBeanでは、カレンダベースのタイマーはサポートされません。

カレンダベースのタイマーは、javax.ejb.TimerServiceの2つのメソッドを使用してプログラム的に作成できます。これらは、引数としてjavax.ejb.ScheduleExpressionを受け取ります。タイマーを作成する前に、ScheduleExpressionを作成してデータを入力します。自動カレンダベース・タイマーを作成する場合、javax.ejb.Scheduleアノテーション(および対応するejb-jar.xml要素)には、カレンダベースのタイマー式を構成できる多数の属性が含まれます。

カレンダベースの時間式の7つの属性の詳細は、Enterprise JavaBeans 3.2仕様(JSR-345)(http://jcp.org/en/jsr/summary?id=345)のカレンダベースのタイマー式に関する第18.2.1項を参照してください。

自動作成されるEJBタイマー

EJB 3.2タイマー・サービスでは、Beanクラスまたはデプロイメント記述子のメタデータに基づくタイマーの自動作成をサポートします。これによりBean開発者は、Bean呼出しに依存せずにタイマーをスケジューリングし、プログラムでいずれかのTimer Serviceタイマー作成メソッドを呼び出すことができます。自動作成されるタイマーは、アプリケーション・デプロイメントの結果としてコンテナで作成されます。

javax.ejb.Scheduleアノテーションを使用して、特定のタイムアウト・スケジュールを持つタイマーを自動的に作成できます。このアノテーションは、そのスケジュールに関連付けられるタイマー・コールバックを受け取るBeanクラス(またはスーパークラス)のメソッドに適用されます。javax.ejb.Schedulesアノテーションを使用して、複数の自動タイマーを単一のタイムアウト・コールバック・メソッドに適用できます。

クラスタ化EJBタイマー実装を使用する場合、EJBがデプロイされているサーバー数にかかわらず、それぞれのScheduleアノテーションは単一の永続タイマーに対応します。

非永続タイマー

デフォルトでは、EJBタイマーは永続します。非永続タイマーは、その存続時間が、タイマーが作成されたJVMに関係するタイマーです。非永続タイマーは、アプリケーションの停止、コンテナのクラッシュ、タイマーが起動されたJVMの失敗/停止のイベントが発生すると、キャンセルと見なされます。

注意:

EJB 2.xエンティティBeanでは、非永続タイマーはサポートされません。

非永続タイマーは、プログラムで作成することも自動的に作成することもできます(@Scheduleまたはデプロイメント記述子を使用します)。

自動の非永続タイマーを指定するには、@Scheduleアノテーションの永続属性をfalseに設定します。自動の非永続タイマーでは、コンテナが配信される各JVMのアプリケーションの初期化時に、コンテナで新しい非永続タイマーを作成します。

クラスタ化EJBタイマー・サービスとローカルEJBタイマー・サービス

EJBタイマー・サービスは、2つのタイプ(クラスタまたはローカル)を構成することができます。

クラスタ化EJBタイマー・サービス

クラスタ化EJBタイマー・サービスには、次の利点があります。

- 可視性に優れています。
クラスタ内のすべてのノードからタイマーにアクセスできます。たとえば、javax.ejb.TimerService.getTimers()メソッドを使用すると、EJBに対して作成されたクラスタに含まれるすべてのステートレス・セッションBeanタイマーまたはメッセージドリブンBeanタイマーの完全なリストが返されます。エンティティBeanの主キーをgetTimers()メソッドに渡すと、そのエンティティBeanのタイマーのリストが返されます。

- 自動ロード・バランシングおよびフェイルオーバー
クラスタ化EJBタイマー・サービスは、ジョブ・スケジューラのロード・バランシング機能とフェイルオーバー機能を利用できます。

クラスタ化EJBタイマー・サービスの構成については、「クラスタ化EJBタイマーの構成」を参照してください

ローカルEJBタイマー・サービス

ローカルEJBタイマー・サービスは、ローカルEJBタイマー・サービスが作成されたサーバー上でのみ実行され、そのサーバー上のBeanにしか認識されません。ローカルEJBタイマー・サービスを使用する場合、クラスタ化EJBタイマー・サービスとは異なり、クラスタ、データベース、JDBCデータ・ソース、またはリース・サービスを構成する必要はありません。

ローカルEJBタイマー・オブジェクトは、別のサーバーに移行できません。タイマー・オブジェクトは、サーバー全体の一部としてのみ移行できます。EJBタイマーが存在するサーバーが何らかの理由でダウンした場合、サーバーを再起動するか、またはサーバー全体を移行しなければタイマーを実行できません。

注意:

クラスタ化された環境では、ローカル・タイマー実装に厳密な制限があるため、ローカル・タイマーを使用しないことをお薦めします。そのかわりに、クラスタ化されたタイマー実装を使用します。クラスタ化された環境でローカル・タイマー実装が使用されるように構成されている場合、デプロイメント時に警告がスローされます。

クラスタ化EJBタイマーの構成

注意:

クラスタ化EJBタイマーの利点については、「クラスタ化EJBタイマー・サービスとローカルEJBタイマー・サービス」を参照してください

EJBタイマーのクラスタリングを構成するには、次のステップを実行します:

1. 以下について構成したかどうかを確認します。

- クラスタ化ドメイン。詳細は、Oracle WebLogic Serverクラスタの管理のWebLogicクラスタの設定を参照してください。

- ジョブ・スケジューラの以下の機能。

- HAデータベース(Oracle、DB2、Informix、MySQL、Sybase、MSSQLなど)。

- config.xmlファイルの<data-source-for-job-scheduler>要素を使用してHAデータベースにマップされているJDBCデータ・ソース。

- リース・サービス。デフォルトでは、データベース・リースが使用され、config.xmlファイルの<data-source-for-job-scheduler>要素によって定義されたJDBCデータ・ソースが使用されます。

ジョブ・スケジューラの構成の詳細は、Oracle WebLogic Server CommonJアプリケーションの開発のタイマーおよびワーク・マネージャAPIを参照してください。

2. クラスタ化EJBタイマー・サービスを有効にするために、weblogic-ejb-jar.xmlデプロイメント記述子のtimer-implementation要素をClusteredに設定します。

<timer-implementation>Clustered</timer-implementation>

詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスのtimer-implementation要素の説明を参照してください

クラスタ化EJBタイマー・サービスでは、以下のように動作が変更されることに注意してください。

- weblogic.ejb.WLTimer*インタフェースは、クラスタ化EJBタイマー・サービスではサポートされません。

- createTimer()メソッドを使用してクラスタ化EJBタイマーを新しく作成する場合、タイマーの初期セット・アップ時にタイムアウトの実行が遅延する場合があります。

- ジョブ・スケジューラでは、「少なくとも1回」の実行が保証されます。クラスタ化EJBタイマーが期限切れになった場合、データベースはリスナー・コールバック・メソッドが完了するまで更新されません。データベースが更新される前にサーバーがクラッシュした場合、タイマーはもう一度実行されます。

- クラスタ化EJBタイマー・サービスでは、障害が発生した場合に実行するアクションに関するタイマーの構成オプションは使用できません。これらの構成オプションには、再試行の遅延、再試行の最大数、タイムアウトの最大数、およびタイムアウト・エラー・アクションがあります。

- ジョブ・スケジューラは、期限切れになるタイマーを識別するために30秒ごとにデータベースに対して問合せを実行します。30秒未満の間隔でタイマーの実行が遅延する場合があります。

- 障害が発生した場合、トランザクション対応のタイマーのみ再試行されます。

- タイマー実行の固定間隔スケジューリングはサポートされません。

注意:
停止されていないリソース・グループを移行すると、そのグループは複数宛先になります。ただし、クラスタ化EJBタイマーでは複数宛先がサポートされていないため、クラスタ化EJBタイマーが期待どおりに動作しない場合があります。この問題を回避するには、リソース・グループを停止してからそのグループを移行することをお薦めします。ライブ、非ライブ、宛先および複数宛先の各グループの詳細は、Oracle WebLogic Server Multitenantの使用を参照してください。

Javaプログラミング・インタフェースを使用してタイマー・オブジェクトをプログラミングする

この節では、EJB 3.2仕様に定義されている、タイマーのプログラミングに使用できるJavaプログラミング・インタフェースについて説明します。これらのインタフェースの詳細は、EJB 3.2仕様を参照してください。また、この節では、WebLogic Server固有のタイマー関連インタフェースについて詳しく説明します。

EJB 3.2タイマー関連プログラミング・インタフェース

次の表に、タイマーのプログラミングに使用できるEJB 3.2インタフェースを示します。

表4-2 EJB 3.2タイマー関連プログラミング・インタフェース

プログラミング・インタフェース

説明

javax.ejb.ScheduleExpression

カレンダベースEJBタイマー式の作成

javax.ejb.Schedule

特定のタイムアウト・スケジュールを持つタイマーを自動的に作成します。

javax.ejb.Schedulesアノテーションを使用して、複数の自動タイマーを単一のタイムアウト・コールバック・メソッドに適用できます。

javax.ejb.TimedObject

タイマー・コールバックのためにタイマー・サービスに登録されるBeanのエンタープライズBeanクラスによって実装されます。このインタフェースは、単一のメソッド、ejbTimeoutを備えています。

EJBContext

getTimerServiceメソッドを使用してタイマー・サービスにアクセスします。

javax.ejb.TimerService

EJBの新しいEJBタイマーを作成するか、既存のEJBタイマーにアクセスします。

javax.ejb.Timer

特定のEJBタイマーに関する情報にアクセスします。

javax.ejb.TimerHandle

永続化できるシリアライズ可能なタイマー・ハンドルを定義します。タイマーはローカル・オブジェクトなので、TimerHandleはBeanのリモート・インタフェースまたはWebサービス・インタフェースを介して渡してはいけません。

EJB 2.1のタイマー関連プログラミング・インタフェースの詳細は、EJB 2.1仕様を参照してください。

WebLogic Server固有のタイマー関連インタフェース

タイマーのプログラミングに使用できるWebLogic Server固有のインタフェースは以下のとおりです。

- weblogic.management.runtime.EJBTimerRuntimeMBean。特定のEJBHomeのタイマーの実行時情報と管理機能を提供します。例4-3にweblogic.management.runtime.EJBTimerRuntimeMBeanインタフェースを示します。

例4-3 weblogic.management.runtime.EJBTimerRuntimeMBeanインタフェース

public interface weblogic.management.runtime.EJBTimerRuntimeMBean {
public int getTimeoutCount(); // get the number of successful timeout notifications that have been made
public int getActiveTimerCount(); // get the number of active timers for this EJBHome
public int getCancelledTimerCount(); // get the number of timers that have been cancelled for this EJBHome
public int getDisabledTimerCount(); // get the number of timers temporarily disabled for this EJBHome
public void activateDisabledTimers(); // activate any temporarily disabled timers
}

- weblogic.ejb.WLTimerServiceインタフェース。javax.ejb.TimerServiceインタフェースの拡張です。このインタフェースを使用すると、タイマーに関するWebLogic Server固有の構成情報を指定できます。例4-4にweblogic.ejb.WLTimerServiceインタフェースを示します。javax.ejb.TimerServiceの詳細は、EJB 2.1仕様を参照してください。

注意:

weblogic.ejb.WLTimerServiceインタフェースは、クラスタ化されたEJBタイマー・サービスではサポートされません(「クラスタ化されたEJBタイマーの構成」を参照)。

例4-4 weblogic.ejb.WLTimerServiceインタフェース

public interface WLTimerService extends TimerService {
public Timer createTimer(Date initial, long duration, Serializable info,
WLTimerInfo wlTimerInfo)
throws IllegalArgumentException, IllegalStateException, EJBException;
public Timer createTimer(Date expiration, Serializable info,
WLTimerInfo wlTimerInfo)
throws IllegalArgumentException, IllegalStateException, EJBException;
public Timer createTimer(long initial, long duration, Serializable info
WLTimerInfo wlTimerInfo)
throws IllegalArgumentException, IllegalStateException, EJBException;
public Timer createTimer(long duration, Serializable info,
WLTimerInfo wlTimerInfo)
throws IllegalArgumentException, IllegalStateException, EJBException;
}

- weblogic.ejb.WLTimerInfoインタフェース。weblogic.ejb.WLTimerServiceインタフェースで使用され、タイマーに関するWebLogic Server固有の構成情報を渡します。例4-5にweblogic.ejb.WLTimerInfoインタフェースを示します。

注意:

weblogic.ejb.WLTimerServiceインタフェースは、クラスタ化されたEJBタイマー・サービスではサポートされません(「クラスタ化されたEJBタイマーの構成」を参照)。

例4-5 weblogic.ejb.WLTimerInfoインタフェース

public final interface WLTimerInfo {
public static int REMOVE_TIMER_ACTION  = 1;
public static int DISABLE_TIMER_ACTION = 2;
public static int SKIP_TIMEOUT_ACTION  = 3;
/**
* Sets the maximum number of retry attempts that will be
* performed for this timer.  If all retry attempts
* are unsuccesful, the timeout failure action will
* be executed.
*/
public void setMaxRetryAttempts(int retries);
public int getMaxRetryAttempts();
/**
* Sets the number of milliseconds that should elapse
* before any retry attempts are made.
*/
public void setRetryDelay(long millis);
public long getRetryDelay();
/**
* Sets the maximum number of timeouts that can occur
* for this timer.  After the specified number of
* timeouts have occurred successfully, the timer
* will be removed.
*/
public void setMaxTimeouts(int max);
public int getMaxTimeouts();
/**
* Sets the action the container will take when ejbTimeout
* and all retry attempts fail.  The REMOVE_TIMER_ACTION,
* DISABLE_TIMER_ACTION, and SKIP_TIMEOUT_ACTION fields
* of this interface define the possible values.
*/
public void setTimeoutFailureAction(int action);
public int getTimeoutFailureAction();
}

- weblogic.ejb.WLTimerインタフェース。javax.ejb.Timerインタフェースの拡張であり、タイマーの現在の状態に関する追加情報を提供します。例4-6にweblogic.ejb.WLTimerインタフェースを示します。

注意:

weblogic.ejb.WLTimerServiceインタフェースは、クラスタ化されたEJBタイマー・サービスではサポートされません(「クラスタ化されたEJBタイマーの構成」を参照)。

例4-6 weblogic.ejb.WLTimerインタフェース

public interface WLTimer extends Timer {
public int getRetryAttemptCount();
public int getMaximumRetryAttempts();
public int getCompletedTimeoutCount();
}

EJBクライアントへのアクセスのプログラミング

この項では、エンタープライズBeanへのアクセスを提供するクライアント・ビューを決定する際のガイドラインを示します。

リモート・クライアント

EJB 3.2仕様に示されているように、リモート・クライアントは、Beanのリモート・ビジネス・インタフェースを介してセッションBeanにアクセスします。EJB 2.1以前のAPIに記述されたセッションBeanクライアントおよびコンポーネントでは、リモート・クライアントは、セッションBeanのリモート・ホームおよびリモート・コンポーネント・インタフェースを介してセッションBeanにアクセスします。

注意:

EJB 2.1以前のAPIでは、リモート・クライアントが、セッションBeanのリモート・ホームおよびリモート・コンポーネント・インタフェースによって、ステートフルまたはステートレスのセッションBeanにアクセス必要がありました。これらのインタフェースは、EJB 3.xでも使用できます。詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のEJBクラスおよびインタフェースの作成を参照してください。

エンタープライズBeanのリモート・クライアント・ビューは、場所に関係なく動作します。Beanインスタンスと同じJVMで稼働しているクライアントは、同じAPIを使用して、同じマシンまたは別のマシン上の異なるJVMで稼働するクライアントとしてBeanにアクセスします。

ローカル・クライアント

EJB 3.2仕様で示されているように、ローカル・クライアントは、Beanのローカル・ビジネス・インタフェース、またはBeanクラスのすべてのパブリック・メソッドを示すインタフェースなしのクライアント・ビューを介してセッションBeanにアクセスします。EJB 2.1以前のAPIに記述されたセッションBeanまたはエンティティBeanクライアントおよびコンポーネントでは、ローカル・クライアントは、Beanのローカル・ホームおよびローカル・コンポーネント・インタフェースを介してエンタープライズBeanにアクセスします。ローカル・ビジネス・インタフェースまたはインタフェースなしのローカル・ビューを実装するコンテナ・オブジェクトは、ローカルJavaオブジェクトです。

ローカル・クライアントは、ローカル・クライアント・ビューを提供するセッションBeanが同じアプリケーション内に存在し、そのBeanと密結合できるクライアントです。セッションBeanのローカル・クライアントは、別のエンタープライズBeanまたはWebコンポーネントにすることもできます。ローカル・クライアント・ビューを介してエンタープライズBeanにアクセスするには、ローカル・クライアント・ビューを提供するエンタープライズBeanとローカル・クライアントが同じアプリケーション内に配置される必要があります。そのため、ローカル・クライアント・ビューでは、リモート・クライアント・ビューに備わる位置の透過性は提供されません。

クライアントからのEJBのルックアップ

エンタープライズBeanのクライアントは、エンタープライズBeanのインスタンスへの参照を取得します。そのためには、Javaプログラミング言語のアノテーションで依存関係インジェクションを使用するか、エンタープライズBeanインスタンスを検索するJNDI構文を使用してJNDIルックアップを実行します。

注意:

クライアントでEJBリンクを使用して2.x以前のエンタープライズBeanをルックアップする方法の詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のEJBリンクの使用を参照してください。

依存関係インジェクションの使用

依存関係インジェクションでは、Beanコンテキスト内のリソースや他の環境エントリへの参照が、EJBコンテナによってBeanの変数またはセッター・メソッドに自動的に提供(注入)されます。依存関係インジェクションは、javax.ejb.EJBContextインタフェースまたはJNDI APIを使用したリソースのルックアップを、より簡単にプログラミングするための方法にすぎません。

依存関係インジェクションを指定するには、注入するリソースのタイプに応じて、以下のアノテーションのいずれかを変数またはセッター・メソッドに追加します。

- @javax.ejb.EJB - 別のEJBへの依存性を指定します。

- @javax.annotation.Resource - 外部リソース(JDBCデータ・ソース、JMS宛先、接続ファクトリなど)への依存性を指定します。

詳細は、「変数またはセッター・メソッドにリソース依存性を注入する」を参照してください

JNDIポータブル構文の使用

EJB 3.2のポータブルなグローバルJNDIネーミング・オプションは、多数の一般的なネームスペースを提供します。ここにEJBコンポーネントを登録し、この節に記載されているパターンを使用して検索できます。これにより、EJBコンポーネントをJNDIに登録する方法および場所、およびそれらをアプリケーションでルックアップおよび使用する方法を標準化します。

ポータブルJNDIルックアップでは、java:global、java:module、java:appという3つのJNDIネームスペースが使用されます。

- java:global JNDIネームスペースは、JNDIルックアップを使用してリモート・エンタープライズBeanを検索するポータブルな方法です。JNDIアドレスは、次のような形式です。
java:global[/アプリケーション名]/モジュール名/エンタープライズBean名[/インタフェース名]

アプリケーション名およびモジュール名のデフォルトは、アプリケーションおよびモジュールからファイル拡張子を除いた名前になります。アプリケーション名は、アプリケーションがEAR内にパッケージ化される場合にのみ必要になります。インタフェース名は、エンタープライズBeanが複数のビジネス・インタフェースを実装する場合にのみ必要になります。

- java:moduleネームスペースは、同じモジュール内でローカル・エンタープライズBeanをルックアップする際に使用されます。java:moduleネームスペースを使用するJNDIアドレスは、次の形式になります。
java:module/エンタープライズBean名/[インタフェース名]

インタフェース名は、エンタープライズBeanが複数のビジネス・インタフェースを実装する場合にのみ必要になります。

- java:appネームスペースは、同じアプリケーション内でパッケージ化されたローカル・エンタープライズBeanをルックアップする際に使用されます。つまり、エンタープライズBeanは、複数のJava EEモジュールを含むEARファイル内でパッケージ化されます。ava:appネームスペースを使用するJNDIアドレスは、次の形式になります。
java:app[/モジュール名]/エンタープライズBean名[/インタフェース名]

モジュール名は必要に応じて指定します。インタフェース名は、エンタープライズBeanが複数のビジネス・インタフェースを実装する場合にのみ必要になります。

たとえば、エンタープライズBeanのMyBeanがWebアプリケーション・アーカイブmyApp.warの中にパッケージ化される場合、デフォルトのモジュール名はmyAppになります。(この場合、web.xmlファイルでモジュール名を明示的に構成できます。)ポータブルJNDI名は、java:module/MyBeanです。java:globalネームスペースを使用して同じJNDI名を表すと、java:global/myApp/MyBeanとなります。

JNDI名のカスタマイズ

グローバルJNDIバインディングはデフォルトで登録されますが、weblogic.javaee.JNDINameおよびweblogic.javaee.JNDINamesアノテーションを使用して、EJBクライアント・ビュー・バインディングのJNDI名をカスタマイズすることもできます。詳細は、「weblogic.javaee.JNDIName」および「weblogic.javaee.JNDINames」を参照してください

デプロイメント記述子を使用するEJBでは、weblogic-ejb-jar.xmlデプロイメント記述子のjndi-binding要素を使用して、カスタムのJNDIバインディングを指定できます。詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のEJBデプロイメント記述子を参照してください。

URLにリクエストを送信するようにEJBを構成する

EJBがjava.net.URLリソース・マネージャ接続ファクトリ・タイプを使用して外部HTTPサーバーとのHttpURLConnectionを開くようにするには、URLまたはURLに対応するJNDIツリーでバインドされたオブジェクトを、Beanクラスの@Resourceアノテーションを使用するか、またはデプロイメント記述子を使用する場合はejb-jar.xmlのresource-ref要素およびweblogic-ejb-jar.xmlのres-ref-name要素を使用して指定します。

URLによるHTTPリソースの指定

EJBのリクエストが送信されるURLをアノテーションを使用して指定するには:

1. BeanクラスのURLフィールドに@Resourceで注釈付けします。

2. @Resourceのlook-up要素を使用してURLの値を指定します。

EJBのリクエストが送信されるURLを、デプロイメント記述子を使用して指定するには:

1. ejb-jar.xmlのresource-ref要素の<jndi-name>要素でURLを指定します。

2. weblogic-ejb-jar.xmlのresource-description要素の<jndi-name>要素でURLを指定します。

<resource-description>
<res-ref-name>url/MyURL</res-ref-name>
<jndi-name>http://www.rediff.com/</jndi-name>
</resource-description>

WebLogic Serverは指定されたjndi-nameでURLオブジェクトを作成し、そのオブジェクトをjava:comp/envにバインドします。

JNDI名によるHTTPリソースの指定

JNDIでバインドされURLに対応するオブジェクトを、URLを指定するかわりにアノテーションを使用して指定するには:

1. BeanクラスのURLフィールドに@Resourceで注釈付けします。

2. @Resourceのlook-up要素を使用して、URLがJNDIでバインドされている名前を指定します。

JNDIでバインドされURLに対応するオブジェクトを、URLを指定するかわりにデプロイメント記述子を使用して指定するには:

1. ejb-jar.xmlのresource-ref要素の<jndi-name>要素で、URLがJNDIでバインドされている名前を指定します。

2. 次のように、weblogic-ejb-jar.xmlのresource-description要素の<jndi-name>要素で、URLがJNDIでバインドされている名前を指定します。

<resource-description>
<res-ref-name>url/MyURL1</res-ref-name>
<jndi-name>firstName</jndi-name>
</resource-description>

firstNameは、URLに対応するJNDIツリーにバインドされたオブジェクトです。このバインディングは、起動クラスで行うこともできます。jndi-nameが有効なURLでない場合、WebLogic ServerはそれをURLに対応し、すでにJNDIツリーにバインドされているオブジェクトとして取り扱い、LinkRefとそのjndi-nameをバインドします。

BeanコードからのHTTPリソースへのアクセス

HTTPリソースの指定方法(URLかURLに対応するJNDI名か)に関係なく、次のようにしてEJBのコードからそのHTTPリソースにアクセスできます。

URL url = (URL) context.lookup("java:comp/env/url/MyURL");
connection = (HttpURLConnection)url.openConnection();

EJBのネットワーク通信の構成

EJBが通信に使用するネットワーク接続の属性は、カスタム・ネットワーク・チャネルを構成してEJBに割り当てることによって設定できます。WebLogic Serverのネットワーク・チャネルとそれに関連する構成手順については、Oracle WebLogic Serverサーバー環境の管理のネットワーク・リソースの構成を参照してください。カスタム・チャネルを構成したら、weblogic-ejb-jar.xmlのnetwork-access-point要素を使用してEJBに割り当てます。

トランザクションのプログラミングと構成

以降の節では、トランザクション・プログラミングのガイドラインを示します。

コンテナ管理によるトランザクションのプログラミング

コンテナ管理によるトランザクションは、Bean管理によるトランザクションよりもプログラミングが簡単です。その理由は、境界設定(トランザクションの開始と停止)がEJBコンテナで行われるからです。目的のトランザクション動作を構成するには、EJBアノテーションjavax.ejb.TransactionAttributeを使用するか、EJBデプロイメント記述子ejb-jar.xmlおよびweblogic-ejb-jar.xmlを使用します。

- EJBアノテーションを使用して、Beanファイルでコンテナ管理によるトランザクションを指定する方法の詳細は、「トランザクション管理とトランザクション属性を指定する」を参照してください。

- EJBデプロイメント記述子を使用して、コンテナ管理によるトランザクションを指定する方法の詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のコンテナ管理によるトランザクション要素を参照してください。

コンテナ管理によるトランザクションの主なプログラミング・ガイドラインは以下のとおりです。

- トランザクション境界の保持 - コンテナが設定したトランザクションの境界に干渉するメソッドは呼び出さないでください。以下のメソッドは使用しないでください。

- java.sql.Connectionのcommit、setAutoCommit、およびrollbackメソッド

- javax.ejb.EJBContextのgetUserTransactionメソッド

- javax.transaction.UserTransactionのすべてのメソッド

- トランザクションの明示的なロールバック - 明示的にコンテナがコンテナ管理によるトランザクションをロールバックするようにするには、EJBContextインタフェースのsetRollbackOnlyメソッドを呼び出します。(Beanから非アプリケーション例外(主としてEJBException)がスローされる場合、ロールバックは自動的に行われます。)

- シリアライゼーション問題の回避 - 多くのデータ・ストアでは、シリアライゼーションに関する問題の検出は、単一ユーザー接続の場合でさえ制限されています。そのような場合は、weblogic-ejb-jar.xmlのtransaction-isolationがTransactionSerializableに設定されていても、同じ行でクライアント間に競合が発生した場合はEJBクライアントで例外またはロールバックが発生する場合があります。そのような例外を回避するために、以下のことができます。

- SQL例外を捕捉して(たとえばトランザクションを再起動などして)適切に解決するコードをクライアント・アプリケーションに含める

- Oracleデータベースでは、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発の付録weblogic-ejb-jar.xmlデプロイメント記述子のリファレンスの「isolation-level」で説明されているトランザクション分離設定を使用します

コンテナ管理トランザクションの自動的な再試行の構成

Oracle WebLogic Serverでは、トランザクションを開始したビジネス・メソッドが、システム例外に関連のないトランザクション・ロールバックが原因で失敗した場合、EJBコンテナが新しいトランザクションを開始し、失敗したメソッドを指定された回数まで再試行するように指定できます。メソッドの失敗が指定された再試行回数に達した場合、EJBコンテナは例外をスローします。

注意:

EJBコンテナは、システム例外に基づくエラーが原因で失敗したトランザクションは再試行しません。

コンテナ管理によるトランザクションの自動的な再試行を構成するには:

1. 使用するBeanがコンテナ管理によるセッションBeanまたはエンティティBeanであることを確認します。

コンテナ管理によるセッションBeanおよびエンティティBeanの場合にのみ、コンテナ管理によるトランザクションの自動再試行を構成できます。メッセージドリブンBeanの場合は、コンテナ管理によるトランザクションの自動再試行を構成できません。MDBは、メッセージの受信を含むトランザクションがロールバックされたときに、そのメッセージの受信の確認応答を行わないため、メッセージは確認応答が行われるまで自動的に再試行されます。また、タイマーBeanの場合も、コンテナ管理によるトランザクションの自動再試行は構成できません。また、タイマーBeanの場合も、コンテナ管理によるトランザクションの自動再試行は構成できません。タイマーBeanのejbTimeoutメソッドが開始されてロールバックされると、タイムアウトが常に再試行されるからです。

2. トランザクションの自動再試行を構成する場合、対象となるビジネス・メソッドは、Beanのリモートまたはローカル・インタフェースの内部か、またはホーム・インタフェースのホーム・メソッド(特定のBeanインスタンスに固有ではないローカル・ホーム・ビジネス・ロジック)として定義されている必要があります。メソッドには、以下のコンテナ管理トランザクション属性の1つが設定されていなければなりません。

- RequiresNew。メソッドのトランザクション属性(ejb-jar.xmlのtrans-attribute要素)がRequiresNewの場合、メソッドの呼出し前に常に新しいトランザクションが開始され、構成されている場合、そのトランザクションが失敗すると自動再試行が行われます。

- Required。メソッドのトランザクション属性(ejb-jar.xmlのtrans-attribute要素)がRequiredの場合、メソッドが新しいトランザクションで再試行されるのは、失敗したトランザクションがそのメソッドのために開始された場合のみです。

詳細については、以下を参照してください。

- プログラミング・インタフェースについては、「EJBクライアントへのアクセスのプログラミング」を参照してください

- ejb-jar.xmlのtrans-attribute要素については、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のコンテナ管理によるトランザクション要素を参照してください。ここには、EJBデプロイメント記述子の作成および編集に関する詳細情報が記載されています。

3. トランザクションの自動再試行を有効にする場合、対象となるメソッドは再呼出しできなければなりません。失敗したメソッドの再試行によって得られる結果は、直前の再試行が成功した場合に得られる結果と同じでなければなりません。具体的には、次のとおりです。

- メソッドの呼出しによって呼出しチェーンが開始された場合、そのメソッドを再試行するときは呼出しチェーン全体を再呼び出しするのが安全です。

- メソッドのすべてのパラメータを再利用できなければなりません。メソッドが再試行される場合、そのメソッドは失敗したメソッドを呼び出すために使用されたパラメータで再試行されます。一般に、再利用できるパラメータは、プリミティブ、不変オブジェクト、または読取り専用オブジェクトの参照です。パラメータがメソッドによって変更されるオブジェクトの参照である場合、メソッドの再呼出しによってメソッド呼出しの結果に悪影響が生じないようにしてください。

- 再試行されるメソッドを保持するBeanがステートフル・セッションBeanである場合、そのBeanの対話状態は再呼出し時に失われてはなりません。ステートフル・セッションBeanの状態はトランザクション対応ではなく、トランザクションのロールバック中に復元できないので、トランザクションの自動再試行の機能を使用する場合、Beanの状態がロールバック後も有効であることを確認しておく必要があります。

4. EJBコンテナがどのメソッドのトランザクションを自動的に再試行するか、およびその回数は、weblogic-ejb-jar.xmlのretry-methods-on-rollback要素で指定します。

retry-methods-on-rollbackのretry-count下位要素は、WebLogic Server管理コンソールからも変更できます。

Bean管理のトランザクションのプログラミング

この節では、Bean管理によるトランザクションのプログラミング上の考慮事項を示します。

- トランザクションの境界設定 - EJBまたはクライアント・コードにトランザクション境界を定義するには、Java Transaction Service (JTS)またはJDBCデータベース接続を取得する前に、UserTransactionオブジェクトを取得してトランザクションを開始しなければなりません。UserTransactionオブジェクトを取得するには、次のコマンドを使用します。

ctx.lookup("javax.transaction.UserTransaction");

UserTransactionオブジェクトを取得した後は、tx.begin()、tx.commit()、tx.rollback()でトランザクションの境界を指定します。

データベース接続を取得してからトランザクションを開始した場合、その接続は新しいトランザクションと何の関連性も持たず、以後のトランザクション・コンテキストにその接続を「入れる」ためのセマンティクスも存在しません。JTS接続がトランザクション・コンテキストに関連付けられていない場合、JTS接続はautocommitをtrueに設定した標準のJDBC接続と同じように動作し、更新はデータ・ストアに自動的にコミットされます。

いったんトランザクション・コンテキスト内にデータベース接続が作成されると、その接続はトランザクションがコミットまたはロールバックされるまで確保されます。パフォーマンスとスループットを最適化するには、トランザクションを迅速に完了させることによって、データベース接続を解放し、他のクライアント・リクエストが使用できるようにする必要があります。

注意:

アクティブなトランザクション・コンテキストには単一のデータベース接続しか関連付けることができません。

- トランザクション分離レベルの設定 - Bean管理によるトランザクションでは、分離レベルはBeanコードで定義します。有効な分離レベルは、java.sql.Connectionインタフェースで定義されます。分離レベルの動作の詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発の付録weblogic-ejb-jar.xmlデプロイメント記述子のリファレンスの「isolation-level」を参照してください
サンプル・コードについては、例4-7を参照してください。

例4-7 BMTでのトランザクション分離レベルの設定

import javax.transaction.Transaction;
import java.sql.Connection
import weblogic.transaction.TxHelper:
import weblogic.transaction.Transaction;
import weblogic.transaction.TxConstants;
User Transaction tx = (UserTransaction)
ctx.lookup("javax.transaction.UserTransaction");
//Begin user transaction
tx.begin();
//Set transaction isolation level to TransactionReadCommitted
Transaction tx = TxHelper.getTransaction();
tx.setProperty (TxConstants.ISOLATION_LEVEL, new Integer
(Connection.TransactionReadCommitted));
//perform transaction work
tx.commit();

- 制限されたメソッドの回避 - Bean管理によるトランザクションでは、EJBContextインタフェースのgetRollbackOnlyメソッドとsetRollbackOnlyメソッドは呼び出さないでください。これらのメソッドは、コンテナ管理によるトランザクションのみで使用します。Bean管理によるトランザクションでは、UserTransactionインタフェースのgetStatusメソッドとrollbackメソッドを呼び出します。

- アクティブなトランザクション・コンテキストにつき1つの接続の使用 - アクティブなトランザクション・コンテキストに関連付けることができるのは、1つのデータベース接続だけです。

複数のEJBで分散されるトランザクションのプログラミング

この節では、複数のBean(複数のサーバー・インスタンスに存在する場合もある)にトランザクションを分散させる2つのアプローチを説明します。

クライアントのトランザクション・コンテキストから複数のEJBを呼び出す

次の断片的なコードは、UserTransactionオブジェクトを取得し、それを使用してトランザクションを開始およびコミットするクライアント・アプリケーションから引用したものです。クライアントは、トランザクションのコンテキストの中で2つのEJBを呼び出します。

import javax.transaction.*;
...
u = (UserTransaction) jndiContext.lookup("javax.transaction.UserTransaction");
u.begin();
account1.withdraw(100);
account2.deposit(100);
u.commit();
...

account1とaccount2のBeanで実行される更新は、1つのUserTransactionのコンテキスト内で行われます。同じサーバー・インスタンス上にあるか、異なるサーバー・インスタンスにあるか、またはWebLogic Serverクラスタにあるのかに関係なく、EJBは1つの論理単位として一緒にコミットまたはロールバックされます。

1つのトランザクション・コンテキストから呼び出されるEJBはすべて、クライアント・トランザクションをサポートしている必要があります。つまり、ejb-jar.xmlの各Beanのtrans-attribute要素が、Required、Supports、またはMandatoryに設定されている必要があります。

EJB「ラッパー」を使用してEJB間トランザクションをカプセル化する

トランザクションをカプセル化するラッパーEJBを使用できます。クライアントはラッパーEJBを呼び出して銀行振替などのアクションを実行し、ラッパーは新しいトランザクションを開始して、トランザクションの処理を実行する1つまたは複数のEJBを呼び出します。

ラッパーEJBは、他のEJBを呼び出す前にトランザクション・コンテキストを明示的に取得できます。あるいは、ejb-jar.xmlでラッパーのtrans-attribute要素がRequiredまたはRequiresNewに設定されている場合、WebLogic Serverは新しいトランザクション・コンテキストを自動的に作成できます。

ラッパーEJBによって呼び出されるすべてのEJBは、そのラッパーEJBのトランザクション・コンテキストをサポートしている必要があります。つまり、そのtrans-attribute要素がRequired、Supports、またはMandatoryに設定されていなければなりません。

Javaソースをコンパイルする

EJB BeanクラスのJavaソース・コードの記述と、必要に応じてインターセプタ・クラスの記述が完了したら、それらをクラス・ファイルにコンパイルする必要があります(通常は標準Javaコンパイラを使用します)。生成されたクラス・ファイルは、デプロイメント用のターゲット・モジュールにパッケージ化できます。コンパイルするためのツールとしては以下が一般的です。

- javac - Java SE SDKに付属のjavacコンパイラは、Javaコンパイル機能を提供します。http://www.oracle.com/technetwork/java/javase/documentation/index.htmlを参照してください。

- weblogic.appc: デプロイメント時間を短縮するために、weblogic.appc Javaクラス(またはこれと同等のAntタスクwlappc)を使用して、デプロイ可能なアーカイブ・ファイル(WAR、JARまたはEAR)をプリコンパイルします。weblogic.appcでプリコンパイルをすると、特定のヘルパー・クラスが生成され、アプリケーションが現在のJava EE仕様に準拠しているかどうかを確認するための妥当性チェックが実行されます。詳細は、Oracle WebLogic Serverアプリケーションの開発のwlappcを使用したモジュールとアプリケーションのビルドを参照してください。

- wlcompile Antタスク: javacコンパイラを呼び出して、アプリケーションのJavaコンポーネントを分割開発ディレクトリ構造にコンパイルします。詳細は、Oracle WebLogic Serverアプリケーションの開発のwlcompileを使用したアプリケーションのコンパイルを参照してください。

デプロイメント記述子の作成と編集(省略可能)

EJB 3.xプログラミング・モデルの重要な点は、メタデータ・アノテーションが導入されたことです。アノテーションを使用すると、コンテナ内でのBeanの動作、依存関係インジェクションの要求方法などをJavaクラス自体の中で指定でき、EJBの開発プロセスを簡略化できます。アノテーションは、EJBの2.x以前のバージョンで必要だったデプロイメント記述子にかわるものです。

しかしながら、デプロイメント記述子は、EJB 3.2で完全にサポートされます。ただし、Java EE 6標準のデプロイメント記述子は必須ではありません。たとえば、従来の2.xプログラミング・モデルを使用する場合や、後々の開発やデプロイメントの段階でより細かくカスタマイズできるようにする場合、メタデータ・アノテーションに加えて(またはメタデータ・アノテーションのかわりに)標準のデプロイメント記述子を作成できます。

デプロイメント記述子要素は、対応するアノテーションを常にオーバーライドします。たとえば、Beanクラス内に@javax.ejb.TransactionManagement(BEAN)アノテーションを指定した上で、そのEJB用のejb-jar.xmlデプロイメント記述子を作成し、<transaction-type>要素をcontainerに設定した場合は、デプロイメント記述子の値が優先され、このEJBではコンテナ管理によるトランザクションの境界設定が使用されます。

注意:

EJB 3.2バージョンでは、2.xでサポートされていたWebLogic固有のEJB機能がすべてサポートされます。ただし、weblogic-ejb-jar.xmlまたはweblogic-cmp-rdbms-jar.xmlデプロイメント記述子ファイルで構成する機能は、このEJB 3.2のリリースでも引続き同じ方法で構成する必要があります。これは、現時点ではそれらの機能と同等のアノテーションが存在しないためです。

『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』の2.xバージョンでは、Java EE標準およびWebLogic固有のEJBデプロイメント記述子の作成と編集について詳しく説明しています。特に、以下の節を参照してください。

- EJBデプロイメント記述子(EJBデプロイメント記述子の概要)

- デプロイメント記述子を編集する

- デプロイメント記述子スキーマおよび文書型定義リファレンス

- weblogic-ejb-jar.xmlデプロイメント記述子のリファレンス

- weblogic-cmp-jar.xmlデプロイメント記述子のリファレンス

EJBのパッケージ化

エンタープライズ・アプリケーションの一部としてEJBをパッケージ化することをお薦めします。詳細は、Oracle WebLogic Serverアプリケーションの開発の分割開発ディレクトリからのデプロイとパッケージ化を参照してください。

ただし、EJB 3.2ではEJBコンポーネントを直接Webアプリケーション・アーカイブ(WAR)ファイルの中に配置する機能を提供することでパッケージ化が単純化されたため、WebコンポーネントとEJBコンポーネントを格納するアーカイブを個々に作成して、それらをエンタープライズ・アーカイブ(EAR)ファイルで結合する必要がなくなりました。

JARでのEJBのパッケージ化

WebLogic Serverでは、別のアプリケーションのプログラムに基づくクライアントがEJBへのアクセスに必要とするEJBクラスをパッケージ化するためのejb-client.jarファイルの使用がサポートされています。

Beanのejb-jar.xml ファイルのejb-client-jar要素でクライアントJARの名前を指定します。appcコンパイラを実行すると、EJBにアクセスするために必要なクラスを持つJARファイルが生成されます。

クライアントJARをリモート・クライアントからアクセスできるようにします。Webアプリケーションの場合は、ejb-client.jarを/libディレクトリに配置します。非Webクライアントの場合は、クライアントのクラスパスでejb-client.jarを指定します。

注意:

WebLogic Serverのクラスローディング動作は、クライアントがスタンドアロンかどうかによって異なります。ejb-client.jarにアクセスできるスタンドアロンのクライアントは、ネットワーク経由で必要なクラスをロードできます。ただし、セキュリティ上の理由から、サーバー・インスタンスで動作しているプログラムに基づくクライアントはネットワーク経由でクラスをロードすることはできません。

WARでのEJBのパッケージ化

EJB 3.2では、エンタープライズBeanクラスをejb-jarファイルの中にパッケージ化しなければならないという制限が取り除かれました。そのため、Webアプリケーション・クラスに適用される同じパッケージ化のガイドラインを使用して、EJBクラスをWebアプリケーション・アーカイブ(WAR)の中に直接パッケージ化できます。単にEJBクラスをWEB-INF/classesディレクトリかWEB-INF/libディレクトリ内のJARファイルに入れるのみです。必要に応じて、EJBデプロイメント記述子も使用する場合は、それをWEB-INF/ejb-jar.xmlとしてパッケージ化できます。appcコンパイラを実行すると、EJBコンポーネントにアクセスするために必要なクラスを持つWARファイルが生成されます。

WARファイルには、モジュールで定義されたすべてのコンポーネント(Web、エンタープライズBeanなど)間で共有される単一のコンポーネント・ネーミング環境があります。WARファイルで定義されたそれぞれのエンタープライズBeanは、この単一のコンポーネント環境ネームスペースを、WARファイルで定義されたその他すべてのエンタープライズBean、およびWARファイルで定義されたその他すべてのWebコンポーネントと共有します。

WARファイルにパッケージ化されたエンタープライズBean(および関連する任意のクラス)には、WARファイルにパッケージ化された他の非エンタープライズBeanクラスと同じクラス・ローディング要件があります。たとえば、WARファイルの中にパッケージ化されているサーブレットは、同じWARファイルの中にパッケージ化されているエンタープライズBeanコンポーネントを参照できることが保証され、逆もまた保証されます。

注意:

EJB 2.1エンティティBeanおよびEJB 1.1エンティティBeanは、WARファイル内ではサポートされません。これらのコンポーネント・タイプは、スタンドアロンのejb-jarファイルまたはEARファイル内でパッケージ化されたejb-jarファイル内でのみパッケージ化する必要があります。この制限に違反するアプリケーションは、デプロイに失敗します。

WebLogic Server配布キットにバンドルされている、単純化されたWARのパッケージ化メソッドを使用するサンプルがあります。「EJB 3.1: 単純化されたインタフェースなしのプログラミングおよびWARファイルでのパッケージ化」を参照してください

EJBのデプロイメント

EJBをデプロイすると、WebLogic ServerはEJBのコンポーネントをクライアントに提供できるようになります。EJBは、ユーザーの環境とEJBが本番環境に置かれるかどうかに基づいて、複数の手順のうちの1つでデプロイできます。

WebLogic Serverアプリケーションおよびモジュール(EJBを含む)をデプロイする一般的な手順については、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。EJB固有のデプロイメントの問題および手順の詳細は、「エンタープライズ・アプリケーションの一部としてのスタンドアロンEJBのデプロイメント」および「Webアプリケーションの一部としてのEJBのデプロイメント」を参照してください。

2.xプログラミング・モデルで作成されたEJBのデプロイメントの詳細は、2.xプログラミング・モデルに特化したOracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のEnterprise JavaBeansのデプロイメント・ガイドラインを参照してください。

5 アノテーション付きEJBクラスのプログラミング

この章では、アノテーション付きEJB 3.2クラス・ファイルのプログラミング方法について説明します。

この章の内容は次のとおりです:

- メタデータ・アノテーションとEJB Beanファイルの概要

- Beanファイルのプログラミング: 要件およびEJB 2.xからの変更点

- Beanファイルのプログラミング

- メタデータ・アノテーションの機能別一覧

メタデータ・アノテーションとEJB Beanファイルの概要

WebLogic Server EJB 3.2プログラミング・モデルでは、Java EE 7メタデータ・アノテーション機能を使用して、アノテーション付きEJB 3.2 Beanファイルを作成し、標準Javaコンパイラでクラスをコンパイルします。生成されたクラスは、デプロイメント用のターゲット・モジュールにパッケージ化できます。実行時に、WebLogic Serverはアノテーションを解析して、必要な動作のアスペクトをBeanファイルに適用します。

ヒント:

デプロイメント時間の短縮化を図るために、WebLogicコンパイル・ツールweblogic.appc (またはこれと同等のAntタスクwlappc)を使用して、デプロイ可能なアーカイブ・ファイル(WAR、JARまたはEAR)をプリコンパイルしておくこともできます。weblogic.appcでプリコンパイルをすると、特定のヘルパー・クラスが生成され、アプリケーションが仕様に準拠しているかどうかを確認するための妥当性チェックが実行されます。

アノテーション付き3.2 Beanファイルは、EJBの中核部分です。このファイルにはEJBの動作を決定するJavaコードが含まれています。3.2 Beanファイルは、EJBのビジネス・メソッドを形作るEJBビジネス・インタフェースを実装した通常のJavaクラス・ファイルです。このBeanファイルにJDKメタデータ・アノテーションを追加することで、EJBの構造や特性を指定し、EJBを文書化し、実行時の特別なサービス(ビジネス・レベルの拡張セキュリティ、特別なビジネス・ロジックなど)を提供します。

「メタデータ・アノテーションの機能別一覧」には、Beanファイル内で指定できるアノテーションを機能別にまとめてあります。これらのアノテーションには、以下の仕様に記述されているアノテーションが含まれます。

- Enterprise JavaBeans 3.2仕様(JSR-345)(http://jcp.org/en/jsr/summary?id=345)

- Common Annotations for the Java Platform (JSR-250)(http://www.jcp.org/en/jsr/detail?id=250)

詳細は、「EJBメタデータ・アノテーション・リファレンス」を参照してください。これらのアノテーションのリファレンス情報をアルファベット順にまとめてあります。このトピックは、EJB 3.2を作成するための反復的な開発手順の一部です。詳細な開発手順については、「Enterprise JavaBeansの反復的な開発」を参照してください。

一般的なEJBの設計およびアーキテクチャの詳細は、次のドキュメントを参照してください。

- Enterprise JavaBeansのWebサイト(http://www.oracle.com/technetwork/java/ejb-141389.html)

- Java EE 6プラットフォームの概要: パート3 (EJB Technology, Even Easier to Use)(http://www.oracle.com/technetwork/articles/javaee/javaee6overview-part3-139660.html#ejbeasy)

- Java EE 7チュートリアル(http://docs.oracle.com/javaee/7/tutorial/index.html)

Beanファイルのプログラミング: 要件およびEJB 2.xからの変更点

EJB 3.2 Beanクラス・ファイルをプログラミングする上での要件は、基本的にはEJB 2.xでの要件と同じです。この項では、Beanクラスの基本的な必須要件について簡単に説明し、EJB 2.xとEJB 3.2の要件の相違点について説明します。

Beanクラスをプログラミングする上での必須要件と任意要件の詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』を参照してください。

Beanファイルの要件とEJB 2.xからの変更点

次に、EJB 3.2でBeanクラスをプログラミングする上での要件と、EJB 2.xの要件のうちEJB 3.2には適用されなくなったものをまとめます。

- クラスにBeanタイプを指定する必要があります。通常は、以下のメタデータ・アノテーションのいずれかを使用して指定します。これらのアノテーションは、デプロイメント記述子を使用してオーバーライドすることもできます。

- @javax.ejb.Stateless

- @javax.ejb.Stateful

- @javax.ejb.Singleton

- @javax.ejb.MessageDriven

注意:

Oracle Kodo JPA/JDOは、このリリースのWebLogic Serverでサポートされなくなりました。ただし、Oracle Kodoを使用している場合は、個別のドキュメントの3.0エンティティBean(@javax.ejb.Entity)のプログラミングの説明を参照してください。

JPA 2.1をサポートするOracle TopLinkを使用することをお薦めします。Kodoでは、JPA 1.0のみをサポートします。詳細は、「Oracle WebLogic ServerでのOracle TopLinkの使用方法」を参照してください

- BeanがセッションBeanである場合、Beanクラスで次のいずれかを実装できます。

- インタフェースなしのローカル・クライアント・ビュー・タイプ。個別のローカル・ビジネス・インタフェースを必要とすることなくローカル・セッションBeanへのアクセスを提供して、EJBの開発を単純化しています。(EJB 3.2では、MDBもインタフェースなしのローカル・クライアント・ビューを使用できます。)

- Beanのビジネス・インタフェースまたはBeanのビジネス・インタフェースのメソッド(存在する場合)。

- セッションBeanにjavax.ejb.SessionBeanを実装する必要がなくなりました。つまり、ejbCreate()やejbPassivate()などのejbXXX()メソッドを実装する必要がなくなりました。

- ステートフル・セッションBeanにjava.io.Serializableを実装する必要がなくなりました。

- メッセージドリブンBeanにjavax.ejb.MessageDrivenBeanを実装する必要がなくなりました。

次の要件はEJB 2.xから変更されていませんが、念のため簡単にまとめておきます。

- クラスはpublicとして定義する必要があります。finalやabstractとして定義することはできません。クラスは最上位のクラスでなければなりません。

- クラスには、パラメータを取らないpublicコンストラクタが必要です。

- クラスにfinalize()メソッドを定義することはできません。

- BeanがメッセージドリブンBeanである場合は、Beanでサポートするメッセージング・タイプに必要なメッセージ・リスナー・インタフェース(またはそのメッセージ・リスナー・インタフェースのメソッド)を、Beanクラスに直接的または間接的に実装する必要があります。JMSの場合であれば、メッセージ・リスナー・インタフェースはjavax.jms.MessageListenerインタフェースになります。

Beanクラス・メソッドの要件

メソッドの要件はEJB 2.xから変更されていませんが、念のため簡単にまとめておきます。

セッションBeanクラスのメソッド(ビジネス・インタフェース・メソッドを実装するメソッド)の要件は以下のとおりです。

- メソッドには任意の名前を付けることができます。

- ビジネス・メソッドはpublicとして宣言する必要があります。finalやstaticとして宣言することはできません。

- セッションBeanのリモート・ビジネス・インタフェース(またはリモート・インタフェース)のビジネス・メソッドに対応するメソッドの場合は、引数や戻り値の型をRMI/IIOPの有効な型にする必要があります。

- throws句で任意のアプリケーション例外を定義できます。

メッセージドリブンBeanクラスのメソッドの要件は以下のとおりです。

- メソッドには、メッセージ・リスナー・インタフェースのリスナー・メソッドを実装する必要があります。

- メソッドはpublicとして宣言する必要があります。finalやstaticとして宣言することはできません。

Beanファイルのプログラミング

以降の節では、アノテーション付きEJB 3.2クラス・ファイルをプログラミングする際に推奨される手順について説明します。

- Beanファイルをプログラミングする際の一般的な手順

- ビジネス・インタフェースとその他のインタフェースを指定する

- Beanタイプ(ステートレス、シングルトン、ステートフル、メッセージドリブン)を指定する

- 変数またはセッター・メソッドにリソース依存性を注入する

- 3.0エンティティを呼び出す

- ビジネス・メソッドまたはライフサイクル・コールバック・イベントのインターセプタを指定する

- アプリケーション例外をプログラミングする

- EJBへのアクセスにセキュリティを設定する

- トランザクション管理とトランザクション属性を指定する

Beanファイルをプログラミングする際の一般的な手順

次の手順では、EJBの3.2 Beanファイルをプログラミングする場合の一般的で基本的な手順を説明します。細かな手順は、どのような動作のEJBを作成するかによって異なります。

以降の節で使用するサンプル・コードについては、「Enterprise JavaBeansの単純なサンプル」を参照してください。

1. Beanファイルで使用するEJB 3.2アノテーションおよびその他の共通アノテーションをインポートします。一般的なEJBアノテーションはjavax.ejbパッケージに含まれています。また、インターセプタ・アノテーションはjavax.interceptorパッケージ、3.2エンティティを呼び出すためのアノテーションはjavax.persistenceパッケージ、共通アノテーションはjavax.commonまたはjavax.common.securityパッケージに含まれています。次に例を示します。

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.interceptor.ExcludeDefaultInterceptors;

2. EJBが実装するインタフェース(ビジネス・インタフェースまたはインタフェースなしのビュー)およびその他の標準インタフェースを指定します。インタフェースは、明示的に実装しても、アノテーションを使用して指定してもかまいません。

「ビジネス・インタフェースとその他のインタフェースを指定する」を参照してください

3. 必須のアノテーションを使用して、プログラミングするBeanのタイプ(セッションまたはメッセージドリブン)を指定します。

「Beanタイプ(ステートレス、シングルトン、ステートフル、メッセージドリブン)を指定する」を参照してください。

4. 必要に応じて依存関係インジェクションを設定し、外部リソース(別のEJB、他のJava EE 7オブジェクトなど)を使用できるようにします。

「変数またはセッター・メソッドにリソース依存性を注入する」を参照してください

5. 必要に応じてEntityManagerオブジェクトを作成し、エンティティ・アノテーションを使用してエンティティ情報を注入します。

「3.0エンティティを呼び出す」を参照してください

6. 必要に応じて、ビジネス・メソッドまたはライフサイクル・コールバック・メソッドのインターセプタ・メソッドをプログラミングおよび構成します。インターセプタ・メソッドは、Beanファイル自体の中でも、別のJavaファイル内でもプログラミングできます。

「ビジネス・メソッドまたはライフサイクル・コールバック・イベントのインターセプタを指定する」を参照してください

7. ビジネス・インタフェースにアプリケーション例外をスローするビジネス・メソッドを指定した場合は、例外クラスをプログラミングする必要があります。この点は、EJB 2.xでも同様です。

EJB 3.2固有の情報については、「アプリケーション例外をプログラミングする」を参照してください。

8. 必要に応じ、セキュリティ関連のメタデータ・アノテーションを使用して、EJBメソッドを呼び出すことができるセキュリティ・ロールを指定します。

「EJBへのアクセスにセキュリティを設定する」を参照してください

9. 必要に応じて、EJBで実行するデフォルトのトランザクション構成を変更します。

「トランザクション管理とトランザクション属性を指定する」を参照してください

ビジネス・インタフェースとその他のインタフェースを指定する

EJB 3.x APIに記述されたセッションBeanのEJB 3.xローカルまたはリモート・クライアントは、そのビジネス・インタフェースを介してセッションBeanにアクセスします。ローカル・クライアントは、Beanクラスのすべてのパブリック・メソッドを公開するインタフェースなしのビューを介してセッションBeanにアクセスすることもできます。

ビジネス・インタフェースを指定する

EJB Beanクラスのビジネス・インタフェースを指定する方法は2つあります。

- implements Javaキーワードを使用してビジネス・インタフェースを明示的に実装します。

- メタデータ・アノテーション(たとえばjavax.ejb.Localやjavax.ejb.Remote)を使用してビジネス・インタフェースを指定します。この場合は、Beanクラスに明示的にビジネス・インタフェースを実装する必要はありません。

通常、EJB Beanクラスに実装したインタフェースは、そのEJBのビジネス・インタフェースと見なされます。また、リモート・インタフェースであることを明示しない限り、ビジネス・インタフェースはローカル・インタフェースと見なされます。ビジネス・インタフェースをリモート・インタフェースとして明示するには、javax.ejb.Remoteアノテーションを使用するか、適切なEJBデプロイメント記述子を更新します。javax.ejb.Remoteおよびjavax.ejb.Localアノテーションは、ビジネス・インタフェース自体で指定することも、そのインタフェースを実装するBeanクラスで指定することもできます。

Beanクラスには、複数のインタフェースを実装できます。その場合(ただし、下に示すインタフェースは対象外)は、EJBのビジネス・インタフェースをjavax.ejb.Localまたはjavax.ejb.Remoteアノテーションを使用して明示的に指定する必要があります。指定する場所は、ビジネス・インタフェース自体でも、そのビジネス・インタフェースを実装するBeanクラスでも、適切なデプロイメント記述子でも構いません。

Beanクラスに複数のインタフェースが実装されているかどうかを判断する際、以下のインタフェースは対象外となります。

- java.io.Serializable

- java.io.Externalizable

- javax.ejbパッケージで定義されたすべてのインタフェース

次のコードの抜粋に、Beanクラスのビジネス・インタフェースを明示的に実装して指定する方法を示します。

public class ServiceBean
implements Service

サンプル全体を見るには、「単純なビジネス・インタフェースを使用するステートレスEJBのサンプル」を参照してください

インタフェースなしのビューを指定する

ローカルのインタフェースなしのビューを公開するエンタープライズBeanへのクライアントのアクセスは、依存関係インジェクションまたはJNDIルックアップを介して実行されます。EJB 3.2では、MDBもインタフェースなしのローカル・クライアント・ビューを使用できます。

- 依存関係インジェクションを介してエンタープライズBeanのインタフェースなしのビューへの参照を取得するには、javax.ejb.EJBアノテーションを使用してエンタープライズBeanの実装クラスを指定します。

@EJB
ExampleBean exampleBean;

- JNDIルックアップを介してエンタープライズBeanのインタフェースなしのビューへの参照を取得するには、javax.naming.InitialContextインタフェースのルックアップ・メソッドを使用します。

ExampleBean exampleBean = (ExampleBean)
InitialContext.lookup("java:module/ExampleBean");

クライアントは、新しい演算子を使用してインタフェースなしのビューを使用するエンタープライズBeanの新しいインスタンスを取得することはありません。

WebLogic Server配布キットにバンドルされているインタフェースなしのクライアント・ビューを使用するサンプル・コードがあります。「EJB 3.1: 単純化されたインタフェースなしのプログラミングおよびWARファイルでのパッケージ化」および「EJB 3.2: メソッドのないリスナーを使用するメッセージドリブンBeanのサンプル」を参照してください。

インタフェースなしのクライアント・ビューの実装の詳細は、Java EE 7チュートリアル(http://docs.oracle.com/javaee/7/tutorial/index.html)の「エンタープライズBean」の章のインタフェースなしのビューを使用したローカル・エンタープライズBeanへのアクセスに関する項を参照してください。

Beanタイプ(ステートレス、シングルトン、ステートフル、メッセージドリブン)を指定する

3.2 Beanクラスで必須となるメタデータ・アノテーションは、プログラミングするBeanのタイプを指定するアノテーション1つのみです。以下のアノテーションのうち、いずれか1つのみを指定する必要があります。

- @javax.ejb.Stateless - ステートレス・セッションBeanをプログラミングすることを指定します。

- @javax.ejb.Singleton - シングルトン・セッションBeanをプログラミングすることを指定します。

- @javax.ejb.Stateful - ステートフル・セッションBeanをプログラミングすることを指定します。

- @javax.ejb.MessageDriven - メッセージドリブンBeanをプログラミングすることを指定します。

注意:

Oracle Kodo JPA/JDOは、このリリースのWebLogic Serverでサポートされなくなりました。ただし、Oracle Kodoを使用している場合は、個別のドキュメントの3.0エンティティBean(@javax.ejb.Entity)のプログラミングの説明を参照してください。

JPA 2.1をサポートするOracle TopLinkを使用することをお薦めします。Kodoでは、JPA 1.0のみをサポートします。詳細は、「Oracle WebLogic ServerでのOracle TopLinkの使用方法」を参照してください

必須ではありませんが、アノテーションの属性を指定すると、Beanタイプをより詳しく記述できます。たとえば、以下の属性はすべてのBeanタイプに設定できます。

- name - Beanクラスの名前です。デフォルト値は、未修飾のBeanクラス名です。

- mappedName - Beanの製品固有の名前です。

- description - Beanについての説明です。

メッセージドリブンBeanをプログラミングする場合は、以下の属性を指定することもできます。

- messageListenerInterface - メッセージ・リスナー・インタフェースを明示的に実装していない場合や、Beanに追加のインタフェースを実装する場合に、メッセージ・リスナー・インタフェースを指定します。

- activationConfig - アクティブ化構成の名前と値のペアの配列を指定します。この配列は、Beanを操作環境で構成するために使用します。

次のコードの抜粋に、Beanがステートレス・セッションBeanであることを指定する方法を示します。

@Stateless
public class ServiceBean
implements Service

サンプル全体を見るには、「単純なビジネス・インタフェースを使用するステートレスEJBのサンプル」を参照してください

変数またはセッター・メソッドにリソース依存性を注入する

「依存関係インジェクション」では、Beanコンテキスト内のリソースや他の環境エントリを元に、EJBコンテナによってBeanの変数またはセッター・メソッドが自動的に提供(または「注入」)されます。依存関係インジェクションは、javax.ejb.EJBContextインタフェースまたはJNDI APIを使用したリソースのルックアップを、より簡単にプログラミングするための方法にすぎません。

依存関係インジェクションを指定するには、注入するリソースのタイプに応じて、以下のアノテーションのいずれかを変数またはセッター・メソッドに追加します。

- @javax.ejb.EJB - 別のEJBへの依存性を指定します。

- @javax.annotation.Resource - 外部リソース(JDBCデータ・ソース、JMS宛先、接続ファクトリなど)への依存性を指定します。

注意:

このアノテーションは、EJB固有のものではありません。さまざまなJava EEコンポーネントで使用するメタデータ・アノテーションの共通セットの一部です。

これらのアノテーションには、複数のリソースへの依存性を指定するため、それぞれに相当するグループ化アノテーション(@javax.ejb.EJBsおよび@javax.annotation.Resources)があります。

必須ではありませんが、これらの依存性アノテーションに属性を指定すると、依存するリソースを明示的に記述できます。指定する必要のある情報の量は、その使用コンテキストと、EJBコンテナがそのコンテキストからどの程度の情報を推測できるかによって異なります。これらの属性の詳細と、どのような場合に使用すべきかについては、「javax.ejb.EJB」および「javax.annotation.Resource」を参照してください。

次のコード・スニペットでは、@javax.ejb.EJB アノテーションを使用して、EJBへの依存関係を変数に注入する方法を示します。ここでは、Beanファイル内の関連する部分のみを示します。

package examples;
import javax.ejb.EJB;
...
@Stateful
public class AccountBean
implements Account
{
@EJB(beanName="ServiceBean")
private Service service;
...
public void sayHelloFromAccountBean() {
service.sayHelloFromServiceBean();
}

この例では、プライベート属性serviceに@javax.ejb.EJBアノテーションを付けて、Bean名ServiceBeanでEJBへの参照を作成しています。サービス変数のデータ型はServiceです。これは、ServiceBean Beanクラスが実装するビジネス・インタフェースです。EJBコンテナは、AccountBean EJBを作成し、即座にServiceBeanへの参照をservice変数に注入します。これにより、この変数から、SessionBeanのすべてのビジネス・メソッドに直接アクセスできるようになります。その結果、例に示されているように、sayHelloFromAccountBeanメソッド実装でsayHelloFromServiceBeanメソッドを呼び出すことが可能になります。

3.0エンティティを呼び出す

この節では、セッションBean内から3.0エンティティを呼び出して更新する方法について説明します。

注意:

Oracle TopLink (JPA 2.1永続性プロバイダ)は、前のリリースのデフォルト・プロバイダのKodoに取ってかわり、デフォルトのJPAプロバイダになっています。persistence.xmlでJPAプロバイダが指定されていないアプリケーションでは、デフォルトでTopLinkが使用されます。詳細は、「Oracle WebLogic Serverでの永続性プロバイダの構成」を参照してください。

エンティティとは、データ・ストア・レコードを表す永続オブジェクトです。通常、エンティティのインスタンスは、データベース表の単一の行を表します。エンティティを使用すると、永続ストア内の情報の問合せや更新を、Java EEコンポーネント内(セッションBeanなど)から簡単に行えます。たとえば、Personエンティティであれば、name、address、ageなどのフィールドを含み、それぞれのフィールドがデータベース内の表の列に対応します。javax.persistence.EntityManagerオブジェクトを使用してエンティティにアクセスして管理する場合、一意のIDまたはSQL問合せを使用してPersonレコードを簡単に取得でき、情報を変更した場合はその情報が基底のデータ・ストアに自動的に送信されます。

以下の節では、セッションBeanをエンティティと対話させるために必要な一般的なプログラミング・タスクについて説明します。

- メタデータ・アノテーションを使用して永続性コンテキストを注入する

- EntityManager APIを使用してエンティティを検索する

- EntityManagerを使用してエンティティを作成および更新する

メタデータ・アノテーションを使用して永続性コンテキストを注入する

セッションBeanでは、以下のメタデータ・アノテーションを使用して、変数にエンティティ情報を注入できます。

- @javax.persistence.PersistenceContext - 永続性コンテキストをjavax.persistence.EntityManagerデータ型の変数に注入します。「永続性コンテキスト」は単なるエンティティのセットで、1つの永続IDに1つの一意のエンティティ・インスタンスが対応します。persistence.xmlファイル内に、セッションBeanで使用できる永続性コンテキストを定義して名前を付けます。

- @javax.persistence.PersistenceContexts - 複数の永続性コンテキストのセットを指定します。

- @javax.persistence.PersistenceUnit - 永続性コンテキストをjavax.persistence.EntityManagerFactoryデータ型の変数に注入します。

- @javax.persistence.PersistenceUnits - 複数の永続性コンテキストのセットを指定します。

@PersistenceContextアノテーションと@PersistenceUnitアノテーションは、ほとんど同じ機能(変数に永続性コンテキスト情報を注入する)を果たします。大きな違いは、情報の注入先となるインスタンスのデータ型です。セッションBean内のEntityManagerのライフサイクルを完全に制御したい場合は、@PersistenceUnitを使用してEntityManagerFactoryインスタンスに注入し、EntityManagerを手動で作成するためのコードを記述します。処理が完了したら、リソースを解放するために破棄します。EntityManagerのライフサイクルをEJBコンテナで管理したい場合は、@PersistenceContextアノテーションを使用してEntityManagerに直接注入します。

次の例では、永続性コンテキストをEntityManagerデータ型の変数emに注入する方法を示します。該当するコードは太字で示してあります。

package examples;

import javax.ejb.Stateless;

import javax.persistence.PersistenceContext;
import javax.persistence.EntityManager;

@Stateless
public class ServiceBean
implements Service

{
@PersistenceContext private EntityManager em;

...

EntityManager APIを使用してエンティティを検索する

EntityManagerオブジェクトをいったんインスタンス化したら、そのメソッドを使用して永続性コンテキスト内のエンティティと対話できます。この節では、エンティティのライフサイクルを特定および管理するメソッドについて説明します。EntityManagerのその他の用途(トランザクション管理、キャッシュ処理など)については、「Oracle WebLogic ServerでのOracle TopLinkの使用方法」を参照してください。

注意:

この節では、理解しやすいように、エンティティがデータベース表の実際の行を表すように構成されているものとします。

EntityManager.find()メソッドを使用すると、表内の行をその主キーに基づいて検索できます。findメソッドは2つのパラメータをとります。1つは問合せするエンティティ・クラス(たとえばPerson.class)、もう1つは取得する特定の行の主キーの値です。行を取得したら、標準のgetXXXメソッドを使用して、エンティティの特定のプロパティを取得できます。次のコードの抜粋に、主キーの値が10のPersonを検索してその住所を取得する方法を示します。

public List<Person> findPerson () {

Person p = em.find(Person.class, 10);
Address a = p.getAddress();

Query q = em.createQuery("select p from Person p where p.name = :name");
q.setParameter("name", "Patrick");
List<Person> l = (List<Person>) q.getResultList();

return l;

}

この例では、EntityManager.createQuery()メソッドを使用して、カスタムSQL問合せを含むQueryオブジェクトを作成する方法も示されています。この方法は、表の主キーだけで問合せできるEntityManager.find()メソッドとは対照的です。この例では、表内のPatrickという名前のPersonをすべて問合せし、行の結果セットをList<Person>オブジェクトに設定して呼出し側のメソッドfindPerson()に返しています。

EntityManagerを使用してエンティティを作成および更新する

新しいエンティティ・インスタンスを作成する(つまり、データベースに新しい行を追加する)には、EntityManager.persistメソッドを使用します。次にコードの抜粋を示します。

@TransactionAttribute(REQUIRED)
public Person createNewPerson(String name, int age) {

Person p = new Person(name, age);
em.persist(p); // register the new object with the database

Address a = new Address();
p.setAddress(a);
em.persist(a); // depending on how things are configured, this may or
// may not be required
return p;

}

注意:

エンティティの作成および更新は、常にトランザクション内から行う必要があります。この例で、@TransactionAttributeアノテーションがREQUIREDに設定されているのはそのためです。

前述の例では、createNewPersonメソッドに渡されたパラメータに基づいて新しいPersonを作成する方法を示しています。その後、EntityManager.persistメソッドを呼び出すことで、行がデータベース表に自動的に追加されます。

例では、新しく作成したPersonエンティティ(つまり、新しい表行)のAddressを、setAddress()エンティティ・メソッドを使用して更新する方法も示されています。Personエンティティのカスケード構成によっては、2番目のpersist()呼出しが不要な場合もあります。これは、データベースへの更新が、setAddress()メソッドによって自動的にトリガーされる場合があるためです。カスケード処理の詳細は、「Oracle WebLogic ServerでのOracle TopLinkの使用方法」を参照してください。

EntityManager.find()メソッドを使用してエンティティ・インスタンスを検索し、setXXXメソッドを使用してエンティティのプロパティを変更する場合は、データベースが自動的に更新されるため、 EntityManager.persist()メソッドを明示的に呼び出す必要はありません。次のコード・スニペットを参照してください。

@TransactionAttribute(REQUIRED)
public Person changePerson(int id, int newAge) {
Person p = em.find(Person.class, id);
p.setAge(newAge);
return p;
}

この例では、Person.setAge()メソッドの呼出しによって、データベース表内の適切な行への更新が自動的にトリガーされています。

EntityManager.merge()メソッドを使用すると、クライアントによるエンティティの更新に基づいて、データベース表内の行をすばやく簡単に更新できます。次に例を示します。

@TransactionAttribute(REQUIRED)
public Person applyOfflineChanges(Person pDTO) {
return em.merge(pDTO);
}

この例のapplyOfflineChanges()メソッドはセッションBeanのビジネス・メソッドで、パラメータとしてセッションBeanクライアントによって作成済みのPersonを取ります。このPersonをEntityManager.merge()メソッドに渡すと、EJBコンテナが自動的にデータベース表の既存の行を検索し、その行を新しいデータで更新します。更新後には、merge()メソッドによってその行のコピーが返されます。

ビジネス・メソッドまたはライフサイクル・コールバック・イベントのインターセプタを指定する

インターセプタは、ビジネス・メソッドの呼出しやライフサイクル・コールバック・イベントをインターセプトするメソッドです。インターセプタ・メソッドには、ビジネス・メソッドをインターセプトするメソッドと、ライフサイクル・コールバック・メソッドをインターセプトするメソッドの2種類があります。

インターセプタは、セッションBeanおよびメッセージドリブンBeanに指定できます。

インターセプタ・メソッドは、Beanクラス自体の中でプログラミングできますが、Beanクラスとは別にインターセプタ・クラスをプログラミングして@javax.interceptor.InterceptorsアノテーションでBeanクラスに関連付けることもできます。特定の順序でチェーンとして実行する複数のインターセプタ・メソッドを作成できます。

インターセプタ・インスタンスには状態を保持できます。インターセプタ・インスタンスのライフサイクルは、それが関連付けられているBeanインスタンスのライフサイクルと同じです。インターセプタからは、JNDI、JDBC、JMS、他のエンタープライズBean、およびEntityManagerを呼び出すことができます。インターセプタ・メソッドでは、その呼出しの対象となったBeanのJNDIネーム・スペースが共有されます。エンタープライズBeanのコンポーネントに適用する制約をプログラミングすると、それがインターセプタにも適用されます。

インターセプタは、javax.interceptorパッケージのメタデータ・アノテーションを使用して構成します。構成方法については後ほど説明します。

以下の節では、Beanクラスのインターセプタを実際にプログラミングする方法について説明します。

- ビジネス・インターセプタまたはライフサイクル・インターセプタを指定する:一般的な手順

- インターセプタ・クラスをプログラミングする

- ビジネス・メソッド・インターセプタ・メソッドをプログラミングする

- 非同期ビジネス・メソッドをプログラミングする

- ライフサイクル・コールバック・インターセプタ・メソッドをプログラミングする

- デフォルト・インターセプタ・メソッドを指定する

- InvocationContext APIを使用してインターセプタ間で状態を保存する

ビジネス・インターセプタまたはライフサイクル・インターセプタを指定する:一般的な手順

次に示す手順は、Beanクラスのインターセプタを指定してプログラミングする一般的な手順です。

インターセプタを指定しているサンプルについては「単純なステートフルEJBのサンプル」を、インターセプタ・クラスのプログラミングのサンプルについては「インターセプタ・クラスのサンプル」を参照してください。

1. インターセプタ・メソッドを、Beanクラス内でプログラミングするか、別のインターセプタ・クラス内でプログラミングするかを決めます。

2. インターセプタ・メソッドを別のインターセプタ・クラス内でプログラミングする場合は、次の手順に従います。

a. 「インターセプタ・クラスをプログラミングする」の説明に従ってクラスをプログラミングします

b. Beanクラスでは、@javax.interceptor.Interceptorsアノテーションを使用して、インターセプタ・クラスをBeanクラスに関連付けます。インターセプタ・クラス内のメソッドには、@javax.interceptor.AroundInvokeアノテーションを付けます。これで、そのBeanクラスのビジネス・メソッド・インターセプタ・メソッドになります。同様に、ライフサイクル・コールバック・アノテーションを付けたメソッドは、そのBeanクラスのライフサイクル・コールバック・インターセプタ・メソッドになります。

1つのBeanクラスに指定できるインターセプタ・クラスの数に制限はありません。複数のインターセプタ・クラスを指定した場合は、アノテーションに記述されている順序で実行されます。インターセプタ・クラスをクラス・レベルで指定した場合、インターセプタ・メソッドは適切なすべてのBeanクラス・メソッドに適用されます。インターセプタ・クラスをメソッド・レベルで指定した場合は、アノテーションを付けたメソッドにのみ適用されます。

3. インターセプタ・メソッドをプログラミングしたクラス(Beanクラスまたはインターセプタ・クラス)で、「ビジネス・メソッド・インターセプタ・メソッドをプログラミングする」の説明に従ってビジネス・メソッド・インターセプタ・メソッドをプログラミングします

4. インターセプタ・メソッドをプログラミングしたクラス(Beanクラスまたはインターセプタ・クラス)で、「ライフサイクル・コールバック・インターセプタ・メソッドをプログラミングする」の説明に従ってライフサイクル・コールバック・インターセプタ・メソッドをプログラミングします

5. 必要に応じ、Beanクラス内でメソッドに@javax.interceptor.ExcludeClassInterceptorsアノテーションを付けて、クラス・レベルで定義したインターセプタを除外します。

6. 必要に応じ、Beanクラス内でクラスまたはメソッドに@javax.interceptor.ExcludeDefaultInterceptorsアノテーションを付けて、後で定義する可能性のあるデフォルト・インターセプタを除外します。デフォルト・インターセプタは、ejb-jar.xmlデプロイメント記述子で構成します。アノテーションを使用して明示的に除外しない限り、JARファイル内のすべてのEJBに適用されます。

7. 必要に応じ、「デフォルト・インターセプタ・メソッドを指定する」の説明に従って、EJB JARファイル全体に適用されるデフォルト・インターセプタを指定します

インターセプタ・クラスをプログラミングする

インターセプタ・クラスは、インターセプタ・アノテーションを含むプレーンJavaクラスです。インターセプタ・アノテーションによって、どのメソッドでビジネス・メソッドやライフサイクル・コールバック・メソッドをインターセプトするかを指定します。

インターセプタ・クラスでは、依存関係インジェクションがサポートされます。依存関係インジェクションは、インターセプタ・クラス・インスタンスの作成時に、関連付けられているエンタープライズBeanのネーミング・コンテキストを使用して実行されます。

インターセプタ・クラスには、引数を取らないパブリック・コンストラクタを含める必要があります。

インターセプタ・クラスに含めるメソッドの数に制限はありませんが、インターセプタ・アノテーションを付けることのできるメソッドの数に上限があるためその制約を受けます。この点については、以降の節で説明します。

サンプルについては、「インターセプタ・クラスのサンプル」を参照してください

ビジネス・メソッド・インターセプタ・メソッドをプログラミングする

ビジネス・メソッド・インターセプタ・メソッドを指定するには、メソッドに@AroundInvokeアノテーションを付けます。

@AroundInvokeアノテーションを付けたメソッドは、インターセプタ・クラスまたはBeanクラスごとに1つしか指定できません。1つのビジネス・メソッドに対して複数のインターセプタ・メソッドを指定するには、Beanファイル自体の中にインターセプタ・メソッドを指定した上で(この指定は省略可能)、複数のインターセプタ・クラスをBeanファイルに関連付ける必要があります。インターセプタ・メソッドが実行される順序は、関連付けられたインターセプタ・クラスを@Interceptorアノテーション内で指定する順序によって決まります。Beanファイル自体の中に指定したインターセプタ・メソッドは、インターセプタ・クラス内に定義されたメソッドの後に実行されます。

ビジネス・メソッド自体に@AroundInvokeアノテーションを付けることはできません。

@AroundInvokeメソッドのシグネチャは次のようになっている必要があります。

Object <METHOD>(InvocationContext) throws Exception

@AroundInvokeアノテーションを付けたメソッドは、常にInvocationContext.proceed()を呼び出すようにするか、ビジネス・メソッドや後続の@AroundInvokeメソッドが呼び出されないようにする必要があります。InvocationContext APIの詳細については、「InvocationContext APIを使用してインターセプタ間で状態を保存する」を参照してください。

ビジネス・メソッド・インターセプタ・メソッドの呼出しは、対象となるビジネス・メソッドと同じトランザクションおよびセキュリティ・コンテキストの中で発生します。ビジネス・メソッド・インターセプタ・メソッドからは、ビジネス・メソッドのthrows句で許可されている実行時例外やアプリケーション例外が送出されることがあります。

サンプルについては、「インターセプタ・クラスのサンプル」を参照してください

非同期ビジネス・メソッドをプログラミングする

セッションBeanでは、非同期メソッド、ビジネス・メソッドを実装できます。これらのメソッドでは、そのメソッドがセッションBeanインスタンスで呼び出される前にエンタープライズBeanコンテナによってクライアントに制御が戻されます。これに続き、クライアントでは、Java SEの並行処理APIを使用して、結果の取得、呼出しの取消し、例外のチェックを実行できます。通常、非同期メソッドは、メソッドの呼出し結果が即座に必要でない場合に、アプリケーションのスループット向上やレスポンス時間短縮の方法として、長時間実行される処理、プロセッサ負荷の高いタスク、バックグラウンド・タスクに対して使用します。

非同期ではない通常のビジネス・メソッドをセッションBeanクライアントが呼び出した場合、メソッドが完了するまでクライアントには制御が戻りません。一方、クライアントで非同期メソッドを呼び出した場合は、エンタープライズBeanコンテナによってクライアントにただちに制御が戻されます。そのため、クライアントではメソッドの呼出しが完了するまでの間、他のタスクを実行できます。メソッドが結果を返す場合、その結果はjava.util.concurrent.Future<V>インタフェースの実装になります。「V」は結果値の型です。Future<V>インタフェースには、クライアントで使用するメソッドが定義されており、これらのメソッドを使用して、計算の完了状態のチェック、呼出し完了までの待機、最終結果の取得、呼出しの取消しを実行できます。

非同期メソッド呼出しのセマンティクスは、インタフェースなしのローカル・ビジネス・クライアント・ビューおよびリモート・クライアント・ビューのみに適用されます。EJB 2.xローカル、EJB 2.xリモート、およびWebサービス・クライアント・ビューを介して公開されるメソッドは、非同期として指定しないでください。

非同期ビジネス・メソッドの作成方法の詳細は、Java EE 7チュートリアル(http://docs.oracle.com/javaee/7/tutorial/index.html)の「エンタープライズBean」の章の非同期メソッドの呼出しに関する項を参照してください。

ライフサイクル・コールバック・インターセプタ・メソッドをプログラミングする

ライフサイクル・コールバック・インターセプタ・メソッドとして指定したメソッドは、EJBコンテナからライフサイクル・イベントの通知を受信できます。ライフサイクル・イベントには、Beanインスタンスの作成、パッシブ化、破棄などがあります。

ライフサイクル・コールバック・インターセプタ・メソッドには任意の名前を付けることができます。この点は、メソッドの名前をejbCreate()やejbPassivate()などにしなければならなかったEJB 2.xプログラミング・モデルとは異なります。

メソッドをライフサイクル・コールバック・インターセプタ・メソッドとして指定するには、以下のライフサイクル・インターセプタ・アノテーションを使用します。

- @javax.ejb.PrePassivate - EJBコンテナがステートフル・セッションBeanをパッシブ化する直前に通知を受信するメソッドを指定します。

- @javax.ejb.PostActivate - EJBコンテナがステートフル・セッションBeanを再アクティブ化した直後に通知を受信するメソッドを指定します。

- @javax.annotation.PostConstruct - EJBコンテナが1番目のビジネス・メソッドを呼び出す前と、依存関係インジェクションを完了した後に通知を受信するメソッドを指定します。通常、このアノテーションは、初期化を実行するメソッドに適用します。

注意:

このアノテーションは、javax.ejbパッケージではなく、javax.annotationパッケージに含まれています。

- @javax.annotation.PreDestroy - EJBコンテナがBeanインスタンスを破棄する直前に通知を受信するメソッドを指定します。通常、このアノテーションは、Beanクラスが保持しているリソースを解放するメソッドに適用します。

注意:

このアノテーションは、javax.ejbパッケージではなく、javax.annotationパッケージに含まれています。

上に挙げたアノテーションは、メソッドがBeanクラス内にあるか別のインターセプタ・クラス内にあるかに関係なく同じ方法で使用します。1つのメソッドに複数のアノテーションを付けることもできます。

また、Beanクラス内または関連付けられたインターセプタ・クラス内に、ライフサイクル・コールバック・アノテーションのサブセットや組み合わせを指定することも可能です。ただし、1つのクラス内に、同じコールバック・アノテーションを複数回指定することはできません。1つのクラス内に複数のコールバック・アノテーションを指定した場合、そのEJBはデプロイされません。

1つのライフサイクル・コールバック・イベントに対して複数のインターセプタ・メソッドを指定するには、Beanファイル自体の中にライフサイクル・コールバック・インターセプタ・メソッドを指定した上で(この指定は省略可能)、複数のインターセプタ・クラスをBeanファイルに関連付ける必要があります。インターセプタ・メソッドが実行される順序は、関連付けられたインターセプタ・クラスを@Interceptorアノテーション内で指定する順序によって決まります。Beanファイル自体の中に指定したインターセプタ・メソッドは、インターセプタ・クラス内に定義されたメソッドの後に実行されます。

アノテーションを付けたメソッドのシグネチャは、メソッドをどこで定義したかによって異なります。

- Beanクラスで定義したライフサイクル・コールバック・メソッドのシグネチャは次のようになります。

void <METHOD>()

- インターセプタ・クラスで定義したライフサイクル・コールバック・メソッドのシグネチャは次のようになります。

void <METHOD>(InvocationContext)

InvocationContext APIの詳細については、「InvocationContext APIを使用してインターセプタ間で状態を保存する」を参照してください。

ライフサイクル・インターセプタ・クラスをプログラミングする際のその他の要件については、「javax.ejb.PostActivate」、「javax.ejb.PrePassivate」、「javax.annotation.PostConstruct」、および「javax.annotation.PreDestroy」を参照してください。

サンプルについては、「インターセプタ・クラスのサンプル」を参照してください

デフォルト・インターセプタ・メソッドを指定する

デフォルト・インターセプタ・メソッドは、特定のEJB JARファイル内または展開されたディレクトリ内のすべてのコンポーネントに適用されます。したがって、必ずejb-jar.xmlデプロイメント記述子で構成する必要があり、メタデータ・アノテーションは特定のEJBにしか適用されないため使用できません。

デフォルト・インターセプタ・メソッドが設定されている場合、EJBコンテナは、EJBに対して定義されている他のすべてのインターセプタ(ビジネスおよびライフサイクルの両方)を呼び出す前に、このデフォルト・インターセプタ・メソッドを呼び出します。特定のEJBでデフォルト・インターセプタが呼び出されないようにするには、Beanファイルでクラス・レベルの@javax.interceptor.ExcludeDefaultInterceptorsアノテーションを指定します。

ejb-jar.xmlファイルでは、<assembly-descriptor>の<interceptor-binding>子要素を使用してデフォルト・インターセプタを指定します。具体的には、<ejb-name>子要素を*に設定してそのクラスがすべてのEJBに適用されるようにしてから、<interceptor-class>子要素をインターセプタ・クラスの名前に設定します。

次のejb-jar.xmlからの抜粋に、デフォルト・インターセプタ・クラスorg.mycompany.DefaultICを指定する方法を示します。

<?xml version="1.0" encoding="UTF-8"?>

<ejb-jar version="3.0"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">

...

<assembly-descriptor>

...

<interceptor-binding>
<ejb-name>*</ejb-name>
<interceptor-class>org.mycompany.DefaultIC</interceptor-class>
</interceptors>

</assembly-descriptor>

</ejb-jar>

InvocationContext APIを使用してインターセプタ間で状態を保存する

javax.interceptor.InvocationContext APIを使用すると、特定のビジネス・メソッドまたはライフサイクル・コールバックに対して実行するインターセプタ間で状態情報をやり取りできます。EJBコンテナは、同じInvocationContextインスタンスを各インターセプタ・メソッドに渡します。したがって、たとえばビジネス・メソッド・インターセプタ・メソッドを初めて実行したときの情報を保存しておき、このビジネス・メソッドに対して実行する後続のインターセプタ・メソッドにこの情報を渡すことができます。InvocationContextインスタンスは、ビジネス・メソッド呼出しやライフサイクル・コールバック呼出しの間では共有されません。

すべてのインターセプタ・メソッドは、InvocationContextパラメータを取る必要があります。これにより、InvocationContextインタフェースのメソッドを使用して、コンテキスト情報を取得したり設定したりすることが可能になります。次に、InvocationContextインタフェースを示します。

public interface InvocationContext {
public Object getBean();
public Method getMethod();
public Object[] getParameters();
public void setParameters(Object[]);
public java.util.Map getContextData();
public Object proceed() throws Exception;
}

getBeanメソッドは、Beanインスタンスを返します。getMethodメソッドは、呼び出されたインターセプタ・メソッドが対象とするビジネス・メソッドの名前を返します。ライフサイクル・コールバック・インターセプタ・メソッドの場合はnullを返します。

proceedメソッドは、チェーン内の次のインターセプタ・メソッドの呼出しを発生させます。チェーン内の最後の@AroundInvokeインターセプタ・メソッドから呼び出された場合は、ビジネス・メソッド自体の呼出しを発生させます。

InvocationContextを使用しているサンプルについては、「インターセプタ・クラスのサンプル」を参照してください

アプリケーション例外をプログラミングする

ビジネス・インタフェースにアプリケーション例外を送出するメソッドを指定した場合は、その例外をBeanクラスとは別のクラスとしてプログラミングする必要があります。

@javax.ejb.ApplicationExceptionアノテーションを使用すると、例外クラスがEJBのビジネス・メソッドによって送出されるアプリケーション例外であることを指定できます。アプリケーション・エラーが発生すると、EJBコンテナからクライアントに直接例外が報告されます。

アプリケーション・エラーが発生したときに現在のトランザクションをロールバックするかどうかを指定するには、@ApplicationExceptionのrollbackブール属性を使用します。デフォルトでは、エラーが発生しても現在のトランザクションはロールバックされません。

このアノテーションでは、検査済みの例外も未検査の例外も指定できます。

次に示すProcessingException.javaファイルでは、@ApplicationExceptionアノテーションを使用して、例外クラスがEJBのビジネス・メソッドによって送出されるアプリケーション例外であることを指定する方法を示します。

package examples;

import javax.ejb.ApplicationException;

/**
* Application exception class thrown when there was a processing error
* with a business method of the EJB.  Annotated with the
* @ApplicationException annotation.
*/

@ApplicationException()
public class ProcessingException extends Exception {

/**
* Catches exceptions without a specified string
*
*/
public ProcessingException() {}

/**
* Constructs the appropriate exception with the specified string
*
* @param message           Exception message
*/
public ProcessingException(String message) {super(message);}
}

EJBへのアクセスにセキュリティを設定する

デフォルトでは、EJBのパブリック・メソッドはどのユーザーでも呼び出すことができます。EJBへのアクセスを制限したい場合は、以下のセキュリティ関連アノテーションを使用して、すべてのメソッド(またはメソッドのサブセット)を呼び出すことができるロールを指定します。

- javax.annotation.security.DeclareRoles - EJBのセキュリティ設定に使用するセキュリティ・ロールのリストを明示的に宣言します。

- javax.annotation.security.RolesAllowed - EJBのメソッドを呼び出すことができるセキュリティ・ロールを指定します。すべてのメソッドを呼び出すことができるロールはクラス・レベルで指定し、特定のメソッドのみを呼び出すことができるロールはメソッド・レベルで指定します。

- javax.annotation.security.DenyAll - どのロールでも呼び出すことができないメソッドを指定します。

- javax.annotation.security.PermitAll - すべてのロールで呼び出すことができるメソッドを指定します。

- javax.annotation.security.RunAs - EJBを実行するロールを指定します。デフォルトでは、EJBはそれを実際に呼び出したユーザーとして実行されます。

上に挙げたアノテーションは、EJB 3.2だけでなく、メタデータ・アノテーションをサポートする様々なJava EEコンポーネントで使用できます。

セキュリティ・ロールを作成し、ロールにユーザーをマッピングするには、WebLogic Server管理コンソールでセキュリティ・レルムを更新します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理を参照してください。

次に、すべてのセキュリティ関連アノテーションを使用した単純なステートレス・セッションEJBのサンプルを示します。太字で示した部分については後ほど解説します。

package examples;

import javax.ejb.Stateless;

import javax.annotation.security.DeclareRoles;
import javax.annotation.security.PermitAll;
import javax.annotation.security.DenyAll;
import javax.annotation.security.RolesAllowed;
import javax.annotation.security.RunAs;

/**
* Bean file that implements the Service business interface.
*/

@Stateless
@DeclareRoles( { "admin", "hr" } )
@RunAs ("admin")

public class ServiceBean
implements Service
{
@RolesAllowed ( {"admin", "hr"} )
public void sayHelloRestricted() {
System.out.println("Only some roles can invoke this method.");
}

@DenyAll
public void sayHelloSecret() {
System.out.println("No one can invoke this method.");
}

@PermitAll
public void sayHelloPublic() {
System.out.println("Everyone can invoke this method.");
}
}

このサンプル・コードで注目すべき主な点は以下のとおりです。

- セキュリティ関連メタデータ・アノテーションをインポートしています。

import javax.annotation.security.DeclareRoles;
import javax.annotation.security.PermitAll;
import javax.annotation.security.DenyAll;
import javax.annotation.security.RolesAllowed;
import javax.annotation.security.RunAs;

- クラス・レベルの@DeclareRolesアノテーションは、後ほど設定する一部またはすべてのメソッドのセキュリティで、adminおよびhrセキュリティ・ロールを使用することを明示的に指定しています。このアノテーションは必須ではありません。たとえば、@RolesReferencedアノテーションで参照されるすべてのセキュリティ・ロールは暗黙的に宣言されます。しかし、セキュリティ・ロールを明示的に宣言することでコードが理解しやすくなります。

- クラス・レベルの@RunAsアノテーションは、EJBの特定のメソッドを実際にどのユーザーが呼び出したかに関係なく、EJBコンテナがメソッドをadminロールとして実行することを指定しています。もちろん、元のユーザーにそのメソッドの呼出しが許可されていることが前提になっています。

- sayHelloRestrictedメソッドの@RolesAllowedアノテーションは、このメソッドの呼出しをadminまたはhrロールにマッピングされているユーザーにのみ許可することを指定しています。

- sayHelloSecretメソッドの@DenyAllアノテーションは、このメソッドの呼出しをどのロールにマッピングされているユーザーにも許可しないことを指定しています。

- sayHelloPublicメソッドの@PermitAllアノテーションは、このメソッドの呼出しをどのロールにマッピングされているユーザーにも許可することを指定しています。

トランザクション管理とトランザクション属性を指定する

デフォルトでは、EJBコンテナはビジネス・メソッドをトランザクション・コンテキスト内で呼び出します。また、トランザクションをコミットまたはロールバックするかどうかはEJBコンテナ自体が決定します。これを、コンテナ管理によるトランザクションの境界設定といいます。

このデフォルト動作は、Beanファイルで以下のアノテーションを使用して変更できます。

- javax.ejb.TransactionManagement - トランザクションの境界設定を、EJBコンテナで管理するかBeanファイルで管理するかを指定します。Beanファイル管理を指定する場合は、Beanファイル内でトランザクション管理をプログラミングする必要があります。通常はJava Transaction API (JTA)を使用してプログラミングします。

- javax.ejb.TransactionAttribute - EJBコンテナがメソッドをトランザクション内で呼び出すかどうかを指定します。

javax.ejb.TransactionAttributeアノテーションを使用しているサンプルについては、「単純なステートフルEJBのサンプル」を参照してください

メタデータ・アノテーションの機能別一覧

以降の各節の表では、アノテーションを機能別にグループ化しています。ここに示すEJB 3.2メタデータ・アノテーションについては、完全なリファレンス情報を「EJBメタデータ・アノテーション・リファレンス」にアルファベット順でまとめてあります。

- Beanタイプを指定するためのアノテーション

- ローカル・インタフェースまたはリモート・インタフェースを指定するためのアノテーション

- EJB 2.xクライアント・ビューをサポートするためのアノテーション

- 3.0エンティティBeanを呼び出すためのアノテーション

- トランザクション関連のアノテーション

- インターセプタを指定するためのアノテーション

- ライフサイクル・コールバックを指定するためのアノテーション

- セキュリティ関連のアノテーション

- コンテキスト依存性アノテーション

- タイムアウトと例外のアノテーション

Beanタイプを指定するためのアノテーション

以下の表では、Beanタイプの指定に使用するアノテーションについて簡単に説明します。

表5-1 Beanタイプを指定するためのアノテーション

アノテーション

説明

@javax.ejb.Stateless

Beanクラスがステートレス・セッションBeanであることを指定します。詳細については、「javax.ejb.Stateless」を参照してください

@javax.ejb.Singleton

Beanクラスがシングルトン・セッションBeanであることを指定します。詳細は、「javax.ejb.Singleton」を参照してください

@javax.ejb.Stateful

Beanクラスがステートフル・セッションBeanであることを指定します。詳細は、「javax.ejb.Startup」を参照してください

@javax.ejb.Init

ステートフル・セッションBeanメソッドと、適合するEJB 2.1 EJBHomeまたはEJBLocalHomeクライアント・ビューのcreate<METHOD>メソッドとの対応関係を指定します。詳細については、「javax.ejb.Init」を参照してください

@javax.ejb.Remove

ステートフル・セッションBeanのremoveメソッドを指定します。詳細については、「javax.ejb.Remove」を参照してください

@javax.ejb.MessageDriven

BeanクラスがメッセージドリブンBeanであることを指定します。詳細については、「javax.ejb.MessageDriven」を参照してください

@javax.ejb.ActivationConfigProperty

操作環境でメッセージドリブンBeanを構成するために使用するプロパティを指定します。詳細については、「javax.ejb.ActivationConfigProperty」を参照してください

ローカル・インタフェースまたはリモート・インタフェースを指定するためのアノテーション

以下の表では、ローカル・インタフェースまたはリモート・インタフェースの指定に使用するアノテーションについて簡単に説明します。

表5-2 ローカル・インタフェースまたはリモート・インタフェースを指定するためのアノテーション

アノテーション

説明

@javax.ejb.Local

Beanのローカル・インタフェースを指定します。詳細については、「javax.ejb.Local」を参照してください

@javax.ejb.Remote

Beanのリモート・インタフェースを指定します。詳細については、「javax.ejb.Remote」を参照してください

EJB 2.xクライアント・ビューをサポートするためのアノテーション

以下の表では、EJB 2.Xクライアント・ビューのサポートに使用するアノテーションについて簡単に説明します。

表5-3 EJB 2.xクライアント・ビューをサポートするためのアノテーション

アノテーション

説明

@javax.ejb.LocalHome

Beanのローカル・ホーム・インタフェースを指定します。詳細については、「javax.ejb.LocalHome」を参照してください

@javax.ejb.RemoteHome

Beanのリモート・ホーム・インタフェースを指定します。詳細については、「javax.ejb.RemoteHome」を参照してください

3.0エンティティBeanを呼び出すためのアノテーション

以下の表では、3.0エンティティBeanの呼出しに使用するアノテーションについて簡単に説明します。

表5-4 3.0エンティティBeanを呼び出すためのアノテーション

アノテーション

説明

@javax.persistence.PersistenceContext

EntityManager永続性コンテキストへの依存関係を指定します。詳細は、「javax.persistence.PersistenceContext」を参照してください

@javax.persistence.PersistenceContexts

1つまたは複数のPersistenceContextアノテーションを指定します。詳細は、「javax.persistence.PersistenceContexts」を参照してください

@javax.persistence.PersistenceUnit

EntityManagerFactoryへの依存関係を指定します。詳細は、「javax.persistence.PersistenceUnit」を参照してください

@javax.persistence.PersistenceUnits

1つまたは複数のPersistenceUnitアノテーションを指定します。詳細は、「javax.persistence.PersistenceUnits」を参照してください

トランザクション関連のアノテーション

以下の表では、トランザクションに使用するアノテーションについて簡単に説明します。

表5-5 トランザクション関連のアノテーション

アノテーション

説明

@javax.ejb.TransactionManagement

トランザクションの境界設定管理の種類(コンテナ管理またはBean管理)を指定します。詳細については、「javax.ejb.TransactionManagement」を参照してください

@javax.ejb.TransactionAttribute

ビジネス・メソッドをトランザクションのコンテキスト内で呼び出すかどうかを指定します。詳細については、「javax.ejb.TransactionManagement」を参照してください

インターセプタを指定するためのアノテーション

以下の表では、インターセプタの指定に使用するアノテーションについて簡単に説明します。

表5-6 インターセプタを指定するためのアノテーション

アノテーション

説明

@javax.interceptor.Interceptors

Beanクラスまたはメソッドに関連付けるインターセプタ・クラスのリストを指定します。詳細については、「javax.interceptor.Interceptors」を参照してください

@javax.interceptor.AroundInvoke

インターセプタ・メソッドを指定します。詳細については、「javax.interceptor.AroundInvoke」を参照してください

@javax.interceptor.ExcludeClassInterceptors

アノテーションを付けたメソッドが呼び出されたときに、クラス・レベルのインターセプタを呼び出さないことを指定します。詳細は、javax.interceptor.ExcludeClassInterceptorsを参照してください

@javax.interceptor.ExcludeDefaultInterceptors

アノテーションを付けたメソッドが呼び出されたときに、デフォルト・インターセプタを呼び出さないことを指定します。詳細は、javax.interceptor.ExcludeDefaultInterceptorsを参照してください

ライフサイクル・コールバックを指定するためのアノテーション

以下の表では、ライフサイクル・コールバックの指定に使用するアノテーションについて簡単に説明します。

表5-7 ライフサイクル・コールバックを指定するためのアノテーション

アノテーション

説明

@javax.ejb.PostActivate

ステートフル・セッションBeanがアクティブ化された後にコールバックを受信するメソッドを指定します。詳細については、「javax.ejb.PostActivate」を参照してください

@javax.ejb.PrePassivate

ステートフル・セッションBeanがパッシブ化される前にコールバックを受信するメソッドを指定します。詳細については、「javax.ejb.PrePassivate」を参照してください

@javax.annotation.PostConstruct

依存関係インジェクションが完了した後に、初期化を実行するために呼び出す必要のあるメソッドを指定します。詳細については、「javax.annotation.PostConstruct」を参照してください

@javax.annotation.PreDestroy

コンテナがインスタンスを削除しようとしていることを知らせるコールバック通知を受信するメソッドを指定します。詳細については、「javax.annotation.PreDestroy」を参照してください

セキュリティ関連のアノテーション

以下のメタデータ・アノテーションは、EJB 3.2固有のアノテーションではなく、javax.annotation.securityパッケージに含まれる一般的なセキュリティ関連アノテーションです。

表5-8 セキュリティ関連のアノテーション

アノテーション

説明

@javax.annotation.security.DeclareRoles

Beanクラス内のセキュリティ・ロールへの参照を指定します。詳細については、「javax.annotation.security.DeclareRoles」を参照してください

@javax.annotation.security.RolesAllowed

Beanのビジネス・メソッドを呼び出すことができるセキュリティ・ロールのリストを指定します。詳細については、「javax.annotation.security.RolesAllowed」を参照してください

@javax.annotation.security.PermitAll

そのメソッドがすべてのセキュリティ・ロールで呼び出せることを指定します。詳細については、「javax.annotation.security.PermitAll」を参照してください

@javax.annotation.security.DenyAll

そのメソッドがどのセキュリティ・ロールでも呼び出せないことを指定します。詳細については、「javax.annotation.security.DenyAll」を参照してください

@javax.annotation.security.RunAs

そのメソッドをどのセキュリティ・ロールとして実行するかを指定します。詳細については、「javax.annotation.security.RunAs」を参照してください

コンテキスト依存性アノテーション

以下の表では、コンテキスト依存性に使用するアノテーションについて簡単に説明します。

表5-9 コンテキスト依存性アノテーション

アノテーション

説明

@javax.ejb.EJB

EJBビジネス・インタフェースまたはホーム・インタフェースへの依存性を指定します。詳細については、「javax.ejb.EJB」を参照してください

@javax.ejb.EJBs

1つまたは複数の@EJBアノテーションを指定します。詳細は、「javax.ejb.EJBs」を参照してください

@javax.annotation.Resource

Beanの環境内の外部リソースへの依存性を指定します。詳細については、「javax.annotation.Resource」を参照してください

@javax.annotation.Resources

1つまたは複数の@Resourceアノテーションを指定します。詳細は、「javax.annotation.Resources」を参照してください

タイムアウトと例外のアノテーション

以下の表では、タイムアウトと例外に使用するアノテーションについて簡単に説明します。

表5-10 タイムアウトと例外のアノテーション

アノテーション

説明

@javax.ejb.Timeout

Beanクラスのタイムアウト・メソッドを指定します。詳細については、「javax.ejb.Timeout」を参照してください

@javax.ejb.ApplicationException

例外がアプリケーション例外で、クライアントに直接報告することを指定します。詳細については、「javax.ejb.ApplicationException」を参照してください

タイマーとスケジューリングのアノテーション

以下の表では、タイマーおよびスケジューリングに固有のアノテーションに使用するアノテーションについて簡単に説明します。

表5-11 タイマーとスケジューリングのアノテーション

アノテーション

説明

@javax.ejb.Timeout

Beanクラスのタイムアウト・メソッドを指定します。詳細については、「javax.ejb.Timeout」を参照してください

@javax.ejb.ApplicationException

例外がアプリケーション例外で、クライアントに直接報告することを指定します。詳細については、「javax.ejb.ApplicationException」を参照してください

6 Enterprise JavaBeansのデプロイメント・ガイドライン

この章では、EJB固有のデプロイメント・ガイドラインについて説明します。すべてのデプロイ可能なアプリケーション・ユニットに共通のデプロイメント・トピックについては、『Oracle WebLogic Server へのアプリケーションのデプロイ』(WebLogic Serverアプリケーションおよびモジュールのデプロイメントに関する包括的なガイド)のトピックへの相互参照がこの章にあります。

この章の内容は次のとおりです。

- EJBをデプロイする前に

- デプロイメント・タスクの理解と実行

- EJBデプロイメントのガイドライン

EJBをデプロイする前に

デプロイメントのプロセスを開始する前に、以下の準備が必要です。

- 展開ディレクトリ形式の、またはデプロイメント記述子と一緒にアーカイブ・ファイル(スタンドアロンEJBの場合はJAR、EJBがエンタープライズ・アプリケーションの一部である場合はEAR、EJBがWebアプリケーションの一部である場合はWAR)にパッケージ化された、動作可能でテスト済のBeanコード。本番環境では、アプリケーションをEARとしてパッケージ化することをお薦めします。

注意:

EJB 3.1(以降)では、エンタープライズBeanクラスをejb-jarファイルの中にパッケージ化しなければならないという制限が取り除かれました。そのため、Webアプリケーション・クラスに適用される同じパッケージ化のガイドラインを使用して、EJBクラスをWebアプリケーション・アーカイブ(WAR)の中に直接パッケージ化できます。「Webアプリケーションの一部としてのEJBのデプロイメント」を参照してください

EJBの作成とパッケージ化に必要な手順の概要については、「EJB開発プロセスの概要」を参照してください

- 必要なアノテーション付きEJBクラスをプログラムして、@javax.ejb.Stateful、@javax.ejb.Stateless、@javax.ejb.Singletonまたは@javax.ejb.MessageDrivenのいずれかのEJBのタイプを指定します。
Beanクラスのプログラミングの詳細やサンプルについては、「アノテーション付きEJBクラスのプログラミング」を参照してください。

- オプションではあるものの、サポートされているデプロイメント記述子の構成。ejb-jar.xml、weblogic-ejb-jar.xml、およびコンテナ管理による永続性を使用するエンティティEJBの場合はweblogic-cmp-jar.xmlです。
EJBデプロイメント記述子の作成については、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のデプロイメント記述子の生成を参照してください。

デプロイメント・タスクの理解と実行

表6-1は、デプロイメント方法についての決定を支援したり、デプロイメント・タスクを実行する手順を説明したりするWebLogic Serverドキュメントのトピックへのガイドです。EJB固有のデプロイメント・トピックについては、「EJBデプロイメントのガイドライン」を参照してください

表6-1 デプロイメントのタスクとトピック

目的とする作業

参照先

開発環境でのデプロイメント

Oracle WebLogic Serverアプリケーションの開発の分割開発ディレクトリからのデプロイとパッケージ化。

デプロイメント・ツールの選択

Oracle WebLogic Serverへのアプリケーションのデプロイのデプロイメント・ツール

デプロイメント用の適切なパッケージ化の指定

Oracle WebLogic Serverへのアプリケーションのデプロイのアプリケーションおよびモジュールのデプロイメント準備。

分割ディレクトリ構造でのEJBコンポーネントの配置

Oracle WebLogic ServerへのアプリケーションのデプロイのEJB。

ステージング・モードの選択

Oracle WebLogic Serverへのアプリケーションのデプロイのステージング・モードによるデプロイメント・ファイルのコピーの制御

特定のデプロイメント・タスクの実行

Oracle WebLogic Serverへのアプリケーションのデプロイのデプロイメント・プロセスの概要。

EJBデプロイメントのガイドライン

以降の節では、EJBをデプロイするためのガイドラインを示します。

- エンタープライズ・アプリケーションの一部としてのスタンドアロンEJBのデプロイメント

- Webアプリケーションの一部としてのEJBのデプロイメント

- お互いに呼出しあう複数のEJBの同じアプリケーションでのデプロイメント

- 依存関係インジェクションを使用するEJBのデプロイメント

- クラスタへの均一なデプロイメント

- EJBのクラスタへのデプロイメント

- EJBの再デプロイメント

- FastSwapデプロイメントによるデプロイメントの最小化

- 警告メッセージの理解

- EJBデプロイメントの警告メッセージの無効化

エンタープライズ・アプリケーションの一部としてのスタンドアロンEJBのデプロイメント

スタンドアロンのEJBアプリケーションは、エンタープライズ・アプリケーションの一部としてパッケージ化およびデプロイすることをお薦めします。エンタープライズ・アプリケーションは、Webアプリケーション、EJB、およびリソース・アダプタが1つのデプロイメント・ユニットにまとめられたJava EE 7デプロイメント・ユニットです。

これは、アプリケーションの移行、追加、および変更を容易に行うことができるベスト・プラクティスです。また、アプリケーションをエンタープライズ・アプリケーションの一部としてパッケージ化することにより、分割開発ディレクトリ構造を活用できます。この構造には、従来の単一ディレクトリ構造に比べて多くの利点があります。

Oracle WebLogic Serverアプリケーションの開発の分割開発ディレクトリ環境の概要を参照してください。

Webアプリケーションの一部としてのEJBのデプロイメント

エンタープライズBeanは、Webアプリケーション・モジュール(WAR)内にパッケージ化することもできます。

EJB 3.1(以降)では、エンタープライズBeanクラスをejb-jarファイルの中にパッケージ化しなければならないという制限が取り除かれました。そのため、Webアプリケーション・クラスに適用される同じパッケージ化のガイドラインを使用して、EJBクラスをWebアプリケーション・アーカイブ(WAR)の中に直接パッケージ化できます。単にEJBクラスをWEB-INF/classesディレクトリかWEB-INF/libディレクトリ内のJARファイルに入れるのみです。必要に応じて、EJBデプロイメント記述子も使用する場合は、それをWEB-INF/ejb-jar.xmlとしてパッケージ化できます。appcコンパイラを実行すると、EJBコンポーネントにアクセスするために必要なクラスを持つWARファイルが生成されます。

WARでのEJBのパッケージ化を参照してください。

お互いに呼出しあう複数のEJBの同じアプリケーションでのデプロイメント

あるアプリケーションのEJBが別のアプリケーションのEJBを呼び出す場合、WebLogic Serverはクラスローディング上の必要からメソッドの引数を値で渡します。EJBが同じアプリケーション内にある場合、WebLogic Serverは参照によってメソッド引数を渡せます。それにより、パラメータのコピーが行われないので、メソッド呼出しのパフォーマンスが向上します。

最高のパフォーマンスを引き出すには、お互いに呼出しあうコンポーネントを同じアプリケーションにパッケージ化し、weblogic-ejb-jar.xmlのenable-call-by-referenceをTrueに設定します。(デフォルトでは、enable-call-by-referenceはFalseです。)

プロトコル切替えの制限

アプリケーション・クライアント・リクエストに複数のホップがあり、QOSの構成がサーバー間で異なる場合は、プロトコルを切り替える必要があります。

たとえば、クライアントがSSLリクエストをJMSのフロントエンド・クラスタに送信する際、JMSのフロントエンド・クラスタはそのリクエストをクリア・テキストを使用してJMSのバックエンド・クラスタに転送します。この場合、t3sプロトコルからt3プロトコルへの切替えが必要なことがあります。

注意:
プロトコルの切替えはデフォルトのチャネルでのみ可能です。カスタム・チャネルではプロトコルの切替えはサポートされていません。

依存関係インジェクションを使用するEJBのデプロイメント

EJBで依存関係インジェクションを使用する場合、クラスで定義したリソース名とスーパークラスは、一意でなければなりません。例:

public class ClientServlet extends HttpServlet {
@EJB(name = 'DateServiceBean', beanInterface = DateService.class)
private DateService bean; .... }
public class DerivedClientServlet extends ClientServlet {
@EJB(name = MyDateServiceBean', beanInterface = DateService.class)
private DateService bean; .... }

依存関係インジェクションについては、Oracle WebLogic Serverアプリケーションの開発のJava EEアノテーションと依存関係インジェクションの使用を参照してください。

クラスタへの均一なデプロイメント

EJBがWebLogic Serverクラスタで動作する場合は、それらのEJBを均一に(クラスタ内の各管理対象サーバーに)デプロイすることをお薦めします。EJBは、クラスタ内の1つのサーバーのみにデプロイする(つまり、モジュールをサーバーに"固定"する)こともできます。このタイプのデプロイメントはそれほど一般的ではなく、固定サービスが要求される特別な状況においてのみ行うようにする必要があります。詳細は、Oracle WebLogic Serverクラスタの管理のクラスタ構成の理解を参照してください。

EJBのクラスタへのデプロイメント

未コンパイルのEJBは、デプロイ中にクラスタ内のすべてのサーバー・インスタンスにコピーされますが、このEJBはデプロイ先のサーバー・インスタンス上でしかコンパイルされません。その結果、クラスタ内でEJBのターゲットとなっていないサーバー・インスタンスでは、EJBの呼出しに必要なクラスが不足します。

クラスタ内の単一のサーバー・インスタンスへEJBをデプロイまたは再デプロイする場合、クライアントはクラスタ内の別のサーバーを通じてEJBアプリケーションを呼び出せるようになります。

固定デプロイメントの詳細は、Oracle WebLogic Serverクラスタの管理の単一のサーバー・インスタンスへのデプロイ(固定デプロイメント)を参照してください。

EJBの再デプロイメント

デプロイしたEJBのクラスに変更を加えたら、そのEJBを再デプロイする必要があります。自動デプロイメントを使用すると、WebLogic Serverの再起動時にデプロイメントが自動的に行われます。それ以外の場合は、EJBを明示的に再デプロイする必要があります。

EJBデプロイメントを再デプロイすると、EJBプロバイダがデプロイ済みのEJBクラスを変更し、再コンパイルしてから、動作中のサーバーのクラスを「リフレッシュ」できるようになります。

再デプロイを行うと、そのEJBで現在ロードされているクラスがサーバー内ですぐに使用不可になったことが示され、EJBのクラスローダーと関連クラスが削除されます。同時に、改版されたEJBのクラスをロードして維持する新規のEJBクラスローダーが作成されます。

クライアントが次にEJBへの参照を必要とする場合、クライアントのEJBメソッドの呼出しでは、変更済みのEJBクラスが使用されます。

Oracle WebLogic Serverの理解のシステム管理ツールおよびAPIのサマリーにリストされている管理ツールのいずれかを使用して、スタンドアロンのEJBまたはアプリケーションの一部であるEJBを再デプロイできます。手順については、Oracle WebLogic Serverへのアプリケーションのデプロイの本番環境でのアプリケーションの再デプロイを参照してください。

以下のものに対しては、本番再デプロイメントはサポートされません。

- JTSドライバを使用するアプリケーション。

- EJB 1.1のコンテナ管理による永続性(CMP) EJBを含むアプリケーション。CMP EJBを含むアプリケーションで本番再デプロイメントを使用するには、EJB 1.1 CMPではなくEJB 2.x CMPを使用します。

本番再デプロイメントの制限の詳細は、Oracle WebLogic Serverへのアプリケーションのデプロイの本番再デプロイメントの要件と制限事項を参照してください。

FastSwapデプロイメントによるデプロイメントの最小化

あるEJBアプリケーションを繰返し開発する場合は、EJBの実装クラス・ファイルに多くの変更を加えて、通常は開発中に何度もEJBモジュールを再デプロイします。

Java EE 5では、ClassLoaderを削除したり既存のインスタンスを破棄したりすることなく、実行時にクラスを再定義する機能が導入されています。これにより、コンテナは実行中のアプリケーションに影響を与えることなく、変更されたクラスを再ロードできるため、反復的な開発サイクル時間が大幅に短縮され、開発およびテスト全体が改善されています。

FastSwapを使用すると、ClassLoaderを再ロードせずにインプレースでJavaクラスを再定義するため、所要時間を短縮できるという点で明らかに有利です。つまり、変更がアプリケーションによって再デプロイされて有効になるまで待つ必要はありません。かわりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。

FastSwapの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。

警告メッセージの理解

特定の警告に関する詳細情報は、weblogic.GetMessageツールで取得できます。例:

java weblogic.GetMessage -detail -id BEA-010202

EJBデプロイメントの警告メッセージの無効化

WebLogic Serverでは、デプロイメント中に発生する特定の警告メッセージを無効化できます。この機能は、すでにわかっている情報をメッセージが通知する場合に便利です。

たとえば、EJBのメソッドが値ではなく参照で呼出しを行う場合、WebLogic Serverはデプロイメントの過程で「Call-by-reference not enabled.」という警告メッセージを生成します。

weblogic-ejb-jar.xmlでdisable-warning要素を使用すると、特定のメッセージを無効化できます。無効化できるメッセージのリストとメッセージを無効化する方法の詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスの章のdisable-warningを参照してください。

7 Oracle WebLogic Serverでの組込みEJBコンテナの使用方法

この章では、Oracle WebLogic Serverで組込み可能なEJBコンテナを使用する方法の概要を説明します。

この章の内容は次のとおりです:

- 組込み可能なEJBコンテナの概要

- 組込みEJBコンテナでサポートされるEJB Liteの機能

組込み可能なEJBコンテナの概要

従来のJava EEサーバーベースの実行とは異なり、組込み可能なコンテナを使用することで、クライアント・コードとそれに対応するエンタープライズBeanをJava EEサーバーにデプロイしなくてもJava SE環境で実行できます。これにより、テスト、オフライン処理(バッチ・ジョブなど)、およびデスクトップ・アプリケーションのEJBプログラミング・モデルの使用に対するサポートが向上します。

Java EEサーバーのエンタープライズBeanコンテナに存在するほとんどのサービスは、注入、コンテナ管理のトランザクションおよびセキュリティを含め、組込みエンタープライズBeanコンテナで使用できます。エンタープライズBeanコンポーネントは組込みでもJava EE環境でも同様に実行されるため、同じエンタープライズBeanをスタンドアロンおよびネットワーク・アプリケーションの両方で容易に再利用できます。

Java SE環境で組込みEJBコンテナを使用する詳細な例は、「EJB 3.1: Java SEで組込み可能なEJBコンテナを使用するサンプル」を参照してください

組込みEJBコンテナでサポートされるEJB Liteの機能

組込みEJBコンテナでは、EJB 3.2 APIのEJB Liteサブセットがサポートされます。EJB Liteは、定義上、機能のサブセットであり、新しい機能を記述するものではありません。この項では、EJB 3.2仕様で定義されているEJB Liteのサポート要件の概要を説明します。

表7-1は、EJB 3.2仕様で定義されているEJB Lite機能の正式な要件を表します。

表7-1 EJB LiteとEJB 3.2全機能の要件

要件

EJB Lite

EJB 3.2全機能

コンポーネント

セッションBean (ステートフル、ステートレス、シングルトン)

はい

はい

メッセージドリブンBean

いいえ

はい

2.x/1.1 CMP/BMPエンティティBean

いいえ

はい

JPA 2.1

はい

はい

セッションBeanクライアント・ビュー

ローカル/インタフェースなし

はい

はい

3.xリモート

いいえ

はい

2.xリモート・ホーム/コンポーネント

いいえ

はい

JAX-WS Webサービス・エンドポイント

いいえ

はい

JAX-RPC Webサービス・エンドポイント

いいえ

はい

サービス

EJBタイマー・サービス(非永続)

はい

はい

非同期セッションBeanの呼出し(ローカル)

はい

はい

インターセプタ

はい

はい

RMI-IIOPの相互運用性

いいえ

はい

コンテナ管理のトランザクション/Bean管理のトランザクション

はい

はい

宣言によるセキュリティとプログラムによるセキュリティ

はい

はい

その他

組込み可能なAPI

はい

はい

8 Oracle WebLogic Serverでの永続性プロバイダの構成

この章では、Oracle WebLogic Serverのデフォルトの永続性プロバイダであるOracle TopLinkについて説明し、その使用方法を紹介します。この章では、WebLogic Serverでデフォルトの永続性プロパイダを設定する方法も説明します。

この章の内容は次のとおりです:

- Oracle TopLinkの概要

- 永続性プロバイダの指定

- Oracle WebLogic ServerでのOracle TopLinkの使用方法

Oracle TopLinkの概要

Oracle TopLinkは、WebLogic Server 12c以降のデフォルトの永続性プロバイダです。これは、包括的な標準ベースのオブジェクト永続性およびオブジェクト変換フレームワークであり、アプリケーションの永続性レイヤーに関するAPI、スキーマ、ランタイム・サービスを提供します。

TopLinkのコア・コンポーネントは、EclipseLinkプロジェクトで作成されたライブラリとユーティリティで構成されています。EclipseLinkとは、TopLinkで提供される開発フレームワークおよびランタイムのオープン・ソース実装です。EclipseLinkでは、次の仕様に加えて付加価値機能を実装します。

- Java Persistence 2.1 (JPA 2.1)。
JPA 2.1には、Criteria Bulk Update/Delete、ストアド・プロシージャ、JPQL汎用関数、インジェクション可能なエンティティ・リスナー、TREAT、コンバータ、DDL生成およびエンティティ・グラフなどの機能に対する新しいサポートまたは拡張が含まれます。JPA 2.1の完全な仕様は、「JSR-000338 Java Persistence 2.1 (Final Release)」(http://jcp.org/aboutJava/communityprocess/final/jsr338/index.html)を参照してください。

- Java Architecture for XML Binding (JAXB) 2.2(EclipseLink JAXB実装、およびEclipseLink拡張機能は、MOXyと呼ばれています。)
JAXB 2.0仕様については、「JSR-000222 Java Architecture for XML Binding (JAXB) 2.0」(http://jcp.org/aboutJava/communityprocess/pfd/jsr222/index.html)を参照してください。

- EclipseLinkには、Database Web Service (DBWS)も含まれます。これは、Java API for XML Web Services (JAX-WS) 2 Webサービスを使用することで、リレーショナル・データベース・アーティファクトへのアクセスを提供します。

EclipseLinkは、Oracle SpatialおよびOracle XDBのマッピング機能もサポートします。

サポートされるその他のサービスを含め、EclipseLinkに関する詳細は、EclipseLinkプロジェクト・ホーム(http://wiki.eclipse.org/EclipseLink)およびEclipseLink/Documentation Center(http://wiki.eclipse.org/EclipseLink/UserGuide)を参照してください。

すべてのEclipseLinkに加えて、Oracle TopLinkには次が含まれます。

- TopLink Grid。EclipseLinkでOracle Coherenceをレベル2 (L2)キャッシュおよびエンティティの永続性レイヤーとして使用するためのEclipseLink JPAとOracle Coherenceとの統合です。詳細は、Oracle Coherenceでのアプリケーションの開発およびを参照してください。

注意:

Oracle CoherenceでTopLink Gridを使用するためのライセンスが必要です。

- WebLogic Serverとのロギングの統合。

- WebLogic ServerでのMBeanのサポート。

Oracle TopLinkアプリケーションの開発、デプロイメント、および構成の詳細は、次を参照してください。

- Oracle TopLinkソリューション・ガイド

- Oracle TopLinkの理解

- Oracle TopLinkのJava APIリファレンス

注意:

前述のドキュメントはOracle TopLink 12.1.3用ですが、現在のバージョンのWebLogic Serverにも適用されます。

次のEclipseLinkの資料も参照してください。

- EclipseLink Documentation Center (http://www.eclipse.org/eclipselink/documentation/)

- EclipseLinkサンプル(http://wiki.eclipse.org/EclipseLink/Examples)

永続性プロバイダの指定

次の項で説明するように、アプリケーション・コードの永続性ユニットで使用する永続性プロバイダを指定するか、あるいはWebLogic Serverドメインのデフォルト永続性プロバイダを受け入れることができます。

- ドメインのデフォルト・プロバイダの設定

- アプリケーションでの永続性プロバイダの指定

ドメインのデフォルト・プロバイダの設定

他に何も指定していないと、WebLogic Serverドメインのデフォルト永続性プロバイダとしてTopLinkが使用されます。デフォルト・プロバイダは、別の永続性プロバイダを使用するように構成されていないアプリケーションの任意のエンティティで使用されます。デフォルト・プロバイダは、注入されたエンティティ・マネージャおよびファクトりでもアプリケーション管理のエンティティ・マネージャおよびファクトリでも使用されます。

デフォルト・プロバイダは、WebLogic Server管理コンソールで設定することも、直接JPAMBean.DefaultJPAProviderで設定することもできます。

注意:

Oracle Kodo JPA/JDOは、このリリースのWebLogic Serverでサポートされなくなりました。JPA 2.1をサポートするOracle TopLinkを使用することをお薦めします。Kodoでは、JPA 1.0のみをサポートします。

WebLogic Server管理コンソールでデフォルトを設定する方法は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデフォルトのJPA永続性プロバイダの構成を参照してください。

デフォルト・プロバイダを変更する場合、JPAプロバイダを指定しない任意のデプロイされたアプリケーションに対して次を実行する必要があります。

- アプリケーション管理によるエンティティ・マネージャ・ファクトリを使用するアプリケーションを再起動します。

- 注入されたエンティティ・マネージャ・ファクトリまたはエンティティ・マネーシャを使用するアプリケーションを再デプロイします。

アプリケーションでの永続性プロバイダの指定

アプリケーションで指定された永続性プロバイダは、WebLogic Serverドメインに設定されたデフォルト・プロバイダより優先されます。

使用するプロバイダは、次のようにして設定できます。

- persistence.xmlファイル内の永続性ユニットの<provider>要素でプロバイダを指定します。例:

<persistence-unit name="example">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
...
</persistence-unit>

- javax.persistence.Persistence.createEntityManagerFactory(String, Map)メソッドのMapパラメータに渡すjavax.persistence.providerプロパティでプロバイダを指定します。

Oracle WebLogic ServerでのOracle TopLinkの使用方法

WebLogic ServerでのOracle TopLinkの使用の詳細は、Oracle TopLinkソリューション・ガイドのWebLogic ServerでのTopLinkの使用を参照してください。これはOracle TopLink 12.1.3の刊行物ですが、現在のバージョンのWebLogic Serverに適用されます。

A EJB メタデータ・アノテーション・リファレンス

この付録では、EJB 3.xメタデータ・アノテーションのリファレンス情報を提供します。

この付録の内容は次のとおりです。

- EJB 3.xアノテーションの概要

- ステートレスBean、ステートフルBean、メッセージドリブンBeanのアノテーション

- インターセプタの構成に使用するアノテーション

- エンティティBeanとの対話に使用するアノテーション

- EJB 3.xで使用する標準JDKアノテーション

- EJB 3.xで使用するセキュリティ関連の標準JDKアノテーション

- WebLogicアノテーション

EJB 3.xアノテーションの概要

WebLogic Server EJB 3.2プログラミング・モデルでは、Java EE 7メタデータ・アノテーション機能を使用して、アノテーション付きEJB 3.2 Beanファイルを作成し、標準Javaコンパイラでクラスをコンパイルします。生成されたクラスは、デプロイメント用のターゲット・モジュールにパッケージ化できます。実行時に、WebLogic Serverはアノテーションを解析して、必要な動作のアスペクトをBeanファイルに適用します。

以降の節では、EJB Beanファイルで指定できるメタデータ・アノテーションのリファレンス情報を提供します。一部のアノテーションはjavax.ejbパッケージに含まれています。つまり、EJBに固有のアノテーションです。それ以外のアノテーションは、より一般的で他のJava EE 7コンポーネントでも使用するアノテーションです。したがって、javax.annotationなどの一般的なパッケージに含まれています。

注意:

EJB実装で引き続きデプロイメント記述子を使用する場合は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のEJBデプロイメント記述子に関する項を参照してください。

ステートレスBean、ステートフルBean、メッセージドリブンBeanのアノテーション

この節では、以下のアノテーションのリファレンス情報を提供します。

- javax.ejb.AccessTimeout

- javax.ejb.ActivationConfigProperty

- javax.ejb.AfterBegin

- javax.ejb.AfterCompletion

- javax.ejb.ApplicationException

- javax.ejb.Asynchronous

- javax.ejb.BeforeCompletion

- javax.ejb.ConcurrencyManagement

- javax.ejb.DependsOn

- javax.ejb.EJB

- javax.ejb.EJBs

- javax.ejb.Init

- javax.ejb.Local

- javax.ejb.LocalBean

- javax.ejb.LocalHome

- javax.ejb.Lock

- javax.ejb.MessageDriven

- javax.ejb.PostActivate

- javax.ejb.PrePassivate

- javax.ejb.Remote

- javax.ejb.RemoteHome

- javax.ejb.Remove

- javax.ejb.Schedule

- javax.ejb.Schedules

- javax.ejb.Singleton

- javax.ejb.Startup

- javax.ejb.StatefulTimeout

- javax.ejb.Stateless

- javax.ejb.Timeout

- javax.ejb.TransactionAttribute

- javax.ejb.TransactionManagement

javax.ejb.AccessTimeout

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド、型

タイムアウトするまで同時アクセスがブロックされる時間を任意の時間単位で指定します。

このアノテーションは、コンテナ管理による同時実行性を使用する、ステートフル・セッションBeanまたはシングルトン・セッションBeanに適用できます。

デフォルトでは、クライアントはステートフル・セッション・オブジェクトに対して同時呼出しを実行できますが、このような同時リクエストはコンテナでシリアライズする必要があります。AccessTimeoutアノテーションは、ステートフル・セッションBeanインスタンスがすでに別のリクエストを処理している場合に、そのBeanへのリクエストがブロックされる時間を指定するために使用します。AccessTimeoutアノテーションの値に0を指定すると、ステートフル・セッションBeanへの同時クライアント・リクエストを禁止するようにコンテナに指示されます。

AccessTimeoutアノテーションは、ビジネス・メソッドまたはBeanクラスに指定できます。クラスに指定した場合は、そのクラスのすべてのビジネス・メソッドに適用されます。クラスおよびそのクラスのビジネス・メソッドの両方に指定した場合、そのメソッドではメソッド・レベルのアノテーションが優先されます。

シングルトン・セッションBeanの場合、アクセス・タイムアウトは同時実行性のロックを使用できるメソッドのみに適用されます。AccessTimeoutアノテーションは、シングルトン・セッションBeanクラスまたはそのクラスの該当するメソッドに指定できます。AccessTimeoutをクラスおよびクラスのビジネス・メソッドの両方で指定した場合、そのメソッドではメソッド・レベルのアノテーションが優先されます。

詳細は、「EJBタイマー・サービスのプログラミング(省略可能)」を参照してください

属性

次の表で属性について簡単に説明します。

表A-1 javax.ejb.AccessTimeoutアノテーションの属性

名前

説明

データ型

必須?

value

タイムアウトするまで同時アクセスがブロックされる時間を任意の時間単位で指定します。

- 0よりも大きい場合は、unit要素で指定した単位によるタイムアウト値を示します。

- 0の場合は、同時アクセスが許可されないことを意味します。

- -1の場合は、クライアント・リクエストは、前のリクエストが処理されるまで無期限にブロックされることを示します。

-1よりも小さい値は無効です。

Long

いいえ

unit

指定した値に使用する単位を指定します。

この属性のデフォルト値はjava.util.concurrent.TimeUnit.MILLISECONDSです。

TimeUnit

いいえ

javax.ejb.ActivationConfigProperty

以降の節では、このアノテーションについて詳しく説明します。

注意:

Enterprise JavaBean仕様に基づき、javax.ejb.ActivationConfigPropertyはMDBでのみ使用されます。このアノテーションは、セッションBeanおよびエンティティBeanでは使用されません。

説明

ターゲット: すべて

操作環境でメッセージドリブンBeanを構成するために使用するプロパティを指定します。確認応答モード、メッセージ・セレクタ、想定される宛先やエンドポイントのタイプなどの情報を含めることができます。ActivationConfigPropertyはメッセージドリブンBeanでのみ使用され、セッションBeanおよびエンティティBeanでは使用されません。

このアノテーションは、@javax.ejb.MessageDrivenアノテーションのactivationConfig属性の値としてのみ使用します。このアノテーションの詳細は、Oracle WebLogic ServerメッセージドリブンBeanの開発のEJB 3.2準拠MDBの使用とMDB向けデプロイメント要素およびアノテーションを参照してください。

属性

次の表で属性について簡単に説明します。

表A-2 javax.ejb.ActivationConfigPropertyアノテーションの属性

名前

説明

データ型

必須?

propertyName

アクティブ化プロパティの名前を指定します。

String

はい

propertyValue

アクティブ化プロパティの値を指定します。

String

はい

javax.ejb.AfterBegin

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

after beginセッション同期コールバックを受信するステートフル・セッションBeanメソッドを指定します。

after beginコールバックは、ステートフル・セッションBeanインスタンスに対して、新しいトランザクションが開始されたこと、およびそのインスタンスに対する以降のビジネス・メソッドがそのトランザクションのコンテキスト内で呼び出されることを通知します。

このメソッドは適切なトランザクション・コンテキスト内で実行されます。Beanで使用できるAfterBeginメソッドは1つまでです。このメソッドのシグネチャは次のルールに従う必要があります。

- finalやstaticとして宣言することはできません。

- 任意のアクセス・タイプを指定できます。

- 戻り型はvoidでなければなりません。

- 引数を取ることはできません。

このメソッドはトランザクション・コンテキストを使用せずに実行されます。

ステートフル・セッションBeanクラスでは、SessionSynchronizationインタフェースまたはセッション同期アノテーションのいずれかを使用できますが、両方使用することはできません。

javax.ejb.AfterCompletion

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

after completionセッション同期コールバックを受信するステートフル・セッションBeanメソッドを指定します。

after completionコールバックは、ステートフル・セッションBeanインスタンスに対して、トランザクションのコミット・プロトコルが完了したことを通知します。完了ステータスがtrueの場合は、トランザクションがコミットされたことを示します。ステータスがfalseの場合は、ロールバックが行われたことを示します。

Beanで使用できるAfterCompletionメソッドは1つまでです。このメソッドのシグネチャは次のルールに従う必要があります。

- finalやstaticとして宣言することはできません。

- 任意のアクセス・タイプを指定できます。

- 戻り型はvoidでなければなりません。

- boolean型の引数を1つ取る必要があります。

このメソッドはトランザクション・コンテキストを使用せずに実行されます。

ステートフル・セッションBeanクラスでは、SessionSynchronizationインタフェースまたはセッション同期アノテーションのいずれかを使用できますが、両方使用することはできません。

javax.ejb.ApplicationException

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

その例外がアプリケーション例外で、クライアント・アプリケーションに直接(ラップせずに)報告することを指定します。

このアノテーションは、検査済みの例外と未検査の例外の両方に適用できます。

属性

次の表で属性について簡単に説明します。

表A-3 javax.ejb.ApplicationExceptionアノテーションの属性

名前

説明

データ型

必須?

rollback

BeanがEJBコンテナ内部で呼び出されている場合に、例外が送出されたらトランザクションをロールバックするかどうかを指定します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はfalseで、その場合トランザクションはロールバックされません。

boolean

いいえ

javax.ejb.Asynchronous

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド、型

セッションBeanメソッドを非同期メソッドとして示す場合や、セッションBeanクラスのすべてのビジネス・メソッドを非同期として指定する場合に使用します。これらのメソッドでは、そのメソッドがセッションBeanインスタンスで呼び出される前にエンタープライズBeanコンテナによってクライアントに制御が戻されます。通常、非同期メソッドは、メソッドの呼出し結果が即座に必要でない場合に、アプリケーションのスループット向上やレスポンス時間短縮の方法として、長時間実行される処理、プロセッサ負荷の高いタスク、バックグラウンド・タスクに対して使用します。

クライアントで非同期メソッドを呼び出した場合は、エンタープライズBeanコンテナによってクライアントにただちに制御が戻されます。そのため、クライアントではメソッドの呼出しが完了するまでの間、他のタスクを実行できます。メソッドが結果を返す場合、その結果は戻り型voidまたはjava.util.concurrent.Future<V>インタフェースの実装になります。Vは結果値の型です。Future<V>インタフェースには、クライアントで使用するメソッドが定義されており、これらのメソッドを使用して、計算の完了状態のチェック、呼出し完了までの待機、最終結果の取得、呼出しの取消しを実行できます。

非同期メソッド呼出しのセマンティクスは、インタフェースなしのローカル・ビジネス・クライアント・ビューおよびリモート・クライアント・ビューのみに適用されます。EJB 2.xローカル、EJB 2.xリモート、およびWebサービス・クライアント・ビューを介して公開されるメソッドは、非同期として指定しないでください。

javax.ejb.BeforeCompletion

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

before completionセッション同期コールバックを受信するステートフル・セッションBeanメソッドを指定します。

before completionコールバックは、ステートフル・セッションBeanインスタンスに対して、トランザクションがコミットされようとしていることを通知します。

このメソッドは適切なトランザクション・コンテキスト内で実行されます。

注意:

インスタンスは、セッション・コンテキストでsetRollbackOnly()メソッドを呼び出すか、例外をスローすることにより、コンテナでトランザクションをロールバックさせることができます。Beanで使用できるBeforeCompletionメソッドは1つまでです。

このメソッドのシグネチャは次のルールに従う必要があります。

- finalやstaticとして宣言することはできません。

- 任意のアクセス・タイプを指定できます。

- 戻り型はvoidでなければなりません。

- 引数を取ることはできません。

このメソッドはトランザクション・コンテキストを使用せずに実行されます。

ステートフル・セッションBeanクラスでは、SessionSynchronizationインタフェースまたはセッション同期アノテーションのいずれかを使用できますが、両方使用することはできません。

javax.ejb.ConcurrencyManagement

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: 型

シングルトン・セッションBeanの同時実行性管理の種類を宣言します。

このアノテーションが指定されていない場合、そのシングルトンBeanではコンテナ管理の同時実行性を使用するものと見なされます。

このアノテーションはステートフル・セッションBeanに適用できますが、適用しても、そのようなBeanの同時実行性管理のセマンティクスには効果がありません。Bean管理による同時実行性(BEAN)に対する同時実行性管理の種類は、ステートフル・セッションBeanには適用されません。

属性

次の表で属性について簡単に説明します。

表A-4 javax.ejb.ConcurrencyManagementアノテーションの属性

名前

説明

データ型

必須?

value

Beanクラスで使用される同時実行性管理の種類を指定します。

この属性の有効な値は以下のとおりです。

- ConcurrencyManagementType.CONTAINER

- ConcurrencyManagementType.BEAN

この属性のデフォルト値はjavax.ejb.ConcurrencyManagementType.CONTAINERです。

String

省略可能

javax.ejb.DependsOn

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: 型

初期化時のシングルトン・コンポーネント間の依存関係を指定するために使用します。

シングルトンのPostConstructメソッドが呼び出される前に、そのシングルトンとDependsOn関係にあるすべてのシングルトンBeanが初期化されることをコンテナが保証します。

アプリケーションの停止時に、このシングルトンとDependsOn関係にあるすべてのシングルトンBeanがシングルトンのPreDestroyメソッド内でまだ使用できることをコンテナが保証します。

属性

次の表で属性について簡単に説明します。

表A-5 javax.ejb.DependsOnアノテーションの属性

名前

説明

データ型

必須?

value

このシングルトンの前に初期化が必要なシングルトン・コンポーネントのEJB名を指定します。名前を指定する順序は重要ではありません。

String

省略可能

javax.ejb.EJB

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス、メソッド、フィールド

EJBビジネス・インタフェースまはたホーム・インタフェースへの依存性(参照)を指定します。

他のEJBへの依存関係を指定するには、Beanのインスタンス変数に@EJBアノテーションを付けます。WebLogic Serverでは、アノテーションを付けた変数が、依存先のEJBへの参照に基づいて自動的に初期化されます。これを依存関係インジェクションと呼びます。この初期化は、BeanのEJBContextが設定された後、Beanのビジネス・メソッドが呼び出される前に発生します。

このアノテーションをBeanクラス内のセッター・メソッドに付けることもできます。その場合、WebLogic Serverはセッター・メソッド自体を使用して依存関係インジェクションを実行します。この方法でインスタンス変数に依存性を注入することもできます。

このアノテーションをクラスに適用すると、Beanが実行時にルックアップするEJBが宣言されます。

変数またはセッター・メソッドへの注入を使用する場合、WebLogic Serverでは、アノテーションを付けたインスタンス変数またはセッター・メソッドのパラメータの名前またはデータ型に基づいて参照先のEJBの名前が判別されます。少しでも不明確な場合は、@EJBアノテーションのbeanName属性またはmappedName属性を使用して、依存先のEJBの名前を明示的に指定する必要があります。

属性

次の表で属性について簡単に説明します。

表A-6 javax.ejb.EJBアノテーションの属性

名前

説明

データ型

必須?

name

環境内で参照先EJBのルックアップに使用する名前を指定します。

この名前は、クラスおよびそのスーパークラスからなるデプロイメント・ユニット内でユニークでなければなりません。

String

いいえ

beanInterface

参照先EJBのインタフェース・タイプ(ビジネス・インタフェースまたはホーム・インタフェース)を指定します。

この属性のデフォルト値はObject.classです。

Class

いいえ

beanName

参照先EJBの名前を指定します。

この属性は、参照先EJBの@Statelessまたは@Statefulアノテーションのname要素(デフォルトでは、参照先Beanクラスの未修飾名)に対応します。

EJB JARファイル内の複数のセッションBeanが同じインタフェースを実装している場合は、各Beanの名前をユニークにする必要があるため、この属性が非常に有用になります。

String

いいえ

mappedName

参照先EJBのグローバルJNDI名を指定します。

例:

mappedName="bank.Account"

この場合は、WebLogic Server JNDIツリー内にデプロイされているbank.AccountというグローバルJNDI名の参照先EJBを指定しています。

注意: マッピングされた名前を使用するEJBは、移行できなくなる可能性があります。

String

いいえ

description

EJB参照の説明。

String

いいえ

javax.ejb.EJBs

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

@javax.ejb.EJBアノテーションの配列を指定します。

属性

次の表で属性について簡単に説明します。

表A-7 javax.ejb.EJBsアノテーションの属性

名前

説明

データ型

必須?

value

@javax.ejb.EJBアノテーションの配列を指定します。

EJB[]

いいえ

javax.ejb.Init

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

Beanクラス内のメソッドと、適合するEJB 2.1 EJBHomeまたはEJBLocalHomeクライアント・ビューのcreateMETHODメソッドとの対応関係を指定します。

このアノテーションは、ステートフル・セッションBean (クラス・レベルの@javax.ejb.Statefulアノテーションを付けたBean)でのみ使用します。

@javax.ejb.Initアノテーションを付けたメソッドの戻り値の型はvoidでなければなりません。また、パラメータの型は、参照するcreateMETHODメソッドのパラメータの型とまったく同じである必要があります。

@Initアノテーションが必要になるのは、Remote-HomeまたはLocalHomeインタフェースを提供するステートフル・セッションBeanのみです。少しでも不明確な場合は、value属性を使用して、HomeまたはLocalHomeインタフェースの適合するcreateメソッドの名前を指定する必要があります。

属性

次の表で属性について簡単に説明します。

表A-8 javax.ejb.Initアノテーションの属性

名前

説明

データ型

必須?

value

対応するcreateMETHODメソッドの名前を指定します。

この属性を指定する必要があるのは、@Initアノテーションを使用して、複数のcreate<METHOD>メソッドを含むステートフル・セッションBeanの適合するHomeインタフェースを関連付ける場合のみです。

String

いいえ

javax.ejb.Local

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

セッションBeanのローカル・インタフェースを指定します。ローカル・インタフェースは、ビジネス・ロジックをローカル・クライアント(EJBと同じアプリケーションで動作しているクライアント)にエクスポーズします。ローカル・クライアントから呼び出せるビジネス・メソッドを定義します。

Beanクラスに複数のインタフェース(ただし以下のインタフェースを除く)が実装されている場合は、このアノテーションを指定する必要があります。

- java.io.Serializable

- java.io.Externalizable

- javax.ejb.*

このアノテーションは、ステートレスまたはステートフル・セッションBeanにのみ適用されます。

属性

次の表で属性について簡単に説明します。

表A-9 javax.ejb.Localの属性

名前

説明

データ型

必須?

value

ローカル・インタフェースのリストをクラスの配列として指定します。

この属性を指定する必要があるのは、Beanクラスに複数のインタフェース(ただし以下のインタフェースを除く)が実装されている場合のみです。

- java.io.Serializable

- java.io.Externalizable

- javax.ejb.*

Class[]

いいえ

javax.ejb.LocalBean

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: 型

セッションBeanでインタフェースなしのビューを公開するように指定します。

javax.ejb.LocalHome

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

Beanクラスのローカル・ホーム・インタフェースを指定します。

ローカル・ホーム・インタフェースは、ローカル・クライアント(EJBと同じアプリケーションで動作するクライアント)から使用して、Beanのインスタンスを作成、削除、および(エンティティBeanの場合は)検索することができるメソッドを提供します。ローカル・ホーム・インタフェースには、特定のBeanインスタンスに固有ではないビジネス・ロジックであるホーム・メソッドもあります。

この属性は、ステートレスおよびステートフル・セッションBeanにのみ適用されます。

通常、この属性は、EJB 3.x Beanの適合するEJB 2.1コンポーネント・ビューを提供する予定がある場合にのみ指定します。このアノテーションは、EJB 2.1 APIに記述されているBeanクラスにも使用できます。

属性

次の表で属性について簡単に説明します。

表A-10 javax.ejb.LocalHomeアノテーションの属性

名前

説明

データ型

必須?

value

ローカル・ホーム・クラスを指定します。

Class

はい

javax.ejb.Lock

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: 型、メソッド

コンテナ管理による同時実行性を使用するシングルトン・セッションBeanに対して同時実行性のロックを宣言します。

このアノテーションは、BeanクラスまたはそのBeanクラスのビジネス・メソッド、あるいはこの両方に指定できます。このアノテーションをビジネス・メソッドに指定すると、クラス・レベルで指定した値(ある場合)は、オーバーライドされます。

このアノテーションが使用されていない場合、値はLock(WRITE)であると見なされます。

属性

次の表で属性について簡単に説明します。

表A-11 ejb.LockTypeアノテーションの属性

名前

説明

データ型

必須?

value

コンテナ管理による同時実行性を使用するシングルトン・セッションBeanで使用される同時実行性のロックを指定します。

この属性の有効な値は以下のとおりです。

- LockType.READ

- LockType.WRITE

デフォルト値はjavax.ejb.LockType.WRITEです。

String

省略可能

javax.ejb.MessageDriven

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

Enterprise JavaBeanがメッセージドリブンBeanであることを指定します。

属性

次の表で属性について簡単に説明します。

表A-12 javax.ejb.MessageDrivenアノテーションの属性

名前

説明

データ型

必須?

name

このメッセージドリブンBeanの名前を指定します。

この属性を指定しない場合は、Beanクラスの未修飾名がデフォルト値になります。

String

いいえ

messageListenerInterface

Beanクラスのメッセージ・リスナー・インタフェースを指定します。

Beanクラスにメッセージ・リスナー・インタフェースが明示的に実装されていない場合や、Beanクラスに複数のインタフェース(ただし、java.io.Serializable、java.io.Externalizable、およびjavax.ejbパッケージ内のすべてのインタフェースを除く)が実装されている場合は、この属性を指定する必要があります。

この属性のデフォルト値はObject.classです。

Class

いいえ

activationConfig

操作環境でのメッセージドリブンBeanの構成を指定します。確認応答モード、メッセージ・セレクタ、想定される宛先やエンドポイントのタイプなどの情報を含めることができます。

アクティブ化構成情報(プロパティ名や値)は、@javax.ejb.ActivationConfigPropertyアノテーションの配列を使用して指定します。

ActivationConfigProperty[]

いいえ

mappedName

メッセージドリブンBeanをマッピングする製品固有の名前を指定します。

この属性を使用して、このメッセージドリブンBeanのメッセージ宛先のJNDI名を指定することもできます。例:

mappedName="my.Queue"

このメッセージドリブンBeanは、WebLogic Server JNDIツリー内にデプロイされているmy.QueueというJNDI名のJMSキューに関連付けられます。

注意: この属性を指定した場合は、そのメッセージドリブンBeanを移行できなくなる可能性があります。

String

いいえ

description

メッセージドリブンBeanの説明を指定します。

String

いいえ

javax.ejb.PostActivate

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

EJBコンテナがBeanインスタンスを再アクティブ化した直後に通知を受信するライフサイクル・コールバック・メソッドを指定します。

このアノテーションは、ステートフル・セッションBeanにのみ適用されます。ステートフル・セッションBeanインスタンスがパッシブ化されたときの会話状態はEJBコンテナによって自動的に保持されるため、ほとんどのステートフル・セッションBeanではこのアノテーションを指定する必要はありません。このアノテーション(およびこれと対をなす@PrePassivate)を使用する必要があるのは、ステートフル・セッションBeanで開いておきたいリソースがあり、そのリソースをBeanインスタンスのパッシブ化の前に閉じ、Beanインスタンスのアクティブ化中に開きなおす必要がある場合のみです。

このアノテーションは、Beanクラス内の1つのメソッドにのみ付けることができます。このアノテーションを複数のメソッドに付けた場合、そのEJBはデプロイされません。

@PostActivateアノテーションを付けるメソッドは、以下の要件を満たす必要があります。

- メソッドの戻り値の型がvoidでなければなりません。

- 検査済みの例外を送出してはなりません。

- public、protected、package private、またはprivateにすることは可能です。

- staticにすることはできません。

- finalにすることはできません。

このアノテーションには、属性はありません。

javax.ejb.PrePassivate

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

EJBコンテナがBeanインスタンスをパッシブ化する直前に通知を受信するライフサイクル・コールバック・メソッドを指定します。

このアノテーションは、ステートフル・セッションBeanにのみ適用されます。ステートフル・セッションBeanインスタンスがパッシブ化されたときの会話状態はEJBコンテナによって自動的に保持されるため、ほとんどのステートフル・セッションBeanではこのアノテーションを指定する必要はありません。このアノテーション(およびこれと対をなす@PostActivate)を使用する必要があるのは、ステートフル・セッションBeanで開いておきたいリソースがあり、そのリソースをBeanインスタンスのパッシブ化の前に閉じ、Beanインスタンスのアクティブ化中に開きなおす必要がある場合のみです。

このアノテーションは、Beanクラス内の1つのメソッドにのみ付けることができます。このアノテーションを複数のメソッドに付けた場合、そのEJBはデプロイされません。

@PrePassivateアノテーションを付けるメソッドは、以下の要件を満たす必要があります。

- メソッドの戻り値の型がvoidでなければなりません。

- 検査済みの例外を送出してはなりません。

- public、protected、package private、またはprivateにすることは可能です。

- staticにすることはできません。

- finalにすることはできません。

このアノテーションには、属性はありません。

javax.ejb.Remote

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

セッションBeanのリモート・インタフェースを指定します。リモート・インタフェースはビジネス・ロジックをリモート・クライアント(EJBとは別のアプリケーションで動作するクライアント)にエクスポーズします。リモート・クライアントから呼び出せるビジネス・メソッドを定義します。

このアノテーションは、ステートレスまたはステートフル・セッションBeanにのみ適用されます。

属性

次の表で属性について簡単に説明します。

表A-13 javax.ejb.Remoteアノテーションの属性

名前

説明

データ型

必須?

value

リモート・インタフェースのリストをクラスの配列として指定します。

この属性を指定する必要があるのは、Beanクラスに複数のインタフェース(ただし以下のインタフェースを除く)が実装されている場合のみです。

- java.io.Serializable

- java.io.Externalizable

- javax.ejb.*

Class[]

いいえ

javax.ejb.RemoteHome

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

Beanクラスのリモート・ホーム・インタフェースを指定します。

リモート・ホーム・インタフェースは、リモート・クライアント(EJBとは別のアプリケーションで動作するクライアント)でBeanのインスタンスを作成、削除、および検索するためのメソッドを提供します。

この属性は、ステートレスおよびステートフル・セッションBeanにのみ適用されます。

通常、この属性は、EJB 3.x Beanの適合するEJB 2.1コンポーネント・ビューを提供する予定がある場合にのみ指定します。このアノテーションは、EJB 2.1 APIに記述されているBeanクラスにも使用できます。

属性

次の表で属性について簡単に説明します。

表A-14 javax.ejb.RemoteHomeアノテーションの属性

名前

説明

データ型

必須?

value

リモート・ホーム・クラスを指定します。

Class

はい

javax.ejb.Remove

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

@javax.ejb.Removeアノテーションは、ステートフル・セッションBeanのremoveメソッドを指定するために使用します。

EJBコンテナは、そのメソッドが完了したときに、@javax.annotation.PreDestroyアノテーションが付いているメソッドがあればそれを呼び出してからステートフル・セッションBeanを破棄します。

属性

次の表で属性について簡単に説明します。

表A-15 javax.ejb.Removeアノテーションの属性

名前

説明

データ型

必須?

retainIfException

このアノテーションを付けたメソッドがアプリケーション例外で異常終了した場合には、ステートフル・セッションBeanを削除しないことを指定します。

有効な値は、trueおよびfalseです。デフォルト値はfalseです。

boolean

いいえ

javax.ejb.Schedule

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

タイムアウト・スケジュールで自動作成されるタイマーをCRONと同様の時間表現に基づいてスケジュールします。アノテーションを付けたメソッドは、タイムアウト・コールバック・メソッドとして使用されます。

このアノテーションのすべての要素は、省略可能です。何も指定されていない場合は、毎日午前0時にコールバックが発生し、永続タイマーが作成されます。この時間は、アプリケーションが実行されているコンテナに関連付けられているデフォルト・タイムゾーンに基づきます。

スケジュールの指定は、次に示す7個の要素で構成されています。また、timezone要素は、スケジュール指定が評価されるコンテキストのデフォルト以外のタイムゾーンを指定する場合に使用します。persistent要素は、非永続タイマーを指定する場合に使用します。info要素は、タイマー・コールバック発生時に取得されると思われる追加情報を指定する場合に使用します。

カレンダベースのスケジュールの要素

カレンダベースのスケジュールを指定する要素は次のとおりです。

- second - 1分のうちの秒(1つまたは複数)。
許容される値: [0,59]

- minute - 1時間のうちの分(1つまたは複数)。
許容される値: [0,59]

- hour - 1日のうちの時間(1つまたは複数)。
許容される値: [0,23]

- dayOfMonth - 1か月のうちの日(1つまたは複数)。
許容される値:]

- 1,31]

- -7, -1

- "Last"

- {"1st", "2nd", "3rd", "4th", "5th", "Last"} {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"}

"Last"は月の最終日を意味します。

-x (xの範囲は[-7, -1])は、月の最終日から数えてx日前を意味します。

週の曜日に適用される"1st"、"2nd"などは、月内でその曜日がそれぞれ出現する日を識別します。

- month - 1年のうちの月(1つまたは複数)。
許容される値:]

- [1,12]

- {"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", Dec"}

- dayOfWeek - 1週間のうちの曜日(1つまたは複数)。
許容される値:]

- [0,7]

- {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"}

"0"および"7"はいずれも日曜日を表します。

- year - 特定の暦年。
許容される値: 4桁の暦年

要素値でサポートされる形式

各要素では次のいずれかの形式で記述された値がサポートされます。

- 単一の値 - その属性で使用可能な値の中から1つのみに限定します。

Example: second = "10"
Example: month = "Sep"

- ワイルド・カード - "*"はその属性で有効な値のすべてを表します。

Example: second = "*"
Example: dayOfWeek = "*"

- リスト - 属性を2つ以上の有効な値または範囲に限定します。文字列内の区切り文字にはコンマを使用します。リスト内の各アイテムは単一の値または範囲でなければなりません。リストのアイテムには、リスト、ワイルド・カード、増分は指定できません。重複値は無視されます。

Example: second = "10,20,30"
Example: dayOfWeek = "Mon,Wed,Fri"
Example: minute = "0-10,30,40"

- 範囲 - 複数の値を含む範囲に属性を限定します。範囲の両端はダッシュで区切ります。範囲の両端は単一の属性値でなければなりません。範囲のメンバーには、リスト、ワイルド・カード、範囲、増分は指定できません。範囲"x-y"でxがyよりも大きい場合、その範囲は"x-max, min-y"と同等です。ここで示すmaxは対応する属性の最大値、minは最小値です。範囲"x-x"、つまり範囲の両方の値が同じ場合は、単一の値xとして評価されます。曜日の範囲"0-7"は、"*"と同等です。

Example: second = "1-10"
Example: dayOfWeek = "Fri-Mon"
Example: dayOfMonth = "27-3" (Equivalent to "27-Last , 1-3"

- 増分 - 前方のスラッシュによって属性を開始点と間隔に基づいて限定します。1分、1時間、1日のうちのそれぞれN秒、分、時間おきの時間を指定するために使用します。x/yという表現では、属性は時間xで始まる有効な値の中でy番目の値おきに限定されます。値xは含まれます。xの位置にワイルド・カード文字(*)を使用できます。これは0と同等です。増分の使用は、second、minuteおよびhour要素内のみでサポートされます。secondおよびminute要素では、xおよびyはそれぞれ[0,59]の範囲で指定する必要があります。hour要素では、xおよびyはそれぞれ[0,23]の範囲で指定する必要があります。

Example: minute = "?/5" (Every five minutes within the hour)

これは「minute = "0,5,10,15,20,25,30,35,40,45,50,55"」と同等です。

Example: second = "30/10" (Every 10 seconds within the minute, starting at second 30)

これは「second = "30,40,50"」と同等です。

増分値の一連の照合処理は、その属性の最大値を超えると停止します。限度を超えて継続されることはありません。

Example : ( minute = "?/14", hour="1,2")

これは「(minute = "0,14,28,42,56", hour = "1,2")」(午前1時から2時の間で14分おき)と同等です。

スケジュール指定の要素のその他のルール

スケジュール指定の要素に適用されるその他のルールは次のとおりです。

- dayOfMonth要素にワイルド・カード以外の値を指定し、dayOfWeek要素にもワイルド・カード以外の値を指定した場合、dayOfMonth値またはdayOfWeek値のいずれかに一致する日はすべて適用対象と見なされます。

- 空白は無視されます(文字列定数と数値は除く)。

- すべての文字列定数(例: "Sun"、"Jan"、"1st"など)において、大文字と小文字は区別されません。

スケジュールベースのタイマー時間は、アプリケーションが実行されているコンテナに関連付けられているデフォルト・タイムゾーンのコンテキストで評価されます。スケジュール・ベースのタイマーでは、必要に応じてこのデフォルトをオーバーライドして、特定のタイムゾーンに関連付けることができます。スケジュールベースのタイマーを特定のタイムゾーンに関連付けると、そのタイマーの時間はすべて、コンテナが実行されているデフォルト・タイムゾーンに関係なく、そのタイムゾーンのコンテキストで評価されます。

Scheduleアノテーションを適用するタイムアウト・コールバック・メソッドは、次のシグネチャのいずれかにする必要があります(<METHOD>にはメソッド名を指定します)。

void <METHOD>()
void <METHOD>(Timer timer)

タイムアウト・コールバック・メソッドには、public、private、protectedまたはpackageレベルのアクセスを指定できます。タイムアウト・コールバック・メソッドをfinalやstaticとして宣言することはできません。タイムアウト・コールバック・メソッドでアプリケーション例外をスローすることはできません。

属性

次の表で属性について簡単に説明します。

表A-16 javax.ejb.Scheduleアノテーションの属性

名前

説明

データ型

必須?

dayofMonth

1か月のうちの日(1つまたは複数)を指定します。

デフォルト値は*です。

String

いいえ

dayofWeek

1週間のうちの曜日(1つまたは複数)を指定します。

デフォルト値は*です。

String

いいえ

hour

1日のうちの時間(1つまたは複数)を指定します。

デフォルト値は0です。

String

いいえ

info

タイマーに関連付けられている情報文字列を指定します。

デフォルト値は0です。

String

いいえ

minute

1時間のうちの分(1つまたは複数)を指定します。

デフォルト値は0です。

String

いいえ

month

1年のうちの月(1つまたは複数)を指定します。

デフォルト値は*です。

String

いいえ

persistent

作成されるタイマーが永続タイマーかどうかを指定します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はtrueです。

Boolean

いいえ

second

1分のうちの秒(1つまたは複数)を指定します。

デフォルト値は0です。

String

いいえ

timezone

スケジュールが評価されるタイムゾーンを指定します。タイムゾーンはID文字列として指定されています。必要なタイムゾーンの一連のIDは、パブリック・ドメインのzoneinfoデータベースのZone Name(TZ)列に定義されています。

デフォルト値: タイムゾーンが指定されていない場合、スケジュールは、アプリケーションが実行されているコンテナに関連付けられているデフォルト・タイムゾーンのコンテキストで評価されます。

String

いいえ

year

暦年(1つまたは複数)を指定します。

デフォルト値は*です。

String

いいえ

javax.ejb.Schedules

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

複数のカレンダベースのタイマーをスケジュールする1つのタイマー・コールバック・メソッドに適用されます。Schedulesアノテーションを適用するメソッドは、次のシグネチャのいずれかにする必要があります(<METHOD>にはメソッド名を指定します)。

void <METHOD>()
void <METHOD>(Timer timer)

属性

次の表で属性について簡単に説明します。

表A-17 javax.ejb.Schedulesアノテーションの属性

名前

説明

データ型

必須?

value

カレンダベースのタイマー指定を1つ以上指定します。

Schedule[]

はい

javax.ejb.Singleton

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

Enterprise JavaBeanがシングルトン・セッションBeanであることを指定します。

属性

次の表で属性について簡単に説明します。

表A-18 javax.ejb.Singletonアノテーションの属性

名前

説明

データ型

必須?

name

このシングルトン・セッションBeanの名前を指定します。

この属性を指定しない場合は、Beanクラスの未修飾名がデフォルト値になります。

String

いいえ

mappedName

シングルトン・セッションBeanをマッピングする製品固有の名前を指定します。

この属性を使用して、このシングルトン・セッションBeanのJNDI名を指定することもできます。WebLogic Serverでは、BeanのグローバルJNDI名を作成する際にmappedName属性の値を使用します。具体的には、JNDI名は次のようになります。

mappedName#name_of_businessInterface

name_of_businessInterfaceは、このセッションBeanのビジネス・インタフェースの完全修飾名。

たとえば、ビジネス・インタフェースの完全修飾名がcom.CheckingAccountである場合にmappedName="bank"と指定すると、このビジネス・インタフェースのJNDI名はbank#com.CheckingAccountとなります。

注意: この属性を指定した場合は、そのシングルトン・セッションBeanを移行できなくなる可能性があります。

String

いいえ

description

シングルトン・セッションBeanの説明。

String

省略可能

javax.ejb.Startup

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

Enterprise JavaBeanがステートフル・セッションBeanであることを指定します。

javax.ejb.StatefulTimeout

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: 型

ステートフル・セッションBeanのアイドル状態(クライアント呼出しを受信しない状態)が許容される時間数を指定します。この時間が経過すると、ステートフル・セッションBeanはコンテナによって削除されます。

属性

次の表で属性について簡単に説明します。

表A-19 javax.ejb.StatefulTimeoutアノテーションの属性

名前

説明

データ型

必須?

value

ステートフル・セッションBeanで許可するアイドル時間を指定します。

- 0よりも大きい場合は、unit要素で指定した単位によるタイムアウト値を示します。

- 0の場合は、同時アクセスが許可されないことを意味します。

- -1の場合は、クライアント・リクエストは、前のリクエストが処理されるまで無期限にブロックされることを示します。

-1よりも小さい値は無効です。

Long

いいえ

unit

指定した値に使用する単位を指定します。

この属性のデフォルト値はjava.util.concurrent.TimeUnit.MINUTESです。

TimeUnit

いいえ

javax.ejb.Stateless

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

Enterprise JavaBeanがステートレス・セッションBeanであることを指定します。

属性

次の表で属性について簡単に説明します。

表A-20 javax.ejb.Statelessアノテーションの属性

名前

説明

データ型

必須?

name

このステートレス・セッションBeanの名前を指定します。

この属性を指定しない場合は、Beanクラスの未修飾名がデフォルト値になります。

String

いいえ

mappedName

ステートレス・セッションBeanをマッピングする製品固有の名前を指定します。

この属性を使用して、このステートレス・セッションBeanのJNDI名を指定することもできます。WebLogic Serverでは、BeanのグローバルJNDI名を作成する際にmappedName属性の値を使用します。具体的には、JNDI名は次のようになります。

mappedName#name_of_businessInterface

name_of_businessInterfaceは、このセッションBeanのビジネス・インタフェースの完全修飾名。

たとえば、ビジネス・インタフェースの完全修飾名がcom.CheckingAccountである場合にmappedName="bank"と指定すると、このビジネス・インタフェースのJNDI名はbank#com.CheckingAccountとなります。

注意: この属性を指定した場合は、そのステートレス・セッションBeanを移行できなくなる可能性があります。

String

いいえ

description

ステートレス・セッションBeanの説明。

String

省略可能

javax.ejb.Timeout

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

Beanクラスのタイムアウト・メソッドを指定します。

このアノテーションは、Beanクラス内でEJBタイマー・サービスを簡単にプログラミングするためのアノテーションです。EJBタイマー・サービスはEJBコンテナによって提供されるサービスです。このサービスを使用すると、タイマー・オブジェクトが期限切れになったときに発生するコールバックをスケジューリングするタイマーを作成できます。

EJB 3.xより前のバージョンでタイマー・サービスをプログラミングするには、Beanクラスにjavax.ejb.TimedObjectオブジェクトを実装する必要がありました。また、BeanクラスにejbTimeoutという名前のメソッドを含める必要もありました。EJBのバージョン3.xでは、これらの要件が緩和されました。javax.ejb.TimedObjectインタフェースを実装する必要はなくなり、@Timeoutアノテーションを付けている限り、タイムアウト・メソッドに任意の名前を付けることができるようになりました。ただし、必要であれば、3.xより前の方法でタイマー・サービスをプログラミングすることもできます。

詳細は、「EJBタイマー・サービスのプログラミング(省略可能)」を参照してください

このアノテーションには、属性はありません。

javax.ejb.TransactionAttribute

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス、メソッド

EJBコンテナがEJBビジネス・メソッドをトランザクション・コンテキスト内で呼び出すかどうかを指定します。

注意:

このアノテーションを指定した場合は、@TransactionManagementアノテーションを使用して、コンテナ管理によるトランザクションの境界設定を指定する必要があります。

このアノテーションは、Beanクラスに指定することも、クラスの特定のメソッド(ビジネス・インタフェースのメソッド)に指定することもできます。Beanクラスに指定した場合、アノテーションはそのクラスの該当するすべてのビジネス・インタフェース・メソッドに適用されます。特定のメソッドに指定した場合は、そのメソッドにのみ適用されます。このアノテーションをクラス・レベルとメソッド・レベルの両方で指定し、それらの値が食い違っている場合は、メソッド・レベルの値が優先されます。

Beanクラスで@TransactionAttributeアノテーションを指定しない場合は、コンテナ管理によるトランザクションの境界設定が使用されます。トランザクション属性のセマンティクスはREQUIREDと見なされます。

属性

次の表で属性について簡単に説明します。

表A-21 javax.ejb.TransactionAttributeアノテーションの属性

名前

説明

データ型

必須?

value

ビジネス・メソッドの呼出し時に、EJBコンテナがトランザクションの境界設定を管理する方法を指定します。

これらの値の詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のコンテナ管理によるトランザクション要素の表のtrans-attribute要素の説明を参照してください。

この属性の有効な値は以下のとおりです。

- TransactionAttributeType.MANDATORY

- TransactionAttributeType.REQUIRED

- TransactionAttributeType.REQUIRED_NEW

- TransactionAttributeType.SUPPORTS

- TransactionAttributeType.NOT_SUPPORTED

- TransactionAttributeType.NEVER

デフォルト値はTransactionAttributeType.REQUIREDです。

String

省略可能

javax.ejb.TransactionManagement

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

セッションBeanまたはメッセージドリブンBeanのトランザクションの境界設定管理の種類を指定します。

トランザクションとは、ディスク上、メモリー内、またはデータベース内にあるアプリケーションの状態を変更する作業の1単位であり、一度開始されると最後まで完了するか、あるいは一切何も行われません。トランザクションは、EJBコンテナ、Beanコード、またはクライアント・コードによって境界設定(開始およびコミットまたはロールバックでの終了)することができます。このアノテーションは、トランザクションの境界設定を、EJBコンテナで管理するか、ユーザーが記述したBeanコードで管理するかを指定します。

Beanクラスにこのアノテーションを指定しない場合、そのBeanではトランザクションの境界設定をコンテナで管理するものと見なされます。

トランザクションの詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のトランザクションの設計と管理のオプションを参照してください。

属性

次の表で属性について簡単に説明します。

表A-22 javax.ejb.TransactionManagementアノテーションの属性

名前

説明

データ型

必須?

value

Beanクラスで使用するトランザクションの境界設定管理の種類を指定します。

この属性の有効な値は以下のとおりです。

- TransactionManagementType.CONTAINER

- TransactionManagementType.BEAN

デフォルト値はTransactionManagementType.CONTAINERです。

String

省略可能

インターセプタの構成に使用するアノテーション

この項では、次の各項で説明するアノテーションのリファレンス情報を提供します。

- javax.interceptor.AroundInvoke

- javax.interceptor.ExcludeClassInterceptors

- javax.interceptor.ExcludeDefaultInterceptors

- javax.interceptor.Interceptors

javax.interceptor.AroundInvoke

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

Beanクラスまたはインターセプタ・クラスのビジネス・メソッド・インターセプタを指定します。

@AroundInvokeアノテーションは、Beanクラスまたはインターセプタ・クラス内の1つのメソッドにのみ付けることができます。なお、Beanクラスのビジネス・メソッドに付けることはできません。

このアノテーションには、属性はありません。

javax.interceptor.ExcludeClassInterceptors

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

このアノテーションを付けたメソッドに対して、クラス・レベルのインターセプタを呼び出さないことを指定します。デフォルト・インターセプタの呼出しは、@ExcludeDefaultInterceptorsアノテーションでのみ除外できます。

このアノテーションには、属性はありません。

javax.interceptor.ExcludeDefaultInterceptors

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス、メソッド

定義されているどのデフォルト・インターセプタも呼び出さないことを指定します(デフォルト・インターセプタは、EJBデプロイメント記述子でのみ指定できます。アノテーションでは指定できません)。

クラス・レベルで定義した場合、デフォルト・インターセプタはBeanのどのビジネス・メソッドに対しても呼び出されません。メソッド・レベルで定義した場合は、その特定のビジネス・メソッドに対しては呼び出されませんが、それ以外の@ExludeDefaultInterceptorsアノテーションが付いていないすべてのビジネス・メソッドに対しては呼び出されます。

このアノテーションには、属性はありません。

javax.interceptor.Interceptors

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス、メソッド

Beanクラスまたはメソッドに関連付けるインターセプタ・クラスを指定します。インターセプタ・クラスは、Beanクラスとはまったく別のクラスです。インターセプタ・クラスのメソッドは、Beanのビジネス・メソッド呼び出しまたはライフサイクル・イベントに呼応する形で呼び出されます。

インターセプタ・クラスには、ビジネス・インターセプタ・メソッド(@javax.interceptor.AroundInvokeアノテーションを付けたメソッド)と、ライフサイクル・コールバック・メソッド(@javax.annotation.PostConstruct、@javax.annotation.PreDestroy、@javax.ejb.PostActivate、または@javax.ejb.PrePassivateアノテーションを付けたメソッド)の両方を含めることができます。

Beanクラスに対して定義できるインターセプタ・クラスの数に制限はありません。複数のインターセプタ・クラスを定義した場合は、そのアノテーション内に指定した順序で呼び出されます。

アノテーションをクラス・レベルで指定した場合、インターセプタはEJBのすべてのビジネス・メソッドに適用されます。メソッド・レベルで指定した場合は、そのメソッドにのみ適用されます。同じインターセプタ・クラスを、Beanクラスの複数のメソッドに指定することもできます。メソッド・レベルのインターセプタは、デフォルトでは、適用されるすべてのインターセプタ(デフォルト・インターセプタ、クラス・レベルのインターセプタなど)の後に呼び出されます。

属性

次の表で属性について簡単に説明します。

表A-23 javax.interceptor.Interceptorsアノテーションの属性

名前

説明

データ型

必須?

value

インターセプタ・クラスの配列を指定します。配列に複数のインターセプタ・クラスを含める場合は、配列内で指定した順序によって呼出しの順序が決まります。

Class[]

はい

エンティティBeanとの対話に使用するアノテーション

この項では、次の各項で説明するアノテーションのリファレンス情報を提供します。

- javax.persistence.PersistenceContext

- javax.persistence.PersistenceContexts

- javax.persistence.PersistenceUnit

- javax.persistence.PersistenceUnits

javax.persistence.PersistenceContext

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス、メソッド、フィールド

コンテナ管理のEntityManager永続性コンテキストへの依存性を指定します。

このアノテーションは、3.xエンティティBeanと対話するために使用します。通常はEntityManagerインスタンスへの依存関係インジェクションを実行します。

EntityManagerインタフェースには、永続性コンテキストとの対話に使用するメソッドが定義されています。永続性コンテキストとは、エンティティ・インスタンスのセットです。エンティティとは、軽量の永続ドメイン・オブジェクトです。EntityManager APIを使用すると、永続エンティティ・インスタンスの作成や削除、主キーに基づくエンティティの検索、およびエンティティに対する問合せを実行できます。

属性

次の表で属性について簡単に説明します。

表A-24 javax.persistence.PersistenceContextAnnotationの属性

名前

説明

データ型

必須?

name

EntityManagerとその永続性ユニットの名前(セッションBeanまたはメッセージドリブンBeanのコンテキスト内で使用する名前)を指定します。

この属性は、JNDIルックアップを使用してEntityManagerを取得する場合にのみ指定します。依存関係インジェクションを使用する場合は指定する必要はありません。

String

いいえ

unitName

永続性ユニットの名前を指定します。

この属性の値としてpersistence.xmlファイル内の永続性ユニットと同じ名前を指定すると、EJBコンテナによって永続性ユニットが自動的にデプロイされ、そのJNDI名としてその永続性ユニット名が設定されます。同様に、この属性を指定しない場合でも、永続性コンテキスト情報を注入する変数の名前をpersistence.xmlファイル内の永続性ユニットの名前と同じにすれば、EJBコンテナによって永続性ユニットが自動的にデプロイされ、そのJNDI名が永続性ユニット名と同じになるように設定されます。

注意 : persistence.xmlファイルは、EJB JARファイルのMETA-INFディレクトリに格納されているXMLファイルで、エンティティBeanで使用するデータベースと、EntityManagerのデフォルトの動作を指定します。

参照するスコープ内に複数の永続性ユニットがある場合は、この属性を指定する必要があります。

String

いいえ

type

永続性コンテキストの存続期間を、1つのトランザクションのスコープに限定するか、1つのトランザクションのスコープを超えて延長させるかを指定します。

この属性の有効な値は以下のとおりです。

- PersistenceContextType.TRANSACTION

- PersistenceContextType.EXTENDED

デフォルト値はPersistenceContextType.TRANSACTIONです。

PersistenceContextType

いいえ

javax.persistence.PersistenceContexts

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

@javax.persistence.PersistenceContextアノテーションの配列を指定します。

属性

次の表で属性について簡単に説明します。

表A-25 javax.persistence.PersistenceContextsアノテーションの属性

名前

説明

データ型

必須?

value

@javax.persistence.PersistenceContextアノテーションの配列を指定します。

PersistenceContext[]

必須

javax.persistence.PersistenceUnit

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス、メソッド、フィールド

EntityManagerFactoryオブジェクトへの依存性を指定します。

このアノテーションは、3.xエンティティBeanと対話するために使用します。通常はEntityManagerFactoryインスタンスへの依存関係インジェクションを実行します。このEntityManagerFactoryを使用して、1つまたは複数のEntityManagerインスタンスを作成できます。このアノテーションは@PersistenceContextアノテーションに似ていますが、EntityManagerの作成や破棄をEJBコンテナに任せずユーザー自身が行うため、その存続期間をより細かく制御できる点が異なります。

EntityManagerインタフェースには、永続性コンテキストとの対話に使用するメソッドが定義されています。永続性コンテキストとは、エンティティ・インスタンスのセットです。エンティティとは、軽量の永続ドメイン・オブジェクトです。EntityManager APIを使用すると、永続エンティティ・インスタンスの作成や削除、主キーに基づくエンティティの検索、およびエンティティに対する問合せを実行できます。

属性

次の表で属性について簡単に説明します。

表A-26 javax.persistence.PersistenceUnitアノテーションの属性

名前

説明

データ型

必須?

name

EntityManagerFactoryの名前(セッションBeanまたはメッセージドリブンBeanのコンテキスト内で使用する名前)を指定します。

この属性は、依存関係インジェクションを使用する場合は指定する必要はありません。JNDIも使用して情報をルックアップする場合にのみ指定します。

String

いいえ

unitName

persistence.xmlファイルに定義されている永続性ユニットの名前を参照します。このファイルは、EJB JARファイルのMETA-INFディレクトリに格納されているXMLファイルで、エンティティBeanで使用するデータベースと、EntityManagerのデフォルトの動作を指定します。

この属性を設定した場合は、参照先の永続性ユニットがEJBコンテナによって自動的にデプロイされ、そのJNDI名としてその永続性ユニット名が設定されます。同様に、この属性を指定しない場合でも、永続性コンテキスト情報を注入する変数の名前をpersistence.xmlファイル内の永続性ユニットの名前と同じにすれば、EJBコンテナによって永続性ユニットが自動的にデプロイされ、そのJNDI名が永続性ユニット名と同じになるように設定されます。

参照するスコープ内に複数の永続性ユニットがある場合にのみ、この属性を指定する必要があります。

String

いいえ

javax.persistence.PersistenceUnits

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

@javax.persistence.PersistenceUnitアノテーションの配列を指定します。

属性

次の表で属性について簡単に説明します。

表A-27 javax.persistence.PersistenceUnitsアノテーションの属性

名前

説明

データ型

必須?

value

@javax.persistence.PersistenceUnitアノテーションの配列を指定します。

PersistenceUnit[]

はい

EJB 3.xで使用する標準JDKアノテーション

この項では、次の各項で説明するアノテーションのリファレンス情報を提供します。

- javax.annotation.PostConstruct

- javax.annotation.PreDestroy

- javax.annotation.Resource

- javax.annotation.Resources

javax.annotation.PostConstruct

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

依存関係インジェクションが完了した後、1番目のビジネス・メソッドを呼び出す前に、初期化を実行するためにEJBコンテナから呼び出す必要のあるライフサイクル・コールバック・メソッドを指定します。

依存関係インジェクションを含むすべてのBeanクラスには、@PostConstructメソッドを指定できます。

このアノテーションは、Beanクラス内の1つのメソッドにのみ付けることができます。このアノテーションを複数のメソッドに付けた場合、そのEJBはデプロイされません。

@PostConstructアノテーションを付けるメソッドは、以下の要件を満たす必要があります。

- メソッドの戻り値の型がvoidでなければなりません。

- 検査済みの例外を送出してはなりません。

- public、protected、package private、またはprivateにすることは可能です。

- staticにすることはできません。

- finalにすることはできません。

このアノテーションには、属性はありません。

javax.annotation.PreDestroy

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

EJBコンテナがBeanクラス・インスタンスを破棄する直前に通知を受信するライフサイクル・コールバック・メソッドを指定します。通常、このアノテーションは、Beanクラスが保持しているリソースを解放するメソッドに適用します。

このアノテーションは、Beanクラス内の1つのメソッドにのみ付けることができます。このアノテーションを複数のメソッドに付けた場合、そのEJBはデプロイされません。

@PreDestroyアノテーションを付けるメソッドは、以下の要件を満たす必要があります。

- メソッドの戻り値の型がvoidでなければなりません。

- 検査済みの例外を送出してはなりません。

- public、protected、package private、またはprivateにすることは可能です。

- staticにすることはできません。

- finalにすることはできません。

このアノテーションには、属性はありません。

javax.annotation.Resource

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス、メソッド、フィールド

外部リソース(JDBCデータ・ソース、JMS宛先、接続ファクトリなど)への依存性を指定します。

このアノテーションをフィールドまたはメソッドに指定すると、Beanの初期化時に、要求されたリソースのインスタンスがBeanに注入されます。このアノテーションをクラスに適用すると、Beanが実行時にルックアップするリソースが宣言されます。

属性

次の表で属性について簡単に説明します。

表A-28 javax.annotation.Resourceアノテーションの属性

名前

説明

データ型

必須?

name

リソース参照の名前を指定します。

@Resourceアノテーションをフィールドに適用した場合は、クラス名で修飾されたフィールド名がname属性のデフォルト値になります。メソッドに適用した場合は、そのメソッドに対応するJavaBeanプロパティ名をクラス名で修飾した名前がデフォルト値になります。このアノテーションをクラスに適用した場合はデフォルト値がないため、この属性を指定する必要があります。

String

いいえ

type

リソースのJavaデータ型を指定します。

@Resourceアノテーションをフィールドに適用した場合は、そのフィールドの型がtype属性のデフォルト値になります。メソッドに適用した場合は、JavaBeanプロパティの型がデフォルトになります。クラスに適用した場合はデフォルト値がないため、この属性を指定する必要があります。

Class

いいえ

authenticationType

このリソースに使用する認証タイプを指定します。

この属性は、サポートされるタイプの接続ファクトリを表すリソースにのみ指定します。

この属性の有効な値は以下のとおりです。

- AuthenticationType.CONTAINER

- AuthenticationType.APPLICATION

デフォルト値はAuthenticationType.CONTAINERです。

AuthenticationType

いいえ

shareable

リソースを、このEJBと他のEJBとの間で共有できるかどうかを指定します。

この属性は、サポートされるタイプの接続ファクトリまたはORBオブジェクト・インスタンスを表すリソースにのみ指定します。

この属性の有効な値は、trueおよびfalseです。デフォルト値はtrueです。

boolean

いいえ

mappedName

依存リソースのグローバルJNDI名を指定します。

例:

mappedName="my.Datasource"

この場合は、WebLogic Server JNDIツリー内にデプロイされているmy.DatasourceというグローバルJNDI名の依存リソースを指定しています。

String

いいえ

description

リソースの説明を指定します。

String

いいえ

javax.annotation.Resources

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

@Resourceアノテーションの配列を指定します。

属性

次の表で属性について簡単に説明します。

表A-29 javax.annotation.Resourcesアノテーションの属性

名前

説明

データ型

必須?

value

@Resourceアノテーションの配列を指定します。

Resource[]

はい

EJB 3.xで使用するセキュリティ関連の標準JDKアノテーション

この項では、次の各項で説明するアノテーションのリファレンス情報を提供します。

- javax.annotation.security.DeclareRoles

- javax.annotation.security.DenyAll

- javax.annotation.security.PermitAll

- javax.annotation.security.RolesAllowed

- javax.annotation.security.RunAs

javax.annotation.security.DeclareRoles

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

EJBで使用するセキュリティ・ロールを定義します。

通常、このアノテーションは、アノテーションを付けたクラスのメソッド内から(たとえばisUserInRoleメソッドを使用して)テストできるロールを定義するために使用します。また、クラスまたはクラスのメソッドで@RolesAllowedアノテーションを使用している場合はロールが暗黙的に宣言されますが、このアノテーションを使用することでそれらのロールを明示的に宣言できます。

WebLogic Serverのセキュリティ・ロールは、WebLogic Server管理コンソールを使用して作成できます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理を参照してください。

属性

次の表で属性について簡単に説明します。

表A-30 javax.annotation.security.DeclareRolesアノテーションの属性

名前

説明

データ型

必須?

value

Beanクラス内で使用するセキュリティ・ロールの配列を指定します。

String[]

必須

javax.annotation.security.DenyAll

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

このアノテーションを付けたメソッドへのアクセスを、どのセキュリティ・ロールにも許可しないことを指定します。つまり、このメソッドは、EJBコンテナでの実行から除外されます。

このアノテーションには、属性はありません。

javax.annotation.security.PermitAll

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

このアノテーションを付けたメソッドへのアクセスを、WebLogic Serverに定義されているすべてのセキュリティ・ロールに許可することを指定します。

このアノテーションには、属性はありません。

javax.annotation.security.RolesAllowed

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス、メソッド

EJB内のメソッドにアクセスできるセキュリティ・ロールのリストを指定します。

クラス・レベルで指定した場合は、Beanクラス内のすべてのメソッドに適用されます。メソッド・レベルで指定した場合は、そのメソッドにのみ適用されます。このアノテーションをクラス・レベルとメソッド・レベルの両方で指定した場合は、クラス・レベルの値がメソッド・レベルの値によってオーバーライドされます。

WebLogic Serverのセキュリティ・ロールは、WebLogic Server管理コンソールを使用して作成できます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理を参照してください。

属性

次の表で属性について簡単に説明します。

表A-31 javax.annotation.security.RolesAllowedアノテーションの属性

名前

説明

データ型

必須?

value

Beanクラスのメソッドにアクセスできるセキュリティ・ロールのリストを指定します。

String[]

必須

javax.annotation.security.RunAs

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

EJBコンテナ内で実際にEJBを実行するセキュリティ・ロールを指定します。

セキュリティ・ロールは、WebLogic Serverセキュリティ・レルムにあり、ユーザーやグループにマップする必要があります。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理を参照してください。

属性

次の表で属性について簡単に説明します。

表A-32 javax.annotation.security.RunAsアノテーションの属性

名前

説明

データ型

必須?

value

EJBをどのセキュリティ・ロールとして実行するかを指定します。

String

必須

WebLogicアノテーション

この項では、次の各項で説明するWebLogicアノテーションのリファレンス情報を提供します。

- weblogic.javaee.AllowRemoveDuringTransaction

- weblogic.javaee.CallByReference

- weblogic.javaee.DisableWarnings

- weblogic.javaee.EJBReference

- weblogic.javaee.Idempotent

- weblogic.javaee.JMSClientID

- weblogic.javaee.JNDIName

- weblogic.javaee.JNDINames

- weblogic.javaee.MessageDestinationConfiguration

- weblogic.javaee.TransactionIsolation

- weblogic.javaee.TransactionTimeoutSeconds

注意:

この節で説明するアノテーションは、それぞれに相当する構成がweblogic-ejb-jar.xmlデプロイメント記述子で定義されている場合はオーバーライドされます。詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスを参照してください。

weblogic.javaee.AllowRemoveDuringTransaction

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス(ステートフル・セッションEJBのみ)

トランザクション中にインスタンスが削除できるかどうかを指定するフラグです。

注意:

このアノテーションは、weblogic-ejb-jar.xmlデプロイメント記述子のallow-remove-during-transaction要素によってオーバーライドされます。詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスを参照してください。

weblogic.javaee.CallByReference

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス(ステートフルまたはステートレス・セッションEJBのみ)

EJBがリモートから呼び出されたか同じEAR内から呼び出されたかに関係なく、パラメータをコピーするかどうか(または参照によって渡すかどうか)を指定するフラグです。

注意:

メソッドのパラメータは、EJBがリモートで呼び出されたときには常に値で渡されます。このアノテーションは、weblogic-ejb-jar.xmlデプロイメント記述子のenable-call-by-reference要素によってオーバーライドされます。詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスを参照してください。

weblogic.javaee.DisableWarnings

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

IDを指定した警告メッセージをWebLogic Serverが無効化するように指定します。

注意:

このアノテーションは、weblogic-ejb-jar.xmlデプロイメント記述子のdisable-warning要素によってオーバーライドされます。詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスを参照してください。

属性

次の表で属性について簡単に説明します。

表A-33 weblogic.javaee.DisableWarningsの属性

名前

説明

データ型

必須?

WarningCode

警告コードを指定します。以下の4つの値のいずれかに設定します。

- BEA-010001 - 警告メッセージ「EJB class loaded from system classpath during deployment.」を無効化します。

- BEA-010054 - 警告メッセージ「EJB class loaded from system classpath during compilation.」を無効化します。

- BEA-010200 - 警告メッセージ「EJB impl class contains a public static field, method or class.」を無効化します。

- BEA-010202 - 警告メッセージ「Call-by-reference not enabled.」を無効化します。

String

はい

weblogic.javaee.EJBReference

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス、メソッド、フィールド

EJB参照名をJNDI名にマップします。

属性

次の表で属性について簡単に説明します。

表A-34 weblogic.javaee.EJBReferenceアノテーションの属性

名前

説明

データ型

必須?

name

環境内で参照先EJBのルックアップに使用する名前を指定します。

この名前は、クラスおよびそのスーパークラスからなるデプロイメント・ユニット内でユニークでなければなりません。

String

はい

jndiName

WebLogic Serverで使用可能な実際のEJB、リソース、または参照のJNDI名を指定します。

String

はい

weblogic.javaee.Idempotent

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

同じメソッドを同じ引数で繰返し呼び出しても、1回の呼出しと同じ効果がもたらされるように記述されたEJBを指定します。これにより、フェイルオーバー・ハンドラは、失敗したサーバー上で実際に呼出しがコンパイルされるかどうかを知らなくても、失敗した呼出しを再試行できるようになります。あるメソッドについて多重呼出し不変を有効にした場合、EJBスタブは、EJBのホスト・サーバーに接続できるかぎり、あらゆる失敗から自動的に回復することができます。

注意:

このアノテーションは、weblogic-ejb-jar.xmlデプロイメント記述子のidempotent-methodおよびretry-methods-on-rollback要素によってオーバーライドされます。詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスを参照してください。

属性

次の表で属性について簡単に説明します。

表A-35 weblogic.javaee.Idempotentの属性

名前

説明

データ型

必須?

retryOnRollbackCount

ロールバックされたコンテナ管理のトランザクションを自動的に再試行する回数。

この属性のデフォルトは0です。

int

いいえ

weblogic.javaee.JMSClientID

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

JMS宛先に接続するときのMDBのクライアントIDを指定します。JMSトピックに対する恒久サブスクリプションで必須です。

weblogic.javaee.MessageDestinationConfigurationでMDBが使用する接続ファクトリを指定した場合、クライアントIDはconfig.xml内の関連付けられているJMSConnectionFactory要素のClientID要素で定義できます。

config.xmlのJMSConnectionFactoryでClientIDを指定しないか、デフォルト接続ファクトリを使用する(weblogic.javaee.MessageDestinationConfigurationを指定しない)場合、MDBはjms-client-id値をそのクライアントIDとして使用します。

注意:

このアノテーションは、weblogic-ejb-jar.xmlデプロイメント記述子のjms-client-id要素によってオーバーライドされます。詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスを参照してください。

属性

次の表で属性について簡単に説明します。

表A-36 weblogic.javaee.JMSClientIDの属性

名前

説明

データ型

必須?

value

クライアントID。

String

いいえ

generateUniqueID

MDBのすべてのインスタンスについて、EJBコンテナでユニークなクライアントIDを生成するかどうかを示すフラグ。このフラグを有効にすると、WebLogic Serverクラスタ内の複数のサーバー・インスタンスへの恒久MDBのデプロイが容易になります。

Class

いいえ

weblogic.javaee.JNDIName

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス(ステートフルまたはステートレス・セッションEJBのみ)

特定のクライアント・ビューのBeanクラスに適用可能なカスタムJNDI名を指定します。インタフェースなしのビューのJNDI名を示すためにBeanクラスに適用する場合、classNameは省略可能です。

注意:

このアノテーションは、weblogic-ejb-jar.xmlデプロイメント記述子のjndi-binding要素によってオーバーライドされます。詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスを参照してください。

属性

次の表で属性について簡単に説明します。

表A-37 weblogic.javaee.JNDINameの属性

名前

説明

データ型

必須?

classname

クライアント・ビューのクラス名。

String

いいえ

value

クライアント・ビューのJNDI名。

String

いいえ

weblogic.javaee.JNDINames

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス(ステートフルまたはステートレス・セッションEJBのみ)

EJBに適用可能な複数のカスタムJNDI名を指定します。

属性

次の表で属性について簡単に説明します。

表A-38 weblogic.javaee.JNDINamesの属性

名前

説明

データ型

必須?

value

EJBに適用する複数のカスタムJNDI名

JNDIName

いいえ

weblogic.javaee.MessageDestinationConfiguration

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス(メッセージドリブンEJBのみ)

メッセージドリブンEJBがキューとトピックを作成するためにルックアップするJMS接続ファクトリのJNDI名を指定します。

注意:

このアノテーションは、weblogic-ejb-jar.xmlデプロイメント記述子のconnection-factory-jndi-name要素によってオーバーライドされます。詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスを参照してください。

属性

次の表で属性について簡単に説明します。

表A-39 weblogic.javaee.MessageDestinationConfigurationの属性

名前

説明

データ型

必須?

connectionFactoryJNDIName

接続ファクトリのJNDI名。この属性のデフォルトは空文字列。

String

いいえ

initialContextFactory

WebLogic初期コンテキスト・ファクトリ。この属性のデフォルトはweblogic.jndi.WLInitialContextFactory.classです。

Class

いいえ

providerURL

プロバイダのURL。この属性のデフォルトはt3://localhost:7001です。

String

いいえ

weblogic.javaee.TransactionIsolation

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: メソッド

EJBのメソッド・レベルのトランザクション・アイソレーション設定です。

注意:

このアノテーションは、weblogic-ejb-jar.xmlデプロイメント記述子のtrans-timeout-seconds要素によってオーバーライドされます。詳細は、Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスを参照してください。

属性

次の表で属性について簡単に説明します。

表A-40 weblogic.javaee.Idempotentの属性

名前

説明

データ型

必須?

IsolationLevel

アイソレーション・レベル。有効な値は以下のとおりです。

- READ_COMMITTED - トランザクションは、他のトランザクションでコミットされた更新のみ読み取ることができます。

- READ_UNCOMITTED - トランザクションでは、他のトランザクションでコミットされていない更新のみ読み取ることができます。

- REPEATABLE_READ - トランザクションでデータの一部を読み取ると、そのデータが他のトランザクションで変更されても、最初の読取り時と同じ値が返されます。

- SERIALIZABLE - このトランザクションを同時に複数回実行すると、トランザクションを順番に複数回実行することと同じことになります。

この属性のデフォルトはDEFAULT。

int

いいえ

weblogic.javaee.TransactionTimeoutSeconds

以降の節では、このアノテーションについて詳しく説明します。

説明

ターゲット: クラス

トランザクションのタイムアウトを秒単位で定義します。

属性

次の表で属性について簡単に説明します。

表A-41 weblogic.javaee.TransactionTimeoutSecondsの属性

名前

説明

データ型

必須?

value

トランザクション・タイムアウトの値(秒)。この属性のデフォルトは30 (秒)。

int

いいえ