|
|
以下の節では、Oracle SALT の管理に関する各種トピックの概要を説明します。
この節では、Oracle SALT の管理に必要な次の基本コンセプトを説明します。
Oracle Tuxedo 9.0 リリースから、Tuxedo サービス メタデータを保存したり取得したりするために、Tuxedo サービス メタデータ リポジトリが開発されました。Tuxedo サービス メタデータは、Tuxedo サービスの要求/応答の詳細情報を記述するために役立つ Tuxedo サービス属性の集合のことです。Oracle SALT ゲートウェイ サーバ (GWWS) は、Tuxedo 要求/応答形式 (バッファ タイプ) と標準 SOAP メッセージ形式との変換のため、Tuxedo サービス メタデータ リポジトリを使用します。
Oracle SALT を使用して Tuxedo サービスを Web サービスとしてエクスポーズするとき、Tuxedo サービス メタデータを Tuxedo サービス メタデータ リポジトリで定義しロードする必要があります。Oracle SALT は Tuxedo サービス メタデータから対応する SOAP メッセージ形式を定義できます。
Oracle SALT では、Tuxedo アプリケーションから外部 Web サービスを呼び出すとき、WSDL ファイル コンバータ wsdlcvt が提供されます。このコマンド ユーティリティを使用して、あらゆる Web サービスのオペレーションから Tuxedo サービス メタデータを定義できます。変換されたサービスは SALT プロキシ サービスと呼ばれ、通常の Tuxedo サービスとして呼び出すことができます。SALT プロキシ サービスも、Tuxedo サービス メタデータ リポジトリにロードする必要があります。
Tuxedo サービス メタデータ情報を取得するには、Tuxedo サービス メタデータ リポジトリ システム サーバ (TMMETADATA) を Tuxedo アプリケーションで起動するように設定する必要があります。
| 注意 : | TMMETADATA は、Oracle SALT ゲートウェイ GWWS サーバを使用する前に起動する必要があります。 |
詳細については、「Tuxedo サービス メタデータ リポジトリ」および「Oracle SALT の Tuxedo サービス メタデータ リポジトリの使用」を参照してください。
Oracle SALT をデプロイするためには、以下の 2 種類のコンフィグレーション ファイルが必要です。
SALT Web サービス定義ファイル (WSDF) は、XML ベースのファイルであり、SALT Web サービス コンポーネント (Web サービス バインディング、Web サービスのオペレーション、Web サービス ポリシー等) を定義するのに使います。WSDF は、Web サービス定義言語データ モデルの Oracle SALT 特有の表現です。WSDF には、ネイティブと非ネイティブの 2 つの種類があります。
ネイティブ WSDF は手作業で作成します。一連の Tuxedo サービスとその Web サービスとしてエクスポーズする方法について WSDF で定義する必要があります。これは、SALT 1.1 コンフィグレーション ファイルと同様です。ネイティブ WSDF は SALT WSDL ジェネレータ (tmwsdlgen) の入力ファイルです。詳細については、「ネイティブ Tuxedo サービスのコンフィグレーション」を参照してください。
非ネイティブな WSDF は、SALT WSDL コンバータ (wsdlcvt) を使用して変換された外部 WSDL ファイルから作成します。基本的に、作成した WSDF を (高度な機能のコンフィグレーションの以外の場合) 変更する必要はありません。詳細については、「外部 Web サービスのコンフィグレーション」を参照してください。
SALT デプロイメント ファイル (SALTDEPLOY) は、XML ベースのファイルであり、Oracle SALT GWWS サーバ デプロイメント情報を Tuxedo マシンごとに定義するために使用されます。SALTDEPLOY ファイルでは、すべての必要な WSDF ファイルの一覧を表示します。また、Tuxedo マシン上デプロイされている GWWS サーバ数を指定し、それぞれの GWWS サーバに対する着信および発信 Web サービス インドポイントを関連付けます。SALTDEPLOY ファイルには、グローバル リソース (証明書およびプラグイン ロード ライブラリを含む) が設定されているシステム セクションが含まれています。詳細については、「SALT デプロイメント ファイルの作成」を参照してください。
図 1-1 では、Oracle SALT デプロイメント モデルを示します。
Oracle SALT では、Oracle Tuxedo システム上に構築されている Oracle SALT アプリケーションのさまざまな部分を管理するために一連のコマンド ユーティリティが提供されます。これらのユーティリティは、以下のタスクに使用できます。
コマンドライン ユーティリティを使用して Oracle SALT アプリケーションをコンフィグレーションできます。具体的には、XML エディタを使用してアプリケーションに対してコンフィグレーション ファイル (WSDF ファイルおよび SALTDEPLOY ファイル) を作成し編集した後、wsloadcf というコマンドライン ユーティリティを使用して、XML ファイル (SALTDEPLOY ファイルおよび参照 WSDF ファイル) をバイナリ ファイル (SALTCONFIG) に変換することができます。これで、SALT ゲートウェイ (GWWS) サーバを起動する準備が整いました。
以下に、アプリケーションをコンフィグレーションするために使用できる Oracle SALT コマンドライン ユーティリティを示します。
各 Tuxedo マシン上に開始されるコマンドです。このコマンドを使用すると、アプリケーションの SALTDEPLOY ファイルおよび参照 WSDF ファイルをバイナリ SALTCONFIG ファイルにコンパイルすることができます。wsloadcf コマンドは、SALTCONFIG 環境変数によって定義された場所でバイナリ ファイルをロードします。
外部 WSDL (Web Services Description Language) ファイルを Tuxedo 定義ファイル (WSDF ファイル、Tuxedo サービス メタデータ定義ファイル、FML32 フィールド テーブル ファイルおよび XML スキーマ ファイル) に変換するコマンドです。生成された WSDF ファイルは、特に SALT 発信呼び出しのために使用される非ネイティブ WSDF ファイルです。
Oracle SALT は Oracle Tuxedo フレームワーク上に構築されているので、Oracle Tuxedo で提供されている以下のコマンドライン ユーティリティを使用して Oracle SALT 特有の項目を Tuxedo アプリケーションにコンフィグレーションする必要があります。
マスター Tuxedo マシン上に実行するコマンドです。このコマンドを使用すると、Tuxedo アプリケーション UBBCONFIG ファイルをバイナリ TUXCONFIG ファイルにコンパイルできます。Oracle SALT ゲートウェイ サーバを起動するには、GWWS サーバを UBBCONFIG ファイルに指定する必要があります。
Tuxedo サービス メタデータ リポジトリ システム サーバ (TMMETADATA) が起動されているマシン上に実行するコマンドです。このコマンドを使用すると、Tuxedo サービス メタデータ定義テキスト ファイルをバイナリ Tuxedo サービス メタデータ リポジトリ ファイルにロードできます。Web サービスのオペレーションとしてエクスポーズするすべての Tuxedo レガシー サービスを Tuxedo サービス メタデータ リポジトリにロードする必要があります。また、すべての wsdlcvt で生成された SALT プロキシ サービスを Tuxedo サービス メタデータ リポジトリにロードする必要があります。
コマンドライン ユーティリティ wsadmin(1) を使用して、Tuxedo アプリケーション内で Oracle SALT ゲートウェイ サーバの管理機能を実行できます。tmadmin、dmadmin および qmadmin コマンドと同じように、wsadmin は対話型のメタコマンドでサブコマンドを実行できます。
Oracle Tuxedo アプリケーションでは、wsadmin(1) コマンドを実行することで、Tuxedo アプリケーションに定義された SALT ゲートウェイ サーバをモニタおよび管理することができます。
SCA コンポジットは、関連付けられたコンフィグレーション ファイル内に記述し、ファイル名の末尾を「.composite」にするのが一般的です。このファイルでは、サービス コンポーネント定義言語 (SCDL) という XML ベースのフォーマットを使用して、コンポジットに含めるコンポーネントを記述したり、コンポーネント間の関係を指定したりします。Oracle SALT SCA をデプロイするためには、少なくとも 1 つのルート コンポジット ファイルを $APPDIR に配置する必要があります。
次に示すように、2 種類のコンフィグレーション ファイルがあります。
.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-2 に、コード リスト 1-1 のコンフィグレーションによって暗示されるディレクトリ階層を示します。
$APPDIR/ECHO.app.composite
$APPDIR/ECHO
$APPDIR/ECHO/ECHO.composite
$APPDIR/ECHO/ECHO.componentType
$APPDIR/TOUPPER
$APPDIR/TOUPPER/TOUPPER.composite
$APPDIR/TOUPPER/TOUPPER.componentType
このサンプルは典型的なサーバ コンフィグレーションです。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 つの 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 つのサービスを提供する Tuxedo サーバが EchoServer である場合は、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 の存在が暗示されています。
| 注意 : | Tuxedo SCA でサポートされる実装タイプは「cpp」のみです。 |
Oracle SALT SCA では、Tuxedo システム上に構築されている Oracle SALT SCA アプリケーションを管理するために一連のコマンドライン ユーティリティが提供されます。これらのユーティリティのほとんどはアプリケーション開発用ですが、管理用のユーティリティも 2 つ含まれています。詳細については、『リファレンス ガイド』を参照してください。
scapasswordtool コマンドライン ユーティリティを使用すると、SALT SCA セキュリティをコンフィグレーションできます。このユーティリティでは、SCA クライアント内で Tuxedo 認証のパスワードを管理したり、そのパスワードのストア ファイル (password.store) に値を設定したりできます。
Tuxedo セキュリティが APP_PW 以上に設定されている場合、SCA コンポーネントが Tuxedo ベースのサービスを参照すると、password.store ファイルから検索され、コンフィグレーション コンポジット ファイル内のパスワードおよびユーザ ID に一致するエントリがあるかどうかがチェックされます。ユーザ ID はプレーン テキストですが、パスワードは暗号化されています。
ユーザ ID とパスワードを追加または作成するには、次の手順に従います。
ユーザ ID とパスワードを削除するには、scapasswordtool -i userID -d と入力します。
ユーザ ID とそれに関連付けられているパスワードが削除されます。
サービスを ATMI バインディングで宣言する Tuxedo SCA コンポーネントは、通常の Tuxedo サービスとして管理します。このようなサーバのインスタンスは、既存の Tuxedo コマンド (tmadmin、tmboot、tmshutdown など) を使用して起動、モニタ、停止できます。
特定のメソッドのアクティビティや可用性をモニタするには、tmadmin を使用して、SCDL ファイルに定義された ATMI バインディング内に宣言されているサービスを選択します。
buildscaserver コマンドで構築した SCA サーバも、scaadmin コマンドライン ユーティリティを使用して呼び出すことのできる管理機能を備えています。
  
|