|
|
|
|
|
|
CORBA Domains の計画とコンフィギュレーション
BEA Tuxedo CORBA 環境の Domains は、コア ATMI BEA Tuxedo 環境の Domains を拡張したものです。ドメインは、完全に管理可能な構造体です。ドメインを参照するプログラミング・インターフェイスはありません。ドメイン関連の設定は、すべてコンフィギュレーション・ファイルで指定されます。この設定を行うのは管理者だけです。
この章は、以下の節で構成されています。
マルチ・ドメイン環境 CORBA Domains の概要
企業には、地理的に分けられたアプリケーションや、業務別のアプリケーションなど、さまざまなアプリケーションがあるため、多数の独立したドメインが存在します。各ドメインは通常、個別のユニットとして管理されています。つまり、地理的条件 (マシンが存在する場所) や組織上の部門 (経理部門、生産部門、発送部門など) ごとに管理されています。
各企業では、このようなドメイン上のさまざまなアプリケーションを統合することが求められています。通常、1 つのドメインを拡張して企業全体の業務をカバーすることは可能です。ただし、1 つのドメイン内のマシン数やサービス数を大幅に増やすのは、現実的ではありません。シングル・ドメインでは、ドメイン全体を管理する必要があるため、コンフィギュレーションが急速に肥大化し、アプリケーションの開発やインプリメントより多くの労力がかかります。
したがって、ドメインを管理しやすいサイズに抑えるには、アプリケーションを複数のドメインに分散し、さらに、各ドメインのアプリケーションからほかのドメインのサービスにアクセスできるようにする必要があります。このようなドメイン間の通信機能を総称して「BEA Tuxedo ドメイン」と呼びます。
ドメイン間通信
次の図は、単純なマルチ・ドメイン・コンフィギュレーションを示しています。
マルチ・ドメイン・コンフィギュレーション
以下は、クライアント X とドメイン A 間のシングル・ドメイン通信の手順です。
注記 上の手順では、クライアントはオブジェクトの位置や、所属先のドメインを認識していません。クライアント・マシンは単純な構造で、必要なインフラストラクチャも少ないため (大部分はスタンドアロン)、クライアントをドメイン A に接続するための管理は比較的単純です。クライアントの主な管理タスクは BEA Tuxedo ドメインへの接続ですが、実際の管理タスクは、ドメイン A 内の ISL のアドレスを設定することです。
マルチ・ドメイン通信では、Q1 はドメイン C にあるオブジェクト R1 のサービスを要求するので、ドメインの境界をまたいで上の手順 1 〜 4 に対応する処理を実行する必要があります。実際の手順は以下のようになります。
注記 クライアント X で、オブジェクト Q1 がドメイン C のファクトリとオブジェクトを取得するには、何らかの管理タスクが必要です。図 31 に示すように、ドメイン間通信にはドメイン・ゲートウェイを使用します。ドメイン・ゲートウェイは、ドメイン内のシステム・サーバです。
システム・サーバは、ユーザ定義のサーバとは異なり、ネーム・サーバ、FactoryFinder、ISL などと共に BEA Tuxedo 製品の一部として提供されています。ドメイン・ゲートウェイは、ドメインの接続ポイントになるので、概念的には ISL と似ています。ただし、ISL と異なり、ドメイン・ゲートウェイは別のドメイン・ゲートウェイに接続し、それ自身がドメインの接続ポイントになります。つまり、ドメイン・ゲートウェイの役割は、別のドメイン・ゲートウェイに接続することです。したがって、2 つのドメイン・ゲートウェイは相互に協調し合い、別のドメインに存在するオブジェクトの呼び出しが、適切なドメインに確実にルーティングされるようにします。
ドメイン・ゲートウェイがこのような役割を果たすには、適切なコンフィギュレーションが必要です。次の節では、このコンフィギュレーションについて説明します。
マルチ・ドメイン・コンフィギュレーションの要素
マルチ・ドメイン・コンフィギュレーションは、以下の要素で構成されます。
UBBCONFIG ファイルでは、ドメイン名を指定し、ドメイン・ゲートウェイ・サーバのグループ・エントリとサービス・エントリを設定します。UBBCONFIG ファイルでは、ドメイン・ゲートウェイの属性は指定しません。これらの属性はすべて DMCONFIG ファイルで指定します。
ドメイン・コンフィギュレーション・ファイル (DMCONFIG) では、ローカル・ドメインに接続されるリモート・ドメインを指定します。DMCONFIG ファイルがないと接続が確立されません。
1 つまたは複数のドメインに接続されたドメインごとに、1 つの FactoryFinder ドメイン・コンフィギュレーション・ファイル (factory_finder.ini) が必要です。ドメインが別のドメインに接続されていない場合、このファイルは必要ありません。
このファイルでは、ドメインの境界をまたいで検索するファクトリを指定します。factory_finder.ini ファイルと DMCONFIG ファイルには、同じ接続先ドメインの情報を指定し、どちらも同じ接続を実現をできるようにする必要があります。
BEA Tuxedo ドメインの主な機能は、CORBA ドメインのアプリケーションが、別のドメインのオブジェクトを呼び出す際に、クライアントまたはサーバ・アプリケーションがドメインを意識せずに処理できるようにすることです。ドメインの境界をまたぐこのような呼び出しを、アプリケーションがドメインの境界を意識せずに実行するには、さまざまなコンフィギュレーション情報が必要です。
リモート・ドメインのオブジェクト・リファレンスを呼び出すことができるかどうかは、ドメインごとに、UBBCONFIG、DMCONFIG、および factory_finder.ini の 3 つのコンフィギュレーション・ファイルが適切に設定され、これらの内 DMCONFIG と factory_finder.ini の 2 つのコンフィギュレーション・ファイルがドメイン間で対応しているかどうかによって決まります。ドメインの数が増えるほど、このような調整も複雑になります。
オブジェクト・リファレンスを使用して、ローカル・ドメインまたはリモート・ドメインを指定できます。FactoryFinder がリモート・ドメイン内のファクトリに対するオブジェクト・リファレンスを返すと、通常リモート・ドメインの参照が発生します。また、ファクトリがそのリモート・ドメインのオブジェクト・リファレンスを作成して返しても、リモート・ドメインの参照が発生します (ただし、ファクトリのドメインに対するローカル参照になります)。
注記 アプリケーションは、オブジェクト・リファレンスのドメインを認識しません。つまり、アプリケーション側では、オブジェクト・リファレンスが参照するドメインを見つけられません。したがって、リモート・ドメインに対するオブジェクト・リファレンスの呼び出しは、アプリケーションに対して透過的に行われます。この透過性により、管理者は各ドメインのサービスを自由に設定し、複数のドメイン間にリソースを分散することができます。ドメインに関する情報がアプリケーションに存在する場合、コンフィギュレーションを変更すると、アプリケーションも同様に作成し直す必要があります。
ローカル・ドメインのサーバから別のドメインのオブジェクト・リファレンスを取得する場合、アプリケーション側では、ローカル・ドメインのオブジェクト・リファレンスを取得する場合と同じ方法で FactoryFinder を使用します。アプリケーション側では、FactoryFinder が別のドメインのファクトリに対するリファレンスを返したことが認識されないので、同じ方法が使用されます。コンフィギュレーション・ファイルには、このことは示されません。
FactoryFinder またはファクトリによってオブジェクト・リファレンスが取得されると、そのオブジェクト・リファレンスを任意の転送先に渡すことができます。たとえば、ローカル・ドメインのオブジェクトに渡したり、クライアントに返したり、別のドメインに渡すことができます。
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|