bea ホーム | 製品 | dev2dev | support | askBEA
BEA Logo Tuxedo
 ドキュメントのダウンロード   サイトマップ   用語集 
検索
0
e-docs > Tuxedo > Tuxedo CORBA サーバ・アプリケーションの開発方法 > BEA Tuxedo の CORBA サーバ・アプリケーションのスケーリング

Tuxedo CORBA サーバ・アプリケーションの開発方法

 Previous Next Contents Index View as PDF  

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

この章では、BEA Tuxedo システムの主要なスケーラビリティ機能を利用して CORBA サーバ・アプリケーションのスケーラビリティを高める方法について、Production University サンプル・アプリケーションを例にして説明します。Production サンプル・アプリケーションは、これらのスケーラビリティ機能を利用して以下の目標を達成します。

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

 

BEA Tuxedo システムで利用可能なスケーラビリティ機能の概要

高度にスケーラブルなアプリケーションのサポートは、BEA Tuxedo システムの長所の 1 つです。多くのアプリケーションは、1 〜 10 のサーバ・プロセス、および 10 〜 100 のクライアント・アプリケーションが動作している環境で良好に機能します。しかし、ビジネス環境では、アプリケーションは次のレベルの処理をサポートする必要があります。

このような要件を負ったアプリケーションをデプロイすると、リソースの不足および性能のボトルネックがすぐに表面化します。BEA Tuxedo システムではこうした大規模なデプロイメントが複数の方法でサポートされていて、この章ではそれらのうち次の 3 つについて説明します。

アプリケーションを高度にスケーラブルにするために BEA Tuxedo システムで提供されているほかの機能には、IIOP リスナ/ハンドラがあります。概要については『BEA Tuxedo CORBA アプリケーション入門』、詳細な説明については『BEA Tuxedo アプリケーションの設定』を参照してください。また、『BEA Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング』も参照してください。

 

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

ここでは、非常に大規模な処理機能を実現できるようにアプリケーションをスケーリングする方法について、Production サンプル・アプリケーションを例にして説明します。Production サンプル・アプリケーションの設計上の基本的な目標は、対応できるクライアント・アプリケーションの数を大幅に増やすために、次のように対処することです。

こうした設計目標に対応するために、Production サンプル・アプリケーションでは次の処理をします。

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

Production サンプル・アプリケーションの設計では、複数台のマシン上で複数のデータベースを使用して実行するコンフィギュレーションが可能になるように設定されています。複数のマシンおよびデータベースを使用するようにコンフィギュレーションを変更する作業には、UBBCONFIG ファイルの変更とデータベースの分離が関係し、これらの詳細は第 8 章の 27 ページ「Production サーバ・アプリケーションをさらにスケーリングする方法」で説明されています。

以後の各節では、Production サンプル・アプリケーションのスケーラビリティの目標を達成するために、複製されたサーバ・プロセスおよびサーバ・グループの使用、オブジェクト状態管理、およびファクトリ・ベース・ルーティングについて説明します。次の節では、Production サンプル・アプリケーションにインプリメントされている OMG IDL の変更について説明します。

Production サンプル・アプリケーションの OMG IDL の変更

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

サーバ・プロセスおよびサーバ・グループの複製

BEA Tuxedo システムでは、サーバ・アプリケーションのコンフィギュレーションに多様な選択肢が用意されています。たとえば、以下のコンフィギュレーションが可能です。

以上をまとめると、次のようになります。

次の節では、複製されたサーバ・プロセスおよびグループについて説明するほか、それらを BEA Tuxedo システムにコンフィギュレーションする方法についても説明します。

複製されたサーバ・プロセス

使用するアプリケーションでサーバ・プロセスを複製すると、以下の利点があります。

複製されたサーバ・プロセスの利点を完全に活用するには、使用するサーバ・アプリケーションによってインスタンス化される各オブジェクトのすべてが一意な ID を持つようにしてください。こうすれば、オブジェクト上でのクライアント呼び出しによって必要なオブジェクトがインスタンス化される処理が、利用可能な複数のサーバ・プロセスの境界内で実行されるので、既に活性化されているオブジェクトのためのキューに入れられずに済みます。

図8-1 は、次のことを示します。

この図では、2 つのグループは 1 台のマシンで実行されているものとして示されます。

