Oracle Tuxedoアプリケーションの設定

Oracle Tuxedo CORBAリモート・クライアント・アプリケーションの管理

この章では、標準のインターネットORB間プロトコル(IIOP : Internet Inter-ORB Protocol)を使用してOracle Tuxedo CORBAのリモート・クライアント・アプリケーションからCORBAオブジェクトへの接続を構成する方法について説明します。この章は、Oracle Tuxedo CORBAサーバーにのみ適用されます。

このトピックには次の項が含まれます:

CORBAオブジェクト関連の用語

以下は、この章で使用する用語のリストです。

DLL

IIOP

ISH

ISL

サーバー

ネイティブ・クライアント

リモート・クライアント

ネイティブ共同クライアント/サーバー

リモート共同クライアント/サーバー

Oracle Tuxedo CORBAオブジェクト

コールバック・オブジェクト

CORBAリモート・クライアントの概要

この項での「リモート・クライアント」は、Oracle Tuxedo CORBAサーバー・ソフトウェアがフル・インストールされていないシステムにデプロイされたCORBAクライアント・アプリケーションを意味します。つまり、管理サーバーやアプリケーション・サーバーが実行されず、掲示板もないことを意味します。クライアントとアプリケーション間の通信は、すべてネットワーク経由で行われます。

クライアントのタイプは以下のとおりです。

クライアント・プロセスは、UNIXまたはMicrosoft Windows上で実行できます。また、クライアントはCORBA ORBインタフェースにアクセスすることができます。ユーザーは、呼出しが背後のネットワークでどのように処理されているかを意識する必要はありません。クライアント・プロセスはシステムに登録され、ネイティブ・クライアントと同じステータスになります。

クライアントには以下の特徴があります。

CORBAリモート・クライアントが接続されたアプリケーションの例

図15-1は、リモート・クライアントが接続されたアプリケーションの例です。リモート・クライアントからCORBAサーバー・アプリケーションへのアクセス・リクエストは、ネットワーク経由でISHに送信されます。このプロセスがアプリケーション・サーバーにリクエストを送信し、その応答をリモート・クライアントに返します。

リモート・クライアントからアプリケーションへの接続方法

クライアントは、既知のネットワーク・アドレスを使用してIIOPリスナー/ハンドラでISLプロセスに接続します。この接続は、クライアントがBootstrapオブジェクトのコンストラクタを呼び出すと開始されます。ISLプロセスは、オペレーティング・システム固有の機能を使用して、選択されたISHプロセスに直接接続を渡します。クライアント・アプリケーション側から見ると、接続は1つだけです。クライアント・アプリケーションは、現在ISHプロセスに接続されていることを認識せず、また、認識する必要もありません。

CORBAリモート・クライアントの環境変数を設定する

CORBA C++クライアントでは、以下に示す環境変数を使用してシステムに情報を渡すことができます。

CORBAリモート・クライアントの最大数を設定する

アプリケーションにリモート・クライアントを参加させるには、UBBCONFIGファイルのMACHINESセクションでMAXWSCLIENTSパラメータを指定する必要があります。

MAXWSCLIENTSは、リモート・クライアント専用として予約するアクセサ・スロットの数を、起動時にOracle Tuxedoシステムに知らせます。ネイティブ・クライアントの場合、各アクセサ・スロットに必要なセマフォは1つです。一方、ISHプロセス(リモート・クライアントのかわりにネイティブ・プラットフォーム上で実行するプロセス)は、リモート・クライアントのアクセスを単一のアクセサ・スロットに多重化するので、必要なセマフォは1つだけです。この点も、リモート機能の別の利点の1つです。多くのクライアントをネイティブ・プラットフォームからリモート・システムに移動することによって、アプリケーションで使用するIPCリソースを減らすことができます。

