ページの先頭です。
サイト内の現在位置を表示しています。
  1. ホーム
  2. ソフトウェア
  3. WebOTX
  4. アプリケーションサーバ
  5. 特長/機能
  6. 機能一覧
  7. EJBコンテナ機能
ここから本文です。

WebOTX Application Server - EJBコンテナ機能

「機能一覧」へ戻る

AS Standard-J Editionが備える機能AS Expressが備える機能AS Foundationが備える機能AS Standard Editionが備える機能AS Enterprise Editionが備える機能SIP ASが備える機能Enterprise Service Busが備える機能
EJBコンテナは多層モデルにおいてビジネスロジックをEnterprise JavaBeans (EJB) アーキテクチャに従って実装した場合のコンテナ処理を行います。アプリケーションはセッション制御やトランザクション制御、セキュリティ制御などをなるべく意識しないで、ビジネスロジックに注力することが望まれます。EJBコンテナはこれらの制御をアプリケーション(Enterprise Beanと呼ぶ)に変わって実現します。WebOTXではEJB 3.0仕様に準拠したEJBコンテナを提供しています(EJB3.0に準拠したのはV8.1からです)。

Enterprise Beanコンポーネント

EJBアーキテクチャは、エンタープライズ・アプリケーションのビジネス・ロジックを含むコンポーネントを開発しEJBコンテナに配備するためのサーバサイド技術です。このコンポーネントは、拡張性に富み、トランザクション型で、複数ユーザに対するセキュリティが適用されます。これらに適用するサービス提供元がEJBコンテナにあたります。

Enterprise Beanには、Session BeanEntity 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により、トランザクションやセキュリティ、セッション管理などの複雑な制御は上述のようにEJBコンテナで請け負い、開発者はビジネスロジック作成に注力が可能となりますが、実際にEJB 2.xまでの仕様に従ってアプリケーション開発を行う場合、必要となる各種ファイルの多さや、設定規則の複雑さから開発者負担は無視できないレベルで存在していました。

EJB3.0は、これらの問題を改善するために策定されています。O/RマッピングフレームワークやDI/AOPコンテナフレームワークからフィードバックされた機能と、Java SE 5 で導入されたアノテーションを用いることによって、開発の容易化が図られています。

EJBコンテナのサービス

EJB 3.0 コンテナは、全てのコンポーネントにJava SE 5 API を提供します。それに加えて、Java EE 5 API も使用できます。次に示す項目は、WebOTX のEJB コンテナで利用できるJava EE 5 のAPI 実装です。

これらのAPIサービスの他、アプリケーション・プログラミングが簡素化でき、アプリケーション間のカスタマイズを可能にさせるサービスも用意しています。

ネーミングサービス

ネーミング・サービスは、アプリケーション・クライアントやEnterprise Bean、WebコンポーネントにJNDIネーミング環境へのアクセスを提供します。このネーミング環境では、コンポーネントのソースコードを変更することなくコンポーネントをカスタマイズすることができます。EJBコンテナは、コンポーネントの実行環境を実装し、これをコンポーネントにJNDIネーミング・コンテキストとして提供します。

コンポーネントでは、JTA UserTransactionオブジェクトのようなシステム提供オブジェクトと、EJB参照、環境エントリ、JDBCデータソースやメール送信などのユーザ定義オブジェクトの名前を指定してネーミング・サービスにアクセスできます。EJBコンテナは、そのアクセスに備えて名前サーバに定義オブジェクトをバインドしておく役割を持ちます。

ユーザ定義オブジェクトは、「java:comp/env」という名前空間の先に格納されます。この下には、JNDIサービスによってアプリケーション毎にサブコンテキストが割り当てられます。これにより、たとえ異なるアプリケーションで同一の登録名が与えられていても、それらが実際の登録時に衝突することなくアプリケーション間の独立性が維持できます。

配備サービス

