1. Mainframe Adapter for TCP Gatewayユーザーズ・ガイド
  2. Oracle TMA TCP Gatewayの処理の仕組みの理解

2 Oracle TMA TCP Gatewayの処理の仕組みの理解

Tuxedo Mainframe Adapter for TCP Gateway(以後TMA TCP Gatewayと呼ぶ)の処理の仕組みを理解するには、次のタスクの内容を理解する必要があります。次のトピックでは、これらのタスクについて説明します:

2.1 構成の計画

Tuxedo Mainframe Adapter for TCP Gatewayを使用して異なるタイプのシステム同士を接続する大きなメリットとしては、それぞれのプログラミング環境の独立性を高いレベルで確保できることがあげられます。Oracle Tuxedoプログラマは、異なるタイプのシステムやリモート・リージョン内のシステムにサービスがどのように扱われるかのかを知る必要がほとんどありません。何か特別変わった方法で、アプリケーション・プログラムを開発する必要があるわけではありません。

このような高度な透過性を実現する上で、TMA TCP Gatewayの構成が大きな意味を持ちます。TMA TCP Gatewayの構成によって、ネーミング・ルールやデータ・フォーマットのような環境の違いがプログラマやプログラムから遮蔽されます。

環境上の相違点は3点ほどありますが、そのそれぞれがTMA TCP Gatewayの構成ファイル(GWICONFIGとDMCONFIG)に区分けされています。これらは次のとおりです:

  • サービス名

    異なるシステムの間では、サービスの名前付けルールが異なります。サービスの名前の長さ、名前に使用可能な文字が異なることもありますが、サービス名の構造やサービス名の選ばれ方に関するルールがそもそも異なっていることもあります。

  • 入出力データのフォーマット

    異なるシステムの間では、入出力データのフォーマット(構造、文字セットなど)のルールが異なります。

  • エラー処理

    異なるシステムの間では、アプリケーションのエラーの通知方法が異なります。

このような違いを吸収する方法はマッピングと呼ばれています。一般的に何かをマップする際に、ローカルの値やエンティティを、リモート・システム側のプログラムの意味を表す値やエンティティに関連付けます。

説明しなくても想像が付くと思いますが、サービス名をマップする手順とは、サービスに付与するローカルの名前と、そのサービスに付与するリモートの名前のペアを構成ファイルのレコードに作成することです。一方、入力データ、出力データおよびアプリケーション・エラーのマッピングはもっと複雑です。概念と背景事情に関する情報が必須になります。

TMA TCP Gatewayの構成ファイル(GWICONFIGおよびDMCONFIG)の更新に関する詳細は、「Oracle TMA TCP Gatewayの構成」を参照してください

ノート:

TMA TCP Gatewayのすべての構成パラメータは「Oracle TMA TCP Gatewayの構成」に記載されています。このドキュメントでは、個別の導入が必要な複雑なパラメータに焦点を当てています。

データ・マッピングを構成する手順は、Oracle Tuxedoのプログラミング環境に対する知識が必要になるという点で、プログラミングという行為と考えて差し支えありません。しかし、構成パラメータの影響を受けるアプリケーション・プログラムは多数に及ぶため、通常は管理者が構成を担当します。

親トピック: Oracle TMA TCP Gatewayの処理の仕組みの理解

2.2 TMA TCP Gatewayの初期化

tmbootコマンドを使用してOracle Tuxedoソフトウェアを起動すると、TMA TCP Gatewayは次のように初期化を行います。

  1. TMA TCP GatewayソフトウェアはGWICONFIG構成ファイルを解析し、すべてのパラメータを初期化します。解析中にエラーが検出されると、TMA TCP GatewayがULOGファイルにメッセージを書き込み、初期化が中断されます。
  2. GWICONFIGファイルの読取りが終わると、TMA TCP Gatewayはファイルに指定されているとおりの名前でリモート・サービスを動的に公開します。これらのサービスには、すべてのリモート・ゲートウェイを対象にしたサービスが含まれます。

