Oracle® Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansの開発 12c (12.2.1.1.0) E77278-02 |
|
前 |
次 |
この章の内容は以下のとおりです。
これらの項では、EJB 3.2、3.1と3.0、およびEJB 2.xと3.xとの間のEJBプログラミングのモデルおよび要件に関する変更点をまとめています。
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の仕様では、プログラミングおよびパッケージ化モデルの変更が簡素化されています。前のバージョンの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 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リファレンスに関する項を参照してください。
Enterprise JavaBeans (EJB) 3.2テクノロジは、Java EE 7のサーバー側コンポーネント・アーキテクチャです。EJB 3.2テクノロジを使用することで、Javaテクノロジに基づいて、安全でポータブルな分散トランザクション・アプリケーションを迅速かつ容易に開発できます。
セッション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の対話を管理するか、ワークフローを管理できます。
例: 社員が個人のプロファイル情報を表示して更新できる、ある会社のWebサイトでは、ステートフル・セッションBeanを使用して様々な他のBeanを呼び出し、ユーザーがページ上で「データの表示」をクリックした後に次のようなユーザーが必要とするサービスを提供できます。
JSPからログイン・データを受け付け、そのログイン・データを検証する別のEJBを呼び出す
認可の確認をJSPに送信する
認可されたユーザーのプロファイル情報にアクセスするBeanを呼び出す
ステートレス・セッションBeanは、呼出し間でセッションやクライアントの状態の情報を格納しません。唯一格納されることのある状態はクライアントに固有のものではなく、キャッシュされたデータベース接続や別のEJBの参照などです。ステートレス・セッションBeanが状態を格納できるのは、長くてメソッド呼出しの期間だけです。メソッドが完了すると、状態情報は維持されません。
ステートレス・セッションBeanのインスタンスはすべて、どのクライアントにもサービスを提供できます(どのインスタンスも機能は同じ)。ステートレス・セッションBeanは、ステートフル・セッションBeanよりもパフォーマンスが優れています。その理由は、各ステートレス・セッションBeanが複数のクライアントをサポートできるからです(ただし一度に1つ)。ステートレス・セッションBeanのクライアントは、Webサービス・エンドポイントにできます。
例: 訪問者が問合せ先リンクをクリックして電子メール送信できるインターネット・アプリケーションでは、ステートレス・セッションBeanを使用して、JSPによってユーザーから収集された送信先と送信元の情報に基づいて電子メールを生成できます。
シングルトン・セッション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は、JMSキューまたトピックからメッセージを受信し、そのメッセージの内容に基づいてビジネス・ロジックを実行します。それは、EJBとJMSの間の非同期インタフェースです。
MDBインスタンスはそのライフサイクルを通じて、同時にではありませんが複数のクライアントからのメッセージを処理できます。特定のクライアントの状態は維持されません。メッセージドリブンBeanのインスタンスはすべて同じ機能であり、EJBコンテナはどのMDBインスタンスにもメッセージを割り当てることができます。コンテナは、それらのインスタンスをプールしてメッセージのストリームの並行処理を可能にします。
EJBコンテナは、必要に応じてBeanのインスタンスを作成し、JMSメッセージをインスタンスに渡すことによってメッセージドリブンBeanと直接対話します。コンテナは、デプロイメント時にBeanのインスタンスを作成し、メッセージのトラフィックに基づいて作動時にインスタンスを追加および削除します。
詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』を参照してください。
例:顧客から注文を受けるプロセスがサプライヤへの発注プロセスを引き起こすオンライン・ショッピング・アプリケーションでは、サプライヤへの発注プロセスをメッセージドリブンBeanで実装できます。顧客の注文が必ずサプライヤへの発注につながる一方で、そのステップは疎結合になります。その理由は、顧客の注文を確定する前にサプライヤへの発注を生成する必要はないからです。関連するサプライヤへの注文が発行される前に顧客の注文が「蓄積」されるのは問題なく、有益なことです。
以下の節では、各Beanタイプで必須のクラス、EJB実行時環境、およびBeanの実行時の動作を管理するデプロイメント記述子ファイルについて簡単に説明します。
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コンテナとは、アプリケーション・サーバーにデプロイされたBeanの実行時コンテナです。このコンテナはアプリケーション・サーバーの起動時に自動的に作成され、Beanと以下のような実行時サービスの間のインタフェースとして機能します。
ライフサイクル管理
コード生成
セキュリティ
トランザクションの管理
ロックと同時実行性制御
WebLogic Server EJB 3.2プログラミング・モデルでは、Java EE 7メタデータ・アノテーション機能を使用して、アノテーション付きEJB 3.2 Beanファイルを作成し、標準Javaコンパイラでクラスをコンパイルします。生成されたクラスは、デプロイメント用のターゲット・モジュールにパッケージ化できます。実行時に、WebLogic Serverはアノテーションを解析して、必要な動作のアスペクトをBeanファイルに適用します。
詳細は、「アノテーション付き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は、サーブレット、Javaクライアント・アプリケーション、他のEJB、Webサービス、非Javaクライアントなどのサーバー側またはクライアント側オブジェクトからアクセスできます。EJBのクライアントは、アプリケーションが同じか別かに関係なく同じ方法でEJBにアクセスします。WebLogic Serverは、リモートで機能できる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へのアクセスに関する項を参照してください。
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へのアクセスにセキュリティを設定する」で説明します
また、セキュリティ・ロールを作成し、ロールにユーザーをマッピングするには、WebLogic Server管理コンソールでセキュリティ・レルムを更新します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理に関する項を参照してください。
セキュリティおよびEJBの追加情報は、以下を参照してください。
『Oracle WebLogic Serverセキュリティの理解』のセキュリティの基礎に関する項に、認証、認可など、セキュリティ関連の基礎的な情報があります。
『WebLogicセキュリティ・サービスによるアプリケーションの開発』ののEnterprise JavaBeans (EJB)のセキュリティ対策に関する項には、EJBの認証と認可を構成する手順が説明されています。
『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』には、WebLogic Server管理コンソールを使用してEJBの認証と認可を構成する手順が含まれています。