このトピックでは、同一アプリケーションの複数エディションを並行して活動化する方法を説明します。
並行した活動化は、実動前の妥当性検査、選択されたユーザーのグループに対するアプリケーションの準備試験、
および、アプリケーション・アップグレードにおいて、識別可能なクライアント・マシンのブランチに対応する変更が
必要な場合のブランチ・ロールアウトなどで有用です。
Before you begin
同一アプリケーションの、少なくとも 2 つのエディションがインストールされている必要があります。
この解説では、BeenThere アプリケーションのエディション 1.0 がターゲット BTDC1 にインストール済みであり、エディション 2.0
がターゲット BTDC2 にインストールされています。
Why and when to perform this task
それぞれのエディションは、別々のデプロイメント・ターゲット上で活動中である必要があります。
同一アプリケーションの複数エディションが同一環境のユーザーに対して並行して使用可能である場合、オンデマンド・ルーター (ODR) は、要求のあいまいさを排除して対象のエディションにルーティングするために使用可能な情報がない限り、
活動中のエディションを区別できません。
各エディションごとにルーティング・ルールや固有のインターフェースを使用すれば、このあいまいさを防止できます。
複数のデプロイメント・ターゲットにある複数のアプリケーション・エディションを並行してホストし、アクセスするには、以下を実行します。
- 「アプリケーション」>「Edition control center」とクリックします。
ご使用のアプリケーションの 2 つのエディションがインストール済みであり、1 つのエディションのみが活動中であることを確認します。
- 「BeenThere」アプリケーションのリンクをクリックします。
- エディション 2.0 を選択し、「活動化」をクリックします。
- 以下を実行して、アプリケーション・エディションごとにルーティング・ポリシーを作成します。
- 「アプリケーション」>「エンタープライズ・アプリケーション」とクリックします。
- ご使用のアプリケーション・リンクをクリックします。
この解説では、「BeenThere」をクリックします。
- 「Routing policies」タブをクリックします。
- 「Work classes for HTTP requests」を展開します。
ルーティング・ルールが指定されていないため、
すべての要求はこのページに表示されたエディションにルーティングされます。
この解説では、すべての要求はアプリケーション・エディション BeenThere-edition2.0
にルーティングされます。
- 「Rule builder」をクリックします。
- ルールのリストから、ルールを選択します。
この解説では、「clienthost」を選択し、「追加」をクリックします。
- ルールの基準を選択します。
この解説では、等価 (=) 演算子を選択し、ご使用のクライアント・ホスト名の値を入力します。
「OK」をクリックします。
- 再度「OK」をクリックします。
- 「Work classes for HTTP requests」を展開します。
- 新規ルールに関連付けるアクションを設定します。
この解説では、ホストからの要求をエディション BeenThere-edition1.0
にルーティングします。
対応するアクションを「Then」リストから選択し、「適用」をクリックしてルールを保管します。
- 「Routing policies」タブで「適用」をクリックします。
- 構成リポジトリーへの変更を保管し、ノードを同期します。
- ODR が実行中であることを確認します。
「サーバー」>「On demand routers」とクリックします。
- 各アプリケーション・エディションへの並行アクセスをテストします。
2 つの動的クラスター BTDC1 および BTDC2
に関連したアプリケーション・サーバーを選択し、「開始」をクリックして、2
つのアプリケーション・エディションを選択します。
Result
指定したホスト名のクライアントから ODR に要求が送信されると、その要求は
edition 1.0 により処理され、その他のすべてのクライアントからの要求は
edition 2.0 により処理されます。
Example
例えば、実稼働環境において、あるアプリケーション・エディションの実動前テストを選択されたユーザー・グループで実行するには、デプロイメント・ターゲットのクローンをそのリソースおよびセキュリティー定義も含めて作成し、
クローンの環境でターゲットのエディションを活動化します。
ルーティング・ルールを使用して、選択されたユーザーのサブセットをそのエディションに方向転換するように
ODR に指示します。
さらに、アプリケーションの準備試験を行う場合は、ルーティング・ルールを使用して、エディション
2.0 の試験ユーザーとエディション 1.0 の一般ユーザーを分離できます。
ブランチ・ロールアウトの場合は、ルーティング・ルールを使用して、
それぞれのブランチを適切なエディションに誘導します。
クライアント・コードは後続のそれぞれのブランチで更新されるので、
サーバー・サイドのルーティング・ルールがクライアントを限定するよう更新され、
新規に更新されたブランチが適切なエディションに送信されるようにできます。
ルーティング・ルールがユーザー要求の区別に対して不十分である場合や、
ユーザーがルーティング・ルール以外の方法を希望する場合は、それぞれのエディションに独自の固有
URI および Enterprise JavaBeans (EJB) Java Naming and Directory Interface (JNDI) 名を設定できます。
ルーティング・ルールと異なり、各エディション用の固有インターフェースはアプリケーション・ユーザーに公開されます。
そのため、ユーザーは、適切な名前を選択して適切なエディションを使用する必要があります。