|
|
以下の節では、プロダクション再デプロイメント方式を使用してアプリケーションをプログラムおよび管理する方法について説明します。
プロダクション再デプロイメントを使用すると、デプロイされたアプリケーションを停止せずに (アプリケーションのクライアントへの可用性を中断することなく)、プロダクション環境でアプリケーションの新しいバージョンを再デプロイできます。プロダクション再デプロイメントのしくみは、更新されたアプリケーションの新しいバージョンを、同じアプリケーションの古いバージョンと並行してデプロイすることです。WebLogic Server は、新しいクライアント要求のみが新しいバージョンに転送されるように、自動的にクライアント接続を管理します。再デプロイメント時にアプリケーションにすでに接続していたクライアントは、作業が完了するまで古いバージョンのアプリケーションを使用し続けます。
詳細については、「プロダクション再デプロイメントを使用したアプリケーションの更新」を参照してください。
プロダクション再デプロイメントでは HTTP クライアントと RMI クライアントのみをサポートし、Java クライアントはサポートしません。開発および設計段階において、サポートされないクライアントが、プロダクション再デプロイメントを使用しているアプリケーションにアクセスしないようにしておく必要があります。WebLogic Server はサポートされないクライアントがアプリケーションにアクセスしたことを検出せず、プロダクション再デプロイメント時にはサポートされないクライアント接続を保護しません。
エンタープライズ アプリケーションには、サポートされている J2EE モジュールであれば、どのタイプでも格納できます。エンタープライズ アプリケーションには、アプリケーション スコープの JMS モジュールや JDBC モジュールを含めることもできます。
エンタープライズ アプリケーションに JCA リソース アダプタ モジュールが含まれる場合、モジュールは以下の条件を満たす必要があります。
新しいバージョンの EAR のリソース アダプタがデプロイされる前に、旧バージョンのアプリケーションのリソース アダプタがコールバックを受け取ります。その後で、新しいバージョンのアプリケーションがデプロイされ、旧バージョンの EAR 全体が廃止されます。
リソース アダプタのプロダクション再デプロイメント要件の詳細なリストについては、『WebLogic リソース アダプタ プログラマーズ ガイド』の「プロダクションの再デプロイメント」を参照してください。
プロダクション再デプロイメントでは、グローバルな 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 のバージョン識別子を指定し、新しいアプリケーションがデプロイメント用にリリースされるたびにバージョンを自動的にインクリメントするように指定することをお勧めします。これにより、管理者またはデプロイ担当者がアプリケーションを再デプロイするたびに、プロダクション再デプロイメントが実行されるようになります。
テスト目的で、デプロイ担当者が、デプロイメントおよび再デプロイメント時にバージョン識別子をアプリケーションに割り当てることもできます。『WebLogic Server アプリケーションのデプロイメント』の「デプロイメントおよび再デプロイメント中のバージョン識別子の割り当て」を参照してください。
WebLogic Server は、MANIFEST.MF ファイルの Weblogic-Application-Version プロパティの値からアプリケーション バージョンを取得します。バージョン文字列には、215 文字までの長さを指定できます。文字列は、表 6-1 で示す有効な文字で構成する必要があります。
たとえば、次のマニフェスト ファイルの内容は、バージョン「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 属性を使用して、表示やロギングなどに使用するバージョン情報を取得できます。表 6-2 では、ApplicationMBean で利用できる読み込み専用属性を示します。
ApplicationRuntimeMBean でも、新しい読み込み専用属性を利用できます。表 6-3 を参照してください。
|
|
  
|