図 8-1 Production サンプルの複製サーバ・グループ


 


 

これらのグループのいずれかに要求が着信したとき、BEA Tuxedo ドメインには要求を処理できる利用可能なサーバ・プロセスが複数あり、BEA Tuxedo ドメインは最も負荷の少ないサーバ・プロセスを選択することができます。

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

複製されたサーバ・グループ

サーバ・グループの概念は BEA Tuxedo システムに固有のもので、CORBA のインプリメンテーションに追加されます。サーバ・グループは、BEA Tuxedo システムのスケーラビリティ機能の重要な要素です。基本的に、デプロイメント・システムにマシンを追加する場合は、グループを追加する必要があります。

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

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


 

図8-2 では、Production マシン 1 と 2 のグループの内容で異なるのはデータベースのみです。Production マシン 1 用のデータベースには、学生のサブセットについて、学生情報および口座情報が含まれています。Production マシン 2 用のデータベースには、学生の別のサブセットについて、学生情報および口座情報が含まれています。両方のデータベースにあるコース情報のテーブルは同じ内容です。データベースにある学生情報が、同じデータベース内の口座情報とは完全に無関連であることに注意してください。

サーバ・グループのコンフィギュレーションの方法、実行場所、および複製の方法は、UBBCONFIG ファイルに指定されています。サーバ・グループを複製すると、次の処理が可能になります。

複数のサーバ・グループを持つと、次のような影響があります。

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

複製されたサーバ・プロセスおよびグループのコンフィギュレーション

使用する BEA Tuxedo ドメインにある複製されたサーバ・プロセスおよびグループをコンフィギュレーションするには、以下の手順に従います。

  1. アプリケーションの UBBCONFIG ファイルを、「ワードパッド」などのテキスト・エディタで開きます。

  2. GROUPS セクションで、コンフィギュレーションするグループの名前を指定します。

  3. SERVERS セクションに、複製するサーバ・プロセスに関する次の情報を入力します。

    MIN および MAX パラメータは、指定されたオブジェクトへの要求をサーバ・アプリケーションでどの程度まで並行処理できるかを決定します。実行時には、必要に応じて、システム管理者がリソースのボトルネックを調べて、新しいサーバ・プロセスを起動することができます。このアプリケーションは、システム管理者がスケーリングできるように設計されています。

次に、Production サンプル・アプリケーションの 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

オブジェクト状態管理によるアプリケーションのスケーリング

CORBA サーバ・アプリケーションの概念で説明したように、オブジェクト状態管理は大規模なクライアント/サーバ・システムでは根本的に重要な検討事項です。それは、こうしたシステムでは最適なスループットおよび応答時間を実現することが重要であるためです。この節では、BEA Tuxedo サーバ・アプリケーションによって管理されるオブジェクトのスケーラビリティを高めるためにオブジェクト状態管理を使用する方法を、Production サンプル・アプリケーションの Registrar および Teller オブジェクトを例にして説明します。

次のテーブルは、使用する BEA Tuxedo アプリケーションのスケーラビリティを大きく高めるために、BEA Tuxedo システムでサポートされているオブジェクト状態管理モデルを使用する方法をまとめたものです。

状態モデル

スケーラビリティを達成するための使用法

メソッド・バウンド

メソッド・バウンド・オブジェクトは、クライアントによって呼び出されている間だけ、マシンのメモリへ格納されます。呼び出しが完了すると、オブジェクトは非活性化され、そのオブジェクトの状態データはすべて、メモリからフラッシュされます。

メソッド・バウンド・オブジェクトは、使用するアプリケーションに状態を持たないサーバ・モデルを作成する場合に使用できます。こうすれば、アプリケーションで数千のオブジェクトを管理できます。クライアント・アプリケーションのビューからは、すべてのオブジェクトがサービス要求に利用可能です。しかし、サーバ・アプリケーションがオブジェクトをメモリにマッピングするのはクライアントによってオブジェクトが呼び出されている間だけなので、任意の時点でメモリ内にあるオブジェクトのうち、サーバ・アプリケーションによって管理されているものは比較的少数にとどまります。

メソッド・バウンド・オブジェクトは、このマニュアルでは状態を持たないオブジェクトともいいます。

プロセス・バウンド

