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

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

注意:	Oracle Tuxedo CORBA JavaクライアントとOracle Tuxedo CORBA JavaクライアントORBはTuxedo 8.1で非推奨になり、Tuxedo 9.xではサポートされなくなりました。 Oracle Tuxedo CORBA JavaクライアントとOracle Tuxedo CORBA JavaクライアントORBのすべてのテキスト・リファレンスや関連するサンプル・コードは、以下の場合にのみ使用してください。

•	サード・パーティのJava ORBライブラリの実装や実行に役立てる場合

•	プログラマが参照する場合

サード・パーティのCORBA Java ORBのテクニカル・サポートは、各ベンダーによって提供されます。Oracle Tuxedoでは、サード・パーティのCORBA Java ORBに関するテクニカル・サポートやマニュアルは提供していません。

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

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

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

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

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

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

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

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

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

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

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

DLL

ダイナミック・リンク・ライブラリ。ロード・モジュールにグループ化された関数の集合。Windowsアプリケーションでは、実行時に実行可能プログラムに動的にリンクされます。

IIOP

インターネットORB間プロトコル(IIOP)。TCP/IP準拠の通信プロトコルで、共通のバックボーン・プロトコルとしてCORBA定義のメッセージ送受信をサポートします。

ISH

IIOPサーバー・ハンドラ。アプリケーション・サイト上で実行されるクライアント・プロセス。リモート・クライアントの代理として機能します。

ISL

IIOPサーバー・リスナー。アプリケーション・サイト上で実行されるサーバー・プロセス。リモート・クライアントの接続リクエストをリスニングします。

サーバー

<Default ? Font>Oracle Tuxedoドメインのマシンにホストされているサーバー。Oracle Tuxedo CORBAサーバーは、Oracle Tuxedo CORBAのbuildobjserverコマンドを使用して作成されます。CORBAサーバーは、セキュリティ、トランザクション、オブジェクトの状態管理など、<Default ?Font>Oracle Tuxedoの機能を実装します。サーバーは、<Default ?Font>Oracle Tuxedoドメイン内外の任意のサーバーを呼び出すことができます。

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

<Default ? Font>Oracle Tuxedoドメイン内に配置されたクライアント。CORBA ORBを使用して、<Default ? Font>Oracle Tuxedoドメイン内外のオブジェクトを呼び出します。ネイティブ・クライアントのホストには、<Default ? Font>Oracle Tuxedoの管理コンポーネントおよびインフラストラクチャ・コンポーネント(tmadmin、FactoryFinder、ISL/ISHなど)があります。ネイティブ・クライアントは、環境オブジェクトを使用してCORBAオブジェクトにアクセスします。ネイティブC++クライアントはbuildobjclientコマンドを使用して作成し、ネイティブJavaクライアントはサード・パーティORB提供のツールを使用して作成します。

リモート・クライアント

<Default ? Font>Oracle Tuxedoドメイン内に配置されていないクライアント。リモート・クライアントは、CORBA ORBを使用して、<Default ? Font>Oracle Tuxedoドメイン内外のオブジェクトを呼び出すことができます。リモート・クライアントのホストには、<Default ? Font>Oracle Tuxedoの管理コンポーネントおよびインフラストラクチャ・コンポーネント(tmadmin、FactoryFinder、ISL/ISHなど)はありませんが、リモート・クライアントがオブジェクトを呼び出すことができるサポート・ソフトウェア(CORBA ORB)があります。リモート・クライアントは、環境オブジェクトを使用してCORBAオブジェクトにアクセスします。リモートC++クライアントはbuildobjclientコマンドを使用して作成し、リモートJavaクライアントはサード・パーティORB提供のツールを使用して作成します。

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

次の2つの目的を持つプロセス。(1)一部のビジネス・アクションのスタータとして機能するコードを実行する。(2)オブジェクトを呼び出すためのメソッド・コードを実行する。<Default ? Font>Oracle Tuxedoドメイン内に配置された共同クライアント/サーバー。ネイティブ共同C++クライアント/サーバーは、buildobjclientコマンドを使用して作成します。Javaネイティブ共同クライアント/サーバーはサポートされていません。

