CORBA サーバ・アプリケーションのスケーリング

ドキュメントのダウンロード

サイトマップ

用語集

検索

e-docs > Tuxedo > Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング > CORBA サーバ・アプリケーションのスケーリング

Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング

CORBA サーバ・アプリケーションのスケーリング

ここでは、以下の内容について説明します。

このトピックでは Production サンプル・アプリケーションを例として使用し、CORBA C++ アプリケーションをスケーリングして処理能力を高める方法を示します。事前に、必ず次の個所をお読みください。

BEA Tuxedo CORBA アプリケーションのチューニングとスケーリングに関する包括的な説明については、BEA Tuxedo CORBA アプリケーションのスケーリング
BEA Tuxedo オンライン・マニュアルの「Production サンプル・アプリケーション」

Production サンプル・アプリケーションのスケーリングについて

Production サンプル・アプリケーションには、Wrapper サンプル・アプリケーションと同じエンド・ユーザ向けの機能が用意されています。Production サンプル・アプリケーションでは、BEA Tuxedo ソフトウェアの機能を使用して既存の BEA Tuxedo アプリケーションをスケーリングする方法が示されます。

この節では、以下の内容について説明します。

設計上の目標

Production サンプル・アプリケーションの設計上の主な目標は、次の処理により、対応できるクライアント・アプリケーションの数を大幅に増やすことです。

並列的に、および 1 つのマシン上で、同じインターフェイスをインプリメントする複数のオブジェクトに対するクライアント要求を処理します。
1 つのマシンへある特定の学生ために、および別のマシンへ別の学生のために、要求を転送します。
マシンをさらに追加して、処理負荷を分担します。

アプリケーションのスケーリング方法

これらの設計上の目標に対応するため、Production サンプル・アプリケーションは次のようにしてスケーリングされています。

状態を持たないオブジェクト・モデルをインプリメントして、サーバ・プロセスが同時に管理できるクライアント要求の数を増やします。
University、Billing および BEA Tuxedo Teller アプリケーションのサーバ・プロセスを、それらのコンフィギュレーションが行われているグループ内で複製します。該当するグループは、UBBCONFIG ファイルで定義されている ORA_GRP サーバ・グループおよび APP_GRP サーバ・グループです。
ORA_GRP サーバ・グループおよび APP_GRP サーバ・グループを追加のサーバ・マシンである Production マシン 2 上で複製し、データベースの分割も行います。
以下のオブジェクトに一意のオブジェクト ID (OID) を割り当て、それらがそれぞれのグループにおいて同時に複数回インスタンス化されるようにします。
これにより、これらのオブジェクトはプロセスではなくクライアント・アプリケーションごとに利用可能となるので、並列処理機能に対応できるようになります。
ファクトリ・ベース・ルーティングをインプリメントして、1 つのマシンへは一部の学生のために、別のマシンへはほかの学生のために、クライアント要求を転送します。

注記 Production サンプル・アプリケーションの使用を簡単にするには、1 つのデータベースを使い、1 つのマシン上で実行されるように、アプリケーションを BEA Tuxedo ソフトウェア・キット上でコンフィギュレーションします。ただし、この章で示した例では、アプリケーションは 2 つのデータベースを使って 2 つのマシン上で動作しています。

Production サンプル・アプリケーションは、数台のマシン上で動作し、複数のデータベースを使用すべくコンフィギュレーションできるよう設計されています。コンフィギュレーションを複数のマシンとデータベース用に変更するには、UBBCONFIG ファイルを修正して、データベースを分割することが必要です。この手順は、アプリケーションをさらにスケーリングする方法で説明しています。

以下の節では、Production サンプル・アプリケーションが複製されたサーバ・プロセスとサーバ・グループ、オブジェクト状態管理、およびファクトリ・ベース・ルーティングをどのように使用して、スケーラビリティの目標を達成するかを説明します。

OMG IDL の変更

Production サンプル・アプリケーションでの OMG IDL の変更は、RegistrarFactory オブジェクトの find_registrar() オペレーション、および TellerFactory オブジェクトの find_teller() オペレーションに限定されています。2 つのオペレーションは、それぞれ学生 ID と口座番号を要求するように修正する必要があります。これらは、ファクトリ・ベース・ルーティングのインプリメントに必要なものです。Production サンプル・アプリケーションでのファクトリ・ベース・ルーティングのインプリメンテーションと使用については、ファクトリ・ベース・ルーティングによるスケーリングを参照してください。

状態を持たないオブジェクト・モデルの使用方法