プロセス・バウンド・オブジェクトは、最初に呼び出された時点から、自身が実行されているサーバ・プロセスがシャットダウンされるまでメモリ内にとどまります。使用するアプリケーションで支障がなければ、大量の状態データを伴うプロセス・バウンド・オブジェクトは、複数のクライアント呼び出しに対応するためにメモリ内にとどまることができます。このようにすることで、システムのリソースは、クライアント呼び出しごとにオブジェクトの状態データを読み書きすることから解放されます。

プロセス・バウンド・オブジェクトは、このマニュアルでは状態を持つオブジェクトともいいます。トランザクション・バウンド・オブジェクトも状態を持つと見なされる点に注意してください。これは、トランザクションのスコープ内であれば、自身への呼び出しの間はメモリ内にとどまることが可能なためです。

 

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

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

しかし、Registrar および Teller オブジェクトが状態を持たず、これらのオブジェクトを管理するサーバ・プロセスが複製されていれば、これらのオブジェクトはクライアント要求の並行処理に利用可能になります。これらのオブジェクトで同時に処理できるクライアント要求の数に対する唯一の制限は、これらのオブジェクトをインスタンス化できる利用可能なサーバ・プロセスの数です。したがって、これらの状態を持たないオブジェクトはマシン・リソースのより効率的な使用と、クライアント応答時間の短縮を実現します。

最も重要なのは、BEA Tuxedo システムが Registrar および Teller オブジェクトのコピーを、両オブジェクトごとに複製されたサーバ・プロセス内でインスタンス化できるようにするためには、これらのオブジェクトのコピーが一意である必要があるということです。これらのオブジェクトの各インスタンスを一意にするために、オブジェクトのファクトリでは一意のオブジェクト ID をオブジェクトに割り当てる必要があります。このことも含めて、これら 2 つのオブジェクトに関する設計上の検討事項については、第 8 章の 22 ページ「Registrar および Teller オブジェクトに関する設計上の追加考慮事項」を参照してください。

ファクトリ・ベース・ルーティング

ファクトリ・ベース・ルーティングは、特定のサーバ・グループへクライアント要求を送信する方法を提供する強力な機能です。ファクトリ・ベース・ルーティングを使用すれば、アプリケーションの処理負荷を複数のマシンに分散できます。これは、指定されたオブジェクトがインスタンス化されるグループ、すなわちマシンを決定できるからです。

ファクトリ・ベース・ルーティングを使用すれば、BEA Tuxedo システムのさまざまなロード・バランシング機能およびスケーラビリティ機能を拡張することができます。Production サンプル・アプリケーションの場合、ファクトリ・ベース・ルーティングを使用すれば、学生のサブセットの 1 つを登録する要求を 1 台のマシンへ送信し、別のサブセットに関する要求は別のマシンへ送信することができます。使用するアプリケーションの処理能力を増やすためにマシンを追加しても、BEA Tuxedo システムではアプリケーションのファクトリ・ベース・ルーティングを簡単に変更してマシンの追加に対応できます。

ファクトリ・ベース・ルーティングの第一の利点は、デプロイメント環境の拡大に対応して、アプリケーション、特にインターフェイスの呼び出し機能をスケール・アップするための簡単な方法が提供されることです。アプリケーションのデプロイメント範囲を追加マシンにも広げることは、厳密には管理用の機能であり、アプリケーションの再コーディングや再ビルドは不要です。

クライアント/サーバ・アプリケーションにファクトリ・ベース・ルーティングをインプリメントする際に設計上最も重要な検討事項は、ルーティングのベースとなる値の選択です。以下の節では、ファクトリ・ベース・ルーティングの機能について、Production サンプル・アプリケーションを使用して説明します。Production サンプル・アプリケーションは、ファクトリ・ベース・ルーティングを次のように使用します。

ファクトリ・ベース・ルーティングのしくみ

ファクトリでファクトリ・ベース・ルーティングをインプリメントする際には、ファクトリがオブジェクト・リファレンスを作成する方法が変更されます。すべてのオブジェクト・リファレンスはグループ ID を含み、デフォルトのグループ ID はオブジェクト・リファレンスを作成するファクトリと同じになります。しかし、ファクトリ・ベース・ルーティングを使用する場合、ファクトリはグループ ID を決定するルーティング基準も含めてオブジェクト・リファレンスを作成します。その後、クライアント・アプリケーションがこうしたオブジェクト・リファレンスを使用して呼び出しを送信すると、BEA Tuxedo システムによって、要求はオブジェクト・リファレンスに指定されたグループ ID へルーティングされます。ここでは、オブジェクト・リファレンスに関するグループ ID がどのようにして生成されるかを説明します。

