|
|
SALTでは、 Oracle Tuxedoサービス・メタデータ・リポジトリを利用して、Oracle Tuxedoの従来のサービスとSALTプロキシ・サービスの両方のサービス契約情報を定義します。リストされたすべてのOracle Tuxedoサービスのサービス規約情報を、ローカルOracle Tuxedoドメインによって提供されるOracle Tuxedoサービス・メタデータ・リポジトリ・システム・サービスにアクセスして取得します。通常は、次に示すように、SALTから TMMETADATAシステムを呼び出します。
GWWSサーバーの実行時間の時Oracle Tuxedoサービス・メタデータ・リポジトリを呼び出し、適切な時間に必要なOracle Tuxedoサービス定義を取得します。
Oracle Tuxedoサービス・メタデータ・リポジトリを呼び出し、必要なOracle Tuxedoサービス定義を取得して、それをWSDL記述に変換します。
次のトピックでは、SALT特有のOracle Tuxedoサービス・メタデータ・リポジトリ・キーワードとパラメータの使用について説明します。
表1では、SALTで使用および解釈されるOracle Tuxedoサービス・メタデータ・リポジトリのサービス・レベル・キーワードを示します。
| 注意: | リストされていないメタデータ・リポジトリのサービスレベル・キーワードは、SALTとは関係性がなく、SALTコンポーネントがOracle Tuxedoサービス・メタデータ・リポジトリをロードするときに無視されます。 |
Oracle Tuxedoサービス・メタデータ・リポジトリでは、パラメータはOracle Tuxedoサービスの型付きバッファ内にカプセル化されたサブ要素として解釈されます。パラメータごとに、データ型、バッファ内の出現回数、サイズ制限、その他のOracle Tuxedoに固有の制限を設定できます。次に注意してください。
バッファの個々のパラメータがVIEW/VIEW32構造のメンバー1つを表します。
バッファの個々のパラメータが、バッファ内に存在する可能性のあるFML/FML32フィールド要素を表します。
Oracle Tuxedoによってバッファ全体が1つのデータのように扱われます。バッファに対して最大で1つのパラメータを設定することが認められており、制約ファセット(バッファ・サイズのしきい値など)を定義できます。
パラメータを使用してバッファ型の詳細について説明することができます。
表2では、SALTで使用および解釈されるOracle Tuxedoサービス・メタデータ・リポジトリのパラメータ・レベル・キーワードを示します。
| 注意: | リストされていないメタデータ・リポジトリのパラメータレベル・キーワードは、SALTとは関係性がなく、SALTコンポーネントがOracle Tuxedoサービス・メタデータ・リポジトリをロードするときに無視されます。 |
|
|||
|
|||
この項では、ネイティブOracle TuxedoサービスをWebサービスとして公開するために必要な構成タスクと省略可能な構成タスクについて説明します。
1つまたは複数のHTTP/Sエンドポイントを介して一連のOracle TuxedoサービスをWebサービスとして公開するには、ネイティブWSDFを定義する必要があります。
各ネイティブWSDFは、一意のWSDF名で定義する必要があります。WSDFでは、Webサービス・アプリケーションの詳細(SOAPプロトコルの詳細、Webサービス操作として公開するOracle Tuxedoサービスの一覧など)に対して1つまたは複数の<WSBinding>要素を定義できます。
mapsoapheader属性は、SOAPヘッダーを構成するために使用します。これにより、SOAPヘッダーを表すFML32フィールドが定義されます。これはTA_WS_SOAP_HEADER STRINGタイプです。
| 注意: | mapsoapheader属性は、SALTに同梱されているwssoapflds.hファイルで定義されます。 |
リスト1では、SOAPヘッダーの定義の例を示します。
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper">
<Property name="mapsoapheader" value="true" /></Service>
</Servicegroup>
....
</WSBinding>
</Definition>
mapsoapheader属性のデフォルト値は「false」で、これは、GWWSがSOAPヘッダーとFMLフィールド間のマッピングを実行しないことを示します。
mapsoapheaderをtrueに設定すると、着信サービスおよび発信サービスのマッピング動作は次のようになります。
インバウンド・サービスについては、リスト2に示すように、GWWSがSOAPヘッダーを変換します。
<cup:SoapHeader xmlns:cup='http://www.xxx.com/soa/esb/message/1_0'>
<cup:Head>
<cup:Name>xxx</cup:Name>
<cup:Value>xxx</cup:Value>
</cup:Head>
</cup:SoapHeader>
STRINGバッファは、TA_WS_SOAP_HEADERフィールドに割り当てられ、ターゲットFML32バッファを挿入します。ターゲット・バッファ・タイプがFML32ではない場合、変換は有効になりません。
発信サービスでは、GWWSは、リクエスト・バッファからTA_WS_SOAP_HEADERを受け取り、SOAPパッケージの構成時にSOAPヘッダーにそれを配置します。
個々のWSBindingオブジェクトは、<WSBinding>要素を使用して定義します。個々のWSBindingオブジェクトは、WSDF内で一意のWSBinding IDを使用して定義する必要があります。WSBinding IDは、GWWSによって使用されるSALTDEPLOYファイルの参照に必要なインジケータです。
個々のWSBindingオブジェクトは、<SOAP>サブ要素を使用してSOAPプロトコルの詳細に関連付けることができます。WSBindingオブジェクトには、デフォルトではSOAP 1.1およびdocument/literalスタイルのSOAPメッセージが適用されます。
リスト3では、<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>サブ要素を使用してOracle Tuxedoサービスのグループに定義する必要があります。<Servicegroup>の下の各<Service>要素は、WebサービスのクライアントからアクセスできるOracle Tuxedoサービスを表します。
個々のサービス・オブジェクトは、<Service>要素を使用して定義します。各サービスは、公開されたOracle Tuxedoサービスを示すように「name」属性で指定する必要があります。通常、Oracle Tuxedoサービス・メタデータ・リポジトリからOracle Tuxedoサービス規約情報を取得するには、「name」値がキー値として使用されます。
リスト4では、WSBindingのサービス・グループを定義する方法を示します。
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper" />
<Service name="tolower" />
</Servicegroup>
...
</WSBinding>
</Definition>
SOAP XMLペイロードおよびOracle Tuxedo型付きバッファの変換ルーチンをカスタマイズするために独自のプラグイン機能を作成できます。詳細は、SALT Webサービスのプログラミングの SALTプラグインの使用に関する項、および「プラグイン・ライブラリの構成」を参照してください。
プラグインを作成および構成すると、<service>要素を使用してそれを参照して、そのサービスのユーザー定義データ・マッピング・ルールを指定できます。<Msghandler>要素は、メッセージ・レベル(<Input>、<Output>または<Fault>)で定義して、メッセージを変換するために「P_CUSTOM_TYPE」カテゴリ・プラグインのどの実装を使用する必要があるかについて指定できます。<Msghandler>要素の内容はプラグインの名前です。
リスト5では、入力を変換するために「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>SALTには、使用されることの多い用途に合せてあらかじめパッケージ化されたWS-Policyファイルが含まれています。これらのWS-Policyファイルは$TUXDIR/udataobj/salt/policyディレクトリにあります。これらのファイルを参照するには、location=”salt:<policy_file_name>”を使用します。
リスト6では、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-Securityポリシー・ファイルの使用」を参照してください。
Oracle TuxedoのネイティブWSDFが作成されたら、SALT WSDLの生成ユーティリティtmwsdlgenを使用して、対応するWSDLファイルを生成できます。次のサンプル・コマンドでは、「app1.wsdf」というWSDFから「app1.wsdl」というWSDLファイルを生成します。
tmwsdlgen -c app1.wsdf -o app1.wsdl
| 注意: | tmwsdlgenを実行する前に、TUXCONFIG環境変数を正しく設定し、TMMETADATAを使用して関連するOracle Tuxedoアプリケーションを起動する必要があります。 |
または、「-o」オプションを使用して出力WSDLファイル名を指定できます。指定しない場合、tmwsdlgenは、デフォルト値として「tuxedo.wsdl」という名前のWSDLファイルを作成します。
ネイティブWSDFファイルに、CARRAYバッファを使用するOracle Tuxedoサービスが含まれている場合、CARRAYバッファ・マッピングに対して別のスタイルのWSDLファイルを生成するためにtmwsdlgenオプションを指定できます。デフォルトでは、CARRAYバッファがSOAPメッセージでxsd:base64Binary XMLデータ型としてマップされています。詳細は、SALT Webサービスのプログラミングの データ型のマッピングと変換に関する項、およびSALTリファレンス・ガイドのtmwsdlgenに関する項を参照してください。
Oracle TuxedoのバージョンベースのルーティングをWebサービスとして公開されているOracle Tuxedoサービスで使用すると、次のことが行われます。
リスト7では、GWWSがUBBCONFIGの設定からリクエスト・バージョンの"1"を継承しているため、VERSION_RANGE設定(この例ではGROUP1)に"1"を含んでいるOracle Tuxedoアプリケーション・サーバーによって通知されるサービスを公開する例を示します。GWWSが公開するサービスが実際にはGROUP2のサーバーで実行されている場合は、結果として、TPENOENTエラーがWebサービスのクライアントに転送されます。
...
GROUP1
LMID=L1 GRPNO=2 VERSION_RANGE="1-2"
GROUP2
LMID=L1 GRPNO=2 VERSION_RANGE="3-4"
GWWS_GRP
LMID=L1 GRPNO=3 REQUEST_VERSION=1
...
|mySERVER SRVGRP=GROUP2 SRVID=30
...
GWWS SRVGRP=GWWS_GRP SRVID=30
...
外部Webサービスは、手動またはSALTのWebコンソールを介して構成できます。
Webコンソールは、GUIベースのSALT構成ツールです。機能の1つに、WSDLファイルの指定による外部Webサーボスのインポートがあります。
WSDLファイルは、SALT WebコンソールのメインWebページの「外部Webサービスのインポート」への入力として指定します。入力ファイルは、Webコンソールを起動するローカルの場所に置くことも、GWWSサーバーがアクティブとして実行されるサーバー(リモート)上に置くこともできます。
WSDLファイルを受信すると、GWWSサーバーはwsdlcvtツールを使用して、APPDIRディレクトリに次の各拡張子に対応したファイルを生成します。
wsdlcvt -y -f -i <input_WSDL_file> -o <base_name>
前述のファイルは、WSDLファイルを入力するだけでGWWSサーバーによって内部的に生成されるため、ユーザーの介入は必要ありません。
ファイルが正常に生成されたら、APPDIRディレクトリに次の環境変数を設定する必要があります。
GWWSサーバーは、WSDLファイルからインポートした新しいサービス/操作およびバインドで、サービス・メタデータ・リポジトリとSALT構成ファイル(SALTCONFIG)をリロードします。
インポートされたWebサービスは、SALT Webコンソールのメイン・ページの「インポートされたWebサービス」セクションの下に表示されます。詳細は、次の項を参照してください。
SALTには、外部WSDLファイルをOracle Tuxedo定義に変換するためのWSDL変換コマンド・ユーティリティが付属しています。WSDLファイルはExtensible Stylesheet Language Transformations (XSLT)テクノロジを使用して変換されます。SALTのインストール・パッケージには、デフォルトのXSLTツールキットとして使用するApache Xalan Java 2.7.0がバンドルされています。
SALT WSDLコンバータは2つの部分で構成されています。
wsdlcvtは、Xalanツールキットを呼び出します。このラッパー・スクリプトでは、使いやすいWSDLコンバータ・インタフェースが提供されています。次のサンプル・コマンドでは、外部WSDLファイルを変換してOracle Tuxedo定義ファイルを生成しています。
wsdlcvt -i GoogleSearch.wsdl -o GSearch
表3では、SALT WSDLコンバータによって生成されたOracle Tuxedo定義ファイルを示します。
SALTでは、各wsdl:messageがOracle Tuxedo FML32タイプ・バッファにマップされます。SALT WSDLコンバータでは、各メッセージのXML Schemaが分解され、各基本XMLスニペットにFML32フィールドとしてマップされます。生成されたFML32フィールドは定義表ファイルで定義され、デフォルトではそのフィールド名がXML要素のローカル名と同じになります。
Oracle TuxedoアプリケーションからSALTプロキシ・サービスにアクセスする場合は、生成されたFML32フィールドを参照してリクエスト・メッセージとレスポンス・メッセージを処理する必要があります。FML32環境変数を適切に設定して、Oracle TuxedoアプリケーションとGWWSサーバーの両方がフィールド名とフィールドID値をマップできるようにする必要があります。
|
|||
SALT WSDLコンバータでWSDLファイルをWSDFファイルに変換し、これを発信方向のSALTデプロイメント・ファイルでGWWSサーバーにデプロイできます。生成されたWSDFファイルは、ネイティブではないWSDFファイルになります。
|
|||
WSDLの埋め込みXML SchemaとインポートXML Schema(<xsd:import>で参照するXML Schemaコンテンツ)は、ローカルに.xsdファイルとして保存されます。これらはGWWSサーバーで使用するファイルで、同じディレクトリに保存する必要があります。
|
表4では、WSDL要素からTuxedoサービス・メタデータ定義キーワードへのマッピング・ルールを示します。
|
||||
表5では、WSDL要素からWSDF要素へのマッピング・ルールを示します。
発信Webサービス・アプリケーションを構成するには、次の変換後のタスクを実行する必要があります。
WSDLファイルを変換すると、コンテキスト情報の切捨てや消失のせいで、予期せぬ名前の競合が発生する場合があります。生成されたサービス・メタデータ定義とFML32フィールド表ファイルを使用する前に、次のような名前の競合を解決する必要があります。
「tuxservice」の定義が重複している場合は解決する SALTプロキシ・サービス・メタデータ定義のキーワードtuxserviceは、元のWebサービス・オペレーションのローカル名が15文字以上ある場合はそれ以降を切り捨てた値になります。
そのため、複数SALTプロキシ・サービス・エントリで、切捨て後のtruncatedの値が重複する可能性があります。GWWSサーバーではtuxserviceの値を通知済のサービス名として使用するため、複数のSALTプロキシ・サービス間の名前の競合を手動で解決して、サービス要求が確実に配信されるようにする必要があります。名前の競合を解決するには、tuxserviceに一意で意味のある名前を割り当てる必要があります。
外部WSDLファイルをOracle Tuxedo定義に変換すると、各wsdl:messageが解析され、wsdl:messageの基本XMLスニペットを表すFML32フィールドのセットが含まれているFML32バッファ・フォーマットとしてマップされます。生成されるFML32フィールドは、デフォルトでは対応するXML要素のローカル名に基づいて命名されます。
生成されたフィールド表ファイル内のFML32フィールド定義はフィールド名でソートされるため、重複している名前を簡単に見つけることができます。SOAP/FML32のマッピングを実現するには、フィールド名の競合を解決する必要があります。生成によって重複したフィールド名を、一意で意味のある他のFML32フィールド名値に変更する必要があります。それに合わせて、生成されたSALTプロキシ・サービス定義内の対応するサービス・メタデータ・キーワードparamの値も変更しなければなりません。FML32フィールドとサービス・メタデータ・キーワード「param」の定義について生成されるコメントは、どのnameとparamが対応するかを調べる際に有用です。
名前の競合が解決したら、tmloadreposユーティリティを使用して、SALTプロキシ・サービス・メタデータ定義をOracle Tuxedoサービス・メタデータ・リポジトリにロードする必要があります。詳細は、Oracle Tuxedoコマンド・リファレンス・ガイドのtmloadreposに関する項を参照してください。
発信Webサービス用にGWWSサーバーを起動する前に、次の環境変数を設定する必要があります。
FIELDTBLS32環境変数を更新します。XSDDIR環境変数およびXSDFILES環境変数を設定します。XSDDIR環境変数およびXSDFILES環境変数が含まれています。 これらは、GWWSサーバーによって使用され、実行時にすべての外部XMLスキーマ・ファイルをロードします。複数の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を使用してTuxedoにインポートした外部Webサービスで、Oracle Tuxedoのバージョンベースのルーティングを使用する場合は、次のことに注意してください。
• GWWSの1つのインスタンスが同じ名前の2つ以上のサービスを通知することはできません。同じサービスは異なるインスタンスにある必要があります。
• 前述に基づいて、*GROUPのそれぞれにVERSION_RANGEを設定して複数のGWWSインスタンスを構成すると、既存のメカニズムで簡単に利用することができます。
リストでは、Oracle Tuxedoプログラム(クライアントまたはサーバー)がGROUP2とGROUP3の両方のグループのGWWSで公開されている外部Webサービスを呼び出す例を示します。バージョン1または2を使用しているプログラムは、GROUP2のGWWSが公開しエンドポイント1に接続しているサービスにルーティングされます。また、バージョン3または4を使用しているプログラムは、GROUP3のGWWSが公開しGROUP2のGWWSとは別のエンドポイントに接続しているサービスにルーティングされます。
...
GROUP2
LMID=L1 GRPNO=2 VERSION_RANGE="1-2"
GROUP3
LMID=L1 GRPNO=3 REQUEST_VERSION=1 VERSION_RANGE="3-4"
...
GWWS SRVGRP=GROUP2 SRVID=30
...
GWWS SRVGRP=GROUP3 SRVID=30
...
同じサービス・グループおよびサービス操作に対して複数のバインドを作成することができます。ただし、異なるサービス・グループおよび操作に対して複数のバインドを作成することはできません。
着信サービスについては、複数バインドを次のように作成することができます。
複数のバインドを追加するには、Webコンソールを使用する必要があります。
WSDLファイルを使用してインポートしたWebサービスは、Tuxedoクライアントがリクエストを送信し外部Webサービスからレスポンスを受信する、発信サービスです。
インポートしたWebサービスのユーザーは、Webコンソールとポリシー・ファイルを使用して、エンドポイント・アドレスの値を変更することができます。ただし、複数バインドやSOAP属性を追加することはできません。
SALTデプロイメント・ファイル(SALTDEPLOY)では、SALT Webサービスのアプリケーションを定義します。SALTDEPLOYファイルは、バイナリSALTCONFIGファイルのWebサービス・アプリケーションに対する重要な入力です。
SALTDEPLOYファイルを作成するには、次の手順に従います。
詳細については、『Oracle SALTリファレンス・ガイド』のSALTデプロイメント・ファイルのリファレンスに関する項を参照してください。
必要なWSDFファイルをすべてSALTデプロイメント・ファイルにインポートする必要があります。インポートされた各WSDFファイルには、一意のWSDF名が設定されている必要があり、この名前はデプロイメントに関連付けるためにGWWSサーバーによって使用されます。インポートされた各WSDFファイルは、SALTDEPLOYファイルに指定した場所を介してアクセスできる必要があります。
リスト9には、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またはそれ以上のアクセス・エンドポイントを発信エンドポイントとして指定できます。
リスト10には、着信および発信エンドポイントで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」属性は、値を含む異なるプロパティ要素を表します。表6に、GWWSサーバーレベル・プロパティを示します。
| 注意: | 詳細は、複数のエンコーディング・サポートの構成を参照してください。 |
| 注意: | 詳細は、「SALTの実行時の管理」のGWWSサーバーのチューニングに関する項を参照してください。 |
リスト11GWWSプロパティの構成方法の例を示します。
<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メッセージとOracle 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での複数のエンコーディング・サポートを有効にするには、リスト12に示すように、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>
表7では、GWWSサーバー・レベルの複数エンコーディング・プロパティを有効にした場合に適用される、SOAPメッセージとTuxedoバッファの間のエンコーディング・マッピング・ルールの詳細について説明します。
|
||||
|
||||
|
SALTでは、すべてのGWWSサーバーによって共有される一連のグローバル・リソースをSALTDEPLOYファイルで定義します。次のシステムレベル・リソースをSALTDEPLOYファイルで構成できます。
証明書の情報は、SSLリスニング・エンドポイントを作成するまたは認証およびメッセージ署名用X.509証明書を使用するようにGWWSサーバーで構成する必要があります。同じデプロイメント・ファイルに指定したすべてのGWWSサーバーは同じ証明書の設定(秘密鍵ファイル、信頼されている証明書ディレクトリなどを含む)を共有します。
秘密鍵ファイルは<Certificate>/<PrivateKey>サブ要素を使用して構成します。秘密鍵ファイルはPEMファイル形式で、ローカルで保存される必要があります。<Certificate>/<VerifyClient>サブ要素をtrueに設定すると、SSLクライアントを確認できます。
| 注意: | デフォルトでは、GWWSサーバーはSSLクライアントを確認しません。 |
SSLクライアントを確認する場合やX.509証明書の認証機能が有効になっている場合、一連の信頼済証明書はローカルで保存し、GWWSサーバーで指定する必要があります。GWWSサーバーの信頼済証明書を定義するには2つの方法があります。
| 注意: | 識別名の「cn」属性は、証明書ルックアップ用のキーとして使用されます。名前で使用されるワイルドカードはサポートされません。空の件名フィールドは許可されません。この制約はOracle Tuxedoでも見つかります。 |
リスト13には、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サーバーの起動中に呼び出される関数のセットです。SALTには、プラグインを定義して実装するための共通インタフェースとして、プラグイン・フレームワークが用意されています。プラグインを実装するには、実際の関数が含まれているダイナミック・ライブラリを使用します。実装ライブラリはGWWSサーバーの起動中に動的にロードされます。関数は、プラグイン・インタフェースの実装として登録されます。
GWWSサーバーがライブラリをロードできるように、ライブラリは<Plugin>/<Interface>要素を使用してSALTDEPLOYファイルに指定する必要があります。
リスト14には、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のプログラミング』のSALTプラグインの使用に関する項を参照してください。 |
現在のSALTは次の高度なWebサービス・メッセージング機能をサポートしています。
非同期Webサービス・メッセージングの着信と発信の両方をサポートします。
着信Webサービスの信頼性のあるメッセージ配信をサポートします。
SALTでは、着信サービスおよび発信サービスの両方にWebサービスAddressingがサポートされます。GWWSサーバーによって使用されるWeb Service Addressing (WS-Addressing)のメッセージは、Web Service Addressing標準(W3C Member Submission 2004年8月10日)に準拠している必要があります。
着信サービスは特有なWeb service addressingの構成が必要ではありません。GWWSサーバーはWS-Addressingリクエスト・メッセージおよび非WS-Addressingリクエスト・メッセージによって受け付けて回答します。
発信サービスについては、以下の項で説明しているようにWeb service addressingの構成が必要です。
発信サービスについては、Web Service AddressingはWebサービス・バインディング・レベルで構成します。SALTDEPLOYファイルでは、各GWWSサーバーは、WS-Addressingを有効にするために参照された任意の発信WSBindingオブジェクトに対して、<WSAddressing>要素を使用してWS-Addressingエンドポイントを指定できます。
WS-Addressingエンドポイントを設定した後、GWWSサーバーは起動時にリスニング・エンドポイントを作成します。発信WSBindingに指定したすべてのサービスはWS-Addressingメッセージで呼出します。
リスト15には、参照された発信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」に設定する必要があります。このプロパティは、着信サービスには影響しません。
リスト16には、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>
現在、SALTは着信サービスのみの信頼性のあるメッセージングをサポートしています。信頼性のあるメッセージングの機能を有効にするには、Webサービスの信頼性のあるメッセージングのポリシー・ファイルを作成し、このポリシー・ファイルをWSDFに含める必要があります。ポリシー・ファイルはWS-ReliableMessagingポリシー・アサーション仕様(2005年2月)に準拠している必要があります。
| 注意: | 信頼性のあるメッセージング・ポリシーの定義を含むWSDFは、着信方向のみにGWWSサーバーで使用する必要があります。 |
信頼性のあるメッセージングのポリシー・ファイルは、WS-ReliableMessagingのアサーションを含む一般的なWS-Policyファイルです。WS-ReliableMessagingのアサーションは、サポート対象のWS-ReliableMessage仕様のバージョン、ソース・エンドポイントの再伝送までの時間間隔、送信元エンドポイントの承認までの時間間隔などの機能を説明するXMLセグメントです。
詳細は、SALTリファレンス・ガイドのSALT WS-ReliableMessagingポリシー・アサーション・リファレンスに関する項を参照してください。
リスト17には、信頼性のあるメッセージングのポリシー・ファイルの例を示します。
<?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ポリシー・ファイルを参照する必要があります。リスト18には、WS-ReliableMessagingポリシー・ファイルの参照方法を示します。
<Definition ...><Policy location=”RMPolicy.xml” />
<WSBinding ...>
<Servicegroup ...><Service ... />
<Service ... />
...
</Servicegroup ...>
</WSBinding>
</Definition>
| 注意: | SALTにおいて、信頼性のあるメッセージングではプロセス障害/システム障害の状況がサポートされていません。つまり、SALTではメッセージが永続ストレージ領域には保存されません。SALTはSOAPクライアントと直接モードでやりとりします。通常、システム障害から回復するには、クライアントとサーバーの間でビジネス・ロジックの同期化を行う必要があります。 |
SALTは、CARRAY型付きバッファ、またはフィールド付きバッファ(VIEW、VIEW32、FMLまたはFML32)のCARRAYフィールドに対するバイナリ添付ファイルをサポートします。デフォルトでは、バイナリ・バッファ/フィールドはbase64エンコードされます。リスト19に示すように、MTOMを有効にするには、WSDFファイルでサービスまたはサービス・グループに構成を追加する必要があります。
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper">
<Policy location="salt:ws-mtom.xml"/> </Service>
<Service name="tolower" />
</Servicegroup>
....
</WSBinding>
</Definition>
SALTでは、転送レベルとSOAPメッセージ・レベルの両方のレベルでセキュリティがサポートされます。次のトピックでは、各レベルにおいてセキュリティ機能を設定する方法について説明します。
SALTでは、SSLリンクレベル・セキュリティを使用してポイントツーポイント・セキュリティが提供され、着信サービスおよび発信サービスの両方のサービス認証に対してHTTP基本認証メカニズムがサポートされます。
SSLを使用して着信エンドポイントでリンク・レベル・セキュリティを設定するには、エンドポイント・アドレスの前に接頭辞として「https://」を指定できます。この着信エンドポイントを使用するGWWSサーバーは、SSLリスニング・ポートを作成してWebサービス・クライアントをSSL接続で保護します。SSL機能では、証明書の設定を指定する必要があります。詳細は、「証明書の構成」を参照してください。
発信エンドポイントへのSSL接続は、GWWSサーバーによって自動的に作成され、接頭辞「https://」のURLで公開されます。
SALTでは、Webサービスのクライアントを認証するかどうかは、Oracle Tuxedoセキュリティ・フレームワークによって決まります。SALTには、着信HTTP基本認証を有効にするために必要な特定の構成はありません。Oracle Tuxedoシステムでユーザー資格証明が必要な場合、Webサービス・クライアント・プログラムのかわりにHTTP基本認証がユーザー資格証明を実行します。
GWWSゲートウェイでは、次に示す2つの認証パターンに関するOracle Tuxedoドメイン・セキュリティ構成がサポートされています。
GWWSサーバーは、クライアントSOAPリクエストのHTTPヘッダーから次の文字列を取得し、Oracle Tuxedoでの認証用に渡します。
Authorization: Basic <base64Binary of username:password>
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
この例では、クライアントから渡されたOracle Tuxedoユーザー名は「Aladdin」、パスワードは「open sesame」であり、このペア値がOracle Tuxedoの認証に使用されます。
SALTは、発信HTTP基本認証のユーザー資格証明を作成するために認証プラグイン開発をサポートしています。発信HTTP基本認証は、エンドポイントレベルで構成されます。発信エンドポイントにおいて、HTTPメッセージでユーザー・プロファイルが必要の場合、WSDFファイル内でHTTPエンドポイント用HTTPレルムを指定する必要があります。GWWSサーバーは、ユーザー名とパスワードを作成するために認証プラグイン・ライブラリを呼出し、HTTP基本認証メカニズムを使用してリクエスト・メッセージに送信します。
リスト20には、発信エンドポイントに対する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>要素の設定で指定された発信エンドポイントに送信すると、Oracle TuxedoクライアントuidおよびgidがGWWSサーバーから認証のプラグイン機能に渡されます。このプラグイン機能はOracle Tuxedoクライアントの情報に従ってHTTP基本認証のusername/passwordを確定します。HTTP基本認証のusername/passwordマッピングのためにOracle Tuxedoクライアントuid / gidを取得するには、Oracle Tuxedoセキュリティ・レベルもUBBCONFIGファイルで構成する必要があります。詳細は、『SALT Webサービスのプログラミング』の発信HTTP基本認証のOracle Tuxedoセキュリティ・レベルの構成に関する項と発信認証プラグインのプログラミングに関する項を参照してください。
SALTでは、メッセージ・レベル・セキュリティに対してWebサービス・セキュリティ1.0および1.1仕様をサポートします。SALTでは、次の項目を保証するためにメッセージレベル・セキュリティを使用できます。
Webサービス・セキュリティのSALTの実装: SOAPメッセージ・セキュリティの仕様は次のユース・ケースをサポートします。
SALTには、メッセージ・レベル・セキュリティのユースケースのために使用される複数のWS-Securityポリシー1.0および1.2のファイルが含まれています。
SALTが正常にインストールされると、WS-Policyファイルが$TUXDIR/udataobj/salt/policyに配置されます。
表8に、SALTに付属するデフォルトWS-Securityポリシー・ファイルを示します。
上述のWS-Security Policy 1.2 UserTokenファイル以外のすべてのポリシー・ファイルを、ネイティブWSDFファイルの<Servicegroup>要素または<Service>要素を使用して参照できます。WSSP 1.2 UserTokenファイルは、 <Servicegroup>を使用した場合のみ参照できます。
リスト21に、サービス「TOUPPER」で、クライアントがプレーン・テキスト形式のUsernameTokenとリクエスト形式のX509v3Tokenを送信する必要があり、X.509トークンで署名付きメッセージのSOAP:Body部分も必要とする、ポリシー割当ての組合せを示します。サンプル「wsseapp」では、WSSP 1.2 UserTokenファイルを<Service>要素で使用するようにクリップする方法を示します。
<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は、SAML 1.1とSAML 2.0シングル・サインオン(SSO)をサポートします。シングル・サインオンを使用すると、エンド・ユーザーにかわって認証を実行することにより、セキュアな受信リクエストを処理できます。資格証明を要求する必要はありません。
SAML SSOのSALT実装は、送信者保証による確認方法をサポートします。この方法では、SALTはバックエンド・システムを表し、Webサービス媒介者がバックエンドとエンド・ユーザーの間に存在します。この場合、Webサービス媒介者は、SAMLトークン・メカニズムを使用してエンド・ユーザーを「保証」します。
| 注意: | SAML SSOを使用するため、SALTDEPLOYファイルの<Certificates>要素が正しく構成されていることを確認します。 |
GWWSを介してOracle TuxedoにアクセスするためのSAMLセキュリティ・トークンを所持するトランスポートとしてTLS/SSLを使用することは必須ではありませんが、Webサービス媒介者がSAMLセキュリティ・トークンを使用してGWWSを介してOracle Tuxedoにアクセスするには、TLS/SSLを使用することをお薦めします。TLS/SSLを使用すると、SOAPメッセージの内容が開示または変更されたことが検知されません。これはファイアウォール外のワイド・エリア・ネットワークを介してOracle Tuxedoサービスにアクセスするときに特に重要です。
信頼できるSAMLアサーション発行者の公開鍵証明書は、$APPDIRディレクトリに存在する必要があります。これらの証明書は、PEM形式である必要があります。証明書の名前は、発行者の名前が反映されている必要があります。たとえば、発行者IDが「"ws_1"」の場合、証明書名はws_1.pemである必要があります。
ただし、発行者名が長い場合、PEMファイル名をかなり簡潔にしても管理者に役立つように、キー・ファイルによって、本当の発行者名とそのローカルの参照名を相互に関係付けることが可能です。
たとえば、アサーション発行者名がweb.abc.com/saml/authenticatorの場合、その公開鍵証明書のPEMファイル名は、「www.abc.com/saml/authenticator.pem"」でなく「abc.pem」と名付けることができます。
これは、「/」記号がパスの区切り文字としても機能するUNIX環境の場合に特に有効です。そのような混乱が起こる可能性がある場合、この変換は必須です。
キー・ファイル名は、「saml_key.meta」に固定されます。「CertPath」で指定されたのと同じファイル・フォルダにあるはずです。このファイルはXML形式であり、ファイル・システムで保護されている必要があります。
キー・ファイルは、XMLファイルです。このファイルには、次の3種類の情報が保存されています。
| 注意: | このファイルを手動で変更しないでください。ファイルの整合性チェックが失敗する原因になります。 |
ファイル情報のセクションには、このファイルを生成したツールのバージョン番号、ランダム・キー、管理パスワードおよびデジタル署名が含まれます。
このGWWSキーのセクションには、GWWS対称鍵が1つ含まれます。GWWSが検証タスクを単純化するように構成できる対称鍵は1つのみです。このキーは、不明瞭化されたキーで暗号化されます。構成されているGWWS対称鍵がない場合、このセクションはオプションであり、消去されます。
異なるマシン・ノード上に複数のGWWSを持つMP構成では、このファイルが各ノード上でレプリケートされる必要があります。しかし、異なるGWWSキーが望ましい場合、類似してはいるがGWWSキー・レコードが異なっているキー・ファイルを異なるノードへコピーできます。
このセクションには、複数のレコード(信頼できるアサーション発行者ごとに1つ)が含まれます。発行者識別子、ローカル発行者識別子、対称鍵、および公開鍵証明書も存在するかどうかが含まれます。
発行者識別子は、WSSEセキュリティ・ヘッダー内で「<saml:Assertion>」要素の「issuer」属性で示される値です。
ローカル発行者識別子が発行者の略名です。長い発行者識別子を、短くて覚えやすく、しかもローカルに一意性を保つようにするためのものです。このオプションのデータが存在し、証明書も存在する場合、証明書はローカル発行者識別子の名前にファイル拡張子「pem」を付けたものである必要があります。
対称鍵は、発行者がアサーションに署名した共有シークレットです。このデータはオプションです。署名にどのアルゴリズムが使用できるかは、キーの長さからもわかります。
公開鍵証明書が存在するかどうかを示すフィールドの値は、公開鍵証明書が存在するかどうかを示します。証明書が存在する場合、証明書は「CertPath」要素で指定されたフォルダ内にあるはずです。このフィールドは、同時に対称鍵フィールドが存在する場合にも真である可能性があります。GWWSは、実行時に、どちらのキーを使用して署名を検証するべきかを検出します。
キー・ファイルを管理するための新しいコマンドがwsadminに追加されます。この新しいコマンドを使用して、新しいキー・ファイルの生成、新しいレコードの追加、既存のレコードの削除、およびレコードの変更を実行できます。管理するファイルの名前は、現在の作業ディレクトリの「saml_key.meta」です。
キー・ファイルを作成するには、次のwsadminコマンドを発行します。
ここで「-p password」は、新しく作成されたキー・ファイルにアクセスするための管理のパスワードです。名前が「saml_key.meta」のキー・ファイルが、現在の作業ディレクトリに作成されます。
saml add -i -n authority.abc.com -l abc -c -p password
ここで、「-i」は、名前が「authority.abc.com」、短いローカル参照名が「abc」で、キー・ファイルにアクセスするためのアクセス・パスワードを持つ発行者を追加するように指示しています。キー・ファイルsaml_key.metaは、現在の作業ディレクトリに存在する必要があります。「-c」オプションがあるため、「abc.pem」という名前の公開鍵証明書が「CertPath」の中に存在する必要があります。
詳細は、『SALTコマンド・リファレンス』のwsadminに関する項を参照してください。
次に、SALT管理者がGWWSを、SAMLアサーションを扱えるように初めて設定する手順について説明します。
$APPDIRに変更し、wsadminを開始します。saml create」コマンドを使用してキー・ファイルを作成します。 saml add -g」コマンドを使用してGWWSレコードを追加します。saml add -i」コマンドを使用して、信頼できる各アサーション発行者に対応する、信頼できるアサーション発行者レコードを追加します。Certificate」要素に記述されたディレクトリに、ファイル「saml_key.meta」をコピーします。"tmboot -y"を使用してOracle Tuxedoアプリケーション・ドメインを起動します。MPモード構成では、異なるGWWSインスタンスに対して、キー・ファイル内に異なるGWWSレコードが存在することが可能です。次の手順では、GWWSインスタンスに対応するキー・ファイルを異なるノード上で作成します。
SALTには、SAML SSO用にサービスを構成するために使用できるいくつかのWS-Policyファイルが含まれます(Table9参照)。
前述のファイルは、ネイティブのWSDFファイルの<ServiceGroup>または<Service>のレベルで参照できます。
このポリシーは、他のWS-Securityポリシー(インバウンド本体の署名など)と組み合される場合があります。詳細は、「メッセージ・レベルのWebサービス・セキュリティの構成」を参照してください。
たとえば、リスト22は、サポートされている機能を概説したSAML1.1のポリシー・ファイルを示しています。
<?xml version="1.0"?>
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Tokensp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Always">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:ProtectTokens/>
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedSupportingTokens>
<wsp:Policy>
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssSamlV11Token10/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
</wsp:Policy>
表10に、オプションのSAMLアサーション要素が提示する必要があるものをリストします。
NONEとAPP_PWの例では、オプションの要素「Subject」が存在する場合、Oracle Tuxedoにアクセスするのに「NameID」が使用されます。オプションの「Subject」要素が存在しない場合、クライアントは匿名ユーザー・アイデンティティでOracle Tuxedoにアクセスするものとみなされます。匿名アクセスが許可されない(つまり匿名に対する資格証明マッピングがない)場合、リクエストは失敗します。
SAMLアサーションが「Subject」要素を含まず、TuxedoのSECURITYレベルがUSER_PW、ACL、またはMANDATORY_ACLに構成されている場合、リクエストは拒否されます。
発信GWWS SOAPメッセージのX.509ベース認証には、X.509 V3公開鍵証明書が必要です。この目的で使用する公開鍵証明書は、同じWebサービスを宛先とするすべてのリクエスト用に1つの証明書を構成するか、Tuxedo SECURITYがUSER_AUTH以上に設定されている場合はリクエストの呼出しごとに1つの証明書を構成します。後者の場合、証明書にはTuxedoユーザーIDまたはマップされたリモート・ユーザー名(IDマッピング・プラグインがインストールされている場合)と同じ名前が付けられている必要があります。
1. トランスポート層のセキュリティ用の手動認証(SSL/TLSなど)
3. メッセージレベルで(トランスポート層ではなく)ユーザーを認証するために使用するSOAPメッセージの一部
3つのタスクのすべてを実行するか一部のみを実行するかは、Webサービスで使用するWSポリシーによって異なります。
メッセージの暗号化は必須ではないため、サポートされません。メッセージの整合性とプライバシを保護するには、SSL/TLSを優先トランスポート・メカニズムにすることをお薦めします。SSL/TLSに使用されるX.509公開鍵証明書は署名に使用されるものとは異なり、ユーザーの構成に依存します。
GWWSはクライアントからのリクエストを受信すると、メッセージを処理し、オプションでメッセージに署名を行い、WSポリシーで要求されている場合は証明書をSOAPリクエスト・メッセージへのバイナリ・セキュリティ・トークンとして添付します。次に、SSL/TLSを介してリモートWebサービスにリクエストを送信します。このSSL/TLS接続が一方向SSLまたは双方向SSLのいずれになるかは、WSポリシーによって異なります。
SSL/TLS接続がプロセスを確立している間、接続が双方向SSLでありリクエストをWebサービスに転送する場合、アプリケーション・サーバーはクライアントの証明書を検証します。
Webサービスはリクエストを受信すると、Webサービスで要求されている場合は証明書を検証し、署名を検証します。 リクエストが正しい場合は、応答を返信します。Webサービスによって返信される応答にも、WSポリシーに従って署名が行われます。
GWWSは応答を受信すると、それを実際のSALTクライアントに転送します。応答に署名がある場合、GWWSはSALTクライアントに応答を返信する前に、証明書を検証し、署名を確認します。
<S11:Envelope xmlns:S11="…" >
<S11:Header>
<wsse:Security xmlns:wsse="…" xmlns:wsu="…">
<wsse:BinarySecurityToken
wsu:id="binarytoken"
ValueType="wsse:X590v3"
EncodingType="wsse:Base64Binary">
MIIEzzCCA9CgAwIBAgIQEmtJZc0…
</wsse:BinarySecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:Reference URI="#body">…</ds:Reference>
<ds:Reference URI="#binarytoken">…</ds:Reference>
</ds:SignedInfo>
…
</ds:Signature>
</wsse:Security>
</S11:Header>
<S11:Body wsu:Id="body" xmlns:wsu="…">
…
</S11:Body>
</S11:Envelope>
GWWSを介してWebサービスに正常にアクセスするには、GWWSが実行時にアクセスできる有効なクライアント証明書と秘密鍵を構成する必要があります。この証明書と秘密鍵は、Webサービスの要件に従って、トランスポート・レベル・セキュリティまたはメッセージ・レベル・セキュリティ、あるいはその両方で使用できます。
現在、Tuxedo SALTはデプロイメント記述子の"System"要素を通して構成された単一の証明書のみをサポートしています。この制限によって、異なるインスタンスのGWWSゲートウェイを通過するすべてのリクエストでSSL/TLS接続を確立するために同じ証明書が使用されます。同様に、Webサービスからは、これらが同じユーザーから送られたものとして見えるため、アクセス権限は同じです。新機能によってこの制約が排除され、異なる証明書を使用して異なるクライアントまたはゲートウェイを表すことができるようになりました。
SALT構成は、デプロイメント記述子(DEP)と複数のWebサービス定義ファイル(WSDF)で構成されます。新しい機能では、この目的に使用するデフォルトのユーザーIDの構成や、TuxedoユーザーIDをX.509証明書にマップするためのフィルタ/マッパーの使用方法をGWWSに指示するために"Property"を使用します。構成に使用する"Property"は、"GWInstance"および"Service"の両方に構成可能な子要素として使用可能なXML要素です。"GWInstance"はSALTデプロイメント記述子に構成されており、"Service"はSALT Webサービス定義ファイルに構成されています。
WebサービスのWS-Securityポリシーでメッセージレベルのセキュリティが必要とされている場合、GWWSは秘密鍵を使用してメッセージに署名を行い、SOAPメッセージにバイナリ・セキュリティ・トークンとして証明書を添付します。これは、ターゲットのWebサービスがメッセージを検証してユーザーを認証するために使用します。あるいは、証明書と秘密鍵のみを使用して、セキュアなトランスポート・レイヤー接続(SSL/TLS)を作成します
サービス・リクエストがユーザー識別に"X.509"セキュリティ・トークンを使用するかどうかは、Webサービスに関連付けられているWSセキュリティ・ポリシーによって決まります。
| 注意: | この機能は、X.509 V3公開鍵証明書のみをサポートします。他のバージョンはサポートされません。 |
メッセージ・レベルのセキュリティに使用されるX.509 V3公開鍵証明書は、次のいずれかのソースから入手します。
1. トランスポート・セキュリティ用に構成されたX.509証明書。
2. 特定のインスタンスのGWWSゲートウェイに関連付けられているX.509証明書。
3. Webサービスにプリセットされているプリンシパルに関連付けられているX.509証明書
4. SALTクライアントに関連付けられているX.509証明書
異なるセキュリティ設定を支援するための3つの新しいプロパティが構成に追加されました。3つのプロパティはすべて"GWInstance"と"Service"で使用できます。"Service"要素はWSDFで使用可能であり、"GWInstance"はSALTデプロイメント記述子で使用可能です。
このプロパティでは、X.509証明書のルックアップで使用するデフォルトのクライアント名を定義します。"Service"の構成は"GWInstance"の構成より優先されます。次の例では、サービス"GetData"の"catalina"がデフォルトとして有効なクライアント名であることを示します。
<?xml version="1.0" encoding="UTF-8" ?>
<!- Sample.wsdf
-->
<Definition …>
<WSBinding id="sample_Binding">
<SOAP>
<AccessingPoiints>
…
</AccessingPoint>
</SOAP>
<ServiceGroup id="SampleSrvGrp">
<Service name="GetData">
<Property name="defaultClientIdentification" value="catalina"/>
</Service>
</ServiceGroup>
</WSBinding>
</Definition>
<?xml version="1.0" encoding="UTF-8"?>
<!- sample.dep
-->
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<WSDF>
<Import location="c:/salt/x.509/Sample.wsdf"></Import>
</WSDF>
<WSGateway>
<GWInstance id="INSTANCE1">
<Outbound>
…
</Outbound>
<Properties>
<Property name="defaultClientIdentification" value="melbourne"/>
</Properties>
</GWInstance>
</WSGateway>
<System>
<Certificate>
…
</Certificate>
</System>
</Deployment>
GWWSインスタンス"INSTANCE1"で提供され、独自の"defaultClientId"を持たないその他のすべてのサービスについては、GWWSのデフォルト・クライアントID(ここでは"melbourne")が使用されます。
どのWebサービスにも同じクライアントX.509証明書を使用するかどうかは、"useSingleClientIdentification"で決まります。このフィルタを有効化するよう決定された場合、すべてのSALTクライアント・リクエストは"defaultClientIdentification"で構成された識別を使用します。"defaultCleintIdentification"が構成されていない場合は、構成エラーであるため、"wsloadcf"によってエラーが発行されます。このオプションはデフォルトでは無効にされています。
Tuxedo "SECURITY"が少なくとも"USER_AUTH"レベルで構成されている場合、このフィルタはランタイム・クライアントX.509証明書選択にのみ影響があります。Tuxedo SECURITYが"NONE"または"APP_PW"に構成されている場合、このフィルタはクライアント証明書の選択には使用されません。実行時にこの属性が無効化されたとしても、前の段落で説明したエラー条件は依然としてtrueです。
次に、この単一クライアント識別フィルタを使用可能にするかどうかを判定するためのマトリックス表を示します。
前の項の例では、両方の場所でこのプロパティを省略しているので、このフィルタは無効化されています。次の例では、このフィルタは有効化されています。
<?xml version="1.0" encoding="UTF-8" ?>
<!- Sample.wsdf
-->
<Definition …>
<WSBinding id="sample_Binding">
<SOAP>
<AccessingPoints>
…
</AccessingPoints>
</SOAP>
<ServiceGroup id="SampleSrvGrp">
<Service name="GetData">
<Property name="defaultClientIdentification" value="catalina"/>
<Property name="useSingleClientIdentification" value="true" />
</Service>
</ServiceGroup>
</WSBinding>
</Definition>
<?xml version="1.0" encoding="UTF-8"?>
<!- sample.dep
-->
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<WSDF>
<Import location="c:/salt/x.509/Sample.wsdf"></Import>
</WSDF>
<WSGateway>
<GWInstance id="INSTANCE1">
<Outbound>
…
</Outbound>
<Properties>
<Property name="defaultClientIdentification" value="melbourne"/>
</Properties>
</GWInstance>
</WSGateway>
<System>
<Certificate>
…
</Certificate>
</System>
</Deployment>
Tuxedo SECURITYが少なくとも"USER_AUTH"レベルで構成されている場合、このプロパティはX.509証明書選択にのみ影響があります。このプロパティは、ユーザーが独自のX.509証明書を所有していなくても、Webサービスにアクセスする際にデフォルトのクライアント識別を使用することを許可します。このオプションはデフォルトでは無効にされています。
次に、この匿名クライアント・アクセス・フィルタを使用可能にするかどうかを判定するためのマトリックス表を示します。
このフィルタを有効化するよう決定された場合、"defaultClientIdentification"を構成する必要があります。"defaultClientIdentification"が構成されていない場合、"wsloadcf"は失敗し、エラーを返します。
<?xml version="1.0" encoding="UTF-8" ?>
<!- Sample.wsdf
-->
<Definition …>
<WSBinding id="sample_Binding">
<SOAP>
<AccessingPoints>
…
</AccessingPoints>
</SOAP>
<Servicegroup id="SampleSrvGrp">
<Service name="GetData">
<Property name="defaultClientIdentification" value="catalina"/>
<Property name="allowAnonymousAccess" value="true" />
</Service>
</Servicegroup>
</WSBinding>
</Definition>
<?xml version="1.0" encoding="UTF-8"?>
<!- sample.dep
-->
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<WSDF>
<Import location="c:/salt/x.509/Sample.wsdf"></Import>
</WSDF>
<WSGateway>
<GWInstance id="INSTANCE1">
<Outbound>
…
</Outbound>
<Properties>
<Property name="defaultClientIdentification" value="melbourne"/>
<Property name="allowAnonymousAccess" value="false" />
</Properties>
</GWInstance>
</WSGateway>
<System>
<Certificate>
…
</Certificate>
</System>
</Deployment>
SALT構成ファイルのコンパイルとは、XMLバージョンSALTDEPLOYファイルから(SALTCONFIG)ファイルのバイナリ・バージョンを生成することです。構成ファイルをコンパイルするには、wsloadcfコマンドを実行します。wsloadcfはデプロイメント・ファイルを解析してバイナリ・ファイルをロードします。
wsloadcfはデプロイメント・ファイル、インポートされたWSDFファイルおよびデプロイメント・ファイルに参照したWS-Policyファイルを読み込み、各ファイルのXMLスキーマ形式によって構文をチェックします。また、必要に応じて、SALTCONFIGというバイナリ構成ファイルをロードします。SALTCONFIGおよび(必要に応じて) SALTOFFSET環境変数は、SALTCONFIGファイルを指し、(必要に応じて)情報を格納する場所にオフセットします。
SALT構成ファイルは、あらかじめ定義したXMLスキーマ・ファイルに従ってwsloadcfにより検証されます。SALTで必要なXMLスキーマ・ファイルは$TUXDIR/udataobj/saltディレクトリに配置されています。
オプション「-n」を指定すると、wsloadcfはバイナリ・バージョンのSALTCONFIGを生成せずに、検証の目的にのみ実行できます。
詳細は、『SALTリファレンス・ガイド』のwsloadcfリファレンスに関する項を参照してください。
SALT構成を設定およびコンパイルした後、Oracle Tuxedo UBBCONFIGファイルは、Oracle TuxedoアプリケーションにSALTコンポーネントが適用されるように更新する必要があります。表13には、SALTのUBBCONFIGファイルの構成タスクを示します。
SALTは、UBBCONFIGファイルに少なくとも1つのTMMETADATAサーバーを指定する必要があります。Tuxedoサービス定義にアクセスするスループットを増加するために、複数のTMMETADATAサーバーの指定も可能です。
リスト30には、Oracle 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"
......
| 注意: | 全体のOracle Tuxedoドメインに対してサービス・メタデータ・リポジトリ・ファイルを1つのみ保持することをお薦めします。これを確認するには、Oracle Tuxedoドメインで実行している複数のTMMETADATAサーバーが同じリポジトリ・ファイルを指す必要があります。 |
詳細は、Oracle Tuxedoドキュメントの Tuxedoサービス・メタデータ・リポジトリの管理に関する項を参照してください。
SALTDEPLOYファイルに定義されたGWWSインスタンスを起動するには、UBBCONFIGファイルの*SERVERSセクションでGWWSサーバーを指定する必要があります。1つまたは複数のGWWSサーバー・インスタンスを並行してUBBCONFIGファイルに定義できます。各GWWSサーバーは、Oracle Tuxedoドメイン内でオプション「-i」を使用して、一意のインスタンスIDに割り当てる必要があります。インスタンスIDは、XMLバージョンのSALTDEPLOYファイルおよび生成されたバイナリ・バージョンのSALTCONFIGファイルに存在する必要があります。
リスト31には、Oracle 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"
......
詳細は、Oracle SALTリファレンス・ガイドの「GWWS」を参照してください。
| 注: | UBBCONFIGファイルでは、GWWSサーバーが起動する前にTMMETADATAシステム・サーバーが確実に起動するよう設定してください。GWWSサーバーはTMMETADATAによって提供されるサービスを呼び出すため、TMMETADATAよりも後に起動する必要があります。 |
| 注意: | GWWSサーバーから呼び出される前にTMMETADATAが確実に起動するようにするため、UBBCONFIGファイルの*SERVERS定義内で、TMMETADATAを先に、GWWSを後に記述するか、SEQUENCEパラメータを使用します。 |
| 注意: | SALT構成情報は、SALTCONFIGファイルのバイナリを生成するために、wsloadcfであらかじめコンパイルされます。GWWSサーバーは起動時にSALTCONFIGファイルを読み取ります。SALTCONFIGファイル・エンティティを使用してSALTCONFIG環境変数を適切に設定してから、GWWSサーバーを起動してください。 |
| 注: | オプション「-c」はSALTの現在のバージョンでは非推奨になっています。SALT 1.1リリースにおいて、GWWSサーバーに対してSALT 1.1ファイルを指定ためにオプション「-c」を使用します。SALT 2.0では、GWWSサーバーは、起動時にSALTCONFIGファイルを読込みます。GWWSサーバーは、このオプションを指定して起動すると、このオプションは非推奨になっていることを示す警告メッセージが表示されます。指定されたファイルは任意のファイルで、GWWSサーバーによって読み込まれません。 |
SALT GWWSサーバーでOracle Tuxedoドメインを構成するとき、SALTアプリケーションの要件に応じて、UBBCONFIG ファイルに定義されたOracle Tuxedoシステム制限事項を設計および更新する必要があります。
| ヒント: | 適切なMAXSERVERS数を*RESOURCESセクションで定義します。 |
SALTでは、Oracle TuxedoドメインのTMMETADATAおよびGWWS内で次のシステム・サーバーを起動する必要があります。TMMETADATAおよびGWWSサーバー数は、MAXSERVERS値に指定する必要があります。
| ヒント: | 適切なMAXSERVICES数を*RESOURCESセクションで定義します。 |
GWWSサーバーは、発信方向で機能する場合、外部wsdl操作がOracle Tuxedoサービスでマップされ、GWWSサーバーを介して通知されます。すべてのGWWSサーバーによって通知されたサービス数は、MAXSERVICES値に指定する必要があります。
| ヒント: | 適切なMAXACCESSERS数を*RESOURCESセクションで定義します。 |
MAXACCESSERS 値は、このアプリケーションの特定のマシン上のOracle Tuxedo掲示板と同時に接続できるクライアントおよびサーバーのデフォルトの最大数を指定するために使用します。TMMETADATAおよびGWWSサーバー数、最大同時Webサービス・クライアントのリクエスト数は、MAXACCESSERS値に指定する必要があります。
| ヒント: | 適切なMAXWSCLIENTS数を*MACHINESセクションで定義します。 |
GWWSサーバーは着信方向で操作する場合、Webサービスの各クライアントはOracle Tuxedoシステムのワークステーション・クライアントとみなされます。したがって、GWWSサーバーをデプロイするマシンのUBBCONFIGファイルでは、MAXWSCLIENTSに適切な値を設定する必要があります。この値は共有されます。
SALTの証明書を設定する際には、セキュリティのパスワードを設定する必要があります。GWWSサーバーでは、SSLリンクレベル暗号化やWebサービス・セキュリティX.509トークンおよび署名機能を有効にするとき、証明書を設定する必要があります。証明書の秘密鍵のファイルを作成し、パスワードで暗号化する必要があります。
証明書に関連する機能を使用してGWWSサーバーが指定される場合、それらは秘密鍵ファイルを読み取り、パスワード・フレーズを使用してそれらを復号化するために必要です。各GWWSサーバーに対してパスワード・フレーズを構成するには、*SERVERSセクションにおける必要な各GWWSサーバー・エントリの下にキーワードSEC_PRINCIPAL_NAMEおよびSEC_PRINCIPAL_PASSVARを指定する必要があります。tmloadcfを使用してUBBCONFIGファイルをコンパイルする際には、管理者がパスワード・フレーズを入力する必要があり、これは秘密鍵ファイルを正しく復号化するために使用できます。
| 注意: | SALTデプロイメント・ファイルに秘密鍵ファイルを1つのみ指定できます。SALTデプロイメント・ファイルに定義されているすべてのGWWSサーバーについては、秘密鍵ファイルの復号化のため同じパスワードを提供する必要があります。 |
リスト32には、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"
......
詳細は、Oracle Tuxedo 12cR2ドキュメントの UBBCONFIG(5)に関する項を参照してください。
SALTのGWWSサーバーは、Webサービス・クライアントの有効性をチェックするためにOracle Tuxedo認証フレームワークに依存します。Oracle Tuxedoの従来のアプリケーションがすでに適用されている場合、Webサービス・クライアントは次のいずれかの方法でユーザー資格証明を送信する必要があります。
逆に、SALTに対してWebサービス・クライアントを認証する場合、Oracle TuxedoドメインでOracle Tuxedo認証を構成する必要があります。
詳細は、Oracle Tuxedo 12cR2ドキュメントの 認証の管理に関する項を参照してください。
発信HTTP基本認証username /passwordをマッピングするためにOracle Tuxedoクライアントuid / gidを取得するには、UBBCONFIGファイルでOracle Tuxedoセキュリティ・レベルをUSER_AUTH、ACLまたはMANDATORY_ACLとして構成する必要があります。
リスト33には、UBBCONFIGファイルでセキュリティレベルACLを定義するUBBCONFIGファイルのセグメントを示します。
*RESOURCES
IPCKEY ...
......
SECURITY ACL
......
MPモードのOracle Tuxedoドメイン内の複数のマシンで実行しているGWWSサーバーを設定するには、各Oracle 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サーバーを実行するには、次の手順に従います。
| 注意: | Oracle Tuxedoドメインに定義された複数のSALT 1.1構成ファイルがある場合、ステップ1から3に従って、複数のバイナリSALTCONFIGファイルを生成し、対応する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ファイルを手動で編集する必要があります。 |
リスト34に、指定された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ファイルおよびデプロイメント・ファイルを、リスト35およびリスト36にそれぞれ示します。
<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>
サービスの検索を有効にすると、サービスを提供するサーバーによってサービス規約情報が収集され、この情報が TMMETADATA(5)で実装された内部サービスに送信されます。通信のオーバーヘッドを軽減するため、同じサービス規約は1回のみ送信されます。
サービス規約は、TMMETADATA サーバーによって収集されたデータに基づいて生成されます。規約情報は、メタデータ・リポジトリに格納するか、テキスト・ファイルに出力しておいてtmloadreposでメタデータ・リポジトリにロードできます。SALTでは、tmscdコマンドを使用してサービス規約の実行時収集を管理できます。詳細は、『SALTコマンド・リファレンス・ガイド』のtmscdに関する項を参照してください。
生成されたサービス規約情報には、サービス名、リクエスト・バッファ情報、応答バッファ情報、およびエラー・バッファ情報(エラーがある場合のみ)が含まれます。TMMETADATAサーバーへの送信が失敗した場合、収集されたサービス規約情報は破棄されます。バッファ情報には、バッファ・タイプ、サブタイプ、およびFML/FML32のフィールド情報(name、type、subtype)が含まれます。
検索は、FML32バッファ内のすべての埋め込みバッファでサポートされます。FML/FML32フィールドが出現すると、検索によってメタデータ・リポジトリ内のcount/requiredcountのパターンが自動的に更新されます。フィールドの出現がパターンに影響することはありませんが、「requiredcount」で最小出現回数を指定できます。規約検索の期間全体での最大出現回数は「count」で指定します。
VIEW/VIEW32/X_C_TYPE/X_COMMONの場合は、ビュー名のみが検索されます。SALTでメタデータ・リポジトリを使用している場合は、ビュー名に基づいて詳しい説明を生成できます。
| 注意: | autodiscovery(表14を参照)を指定したパターンは比較されます。 |
| 注: | メタデータ・リポジトリ内に同じautodiscoveryパターンがすでに存在する場合は、新しい方のパターンが無視されます。 |
サポートされるのは、アプリケーションATMIサービス(ローカル、または/TDOMAINゲートウェイ経由でインポートされたもの)のみです。サービス規約検索では、以下のサービスはサポートされません。
| 注意: | 応答のないサービスは、メタデータ・リポジトリでは「oneway」サービスとしてマップされます。 |
サービスがtpreturn()のかわりに tpforward()を発行すると、そのサービスの応答バッファ情報が転送先のサービスの応答バッファ情報と同じになります。例:
収集されたサービス規約検索情報を、メタデータ・リポジトリに直接格納するかわりにファイルに書き出す場合、 TMMETADATA(5) -o<filename>オプションを使用し、tmloadreposを使用して、ファイルをメタデータ・リポジトリに手動でロードする必要があります。詳細は、Oracle Tuxedoコマンド・リファレンス・ガイドのtmloadreposに関する項を参照してください。
ファイルをメタデータ・リポジトリの代わりのストレージとして使用する場合、出力はtmloadreposに準拠したフォーマットになります。このファイルは、サービス・ヘッダー・セクションと、パラメータごとのパラメータ・セクションで構成されます。サービス・ヘッダーには、表14に示す項目が含まれます。「service」フィールドのフォーマットは、<TuxedoServiceName>+'_'+<SequenceNo>です。Oracle Tuxedoサービスに複数のパターンが認識された場合に名前の競合を避けるため、接尾辞 <SequenceNo>が使用されます。
| 注意: | <SequenceNo>は、メタデータ・リポジトリにすでに格納された最後の<SequenceNo>の番号から始まります。 |
サービス・パラメータには、表15に示す情報が含まれます。
入力: 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)
| 注: | これらの構成の変更は、SALTDEPLOY追加擬似スキーマおよびWSDF追加擬似スキーマの付録に要約されています。 |
| 注: | 追加情報は、 SALT相互運用性ガイドを参照してください。 |
Oracle Tuxedoまたは/DomainのTLogファイルと同様に、トランザクション・ログ(TLogDevice)要素を使用して、GWWSシステム・サーバーを構成する必要があります。リスト37に示すように、TLOGDevice要素が、SALTCONFIGソース・ファイル(SALTDEPLOY)に追加されます。
TLOGName要素も追加して、GWWSインスタンスで同じTLogデバイスを共有できます。
TLogデバイスは、Webサービス・ゲートウェイ・インスタンスごとに1つのみ設定できます(つまり、トランザクション・ログ要素は/Deployment/WSGateway/GWInstanceの子要素です)。
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<WSDF>
...
</WSDF>
<WSGateway>
<GWInstance id="GW1">
<TLogDevice location="/app/GWTLOG"/>
<TLogName id="GW1TLOG"/>
...
</GWInstance>
</WSGateway>
...
</Deployment>
Oracle Tuxedoベースのサービスは、コーディネータを使用してDurable 2PCプロトコルに登録されます。
Oracle Tuxedoがコーディネータ(発信方向)である場合、GWWSシステム・サーバーでは、Volatile 2PCまたはDurable 2PCの登録リクエストを許可し、それに応じてこれらを処理します。
図2では、典型的なWS-ATコンテキスト・サービスの呼出しのアプリケーションとプロトコルのフローを示します。
SALT GWWSゲートウェイの構成手順および実行時の動作を、(図2に示すようなOracle Tuxedoドメインのロールに応じて)次の項で説明します。
Webサービスとして公開されたOracle Tuxedoサービスは、着信WS-ATトランザクション・リクエストに関連付けられたローカル・トランザクションを開始するために、トランザクション・ログ・ファイルを作成しGWWSデプロイ構成ファイルにこれを追加する以外の固有の構成を必要としません。
トランザクションをOracle Tuxedoドメインに伝播できることを確認するためには、次の手順を実行します。
CoordinationContext要素を含む着信コールは、Oracle Tuxedoグローバル・トランザクションを作成します。Oracle Tuxedoクライアントが外部WebサービスへのOracle Tuxedoグローバル・トランザクションを伝播するために、次の手順を実行します。
CoordinationContext要素が作成され、アプリケーション・リクエストとともにSOAPヘッダーに送信されます。RegistrationService要素のCoordinationContext要素とともに送信され、トランザクションで使用します。プロトコル交換(準備/コミットまたはロールバックなど)とともに、この手順は両側で透過的です。 リスト1に示すように、MaxTran要素を使用して、内部トランザクション表のサイズを構成できます。デフォルトはMAXGTTです。
| 注意: | MaxTran値は省略可能です。構成された値がMAXGTTより大きい場合、これは無視され、かわりにMAXGTTが使用されます。 |
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<WSDF>
...
</WSDF>
<WSGateway>
<GWInstance id="GW1">
...
<MaxTran value="500"/>
...
</GWInstance>
</WSGateway>
...
</Deployment>
WS-ATは、リクエストが操作呼出しを原子性トランザクションの一部として作成する必要または可能性があるかどうかを示すことができるポリシー・アサーションを定義します。
policy.xmlファイルには、WS-ATポリシー要素が含まれます。リスト2に示すように、WS-ATは、ATAssertion要素をOptional属性に定義する場合、 /wsat:ATAssertion/@wsp:Optional="true"となります。
<?xml version="1.0"?>
<wsp:Policy wsp:Name="TransactionalServicePolicy"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsat="http://docs.oasis-open.org/ws-tx/wsat/2006/06">
<wsat:ATAssertion wsp:Optional="true"/>
</wsp:Policy>
| 注: | 外部WSDLを適切にインポートするために、wsdlcvtコマンドを変更して、ATAssertion要素を含むpolicy.xmlファイルを生成します(WSDL内に存在する場合)。発信リクエストでは、ATAssertion要素を含むpolicy.xmlファイルを作成し、SALTDEPLOYソースで適切に示す必要があります。 |
着信トランザクションの場合、実行時に特定の動作変更は行われません。クライアントのWSDLの消費は、構成された値に基づいて決定し、通常の場合のように、実行時の動作が続きます。
ATAssertionで"Optional=true"が構成されない場合、トランザクションで呼出しを行う必要があります。対応するXAトランザクションが存在しない場合、WS-TXトランザクションは開始されますが、Oracle Tuxedo XAトランザクションには関連付けられません。XAトランザクションが存在する場合、動作の変更はありません。ATAssertionで"Optional=true"が構成されると、対応するOracle Tuxedo XAトランザクションが呼出しのコンテキストに存在する場合のみ、発信トランザクション・コンテキストがリクエストされます。ATAssertionが構成されない場合、対応するサービス呼出しはトランザクションの外側で行われます。Oracle Tuxedo XAトランザクションのコンテキストで外部Webサービスへの呼出しが行われる場合、Webサービス呼出しはトランザクションを伝播しません。 これにより、グローバル・トランザクションからあるWebサービス呼出しを除外でき、ほとんどの既存のWebサービス呼出し(WS-TXをサポートしていない)のデフォルトを表します。
WSDLの生成が拡張されて、対応するサービスのポリシー・ファイルに構成されたアサーションに対応するATAssertion要素が生成されます。
発信リクエストでは、WSDL変換ツールであるwsdlcvtが、ATAssertion要素を含むpolicy.xmlファイルを生成します(処理されたWSDL内に存在する場合)。policy.xmlファイルの場所を、SALTDEPLOYソースに適切に構成する必要があります。
SALT構成ツールを使用すると、構成の表示および変更を実行できます。Oracle Tuxedoサービスは、構成ファイルを編集せずにWebサービスとして公開できます。
| 注: | Internet Explorer 9では、デフォルトでWebページがCSS情報なしで表示されます。このページを正常に表示するには、Internet Explorer 8ドキュメント互換性モードを使用する必要があります。次の手順を実行します。 |
Web管理は、デフォルトでは無効です。管理機能を有効にするには、UBBCONFIGで次のように-aオプションを使用してGWWSサーバーを構成する必要があります。
<scheme>は、「http」または「https」です。「https」を使用する場合、SSLでアプリケーションWebサービスをセキュア化する場合と同様に、秘密鍵と証明書を追加することでSSL機能に対応するようにGWWSを構成する必要があります。
<host>は、エンドポイントをリスニングしている管理URLの名前またはIPアドレスです。
<port>は、エンドポイントをリスニングしている管理URLのポート値です。
Web管理コンソールにアクセスするには、次のURLを使用します。
<scheme>://<host>:<port>/admin
例: https://server.company.com:3333/admin
カスタムHTTPヘッダーにより、Oracle TuxedoとHTTPヘッダーを使用するサーバーまたはクライアントが相互運用を行いデータを転送できるようになります。リスト3に示すように、このオプションを有効化しアクティブにするには、enableCustomHTTPHeadersプロパティを使用する必要があります。
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<WSDF>
...
</WSDF>
<WSGateway>
<GWInstance id="GW1">
...
<Inbound>
...
</Inbound>
<Outbound>
...
</Outbound>
<Properties>
<Property name="enableCustomHTTPHeaders" value="true">
</Properties>
...
RESTモードはデフォルトで無効化されています。RESTモードを有効にするには、SALTDEPLOYでそのようにGWWSサーバーを構成する必要があります。
| 注: | SALT GWWSでは、常に'<?xml version="1.0" encoding="UTF-8"?>'プロローグ付きのXMLヘッダーが生成されます。これは現在制限されており、HTTPレベルで処理されるとき、エンコーディング処理には影響しません。 |
/Deployment/WSGateway/GWInstance/Inbound/REST/Network
この要素には、次に示すように、httpまたはhttpsのRESTリスニング・エンドポイントを指定するための2つの属性が含まれています。
<HTTP>
<Network http="host:port" https="host:port"/>
...
</HTTP>
1つの<Network>要素のみが許可されます。httpおよびhttps要素はオプションですが、少なくとも1つを指定する必要があります。httpおよびhttps属性は次のように構成されます。
すべてのRESTリクエストは、同じ<host>:<port> の組合せで実行されます。つまり、ゲートウェイごと、プロトコル(httpおよびhttps)ごとにそのような組合せを2つ以上使用することはできません。
サービスの呼出しは、URL作成の基本として、前述のパターンを使用します。例:
デフォルトでは、RESTを使用して通知するようにサービスが明示的および個別に指定されていない場合、呼出し可能にはなりません。サービスを参照してください。
前述のように、RESTがコマンド行スイッチを使用して構成されている場合、アクセス可能なサービスを指定するために、要素をSALTDEPLOYする必要があります。
Oracle Tuxedoは、RESTパラダイムを活用したCRUD (作成、読取り、更新、削除)マッピングを使用して公開されます。たとえば、表1に示すように、bankAccountという名前のRESTサービスにはOracle TuxedoへのHTTPメソッドのマッピングがあります。
URL: http://host:1234/bankAccount?account=1234
GET /bankAccount?account=1234 HTTP/1.0
Content-Type: application/json
{{'account':1234},{'balance':1000}...}
<Inbound>にゼロまたは1つの<RESTHTTP>要素があり、<HTTPREST>. <Service>にある1つ以上の<Service>要素には、次の属性が含まれます。
<Service>ごとに少なくとも1つ(最大4、サポートされるメソッドごとに1つ)の<Method>要素があります。<Method>要素には次の属性が含まれます。
マップされるメソッドの名前(GET、POST、DELETE、PUT)の値。これ以外の値では、wsloadcf時間に構成エラーになります。
インタフェースとして使用するTuxedoメタデータ・リポジトリ・サービスの名前。この値はオプションです。構成ツールのテスト・ページでテスト・コードを生成する際に使用するバッファタイプやパラメータ・リストの指定に使用します。値は、TuxedoサービスをRESTfulサービスとして公開する際に構成コンソールによって生成されます。
Oracle Tuxedoバッファ・タイプ/オプションで入力の変換に使用されるサブタイプ。値は既存のすべてのOracle Tuxedoバッファ・タイプと同じです。VIEW/VIEW32バッファ・タイプの場合は、注釈{VIEW|VIEW32}/<Subtype>を使用してサブタイプの概念が伝達されます。例: 'VIEW32/customer'。
詳細は、『SALTプログラミング・ガイド』のデータ型のマッピングとメッセージの変換サービスに関する項を参照してください。
Oracle Tuxedoサービスは動的に通知できるため、サービスがすでに通知されているかどうかのチェックはありません。示したように、サービスがこのセクションにリストされていない場合、RESTを使用して呼び出すことはできません。
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<WSDF>
...
</WSDF>
<WSGateway>
<GWInstance id="GW1">
<Inbound>
<Binding ref="bankapp:bankapp_binding">
<Endpoint use="http1"/>
<Endpoint use="https1" />
</Binding>
<RESTHTTP>
<Network http="host:1234" https="host:1235"/>
<Service name="bankAccount">
<Method name="GET"
reposservice="ACCOUNT_INFO"
service="ACCOUNT_INFO"
inputbuffer="FML32"/>
<Method name="POST"
reposservice="OPEN_ACCOUNT"
service="OPEN_ACCOUNT"
inputbuffer="FML32"/>
<Method name="DELETE"
reposservice="CLOSE_ACCOUNT"
service="CLOSE_ACCOUNT"
inputbuffer="FML32"/>
<Method name="PUT"
reposservice="UPDATE_ACCOUNT"
service="UPDATE_ACCOUNT"
inputbuffer="FML32"/>
</Service>
</RESTHTTP>
</Inbound>
...
SALTDEPLOYに/Deployment/WSGateway/GWInstance/Oubound/HTTP/Serviceの要素が追加されます。
<Outbound>にゼロまたは1つの<HTTP>要素があり、<HTTP>. <Service>にある1つ以上の<Service>要素には、次の属性が含まれます。
| 注: | TuxedoサービスはのURL + HTTPメソッド + HTTPマッピング(JSONまたはXML)の組合せでマップされる必要があります。Tuxedo側にはTuxedoサービスの注釈のみがあるため、HTTP/REST着信とは異なります。 |
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<WSDF>
...
</WSDF>
<WSGateway>
<GWInstance id="GW1">
...
<Outbound>
<Binding ref="bankapp:bankapp_binding">
<Endpoint use="http1"/>
<Endpoint use="https1" />
</Binding>
<HTTP>
<Service name="BANK_GET"
method="GET"
address="http://some.org/bankAccount"
content-type="JSON"
outputbuffer="FML32"/>
<Service name="HTTPSvcGet"
method="GET"
address="http://some.org/some/path"
content-type="JSON"
outputbuffer="FML32"/>
<Service name="HTTPSvcPost"
method="POST"
address="http://some.org/some/path"
content-type="JSON"
outputbuffer="FML32"/>
</HTTP>
</Outbound>
...
SALT MIBインタフェースは、tpcall(".wm" + GWWSID,...)を使用して呼び出します。次の定義済みクラスが用意されています。
$ ud32 < reload.ud32
with reload.ud32 containing:
SRVCNM .wmGW1
TA_OPERATION GET
TA_CLASS T_WSRELOAD
".wmGW1" above is this particular instance and must match the gateway id as specified in the UBBCONFIG file in the "-i" option of the GWWS system server.
Example of a reply:
RTN pkt(1) is :
TA_ERROR 0
TA_MORE 0
TA_OCCURS 1
TA_CLASS T_WSRELOAD
TA_STATUS Config reloaded
$ ud32 < saltgw.ud32
SENT pkt(1) is :
SRVCNM .wmgw1
TA_CLASS T_SALTGW
TA_OPERATION GET
RTN pkt(1) is :
TA_ERROR 0
TA_MORE 0
TA_OCCURS 1
TA_INSTANCEID gw1
TA_TLOGDEVICE
TA_TLOGNAME
TA_WSATENDPOINT
TA_MAXTRAN
TA_SOCKSADDRLIST
TA_MAXCONTENTLEN 0
TA_THREADPOOLSIZE 16
TA_TIMEOUT 300
TA_MAXBACKLOG 20
TA_ENABLEMULTIENC true
TA_ENABLESOAPVAL false
TA_PRIVATEKEY
TA_VERIFYCLIENT
TA_TRUSTEDCERT
TA_CERTPATH
TA_PLUGINLIBRARIES
TA_PLUGINPARAMS
TA_RESTHTTPADDRESS localhost:1111
TA_RESTHTTPSADDRESS
このクラスをGET操作で呼び出すと、SALTCONFIGファイルがリロードされます。これはGWWSを再起動することと同じですが、実際にはシャットダウンせずにリブートします。
T_WSGWクラスは、スレッド数、TLOGデバイスおよび名前などのゲートウェイ・インスタンスの属性を表します。
TA_INSTANCEID
TA_TLOGDEVICE
TA_TLOGNAME
TA_WSATENDPOINT
TA_MAXTRAN
TA_SOCKSADDRLIST
TA_MAXCONTENTLENGTH
TA_THREADPOOLSIZE
TA_NWTIMEOUT
TA_MAXBACKLOG
TA_ENABLEMULTIENC
TA_ENABLESOAPVAL
TA_PRIVATEKEY
TA_VERIFYCLIENT
TA_TRUSTEDCERT
TA_CERTPATH
TA_PLUGINLIBRARIES
TA_PLUGINPARAMS
TA_WS_REQREPDONE
TA_WS_REQREPFAIL
TA_WS_ONEWAYDONE
TA_WS_ONEWAYFAIL
TA_WS_OUTBOUNDDONE
TA_WS_OUTBOUNDFAIL
TA_WS_OUTBOUND_ONEWAYDONE
TA_WS_OUTBOUND_ONEWAYFAIL
TA_WS_INBOUNTIME
TA_WS_OUTBOUNTIME
TA_WS_THREADS
TA_WS_TOTALPENDING
TA_RESTINBOUNDDONE
TA_RESTINBOUNDFAIL
TA_RESTINBOUNDTIME
TA_RESTOUTBOUNDDONE
TA_RESTOUTBOUNDFAIL
TA_RESTOUTBOUNDTIME
T_WSWEBSERVICEクラスはSOAP Webサービスの構成属性を表します。WSDFNAMEによって識別される各Webサービスには、バインディングの1つ以上のインスタンスを含めることができます。これは、このクラスの1つ以上のインスタンスとして返されます。例: 'ACCOUNT'という名前のWebサービスの場合:
TA_WSDFNAME
TA_BINDINGID
TA_INSTANCEID
TA_WSDFDIRECTION
TA_ENDPOINTIDLIST
TA_WSAENDPOINT (発信のみ)
TA_REALM (発信のみ)
T_WSBINDINGクラスはSOAPバインドの構成属性を表します。
必須キー・フィールド: TA_BINDINGIDおよびTA_WSDFNAME
TA_BINDINGID
TA_WSDFNAME
TA_SOAPVERSION
TA_SOAPSTYLE
TA_SOAPENCODING
TA_POLICIES
TA_ENDPOINTS
T_WSOPERATIONクラスはSOAP操作の構成属性を表します。
必須キー・フィールド: TA_BINDINGIDおよびTA_WSDFNAME。
TA_BINDINGID
TA_SERVICENAME
TA_WSDFNAME
TA_TUXEDOREF
TA_NAMESPACE
TA_SOAPACTION
TA_POLICIES
TA_ASYNCTIMEOUT
TA_DISABLEWSA
TA_INPUTMSGNAME
TA_INPUTWSAACTION
TA_INPUTMSGHANDLER
TA_OUTPUTMSGNAME
TA_OUTPUTWSAACTION
TA_OUTPUTMSGHANDLER
TA_FAULTMSGNAME
TA_FAULTWSAACTION
TA_FAULTMSGHANDLER
TA_WS_REQREPDONE
TA_WS_REQREPFAIL
TA_WS_ONEWAYDONE
TA_WS_ONEWAYFAIL
TA_WS_INBOUNTIME
TA_WS_OUTBOUNDDONE
TA_WS_OUTBOUNDFAIL
TA_WS_OUTBOUND_ONEWAYDONE
TA_WS_OUTBOUND_ONEWAYFAIL
TA_WS_OUTBOUNTIME
T_WSHTTPSERVICEクラスはSALT RESTサービスの構成属性を表します。
TA_RESTSVCNAME
TA_RESTPOSTSERVICE
TA_RESTPUTSERVICE
TA_RESTGETSERVICE
TA_RESTDELETESERVICE
TA_RESTPOSTINBUF
TA_RESTPUTINBUF
TA_RESTGETINBUF
TA_RESTDELETEINBUF
TA_RESTPOSTTUXREF
TA_RESTPUTTUXREF
TA_RESTGETTUXREF
TA_RESTDELETETUXREF
TA_RESTDONE
TA_RESTFAIL
TA_RESTPENDING
TA_RESTTIME
T_WSTRANSACTIONクラスはWS-TXトランザクションの実行時属性を表します。
TA_INSTANCEID
TA_WS_TRANPROCESSID
TA_WS_TRANSVCNAME
TA_WS_TRANGTRID
TA_WS_TRANCOORCONTEXT
TA_STATE
GET: "{ACTive | COMcalled | REAdy | HEUristic | HEuristic Hazard }" GET操作は、選択したT_WSTRANSACTIONオブジェクトの実行時情報を取得します。次に示す状態は、GETリクエストに応えて返されるTA_STATEの意味を示します。
TA_WS_TRANTIMESTAMP
TA_WS_BRANCHES
| 注: | SALT構成ツールをOracle Tuxedoセキュリティに統合するために、ユーザー側でSSL/TLSを使用してユーザー名とパスワードを保護することをお薦めします。 |
ACLまたはMANDATORY_ACLセキュリティを必要とするOracle Tuxedoアプリケーション・ドメインの場合、Oracle Tuxedoのセキュリティ・データ・ファイルでコンソール・サービスを構成する必要があります。この付加情報は、構成ツール・サービスに対するOracle Tuxedoアクセス制御に使用されます。デフォルトの構成ツール・サービス名は「"SALTWEBCONSOLE"」ですが、GWWSオプション"-C <CONSOLE SERVICE NAME>"を使用して変更できます。例:
http://server.company.com:3333/admin -C CONSOLE"
この指示により、GWWSは、アクセス制御のサービス名として「CONSOLE」を使用します。
| 注: | また、「tpacladd」を使用してこのWebコンソール・サービスをセキュリティ・データ・ファイルに追加する必要があります。例: $ tpacladd -g 1000 CONSOLE |
| 注: | これにより、CONSOLE がセキュリティ・データ・ファイルにOracle Tuxedo SERVICEとして追加され、アクセスが、グループID 1000のグループに属するユーザーのみに制限されます。 |
UBBCONFIGファイルの「*RESOURCES」セクションにSECURITYを設定しないか、値を「NONE」に設定した場合、SALT構成ツールにアクセスするときにセキュリティは使用されません。ツールのURLを知っている人は誰でもアクセスできます。リスト8に、UBBCONFIGファイルの「*RESOURCES」セクションの例を示します。
*RESOURCES
IPCKEY 15301
DOMAIN mydomain
MASTER machine1
MAXACCESSERS 50
MAXSERVERS 10
MAXSERVICES 40
MODEL SHM
LDBAL N
「*RESOURCES」セクションのSECURITYに値APP_PWを設定すると、Oracle Tuxedoアプリケーション・パスワード・セキュリティが有効になります。SALT構成ツールにアクセスするユーザーは、このパスワードの提示を要求されます。正しく提示できなかった場合、アクセスは拒否されます。リスト9に、UBBCONFIGファイルの「*RESOURCES」セクションの例を示します。
*RESOURCES
IPCKEY 15301
DOMAIN mydomain
MASTER machine1
MAXACCESSERS 50
MAXSERVERS 10
MAXSERVICES 40
MODEL SHM
LDBAL N
SECURITY APP_PW
「*RESOURCES」セクションのSECURITYに値USER_AUTHを設定すると、Oracle Tuxedoユーザー認証セキュリティが有効になります。SALT構成ツールにアクセスするユーザーは、有効なOracle Tuxedoユーザー名とパスワードの提示を要求されます。正しく提示できなかった場合、アクセスは拒否されます。リスト10に、UBBCONFIGファイルの「*RESOURCES」セクションの例を示します。
*RESOURCES
IPCKEY 15301
DOMAIN mydomain
MASTER machine1
MAXACCESSERS 50
MAXSERVERS 10
MAXSERVICES 40
MODEL SHM
LDBAL N
SECURITY USER_AUTH
「tpusradd」コマンドを使用してユーザーを追加できます。次の例では、Oracle Tuxedoアプリケーション・ドメインのグループIDが1000のグループにユーザー「tom」が追加されます。
$ tpusradd -u 2503 -g 1000 tom
「*RESOURCES」セクションのSECURITYに値ACLを設定すると、Oracle Tuxedoアクセス制御リスト・セキュリティが有効になります。SALT構成ツールにアクセスするユーザーは、Webコンソールへのアクセスを許可されたグループに属する有効なOracle Tuxedoユーザー名とパスワードの提示を要求されます。正しく提示できなかった場合、アクセスは拒否されます。リスト11に、UBBCONFIGファイルの「*RESOURCES」セクションの例を示します。
*RESOURCES
IPCKEY 15301
DOMAIN mydomain
MASTER machine1
MAXACCESSERS 50
MAXSERVERS 10
MAXSERVICES 40
MODEL SHM
LDBAL N
SECURITY ACL
「tpacladd」コマンドを使用すると、構成ツールへのアクセス制御を追加できます。次の例では、Oracle Tuxedoアプリケーション・ドメインのアクセス制御リストに構成ツール・サービス「SALTWEBCONSOLE」が追加されます。
$ tpacladd -g 1000 SALTWEBCONSOLE
サービスがOracle Tuxedoアクセス制御セキュリティ・データ・ファイルに追加されていない場合、有効なOracle Tuxedoユーザー名とパスワードを持つあらゆるユーザーがSALT Webコンソールにアクセスできます。
「*RESOURCES」セクションのSECURITYに値MANDATORY_ACLを設定すると、Oracle Tuxedoアクセス制御リスト・セキュリティが有効になります。SALT構成ツールにアクセスするユーザーは、構成ツールへのアクセスを許可されたグループに属する有効なOracle Tuxedoユーザー名とパスワードの提示を要求されます。正しく提示できなかった場合、アクセスは拒否されます。リスト12に、UBBCONFIGファイルの「*RESOURCES」セクションの例を示します。
*RESOURCES
IPCKEY 15301
DOMAIN mydomain
MASTER machine1
MAXACCESSERS 50
MAXSERVERS 10
MAXSERVICES 40
MODEL SHM
LDBAL N
SECURITY MANDATORY_ACL
「tpacladd」コマンドを使用すると、構成ツールへのアクセス制御を追加できます。次の例では、Tuxedoアプリケーション・ドメインのアクセス制御リストに構成ツール・サービス「SALTWEBCONSOLE」が追加されます。
$ tpacladd -g 1000 SALTWEBCONSOLE
サービスがOracle Tuxedoアクセス制御セキュリティ・データ・ファイルに追加されていない場合、SALT Webコンソールにアクセスできません。
  
|