親トピック: Oracle TMA TCP Gatewayの処理の仕組みの理解

2.3 ローカルのサービス・リクエストの処理

TMA TCP Gatewayはローカルのクライアント・プログラムからOracle Tuxedoサービスのリクエストを受信すると、次のようにリクエストを処理します。

親トピック: Oracle TMA TCP Gatewayの処理の仕組みの理解

2.3.1 ステップ1: Oracle Tuxedoソフトウェアからサービス・リクエストを受信する

クライアント・プログラムが、TMA TCP Gatewayを介してアクセス可能なリモート・サービスに対するリクエストを送信すると、Oracle Tuxedoはそのリクエストを、サービスのリクエストを待機しているゲートウェイに転送します。

親トピック: ローカルのサービス・リクエストの処理

2.3.2 ステップ2: リモート・システムに接続する

TMA TCP Gatewayは、どのリモート・システムが各リクエストを処理するのかを判断します。目的のリモート・システムを決めるために、データ依存型のルーティング・ルールを使用できます。

この時点で、目的のリモート・システムへの接続がない場合、または既存の接続が切断されている場合、TMA TCP Gatewayは新しい接続を開きます。

リモート・システムが接続の障害を示す情報を戻した場合は、Oracle Tuxedoサービスのリクエストは失敗し、エラーが呼出し元に戻されます。戻されるエラーの値が実際にどうなるかは、接続の障害が発生したタイミングに応じて決まります。障害に関する情報はULOGファイルに書き込まれます。

親トピック: ローカルのサービス・リクエストの処理

2.3.3 ステップ3: 入力バッファのタイプを変換する

場合によっては、サービス・リクエストに関連付けられている型付きバッファを変換しないと、サービス・リクエストをリモート・システムに送信できないことがあります。型変換の処理には、リモート・サービス側で受付けが可能なフォーマットにバッファのレイアウトを変更する処理が含まれます。

たとえば、ローカルのクライアント・プログラムが、リモート・サービスが処理できないFMLバッファにユーザー入力データを格納する場合は、リモート・サービス側で実際に必要としている構造にバッファを変換する必要があります。

入力の型変換が必要な場合、プログラマまたは管理者は次の手順に従う必要があります。

  • リモート・サービス側で実際に必要としている入力データのフォーマットを確認します。
  • 必要に応じて、入力データのフォーマットを記述するVIEW定義を作成します。VIEW定義とは、Oracle Tuxedo環境の入出力に使用するデータ構造を記述したものです。
  • TMA TCP Gatewayの構成ファイル(GWICONFIGとDMCONFIG)で、この情報を指定します。

これらの手順が完了すると、TMA TCP Gatewayが必要な型変換をすべて自動的に実行します。

VIEW定義を作成して型変換を進める方法については、「Oracle TMA TCP Gatewayのデータ・マッピングに関する構成」を参照してくださいTMA TCP Gatewayの構成ファイルについては、「Oracle TMA TCP Gatewayの構成」を参照してください

親トピック: ローカルのサービス・リクエストの処理

2.3.4 ステップ4: 入力データを変換する

データは必要に応じて、TMA TCP Gatewayソフトウェアによって自動的に変換されます。変換とは、ワード長、バイト・オーダーおよび文字エンコードという、そのデータ型本来の表現形態を変更することを指します。

データが正しく変換されるように、管理者はGWICONFIG構成ファイルで何種類かのパラメータを指定する必要があります。TMA TCP Gatewayによるデータ変換の仕組みの詳細は、「Oracle TMA TCP Gatewayのデータ・マッピングに関する構成」を参照してください。

親トピック: ローカルのサービス・リクエストの処理

2.3.5 ステップ5: サービス・リクエストを伝達する

