サービス・コンポーネント・アーキテクチャ

     前  次    新規ウィンドウで目次を開く    PDFとして表示 - 新規ウィンドウ  Adobe Readerを取得 - 新規ウィンドウ
コンテンツはここから始まります

Oracle Tuxedo SCAコンポーネントの管理

この章では、次の項について説明します。

 

Oracle Tuxedo SCAデプロイメント・モデル

SCAコンポジットは、関連付けられた構成ファイル内に記述し、ファイル名の末尾を「.composite」にするのが一般的です。このファイルでは、サービス・コンポーネント定義言語(SCDL)というXMLベースのフォーマットを使用して、コンポジットに含めるコンポーネントを記述したり、コンポーネント間の関係を指定したりします。Oracle Tuxedo SCAをデプロイするためには、少なくとも1つのルート・コンポジット・ファイルを$APPDIRに配置する必要があります。

次に示すように、2種類の構成ファイルがあります。

ルートのコンポジット・ファイルには、1つまたは複数のコンポーネントを構成できます。各コンポーネントのサブディレクトリには、そのコンポーネント独自の.compositeファイルと.componentTypeファイルが格納されます。

SCAコンポジットの構成ファイル

コンポジット内には、ゼロ個以上のコンポーネント要素を含めることができます。ルートのコンポジット・ファイルは、サーバー環境の$APPDIR内に格納する必要があります。

リスト1-1に、2つのコンポーネントからなるルート・コンポジットのサンプルを示します。

リスト1-1 2つのコンポーネントからなるルート・コンポジット 
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="ECHO.app">
       <component name="ECHO">
              <implementation.composite name="ECHO" />
       </component>
       <component name="TOUPPER">
              <implementation.composite name="TOUPPER" />
       </component>
</composite>

リスト1-1の構成に基づいて、リスト1-2では、暗黙的なディレクトリ階層を示します。

リスト1-2 SCAコンポジットのディレクトリ階層 
$APPDIR/ECHO.app.composite
$APPDIR/ECHO
$APPDIR/ECHO/ECHO.composite
$APPDIR/ECHO/ECHO.componentType
$APPDIR/TOUPPER
$APPDIR/TOUPPER/TOUPPER.composite
$APPDIR/TOUPPER/TOUPPER.componentType

この例は典型的なサーバー構成です。Oracle Tuxedo SCAクライアントのアプリケーション・トポロジもこれとよく似ており、クライアント・アプリケーションをルートのコンポジット・ファイルのサブディレクトリに配置します。リスト1-3では、ECHOによって提供されるECHO1サービスを使用するEchoClientというクライアントのディレクトリ構造を示します。

リスト1-3 ディレクトリ構造 
$APPDIR/root.composite
$APPDIR/EchoClient/EchoClient.composite
$APPDIR/EchoClient.composite
$APPDIR/EchoClient/EchoClient.dll
$APPDIR/EchoClient/EchoClient.exe
注意: SCAサーバー環境と違い、SCAクライアント環境ではコンポーネント構成ファイルを環境内に配置する必要はありません。

SCAコンポーネントの構成ファイル

コンポーネントとは、SCAアセンブリ内のビジネス機能の基本要素です。これらのコンポーネントをSCAコンポジットによって結合することでビジネス・ソリューションが完成します。コンポーネントは、実装の構成済インスタンスです。サービスを提供し、サービスを消費します。複数のコンポーネントで同じ実装を使用し、それぞれ違う実装として構成することも可能です。

コンポーネントは、xxx.compositeファイル内でコンポジットのサブ要素として宣言します。1つのコンポーネントは、コンポジット要素の子である1つのコンポーネント要素で表現します。リスト1-1のコンポジットを使用して、2つのコンポーネント(ECHOおよびTOUPPER)に情報を含めます。ECHOサービス($APPDIR/ECHO/ECHO.composite)のECHO.compositeの情報をリスト1-4に示します。