配備サービスでは、コンポーネントをカスタマイズしてパッケージ化されたJava EEアプリケーションを配備ツールから受け取り、パッケージ内の配備情報を解析した後、その情報に従ってEJBコンテナ上でEnterprise Beanコンポーネントを実行可能状態にするものです。

トランザクションサービス

アプリケーションはトランザクションにより、それ以上分割できない一連の作業ユニットに分割されます。トランザクションをサポートするシステムでは、各ユニット全体は他のプロセスからの干渉を受けずに完了することが保証されます。ユニットは、全体を完了できる場合はコミットされます。全体を完了できなければ、そのユニットで実行された処理全体がシステムによって元に戻されます(ロールバック)。

Enterprise Beanでは、Bean管理とコンテナ管理という2つのトランザクション境界設定方式が用意されています。Bean管理による場合は、Beanプログラム自身が全てのトランザクション管理工程をコード化しなければなりません。一方、コンテナ管理による場合は、EJBコンテナが配備時のトランザクション属性に基づいて管理します。コンテナが管理する範囲は、トランザクションの開始と終了処理だけでなく、トランザクショナルなオブジェクトの寿命全体を通じてトランザクション・コンテキストを維持します。これにより、分散環境におけるトランザクションの場合に、コンポーネント供給者の責任分担とタスクが大幅に簡素化されます。

トランザクション属性は、Enterprise Beanがコンテナ管理によるトランザクション境界設定を使うBeanのメソッドに関連付けられた値です。Beanのトランザクション処理過程を最適化するために、メソッドごとに別の属性を与えることができます。

Required クライアントがトランザクション中であるとき、そのトランザクションでメソッドを実行します。
クライアントがトランザクション中でないとき、新たにトランザクションを開始してメソッドを実行し、メソッドの実行が終了したら、開始したトランザクションをコミットします。
RequiresNew クライアントがトランザクション中であるとき、コンテナはメソッドを実行する前に、クライアントのトランザクションを中断させ、新たにトランザクションを開始してメソッドを実行します。
メソッドの実行が終了したら、開始したトランザクションをコミットして、中断しているクライアントのトランザクションを復帰させます。
クライアントがトランザクション中でないとき、新たにトランザクションを開始してメソッドを実行し、メソッドの実行が終了したら、開始したトランザクションをコミットします (Requiredと同様)。
Mandatory クライアントがトランザクション中であるとき、そのトランザクションでメソッドを実行します(Requiredと同様)。
クライアントがトランザクション中でないとき、コンテナはクライアントに対し、TransactionRequiredException例外を送出します。
NotSupported クライアントがトランザクション中であるとき、そのトランザクションでメソッドを実行します(Requiredと同様)。
クライアントがトランザクション中でないとき、コンテナはクライアントに対し、TransactionRequiredException例外を送出します。
Supports クライアントがトランザクション中であるとき、そのトランザクションでメソッドを実行します (Requiredと同様)。
クライアントがトランザクション中でないとき、そのままトランザクションなしでメソッドが実行されます(NotSupportedと同様)。
Never クライアントがトランザクション中であるとき、コンテナはRemoteException例外を送出します。
クライアントがトランザクション中でないとき、そのままトランザクションなしでメソッドが実行されます(NotSupportedと同様)。

セキュリティサービス

Java EEプラットフォームのセキュリティ・サービスは、リソースがその使用権限を持つユーザにのみアクセスされることを保証するように設計されています。アクセス制御は、認証と承認のステップに分かれています。

EJBコンテナには、宣言とプログラムによるものの2つのセキュリティ方式が用意されています。宣言によるセキュリティは、コンポーネント内に含まれる配備記述子という実行時属性によって指定されます。プログラムによるセキュリティは、プログラム内でアクセスされるセキュリティ機構を指します。EJB仕様では、その標準APIを用意しています。