ファクトリ・ベース・ルーティングをインプリメントするには、次の項目を調整する必要があります。

調整が必要なデータについて説明するために、以降の 2 つの節では、UBBCONFIG ファイルでのファクトリ・ベース・ルーティングのコンフィギュレーションと、ファクトリでのファクトリ・ベース・ルーティングのインプリメンテーションを説明します。

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

要求がルーティングされる各インターフェイスについて、UBBCONFIG ファイルに次の情報を記述する必要があります。

ファクトリ・ベース・ルーティングをコンフィギュレーションするには、UBBCONFIG ファイルの INTERFACES および ROUTING セクションで次のデータを指定するほか、グループおよびマシンを識別する方法を指定する必要があります。

  1. INTERFACES セクションには、ファクトリ・ベース・ルーティングを有効にするインターフェイスの名前の一覧が示されます。各インターフェイスについて、このセクションでインターフェースのルーティングの基準の種類を指定します。このセクションでは、次の例のように、FACTORYROUTING という識別子でルーティング基準を指定します。 
    INTERFACES
        "IDL:beasys.com/UniversityP/Registrar:1.0"
            FACTORYROUTING = STU_ID
        "IDL:beasys.com/BillingP/Teller:1.0"
            FACTORYROUTING = ACT_NUM

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

  2. ROUTING セクションでは、ルーティング値ごとに以下のデータを指定します。

    次に、Production サンプル・アプリケーションで使用する 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"

