|
|
Oracle Service Architecture Leveraging Tuxedo (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型付きバッファの変換ルーチンをカスタマイズするために独自のプラグイン機能を作成できます。詳細は、Oracle Service Architecture Leveraging Tuxedo 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データ型としてマップされています。詳細は、Oracle Service Architecture Leveraging Tuxedo Webサービスのプログラミングのデータ型のマッピングと変換に関する項、およびOracle Service Architecture Leveraging Tuxedoリファレンス・ガイドのtmwsdlgenを参照してください。
Oracle Tuxedoから外部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定義ファイルを示します。
Oracle Service Architecture Leveraging Tuxedoは、各wsdlメッセージを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デプロイメント・ファイル(SALTDEPLOY)では、SALT Webサービスのアプリケーションを定義します。SALTDEPLOYファイルは、バイナリSALTCONFIGファイルのWebサービス・アプリケーションに対する重要な入力です。
SALTDEPLOYファイルを作成するには、次の手順に従います。
詳細については、『Oracle SALTリファレンス・ガイド』のSALTデプロイメント・ファイルのリファレンスに関する項を参照してください。
必要なWSDFファイルをすべてSALTデプロイメント・ファイルにインポートする必要があります。インポートされた各WSDFファイルには、一意のWSDF名が設定されている必要があり、この名前はデプロイメントに関連付けるためにGWWSサーバーによって使用されます。インポートされた各WSDFファイルは、SALTDEPLOYファイルに指定した場所を介してアクセスできる必要があります。
リスト7には、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またはそれ以上のアクセス・エンドポイントを発信エンドポイントとして指定できます。
リスト8には、着信および発信エンドポイントで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サーバーのチューニングに関する項を参照してください。 |
リスト9GWWSプロパティの構成方法の例を示します。
<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での複数のエンコーディング・サポートを有効にするには、リスト10に示すように、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でも見つかります。 |
リスト11には、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ファイルに指定する必要があります。
リスト12には、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サービス・メッセージングの着信と発信の両方をサポートします。
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メッセージで呼出します。
リスト13には、参照された発信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」に設定する必要があります。このプロパティは、着信サービスには影響しません。
リスト14には、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セグメントです。
詳細は、 Oracle Service Architecture Leveraging Tuxedoリファレンス・ガイドの SALT WS-信頼できるメッセージングのポリシー・アサーション・リファレンスの項を参照してください。
リスト15には、信頼性のあるメッセージングのポリシー・ファイルの例を示します。
<?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ポリシー・ファイルを参照する必要があります。リスト16には、WS-ReliableMessagingポリシー・ファイルの参照方法を示します。
<Definition ...><Policy location=”RMPolicy.xml” />
<WSBinding ...>
<Servicegroup ...><Service ... />
<Service ... />
...
</Servicegroup ...>
</WSBinding>
</Definition>
| 注意: | SALTにおいて、信頼性のあるメッセージングではプロセス障害/システム障害の状況がサポートされていません。つまり、SALTではメッセージが永続ストレージ領域には保存されません。SALTはSOAPクライアントと直接モードでやりとりします。通常、システム障害から回復するには、クライアントとサーバーの間でビジネス・ロジックの同期化を行う必要があります。 |
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の認証に使用されます。
APP_PW)を使用する場合 Oracle TuxedoでAPP_PWが使用されている場合、HTTPユーザー名の値は無視され、GWWSサーバーはパスワード文字列のみをOracle Tuxedoアプリケーション・パスワードとして使用し、認証をチェックします。
USER_AUTH)を使用する場合 Oracle TuxedoでUSER_AUTHが使用されている場合、HTTPユーザー名とパスワードの両方の値が使用されます。この場合、GWWSサーバーはOracle Tuxedoアプリケーション・パスワードをチェックしません。
| 注意: | Webサービスのクライアントに対しては、ACLおよびMANDATORY_ACLがサポートされていません。そのため、ACLに関するすべての構成はOracle Tuxedoシステムによって無視されます。SALTには、グループ情報をWebサービスのクライアントに提供する機能はありません。 |
SALTは、発信HTTP基本認証のユーザー資格証明を作成するために認証プラグイン開発をサポートしています。発信HTTP基本認証は、エンドポイントレベルで構成されます。発信エンドポイントにおいて、HTTPメッセージでユーザー・プロファイルが必要の場合、WSDFファイル内でHTTPエンドポイント用HTTPレルムを指定する必要があります。GWWSサーバーは、ユーザー名とパスワードを作成するために認証プラグイン・ライブラリを呼出し、HTTP基本認証メカニズムを使用してリクエスト・メッセージに送信します。
リスト17には、発信エンドポイントに対する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ファイルで構成する必要があります。詳細は、Oracle Service Architecture Leveraging Tuxedo 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>を使用した場合のみ参照できます。
リスト18に、サービス「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トークン・メカニズムを使用してエンド・ユーザーを「保証」します。
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サービス・セキュリティの構成」を参照してください。
たとえば、リスト19は、サポートされている機能を概説した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:WssSamlV20Token11/>
</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に構成されている場合、リクエストは拒否されます。
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を生成せずに、検証の目的にのみ実行できます。
詳細は、Oracle Service Architecture Leveraging Tuxedoリファレンス・ガイドの wsloadcfリファレンスを参照してください。
SALT構成を設定およびコンパイルした後、Oracle Tuxedo UBBCONFIGファイルは、Oracle TuxedoアプリケーションにSALTコンポーネントが適用されるように更新する必要があります。表11には、SALTのUBBCONFIGファイルの構成タスクを示します。
SALTは、UBBCONFIGファイルに少なくとも1つのTMMETADATAサーバーを指定する必要があります。Tuxedoサービス定義にアクセスするスループットを増加するために、複数のTMMETADATAサーバーの指定も可能です。
リスト20には、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ファイルに存在する必要があります。
リスト21には、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サーバーについては、秘密キー・ファイルの復号化のため同じパスワードを提供する必要があります。 |
リスト22には、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 12cR1ドキュメントの UBBCONFIG(5)に関する項を参照してください。
SALTのGWWSサーバーは、Webサービス・クライアントの有効性をチェックするためにOracle Tuxedo認証フレームワークに依存します。Oracle Tuxedoの従来のアプリケーションがすでに適用されている場合、Webサービス・クライアントは次のいずれかの方法でユーザー資格証明を送信する必要があります。
逆に、SALTに対してWebサービス・クライアントを認証する場合、Oracle TuxedoドメインでOracle Tuxedo認証を構成する必要があります。
詳細は、Oracle Tuxedo 12cR1ドキュメントの 認証の管理に関する項を参照してください。
発信HTTP基本認証username /passwordをマッピングするためにOracle Tuxedoクライアントuid / gidを取得するには、UBBCONFIGファイルでOracle Tuxedoセキュリティ・レベルをUSER_AUTH、ACLまたはMANDATORY_ACLとして構成する必要があります。
リスト23には、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ファイルを手動で編集する必要があります。 |
リスト24に、指定された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ファイルおよびデプロイメント・ファイルを、リスト25およびリスト26にそれぞれ示します。
<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コマンドを使用してサービス規約の実行時収集を管理できます。詳細は、Oracle Service Architecture Leveraging Tuxedoコマンド・リファレンス・ガイドのtmscdに関する項を参照してください。
生成されたサービス規約情報には、サービス名、リクエスト・バッファ情報、応答バッファ情報、およびエラー・バッファ情報(エラーがある場合のみ)が含まれます。TMMETADATAサーバーへの送信が失敗した場合、収集されたサービス規約情報は破棄されます。バッファ情報には、バッファ・タイプ、サブタイプ、およびFML/FML32のフィールド情報(name、type、subtype)が含まれます。
検索は、FML32バッファ内のすべての埋め込みバッファでサポートされます。FML/FML32フィールドが出現すると、検索によってメタデータ・リポジトリ内のcount/requiredcountのパターンが自動的に更新されます。フィールドの出現がパターンに影響することはありませんが、「requiredcount」で最小出現回数を指定できます。規約検索の期間全体での最大出現回数は「count」で指定します。
VIEW/VIEW32/X_C_TYPE/X_COMMONの場合は、ビュー名のみが検索されます。SALTでメタデータ・リポジトリを使用している場合は、ビュー名に基づいて詳しい説明を生成できます。
| 注意: | autodiscovery(表12を参照)を指定したパターンは比較されます。 |
| 注意: | メタデータ・リポジトリ内に同じautodiscoveryパターンがすでに存在する場合は、新しい方のパターンが無視されます。 |
サポートされるのは、アプリケーションATMIサービス(ローカル、または/TDOMAINゲートウェイ経由でインポートされたもの)のみです。サービス規約検索では、次のサービスはサポートされません。
| 注意: | 応答のないサービスは、メタデータ・リポジトリでは「oneway」サービスとしてマップされます。 |
サービスがtpreturn()のかわりに tpforward()を発行すると、そのサービスの応答バッファ情報が転送先のサービスの応答バッファ情報と同じになります。たとえば、次のように指定します。
収集されたサービス規約検索情報を、メタデータ・リポジトリに直接格納するかわりにファイルに書き出す場合、 TMMETADATA(5) -o<filename>オプションを使用し、tmloadreposを使用して、ファイルをメタデータ・リポジトリに手動でロードする必要があります。詳細は、Oracle Tuxedoコマンド・リファレンス・ガイドのtmloadreposに関する項を参照してください。
ファイルをメタデータ・リポジトリの代わりのストレージとして使用する場合、出力はtmloadreposに準拠したフォーマットになります。このファイルは、サービス・ヘッダー・セクションと、パラメータごとのパラメータ・セクションで構成されます。サービス・ヘッダーには、表12に示す項目が含まれます。「service」フィールドのフォーマットは、<TuxedoServiceName>+'_'+<SequenceNo>です。Oracle Tuxedoサービスに複数のパターンが認識された場合に名前の競合を避けるため、接尾辞 <SequenceNo>が使用されます。
| 注意: | <SequenceNo>は、メタデータ・リポジトリにすでに格納された最後の<SequenceNo>の番号から始まります。 |
サービス・パラメータには、表13に示す情報が含まれます。
入力: 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システム・サーバーを構成する必要があります。リスト27に示すように、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
| 注意: | 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を知っている人は誰でもアクセスできます。リスト3に、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構成ツールにアクセスするユーザーは、このパスワードの提示を要求されます。正しく提示できなかった場合、アクセスは拒否されます。リスト4に、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ユーザー名とパスワードの提示を要求されます。正しく提示できなかった場合、アクセスは拒否されます。リスト5に、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ユーザー名とパスワードの提示を要求されます。正しく提示できなかった場合、アクセスは拒否されます。リスト6に、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ユーザー名とパスワードの提示を要求されます。正しく提示できなかった場合、アクセスは拒否されます。リスト7に、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コンソールにアクセスできるユーザーはいません。
  
|