1. アプリケーション構成ガイド
  2. サービス・バージョンのTuxedoアプリケーションへの適用

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

この項の内容は次のとおりです。

17.1 概要

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

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

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

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

親トピック: サービス・バージョンのTuxedoアプリケーションへの適用

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

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

親トピック: サービス・バージョンのTuxedoアプリケーションへの適用

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

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

例:

*RESOURCES
OPTIONS         APPVER, LAN

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

例:

*RESOURCES
OPTIONS         LAN

ノート:

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

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

17.2.2 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によるユーザー構成サービス・バージョン情報のリセット』を参照してください。

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

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

親トピック: サービス・バージョンのTuxedoアプリケーションへの適用

17.3.1 UBB構成ファイルの構成

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

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

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

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

  • サーバーは、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.3.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

次のリストでは、アプリケーション・サービス・バージョンは次のように構成されます:

  • 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構成ファイルの構成」を参照してください。

親トピック: アプリケーション・サービス・バージョンの構成

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

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

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

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

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

次のリストを使用して説明します:

  • 初期化期間中にserver3がSVC2を呼び出すと仮定すると、サービス候補は次のようになります。 
    Server1:SVC2 1-2
Server2:SVC2 3-4
    次のリストで構成されたserver3のREQUEST_VERSIONは3であるため、server3はServer2:SVC2を呼び出します。
  • ネイティブ・クライアントがSVC3を呼び出す必要があると仮定すると、サービス候補は次のようになります。 
    Server1:SVC3 1-2
Server2:SVC3 3-4
    次のリストで構成されたネイティブ・クライアントのREQUEST_VERSIONは1であるため、ネイティブ・クライアントはServer1:SVC3を呼び出します
  • 次のリストで構成されたネイティブ・クライアントのREQUEST_VERSIONは1であるため、ネイティブ・クライアントはServer1:SVC3を呼び出します
  • ネイティブ・クライアントがServer1:SVC1を呼び出し、かつServer1:SVC1がSVC3を呼び出す必要があると仮定すると、サービス候補は次のようになります。 
    Server2:SVC3 3-4
Server3:SVC3 1-3
    次のリストで構成されているように、Server1:SVC1は1の受信REQUEST_VERSIONを伝播し、その結果、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です。

親トピック: サービス・バージョンのTuxedoアプリケーションへの適用

17.5 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に設定することのみです。

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

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

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

親トピック: サービス・バージョンのTuxedoアプリケーションへの適用

17.6 相互運用性

次に示すように、ドメイン構成ファイルを使用して、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クライアントの場合も、これらのバージョン・コントロールはありません。

親トピック: サービス・バージョンのTuxedoアプリケーションへの適用