上の例では、一方の範囲に入る ID を持った学生についての Registrar オブジェクト・リファレンスは一方のサーバ・グループにルーティングされ、もう一方の範囲に入る ID を持った学生についての Registrar オブジェクト・リファレンスは他方のグループにルーティングされるということが示されています。同様に、ある 1 つの範囲の口座に対する Teller オブジェクト・リファレンスは、ある 1 つのサーバ・グループにルーティングされ、別の範囲の口座に対する Teller オブジェクト・リファレンスは、別のグループにルーティングされます。

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

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

     
    • *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"

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

    ファクトリは、TP::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 をビルドすることにあります。

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

    RegistrarFactory オブジェクトは、次のコードを使用して NVlist に学生 ID を挿入します。

     
    // put the student id (which is the routing criteria)
    // into a 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 オブジェクトは次のようにして TP::create_object_reference() オペレーションを呼び出し、前のコード例で作成された NVlist を渡します。

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

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

    注記 指定されたインターフェイスおよび OID を持つ 1 つのオブジェクトが 2 つの異なるグループで同時に活性化されることも、それら 2 つのグループに同じオブジェクト・インプリメンテーションがある場合には起こりえます。しかし、使用するファクトリで一意な OID が生成されていれば、こうした状況はほぼありません。指定されたインターフェイス名および OID の 1 つのオブジェクトがドメイン内で一度に 1 つだけ利用可能であることを保証する必要がある場合は、次のいずれかを行います。ファクトリ・ベース・ルーティングを使用して、特定の OID のオブジェクトが常に同じグループにルーティングされるようにするか、指定されるオブジェクト・インプリメンテーションが 1 つのグループのみに存在するようにドメインをコンフィグレーションする。そうすれば、指定されたインターフェイス名および OID を持つ 1 つのオブジェクトに複数のクライアントがオブジェクト・リファレンスをした場合でも、そのリファレンスは常に同じオブジェクト・インスタンスへルーティングされることになります。

    オブジェクトの OID によるルーティングを利用可能にするには、TP::create_object_reference() オペレーションで OID をルーティング基準に指定してから、UBBCONFIG ファイルをそれに合わせて設定します。

    実行時の処理

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

    1. クライアント・アプリケーションが、RegistrarFactory オブジェクトを呼び出し、Registrar オブジェクトへのリファレンスを要求します。要求には学生 ID が含まれます。

    2. RegistrarFactory は、NVlist に学生 ID を挿入します。これは、ルーティング基準として使用されます。

    3. RegistrarFactory は、TP::create_object_reference() オペレーションを呼び出し、Registrar インターフェイス名、一意の OID、および NVlist を渡します。

    4. BEA Tuxedo システムはルーティング・テーブルの内容を NVlist の値と比較して、グループ ID を判別します。

    5. BEA Tuxedo システムは、オブジェクト・リファレンスにグループ ID を挿入します。

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

    注記 Process-Entity デザイン・パターンを使用する場合は、ファクトリ・ベース・ルーティングのインプリメンテーションに注意してください。オブジェクトは、グループのデータベースに格納されているエンティティしか処理できません。

    Registrar および Teller オブジェクトに関する設計上の追加考慮事項

    Registrar および Teller オブジェクトの設計に影響する主な考慮事項には、以下のものがあります。

    これらの考慮事項の主要な意味は、これらのオブジェクトが次の項目を満たす必要があるということです。

    以降の節では、これらの検討事項およびその内容について詳しく説明します。

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

    Production サンプル・アプリケーションの前に扱った University サーバ・アプリケーションでは、Registrar および Teller オブジェクトの実行時の振る舞いは簡単なものでした。

    しかし、University および Billing サーバ・プロセスが複製されると、BEA Tuxedo ドメインには Registrar および Teller オブジェクトの複数のインスタンスを区別する方法が必要になります。つまり、1 つのグループで 2 つの University サーバ・プロセスが実行中である場合、BEA Tuxedo ドメインには、いわば、1 番目の University サーバ・プロセスで実行中の Registrar オブジェクトと、2 番目の University サーバ・プロセスで実行中の Registrar オブジェクトを区別するための方法が必要になります。

    これらのオブジェクトの複数のインスタンスを区別する機能を BEA Tuxedo ドメインに与える方法は、オブジェクトの各インスタンスを一意にすることです。

    各 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 セットを送信します。先に説明したように、ファクトリ・ベース・ルーティングは、Registrar オブジェクトへのリファレンスが作成されている方法によって RegistrarFactory オブジェクトにインプリメントされています。

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

    1. クライアント・アプリケーションは、RegistrarFactory オブジェクトの find_registrar() オペレーションを呼び出します。この要求には学生 ID 1000003 が含まれます。

    2. BEA Tuxedo ドメインは、クライアント要求を任意の RegistrarFactory オブジェクトにルーティングします。

    3. RegistrarFactory オブジェクトは、UBBCONFIG ファイルのルーティング情報に基づいて、学生 ID を使用して ORA_GRP1 の Registrar オブジェクトへのオブジェクト・リファレンスを作成し、このオブジェクト・リファレンスをクライアント・アプリケーションに返します。

    4. クライアント・アプリケーションは、Registrar オブジェクトの register_for_courses() オペレーションを呼び出します。

    5. BEA Tuxedo ドメインは、クライアント要求を受信してから、それをオブジェクト・リファレンスで指定されているサーバ・グループへルーティングします。この場合、クライアント要求は Production マシン 1 にある ORA_GRP1 の University サーバ・プロセスに送信されます。

    6. University サーバ・プロセスは、Registrar オブジェクトをインスタンス化し、それにクライアント呼び出しを送信します。

    以上のシナリオの RegistrarFactory オブジェクトがクライアント・アプリケーションに返すのは、ORA_GRP1 でだけインスタンス化できる Registrar オブジェクトへの一意なリファレンスです。ORA_GRP1 は Production マシン 1 で実行されていて、学生 ID が 100001 〜 100005 の範囲の学生に関するデータが格納されているデータベースを利用します。このため、続けてクライアント・アプリケーションが学生に関する Registrar オブジェクトへの要求を送信したとき、Registrar オブジェクトは適切なデータベースとやり取りができます。

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

    Registrar オブジェクトで Teller オブジェクトが必要になると、Registrar オブジェクトは TellerFactory オブジェクトを呼び出します。このとき、University Server オブジェクトでキャッシュされている TellerFactory オブジェクト・リファレンスが使用されます。詳細については、第 7 章の 13 ページ「Teller オブジェクトへの要求の送信」を参照してください。

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

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

     

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

    将来的には、Production サンプル・アプリケーションのシステム管理者が BEA Tuxedo ドメインの容量を増やす必要を感じる場合もあります。たとえば、University で学生数が大幅に増加した場合や、7 つのキャンパスがある大学の全体のコース登録処理を扱えるように Production アプリケーションをスケール・アップする場合などが考えられます。これを行うのに、アプリケーションを修正したり再ビルドしたりする必要はありません。

    継続的に容量を追加するために、システム管理者には以下のツールが用意されています。

    注記 データベースを使用するアプリケーションの容量を増やす場合、特にファクトリ・ベース・ルーティングを使用しているときには、データベースの設定に与える影響を検討する必要があります。たとえば、Production サンプル・アプリケーションが 6 台のマシン間に分散している場合は、UBBCONFIG ファイルのルーティング・テーブルに基づいて、適切に各マシンのデータベースを設定する必要があります。

     

    状態を持たないオブジェクトまたは状態を持つオブジェクトの選択

    一般に、状態を持たないオブジェクトをインプリメントする際のコストと、状態を持つオブジェクトをインプリメントする際のコストを比較する必要があります。

    オブジェクトをその永続状態で初期化するコストが高い場合 (これは、たとえば、そのオブジェクトのデータが大きな領域を占めている場合や、永続状態の場所が、それを活性化するサーバントから大幅に離れたディスク上である場合ですが)、たとえオブジェクトが会話の間アイドル状態であるとしても、オブジェクトが状態を持たないようにしておく方が合理的です。オブジェクトを活性化されたままにしておくコストが、マシンのリソース使用率との関連で高額になる場合は、そのようなオブジェクトは状態を持たないようにするほうが合理的です。

    オブジェクトの状態を、アプリケーションに合わせて効率的かつ適切な方法で管理することにより、アプリケーションの能力を最大限に高めて、多数のオブジェクトを使用する多数のクライアント・アプリケーションを同時にサポートできます。一般には、こうした目的のために、オブジェクトに対して method 活性化方針を割り当てます。こうすることによって、アイドル状態のオブジェクト・インスタンスが非活性化され、マシンのリソースをほかのオブジェクト・インスタンスに割り当てられるようになります。ただし、使用するアプリケーション固有の特性および要件は、アプリケーションごとに異なります。

    注記 BEA Tuxedo リリース 8.0 では、性能の拡張として、パラレル・オブジェクトのサポートが提供されています。この機能を利用すると、特定アプリケーションのすべてのビジネス・オブジェクトを状態を持たないオブジェクトにすることができます。詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』の「第 3 章 TP フレームワーク」を参照してください。

    状態を持たないオブジェクトが必要な場合

    サーバ・リソースはオブジェクトがアイドル状態のときには絶対に使用されないため、状態を持たないオブジェクトは一般に、サーバ・リソースの性能を高め、最適な使い方を実現します。状態を持たないオブジェクトは、一般に、サーバ・アプリケーションのインプリメンテーションに適した手法です。状態を持たないオブジェクトは、特に以下の状況に適しています。

    オブジェクトを状態を持たないようにすることで、サーバ・アプリケーションのリソースがクライアント・アプリケーションからの入力の待機のために不定期に長時間拘束されないようにできます。

    状態を持たないオブジェクト・モデルを使用するアプリケーションでは、次の特性に注意してください。

    状態を持つオブジェクトが必要な場合

    状態を持つオブジェクトは、いったん活性化されると、オブジェクトが存在しているプロセスがシャットダウンされたり、オブジェクトが活性化されているトランザクションが完了したりといった、特定のイベントが発生するまで、メモリ内にとどまります。

    状態を持つオブジェクトは、一般に以下の状況に適しています。

    注記 プロセス・オブジェクトをトランザクションにどのように関与させるかについては、注意深く検討してください。トランザクションに関与しているすべてのオブジェクトは、ほかのクライアント・アプリケーションまたはオブジェクトから呼び出せません。プロセス・オブジェクトは多数のクライアント・アプリケーションによって利用されるので、トランザクションに対して頻繁に、または長期間関与すると、問題の原因になる可能性があります。

    状態を持つオブジェクトの以下の振る舞いに注意してください。

     

    Back to Top Previous Next
    dev2devesupportedocs.bea.compartner net
    Contact e-docsContact BEAwebmasterprivacy