管理ガイド

Oracle SALTアプリケーションの構成

この項の内容は次のとおりです。

Oracle Tuxedo Webサービスの構成

Oracle SALTのOracle Tuxedoサービス・メタデータ・リポジトリの使用

Oracle SALTでは、 Oracle Tuxedoサービス・メタデータ・リポジトリを利用して、Oracle Tuxedoの従来のサービスとOracle SALTプロキシ・サービスの両方のサービス契約情報を定義します。リストされたすべてのOracle Tuxedoサービスのサービス規約情報を、ローカルOracle Tuxedoドメインによって提供されるOracle Tuxedoサービス・メタデータ・リポジトリ・システム・サービスにアクセスして取得します。通常は、次に示すように、SALTから TMMETADATAシステムを呼び出します。

次のトピックでは、SALT特有のOracle Tuxedoサービス・メタデータ・リポジトリ・キーワードとパラメータの使用について説明します。

Oracle SALT用のサービス・レベル・キーワードの定義

表3-1では、SALTで使用および解釈されるOracle Tuxedoサービス・メタデータ・リポジトリのサービス・レベル・キーワードを示します。

Oracle SALT用のサービス・パラメータの定義

Oracle Tuxedoサービス・メタデータ・リポジトリでは、パラメータはOracle Tuxedoサービスの型付きバッファ内にカプセル化されたサブ要素として解釈されます。パラメータごとに、データ型、バッファ内の出現回数、サイズ制限、その他のOracle Tuxedoに固有の制限を設定できます。次に注意してください。

表3-2では、SALTで使用および解釈されるOracle Tuxedoサービス・メタデータ・リポジトリのパラメータ・レベル・キーワードを示します。

ネイティブOracle Tuxedoサービスの構成

この項では、ネイティブOracle TuxedoサービスをWebサービスとして公開するために必要な構成タスクと省略可能な構成タスクについて説明します。

ネイティブWSDFの作成

1つまたは複数のHTTP/Sエンドポイントを介して一連のOracle TuxedoサービスをWebサービスとして公開するには、ネイティブWSDFを定義する必要があります。

各ネイティブWSDFは、一意のWSDF名で定義する必要があります。WSDFでは、Webサービス・アプリケーションの詳細(SOAPプロトコルの詳細、Webサービス操作として公開するOracle Tuxedoサービスの一覧など)に対して1つまたは複数の<WSBinding>要素を定義できます。

この項の内容は次のとおりです。

SOAPヘッダーの定義

mapsoapheader属性は、SOAPヘッダーを構成するために使用します。これにより、SOAPヘッダーを表すFML32フィールドが定義されます。これはTA_WS_SOAP_HEADER STRINGタイプです。

リスト3-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に設定すると、着信サービスおよび発信サービスのマッピング動作は次のようになります。

WSBindingオブジェクトの定義

個々のWSBindingオブジェクトは、<WSBinding>要素を使用して定義します。個々のWSBindingオブジェクトは、WSDF内で一意のWSBinding IDを使用して定義する必要があります。WSBinding IDは、GWWSによって使用されるSALTDEPLOYファイルの参照に必要なインジケータです。

個々のWSBindingオブジェクトは、<SOAP>サブ要素を使用してSOAPプロトコルの詳細に関連付けることができます。WSBindingオブジェクトには、デフォルトではSOAP 1.1およびdocument/literalスタイルのSOAPメッセージが適用されます。

リスト3-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」値がキー値として使用されます。

リスト3-4では、WSBindingのサービス・グループを定義する方法を示します。

<Definition ...>
  <WSBinding id="simpapp_binding">
    <Servicegroup id="simpapp">
      <Service name="toupper" />
      <Service name="tolower" />
    </Servicegroup>
    ...
  </WSBinding>
</Definition>

メッセージ変換ハンドラの構成

SOAP XMLペイロードおよびOracle Tuxedo型付きバッファの変換ルーチンをカスタマイズするために独自のプラグイン機能を作成できます。詳細は、Oracle SALT Webサービスのプログラミングの Oracle SALTプラグインの使用に関する項、および「プラグイン・ライブラリの構成」を参照してください。

プラグインを作成および構成すると、<service>要素を使用してそれを参照して、そのサービスのユーザー定義データ・マッピング・ルールを指定できます。<Msghandler>要素は、メッセージ・レベル(<Input>、<Output>または<Fault>)で定義して、メッセージを変換するために「P_CUSTOM_TYPE」カテゴリ・プラグインのどの実装を使用する必要があるかについて指定できます。<Msghandler>要素の内容はプラグインの名前です。

リスト3-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>

WS-Policyファイルの使用

高度なWebサービスの機能は、WS-Policyファイル(例えば、信頼性のあるメッセージングおよびWebサービスのメッセージ・レベル・セキュリティ)を構成して有効できます。これらの機能を使用するには、WS-Policyファイルの作成が必要になる場合があります。Web Service Policy Framework仕様により、Webサービスのポリシーを記述および通信するための汎用的なモデルと構文が提供されています。

WS-Policyファイルを使用する場合、<Policy>要素を定義してこれらの異なるWS-PolicyファイルをWSDFに組み込む必要があります。ポリシー・ファイル・パスの指定にはlocation属性を使用します。絶対ファイル・パスでも相対ファイル・パスでも指定できます。省略可能なuse属性をメッセージ・レベルのアサーション・ポリシー・ファイルで使用すると、適用するメッセージ(リクエスト(入力)メッセージ、レスポンス(出力)メッセージ、またはフォルト・メッセージ、あるいはこれら3つの組合せ)を指定できます。

WSDFには、WS-Policyファイルを参照する2つのサブ要素があります。

Oracle SALTには、使用されることの多い用途に合せてあらかじめパッケージ化されたWS-Policyファイルが含まれています。これらのWS-Policyファイルは$TUXDIR/udataobj/salt/policyディレクトリにあります。これらのファイルを参照するには、location=”salt:<policy_file_name>”を使用します。

リスト3-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ポリシー・ファイルの使用」を参照してください。

ネイティブWSDFからWSDLファイルの生成

Oracle TuxedoのネイティブWSDFが作成されたら、Oracle SALT WSDLの生成ユーティリティtmwsdlgenを使用して、対応するWSDLファイルを生成できます。次のサンプル・コマンドでは、「app1.wsdf」というWSDFから「app1.wsdl」というWSDLファイルを生成します。

tmwsdlgen -c app1.wsdf -o app1.wsdl

または、「-o」オプションを使用して出力WSDLファイル名を指定できます。 指定しない場合、tmwsdlgenは、デフォルト値として「tuxedo.wsdl」という名前のWSDLファイルを作成します。

ネイティブWSDFファイルに、CARRAYバッファを使用するOracle Tuxedoサービスが含まれている場合、CARRAYバッファ・マッピングに対して別のスタイルのWSDLファイルを生成するためにtmwsdlgenオプションを指定できます。デフォルトでは、CARRAYバッファがSOAPメッセージでxsd:base64Binary XMLデータ型としてマップされています。詳細は、Oracle SALT Webサービスのプログラミングの データ型のマッピングと変換に関する項、およびOracle SALTリファレンス・ガイドの tmwsdlgenに関する項を参照してください。

外部Webサービスの構成

Oracle Tuxedoから外部Webサービスを呼び出すには、次の構成タスクを実行する必要があります。

Oracle Tuxedo定義へのWSDLファイルの変換

Oracle SALTには、外部WSDLファイルをOracle Tuxedo定義に変換するためのWSDL変換コマンド・ユーティリティが付属しています。WSDLファイルはExtensible Stylesheet Language Transformations (XSLT)テクノロジを使用して変換されます。Oracle SALTのインストール・パッケージには、デフォルトのXSLTツールキットとして使用するApache Xalan Java 2.7.0がバンドルされています。