ここでは、Production サンプル・アプリケーションにおいて、スケーラビリティを増大させるために、オブジェクト状態管理をどのように Registrar オブジェクトおよび Teller オブジェクトで使用するかを説明します。オブジェクト状態管理の概要については、オブジェクト状態管理の使用を参照してください。

スケーラビリティを増大させるには、Production サーバ・アプリケーションで、Registrar および Teller オブジェクトに method 活性化方針をコンフィギュレーションします。これら 2 つのオブジェクトに method 活性化方針を割り当てた結果、振る舞いに次の変化がみられます。

これらのオブジェクトが呼び出されるときは常に、適切なサーバ・グループ内の BEA Tuxedo ドメインによってインスタンス化されます。
呼び出しが完了すると、BEA Tuxedo ドメインによりこれらのオブジェクトは非活性化されます。

Basic から Wrapper までの各種サンプル・アプリケーションでは、Registrar オブジェクトはプロセス・バウンド・オブジェクト (process 活性化方針) となっていました。Registrar オブジェクトに対するクライアント要求はすべて、常にサーバ・マシンのメモリ内の同じオブジェクト・インスタンスに送られました。Basic サンプル・アプリケーションの設計は、すべての小規模なデプロイメントに適しています。しかし、クライアント・アプリケーションの要求が増すにつれて、Registrar オブジェクト上のクライアント要求はキューに入れられるようになり、このため応答時間が遅くなります。

ただし、 Registrar および Teller オブジェクトが状態を持たないオブジェクト (method 活性化方針) であり、これらのオブジェクトを管理するサーバ・プロセスが複製されている場合、Registrar および Teller の各オブジェクトは並行して複数のクライアント要求を処理できます。これらのオブジェクトで処理できる同時のクライアント要求の数で制約があるのは、Registrar および Teller のオブジェクトをインスタンス化できる、利用可能なサーバ・プロセスの数だけです。したがって、これらの状態を持たないオブジェクトはマシン・リソースのより効率的な使用と、クライアント応答時間の短縮を実現します。

最も重要なのは、BEA Tuxedo CORBA で、Registrar および Teller オブジェクトのコピーを各複製サーバ・プロセス内でインスタンス化できるように、オブジェクトの各コピーが一意でなければならないことです。これらのオブジェクトの各インスタンスを一意にするために、オブジェクトのファクトリでは一意のオブジェクト ID をオブジェクトに割り当てる必要があります。

BEA Tuxedo アプリケーションが複製サーバ・アプリケーション・プロセスのそれぞれで Registrar および Teller オブジェクトのコピーをインスタンス化するには、オブジェクトの各コピーが一意のオブジェクト ID (OID) を備えていなければなりません。一意な OID は、これらのオブジェクトを作成するファクトリで割り当てられます。一意なオブジェクト ID の生成についての詳細は、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』を参照してください。その他の設計上の考慮事項については、設計上の追加考慮事項を参照してください。

サーバ・プロセスおよびサーバ・グループの複製によるスケーリング

ここでは、以下の内容について説明します。

このトピックでは、サーバ・プロセスおよびサーバ・グループを複製することによる、Production サンプル・アプリケーションのスケーリング方法を説明します。概要については、サーバ・プロセスおよびサーバ・グループの複製を参照してください。

Production アプリケーションでのサーバ・プロセスの複製

この節では、Production サンプル・アプリケーションによるサーバ・アプリケーションの複製方法を説明します。この機能の概要については、サーバ・プロセスの複製を参照してください。

図2-1 では、単一のマシン上で実行される、複製された ORA_GRP および APP_GRP グループを示します。

University サーバ・アプリケーション、BEA Tuxedo Teller アプリケーション、および Oracle7 TMS サーバ・プロセスは、ORA_GRP グループ内で複製されます。
Billing サーバ・プロセスは、APP_GRP グループ内で複製されます。
図 2-1 Production サンプルの複製サーバ・グループ

これらのグループの 1 つに要求が到達したとき、BEA Tuxedo ドメインにはこの要求を処理できるサーバ・プロセスがいくつかあります。BEA Tuxedo ドメインは、最も負荷の軽いサーバ・プロセスを選択することができます。

図2-1 では、次の点に留意してください。

常に、特定のサーバ・プロセス内で、RegistrarFactory、Registrar、TellerFactory、または Teller オブジェクトのインスタンスが複数存在することはできません。
CourseSynopsisEnumerator オブジェクトは、どの University サーバ・プロセスでも、任意の数だけ存在することができます。

Production アプリケーションでのサーバ・グループの複製