注意:	ネイティブ共同クライアント/サーバーのサーバー・ロールは、通常のサーバーよりも堅牢性が大幅に低くなります。これには、Oracle Tuxedo CORBAの管理コンポーネントとインフラストラクチャ・コンポーネント(tmadmin、FactoryFinder、ISL/ISHなど)のいずれもなく(そのため、<Default ? Font>Oracle Tuxedoのスケーラビリティと信頼性に関するいずれの属性もありません)、<Default ? Font>Oracle Tuxedo TP Frameworkも使用しないため、クライアントとORBの間でより直接的な対話が必要になります。

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

次の2つの目的を持つプロセス。(1)一部のビジネス・アクションのスタータとして機能するコードを実行する。(2)オブジェクトを呼び出すためのメソッド・コードを実行する。<Default ? Font>Oracle Tuxedoドメイン外に配置された共同クライアント/サーバー。共同クライアント/サーバーは、<Default ? Font>Oracle Tuxedo TP Frameworkを使用しないため、クライアントとORBの間でより直接的な対話が必要です。リモート共同C++クライアント/サーバーは、buildobjclientコマンドを使用して作成し、リモートJavaクライアント/サーバーは、サード・パーティORB提供のツールを使用して作成します。

注意:	共同クライアント/サーバーは、そのサーバー・ロールの一部としてクライアントの役割を果すサーバーとは異なります。サーバーは呼出し処理を完了すると、休止状態に戻ります。共同クライアント/サーバーは常にアクティブ・モードで動作し、サーバー・ロールとは関連のないコードを実行します。そのため、サーバー・ロールによってアクティブなクライアント・ロールが一時的に中断されますが、クライアント・ロールは常に再開されます。

注意:	リモート共同クライアント/サーバーのサーバー・ロールは、通常のサーバーよりも堅牢性が大幅に低くなります。クライアントにもサーバーにも、<Default ? Font>Oracle Tuxedoの管理コンポーネントおよびインフラストラクチャ・コンポーネント(tmadmin、FactoryFinder、ISL/ISHなど)はありません(そのため、<Default ? Font>Oracle Tuxedoのスケーラビリティと信頼性に関するいずれの属性もありません)。

Oracle Tuxedo CORBAオブジェクト

TP Frameworkを使用して実装され、セキュリティ、トランザクションおよびオブジェクトの状態管理を実装するCORBAオブジェクト。CORBAオブジェクトは、Oracle Tuxedo CORBAサーバーに実装されます。つまり、これらは<Default ? Font>Oracle Tuxedoドメインの一部であり、<Default ? Font>Oracle Tuxedoインフラストラクチャを使用します。

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

クライアントによるターゲット・オブジェクトの呼出しで、パラメータとして指定されるCORBAオブジェクト。ターゲット・オブジェクトは、そのターゲット・オブジェクトの実行時、または後で(ターゲット・オブジェクトの呼出しが完了した後でも)コールバック・オブジェクトを呼び出すことができます。コールバック・オブジェクトは、<Default ? Font>Oracle Tuxedoドメイン内外に配置できます。

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

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

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

•	CORBA C++クライアント

クライアント・プロセスは、UNIXまたはMicrosoft Windowsで実行できます。このクライアントは、CORBA ORBインタフェースにアクセスできます。呼出しの背後のネットワークは、ユーザーに対して透過的に処理されます。クライアント・プロセスはシステムに登録され、ネイティブ・クライアントと同じステータスになります。

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

•	リモートCORBAオブジェクトでメソッドを呼び出します。

•	トランザクションの開始、ロールバック、またはコミットを行います。

•	アプリケーション・セキュリティにパスする必要があります。

注意:	クライアント・プロセスは、ISHを通してネイティブ・ドメインと通信します。

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

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

図16-1 リモート・クライアントが接続された銀行業務アプリケーション

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

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

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

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

•	TUXDIR - このリモート・クライアント上のOracle Tuxedo CORBAクライアント・ソフトウェアの場所。クライアントを接続するにはこの値が設定されていなければなりません。

•	TOBJADDR - クライアントがコンタクトするISLのネットワーク・アドレス。この値は、アプリケーションの構成ファイルで指定されたISLプロセスのアドレスと一致していなければなりません。

注意:

プログラマがBootstrapコンストラクタまたはTOBJADDRで指定するネットワーク・アドレスは、サーバー・アプリケーションのUBBCONFIGファイルのネットワーク・アドレスと完全に一致する必要があります。アドレスの形式や、大文字/小文字も一致する必要があります。これらのアドレスが一致しないと、Bootstrapコンストラクタの呼出しが失敗し、一見無関係と思われる次のエラー・メッセージが表示されます。 ERROR: Unofficial connection from client at <tcp/ip address>/<port-number>: たとえば、ISLコマンド行オプション文字列(サーバー・アプリケーションのUBBCONFIGファイル)で、ネットワーク・アドレスが//TRIXIE:3500;TLSv1.2に指定されている場合、BootstrapコンストラクタまたはTOBJADDRで//192.12.4.6:3500;TLSv1.2や//trixie:3500;TLSv1.2を指定すると、接続が失敗します。 UNIXシステムでは、ホスト・システムでuname -nコマンドを使用して大文字/小文字を判別します。Windowsシステムでは、ホスト・システムで「コントロール・パネル」の「ネットワーク」を使用して大文字/小文字を指定します。または、環境変数COMPUTERNAMEを使用します。次に例を示します。 echo %COMPUTERNAME%

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

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

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

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

 

パラメータ	説明
MAXWSCLIENTS	マシンに接続するリモート・クライアントの最大数を指定します。 デフォルトは0です。値を指定しないと、リモート・クライアントは、指定されたマシンに接続できません。 構文はMAXWSCLIENTS=numberです。

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

リモート・クライアントは、1つのISLプロセスおよび1つ以上のISHプロセスのサービスを介して、アプリケーションにアクセスします。ISLは、<Default ? Font>Oracle Tuxedoシステムによって提供されるサーバーとして、1つのエントリで指定されます。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"

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

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

リスト16-1に、リモート・クライアントをサポートするサンプルUBBCONFIGファイルを示します。次の特徴があります。

•	MACHINESセクションでは、2つのサイトでデフォルトのMAXWSCLIENTSがオーバーライドされています。SITE1ではデフォルト値が150に引き上げられ、SITE2では0に引き下げられています。値0の場合は、リモート・クライアントが接続されません。

•	SERVERSセクションには、BANKB1グループのISLプロセスが示されています。サーバーIDは500で、再起動可能と指定されています。

•	コマンド行オプションでは、以下の値が指定されています。

•	IIOPリスナー/ハンドラは、そのすべてのサービスを通知します(-A)。

•	IIOPリスナー/ハンドラは、ポート2500のホストTRIXIEでリスニングします。

•	ネットワーク・プロバイダは/dev/tcp (-d)です。

•	起動するISHプロセスの最小数は5です(-m)。

•	起動するISHプロセスの最大数は30です(-M)。

•	各ハンドラは同時に最大5つのクライアントを接続できます(-x)。

リスト16-1 サンプルUBBCONFIGファイルの構成

*MACHINES
SITE1
...
MAXWSCLIENTS=150
...
SITE2
...
MAXWSCLIENTS=0
...
*SERVERS
...
ISL SRVGRP=”BANKB1" SRVID=500 RESTART=Y
CLOPT=”-A -- -n //TRIXIE:2500 -d /dev/tcp
-m 5 -M 30 -x 5"
..

 

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

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

アウトバウンドIIOPサポート・コンポーネントと直接対話するユーザーは管理者のみです。管理者は、適切な起動パラメータを使用してISLを起動し、接続されているクライアントに存在しないオブジェクトへのアウトバウンドIIOPを有効にする必要があります。管理者は、起動するISLの数や様々な起動パラメータを調整し、インストールの特定のワークロード特性に応じた最適な構成を取得する必要があります。

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

注意:	アウトバウンドIIOPは、トランザクションおよびセキュリティ機能ではサポートされていません。

機能説明

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

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

•	双方向 - 同じ接続を再利用するアウトバウンドIIOP (<Default ? Font>Oracle WebLogic Enterpriseリリース4.2以降のC++ GIOP 1.2サーバー、クライアントおよび共同クライアント/サーバーでのみサポート)

