|
|
Oracle SALT では、外部 Web サービスを Tuxedo ドメインにインポートできます。外部 Web サービスを Tuxedo ドメインにインポートするには、最初に WSDL ファイルをロードして変換する必要があります。Oracle SALT WSDL 変換ユーティリティ (wsdlcvt) は、各 wsdl:operation を Oracle SALT のプロキシ サービスに変換します。変換された SALT のプロキシ サービスを標準的な Tuxedo ATMI 関数を使用して直接に呼び出すことができます。
Oracle SALT のプロキシ サービスの呼び出しは GWWS サーバに送信します。リクエストは Tuxedo タイプ バッファから SOAP メッセージに変換して、対応する外部 Web サービスに送信します。外部 Web サービスからの応答は、Tuxedo タイプ バッファに変換して、Tuxedo アプリケーションに返します。GWWS はプロキシ仲介として機能します。
サービスを呼び出す時にエラーが発生する場合、GWWS サーバは tperrno によりエラー状態を設定します。このエラー状態は Tuxedo アプリケーションによって取得できます。これにより、SALT のプロキシ サービスのエラー状態を検出し、処理することができます。
Oracle SALT では、WSDL 変換ユーティリティ (wsdlcvt) が提供されています。このユーティリティを使用すると、WSDL ファイルで定義されたサービスにアクセスするために Tuxedo ATMI プログラムを開発できるよう、外部 WSDL ファイルを Tuxedo の特定の定義ファイルに変換できます。
Oracle SALT は、以下のルールを使用して WSDL オブジェクト モデルを Tuxedo モデルに変換します。
wsdl:operation オブジェクトとその入力/出力メッセージの情報は、Tuxedo サービス メタデータ リポジトリの入力構文に準拠する Tuxedo サービスの定義として変換します。
表 4-1 に、WSDL ファイルと Tuxedo 定義ファイル間の詳細マッピングとの関係を示します。
以下の節では、Tuxedo アプリケーションから変換された SALT のプロキシ サービスの呼び出し方法について説明します。
Oracle SALT では、発信サービスの呼び出しに対する Tuxedo 要求/応答の通信パターンのみがサポートされています。Tuxedo アプリケーションは、以下の通信 Tuxedo ATMI により SALT のプロキシ サービスを要求することができます。
tpcall(1) / tpacall(1) / tpgetreply(1)
これらの基準的な ATMI 機能を Tuxedo タイプ バッファとともに入力パラメータとして呼び出すことができます。呼び出しが返された場合、Tuxedo タイプ バッファも返されます。このバッファは変換された外部 Web サービス インタフェースに準拠します。tpacall/tpgetreply は、SOAP 非同期通信と関連していません。
tpforward(1)
Tuxedo サーバ アプリケーションは、Tuxedo 要求を指定した SALT のプロキシ サービスに送付するためにこの機能を使用できます。応答バッファは、従来のネイティブ Tuxedo サービスと同じようにクライアント アプリケーションの応答キューに直接送信されます。
TMQFORWARD を有効したキュー ベース通信
Tuxedo システム サーバ TMQFORWARD は、キューに登録された要求を受け付けて、キューと同じ名前である Oracle SALT のプロキシ サービスに送信します。
Oracle SALT には、以下の Tuxedo 通信パターンはサポートされていません。
GWWS を起動して Oracle SALT のプロキシ サービスを公開する場合、このサービスを呼び出すために Tuxedo アプリケーションを生成できます。SALT のプロキシ サービスをアクセスするプログラムを開発するには、次の手順に従います。
| 注意 : | GWWS は、wsdlcvt を使用して生成された FML32 フィールド テーブル ファイルを常に使用します。フィールド名がユニークであることをシステム レベルで確認する必要があります。2 つまたは複数のフィールドは同じフィールド名と関連つけられている場合、フィールド名を変更します。変更したフィールド名に従って、Tuxedo サービス メタデータ リポジトリの定義も変更するようにしてください。 生成された FML32 フィールド テーブルのフィールド インデックスのベース数は、無効なデフォルト値から有効な値に変更する必要があります。テーブルのすべてのフィールド インデックスは全体のシステム レベルでユニークであるかを確認できます。 |
tpcall(1) または tpacall(1) を使用することができます。
外部 Web サービスをアクセスする時に GWWS サーバにエラーが発生した場合、Tuxedo アプリケーションがエラーを診断できるように tperrno を設定します。表 4-2 に、使用可能な Oracle SALT のプロキシ サービス tperrno 値を示します。
リストされたすべてのルールは、WSDL 入力/出力メッセージを Tuxedo メタデータ inbuf/outbuf の定義にマップするために使用されます。いくつかのルールを変更すると、WSDL ファイルのデフォルト メッセージを Tuxedo メタデータ errbuf にマップすることができます。
メタデータ errbuf を SOAP エラー メッセージにマップするために、Tux モードおよび XSD モードという 2 つのモードがあります。
XSD モードの各サービス (servicemode=webservice) については、メタデータで type=FML32 の errbuf が含まれています。
errbuf は FML32 バッファです。これは対応に表れる SOAP : エラー メッセージの記述で、SOAP 1.1 および 1.2 に異なります。従って、errbuf 定義の内容は SOAP バージョンと WSDL エラー メッセージの両方により決定します。
パラメータの詳細/詳細 (1.1/1.2) は FML32 フィールドで、各フィールドは 1 つの wsdl : エラー メッセージ (wsdl:fault は存在する場合) で定義された wsdl:part を示します。各部は、FML32 フィールド内に param (フィールド) として定義されます。マッピング ルールは入力/出力バッファと同じです。しかし、param の requiredcount は 0 であるため、SOAP エラー メッセージの一部が表示されない可能性があります。
soap:fault message の他の要素は、常に errbuf 内のフィールドとして定義します。要素の MUST または OPTIONAL に応じて、requiredcount は 1 または 0 です。
メタデータ内の各部定義は、SOAP エラー メッセージ内の <detail> をエラー バッファ内のフィールドに変換する方法を示します。
  
|