この節では、Production サンプル・アプリケーションによるサーバ・グループの複製方法を説明します。この機能の概要については、サーバ・グループの複製を参照してください。

図2-2 は、アプリケーションの UBBCONFIG ファイルで ORA_GRP2 および APP_GRP2 として指定された、別のマシン上で複製される Production サンプル・アプリケーション・グループを示します。

図 2-2 複数のマシンにわたるサーバ・グループの複製

図2-2 では、Production マシン 1 および 2 のグループの内容の違いはデータベースのみです。

Production マシン 1 のデータベースには、100001 から 100005 までの間の ID を持つ学生の、学生情報および口座情報が格納されています。
Production マシン 2 のデータベースには、100006 から 100010 までの間の ID を持つ学生の、学生情報および口座情報が格納されています。

注記双方のデータベースのコース情報テーブルは同じものです。

所定のデータベース内の学生情報は、同じデータベース内の口座情報とはまったく関係がない場合があります。

Production サンプル・アプリケーションがファクトリ・ベース・ルーティングを使用して、複数のマシン間にアプリケーションの処理負荷を分散する方法の詳細については、ファクトリ・ベース・ルーティングによるスケーリングを参照してください。

Production アプリケーションの複製サーバ・プロセスおよびグループのコンフィギュレーション

リスト2-1 は、Production サンプル・アプリケーションの UBBCONFIG ファイルの GROUPS および SERVERS セクションからの抜粋です。

コードリスト 2-1 UBBCONFIG ファイルの GROUPS および SERVERS セクション

*GROUPS
    APP_GRP1
        LMID      = SITE1
        GRPNO     = 2
        TMSNAME   = TMS
    APP_GRP2
        LMID      = SITE1
        GRPNO     = 3
        TMSNAME   = TMS
    ORA_GRP1
        LMID      = SITE1
        GRPNO     = 4
        OPENINFO  = "ORACLE_XA:Oracle_XA+Acc=P/scott/..."
        CLOSEINFO = ""
        TMSNAME   = "TMS_ORA"
    ORA_GRP2
        LMID      = SITE1
        GRPNO     = 5
        OPENINFO  = "ORACLE_XA:Oracle_XA+Acc=P/scott/..."
        CLOSEINFO = ""
        TMSNAME   = "TMS_ORA"

*SERVERS
    # デフォルトでは、各サーバのインスタンスを 2 つ活性化
    # して、管理者が各サーバのインスタンスを 5つ
    # まで活性化できるようにしている
    DEFAULT:
        MIN     = 2
        MAX     = 5
    tellp_server
        SRVGRP  = ORA_GRP1
        SRVID   = 10
        RESTART = N
    tellp_server
        SRVGRP  = ORA_GRP2
        SRVID   = 10
        RESTART = N

    billp_server
        SRVGRP  = APP_GRP1
        SRVID   = 10
        RESTART = N
    billp_server
        SRVGRP  = APP_GRP2
        SRVID   = 10
        RESTART = N
    univp_server
        SRVGRP  = ORA_GRP1
        SRVID   = 20
        RESTART = N
    univp_server
        SRVGRP  = ORA_GRP2
        SRVID   = 20
        RESTART = N

ファクトリ・ベース・ルーティングによるスケーリング

ここでは、以下の内容について説明します。

このトピックでは、ファクトリ・ベース・ルーティングを使用して Production サンプル・アプリケーションをスケーリングする方法について説明します。ファクトリ・ベース・ルーティングの概要については、ファクトリ・ベース・ルーティングの使用 (CORBA サーバのみ)を参照してください。

Production アプリケーションでのファクトリ・ベース・ルーティングについて

この節では、Production サンプル・アプリケーションがどのようにファクトリ・ベース・ルーティングを使用するかを説明します。この機能の概要については、ファクトリ・ベース・ルーティングの使用 (CORBA サーバのみ)を参照してください。

ファクトリ・ベース・ルーティングを使用すると、BEA Tuxedo CORBA のロード・バランシング機能およびスケーラビリティ機能を拡張できます。Production サンプル・アプリケーションでは、ファクトリ・ベース・ルーティングを使用して、1 つのマシンに 1 つの学生のサブセットを登録する要求を、別のマシンに別の学生のサブセットを登録する要求を送信できます。アプリケーションの処理機能を向上させると、アプリケーション内でのファクトリ・ベース・ルーティングを簡単に変更して、マシンをさらに追加できます。