TMA TCP Gateway製品はリクエスト・メッセージを作成します。このメッセージは次の項目で構成され、リモート・システムに送信されます。

  • リモート・サービス名
  • TMA TCP Gatewayが必要に応じてレイアウトと型を変換した入力データ・レコード
  • リモート・サービスが呼出し元に応答を戻す必要があるのかどうかを示す情報

親トピック: ローカルのサービス・リクエストの処理

2.3.6 ステップ6: 応答を受け取る

リクエスト・メッセージを送信した後に、TMA TCP Gatewayは応答操作を実行します。リモート・システムからメッセージを受け取る前に、TMA TCP Gatewayが時間切れによるタイムアウト情報を受信すると、TPETIMEエラーが呼出し元に戻されます。

親トピック: ローカルのサービス・リクエストの処理

2.3.7 ステップ7: 応答を変換する

TMA TCP Gatewayが応答を受信した後に、データ表現が必要に応じて、入力時とは逆向きに変換されます。詳細は、「ステップ4: 入力データを変換する」を参照してください

親トピック: ローカルのサービス・リクエストの処理

2.3.8 ステップ8: 出力データを変換する

応答のフォーマットがローカルのクライアント・プログラムに適合しない場合は、TMA TCP Gatewayがその応答を適切なバッファ・フォーマットに変換します。

出力の変換が必要な場合、プログラマまたは管理者は次の手順に従う必要があります。

  • ローカルのクライアント・プログラムが実際に必要としている、出力バッファの型とフォーマットを確認します。
  • 必要に応じて、出力バッファのフォーマットを記述するVIEW定義を作成します。
  • TMA TCP Gatewayの構成ファイル(GWICONFIGとDMCONFIG)で、この情報を指定します。

これらの手順が完了すると、必要な変換が自動的に実行されるようになります。

VIEW定義を作成して型変換を容易にする方法については、「Oracle TMA TCP Gatewayのデータ・マッピングに関する構成」を参照してください。TMA TCP Gatewayの構成ファイルについては、「Oracle TMA TCP Gatewayの構成」を参照してください。

親トピック: ローカルのサービス・リクエストの処理

2.3.9 ステップ9: 呼出し元に応答を送信する

出力の型変換および出力データのトランスレーションが完了したOracle Tuxedoバッファは、TPSUCCESSまたはTPFAILという指標情報が付加された状態で、呼出し元に戻されます。

親トピック: ローカルのサービス・リクエストの処理

2.4 リモートのサービス・リクエストの処理

TMA TCP Gatewayソフトウェアは、リモートのサービス・リクエスト(リモート・システムからのサービス・リクエスト)をローカル・リクエストのときとほぼ同じように処理します。簡単にまとめると、次のようになります。

  1. TMA TCP Gatewayがサービス・リクエストを受信し、そのリクエストに関連付けられている入力レコードの型とレイアウトが、必要に応じて、所定の入力バッファ・フォーマットに合うように変換されます。
  2. クライアント・プログラムとして機能するゲートウェイが、サービス・リクエストをOracle Tuxedoソフトウェアに渡します。
  3. サービス・ルーチンが完了すると、必要に応じて、出力バッファが所定の出力レコード・フォーマットに変換および/またはトランスレートされます。
  4. 最終目標であるリモート・システム上のリクエスタに出力が送信されます。

レコード、バッファおよびデータの変換の詳細は、「ローカルのサービス・リクエストの処理」を参照してください

親トピック: Oracle TMA TCP Gatewayの処理の仕組みの理解

2.5 停止リクエストの処理

tmshutdownコマンドを使用して停止リクエストをTMA TCP Gatewayに送信すると、TMA TCP Gatewayは次の処理を実行します:

  1. 未処理のリクエストの終了
  2. 開いているすべての接続の切断
  3. 終了

親トピック: Oracle TMA TCP Gatewayの処理の仕組みの理解

2.6 プログラミングの考慮事項

