| Oracle Containers for J2EEデプロイメント・ガイド 10g（10.1.3.5.0） B56032-01 |
|
 戻る |
 次へ |
次の項目では、OC4Jインスタンスで実行するアプリケーションへのEnterprise JavaBeans（EJB）モジュールのデプロイと再デプロイについて説明します。
EJBデプロイ・プロセスは高度に自動化されています。1つ以上のEJB JARファイルを含むアプリケーションをデプロイすると、OC4Jは次の内容を実行します。
OC4Jは、各ホーム・インタフェース（EJBHomeおよびEJBLocalHomeの実装）と、各EJB JARファイルにパッケージされたコンポーネント・インタフェース（EJBObjectおよびEJBLocalObjectの実装）に対してラッパー・クラスを生成します。
OC4Jは、生成されたEJBラッパー・クラスのコンパイルに使用するように構成されたJavaコンパイラを呼び出します。コンパイルされたクラスは、ORACLE_HOME/j2ee/instance/app_name/application-deployments/に生成される新しいサブディレクトリのdeployment-cache.jarという名前のアーカイブに出力されます。このサブディレクトリの名前は、デプロイされるEJB JARと同じです。
たとえば、inventory-ejb.jarを含むmystore.earをデプロイしたとします。コンパイルされたラッパー・クラスは、ORACLE_HOME/j2ee/instance/mystore/application-deployments/inventory-ejb/deployment-cache.jarに生成されます。
OC4Jは、そのように構成されている場合はオプションとして、各ホーム・インタフェースおよびコンポーネント・インタフェースに対してクライアント・サイドIIOPスタブを生成します。
OC4Jによりアプリケーションに対して作成されるディレクトリ構造の例は、「デプロイされたアプリケーション・ディレクトリ構造の例」を参照してください。
多数（100程度）のEJBモジュールを含むEJB JARファイルのデプロイでは、OC4JやJavaコンパイラで実行される処理量のために、アプリケーションのデプロイに必要な時間が大幅に延長される可能性があります。大型アプリケーションのデプロイでのOC4JおよびJavaのチューニングのガイドラインは、第4章「大型アプリケーションのデプロイ」を参照してください。
|
注意: Application Server Controlを使用している場合、セッションBeanでデプロイされたEJB 3.0エンティティはEJB JARモジュールのApplication Server Controlビューでは表示できません。EJB 3.0エンティティをOC4Jにデプロイした後、それをApplication Server Controlで管理することはできません。EJBモジュールの表示にApplication Server Controlを使用すると、エンティティBean領域に次のメッセージが表示されます。No entity beans found セッションBeanなどのその他のEJB 3.0 Beanはすべて管理できます。EJB 3.0セッションBeanとEJB 3.0エンティティの両方を含むEJBモジュールをデプロイした場合、セッションBeanはApplication Server Controlで表示できますが、エンティティは表示できません。 EJBモジュール管理の詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』を参照してください。 |
Application Server Control、admin_client.jarまたはOC4J Antタスクを使用してデプロイを行うときに、OC4Jは、オプションとして各ホーム・インタフェースおよびコンポーネント・インタフェースに対してクライアント・サイドIIOPスタブを生成します（そのように構成されている場合）。
Application Server Controlによるアプリケーションのデプロイ方法は、「アプリケーションのデプロイまたは再デプロイ」を参照してください。
EJBモジュールをデプロイする前に、クライアント・サイドIIOPスタブを生成するようにApplication Server ControlでOC4Jを構成します。
OC4Jインスタンスに対する「管理」タブをクリックします。
「プロパティ」の下の「EJBコンパイラ設定」を選択します。
「コンパイル時パラメータ」の下の「EJBのコンパイル時にIIOPクライアント・スタブを生成」を選択します。
次に、デプロイ時のスタブ生成を有効にします。
デプロイ・ウィザードの3番目のパネル（「デプロイ設定」）で、「デプロイ・プランの編集」をクリックします。
enableIIOPをtrueに設定します。
すべてのEJBモジュールに対して生成されたアプリケーションレベルのスタブは、ORACLE_HOME/j2ee/instance/application-deployments/app_nameディレクトリの_iiopClient.jarという名前のアーカイブに出力されます。
また、個別のEJBモジュールに対するスタブは、ORACLE_HOME/j2ee/instance/application-deployments/app_name/ejbModuleName/ディレクトリの同じ名前のアーカイブに生成されます。
admin_client.jarコマンドラインに対する-deployコマンドには、IIOPスタブを生成する2つのオプションがあります。1つはサーバーにスタブを生成するオプション、もう1つはサーバーにスタブを生成して、新しいスタブを別の場所にコピーするオプションです。
EJBモジュールをデプロイする前に、-DGenerateIIOPシステム・プロパティを設定します。これで、OC4Jが起動時にクライアント・サイドIIOPスタブを生成するように構成されます。
スタンドアロンOC4Jでは、OC4Jコマンドラインでこのシステム・プロパティを次のように指定します。
java -DGenerateIIOP=true -Dhttp.session.debug=true -jar oc4j.jar
OPMN管理のOC4Jインスタンスでは、次のようにopmn.xmlでプロパティを設定します。
<ias-component id="default_group">
<process-type id="home" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="java-options" value="-DGenerateIIOP=true
-Dhttp.session.debug=true"/>
</category>
...
</module-data>
</process-type>
</ias-component>
次に、admin_client.jar -deployコマンドでアプリケーションをデプロイします。このコマンドの使用方法は、「アーカイブのデプロイ」を参照してください。
-enableIIOPを指定して、IIOPクライアント・スタブをOC4Jサーバーに生成します。
すべてのEJBモジュールに対して生成されたアプリケーションレベルのスタブは、ORACLE_HOME/j2ee/instance/application-deployments/appNameディレクトリの_iiopClient.jarという名前のアーカイブに出力されます。また、個別のEJBモジュールに対するスタブは、ORACLE_HOME/j2ee/instance/application-deployments/appName/ejbModuleName/ディレクトリの同じ名前のアーカイブに生成されます。
-iiopClientJar pathを指定して、前述と同じ場所およびパラメータで指定したパスにスタブを生成します。
デプロイ後にサーバーのファイル・システムからデプロイ・アーカイブを削除する場合は、-removeArchiveを挿入します。
deploy Antタスクにも、IIOPスタブを生成する2つのオプションがあります。1つはサーバーにスタブを生成するオプション、もう1つはサーバーにスタブを生成して、新しいスタブを別の場所にコピーするオプションです。
EJBモジュールをデプロイする前に、-DGenerateIIOPシステム・プロパティを設定します。これで、OC4Jが起動時にクライアント・サイドIIOPスタブを生成するように構成されます。詳細は、前述の項の「admin_client.jarによるスタブの生成」を参照してください。
次に、deployタスクでアプリケーションをデプロイします。このタスクの使用方法は、「J2EEアプリケーション（EAR）のデプロイ」を参照してください。
enableIIOPを指定して、IIOPクライアント・スタブをOC4Jサーバーに生成します。
すべてのEJBモジュールに対して生成されたアプリケーションレベルのスタブは、ORACLE_HOME/j2ee/instance/application-deployments/appNameディレクトリの_iiopClient.jarという名前のアーカイブに出力されます。また、個別のEJBモジュールに対するスタブは、ORACLE_HOME/j2ee/instance/application-deployments/appName/ejbModuleNameディレクトリの同じ名前のアーカイブに生成されます。
iiopClientJarPathを指定して、前述と同じ場所およびパラメータで指定したパスにスタブを生成します。
OC4Jでは、デプロイ済アプリケーションに含まれるEJBモジュールの増分再デプロイ、つまり部分的な再デプロイがサポートされます。この機能により、EJB JAR内の変更されたBeanのみをデプロイすることが可能になります。モジュール全体を再デプロイする必要はありません。前にデプロイされたBeanで変更されていないものは引き続き使用されます。
この機能は、以前のリリースのOC4Jから大幅に拡張されています。以前のリリースでは、EJBモジュールが1つの単位として扱われ、モジュールをまずアンデプロイしてから更新を再デプロイする必要がありました。
OC4Jの再起動が必要になるのは、再デプロイ・プロセスでEJB構成データが変更される場合のみです。変更がない場合は、OC4Jを再起動せずにホット・デプロイを実行できます。
増分再デプロイ操作では、更新対象のEJBモジュールを含むアプリケーションが自動的に停止します。終了すると、アプリケーションが自動的に再起動します。
|
注意: 再デプロイ時には、更新されるEJBモジュールに対するクライアントの接続は切断されます。EJBモジュールを再デプロイする前にアプリケーションを停止することを強くお薦めします。既存のすべてのリクエストの処理は完了できますが、新しいリクエストが可能になるのはアプリケーションが再起動されてからです。 |
CMPまたはBMPエンティティBeanについて、OC4Jはコード生成を使用してEJBインタフェース（ラッパー）のサーバー実装を生成します。このケースでは、変更されたBeanのみの増分デプロイの方が、アプリケーション全体の再デプロイよりも効率がよい場合がほとんどです。
セッションBean、メッセージドリブンBeanおよびEJB 3.0 JPAエンティティについて、OC4Jはバイト・コード生成を使用してラッパーを生成します。このアプローチではデプロイ時間が非常に短縮されるため、アプリケーション全体の再デプロイが変更されたBeanのみの再デプロイと同じくらい効率的になる可能性があります。このケースでは、増分再デプロイはオプションとなります。
増分デプロイを使用する一般的手順は次のとおりです。
多数のEnterprise Beanを持つアプリケーションをデプロイします。
EJBモジュールのBean関連クラス・ファイルを変更して、EJB JARファイルを再構築します（myBeans-ejb.jarなど）。
次のいずれかのツールを使用して更新したEJB JARをOC4Jに送信します。
JDeveloper
updateEJBModule Antタスク
「デプロイ済EJBモジュールでの変更済クラスの更新」を参照してください。
admin_client.jarまたはadmin.jarコマンドライン・ユーティリティの-updateEBJModuleコマンド
admin_client.jarの使用に関する詳細は「デプロイ済EJBモジュールでの変更済クラスの更新」、admin.jarの使用に関する詳細は「デプロイ済アプリケーション内のEJBモジュールの更新」を参照してください。
次の例は、増分再デプロイでadmin_client.jarを使用する方法を示しています。
java -jar admin_client.jar deployer:oc4j:rmis://localhost:23791 admin welcome -updateEJBModule -appName petstore -ejbModuleName myBeans-ejb.jar -file build/myBeans-ejb.jar
ステップ2および3を繰り返します。
詳細は『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』を参照してください。
EJBの再デプロイが既存のクライアントに与える影響は、アプリケーションで使用されるEJBモジュールのタイプによって異なります。次の項目について説明します。
セッションBeanの再デプロイに関連する問題を次に示します。
ステートレス・セッションEJBモジュールを含むアプリケーションでは、再デプロイはユーザーに対して透過的に行われ、サービスの中断はありません。既存のリクエストは現行のBeanインスタンスで処理されますが、新しいリクエストは新しいインスタンスで処理されます。
アクティブなステートフル・セッションEJBインスタンスを利用するアプリケーションまたはWebサービスでは、永続ディレクトリを明示的に指定する必要があります。このディレクトリには、アンデプロイ・プロセスと再デプロイ・プロセスの際にシリアライズによってクライアントの状態データが永続化されます。このディレクトリを指定しないと、シリアライズされた状態データはすべてアンデプロイ時に失われます。
永続ディレクトリは、orion-application.xml構成ファイルの<persistence>要素で定義されます。このディレクトリは、EJBアーカイブのデプロイ時にデプロイ・プラン・エディタを使用してpersistencePathプロパティの値として設定することもできます。詳細は、「Webモジュールの構成プロパティの設定」を参照してください。
また、既存のクライアントでは、モジュールにデプロイされたセッションBeanの構造に変更があるとシリアライズ関連の例外が発生することに注意してください。