Production サンプル・アプリケーションでのファクトリ・ベース・ルーティングのインプリメンテーションに関する設計上の主な考慮事項は、ルーティングの基準となる値の選択です。Production サンプル・アプリケーションは、次のようにファクトリ・ベース・ルーティングを使用します。

クライアント・アプリケーションから Registrar オブジェクトへの要求は、学生 ID に基づいてルーティングされます。ID が 100001 ～ 100005 の学生からの要求は、Production マシン 1 にルーティングされます。ID が 100006 ～ 100010 の学生からの要求は、Production マシン 2 にルーティングされます。
Registrarオブジェクトから Teller オブジェクトへの要求は、口座番号に基づいてルーティングされます。200010 から 200014 までの口座番号への支払い要求は、Production マシン 1 にルーティングされます。200015 から 200019 までの口座番号への支払い要求は、Production マシン 2 にルーティングされます。

UBBCONFIG ファイルでのファクトリ・ベース・ルーティングのコンフィギュレーション

University Production サンプル・アプリケーションでは、ファクトリ・ベース・ルーティングのインプリメント方法が例示されます。ubb_b.nt コンフィギュレーション・ファイルからの INTERFACES、ROUTING、および GROUPS セクションでは、BEA Tuxedo CORBA アプリケーションでファクトリ・ベース・ルーティングをインプリメントする方法が示されます。このサンプルの ubb_p.nt または ubb_p.mk UBBCONFIG ファイルは、BEA Tuxedo ソフトウェアをインストールしたディレクトリで見つけることができます。¥samples¥corba¥university¥production サブディレクトリを参照してください。

UBBCONFIG ファイルでは、グループおよびマシンの識別方法に加えて、INTERFACES および ROUTINGセクションにおいて、以下のデータを指定する必要があります。

INTERFACES セクションには、ファクトリ・ベース・ルーティングを有効にするインターフェイスの名前の一覧が示されます。各インターフェイスについて、このセクションではインターフェイスがルーティングを行う基準の種類を指定します。リスト2-2 で示すように、ここでは識別子 FACTORYROUTING によってルーティング基準を指定します。

コードリスト 2-2 UBBCONFIG ファイルの INTERFACES セクション

INTERFACES
    "IDL:beasys.com/UniversityP/Registrar:1.0"
        FACTORYROUTING = STU_ID
    "IDL:beasys.com/BillingP/Teller:1.0"
        FACTORYROUTING = ACT_NUM

リスト2-2 は、ファクトリ・ベース・ルーティングが使用されている Production サンプルの 2 つのインターフェイスの完全修飾インターフェイス名を示します。FACTORYROUTING 識別子は、ルーティング値の名前を指定します。値はそれぞれ、STU_ID および ACT_NUM です。

ROUTING セクションは、各ルーティング値について、表 2-1 に記載のパラメータを指定します。

表 2-1 ROUTING セクションで指定されるパラメータ

パラメータ	説明
TYPE	ルーティングのタイプを指定します。Production サンプルでは、ルーティングのタイプはファクトリ・ベース・ルーティングです。したがって、このパラメータは FACTORY と定義されます。
FIELD	ファクトリがルーティング値に挿入する変数名を指定します。Production サンプルでは、フィールド・パラメータはそれぞれ、student_id および account_number です。
FIELDTYPE	ルーティング値のデータ型を指定します。Production サンプルでは、student_id および account_number のフィールド型は long です。
RANGES	各グループにルーティングされる値を指定します。

リスト2-3 は、Production サンプル・アプリケーションで使用される UBBCONFIG ファイルの ROUTING セクションを示します。

コードリスト 2-3 UBBCONFIG ファイルの ROUTING セクション

ROUTING
    STU_ID
        FIELD     = "student_id"
        TYPE      = FACTORY
        FIELDTYPE = LONG
        RANGES    = "100001-100005:ORA_GRP1,100006-100010:ORA_GRP2"
    ACT_NUM
        FIELD     = "account_number"
        TYPE      = FACTORY
        FIELDTYPE = LONG
        RANGES    = "200010-200014:APP_GRP1,200015-200019:APP_GRP2"

リスト2-3 は、ある 1 つの範囲の ID を持つ学生に対する Registrar オブジェクト・リファレンスが、ある 1 つのサーバ・グループにルーティングされ、別の範囲の ID を持つ学生に対する Registrar オブジェクト・リファレンスが、別のグループに割り当てられることを示します。同様に、ある 1 つの範囲の口座に対する Teller オブジェクト・リファレンスは、ある 1 つのサーバ・グループにルーティングされ、別の範囲の口座に対する Teller オブジェクト・リファレンスは、別のグループにルーティングされます。