•	非対称 - 2番目の接続経由のアウトバウンドIIOP (GIOP 1.0、GIOP 1.1、GIOP 1.2のサーバー、クライアント、および共同クライアント/サーバー・アプリケーションでサポート)。

•	デュアル・ペア接続 - アウトバウンドIIOP (GIOP 1.0、GIOP 1.1、GIOP 1.2のサーバー、クライアント、および共同クライアント/サーバー・アプリケーションでサポート)。

注意:

GIOP 1.2は、<Default ? Font>Oracle WebLogic Enterpriseリリース4.2 (以降)と<Default ? Font>Oracle Tuxedoリリース8.0 (以降)のC++クライアント、サーバーおよび共同クライアント/サーバーでのみサポートされます。<Default ? Font>Oracle WebLogic Enterpriseリリース4.0および4.1のC++クライアントとサーバーでは、GIOPのバージョン1.0および1.1はサポートされますが、GIOP 1.2はサポートされません。Javaクライアント、サーバーおよび共同クライアント/サーバーでは、GIOP 1.0のみがサポートされます。

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

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

図16-2 サポートされる共同クライアント/サーバーIIOP接続

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

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

1.	クライアントはオブジェクト参照を作成し、Oracle Tuxedo CORBAサーバーを呼び出します。クライアントORBは、サービス・コンテキストを使用して、その接続が双方向であることを識別します。このサービス・コンテキストは、メッセージとともにOracle Tuxedo CORBAサーバーに送信されます。

2.	オブジェクト参照をアンマーシャリングするとき、Oracle Tuxedo CORBAサーバーは、サービス・コンテキストのホスト/ポートをオブジェクト参照のホスト/ポートと比較します。これらが一致すると、ORBによって、ISHへのルーティングに必要なISHクライアント情報が追加されます。このクライアント情報は、オブジェクト参照がOracle Tuxedo CORBAサーバーに渡されるたびに、オブジェクト参照とともに送信されます。

3.	適切な時点で、Oracle Tuxedo CORBAサーバーまたはネイティブ・クライアントがオブジェクト参照を呼び出します。クライアント情報が指定されている場合、ルーティング・コードによって適切なISHが呼び出されます。

4.	ISHは、同じクライアント接続を使用してリクエストをクライアントに送信します。

5.	クライアントはメソッドを実行し、クライアント接続を使用してISHに応答を返します。

6.	ISHは、応答を受信してOracle Tuxedo CORBAサーバーに転送します。

図16-3 双方向接続

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

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

1.	サーバーは、あるソースからオブジェクト参照を取得します。ネーミング・サービスやstring_to_objectを取得したり、クライアントを介して渡すこともできますが、クライアント自体に存在するものは対象外です。ISHに接続されたクライアントにはオブジェクト参照が存在しないため、双方向接続を使用して送信時呼出しを行うことはできません。Oracle Tuxedo CORBAサーバーがオブジェクト参照を呼び出します。

2.	最初の呼出しで、ルーティング・コードによってISLのサービスが呼び出され、ホスト/ポートに渡されます。

3.	ISLはアウトバウンド呼出しを処理するISHを選択し、ISH情報をOracle Tuxedo CORBAサーバーに返します。

4.	Oracle Tuxedo CORBAサーバーはISHを呼び出します。

5.	ISHは、クライアントにリクエストを送信するために使用する送信接続を決定します。接続が確立されていない場合、ISHはホスト/ポートへの接続を作成します。

6.	クライアントがメソッドを実行し、ISHに応答を返します。

7.	ISHは、応答を受信してOracle Tuxedo CORBAサーバーに転送します。

図16-4 非対称のアウトバウンドIIOP

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

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

1.	クライアントは、オブジェクト参照を作成し、Bootstrap関数(register_callback_port)を呼び出して、オブジェクト参照を渡します。

2.	ISHがIORからホスト/ポートを取得し、クライアント・コンテキストに保存します。

3.	クライアントは、Oracle Tuxedo CORBAサーバーを呼び出して、オブジェクト参照を渡します。register_callback_port呼出しによって、ISHはホスト/ポートを含むサービス・コンテキストを作成します。このサービス・コンテキストは、メッセージと共にOracle Tuxedo CORBAサーバーに送信されます。

