1. アプリケーション構成ガイド
  2. Oracle Tuxedo CORBAリモート・クライアント・アプリケーションの管理

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

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

16.1 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に関する技術的なサポートまたはドキュメントは提供していません。

このトピックには、次の項があります。

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

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

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

DLL
動的リンク・ライブラリ。ロード・モジュールにグループ化された関数の集合。Windowsアプリケーションでは、実行時に実行形式プログラムに動的にリンクされます。
IIOP
インターネットORB間プロトコル(IIOP)TCP/IP準拠の通信プロトコルで、共通のバックボーン・プロトコルとしてCORBA定義のメッセージ送受信をサポートします。
ISH
IIOPサーバー・ハンドラ。アプリケーション・サイト上で実行されるクライアント・プロセス。リモート・クライアントの代理として機能します。
ISL
IIOPサーバー・リスナー。アプリケーション・サイト上で実行されるサーバー・プロセス。リモート・クライアントの接続リクエストをリスニングします。
サーバー
Oracle Tuxedoドメインのマシンで管理されるサーバー。Oracle Tuxedo CORBAサーバーは、Oracle Tuxedo CORBAのbuildobjserverコマンドを使用して作成されます。CORBAサーバーは、セキュリティ、トランザクション、オブジェクトの状態管理など、Oracle Tuxedoの機能を実装します。サーバーは、Oracle Tuxedoドメイン内外の任意のサーバーを呼び出すことができます。
ネイティブ・クライアント
Oracle Tuxedoドメイン内のクライアント。CORBA ORBを使用して、Oracle Tuxedoドメイン内外のオブジェクトを呼び出します。ネイティブ・クライアントのホストには、Oracle Tuxedoの管理コンポーネントとインフラストラクチャ・コンポーネントがあります。たとえば、tmadmin、FactoryFinder、ISL/ISHなどです。ネイティブ・クライアントは、環境オブジェクトを使用してCORBAオブジェクトにアクセスします。ネイティブC++クライアントはbuildobjclientコマンドを使用して作成し、ネイティブJavaクライアントはサード・パーティORB提供のツールを使用して作成します。
リモート・クライアント
Oracle Tuxedoドメイン外のクライアント。リモート・クライアントは、CORBA ORBを使用して、Oracle Tuxedoドメイン内外のオブジェクトを呼び出すことができます。リモート・クライアントのホストには、tmadmin、FactoryFinder、ISL/ISHなど、Oracle Tuxedoの管理コンポーネントやインフラストラクチャ・コンポーネントはなく、リモート・クライアントがオブジェクトを呼び出すためのサポート・ソフトウェア(CORBA ORB)があります。リモート・クライアントは、環境オブジェクトを使用してCORBAオブジェクトにアクセスします。リモートC++クライアントはbuildobjclientコマンドを使用して作成し、リモートJavaクライアントはサード・パーティORB提供のツールを使用して作成します。
ネイティブ共同クライアント/サーバー
次の2つの目的を持つプロセス:
  1. 一部のビジネス・アクションのスタータとして機能するコードを実行します。
  2. オブジェクトに対する呼出しのメソッド・コードを実行します。共同クライアント/サーバーは、Oracle Tuxedoドメイン内にあります。ネイティブ共同C++クライアント/サーバーは、buildobjclientコマンドを使用して作成します。Javaネイティブ共同クライアント/サーバーはサポートされていません。

ノート:

ネイティブ共同クライアント/サーバーのサーバー・ロールは、通常のサーバーと比べて大幅に弱くなります。tmadmin、FactoryFinder、ISL/ISHなどのOracle Tuxedo CORBAの管理コンポーネントやインフラストラクチャ・コンポーネントはなく(Oracle Tuxedoのスケーラビリティと信頼性に関する属性もなし)、Oracle TuxedoのTP Frameworkも使用しないため、クライアントとORB間でより直接的な対話が必要になります。
リモート共同クライアント/サーバー
次の2つの目的を持つプロセス:
  1. 一部のビジネス・アクションのスタータとして機能するコードを実行します
  2. オブジェクトに対する呼出しのメソッド・コードを実行します。共同クライアント/サーバーは、Oracle Tuxedoドメイン外にあります。共同クライアント/サーバーはOracle Tuxedo TP Frameworkを使用しないので、クライアントとORB間でより直接的な対話が必要です。リモート共同C++クライアント/サーバーはbuildobjclientコマンドを使用して作成し、リモートJavaクライアント/サーバーはサード・パーティORB提供のツールを使用して作成します。

ノート:

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

リモート共同クライアント/サーバーのサーバー・ロールは、通常のサーバーと比べて大幅に弱くなります。クライアントにもサーバーにも、tmadmin、FactoryFinder、ISL/ISHなど、Oracle Tuxedoの管理コンポーネントやインフラストラクチャ・コンポーネントはありません(Oracle Tuxedoのスケーラビリティや信頼性に関する属性もなし)。

