この章の内容は次のとおりです。
本番再デプロイメントを使用すると、デプロイされたアプリケーションを停止せずに(アプリケーションのクライアントへの可用性を中断することなく)、本番環境でアプリケーションの新しいバージョンを再デプロイできます。本番再デプロイメントのしくみは、更新されたアプリケーションの新しいバージョンを、同じアプリケーションの古いバージョンと並行してデプロイすることです。WebLogic Serverは、新しいクライアント・リクエストのみが新しいバージョンに転送されるように、自動的にクライアント接続を管理します。再デプロイメント時にアプリケーションにすでに接続していたクライアントは、作業が完了するまで、より古いリタイア中のバージョンのアプリケーションを使用し続けます。
詳細は、「本番再デプロイメントを使用したアプリケーションのアップグレード」を参照してください。
本番再デプロイメントでサポートされるのはHTTPクライアントとRMIクライアントのみです。開発および設計段階において、サポートされないクライアントが、本番再デプロイメントを使用しているアプリケーションにアクセスしないようにしておく必要があります。WebLogic Serverはサポートされないクライアントがアプリケーションにアクセスしたことを検出せず、本番再デプロイメント時にはサポートされないクライアント接続を保護しません。
エンタープライズ・アプリケーションには、サポートされているJava EEモジュールであれば、どのタイプでも格納できます。エンタープライズ・アプリケーションには、アプリケーション・スコープのJMSモジュールやJDBCモジュールも格納できます。
エンタープライズ・アプリケーションにJCAリソース・アダプタ・モジュールが含まれる場合、モジュールは次の条件を満たす必要があります。
JCA 1.5に準拠している必要があります
weblogic.connector.extensions.Suspendable
インタフェースを実装する必要があります
enable-access-outside-app
がfalse
(デフォルト値)に設定された状態で、アプリケーション・スコープ方式で使用される必要があります
新しいバージョンのEARのリソース・アダプタがデプロイされる前に、旧バージョンのアプリケーションのリソース・アダプタがコールバックを受け取ります。その後で、新しいバージョンのアプリケーションがデプロイされ、旧バージョンのEAR全体がリタイアされます。
リソース・アダプタの本番再デプロイメント要件の一覧については、『Oracle WebLogic Serverリソース・アダプタの開発』の本番再デプロイメントに関する項を参照してください。
本番再デプロイメントでは、グローバルなJMS宛先からのインバウンドJMSメッセージによってアクセスされるエンタープライズ・アプリケーションおよび1つまたは複数のメッセージドリブンBeanをコンシューマとして使用するエンタープライズ・アプリケーションもサポートされます。この種類のアプリケーションの場合、WebLogic Serverは、リタイアされた旧バージョンのアプリケーションのメッセージドリブンBeanを保留してから、新しいバージョンのメッセージドリブンBeanをデプロイします。グローバルJMS宛先に対してJMS APIを使用するJMSコンシューマの場合、本番再デプロイメントはサポートされません。メッセージドリブンBeanが、保留中にパブリッシュされたメッセージなど、トピックからパブリッシュされたメッセージをすべて受信する必要がある場合は、恒久サブスクライバを使用します。
WebLogic Serverは、本番再デプロイメントを実行する際に、アプリケーションの2つのインスタンスを同時にデプロイします。アプリケーションの複数のインスタンスがWebLogic Serverドメインに共存できるようにするには、一定のプログラミング規約に従う必要があります。次の項では、本番再デプロイメントで必須のプログラミング規約について説明します。
インプレース再デプロイメント戦略を使用するアプリケーションは、リソースの使用に際して自己完結型となるのが最善の方法です。つまり、バージョン管理されたアプリケーションの場合は通常、グローバル・リソースではなく、アプリケーション・スコープのJMSおよびJDBCリソースを可能な限り使用します。
アプリケーションがグローバル・リソースを使用する必要がある場合、アプリケーションが複数のインスタンスによる安全な同時アクセスをサポートするようにプログラミングする必要があります。これは、アプリケーションが外部(別にデプロイされた)アプリケーションまたは外部プロパティ・ファイルを使用する場合にも当てはまります。WebLogic Serverでは、バージョン管理されたアプリケーションでグローバル・リソースを使用できない仕様にはなっていないので、リソースへのアクセスが安全な方法で行われるようにする必要があります。
バージョン管理されたアプリケーション内からグローバルJNDIリソースをルックアップすると、警告メッセージが表示されます。このチェックを無効にするには、JNDIルックアップ時にJNDI環境プロパティweblogic.jndi.WLContext.ALLOW_GLOBAL_RESOURCE_LOOKUP
をtrue
に設定します。
同様に、外部アプリケーションをルックアップしたときに警告が表示されないようにするには、JNDI環境プロパティweblogic.jndi.WLContext.ALLOW_EXTERNAL_APP_LOOKUP
をtrue
に設定します。
WebLogic Serverは、JMSおよびJDBCアプリケーション・モジュールなどのアプリケーション・スコープのリソースを、アプリケーションで使用可能なローカルJNDIツリーにバインドします。バージョン管理されていないアプリケーションと同様に、バージョン管理されているアプリケーションは、このローカル・ツリーからアプリケーション・スコープのリソースを直接ルックアップできます。アプリケーション・スコープJMSモジュールには、JMS APIまたはメッセージドリブンBeanなどのサポートされているJMSインタフェースを介してアクセスできます。
グローバルJNDIツリーにバインドされているアプリケーション・モジュールには、同じアプリケーション・バージョン内からのみアクセスする必要があります。WebLogic Serverは、バージョン管理されているアプリケーションでデプロイされたグローバル・リソースに対してバージョン対応JNDIルックアップとバインドを実行します。デフォルトでは、グローバル・リソースに対する内部JNDIルックアップは、同じバージョンのアプリケーションに対するバインドを返します。
現在のバージョンのアプリケーションが見つからない場合は、JNDI環境プロパティweblogic.jndi.WLContext.RELAX_VERSION_LOOKUP
を使用して、同じバージョンではなく、現在アクティブなバージョンのアプリケーションからバインドを返します。
注意:
ルックアップしている新旧バージョンのリソースが互換可能であることが明らかな場合にのみ、weblogic.jndi.WLContext.RELAX_VERSION_LOOKUP
をtrue
に設定します。
アプリケーションで使用するセキュリティ・プロバイダは、WebLogic ServerアプリケーションのバージョニングSSPIをサポートする必要があります。デフォルトのWebLogic Serverセキュリティ・プロバイダ(許可、ロール・マッピング、および資格証明マッピング・プロバイダ)は、アプリケーション・バージョニングSSPIをサポートしています。
本番再デプロイメントを使用するには、アプリケーションの現在のデプロイされているバージョンと更新されたバージョンの双方が一意のバージョン識別子を指定する必要があります。「アプリケーションのバージョンの割当て」を参照してください。
バージョン管理されたアプリケーションは、各バージョンで共通しているアプリケーション名とアプリケーションのバージョンごとに変わるアプリケーション識別子の両方をプログラムで取得できます。デプロイされたバージョンに関係なく、アプリケーション名を参照するエラー・メッセージまたは基本表示には、アプリケーション名を使用します。アプリケーションのデプロイされたバージョンに対してアプリケーションが一意の識別子を提供する必要がある場合は、アプリケーションIDを使用します。名前と識別子を提供するMBean属性の詳細は、「バージョン情報へのアクセス」を参照してください。
「本番再デプロイメントとは」の説明にあるとおり、WebLogic Serverは、進行中のクライアントの全作業が完了するまで、クライアント・アプリケーションのリクエストを同じバージョンのアプリケーションにルーティングします。ただし、アプリケーションのバージョンがタイムアウト期間によってリタイアされるか、デプロイされていない場合、クライアントのリクエストは、アクティブなバージョンのアプリケーションにルーティングされます。つまり、指定したアプリケーション・バージョンに対するクライアントの関連付けは、best-effortに基づいて維持されます。
リクエストの処理時に別のアプリケーションに再帰的にアクセスするクライアント・アプリケーションの場合、この性質は問題となる場合があります。WebLogic Serverは、再帰的にアクセスされたアプリケーションの同じバージョンにリクエストをディスパッチしようとしますが、中間のアプリケーション・バージョンが手動でデプロイされていないこと、およびタイムアウト期間後であることを保証しません。厳密なバージョン要件を持つ関連アプリケーションのグループがある場合は、本番再デプロイメント時のバージョンの一貫性を維持するために、全アプリケーションをまとめてパッケージ化することをお薦めします。
アプリケーションのMANIFEST.MF
のバージョン識別子を指定し、新しいアプリケーションがデプロイメント用にリリースされるたびにバージョンを自動的にインクリメントするように指定することをお薦めします。これにより、管理者またはデプロイヤがアプリケーションを再デプロイするたびに、本番再デプロイメントが実行されるようになります。
テスト目的で、デプロイヤが、デプロイメントおよび再デプロイメント時にバージョン識別子をアプリケーションに割り当てることもできます。『Oracle WebLogic Serverへのアプリケーションへのデプロイ』のデプロイメントおよび再デプロイメント中のバージョン識別子の割当てに関する項を参照してください。
WebLogic Serverは、MANIFEST.MF
ファイルのWeblogic-Application-Version
プロパティの値からアプリケーション・バージョンを取得します。バージョン文字列には最大で215文字まで指定できます。表7-1に示す有効な文字以外は使用できません。
表7-1 有効な文字と無効な文字
有効なASCII文字 | 無効なバージョン構成 |
---|---|
a-z |
.. |
A-Z |
. |
0-9 |
|
他の文字と組み合わせたピリオド(「.」)、アンダースコア(「_」)、ハイフン(「-」) |
たとえば、次のマニフェスト・ファイルの内容は、バージョン「v920.beta」
のアプリケーションを示します。
Manifest-Version: 1.0 Created-By: 1.4.1_05-b01 (Sun Microsystems Inc.) Weblogic-Application-Version: v920.beta
WebLogic Server 9.2以降へのデプロイメント用にアプリケーションをアップグレードする場合、AppDeploymentMBean
から取得されたName
属性は、デプロイされたアプリケーション名およびアプリケーションのバージョン文字列で構成された一意のアプリケーション識別子を戻します。デプロイされたアプリケーション名が必要なアプリケーションは、Name
属性ではなく、新しいApplicationName
属性を使用する必要があります。一意の識別子が必要なアプリケーションは、Name
属性とApplicationIdentifier
属性のどちらでも使用できます(「バージョン情報へのアクセス」を参照)。
アプリケーション・コードは、新しいMBean属性を使用して、表示やロギングなどに使用するバージョン情報を取得できます。次の表では、ApplicationMBean
で利用できる読取り専用属性を示します。
表7-2 ApplicationMBeanの読取り専用のバージョン属性
属性名 | 説明 |
---|---|
ApplicationName |
アプリケーションのデプロイメント名を表す文字列 |
VersionIdentifier |
同じアプリケーションのすべてのバージョンの中から、現在のアプリケーションのバージョンを一意に識別する文字列 |
ApplicationIdentifier |
デプロイされたすべてのアプリケーションおよびバージョンの中から、現在のアプリケーションのバージョンを一意に識別する文字列 |
ApplicationRuntimeMBean
でも、新しい読取り専用属性のバージョン情報を利用できます。次の表を参照してください。
表7-3 ApplicationRuntimeMBeanの読取り専用のバージョン属性
属性名 | 説明 |
---|---|
ApplicationName |
アプリケーションのデプロイメント名を表す文字列 |
ApplicationVersion |
アプリケーションのバージョンを表す文字列 |
ActiveVersionState |
アクティブなアプリケーション・バージョンの現在の状態を示す整数。アクティブなバージョンの有効な状態は次のとおりです。
詳細は、『Oracle WebLogic Server Java APIリファレンス』を参照してください。 管理者が本番再デプロイメント・プロセスを逆転させる場合もあるため、現在アクティブなバージョンが、最後にデプロイされたバージョンに対応しているとは限りません。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番再デプロイメント・プロセスのロールバックに関する項を参照してください。 |