UBBCONFIG ファイルの ROUTING セクションにある RANGES 識別子で指定されたグループを識別およびコンフィギュレーションする必要があります。たとえば、Production サンプルは APP_GRP1、APP_GRP2、ORA_GRP1、および ORA_GRP2 という 4 つのグループを指定します。これらのグループをコンフィギュレーションし、グループが実行されるマシンを識別する必要があります。

リスト2-4 は、Production サンプルの UBBCONFIG ファイルにおける、GROUPS セクションを示します。ここで ORA_GRP1 および ORA_GRP2 の各グループがコンフィギュレーションされます。GROUPS セクション内の名前と、ROUTING セクションの RANGES パラメータで指定されたグループ名がどのように一致しているかに注目してください。これは、ファクトリ・ベース・ルーティングが正しく機能するために重要です。さらに、アプリケーションでグループをコンフィギュレーションする方法に関する何らかの変更も、ROUTING セクションに反映される必要があります。BEA Tuxedo ソフトウェアとともにパッケージされている Production サンプルは 1 台のマシンでだけ実行できるようにコンフィギュレーションされている点に注意してください。ただし、このアプリケーションを複数のマシンで実行できるようにコンフィギュレーションすることは簡単です。

コードリスト 2-4 UBBCONFIG ファイルの GROUPS セクション

*GROUPS
    APP_GRP1
        LMID      = SITE1
        GRPNO     = 2
        TMSNAME   = TMS
    APP_GRP2
        LMID      = SITE1
        GRPNO     = 3
        TMSNAME   = TMS
    ORA_GRP1
        LMID      = SITE1
        GRPNO     = 4
        OPENINFO = "ORACLE_XA:Oracle_XA+Acc=P/scott/tiger+SesTm=100+LogDir=.+MaxCur=5"
        CLOSEINFO = ""
        TMSNAME   = "TMS_ORA"
    ORA_GRP2
        LMID      = SITE1
        GRPNO     = 5
OPENINFO = "ORACLE_XA:Oracle_XA+Acc=P/scott/tiger+SesTm=100+LogDir=.+MaxCur=5"
        CLOSEINFO = ""
        TMSNAME   = "TMS_ORA"

ファクトリでのファクトリ・ベース・ルーティングのインプリメンテーション

ファクトリでは、TP::create_object_reference() オペレーションに対する呼び出しのインプリメントと同様の方式でファクトリ・ベース・ルーティングが行われます。このオペレーションは、リスト2-5 に示す C++ バインディングを備えています。

コードリスト 2-5 create_object_reference の C++ バインディング

CORBA::Object_ptr  TP::create_object_reference (
                       const char* interfaceName,
                       const PortableServer::oid &stroid,
                        CORBA::NVlist_ptr criteria);

このオペレーションに対する 3 番目のパラメータである criteria は、ファクトリ・ベース・ルーティングに使用される、名前の付いた値を指定します。ファクトリ内でファクトリ・ベース・ルーティングをインプリメントするには、NVlist をビルドする必要があります。ファクトリ・ベース・ルーティングの使用はオプションであり、この引数に依存します。ファクトリ・ベース・ルーティングを使用する代わりに、この引数に 0 (ゼロ) の値を渡すこともできます。

前述のように、Production サンプル・アプリケーションの RegistrarFactory オブジェクトは、値 STU_ID を指定します。この値は、UBBCONFIG ファイル内の次の情報に完全一致している必要があります。

INTERFACES セクションの FACTORYROUTING 識別子で指定される、ルーティング名、タイプ、および使用できる値
ROUTING セクションで指定される、ルーティング基準名、フィールド、およびフィールド型

RegistrarFactory オブジェクトは、リスト2-6 に記載のコードを使用して、学生 ID を NVlist に挿入します。

コードリスト 2-6 RegistrarFactory オブジェクトの NVlist

// 学生 ID (ルーティング基準) を
// CORBA NVList に挿入
CORBA::NVList_var v_criteria;
TP::orb()->create_list(1, v_criteria.out());
CORBA::Any any;
any <<= (CORBA::Long)student;
v_criteria->add_value("student_id", any, 0);

RegistrarFactory オブジェクトには、リスト2-7 に示す TP::create_object_reference() オペレーションに対する呼び出しが含まれます。これにより、リスト2-6 で作成された NVlist が渡されます。

コードリスト 2-7 RegistrarFactory オブジェクトでの create_object_reference の呼び出し

