サービス・バージョンのTuxedoアプリケーションへの適用

このトピックは、以下の項で構成されています。

•

概要

•	アプリケーション・サービスのバージョニングの有効化および無効化

•	アプリケーション・サービス・バージョンの構成

•	バージョン・ベース・ルーティング

•	MIBによるユーザー構成サービス・バージョン情報のリセット

•

相互運用性

概要

時間の経過に伴い、既存の機能を維持すると同時に、サービスに新機能を追加するようユーザーが求めることは珍しくありません。互換性のリスクを減らすために、2つのバージョン・サービスに同じサービス名(1つは旧機能用、もう1つは新機能用)を付与することをお薦めします。古いクライアントではコードを変更しないで既存の機能を引き続き使用できる一方で、新しいクライアントでは新しい機能を使用できます。

アプリケーション・サービス・バージョン機能によって、Tuxedoのカスタマが各ステージでTuxedoアプリケーションを計画、開発、テスト、スケーリングおよびデプロイするために使用できる構成駆動型の方法が提供されます。ユーザーは、バージョンを使用して、現在のTuxedo管理階層の様々な仮想アプリケーション・ドメイン、様々な仮想マシンおよび様々な仮想サーバー・グループに、現在のTuxedoアプリケーションを分離することで、様々な特別ビジネス・アクセス・ロジックに対応し、その一方でノンストップ・モードでアップグレード要件を満たすことができます。

この機能は、COBOLアプリケーションおよびプログラミング環境をサポートしており、COBOL環境を特別に変更する必要はありません。

この機能は、/Qに対してのみFORWARDキューをサポートしています。アプリケーション・サービス・バージョニングが有効な場合、クライアントがFORWARDキューにメッセージを入れると、FORWARDキューは、キューに入れられたメッセージを、クライアントのリクエスト・バージョンをサポートするサービスに転送します。

アプリケーション・サービスのバージョニングの有効化および無効化

UBB構成ファイルやMIBを使用すると、アプリケーション・サービス・バージョニング機能を有効化/無効化できます。

UBB構成ファイルによるアプリケーション・サービス・バージョニングの有効化/無効化

UBB構成ファイルでアプリケーション・サービス・バージョニングを有効化するには、APPVERオプションを*RESOURCESセクション内のOPTIONSパラメータに追加します。

例:

*RESOURCES

OPTIONS APPVER, LAN

UBB構成ファイルでアプリケーション・サービス・バージョンを無効化するには、APPVERオプションを*RESOURCESセクション内のOPTIONSパラメータから削除します。

例:

*RESOURCES

OPTIONS LAN

注意:	アプリケーション・サービス・バージョニングが無効化されると、*RESOURCEおよび*GROUPセクション内でアプリケーション・サービス・バージョニング関連属性を構成できません。

MIBによるアプリケーション・サービス・バージョニングの有効化/無効化

MIBでアプリケーション・サービス・バージョニングを有効化するには、APPVERオプションをT_DOMAINクラス内のTA_OPTIONSに追加します。

例:

SRVCNM .TMIB

TA_OPERATION SET

TA_CLASS T_DOMAIN

TA_OPTIONS APPVER,LAN

MIBでアプリケーション・サービス・バージョニングを無効化するには、APPVERオプションをT_DOMAINクラス内のTA_OPTIONSから削除します。

例:

SRVCNM .TMIB

TA_OPERATION SET

TA_CLASS T_DOMAIN

TA_OPTIONS LAN

注意:	アプリケーション・サービス・バージョニングを無効化する前に、MIBで構成済のアプリケーション・サービス・バージョニング関連オプションを削除する必要があります。詳細は、「MIBによるユーザー構成サービス・バージョン情報のリセット」を参照してください。

アプリケーション・サービス・バージョンの構成

UBB構成ファイルの構成