TMA TCP Gatewayを介してリクエストを送信するOracle Tuxedoアプリケーション・プログラムの開発は全体的に、他のOracle Tuxedoアプリケーション・プログラムの開発と変わりません。

TMA TCP Gateway製品は、ATMIインタフェースやXATMIインタフェースに備わっているリクエスト/応答の通信機能をすべてサポートしています。しかも、サポートしているすべての機能を、Oracle Tuxedoのドキュメントに記載されている通常の方式で使用できます。

  • XATMIバッファ・タイプとATMIバッファ・タイプがすべてサポートされています。
  • すべてのシステム・エラーが、Oracle Tuxedoのドキュメントに記載されている通常の方式で通知されます。

親トピック: Oracle TMA TCP Gatewayの処理の仕組みの理解

2.6.1 入出力に関する問題

この項では、TMA TCP Gatewayを使用するアプリケーション・プログラムをプログラマが開発する際に考慮する必要がある入出力の問題について何点か説明します。

親トピック: プログラミングの考慮事項

2.6.1.1 TMA TCP Gatewayを使った入出力データの準備作業

「ローカル・サービス・リクエストの処理」のトピックでは、リモート・システムまたはリモート・リージョン、ローカル・システムが受理可能なフォーマットに入出力パラメータを変換する必要がある、様々な状況について説明します。

TMA TCP Gateway製品の構成は非常に性能が高く、パラメータの変換やマッピングが簡単になっているため、別の手段でプログラミングする必要がありません。

TMA TCP Gatewayの構成ファイル(GWICONFIGとDMCONFIG)に設定情報が一元的されており、これらのファイルを使用して、ローカル・システムとリモート・システムまたはリモート・リージョンとの間の関係を定義し維持できます。これらの関係としては、入出力パラメータのマッピング以外にも、サービス名のマッピング(リモート・サービス名をローカル・サービス名にマップすること)とエラー・レコードのマッピングを行うことができます。

GWICONFIG構成ファイルの詳細は、「Oracle TMA TCP Gatewayの構成」を参照してください

親トピック: 入出力に関する問題

2.6.1.2 サービス・リクエストのパラメータ

Oracle Tuxedoアプリケーション・プログラムは、TMA TCP Gatewayを介して、次の2つのカテゴリに属するリモート・サービスをリクエストできます。

  • もともとは従来のOLTP環境用に開発された後に、Oracle Tuxedoと連携できるように適合化された既存のアプリケーション・プログラム。
  • XATMIまたはATMI (Oracle Tuxedo)環境に限定した形で開発されたサービス。このカテゴリに当てはまるものは、リモートのOracle Tuxedoリージョン側にあるサービスです。

リモート・サービスがOracle Tuxedo環境に限定した形で開発された場合は、そのサービスに必要な入力がどうなるかは、次の3つの要因で決まります。

一方、リモート・サービスが既存のOLTPアプリケーション・プログラムである場合は、たいてい、入力に対する要件が他にも必要になります。たとえば、多くのシステムで、入力として端末データも要求されます。

前述したように、TMA TCP Gatewayに備わっている構成能力を上手に活用すれば、ほとんどの場合、開発するOracle Tuxedoアプリケーションのソース・コードの中で、端末データなどの制御情報を扱う必要はありません。たとえば、TMA TCP Gatewayの構成に付随するVIEW定義の中で、端末制御コードを扱うことができます。

Oracle Tuxedoサービスの通常の入力要件の詳細は、Oracle Tuxedoプログラマーズ・ガイドを参照してください。

親トピック: 入出力に関する問題

2.6.1.3 出力データの考慮事項

Oracle Tuxedo環境の配置の透過性を維持するために、TMA TCP GatewayはOracle Tuxedoの入力バッファのデータを専用の出力バッファに残しておきません。したがって、入出力に同じバッファを使用したときの結果を理解しておかないと問題が起きます。

