|
|
Tuxedo Mainframe Adapter for TCP Gateway(以後TMA TCP Gatewayと呼ぶ)の処理の仕組みを理解するには、次の処理の内容を理解する必要があります。
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のプログラミング環境に対する知識が必要になるという点で、プログラミングという行為と考えて差し支えありません。しかし、構成パラメータの影響を受けるアプリケーション・プログラムは多数に及ぶため、通常は管理者が構成を担当します。 |
tmbootコマンドを使用してOracle Tuxedoソフトウェアを起動すると、TMA TCP Gatewayは次のように初期化を行います。
TMA TCP Gatewayはローカルのクライアント・プログラムからOracle Tuxedoサービスのリクエストを受信すると、次のようにリクエストを処理します。
クライアント・プログラムが、TMA TCP Gatewayを介してアクセス可能なリモート・サービスに対するリクエストを送信すると、Oracle Tuxedoはそのリクエストを、サービスのリクエストを待機しているゲートウェイに転送します。
TMA TCP Gatewayは、どのリモート・システムが各リクエストを処理するのかを判断します。目的のリモート・システムを決めるために、データ依存型のルーティング・ルールを使用できます。
この時点で、目的のリモート・システムへの接続がない場合、または既存の接続が切断されている場合、TMA TCP Gatewayは新しい接続を開きます。
リモート・システムが接続の障害を示す情報を戻した場合は、Oracle Tuxedoサービスのリクエストは失敗し、エラーが呼出し元に戻されます。戻されるエラーの値が実際にどうなるかは、接続の障害が発生したタイミングに応じて決まります。障害に関する情報はULOGファイルに書き込まれます。
場合によっては、サービス・リクエストに関連付けられている型付きバッファを変換しないと、サービス・リクエストをリモート・システムに送信できないことがあります。型変換の処理には、リモート・サービス側で受付けが可能なフォーマットにバッファのレイアウトを変更する処理が含まれます。
たとえば、ローカルのクライアント・プログラムが、リモート・サービスが処理できないFMLバッファにユーザー入力データを格納する場合は、リモート・サービス側で実際に必要としている構造にバッファを変換する必要があります。
入力の型変換が必要な場合、プログラマまたは管理者は次の手順に従う必要があります。
これらの手順が完了すると、TMA TCP Gatewayが必要な型変換をすべて自動的に実行します。
VIEW定義を作成して型変換を進める方法については、「Oracle TMA TCP Gatewayのデータ・マッピングに関する構成」を参照してください。TMA TCP Gatewayの構成ファイルについては、「Oracle TMA TCP Gatewayの構成」を参照してください。
データは必要に応じて、TMA TCP Gatewayソフトウェアによって自動的に変換されます。変換とは、ワード長、バイト・オーダーおよび文字エンコードという、そのデータ型本来の表現形態を変更することを指します。
データが正しく変換されるように、管理者はGWICONFIG構成ファイルで何種類かのパラメータを指定する必要があります。TMA TCP Gatewayによるデータ変換の仕組みの詳細は、「Oracle TMA TCP Gatewayのデータ・マッピングに関する構成」の項を参照してください。
TMA TCP Gateway製品はリクエスト・メッセージを作成します。このメッセージは次の項目で構成され、リモート・システムに送信されます。
リクエスト・メッセージを送信した後に、TMA TCP Gatewayは応答操作を実行します。リモート・システムからメッセージを受け取る前に、TMA TCP Gatewayが時間切れによるタイムアウト情報を受信すると、TPETIMEエラーが呼出し元に戻されます。
TMA TCP Gatewayが応答を受信した後に、データ表現が必要に応じて、入力時とは逆向きに変換されます。詳細は、このドキュメントの「ステップ4: 入力データを変換する」の項を参照してください。
応答のフォーマットがローカルのクライアント・プログラムに適合しない場合は、TMA TCP Gatewayがその応答を適切なバッファ・フォーマットに変換します。
出力の変換が必要な場合、プログラマまたは管理者は次の手順に従う必要があります。
これらの手順が完了すると、必要な変換が自動的に実行されるようになります。
VIEW定義を作成して型変換を容易にする方法については、「Oracle TMA TCP Gatewayのデータ・マッピングに関する構成」の項を参照してください。TMA TCP Gatewayの構成ファイルについては、「Oracle TMA TCP Gatewayの構成」の項を参照してください。
出力の型変換および出力データのトランスレーションが完了したOracle Tuxedoバッファは、TPSUCCESSまたはTPFAILという指標情報が付加された状態で、呼出し元に戻されます。
TMA TCP Gatewayソフトウェアは、リモートのサービス・リクエスト(リモート・システムからのサービス・リクエスト)をローカル・リクエストのときとほぼ同じように処理します。簡単にまとめると、次のようになります。
レコード、バッファおよびデータの変換の詳細は、「ローカルのサービス・リクエストの処理」の項を参照してください。
tmshutdownコマンドを使用して停止リクエストをTMA TCP Gatewayに送信すると、TMA TCP Gatewayは次の処理を実行します。
TMA TCP Gatewayを介してリクエストを送信するOracle Tuxedoアプリケーション・プログラムの開発は全体的に、他のOracle Tuxedoアプリケーション・プログラムの開発と変わりません。
TMA TCP Gateway製品は、ATMIインタフェースやXATMIインタフェースに備わっているリクエスト/応答の通信機能をすべてサポートしています。しかも、サポートしているすべての機能を、Oracle Tuxedoのドキュメントに記載されている通常の方式で使用できます。
この項では、TMA TCP Gatewayを使用するアプリケーション・プログラムをプログラマが開発する際に考慮する必要がある入出力の問題について何点か説明します。
「ローカルのサービス・リクエストの処理」の項では、リモート・システムまたはリモート・リージョン、およびローカル・システムが受付け可能なフォーマットに入出力パラメータを変換する必要がある、様々なケースについて説明しています。
TMA TCP Gateway製品の構成は非常に性能が高く、パラメータの変換やマッピングが簡単になっているため、別の手段でプログラミングする必要がありません。
TMA TCP Gatewayの構成ファイル(GWICONFIGとDMCONFIG)に設定情報が一元的されており、これらのファイルを使用して、ローカル・システムとリモート・システムまたはリモート・リージョンとの間の関係を定義し維持できます。これらの関係としては、入出力パラメータのマッピング以外にも、サービス名のマッピング(リモート・サービス名をローカル・サービス名にマップすること)とエラー・レコードのマッピングを行うことができます。
GWICONFIG構成ファイルの詳細は、「Oracle TMA TCP Gatewayの構成」の項を参照してください。
Oracle Tuxedoアプリケーション・プログラムは、TMA TCP Gatewayを介して、次の2つのカテゴリに属するリモート・サービスをリクエストできます。
リモート・サービスがOracle Tuxedo環境に限定した形で開発された場合は、そのサービスに必要な入力がどうなるかは、次の3つの要因で決まります。
一方、リモート・サービスが既存のOLTPアプリケーション・プログラムである場合は、たいてい、入力に対する要件が他にも必要になります。たとえば、多くのシステムで、入力として端末データも要求されます。
前述したように、TMA TCP Gatewayに備わっている構成能力を上手に活用すれば、ほとんどの場合、開発するOracle Tuxedoアプリケーションのソース・コードの中で、端末データなどの制御情報を扱う必要はありません。たとえば、TMA TCP Gatewayの構成に付随するVIEW定義の中で、端末制御コードを扱うことができます。
Oracle Tuxedoサービスの通常の入力要件に関する詳細は、Oracle Tuxedoプログラマーズ・ガイドを参照してください。
Oracle Tuxedo環境の配置の透過性を維持するために、TMA TCP GatewayはOracle Tuxedoの入力バッファのデータを専用の出力バッファに残しておきません。したがって、入出力に同じバッファを使用したときの結果を理解しておかないと問題が起きます。
具体的に言うと、既存のOracle Tuxedoアプリケーションの中には、サービス・リクエストのやり取りの間に、結果を蓄積したり、アプリケーションの状態を維持するためにFMLバッファを使用するものもあります。開発者がそのようなアプリケーションにTMA TCP Gatewayを追加する場合は、次のいずれかを実施する必要があります。
この要件は、TMA TCP Gatewayを使用する前からあった要件と変わりません。つまり、FMLバッファに出力データを蓄積するアプリケーション・プログラムの場合は、新しいバッファでも初期化しなおしたバッファでもなく、元のFML入力バッファ内にサービスが(出力データを付加した状態で)応答を戻すようにしなくてはなりません。
ATMIインタフェースとしては、主に会話、トランザクションおよびクライアント識別に関連する機能と関数がありますが、アプリケーション・プログラムがこの機能や関数を使用してTMA TCP Gatewayを介してやり取りできるわけではありません。
このガイドでは、このように常時意識する必要のあるタイプの制限事項を運用上の考慮事項として扱ってします。次の項から、具体的な運用上の考慮事項について説明します。
| 注意: | これから説明するローカルのアプリケーション・プログラムとは、ユーザー側のOracle Tuxedoリージョンの内側にあるアプリケーション・プログラムです。リモートのアプリケーション・プログラムとは、ユーザー側のOracle Tuxedoリージョンの外側にあるアプリケーション・プログラムです。 |
TMA TCP Gateway製品はトランザクション型でない通信のみをサポートします。したがって、TMA TCP Gatewayを介するすべての通信には、次の運用上の考慮事項が適用されます。
tx_begin()/tx_commit()ペアやtpbegin()/tpcommit()ペアのような、任意のローカル・トランザクションの範囲の中には入れない形で、tpcall()関数、またはtpacall()関数とtpgetrply()関数を実行する必要があります。tpcall()関数またはtpacall()関数に対するフラグの1つとして、TPNOTRANを指定する必要があります。 tpsprio()関数とtpgprio()関数には、次の運用上の考慮事項が適用されます。
tpsprio()関数を使用してリモート・サービスの処理の優先順位を設定することはできません。tpsprio()関数を呼び出すと、かわりにローカルのTMA TCP Gatewayの優先順位が設定されます。tpsprio()関数を使用してローカル・サービスの処理の優先順位を設定することはできません。tpgprio()関数を使用してリモート・サービスの優先順位を確認すると、ローカルのTMA TCP Gatewayの優先順位が戻されます。 tpbroadcast()関数とtpnotify()関数には、次の運用上の考慮事項が適用されます。
ローカルのアプリケーション・プログラムがTMA TCP Gatewayを介してリクエストを送信するときに、次の3種類のエラーを検出することがあります。
次の項から、TMA TCP Gatewayがこれらのタイプのエラーをどのように扱うのかについて説明します。
ローカル・ゲートウェイまたはリモート・ゲートウェイで発生したエラーは、Oracle TuxedoのULOGファイルに記録され、関連するサービス・リクエストは失敗します。また、該当するエラー・コードも呼出し元に戻されます。
リモート・システムで問題が発生した場合は、サービス・リクエストは失敗するか、またはタイムアウトします。結果がどちらになるかは、リモート・システム側でTMA TCP Gatewayがどのように障害を検出しているのかに応じて決まります。
リモートのターゲット・システム側では、TMA TCP Gatewayが特定のタイプの障害を検出できない場合は、TMA TCP Gatewayのブロッキング・タイムアウト・パラメータの値を調整すれば、時間の制約を受けずに問題を検出できます。
ブロッキング・タイムアウト・パラメータの詳細は、「Oracle TMA TCP Gatewayの構成」の項を参照してください。
アプリケーション・エラーはリモート・システムの障害と似ています。リモート・システムは、エラー・メッセージの生成元になる情報をローカルのTMA TCP Gatewayに渡すために、エラー・インジケータを使用することもあれば、使用しないこともあります。そのようなエラー・インジケータが存在しない場合、サービス・ルーチンは通常、独自のメカニズムを使用して障害を呼出し元に通知します。
アプリケーション・エラーが発生したときに、サービス・ルーチンによっては、通常の出力レコードを1件も戻さないものもあります。かわりに、障害メッセージを含む文字列のように、エラーが発生したことを示す他のなんらかのデータを戻すことがあります。
TMA TCP Gatewayは、リモート・システムからサービスの障害メッセージを受信すると、次の処理を行います。
| 注意: | Oracle Tuxedoアプリケーションは、サービスの障害を検出したときに、戻されたバッファが、実際に必要としているタイプかどうかチェックしなくなります。Oracle Tuxedoアプリケーション・プログラムは、障害が発生したときに戻されたバッファを無視することがあります。バッファのタイプを確認する必要がある場合は、Oracle Tuxedoのtptypes()関数を使用してください。タイプが不明な場合は、それに応じた形でバッファを処理できます(たとえば、エラー文字列を含むウィンドウを表示するなど)。 |
  
|