| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > ATMI アプリケーションでの Tuxedo TOP END Domain Gateway の使用 > TOP END Domain Gateway を使用したシステム間の相互接続 |
|
ATMI アプリケーションでの Tuxedo TOP END Domain Gateway の使用
|
TOP END Domain Gateway を使用したシステム間の相互接続
ここでは、次の内容について説明します。
BEA TOP END システムと BEA Tuxedo システムの相互運用性について
次の図に示すように、TOP END Domain Gateway は BEA TOP END システムと BEA Tuxedo システム間の相互運用性に関し、3 つのパターンをサポートしています。
図 2-1 サポートされている TEDG の相互運用性のパターン
関連項目
TEDG の接続処理とメッセージ送信
ここでは、次の内容について説明します。
要求/応答型のメッセージ送信
TEDG では、BEA Tuxedo システムと BEA TOP END システム間で要求/応答型のメッセージ送信がサポートされます。TEDG は、これらの 2 つのシステムの仲介役を果たします。
BEA Tuxedo クライアントから BEA TOP END サーバへの送信
BEA Tuxedo クライアントは TEDG をローカル・サーバと見なします。TEDG は、DMCONFIG ファイルの DM_REMOTE_SERVICES セクションの SERVICE エントリに基づいてサービスを宣言します。クライアント・プログラムは、ローカル・サービスをアドレス指定する場合と同じように、tpcall(3c) を使って要求を発行します。非同期の要求と応答は、それぞれ tpacall(3c) と tpgetrply(3c) 関数によりサポートされます。
TEDG はサービス名を使用して DM_REMOTE_SERVICES セクションの SERVICE エントリを検索し、対応する BEA TOP END プロダクト、関数、MSR ターゲット、および関数修飾子を決定します。FML32 バッファの場合、メッセージが送信される前に必要に応じてデータ・マーシャリングが実行されます。
BEA TOP END サーバは、tp_server_send(3T) を使用してクライアントからの要求に応答します。
BEA TOP END クライアントから BEA Tuxedo サーバへの送信
BEA TOP END クライアントは tp_client_send(3T) または tp_client_signon(3T) を使用して、BEA Tuxedo サービスを要求します。BEA TOP END クライアントの呼び出しは非同期です。応答は tp_client_receive(3T) 呼び出しによって処理されます。
メッセージは、TEDG によって宣言されるプロダクト、関数、および MSR ターゲット (オプション) の 3 つの情報に基づいてルーティングされます。通常の BEA TOP END ルーティング規則とロード・バランシング規則を使用して、宛先ノードが決定されます。TEDG がメッセージを受け取ると、メッセージで指定されているプロダクト、関数、オプションの MSR ターゲット、および関数修飾子から、DMCONFIG ファイルの DM_LOCAL_SERVICES セクションの SERVICE エントリに従って対応する BEA Tuxedo サービスが決定されます。データのマーシャリング解除が実行された後、メッセージは該当する BEA Tuxedo サービスに送信されます。
関連項目
会話型メッセージ送信
BEA Tuxedo システムと BEA TOP END システムでは異なるスタイルの会話型メッセージ送信がサポートされています。
TEDG では、BEA TOP END の擬似会話を BEA Tuxedo 会話型モデルにマッピングすることができます。これにより、次のことが可能になります。
BEA Tuxedo システムと BEA TOP END システム間の接続の確立
BEA TOP END のノードは接続時に、利用可能なサービスを隣接ノードに対して宣言します。新しいサービスは動的に宣言されます。利用できなくなったサービスは宣言を取り消されます。このため、BEA TOP END ノードは接続されているノード上のすべてのサービス状況を常に把握することができます。
BEA Tuxedo システムの場合はこれと異なります。マルチ・ノード型の BEA Tuxedo ドメインでは、接続アーキテクチャは BEA TOP END システムの場合とほとんど同じですが、ドメイン間接続では異なります。
BEA Tuxedo システムには TEDG に割り当てるための次の 3 つの接続方針が用意されています。
デフォルトでは、別のドメインへの接続はそのようなサービス要求がなされるまで行われません (CONNECTION_POLICY=ON_DEMAND)。このような接続をレイジー接続と呼びます。ただし、ゲートウェイは接続が行われる前に、ローカル・ドメインにリモート・サービスを宣言します。接続が行われないと、ゲートウェイは呼び出し元にエラーを返しますが、関連するサービスは宣言されたままです。
オプションで、TEDG が毎日起動時に自動的にほかの BEA TOP END システムと接続するように設定できます (CONNECTION_POLICY=ON_STARTUP)。接続が確立すると、関連するすべてのサービスが利用可能であると見なされて宣言されます。接続を確立できない、またはいったん確立したがその後で接続に失敗した場合、関連するサービスは中断されます (CONNECTION_POLICY=INCOMING_ONLY および CONNECTION_POLICY=ON_STARTUP)。このように、リモート・サービスは継続的に宣言されるように設定するか (CONNECTION_POLICY=ON_DEMAND)、またはリモート・ドメインへの接続がオープンの場合にのみ宣言されるように設定できます (CONNECTION_POLICY=ON_STARTUP および CONNECTION_POLICY=INCOMING_ONLY)。
ローカル・サービスについては、接続方針に関係なく、BEA TOP END ノードとの接続が確立されると TEDG は BEA TOP END システムにローカル・サービスを宣言 (エクスポート) します。TEDG はローカル・ドメインの DMCONFIG ファイル内の規則を使って、どのサービスを宣言するか決定します。TEDG はローカル・ドメインに関連する DM_LOCAL_SERVICES セクション内の各 SERVICE エントリを宣言します。それぞれのサービスに対して、TEDG は関連するパラメータ (TE_PRODUCT、TE_FUNCTION、および TE_TARGET) を BEA TOP END システムに宣言します。個々のサービス可用性状況は BEA TOP END システムではトラッキングされません。ネットワーク接続状況のみトラッキングされます。
起動時に接続する (ON_STARTUP)
BEA Tuxedo の ON_STARTUP 方針は、BEA TOP END 接続方針と最もよく似ています。この方針が選択されていると、TEDG は設定された BEA TOP END ノードそれぞれに接続しようとします。複数のネットワーク・アドレスが設定されている場合は順に試行されます。設定されていれば再接続が行われます。接続が成功すると、TEDG は関連するリモート・サービスをローカル・ドメインに宣言します。接続が失敗する (または失われる) と、接続が再度確立されるまで、関連するサービスは中断されます。BEA TOP END ノードでの個々のサービス可用性状況はトラッキングされません。
クライアント・プログラムがリモート・サービスを要求したときに接続する (ON_DEMAND)
ON_DEMAND または「レイジー接続」方針は、BEA Tuxedo システムのデフォルトの接続方針です。接続は、リモート・サービスに対するクライアント要求を満たすため、必要に応じて行われます。複数のネットワーク・アドレスが設定されている場合は順に試行されます。再接続は行われません。TEDG は起動時にリモート・サービスを BEA Tuxedo システムに宣言しますが、実際にはどの BEA TOP END ノードにも接続しません。接続状況に関係なく、リモート・サービスは常に宣言されます。BEA TOP END ノードでの個々のサービス可用性状況はトラッキングされません。
受信時接続のみ受け付ける (INCOMING_ONLY)
INCOMING_ONLY 方針は、TEDG がリモート・ドメインへの接続を試行せず、関連するリモート・サービスを宣言しないように指定します。接続は、TEDG に接続している BEA TOP END システムが開始するか、または BEA Tuxedo 管理者が手動で開始しなければなりません。複数のネットワーク・アドレスが設定されている場合、手動で接続を確立する管理者のみが処理できます。再接続は行われません。接続が成功すると、関連するリモート・サービスが宣言されます。接続が失敗すると、接続が確立されるまで、関連するサービスは中断されます。BEA TOP END ノードでの個々のサービス可用性状況はトラッキングされません。
メッセージのルーティング
BEA TOP END システムと BEA Tuxedo システムはいずれも、メッセージの内容に基づくルーティングをサポートしています。ただし、TEDG を介して行われるルーティングの粒度において両者は異なります。BEA Tuxedo システムのデータ依存型ルーティング (DDR: Data-Dependent Routing) 機能と BEA TOP END システムのメッセージ・センシティブ・ルーティング (MSR: Message Sensitive Routing) 機能を使用して、両方のシステム間でメッセージ・トラフィックを低レベルで転送できます。これらの機能は相互に排他的でなく、一緒に使用してシステム間のメッセージ・トラフィックを制御することができます。
BEA Tuxedo データ依存型ルーティング (DDR)
ほかの Domains コンポーネント同様に、TEDG に対してルーティング基準を DMCONFIG ファイルの DM_ROUTING セクションで指定します。指定した基準に基づいて、メッセージはその内容に応じたリモート・ドメインにルーティングされます。TEDG では、リモート・ドメインは特定の NI (BEA TOP END システムのノード) にマッピングされます。
BEA TOP END メッセージ・センシティブ・ルーティング (MSR)
BEA TOP END クライアントは、MSR 機能を使用するか、サービス要求の一部として MSR ターゲットを明示的に指定できます。BEA Tuxedo サービスはオプションの MSR ターゲットを含む BEA TOP END サービス・パラメータ (DMCONFIG ファイルの DM_LOCAL_SERVICES セクションの TARGET パラメータ) にマッピングされるので、BEA Tuxedo サービスが一意にマッピングされる限り、BEA TOP END システムから、BEA Tuxedo システムで提供される特定のサービスにメッセージをルーティングすることができます。
形式とメッセージ内容の変換 (MCC)
TOP END Domain Gateway は、raw データ・バッファか FML32 のいずれかを使って BEA TOP END のクライアントとサーバをサポートしています。主にスクリーンの形式を記述するために使用される BEA TOP END の形式変換機能はサポートされません。
メッセージを変換し、形式情報を基にする、メッセージ内容の変換機能 (MCC) もサポートされません。形式を指定されたメッセージが TEDG に送られると、形式情報は無視され、このオカレンスについてのメッセージが userlog に記録されます。
メッセージのサイズと種類
BEA TOP END システムと TEDG は最大 30K (30 X 1024) バイト (RTQ メッセージの場合は 30,000) 長のメッセージを送受信できます。BEA TOP END ラージ・メッセージ・アーキテクチャ (LMA: Large Message Architecture) は TEDG ではサポートされません。
BEA TOP END アプリケーション・プログラミング・インターフェイスの LMA 機能を無効にするには、すべての BEA TOP END CSI 呼び出しで attach_info パラメータに NULL を設定します。関数呼び出しにアタッチメントが含まれる場合、TEDG は次の処理を行います。
BEA Tuxedo システムではラージ・メッセージを通常処理の一部として使用できるので、TEDG はラージ・メッセージを検出するとクライアントにエラーを返し、BEA TOP END システムには転送しません。
TEDG は、raw データ・バッファか FML32 のいずれかを使って BEA TOP END クライアントおよびサーバをサポートします。BEA TOP END スクリーン形式は使用できません。
TEDG のキュー処理
BEA TOP END システムと BEA Tuxedo システムはいずれも、コンポーネント間でメッセージをやり取りするための手段として、高信頼性のキューをサポートしています。BEA Tuxedo の /Q 機能および BEA TOP END 回復可能トランザクション・キューイング (RTQ: Recoverable Transaction Queuing) プロダクトでは、メッセージの送受信に当たり、処理前にメッセージを格納しておくための安定した手段としてキューを使用できます。キューは、要求のオフライン処理が望ましい場合、あるいはオフライン処理がクライアント/サーバ通信の唯一の実用的な方法である場合に有用です。/Q および RTQ では、キューに正常に登録されたメッセージは必ずサーバに送信されます。元のメッセージのキュー処理、およびそれ以降のメッセージの処理において、完全なトランザクション・セマンティクスがサポートされています。
TEDG は、BEA Tuxedo システムと BEA TOP END システム間でメッセージのキュー処理とトランザクションのキュー処理をサポートします。/Q と RTQ は類似の機能を備えていますが、キューに入れられたメッセージの処理方法が基本的に異なります。
BEA Tuxedo システムには、明示的にメッセージをキューから取り出す関数が用意されています。『BEA Tuxedo C リファレンス』 の tpdequeue(3c) を参照してください。あるいは、システムで提供されるサービス TMQFORWARD(5) によって自動的にメッセージをキューから取り出し、通常の tpcall(3c) 関数を介して標準 BEA Tuxedo サーバに転送することができます。宛先サービスはキュー名にマッピングされます。
一方、BEA TOP END システムには、ユーザ・プログラムで使用できるキューからの取り出し機能はありません。メッセージは RTQ サブシステムによってキューから取り出され、目的のサービスに送られます。宛先サービスのアドレスは、メッセージをキューに登録する処理の一部として指定されます。『BEA TOP END Programmer’s Reference Manual』の tp_rtq_put(3T) を参照してください。キューとサービスの関係は任意です。
関連項目
TEDG でのトランザクションのサポート
TOP END Domain Gateway (TEDG) では、BEA TOP END システムと BEA Tuxedo システム間でのトランザクションに関与するメッセージの送受信やキュー処理がサポートされます。
特に、TEDG は次の処理を行います。
トランザクション識別子のマッピング
BEA TOP END システムと BEA Tuxedo システムは、XA 標準のトランザクション識別子 (XID) を使用します。BEA Tuxedo システムでは後者をグローバル・トランザクション識別子 (GTRID: Global Transaction Identifier) と呼びます。BEA TOP END ユーザはトランザクションを「XID」で識別します。XA XID はグローバル・トランザクション ID (GTRID) とブランチ修飾子 (BQUAL: Branch Qualifier) で構成されます。TEDG では新しいトランザクション・ステップごとに新しいトランザクション・ブランチが作成されます。これは疎結合です。疎結合関係と密結合関係の詳細については、『BEA Tuxedo Domains コンポーネント』の「トランザクションで GTRID マッピングを使用する」を参照してください。TEDG では、BEA TOP END または BEA Tuxedo システムに数回またがるループ・バック・トランザクションがサポートされます。ホップごとに新しいブランチが生成されます。
BEA TOP END システム宛てのトランザクション・ブランチに対して、TEDG は BEA TOP END のブランチ・デザインに従ってブランチを作成します。着信トランザクション・ブランチに対しては BEA Tuxedo のデザインが使用されます。
トランザクション管理
TEDG のトランザクション管理では、トランザクション・ログの記録機能と回復機能が用意されています。
トランザクション・ログの記録
TEDG は 2 フェーズ・コミット・プロセス中にトランザクションの状態を記録して、回復を可能にします。TEDG の各インスタンスに固有のログがあります。DMTLOG は DMCONFIG ファイルの DM_LOCAL_DOMAINS セクションで指定されます。ほかの Domains 機能と同様に、記録機能は GWADM 管理サーバで提供されます。
トランザクションがすべてのノードでコミットされると、そのトランザクションのレコードは削除されます。
トランザクションの回復
TEDG の回復機能はほかの Domains プロダクトと同じ処理を実行します。
ドメイン・ゲートウェイ・グループが起動すると、ゲートウェイは DMTLOG を自動的にウォームスタートします。ウォームスタートではログがスキャンされ、未完了のトランザクションがあるかどうかチェックされます。未完了のトランザクションが見つかると、そのトランザクションを処理するアクションが実行されます。
TEDG では BEA TOP END 拡張回復 (XR: Extended Recovery) 機能を使用する BEA TOP END ノードに接続できます。TEDG 自体は XR ノードにはなりません。
関連項目
API の特性
BEA Tuxedo と BEA TOP END には、X/Open DTP モデルに準拠したアプリケーション・プログラミング・インターフェイス (API) が用意されています。BEA Tuxedo の API は、アプリケーション・トランザクション・モニタ・インターフェイス (ATMI) と呼ばれ、BEA TOP END の API は、クライアント/サーバ・インタラクション (CSI) と呼ばれます。
BEA Tuxedo ATMI の特性
BEA Tuxedo の ATMI は、アプリケーションとトランザクション処理システムの仲介役となります。このインターフェイスは、リソースのオープンとクローズ、トランザクションの管理、型付きバッファの管理、および要求/応答型、会話型、キューイングの関数呼び出しなどを行う各種のルーチンで構成されています。
BEA Tuxedo のクライアント・プログラムとサーバ・プログラムは、BEA Tuxedo ATMI 関数を使用し、TOP END Domain Gateway (TEDG) を介して BEA TOP END クライアントおよびサーバ・プログラムと通信します。ATMI 関数を使用して BEA TOP END アプリケーションと通信する方法は、ほかのドメイン・ゲートウェイを介して BEA Tuxedo プログラムまたはアプリケーションと通信する場合とほとんど同じです。ただし、TEDG とほかのドメイン・ゲートウェイでは、サポートされている関数と機能が異なります。TEDG は、似ているが同一ではない 2 つのクライアント/サーバ環境に接続するため、これらの環境を相互運用する際は両方の環境に共通の機能のみサポートされます。BEA Tuxedo システムと BEA TOP END システムに共通の機能は、TEDG のコンフィギュレーション、機能マッピング、および ATMI プログラミング・インターフェイスで明示的にサポートされている機能により、標準的な ATMI に近い形式で提供されます。
サポートされている ATMI の機能と関数
以下は、TEDG を介した通信でサポートされる ATMI プログラミング機能です。例では、TEDG の機能にとって重要な関数を取り上げています。完全にアプリケーションを作成するには、これら以外のインターフェイス関数も必要です。
サポートされていない ATMI 機能
BEA Tuxedo ATMI 機能のなかには、対応する機能が BEA TOP END システムにないものもあります。こうした機能は BEA Tuxedo システムでは利用できますが、TEDG ではサポートされていません。TEDG でサポートされていない ATMI 機能は次のとおりです。
BEA TOP END CSI の特性
BEA TOP END アプリケーション・プログラミング・インターフェイス (API) の CSI は、BEA TOP END クライアントおよびサーバ・プログラムが TEDG を介して BEA Tuxedo クライアントおよびサーバ・プログラムと通信するためのルーチンを提供します。CSI ルーチン呼び出しを使用して BEA Tuxedo ATMI アプリケーションと通信する方法は、ほかの CSI アプリケーションと通信する場合とほとんど同じです。主な相違点は、各ルーチンでサポートされている機能またはオプションが異なることです。BEA Tuxedo システムと BEA TOP END システムに共通の機能は、TEDG のコンフィギュレーション、機能マッピング、および CSI プログラミング・インターフェイスで明示的にサポートされている機能により、標準的な CSI に近い形式で提供されます。
サポートされている CSI 機能およびルーチン
BEA TOP END にはいくつかのプログラミング・インターフェイスが用意されています。このマニュアルでは、それらをすべて CSI の一部と見なします。TEDG を介する通信でサポートされているプログラミング機能およびルーチンは次のとおりです。
例に挙げているルーチン呼び出しは、TEDG の観点から見て機能に関連する主要なルーチン呼び出しです。完全なアプリケーションを作成するには、ほかのルーチン呼び出しも必要です。さらに、ここに挙げた呼び出しの変化形も利用できます。
サポートされていない CSI 機能
BEA TOP END ブログラミング機能のなかには、対応する機能が BEA Tuxedo システムにないものもあります。こうした機能は BEA TOP END システムでは利用できますが、TEDG ではサポートされていません。
関連項目
TEDG の管理
TOP END Domain Gateway (TEDG) は、BEA Tuxedo アプリケーション空間の一部として、標準の BEA Tuxedo ツール (tmadmin(1) および dmadmin(1)) を使用して管理されます。BEA TOP END システムを通して TEDG を管理することはできません。
TEDG のコンフィギュレーションは主に BEA Tuxedo ツール (DMCONFIG および dmloadcf(1)) を使って行われます。TEDG ノードのほかに、BEA TOP END システムで必要なコンフィギュレーションは、使用するセキュリティ・メカニズムのコンフィギュレーションのみです。
TEDG の実行時管理は BEA Tuxedo ツール、dmadmin コマンドと DMADM および GWADM ゲートウェイ・サーバによって行われます。
関連項目
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