MAXWSCLIENTSは、MAXACCESSERSに指定された数のうち、指定された数のアクセサ・スロットを使用します。MAXWSCLIENTSの設定時には、ネイティブ・クライアントとサーバーを収容するために必要な数のスロットを残しておく必要があります。MAXWSCLIENTSにMAXACCESSERSより大きい値を指定しないでください。次の表は、MAXWSCLIENTSパラメータの説明です。

CORBAリモート・クライアントのリスナーを構成する

リモート・クライアントは、1つのISLプロセスと、1つ以上のISHプロセスのサービスを介してアプリケーションにアクセスします。ISLは、Oracle Tuxedoシステム側で提供されるサーバーとして、1つのエントリで指定されます。ISLは複数のリモート・クライアントを扱うことができます。これらのリモート・クライアントは、唯一の通信ポイントであるISLを経由して特定のネットワーク・アドレス(ISLコマンド行で指定)のアプリケーションに接続します。リスナーは、1つまたは複数のリモート・ハンドラ・プロセスをスケジューリングします。ISHプロセスは、アプリケーションの管理ドメインで、リモート・システム上のリモート・クライアントの代理として機能します。ISHは多重化スキームによって、複数のリモート・クライアントを同時にサポートします。

リモート・クライアントをアプリケーションに参加させるには、UBBCONFIGファイルのSERVERSセクションでISLプロセスを示す必要があります。この場合、サーバーのリストと同じ構文を使用します。

CLOPTパラメータの形式

以下のISLコマンド行オプション(CLOPT)を使用して、リモート・クライアントのISLプロセスに情報を渡します。CLOPTパラメータの形式は、次のとおりです。

