|
|
ユーザーが、既存の機能を維持するとともに、時間の経過に伴って新しい機能をサービスに追加したいと考えるのはよくあることです。互換性のリスクをなくすためには、2種類のバージョン・サービスに同じサービス名(1つは旧機能用、もう1つは新機能用)を付与することをお薦めします。新クライアントでは新機能を使用できますが、旧クライアントではコードを変更せずに既存の機能をそのまま使用できます。
アプリケーション・サービス・バージョニング機能では、各段階でご使用のTuxedoアプリケーションを計画、開発、テスト、拡張およびデプロイできる構成ドリブンの方法が提供されています。ユーザーは、様々な特別ビジネス・アクセス・ロジックに対応し、その一方でノンストップ・モードでアップグレード用件を満たすため、バージョンを使用して現在のTuxedoアプリケーションを現在のTuxedo管理階層上で別々の仮想アプリケーション・ドメイン、別々の仮想マシンおよび別々の仮想サーバー・グループにパーティション化できます。
この機能は、COBOLアプリケーションおよびプログラミング環境をサポートしており、COBOL環境を特別に変更する必要はありません。
この機能は、/Qに対してのみFORWARDキューをサポートしています。アプリケーション・サービス・バージョニングが有効な場合、クライアントがFORWARDキューにメッセージを入れると、FORWARDキューは、キューに入れられたメッセージを、クライアントのリクエスト・バージョンをサポートするサービスに転送します。
UBB構成ファイルやMIBを使用すると、アプリケーション・サービス・バージョニング機能を有効化/無効化できます。
UBB構成ファイルでアプリケーション・サービス・バージョニングを有効化するには、APPVERオプションを*RESOURCESセクション内のOPTIONSパラメータに追加します。
*RESOURCES
OPTIONS APPVER, LAN
UBB構成ファイルでアプリケーション・サービス・バージョンを無効化するには、APPVERオプションを*RESOURCESセクション内のOPTIONSパラメータから削除します。
*RESOURCES
OPTIONS LAN
| 注: | アプリケーション・サービス・バージョニングが無効化されると、*RESOURCEおよび*GROUPセクション内でアプリケーション・サービス・バージョニング関連属性を構成できません。 |
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から削除します。
TA_OPERATION SET
TA_CLASS T_DOMAIN
TA_OPTIONS LAN
| 注: | アプリケーション・サービス・バージョニングを無効化する前に、MIBで構成済のアプリケーション・サービス・バージョニング関連オプションを削除する必要があります。詳細は、『MIBによるユーザー構成サービス・バージョン情報のリセット』を参照してください。 |
REQUEST_VERSION、VERSION_POLICYおよびVERSION_RANGEという3つの属性は、構成済のTuxedo管理エンティティでバージョンおよび受入可能なバージョン範囲を指定するために構成ファイルで使用されます。これらの3つの属性は、リスト16-1に示すように、UBB構成ファイルの*GROUPSおよび*RESOURCESセクションで構成できます。
詳細は、『Oracle Tuxedoリファレンス・ガイド』のセクション5「ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス」のUBBCONFIG(5)を参照してください。
*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
リスト16-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です。 REQUEST_VERSIONはWSLによって決定され、REQUEST_VERSIONはUBB構成ファイルに従い4です。つまり、/WSクライアントのREQUEST_VERSIONは4になります。REQUEST_VERSIONはJSLによって決定され、REQUEST_VERSIONはUBB構成ファイルに従い3です。つまり、JOLTクライアントのREQUEST_VERSIONは3になります。リスト16-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
リスト16-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によってすべての条件を満たすサービスが選択されます。複数のルーティング・メカニズムを使用する前にその相互運用性について理解しておくことをお薦めします。
リスト16-1を例として使用します。
server3がSVC2を呼び出すと仮定すると、サービス候補は次のようになります。 リスト16-1で構成されたserver3のREQUEST_VERSIONは3であるため、server3はServer2:SVC2を呼び出します。
SVC3を呼び出す必要があると仮定すると、サービス候補は次のようになります。 リスト16-1で構成されたネイティブ・クライアントのREQUEST_VERSIONは1であるため、ネイティブ・クライアントはServer1:SVC3を呼び出します。
Server1:SVC1を呼び出し、かつServer1:SVC1がSVC3を呼び出す必要があると仮定すると、サービス候補は次のようになります。 リスト16-1で構成されているように、Server1:SVC1は受信REQUEST_VERSION (1)を伝達し、その結果、Server1:SVC1のREQUEST_VERSIONは、独自のREQUEST_VERSIONである2から1になるため、Server1:SVC1はServer3:SVC3を呼び出します。
REMOTEDOM2から送信される場合、元のREQUEST_VERSIONが6と仮定すると、受信リクエストのREQUEST_VERSION は4に変更されます。REMOTEDOM1から送信される場合、元のREQUEST_VERSIONが2であると仮定すると、受信リクエストのREQUEST_VERSIONはやはり2です。
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に設定することのみです。
たとえば、リスト16-3で示されるようにMIBでREQUEST_VERSIONを変更します。
SRVCNM .TMIB
TA_OPERATION SET
TA_CLASS T_GROUP
TA_SRVGRP APPGRP1
TA_GRPNO 1
TA_CURLMID SITE1
TA_REQUEST_VERSION 4
Then the user reset the REQUEST_VERSION to default value through MIB:
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ドメインの相互運用性を制御できます。
古いTuxedoドメインから送られてくるリクエストが、対応するリモート・ドメイン用のREQUEST_VERSIONが構成されていないTuxedo 12cドメインに届いた場合、リクエスト・バージョンは0に変更されます。
デフォルトのリクエスト・バージョンは0-65535です。これは、新しいドメインが、JCA/WTC/旧Tuxedoドメインからインポートされたすべてのサービスを、デフォルトでコールできることを意味します。
MP環境で、旧バージョンのTuxedoがインストールされているマシンでローカル・クライアントが実行される場合、旧バージョンのTuxedoにはバージョン・コントロールがないため、クライアントはどのバージョンのサービスもコールできます。
同様に、旧バージョンのWSLサーバーまたはJSLサーバーに接続している/WSクライアントまたはJoltクライアントの場合も、これらのバージョン・コントロールはありません。
  
|