Oracle SALT WSDLコンバータは2つの部分で構成されています。

次のサンプル・コマンドでは、外部WSDLファイルを変換してOracle Tuxedo定義ファイルを生成しています。

wsdlcvt -i http://api.google.com/GoogleSearch.wsdl -o GSearch

表3-3では、Oracle SALT WSDLコンバータによって生成されたOracle Tuxedo定義ファイルを示します。

WSDLからTuxedoサービス・メタデータ・キーワードへのマッピング

表3-4では、WSDL要素からTuxedoサービス・メタデータ定義キーワードへのマッピング・ルールを示します。

WSDLからWSDFへのマッピング

表3-5では、WSDL要素からWSDF要素へのマッピング・ルールを示します。

変換後のタスク

発信Webサービス・アプリケーションを構成するには、以下の変換後のタスクを実行する必要があります。

生成されたOracle SALTプロキシ・サービス定義での名前の競合を解決する

WSDLファイルを変換すると、コンテキスト情報の切り捨てまたは消失のせいで、予期せぬ名前の競合が発生する場合があります。生成されたサービス・メタデータ定義とFML32フィールド表ファイルを使用する前に、以下のような名前の競合を解決する必要があります。

生成されたSALTプロキシ・サービス・メタデータ定義をロードする

名前の競合が解決したら、tmloadreposユーティリティを使用して、Oracle SALTプロキシ・サービス・メタデータ定義をOracle Tuxedoサービス・メタデータ・リポジトリにロードする必要があります。詳細は、Oracle Tuxedoコマンド・リファレンス・ガイドのtmloadreposに関する項を参照してください。

GWWSランタイムの環境変数を設定する

発信Webサービス用にGWWSサーバーを起動する前に、次の環境変数を設定する必要があります。

Oracle SALTデプロイメント・ファイルの作成

Oracle SALTデプロイメント・ファイル(SALTDEPLOY)では、SALT Webサービスのアプリケーションを定義します。SALTDEPLOYファイルは、バイナリSALTCONFIGファイルのWebサービス・アプリケーションに対する重要な入力です。

SALTDEPLOYファイルを作成するには、次の手順に従います。

詳細は、Oracle SALTリファレンス・ガイドの Oracle SALTのデプロイメント・ファイル・リファレンスに関する項を参照してください。

WSDFファイルのインポート

必要なWSDFファイルをすべてOracle SALTデプロイメント・ファイルにインポートする必要があります。インポートされた各WSDFファイルには、一意のWSDF名が設定されている必要があり、この名前はデプロイメントに関連付けるためにGWWSサーバーによって使用されます。インポートされた各WSDFファイルは、SALTDEPLOYファイルに指定した場所を介してアクセスできる必要があります。

リスト3-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サーバーの構成

各GWWSサーバーは、インポートされたWSDFファイルに定義した着信WSBindingオブジェクトおよび発信WSBindingオブジェクトのグループとともにデプロイできます。各WSBindingオブジェクトは、「ref=<wsdf_name>:<WSBinding id>」属性を使用して参照します。着信WSBindingオブジェクトについては、各GWWSサーバーで、WSBindingオブジェクトのエンドポイント・リストから少なくとも1つのアクセス・エンドポイントを着信エンドポイントとして指定する必要があります。発信WSBindingオブジェクトについては、各GWWSサーバーで、WSBindingオブジェクトのエンドポイント・リストから0またはそれ以上のアクセス・エンドポイントを発信エンドポイントとして指定できます。

リスト3-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サーバー・レベル・プロパティの構成

GWWSサーバーは、機能をオン/オフにするプロパティまたはサーバーのパフォーマンスをチューニングする引数を設定するプロパティで構成できます。

プロパティは、<GWInstance>の子要素<Properties>に構成されます。個別の各プロパティは、「name」属性および「value」属性を含む<Property> 要素を使用して定義します。異なる「name」属性は、値を含む異なるプロパティ要素を表します。表3-6には、GWWSサーバー・レベル・プロパティを示します。

リスト3-9には、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>

複数のエンコーディング・サポートの構成

Oracle SALTでは、SOAPメッセージ用の複数のエンコーディング、およびSOAPメッセージとOracle Tuxedoバッファの間のエンコーディング・マッピングがサポートされています。Oracle SALTでは、次の文字エンコーディングがサポートされています。

GWWSでの複数のエンコーディング・サポートを有効にするには、リスト3-10に示すように、GWWSサーバー・レベル・プロパティ「enableMultiEncoding」を「true」に設定する必要があります。

<Deployment ..>
  ...
  <WSGateway>
    <GWInstance id="GWWS1">
      .......
      <Properties>
        <Property name="enableMultiEncoding" value="true"/>
      </Properties>
    </GWInstance>
  </WSGateway>
  ...
</ Deployment>

表3-7では、GWWSサーバー・レベルの複数エンコーディング・プロパティを有効にした場合に適用される、SOAPメッセージとTuxedoバッファの間のエンコーディング・マッピング・ルールの詳細について説明します。

システム・レベル・リソースの構成

Oracle SALTでは、すべてのGWWSサーバーによって共有される一連のグローバル・リソースを SALTDEPLOYファイルに定義します。次のシステム・レベル・リソースをSALTDEPLOYファイルに構成できます。

証明書の構成

証明書の情報は、SSLリスニング・エンドポイントを作成するまたは認証およびメッセージ署名用X.509証明書を使用するようにGWWSサーバーで構成する必要があります。同じデプロイメント・ファイルに指定したすべてのGWWSサーバーは同じ証明書の設定(秘密キー・ファイル、信頼されている証明書ディレクトリなどを含む)を共有します。

秘密キー・ファイルは<Certificate>/<PrivateKey>サブ要素を使用して構成します。秘密キー・ファイルはPEMファイル形式で、ローカルで保存される必要があります。

<Certificate>/<VerifyClient>サブ要素をtrueに設定すると、SSLクライアントを確認できます。デフォルトでは、GWWSサーバーはSSLクライアントを確認しません。

SSLクライアントを確認する場合やX.509証明書の認証機能が有効になっている場合、一連の信頼済み証明書はローカルで保存し、GWWSサーバーで指定する必要があります。 GWWSサーバーの信頼済み証明書を定義するには2つの方法があります。

リスト3-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サーバーの起動中に呼び出される関数のセットです。 Oracle SALTには、プラグインを定義して実装するための共通インタフェースとして、プラグイン・フレームワークが用意されています。 プラグインを実装するには、実際の関数が含まれているダイナミック・ライブラリを使用します。 実装ライブラリはGWWSサーバーの起動中に動的にロードされます。 関数は、プラグイン・インタフェースの実装として登録されます。

GWWSサーバーがライブラリをロードできるように、ライブラリは<Plugin>/<Interface>要素を使用してSALTDEPLOYファイルに指定する必要があります。

リスト3-12には、GWWSサーバーがロードする複数のカスタマイズされたプラグイン・ライブラリを構成するSALTDEPLOYファイルのセグメントを示します。

<Deployment ..>
  ...
  <System>
    <Plugin>
      <Interface lib=”plugin_1.so” />
      <Interface lib=”plugin_2.so” />
    </Plugin>
  </System>
</Deployment

高度なWebサービス・メッセージング機能の構成

現在のOracle SALTは以下の高度なWebサービス・メッセージング機能をサポートしています。

Webサービス・アドレス

Oracle SALTでは、着信サービスおよび発信サービスの両方にWeb Service 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の構成が必要です。