リスト1-4 ECHO.composite 
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
       name="ECHO">
       <service name="ECHO">
              <interface.cpp header="ECHO.h" />
              <binding.atmi requires="legacy">
                     <map target="EchoString1">ECHO1</map>
                     <map target="EchoString2">ECHO2</map>
              </binding.atmi>
              <reference>EchoServiceComponent</reference>
       </service>
       <component name="EchoServiceComponent">
              <implementation.cpp library="ECHO" header="ECHOImpl.h" />
       </component>
</composite>

ECHOサービスは、2つのOracle Tuxedoサービス(ECHO1およびECHO2)を提供します。ECHO1は、CPP関数「EchoString1」を実行します。ECHO2は、CPP関数「EchoString2」を実行します。ここでは、$APPDIR/ECHO/ECHOImpl.componentTypeおよび$APPDIR/ECHO/ECHO.soの存在が暗示されています。リスト1-5では、ECHOImpl.componentTypeに含める情報の例を示します。

注意: 一部のUNIXシステムでは、接尾辞が.so.71または.slになります。

ECHO.so(WindowsではECHO.dll)は、EchoString1とEchoString2の実装が格納された共有ライブラリで、サービスの初期化時にメモリーにロードされます。ECHO1およびECHO2は、サーバーの初期化時に動的に公開されます。たとえば、これら2つのサービスを提供するOracle TuxedoサーバーがEchoServerである場合は、Oracle Tuxedo UBBCONFIGファイルにリスト1-6に示すような情報を含める必要があります。

リスト1-5 ECHOImpl.componentType 
<?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="ECHO">
              <interface.cpp header="ECHO.h"/>
       </service>
</componentType>
リスト1-6 UBBCONFIGファイルの例 
...
*SERVERS
DEFAULT:
       CLOPT="-A"
EchoServer  SRVGRP=GROUP1 SRVID=1001
...

TOUPPERサービスの場合は、ECHO.app.compositeファイルによって$APPDIR/TOUPPER/TOUPPER.compositeの存在も暗示されます。リスト1-7に、TOUPPER.compositeファイルに含める情報の例を示します。

リスト1-7 TOUPPER.compositeファイルのサンプル 
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
       name="TOUPPER">
       <service name="TOUPPER">
              <interface.cpp header="TOUPPER.h" />
                     <binding.atmi requires="legacy">
                            <map target="UpperString1">TOUPPER1</map>
                            <map target="UpperString2">TOUPPER2</map>
                     </binding.atmi>
              <reference>ToupperServiceComponent</reference>
       </service>

       <component name="ToupperServiceComponent">
              <implementation.cpp library="TOUPPER" header="TOUPPERImpl.h" />
       </component>
</composite>

このコンポジット・ファイルでも、$APPDIR/TOUPPER/TOUPPERImpl.componentTypeおよび$APPDIR/TOUPPER/TOUPPER.soの存在が暗示されています。

注意: Oracle Tuxedo SCAでサポートされる実装タイプは、「cpp」のみです。

 

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

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

SCA ATMIクライアントの構成

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

注意: APPDIR環境変数に、root.compositeファイルのディレクトリを指定する必要があります。

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

リスト1-8 クライアント・アプリケーションのルート・コンポジット・ファイル 
<?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"/>に指定された名前と一致する必要があります。リスト1-9には、クライアント・アプリケーションのコンポジット・ファイルを示します。

リスト1-9 クライアント・アプリケーションのコンポジット・ファイル 
<?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>

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

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

注意: SCA_COMPONENTを設定する必要があります。リスト1-9では、SCA_COMPONENT=testStringClientCompとなります。

SCA JATMIクライアントの構成

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

注意: クライアント・アプリケーションの.jarファイルはCLASSPATHに含める必要があります。次の.jarファイルもCLASSPATHの一部に含める必要があります。

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