REQUEST_VERSION、VERSION_POLICYおよびVERSION_RANGEという3つの属性は、構成済のTuxedo管理エンティティでバージョンおよび許容されるバージョンの範囲を指定するために構成ファイルで使用されます。これらの3つの属性は、リスト17-1に示すように、UBB構成ファイルの*GROUPSおよび*RESOURCESセクションで構成できます

詳細は、『Oracle Tuxedoリファレンス・ガイド』のセクション5 - ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンスに関する項のUBBCONFIG(5)を参照してください。

リスト17-1 UBB構成ファイルのアプリケーション・サービス・バージョン構成

*RESOURCES
DOMAINID LOCALDOM
OPTIONS LAN,APPVER
REQUEST_VERSION 1 VERSION_RANGE "1-2"
*GROUPS
GRP1 GRPNO=1 REQUEST_VERSION=2
VERSION_POLICY="PROPAGATE"
GRP2 GRPNO=2 VERSION_RANGE="3-4"
GRP3 GRPNO=3 REQUEST_VERSION=3 VERSION_RANGE="1-3"
DMGRP GRPNO=4 LMID=SITE1
GWGRP GRPNO=5 LMID=SITE1
WSGRP GRPNO=6 LMID=SITE1 REQUEST_VERSION=4
JGRP GRPNO=7 LMID=SITE1 REQUEST_VERSION=3
*SERVERS
SERVER1 SVRGRP=GRP1
SERVER2 SVRGRP=GRP2
SERVER3 SVRGRP=GRP3
DMADM SRVGRP=DMGRP
GWADM SRVGRP=GWGRP
GWTDOMAIN SRVGRP=GWGRP
WSL SRVGRP=WSGRP
JSL SRVGRP=JGRP

 

リスト17-1を例にすると、アプリケーション・サービス・バージョンには次のルールがあります。

•	サーバーは、REQUEST_VERSION属性が属するグループからその属性を継承します。サーバーがサービスを通知すると、サービスはサーバーが属するグループからバージョン属性を継承します。グループにバージョン属性値が指定されていない場合、*RESOURCESセクションで指定された属性から上位が継承されます。このルールに基づき、

•	server1がSVC2およびSVC3を通知する場合、SVC2およびSVC3のREQUEST_VERSION、VERSION_RANGEおよびVERSION_POLICYはそれぞれ2、"1-2"およびPROPAGATEです。

•	server2がSVC1、SVC2およびSVC3を通知する場合、SVC1、SVC2およびSVC3のREQUEST_VERSION、VERSION_RANGEおよびVERSION_POLICYはそれぞれ1、"3-4"およびnon-PROPAGATEです。

•	server3がSVC1およびSVC2を通知する場合、SVC1およびSVC2のREQUEST_VERSION、VERSION_RANGEおよびVERSION_POLICYはそれぞれ3、"1-3"およびnon-PROPAGATEです。

•	グループ名を指定せずにネイティブ・クライアントがアプリケーションに参加する場合、そのREQUEST_VERSIONは1です。

•	GRP3などのグループ名を指定してネイティブ・クライアントがアプリケーションに参加する場合、そのREQUEST_VERSIONは3です。

•	/WSクライアントがアプリケーションに参加する場合、そのREQUEST_VERSIONはWSLによって決定され、REQUEST_VERSIONはUBB構成ファイルに従い4です。つまり、/WSクライアントのREQUEST_VERSIONは4になります。

•	JOLTクライアントがアプリケーションに参加する場合、そのREQUEST_VERSIONはJSLによって決定され、REQUEST_VERSIONはUBB構成ファイルに従い3です。つまり、JOLTクライアントのREQUEST_VERSIONは3になります。

ドメイン構成ファイルの構成

リスト17-2に、ドメイン構成ファイルのアプリケーション・サービス・バージョン構成の例を示します。

リスト17-2 ドメイン構成ファイルのアプリケーション・サービス・バージョン構成