// ルーティング基準を使用して、registrar オブジェクト・
// リファレンスを作成
CORBA::Object_var v_reg_oref =
    TP::create_object_reference(
        UniversityP::_tc_Registrar->id(),
        object_id,
        v_criteria.in()
    );

Production サンプル・アプリケーションはまた、TellerFactory オブジェクトでもファクトリ・ベース・ルーティングを使用し、口座番号に基づいて Teller オブジェクトがインスタンス化されるべきグループを決定します。

実行時の処理

ファクトリでファクトリ・ベース・ルーティングをインプリメントするとき、BEA Tuxedo CORBA によってオブジェクト・リファレンスが生成されます。以下の例では、ファクトリ・ベース・ルーティングのインプリメント時に、クライアント・アプリケーションが Registrar オブジェクトへのオブジェクト・リファレンスを取得する方法を示します。

クライアント・アプリケーションが、RegistrarFactory オブジェクトを呼び出し、Registrar オブジェクトへのリファレンスを要求します。要求には、学生 ID が含まれています。
RegistrarFactory は、NVlist に学生 ID を挿入します。これは、ルーティング基準として使用されます。
RegistrarFactory は、TP::create_object_reference() オペレーションを呼び出し、Registrar インターフェイス名、一意の OID、および NVlist を渡します。
BEA Tuxedo CORBA は、ルーティング・テーブルの内容を、 NVlist 内の値と比較し、グループ ID を決定します。
BEA Tuxedo CORBA は、グループに関する情報を、オブジェクト・リファレンスに挿入します。

クライアント・アプリケーションがその後、オブジェクト・リファレンスを使用してオブジェクトを呼び出すと、BEA Tuxedo CORBA はオブジェクト・リファレンスで指定されたグループに要求をルーティングします。

注記プロセス・エンティティの設計パターンを使用する場合は、ファクトリ・ベース・ルーティングのインプリメントは慎重に行う必要があります。オブジェクトは、グループのデータベースに格納されているエンティティしか処理できません。

設計上の追加考慮事項

ここでは、以下の内容について説明します。

設計上の追加考慮事項について

Registrar オブジェクトおよび Teller オブジェクトを設計する際には、次のことを確認してください。

Registrar オブジェクトおよび Teller オブジェクトが、Production デプロイメント具体的には複数の複製サーバ・プロセスおよび複数のグループにわたって、適正に機能していること。University および Billing の各サーバ・プロセスが複製されている場合の設計では、これら 2 つのオブジェクトをどのようにインスタンス化するかを考慮する必要があります。
Production BEA Tuxedo ドメインの 2 つのサーバ・グループが各々、別のデータベースを扱う場合には、所定の学生への登録および課金のオペレーションに対するクライアント要求が、正しいサーバ・グループに送られること。

オブジェクトは一意のオブジェクト ID (OID) を持ち、メソッド・バウンドである必要があります。つまり、これらのオブジェクトには、method 活性化方針が割り当てられている必要があります。

Registrar オブジェクトおよび Teller オブジェクトのインスタンス化

Production サンプル・アプリケーションほど高度でない University サーバ・アプリケーションでは、Registrar オブジェクトと Teller オブジェクトの実行時の振る舞いは、より単純でした。

各オブジェクトは、プロセス・バウンドでした。つまり、最初に呼び出されたときに活性化され、そのオブジェクトが実行されているサーバ・プロセスがシャットダウンされるまで、メモリ内に残っていました。
BEA Tuxedo ドメインで実行されるサーバ・グループは 1 つしかなく、グループ内では University および Billing のサーバ・プロセスは 1 つしかなかったため、すべてのクライアント要求は、同じオブジェクトに転送されました。複数のクライアント要求が BEA Tuxedo ドメインに到達する一方で、これらの各オブジェクトが処理するクライアントは一度に 1 つずつでした。
各オブジェクトのインスタンスは、それらが実行されているサーバ・プロセスに 1つしかなかったため、どちらのオブジェクトにも一意の OID は不要でした。各オブジェクトの OID が指定するのは、インターフェイス・リポジトリ ID のみでした。

しかし今では、University および Billing サーバ・プロセスは複製されているため、BEA Tuxedo CORBA は Registrar オブジェクトと Teller オブジェクトの複数インスタンスを区別できなくてはなりません。たとえば、グループ内で 2 つの University サーバ・プロセスが実行されている場合、BEA Tuxedo CORBA には、1 つ目の University サーバ・プロセスで実行されている Registrar オブジェクトと、2 つ目のサーバ・プロセスで実行されている Registrar オブジェクトを区別する手段が必要です。これらのオブジェクトの複数のインスタンスを区別するには、各オブジェクト・インスタンスが一意的である必要があります。