リスト1-10 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を使用して、クライアント・アプリケーションの場所を指定します。

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

リスト1-11 $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>
リスト1-12 $APPDIR/ECHO/ECHO.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環境変数を使用して、クライアント・アプリケーションの場所を指定します。

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

リスト1-13 $APPDIR/root.composite 
<?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>
リスト1-14 $APPDIR/calcClient/calcClient.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)を構成する必要もあります。

  1. TMMETADATAおよびGWWSサーバーが停止していることを確認します。
  2. 使用するサービスのWSDLで、wsdlcvtを実行します。これにより、WSDFファイル、Oracle Tuxedoメタデータ・リポジトリのインタフェース定義ファイル、fml32フィールド表、およびXMLスキーマが生成されます。
  3. 必要に応じ、生成されたWSDFファイルを修正して、実行時に使用する実際のエンドポイント・アドレスをオーバーライドします。詳細は、WSDFのドキュメントを参照してください。
  4. Oracle Tuxedoメタデータ・リポジトリのインタフェース定義を、TMMETADATAサーバー・リポジトリにロードします(例: $ tmloadrepos -I calc.mif metadata.repos -y)。詳細は、tmloadreposに関するドキュメントを参照してください。
  5. GWWS構成入力ファイル(たとえばgwws.depというファイル)に、WSDFへの参照を追加します。リスト1-15では、追加された要素が青色で強調表示されています。
  6. GWWSバイナリ構成ファイルを再ロードして、ここまでに加えた変更を有効にします(例: $ wsloadcf -y gwws.dep)。
  7. GWWSとTMMETADATAを再起動します。
    8. リスト1-15 GWWS構成ファイル 
    <?xml version="1.0" encoding="UTF-8"?>
    <saltdep:Deployment xmlns:saltdep="http://www.bea.com/Tuxedo/SALTDEPLOY/2007" xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
           <saltdep:WSDF>
                  <saltdep:Import location="calc.wsdf"/>
           </saltdep:WSDF>
           <saltdep:WSGateway>
                  <saltdep:GWInstance id="GWWS1">
                         <saltdep:Outbound>
                         <saltdep:Binding ref="calc:CalculatorSOAP11Binding">
                         <saltdep:Endpoint use="CalculatorSOAP11port"/>
                         </saltdep:Binding>
                         </saltdep:Outbound>
                  </saltdep:GWInstance>
           </saltdep:WSGateway>
            <saltdep:System/>
    </saltdep:Deployment>

SCA ATMIサーバーの構成

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

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

リスト1-16 $APPDIR/root.composite 
<?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>

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

リスト1-17 $APPDIR/Purchase.component/Purchase.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>

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

リスト1-18 $APPDIR/Purchase.component/PurchaseImpl.componentType 
<?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バインディングの構成に似ています。

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

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