具体的に言うと、既存のOracle Tuxedoアプリケーションの中には、サービス・リクエストのやり取りの間に、結果を蓄積したり、アプリケーションの状態を維持するためにFMLバッファを使用するものもあります。開発者がそのようなアプリケーションにTMA TCP Gatewayを追加する場合は、次のいずれかを実施する必要があります。

  • リクエストを作成するクライアント・プログラム(またはサービス・ルーチン)に、必要なデータのコピーを取っておくようにします。
  • リモート・サービスが出力レコードと一緒に入力データを戻すようします。

この要件は、TMA TCP Gatewayを使用する前からあった要件と変わりません。つまり、FMLバッファに出力データを蓄積するアプリケーション・プログラムの場合は、新しいバッファでも初期化しなおしたバッファでもなく、元のFML入力バッファ内にサービスが(出力データを付加した状態で)応答を戻すようにしなくてはなりません。

親トピック: 入出力に関する問題

2.6.2 一部のATMI関数を使用する際の制限事項

ATMIインタフェースとしては、主に会話、トランザクションおよびクライアント識別に関連する機能と関数がありますが、アプリケーション・プログラムがこの機能や関数を使用してTMA TCP Gatewayを介してやり取りできるわけではありません。

このガイドでは、このように常時意識する必要のあるタイプの制限事項を運用上の考慮事項として扱ってします。具体的な運用上の考慮事項については、次の項で説明します:

ノート:

これから説明するローカルのアプリケーション・プログラムとは、ユーザー側のOracle Tuxedoリージョンの内側にあるアプリケーション・プログラムです。リモートのアプリケーション・プログラムとは、ユーザー側のOracle Tuxedoリージョンの外側にあるアプリケーション・プログラムです。

親トピック: プログラミングの考慮事項

2.6.2.1 会話型通信の関数

会話型通信の関数には次の運用上の考慮事項が適用されます。

  • ローカルのクライアント・プログラムとサーバー・プログラムはtpconnect()関数を使用してリモート・サービスとの会話を確立することができません。
  • リモートのクライアント・プログラムとサーバー・プログラムはtpconnect()関数を使用してローカル・サービスとの会話を確立することができません。
  • tpsend()、tprecv()およびtpdiscon()の各関数も同様に、TMA TCP Gatewayを介した通信に使用することができません。
2.6.2.2 トランザクション型でない通信

TMA TCP Gateway製品はトランザクション型でない通信のみをサポートします。したがって、TMA TCP Gatewayを介するすべての通信には、次の運用上の考慮事項が適用されます。

  • ローカルのクライアント・プログラムまたはサーバー・プログラムから呼び出されるリモート・サービスは必ず、任意のローカル・トランザクションの範囲の中に入れない形で実行するようにします。
  • リモートのクライアント・プログラムまたはサーバー・プログラムから呼び出されるローカル・サービスは必ず、任意のローカル・トランザクションの範囲に入れない形で実行するようにします。
  • リモート・サービスを呼び出すローカルのクライアント・プログラムまたはサーバー・プログラムは、tx_begin()/tx_commit()ペアやtpbegin()/tpcommit()ペアのような、任意のローカル・トランザクションの範囲の中には入れない形で、tpcall()関数、またはtpacall()関数とtpgetrply()関数を実行する必要があります。
  • ローカルのクライアント・プログラムまたはサーバー・プログラムが、ローカル・トランザクションの範囲の中でリモート・サービスを呼び出す必要がある場合は、tpcall()関数またはtpacall()関数に対するフラグの1つとして、TPNOTRANを指定する必要があります。
2.6.2.3 tpsprio( )関数とtpgprio( )関数

