| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo Domains コンポーネント > Domains について |
|
Tuxedo Domains コンポーネント
|
Domains について
以下の節では、BEA Tuxedo Domains コンポーネントの概要を説明します。
BEA Tuxedo の Domains コンポーネントとは
企業のビジネスが拡大するに従って、機能、地理、機密度に基づいて分かれている、それぞれが管理上独立したアプリケーションにビジネス情報管理を取り入れる必要が出てきます。それらの独立したビジネス・アプリケーションはドメインと呼ばれ、情報を共有する必要があります。BEA Tuxedo Domains コンポーネントはビジネスのドメイン間で相互運用を実現するインフラストラクチャを提供し、それによって BEA Tuxedo クライアント/サーバ・モデルが複数のトランザクション処理 (TP) ドメインに拡張されます。次の図は、BEA Tuxedo Domains コンポーネントによって、どのようにして複数のドメインが結び付けられるのかを示しています。
図 1-1 BEA Tuxedo Domains コンポーネントを使用したドメイン間通信
ドメイン間の相互運用性 リモート・ドメインのサービスをローカル・ドメインのユーザが透過的に利用できるようにしたり、ローカル・ドメインのサービスをリモート・ドメインのユーザが利用できるようにすることで、BEA Tuxedo Domains コンポーネントは企業のビジネス・アプリケーションの間にある壁を取り払います。また、Domains コンポーネントを利用することで、BEA Tuxedo アプリケーションを実行する企業は、ほかのトランザクション処理 (TP) システム (BEA 社の WebLogic Server、BEA 社の TOP END、IBM/Transarc の Encina、IBM の CICS など) で動作するアプリケーションとの相互運用を実現してビジネスを拡張することができます。 企業ではビジネス・アプリケーションの性質をその名前の一部としてよく使用するので、アプリケーションの名前は「課金ドメイン」や「オーダ・エントリ・ドメイン」のようになります。BEA Tuxedo ドメインは、UBBCONFIG という 1 つのコンフィギュレーション・ファイルで制御される単一コンピュータまたは複数コンピュータのネットワークです。BEA Tuxedo のコンフィギュレーション・ファイルには、どのよう名前でも付けられます。ただし、そのファイルの内容は『BEA Tuxedo のファイル形式とデータ記述方法』の UBBCONFIG(5) リファレンス・ページで指定された形式に準拠している必要があります。BEA Tuxedo ドメインは、1 つのユニットとして管理されます。 ドメイン・ゲートウェイの種類 BEA Tuxedo Domains コンポーネントは、各種のネットワークおよびドメインと通信するためのさまざまなゲートウェイを提供します。具体的には、Domains コンポーネントでは以下のドメイン・ゲートウェイが提供されます。
これ以降は、BEA TDomain ゲートウェイおよび BEA Tuxedo ドメイン間の通信を中心に説明します。WTC ゲートウェイについては、次のドキュメントを参照してください。
TEDG ゲートウェイについては、『ATMI アプリケーションでの BEA Tuxedo TOP END Domain Gateway の使用』を参照してください。BEA eLink のゲートウェイについては、 の『BEA eLink Documentation』を参照してください。
Domains コンフィギュレーションの例
次の図は、ドメインが 4 つのサンプル Domains コンフィギュレーションを示しています。そのうちの 3 つは BEA Tuxedo ドメインです。
図 1-2 銀行業務の Domains コンフィギュレーションの例
図の一番下にある BEA Tuxedo クレジット・カード認可センターには、bankgw1 という TDomain ゲートウェイ・グループと bankgw2 という OSI TP ゲートウェイ・グループの 2 つのゲートウェイ・グループがあります。bankgw1 は、ネットワーク・プロトコル TCP/IP を使用して 2 つのリモート BEA Tuxedo ドメイン (ABC 銀行と CBA 銀行) へのアクセスを提供します。bankgw2 は、ネットワーク・プロトコル OSI TP を使用して 1 つのリモート・ドメイン (XYZ 銀行) へのアクセスを提供します。 この例では、別のドメインである ABC 銀行が、クレジット・カード認可システムに対するサービス要求を生成しています。その要求は、グループ bankgw1 で動作している GWTDOMAIN というドメイン・ゲートウェイ・サーバ・プロセスによって受信されます。このゲートウェイは、ローカルで動作している別のサーバ・プロセスが提供するクレジット・カード認可サービスに対し、リモート・ドメインの代わりにサービス要求を発行します。このサーバは、要求を処理してから、応答をゲートウェイに送信します。ゲートウェイは、応答を ABC 銀行に転送します。 クレジット・カード認可センターからサービス要求を発行することもできます。たとえば認可センターは、GWOSITP というドメイン・ゲートウェイ・サーバ・プロセスを通じて XYZ 銀行に残高照会を要求できます。 BEA Tuxedo Domains コンポーネントは、リモート・サービス (ほかのドメインのサービス) をローカル・サービスであるかのように宣言するドメイン・ゲートウェイ・サーバ・プロセスを通じてドメイン間通信を実現します。
ドメイン・ゲートウェイでサポートされる機能
ドメイン・ゲートウェイでは、次の機能がサポートされています。
ローカル・ドメインとリモート・ドメイン間での要求/応答型の通信
ドメイン・ゲートウェイは、ATMI インターフェイスで定義された要求/応答型のモデルをサポートしています。論理的に 1 つのアプリケーション内で使用するよう制限されており、ドメイン間での使用はサポートされていない以下の BEA Tuxedo ATMI 関数を除いて、BEA Tuxedo アプリケーションはローカル・サービスの場合とまったく同じようにリモート・サービスを要求できます。
アプリケーションの移植性を維持するため、tpforward(3c) がサポートされています。転送された要求は、ドメイン・ゲートウェイにより、単純なサービス要求として解釈されます。次の図は、このプロセスを示しています。この図では、tpforward を使用して、リモート・サービスを要求する簡単な流れを示します。
図 1-3 tpforward を使用してリモート・サービスに要求を送信する
BEA Tuxedo 要求/応答型モデルの詳細については、『BEA Tuxedo システム入門』の2-13 ページの「要求/応答型通信」を参照してください。 ローカル・ドメインとリモート・ドメイン間での会話型通信 ドメイン・ゲートウェイは、ATMI インターフェイスで定義された会話型のモデルをサポートしています。ATMI は接続指向型のインターフェイスです。このインターフェイスを使用すると、クライアントは、会話型モデルでプログラミングされたサービスとの会話を確立し、保持することができます。 BEA Tuxedo アプリケーションは、tpconnect(3c) を使用してリモート・サービスとの会話を確立し、tpsend(3c) と tprecv(3c) を使用してこのサービスと通信し、tpdiscon(3c) を使用して会話を終了します。ドメイン・ゲートウェイは、リモート・サービスとの会話を保持し、BEA Tuxedo の会話型サービスの定義と同じ方法で戻り値 (TPSUCCESS または TPFAIL を返す tpreturn) を返し、接続を切断します。 注記 接続指向型の ATMI 関数では、半二重会話を使用できます。会話サービスでは tpforward(3c) を使用できません。 BEA Tuxedo 会話型モデルの詳細については、『BEA Tuxedo システム入門』の2-14 ページの「会話型通信」を参照してください。 リモート・ドメインでのメッセージのキュー登録 ドメイン・ゲートウェイは、ATMI インターフェイスで定義されたキューの処理モデルをサポートしています。クライアントやサーバはどれも、リモート・ドメインのキューにメッセージまたはサービス要求を格納できます。格納された要求はすべて、安全性を確保するため、トランザクション・プロトコルを使用して送信されます。 BEA Tuxedo システムでは、メッセージを永続記憶域 (ディスク) や非永続記憶域 (メモリ) に登録して、後で処理や検索を行うことができます。ATMI には、メッセージをキューに追加 (tpenqueue) したり、キューから読み取る (tpdequeue) ためのプリミティブが用意されています。応答メッセージやエラー・メッセージをキューに登録しておき、後でクライアントに返すこともできます。キューの作成、一覧表示、および変更を行うための管理コマンド・インタプリタ (qmadmin) も用意されています。また、メッセージをキューに登録したり、キューから取り出す要求を受け付けるサーバ (TMQUEUE サーバ)、キューから取り出したメッセージを処理するために転送するサーバ (TMQFORWARD サーバ)、およびキューの処理を伴うトランザクションを管理するサーバ (TMS_QM サーバ) の 3 つのサーバが用意されています。 BEA Tuxedo キューの処理モデルの詳細については、『BEA Tuxedo システム入門』の2-15 ページの「メッセージ・キューイング通信」を参照してください。 Domains の符号化および復号化操作 ドメイン・ゲートウェイは、ドメイン・ゲートウェイ・サーバ・プロセスが実行されているリリースの BEA Tuxedo システム・ソフトウェアによってサポートされているすべての定義済み型付きバッファをサポートします。リリース 8.1 の BEA Tuxedo は、11 種の定義済みバッファ型をサポートしています。 BEA Tuxedo リリースでサポートされている各バッファ型には、プログラマの介入なしで初期化、メッセージの送受信、およびデータの符号化/復号化を行うために自動的に呼び出すことができるそれ独自のルーチン・セットがあります。それらのルーチンは、型付きバッファ・スイッチと呼ばれます。 BEA Tuxedo ATMI アプリケーションでは、クライアントとサーバとの間でデータ (サービス要求と応答) を送信するために型付きバッファが使用されます。その名前のとおりそれ自身についての情報 (メタデータ) が含まれている型付きバッファにより、アプリケーション・プログラマは、アプリケーションのクライアント側およびサーバ側で稼動中のマシンのデータ表現スキーマを意識せずにデータを転送することができます。 ドメイン・ゲートウェイは、ワークステーション、ローカルの BEA Tuxedo マシン、およびリモート・ドメインから送信されるサービス要求を受信し、処理できます。ドメイン・ゲートウェイは、次の理由により、符号化されている受信したすべてのサービス要求を適切な型付きバッファ・スイッチを使用して復号化します。
OSI 用語では、抽象構文 (データの構造) と転送構文 (データ転送に使用する特定の符号化) を明確に区別します。各型付きバッファでは、特定のデータ構造 (抽象構文) と、そのデータ構造を特定の転送構文 (たとえば XDR) にマッピングするのに必要な符号化規則 (型付きバッファの動作) を暗黙的に定義します。符号化/復号化をサポートする定義済みのバッファ型について、BEA Tuxedo システムではそれらの型を XDR 転送構文にマッピングするための符号化規則が用意されています。
型付きバッファおよび符号化/復号化操作の詳細については、『BEA Tuxedo システム入門』の2-27 ページの「型付きバッファ」を参照してください。
BEA Tuxedo Domains のアーキテクチャ
BEA Tuxedo Domains のアーキテクチャは、主に次の 4 つの要素で構成されています。
Domains コンフィギュレーション・ファイル
Domains コンフィギュレーションは、BEA Tuxedo Domains コンポーネントを介して通信したりサービスを共有したりできる複数のドメイン (アプリケーション) の集合です。複数のドメインがどのように接続されるのか、およびどのサービスが互いに利用可能になるのかは、Domains コンフィギュレーション・ファイルで定義します。Domains コンフィギュレーションに関与する各 BEA Tuxedo ドメインでは、それ専用の Domains コンフィギュレーション・ファイルが必要です。
テキスト形式の Domains コンフィギュレーション・ファイルは DMCONFIG ファイルと呼ばれますが、任意の名前を付けることもできます。ただし、そのファイルの内容が『BEA Tuxedo のファイル形式とデータ記述方法』の DMCONFIG(5) リファレンス・ページで説明されている形式に準拠している場合に限ります。バイナリ形式の Domains コンフィギュレーション・ファイルは、BDMCONFIG と呼ばれます。DMCONFIG ファイルの詳細については、Domains コンフィギュレーション・ファイルを参照してください。
ドメイン・ゲートウェイ・サーバ
BEA Tuxedo Domains コンポーネントは、非同期性の高い、マルチタスク型およびマルチスレッド型のドメイン・ゲートウェイ・プロセスを使用してマルチ・ドメインの相互運用性を実現します。そのドメイン・ゲートウェイ・プロセスは、アプリケーション・プログラマとアプリケーション・ユーザが両方とも別のドメインのサービスに透過的にアクセスできるようにする BEA Tuxedo 提供サーバです。
次の図は、1 つの BEA Tuxedo ドメインが、ドメイン・ゲートウェイを介して別のドメインと通信する方法を示しています。
図 1-4 ゲートウェイを介した双方向通信
この図では、ドメイン・ゲートウェイがクレジット・カードの認可要求を処理し、別のドメインに送信する様子を示しています。このゲートウェイは、認可要求に対する応答も処理します。 Domains 管理サーバ 次の図は、Domains コンフィギュレーションを管理するために使用される BEA Tuxedo Domains 管理サーバを示しています。 図 1-5 Domains 管理サーバ
ドメイン・ゲートウェイ・グループは、前の図で示されているように、ゲートウェイ管理サーバ (GWADM)、ドメイン・ゲートウェイ・サーバ (GWTDOMAIN など)、および (オプションの) Domains トランザクション・ログ (TLOG) で構成されます。GWADM サーバは、ドメイン・ゲートウェイの実行時における管理を可能にします。BEA Tuxedo ドメインは、ドメイン・ゲートウェイ・グループを通じて 1 つ以上のリモート・ドメインと通信できます。 BEA Tuxedo ドメインで動作するすべてのドメイン・ゲートウェイ・グループと関連付けられているのは、Domains 管理サーバ (DMADM) です。Domains 管理サーバは、BEA Tuxedo Domains コンフィギュレーション・ファイル (BDMCONFIG) の実行時における管理を可能にします。 GWADM サーバ GWADM(5) サーバは、DMADM サーバに登録して、対応するゲートウェイ・グループで使用されるコンフィギュレーション情報を取得します。GWADM は、DMADMIN サービスからの要求、つまり、指定したゲートウェイ・グループの実行時オプションでの統計情報や変更に対する要求を受け付けます。DMADMIN サービスは、DMADM によって宣言された汎用管理サービスです。GWADM は、定期的に "I-am-alive" メッセージを DMADM サーバに送信します。DMADM から応答がなければ、GWADM は再度登録を行います。このプロセスにより、GWADM サーバは、そのゲートウェイ・グループの Domains コンフィギュレーションに関する最新の情報を常に保持できます。 GWADM の詳細については、Domains の管理 を参照してください。 DMADM サーバ DMADM(5) サーバは、ゲートウェイ・グループの登録サービスを提供します。このサービスは、GWADM サーバの初期化プロシージャの一部として GWADM サーバによって要求されます。登録サービスは、要求元のゲートウェイ・グループが要求するコンフィギュレーション情報をダウンロードします。DMADM サーバは、登録済みのゲートウェイ・グループのリストを管理し、Domains コンフィギュレーション・ファイル (BDMCONFIG) が変更されると、変更内容をリスト内のゲートウェイ・グループに伝播します。 DMADM の詳細については、Domains の管理 を参照してください。 Domains 管理ツール 次の Domains 管理ツールは、Domains コンフィギュレーションの設定と管理のために BEA Tuxedo システムによって提供されます。
次の図は、Domains 管理ツールと Domains のテキスト形式およびバイナリ形式のコンフィギュレーション・ファイルの関係を示しています。dmadmin ユーティリティを使用する管理は、DMADM サーバで宣言される DMADMIN サービスを通じて行います。
dmloadcf コマンド dmloadcf(1) コマンドは、DMCONFIG ファイルを解析して、その情報を BDMCONFIG にロードします。このコマンドは、環境変数 BDMCONFIG を使用して、コンフィギュレーションが格納されるデバイス・ファイルまたはシステム・ファイルの名前を示します。 dmloadcf コマンドに -c オプションを指定して実行すると、コンフィギュレーションで指定された各ローカル・ドメインに必要なプロセス間通信 (IPC) 資源の量を計算できます。 dmloadcf コマンドは、DMTYPE ファイル (Windows の場合は %TUXDIR%¥udataobj¥DMTYPE、UNIX の場合は $TUXDIR/udataobj/DMTYPE) をチェックして、Domains コンフィギュレーション・ファイルで指定されたドメイン・ゲートウェイ・タイプが有効であるかどうかを検証します。各タイプのドメイン・ゲートウェイには、DMTYPE ファイルでタグとして使用されるドメイン・タイプ指定子 (TDOMAIN、TOPEND、SNAX、OSITP、OSITPX) があります。ファイル内の各行の形式は、次のとおりです。 dmtype:access_module_lib:comm_libs:tm_typesw_lib:gw_typesw_lib このファイルには、次のような TDomain ゲートウェイ用のエントリがあります。 dmloadcf の詳細については、『BEA Tuxedo コマンド・リファレンス』の dmloadcf(1) リファレンス・ページを参照してください。 dmunloadcf コマンド dmunloadcf(1) コマンドは、BDMCONFIG コンフィギュレーション・ファイルをバイナリ形式からテキスト形式に変換して、標準出力に出力します。dmunloadcf の詳細については、『BEA Tuxedo コマンド・リファレンス』の dmunloadcf(1) リファレンス・ページを参照してください。 dmadmin コマンド dmadmin(1) コマンドは、BEA Tuxedo の管理者が Tuxedo の実行中にドメイン・ゲートウェイを設定、監視、およびチューニングできるようにします。このコマンドは、管理コマンドを変換して要求を DMADMIN サービス (DMADM サーバにより宣言される汎用管理サービス) に送信する管理コマンド・インタプリタとしても機能します。この結果、DMADMIN サービスは、BDMCONFIG ファイル内の情報を検証、取得、または更新する関数を呼び出します。 -c オプションを指定して dmadmin を呼び出すと、BDMCONFIG ファイルが動的に更新されます。変更されるコンフィギュレーションに応じて、一部の更新はすぐに行われ、ほかの更新はその更新で影響を受けるものが新しく発生したときにのみ行われます。 dmadmin の詳細については、Domains の管理を参照してください。
TDOMAIN:-lgwt:-lnwi -lnws -lnwi::
Domains コンフィギュレーション・ファイル
Domains コンフィギュレーションに関与する各 BEA Tuxedo ドメインには、ドメイン間パラメータの定義されるコンフィギュレーション・ファイルがあります。テキスト形式のコンフィギュレーション・ファイルは DMCONFIG と呼ばれますが、コンフィギュレーション・ファイルには任意の名前を付けることができます。ただし、そのファイルの内容が『BEA Tuxedo のファイル形式とデータ記述方法』の DMCONFIG(5) リファレンス・ページで説明されている形式に準拠している場合に限ります。典型的なコンフィギュレーション・ファイル名は、文字列 dm で始まり、その後にファイル名 dmconfig の config のようなニーモニック文字列が続きます。
Domains コンフィギュレーションの管理者は、コンフィギュレーションに参加する BEA Tuxedo ドメインごとに別個の DMCONFIG ファイルを作成する必要があります。 DMCONFIG ファイルは、任意のテキスト・エディタで作成および編集できます。
DMCONFIG ファイルの場所
Domains コンフィギュレーションに関与する BEA Tuxedo ドメインの DMCONFIG ファイルは、Tuxedo ドメインの UBBCONFIG ファイルで指定されているとおりに、Domains 管理サーバ DMADM が実行されるマシン上に配置されます。DMADM サーバは、Tuxedo ドメインのどのマシン (マスタ・マシン、非マスタ・マシン) でも実行できます。
注記 BEA Tuxedo ドメインのマスタ・マシンは、ドメインの UBBCONFIG ファイルが格納され、UBBCONFIG ファイルの RESOURCES セクションでマスタ・マシンとして指定されます。Tuxedo ドメインは、マスタ・マシンを使用して起動、停止、および管理します。
バイナリ形式の DMCONFIG ファイル
BDMCONFIG ファイルは、DMCONFIG ファイルのバイナリ形式です。dmloadcf コマンドを実行することで作成されます。このコマンドは、DMCONFIG を解析して、バイナリ形式の BDMCONFIG ファイルを BDMCONFIG 環境変数で示された位置にロードします。DMCONFIG と同じように、BDMCONFIG ファイルにも任意の名前を付けることができます。その実際の名前は、BDMCONFIG 環境変数で指定されたデバイス・ファイル名またはシステム・ファイル名です。BDMCONFIG 環境変数は、BDMCONFIG がロードされるデバイス・ファイル名またはシステム・ファイル名で終わる絶対パス名に設定する必要があります。
UBBCONFIG のバイナリ形式である TUXCONFIG ファイルと違って、BDMCONFIG ファイルは Tuxedo アプリケーションの起動時に Tuxedo ドメインのほかのどのマシンにも複製転送されません。BDMCONFIG ファイルを Tuxedo ドメインのほかのマシンにも配置するためには、そのドメインの管理者が手作業で配置する必要があります。
DMCONFIG ファイルのセクションの記述
DMCONFIG ファイルは、複数の指定セクションで構成されます。セクションは、アスタリスク (*) が先頭に付いた行から始まります。アスタリスク (*) の直後にはセクション名が表示されます。セクション名を指定するときにはアスタリスクが必要です。
使用可能なセクションは、
注記 DM_LOCAL セクションは、DM_REMOTE セクションの前に置く必要があります。
Domains コンフィギュレーションの管理者は、以上のセクションを以下の目的で使用します。
次の図は、いまここで説明している作業の単純な例です。
図 1-7 2 つの BEA Tuxedo ドメインで共有されるサービスを確定する―例
この例では、ドメイン X に作成された DMCONFIG ファイルを補うドメイン Y の DMCONFIG ファイルも作成する必要があります。つまり、ドメイン X の DMCONFIG ファイルのローカル・ドメイン・アクセス・ポイントがドメイン Y の DMCONFIG ファイルでリモート・ドメイン・アクセス・ポイントになり、ドメイン X の DMCONFIG ファイルのリモート・ドメイン・アクセス・ポイントがドメイン Y の DMCONFIG ファイルでローカル・ドメイン・アクセス・ポイントになります。例では、TDomain ゲートウェイ・サーバの使い方が例示されています。 次の表では、DMCONFIG ファイルの各セクションについて説明します。
DMCONFIG ファイルの詳細については、『BEA Tuxedo のファイル形式とデータ記述方法』のリファレンス・ページ DMCONFIG(5) および DM_MIB(5) を参照してください。 DMCONFIG ファイル関連の新しい用語 BEA Tuxedo のリリース 7.1 以降では、Domains 用の MIB で、ローカル・ドメインとリモート・ドメインとの相互作用を記述するため、クラスと属性の用語が改善されています。新しい用語は、DMCONFIG(5) のリファレンス・ページ、セクション名、パラメータ名、エラー・メッセージ、および DM_MIB(5) のリファレンス・ページ、クラス、およびエラー・メッセージで使用されています。 旧バージョンとの互換性のため、BEA Tuxedo 7.1 より以前に使用された DMCONFIG 用語と、改善された Domains 用の MIB 用語との間にエイリアスが提供されています。BEA Tuxedo のリリース 7.1 以降の DMCONFIG では、両方のバージョンの用語を使用できます。次の表では、DMCONFIG ファイルの以前の用語と新しい用語を対比させています。
BEA Tuxedo のリリース 7.1 以降の dmunloadcf コマンドでは、デフォルトで新しいドメイン関連の用語を使用する DMCONFIG ファイルが生成されます。以前のドメイン関連の用語を使用する DMCONFIG ファイルを出力するには、-c オプションを使用します。次に例を示します。 prompt> dmunloadcf -c > dmconfig_prev
Domains データ依存型ルーティングの指定
次のどのバッファ・タイプでも、DMCONFIG ファイルの DM_ROUTING セクションで、ローカルのサービス要求をリモート・ドメインにルーティングするためのデータ依存型ルーティング基準を指定できます。
次の例では、リモート・サービスの TOUPPER は REMOT1 および REMOT2 という 2 つのリモート・ドメイン・アクセス・ポイントを通じて利用でき、TOUPPER のデータ依存型ルーティング基準は ACCOUNT というルーティング基準テーブルで定義されています。例の RTOUPPER1 と RTOUPPER2 は、リモート・ドメインで予期される実際のサービス名 TOUPPER のエイリアスです。
*DM_IMPORT
RTOUPPER1 AUTOTRAN=N
RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
CONV=N
RNAME=“TOUPPER”
ROUTING=ACCOUNT
RTOUPPER2 AUTOTRAN=N
RACCESSPOINT=REMOT2
LACCESSPOINT=LOCAL1
CONV=N
RNAME=“TOUPPER”
ROUTING=ACCOUNT
*DM_ROUTING
ACCOUNT FIELD=branchid
BUFTYPE=“VIEW:account”
RANGES=“MIN-1000:REMOT1,1001-3000:REMOT2”
ACCOUNT ルーティング・テーブルに関して、VIEW と account はこのルーティング・テーブルが有効であるデータ・バッファのタイプとサブタイプで、branchid はルーティングが適用される VIEW データ・バッファのフィールドの名前です。branchid フィールドの有効な値は次のとおりです。
TOUPPER サービス要求の branchid フィールドの値が MIN-1000 の範囲にある場合、サービス要求は REMOT1 アクセス・ポイントを通じてルーティングされます。TOUPPER サービス要求の branchid フィールドの値が 1001-3000 の範囲にある場合、サービス要求は REMOT2 アクセス・ポイントを通じてルーティングされます。
Domains のトランザクション・タイムアウトとブロッキング・タイムアウトの指定
BEA Tuxedo システムには、トランザクション・タイムアウト・メカニズムとブロッキング・タイムアウト・メカニズムの 2 つのタイムアウト・メカニズムがあります。トランザクション・タイムアウトは、サービス要求を処理する ATMI トランザクションの期間を定義するために使用します。このタイムアウト値は、トランザクションを開始するときに定義されます。一方、ブロッキング・タイムアウトは、個々のサービス要求の期間、つまり、サービス要求に対する応答を ATMI アプリケーションが待つ時間を定義するために使用します。
プロセスがトランザクション・モードではない場合、BEA Tuxedo システムによってブロッキング・タイムアウトが実行されます。プロセスがトランザクション・モードである場合は、BEA Tuxedo システムによってトランザクション・タイムアウトが実行されますが、ブロッキング・タイムアウトは実行されません。後者の説明はドメイン内トランザクション (1 つの BEA Tuxedo ドメイン内で処理されるトランザクション) では当てはまりますが、ドメイン間トランザクションでは当てはまりません。ドメイン間トランザクションでは、プロセスがトランザクション・モードである場合、Domains ソフトウェアによってトランザクション・タイムアウトとブロッキング・タイムアウトの両方が実行されます。
Domains コンポーネントによるトランザクション・タイムアウトの処理
BEA Tuxedo のトランザクション・タイムアウト・メカニズムは、Domains コンポーネントにもそのまま適用されます。ドメイン・ゲートウェイはトランザクション・マネージャ・サーバ (TMS) 機能をインプリメントしているため、BEA Tuxedo BBL 管理プロセスで生成される TMS タイムアウト・メッセージの処理を要求されます。したがって、BEA Tuxedo と Domains で使用されるトランザクション・タイムアウトのメカニズムが同じであることが必要となります。
DMCONFIG ファイルの DM_EXPORT セクションでリモート・ドメインから利用できるようにされたローカル・サービスは、ローカル UBBCONFIG ファイルの SERVICES セクションから次のトランザクション関連プロパティを継承します。
同様に、DMCONFIG ファイルの DM_IMPORT セクションでローカル・ドメインから利用できるようにされたリモート BEA Tuxedo サービスは、リモートの UBBCONFIG ファイルの SERVICES セクションから AUTOTRAN プロパティと TRANTIME プロパティを継承します。トランザクションで TRANTIME タイムアウト値を過ぎると、そのトランザクションの影響を受ける BEA Tuxedo ノードによって TMS タイムアウト・メッセージが生成されます。
BEA Tuxedo のリリース 8.1 以降が動作するマシンで宣言されたサービスは、UBBCONFIG ファイルの RESOURCES セクションから MAXTRANTIME という追加的なトランザクション・タイムアウト・プロパティを継承します。MAXTRANTIME タイムアウト値が TRANTIME タイムアウト値またはトランザクションを開始する tpbegin(3c) の呼び出しで渡されたタイムアウト値より小さい場合、トランザクションのタイムアウトは MAXTRANTIME の値に削減されます。MAXTRANTIME は、BEA Tuxedo の 8.0 以前が動作しているマシンで開始されたトランザクションには関係ありません。ただし、BEA Tuxedo の 8.1 以降が動作しているマシンがそのトランザクションの影響を受ける場合、トランザクションのタイムアウト値はそのノードに設定された MAXTRANTIME 値に制限 (必要に応じ削減) されます。
Domains コンフィギュレーションでは、次のトランザクション処理シナリオが考えられます。
TRANTIME または tpbegin() タイムアウト値が MAXTRANTIME 以下である場合、トランザクション処理は前に説明したシナリオになります。
TRANTIME または tpbegin() タイムアウト値が MAXTRANTIME より大きい場合、トランザクションのタイムアウト値は影響を受けるノードによって MAXTRANTIME に削減されます。MAXTRANTIME タイムアウト値を過ぎると、影響を受けるノードで TMS タイムアウト・メッセージが生成されます。
MAXTRANTIME の詳細については、UBBCONFIG(5) の RESOURCES セクションの MAXTRANTIME、または TM_MIB(5) の T_DOMAIN クラスの TA_MAXTRANTIME を参照してください。
Domains コンポーネントによるブロッキング・タイムアウトの処理
BEA Tuxedo のブロッキング・タイムアウト・メカニズムでは、ローカル・マシンで動作する各 BEA Tuxedo クライアント・プロセスまたはサーバ・プロセスに割り当てられたレジストリ・スロット内の情報を使用します。レジストリ・スロットは、各プロセスに 1 つです。レジストリ・スロット内の情報は、BLOCKTIME で指定された期間を過ぎてもブロックされたままの要求元を検出するためにローカルの BBL で使用されます。ドメイン・ゲートウェイ・プロセスは一度に複数のサービス要求を処理できるマルチタスク型サーバなので (複数のレジストリ・スロットが必要)、ドメイン・ゲートウェイではレジストリ・スロット・メカニズムを使用できません。Domains 環境でブロッキング・タイムアウトが発生すると、エラーまたは障害を通知する応答メッセージがドメイン・ゲートウェイから要求元に送信され、サービス要求に関連するあらゆるコンテキストがクリーンアップされます。
DMCONFIG ファイルの DM_LOCAL セクションでは、BLOCKTIME パラメータを使用してローカル・ドメイン・アクセス・ポイントのブロッキング・タイムアウトを設定できます。次に例を示します。
*DM_LOCAL
LOCAL1 GWGRP=GWTGROUP
TYPE=TDOMAIN
ACCESSPOINTID=“BA.CENTRAL01”
BLOCKTIME=30
BLOCKTIME パラメータでは、ATMI ブロッキング呼び出しがブロックされる最大待ち時間を指定します。この時間を過ぎると、タイムアウトになります。ブロッキング・タイムアウト状態は、影響を受けたサービス要求が失敗していることを意味します。
ブロッキング・タイムアウト値は、UBBCONFIG ファイルの RESOURCES セクションで指定された SCANUNIT パラメータの乗数です。値 SCANUNIT * BLOCKTIME は、SCANUNIT 以上、32,767 秒以下である必要があります。
BLOCKTIME が DMCONFIG ファイルで指定されていない場合、デフォルトは UBBCONFIG ファイルの RESOURCES セクションで指定された BLOCKTIME パラメータの値に設定されます。BLOCKTIME パラメータが UBBCONFIG ファイルで指定されていない場合、デフォルトは SCANUNIT * BLOCKTIME が約 60 秒になるように設定されます。
トランザクションの期間が BLOCKTIME を過ぎると、ドメイン間トランザクションでブロッキング・タイムアウト状態が生じます。つまり、ドメイン間トランザクションについては、BLOCKTIME 値が UBBCONFIG ファイルの SERVICES セクションで指定された TRANTIME タイムアウト値、またはトランザクションを開始する tpbegin() の呼び出しで渡されたタイムアウト値より小さい場合、トランザクションのタイムアウトは BLOCKTIME の値に削減されます。その一方で、1 つの BEA Tuxedo ドメイン内で処理されるドメイン内トランザクションの場合、TUXCONFIG ファイルの RESOURCES セクションで指定された BLOCKTIME 値はドメイン内トランザクションのタイムアウトに影響しません。
Domains の接続方針の指定
ユーザは、以下のいずれかの接続方針を選択して、ローカル・ドメイン・ゲートウェイから 1 つ以上のリモート・ドメインへの接続条件を指定できます。
接続方針は、TDomain および TOP END ドメイン・ゲートウェイのみに適用されます。
接続方針の設定方法
DMCONFIG ファイルの DM_LOCAL セクションでは、CONNECTION_POLICY パラメータを使用してローカル・ドメイン・アクセス・ポイントの接続方針を設定します。次に例を示します。
*DM_LOCAL
LOCAL1 GWGRP=GWTGROUP
TYPE=TDOMAIN
ACCESSPOINTID=“BA.CENTRAL01”
BLOCKTIME=30
CONNECTION_POLICY=ON_STARTUP
ローカル・ドメイン・アクセス・ポイントの接続方針を指定しない場合、そのアクセス・ポイントの接続方針はデフォルトで ON_DEMAND になります。
BEA Tuxedo リリース 8.1 以降が動作している TDomain ゲートウェイについては、DMCONFIG ファイルの DM_TDOMAIN セクションでローカルまたはリモート・ドメイン単位で接続方針を設定できます。次に例を示します。
*DM_LOCAL
LOCAL1 GWGRP=GWTGROUP
TYPE=TDOMAIN
ACCESSPOINTID=“BA.CENTRAL01”
BLOCKTIME=30
*DM_TDOMAIN
LOCAL1 NWADDR=“//albany.acme.com:4051”
CONNECTION_POLICY=ON_STARTUP
REMOT1 NWADDR=“//newyork.acme.com:65431”
CONNECTION_POLICY=ON_DEMAND
REMOT2 NWADDR=“//philly.acme.com:65431”
リモート・ドメイン・アクセス・ポイントに指定された接続方針は、ローカル・ドメイン・アクセス・ポイントに指定された接続方針に優先します。このため、前の例の接続方針コンフィギュレーションは次のようになります。
LOCAL1 to REMOT1 - ON_DEMAND
LOCAL1 to REMOT2 - ON_STARTUP
BEA Tuxedo 8.1 以降では、DMCONFIG ファイルの DM_TDOMAIN セクションでローカル・ドメイン・アクセス・ポイントに次のいずれかの接続方針値を指定できます。
ローカル・ドメイン・アクセス・ポイントの接続方針を指定しない場合は、DMCONFIG ファイルの DM_LOCAL セクションで指定されたグローバル接続方針がデフォルトで使用されます。DM_TDOMAIN セクションで指定されたグローバル接続方針は、DM_LOCAL セクションで指定されたグローバル接続方針に優先します。
注記 DM_TDOMAIN セクションでグローバル接続方針を指定する場合は、DM_LOCAL セクションでグローバル接続方針を指定しないでください。
BEA Tuxedo 8.1 以降では、リモート・ドメイン・アクセス・ポイントの接続方針値も、DMCONFIG ファイルの DM_TDOMAIN セクションで次のいずれかから指定できます。
リモート・ドメイン・アクセス・ポイントに LOCAL を指定するか、接続方針を指定しないと、デフォルトでグローバル接続方針が使用されます。
リモート・ドメインの接続方針機能がないと、グローバル接続方針が ON_STARTUP の場合に、ローカル TDomain ゲートウェイはたとえ一部のリモート・ドメインが最初は使用されない場合でも起動時にすべてのリモート・ドメインに接続しようとします。このため、リモート・ドメインの数が多い場合は起動にかなりの時間がかかります。リモート・ドメインの接続方針機能を使用する場合は、グローバル接続方針の ON_STARTUP で、起動時に自動的には確立されないリモート・ドメインの接続を選択できます。
接続再試行プロセスの使用方法
CONNECTION_POLICY が ON_STARTUP に設定されている場合は、ほかの 2 つのパラメータを設定して、ローカル・ドメイン・ゲートウェイがリモート・ドメインへの接続を試行する回数を指定できます。デフォルトでは、ローカル・ドメイン・ゲートウェイは 60 秒おきに失敗した接続を再試行しますが、パラメータ MAXRETRY および RETRY_INTERVAL を使用してこの間隔に別の値を指定することもできます。
MAXRETRY パラメータでは、ドメイン・ゲートウェイがリモート・ドメインへの接続を試行する回数を指定します。最小値は 0、最大値は 2147483647 です。デフォルト設定は 2147483647 です。このパラメータを 0 に設定すると、接続再試行プロセスが無効になります。
RETRY_INTERVAL パラメータでは、リモート・ドメインへの接続を確立する自動的な試みの秒間隔を指定します。最小値は 0、最大値は 2147483647 です。デフォルト設定は 60 です。MAXRETRY パラメータが 0 に設定されている場合、RETRY_INTERVAL は設定できません。
例 1
*DM_LOCAL
LOCAL1 GWGRP=GWTGROUP
TYPE=TDOMAIN
ACCESSPOINTID=“BA.CENTRAL01”
BLOCKTIME=30
CONNECTION_POLICY=ON_STARTUP
MAXRETRY=5
RETRY_INTERVAL=100
例 2 (BEA Tuxedo リリース 8.1 以降が動作する TDomain ゲートウェイでのみ可能)
*DM_LOCAL
LOCAL1 GWGRP=GWTGROUP
TYPE=TDOMAIN
ACCESSPOINTID=“BA.CENTRAL01”
BLOCKTIME=30
*DM_TDOMAIN
LOCAL1 NWADDR=“//albany.acme.com:4051”
CONNECTION_POLICY=ON_STARTUP
MAXRETRY=5
RETRY_INTERVAL=100
REMOT1 NWADDR=“//newyork.acme.com:65431”
CONNECTION_POLICY=ON_STARTUP
MAXRETRY=10
RETRY_INTERVAL=40
2 番目の例で、MAXRETRY および RETRY_INTERVAL の値 10 と 40 は、REMOT1 というリモート・ドメイン・アクセス・ポイントへの接続を確立するためにローカル TDomain ゲートウェイで使用される自動接続再試行の基準になります。
接続方針によるリモート・サービスの可用性の判断
接続方針を指定すると、それによって、リモート・ドメインからインポートされたサービスがドメイン・ゲートウェイによって BEA Tuxedo 掲示板でどのように宣言されるかが決まります。
接続方針が ON_STARTUP または INCOMING_ONLY の場合 (ON_DEMAND は除く)、TDomain および TOP END ドメイン・ゲートウェイの機能である Dynamic Status はリモート・サービスの状態を調べます。リモート・サービスの状態は、ローカル・ドメイン・ゲートウェイとリモート・ドメイン・ゲートウェイのネットワーク接続の状態によって決まります。リモート・サービスは、そのサービスのあるドメインへの接続が正常に確立されるたびにローカル・ドメインで宣言されて利用可能になります。リモート・サービスは、そのサービスのあるドメインとの接続が切れるたびに中断されて利用不能になります。
ドメイン・ゲートウェイは、各サービスに対して、サービスのインポート元であるリモート・ドメインを監視するほか、どのリモート・ドメインがアクセス可能であるかも監視します。この方法により、ゲートウェイは、リモート・ドメインに対する要求のロード・バランシングを実行します。サービスのインポート元であるすべてのリモート・ドメインがアクセス不可能になると、そのサービスはドメイン・ゲートウェイによって BEA Tuxedo 掲示板で中断されます。
たとえば、DMCONFIG ファイルの DM_IMPORT セクションを以下のように指定することにより、RSVC というサービスを 2 つのリモート・ドメインからインポートするとします。
*DM_IMPORT
RSVC AUTOTRAN=N
RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
RSVC AUTOTRAN=N
RACCESSPOINT=REMOT2
LACCESSPOINT=LOCAL1
REMOT1 および REMOT2 への接続が可能な場合、ドメイン・ゲートウェイは、RSVC サービスに対する要求のロード・バランシングを実行します。REMOT1 への接続が不可能になると、ゲートウェイは、RSVC サービスへのすべての要求を REMOT2 に送信します。REMOT1 および REMOT2 への接続が両方とも不可能になると、ゲートウェイは、掲示板の RSVC を中断します。RSVC に対する以降の要求は、ローカル・サービスにルーティングされるか、または失敗して TPENOENT が返されます。
関連項目
Domains のフェイルオーバーとフェイルバックの指定
DMCONFIG ファイルの DM_IMPORT セクションでは、Domains コンフィギュレーションの Domains レベルのフェイルオーバーおよびフェイルバック機能を設定できます。DMCONFIG ファイルの DM_TDOMAIN セクションでは、Domains コンフィギュレーションの Domains リンク・レベルのフェイルオーバー機能を設定できます。
Domains レベルのフェイルオーバーとフェイルバックの設定
Domains レベルのフェイルオーバーは、一次リモート・ドメインで障害が検出されたときに要求を代替リモート・ドメインに転送するメカニズムです。一次リモート・ドメインが回復したときには、そのドメインへのフェイルバックも行われます。
Domains レベルのフェイルオーバーとフェイルバックをサポートするには、特定のサービスを実行できるリモート・ドメイン・アクセス・ポイントのリストを指定します。次に例を示します。
*DM_IMPORT
TOUPPER RACCESSPOINT=“REMOT1,REMOT2,REMOT3”
この例で、TOUPPER サービスは REMOT1 (一次)、REMOT2、および REMOT3 の 3 つのリモート・ドメイン・アクセス・ポイントのいずれかで実行できます。REMOT1 が利用できなくなると、REMOT2 がフェイルオーバーに使用されます。REMOT1 と REMOT2 が両方とも使用できない場合は、REMOT3 がフェイルオーバーに使用されます。
サービスの代替リモート・ドメインを設定する必要がある場合は、ON_STARTUP または INCOMING_ONLY を CONNECTION_POLICY パラメータの値として指定します。接続方針として ON_DEMAND を指定すると、RACCESSPOINT パラメータで指定された代替リモート・ドメインに「フェイルオーバー」できません。
Domains レベルのフェイルバックは、一次リモート・ドメインへのネットワーク接続が次のいずれかの理由で再確立されたときに行われます。
Domains リンク・レベルのフェイルオーバーの設定
Domains のリンク・レベルのフェイルオーバーは、一次ネットワーク・リンクが失敗したときに二次ネットワーク・リンクが有効になるようにするメカニズムです。ただし、一次リンクが回復してもそのリンクへのフェイルバックは行われません。つまり、一次リンクが回復したときには、二次リンクを手動で無効にしてトラフィックを強制的に一次リンクに戻す必要があります。
Domains のリンク・レベルのフェイルオーバーを設定するには、DMCONFIG ファイルの DM_TDOMAIN セクションでリモート・ドメイン・アクセス・ポイントの複数のエントリを指定します。次に例を示します。
*DM_TDOMAIN
REMOT1 NWADDR=“//newyork.acme.com:65431”
REMOT1 NWADDR=“//trenton.acme.com:65431”
最初のエントリは一次アドレスと見なされます。つまり、その NWADDR はリモート・ドメイン・アクセス・ポイントへの接続が試行されるときに試される最初のネットワーク・アドレスです。2 番目のエントリは二次アドレスと見なされます。つまり、その NWADDR は一次アドレスを使用して接続を確立できないときに試される 2 番目のネットワーク・アドレスです。
2 番目のエントリは、一次リモート・ゲートウェイのある BEA Tuxedo ドメインとは別の BEA Tuxedo ドメインにある二次リモート・ゲートウェイを指します。二次と一次のリモート・ゲートウェイは、その関連する DMCONFIG ファイルの DM_LOCAL セクションで同じ ACCESSPOINTID が定義されている必要があります。この処置は、ゲートウェイのミラーリングと呼ばれることがあります。この機能をトランザクションまたは会話で使用することはお勧めしません。また、一次リモート・ゲートウェイが使用可能なときに使用することもお勧めしません。
Domains のキープアライブの指定
Domains のキープアライブ (BEA Tuxedo リリース 8.1 以降が動作する TDomain ゲートウェイで利用可能) を利用すると、TDomain ゲートウェイの接続ごとに TCP レベルおよびアプリケーション・レベルでキープアライブ・プロトコルを有効化および設定できます。TCP レベルのキープアライブとアプリケーション・レベルのキープアライブは相互に排他的ではないので、両方のオプションを使用して Domains 接続を設定できます。
次の表は、Domains のキープアライブに関する主要な情報を提供します。
.
ほとんどの BEA Tuxedo Domains コンフィギュレーションはファイアウォールをまたがっており、ファイアウォールはアイドル接続がタイムアウトになる原因となります。Domains キープアライブは活動のない期間に BEA Tuxedo のドメイン間接続をオープンに維持するだけでなく、TDomain ゲートウェイで Domains 接続の失敗を迅速に検出できるようにします。現在、TDomain ゲートウェイは基盤の TCP スタックを通じて Domains 接続の失敗を検出しています。TCP スタックは、失敗の発生後 15 分以上経ってからその失敗を報告します。実際に何分かかるかは、ローカルのオペレーティング・システムのコンフィギュレーションによって異なります。 TCP レベルのキープアライブ キープアライブ機能は TCP の仕様に含まれていませんが、ほとんどのオペレーティング・システムでは TCP キープアライブ・タイマーが提供されます。TCP キープアライブ・タイマーを使用すると、TCP 接続の片側のサーバ・マシンでその接続のもう片側のクライアント・マシンがアクセス可能かどうかを検出できます。 TCP 接続を経由してサーバ・マシンに届くメッセージはすべて、TCP キープアライブ・タイマーをリセットします。キープアライブ・タイマーで事前定義済みの期間 (通常は 2 時間) TCP 接続で活動がないと検出されると、タイマーが切れて、サーバ・マシンからセグメント検査パケットがクライアント・マシンに送信されます。接続がまだオープンであり、クライアント・マシンがまだ機能している場合は、クライアント・マシンから肯定応答がサーバ・マシンに送信されます。セグメント検査パケットを送信してから一定の期間肯定応答が届かない場合、サーバ・マシンは接続が切れていると判断して、その接続と関連付けられたリソースをすべて解放します。 接続がオープンでクライアント・マシンが機能しているかどうかを判断するだけでなく、TCP レベルのキープアライブはファイアウォールをまたがってアイドル接続をオープンに維持することもできます。接続で活動がない状態が定義済みの期間続いた後にセグメント検査パケットを自動的に送信することで、ファイアウォールのアイドル接続タイマーがタイムアウトになる前にリセットされ、それによって接続のオープンが維持されます。 オペレーティング・システムの TCP キープアライブ・タイマーの間隔は、通常は 2 時間に設定されます。この間隔は変更できますが、その変更によってマシンのすべての TCP 接続が影響を受けます。オペレーティング・システムの TCP キープアライブ間隔は、システム全体にかかわる値です。 Domains の TCP レベルのキープアライブの設定 Domains の BEA Tuxedo TCP レベル・キープアライブ・オプションは TCPKEEPALIVE という名前で、DMCONFIG ファイルの DM_TDOMAIN セクションにオプション・パラメータとして追加されています。このパラメータを使用すると、Domains の TCP レベルのキープアライブ・オプションをローカル・ドメインまたはリモート・ドメイン単位で有効にできます。 TCPKEEPALIVE の有効な値は次のとおりです。
Domains の TCP レベルのキープアライブ・オプションは、デフォルトでは無効です。Domains 接続で TCP レベルのキープアライブを有効にした場合、オペレーティング・システムの TCP キープアライブ・タイマーに設定されたシステム全体にかかわる値が、その接続のキープアライブ間隔として使用されます。
TCPKEEPALIVE の使い方を明確にするために、次の Domains TCP レベル・キープアライブ・コンフィギュレーションを考えてください。
*DM_TDOMAIN
LOCAL1 NWADDR=“//albany.acme.com:4051”
TCPKEEPALIVE=Y
REMOT1 NWADDR=“//newyork.acme.com:65431”
REMOT2 NWADDR=“//philly.acme.com:65431”
TCPKEEPALIVE=NO
リモート・ドメイン・アクセス・ポイントに指定された TCP レベルのキープアライブ・コンフィギュレーションは、ローカル・ドメイン・アクセス・ポイントに指定された TCP レベルのキープアライブ・コンフィギュレーションに優先します。このため、前の例の TCP レベルのキープアライブ・コンフィギュレーションは次のようになります。
LOCAL1 から REMOT1―TCP レベルのキープアライブ有効
LOCAL1 から REMOT2―TCP レベルのキープアライブ無効
ローカル・ドメイン・アクセス・ポイントの場合、TCPKEEPALIVE パラメータに次のいずれかの値を指定できます。
リモート・ドメイン・アクセス・ポイントの場合、TCPKEEPALIVE パラメータに次のいずれかの値を指定できます。
リモート・ドメイン・アクセス・ポイントで LOCAL を指定するか、コンフィギュレーションを指定しないと、デフォルトでローカルの TCP レベルのキープアライブ・コンフィギュレーションが使用されます。
注記 相互作用する 2 つの BEA Tuxedo ドメインのそれぞれで TCP レベルのキープアライブを有効にできます。ただし、両方のドメインで BEA Tuxedo 8.1 以降が動作している必要があります。
Domains 接続の接続方針が ON_STARTUP で、TCP 接続が TCP レベルのキープアライブの障害によりクローズしている場合は、自動接続再試行が行われます。接続の再試行が成功しない場合は、dmadmin connect コマンドを使用して接続を再確立する必要があります。dmadmin connect コマンドについては、ドメイン間の接続の確立を参照してください。
アプリケーション・レベルのキープアライブ
オペレーティング・システムの TCP キープアライブについては、セグメント検査パケットが不必要に帯域幅を消費し、インターネット接続でユーザがパケット単位で支払うお金を浪費するということで、一部の人たちは使用することに異を唱えています。また、アプリケーション層では次のことを判断すべきなので、キープアライブはトランスポート (TCP) 層ではなくアプリケーション層またはリンク層が適していると信じている人たちもいます。
誰がどのような意見を持っているかに関係なく、アプリケーション・レベルのキープアライブはキープアライブ・タイマーの間隔を接続ごとに設定できるという点では TCP レベルのキープアライブよりも優れています。TCP レベルのキープアライブの場合、タイマーの間隔はマシン単位で設定します。
アプリケーション・レベルのキープアライブを使用した場合、サーバ・アプリケーションはアプリケーション・キープアライブ・タイマーがタイムアウトになるたびにアプリケーション固有のキープアライブ・メッセージを送信します。キープアライブ・メッセージは通常はヘッダ情報のみで構成され、データは関連付けられていません。クライアント・アプリケーションは、肯定応答を送信してサーバ・アプリケーションに応答します。キープアライブ・メッセージを送信してから事前定義済みの期間肯定応答が届かない場合、サーバ・アプリケーションは接続が切れていると判断して、その接続と関連付けられたリソースをすべて解放します。
接続がオープンでクライアント・アプリケーションが機能しているかどうかを判断するだけでなく、アプリケーション・レベルのキープアライブはファイアウォールをまたがってアイドル接続をオープンに維持することもできます。接続で活動がないことが定義済みの期間続いた後にキープアライブ・メッセージを自動的に送信することで、ファイアウォールのアイドル接続タイマーがタイムアウトになる前にリセットされ、それによって接続のオープンが維持されます。
Domains のアプリケーション・レベルのキープアライブの設定
Domains の BEA Tuxedo アプリケーション・レベル・キープアライブ・オプションは KEEPALIVE 名前です。このパラメータとそれに伴う KEEPALIVEWAIT というパラメータが、DMCONFIG ファイルの DM_TDOMAIN セクションのオプション・パラメータとして追加されています。これらのパラメータを使用すると、Domains のアプリケーション・レベルのキープアライブ・オプションをローカル・ドメインまたはリモート・ドメイン単位で設定できます。
DMKEEPALIVE パラメータでは、Domains 接続でトラフィックを受信することなくローカル TDomain ゲートウェイが待機する最長時間を指定します。この時間を過ぎると、ゲートウェイからアプリケーション・レベル・キープアライブ要求メッセージが送信されます。DMKEEPALIVE の有効な値は次のとおりです。
DMKEEPALIVE のデフォルト設定は 0 です。
DMKEEPALIVEWAIT パラメータでは、送信したキープアライブ・メッセージに対する肯定応答を受信することなくローカル TDomain ゲートウェイが待機する最長時間を指定します。この時間を過ぎると、ゲートウェイはリモート TDomain ゲートウェイとの接続が切れているものと判断し、その接続に関連付けられたすべてのリソースを解放します。DMKEEPALIVEWAIT の最小値は 0、最大値は 2147483647 ミリ秒で、現在は Domains ソフトウェアによって最近の秒に丸められます。DMKEEPALIVEWAIT のデフォルト設定は 0 です。
DMKEEPALIVE と DMKEEPALIVEWAIT の使い方を明確にするために、次の Domains アプリケーション・レベル・キープアライブ・コンフィギュレーションを考えてください。
*DM_TDOMAIN
LOCAL1 NWADDR=“//albany.acme.com:4051”
DMKEEPALIVE=1010
DMKEEPALIVEWAIT=20
REMOT1 NWADDR=“//newyork.acme.com:65431”
DMKEEPALIVE=4000
DMKEEPALIVEWAIT=3000
REMOT2 NWADDR=“//philly.acme.com:65431”
DMKEEPALIVE=-1
リモート・ドメイン・アクセス・ポイントに指定されたキープアライブ・コンフィギュレーションは、ローカル・ドメイン・アクセス・ポイントに指定されたキープアライブ・コンフィギュレーションに優先します。このため、前の例のアプリケーション・レベルのキープアライブ・コンフィギュレーションは次のようになります。
LOCAL1 から REMOT1―キープアライブ・タイマー = 4 秒、待機タイマー = 3 秒
LOCAL1 から REMOT2―キープアライブ・タイマー = 2 秒、待機タイマー = 1 秒
ローカル・ドメイン・アクセス・ポイントの場合、DMKEEPALIVE パラメータに次のいずれかの値を指定できます。
リモート・ドメイン・アクセス・ポイントの場合、DMKEEPALIVE パラメータに次のいずれかの値を指定できます。
リモート・ドメイン・アクセス・ポイントで -1 を指定するか、キープアライブ・コンフィギュレーションを指定しないと、デフォルトでローカルのアプリケーション・レベルのキープアライブ・コンフィギュレーションが使用されます。
注記 相互運用される 2 つの BEA Tuxedo ドメインのそれぞれで、アプリケーション・レベルのキープアライブを設定できます。待機間隔は同じでも別々でもかまいません。ただし、両方のドメインで BEA Tuxedo 8.1 以降が動作している必要があります。
Domains 接続の接続方針が ON_STARTUP であり、その接続でアプリケーション・レベルのキープアライブの障害が発生した場合は、自動的な接続再試行プロセスによって接続の再確立が行われます。接続再試行プロセスの詳細については、接続再試行プロセスの使用方法を参照してください。
旧リリースの BEA Tuxedo とのキープアライブの互換性
Domains の TCP レベルのキープアライブは、BEA Tuxedo 8.0 以前と互換性があります。Domains の TCP レベルのキープアライブはネットワーク・トランスポート (TCP) 層で実行されるので、TCP 接続の反対側の BEA Tuxedo ソフトウェアはどのリリースの BEA Tuxedo でもかまいません。
Domains のアプリケーション・レベルのキープアライブは、BEA Tuxedo 8.0 以前と互換性がありません。TCP 接続の反対側の BEA Tuxedo ソフトウェアは、BEA Tuxedo 8.1 以降でないとアプリケーション・レベル・キープアライブ・メッセージを理解できません。旧リリースの BEA Tuxedo ソフトウェアが動作している TDomain ゲートウェイに接続した場合、TDomain ゲートウェイはアプリケーション・レベルのキープアライブ・メッセージを送信しません。代わりに、リモート・ドメインで旧リリースの BEA Tuxedo ソフトウェアが動作しており、Domains のアプリケーション・レベルのキープアライブがサポートされていないことを示す警告メッセージがローカルのユーザ・ログ (ULOG) に記録されます。
Domains 環境の設定
次のリストは、TDomain ゲートウェイ・タイプ用に Domains 環境を設定するためのタスクをまとめたものです。
*DM_LOCAL
LOCAL1 GWGRP=GWTGROUP
TYPE=TDOMAIN
ACCESSPOINTID=“BA.CENTRAL01”
BLOCKTIME=30
CONNECTION_POLICY=ON_STARTUP
MAXRETRY=5
RETRY_INTERVAL=100
*DM_REMOTE
REMOT1 TYPE=TDOMAIN
ACCESSPOINTID=“BA.BANK01”
REMOT2 TYPE=TDOMAIN
ACCESSPOINTID=“BA.BANK02”
*DM_EXPORT
LTOLOWER LACCESSPOINT=LOCAL1
CONV=N
RNAME=“TOLOWER”
*DM_IMPORT
RTOUPPER AUTOTRAN=N
RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
CONV=N
RNAME=“TOUPPER”
*DM_TDOMAIN
LOCAL1 NWADDR=“//albany.acme.com:4051”
REMOT1 NWADDR=“//newyork.acme.com:65431”
REMOT2 NWADDR=“//philly.acme.com:65431”
DMCONFIG ファイルは、DMADM サーバと同じマシン上に配置する必要があります。
Domains ATMI 環境を設定する詳しい例については、ATMI Domains の計画とコンフィギュレーションを参照してください。Domains CORBA 環境を設定する詳しい例については、CORBA Domains の計画とコンフィギュレーションを参照してください。
移行を考慮した Domains 環境の設定
次に示すサンプルの UBBCONFIG ファイルと DMCONFIG ファイルを参照すると、Domains の移行を考慮して BEA Tuxedo アプリケーションを設定する方法がわかります。Domains の移行に特に重要なエントリは太字で示されています。
コード リスト1-1 Domains の移行を考えて設定されたサンプル UBBCONFIG ファイル
*RESOURCES
IPCKEY 76666
MASTER SITE1,SITE2
OPTIONS LAN,MIGRATE
MODEL MP
#
*MACHINES
mach1 LMID=SITE1
TUXDIR=“/home/rsmith/tuxroot”
APPDIR=“/home/rsmith/bankapp”
TUXCONFIG=“/home/rsmith/bankapp/tuxconfig”
mach2 LMID=SITE2
TUXDIR=“/home/rsmith/tuxroot”
APPDIR=“/home/rsmith/bankapp”
TUXCONFIG=“/home/rsmith/bankapp/tuxconfig”
mach3 LMID=SITE3
TUXDIR=“/home/rsmith/tuxroot”
APPDIR=“/home/rsmith/bankapp”
TUXCONFIG=“/home/rsmith/bankapp/tuxconfig”
#
*GROUPS
DMADMGRP LMID=“SITE1,SITE3” GRPNO=1
GWTGROUP LMID=“SITE2,SITE3” GRPNO=2
.
.
.
*NETWORK
SITE1 NADDR=“//albany.acme.com:4065”
NLSADDR=“//albany.acme.com:4068”
SITE2 NADDR=“//auburn.acme.com:4065”
NLSADDR=“//auburn.acme.com:4068”
SITE3 NADDR=“//boston.acme.com:4065”
NLSADDR=“//boston.acme.com:4068”
#
*SERVERS
DMADM SRVGRP=DMADMGRP
SRVID=1001
REPLYQ=N
RESTART=Y
GRACE=0
GWADM SRVGRP=GWTGROUP
SRVID=1002
REPLYQ=N
RESTART=Y
GRACE=0
GWTDOMAIN SRVGRP=GWTGROUP
SRVID=1003
RQADDR=“GWTGROUP”
REPLYQ=N
RESTART=Y
GRACE=0
.
.
.
注記 この例では、DMADM、GWADM、および GWTDOMAIN の各サーバで REPLYQ=N が指定されています。この設定は必須ではありません。必要に応じて REPLYQ=Y を指定して、それらのどのサーバにでも応答キューを指定できます。ただし、REPLYQ が N に設定されている場合は、パフォーマンスが向上することがあります。
コード リスト1-2 Domains の移行を考えて設定されたサンプル DMCONFIG ファイル
*DM_LOCAL
LOCAL1 GWGRP=GWTGROUP
TYPE=TDOMAIN
ACCESSPOINTID=“BA.CENTRAL01”
BLOCKTIME=30
CONNECTION_POLICY=ON_STARTUP
MAXRETRY=5
RETRY_INTERVAL=100
*DM_REMOTE
REMOT1 TYPE=TDOMAIN
ACCESSPOINTID=“BA.BANK01”
REMOT2 TYPE=TDOMAIN
ACCESSPOINTID=“BA.BANK02”
*DM_EXPORT
LTOLOWER LACCESSPOINT=LOCAL1
CONV=N
RNAME=“TOLOWER”
*DM_IMPORT
RTOUPPER AUTOTRAN=N
RACCESSPOINT=REMOT1
LACCESSPOINT=LOCAL1
CONV=N
RNAME=”TOUPPER”
*DM_TDOMAIN
LOCAL1 NWADDR=“//albany.acme.com:4051”
LOCAL1 NWADDR=“//boston.acme.com:4051”
REMOT1 NWADDR=“//newyork.acme.com:65431”
REMOT2 NWADDR=“//philly.acme.com:65431”
サンプルのコンフィギュレーション・ファイルで、DMADM サーバと TDomain ゲートウェイ・グループ・サーバは SITE3 マシンに移行するように設定されています。DMADM の移行については、次のタスクを終えた後に管理者が SITE3 マシンで DMADM サーバ・プロセスをアクティブにします。
TDomain ゲートウェイ・グループの移行については、管理者が SITE3 マシンで GWADM サーバ・プロセスと GWTDOMAIN サーバ・プロセスをアクティブにします。その時点で、LOCAL1 アクセス・ポイントと関連付けられたコンフィギュレーションと責任は、ネットワーク・アドレス boston.acme.com:4051 で接続要求をリスンする新しい GWTDOMAIN サーバ・プロセスによって処理されます。
注記 DMADM とドメイン・ゲートウェイ・グループは、同じマシンに移行する必要はありません。
DMADM サーバの移行
DMADM を新しいマシンに移行するには、次の手順に従います。
TDomain ゲートウェイ・グループの移行
トランザクションが Domains コンフィギュレーションで使用されている場合、TDomain ゲートウェイ・グループは同じ種類のマシン間でのみ移行できます。
TDomain ゲートウェイ・グループを移行するには、次の手順に従います。
*DM_TDOMAIN
LOCAL1 NWADDR=“//primary:port”
LOCAL1 NWADDR=“//backup:port”
個々のサーバ・プロセスをアクティブにする手段
個々の BEA Tuxedo サーバ・プロセスは、次のいずれかの手段でアクティブにできます。
アプリケーションの移行タスクについては、『BEA Tuxedo アプリケーション実行時の管理』の「アプリケーションの移行」を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