4.	オブジェクト参照をアンマーシャリングするとき、Oracle Tuxedo CORBAサーバーは、サービス・コンテキストのホスト/ポートをオブジェクト参照のホスト/ポートと比較します。これらが一致すると、ORBによって、オブジェクト参照にISHクライアント情報が追加されます。このクライアント情報は、オブジェクト参照がOracle Tuxedo CORBAサーバーに渡されるたびに、オブジェクト参照とともに送信されます。

5.	適切な時点で、Oracle Tuxedo CORBAサーバーまたはネイティブ・クライアントがオブジェクト参照を呼び出します。ルーティング・コードによって適切なISHが呼び出され、クライアント情報が渡されます。

6.	ISHは、クライアントへの2番目の接続を作成します。これは、この2番目の接続を使用してクライアントにリクエストを送信します。

7.	クライアントがメソッドを実行し、最初のクライアント接続を使用してISHに応答を返します。

8.	ISHは応答を受信して、これをOracle Tuxedo CORBAサーバーに送信します。クライアントがISHから切断されると、2番目の接続も切断されます。

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

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

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

1.	各ISLでサービスが通知されます。

2.	ルーティング・コードによってサービス名が呼び出されます。

注意:	ISLの検出には通常のOracle Tuxedoルーティングが使用されます。

3.	同じマシン上でアイドル状態のISLが使用可能な場合は、そのISLが常に選択されます。使用できない場合は、NETLOADにより、ほとんどの場合ローカルのISLが選択されます。

注意:	ローカル・マシン以外のマシンでISLが呼び出される場合もあります。

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

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

オブジェクト参照の種類

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

•	<Default ? Font>Oracle Tuxedoドメイン外のOracle Tuxedo CORBAリモート共同クライアント/サーバーによって作成されたオブジェクト参照

•	サード・パーティ製のサーバーによって作成されたオブジェクト参照

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

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

アウトバウンドIIOPサポートのユーザー・インタフェースは、ISLプロセスを起動するコマンド行インタフェースです。<Default ? Font>Oracle Tuxedoソフトウェアのこのリリースでは、ISLコマンドに、アウトバウンド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]
#アウトバウンドIIOPの新しいオプション
[-O]
[-o outbound-max-connections]
[-s Server-timeout]
[-u out-mpx-users] "

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

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

概要

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

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

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

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

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

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

*RESOURCES

OPTIONS APPVER, LAN

アプリケーション・サービス・バージョンを無効化するには、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によりアプリケーション・サービス・バージョンを無効化するには、ユーザーはまず、構成済のアプリケーション・サービス・バージョン関連構成を削除する必要があります。詳細は、次を参照してください

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

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

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

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

*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になります。

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

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

リスト16-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によってすべての基準を満たすサービスが選択されます。ただし、これらのルーティング・メカニズムを一緒に使用する場合は、これらがどのように相互作用するかについて理解しておくことをお薦めします。

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

1.	初期化期間中にserver3がSVC2を呼び出す必要がある場合、server3のREQUEST_VERSIONは3で、サービス候補は次のようになります。

Server1:SVC2 1-2

Server2:SVC2 3-4

つまり、server3はServer2:SVC2を呼び出します。

2.	ネイティブ・クライアントがSVC3を呼び出す必要がある場合、ネイティブ・クライアントのREQUEST_VERSIONは1であり、サービス候補は次のようになります。

Server1:SVC1 1-2

Server2:SVC1 3-4

つまり、ネイティブ・クライアントはServer1:SVC1を呼び出します

3.	Server1:SVC1がSVC3を呼び出す必要がある場合、SVC1は受信REQUEST_VERSIONを伝播します。この場合、受信REQUEST_VERSIONは1であるため、Server1:SVC1の現在のREQUEST_VERSIONは1となり、サービス候補は次のようになります。

Server2:SVC3 3-4

Server3:SVC3 1-3

つまり、Server1:SVC1はServer3:SVC3を呼び出します

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

5.	リクエストがREMOTEDOM1から送信される場合、元のREQUEST_VERSIONが2と仮定すると、受信リクエストのREQUEST_VERSIONは2のままになります。

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

たとえば、リスト16-4に示すように、MIBによりREQUEST_VERSIONを変更できます

リスト16-4 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