tpsprio()関数とtpgprio()関数には、次の運用上の考慮事項が適用されます。

  • ローカルのクライアント・プログラムとサーバー・プログラムが、tpsprio()関数を使用してリモート・サービスの処理の優先順位を設定することはできません。tpsprio()関数を呼び出すと、かわりにローカルのTMA TCP Gatewayの優先順位が設定されます。
  • リモートのクライアント・プログラムとサーバー・プログラムが、tpsprio()関数を使用してローカル・サービスの処理の優先順位を設定することはできません。
  • ローカルのクライアント・プログラムまたはサーバー・プログラムがtpgprio()関数を使用してリモート・サービスの優先順位を確認すると、ローカルのTMA TCP Gatewayの優先順位が戻されます。
2.6.2.4 tpbroadcast()関数とtpnotify()関数

tpbroadcast()関数とtpnotify()関数には、次の運用上の考慮事項が適用されます。

  • ローカルのクライアント・プログラムは、tpbroadcast()関数を使用して、リモートのクライアント・プログラムとの間で任意通知型のメッセージを送受信することができません。
  • ローカル・サービスは、tpbroadcast()関数やtpnotify()関数を使用して、リモートのクライアント・プログラムとの間でメッセージを送受信することができません。

2.6.3 エラー処理

ローカルのアプリケーション・プログラムがTMA TCP Gatewayを介してリクエストを送信する場合、3種類のエラーが発生する可能性があります。次のトピックで、TMA TCP Gatewayがこれらの異なる種類のエラーをどのように処理するかについて説明します。

親トピック: プログラミングの考慮事項

2.6.3.1 ゲートウェイのエラー

ローカル・ゲートウェイまたはリモート・ゲートウェイで発生したエラーは、Oracle TuxedoのULOGファイルに記録され、関連するサービス・リクエストは失敗します。また、該当するエラー・コードも呼出し元に戻されます。

親トピック: エラー処理

2.6.3.2 リモート・システムの障害

リモート・システムで問題が発生した場合は、サービス・リクエストは失敗するか、またはタイムアウトします。結果がどちらになるかは、リモート・システム側でTMA TCP Gatewayがどのように障害を検出しているのかに応じて決まります。

リモートのターゲット・システム側では、TMA TCP Gatewayが特定のタイプの障害を検出できない場合は、TMA TCP Gatewayのブロッキング・タイムアウト・パラメータの値を調整すれば、時間の制約を受けずに問題を検出できます。

ブロッキング・タイムアウト・パラメータの詳細は、「Oracle TMA TCP Gatewayの構成」を参照してください

親トピック: エラー処理

2.6.3.3 アプリケーション・エラー

アプリケーション・エラーはリモート・システムの障害と似ています。リモート・システムは、エラー・メッセージの生成元になる情報をローカルのTMA TCP Gatewayに渡すために、エラー・インジケータを使用することもあれば、使用しないこともあります。そのようなエラー・インジケータが存在しない場合、サービス・ルーチンは通常、独自のメカニズムを使用して障害を呼出し元に通知します。

アプリケーション・エラーが発生したときに、サービス・ルーチンによっては、通常の出力レコードを1件も戻さないものもあります。かわりに、障害メッセージを含む文字列のように、エラーが発生したことを示す他のなんらかのデータを戻すことがあります。

TMA TCP Gatewayは、リモート・システムからサービスの障害メッセージを受信すると、次の処理を行います。

  • 必要に応じて、GWICONFIGファイル内に記述されている指示に従って、出力バッファを変換します。
  • 構成に指示があれば、エラー・レコードをULOGファイルに書き込みます。
  • 該当するタイプのOracle Tuxedoバッファを呼出し元に戻します。

ノート:

Oracle Tuxedoアプリケーションは、サービスの障害を検出したときに、戻されたバッファが、実際に必要としているタイプかどうかチェックしなくなります。Oracle Tuxedoアプリケーション・プログラムは、障害が発生したときに戻されたバッファを無視することがあります。バッファのタイプを確認する必要がある場合は、Oracle Tuxedoのtptypes()関数を使用してください。タイプが不明な場合は、それに応じた形でバッファを処理できます(たとえば、エラー文字列を含むウィンドウを表示するなど)。

親トピック: エラー処理