アクセス制御のステップのうちの認証は、通常、Webコンテナ側のHTTP基本認証やフォームベース認証などを使用します。認証対象は、ユーザ名などのプリンシパルとなります。EJBコンテナを認証する方法はありませんが、WebからEJBにアクセスする場合、Webコンテナで認証されたプリシパルがEJBコンテナに伝播されます。EJBコンテナは、渡されたプリンシパルが呼び出されたメソッドを起動可能かを検査します。承認は、セキュリティ・ロールの概念に基づいています。ロールとは運用者が定義する論理的なユーザ・グループです。ロールは、配備記述子内のプリシパルにマッピングされます。Enterprise Beanの各メソッドに対しては、呼出し元が属するロールを関係付けることが可能です。

高性能で相互接続実績が豊富なRMI over IIOP

クライアント-サーバ間や、各種サーバに収容されている共用オブジェクト間の通信機構としてOMG (Object Management Group) が提唱したプロトコルをサポートしています。このプロトコルを使用すると、EJBコンテナに収容されたオブジェクトと、CORBA技術を使用して開発されたリモート・オブジェクトが相互にアクセスできます。その主要な通信サービスがRMI over IIOPです。

RMI over IIOPは、IIOPを介したRMI APIの実装です。RMI over IIOPを使用すると、アプリケーションがJavaプログラミング言語でリモート・オブジェクトにアクセスできます。

コンテナ間のIIOP リモート呼び出しでは、セキュリティを必要とする場合があります。Java EE 仕様では、RMI-IIOP を介して行われる安全な呼び出しのために、CORBA 仕様の一部である「CSIv2 (Common Secure Interoperability)」プロトコルをサポートします。CSIv2 では、メッセージの一貫性や機密性の保護や、SSL/TLS などの利用した認証に対応しています。

これらの通信技術は、WebOTX Object Brokerを用いています。Object Brokerは、業界最高レベルの性能を発揮します。

タイマーサービス

ビジネスのワークフローをモデル化するアプリケーションは、しばしば計られた時間に合わせたイベントに依存することがあります。タイマーサービスは、Enterprise Bean によって使用される通知やイベントのスケジュール化のために提供される、EJB コンテナでの永続的でトランザクショナルな通知サービスです。

コンテナは、Enterprise Bean に「時間/時刻」をトリガーにコールバックを行います。

タイマーサービスタイマーサービス

タイマーは永続性が保証されているため、サーバがクラッシュしてもシャットダウンしてもタイマー情報は消滅せずに保持され、再起動後に継続してタイマーが作動します。これは、タイマーを永続化するためにデータベースへ情報を格納しているからです。

タイマーサービスは、Enterprise Bean プログラムにとって、より高度な処理制御の管理基盤となえます。タイマーサービスが基盤として提供されることにより、例えば、監査処理や夜間バッチ処理などに有効利用できます。

EJBコンテナの機能構造 ~性能重視か信頼性重視か~

EJBコンテナには、WebOTXのエディションによって2つの異なる機能構造となっています。1つは、Standard-J Editionで提供する1つのJava仮想マシン上で動作する単独EJBサーバです。もう1つは、Standard/Enterprise Editionで提供するWebOTXアプリケーション・サーバへのプラグインとしての構造です。

Standard-J EditionのEJBコンテナ

このエディションでは、性能重視型としてStandard/Enterprise Editionよりも軽量なアーキテクチャになっています。また、メモリ消費量も削減されます。その反面、システム障害に対する多重化や、実行状態のモニタリングなどの機能がStandard/Enterprise Editionに比べ限定されます以下に、Standard-J Edition全体におけるEJBコンテナのシステムを図示します。

Standard-J Edition(性能重視)Standard-J Edition(性能重視)

Standard/Enterprise EditionのEJBコンテナ

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

Standard/Enterprise Edition(信頼性重視)Standard/Enterprise Edition(信頼性重視)

実行時の特徴として、マルチプロセス動作が可能になります。


ページの先頭へ戻る