サイト内の現在位置を表示しています。

WebOTX Application Server - EJBコンテナ機能

AS Expressが備える機能AS Standard Editionが備える機能Enterprise Service Busが備える機能


EJBコンテナは多層モデルにおいてビジネスロジックをEnterprise JavaBeans (EJB) アーキテクチャに従って実装した場合のコンテナ処理を行います。アプリケーションはセッション制御やトランザクション制御、セキュリティ制御などをなるべく意識しないで、ビジネスロジックに注力することが望まれます。EJBコンテナはこれらの制御をアプリケーション(Enterprise Beanと呼ぶ)に変わって実現します。WebOTX V10.1以降(Java EE 7準拠)ではEJB 3.2仕様に準拠しています。

Enterprise Beanコンポーネント

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

Enterprise Beanには、Session BeanEntity Bean、メッセージドリブンBeanの3種類があります。

Session Beanは、クライアントに代わって任意の処理(ビジネスロジック)を実行するインスタンスです。Session Beanはトランザクションに対応するため、実行時にアプリケーション内部で例外が発生した場合はロールバック可能です。ただし、EJBコンテナがダウンすると、Session Beanが破棄されるため回復不能です。

Session Beanには、複数のメソッドやトランザクション間で会話状態を維持できるステートフルSession Bean、会話状態を維持しないステートレスSession Bean、アプリケーションでインスタンスを1つだけ生成するシングルトンSession Beanの3種類あり、用途に応じて適切に使い分けることでEJBの使用負荷を下げることがでます。状態維持のためのオブジェクト管理は、EJBコンテナが行いますが、オブジェクト自体の永続データの管理は、Session Bean自身が行う必要があります。

Entity Beanは、データストア内で維持されるデータを表した永続化オブジェクトですが、Java EE 7仕様からはEntity Beanの代わりにJPA(Java Persistence API)エンティティを使用して永続化オブジェクトを実装することが推奨されています。このため、Java EE 7に準拠するEJB 3.2仕様では、Entity BeanはEJBコンテナが機能を提供しなくても良い、オプション扱いとなっています。ただし、WebOTX V10では後方互換のためにEntity Beanをサポートしています。

EJB 2.0から追加されたメッセージドリブンBeanによって、クライアントが非同期でビジネスロジックにアクセスできようになりました。メッセージドリブンBeanは、待機しているJMSのキューやトピックから受信した非同期メッセージによって初めてアクティブになります。クライアントは、直接メッセージドリブンBeanにアクセスせず、その代わりに、メッセージをJMSサーバにキューやトピックとして送信します。

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

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

EJBコンテナのサービス

EJB 3.2 コンテナは、Java EE 7 の API を使用できます。次に示す項目は、WebOTX のEJB コンテナで利用できるJava EE 7 のAPI 実装です。

  • JSR 353 Java API for JSON Processing
  • JSR 052 Standard Tag Library for JavaServer Pages (JSTL) 1.2
  • JSR 352 Batch Applications for the Java Platform
  • JSR 236 Concurrency Utilities for Java EE 1.0
  • JSR 346 Contexts and Dependency Injection for Java 1.1
  • JSR 330 Dependency Injection for Java 1.0
  • JSR 349 Bean Validation 1.1
  • JSR 345 Enterprise JavaBeans 3.2
  • JSR 318 Interceptors 1.2
  • JSR 322 Java EE Connector Architecture 1.7
  • JSR 338 Java Persistence 2.1
  • JSR 250 Common Annotations for the Java Platform 1.2
  • JSR 343 Java Message Service API 2.0
  • JSR 907 Java Transaction API (JTA) 1.2
  • JSR 919 JavaMail 1.5
  • JSR 196 Java Authentication Service Provider Interface for Containers 1.1
  • JSR 115 Java Authorization Contract for Containers 1.5
  • JSR 088 Java EE Application Deployment 1.2 (Optional)
  • JSR 077 J2EE Management 1.1
  • JSR 222 Java Architecture for XML Binding (JAXB) 2.2
  • JSR 206 Java API for XML Processing (JAXP) 1.3
  • JSR 221 Java Database Connectivity 4.0
  • JSR 003 Java Management Extensions (JMX) 2.0
  • JSR 925 JavaBeans Activation Framework (JAF) 1.1
  • JSR 173 Streaming API for XML (StAX) 1.0

これらの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 クライアントがトランザクション中であるとき、そのトランザクションを中断して、トランザクションなしでメソッドを実行します。
クライアントがトランザクション中でないとき、そのままトランザクションなしでメソッドが実行されます。
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 プログラムにとって、より高度な処理制御の管理基盤となえます。タイマーサービスが基盤として提供されることにより、例えば、監査処理や夜間バッチ処理などに有効利用できます。