各 Registrar および Teller オブジェクトを一意のものにするには、これらのオブジェクトのファクトリで、これらに対するオブジェクト・リファレンスを作成する方法を変更しなければなりません。たとえば Basic サンプル・オブジェクトでは、RegistrarFactory オブジェクトが Registrar オブジェクトへのオブジェクト・リファレンスを作成すると、TP::create_object_reference() オペレーションが、文字列 registrar のみからなる OID を指定していました。しかし、Production サンプル・アプリケーションでは、同じ TP::create_object_reference() オペレーションが、生成された一意の OID を使用します。

各 Registrar および Teller オブジェクトに一意の OID を付与した結果、BEA Tuxedo ドメインではこれらのオブジェクトの複数のインスタンスが、同時に実行可能です。この特性は、状態を持たないオブジェクト・モデルでは一般的なものであり、BEA Tuxedo ドメインが、高い性能を提供しつつ、高度にスケーラブルであり得ることの一例です。

最後に、一意の Registrar および Teller オブジェクトは、それらに対するクライアント要求があるたびにメモリにロードする必要があるため、呼び出しが完了したときにはこれらのオブジェクトを非活性化し、関連するオブジェクト状態がアイドル状態のままメモリに残存しないようにすることが重要です。Production サーバ・アプリケーションは、インプリメンテーション・コンフィギュレーション・ファイル (ICF) 内のこれら 2 つのオブジェクトに、method 活性化方針を割り当てることによって、この問題に対処します。

学生の登録が確実に正しいサーバ・グループ内で行われるようにする

複製サーバ・グループを使用する、主なスケーラビリティ上の利点は、複数台のマシンに処理を分散できることです。しかし、University サンプル・アプリケーションの場合のように、アプリケーションがデータベースと対話する場合は、これら複数のサーバ・グループがデータベースとの対話に与える影響を考慮することが重要です。

多くの場合、デプロイされているマシンに、データベースは 1 つずつ関連付けられています。サーバ・アプリケーションが複数台のマシンに分散されている場合は、データベースをどのようにセットアップするかを検討する必要があります。

この章で説明しているように、Production サンプル・アプリケーションでは、2 つのデータベースを使用します。しかし、このアプリケーションは、簡単にそれ以上のデータベースに対応できるようコンフィギュレーションできます。使用するデータベースの数は、システム管理者が決定できます。

Production サンプル・アプリケーションでは、学生および口座の情報は、2 つのデータベース間に分割されますが、コース情報は同一です。コース情報は、コース登録用途では読み取り専用となっているため、両方のデータベースのコース情報が同一であることは問題にはなりません。一方で、学生情報および口座情報については読み書きが行われます。複数のデータベースが学生および口座についても同一のデータを格納するとしたら (つまり、データベースが分割されていない場合)、アプリケーションでは、学生情報または口座情報が変更されるたびにデータベース全体にわたって学生および口座の情報の更新を同期する処理のオーバーヘッドに対処する必要が生じるでしょう。

Production サンプル・アプリケーションは、ファクトリ・ベース・ルーティングによって、1 台のマシンに要求の 1 セットを、別のマシンに要求の別の 1 セットを送信します。RegistrarFactoryオブジェクトでファクトリ・ベース・ルーティングがどのようにインプリメントされるかは、Registrar オブジェクトへのリファレンスがどのように作成されるかによって変わります。

たとえば、クライアント・アプリケーションが RegistrarFactory オブジェクトに要求を送信して、Registrar オブジェクトのオブジェクト・リファレンスを取得した場合、クライアント・アプリケーションはその要求に学生 ID を含めます。クライアント・アプリケーションは、RegistrarFactory オブジェクトが返すオブジェクト・リファレンスを使用して、その後の Registrar オブジェクトへのすべての呼び出しを、特定の学生のために行う必要があります。ファクトリによって返されたオブジェクト・リファレンスは、グループ固有のものだからです。したがって、たとえばクライアント・アプリケーションがその後、Registrar オブジェクトに対して get_student_details() オペレーションを呼び出すと、クライアント・アプリケーションでは、Registrar オブジェクトが、その学生のデータを格納しているデータベースと関連付けられたサーバ・グループにおいて、確実に活性化されます。

この機能を示すために、Production サンプル・アプリケーションにインプリメントされている以下の実行シナリオを検討してみます。