発信サービスのAddressingエンドポイントの構成

発信サービスについては、Web Service AddressingはWebサービス・バインディング・レベルで構成します。SALTDEPLOYファイルでは、各GWWSサーバーは、WS-Addressingを有効にするために参照された任意の発信WSBindingオブジェクトに対して、<WSAddressing>要素を使用してWS-Addressingエンドポイントを指定できます。

WS-Addressingエンドポイントを設定した後、GWWSサーバーは起動時にリスニング・エンドポイントを作成します。発信WSBindingに指定したすべてのサービスはWS-Addressingメッセージで呼出します。

リスト3-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>

WS-Addressingの無効化

SALTDEPLOYファイルでのWS-Addressingエンドポイントの作成の有無にかかわらず、WSDFで特定の発信サービスのAddressing機能を明示的に無効にできます。特定の発信サービスのAddressing機能を無効にするには、WSDFファイル内の対応する<Service>定義で「disableWSAddressing」プロパティを「true」に設定する必要があります。このプロパティは、着信サービスには影響しません。

リスト3-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>

Webサービスの信頼性のあるメッセージング

現在、Oracle SALTは着信サービスのみの信頼性のあるメッセージングをサポートしています。 信頼性のあるメッセージングの機能を有効にするには、Webサービスの信頼性のあるメッセージングのポリシー・ファイルを作成し、このポリシー・ファイルをWSDFに含める必要があります。 ポリシー・ファイルはWS-ReliableMessagingポリシー・アサーション仕様(2005年2月)に準拠している必要があります。

信頼性のあるメッセージングのポリシー・ファイルの作成

信頼性のあるメッセージングのポリシー・ファイルは、WS-ReliableMessagingのアサーションを含む一般的なWS-Policyファイルです。 WS-ReliableMessagingのアサーションは、サポート対象のWS-ReliableMessage仕様のバージョン、ソース・エンドポイントの再伝送までの時間間隔、送信元エンドポイントの承認までの時間間隔などの機能を説明するXMLセグメントです。

WS-ReliableMessagingポリシー・ファイルの形式の詳細は、Oracle SALTリファレンス・ガイドの「Oracle SALT WS-ReliableMessagingポリシー・アサーションのリファレンス」を参照してください。

リスト3-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ファイルで信頼性のあるメッセージング・ポリシー・ファイルの指定

ネイティブWSDFファイルでは、<Servicegroup>レベルにおいてWS-ReliableMessagingポリシー・ファイルを参照する必要があります。リスト3-16には、WS-ReliableMessagingポリシー・ファイルの参照方法を示します。

<Definition ...>
  <WSBinding ...>
    <Servicegroup ...>
      <Policy location=”RMPolicy.xml” />
      <Service ... />
      <Service ... />
      ...
    </Servicegroup ...>
  </WSBinding>
</Definition>

セキュリティ機能の構成

Oracle SALTでは、トランスポート・レベルとSOAPメッセージ・レベルの両方のレベルでセキュリティがサポートされます。以下のトピックでは、各レベルにおいてセキュリティ機能を設定する方法について説明します。

トランスポート・レベル・セキュリティの構成

Oracle SALTでは、SSLリンク・レベル・セキュリティを使用してポイントツーポイント・セキュリティが提供され、着信サービスおよび発信サービスの両方のサービス認証に対してHTTP基本認証メカニズムがサポートされます。

SSLリンク・レベル・セキュリティの設定

SSLを使用して着信エンドポイントでリンク・レベル・セキュリティを設定するには、エンドポイント・アドレスの前に接頭辞として「https://」を指定できます。この着信エンドポイントを使用するGWWSサーバーは、SSLリスニング・ポートを作成してWebサービス・クライアントをSSL接続で保護します。SSL機能では、証明書の設定を指定する必要があります。証明書の設定の詳細は、「証明書の構成」を参照してください。

発信エンドポイントへのSSL接続は、GWWSサーバーによって自動的に作成され、接頭辞「https://」のURLでパブリッシュされます。

着信HTTP基本認証の構成

Oracle SALTでは、Webサービスのクライアントを認証するかどうかは、Oracle Tuxedoセキュリティ・フレームワークによって決まります。Oracle 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の認証に使用されます。

発信HTTP基本認証の構成

Oracle SALTは、発信HTTP基本認証のユーザー資格証明を作成する認証プラグインの開発を支援します。発信HTTP基本認証はエンドポイント・レベルにおいて設定します。発信エンドポイントにおいて、HTTPメッセージでユーザー・プロファイルが必要の場合、WSDFファイル内でHTTPエンドポイント用HTTPレルムを指定する必要があります。GWWSサーバーは、ユーザー名とパスワードを作成するために認証プラグイン・ライブラリを呼出し、HTTP基本認証メカニズムを使用してリクエスト・メッセージに送信します。

リスト3-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ファイルに構成する必要があります。詳細は、「発信HTTP基本認証のOracle Tuxedoセキュリティ・レベルの構成」を参照してください。

発信認証プラグインを開発する方法の詳細は、『Webサービスのプログラミング』の「発信認証プラグインのプログラミング」を参照してください。

メッセージ・レベルのWebサービス・セキュリティの構成

Oracle SALTでは、メッセージ・レベル・セキュリティに対してWebサービス・セキュリティ1.0および1.1をサポートします。 Oracle SALTでは、以下を保証するためにメッセージ・レベル・セキュリティを使用できます。

Webサービス・セキュリティの主なユース・ケース

Webサービス・セキュリティのOracle SALTの実装: SOAPメッセージ・セキュリティの仕様は以下のユース・ケースをサポートします。

WS-Securityポリシー・ファイルの使用

Oracle SALTでは、メッセージ・レベル・セキュリティの使用例のために使用される複数のWS-Securityポリシー1.0および1.2のファイルが含まれています。

Oracle SALTが正常にインストールされると、WS-Policyファイルが$TUXDIR/udataobj/salt/policyに配置されます。

表3-8には、Oracle SALTに付属するデフォルトWS-Securityポリシー・ファイルを示します。

上述のWS-Security Policy 1.2 UserTokenファイル以外のすべてのポリシー・ファイルを、ネイティブWSDFファイルの<Servicegroup>または<Service>レベルで参照できます。WSSP 1.2 UserTokenファイルは、 <Servicegroup>レベルのみで参照できます。サンプル「wsseapp」には、WSSP 1.2 UserTokenファイルを<Service> レベルで使用するようにクリップする方法を示します。

リスト3-18には、サービス「TOUPPER」で、クライアントがプレーン・テキスト形式のUsernameTokenとリクエスト形式のX509v3Tokenを送信する必要があり、X.509トークンで署名付きメッセージのSOAP:Body部分も必要とする、ポリシー割当ての組合せを示します。

<Definition ...>
  <WSBinding id="simpapp_binding">

    <Servicegroup id="simpapp">
      <Policy location="salt:wssp1.2-Wss1.1-X509V3-auth.xml"/>
      <Service name="TOUPPER" >
        <Policy location="D:/wsseapp/wssp1.2-UsernameToken-Plain.xml"/>
        <Policy location="salt:wssp1.2-signbody.xml" use="input"/>
      </Service>
    </Servicegroup>
    ....
  </WSBinding>
  ......
</Definition>

ポリシーは、<Policy>要素の「location」属性で指定されます。接頭辞の「salt:」は、Oracle SALTに付属のデフォルト・ポリシー・ファイルがすでに使用されていることを示します。ユーザー定義ポリシー・ファイルは、ファイル・パスを直接指定して使用できます。

「signbody」ポリシーは、「use」属性を「input」に設定して使用する必要があります。これにより、ポリシーが入力メッセージに対してのみ適用されます。 出力メッセージのSOAP:Bodyを署名していないので、これは必要です。