Oracle Tuxedo CORBAオブジェクト
TP Frameworkを使用して実装され、セキュリティ、トランザクション、およびオブジェクトの状態管理を実装するCORBAオブジェクト。CORBAオブジェクトは、Oracle Tuxedo CORBAサーバーで実装されます。つまり、これらのオブジェクトはOracle Tuxedoドメインの一部であり、Oracle Tuxedoインフラストラクチャを使用します。
コールバック・オブジェクト
ターゲット・オブジェクトでのクライアントの呼出しで、パラメータとして提供されるCORBAオブジェクト。ターゲット・オブジェクトは、そのターゲット・オブジェクトの実行時、または後で(ターゲット・オブジェクトの呼出しが完了した後でも可)コールバック・オブジェクトを呼び出すことができます。コールバック・オブジェクトは、Oracle Tuxedoドメイン内外のどちらにも配置できます。

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

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

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

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

  • CORBA C++クライアント

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

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

  • リモートCORBAオブジェクトでメソッドを呼び出します。
  • トランザクションの開始、ロールバック、またはコミットを行います。
  • アプリケーション・セキュリティにパスする必要があります。

ノート:

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

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

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

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

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

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

親トピック: CORBAリモート・クライアントの概要

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

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

親トピック: CORBAリモート・クライアントの概要

16.4 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>:
たとえば、ネットワーク・アドレスが、サーバー・アプリケーションのUBBCONFIGファイルにあるISLコマンド行のオプション文字列で//TRIXIE:3500;TLSv1.2に指定されている場合、BootstrapコンストラクタやTOBJADDRで//192.12.4.6:3500;TLSv1.2または//trixie:3500;TLSv1.2のいずれかを指定すると、接続が失敗します。

UNIXシステムで大文字/小文字の区別を調べるには、ホスト・システムでuname -nコマンドを使用します。Windowsシステムでは、ホスト・システムで「コントロール・パネル」の「ネットワーク」を使用して大文字/小文字を指定します。または、環境変数COMPUTERNAMEを使用します。例:

echo %COMPUTERNAME%

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

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

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

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

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

パラメータ 説明
MAXWSCLIENTS マシンに接続するリモート・クライアントの最大数を指定します。

デフォルトは0です。この値を指定しないと、リモート・クライアントから指定されたマシンに接続できません。

構文は、MAXWSCLIENTS=numberです。

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

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

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

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

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

16.6.1 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.7 CORBAリモート・クライアントをサポートするように構成ファイルを変更する

次のリストに、リモート・クライアントをサポートするサンプルUBBCONFIGファイルを示します:

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

サンプル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"
           ..

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

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

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

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

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

ノート:

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

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

16.8.1 機能説明

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

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

  • 双方向 - 接続を再利用するアウトバウンドIIOP (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は、Oracle WebLogic Enterpriseリリース4.2(以降)とOracle Tuxedoリリース8.0(以降)のC++クライアント、サーバー、および共同クライアント/サーバーでのみサポートされます。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.8.1.1 双方向のアウトバウンドIIOP

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

  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 双方向接続


双方向接続の図

親トピック: 機能説明

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

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

  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の図

親トピック: 機能説明

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

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

  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


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

親トピック: 機能説明

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

ISLの検出ステップは以下のとおりです。

  1. 各ISLでサービスが通知されます。
  2. ルーティング・コードによってサービス名が呼び出されます。
  3. ISLの検出には通常のOracle Tuxedoルーティングが使用されます。
  4. 同じマシン上でアイドル状態のISLが使用可能な場合は、そのISLが常に選択されます。アイドルのISLが使用できない場合、NETLOADは通常ローカルISLが選択されていることを確認します。

ノート:

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

親トピック: 機能説明

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

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

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

16.9.1 オブジェクト参照の種類

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

  • Oracle Tuxedoドメイン外のOracle Tuxedo CORBAリモート共同クライアント/サーバーによって作成されたオブジェクト参照Font>Oracle Tuxedoドメイン内外の任意のサーバーを呼び出すことができます
  • サード・パーティ製のサーバーによって作成されたオブジェクト参照

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

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

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

アウトバウンド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コマンドに関する項を参照してください。

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

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

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

16.10.1 概要

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

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

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

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

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

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

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

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

*RESOURCES 
OPTIONS       APPVER, LAN

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

*RESOURCES 
OPTIONS     LAN

ノート:

アプリケーション・バージョンが無効の場合、ユーザーは*RESOURCEおよび *GROUPセクション内のアプリケーション・サービス・バージョン関連構成を構成できません。
16.10.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によるユーザー構成サービス・バージョン情報のリセット』を参照してください。

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

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

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

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

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

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

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

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

*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構成ファイルのアプリケーション・サービス・バージョン構成」を参照してください。

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

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

アプリケーション・サービス機能を有効化すると、システムによってサービス名とサービス・バージョン範囲の両方に従ってリクエストがサービスに送信されます。このメカニズムのことを、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
    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
    Server3:SVC3 1-3 (つまり、Server1:SVC1はServer3:SVC3を呼び出します)
  4. リクエストがREMOTEDOM2から送信される場合、元のREQUEST_VERSIONが6であると仮定すると、受信リクエストのREQUEST_VERSIONは4に変更されます。
  5. リクエストがREMOTEDOM1から送信される場合、元のREQUEST_VERSIONが2であると仮定すると、受信リクエストのREQUEST_VERSIONは2のままになります。
16.10.4.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に設定することのみです。

たとえば、次のリストで示されるように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