リスト1-19 $APPDIR/root.composite 
<?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>
リスト1-20 $APPDIR/account/account.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>
リスト1-21 $APPDIR/account/AccountServiceImpl.componentType 
<?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)を構成する必要があります。実行する手順は次のとおりです。

  1. TMMETADATAおよびGWWSサーバーが停止していることを確認します。
  2. 使用するサービスのWSDLで、wsdlcvtを実行します。これにより、WSDFファイル、Oracle Tuxedoメタデータ・リポジトリのインタフェース定義ファイル、fml32フィールド表、およびXMLスキーマが生成されます。
  3. 生成されたWSDFファイルを修正して、実行時にリクエストを受け付けるために使用する実際のエンドポイント・アドレスを指定します。詳細は、WSDFのドキュメントを参照してください。
  4. Oracle Tuxedoメタデータ・リポジトリのインタフェース定義を、TMMETADATAサーバー・リポジトリにロードします(例: $ tmloadrepos -I AccountService.mif metadata.repos -y)。 詳細は、tmloadreposに関するドキュメントを参照してください。
  5. GWWS構成入力ファイル(たとえばgwws.depというファイル)に、WSDFへの参照を追加します。リスト1-22では、追加された要素が青色で強調表示されています。
  6. GWWSバイナリ構成ファイルを再ロードして、ステップ5で行った変更を有効にします(例: $ wsloadcf -y gwws.dep)。
  7. GWWSとTMMETADATAを再起動します。
    8. リスト1-22 gwws.dep File 
    <?xml version="1.0" encoding="UTF-8"?>
    <saltdep:Deployment xmlns:saltdep="http://www.bea.com/Tuxedo/SALTDEPLOY/2007" xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
           <saltdep:WSDF>
                  <saltdep:Import location="AccountService.wsdf"/>
           </saltdep:WSDF>
           <saltdep:WSGateway>
                  <saltdep:GWInstance id="GWWS1">
                         <saltdep:Inbound>
                                <saltdep:Binding ref="AccountService:AccountServiceSOAP">
                                <saltdep:Endpoint use="AccountServiceSOAP"/>
                                    </saltdep:Binding>
                         </saltdep:Inbound>
                  </saltdep:GWInstance>
           </saltdep:WSGateway>
           <saltdep:System/>
    </saltdep:Deployment>

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 Tuxedo管理者がパスワードの取得を構成するには、次のタスクを実行する必要があります。

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

リスト1-23 $APPDIR/password.store $APPDIR/simple.app.composite 
<?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>
リスト1-24 $APPDIR/simpapp.client/simpapp.client.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>

注意: encryptBitsには、クライアント接続がネゴシエートを試みる暗号化の強度を指定します。フォーマットは、<minencryptbits>/<maxencprytbits>(たとえば128/128)です。指定できる値は、0(暗号化なし)、40、56、128または256です。無効な値を指定すると、構成例外が発生します。

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

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

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

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

注意: 識別名の"cn"属性は、証明書ルックアップ用のキーとして使用されます。ワイルドカードを名前に使用することはできません。サブジェクト・フィールドを空にすることはできません。この制約はOracle Tuxedoでも見つかります。

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

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

リスト1-25 クライアント・コンポジット・ファイル 
<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"

 

Oracle Tuxedo SCAコンポーネントの管理

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

SCA ATMIサーバーおよびクライアントのトレース

SCA ATMIサーバーおよびクライアントでは、Oracle TuxedoおよびSCAが提供する既存のトレース機能を使用できます。次の項では、その使用方法について詳しく説明します。

Oracle Tuxedo TMTRACE

SCA ATMIサーバーおよびクライアントは、Oracle Tuxedo tmtrace(5)機能をサポートしています。TMTRACEから生成されたすべてのトレースがULOGファイルに記録されます。ULOGファイル・トレース情報をチェックすると、エラーの原因を判別するのに役立ちます。Oracle Tuxedo TMTRACE機能を有効にするには、TMTRACE環境変数を設定するか、tmadmin chtrサブコマンドを使用します。

注意: Oracle Tuxedo ATMIメッセージをトレースする場合は、コマンドラインにexport TMTRACE=atmi:ulogと入力します。

SCAランタイム、ATMIサービス・バインディング、および参照バインディングのトレース

次に示すように、トレースに使用する2つの環境変数があります。

注意: これらのトレース機能は、buildscaserverで構築したOracle Tuxedoサーバー、およびbuildscaclientで構築したSCAクライアントでのみ使用できます。

リスト1-26に、SCAランタイムのトレースを記録したULOGのサンプルを示します。

