SALTのOracle Tuxedoサービス・メタデータ・リポジトリの使用
SALTでは、
Oracle Tuxedoサービス・メタデータ・リポジトリを利用して、Oracle Tuxedoの従来のサービスとSALTプロキシ・サービスの両方のサービス契約情報を定義します。リストされたすべてのOracle Tuxedoサービスのサービス規約情報を、ローカルOracle Tuxedoドメインによって提供されるOracle Tuxedoサービス・メタデータ・リポジトリ・システム・サービスにアクセスして取得します。通常は、次に示すように、SALTから
TMMETADATAシステムを呼び出します。
SALTはOracle Tuxedoサービス・メタデータ・リポジトリを呼び出し、適切な時間に必要なOracle Tuxedoサービス定義を取得します。
SALTはOracle Tuxedoサービス・メタデータ・リポジトリを呼び出し、必要なOracle Tuxedoサービス定義を取得して、それをWSDL記述に変換します。
次のトピックでは、SALT特有のOracle Tuxedoサービス・メタデータ・リポジトリ・キーワードとパラメータの使用について説明します。
表1では、SALTで使用および解釈されるOracle Tuxedoサービス・メタデータ・リポジトリのサービス・レベル・キーワードを示します。
|
注意:
|
リストされていないメタデータ・リポジトリのサービスレベル・キーワードは、SALTとは関係性がなく、SALTコンポーネントがOracle Tuxedoサービス・メタデータ・リポジトリをロードするときに無視されます。 |
表1
SALTにおけるOracle Tuxedoサービス・メタデータ・リポジトリのサービス・レベル・キーワードの使用
|
|
|
|
|
サービスの一意のキー値。この値は、SALT WSDFファイルで参照されます。 ネイティブなOracle Tuxedoサービスの場合は、この値をOracle Tuxedoで通知されているサービス名と同じ値にすることも、Oracle Tuxedoで通知されている実際のサービス名とは異なる別名と同じ値にすることもできます。 SALTプロキシ・サービスの場合、通常はこの値をWebサービスのオペレーション・ローカル名にする。 |
|
|
サービス・モード(たとえば、ネイティブOracle TuxedoサービスやOracle SALTプロキシ・サービス)を決定します。 ネイティブOracle Tuxedoサービスを表します。 SALTプロキシ・サービス(たとえば、wsdl:operationを使用して変換されたサービス定義)を表します。 ネイティブOracle Tuxedoサービスを定義するには、 「webservice」を使用しません。この値は、常に外部Webサービスから変換されたサービスを定義するために使用されます。 |
|
|
Oracle Tuxedoで公開されている実際のサービス名。値を指定しない場合は、 serviceキーワードの値と同じと見なされます。 ネイティブなOracle Tuxedoサービスの場合は、このキーワードを使用して定義されたOracle TuxedoサービスをSALTから呼び出します。 SALTプロキシ・サービスの場合は、GWWSサーバーがこのキーワード値を使用してサービス名を公開する。 |
|
|
指定したOracle Tuxedoサービスに対するサービス・メッセージ交換パターンを決定します。 次の値によって、該当する種類のOracle TuxedoサービスとWebサービス・メッセージ交換パターン(MEP)とのマッピング・ルールを指定します。 |
|
|
サービスの入力バッファ(リクエスト・バッファ),の型を指定します。 ネイティブなOracle Tuxedoサービスの場合は、任意のOracle Tuxedo型付きバッファにすることができます。Oracle Tuxedoでバッファ型として予約されている値は次のとおりです。 STRING、CARRAY、XML、MBSTRING、VIEW、VIEW32、FML、FML32、X_C_TYPE、X_COMMON、X_OCTET、NULL (入力バッファは空)
|
注意:
|
値の大文字、小文字は区別されます。 inbufで前述以外のバッファ型を指定した場合、そのバッファはカスタム・バッファ型として扱われます。 |
SALTプロキシ・サービスの場合は、この値を常に FML32にします。 |
|
|
サービスの出力バッファ( TPSUCCESSとのレスポンス・バッファ)の型を指定します。 ネイティブなOracle Tuxedoサービスの場合は、任意のOracle Tuxedo型付きバッファにすることができます。Oracle Tuxedoでバッファ型として予約されている値は次のとおりです。 STRING、CARRAY、XML、MBSTRING、VIEW、VIEW32、FML、FML32、X_C_TYPE、X_COMMON、X_OCTET、NULL (入力バッファは空)
|
注意:
|
値の大文字、小文字は区別されます。 outbufで前述以外のバッファ型を指定した場合、そのバッファはカスタム・バッファ型として扱われます。 |
SALTプロキシ・サービスの場合は、この値を常に FML32にします。 |
|
|
サービスのエラー・バッファ( TPFAILとのレスポンス・バッファ)の型を指定します。 ネイティブなOracle Tuxedoサービスの場合は、任意のOracle Tuxedo型付きバッファにすることができます。Oracle Tuxedoでバッファ型として予約されている値は次のとおりです。 STRING、CARRAY、XML、MBSTRING、VIEW、VIEW32、FML、FML32、X_C_TYPE、X_COMMON、X_OCTET、NULL (入力バッファは空)。
|
注意:
|
値の大文字、小文字は区別されます。 errbufで前述以外のバッファ型を指定した場合、そのバッファはカスタム・バッファ型として扱われます。 |
SALTプロキシ・サービスの場合は、この値を常に FML32にします。 |
|
|
サービスにおいて以下の入力バッファ型に対して使用されるビューの名前を指定します。 VIEW、VIEW32、X_C_TYPE、またはX_COMMON
SALTでは、デフォルトの inview設定をそのまま使用するのではなく、ビューの名前を指定する必要があります。
|
注意:
|
このキーワードは、ネイティブなOracle Tuxedoサービス専用です。 |
|
|
|
サービスにおいて以下の出力バッファ型に対して使用されるビューの名前を指定します。 VIEW、VIEW32、X_C_TYPE、またはX_COMMON
SALTでは、デフォルトの outview設定をそのまま使用するのではなく、ビューの名前を指定する必要があります。
|
注意:
|
このキーワードは、ネイティブなOracle Tuxedoサービス専用です。 |
|
|
|
サービスにおいて以下のエラー・バッファ型に対して使用されるビューの名前を指定します。 VIEW、VIEW32、X_C_TYPE、またはX_COMMON
SALTでは、デフォルトの errview設定をそのまま使用するのではなく、ビューの名前を指定する必要があります。
|
注意:
|
このキーワードは、ネイティブなOracle Tuxedoサービス専用です。 |
|
|
|
サービス入力バッファに関連付ける外部XML Schema要素を指定します。この値を指定すると、外部スキーマが生成済のWSDLに組み込まれ、サービス入力バッファのデフォルトのデータ型マッピング・ルールが置き換えられます。
|
注意:
|
このキーワードは、ネイティブなOracle Tuxedoサービス専用です。 |
|
|
|
サービス出力バッファに関連付ける外部XML Schema要素を指定します。この値を指定すると、外部スキーマが生成済のWSDLに組み込まれ、サービス出力バッファのデフォルトのデータ型マッピング・ルールが置き換えられます。
|
注意:
|
このキーワードは、ネイティブなOracle Tuxedoサービス専用です。 |
|
|
|
サービス・エラー・バッファに関連付ける外部XML Schema要素を指定します。この値を指定すると、外部スキーマが生成済のWSDLに組み込まれ、サービス・エラー・バッファのデフォルトのデータ型マッピング・ルールが置き換えられます。
|
注意:
|
このキーワードは、ネイティブなOracle Tuxedoサービス専用です。 |
|
|
|
Oracle Tuxedo RECORD型付きバッファでは、COBOLコピーブック情報を記述できます。 |
|
|
サービスで入力バッファ型 RECORDに使用するレコード名を指定します。Oracle SALTでは、デフォルトのinrecord設定をそのまま使用するのではなく、レコード名を指定する必要があります。このキーワードはネイティブなTuxedoサービス専用。 |
|
|
サービスで出力バッファ型 RECORDに使用するレコード名を指定します。Oracle SALTでは、デフォルトのoutrecord設定をそのまま使用するのではなく、レコード名を指定する必要があります。このキーワードはネイティブなTuxedoサービス専用。 |
|
|
サービスでエラー・バッファ型 RECORDに使用するレコード名を指定します。Oracle SALTでは、デフォルトのerrrecord設定をそのまま使用するのではなく、レコード名を指定する必要があります。 このキーワードはネイティブなTuxedoサービス専用。 |
Oracle Tuxedoサービス・メタデータ・リポジトリでは、パラメータはOracle Tuxedoサービスの型付きバッファ内にカプセル化されたサブ要素として解釈されます。パラメータごとに、データ型、バッファ内の出現回数、サイズ制限、その他のOracle Tuxedoに固有の制限を設定できます。次に注意してください。
|
•
|
VIEW、 VIEW32、X_C_TYPEまたは X_COMMON型付きバッファ
|
バッファの個々のパラメータが
VIEW/VIEW32構造のメンバー1つを表します。
個々のバッファ・パラメータが、バッファ内に存在する可能性のある
FML/FML32フィールド要素を表します。
|
•
|
STRING、 CARRAY、 XML、 MBSTRINGおよび X_OCTET型付きバッファ
|
これらのバッファは、Oracle Tuxedoによって一様に扱われます。バッファに対して最大で1つのパラメータを設定することが認められており、制約(バッファ・サイズのしきい値など)を定義できます。
パラメータを使用してバッファ型の詳細について説明できます。
|
•
|
VIEW32およびFML32バッファの埋込みをサポートするFML32型付きバッファ
|
この機能が埋め込みパラメータによってサポートされます。
|
•
|
VIEW32バッファの埋込みをサポートするView32型付きバッファ
|
この機能が埋め込みパラメータによってサポートされます。
表2では、SALTで使用および解釈されるOracle Tuxedoサービス・メタデータ・リポジトリのパラメータ・レベル・キーワードを示します。
|
注意:
|
リストされていないメタデータ・リポジトリのパラメータレベル・キーワードは、SALTとは関係性がなく、SALTコンポーネントがOracle Tuxedoサービス・メタデータ・リポジトリをロードするときに無視されます。 |
表2
SALTにおけるOracle Tuxedoサービス・メタデータ・リポジトリのパラメータレベル・キーワードの使用
|
|
|
|
|
|
•
|
VIEW、 VIEW32、 X_C_TYPEまたは X_COMMON
|
ビュー構造のメンバー名を paramキーワードで指定します。 FML/FML32フィールド名を paramキーワードで指定します。
|
•
|
STRING、 CARRAY、 XML、 MBSTRINGまたは X_OCTET
|
このパラメータの定義はSALTにより無視されます。 |
|
|
|
注意:
|
SALTでは、 dec_tおよび ptrデータ型はサポートされていません。 |
|
|
|
パラメータ型が view32の場合、ビュー構造の名前を指定します。その他すべての型のパラメータについて、この値は無視されます。
|
注意:
|
SALTでこの値が必要となるのは、パラメータ型が view32の場合です。 |
このキーワードは、ネイティブなOracle Tuxedoサービス専用です。 |
|
|
一般的な定義をこのパラメータに適用します。Oracle Tuxedo TPFAILシナリオをサポートするために、 access属性の値が拡張されています。 元の値: in、out、inout、noaccess新しい値: err、inerr、outerr、inouterr |
|
|
一般的な定義をこのパラメータに適用します。SALTでは、 countパラメータには requiredcountの値と同じか、またはそれより大きい値を指定する必要があります。 |
|
|
一般的な定義をこのパラメータに適用します。デフォルトは 1です。SALTでは、 countパラメータには requiredcountの値と同じか、またはそれより大きい値を指定する必要があります。 |
|
|
このキーワードは省略可能で、パラメータの最大バイト長を制限する場合に使用します。以下のパラメータ型に対してのみ有効です。 STRING、CARRAY、XML、MBSTRING
設定しない場合、このパラメータは最大バイト長の制限を受けません。 |
|
|
パラメータに対応するXML Schema要素名を指定します。SALT WSDLコンバータによって生成されます。 このキーワードはネイティブなSALTプロキシ・サービス専用。ネイティブなOracle Tuxedoサービスには指定しないでください。 |
|
|
パラメータに対応するXMLプリミティブ・データ型を指定します。SALTであらかじめ定義されたXMLからTuxedoデータ型へのマッピング・ルールに従って、SALT WSDLコンバータによって生成される。 このキーワードはネイティブなSALTプロキシ・サービス専用。ネイティブなOracle Tuxedoサービスには指定しないでください。 |
|
|
Oracle Tuxedo RECORD型付きバッファでは、COBOLコピーブック情報を記述できます。 |
|
|
受信したSOAPエンベロープ・メッセージのSOAPヘッダー部分から取得されます。メッセージは、リクエスト(ネイティブTuxedoサービス)または応答(外部Webサービス呼出し)のいずれかになります。 |
|
|
送信されるSOAPエンベロープ・メッセージのSOAPヘッダー部分に追加されます。メッセージは、応答(ネイティブTuxedoサービス)またはリクエスト(外部Webサービス呼出し)のいずれかになります。 |
|
|
inheaderと outheaderの組合せ。このパラメータは、SOAPメッセージのSOAPヘッダー部分に追加される対象となり、かつ、そこから取得される対象となります。
|
ネイティブ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ヘッダーの定義の例を示します。
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<
Property name="mapsoapheader" value="true" />
mapsoapheader属性のデフォルト値は「
false」で、これは、GWWSがSOAPヘッダーとFMLフィールド間のマッピングを実行しないことを示します。
mapsoapheaderを
trueに設定すると、着信サービスおよび発信サービスのマッピング動作は次のようになります。
着信サービスについては、
リスト2に示すように、GWWSがSOAPヘッダーを変換します。
<cup:SoapHeader xmlns:cup='http://www.xxx.com/soa/esb/message/1_0'>
<cup:Value>xxx</cup:Value>
STRINGバッファは、
TA_WS_SOAP_HEADERフィールドに割り当てられ、ターゲットFML32バッファを挿入します。ターゲット・バッファ・タイプがFML32ではない場合、変換は有効になりません。
発信サービスでは、GWWSは、リクエスト・バッファから
TA_WS_SOAP_HEADERを受け取り、SOAPパッケージの構成時にSOAPヘッダーにそれを配置します。
このモードでは、
リスト3に示すように、サービス・レベルのWSDFエントリでプロパティ
headerMappingを
trueに設定する必要があります。
<?xml version="1.0" encoding="UTF-8"?>
<wsdf:Definition xmlns:wsdf="http://www.bea.com/Tuxedo/WSDF/2007" name="TuxAll" wsdlNamespace="urn:TuxAll.wsdl">
<wsdf:WSBinding id="TuxAll_Binding">
<wsdf:Servicegroup id="TuxAll_PortType">
<wsdf:Service name="strmap_val003"/>
<Property name="headerMapping" value="true"/>
<wsdf:Endpoint address="http://localhost:12438/TuxAll" id="TuxAll_TuxAll_HTTPPort"></wsdf:Endpoint>
<wsdf:Endpoint address="https://localhost:12448/TuxAll" id="TuxAll_TuxAll_HTTPSPort"></wsdf:Endpoint>
個々のWSBindingオブジェクトは、<
WSBinding>要素を使用して定義します。個々のWSBindingオブジェクトは、
WSDF内で一意のWSBinding IDを使用して定義する必要があります。WSBinding IDは、
GWWSによって使用される
SALTDEPLOYファイルの参照に必要なインジケータです。
個々のWSBindingオブジェクトは、<
SOAP>サブ要素を使用してSOAPプロトコルの詳細に関連付けることができます。WSBindingオブジェクトには、デフォルトではSOAP 1.1および
document/literalスタイルのSOAPメッセージが適用されます。
リスト4では、<
SOAP>サブ要素を使用してSOAPプロトコルの詳細を再定義する方法を示します。
リスト4
WSBindingに対する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」値がキー値として使用されます。
リスト5では、WSBindingのサービス・グループを定義する方法を示します。
リスト5
WSBinding用のサービス・グループの定義
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper" />
<Service name="tolower" />
</Servicegroup>
...
</WSBinding>
</Definition>
プラグインを作成および構成すると、<service>要素を使用してそれを参照して、そのサービスのユーザー定義データ・マッピング・ルールを指定できます。
<Msghandler>要素は、メッセージ・レベル(
<Input>、
<Output>または<Fault>)で定義して、メッセージを変換するために
「P_CUSTOM_TYPE」カテゴリ・プラグインのどの実装を使用する必要があるかについて指定できます。
<Msghandler>要素の内容はプラグインの名前です。
リスト6では、入力を変換するために
「MBCONV」カスタム・プラグインを使用するサービスと、出力を変換するために
「XMLCONV」カスタム・プラグインを使用するサービスを示します。
リスト6
サービスに対するメッセージ変換ハンドラの構成
<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つのサブ要素があります。
|
•
|
WS-PolicyファイルがWebサービスのエンドポイントレベルのアサーション(たとえば、信頼性のあるメッセージング・アサーション)から構成されている場合、WS-Policyファイルはこの< Servicegroup>要素を提供するすべてのエンドポイントに適用されます |
|
•
|
WS-PolicyファイルがWebサービス操作レベルのアサーション(たとえば、セキュリティIDアサーション)から構成されている場合、WS-Policyファイルはこの< Servicegroup>要素にリストされるすべてのサービスに適用されます。 |
|
•
|
WS-PolicyファイルがWebサービスのメッセージ・レベルのアサーション(たとえば、セキュリティSignedPartsアサーション)から構成されている場合、WS-Policyファイルはこの< Servicegroup>要素にリストされるすべてのサービスの入力メッセージ、出力メッセージ、フォルト・メッセージに適用されます。 |
|
•
|
注意: 現行リリースのSALTでは、リクエスト・メッセージレベルのアサーションのみサポートされます。メッセージレベルのアサーション・ポリシー・ファイルの場合は、 use="input"のみを指定するようにしてください。 |
|
•
|
WS-PolicyファイルがWebサービス操作レベルのアサーション(たとえば、セキュリティIDアサーション)から構成されている場合、WS-Policyファイルはこの特定のサービスに適用されます。 |
|
•
|
WS-PolicyファイルがWebサービスのメッセージレベルのアサーション(たとえば、セキュリティSignedPartsアサーション)から構成されている場合、WS-Policyファイルはこの特定のサービスの入力メッセージ、出力メッセージ、フォルト・メッセージに適用されます。 |
|
•
|
注意: 現行リリースのSALTでは、リクエスト・メッセージレベルのアサーションのみサポートされます。メッセージレベルのアサーション・ポリシー・ファイルの場合は、 use="input"を指定してください。 |
SALTには、使用されることの多い用途に合せてあらかじめパッケージ化されたWS-Policyファイルが含まれています。これらのWS-Policyファイルは
$TUXDIR/udataobj/salt/policyディレクトリにあります。これらのファイルを参照するには、
location="salt:<policy_file_name>"を使用します。
リスト7では、WS-Policyファイルをネイティブ
WSDFファイルで使用するサンプルを示します。
リスト7
WSDFファイルでのWS-Policyファイルの定義サンプル
<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>
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のバージョンベースのルーティングの使用(着信)
Oracle TuxedoのバージョンベースのルーティングをWebサービスとして公開されているOracle Tuxedoサービスで使用すると、次のことが行われます。
|
•
|
GWWSは、 REQUEST_VERSIONおよび VERSION_RANGEを UBBCONFIGファイルから取得します。 |
|
•
|
リクエストされたバージョンでサービスを呼び出します。 |
|
•
|
異なる設定(特定のゲートウェイからの特定のトラフィックを特定のサービスにルーティングするなど)が必要な場合は、異なる REQUEST_VERSION値で起動されているグループに別のゲートウェイ・インスタンスを構成します。 |
リスト8では、GWWSが
UBBCONFIGの設定からリクエスト・バージョンの"
1"を継承しているため、
VERSION_RANGE設定(この例では
GROUP1)に"
1"を含んでいるOracle Tuxedoアプリケーション・サーバーによって通知されるサービスを公開する例を示します。GWWSが公開するサービスが実際には
GROUP2のサーバーで実行されている場合は、結果として、
TPENOENTエラーがWebサービスのクライアントに転送されます。
リスト8
Webサービスとして公開されているTuxedoサービスでのTuxedoのバージョンベースのルーティングの使用
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サービス」セクションの下に表示されます。詳細は次の項目を参照してください。
Oracle Tuxedo定義へのWSDLファイルの変換
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定義ファイルを示します。
表3
SALT WSDLコンバータによって生成されたTuxedo定義ファイル
|
|
|
Oracle Tuxedoサービス・メタデータ・リポジトリ入力ファイル |
SALT WSDLコンバータでは、各 wsdl:operationがOracle Tuxedoサービス・メタデータ構文に準拠したSALTプロキシ・サービスに変換されます。SALTプロキシ・サービスは、 GWWSサーバーによって公開され、Oracle TuxedoアプリケーションからのATMI呼出しを受け付けるために使用します。 |
|
|
SALTでは、各 wsdl:messageがOracle Tuxedo FML32型付きバッファにマップされます。SALT WSDLコンバータでは、各メッセージのXML Schemaが分解され、各基本XMLスニペットにFML32フィールドとしてマップされます。生成されたFML32フィールドは定義表ファイルで定義され、デフォルトではそのフィールド名がXML要素のローカル名と同じになります。 Oracle TuxedoアプリケーションからSALTプロキシ・サービスにアクセスする場合は、生成されたFML32フィールドを参照してリクエスト・メッセージとレスポンス・メッセージを処理する必要があります。FML32環境変数を適切に設定して、Oracle TuxedoアプリケーションとGWWSサーバーの両方がフィールド名とフィールドID値をマップできるようにする必要があります。
|
注意:
|
生成されたフィールド名が他のフィールド名と競合しているなど、何らかの理由でフィールド名を再定義することがあります。この場合、Oracle Tuxedoサービス・メタデータ定義入力ファイルとFML32フィールド表定義ファイルの両方を変更する必要があります。詳細は、 「?$paratext>?」を参照してください。 |
|
|
|
SALT WSDLコンバータでWSDLファイルをWSDFファイルに変換し、これを発信方向のSALTデプロイメント・ファイルでGWWSサーバーにデプロイできます。生成されたWSDFファイルは、ネイティブではないWSDFファイルになります。
|
注意:
|
ネイティブでないWSDFファイルを着信方向にデプロイしないこと。 |
|
|
|
WSDLの埋込みXMLスキーマとインポートXMLスキーマ(<xsd:import>で参照するXMLスキーマ・コンテンツ)は、ローカルに .xsdファイルとして保存されます。これらはGWWSサーバーで使用するファイルで、同じディレクトリに保存する必要があります。
|
注意:
|
GWWSサーバーにこれらの .xsdファイルをロードできるよう、新たに追加されたXMLスキーマ環境変数( XSDDIRおよび XSDFILES)を適切に設定する必要があります。 |
|
WSDLからTuxedoサービス・メタデータ・キーワードへのマッピング
表4では、WSDL要素からTuxedoサービス・メタデータ定義キーワードへのマッピング・ルールを示します。
表4
WSDL要素からTuxedoサービス・メタデータ定義へのマッピング
|
|
対応するOracle Tuxedoサービス・メタデータ定義キーワード |
|
/wsdl:definitions
/wsdl:portType
/wsdl:operation
@name
|
|
キーワード値は操作のローカル名と同じ値になります。 |
|
|
SALTプロキシ・サービスのOracle Tuxedoシステムでの公開名です。 wsdl操作のローカル名が15文字未満である場合、キーワード値は操作のローカル名と同じ値になり、それ以外の場合、キーワード値は操作のローカル名の先頭15文字になります。 |
/wsdl:definitions
/wsdl:portType
/wsdl:operation
/wsdl:input
|
|
WSDL操作メッセージは、常にOracle Tuxedo FML32バッファ型としてマップされます。 |
/wsdl:definitions
/wsdl:portType
/wsdl:operation
/wsdl:output
|
|
/wsdl:definitions
/wsdl:portType
/wsdl:operation
/wsdl:fault
|
|
表5では、WSDL要素からWSDF要素へのマッピング・ルールを示します。
|
|
|
|
/wsdl:definitions
@targetNamespace
|
/Definition
@wsdlNamespace
|
各wsdl:definitionをWSDF Definitionにマップします。 |
/wsdl:definitions
/wsdl:binding
|
|
各 wsdl:bindingオブジェクトをWSDF WSBinding要素にマップします。 |
/wsdl:definitions
/wsdl:binding
@type
|
/Definition
/WSBinding
/Servicegroup
|
各 wsdl:bindingで参照する wsdl:portTypeオブジェクトを、対応するWSBinding要素のServicegroup要素にマップします。 |
/wsdl:definitions
/wsdl:binding
/soap:binding
|
/Definition
/WSBinding
/SOAP
@version
|
接頭辞が soapのネームスペースがURI http://schemas.xmlsoap.org/wsdl/soap/を参照する場合のSOAPバージョン属性値は 1.1です。 接頭辞が soapのネームスペースがURI http://schemas.xmlsoap.org/wsdl/soap12/を参照する場合のSOAPバージョン属性値は 1.2です。 |
/wsdl:definitions
/wsdl:binding
/soap:binding
@style
|
/Definition
/WSBinding
/SOAP
@style
|
WSDF WSBinding SOAPメッセージのスタイル設定は、対応するWSDL SOAPバインディング・メッセージのスタイル設定と同じになります( rpcまたは document)。 |
/wsdl:definitions
/wsdl:binding
/wsdl:operation
|
/Definition
/WSBinding
/Servicegroup
/Service
|
各 wsdl:operationオブジェクトを対応するWSBinding要素の Service要素にマップします。 |
/wsdl:definitions
/wsdl:port
/soap:address
|
/Definition
/WSBinding
/SOAP
/AccessingPoints
/Endpoint
|
wsdl:bindingオブジェクト用に定義された各soap:addressエンドポイントを、対応する WSBinding要素のEndpoint要素にマップします。
|
発信Webサービス・アプリケーションを構成するには、次の変換後のタスクを実行する必要があります。
生成されたSALTプロキシ・サービス定義での名前の競合を解決する
WSDLファイルを変換すると、コンテキスト情報の切捨てや消失のせいで、予期せぬ名前の競合が発生する場合があります。生成されたサービス・メタデータ定義とFML32フィールド表ファイルを使用する前に、次のような名前の競合を解決する必要があります。
|
•
|
サービス・メタデータ・キーワード tuxserviceの定義が重複している場合は解決する |
SALTプロキシ・サービス・メタデータ定義のキーワード
tuxserviceは、元のWebサービス・オペレーションのローカル名が15文字以上ある場合はそれ以降を切り捨てた値になります。
そのため、複数SALTプロキシ・サービス・エントリで、切捨て後の
tuxserviceの値が重複する可能性があります。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が対応するかを調べる際に有用です。
生成されたSALTプロキシ・サービス・メタデータ定義をロードする
名前の競合が解決したら、
tmloadreposユーティリティを使用して、SALTプロキシ・サービス・メタデータ定義をOracle Tuxedoサービス・メタデータ・リポジトリにロードする必要があります。詳細は、『Oracle Tuxedoコマンド・リファレンス・ガイド』の
tmloadreposに関する項を参照してください。
発信Webサービス用にGWWSサーバーを起動する前に、次の環境変数を設定する必要があります。
|
•
|
生成したFML32フィールド・テーブル・ファイルを追加するには、 FLDTBLDIR32および FIELDTBLS32環境変数を更新します。 |
|
•
|
引用したすべてのXMLスキーマ・ファイルを1つのディレクトリに保存して、 XSDDIR環境変数および XSDFILES環境変数を設定します。 |
|
•
|
SALT 2.0リリースには、 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
Oracle Tuxedoのバージョンベースのルーティングの使用(発信)
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とは別のエンドポイントに接続しているサービスにルーティングされます。
リスト9
Oracle Tuxedoのバージョンベースのルーティングと外部Webサービス
...
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
...
同じサービス・グループおよびサービス操作に対して複数のバインドを作成することができます。ただし、異なるサービス・グループおよび操作に対して複数のバインドを作成することはできません。
着信サービスについては、複数バインドを次のように作成することができます。
|
•
|
作成したバインドのそれぞれにエンドポイント・アドレスを追加できます。これは、サービスごとに"http"と"https"を使い分ける必要がある場合に便利です。 |
|
•
|
異なるSOAPバージョンを指定するため。例: SOAPバージョン1.1または1.2。 |
|
•
|
エンコード・タイプを指定するため。例: RPC/encodedまたはDoc/Literal。 |
複数のバインドを追加するには、Webコンソールを使用する必要があります。
WSDLファイルを使用してインポートしたWebサービスは、Tuxedoクライアントがリクエストを送信し外部Webサービスからレスポンスを受信する、発信サービスです。
インポートしたWebサービスのユーザーは、Webコンソールとポリシー・ファイルを使用して、エンドポイント・アドレスの値を変更することができます。ただし、複数バインドやSOAP属性を追加することはできません。
SALTデプロイメント・ファイル(
SALTDEPLOY)では、SALT Webサービスのアプリケーションを定義します。
SALTDEPLOYファイルは、バイナリ
SALTCONFIGファイルのWebサービス・アプリケーションに対する重要な入力です。
SALTDEPLOYファイルを作成するには、次の手順に従います。
必要なWSDFファイルをすべてSALTデプロイメント・ファイルにインポートする必要があります。インポートされた各WSDFファイルには、一意のWSDF名が設定されている必要があり、この名前はデプロイメントに関連付けるために
GWWSサーバーによって使用されます。インポートされた各WSDFファイルは、
SALTDEPLOYファイルに指定した場所を介してアクセスできる必要があります。
リスト10には、
SALTDEPLOYファイルにWSDFファイルをインポートする方法を示します。
リスト10
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またはそれ以上のアクセス・エンドポイントを発信エンドポイントとして指定できます。
リスト11には、着信および発信エンドポイントでGWWSサーバーを構成する方法を示します。
リスト11
SALTDEPLOYファイルに定義された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サーバーレベル・プロパティを示します。
|
|
|
|
|
|
|
SOAPメッセージで複数のエンコーディングをサポートするかどうかを指定します。 |
|
|
|
|
|
|
|
|
|
着信HTTPメッセージのコンテンツの最大長を指定します。 |
(接尾辞として「M」または「G」を設定できます(例: 1.5M、0.2G))
|
|
|
|
GWWSサーバーのスレッド・プール・サイズを指定します。 |
|
|
|
|
|
|
|
|
|
信頼性のあるメッセージングの確認応答メッセージの応答ポリシーを指定します。GWWSサーバーでは、ネットワークからSOAPリクエストを受信した直後か、Oracle Tuxedoサービスからレスポンス・メッセージが返された後に確認応答メッセージを送信できます。 |
|
|
リスト12に、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メッセージと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での複数のエンコーディング・サポートを有効にするには、
リスト13に示すように、GWWSサーバーレベル・プロパティ
enableMultiEncodingを
trueに設定する必要があります。
|
注意:
|
GWWSでは、UTF-8以外の外部メッセージがUTF-8に変換されます。ただし、エンコーディングの変換はサーバーのパフォーマンスに影響します。デフォルトでは、エンコーディングの変換はオフで、UTF-8エンコードのないメッセージが拒否されます。 |
リスト13
GWWSサーバーの複数エンコーディング・プロパティの構成
<Deployment ..>
...
<WSGateway>
<GWInstance id="GWWS1">
.......
<Properties>
<Property name="
enableMultiEncoding" value="
true"/>
</Properties>
</GWInstance>
</WSGateway>
...
</ Deployment>
表7では、GWWSサーバー・レベルの複数エンコーディング・プロパティを有効にした場合に適用される、SOAPメッセージとTuxedoバッファの間のエンコーディング・マッピング・ルールの詳細について説明します。
表7
SALTメッセージ・エンコーディング・マッピング・ルール
|
|
|
|
|
|
|
string/mbstring/xmlバッファまたはフィールドの文字のエンコーディングをSOAP xmlエンコーディングと同じにします。
|
|
|
|
GWWSは、ターゲットのSOAPメッセージを UTF-8エンコーディングに設定し、元の STRINGバッファには UTF-8エンコーディングの文字のみが含まれるものとみなします。
|
注意:
|
Oracle Tuxedoでの開発においては、STRINGの文字を必ず UTF-8エンコーディングにする必要があります。 |
|
|
|
|
SOAP xmlエンコーディングをMBSTRING/XMLエンコーディングと同じにします。 |
複数の FLD_MBSTRINGフィールドが同じエンコーディングに設定されているFML/32、VIEW/32型付きバッファ |
|
SOAP xmlエンコーディングを FLD_MBSTRINGエンコーディングに設定します。元の型付きバッファ・フィールドの文字は、SOAPメッセージ内では変更されません。
|
注意:
|
Oracle Tuxedoでの開発においては、同じバッファ内のFLD_STRINGの文字を必ず一貫性のあるものにする必要があります。
|
|
複数の FLD_MBSTRINGフィールドが異なるエンコーディングに設定されているFML/32、VIEW/32型付きバッファ |
|
SOAP xmlエンコーディングを UTF-8に設定します。エンコーディングが異なる元の型付きバッファ FLD_MBSTRINGフィールドの文字は、SOAPメッセージ内 UTF-8に変換されます。
|
注意:
|
Oracle Tuxedoでの開発においては、同じバッファ内の FLD_STRINGの文字を必ず UTF-8エンコーディングにする必要があります。 |
|
SALTでは、すべての
GWWSサーバーによって共有される一連のグローバル・リソースを
SALTDEPLOYファイルで定義します。次のシステムレベル・リソースを
SALTDEPLOYファイルで構成できます。
証明書の情報は、SSLリスニング・エンドポイントを作成するまたは認証およびメッセージ署名用X.509証明書を使用するように
GWWSサーバーで構成する必要があります。同じデプロイメント・ファイルに指定したすべての
GWWSサーバーは同じ証明書の設定(秘密キー・ファイル、信頼されている証明書ディレクトリなどを含む)を共有します。
秘密キー・ファイルは
<Certificate>/<PrivateKey>サブ要素を使用して構成します。秘密キー・ファイルはPEMファイル形式で、ローカルで保存される必要があります。
<Certificate>/<VerifyClient>サブ要素を
trueに設定すると、SSLクライアントを確認できます。
|
注意:
|
デフォルトでは、 GWWSサーバーはSSLクライアントを確認しません。 |
SSLクライアントを確認する場合やX.509証明書の認証機能が有効になっている場合、一連の信頼済証明書はローカルで保存し、
GWWSサーバーで指定する必要があります。
GWWSサーバーの信頼済証明書を定義するには2つの方法があります。
|
1.
|
すべての証明書を1つのPEM形式のファイルに指定し、< <Certificate>/<TrustedCert>サブ要素を使用してファイルのパスを定義する方法 |
|
2.
|
別々のPEM形式の証明書ファイルを1つのディレクトリに保存し、< <Certificate>/<CertPath>サブ要素を使用してディレクトリ・パスを定義します。 |
|
注意:
|
識別名の「 cn」属性は、証明書ルックアップ用のキーとして使用されます。名前で使用されるワイルドカードはサポートされません。空の件名フィールドは許可されません。この制約はOracle Tuxedoでも見つかります。 |
リスト14には、
GWWSサーバーの証明書を構成する
SALTDEPLOYファイルのセグメントを示します。
リスト14
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ファイルに指定する必要があります。
リスト15には、
GWWSサーバーがロードする複数のカスタマイズされたプラグイン・ライブラリを構成する
SALTDEPLOYファイルのセグメントを示します。
リスト15
SALTDEPLOYファイルでのプラグイン・ライブラリの構成
<Deployment ..>
...
<System>
<Plugin>
<Interface lib=���plugin_1.so��� />
<Interface lib=���plugin_2.so��� />
</Plugin>
</System>
</Deployment
|
注意:
|
プラグイン・ライブラリをSALT 2.0のプラグイン・インタフェースを使用して開発する場合、インタフェースの 「id」および 「name」属性を指定する必要はありません。これらの値はプラグイン・インタフェースから取得できます。 |
現在のSALTは次の高度なWebサービス・メッセージング機能をサポートしています。
非同期Webサービス・メッセージングの着信と発信の両方をサポートします。
着信Webサービスの信頼性のあるメッセージ配信をサポートします。
ネイティブと外部のWebサービスでバイナリ添付ファイルをサポートします。
着信サービスは特有なWeb service addressingの構成が必要ではありません。
GWWSサーバーはWS-Addressingリクエスト・メッセージおよび非WS-Addressingリクエスト・メッセージによって受け付けて回答します。
発信サービスについては、以下の項で説明しているようにWeb service addressingの構成が必要です。
発信サービスのAddressingエンドポイントの構成
発信サービスについては、Web Service AddressingはWebサービス・バインディング・レベルで構成します。
SALTDEPLOYファイルでは、各
GWWSサーバーは、WS-Addressingを有効にするために参照された任意の発信WSBindingオブジェクトに対して、<
WSAddressing>要素を使用してWS-Addressingエンドポイントを指定できます。
WS-Addressingエンドポイントを設定した後、
GWWSサーバーは起動時にリスニング・エンドポイントを作成します。発信WSBindingに指定したすべてのサービスはWS-Addressingメッセージで呼出します。
リスト16には、参照された発信Webサービス・バインディングに対してWS-Addressingを有効にする
SALTDEPLOYファイルのセグメントを示します。
リスト16
発信Webサービス・バインディングに対して定義されたWS-Addressingエンドポイント
<Deployment ..>
...
<WSGateway>
<GWInstance id="GWWS1">
...
<Outbound>
<Binding ref="app1:app1_binding">
<WSAddressing>
<Endpoint address=���https://myhost:8801/app1_async_point��� tlsversion=TLSv1.2>
</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��� tlsversion=TLSv1.2>
</WSAddressing>
<Endpoint use=" simpapp_GWWS1_HTTPPort" />
<Endpoint use=" simpapp_GWWS1_HTTPSPort" />
</Binding>
</Outbound>
...
</GWInstance>
</WSGateway>
...
</ Deployment>
|
注意:
|
GWWSサーバーの各発信Webサービス・バインディングを特定のWS-Addressingエンドポイント・アドレスに関連付けることができます。これらのエンドポイントは、同じホスト名とポート番号で設定できますが、エンドポイント・アドレスのコンテキスト・パースの部分を異なっている必要があります。
|
外部Webサービス・バインディングは、WS-Addressingメッセージをサポートされない場合、実行時にAddressingエンドポイントの構成に障害が発生する可能性があります。
tlsversion属性は、SSLネットワーク接続で使用されるTLSバージョンを指定します。GWWSエンドポイントでは、デフォルトでTLS 1.2を使用します。TLS 1.0のみをサポートしている以前のリリースのTuxedoアプリケーションに接続している場合は、この属性をTLS 1.0に設定する必要があります。詳細は、
TLSバージョンのネゴシエーションおよび構成に関する項を参照してください。
SALTDEPLOYファイルでのWS-Addressingエンドポイントの作成の有無にかかわらず、WSDFで特定の発信サービスのAddressing機能を明示的に無効にできます。特定の発信サービスのAddressing機能を無効にするには、WSDFファイル内の対応する
<Service>定義で
disableWSAddressingプロパティを
trueに設定する必要があります。このプロパティは、着信サービスには影響しません。
リスト17には、Addressing機能を無効にするWSDFファイルのセグメントを示します。
リスト17
サービス・レベルWS-Addressingの無効化
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper">
<Property name="disableWSAddressing" value=���true��� />
</Service>
<Service name="tolower" />
</Servicegroup>
....
</WSBinding>
</Definition>
|
注意:
|
信頼性のあるメッセージング・ポリシーの定義を含むWSDFは、着信方向のみに GWWSサーバーで使用する必要があります。 |
信頼性のあるメッセージングのポリシー・ファイルの作成
信頼性のあるメッセージングのポリシー・ファイルは、WS-ReliableMessagingのアサーションを含む一般的なWS-Policyファイルです。WS-ReliableMessagingのアサーションは、サポート対象のWS-ReliableMessage仕様のバージョン、ソース・エンドポイントの再伝送までの時間間隔、送信元エンドポイントの承認までの時間間隔などの機能を説明するXMLセグメントです。
リスト18には、信頼性のあるメッセージングのポリシー・ファイルの例を示します。
リスト18
信頼性のあるメッセージングのポリシー・ファイルの例
<?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ファイルで信頼性のあるメッセージング・ポリシー・ファイルの指定
ネイティブWSDFファイルでは、<
Servicegroup>レベルにおいてWS-ReliableMessagingポリシー・ファイルを参照する必要があります。
リスト19には、WS-ReliableMessagingポリシー・ファイルの参照方法を示します。
リスト19
エンドポイント・レベルでのWS-ReliableMessagingポリシーの参照
<Definition ...>
<WSBinding ...>
<Servicegroup ...>
<Policy location=���RMPolicy.xml��� />
<Service ... />
<Service ... />
...
</Servicegroup ...>
</WSBinding>
</Definition>
|
注意:
|
SALTにおいて、信頼性のあるメッセージングではプロセス障害/システム障害の状況がサポートされていません。つまり、SALTではメッセージが永続ストレージ領域には保存されません。SALTはSOAPクライアントと 直接モードでやりとりします。通常、システム障害から回復するには、クライアントとサーバーの間でビジネス・ロジックの同期化を行う必要があります。 |
SALTは、CARRAY型付きバッファ、またはフィールド付きバッファ(VIEW、VIEW32、FMLまたはFML32)のCARRAYフィールドに対するバイナリ添付ファイルをサポートします。デフォルトでは、バイナリ・バッファ/フィールドはbase64エンコードされます。
リスト20に示すように、MTOMを有効にするには、WSDFファイルでサービスまたはサービス・グループに構成を追加する必要があります。
リスト20
<Policy location="salt:ws-mtom.xml"/>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Policy location="salt:ws-mtom.xml"/>
<Service name="tolower" />
SALTでは、転送レベルとSOAPメッセージ・レベルの両方のレベルでセキュリティがサポートされます。次のトピックでは、各レベルにおいてセキュリティ機能を設定する方法について説明します。
SALTでは、SSLリンクレベル・セキュリティを使用してポイントツーポイント・セキュリティが提供され、着信サービスおよび発信サービスの両方のサービス認証に対してHTTP基本認証メカニズムがサポートされます。
SSLを使用して着信エンドポイントでリンク・レベル・セキュリティを設定するには、エンドポイント・アドレスの前に接頭辞として
「https://」を指定できます。この着信エンドポイントを使用する
GWWSサーバーは、SSLリスニング・ポートを作成してWebサービス・クライアントをSSL接続で保護します。SSL機能では、証明書の設定を指定する必要があります。詳細は、
「?$paratext>?」を参照してください。
発信エンドポイントへの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>
HTTPヘッダーから取得される文字列の例を以下に示します。
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
この例では、クライアントから渡されたOracle Tuxedoユーザー名は「
Aladdin」、パスワードは「
open sesame」であり、このペア値がOracle Tuxedoの認証に使用されます。
|
•
|
アプリケーション・パスワード( APP_PW)を使用する場合 |
Oracle Tuxedoで
APP_PWが使用されている場合、HTTPユーザー名の値は無視され、
GWWSサーバーはパスワード文字列のみをOracle Tuxedoアプリケーション・パスワードとして使用し、認証をチェックします。
|
•
|
ユーザー・レベル認証( USER_AUTH)を使用する場合 |
Oracle Tuxedoで
USER_AUTHが使用されている場合、HTTPユーザー名とパスワードの両方の値が使用されます。この場合、
GWWSサーバーはOracle Tuxedoアプリケーション・パスワードをチェックしません。
SALTは、発信HTTP基本認証のユーザー資格証明を作成するために認証プラグイン開発をサポートしています。発信HTTP基本認証は、エンドポイントレベルで構成されます。発信エンドポイントにおいて、HTTPメッセージでユーザー・プロファイルが必要の場合、WSDFファイル内でHTTPエンドポイント用HTTPレルムを指定する必要があります。
GWWSサーバーは、ユーザー名とパスワードを作成するために認証プラグイン・ライブラリを呼出し、HTTP基本認証メカニズムを使用してリクエスト・メッセージに送信します。
リスト21には、発信エンドポイントに対するHTTP基本認証を有効化する方法を示します。
リスト21
発信エンドポイントに対する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ファイルで構成する必要があります。詳細は、
「?$paratext>?」および『SALT Webサービスのプログラミング』の
発信認証プラグインのプログラミングに関する項を参照してください。
メッセージ・レベルのWebサービス・セキュリティの構成
SALTでは、メッセージ・レベル・セキュリティに対してWebサービス・セキュリティ1.0および1.1仕様をサポートします。SALTでは、次の項目を保証するためにメッセージレベル・セキュリティを使用できます。
|
•
|
着信リクエスト・メッセージの整合性(SOAP本文の署名を要求) |
Webサービス・セキュリティのSALTの実装: SOAPメッセージ・セキュリティの仕様は次のユース・ケースをサポートします。
|
•
|
認証のためSOAPメッセージにトークン(ユーザー名またはX.509)を含める |
|
•
|
整合性を保証するため、SOAPメッセージにトークン(X.509)とSOAP本文の署名を含める |
SALTには、メッセージ・レベル・セキュリティのユースケースのために使用される複数のWS-Securityポリシー1.0および1.2のファイルが含まれています。
SALTが正常にインストールされると、WS-Policyファイルが
$TUXDIR/udataobj/salt/policyに配置されます。
表8に、SALTに付属するデフォルトWS-Securityポリシー・ファイルを示します。
表8
SALTに付属するWS-Securityポリシー・ファイル
|
|
|
wssp1.0-username-auth.xml
|
WS-Securityポリシー1.0。サービスの認証用の容易なテキスト・ユーザー名トークン
|
|
|
WS-Securityポリシー1.0。サービスの認証用のX.509 V3証明書トークン
|
|
|
WS-Securityポリシー1.0。X.509証明書トークンの検証用の SOAP:Body上の署名
|
wssp1.2-Wss1.0-UsernameToken-plain-auth.xml
|
WS-Securityポリシー1.2。サービスの認証用の容易なテキスト・ユーザー名トークン
|
wssp1.2-Wss1.1-X509V3-auth.xml
|
WS-Securityポリシー1.2。サービスの認証用のX.509 V3証明書トークン
|
|
|
WS-Securityポリシー1.2。X.509証明書トークンの検証用の SOAP:Body上の署名
|
上述のWS-Security Policy 1.2
UserTokenファイル以外のすべてのポリシー・ファイルを、ネイティブ
WSDFファイルの
<Servicegroup>要素または
<Service>要素を使用して参照できます。WSSP 1.2
UserTokenファイルは、
<Servicegroup>を使用した場合のみ参照できます。
リスト22に、サービス
TOUPPERで、クライアントがプレーン・テキスト形式の
UsernameTokenとリクエスト形式のX509v3Tokenを送信する必要があり、X.509トークンで署名付きメッセージの
SOAP:Body部分も必要とする、ポリシー割当ての組合せを示します。サンプル「
wsseapp」では、WSSP 1.2
UserTokenファイルを
<Service>要素で使用するようにクリップする方法を示します。
リスト22
WS-Securityポリシーの使用方法
<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管理者がGWWSを、SAMLアサーションを扱えるように初めて設定する手順について説明します。
|
1.
|
ディレクトリを $APPDIRに変更し、 wsadminを開始します。 |
|
2.
|
「 saml create」コマンドを使用してキー・ファイルを作成します。 |
|
3.
|
「 saml add -g」コマンドを使用してGWWSレコードを追加します。 |
|
4.
|
「 saml add -i」コマンドを使用して、信頼できる各アサーション発行者に対応する、信頼できるアサーション発行者レコードを追加します。 |
|
5.
|
「CertPath」の下のSALTデプロイメント記述子ファイルの「 Certificate」要素に記述されたディレクトリに、ファイル「 saml_key.meta」をコピーします。 |
|
6.
|
ディレクトリをOracle Tuxedoアプリケーション・ドメインに変更し、 "tmboot -y"を使用してOracle Tuxedoアプリケーション・ドメインを起動します。 |
MPモード構成では、異なるGWWSインスタンスに対して、キー・ファイル内に異なるGWWSレコードが存在することが可能です。次の手順では、GWWSインスタンスに対応するキー・ファイルを異なるノード上で作成します。
|
1.
|
元のキー・ファイルを異なるディレクトリまたはマシンにコピーします。 |
|
2.
|
「 saml delete -g」を使用して既存のGWWSレコードを削除します。 |
|
3.
|
「 saml add -g」コマンドを使用して、異なるGWWSレコードを追加します。 |
表9に示すように、SALTには、SAML SSO用にサービスを構成するために使用できるいくつかのWS-Policyファイルが含まれます
|
|
|
Wssp1.2-2007-Saml1.1-SenderVouches-Https.xml |
|
Wssp1.2-2007-Saml2.0-SenderVouches-Https.xml |
|
Wssp1.2-2007-Saml1.1-SenderVouches.xml |
|
Wssp1.2-2007-Saml2.0-SenderVouches.xml |
|
前述のファイルは、ネイティブのWSDFファイルの
<ServiceGroup>または
<Service>のレベルで参照できます。
たとえば、
リスト23は、サポートされている機能を概説したSAML 1.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>
Oracle Tuxedo SecurityでのSAML要素のマッピング
表10に、オプションのSAMLアサーション要素が提示する必要があるものをリストします。
Oracle Tuxedoセキュリティと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マッピング・プラグインがインストールされている場合)と同じ名前が付けられている必要があります。
構成したX.509公開鍵証明書は、次のように使用されます。
|
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クライアントに応答を返信する前に、証明書を検証し、署名を確認します。
リスト24
X.509認証に基づくSOAPメッセージ
<S11:Envelope xmlns:S11="���" >
<wsse:Security xmlns:wsse="���" xmlns:wsu="���">
<wsse:BinarySecurityToken
EncodingType="wsse:Base64Binary">
MIIEzzCCA9CgAwIBAgIQEmtJZc0���
</wsse:BinarySecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:Reference URI="#body">���</ds:Reference>
<ds:Reference URI="#binarytoken">���</ds:Reference>
<S11:Body wsu:Id="body" xmlns:wsu="���">
GWWSを介してWebサービスに正常にアクセスするには、GWWSが実行時にアクセスできる有効なクライアント証明書と秘密鍵を構成する必要があります。この証明書と秘密鍵は、Webサービスの要件に従って、トランスポート・レベル・セキュリティまたはメッセージ・レベル・セキュリティ、あるいはその両方で使用できます。
現在、Tuxedo SALTはデプロイメント記述子のSystem要素を通して構成された単一の証明書のみをサポートしています。この制限によって、異なるインスタンスのGWWSゲートウェイ
1を通過するすべてのリクエストで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デプロイメント記述子で使用可能です。
defaultClientIdentification
このプロパティでは、X.509証明書のルックアップで使用するデフォルトのクライアント名を定義します。"Service"の構成は"GWInstance"の構成より優先されます。
リスト25では、サービスGetDataのcatalinaがデフォルトとして有効なクライアント名であることを示します。
リスト25
defaultClientIdentificationの例
<?xml version="1.0" encoding="UTF-8" ?>
<WSBinding id="sample_Binding">
<ServiceGroup id="SampleSrvGrp">
<Property name="defaultClientIdentification" value="catalina"/>
<?xml version="1.0" encoding="UTF-8"?>
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<Import location="c:/salt/x.509/Sample.wsdf"></Import>
<GWInstance id="INSTANCE1">
<Property name="defaultClientIdentification" value="melbourne"/>
GWWSインスタンス"INSTANCE1"で提供され、独自の"defaultClientId"を持たないその他のすべてのサービスについては、GWWSのデフォルト・クライアントID(ここでは"melbourne")が使用されます。
useSingleClientIdentification
どのWebサービスにも同じクライアントX.509証明書を使用するかどうかは、"useSingleClientIdentification"で決まります。このフィルタを有効化するよう決定された場合、すべてのSALTクライアント・リクエストは"defaultClientIdentification"で構成された識別を使用します。"defaultCleintIdentification"が構成されていない場合は、構成エラーであるため、"wsloadcf"によってエラーが発行されます。このオプションはデフォルトでは無効にされています。
Tuxedo "SECURITY"が少なくとも"USER_AUTH"レベルで構成されている場合、このフィルタはランタイム・クライアントX.509証明書選択にのみ影響があります。Tuxedo SECURITYが"NONE"または"APP_PW"に構成されている場合、このフィルタはクライアント証明書の選択には使用されません。実行時にこの属性が無効化されたとしても、前の段落で説明したエラー条件は依然としてtrueです。
次に、この単一クライアント識別フィルタを使用可能にするかどうかを判定するためのマトリックス表を示します。
表11
単一クライアント識別フィルタのマトリックス
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
前の項の例では、両方の場所でこのプロパティを省略しているので、このフィルタは無効化されています。次の例では、このフィルタは有効化されています。
<?xml version="1.0" encoding="UTF-8" ?>
<WSBinding id="sample_Binding">
<ServiceGroup id="SampleSrvGrp">
<Property name="defaultClientIdentification" value="catalina"/>
<Property name="useSingleClientIdentification" value="true" />
<?xml version="1.0" encoding="UTF-8"?>
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<Import location="c:/salt/x.509/Sample.wsdf"></Import>
<GWInstance id="INSTANCE1">
<Property name="defaultClientIdentification" value="melbourne"/>
Tuxedo SECURITYが少なくとも"USER_AUTH"レベルで構成されている場合、このプロパティはX.509証明書選択にのみ影響があります。このプロパティは、ユーザーが独自のX.509証明書を所有していなくても、Webサービスにアクセスする際にデフォルトのクライアント識別を使用することを許可します。このオプションはデフォルトでは無効にされています。
次に、この匿名クライアント・アクセス・フィルタを使用可能にするかどうかを判定するためのマトリックス表を示します。
表12
匿名クライアント・アクセス・フィルタのマトリックス
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
このフィルタを有効化するよう決定された場合、"defaultClientIdentification"を構成する必要があります。"defaultClientIdentification"が構成されていない場合、"wsloadcf"は失敗し、エラーを返します。
<?xml version="1.0" encoding="UTF-8" ?>
<WSBinding id="sample_Binding">
<Servicegroup id="SampleSrvGrp">
<Property name="defaultClientIdentification" value="catalina"/>
<Property name="allowAnonymousAccess" value="true" />
<?xml version="1.0" encoding="UTF-8"?>
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<Import location="c:/salt/x.509/Sample.wsdf"></Import>
<GWInstance id="INSTANCE1">
<Property name="defaultClientIdentification" value="melbourne"/>
<Property name="allowAnonymousAccess" value="false" />
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構成を設定およびコンパイルした後、Oracle Tuxedo
UBBCONFIGファイルは、Oracle TuxedoアプリケーションにSALTコンポーネントが適用されるように更新する必要があります。
表13には、SALTの
UBBCONFIGファイルの構成タスクを示します。
表13
SALTのUBBCONFIGファイルの構成タスク
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
*SERVERSセクションでTMMETADATAサーバーの構成
SALTは、
UBBCONFIGファイルに少なくとも1つの
TMMETADATAサーバーを指定する必要があります。Tuxedoサービス定義にアクセスするスループットを増加するために、複数の
TMMETADATAサーバーの指定も可能です。
リスト31には、Oracle Tuxedoアプリケーションに
TMMETADATAサーバーを定義する方法を示す
UBBCONFIGファイルのセグメントの一覧を示します。
リスト31
UBBCONFIGファイルの*SERVERSセクションで定義されたTMMETADATAサーバー
......
*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サーバーが同じリポジトリ・ファイルを指す必要があります。 |
*SERVERSセクションでGWWSサーバーの構成
SALTDEPLOYファイルに定義されたGWWSインスタンスを起動するには、
UBBCONFIGファイルの*
SERVERSセクションで
GWWSサーバーを指定する必要があります。1つまたは複数の
GWWSサーバー・インスタンスを並行して
UBBCONFIGファイルに定義できます。各
GWWSサーバーは、Oracle Tuxedoドメイン内でオプション
-iを使用して、一意のインスタンスIDに割り当てる必要があります。インスタンスIDは、XMLバージョンの
SALTDEPLOYファイルおよび生成されたバイナリ・バージョンの
SALTCONFIGファイルに存在する必要があります。
リスト32には、Oracle Tuxedoアプリケーションに
GWWSサーバーを定義する方法を示す
UBBCONFIGファイルのセグメントの一覧を示します。
リスト32
UBBCONFIGファイルの*SERVERSセクションで定義されたGWWSサーバー
......
*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サーバーによって読み込まれません。
UBBCONFIGファイルでシステム制限事項の更新
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に適切な値を設定する必要があります。この値は共有されます。
GWWSサーバーの証明書のパスワード・フレーズの構成
SALTの証明書を設定する際には、セキュリティのパスワードを設定する必要があります。
GWWSサーバーでは、SSLリンクレベル暗号化やWebサービス・セキュリティX.509トークンおよび署名機能を有効にするとき、証明書を設定する必要があります。証明書の秘密鍵のファイルを作成し、パスワードで暗号化する必要があります。
証明書に関連する機能を使用して
GWWSサーバーが指定される場合、それらは秘密鍵ファイルを読み取り、パスワード・フレーズを使用してそれらを復号化するために必要です。各
GWWSサーバーに対してパスワード・フレーズを構成するには、*
SERVERSセクションにおける必要な各
GWWSサーバー・エントリの下にキーワード
SEC_PRINCIPAL_NAMEおよび
SEC_PRINCIPAL_PASSVARを指定する必要があります。
tmloadcfを使用して
UBBCONFIGファイルをコンパイルする際には、管理者がパスワード・フレーズを入力する必要があり、これは秘密キー・ファイルを正しく復号化するために使用できます。
|
注意:
|
SALTデプロイメント・ファイルに秘密キー・ファイルを1つのみ指定できます。SALTデプロイメント・ファイルに定義されているすべてのGWWSサーバーについては、秘密キー・ファイルの復号化のため同じパスワードを提供する必要があります。 |
リスト33には、
GWWSサーバーに対してセキュリティのパスワード・フレーズを定義する
UBBCONFIGファイルのセグメントを示します。
リスト33
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"
......
Webサービス・クライアント用のOracle Tuxedo認証の構成
SALTの
GWWSサーバーは、Webサービス・クライアントの有効性をチェックするためにOracle Tuxedo認証フレームワークに依存します。Oracle Tuxedoの従来のアプリケーションがすでに適用されている場合、Webサービス・クライアントは次のいずれかの方法でユーザー資格証明を送信する必要があります。
|
•
|
SOAPメッセージ・ヘッダーのWebサービス・セキュリティのユーザー名トークン |
逆に、SALTに対してWebサービス・クライアントを認証する場合、Oracle TuxedoドメインでOracle Tuxedo認証を構成する必要があります。
詳細は、
Oracle Tuxedo 12cR2ドキュメントの
認証の管理に関する項を参照してください。
発信HTTP基本認証のOracle Tuxedoセキュリティ・レベルの構成
発信HTTP基本認証
username /passwordをマッピングするためにOracle Tuxedoクライアント
uid / gidを取得するには、
UBBCONFIGファイルでOracle Tuxedoセキュリティ・レベルを
USER_AUTH、
ACLまたは
MANDATORY_ACLとして構成する必要があります。
リスト34には、
UBBCONFIGファイルでセキュリティレベルACLを定義する
UBBCONFIGファイルのセグメントを示します。
リスト34
発信HTTP基本認証に対してUBBCONFIGファイルで定義されたセキュリティレベルACL
*RESOURCES
IPCKEY ...
......
SECURITY ACL
......
SALTのOracle Tuxedo MPモードでの構成
MPモードのOracle Tuxedoドメイン内の複数のマシンで実行している
GWWSサーバーを設定するには、各Oracle Tuxedoマシンを異なる
SALTDEPLOYファイルおよび一連の別々のコンポーネントで定義する必要があります。
以下のグローバル・リソースを別々のマシンに渡って広める必要があります。
SALTDEPLOYファイルに指定された設定に従って各マシンから秘密キー・ファイルおよび信頼された証明書ファイルをアクセスできる必要があります。
プラグイン共有ライブラリは各マシンでコンパイルする必要があり、
SALTDEPLOYファイルに指定された設定に従ってアクセスできる必要があります。
2つのマシンでは、同じWSDFファイルを関連付けられて、同一の機能がある、異なるマシンで実行している2つの
GWWSサーバーを指定できます。ただし、以下のアーティファクトの伝播を手動で行う必要があります。
|
•
|
Oracle TuxedoサービスがFML32タイプ・バッファを消費する場合の、FML32フィールド表定義ファイル |
|
•
|
wsdlcvtから引用されたXMLスキーマ・ファイル
|
この項では、SALT 1.1からSALT 2.0リリースにアップグレードするカスタマに対して次の2つの移行方法について説明します。
SALT 1.1構成ファイルでGWWSサーバーの実行
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サーバーを実行するには、次の手順に従います。
|
1.
|
wsloadcfを介してSALT 1.1形式の構成ファイルのバイナリ・バージョンの SALTCONFIGをロードします。
|
|
2.
|
GWWSサーバーを起動する前に環境変数 SALTCONFIGを設定します。
|
|
3.
|
このSALT 1.1構成ファイルに関する GWWSサーバーを起動します。 |
|
注意:
|
Oracle Tuxedoドメインに定義された複数のSALT 1.1構成ファイルがある場合、ステップ1から3に従って、複数のバイナリ SALTCONFIGファイルを生成し、対応する GWWSサーバーを起動する必要があります。 |
SALT 1.1構成ファイルを変換してSALT 2.0構成スタイルの採用
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ファイルを手動で編集する必要があります。
リスト35に、指定されたSALT 1.1構成ファイルから変換された
SALTDEPLOYファイルおよび
WSDFファイルを示します。
リスト35
SALT 1.1構成ファイル(simpapp.xml)のサンプル
<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ファイルおよびデプロイメント・ファイルを、
リスト36および
リスト37にそれぞれ示します。
リスト36
SALT 1.1構成ファイルの変換されたWSDFファイル(simpapp.xml.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 tlsversion=TLSv1.2/>
</AccessingPoints>
</SOAP>
</WSBinding>
</Definition>
リスト37
SALT 1.1構成ファイルの変換されたSALTDEPLOYファイル(simpapp.xml.dep)
<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()を発行すると、そのサービスの応答バッファ情報が転送先のサービスの応答バッファ情報と同じになります。例:
|
•
|
クライアントがSTRINGタイプ・バッファでSVCAを呼び出す |
|
•
|
SVCAがリクエストを処理し、SVCBに転送するリクエストとして新しいFML32タイプ・バッファを作成します |
|
•
|
SVCBがリクエストを処理し、クライアントにSTRINGバッファを返す。SVCAの規約は STRING+STRINGです。SVCBの規約は FML32+STRINGです。 |
収集されたサービス規約検索情報を、メタデータ・リポジトリに直接格納するかわりにファイルに書き出す場合、
TMMETADATA(5) -o<filename>オプションを使用し、
tmloadreposを使用して、ファイルをメタデータ・リポジトリに手動でロードする必要があります。詳細は、『Oracle Tuxedoコマンド・リファレンス・ガイド』の
tmloadreposに関する項を参照してください。
ファイルをメタデータ・リポジトリの代わりのストレージとして使用する場合、出力は
tmloadreposに準拠したフォーマットになります。このファイルは、サービス・ヘッダー・セクションと、パラメータごとのパラメータ・セクションで構成されます。サービス・ヘッダーには、
表14に示す項目が含まれます。「
service」フィールドのフォーマットは、
<TuxedoServiceName>+'_'+<SequenceNo>です。Oracle Tuxedoサービスに複数のパターンが認識された場合に名前の競合を避けるため、接尾辞
<SequenceNo>が使用されます。
|
注意:
|
<SequenceNo>は、メタデータ・リポジトリにすでに格納された最後の <SequenceNo>の番号から始まります。
|
サービス・パラメータには、
表15に示す情報が含まれます。
|
|
|
|
|
|
|
<RealServiceName>_<SequenceNo>。
|
|
|
|
|
|
|
|
|
|
|
|
FML、FML32、VIEW、VIEW32、STRING、CARRAY、XML、X_OCTET、X_COMMON、X_C_TYPE、MBSTRINGまたはカスタム・バッファ・タイプを定義したアプリケーションを表すその他の任意の文字列 |
|
|
|
|
|
|
|
|
|
|
|
ビュー名。inbufのタイプがVIEWまたはVIEW32の場合のみ記述されます。 |
|
|
|
ビュー名。outbufのタイプがVIEWまたはVIEW32の場合のみ記述されます。 |
|
|
|
ビュー名。errbufのタイプがVIEWまたはVIEW32の場合のみ記述されます。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
byte、short、integer、float、double、string、carray、dec_t、xml、ptr、fml32、view32、mbstring |
|
|
|
viewまたはview32タイプ・パラメータのビュー名 |
|
|
|
収集期間内のFML/FML32フィールドの最大出現回数 |
|
|
|
収集期間内のFML/FML32フィールドの最小出現回数 |
入力:
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=STRINGservice=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追加擬似スキーマの付録に要約されています。 |
Oracle Tuxedoまたは/DomainのTLogファイルと同様に、トランザクション・ログ(
TLogDevice)要素を使用して、GWWSシステム・サーバーを構成する必要があります。
リスト38に示すように、
TLOGDevice要素が、
SALTCONFIGソース・ファイル(
SALTDEPLOY)に追加されます。
TLOGName要素も追加して、GWWSインスタンスで同じTLogデバイスを共有できます。
TLogデバイスは、Webサービス・ゲートウェイ・インスタンスごとに1つのみ設定できます(つまり、トランザクション・ログ要素は/Deployment/WSGateway/GWInstanceの子要素です)。
リスト38
SALTDEPLOYファイルに追加されたTLOG要素
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<TLogDevice location="/app/GWTLOG"/>
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ドメインに伝播できることを確認するためには、次の手順を実行します。
|
1.
|
呼び出されたOracle Tuxedoサービスがトランザクションをサポートしていることを確認します。 |
|
3.
|
呼び出された外部Webサービスに関して目的の動作に対応するWS-ATアサーションを含むポリシー・ファイルを構成します。詳細は、 「ポリシー・アサーションの構成」を参照してください。 |
|
4.
|
CoordinationContext要素を含む着信コールは、Oracle Tuxedoグローバル・トランザクションを作成します。
|
|
•
|
ゲートウェイのログ・ファイルは構成されません。 wscoor:InvalidStateエラーは呼出し元に戻されます。 「詳細」フィールドに、対応するメッセージが格納されます。 |
|
•
|
ターゲットOracle Tuxedoサービスは、トランザクションをサポートしていません。 TPETRANエラー・コードのアプリケーション・エラーは呼出し元に戻されます。 |
|
•
|
その他のすべてのアプリケーションで、構成( TPENOENTなど)またはシステム・エラーは、通常(非トランザクション)のリクエストの処理と同じ方法で処理されます。 |
Oracle Tuxedoクライアントが外部WebサービスへのOracle Tuxedoグローバル・トランザクションを伝播するために、次の手順を実行します。
|
2.
|
呼び出された外部Webサービスに関して目的の動作に対応するWS-ATアサーションを含むポリシー・ファイルを構成します。詳細は、 「ポリシー・アサーションの構成」を参照してください。 |
|
3.
|
アサーション設定およびOracle Tuxedoトランザクション・コンテンツの存在に応じて、 CoordinationContext要素が作成され、アプリケーション・リクエストとともにSOAPヘッダーに送信されます。 |
|
4.
|
エンドポイント参照が自動的に生成され、リモート RegistrationService要素の CoordinationContext要素とともに送信され、トランザクションで使用します。プロトコル交換(準備/コミットまたはロールバックなど)とともに、この手順は両側で透過的です。 |
|
•
|
リモート・システムがトランザクションをサポートせず、WS-ATアサーション/トランザクション・コンテキスト・コールに must create transactionセマンティクスがある場合、 TPESYSTEMエラーがクライアントに戻されます。 |
|
•
|
リモートに生成されたエラーは、通常で非トランザクションの呼出しと同じ方法で、Oracle Tuxedoクライアントに戻されます。戻されたエラーの 「理由」および 「詳細」フィールドでは、(環境に依存した)エラーの性質を説明します。 |
リスト1に示すように、
MaxTran要素を使用して、内部トランザクション表のサイズを構成できます。デフォルトは
MAXGTTです。
|
注意:
|
MaxTran値は省略可能です。構成された値が MAXGTTより大きい場合、これは無視され、かわりに MAXGTTが使用されます。
|
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
WS-ATは、リクエストが操作呼出しを原子性トランザクションの一部として作成する
必要または
可能性があるかどうかを示すことができるポリシー・アサーションを定義します。
policy.xmlファイルには、WS-ATポリシー要素が含まれます。
リスト2に示すように、WS-ATは、
ATAssertion要素を
Optional属性に定義する場合、
/wsat:ATAssertion/@wsp:Optional="true"となります。
リスト2
Policy.XMLのATAssertion要素
<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"/>
|
注意:
|
外部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メインフレーム・トランザクション・パブリッシャ
この機能は、着信方向ではCOBOLコピーブックに基づくSALT構成アーティファクトの生成をサポートし、発信方向では構成アーティファクトとCOBOLコピーブックを生成します。COBOLコピーブックをSALTアーティファクトに変換する新しいコマンド行ツール(
wscobolcvt)が提供されています。ランタイム・サポートに加えて、構成ツールが次のように拡張されています。
|
•
|
グラフィカル・ユーザー・インタフェースのある、コマンド行ツールと同じレベルの機能を提供します。 |
|
•
|
インタフェースに含まれないように入出力フィールドを制限できます。この場合、値を設定または取得できないため、デフォルト設定ルールが適用されます。 |
COBOLコピーブックをSALTアーティファクトに変換する新しいコマンド行ツールです。
wsdlcvtコマンドでは、インポートされたWSDLに含まれているスキーマの構造に基づいてCOBOLコピーブックを生成できます。
このモードでは、(webserviceとは対照的に)
wsdlcvtによって
servicetype=snaも生成されるため、対応するTuxedoサービスをGWSNAXで起動できます。サービスは外部Webサービスに対応し、
servicetype=webserviceと同じように機能します。
Tuxedoサービス・コンソールを使用して、COBOLコピーブックのインポート・プロセスを自動化したり、それに基づいてWebサービスを生成したり、外部Webサービスをインポートできます。
SOAP着信
(Webサービスとして公開されたメインフレーム・トランザクション)
wscobolcvtコマンドは、レコード・タイプ・バッファを使用してCOBOLコピーブックをサービス・メタデータ(MIF)に変換します。
図3に示すように、COBOLを解析してMIF形式のサービス・メタデータを生成します。
|
1.
|
wscobolcvtでは、引数としてCOBOLソースと次の追加情報を指定します。
|
|
•
|
メインフレーム・トランザクションに対応する、TMAで通知されるサービス名 |
|
•
|
MIF定義が追加されるサービス・メタデータ・リポジトリ |
|
•
|
同じWSDLサービスで複数のトランザクションを公開するために同じMIFサービスをターゲットにするwscobolcvtサポート |
|
2.
|
wscobolcvtは、サービス・メタデータと WSDFファイルを生成します。
|
|
3.
|
オプションで、 wscobolcvtは、 リスト1に示すように、ドメインIDとCRMアドレスを使用して DMCONFIGファイル・エントリを自動的に構成します |
|
4.
|
生成されたファイルと参照を構成に追加してデプロイできます。 |
リスト1
ドメインIDとCRMアドレスを使用したDMCONFIGファイル・エントリ
*DM_LOCAL_DOMAINS
CRMDOM
GWGRP=CRMGRP
TYPE=SNAX
DOMAINID="CRMDOM"
*DM_REMOTE_DOMAINS
CICSDOM
TYPE=SNAX
DOMAINID="CICSDOM"
*DM_SNACRM
CRMDOM
SNACRMADDR="//wasa:1234"
NWDEVICE="/dev/tcp"
LDOM="CRMDOM"
図4に示すように、メインフレーム・トランザクションをREST着信サービスとして公開する手順は、SOAP (
wscobolcvtを使用)と似ています。次の相違点に注意してください。
|
•
|
リスト1に示すように、サービスは SALTDEPにのみ追加されます。
|
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<Import location="GWWS_conf.xml.wsdf"></Import>
<Binding ref="TuxAll:TuxAll_Binding">
<Endpoint use="TuxAll_TuxAll_HTTPPort"></Endpoint>
<Network http="localhost:2211" https=""/>
<Method name="GET" reposservice="BALANCE" service="BALANCE" inputbuffer="RECORD"/>
<Method name="POST" reposservice="DEPOSIT" service="DEPOSIT" inputbuffer="RECORD"/>
SOAP発信
(外部Webサービスを起動するメインフレーム)
wsdlcvtコマンドは、WSDL/スキーマからCOBOLコピーブックを生成するために使用します。発信サービスは
RECORDペイロードを使用して起動され、自動的に検出されてGWWSを使用して変換されます。
-C引数を使用して
wsdlcvtを起動すると、
RECORD型定義、
WSDF、
XSD、
RECORDファイルおよびCOBOLコピーブック・ソース・ファイルを使用してMIFを生成できます。
wsdlcvtには文字列長を指定する
-Dオプションがあり、
xsd:string型がサイズで制限されていない場合に使用します。指定しない場合、文字列のデフォルトは
256(PIC X(256))です。
生成されるMIFエントリ
servicetypeは
snaに設定されます。
図6に示すように、REST発信サービスには、
wsdlcvtと同等のものがありません。
リスト1に示すように、アクセスするサービス・エンドポイントを/Outbound/HTTPセクションに単に追加します。
<Deployment xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007">
<Binding ref="bankapp:bankapp_binding">
<Endpoint use="https1" />
address="http://some.org/bankAccount"