SALT構成のコンパイル

SALT構成ファイルのコンパイルとは、XMLバージョンSALTDEPLOYファイルから(SALTCONFIG)ファイルのバイナリ・バージョンを生成することです。構成ファイルをコンパイルするには、wsloadcfコマンドを実行します。wsloadcfはデプロイメント・ファイルを解析してバイナリ・ファイルをロードします。

wsloadcfはデプロイメント・ファイル、インポートされたWSDFファイルおよびデプロイメント・ファイルに参照したWS-Policyファイルを読み込み、各ファイルのXMLスキーマ形式によって構文をチェックします。また、必要に応じて、SALTCONFIGというバイナリ構成ファイルをロードします。SALTCONFIGおよび(必要に応じて) SALTOFFSET環境変数は、SALTCONFIGファイルを指し、(必要に応じて)情報を格納する場所にオフセットします。

SALT構成ファイルは、あらかじめ定義したXMLスキーマ・ファイルに従ってwsloadcfにより検証されます。Oracle SALTで必要なXMLスキーマ・ファイルは$TUXDIR/udataobj/salt.ディレクトリに配置しています。

オプション「-n」を指定すると、wsloadcfはバイナリ・バージョンのSALTCONFIGを生成せずに、検証の目的にのみ実行できます。

wsloadcfの詳細は、Oracle SALTリファレンス・ガイドの「wsloadcf」を参照してください。

Oracle SALTのUBBCONFIGファイルの構成

Oracle SALT構成を設定およびコンパイルした後、Oracle Tuxedo UBBCONFIGファイルは、Oracle TuxedoアプリケーションにOracle SALTコンポーネントが適用されるように更新する必要があります。表3-9には、Oracle SALTのUBBCONFIGファイルの構成タスクを示します。

*SERVERSセクションでTMMETADATAサーバーの構成

Oracle SALTは、UBBCONFIGファイルに少なくとも1つのTMMETADATAサーバーを定義する必要があります。Tuxedoサービス定義にアクセスするスループットを増加するために、複数のTMMETADATAサーバーの指定も可能です。

リスト3-19には、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ドキュメントのTuxedoサービス・メタデータ・リポジトリの管理に関する項を参照してください。

*SERVERSセクションでGWWSサーバーの構成

SALTDEPLOYファイルに定義されたGWWSインスタンスを起動するには、UBBCONFIGファイルの*SERVERSセクションでGWWSサーバーを指定する必要があります。1つまたは複数のGWWSサーバー・インスタンスを並行してUBBCONFIGファイルに定義できます。各GWWSサーバーは、Oracle Tuxedoドメイン内でオプション「-i」を使用して、一意のインスタンスIDに割り当てる必要があります。インスタンスIDは、XMLバージョンのSALTDEPLOYファイルおよび生成されたバイナリ・バージョンのSALTCONFIGファイルに存在する必要があります。

リスト3-20には、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ファイルでシステム制限事項の更新

SALT GWWSサーバーでOracle Tuxedoドメインを構成するとき、Oracle SALTアプリケーションの要件によって、UBBCONFIG ファイルに定義されたOracle Tuxedoシステム制限事項を設計および更新する必要があります。

Oracle SALTでは、Oracle TuxedoドメインのTMMETADATAおよびGWWS内で次のシステム・サーバーを起動する必要があります。TMMETADATAおよびGWWSサーバー数は、MAXSERVERS値に指定する必要があります。

GWWSサーバーは、発信方向で作業する場合、外部wsdl:operationがOracle Tuxedoサービスでマップされ、GWWSサーバーを介して公開されます。すべてのGWWSサーバーによって公開されたサービス数は、MAXSERVICES値に指定する必要があります。

MAXACCESSERS値は、このアプリケーションの特定のマシン上のOracle Tuxedo掲示板と同時に接続できるクライアントおよびサーバーのデフォルトの最大数を指定するために使用します。TMMETADATAおよびGWWSサーバー数、最大同時Webサービス・クライアントのリクエスト数は、MAXACCESSERS値に指定する必要があります。

GWWSサーバーが着信方向で作業する場合、Webサービスの各クライアントは、Oracle Tuxedoシステムのワークステーション・クライアントと見なされます。したがって、GWWSサーバーをデプロイするマシンのUBBCONFIGで、MAXWSCLIENTSに有効な数値を構成する必要があります。番号を共有します。

GWWSサーバーの証明書のパスワード・フレーズの構成

Oracle SALTの証明書を設定する時にセキュリティのパスワード・フレーズを設定する必要があります。 GWWSサーバーは、SSLリンク・レベル暗号化やWebサービス・セキュリティX.509トークンおよび署名機能を有効化にする時、証明書を設定する必要があります。 証明書の秘密キー・ファイルを作成しパスワード・フレーズで暗号化する必要があります。

証明書に関連する機能を用いてGWWSサーバーが指定される場合、それらは秘密キー・ファイルを読み込み、パスワード・フレーズを使用してそれらを復号化するために必要です。各GWWSサーバーに対してパスワード・フレーズを構成するには、*SERVERSセクションにおける各GWWSサーバー・エントリの下にキーワードSEC_PRINCIPAL_NAMEおよびSEC_PRINCIPAL_PASSVARを指定する必要があります。 tmloadcfを使用してUBBCONFIGファイルをコンパイルする際には、管理者がパスワード・フレーズを入力する必要があり、これは秘密キー・ファイルを正しく復号化するために使用できます。

リスト3-21には、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 11gR1ドキュメントのUBBCONFIG(5)に関する項を参照してください。

Webサービス・クライアント用のOracle Tuxedo認証の構成

Oracle SALTのGWWSサーバーは、Webサービス・クライアントの有効性をチェックするためにOracle Tuxedo認証フレームワークに依存します。Oracle Tuxedoの従来のアプリケーションがすでに適用されている場合、Webサービス・クライアントは次のいずれかの方法でユーザー資格証明を送信する必要があります。

逆に、Oracle SALTに対してWebサービス・クライアントを認証する場合、Oracle TuxedoドメインでOracle Tuxedo認証を構成する必要があります。

Oracle Tuxedo認証の詳細は、Oracle Tuxedo 11gR1ドキュメントの 認証の管理に関する項を参照してください。

発信HTTP基本認証のOracle Tuxedoセキュリティ・レベルの構成

発信HTTP基本認証username /passwordをマッピングするためにOracle Tuxedoクライアントuid / gidを取得するには、UBBCONFIGファイルでOracle Tuxedoセキュリティ・レベルをUSER_AUTH、ACLまたはMANDATORY_ACLとして構成する必要があります。

リスト3-22には、UBBCONFIGファイルでセキュリティ・レベルACLを定義する方法を示すUBBCONFIGファイルのセグメントを示します。

*RESOURCES
IPCKEY ...
......
SECURITY ACL
......

Oracle SALTのOracle Tuxedo MPモードでの構成

MPモードのOracle Tuxedoドメイン内の複数のマシンで実行しているGWWSサーバーを設定するには、各Oracle Tuxedoマシンを異なるSALTDEPLOYファイルおよび一連の別々のコンポーネントで定義する必要があります。

以下のグローバル・リソースを別々のマシンに渡って広める必要があります。

2つのマシンでは、同じWSDFファイルを関連付けられて、同一の機能がある、異なるマシンで実行している2つのGWWSサーバーを指定できます。 ただし、以下のアーティファクトの伝播を手動で行う必要があります。

Oracle SALT 1.1からの移行

この項では、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サーバーを実行するには、次の手順に従います。

