|
|
|
|
|
|
相互運用性の方針の指定
管理者は、UBBCONFIG ファイルの CLOPT -t オプションを使用して、ATMI アプリケーション内の WSH、ドメイン・ゲートウェイ (GWTDOMAIN) およびサーバ・プロセスが、BEA Tuxedo リリース 7.1 より前 (6.5 以前) のソフトウェアを実行しているマシンと相互運用するように指定できます。また、WSINTOPPRE71 環境変数を使用して、ワークステーション・クライアントが BEA Tuxedo リリース 7.1 より前のソフトウェアを実行するマシンと相互運用するよう指定できます。次に、これらのプロセスの相互運用性を説明する 4 つの図を示します。
新しい WSH と古いワークステーション・クライアントの相互運用
上の図では、WSH がリリース 7.1 より前の古い認証プロトコルを使用してワークステーション・クライアントを認証し、内部の代替ユーザ関数を呼び出してクライアントの認可トークンと監査トークンを取得し、それらのトークンをクライアント要求に添付しています。WSH を制御するワークステーション・リスナ (WSL) に対して CLOPT -t オプションが指定されないと、新しい WSH と古いワークステーション・クライアントとの間の通信は実現できません。 注記 代替ユーザ関数は、認証プラグインを呼び出して、古いクライアントの ID を確認します。詳細については、「古いクライアントの ID の確認」を参照してください。 古い WSH と新しいワークステーション・クライアントの相互運用
上の図では、WSH がリリース 7.1 より前の古い認証プロトコルを使用してワークステーション・クライアントを認証します。クライアント要求は、認可トークンと監査トークンを受け取りません。ワークステーション・クライアントに WSINTOPPRE71 環境変数が設定されていない場合、またはこの環境変数が N に設定されている場合、古い WSH と新しいワークステーション・クライアントとの間の通信は実現できません。 サーバと古い ATMI アプリケーションの相互運用
上の図では、アプリケーション 1 のローカル・ドメイン・ゲートウェイ (GWTDOMAIN) が、リリース 7.1 より前の古い認証プロトコルを使用して、アプリケーション 2 のリモート・ドメイン・ゲートウェイを認証しています。ローカル・ドメイン・ゲートウェイは、リモート・クライアントからの要求を受け取ると、内部の代替ユーザ関数を呼び出してリモート・クライアントの認可トークンと監査トークンを取得し、それらのトークンをクライアント要求に添付します。アウトバウンドのクライアント要求 (アプリケーション 1 からアプリケーション 2 に送信される要求) の場合、要求に添付されたトークンは、ローカル・ドメイン・ゲートウェイで取り除かれ、要求はアプリケーション・キーとともにアプリケーション 2 に送信されます(アプリケーション・キーについては、「アプリケーション・キー」を参照してください)。 ドメイン・ゲートウェイに対して CLOPT -t オプションが指定されない場合、新しい ATMI アプリケーションと古い ATMI アプリケーションとの間の通信は実現できません。 サーバと古い BEA Tuxedo システムの相互運用
上の図では、まずマシン 1 にある送信先のサーバが内部の代替ユーザ関数を呼び出し、マシン 2 にあるリモート・クライアントの認可トークンと監査トークンを取得します。取得したトークンがクライアント要求に添付されると、サーバは、クライアントが認可チェックにパスしたと見なして要求を実行します。サーバに対して CLOPT -t オプションが指定されない場合、新しいサーバと古いクライアントとの間の通信は実現できません。 注記 また、上の図で、マシン 1 の WSH がマシン 2 のサーバ宛てのクライアント要求を受け取ると、WSH は要求に添付されたトークンを取り除いてから、その要求をクライアントのアプリケーション・キーとともにマシン 2 のサーバに送信します。同様に、マシン 1 のネイティブ・クライアントがマシン 2 のサーバに要求を送信した場合、ネイティブ・クライアントは、要求に添付されたトークンを取り除いてから、その要求をクライアントのアプリケーション・キーとともにマシン 2 のサーバに送信します。アプリケーション・キーについては、「アプリケーション・キー」を参照してください。 古いクライアントの ID の確認 WSH、ドメイン・ゲートウェイ (GWTDOMAIN)、またはサーバ・プロセスは、内部の代替ユーザ関数を呼び出して、古いクライアントの認可トークンと監査トークンを取得することにより、古いクライアントの ID を確認します。次の図は、この手順を示しています。 古いクライアントの認可トークンと監査トークンの取得
WSH 側で古いクライアントの ID を確認する CLOPT -t オプションが指定されている場合、WSH は、TPINIT バッファの usrname フィールドを使用するか (C の場合)、または TPINFDEF-REC レコードの USRNAME フィールドを使用して (COBOL の場合) 古いクライアントの ID を確認します。「ATMI アプリケーションへの参加」で説明するとおり、クライアントがアプリケーションに参加しようとすると、WSH はクライアントから TPINIT バッファまたは TPINFDEF-REC レコードを受け取ります。WSH は、代替ユーザ関数を呼び出すときにプリンシパル名としてユーザ名を使用します。 デフォルトの認証プラグインの場合、代替ユーザ関数は、ローカルの tpusr ファイルからユーザ名および関連するアプリケーション・キー (ユーザ識別子とグループ識別子の組み合わせ) を検索し、古いクライアント用に作成された認可トークンと監査トークンに、ユーザ名とアプリケーション・キーを両方とも組み込みます。tpusr ファイルについては、「ユーザ・ファイルとグループ・ファイルの設定」を参照してください。 ドメイン・ゲートウェイ側で古いクライアントの ID を確認する CLOPT -t オプションが指定されている場合、ドメイン・ゲートウェイは、リモート・ドメイン・アクセス・ポイントに対して設定された LOCAL_PRINCIPAL_NAME 文字列を使用して、古いクライアントの ID を確認します。ドメイン・ゲートウェイは、ローカルの BDMCONFIG ファイル (バイナリ形式の DMCONFIG(5) ファイル) の DM_REMOTE_DOMAINS セクションで、リモート・ドメイン・アクセス・ポイントの LOCAL_PRINCIPAL_NAME 文字列を検索します。このオプションを指定しない場合は、リモート・ドメイン・アクセス・ポイントの DOMAINID 文字列がデフォルト値になります。ドメイン・ゲートウェイは、代替ユーザ関数を呼び出すときにプリンシパル名として LOCAL_PRINCIPAL_NAME 文字列を使用します。 デフォルトの認証プラグインの場合、代替ユーザ関数は、ローカルの tpusr ファイルから LOCAL_PRINCIPAL_NAME 文字列および関連するアプリケーション・キーを検索し、古いクライアント用に作成された認可トークンと監査トークンに、その文字列 (ID) とアプリケーション・キーを組み込みます。 サーバ側で古いクライアントの ID を確認する CLOPT -t オプションが指定されている場合、サーバは、クライアントに割り当てられたアプリケーション・キーを使用して、古いクライアントの ID を確認します。サーバが受信したクライアント要求には、クライアントに割り当てられたアプリケーション・キーが含まれています。サーバは、ローカルの tpusr ファイルからアプリケーション・キーと関連する名前を検索し、代替ユーザ関数を呼び出すときにプリンシパル名としてその名前を組み込みます。 デフォルトの認証プラグインの場合、代替ユーザ関数は、ローカルの tpusr ファイルから名前および関連するアプリケーション・キーを検索し、古いクライアント用に作成された認可トークンと監査トークンに、名前とアプリケーション・キーを組み込みます。 CLOPT -t オプションの動作のまとめ 次の表は、CLOPT -t オプションを使用して相互運用性を実現できる場合、または実現できない場合の WSH、ドメイン・ゲートウェイ、およびサーバ・プロセスの機能をまとめたものです。
相互運用性を指定する UBBCONFIG のエントリ例
次の例は、ワークステーション・リスナ (WSL) によって制御されるすべての WSH で相互運用性が実現できることを示しています。
*SERVERS
WSL SRVGRP="group_name" SRVID=server_number ...
CLOPT="-A -t ..."
関連項目
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|