*DM_LOCAL
LOCALDOM TYPE=TDOMAIN
DOMAINID="LOCALDOM"
*DM_REMOTE
REMOTEDOM1 TYPE=TDOMAIN
DOMAINID= "DOM1" MTYPE="Linux"
REMOTEDOM2 TYPE=TDOMAIN
DOMAINID= "DOM2" MTYPE="Linux"
REQUEST_VERSION=4
*DM_IMPORT
R_SVC1 RDOM= REMOTEDOM1 VERSION_RANGE="1-3"
R_SVC2 RDOM= REMOTEDOM2 VERSION_RANGE="4-6"
R_SVC3 RDOM= REMOTEDOM2

 

リスト17-2では、アプリケーション・サービス・バージョンは次のとおりに構成されます。

•	REQUEST_VERSIONは、REMOTEDOM1に対しては構成されません。そのため、ドメイン・ゲートウェイは、受信リクエスト・バージョンを変更せずにREMOTEDOM1から受信するすべてのリクエストのリクエスト・バージョンを伝播します。

•	REMOTEDOM2のREQUEST_VERSIONは、4に対して構成されます。そのため、ドメイン・ゲートウェイは、REMOTEDOM2から受信するすべてのリクエスト・バージョンを4に変更します。

•	LOCALDOMは、R_SVC1サービスをREMOTEDOM1からインポートし、VERSION_RANGEを"1-3"に指定します。そのため、LOCALDOMのR_SVC1サービスのVERSION_RANGEは「1-3」です。

•	LOCALDOMは、R_SVC2サービスをREMOTEDOM2からインポートし、VERSION_RANGEを"4-6"に指定します。そのため、LOCALDOMのR_SVC2サービスのVERSION_RANGEは「4-6」です。

•	VERSION_RANGEを指定せずに、LOCALDOMはR_SVC3サービスをインポートします。インポートしたサービスのVERSION_RANGEを決定するのは、依然として*GROUPSおよび*RESOURCESのVERSION_RANGE構成であるため、*RESOURCESのVERSION_RANGEは「1-2」、R_SVC3のVERSION_RANGEは「1-2」です。

詳細は、「UBB構成ファイルの構成」を参照してください。

バージョン・ベース・ルーティング

アプリケーション・サービス・バージョニング機能を有効化すると、システムによってサービス名とサービス・バージョン範囲の両方に従ってリクエストがサービスに送信されます。このメカニズムのことを、バージョン・ベース・ルーティング(VBR)と呼びます。リクエストしたサービス名に一致するサービス・エントリが検出されると、VBRがその後の決定に使用されます。

VBRは、バージョン範囲の2つのバージョン値を持つ現在のリクエスト・バージョン番号を使用したシンプルな数値比較のみを実行します。一致する名前を持つすべてのサービスが当該バージョンのリクエストに許容されない場合、VBRは送信元に「エントリが見つかりません」というエラーを返します。

ルーティング・メカニズムとしてのVBRの機能は、DDR(データ依存ルーティング)、TAR(トランザクション・アフィニティ・ルーティング)、およびRAR(リクエスト・アフィニティ・ルーティング)などの既存ルーティング・メカニズムと同じです。

VBRは他のルーティング・メカニズムと連携できます。複数のルーティング・メカニズムが存在する場合、Oracle Tuxedoによってすべての条件を満たすサービスが選択されます。複数のルーティング・メカニズムを使用する前にその相互運用性について理解しておくことをお薦めします。

リスト17-1を例として使用します。

•	初期化期間中にserver3がSVC2を呼び出すと仮定すると、サービス候補は次のようになります。

Server1:SVC2 1-2

Server2:SVC2 3-4

リスト17-1で構成されたserver3のREQUEST_VERSIONは3であるため、server3はServer2:SVC2を呼び出します。

•	ネイティブ・クライアントがSVC3を呼び出す必要があると仮定すると、サービス候補は次のようになります。

Server1:SVC3 1-2

Server2:SVC3 3-4

リスト17-1で構成されたネイティブ・クライアントのREQUEST_VERSIONは1であるため、ネイティブ・クライアントはServer1:SVC3を呼び出します