SALT 1.1構成ファイルを変換してSALT 2.0構成スタイルの採用

wsloadcfはSALT 1.1構成ファイルからバイナリ・バージョンのSALTCONFIGをロードする時、このSALT 1.1構成ファイルを1つのWSDFファイルと1つのSALTDEPLOYファイルに変換されます。

SALT 1.1構成から変換されたファイルを取得した後、SALT 2.0スタイルの構成で起動することをお薦めします。

リスト3-23には、指定された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ファイルおよびデプロイメント・ファイルを、リスト3-24およびリスト3-25に示します。

<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>

Oracle Tuxedo Webアプリケーション・サーバーの構成

Oracle TuxedoにおけるHTMLアプリケーションのサポートは、Apache HTTP Server 2、Oracle HTTP ServerまたはiPlanetなどのHTTPサーバー環境にインストールされるモジュールまたはプラグインと、Oracle TuxedoベースのCGIのようなプロトコルに準拠する専用のOracle Tuxedoサーバー、もしくはPHP、PythonまたはRubyのスクリプトまたはアプリケーションを実行しているスクリプト・エンジンのいずれかを使用して行われます。スクリプト・エンジンでは、アプリケーションがSymfony (PHP)、Django (Python)またはRails (Ruby)のようなフレームワークをベースとしてOracle Tuxedoサーバーとして稼働することが可能です。

詳細は、『Oracle SALTインストレーション・ガイド』の概要、システム要件に関する項をそれぞれ参照してください。

Apache HTTPおよびOracle HTTP Serverの構成

Apache HTTPおよびOracle HTTP Server用のOracle Tuxedoモジュールが含まれるライブラリは、Oracle Tuxedoの$TUXDIR/udataobj/mod_tuxedo.so (TUXDIRはOracle Tuxedoをインストールした場所を表します)の場所にあり、次のHTTPサーバーのインストール場所にコピーする必要があります。

このモジュールはHTTPサーバーのアドレス領域(同じプロセス)内で稼働し、HTTPリクエストをOracle Tuxedoサービスに転送します。次にOracle Tuxedoサービスから送信されたリプライを取得し、それをクライアント(HTMLブラウザ)に送り返します。これは事前定義済のスクリプトを使用してインストールされている共有ライブラリとして配信され、Apache HTTP Server 2またはOracle HTTP Server (OHS) 11gR1で同様に動作します。

一部の要素には構成が必要です。ApacheまたはOHSのhttpd.confファイルで次の構成手順を実行してください。

複数のOracle Tuxedoアプリケーション・サポート

単一の構成済HTTPサーバー・インスタンスを複数のOracle Tuxedoアプリケーションに結合することが可能です。これを実行するには、個々のtuxconfigパラメータを、httpd.confファイル内にある特定の<Directory>または<Location>に設定します。

たとえば、次のように指定します。

<Directory "/var/www/tux">

...

<IfModule tuxedo.c>

Tuxconfig /home/user/tuxapp/tuxconfig

TuxService myService

</IfModule>

</Directory>

この例では、/var/www/tuxパスから開始するすべてのリクエストが前に構成されたTuxconfig値を使用します。異なるアプリケーションにアクセスするためには、異なる<Directory>または<Location>が構成されている必要があります。

エラー

Oracle Tuxedoの呼出し(tpinit()、tpcall()、tpalloc()、tpfree()など)が原因のエラーはすべて、ApacheまたはOHSのエラー・ログに記録されます。このログ・ファイルは通常、'error_log'という名前の下にあるサーバー・インスタンス・ディレクトリの'logs'ディレクトリにあります。これらのエラーは生成中の呼出しを報告し、tpstrerror()関数出力に従ってエラーを出力します。

たとえば、次のように指定します。

MODTUX_CAT:1234: Error performing tpcall: 6 - TPENOENT - no entry found

Tuxedoに関連しないエラー(メモリー割当て、tuxconfigコマンド構文エラーなど)は同様のエラー・メッセージを同じ場所に出力しますが、tpstrerror()出力は付加されません。

mod_tuxedoによって生成されたエラーによって、リスト3-1に示すように内部サーバー・エラーがクライアント・ブラウザに返されます。

制限

HTTPプロセス・サーバーがスレッドまたはハイブリッド・スレッド(mpm_workerモジュール)モードを使用して動作している可能性があるため、mod_tuxedoはOracle Tuxedoアプリケーションにマルチコンテキスト・モードで結合します。

iPlanet Web Serverプラグインの構成

iPlanet用のOracle Tuxedo NSAPIプラグインが含まれるライブラリは、Oracle Tuxedoの$TUXDIR/udataobj/tux_nsapi.so (TUXDIRはOracle Tuxedoをインストールした場所を表します)の場所にあり、次の場所にコピーする必要があります。

iPlanetのインストール場所: <iPlanet install directory>/plugins
これによってiPlanet Web Serverが正しくロードできるようになります。

このプラグインはHTTPサーバーのアドレス領域(同じプロセス)内で稼働し、HTTPリクエストをOracle Tuxedoサービスに転送します。次にOracle Tuxedoサービスのリプライを取得し、それをクライアント(HTMLブラウザ)に送り返します。そして、事前定義済のスクリプトを使用してインストールされている共有ライブラリとして配信されます。

ライブラリは通常、<iPlanet install directory>/pluginsの場所にあります。一部の要素には構成が必要なため、次の手順に従います。

WEBHNDLRサーバーの構成

WEBHNDLRサーバーはOracle Tuxedoシステム・サーバーで、Webアプリケーションとして稼働するようにPHP、PythonおよびRubyスクリプトを組み込むことができます。

これらのWebアプリケーションはPHP用のスタンドアロン・スクリプト、Python用のWSGI準拠のスクリプト、またはRuby用のRack準拠のスクリプトなどになります。これによってSymfony (PHP)、Django (Python)またはRails (Ruby)などのフレームワークをOracle Tuxedoサーバーとして実行できます。

スクリプト言語ベースのアプリケーションを実行するOracle Tuxedoサーバーは、両方の環境を利用できます。

詳細は、Oracle SALTコマンド・リファレンス・ガイドのWEBHNDLR(5)に関する項と、Oracle SALTプログラミング・ガイドのWebアプリケーション・プログラミングに関する項を参照してください。

Oracle Tuxedo SCAコンポーネントの構成

Oracle Tuxedo SCAコンポーネントの構成には、次のタスクがあります。

SCA ATMIクライアントの構成

SCA ATMIクライアントは、SCAパラダイムで記述し、buildscaclientユーティリティで構築するネイティブOracle Tuxedoクライアントです。クライアントの実行ファイルは、root.compositeファイルが格納されるディレクトリのサブディレクトリに格納する必要があります。

リスト3-27には、クライアント・アプリケーションのルート・コンポジット・ファイル$APPDIR/root.compositeを示します。

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="testApp">
       <component name="testStringClientComp">
              <implementation.composite name="ECHO"/>
       </component>
</composite>

$APPDIR/ECHOディレクトリにはECHOアプリケーションが格納されています。ディレクトリ名「ECHO」は、<implementation.composite name="ECHO"/>に指定された名前と一致する必要があります。リスト3-28には、クライアント・アプリケーションのコンポジット・ファイルを示します。

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="ECHO">
  <reference name="ECHO">
    <interface.cpp header="ECHO.h"/>
      <binding.atmi requires="legacy"> 
        <tuxconfig>/tux/application/ECHOServer/tuxconfig</tuxconfig> 
          <inputBufferType target="TestString">STRING</inputBufferType>
          <outputBufferType target="TestString">STRING</outputBufferType>
          <errorBufferType target="TestString">STRING</errorBufferType>
       <binding.atmi>
  </reference>