ISL SRVGRP=”identifier”
    SRVID="number"
    CLOPT="[ -A ] [ servopts options  ] -- -n netaddr 
    [ -C {detect|warn|none} ]
    [ -d device ]
    [ -K {client|handler|both|none} ]
    [ -m minh ]
    [ -M maxh ]
    [ -T client-timeout]
    [ -x mpx-factor ] 
    [ -H external-netaddr"

For a detailed description of the CLOPT command line options, see the ISL command in the Oracle Tuxedo Command Reference.

CORBAリモート・クライアントをサポートするように構成ファイルを変更する

リスト15-1は、リモート・クライアントをサポートするUBBCONFIGファイルの例です。以下の特徴があります。

リモート共同クライアント/サーバーのアウトバウンドIIOPを構成する

アウトバウンドIIOPのサポートにより、ネイティブ・クライアントと、ネイティブ・クライアントとして機能するサーバーは、Oracle Tuxedoドメイン外のリモート・オブジェクト参照を呼び出すことができます。つまり、コールバックに登録されているリモート・クライアントを呼び出して、リモート・サーバー内のオブジェクトにアクセスすることができます。

アウトバウンドIIOPサポート・コンポーネントと直接通信できるのは管理者だけです。管理者は、適切な起動パラメータを使用してISLを起動し、接続が確立されていないクライアントのオブジェクトに対して、アウトバウンドIIOPを実行できるようにします。また、管理者は、起動するISLの数や各種起動パラメータを調整し、システムの負荷状況に応じた最適な構成を行う必要もあります。

デフォルトのパラメータを使用してISLを起動することも可能です。ただし、Oracle Tuxedo ISLのデフォルトの起動パラメータでは、IIOPのアウトバウンドを有効にできません。

機能説明

アウトバウンドIIOPサポートは、クライアントのコールバックをサポートするために必要です。Oracle WebLogic Enterprise バージョン4.0および4.1では、ISL/ISHがインバウンド・ハーフ・ゲートウェイでした。アウトバウンドIIOPサポートによって、アウトバウンド・ハーフ・ゲートウェイがISL/ISHに追加されます。(図15-2を参照してください。)

ネイティブ・サーバーおよびリモート共同クライアント/サーバー・アプリケーションでサポートされるGIOPのバージョンによって、以下に示す3種類のアウトバウンドIIOP接続を使用できます。

双方向およびデュアル・ペア接続のアウトバウンドIIOPでは、ISHに接続された共同クライアント/サーバーに存在するオブジェクト参照へのアウトバウンドIIOP接続が可能です。非対称のアウトバウンドIIOPでは、ISHに接続された共同クライアント/サーバーに存在しないオブジェクト参照へのアウトバウンドIIOP接続が可能です。また、現在ISHに接続されているクライアント上のオブジェクト参照だけでなく、任意のオブジェクト参照をOracle Tuxedo CORBAクライアントによって呼び出すことができます。

以下の項では、それぞれのアウトバウンドIIOPについて詳しく説明します。

双方向のアウトバウンドIIOP

双方向のアウトバウンドIIOPでは、以下の操作が実行されます(図15-3を参照)。

非対称のアウトバウンドIIOP

非対称のアウトバウンドIIOPでは、以下の操作が実行されます(図15-4を参照)。

デュアル・ペア接続によるアウトバウンドIIOP

デュアル・ペア接続によるアウトバウンドIIOPでは、以下の操作が実行されます(図15-5を参照)。

ルーティング・コードによるISLの検出

ISLの検出手順は以下のとおりです。

ISLコマンドを使用してアウトバウンドIIOPのサポートを構成する

ネイティブなC++またはJavaクライアント、ネイティブ・クライアントとして動作するサーバーからリモート・オブジェクト参照を呼び出す場合は、アウトバウンドIIOPサポートを使用します。ルーティング・コードでは、オブジェクト参照のソースがOracle Tuxedo CORBA ORB以外、またはリモートのOracle Tuxedo CORBA共同クライアント/サーバーであることが認識されます。

オブジェクト参照の種類

リモート・オブジェクト参照には、次の2つの種類があります。

どちらのオブジェクト参照も、ルーティング・コードで検出され、アウトバウンドIIOPサポートに送信された後、処理されます。

ユーザー・インタフェース

アウトバウンドIIOPサポートのユーザー・インタフェースは、コマンド行インタフェースであり、これを使用してISLプロセスを起動します。Oracle Tuxedoソフトウェアの今回のリリースでは、アウトバウンドIIOP処理を構成するための新しいコマンド行オプションが追加されています。これらのオプションを使用すると、ISHに接続されていないクライアントに存在するオブジェクト参照への非対称のIIOP接続がサポートされます。

以下のISLコマンド構文は、アウトバウンドIIOPをサポートする新しいオプションを示しています。

ISL SRVGRP="identifier"

SRVID="number"

CLOPT="[ -A ] [ servopts options ] -- -n netaddr
[ -C {detect|warn|none} ]
[ -d device ]
[ -K {client|handler|both|none} ]
[ -m minh ]
[ -M maxh ]
[ -T Client-timeout]
[ -x mpx-factor ]
[-H external-netaddr]
#NEW options for outbound IIOP
[-O]
[-o outbound-max-connections]
[-s Server-timeout]
[-u out-mpx-users] "

CLOPTコマンド行オプションの詳細は、『Oracle Tuxedoコマンド・リファレンス』のISLコマンドを参照してください。

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

概要

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

アプリケーション・サービス・バージョン機能では、各段階でお使いのTuxedoアプリケーションを計画、開発、テスト、拡張およびデプロイできる構成ドリブンの方法が提供されています。ユーザーは、バージョンを使用して現在のTuxedoアプリケーションを現在のTuxedo管理階層上で別々の仮想アプリケーション・ドメイン、別々の仮想マシンおよび別々の仮想サーバー・グループにパーティション化できます。これによって柔軟な方法を利用できるため、定義したバージョンに従って顧客はアプリケーション・ゾーンを設定し(この観点から、バージョンには論理パーティションIDという新しい意味が与えられます)、すべての種類の特別なビジネス・アクセスに対応できるようになります。また一方では、顧客はバージョンを使用してノンストップ・モードにおける一部のアップグレード要件を解決し、エンド・ユーザー向けにサービス・ビジネス・ロジックをシームレスに変更できます。

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

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

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

アプリケーション・サービス・バージョンを有効化するには、APPVERオプションを*RESOURCESセクション内のOPTIONSパラメータに追加します。例:

*RESOURCES

OPTIONS		APPVER, LAN

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

*RESOURCES

OPTIONS		LAN

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

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

構成済のTuxedo管理エンティティにおけるバージョンおよび許容可能バージョン範囲を指定するため、3つの属性(REQUEST_VERSION、VERSION_POLICYおよびVERSION_RANGE)が構成ファイル内で使用されます。これらの3つの属性は、リスト15-2に示すように、UBB構成ファイルの*GROUPおよび*RESOUCEセクションで構成できます。

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

*RESOUCE
DOMAINID LOCALDOM
OPTIONS	  LAN,APPVER
REQUEST_VERSION 1 	VERSION_RANGE  "1-2"
*GROUP
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
*SERVER
SERVER1 SVRGRP=GRP1
SERVER2 SVRGRP=GRP2
SERVER3 SVRGRP=GRP3
DMADM  SRVGRP=DMGRP
GWADM  SRVGRP=GWGRP
GWTDOMAIN SRVGRP=GWGRP
WSL SRVGRP=WSGRP
JSL SRVGRP=JGRP

server1は、SVC2およびSVC3を通知します。server1はGRP1に属するため、server1、SVC2、SVC3のREQUEST_VERSIONはGRP1から継承されます。GRP1の構成済REQUEST_VERSIONは2であるため、server1、SVC2、SVC3のREQUEST_VERSIONも2です。

SVC2、SVC3のVERSION_RANGE、VERSION_POLICYはGRP1から継承されます。GRP1には構成済のVERSION_RANGEがないため、*RESOURCEセクションから継承され、「1-2」となります。

SVC2、SVC3のVERSION_POLICYはGRP1から継承されます。GRP1の構成済VERSION_POLICYはPROPAGATEであるため、SVC2、SVC3のVERSION_POLICYもPROPAGATEです。

server2は、SVC1、SVC2およびSVC3を通知します。server1で説明したものと同じルールに従い、server2、SVC1、SVC2、SVC3のREQUEST_VERSIONは1、SVC1、SVC2、SVC3のVERSION_RANGEは「3-4」、SVC1、SVC2、SVC3のVERSION_POLICYはnon-PROPAGATEになります。

server3は、SVC1、SVC2を通知します。server1で説明したものと同じルールに従い、server3、SVC1、SVC2のREQUEST_VERSIONは3、SVC1、SVC2のVERSION_RANGEは「1-3」、SVC1、SVC2のVERSION_POLICYは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です。つまり、/WSクライアントのREQUEST_VERSIONは4になります。

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

リスト15-3は、ドメイン構成ファイルのアプリケーション・サービス構成の例を示します。

*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

REMOTEDOM1にはREQUEST_VERSIONが構成されていないため、ドメイン・ゲートウェイによって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を決定するのは、依然として*GROUPおよび*RESOURCEのVERSION_RANGE構成であるため、*RESOUCEのVERSION_RANGEは「1-2」、R_SVC3のVERSION_RANGEは「1-2」です。

詳細は、UBB構成ファイルのアプリケーション・サービス・バージョンの構成に関する項を参照してください。

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

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

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

Tuxedoには、DDR(データ依存ルーティング)、TAR(トランザクション・アフィニティ・ルーティング)およびRAR(リクエスト・アフィニティ・ルーティング)などのいくつかのルーティング・メカニズムが既に提供されています。VBR(バージョン・ベース・ルーティング)は、これら既存のルーティング・アルゴリズムと同じ機能も持つ新しいルーティング・メカニズムです。

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

上のセクションで説明した構成であると仮定します。

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

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

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

REQUEST_VERSION、VERSION_RANGEおよびVERSION_POLICYをデフォルト値にリセットする場合、必要になるのは値をDEFAULTに設定することのみです。

たとえば、リスト15-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      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