クライアント・アプリケーションは、RegistrarFactory オブジェクトの find_registrar() オペレーションを呼び出します。この呼び出しには、学生 ID 1000003 が含まれます。
BEA Tuxedo CORBA は、クライアント要求を任意の RegistrarFactory オブジェクトにルーティングします。
RegistrarFactory オブジェクトは、学生 ID を使用し、UBBCONFIG ファイルのルーティング情報に基づいて、ORA_GRP1 内の Registrar オブジェクトへのオブジェクト・リファレンスを作成し、そのオブジェクト・リファレンスをクライアント・アプリケーションに返します。
クライアント・アプリケーションは、Registrar オブジェクトの register_for_courses() オペレーションを呼び出します。
BEA Tuxedo CORBA はクライアント要求を受け取り、それをオブジェクト・リファレンスで指定されたサーバ・グループにルーティングします。この場合、クライアント要求は、Production マシン 1 の ORA_GRP1 内の University サーバ・プロセスに送られます。
University サーバ・プロセスは、Registrar オブジェクトをインスタンス化し、それにクライアント呼び出しを送信します。

上記の説明の RegistrarFactory オブジェクトは、クライアント・アプリケーションに、ORA_GRP1 内でのみインスタンス化が可能な Registrar オブジェクトへの一意のリファレンスを返します。このグループには Production マシン 1 上で実行され、100001 から 100005 までの ID を持つ学生の学生データを格納したデータベースがあります。したがって、クライアント・アプリケーションが所定の学生のために、その後の要求をこの Registrar オブジェクトに送信すると、 Registrar オブジェクトは適正なデータベースと対話を行います。

Teller オブジェクトが適切なサーバ・グループでインスタンス化されるようにする方法

Registrar オブジェクトは Teller オブジェクトが必要になると、University サーバ・オブジェクトにキャッシュされていた TellerFactory オブジェクト・リファレンスを使用して、TellerFactory オブジェクトを呼び出します。

しかし、TellerFactory オブジェクトではファクトリ・ベース・ルーティングが使用されているため、Registrar オブジェクトは Teller オブジェクトへのリファレンス要求時に、学生の口座番号を渡します。このようにして TellerFactory オブジェクトは、正しいデータベースを備えたグループ内の Teller オブジェクトへのリファレンスを作成します。

注記 Production サンプル・アプリケーションが適正に動作するためには、システム管理者がサーバ・グループとデータベースのコンフィギュレーションを正しく行うことが不可欠です。具体的には、システム管理者はルーティング・テーブルで指定されたルーティング基準と、これらの基準を使用した要求のルーティング先となるデータベースを、確実に一致させる必要があります。Production サンプルを例にすると、指定されたグループにあるデータベースは、そのグループにルーティングされた要求に正しく対応する学生情報および口座情報を含んでいる必要があります。

アプリケーションをさらにスケーリングする方法

将来的には、Production サンプル・アプリケーションのシステム管理者が BEA Tuxedo ドメインの容量を増やす必要を感じる場合もあります。たとえば、今後大学の学生数が著しく増えたり、いくつかのキャンパスを包含する、州全体の大学システムのコース登録プロセスに対応するように Production アプリケーションが拡張されたりすることが考えられます。これを行うのに、アプリケーションを修正したり再ビルドしたりする必要はありません。

システム管理者は、以下の処理によって、容量を追加し続けることができます。

Production サンプル・アプリケーションのサーバ・グループを、追加のマシンにわたるように複製します。

システム管理者は、UBBCONFIG ファイルを修正し、追加のサーバ・グループ、これらのグループで実行されるサーバ・プロセス、およびサーバ・グループが動作するマシンを指定する必要があります。
ファクトリ・ベース・ルーティング・テーブルを変更します。

たとえば、Production サンプル・アプリケーションの既存の 2 つのグループへルーティングする代わりに、システム管理者は UBBCONFIG ファイルのルーティング規則を変更して、BEA Tuxedo ドメインに追加されたサーバ・グループにわたるよう、アプリケーションをさらに分割することができます。ルーティング・テーブルへの変更はすべて、UBBCONFIG ファイル内のコンフィギュレーション済みのサーバ・グループおよびマシンの情報と一致している必要があります。

注記データベースを使用する既存の BEA Tuxedo CORBA アプリケーションに容量を追加する場合、特にファクトリ・ベース・ルーティングを使用しているときは、データベースのセットアップに対する影響も考慮する必要があります。たとえば、Production サンプル・アプリケーションが 6 台のマシンに分散されている場合、各マシン上のデータベースを適切かつ UBBCONFIG ファイルのルーティング・テーブルに従ってセットアップする必要があります。