|
|
WebOTX Manual V10.1 (第7版) 目次を表示 |
アプリケーションサーバでのビジネス層では、アプリケーションの種別に応じた固有のビジネスロジックに 対応し、トランザクション管理、スレッド/プロセス管理、アクセス制御管理などのシステムレベルのサー ビスを提供します。WebOTX では、Java ベースのEJB コンテナを提供しています。EJB コンテナは、 Express から利用可能です。
この層に位置するEJB コンテナは、EIS リソースを使用してWeb 層のコンポーネントやスタンドアロン型ア プリケーション・クライアントからの要求にサービスするEnterprise Bean コンポーネントをホストします。こ の章では、WebOTX のコンポーネント動作サービス機能階層の中で、特にEJB コンテナが提供する機能 について説明します。
EJB コンテナは3層モデルにおいてビジネスロジックをEnterprise Java Beans (EJB) アーキテクチャに従って実装した場合のコンテナ処理を行います。 アプリケーションはセッション制御やトランザクション制御、セキュリティ制御などをなるべく意識しないで、ビジネスロジックに注力することが望まれます。 EJB コンテナはこれらの制御をアプリケーション(Enterprise Bean と呼ぶ)に代わって実現します。 WebOTX ASではEJB3.2 仕様に準拠したEJB コンテナを提供しています。
EJB コンテナには、Enterprise Bean コンポーネントのトランザクション管理やライフサイクル管理、セキュリティ管理などをサポート する機能があります。さらに、JDBC データソースを介したデータベースサーバへのアクセス、JCA リソースアダプタを介したエンタ ープライズ情報システムへのアクセスなどを提供します。
EJB アーキテクチャは、エンタープライズ・アプリケーションのビジネスロジックを含むコンポーネントを開発しEJB コンテナに配備す るためのサーバサイド技術です。このコンポーネントは、拡張性に富み、トランザクション型で、複数ユーザに対するセキュリティが 適用されます。これらに適用するサービス提供元がEJB コンテナにあたります。
Enterprise Bean には、Session Bean とEntity Bean、メッセージ・ドリブンBean の3種類があります。Session Bean とEntity Bean に は、ホームインタフェースとコンポーネントインタフェースがあります。コンポーネントインタフェースは、EJB 1.1 以前の仕様ではリモ ートインタフェースと呼ばれていました。ホームインタフェースは、Bean の生成、検索、削除などのメソッドを定義します。コンポーネ ントインタフェースは、Bean のビジネスロジックを定義します。メッセージ・ドリブンBean には、2つのインタフェースはありません。
Session Bean は、クライアントに代わってサービスを提供するために作成され、通常は単一のクライアント−サーバ・セッションの 期間中にのみ生存します。Session Bean はトランザクション型にすることができますが、EJB コンテナがダウンすると回復不能で す。
Session Bean には、ステートレスのものと、複数のメソッドやトランザクション間で会話状態を維持できるステートフルのタイプがあ ります。状態維持のためのオブジェクト管理は、EJB コンテナが行いますが、オブジェクト自体の永続データは、Session Bean 自身 が管理する必要があります。
Entity Bean は、データストア内で維持されるデータを表した永続化オブジェクトです。Entity Bean は自身で永続性を管理するか、 その機能をEJB コンテナに委譲するかを選択できます。
Entity Bean は、プライマリキーで識別されます。たとえEJB コンテナがダウンしてもEntity Bean オブジェクトや、そのプライマリキ ー、リモート・リファレンスは残ります。
EJB 2.0 から追加されたメッセージ・ドリブンBean によって、クライアントが非同期でビジネスロジックにアクセスできようになりまし た。メッセージ・ドリブンBean は、待機しているJMS のキューやトピックから受信した非同期メッセージによって初めてアクティブにな ります。クライアントは、直接メッセージ・ドリブンBean にアクセスせず、その代わりに、メッセージをJMS サーバにキューやトピックと して送信します。
EJB コンテナには、Enterprise Bean の生成や、他のアプリケーション・コンポーネントがEnterprise Bean にアクセスできるようにネ ーミング・サービスへBean をバインドしたり、許可されたクライアントだけがEnterprise Bean にアクセスすることを保証したり、Bean の状態を永続化領域に保存したり、Bean インスタンスをキャッシュしたり、必要に応じてBean インスタンスを活性化、非活性化する 責任があります。
EJBコンテナは、全てのコンポーネントにJava SE の API を提供します。 それに加えて、Java EE の API も使用できます。 これらのAPの他、アプリケーション・プログラミングが簡素化でき、アプリケーション間のカスタマイズを可能にさせるサービスも用意されています。
ネーミング・サービスは、アプリケーション・クライアントやEnterprise Bean、Web コンポーネントにJNDI ネーミング環境へのアクセ スを提供します。このネーミング環境では、コンポーネントのソースコードを変更することなくコンポーネントをカスタマイズすること ができます。EJB コンテナは、コンポーネントの実行環境を実装し、これをコンポーネントにJNDI ネーミング・コンテキストとして提供 します。
コンポーネントでは、JTA UserTransaction オブジェクトのようなシステム提供オブジェクトと、EJB 参照、環境エントリ、JDBC データ ソースやメール送信などのユーザ定義オブジェクトの名前を指定してネーミング・サービスにアクセスできます。EJB コンテナは、そ のアクセスに備えて名前サーバに定義オブジェクトをバインドしておく役割を持ちます。
ユーザ定義オブジェクトは、「java:comp/env」という名前空間の先に格納されます。この下には、JNDI サービスによってアプリ ケーション毎にサブコンテキストが割り当てられます。これにより、たとえ異なるアプリケーションで同一の登録名が与えられていて も、それらが実際の登録時に衝突することなくアプリケーション間の独立性が維持できます。
JNDI サービスに関する詳細機能は、JNDIを参照してください。
アプリケーションはトランザクションにより、それ以上分割できない一連の作業ユニットに分割されます。トランザクションをサポート するシステムでは、各ユニット全体は他のプロセスからの干渉を受けずに完了することが保証されます。ユニットは、全体を完了で きる場合はコミットされます。全体を完了できなければ、そのユニットで実行された処理全体がシステムによって元に戻されます(ロ ールバック)。
Enterprise Bean では、Bean 管理とコンテナ管理という2つのトランザクション境界設定方式が用意されています。Bean 管理による 場合は、Bean プログラム自身が全てのトランザクション管理工程をコード化しなければなりません。一方、コンテナ管理による場合 は、EJB コンテナが配備時のトランザクション属性に基づいて管理します。コンテナが管理する範囲は、トランザクションの開始と終 了処理だけでなく、トランザクショナルなオブジェクトの寿命全体を通じてトランザクションコンテキストを維持します。これにより、分 散環境におけるトランザクションの場合に、コンポーネント供給者の責任分担とタスクが大幅に簡素化されます。
トランザクション属性は、Enterprise Bean がコンテナ管理によるトランザクション境界設定を使うBean のメソッドに関連付けられた 値です。Bean のトランザクション処理過程を最適化するために、メソッドごとに別の属性を与えることができます。
クライアントがトランザクション中であるとき、そのトランザクションでメソッドを実行します。
クライアントがトランザクション中でないとき、新たにトランザクションを開始してメソッドを実行し、メソッドの実行が終了したら、
開始したトランザクションをコミットします。
クライアントがトランザクション中であるとき、コンテナはメソッドを実行する前に、クライアントのトランザクションを中断させ、新
たにトランザクションを開始してメソッドを実行します。メソッドの実行が終了したら、開始したトランザクションをコミットして、中
断しているクライアントのトランザクションを復帰させます。
クライアントがトランザクション中でないとき、新たにトランザクションを開始してメソッドを実行し、メソッドの実行が終了したら、
開始したトランザクションをコミットします (Required と同様) 。
クライアントがトランザクション中であるとき、そのトランザクションでメソッドを実行します(Required と同様)。
クライアントがトランザクション中でないとき、コンテナはクライアントに対し、TransactionRequiredException 例外を送
出します。
クライアントがトランザクション中であるとき、コンテナはメソッドを実行する前に、クライアントのトランザクションを中断させ、ト
ランザクションなしでメソッドを実行します。メソッドの実行が終了したら、中断しているクライアントのトランザクションを復帰させ
ます。
クライアントがトランザクション中でないとき、そのままトランザクションなしでメソッドが実行されます。
クライアントがトランザクション中であるとき、そのトランザクションでメソッドを実行します (Required と同様)。
クライアントがトランザクション中でないとき、そのままトランザクションなしでメソッドが実行されます(NotSupported と同様)。
クライアントがトランザクション中であるとき、コンテナはRemoteException 例外を送出します。
クライアントがトランザクション中でないとき、そのままトランザクションなしでメソッドが実行されます(NotSupported と同様)。
トランザクションサービス自身に関する詳細機能は、JTAとトランザクションサービスを参照してください。
Java EE プラットフォームのセキュリティサービスは、リソースがその使用権限を持つユーザにのみアクセスされることを保証するよ うに設計されています。アクセス制御は、認証と承認のステップに分かれています。
EJB コンテナには、宣言とプログラムによる2種類のセキュリティ方式が用意されています。宣言によるセキュリティは、コンポーネ ント内に含まれる配備記述子という実行時属性によって指定されます。プログラムによるセキュリティは、プログラム内でアクセスさ れるセキュリティ機構を指します。EJB 仕様では、その標準API を用意しています。
アクセス制御のステップのうちの認証は、通常、Web コンテナ側のHTTP 基本認証やフォームベース認証などを使用します。認証 対象は、ユーザ名などのプリンシパルとなります。EJB コンテナを認証する方法はありませんが、Web からEJB にアクセスする場 合、Web コンテナで認証されたプリシパルがEJB コンテナに伝播されます。EJB コンテナは、渡されたプリンシパルが呼び出された メソッドを起動可能であるかを検査します。承認は、セキュリティ・ロールの概念に基づいています。ロールとは運用者が定義する 論理的なユーザ・グループです。ロールは、配備記述子内のプリシパルにマッピングされます。Enterprise Bean の各メソッドに対し ては、呼出し元が属するロールを関係付けることが可能です。
クライアント−サーバ間や、各種サーバに収容されている共用オブジェクト間の通信機構としてOMG (Object Management Group) プロトコルをサポートしています。このプロトコルを使用すると、EJB コンテナに収容されたオブジェクトと、CORBA 技術を使用して 開発されたリモート・オブジェクトが相互にアクセスできます。その主要な通信サービスがRMI-IIOP です。
RMI-IIOP は、IIOP を介したRMI API の実装です。RMI-IIOP を使用すると、アプリケーションがJava プログラミング言語でリモート・ オブジェクトにアクセスできます。コンテナ間のIIOP リモート呼び出しでは、セキュリティを必要とする場合があります。Java EE 仕様 では、RMI-IIOP を介して行われる安全な呼び出しのために、CORBA 仕様の一部である「CSIv2 (Common Secure Interoperability)」プロトコルをサポートします。CSIv2 では、メッセージの一貫性や機密性の保護や、SSL/TLS などの利用した認証 に対応しています。
これらの通信技術は、WebOTX Object Broker という名前のCORBA 製品を用いています。
EJB コンテナは、WebOTX エディションによって2つの異なる機能構造となっています。1つは、Express で提供する1つのJava 仮 想マシン上で動作する単独EJB サーバです。もう1つは、Standard で提供するWebOTX アプリケーション サーバへのプラグインとしての構造です。
このエディションでは、性能重視型としてStandard よりも軽量なアーキテクチャになっています。また、メモ リ消費量も削減されます。その反面、システム障害に対する多重化のような高度な機能を持ちません。ま た、実行状態のモニタリングは、Standard よりも対象項目が少ないものとなっています。以下に、Express 全体におけるEJB コンテナのシステムを図示します。