注意: 「>>」または「<<」で始まる行は、コードのコンパイル時に出力されません。
コード・リスト1-26 SCAランタイムのトレース情報を記録したULOGファイル 
142059.STRIATUM!?proc.1108.3000.-2: osoa::sca::CompositeContext::getCurrent
142059.STRIATUM!?proc.1108.3000.-2:     >> Tuscany::sca::SCARuntime::getCurrent Runtime
142059.STRIATUM!?proc.1108.3000.-2:     >> tuscany::sca::util::ThreadLocal::getValu e 
142059.STRIATUM!?proc.1108.3000.-2:     << tuscany::sca::util::ThreadLocal::getValu e
142059.STRIATUM!?proc.1108.3000.-2:     >> tuscany::sca::SCARuntime::getShared Runtime
142059.STRIATUM!?proc.1108.3000.-2:     SCARuntime::getSharedRuntime()
142059.STRIATUM!?proc.1108.3000.-2:     >> tuscany::sca::util::Mutex::lock
142059.STRIATUM!?proc.1108.3000.-2:     << tuscany::sca::util::Mutex::lock
142059.STRIATUM!?proc.1108.3000.-2:     >> tuscany::sca::util::Mutex::unlock
142059.STRIATUM!?proc.1108.3000.-2:     << tuscany::sca::util::Mutex::unlock
142059.STRIATUM!?proc.1108.3000.-2:     << tuscany::sca::SCARuntime::getSharedR untime
142059.STRIATUM!?proc.1108.3000.-2:     >> tuscany::sca::util::ThreadLocal::Thread Local
142059.STRIATUM!?proc.1108.3000.-2:     << tuscany::sca::util::ThreadLocal::Thread Local
142059.STRIATUM!?proc.1108.3000.-2:     >> tuscany::sca::SCARuntime::SCARuntime
142059.STRIATUM!?proc.1108.3000.-2:     SCA runtime install root f:\tuxedo\tux101rp _wsc\udataobj\salt\sca
142059.STRIATUM!?proc.1108.3000.-2:     Default component: testStringClientComp
142059.STRIATUM!?proc.1108.3000.-2:     >> tuscany::sca::util::ThreadLocal::getValu e
142059.STRIATUM!?proc.1108.3000.-2:     << tuscany::sca::util::ThreadLocal::getValu e

SCA ATMIサーバーのモニター

buildscaserverユーティリティで構築したOracle Tuxedo SCAサーバーは、scaadminユーティリティを使用してモニターできます。このユーティリティは、サービスに関する統計情報を提供するもので、動的共有ライブラリのロードとアンロードによるメンテナンスにも使用します。

buildscaserverコマンドで構築済のuBikeServer Oracle Tuxedoサーバーでホストするすべてのコンポーネントを再ロードするには、コマンドラインに次のように入力します。

  1. prompt> scaadmin
  2. prompt> reload -s uBikeServer

uBikeServer Oracle Tuxedoサーバーが提供するサービスの統計情報を表示するには、コマンドラインに次のように入力します(表1-1ではその結果を示します)。

  1. prompt> scaadmin
  2. prompt> pstats -s uBikeServer

    3. 表1-1 pstatsによって出力されるサービスの統計情報
    サービス
    メソッド
    ステータス
    処理されたリクエスト
    SEARCHINVENTORY
    searchInventory
    A
    37

scaadminを実行する前に、TUXCONFIG環境変数を設定する必要があります。表1-2に、scaadminのサブコマンドを示します。

表1-2 scaadminのサブコマンド
サブコマンド
省略形
説明
default
d
対応する引数をデフォルトに設定する。マシン名、グループ名、サーバーID、またはサーバー名を指定できる。引数を指定せずにdefaultコマンドを入力した場合は、現在のデフォルト値が出力される。
reload
r
Oracle TuxedoサーバーによってホストされているSCAコンポーネントを動的に再ロードします。
printstats
pstats
Oracle Tuxedoサーバーによってホストされているサービス、関連付けられているメソッド、問合せの数、およびステータス(アクティブ、アイドル)を一覧で表示します。
verbose
v
冗長モードで出力を生成します。
echo
e
エコーのオン/オフを切り替えます。
quit
q
セッションを終了します。