</composite>

このディレクトリには、このクライアント・アプリケーションのクライアント・ダイナミック・リンク・ライブラリも格納されます。たとえば、リスト3-28の例を使用すると、$APPDIR/ECHO/ECHO.so共有オブジェクトがECHOディレクトリに格納されます。ターゲット「TestStr」は、バッファ・タイプのグループ化に使用します。

このディレクトリには、クライアントの実行ファイルも格納されます。クライアント・アプリケーションに関連付けられたネーミング規則はありません。このクライアントECHOアプリケーションは、ECHOアプリケーション・ディレクトリに「doEchoClient」が含まれる可能性が非常に高くなります。たとえば、$APPDIR/ECHO/doEchoClientとなります。

SCA JATMIクライアントの構成

JATMIクライアント・アプリケーションの構成コンポジット・ファイルは、Java .jarファイルの一部です。JATMIクライアントのコンポジット・ファイルは、パッケージの一部ではなく、.jarファイルのベースに配置されます。クライアント・アプリケーションを呼び出すと、SCA Javaランタイムによってコンポジット・ファイルがロードされます。特別なセットアップは必要ありません。

リスト3-29には、SCA JATMIのクライアント・コンポジット・ファイルの例を示します。

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:f="binding-atmi.xsd"
name="EchoComposite">
       <reference name="ECHO" promote="EchoComponent/ECHO">
              <interface.java class="com.abc.sca.java.Echo" />
              <f:binding.atmi requires="legacy">
                     <f:serviceType>RequestResponse</f:serviceType>
                     <f:inputBufferType>FML</f:inputBufferType>
                     <f:outputBufferType>FML</f:outputBufferType>
                     <f:fieldTables>com.abc.sca.java.fml.FMLTABLE
                     </f:fieldTables>
                     <f:workStationParameters>
                            <f:networkAddress>//STRIATUM:15011
                            </f:networkAddress>
                     </f:workStationParameters>
              </f:binding.atmi>
       </reference>
       <component name="EchoComponent">
              <implementation.java
              class="com.abc.sca.java.EchoComponentImpl />
       </component>
</composite>

SCAワークステーション・クライアントの構成

SCAワークステーション・クライアントの構成は、SCAネイティブ・クライアントの構成に似ています。1つの相違点は、SCAワークステーション・クライアントの場合、コンポジット内で<workStationParameters>要素とそのサブ要素を使用する必要があることです。SCAランタイムは、クライアントがSCAネイティブ・クライアントとSCAワークステーション・クライアントのどちらで構築されたかを自動的に検出し、それに応じて適切な参照バインディング・ライブラリをロードします。

SCA Oracle Tuxedoワークステーション・クライアントのディレクトリ階層も、SCAネイティブ・クライアントに似ています。どちらの場合も、環境変数$APPDIRを使用して、クライアント・アプリケーションの場所を指定します。

リスト3-30およびリスト3-31には、SCA Oracle Tuxedoワークステーション・クライアントの構成の例を示します。

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="testApp">
       <component name="testStringClientComp">
              <implementation.composite name="ECHO"/>
       </component>
</composite>

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="ECHO">
  <reference name="ECHO">
    <interface.cpp header="ECHO.h"/>
      <binding.atmi requires="legacy">        
        <inputBufferType target="TestString">STRING</inputBufferType>
        <outputBufferType target="TestString">STRING</outputBufferType>
        <errorBufferType target="TestString">STRING</errorBufferType>
      <workStationParameters>
        <networkAddress>//STRIATUM:4890</networkAddress>
        <encryptBits>128/128</encryptBits>
      </workStationParameters>
      <remoteAccess>WorkStation</remoteAccess>
      </binding.atmi>
  <reference>
</composite>

SCA Webサービス・クライアントの構成

SCA Webサービス・クライアントは、基本的にはSCAネイティブ・クライアントと同じですが、<binding.atmi>要素ではなく<binding.ws>要素を使用する点が異なります。SCAランタイムは、クライアントが使用しているバインディングを自動的に検出し、それに応じて適切な参照バインディングをロードします。

SCA Webサービス・クライアントのディレクトリ階層も、ネイティブ・クライアントに似ています。どちらの場合も、$APPDIR環境変数を使用して、クライアント・アプリケーションの場所を指定します。

リスト3-32およびリスト3-33には、SCA Webサービス・クライアントの構成の例を示します。

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="testApp">
       <component name="calcClient">
              <implementation.composite name="calcClient"/>
       </component>
</composite>

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"name="calcClient">
       <reference name="Calculator">
              <interface.cpp header="CalcService.h"/>
              <binding.ws
              endpoint="http://calc.sample#wsdl.endpoint
              (Calculator/CalculatorSOAP11port)"/>
       </reference>

</composite>

<interface.cpp>要素は、適切なプロキシ・スタブを構築するために必要です。また、<binding.ws>に指定したエンドポイントを配置するクライアント・ディレクトリに、WSDLファイルを格納する必要があります。さらに、次の手順に従って、Oracle Tuxedo Webサービス・ゲートウェイ(GWWS)を構成する必要もあります。

SCA ATMIサーバーの構成

SCA ATMIサーバーでは、SCA ROOTは$APPDIRと同じです。SCAアプリケーションを記述するのに少なくとも1つのコンポジット・ファイルが必要です。SCAランタイムは、このコンポジット・ファイルを検索し、そこから、Oracle Tuxedo環境でホストするSCAサーバー・アプリケーションのすべてのcompositeおよびcomponentTypeファイルをロードします。

リスト3-35には、Oracle Tuxedoアプリケーション・ドメインでホストする2つのSCAアプリケーションが含まれている、root.compositeという名前のルート・コンポジット・ファイルを示します。2つのアプリケーションの名前は、PurchaseおよびFinanceです。これらの2つのSCAアプリケーションには、少なくとも2つのサブディレクトリがあります。1つはPurchase.component、もう1つはFinance.componentという名前です。

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="root">
       <component name="Purchase.component">
              <implementation.composite name="Purchase" />
       </component>
       <component name="Finance.component">
              <implementation.composite name="Finance" />
       </component>
</composite>

リスト3-36では、Purchase.componentディレクトリには、Purchaseアプリケーションのコンポジット・ファイルPurchase.compositeが格納されることを示します。同様に、Finance.componentディレクトリには、Financeアプリケーションのコンポジット・ファイルFinance.compositeが格納されます。

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
       name="Purchase">
       <service name="purchase">
              <interface.cpp header="Purchase.h" />
       <binding.atmi requires="legacy">
              <map target="Order">ORDER</map>
              <map target="TrackOrder">TRACKORDER</map>
       </binding.atmi>
       <reference>PurchaseServiceComponent</reference>
       </service>
       <component name="PurchaseServiceComponent">
              <implementation.cpp library="Purchase" header="PurchaseImpl.h" />
       </component>
</composite>

リスト3-37では、Purchase.compositeは、$APPDIR/Purchase.componentディレクトリにPurchaseImpl.componentTypeファイルが格納され、アプリケーション実装としてCPPを使用していることを示します。この構成を使用するSCAサーバーをbuildscaserverユーティリティを使用して構築すると、実行時に2つのSCAサービス(ORDERおよびTRACKORDER)が自動的に公開されます。サービスの実際のCPP実装は、OrderおよびTrackOrderという名前になります。

<?xml version="1.0" encoding="UTF-8"?>
<componentType xmlns="http://www.osoa.org/xmlns/sca/1.0"
              xmlns:xs="http://www.w3.org/2001/XMLSchema">
       <service name="purchase">
              <interface.cpp header="Purchase.h"/>
       </service>