•	ネイティブ・クライアントがServer1:SVC1を呼び出し、かつServer1:SVC1がSVC3を呼び出す必要があると仮定すると、サービス候補は次のようになります。

Server2:SVC3 3-4

Server3:SVC3 1-3

リスト17-1で構成されているように、Server1:SVC1は受信REQUEST_VERSION (1)を伝播し、その結果、Server1:SVC1のREQUEST_VERSIONは1になり、独自のREQUEST_VERSIONは2になるため、Server1:SVC1はServer3:SVC3を呼び出します

•	リクエストがREMOTEDOM2から送信される場合、元のREQUEST_VERSIONが6と仮定すると、受信リクエストのREQUEST_VERSIONは4に変更されます。

•	リクエストがREMOTEDOM1から送信される場合、元のREQUEST_VERSIONが2であると仮定すると、受信リクエストのREQUEST_VERSIONはやはり2です。

MIBによるユーザー構成サービス・バージョン情報のリセット

UBB構成ファイルの*GROUPSまたは*RESOURCESセクションでREQUEST_VERSION、VERSION_RANGEおよびVERSION_POLICYを構成できます。低レベルの構成は高レベルの構成より優先されます。

ユーザー構成サービス・バージョンの構成がどのレベルにもない場合、システムではデフォルト値が使用されます。その結果、ユーザーが構成した構成とデフォルト値がかなり異なることになります。MIBを使用してREQUEST_VERSION、VERSION_RANGEまたはVERSION_POLICYを変更する場合、ユーザー構成サービス・バージョンの構成になります。MIBを使用してこの変更内容をデフォルト値にリセットする方法を提供することが必要になります。そうしないと、MIB操作でUBB構成ファイルを元の状態に戻すことができません。

REQUEST_VERSION、VERSION_RANGEおよびVERSION_POLICYをデフォルト値にリセットする場合は、値をDEFAULTに設定するだけです。

たとえば、リスト17-3で示されるようにMIBでREQUEST_VERSIONを変更します。

リスト17-3 MIBによるユーザー構成サービス・バージョン情報のリセット

SRVCNM .TMIB
TA_OPERATION SET
TA_CLASS T_GROUP
TA_SRVGRP APPGRP1
TA_GRPNO 1
TA_CURLMID SITE1
TA_REQUEST_VERSION 4
次に、ユーザーはMIBを使用してREQUEST_VERSIONをデフォルト値にリセットします。
SRVCNM .TMIB
TA_OPERATION SET
TA_CLASS T_GROUP
TA_SRVGRP APPGRP1
TA_GRPNO 1
TA_CURLMID SITE1
TA_REQUEST_VERSION DEFAULT

 

相互運用性

次に示すように、ドメイン構成ファイルを使用して、JCA/WTC/旧Tuxedoドメインと新しいTuxedoドメインの相互運用性を制御できます。

•	DM_REMOTEセクションでREQUEST_VERSION属性およびVERSION_POLICY属性を設定することにより、JCA/WTC/旧Tuxedoドメインからのリクエストを制御します

•	DM_IMPORTセクションでVERSION_RANGEを設定することにより、JCA/WTC/旧Tuxedoドメインへのリクエストを制御します。

古いTuxedoドメインから送られてくるリクエストが、対応するリモート・ドメイン用のREQUEST_VERSIONが構成されていないTuxedo 12cドメインに届いた場合、リクエスト・バージョンは0に変更されます。

デフォルトのリクエスト・バージョンは0-65535です。これは、新しいドメインが、JCA/WTC/旧Tuxedoドメインからインポートされたすべてのサービスを、デフォルトでコールできることを意味します。

MP環境で、旧バージョンのTuxedoがインストールされているマシンでローカル・クライアントが実行される場合、旧バージョンのTuxedoにはバージョン・コントロールがないため、クライアントはどのバージョンのサービスもコールできます。

同様に、旧バージョンのWSLサーバーまたはJSLサーバーに接続している/WSクライアントまたはJoltクライアントの場合も、これらのバージョン・コントロールはありません。