|
|
Oracle SALT では、Tuxedo サービス メタデータ リポジトリを利用して、Tuxedo の従来のサービスと SALT プロキシ サービスの両方のサービス契約情報を定義します。Tuxedo サービス一覧で指定したすべてのサービスに関するサービス規約情報を、ローカル Tuxedo ドメインによって提供される Tuxedo サービス メタデータ リポジトリ サービスにアクセスして取得します。通常は、以下に示すように、SALT から TMMETADATA システムを呼び出します。
GWWS サーバの実行時間の時
Tuxedo サービス メタデータ リポジトリを呼び出し、適切な時間に必要な Tuxedo サービス定義を取得します。
Tuxedo サービス メタデータ リポジトリを呼び出し、必要な Tuxedo サービス定義を取得して、それを WSDL 記述に変換します。
以下のトピックでは、SALT 特有の Tuxedo サービス メタデータ リポジトリ キーワードとパラメータの使用について説明します。
表 2-1 では、SALT で使用および解釈される Tuxedo サービス メタデータ リポジトリのサービスレベル キーワードを示します。
| 注意 : | 指定されていないメタデータ リポジトリのサービスレベル キーワードは、Oracle SALT とは関係性がなく、SALT コンポーネントが Tuxedo サービス メタデータ リポジトリをロードする時に無視されます。 |
Tuxedo サービス メタデータ リポジトリでは、パラメータは Tuxedo サービスの型付きバッファ内にカプセル化されたサブ要素として解釈されます。パラメータごとに、データ型、バッファ内の出現回数、サイズ制限、その他 Tuxedo に特有の制限を設定できます。以下に注意してください。
バッファの個々のパラメータが VIEW/VIEW32 構造のメンバー 1 つを表します。
バッファの個々のパラメータが、バッファ内に存在する可能性のある FML/FML32 フィールド要素を表します。
Tuxedo によってバッファ全体が 1 つのデータのように扱われます。バッファに対して最大で 1 つのパラメータを設定することが認められており、これを使って制約 (バッファ サイズのしきい値など) を定義できます。
パラメータを使用してバッファ型の詳細について説明することができます。
表 2-2 では、SALT で使用および解訳される Tuxedo サービス メタデータ リポジトリのパラメータレベル キーワードを示します。
| 注意 : | 指定されていないメタデータ リポジトリのパラメータレベル キーワードは、Oracle SALT とは関係性がなく、SALT コンポーネントが Tuxedo サービス メタデータ リポジトリをロードする時に無視されます。 |
|
|||
|
|||
この節では、ネイティブ Tuxedo サービスを Web サービスとしてエクスポーズするために必要なコンフィグレーションと省略可能なコンフィグレーション タスクについて説明します。
1 つまたは複数の HTTP/S エンドポイントを介して一連の Tuxedo サービスを Web サービスとしてエクスポーズするには、ネイティブ WSDF を定義する必要があります。
各ネイティブ WSDF はユニークな WSDF 名で定義する必要があります。WSDF では、Web サービス アプリケーションの詳細 (SOAP プロトコルの詳細、Web サービスのオペレーションとしてエクスポーズする Tuxedo サービスの一覧など) に対して 1 つまたは複数の <WSBinding> 要素を定義できます。
個々の WSBinding オブジェクトは <WSBinding> 要素を使用して定義します。個々の WSBinding オブジェクトは、WSDF 内でユニークな WSBinding ID を使用して定義する必要があります。WSBinding id は GWWS によって使用される SALTDEPLOY ファイルの参照に必要な識別子です。
個々の WSBinding オブジェクトは、<SOAP> サブ要素を使用して SOAP プロトコルの詳細に関連付けることができます。WSBinding オブジェクトには、デフォルトでは SOAP 1.1 および document/literal スタイルの SOAP メッセージが適用されます。
コード リスト 2-1 では、<SOAP> サブ要素を使用して SOAP プロトコルの詳細を再定義する方法を示します。
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper" />
<Service name="tolower" />
</Servicegroup>
<SOAP version=”1.2” style=”rpc” use=”encoded”>
<AccessingPoints>
...
</AccessingPoints>
</SOAP>
</WSBinding>
</Definition>
<SOAP> 要素内で、一連のアクセス エンドポイントを指定できます。対応する GWWS サーバは、これらのアクセス エンドポイントの URL 値を使用してリスン HTTP/S プロトコル ポートを作成します。着信 WSBinding オブジェクトに対して各 GWWS サーバで HTTP および HTTPS エンドポイントを最大で 1 つ指定することをお勧めします。
個々の WSBinding オブジェクトは、<Servicegroup> サブ要素を使用して Tuxedo サービスのグループに定義する必要があります。<Servicegroup> の下の各 <Service> 要素は、Web サービスのクライアントからアクセスできる Tuxedo サービスを表します。
個々のサービス オブジェクトは、<Service> 要素を使用して定義します。各サービスは、エクスポーズされた Tuxedo サービスを示すように「name」属性で指定する必要があります。通常、Tuxedo サービス メタデータ リポジトリから Tuxedo サービス規約情報を取得するには「name」値がキー値として使用されます。
コード リスト 2-2 では、WSBinding のサービス グループを定義する方法を示します。
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper" />
<Service name="tolower" />
</Servicegroup>
...
</WSBinding>
</Definition>
SOAP XML ペイロードおよび Tuxedo 型付きバッファの変換ルーチンをカスタマイズするために独自のプラグイン機能を作成できます。詳細については、『Web サービスのプログラミング』の「Oracle SALT プラグインの使用」および「プラグイン ライブラリのコンフィグレーション」を参照してください。
プラグインを作成しコンフィグレーションすると、そのサービスのユーザ定義データマッピング ルールを指定するには、<service> 要素を使用してそのプラグインを参照できます。<Msghandler> 要素は、メッセージ レベル (<Input>、<Output>、または <Fault>) で定義することができます。この要素を使用して、メッセージを変換するために「P_CUSTOM_TYPE」カテゴリ プラグインのどの実装を使用する必要があるかについて指定します。<Msghandler> 要素の内容はプラグインの名前です。
コード リスト 2-3 では、入力を変換するために「MBCONV」カスタム タイプ プラグインを使用するサービスと、出力を変換するために「XMLCONV」カスタム タイプ プラグインを使用するサービスを示します。
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper" >
<Input>
<Msghandler>MBCONV</Msghandler>
</Input>
<Output>
<Msghandler>XMLCONV</Msghandler>
</Output>
</Service>
</Servicegroup>
...
</WSBinding>
</Definition>
高度な Web サービスの機能は、WS-Policy ファイル (例えば、信頼性のあるメッセージングおよび Web サービスのメッセージレベル セキュリティ) をコンフィグレーションして有効できます。これらの機能を使用するには、WS-Policy ファイルの作成が必要になる場合があります。Web Service Policy Framework 仕様により、Web サービスのポリシーを記述および通信するための汎用的なモデルと構文が提供されています。
WS-Policy ファイルを使用する場合、<Policy> 要素を定義してこれらの異なる WS-Policy ファイルを WSDF に組み込む必要があります。ポリシー ファイル パスの指定には location 属性を使用します。絶対ファイル パスでも相対ファイル パスでも指定できます。省略可能な use 属性をメッセージ レベルのアサーション ポリシー ファイルで使用すると、適用するメッセージ (リクエスト (入力) メッセージ、応答 (出力) メッセージ、またはエラー メッセージ、あるいはこれら 3 つの組み合わせ) を指定できます。
WSDF には、WS-Policy ファイルを参照する 2 つのサブ要素があります。
Servicegroup>Service>
Oracle SALT には、使用されることの多い用途に合わせてあらかじめパッケージ化された WS-Policy ファイルが含まれています。これらの WS-Policy ファイルは $TUXDIR/udataobj/salt/policy ディレクトリにあります。これらのファイルを参照するには、location="salt:<policy_file_name>" を使用します。
コード リスト 2-4 では、WS-Policy ファイルをネイティブ WSDF ファイルに使用する例を表します。
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Policy location=”./endpoint_policy.xml” />
<Policy location=”/usr/resc/all_input_msg_policy.xml” use=”input” />
<Service name="toupper">
<Policy location=”service_policy.xml” />
<Policy location=”/usr/resc/input_message_policy.xml”
use=”input” />
</Service>
<Service name="tolower" />
</Servicegroup>
....
</WSBinding>
</Definition>
詳細については、「WSDF ファイルで信頼性のあるメッセージング ポリシー ファイルの指定」および「WS-SecurityPolicy ファイルの使用」を参照してください。
Tuxedo のネイティブ WSDF が作成さたら、SALT WSDL の生成ユーティリティ tmwsdlgen を使用して、対応する WSDL ファイルを生成できます。次に、「app1.wsdf」という WSDF から「app1.wsdl」という WSDL ファイルを生成したサンプル コマンドを示します。
tmwsdlgen -c app1.wsdf -o app1.wsdl
| 注意 : | tmwsdlgen を実行する前に、TUXCONFIG 環境変数を正しく設定し、TMMETADATA を使用して関連する Tuxedo アプリケーションを起動する必要があります。 |
または、「-o」オプションを使用して出力 WSDL ファイル名を指定できます。指定しない場合、tmwsdlgen は、デフォルト値として「tuxedo.wsdl」という名前の WSDL ファイルを作成します。
ネイティブ WSDF ファイルに、CARRAY バッファを使用する Tuxedo サービスが含まれている場合、CARRAY バッファ マッピングに対して別のスタイルの WSDL ファイルを生成するために tmwsdlgen オプションを指定できます。デフォルトでは、CARRAY バッファが SOAP メッセージで xsd:base64Binary XML データ型としてマップされています。詳細については、『Web サービスのプログラミング』の「データ型のマッピングとメッセージ変換」および『リファレンス ガイド』の「tmwsdlgen」を参照してください。
Tuxedo から外部 Web サービスを呼出すには、以下のコンフィグレーション タスクを実行します。
Oracle SALT には、外部 WSDL ファイルを Tuxedo 定義に変換するための WSDL 変換ユーティリティが付属しています。WSDL ファイルは Extensible Stylesheet Language Transformations (XSLT) テクノロジを使用して変換されます。SALT のインストール パッケージには、デフォルトの XSLT ツールキットとして使用する Apache Xalan Java 2.7.0 がバンドルされています。
Oracle SALT WSDL コンバータは 2 つの部分で構成されています。
wsdlcvt は、Xalan ツールキットを呼び出します。このラッパー スクリプトでは、使いやすい WSDL コンバータ インタフェースが提供されています。
次のサンプル コマンドでは、外部 WSDL ファイルを変換して Tuxedo 定義ファイルを生成しています。
wsdlcvt -i http://api.google.com/GoogleSearch.wsdl -o GSearch
表 2-3 では、Oracle SALT WSDL コンバータによって生成された Tuxedo 定義ファイルを示します。
|
|||
|
|||
|
表 2-4 では、WSDL 要素から Tuxedo サービス メタデータ定義キーワードへのマッピング ルールを示します。
|
||||
表 2-5 では、WSDL 要素から WSDF 要素へのマッピング ルールを示します。
発信 Web サービス アプリケーションをコンフィグレーションするには、以下の変換後のタスクを実行する必要があります。
WSDL ファイルを変換すると、コンテキスト情報の切り捨てまたは消失のせいで、予期せぬ名前の競合が発生する場合があります。生成されたサービス メタデータ定義と FML32 フィールド テーブル ファイルを使用する前に、以下のような名前の衝突を解決する必要があります。
tuxservice」の定義が重複している場合は解決する
SALT プロキシ サービス メタデータ定義のキーワード tuxservice は、元の Web サービス オペレーションのローカル名が 15 文字以上ある場合はそれ以降を切り捨てた値になります。そのため、複数 SALT プロキシ サービス エントリで、切り捨て後の truncated の値が重複する可能性があります。GWWS サーバでは tuxservice の値を公開済みのサービス名として使用するため、サービス要求が確実に配信されるよう、複数の SALT プロキシ サービス間の名前の競合を手動で解決しなければなりません。名前の競合を解決するには、tuxservice にユニークで意味のある名前を割り当てる必要があります。
外部 WSDL ファイルを Tuxedo 定義に変換すると、各 wsdl:message が解析されて FML32 バッファ フォーマットとしてマップされます。FML32 バッファ フォーマットには、wsdl:message の基本 XML スニペットを表す FML32 フィールドのセットが含まれています。生成される FML32 フィールドは、デフォルトでは対応する XML 要素のローカル名に基づいて命名されます。
生成されたフィールド テーブル ファイル内の FML32 フィールド定義はフィールド名でソートされるため、重複している名前を簡単に見つけることができます。SOAP/FML32 のマッピングを実現するには、フィールド名の競合を解決しなければなりません。生成によって重複したフィールド名を、ユニークで意味のある他の FML32 フィールド名値に変更する必要があります。それに合わせて、生成された SALT プロキシ サービス定義内の対応するサービス メタデータ キーワード param の値も変更しなければなりません。FML32 フィールドとサービス メタデータ キーワード「param」について生成されるコメントは、どの name とどの param が対応するかを調べる際に有用です。
名前の競合が解決したら、tmloadrepos ユーティリティを使用して、SALT プロキシ サービス メタデータ定義を Tuxedo サービス メタデータ リポジトリにロードします。詳細については、「Oracle Tuxedo サービス メタデータ リポジトリ」の「tmloadrepos」を参照してください。
発信 Web サービス用に GWWS サーバを起動する前に、以下の環境変数を設定する必要があります。
FIELDTBLS32 環境変数を更新します。XSDDIR および XSDFILES 環境変数を設定します。XSDDIR および XSDFILES 環境変数があります。これらの環境変数は、実行時にすべての外部 XML スキーマ ファイルをロードするには GWWS サーバによって使用されます。複数の XML スキーマ ファイル名をカンマ「,」で区切る必要があります。例えば、XML スキーマ ファイル a.xsd、b.xsd および c.xsd を /home/user/myxsd ディレクトリに配置すると、GWWS サーバを起動する前に XSDDIR および XSDFILES 環境変数を以下に示すように設定する必要があります。XSDDIR=/home/user/myxsd
XSDFILES=a.xsd,b.xsd,c.xsd
SALT デプロイメント ファイル (SALTDEPLOY) では、SALT Web サービスのアプリケーションを定義します。SALTDEPLOY ファイルはバイナリ SALTCONFIG ファイルの Web サービス アプリケーションに対する重要な入力です。
SALTDEPLOY ファイルを作成するには、次の手順に従います。
詳細については、『リファレンス ガイド』の「SALT デプロイメント ファイルのリファレンス」を参照してください。
必要な WSDF ファイルをすべて SALT デプロイメント ファイルにインポートする必要があります。各インポートした WSDF ファイルはユニークな WSDF 名前が設定されている必要があります。この名前はデプロイメントに関連付けるために GWWS サーバによって使用されます。インポートした各 WSDF ファイルは、SALTDEPLOY ファイルに指定した場所を介してローカルでアクセス可能である必要があります。
コード リスト 2-5 では、SALTDEPLOY ファイルに WSDF ファイルをインポートする方法について説明します。
<Deployment ..>
<WSDF>
<Import location="/home/user/simpapp_wsdf.xml" />
<Import location="/home/user/rmapp_wsdf.xml" />
<Import location="/home/user/google_search.wsdf" />
</WSDF>
...
</Deployment>
各 GWWS サーバは、インポートした WSDF ファイルに定義した着信 WSBinding オブジェクトおよび発信 WSBinding オブジェクトのグループと共にデプロイできます。各 WSBinding オブジェクトは、「ref=<wsdf_name>:<WSBinding id>」属性を使用して参照します。着信 WSBinding オブジェクトについては、GWWS サーバでは、WSBinding オブジェクトのエンドポイント リストから 1 つのアクセス エンドポイントを着信エンドポイントとして指定する必要があります。着信 WSBinding オブジェクトについては、各 GWWS サーバでは、WSBinding オブジェクトのエンドポイント リストから 0 またはそれ以上のアクセス エンドポイントを発信エンドポイントとして指定できます。
コード リスト 2-6 では、着信および発信エンドポイントで GWWS サーバをコンフィグレーションする方法について説明します。
<Deployment ..>
...
<WSGateway>
<GWInstance id="GWWS1">
<Inbound>
<Binding ref="app1:app1_binding">
<Endpoint use="simpapp_GWWS1_HTTPPort" />
<Endpoint use="simpapp_GWWS1_HTTPSPort" />
</Binding>
</Inbound>
<Outbound>
<Binding ref="app2:app2_binding">
<Endpoint use=" simpapp_GWWS1_HTTPPort" />
<Endpoint use=" simpapp_GWWS1_HTTPSPort" />
</Binding>
<Binding ref="app3:app3_binding" />
</Outbound>
</GWInstance>
</WSGateway>
...
</ Deployment>
GWWS サーバは、機能をオン/オフにするプロパティまたはサーバのパフォーマンスをチューニングする引数を設定するプロパティでコンフィグレーションできます。
プロパティは <GWInstance> の子要素 <Properties> にコンフィグレーションされます。各個別のプロパティは、「name」属性および「value」属性を含む <Property> 要素を使用して指定します。異なる「name」属性は、値を含む異なるプロパティ要素を表します。表 2-6 では、GWWS サーバ レベル プロパティを示します。
| 注意 : | GWWS での複数のエンコーディング サポートについては、「複数のエンコーディング サポートのコンフィグレーション」を参照してください。 |
| 注意 : | パフォーマンス チューニング プロパティの詳細については、「GWWS サーバのチューニング」を参照してください。 |
コード リスト 2-7 では、GWWS プロパティのコンフィグレーション例を示します。
<Deployment ..>
...
<WSGateway>
<GWInstance id="GWWS1">
.......
<Properties>
<Property name="thread_pool_size" value="20"/>
<Property name="enableMultiEncoding" value="true"/>
<Property name="timeout" value="600"/>
</Properties>
</GWInstance>
</WSGateway>
...
</ Deployment>
SALT では、SOAP メッセージ用の複数のエンコーディング、および SOAP メッセージと Tuxedo バッファの間のエンコーディング マッピングがサポートされています。文字エンコーディングとしては以下がサポートされます。
| 注意 : | ASCII、BIG5、CP1250、CP1251、CP1252、CP1253、CP1254、CP1255、CP1256、CP1257、CP1258、CP850、CP862、CP866、CP874、EUC-CN、EUC-JP、EUC-KR、GB18030、GB2312、GBK、ISO-2022-JP、ISO-8859-1、ISO-8859-13、ISO-8859-15、ISO-8859-2、ISO-8859-3、ISO-8859-4、ISO-8859-5、ISO-8859-6、ISO-8859-7、ISO-8859-8、ISO-8859-9、JOHAB、KOI8-R、SHIFT_JIS、TIS-620、UTF-16、UTF-16BE、UTF-16LE、UTF-32、UTF-32BE、UTF-32LE、UTF-7、UTF-8 |
GWWS での複数のエンコーディング サポートを有効にするには、GWWS サーバ レベル プロパティ「enableMultiEncoding」を "true" に設定します。
| 注意 : | GWWS では、UTF-8 以外の外部メッセージが UTF-8 に変換されます。ただし、エンコーディングの変換はサーバのパフォーマンスに影響します。デフォルトでは、エンコーディングの変換はオフで、UTF-8 エンコードのないメッセージが拒否されます。 |
<Deployment ..>
...
<WSGateway>
<GWInstance id="GWWS1">
.......
<Properties>
<Property name="enableMultiEncoding" value="true"/>
</Properties>
</GWInstance>
</WSGateway>
...
</ Deployment>
表 2-7 では、GWWS サーバ レベルの複数エンコーディング プロパティを有効にした場合に適用される、SOAP メッセージと Tuxedo バッファの間のエンコーディング マッピング ルールの詳細について説明します。
|
||||
|
||||
|
Oracle SALT では、GWWS サーバによって共有される一連のグローバル リソースを SALTDEPLOY ファイルに指定します。以下のシステムレベル リソースを SALTDEPLOY ファイルにコンフィグレーションできます。
証明書の情報は、SSL リスン エンドポイントを作成するまたは認証およびメッセージ署名用 X.509 証明書を使用するように GWWS サーバでコンフィグレーションする必要があります。同じデプロイメント ファイルに指定したすべての GWWS サーバは同じ証明書の設定 (秘密キー ファイル、信頼されている証明書ディレクトリなどを含む) を共有します。
秘密キー ファイルは <Certificate>/<PrivateKey> サブ要素を使用して設定します。秘密キー ファイルはローカルで保存され、PEM ファイル形式である必要があります。
<Certificate>/<VerifyClient> サーブ要素は true に設定すると、SSL クライアントを確認できます。デフォルトでは、GWWS サーバは SSL クライアントを確認しません。
SSL クライアントを確認する場合や X.509 証明書の認証機能が有効になっている場合、一連の信頼済み証明書はローカルで保存し、GWWS サーバで指定する必要があります。GWWS サーバの信頼済み証明書を定義するには 2 つの方法があります。
コード リスト 2-9 では、GWWS サーバの証明書をコンフィグレーションする SALTDEPLOY ファイルのセグメントを示します。
<Deployment ..>
...
<System>
<Certificates>
<PrivateKey>/home/user/gwws_cert.pem</PrivateKey>
<VerifyClient>true</VerifyClient>
<CertPath>/home/user/trusted_cert</CertPath>
</Certificates>
</System>
</Deployment
プラグインは、GWWS サーバの起動中に呼び出される関数のセットです。Oracle SALT には、プラグインを定義して実装するための共通インタフェースとして、プラグイン フレームワークが用意されています。プラグインを実装するには、実際の関数が含まれているダイナミック ライブラリを使用します。実装ライブラリは GWWS サーバの起動中に動的にロードされます。関数は、プラグイン インタフェースの実装として登録されます。
GWWS サーバがライブラリをロードできるように、ライブラリは <Plugin>/<Interface> 要素を使用して SALTDEPLOY ファイルに指定する必要があります。
コード リスト 2-10 では、GWWS サーバによってロードする複数のカスタマイズしたプラグイン ライブラリをコンフィグレーションする SALTDEPLOY ファイルのセグメントを示します。
<Deployment ..>
...
<System>
<Plugin>
<Interface lib=”plugin_1.so” />
<Interface lib=”plugin_2.so” />
</Plugin>
</System>
</Deployment
| 注意 : | プラグイン ライブラリは SALT 2.0 のプラグイン インタフェースを使用して開発すると、インタフェースの「id」および「name」属性を指定する必要はありません。これらの値はプラグイン インタフェースから取得できます。 |
| 注意 : | 詳細については、『Web サービスのプログラミング』の「Oracle SALT プラグインの使用」を参照してください。 |
現在の Oracle SALT は以下の高度な Web サービス メッセージング機能をサポートしています。
非同期 Web サービス メッセージングの着信と発信の両方をサポートします。
Oracle SALT では、着信サービスおよび発信サービスの両方に Web サービス アドレスがサポートされます。GWWS サーバによって使用される Web サービス アドレス (WS-Addressing) のメッセージは、『Web サービス アドレス仕様』の Web Service Addressing に準拠している必要があります (W3C Member Submission 2004 年 8 月 10 日)。
着信サービスは特有な Web service addressing のコンフィグレーションが必要ではありません。GWWS サーバは WS-Addressing リクエスト メッセージおよび非 WS-Addressing リクエスト メッセージによって受け付けて回答します。
発信サービスについては、以下の節で説明しているように Web service addressing のコンフィグレーションが必要です。
発信サービスについては、Web service addressing はバインディング レベルでコンフィグレーションします。SALTDEPLOY ファイルでは、各 GWWS サーバは WS-Addressing を有効にするために任意の参照した発信 WSBinding オブジェクトに対して <WSAddressing> 要素を使用して WS-Addressing エンドポイントを指定できます。
WS-Addressing エンドポイントを設定した後、GWWS サーバは起動時にリスン エンドポイントを作成します。発信 WSBinding に指定したすべてのサービスは WS-Addressing メッセージで呼出します。
コード リスト 2-11 では、参照した発信 Web サービス バインディングに対して WS-Addressing を有効にする SALTDEPLOY ファイルのセグメントを表します。
<Deployment ..>
...
<WSGateway>
<GWInstance id="GWWS1">
...
<Outbound>
<Binding ref="app1:app1_binding">
<WSAddressing>
<Endpoint address=”https://myhost:8801/app1_async_point”>
</WSAddressing>
<Endpoint use=" simpapp_GWWS1_HTTPPort" />
<Endpoint use=" simpapp_GWWS1_HTTPSPort" />
</Binding>
<Binding ref="app2:app2_binding">
<WSAddressing>
<Endpoint address=”https://myhost:8802/app2_async_point”>
</WSAddressing>
<Endpoint use=" simpapp_GWWS1_HTTPPort" />
<Endpoint use=" simpapp_GWWS1_HTTPSPort" />
</Binding>
</Outbound>
...
</GWInstance>
</WSGateway>
...
</ Deployment>
| 注意 : | GWWS サーバの各発信 Web サービス バインディングを特定の WS-Addressing エンドポイント アドレスに関連付けることができます。これらのエンドポイントは、同じホスト名とポート番号で設定できますが、エンドポイント アドレスのコンテキスト パースの部分を異なっている必要があります。 |
| 注意 : | 外部 Web サービス バインディングは、WS-Addressing メッセージをサポートされない場合、実行時に Addressing エンドポイントのコンフィグレーションに障害が発生する可能性があります。 |
SALTDEPLOY ファイルで WS-Addressing のエンドポイントを作成した場合でも作成していない場合でも、WSDF で特定の発信サービスの Addressing 機能を明示的に無効にできます。特定の発信サービスの Addressing 機能を無効にするには、WSDF ファイル内の対応する <Service> 定義で「disableWSAddressing」プロパティを "true" に設定します。このプロパティは、着信サービスには影響しません。
コード リスト 2-12 では、Addressing 機能を有効にする WSDF ファイルのセグメントを表します。
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper">
<Property name="disableWSAddressing" value=”true” />
</Service>
<Service name="tolower" />
</Servicegroup>
....
</WSBinding>
</Definition>
現在、Oracle SALT は着信サービスのみの信頼性のあるメッセージングをサポートしています。信頼性のあるメッセージングの機能を有効にするには、Web サービスの信頼性のあるメッセージングのポリシー ファイルを作成し、このポリシー ファイルを WSDF に含める必要があります。ポリシーファイルは WS-ReliableMessaging ポリシー アサーション仕様 (2005 年 2 月) に準拠している必要があります。
| 注意 : | 信頼性のあるメッセージングポリシーの定義を含む WSDF は、着信方向のみに GWWS サーバで使用する必要があります。 |
信頼性のあるメッセージングのポリシー ファイルは、WS-ReliableMessaging のアサーションを含む一般的な WS-Policy ファイルです。WS-ReliableMessaging のアサーションは、サポート対象の WS-ReliableMessage 仕様のバージョン、ソース エンドポイントの再伝送までの時間間隔、送信元エンドポイントの承認までの時間間隔などの機能を説明する XML セグメントです。
WS-ReliableMessaging ポリシー ファイルの形式の詳細については、『リファレンス ガイド』の「Oracle SALT WS-ReliableMessaging ポリシー アサーションのリファレンス」を参照してください。
コード リスト 2-13 では、信頼性のあるメッセージングのポリシー ファイルの例を表します。
<?xml version="1.0"?>
<wsp:Policy wsp:Name="ReliableSomeServicePolicy"
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
xmlns:wsp=”http://schemas.xmlsoap.org/ws/2004/09/policy”
xmlns:beapolicy="http://www.bea.com/wsrm/policy">
<wsrm:RMAssertion>
<wsrm:InactivityTimeout Milliseconds="600000" />
<wsrm:AcknowledgementInterval Milliseconds="2000" />
<wsrm:BaseRetransmissionInterval Milliseconds="500"/>
<wsrm:ExponentialBackoff />
<beapolicy:Expires Expires="P1D" />
<beapolicy:QOS QOS=”ExactlyOnce InOrder" />
</wsrm:RMAssertion>
</wsp:Policy>
ネイティブ WSDF ファイルでは、<Servicegroup> レベルにおいて WS-ReliableMessaging ポリシー ファイルを参照する必要があります。WSDF ファイルの以下に示すセグメントは、WS-ReliableMessaging ポリシー ファイルの参照方法について説明します。
<Definition ...><Policy location=”RMPolicy.xml” />
<WSBinding ...>
<Servicegroup ...><Service .../>
<Service .../>
...
</Servicegroup ...>
</WSBinding>
</Definition>
| 注意 : | Oracle SALT において、信頼性のあるメッセージングではプロセス障害/システム障害の状況がサポートされていません。つまり、SALT ではメッセージが永続ストレージ領域には保存されません。Oracle SALT は SOAP クライアントと「直接モード」でやりとりします。通常、システム障害から回復するには、クライアントとサーバの間でビジネス ロジックの同期化を行う必要があります。 |
Oracle SALT では、転送レベルと SOAP メッセージレベルの両方のレベルでセキュリティがサポートされます。以下のトピックでは、各レベルにおいてセキュリティ機能を設定する方法について説明します。
Oracle SALT では、SSL リンクレベル セキュリティを使用してポイントツーポイント セキュリティが提供され、着信サービスおよび発信サービスの両方のサービス認証に対して HTTP 基本認証メカニズムがサポートされます。
SSL を使用して着信エンドポイントでリンクレベル セキュリティを設定するには、エンドポイントアドレスの前にプレフィックスとして「https://」を指定できます。この着信エンドポイントを使用する GWWS サーバは、SSL リスン ポートを作成して Web サービス クライアントを SSL 接続で保護します。SSL 機能では、証明書の設定を指定する必要があります。証明書の設定の詳細については、「証明書のコンフィグレーション」を参照してください。
発信エンドポイントへの SSL 接続は、GWWS サーバによって自動的に作成され、プレフィックス「https://」の URL でパブリッシュされます。
Oracle SALT では、Web サービスのクライアントを認証するかどうかは Tuxedo セキュリティ フレームワークによって決まります。Oracle SALT 側に着信 HTTP 基本認証を有効にする特定のコンフィグレーションはありません。Tuxedo システムには、ユーザの信任状が必要の場合、Web サービス クライアント プログラムの代わりに HTTP 基本認証を使用してユーザの信任状を実現できます。
GWWS ゲートウェイでは、以下に示す 2 つの認証パターンに関する Tuxedo ドメイン セキュリティ コンフィグレーションがサポートされています。
GWWS サーバは、クライアント SOAP リクエストの HTTP ヘッダから以下の文字列を取得し、Tuxedo での認証用に渡します。
Authorization: Basic <ユーザ名:パスワードの base64Binary>
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
この例では、クライアントから渡された Tuxedo ユーザ名は「Aladdin」、パスワードは「open sesame」であり、このペア値が Tuxedo の認証に使われます。
Tuxedo で APP_PW が使われている場合、GWWS サーバは HTTP ユーザ名の値を無視し、パスワード文字列だけを Tuxedo アプリケーション パスワードとして認証をチェックします。
Tuxedo で USER_AUTH が使われている場合は、HTTP ユーザ名とパスワードの両方を使用します。この場合、GWWS サーバでは Tuxedo アプリケーション パスワードをチェックしません。
| 注意 : | Web サービスのクライアントに対しては、ACL および MANDATORY_ACL がサポートされていません。そのため、ACL に関するすべてのコンフィグレーションは Tuxedo システムによって無視されます。Oracle SALT には、グループ情報を Web サービスのクライアントに提供する機能はありません。 |
Oracle SALT は、発信 HTTP 基本認証のユーザ資格を作成する認証プラグインの開発を支援します。発信 HTTP 基本認証はエンドポイント レベルにおいて設定します。発信エンドポイントにおいて、HTTP メッセージでユーザ プロファイルが必要の場合、WSDF ファイル内で HTTP エンドポイント用 HTTP レルムを指定する必要があります。GWWS サーバは、ユーザ名とパスワードを作成するために認証プラグイン ライブラリを呼出し、HTTP 基本認証メカニズムを使用してリクエスト メッセージに送信します。
コード リスト 2-15 では、発信エンドポイントにおいて HTTP 基本認証の有効化について説明します。
<Definition ...>
<WSBinding id="simpapp_binding">
<SOAP>
<AccessingPoints>
<Endpoint id=”...” address=”...”>
<Realm>SIMP_REALM</Realm>
</Endpoint>
</AccessingPoints>
</SOAP>
<Servicegroup id="simpapp">
....
</Servicegroup>
....
</WSBinding>
......
</Definition>
サービスの要求は「Realm」の設定で指定された発信エンドポイントに送信すると、Tuxedo client uid および gid が GWWS サーバから認証のプラグイン機能に渡されます。このプラグイン機能は Tuxedo クライアントの情報によって HTTP 基本認証の username/password を確定します。HTTP 基本認証の username/password をマッピングするために Tuxedo クライアント uid / gid を取得するには、Tuxedo セキュリティ レベルも UBBCONFIG ファイルに設定する必要があります。詳細については、「発信 HTTP 基本認証の Tuxedo セキュリティ レベルのコンフィグレーション」を参照してください。
発信認証プラグインを開発する方法の詳細については、『Web サービスのプログラミング』の「発信認証プラグインのプログラミング」を参照してください。
Oracle SALT では、メッセージレベル セキュリティに対して Web サービス セキュリティ 1.0 および 1.1 をサポートします。Oracle SALT では、以下を保証するためにメッセージレベル セキュリティを使用できます。
Web サービス セキュリティの Oracle SALT の実装 : SOAP メッセージ セキュリティの仕様は以下のユース ケースをサポートします。
Oracle SALT では、メッセージレベル セキュリティの使用例のために使用される複数の WS-Security ポリシー 1.0 および 1.2 のファイルが含まれています。
Oracle SALT が正常にインストールされると、WS-Policy ファイルが $TUXDIR/udataobj/salt/policy に配置されます。
以下の表では、Oracle SALT に付属するデフォルト WS-Security ポリシーファイルを示します。
上記の WS-Security Policy 1.2 UserToken ファイル以外のすべてのポリシー ファイルをネイティブ WSDF ファイルで <Servicegroup> または <Service> レベルで参照できます。WSSP 1.2 UserToken ファイルは <Servicegroup> レベルのみで参照できます。サンプル「wsseapp」では、WSSP 1.2 UserToken ファイルを <Service> レベルで使用するようにクリップする方法について説明します。
コード リスト 2-16 では、ポリシーを作成するときの組み合わせを示します (サービス「TOUPPER」では、クライアントがプレーン テキスト形式の UsernameToken とリクエスト形式の X509v3Token を送信する必要があり、X509 トークンで署名付きメッセージの SOAP:Body 部分も必要です)。
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Policy location="salt:wssp1.2-Wss1.1-X509V3-auth.xml"/>
<Service name="TOUPPER" >
<Policy location="D:/wsseapp/wssp1.2-UsernameToken-Plain.xml"/>
<Policy location="salt:wssp1.2-signbody.xml" use="input"/>
</Service>
</Servicegroup>
....
</WSBinding>
......
</Definition>
ポリシーは <Policy> 要素の「location」属性で指定されます。プレフィックスの「salt:」は、SALT に付属のデフォルト ポリシー ファイルがすでに使用されていることを示します。ユーザ定義ポリシー ファイルは、ファイル パスを直接指定して使用できます。
| 注意 : | ポリシーは <Servicegroup> レベルで参照すると、このサービス グループのすべてのサービスに適用されます。 |
「signbody」ポリシーは、「use」属性を「input」に設定して使用する必要があります。これにより、ポリシーが入力メッセージに対してのみ適用されます。出力メッセージの SOAP:Body を署名していないので、これは必要です。
SALT コンフィグレーション ファイルのコンパイルとは、XML バージョン SALTDEPLOY ファイルから (SALTCONFIG) ファイルのバイナリ バージョンを生成することです。コンフィグレーション ファイルをコンパイルするには、wsloadcf コマンドを実行します。wsloadcf はデプロイメント ファイルを解析してバイナリ ファイルをロードします。
wsloadcf はデプロイメント ファイル、インポートされた WSDF ファイルおよびデプロイメント ファイルに参照した WS-Policy ファイルを読み込み、各ファイルの XML スキーマ形式によって構文をチェックします。また、必要に応じて、SALTCONFIG というバイナリ コンフィグレーション ファイルをロードします。SALTCONFIG および (必要に応じて) SALTOFFSET 環境変数は、SALTCONFIG ファイルを指し、(必要に応じて) 情報を格納する場所にオフセットします。
SALT コンフィグレーション ファイルは、あらかじめ定義した XML スキーマ ファイルに従って wsloadcf により検証されます。Oracle SALT で必要な XML スキーマ ファイルは $TUXDIR/udataobj/salt. ディレクトリに配置しています。
オプション「-n」を指定すると、wsloadcf はバイナリ バージョンの SALTCONFIG を生成せずに、検証の目的にのみ実行できます。
wsloadcf の詳細については、『リファレンス ガイド』の「wsloadcf」を参照してください。
SALT コンフィグレーションを設定しコンパイルした後、Tuxedo UBBCONFIG ファイルは Tuxedo アプリケーションに SALT コンポーネントが適用されるように更新する必要があります。表 2-9 では、Oracle SALT の UBBCONFIG ファイルのコンフィグレーション タスクを示します。
Oracle SALT は、UBBCONFIG ファイルに少なくとも 1 つの TMMETADATA サーバを指定する必要があります。Tuxedo サービス定義をアクセスするスループットを増加するために、複数の TMMETADATA サーバの指定も可能です。
コード リスト 2-17 では、Tuxedo アプリケーションに TMMETADATA サーバを定義する方法を表す UBBCONFIG ファイルのセグメントの一覧を示します。
......
*SERVERS
TMMETADATA SRVGRP=GROUP1 SRVID=1
CLOPT="-A -- – f domain_repository_file -r"
TMMETADATA SRVGRP=GROUP1 SRVID=2
CLOPT="-A -- – f domain_repository_file"
......
| 注意 : | 全体の Tuxedo ドメインに対してサービス メタデータ リポジトリ ファイルを 1 つのみ維持することをお勧めします。これを確認するには、Tuxedo ドメインに実行されている複数の TMMETADATA サーバは同じリポジトリ ファイルを指す必要があります。 |
詳細については、Tuxedo 9.1 ドキュメントの「Tuxedo サービス メタデータ リポジトリの管理」を参照してください。
SALTDEPLOY ファイルに定義された GWWS インスタンスを起動するには、UBBCONFIG ファイルの *SERVERS セクションで GWWS サーバを指定する必要があります。1 つまたは複数の GWWS サーバを並行して UBBCONFIG ファイルに定義できます。各 GWWS サーバは Tuxedo ドメイン内にオプション「-i」を使用してユニークなインスタンス ID で指定する必要があります。インスタンス ID は、XML バージョンの SALTDEPLOY ファイルおよび生成されたバイナリ バージョンの SALTCONFIG ファイルで指定する必要があります。
コード リスト 2-18 では、Tuxedo アプリケーションに GWWS を定義する方法を表す UBBCONFIG ファイルのセグメントの一覧を示します。
......
*SERVERS
GWWS SRVGRP=GROUP1 SRVID=10
CLOPT="-A -- – i GW1"
GWWS SRVGRP=GROUP1 SRVID=11
CLOPT="-A -- – i GW2"
GWWS SRVGRP=GROUP2 SRVID=20
CLOPT="-A -- -c saltconf_2.xml – i GW3"
......
詳細については、『リファレンス ガイド』の「GWWS」を参照してください。
| 注意 : | UBBCONFIG ファイルでは、GWWS サーバが起動する前に TMMETADATA システム サーバが確実に起動するよう設定してください。GWWS サーバは TMMETADATA によって提供されるサービスを呼び出すため、TMMETADATA よりも後に起動する必要があります。 |
| 注意 : | GWWS サーバから呼び出される前に TMMETADATA が確実に起動するようにするため、UBBCONFIG ファイルの *SERVERS 定義内で、TMMETADATA を先に、GWWS を後に記述するか、SEQUENCE パラメータを使用します。 |
| 注意 : | SALT コンフィグレーション情報は、生成されたバイナリ バージョンの SALTCONFIG ファイルに対し、wsloadcf であらかじめコンパイルされます。GWWS サーバは起動時に SALTCONFIG ファイルを読込みます。環境変数 SALTCONFIG は、GWWS サーバを起動する前にバイナリ バージョンの SALTCONFIG ファイルに正しく設定する必要があります。 |
| 注意 : | オプション「-c」は Oracle SALT の現在のバージョンでは非推奨になっています。SALT 1.1 リリースにおいて、GWWS サーバに対して SALT 1.1 ファイルを指定ためにオプション「-c」を使用します。SALT 2.0 では、GWWS サーバは、起動時に SALTCONFIG ファイルを読込みます。GWWS サーバは、このオプションを指定して起動すると、このオプションは非推奨になっていることを示す警告メッセージが表示されます。指定されたファイルは任意のファイルで、GWWS サーバによって読み込まれません。 |
SALT GWWS サーバで Tuxedo ドメインをコンフィグレーションする時、SALT アプリケーションの条件によって UBBCONFIG ファイルに指定された Tuxedo システム制限事項を設計し更新する必要があります。
| ヒント : | *RESOURCES セクションに十分な MAXSERVERS 番号を定義します。 |
Oracle SALT では、Tuxedo ドメインの TMMETADATA および GWWS 内で以下のシステム サーバを起動する必要があります。TMMETADATA および GWWS サーバ数は、MAXSERVERS 値に指定する必要があります。
| ヒント : | *RESOURCES セクションに十分な MAXSERVICES 番号を定義します。 |
GWWS サーバは、発信方向で作業する場合、外部 wsdl:operation が Tuxedo サービスでマップされ、GWWS サーバを介して公開されます。すべての GWWS サーバによって公開されたサービス数は MAXSERVICES 値に指定する必要があります。
| ヒント : | *RESOURCES セクションに十分な MAXACCESSERS 番号を定義します。 |
MAXACCESSERS 値は、このアプリケーションの特定のマシン上の Tuxedo 掲示板と同時に接続するデフォルトのクライアントおよびサーバの最大数を指定するために使用します。TMMETADATA および GWWS サーバ数、最大同時 Web サービス クライアントのリクエスト数は MAXACCESSERS 値に指定する必要があります。
| ヒント : | *MACHINES セクションに十分な MAXWSCLIENTS 番号を定義します。 |
GWWS サーバは着信方向で作業する場合、Web サービスの各クライアントは Tuxedo システムのワークステーション クライアントと見なされます。したがって、GWWS サーバをデプロイするノードの UBBCONFIG では、MAXWSCLIENTS に適切な値を設定する必要があります。番号を共有します。
Oracle SALT の証明書を設定する時にセキュリティのパスワードを設定する必要があります。GWWS サーバは、SSL リンクレベル暗号化や Web サービス セキュリティ X.509 トークンおよび署名機能を有効化にする時、証明書を設定する必要があります。証明書の秘密キー ファイルを作成しパスワードで暗号化する必要があります。
秘密キー ファイルを読込むおよびパスワードを使用して証明書を暗号化するには、GWWS サーバでは、証明書に関する機能を指定する必要があります。各 GWWS サーバに対してパスワードを設定するには、*SERVERS セクションにおける各 GWWS サーバエントリの下にキーワード SEC_PRINCIPAL_NAME および SEC_PRINCIPAL_PASSVAR を指定する必要があります。tmloadcf を使用して UBBCONFIG ファイルをコンパイルする時に、管理者がパスワードを入力する必要があります。このパスワードは秘密キー ファイルを正しく暗号化するために使用できます。
| 注意 : | SALT デプロイメント ファイルに秘密キー ファイルを 1 つのみ指定できます。SALT デプロイメント ファイルに定義されているすべての GWWS サーバについては、秘密キー ファイルの暗号のため同じパスワードを提供する必要があります。 |
コード リスト 2-19 では、GWWS サーバに対してセキュリティのパスワードを指定する方法を示す UBBCONFIG ファイルのセグメントを示します。
......
*SERVERS
GWWS SRVGRP=GROUP1 SRVID=10
SEC_PRINCIPAL_NAME="gwws_certkey"
SEC_PRINCIPAL_VAR="gwws_certkey"
CLOPT="-A -- – i GW1"
GWWS SRVGRP=GROUP1 SRVID=11
SEC_PRINCIPAL_NAME="gwws_certkey"
SEC_PRINCIPAL_PASSVAR="gwws_certkey"
CLOPT="-A -- – i GW2"
......
詳細については、Tuxedo 9.1 ドキュメントの「UBBCONFIG(5)」を参照してください。
Oracle SALT の GWWS は Web サービス クライアントの有効性をチェックするために Tuxedo 認証フレームワークに依存します。Tuxedo の従来のアプリケーションが既に適用されている場合、Web サービス クライアントは次のいずれかの方法でユーザ資格を送信する必要があります。
逆に、Oracle SALT に対して Web サービス クライアントを認証したい場合、Tuxedo ドメインで Tuxedo 認証を設定する必要があります。
Tuxedo 認証の詳細については、Oracle Tuxedo 9.1 ドキュメントの「認証の管理」を参照してください。
発信 HTTP 基本認証 username /password をマッピングするために Tuxedo クライアント uid / gid を取得するには、UBBCONFIG ファイルに Tuxedo セキュリティ レベルを USER_AUTH、ACL または MANDATORY_ACL として設定する必要があります。
コード リスト 2-20 では、UBBCONFIG ファイルにはセキュリティ レベル ACL を指定する方法を表す UBBCONFIG ファイルのセグメントを示しています。
*RESOURCES
IPCKEY ...
......
SECURITY ACL
......
MP モードの Tuxedo ドメイン内の複数のマシンで実行している GWWS サーバを設定するには、各 Tuxedo マシンを異なる SALTDEPLOY ファイルおよび一連の別々のコンポーネントで指定する必要があります。
以下のグローバル リソースを別々のマシンに渡って広める必要があります。
2 つのマシンでは、同じ WSDF ファイルを関連付けられて、同一の機能がある、異なるマシンで実行している 2 つの GWWS サーバを指定できます。ただし、以下のアーチファクトの伝播を手動で行う必要があります。
この節では、SALT 1.1 から SALT 2.0 リリースに更新するカスタマに対して次の 2 つの移動方法について説明します。
SALT 1.1 から SALT 2.0 リリースに更新した後、元の SALT 1.1 コンフィグレーション ファイルを使用して既存の SALT アプリケーションを実行することができます。SALT 2.0 では、これがサポートされています。
SALT コンフィグレーション コンパイラ ユーティリティ wsloadcf は、1 つの SALT 1.1 形式のコンフィグレーション ファイルからバイナリ バージョンの SALTCONFIG をロードすることをサポートします。
SALT 1.1 コンフィグレーション ファイルを使用して SALT 2.0 GWWS サーバを実行するには、次の手順に従います。
| 注意 : | Tuxedo ドメインでは、1 つまたは複数の SALT 1.1 コンフィグレーション ファイルを指定されている場合、複数のバイナリ バージョン SALTCONFIG ファイルを生成するにはステップ 1 から 3 までの処理に従い、対応する GWWS サーバを起動する必要があります。 |
wsloadcf は SALT 1.1 コンフィグレーション ファイルからバイナリ バージョンの SALTCONFIG をロードする時、この SALT 1.1 コンフィグレーション ファイルを 1 つの WSDF ファイルと 1 つの SALTDEPLOY ファイルに変換されます。
SALT 1.1 コンフィグレーションから変換されたファイルを取得した後、SALT 2.0 スタイルのコンフィグレーションで起動することをお勧めします。
| 注意 : | 1 つの SALT 2.0 デプロイメントに複数の SALT 1.1 コンフィグレーション ファイルを組み込むには、他の WSDF ファイルをインポートするために SATLDEPLOY ファイルを手作業で編集する必要があります。 |
以下のサンプルでは、指定された SALT 1.1 コンフィグレーション ファイルから変換された SALTDEPLOY ファイルおよび WSDF ファイルを示します。
<Configuration xmlns=" http://www.bea.com/Tuxedo/Salt/200606">
<Servicelist id="simpapp">
<Service name="toupper" />
<Service name="tolower" />
</Servicelist>
<Policy />
<System />
<WSGateway>
<GWInstance id="GWWS1">
<HTTP address="//127.0.0.1:7805" />
<HTTPS address="127.0.0.1:7806" />
<Property name="timeout" value="300" />
</GWInstance>
</WSGateway>
</Configuration>
変換した SALT 2.0 WSDF ファイルおよびデプロイメント ファイルは以下に示します。
<Definition name="simpapp" wsdlNamespace="urn:simpapp.wsdl"
xmlns=" http://www.bea.com/Tuxedo/WSDF/2007">
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper" />
<Service name="tolower" />
</Servicegroup>
<SOAP>
<AccessingPoints>
<Endpoint id="simpapp_GWWS1_HTTPPort"
address=http://127.0.0.1:7805/simpapp />
<Endpoint id=" simpapp_GWWS1_HTTPSPort"
address=https://127.0.0.1:7806/simpapp />
</AccessingPoints>
</SOAP>
</WSBinding>
</Definition>
<Deployment xmlns=" http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<WSDF>
<Import location="/home/myapp/simpapp.wsdf" />
</ WSDF>
<WSGateway>
<GWInstance id="GWWS1">
<Inbound>
<Binding ref="simpapp:simpapp_binding">
<Endpoint use=" simpapp_GWWS1_HTTPPort" />
<Endpoint use=" simpapp_GWWS1_HTTPSPort" />
</Binding>
</Inbound>
<Properties>
<Property name="timeout" value="300" />
</Properties>
</GWInstance>
</WSGateway>
</ Deployment>
Tuxedo SCA コンポーネントのコンフィグレーションは以下のタスクで構成されます。
SCA ATMI クライアントは、SCA パラダイムで記述し、buildscaclient ユーティリティで構築するネイティブ Tuxedo クライアントです。クライアントの実行ファイルは、root.composite ファイルが格納されるディレクトリのサブディレクトリに格納する必要があります。
| 注意 : | APPDIR 環境変数に、root.composite ファイルのディレクトリを指定する必要があります。 |
コード リスト 2-24 に、クライアント アプリケーションのルート コンポジット ファイル $APPDIR/root.composite を示します。
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="testApp">
<component name="testStringClientComp">
<implementation.composite name="ECHO"/>
</component>
</composite>
$APPDIR/ECHO ディレクトリには、ECHO アプリケーションが格納されます。ディレクトリ名「ECHO」は、<implementation.composite name="ECHO"/> で指定する名前と一致していなければなりません。コード リスト 2-25 に、クライアント アプリケーションのコンポジット ファイルを示します。
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="ECHO">
<reference name="ECHO">
<interface.cpp header="ECHO.h"/>
<binding.atmi requires="legacy">
<tuxconfig>/tux/application/ECHOServer/tuxconfig</tuxconfig>
<inputBufferType target="TestString">STRING</inputBufferType>
<outputBufferType target="TestString">STRING</outputBufferType>
<errorBufferType target="TestString">STRING</errorBufferType>
<binding.atmi>
</reference>
</composite>
このディレクトリには、このクライアント アプリケーションのクライアント ダイナミック リンク ライブラリも格納されます。たとえば、コード リスト 2-25 の場合であれば、$APPDIR/ECHO/ECHO.so 共有オブジェクトが ECHO ディレクトリに格納されます。ターゲット「TestStr」は、バッファ タイプのグループ化に使用します。
このディレクトリには、クライアントの実行ファイルも格納されます。クライアント アプリケーションの命名規約はありません。このクライアント ECHO アプリケーションの場合は、ECHO アプリケーション ディレクトリに「doEchoClient」が格納される可能性が非常に高いといえます。たとえば、$APPDIR/ECHO/doEchoClient となります。
| 注意 : | SCA_COMPONENT を設定する必要があります。コード リスト 2-25 では SCA_COMPONENT=testStringClientComp となります。 |
JATMI クライアント アプリケーションのコンフィグレーション コンポジット ファイルは、Java .jar ファイルの一部です。JATMI クライアントのコンポジット ファイルはパッケージの一部ではなく、.jar ファイルのベースに配置されます。クライアント アプリケーションを呼び出すと、SCA Java ランタイムによってコンポジット ファイルがロードされます。特別なセットアップは必要ありません。
| 注意 : | クライアント アプリケーションの .jar ファイルは、必ず CLASSPATH に含める必要があります。また、以下の .jar ファイルも CLASSPATH に含める必要があります。 |
コード リスト 2-26 に、SCA JATMI クライアントのコンポジット ファイルのサンプルを示します。
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:f="binding-atmi.xsd"
name="EchoComposite">
<reference name="ECHO" promote="EchoComponent/ECHO">
<interface.java class="com.abc.sca.java.Echo" />
<f:binding.atmi requires="legacy">
<f:serviceType>RequestResponse</f:serviceType>
<f:inputBufferType>FML</f:inputBufferType>
<f:outputBufferType>FML</f:outputBufferType>
<f:fieldTables>com.abc.sca.java.fml.FMLTABLE
</f:fieldTables>
<f:workStationParameters>
<f:networkAddress>//STRIATUM:15011
</f:networkAddress>
</f:workStationParameters>
</f:binding.atmi>
</reference>
<component name="EchoComponent">
<implementation.java
class="com.abc.sca.java.EchoComponentImpl />
</component>
</composite>
SCA ワークステーション クライアントのコンフィグレーションは、SCA ネイティブ クライアントのコンフィグレーションに似ています。相違点の 1 つは、SCA ワークステーション クライアントの場合、コンポジット内で <workStationParameters> 要素とそのサブ要素を使用する必要があることです。SCA ランタイムは、クライアントが SCA ネイティブ クライアントと SCA ワークステーション クライアントのどちらとして構築されたかを自動的に検出し、それに応じて適切な参照バインディング ライブラリをロードします。
SCA Tuxedo ワークステーション クライアントのディレクトリ階層も、SCA ネイティブ クライアントに似ています。どちらの場合も、環境変数 $APPDIR を使用してクライアント アプリケーションの場所を指定します。
コード リスト 2-27 に、SCA Tuxedo ワークステーション クライアントのサンプル コンフィグレーションを示します。
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="testApp">
<component name="testStringClientComp">
<implementation.composite name="ECHO"/>
</component>
</composite>
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="ECHO">
<reference name="ECHO">
<interface.cpp header="ECHO.h"/>
<binding.atmi requires="legacy">
<inputBufferType target="TestString">STRING</inputBufferType>
<outputBufferType target="TestString">STRING</outputBufferType>
<errorBufferType target="TestString">STRING</errorBufferType>
<workStationParameters>
<networkAddress>//STRIATUM:4890</networkAddress>
<encryptBits>128/128</encryptBits>
</workStationParameters>
<remoteAccess>WorkStation</remoteAccess>
</binding.atmi>
<reference>
</composite>
SCA Web サービス クライアントは、基本的には SCA ネイティブ クライアントと同じですが、<binding.atmi> 要素ではなく <binding.ws> 要素を使用する点が異なります。SCA ランタイムは、クライアントが使用しているバインディングを自動的に検出し、それに応じて適切な参照バインディングをロードします。
SCA Web サービス クライアントのディレクトリ階層も、SCA ネイティブ クライアントに似ています。どちらの場合も、環境変数 $APPDIR を使用してクライアント アプリケーションの場所を指定します。
コード リスト 2-29 に、SCA Web サービス クライアントのサンプル コンフィグレーションを示します。
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="testApp">
<component name="calcClient">
<implementation.composite name="calcClient"/>
</component>
</composite>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"name="calcClient">
<reference name="Calculator">
<interface.cpp header="CalcService.h"/>
<binding.ws
endpoint="http://calc.sample#wsdl.endpoint
(Calculator/CalculatorSOAP11port)"/>
</reference>
</composite>
<interface.cpp> は、適切なプロキシ スタブを構築するために必要な要素です。また、<binding.ws> に指定したエンドポイントを配置するクライアント ディレクトリに WSDL ファイルを格納する必要があります。さらには、次の手順に従って Tuxedo Web サービス ゲートウェイ (GWWS) をコンフィグレーションする必要もあります。
wsdlcvt を実行します。これにより、WSDF ファイル、Tuxedo メタデータ リポジトリのインタフェース定義ファイル、fml32 フィールド テーブル、および XML スキーマが生成されます。$ tmloadrepos -I calc.mif metadata.repos -y)。詳細については、tmloadrepos に関するドキュメントを参照してください。gwws.dep というファイル) に WSDF への参照を追加します。コード リスト 2-31 では、追加する要素が強調表示されています。$ wsloadcf -y gwws.dep)。<?xml version="1.0" encoding="UTF-8"?>
<saltdep:Deployment xmlns:saltdep="http://www.bea.com/Tuxedo/SALTDEPLOY/2007" xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<saltdep:WSDF>
<saltdep:Import location="calc.wsdf"/>
</saltdep:WSDF>
<saltdep:WSGateway>
<saltdep:GWInstance id="GWWS1">
<saltdep:Outbound>
<saltdep:Binding ref="calc:CalculatorSOAP11Binding">
<saltdep:Endpoint use="CalculatorSOAP11port"/>
</saltdep:Binding>
</saltdep:Outbound>
</saltdep:GWInstance>
</saltdep:WSGateway>
<saltdep:System/>
</saltdep:Deployment>
SCA ATMI サーバの SCA ROOT は $APPDIR と同じです。SCA アプリケーションを記述するため、少なくとも 1 つのコンポジット ファイルが必要です。SCA ランタイムは、このコンポジット ファイルを検索し、その場所から Tuxedo 環境でホストする SCA サーバ アプリケーションのすべての composite および componentType ファイルをロードします。
コード リスト 2-32 に、ルート コンポジット ファイルのサンプルを示します。この root.composite には、Tuxedo アプリケーション ドメインでホストする 2 つの SCA アプリケーションが含まれています。2 つのアプリケーションの名前は Purchase と Finance です。これら 2 つの SCA アプリケーションのサブディレクトリは少なくとも 2 つあります。1 つは Purchase.component、もう 1 つは Finance.component です。
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="root">
<component name="Purchase.component">
<implementation.composite name="Purchase" />
</component>
<component name="Finance.component">
<implementation.composite name="Finance" />
</component>
</composite>
コード リスト 2-33 に、Purchase.component ディレクトリに格納される Purchase アプリケーションのコンポジット ファイル Purchase.composite を示します。同様に、Finance.component ディレクトリには、Finance アプリケーションのコンポジット ファイル Finance.composite が格納されます。
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="Purchase">
<service name="purchase">
<interface.cpp header="Purchase.h" />
<binding.atmi requires="legacy">
<map target="Order">ORDER</map>
<map target="TrackOrder">TRACKORDER</map>
</binding.atmi>
<reference>PurchaseServiceComponent</reference>
</service>
<component name="PurchaseServiceComponent">
<implementation.cpp library="Purchase" header="PurchaseImpl.h" />
</component>
</composite>
コード リスト 2-34 に、Purchase.composite の $APPDIR/Purchase.component ディレクトリに格納される PurchaseImpl.componentType ファイルを示します。ここでは、アプリケーション実装として CPP を使用しています。このコンフィグレーション ファイルを使用する SCA サーバを buildscaserver ユーティリティを使用して構築すると、実行時に 2 つの SCA サービス (ORDER および TRACKORDER) が自動的に公開されます。サービスの実際の CPP 実装は、Order および TrackOrder という名前になります。
<?xml version="1.0" encoding="UTF-8"?>
<componentType xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<service name="purchase">
<interface.cpp header="Purchase.h"/>
</service>
</componentType>
Tuxedo 内でホストし buildscaserver で構築するこれら 2 つの SCA アプリケーションが、PurchaseSvr および FinanceSvr という名前だとすると、UBBCONFIG ファイルの *SERVERS セクションに以下の行を追加する必要があります。
PurchaseSvr SRVGRP=PURCHASEGRP SRVID=500
FinanceSvr SRVGRP=FINANCEGRP SRVID=600
*SERVICES セクションにサービスを追加する必要はありません。Tuxedo でホストする SCA サービスは動的に公開されます。
サーバ サイドでコンポーネントの Web サービス バインディングをコンフィグレーションする方法は、SCA コンポーネントをホストするための ATMI バインディングをコンフィグレーションする方法に似ています。
コード リスト 2-35 に、root.composite という名前のルート コンポジット ファイルを示します。このファイルには、Tuxedo アプリケーション ドメインでホストする 1 つの SCA コンポーネントが含まれています。2 つのアプリケーションの名前は Purchase と Finance です。これら 2 つの SCA アプリケーションのサブディレクトリは少なくとも 2 つあります。1 つは Purchase.component、もう 1 つは Finance.component です。
コード リスト 2-36 に実際のコンポーネント サブディレクトリ、コード リスト 2-37 に componentType ファイルを示します。
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="root">
<component name="account">
<implementation.composite name="account" />
</component>
</composite>
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="account">
<service name="AccountService">
<interface.wsdl interface="http://www.bigbank.com/AccountService#wsdl.interface(AccountService)"/>
<binding.ws/>
<reference>AccountServiceComponent</reference>
</service>
<component name="AccountServiceComponent">
<implementation.cpp library="Account" header="AccountServiceImpl.h"/>
</component>
</composite>
<?xml version="1.0" encoding="UTF-8"?>
<componentType xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<service name="AccountService">
<interface.cpp header="AccountService.h"/>
</service>
</componentType>
上に示した SCA コンポーネントは、-w オプション (Web サービス) を指定した buildscaserver で構築された Tuxedo サーバ (WSServer) によってホストされます。
ここで、Tuxedo UBBCONFIG ファイルの *SERVERS セクションに、WSServer SRVGRP=ACCTGRP SRVID=500 という行を追加する必要があります。
*SERVICES セクションにサービスを追加する必要はありません。Tuxedo でホストする SCA サービスは動的に公開されます。
さらに、Tuxedo Web サービス ゲートウェイ (GWWS) をコンフィグレーションする必要があります。次の手順に従ってください。
wsdlcvt を実行します。これにより、WSDF ファイル、Tuxedo メタデータ リポジトリのインタフェース定義ファイル、fml32 フィールド テーブル、および XML スキーマが生成されます。$ tmloadrepos -I AccountService.mif metadata.repos -y)。tmloadrepos に関するドキュメントを参照してください。gwws.dep というファイル) に WSDF への参照を追加します。コード リスト 2-38 では、追加する要素が強調表示されています。$ wsloadcf -y gwws.dep)。<?xml version="1.0" encoding="UTF-8"?>
<saltdep:Deployment xmlns:saltdep="http://www.bea.com/Tuxedo/SALTDEPLOY/2007" xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<saltdep:WSDF>
<saltdep:Import location="AccountService.wsdf"/></saltdep:WSDF>
<saltdep:WSGateway>
<saltdep:GWInstance id="GWWS1">
<saltdep:Inbound><saltdep:Binding ref="AccountService:AccountServiceSOAP">
<saltdep:Endpoint use="AccountServiceSOAP"/>
</saltdep:Binding>
</saltdep:Inbound>
</saltdep:GWInstance>
</saltdep:WSGateway>
<saltdep:System/>
</saltdep:Deployment>
Tuxedo SCA コンポーネントでは、以下の 2 種類のセキュリティがサポートされます。
Tuxedo アプリケーション ドメイン セキュリティを設定するには、Tuxedo アプリケーション ドメインの TUXCONFIG ファイルの *RESOURCES セクションに SECURITY キーワードを追加します。アプリケーション セキュリティのレベルは、NONE、APP_PW、USER_PW、ACL、および MANDATORY_ACL の 5 つです。NONE 以外のすべてのセキュリティ レベルでは、Tuxedo アプリケーションへのアクセスを取得するため、最低でもユーザからのアプリケーション パスワードが必要になります。USER_PW レベル以上では、ユーザを認証してユーザ資格を確立するため、追加のユーザ パスワードが必要になります。つまり、2 つのパスワードをコンフィグレーションしなければならない場合があるということです。
SCA クライアントが Tuxedo アプリケーション サーバへのアクセスを取得するには、常にこのパスワード情報が必要になります。SCA クライアントがパスワード情報を取得する方法には以下の 2 つがあります。
SALT 管理者がパスワードの取得をコンフィグレーションするには、以下のタスクを実行する必要があります。
コード リスト 2-39 に、SCA ATMI クライアント アプリケーションのサンプルを示します。
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="simple.app">
<component name="simpapp.TuxClient">
<implementation.composite name="simpapp.client"/>
<reference name="TOUPPER">tuxToupper</reference>
</component>
</composite>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="simpapp.client">
<reference name="TOUPPER">
<interface.cpp header="ToupperTuxService.h"/>
<binding.atmi requires="legacy">
<tuxconfig>d:\tests\tuxedo\sca\tests\TUXCONFIG</tuxconfig>
<inputBufferType target="charToup">STRING</inputBufferType>
<outputBufferType target="charToup">STRING</outputBufferType>
<authentication
<passwordIdentifier>aaa</passwordIdentifier>
</authentication>
</binding.atmi>
</reference>
</composite>
上のコンポジットでは、Tuxedo アプリケーション ドメインのパスワード識別子「aaa」を定義しています。これにより、ATMI 参照バインディングが実行時に、識別子「aaa」で password.store ファイルからパスワードを取得できるようにしています。これにユーザ認証を加えて、Tuxedo アプリケーション ドメイン セキュリティを強化することもできます。その場合はセキュリティ レベルを SECURITY=USER_PW 以上に設定し、scapasswordtool -i crusoe -a コマンドを使用します。
次に、simpapp.client.composite ファイルを編集できるツール (テキスト エディタなど) を使用して、<binding.atmi/authentication> 要素に <userPasswordIdentifier>crusoe</userPasswordIdentifier> というエントリを追加します。
これで、パスワード「crusoe」を使用するすべてのユーザが Tuxedo アプリケーションにアクセスできるようになります。
Tuxedo リンクレベル セキュリティは 2 種類あります。1 つはリンクレベルの暗号化 (LLE) を使用して簡単にコンフィグレーションできるもの、もう 1 つはより一般的なトランスポート層セキュリティ (TLS) です (セキュア ソケット レイヤ (SSL) とも呼びます)。ネイティブの ATMI 参照バインディングを使用する SCA ATMI クライアントの場合は、転送メソッドがネイティブ メッセージ キューであり Tuxedo BRIDGE であるため、SCA レベルでリンクレベル セキュリティをコンフィグレーションする必要はありません。
SCA JATMI クライアントの参照バインディングでは、リンクレベル セキュリティはサポートされません。リンクレベル セキュリティのコンフィグレーションが可能な唯一の SCA クライアントは、SCA ワークステーション ATMI クライアントです。
SCA ワークステーション ATMI クライアントのコンポジット ファイルには、<workStationParameters> 要素がコンフィグレーションされています。SCA ランタイムは、このタイプのクライアントに適した参照バインディングを自動的にロードします。
リンクレベルの暗号化をコンフィグレーションするには、コンポジット ファイルに <encryptBits> 要素を追加します。LLE では、以下の要素はコンフィグレーション「しない」ようにしてください。これは SSL 暗号化に固有の要素であるため、SSL を使用しているとみなされてしまいます。
<encryptBits> 要素には、このクライアントがネゴシエートを試みる暗号化の強度を指定します。<encryptBits> 要素の構文は、<minimum encryption strength>/<maximum encryption strength> です。56 ビット暗号化をコンフィグレーションするには、コンポジット ファイルに以下のエントリを追加する必要があります。
<networkAddress>//STRIATUM:8741</networkAddress>
<encryptBits>56/128</encryptBits>
| 注意 : | encryptBits には、クライアント接続がネゴシエートを試みる暗号化の強度を指定します。フォーマットは <minencryptbits>/<maxencprytbits> (たとえば 128/128) です。指定できる値は、0 (暗号化なし)、40、56、128、または 256 です。無効な値を指定すると、コンフィグレーション例外が発生します。 |
これにより、SCA ワークステーション参照バインディングでは、WSH とのネゴシエートにおいて強度が 56 から 128 ビットの暗号化が必要と判断されます。UBBCONFIG ファイルの *SERVERS セクションに、次の行を追加する必要もあります。
WSL SRVGRP=GROUP1 SRVID=1001 CLOPT="-A -- -n //STRIATUM:8741 -a -z 56 -Z 256
TLS/SSL によるリンクレベル セキュリティを有効にするには、<encryptBits> に加え、secPrincipalName、secPrincipalLocation、および secPrincipalPassId をコンフィグレーションする必要があります。
これら 3 つのパラメータにより、SCA ワークステーション ATMI クライアントが TLS/SSL 接続を確立する必要がある場合のパラメータを指定します。
コード リスト 2-41 に、TLS/SSL をコンフィグレーションする際に、/binding.atmi/workStationParameters 内のクライアント コンポジット ファイルに追加する必要のある行を示します。
<networkAddress>//STRITUM:8742</networkAddress>
<secPrincipalName>crusoe</secPrincipalName>
<secPrincipalLocation>/tux/udataobj/security/keys/crusoe.pem</secPrincipalLocation>
<secPrincipalPassId>crusoe</secPrincipalPassId>
Tuxedo では、クライアントがポート 8742 で接続する場合に TLS/SSL を使用することを示すため、WSL に -S 8742 を追加する必要があります。
WSL SRVGRP=GROUP1 SRVID=1001
CLOPT="-A -- -n //STRIATUM:8741 -S 8742 -z 56 -Z 128"
サービスの検索を有効にすると、サービスを提供するサーバによってサービス規約情報が収集され、この情報が TMMETADATA(5) で実装された内部サービスに送信されます。通信のオーバーヘッドを軽減するため、同じサービス規約は 1 回しか送信されないようになっています。
サービス規約は、TMMETADATA サーバによって収集されたデータに基づいて生成されます。規約情報は、メタデータ リポジトリに格納するか、テキスト ファイルに出力しておいて tmloadrepos でメタデータ リポジトリにロードできます。Oracle SALT では、tmscd コマンドを使用してサービス規約の実行時収集を管理できます。詳細については、『リファレンス ガイド』の「tmscd」を参照してください。
生成されたサービス規約情報には、サービス名、リクエスト バッファ情報、応答バッファ情報、およびエラー バッファ情報 (エラーがある場合のみ) が含まれます。TMMETADATA サーバへの送信が失敗した場合、収集されたサービス規約情報は破棄されます。バッファ情報には、バッファ タイプ、サブタイプ、および FML/FML32 のフィールド情報 (name、type、subtype) が含まれます。
検索は、FML32 バッファ内のすべての埋め込みバッファでサポートされます。FML/FML32 フィールドが出現すると、検索によってメタデータ リポジトリ内の count/requiredcount のパターンが自動的に更新されます。フィールドの出現がパターンに影響することはありませんが、「requiredcount」で最小出現回数を指定できます。規約検索の期間全体での最大出現回数は「count」で指定します。
VIEW/VIEW32/X_C_TYPE/X_COMMON の場合は、ビュー名のみが検索されます。ORACLE SALT でメタデータ リポジトリを使用している場合は、ビュー名に基づいてビューの詳しい説明を生成できます。
| 注意 : | autodiscovery (表 2-10 を参照) を指定したパターンは比較されます。 |
| 注意 : | メタデータ リポジトリ内に同じ autodiscovery パターンがすでに存在する場合は、新しいほうのパターンが無視されます。 |
サポートされるのは、アプリケーション ATMI サービス (ローカル、または /TDOMAIN ゲートウェイ経由でインポートされたもの) のみです。サービス規約検索では、以下のサービスはサポートされません。
| 注意 : | 応答のないサービスは、メタデータ リポジトリでは「oneway」サービスとしてマップされます。 |
サービスが tpreturn() の代わりに tpforward() を発行すると、そのサービスの応答バッファ情報が転送先のサービスの応答バッファ情報と同じになります。次に例を示します。
収集されたサービス規約検索情報が必要な場合は、メタデータ リポジトリに直接格納する代わりにファイルに書き出すことができます。その場合は、TMMETADATA(5) -o<filename> オプションを使用し、tmloadrepos を使って手動でファイルをメタデータ リポジトリにロードする必要があります。詳細については、『リファレンス ガイド』の「tmloadrepos」を参照してください。
ファイルをメタデータ リポジトリの代わりのストレージとして使用する場合、出力は tmloadrepos に準拠したフォーマットになります。このファイルは、サービス ヘッダ セクションと、パラメータごとのパラメータ セクションで構成されます。サービス ヘッダには、表 2-10 に示す項目が含まれます。「service」フィールドのフォーマットは <TuxedoServiceName>+'_'+<SequenceNo> です。サフィックス <SequenceNo> が付加されているのは、Tuxedo サービスのパターンが複数認識された場合に名前が衝突するのを避けるためです。
| 注意 : | <SequenceNo> は、メタデータ リポジトリに格納済みの最後の <SequenceNo> の番号から始まります。 |
サービス パラメータには、表 2-11 に示す項目が含まれます。
入力 : service=SVC, request=STRING, reply = TPSUCCESS + STRING
出力パターン : service=SVC_1,tuxservice=SVC,inbuf=STRING,outbuf=STRING
入力 : service=SVC, request=STRING, reply = TPFAIL+ STRING
出力パターン (抜粋): Service=SVC_1, tuxservice=SVC,inbuf=STRING,outbuf=NULL,errbuf=STRING
service=SVC, request=STRING, reply = TPSUCCESS + STRING
service=SVC, request=STRING, reply = TPFAIL+ STRING
service=SVC_1,tuxservice=SVC,inbuf=STRING,outbuf=STRING
Service=SVC_2, tuxservice=SVC,inbuf=STRING,outbuf=NULL,errbuf=STRING
入力 : service=FMLS,request=FML32(name,pwd),reply=TPSUCCESS+FML32(id)
service=FMLS_1,tuxservice=FMLS,inbuf=FML32,outbuf=FML32
param: input(name, pwd), output(id)
service=FMLS,request=FML32(name,pwd),reply=TPSUCCESS+FML32(id)
service=FMLS,request=FML32(name,pwd,token),reply=TPSUCCESS+FML32(id)
service=FMLS_1,tuxservice=FMLS,inbuf=FML32,outbuf=FML32
param: input(name, pwd), output(id)
service=FMLS_2,tuxservice=FMLS,inbuf=FML32,outbuf=FML32
param: input(name, pwd,token), output(id)
  
|