SCAコンポジットは、関連付けられた構成ファイル内に記述し、ファイル名の末尾を「.composite」にするのが一般的です。このファイルでは、サービス・コンポーネント定義言語(SCDL)というXMLベースのフォーマットを使用して、コンポジットに含めるコンポーネントを記述したり、コンポーネント間の関係を指定したりします。Oracle Tuxedo SCAをデプロイするためには、少なくとも1つのルート・コンポジット・ファイルを$APPDIR
に配置する必要があります。
.composite)
.componentType)
ルートのコンポジット・ファイルには、1つまたは複数のコンポーネントを構成できます。各コンポーネントのサブディレクトリには、そのコンポーネント独自の.composite
ファイルと.componentType
ファイルが格納されます。
コンポジット内には、ゼロ個以上のコンポーネント要素を含めることができます。ルートのコンポジット・ファイルは、サーバー環境の$APPDIR
内に格納する必要があります。
リスト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では、暗黙的なディレクトリ階層を示します。
$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
というクライアントのディレクトリ構造を示します。
$APPDIR/root.composite
$APPDIR/EchoClient/EchoClient.composite
$APPDIR/EchoClient.composite
$APPDIR/EchoClient/EchoClient.dll
$APPDIR/EchoClient/EchoClient.exe
注: | SCAサーバー環境と違い、SCAクライアント環境ではコンポーネント構成ファイルを環境内に配置する必要はありません。 |
コンポーネントとは、SCAアセンブリ内のビジネス機能の基本要素です。これらのコンポーネントをSCAコンポジットによって結合することでビジネス・ソリューションが完成します。コンポーネントは、実装の構成済インスタンスです。サービスを提供し、サービスを消費します。複数のコンポーネントで同じ実装を使用し、それぞれ違う実装として構成することも可能です。
コンポーネントは、xxx.composite
ファイル内でコンポジットのサブ要素として宣言します。1つのコンポーネントは、コンポジット要素の子である1つのコンポーネント要素で表現します。リスト1-1のコンポジットを使用して、2つのコンポーネント(ECHO
およびTOUPPER
)に情報を含めます。ECHO
サービス($APPDIR/ECHO/ECHO.composite)
のECHO.composite
の情報をリスト1-4に示します。
<?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に示すような情報を含める必要があります。
<?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>
...
*SERVERS
DEFAULT:
CLOPT="-A"
EchoServer SRVGRP=GROUP1 SRVID=1001
...
TOUPPER
サービスの場合は、ECHO.app.composite
ファイルによって$APPDIR/TOUPPER/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コンポーネントの構成には、次のタスクがあります。
SCA ATMIクライアントは、SCAパラダイムで記述し、buildscaclient
ユーティリティで構築するネイティブOracle Tuxedoクライアントです。クライアントの実行ファイルは、root.composite
ファイルが格納されるディレクトリのサブディレクトリに格納する必要があります。
注: | APPDIR 環境変数に、root.composite ファイルのディレクトリを指定する必要があります。 |
リスト1-8には、クライアント・アプリケーションのルート・コンポジット・ファイル$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"/>
に指定された名前と一致する必要があります。リスト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 となります。 |
JATMIクライアント・アプリケーションの構成コンポジット・ファイルは、Java .jar
ファイルの一部です。JATMIクライアントのコンポジット・ファイルは、パッケージの一部ではなく、.jar
ファイルのベースに配置されます。クライアント・アプリケーションを呼び出すと、SCA Javaランタイムによってコンポジット・ファイルがロードされます。特別なセットアップは必要ありません。
注: | クライアント・アプリケーションの.jar ファイルはCLASSPATH に含める必要があります。次の.jar ファイルもCLASSPATH の一部に含める必要があります。 |
リスト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ネイティブ・クライアントの構成に似ています。1つの相違点は、SCAワークステーション・クライアントの場合、コンポジット内で<workStationParameters>
要素とそのサブ要素を使用する必要があることです。SCAランタイムは、クライアントがSCAネイティブ・クライアントとSCAワークステーション・クライアントのどちらで構築されたかを自動的に検出し、それに応じて適切な参照バインディング・ライブラリをロードします。
SCA Oracle Tuxedoワークステーション・クライアントのディレクトリ階層も、SCAネイティブ・クライアントに似ています。どちらの場合も、環境変数$APPDIR
を使用して、クライアント・アプリケーションの場所を指定します。
リスト1-11およびリスト1-12には、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ネイティブ・クライアントと同じですが、<binding.atmi>
要素ではなく<binding.ws>
要素を使用する点が異なります。SCAランタイムは、クライアントが使用しているバインディングを自動的に検出し、それに応じて適切な参照バインディングをロードします。
SCA Webサービス・クライアントのディレクトリ階層も、ネイティブ・クライアントに似ています。どちらの場合も、$APPDIR
環境変数を使用して、クライアント・アプリケーションの場所を指定します。
リスト1-13およびリスト1-14には、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)を構成する必要もあります。
TMMETADATA
およびGWWSサーバーが停止していることを確認します。wsdlcvt
を実行します。これにより、WSDFファイル、Oracle Tuxedoメタデータ・リポジトリのインタフェース定義ファイル、fml32フィールド表、およびXMLスキーマが生成されます。TMMETADATA
サーバー・リポジトリにロードします(例: $ tmloadrepos -I calc.mif metadata.repos -y
)。詳細は、tmloadrepos
に関するドキュメントを参照してください。gwws.dep
というファイル)に、WSDFへの参照を追加します。リスト1-15では、追加された要素が青色で強調表示されています。$ wsloadcf -y gwws.dep
)。TMMETADATA
を再起動します。<?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 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
という名前です。
<?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
が格納されます。
<?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
という名前になります。
<?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サービスは動的に通知されます。
コンポーネントの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
サイド・ファイルを示します。
<?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)を構成する必要があります。実行する手順は次のとおりです。
TMMETADATA
およびGWWSサーバーが停止していることを確認します。wsdlcvt
を実行します。これにより、WSDFファイル、Oracle Tuxedoメタデータ・リポジトリのインタフェース定義ファイル、fml32フィールド表、およびXMLスキーマが生成されます。TMMETADATA
サーバー・リポジトリにロードします(例: $ tmloadrepos -I AccountService.mif metadata.repos -y
)。
詳細は、tmloadrepos
に関するドキュメントを参照してください。gwws.dep
というファイル)に、WSDFへの参照を追加します。リスト1-22では、追加された要素が青色で強調表示されています。$ wsloadcf -y gwws.dep
)。TMMETADATA
を再起動します。<?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>
Oracle Tuxedo SCAコンポーネントでは、次の2種類のセキュリティがサポートされます。
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 SCAプログラミングのPasswordコールバック・メソッドに関する項を参照してください。 |
Oracle Tuxedo管理者がパスワードの取得を構成するには、次のタスクを実行する必要があります。
リスト1-23およびリスト1-24には、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リンク・レベル・セキュリティには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
内のクライアント・コンポジット・ファイルに追加する必要がある行を示します。
<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"
SCA ATMIサーバーおよびクライアントでは、Oracle TuxedoおよびSCAが提供する既存のトレース機能を使用できます。次の項では、その使用方法について詳しく説明します。
SCA ATMIサーバーおよびクライアントは、Oracle Tuxedo tmtrace(5)機能をサポートしています。TMTRACE
から生成されたすべてのトレースがULOGファイルに記録されます。ULOGファイル・トレース情報をチェックすると、エラーの原因を判別するのに役立ちます。Oracle Tuxedo TMTRACE
機能を有効にするには、TMTRACE
環境変数を設定するか、tmadmin
chtr
サブコマンドを使用します。
注: | Oracle Tuxedo ATMIメッセージをトレースする場合は、コマンド行にexport TMTRACE=atmi:ulog と入力します。 |
次に示すように、トレースに使用する2つの環境変数があります。
注: | これらのトレース機能は、buildscaserver で構築したOracle Tuxedoサーバー、およびbuildscaclient で構築したSCAクライアントでのみ使用できます。 |
リスト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
buildscaserver
ユーティリティで構築したOracle Tuxedo SCAサーバーは、scaadmin
ユーティリティを使用してモニターできます。このユーティリティは、サービスに関する統計情報を提供するもので、動的共有ライブラリのロードとアンロードによるメンテナンスにも使用します。
buildscaserver
コマンドで構築済のuBikeServer
Oracle Tuxedoサーバーでホストするすべてのコンポーネントを再ロードするには、コマンド行に次のように入力します。
uBikeServer
Oracle Tuxedoサーバーが提供するサービスの統計情報を表示するには、コマンド行に次のように入力します(表1-1ではその結果を示します)。
scaadmin
を実行する前に、TUXCONFIG
環境変数を設定する必要があります。表1-2に、scaadmin
のサブコマンドを示します。
注: | WindowsおよびHPシステムでは、「reload」サブコマンドの使用に制限があります。 |
注: | WindowsおよびHPシステム上の複数のサーバーで同じコンポーネント・ライブラリを共有する場合は、共有しているコンポーネント・ライブラリを再ロードすることはできません。複数のサーバーで共有するコンポーネント・ライブラリを再ロードするには、影響を受けるすべてのサーバーに対して「scaadmin」 のreloadサブコマンドを同時に実行する必要があります。 |
Oracle Tuxedo SCAのJava参照バインディングおよびデータ変換では、コンソールへの出力とログ・ファイルへの出力がサポートされます。デフォルトでは、ログ・ファイルの最大数は10、各ファイルの最大サイズは100000バイトで、$APPDIR
にjatmi<number>.log
という名前で格納されます。ログ・ファイル名はローテーションになっており、最新のファイル名には常に0が付加され、その1つ前のファイル名には1が付加されます(たとえば、最新のログ・ファイルはjatmi0.log
、最も古いログ・ファイルはjatmi9.log
となります)。APPDIR
環境変数が設定されておらず、com.oracle.jatmi.APPDIR
Javaプロパティも指定されていない場合、ログは現在の作業ディレクトリに格納されます。
デフォルトでは、アプリケーションを起動するたびにログ・ファイルが上書きされます。ロギングのパラメータの多くはチューニングできます。表1-3では、ロギングに関係するチューニング可能なJavaプロパティを示します。
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では、ログ・ファイルの内容の例を示します。
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