注意: WindowsおよびHPシステムでは、「reload」サブコマンドの使用に制限があります。
注意: WindowsおよびHPシステム上の複数のサーバーで同じコンポーネント・ライブラリを共有する場合は、共有しているコンポーネント・ライブラリを再ロードすることはできません。複数のサーバーで共有するコンポーネント・ライブラリを再ロードするには、影響を受けるすべてのサーバーに対して「scaadmin」のreloadサブコマンドを同時に実行する必要があります。

SCA JATMIクライアントのトレース

Oracle Tuxedo SCAのJava参照バインディングおよびデータ変換では、コンソールへの出力とログ・ファイルへの出力がサポートされます。デフォルトでは、ログ・ファイルの最大数は10、各ファイルの最大サイズは100,000バイトで、$APPDIRにjatmi<number>.logという名前で格納されます。ログ・ファイル名はローテーションになっており、最新のファイル名には常に0が付加され、その1つ前のファイル名には1が付加されます(たとえば、最新のログ・ファイルはjatmi0.log、最も古いログ・ファイルはjatmi9.log となります)。APPDIR環境変数が設定されておらず、com.oracle.jatmi.APPDIR Javaプロパティも指定されていない場合、ログは現在の作業ディレクトリに格納されます。

デフォルトでは、アプリケーションを起動するたびにログ・ファイルが上書きされます。ロギングのパラメータの多くはチューニングできます。表1-3では、ロギングに関係するチューニング可能なJavaプロパティを示します。

表1-3 ロギング・チューニング・プロパティ
機能
プロパティ
値の範囲
デフォルト値
ログ・ファイルの場所
com.oracle.jatmi.APPDIR
有効なパス名
APPDIR環境変数(APPDIRが設定されていない場合は現在の作業ディレクトリ)
ログ・ファイルのサイズ
com.oracle.jatmi.LogFileSize
0 -システムでサポートされる最大ファイル・サイズ
100,000バイト
ファイルの追加
com.oracle.jatmi.LogFileAppend
{true,false}
false
ログ・ファイルの数
com.oracle.jatmi.LogFileCount
1 -ディレクトリに格納できるファイルの最大数
10
ログの出力
com.oracle.jatmi.LogDestination
{file,console,both}
both
ログの形式
com.oracle.jatmi.LogFileFormat
{xml,plain}
plain

Oracle Tuxedo SCA Java参照バインディング・ログを別の言語に変更する場合は、まずインストールされているサポート対象言語を確認します。デフォルトはEnglishです。別の言語に切り替えるには、Oracle Tuxedo SCA Javaクライアントの起動時のJavaコマンドラインに「-Duser.language=<ユーザーの優先言語>」を追加します。例:

java -classpath .:/apps/classes:$CLASSPATH -Duser.langueage=ES -Dcom.oracle.jatmi.LogDestination=console myApplication.

このように入力すると、プレーン・テキストの英語のログがコンソールにのみ出力されます。

表1-3では、ログ・ファイルの内容の例を示します。