</componentType>

Oracle Tuxedo内でホストしbuildscaserverで構築するこれらの2つのSCAアプリケーションが、PurchaseSvrおよびFinanceSvrという名前だと仮定します。UBBCONFIGファイルの*SERVERSセクションに次の行を追加する必要があります。

PurchaseSvr SRVGRP=PURCHASEGRP SRVID=500

FinanceSvr SRVGRP=FINANCEGRP SRVID=600

*SERVICESセクションにサービスを追加する必要はありません。Oracle TuxedoでホストするSCAサービスは動的に公開されます。

SCA Webサービス・サーバーの構成

コンポーネントのWebサービス・バインディングの構成(サーバー側)は、SCAコンポーネントをホストするためのATMIバインディングの構成に似ています。

リスト3-38には、root.compositeという名前のルート・コンポジット・ファイルを示します。これには、Oracle Tuxedoアプリケーション・ドメインでホストする1つのSCAコンポーネントが含まれます。2つのアプリケーションの名前は、PurchaseおよびFinanceです。これらの2つのSCAアプリケーションには、少なくとも2つのサブディレクトリがあり、1つはPurchase.component、もう1つは Finance.componentという名前です。

リスト3-39には、実際のコンポーネント・サブディレクトリを示します。リスト3-40には、componentTypeサイドファイルを示します。

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="root">
       <component name="account">
              <implementation.composite name="account" />
       </component>
</composite>

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
       name="account">
              <service name="AccountService">
                     <interface.wsdl interface="http://www.bigbank.com/AccountService#wsdl.interface(AccountService)"/>
                     <binding.ws/>
                            <reference>AccountServiceComponent</reference>
              </service>

       <component name="AccountServiceComponent">
              <implementation.cpp library="Account" header="AccountServiceImpl.h"/>
       </component>
</composite>

<?xml version="1.0" encoding="UTF-8"?>
<componentType xmlns="http://www.osoa.org/xmlns/sca/1.0"
       xmlns:xs="http://www.w3.org/2001/XMLSchema">
       <service name="AccountService">
              <interface.cpp header="AccountService.h"/>

       </service>
</componentType>

上述のSCAコンポーネントは、-wオプション(Webサービスに対して)を指定したbuildscaserverを使用して構築され、WSServerという名前のOracle Tuxedoサーバーでホストされます。

ここで、Oracle Tuxedo UBBCONFIGファイルの*SERVERSセクションに、WSServer SRVGRP=ACCTGRP SRVID=500という行を追加する必要があります。

*SERVICESセクションにサービスを追加する必要はありません。Oracle TuxedoでホストするSCAサービスは動的に公開されます。

さらに、Oracle Tuxedo Webサービス・ゲートウェイ(GWWS)を構成する必要があります。次の手順に従います。

SCAクライアントのセキュリティの構成

Oracle Tuxedo SCAコンポーネントでは、次の2種類のセキュリティがサポートされます。

Oracle Tuxedoアプリケーション・ドメイン・セキュリティ

Oracle Tuxedoアプリケーション・ドメインのTUXCONFIGファイルの*RESOURCESセクションにSECURITYキーワードを追加すると、Oracle Tuxedoアプリケーション・ドメイン・セキュリティが設定されます。アプリケーション・セキュリティのレベルには、NONE、APP_PW、USER_PW、ACLおよびMANDATORY_ACLの5つがあります。NONE以外のすべてのセキュリティ・レベルでは、Oracle Tuxedoアプリケーションへのアクセスを取得するため、少なくともユーザーからのアプリケーション・パスワードが必要になります。USER_PWレベル以上では、ユーザーを認証してユーザー資格証明を確立するために、追加のユーザー・パスワードが必要になります。合計で2つのパスワードを構成する必要がある可能性があります。

すべてのSCAクライアントは、Oracle Tuxedoアプリケーション・サーバーへのアクセスを取得するために、このパスワード情報が必要になります。SCAクライアントがパスワード情報を取得するには、次の2つの方法があります。

Oracle SALT管理者がパスワードの取得を構成するには、次のタスクを実行する必要があります。

リスト3-42およびリスト3-43には、SCA ATMIクライアント・アプリケーションの例を示します。

<?xml version="1.0" encoding="UTF-8"?>

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
       name="simple.app">
       
       <component name="simpapp.TuxClient">
              <implementation.composite name="simpapp.client"/>
              <reference name="TOUPPER">tuxToupper</reference>
       </component>

</composite>

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" 
name="simpapp.client">

  <reference name="TOUPPER">
    <interface.cpp header="ToupperTuxService.h"/>
    <binding.atmi requires="legacy">
      <tuxconfig>d:\tests\tuxedo\sca\tests\TUXCONFIG</tuxconfig>
      <inputBufferType target="charToup">STRING</inputBufferType>
      <outputBufferType target="charToup">STRING</outputBufferType>
        <authentication
          <passwordIdentifier>aaa</passwordIdentifier>
        </authentication>
    </binding.atmi>
  </reference>
</composite>

上述のコンポジットでは、Oracle Tuxedoアプリケーション・ドメインのパスワード識別子「aaa」を定義しており、これにより、ATMI参照バインディングが、実行時に、識別子「aaa」でpassword.storeファイルからパスワードを取得できるようにしています。必要なユーザー認証によって、Oracle Tuxedoアプリケーション・ドメイン・セキュリティを強化できます。その場合、セキュリティ・レベルをSECURITY=USER_PW以上に設定して、scapasswordtool -i crusoe -aコマンドを使用します。

次に、テキスト・エディタやsimpapp.client.compositeファイルを編集できるその他のツールを使用して、<binding.atmi/authentication> 要素に<userPasswordIdentifier>crusoe</userPasswordIdentifier>というエントリを追加します。

これで、パスワード「crusoe」を使用するすべてのユーザーが、Oracle Tuxedoアプリケーションにアクセスできるようになります。

Oracle Tuxedoリンク・レベル・セキュリティ

Oracle Tuxedoリンク・レベル・セキュリティには2種類あります。1つはリンク・レベルの暗号化(LLE)を使用して簡単に構成できるもの、もう1つはより一般的に使用されるトランスポート層セキュリティ(TLS)です(Secure Sockets Layer(SSL)とも呼びます)。ネイティブのATMI参照バインディングを使用するSCA ATMIクライアントの場合は、トランスポート・メソッドがネイティブ・メッセージ・キューでありOracle Tuxedo BRIDGEであるため、SCAレベルでリンク・レベル・セキュリティを構成する必要はありません。

SCA JATMIクライアントの参照バインディングでは、リンク・レベル・セキュリティはサポートされません。リンク・レベル・セキュリティの構成が可能な唯一のSCAクライアントは、SCAワークステーションATMIクライアントです。

SCAワークステーションATMIクライアントでは、コンポジット・ファイルに構成された<workStationParameters>要素が含まれています。SCAランタイムは、このタイプのクライアントに適した参照バインディングを自動的にロードします。

リンク・レベルの暗号化を構成する

リンク・レベルの暗号化を構成するには、コンポジット・ファイルに<encryptBits>要素を追加します。LLEでは、次の要素を構成しないようにしてください。それらはSSL暗号化に固有であり、SSL暗号化を使用していると見なされるためです。

<encryptBits>要素には、このクライアントがネゴシエートを試みる暗号化の強度を指定します。<encryptBits>要素の構文は、<minimum encryption strength>/<maximum encryption strength>です。最小の56ビット暗号化を構成するには、コンポジット・ファイルに次のエントリを追加する必要があります。

<networkAddress>//STRIATUM:8741</networkAddress>

<encryptBits>56/128</encryptBits>