このエディションでは、信頼性重視型として高度な運用環境と連携します。さらに、堅牢な実行環境の上層に位置することにより、 大規模システムにも対応、拡張できます。以下に、Standard におけるEJB コンテナの関係を図示します。

実行時の特徴として、マルチプロセス動作が可能になります。
Standard では、1つのEJB コンポーネントを複数プロセス上で動作させることができます。このとき、クライ アントからアクセスされるインスタンスの種類によってオブジェクトとプロセスのマッピングが異なります。
WebOTX ASのEJB コンテナはEJB 3.2 仕様の機能を網羅しています。さらに付加価値機能として、下記の機能を提供しています。
プールとは、複数のBean インスタンスをコンテナが制御し、複数のクライアントからのリクエストを効率的に処理するためにBean インスタンスが配置されるメモリ領域を指します。プールにはクライアントからのリクエストに対してサービスを提供するために、全 てのリクエストごとにBean をインスタンス化し、放棄するオーバーヘッドを軽減させる目的があります。
一方、キャッシュとは、クライアントに迅速なサービスを提供するために特定のID を保持したBean インスタンスが配置されるメモリ 領域を指します。クライアントのリクエストにより生成されたBean インスタンスはキャッシュに常駐し、アクセスを高速化させる目的 があります。
プールとキャッシュはEJB の種類によって、そのBean の性質から使用の可否が決まっています。
| ステートレスセッションBean | ステートフルセッションBean | エンティティBean | メッセージ・ドリブンBean | |
|---|---|---|---|---|
| プール | ○ | - | ○ | ○ |
| キャッシュ | - | ○ | ○ | - |
複数トランザクションが稼動する環境でリソースに関するロックを取得する方法はコンカレンシー制御と呼ばれます。コンカレンシー 制御には、ペシミスティック・ロック(悲観的排他)とオプティミスティック・ロック(楽観的排他)の2種類があります。WebOTX では、こ の2つの制御方法をサポートしています。
ペシミスティック・ロックは、「自分が操作している情報は他の人も操作する可能性がある」という悲観的な視点に立っており、トラン ザクション開始時に排他ロックを獲得し、それをトランザクション終了時まで保持する排他方法です。つまり、ロックを獲得したアプ リケーションのみがその行にアクセスすることができ、その行を更新したい他のアプリケーションは待たされることになります。
オプティミスティック・ロックは、「自分が操作している情報は他の人が操作する可能性が低い」という楽観的な視点に立っており、 更新時にリソースに変更がないことを確認し、変更がなければ排他ロックを獲得してリソースを更新し、変更があればアプリケーシ ョンにエラーを返す排他方法です。データベースから値を読み取るだけであれば他のアプリケーションに影響を与えないため、ロッ ク待ちを解消できるという利点があります。
EJB 2.1 仕様ではトランザクションコミットオプションを3つ定義しています。これらは、コミットオプションA・コミットオプションB・コミ ットオプションC と呼ばれています。WebOTX では、コミットオプションB とC をサポートしています。
Bean インスタンスはキャッシュに保持され、プライマリキーは関連付けられていますが永続化フィールド値は関連付けされておら ず、データベースとの同期が取られていない状態です。クライアントがビジネスメソッドを呼び出したとき、EJB コンテナは対応する Bean がキャッシュに存在するかどうかプライマリキーを用いて確認を行います。キャッシュに残存していればそのキャッシュされた Bean をそのまま再利用し、永続化フィールド値とデータベースの同期を取るためにキャッシュされたBean のejbLoad()が呼び 出されます。もしキャッシュに残存していなければ、コミットオプションC 同様にBean インスタンスをプールから推移し、プライマリキ ーの関連付けから行われます。
キャッシュ領域を利用しないため、Bean インスタンスは常にプールで待機しています。そのため、クライアントからビジネスメソッド が呼び出された場合は、まずejbActivate()が呼び出されBean インスタンスにプライマリキーが関連付けられます。その後、 ejbLoad()によりBean インスタンスにプライマリキー以外の永続化フィールドとデータベースとの同期が取られます。また、クライ アントからの呼び出しが終わるとBean に関連付けられたプライマリキーが解放され、Bean インスタンスはプールへ戻されます。