コード・リスト1-27 ログ・ファイルの内容 
9/3/08:3:19:14 PM:10:TRACE[TuxedoConversion,processSendBuf]< (10) return 1st args
9/3/08:3:19:14 PM:10:DBG[AtmiBindingInvoker,invoke]ServiceType: requestresponse
9/3/08:3:19:14 PM:10:DBG[AtmiBindingInvoker,invoke]Return Type Class: simpapp.View7Rep
9/3/08:3:19:14 PM:10:DBG[AtmiBindingInvoker,invoke]target service name: RULE7
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,invoke]TPURCODE: 0
9/3/08:3:19:15 PM:10:TRACE[TuxedoConversion,processReplyBuffer]> (reply simpapp.View7Rep@191777e:0:null)
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processReplyBuffer]returnType: simpapp.View7Rep
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processReplyBuffer]Reply Buffer Class: simpapp.View7Rep
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processReplyBuffer]Reply Buffer Type: X_COMMON
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processReplyBuffer]Reply Buffer Subtype: View7Rep
9/3/08:3:19:15 PM:10:TRACE[TuxedoConversion,processReplyBuffer]< (30) return buffer directly
9/3/08:3:19:15 PM:10:DBG[Accessors,getConventionProperty]Convention Property: CONVENTIONS_TUX
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,invoke]networkAddress: host = STRIATUM, port = 8080
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingInvoker,determineServiceCallParameters]> ()
9/3/08:3:19:15 PM:10:DBG[AtmiBindingImpl,isLegacy]> ()
9/3/08:3:19:15 PM:10:DBG[AtmiBindingImpl,isLegacy]< (10) return true
9/3/08:3:19:15 PM:10:DBG[AtmiBindingImpl,isMap]> ()
9/3/08:3:19:15 PM:10:DBG[AtmiBindingImpl,isMap]< (10) return false
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,determineServiceCallParameters]Operation name = rule7_OVVO
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingImpl,getServiceType]> (rule7_OVVO)
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingImpl,getServiceType]< (10) return null
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingImpl,getInputBufferType]> (rule7_OVVO)
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingImpl,getInputBufferType]< (10) return null
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingImpl,getOutputBufferType]> (rule7_OVVO)
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingImpl,getOutputBufferType]< (10) return null
9/3/08:3:19:15 PM:10:DBG[AtmiBindingImpl,getErrorBufferType]> (rule7_OVVO)
9/3/08:3:19:15 PM:10:DBG[AtmiBindingImpl,getErrorBufferType]< (10) return null
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,determineServiceCallParameters]svcName = RULE7
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,determineServiceCallParameters]svcType = requestresponse
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,determineServiceCallParameters]inbuf = X_COMMON
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,determineServiceCallParameters]outbuf = X_COMMON
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,determineServiceCallParameters]errbuf = null
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingInvoker,determineServiceCallParameters]< (10) return
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,invoke]Input Buffer Type: X_COMMON
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,invoke]Output Buffer Type: X_COMMON
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,invoke]Error Buffer Type: null

9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,invoke]inBufType:X_COMMON, count: 1
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,invoke]outBufType:X_COMMON, 

count: 1
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,invoke]View Classes: simpapp.View7Req,simpapp.View7Rep
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,getClassList]getClassList: Getting class for simpapp.View7Req
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,getClassList]getClassList: Getting class for simpapp.View7Rep
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,setFieldClasses]setFldClasses: null
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,invoke]Passing thro invoker...
9/3/08:3:19:15 PM:10:TRACE[TuxedoConversion,processSendBuf]> (args [Ljava.lang.Object;@ab1b4)
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processSendBuf]args[0] class simpapp.Rule7Req
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,needConversion]buftype: X_COMMON
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processSendBuf]Argument Class Name: simpapp.Rule7Req
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processSendBuf]Input Buffer Id    : XCOMMON
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processSendBuf]Type code          : 10
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processSendBuf]InputBufferType: XCOMMON
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,getClassList]getClassList: Getting class for simpapp.View7Req
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,getClassList]getClassList: Getting class for simpapp.View7Rep
9/3/08:3:19:15 PM:10:TRACE[Accessors,determineConvention]> (simpapp.Rule7Req)
9/3/08:3:19:15 PM:10:DBG[Accessors,determineConvention]Method name: getId
9/3/08:3:19:15 PM:10:DBG[Accessors,determineConvention]Method name: setCmd
9/3/08:3:19:15 PM:10:DBG[Accessors,determineConvention]Method name: setId
9/3/08:3:19:15 PM:10:DBG[Accessors,determineConvention]Method name: getCmd
9/3/08:3:19:15 PM:10:TRACE[Accessors,determineConvention]< (30) return BEAN

  先頭に戻る       前  次