これにより、SCAワークステーション参照バインディングでは、WSHとのネゴシエートにおいて強度が56から128ビットの暗号化が必要と判断されます。 UBBCONFIGファイルの*SERVERSセクションに、次の行を追加する必要もあります。

WSL SRVGRP=GROUP1 SRVID=1001 CLOPT="-A -- -n //STRIATUM:8741 -a -z 56 -Z 256

トランスポート・レベル・セキュリティを構成する

TLS/SSLによるリンク・レベル・セキュリティを有効にするには、<encryptBits>に加えて、secPrincipalName、secPrincipalLocation、およびsecPrincipalPassIdを構成する必要があります。

これら3つのパラメータにより、SCAワークステーションATMIクライアントがTLS/SSL接続を確立する必要がある場合のパラメータを指定します。

リスト3-44には、TLS/SSLを構成する際に、/binding.atmi/workStationParameters内のクライアント・コンポジット・ファイルに追加する必要がある行を示します。

<networkAddress>//STRITUM:8742</networkAddress>
<secPrincipalName>crusoe</secPrincipalName>
<secPrincipalLocation>/tux/udataobj/security/keys/crusoe.pem</secPrincipalLocation>
<secPrincipalPassId>crusoe</secPrincipalPassId>

Oracle Tuxedoでは、クライアントがポート8742で接続する場合にTLS/SSLを使用することを示すために、WSLに-S 8742 を追加する必要があります。

WSL  SRVGRP=GROUP1 SRVID=1001
       CLOPT="-A -- -n //STRIATUM:8741 -S 8742 -z 56 -Z 128"

サービス規約検索の構成

サービスの検索を有効にすると、サービスを提供するサーバーによってサービス規約情報が収集され、この情報が TMMETADATA(5)で実装された内部サービスに送信されます。通信のオーバーヘッドを軽減するため、同じサービス規約は1回のみ送信されます。

サービス規約は、TMMETADATA サーバーによって収集されたデータに基づいて生成されます。規約情報は、メタデータ・リポジトリに格納するか、テキスト・ファイルに出力しておいてtmloadreposでメタデータ・リポジトリにロードできます。Oracle SALTでは、tmscdコマンドを使用してサービス規約の実行時収集を管理できます。詳細は、Oracle SALTコマンド・リファレンス・ガイドのtmscdに関する項を参照してください。

生成されたサービス規約情報には、サービス名、リクエスト・バッファ情報、応答バッファ情報、およびエラー・バッファ情報(エラーがある場合のみ)が含まれます。TMMETADATAサーバーへの送信が失敗した場合、収集されたサービス規約情報は破棄されます。バッファ情報には、バッファ・タイプ、サブタイプ、およびFML/FML32のフィールド情報(name、type、subtype)が含まれます。

検索は、FML32バッファ内のすべての埋め込みバッファでサポートされます。 FML/FML32フィールドが出現すると、検索によってメタデータ・リポジトリ内のcount/requiredcountのパターンが自動的に更新されます。 フィールドの出現がパターンに影響することはありませんが、「requiredcount」で最小出現回数を指定できます。規約検索の期間全体での最大出現回数は「count」で指定します。

VIEW/VIEW32/X_C_TYPE/X_COMMONの場合は、ビュー名のみが検索されます。 ORACLE SALTでメタデータ・リポジトリを使用している場合は、ビュー名に基づいてビューの詳しい説明を生成できます。

サポートされるのは、アプリケーションATMIサービス(ローカル、または/TDOMAINゲートウェイ経由でインポートされたもの)のみです。 サービス規約検索では、以下のサービスはサポートされません。

tpforwardのサポート

サービスがtpreturn()のかわりにtpforward()を発行すると、そのサービスの応答バッファ情報が転送先のサービスの応答バッファ情報と同じになります。次に例を示します。

サービス規約のテキスト・ファイル出力

収集されたサービス規約検索情報を、メタデータ・リポジトリに直接格納するかわりにファイルに書き出す場合、 TMMETADATA(5) -o<filename>オプションを使用し、tmloadreposを使用して、ファイルをメタデータ・リポジトリに手動でロードする必要があります。詳細は、Oracle Tuxedoコマンド・リファレンス・ガイドのtmloadreposに関する項を参照してください。

ファイルをメタデータ・リポジトリのかわりのストレージとして使用する場合、出力はtmloadreposで設定されたフォーマットに準拠しています。このファイルは、サービス・ヘッダー・セクションと、パラメータごとのパラメータ・セクションで構成されます。サービス・ヘッダーには、表3-10に示す項目が含まれます。「service」フィールドのフォーマットは、<TuxedoServiceName>+'_'+<SequenceNo>です。Oracle Tuxedoサービスに複数のパターンが認識された場合に名前の競合を避けるため、接尾辞 <SequenceNo>が使用されます。

サービス・パラメータには、表3-11に示す項目が含まれます。

サンプル

例1:

入力: service=SVC, request=STRING, reply = TPSUCCESS + STRING

出力パターン: service=SVC_1,tuxservice=SVC,inbuf=STRING,outbuf=STRING

例2:

入力: service=SVC, request=STRING, reply = TPFAIL+ STRING

出力パターン(抜粋): Service=SVC_1, tuxservice=SVC,inbuf=STRING,outbuf=NULL,errbuf=STRING

例3:

入力:

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

例4:

入力: 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)

例5:

入力:

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)

Oracle SALT WS-TXサポートの構成

この項の内容は次のとおりです。

トランザクション・ログ・デバイスの構成

Oracle Tuxedoまたは/DomainのTLogファイルと同様に、トランザクション・ログ(TLogDevice)要素を使用して、GWWSシステム・サーバーを構成する必要があります。リスト3-45に示すように、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の登録リクエストを許可し、それに応じてこれらを処理します。

WS-TXトランザクションの構成

図3-2では、典型的なWS-ATコンテキスト・サービスの呼出しのアプリケーションとプロトコルのフローを示します。

Oracle SALT GWWSゲートウェイの構成手順および実行時の動作を、(図3-2に示すようなOracle Tuxedoドメインのロールに応じて)次の項に示します。

着信トランザクションの構成

Webサービスとして公開されたOracle Tuxedoサービスは、着信WS-ATトランザクション・リクエストに関連付けられたローカル・トランザクションを開始するために、トランザクション・ログ・ファイルを作成しGWWSデプロイ構成ファイルにこれを追加する以外の固有の構成を必要としません。

トランザクションをOracle Tuxedoドメインに伝播できることを確認するためには、次の手順を実行します。

エラー条件

エラー条件は次のように処理されます。

発信トランザクションの構成

Oracle Tuxedoクライアントが外部WebサービスへのOracle Tuxedoグローバル・トランザクションを伝播するために、次の手順を実行します。

エラー条件

エラー条件は次のように処理されます。

トランザクションの最大数の構成

リスト3-46に示すように、MaxTran要素を使用して、内部トランザクション表のサイズを構成できます。デフォルトは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ファイル

policy.xmlファイルには、WS-ATポリシー要素が含まれます。リスト3-47に示すように、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の消費は、構成された値に基づいて決定し、通常の場合のように、実行時の動作が続きます。

発信トランザクション

WSDLの生成

WSDLの生成が拡張されて、対応するサービスのポリシー・ファイルに構成されたアサーションに対応するATAssertion要素が生成されます。

WSDLの変換

発信リクエストでは、WSDL変換ツールであるwsdlcvtが、ATAssertion要素を含むpolicy.xmlファイルを生成します(処理されたWSDL内に存在する場合)。policy.xmlファイルの場所を、SALTDEPLOYソースに適切に構成する必要があります。

関連項目