|
|
SCA (Service Component Architecture) のもっとも重要な点は、新しいプログラミング モデルが導入されたことです。Tuxedo アーキテクチャの一部として SCA を採用することで、SOA 環境において高い出力性能、可用性、スケーラビリティをバランスよく兼ね備えたアプリケーションを開発できるようになりました。
SCA コンポーネントは、ATMI バインディングを使用して Tuxedo インフラストラクチャ上で実行します。ATMI バインディングを実装することによって、SCA コンポーネント間だけでなく、SCA コンポーネントと Tuxedo プログラム (クライアントとサーバ) の間のネイティブな Tuxedo 通信も可能になります。
プログラミング モデルに加えて SCDL (Service Component Definition Language) を使用することで、コンポーネント間の対話において何を実行できるかを記述したり、必要なリンク (ワイヤ) を設定するようフレームワークに指示したりできます。
実行時の参照バインディング拡張は、SCA コンテナのクライアントサイドの実装です。他のサービス (SCA コンポーネント、Tuxedo サーバ、Web サービスなど) を呼び出すために必要なコードを、SCA ベースのコンポーネントから透過的にカプセル化します。
SCA クライアント プログラムを開発する手順は次のとおりです。
アプリケーションの物理表現を定義する必要があります。厳密な SCA クライアント アプリケーションは SCA コンポーネント タイプです。コード リスト 6-1 に、アプリケーション内に SCA コンポーネントを配置する際のディレクトリ構造を示します。
myApplication/ (APPDIR 環境変数に指定する最上位のディレクトリ)
root.composite (このアプリケーション内のコンポーネントのリストを格納する SCDL 最上位コンポジット)
myClient/ (このセクションに記述する実際のクライアント コンポーネントを格納するディレクトリ)
myClient.composite (クライアント コンポーネントの SCDL)
myClient.cpp (クライアント プログラムのソース ファイル)
TuxService.h (クライアント プログラムから呼び出すコンポーネントのインタフェース)
コード リスト 6-2 に、典型的な root.composite のサンプルを示します。
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="simple.app">
<component name="myClientComponent">
<implementation.composite name="myClient"/>
</component>
</composite>
ここに、個別コンポーネントのリストを記述します。implementation.composite@name パラメータは、「myClientComponent」という名前のコンポーネントを格納するディレクトリを参照します。この最後の値は実行時に必要になります。詳細については、「クライアント アプリケーションを実行する」を参照してください。
クライアント プログラムには、単一の API に対する呼び出しを実装する必要があります。次に示すこの呼び出しは、SCA ランタイムを設定するために必要なものです。
...
CompositeContext theContext = CompositeContext::getCurrent();
...
実際の呼び出しは、インタフェースに基づいて行われます。このインタフェースは、通常は呼び出すコンポーネントに合わせて開発します。既存の Tuxedo ATMI サービスの場合は、Tuxedo メタデータ リポジトリにアクセスすることでこのインタフェースを生成できます。詳細については、「tuxscagen」および『管理ガイド』を参照してください。
外部 Web サービスを呼び出す場合は、サービス WSDL に適合するインタフェースを提供する必要があります。詳細については、「SCA ATMI バインディングのデータ型のマッピング」の WSDL 型と C++ 型の対応に関する説明を参照してください。
コード リスト 6-3 に、インタフェースのサンプルを示します。
#include <string>
/**
* Tuxedo サービスのビジネス インタフェース
*/
class TuxService
{
public:
virtual std::string TOUPPER(const std::string inputString) = 0;
};
コード リスト 6-3 のインタフェースでは、1 つのメソッド TOUPPER が定義されています。このメソッドは、型 std::string のパラメータ 1 つを取り、型 std::string の値を返します。このインタフェースは、固有の .h ファイル内に記述し、この .h ファイルをインクルードすることでクライアント プログラムから参照できます。
コード リスト 6-4 に、呼び出しを実行するために必要な一連の呼び出しのサンプルを示します。
// SCA 定義
// これらによって Tuxedo 固有の例外定義 ATMIBindingException もインクルードされる
#include "tuxsca.h"
// インタフェースのインクルード
#include "TuxService.h"
...
// クライアント プログラムで CompositeContext クラスを使用する
CompositeContext theContext = CompositeContext::getCurrent();
...
// サービスを見つける
TuxService* toupperService =
(TuxService *)theContext.locateService("TOUPPER");
...
// 呼び出しを実行する
const std::string result = toupperService->TOUPPER("somestring");
...
| 注意 : | この呼び出し自体は、プログラム自体でリンクが設定されている別のファイルにクラスが存在するようなもので、実質的にはローカル呼び出しを実行しているのと同じです。 |
| 注意 : | より詳細なサンプル コードについては、以下のディレクトリに格納されている SCA サンプルを参照してください。 |
ローカル呼び出しと実際のコンポーネントの間のリンクは、SCDL サイド ファイルでバインディングを定義することによって設定します。たとえば、既存の Tuxedo ATMI サービスを呼び出す コード リスト 6-4 のサンプルの場合は、コード リスト 6-5 に示す SCDL 記述子を使用する必要があります。この SCDL は、<componentname>.composite というファイル内に記述します。
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="simpapp.client">
<reference name="TOUPPER">
<interface.cpp header="TuxService.h"/>
<binding.atmi requires="legacy">
<inputBufferType target="TOUPPER">STRING</inputBufferType>
<outputBufferType target="TOUPPER">STRING</outputBufferType>
</binding.atmi>
</reference>
</composite>
このコンポジット ファイルには、クライアント コンポーネントが TOUPPER 参照を呼び出す可能性があること、およびこの呼び出しの実行に ATMI バインディングを使用することが記述されています。実際には、この結果として「TOUPPER」Tuxedo サービスに対して tpcall() が実行されます。この Tuxedo サービスは、実際に存在する Tuxedo ATMI サービスか、ATMI バインディングを使用して公開されている別の SCA コンポーネントです。詳細については、「SCA コンポーネントのプログラミング」を参照してください。
inputBufferType および outputBufferType 要素は、データ交換に使用する Tuxedo バッファのタイプを識別するために使用します。詳細については、「SCA ATMI バインディングのデータ型のマッピング」および「Oracle SALT SCA ATMI バインディングのリファレンス」を参照してください。binding.atmi 要素で使用できるすべての値について説明されています。
すべての要素が揃ったら、buildscaclient コマンドを使用してクライアント プログラムをビルドできます。
構文エラーやコンパイル エラーが発生していなければ、クライアント プログラムは使用できる状態になっています。
クライアント プログラムを実行するには、以下の環境変数を設定する必要があります。
APPDIR - アプリケーション ディレクトリを指定します。SCA の場合は、最上位の SCDL コンポジットが格納されているディレクトリを指定するのが一般的です。SCA_COMPONENT - デフォルトの SCA コンポーネント (コード リスト 6-2 のサンプルでは「myClientComponent」) を指定します。これにより、locateService() 呼び出しでサービスを検索する際に、どこから検索を開始すればよいかを指定できます。
SCA クライアント プログラムから既存の Tuxedo ATMI サービスにアクセスしたい場合は、コード リスト 6-6、コード リスト 6-7、およびコード リスト 6-8 に示すサンプルを参考にすることで簡単にアクセスできます。
| 注意 : | これらのサンプルは、サーバサイド SCA コンポーネントにも使用できます。 |
まずは、コード リスト 6-6 に示す Tuxedo メタデータ リポジトリ エントリを記述し、tuxscagen コマンドを使用してインタフェースと SCDL を生成します。
service=TestString
tuxservice=ECHO
servicetype=service
inbuf=STRING
outbuf=STRING
service=TestCarray
tuxservice=ECHO
servicetype=service
inbuf=CARRAY
outbuf=CARRAY
#ifndef ECHO_h
#define ECHO_h
#include <string>
#include <tuxsca.h>
class ECHO
{
public:
virtual std::string TestString(const std::string arg) = 0;
virtual std::string TestCarray(const struct carray_t * arg) = 0; }; #endif /* ECHO_h */
<?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">
<serviceType target="TestString">RequestResponse</serviceType>
<inputBufferType target="TestString">STRING</inputBufferType>
<outputBufferType target="TestString">STRING</outputBufferType>
<serviceType target="TestCarray">RequestResponse</serviceType>
<inputBufferType target="TestCarray">CARRAY</inputBufferType>
<outputBufferType target="TestCarray">CARRAY</outputBufferType>
</binding.atmi>
</reference>
</composite>
これらのサービスを呼び出す手順は、コード リスト 6-6 から 6-8 に示したサンプルとまったく同じです。
非 SCA Tuxedo ATMI サービスを呼び出した場合は、そのサービスがエラーになっても、tpreturn(TPFAIL, …) API によってデータが返されます。このような場合、SCA クライアントや SCA コンポーネントは ATMIBindingException 型によって中断されます。
サービスから返されたデータがある場合は、ATMIBindingException.getData() を使用して取得できます。
...
try { const char* result = toupperService->charToup("someInput"); } catch (tuscany::sca::atmi::ATMIBindingException& abe) {// SCDL 内の <errorBufferType> 要素内に定義した
// マッピングに対応するデータへのポインタを
// 返す
const char* *result = (const char **)abe.getData();
if (abe.getData() == NULL) {// データが返されなかった
} else {// 処理データが返された
...
}
} catch (tuscany::sca::ServiceInvocationException& sie) {// 他の型の例外が返された
}
...
コード リスト 6-9 のサンプルは、コード リスト 6-10 に示す binding.atmi に対応します。
...
<binding.atmi requires="legacy">
<inputBufferType target="charToup">STRING</inputBufferType>
<outputBufferType target="charToup">STRING</outputBufferType>
<errorBufferType target="charToup">STRING</errorBufferType>
<binding.atmi/>
...
他のデータ型が返された場合は、対応する型にキャストする必要があります。たとえば、commonj::sdo::DataObjectPtr を返す呼び出しは、SCDL では次のようになります。
...
<errorBufferType target="myMethod">FML32/myType</errorBufferType>
...
ATMIBindingException.getData() の結果は、次のようにキャストする必要があります。
...
} catch (tuscany::sca::atmi::ATMIBindingException& abe) {const commonj::sdo::DataObjectPtr *result =
(const commonj::sdo::DataObjectPtr *)abe.getData();
...
呼び出し側のアプリケーションに TPFAIL データを返すルールは次のとおりです。
Tuxedo バッファ タイプと C++ データ情報の間の詳しい変換ルールについては、「SCA ATMI バインディングのデータ型のマッピング」を参照してください。
SCA コンポーネントという用語は、他の SCA ランタイム コンポーネントや非 SCA ランタイム コンポーネントから呼び出すことのできる SCA ランタイム アーティファクトを指します。SCA コンポーネントは、他の SCA コンポーネントや非 SCA コンポーネントに対する呼び出しも実行できます。一方、厳密な SCA クライアントは、他の SCA コンポーネントや非 SCA コンポーネントに対する呼び出しは実行できても、それらから SCA クライアントを呼び出すことはできません。
Oracle SALT の SCA コンテナは、Oracle Tuxedo サーバ環境で SCA コンポーネントをホストすることを可能にします。SCA コンテナを使用することで、Oracle Tuxedo の実績ある信頼性、スケーラビリティ、パフォーマンスを最大限に活用できます。
図 6-1 に、SCA コンポーネントと Tuxedo サーバのマッピング ルールをまとめます。
Tuxedo 参照を使用する SCA コンポーネントには特別な処理は必要ありませんが、サービスを提供する SCA コンポーネントは引き続き Tuxedo 環境で処理する必要があります。
<binding.atmi> 定義を使用して 1 つまたは複数のサービスを宣言している SCA コンポーネントは、SCA コンポジットと同じ数のサービスを公開している単一の Tuxedo サーバにマップされます。binding.atmi セクションにあるできる限り多くのサーバを公開します。/binding.atmi/@map 属性で Tuxedo のネイティブ サービスにリンクされます。/binding.atmi/@map 属性で宣言したメソッドは、Tuxedo からアクセスすることはできません。サービス名の重複はサーバの生成時に検出されるため、単一の Tuxedo サーバ インスタンス内での Tuxedo サービス名とインタフェース メソッドとのマッピングは 1:1 になります。
SCA コンポジットを Tuxedo アプリケーションにデプロイするには、生成された SCA サーバのインスタンスを UBBCONFIG ファイルにコンフィグレーションします。複数のインスタンスをデプロイすることも可能です。マルチスレッド機能も使用でき、既存の Tuxedo 機能を使用して制御できます。
SCA コンポーネント プログラムを開発する手順は次のとおりです。
まずは、アプリケーションの物理表現を定義します。コード リスト 6-13 に、SCA コンポーネントをアプリケーション内に配置するためのディレクトリ構造を示します。
myApplication/ (APPDIR 環境変数に指定する最上位のディレクトリ)
root.composite (このアプリケーション内のコンポーネントのリストを格納する SCDL 最上位コンポジット)
myComponent/ (このセクションに記述する実際のコンポーネントを格納するディレクトリ)
myComponent.composite (コンポーネントの SCDL)
myComponentImpl.cpp (コンポーネント実装のソース ファイル)
TuxService.h (エクスポートポーズするコンポーネントのインタフェース)
TuxServiceImpl.h (コンポーネント実装の定義)
コード リスト 6-14 に、root.composite のサンプルを示します。
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="simple.app">
<component name="myComponent">
<implementation.composite name="myComponent"/>
</component>
</composite>
ここでは、個別のコンポーネントのリストを記述します。implementation.composite@name パラメータは、「myComponent」というコンポーネントを格納するディレクトリを参照します。
他のコンポーネントから呼び出すように設計されたコンポーネントでは、SCA ランタイムを認識する必要はありません。ただし、インタフェース機能については以下の制約があります。
std::string および commonj::sdo::DataObjectPtr) は、パラメータや戻り値としては使用できない
詳細については、「SCA ATMI バインディングのデータ型のマッピング」を参照してください。
コード リスト 6-15 に、クライアント プログラム用に実装するインタフェースのサンプルを示します。
#include <string>
/**
* Tuxedo サービスのビジネス インタフェース
*/
class TuxService
{ public:
virtual std::string TOUPPER(const std::string inputString) = 0;
};
コンポーネント実装は、通常は 2 つのソース ファイルで構成されます (それぞれを コード リスト 6-16 および コード リスト 6-17 に示します)。
<servicename>Impl.h ファイルに記述) <servicename>Impl.cpp ファイルに記述)#include "TuxService.h"
/**
* TuxServiceImpl コンポーネント実装クラス
*/
class TuxServiceImpl: public TuxService
{ public:
virtual std::string toupper(const std::string inputString);
};
#include "TuxServiceImpl.h"
#include "tuxsca.h"
using namespace std;
using namespace osoa::sca;
/**
* TuxServiceImpl コンポーネント実装
*/
std::string TuxServiceImpl::toupper(const string inputString)
{ string result = inputString;
int len = inputString.size();
for (int i = 0; i < len; i++) {result[i] = std::toupper(inputString[i]);
}
return result;
}
また、サイドファイル (componentType) も必要です。このファイルには、SCA ラッパーの生成に必要な情報が格納されます。状況によって (このコンポーネントが別のコンポーネントを呼び出す場合) は、プロキシ コードが格納されることもあります。
この componentType ファイル (<componentname>Impl.componentType) は SCDL ファイル タイプです。コード リスト 6-18 に、componentType ファイルのサンプル (TuxServiceImpl.componentType) を示します。
<?xml version="1.0" encoding="UTF-8"?>
<componentType xmlns="http://www.osoa.org/xmlns/sca/1.0" >
<service name="TuxService">
<interface.cpp header="TuxService.h"/>
</service>
</componentType>
ローカル実装と実際のコンポーネントの間のリンクは、SCDL サイドファイルでバインディングを定義することによって設定します。たとえば、コード リスト 6-18 のファイル タイプを Tuxedo ATMI サービスとしてエクスポーズする場合は、下に示す SCDL を使用する必要があります。この SCDL は、<componentname>.composite というファイル (たとえば myComponent.composite) 内に記述します。
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="simpapp.server">
<service name="mySVC">
<interface.cpp header="TuxService.h"/>
<binding.atmi requires="legacy">
<map target="toupper">TUXSVC</map>
<inputBufferType target="toupper">STRING</inputBufferType>
<outputBufferType target="toupper">STRING</outputBufferType>
</binding.atmi>
<reference>TuxServiceComponent</reference>
</service>
<component name="TuxServiceComponent">
<implementation.cpp library="TuxSvc" header="TuxServiceImpl.h"/>
</component>
</composite>
このコンポジット ファイルを見ると、サービス mySVC を Tuxedo インフラストラクチャ経由で呼び出せることが分かります。また、Oracle Tuxedo システム内で、toupper() メソッドが TUXSVC サービスとして公開されることも分かります。このサービスを初期化すると、他の SCA コンポーネントや非 SCA Tuxedo ATMI クライアントから呼び出せるようになります。
inputBufferType および outputBufferType 要素は、データ交換に使用する Tuxedo バッファのタイプを識別するために使用します。詳細については、「SCA ATMI バインディングのデータ型のマッピング」および「Oracle SALT SCA ATMI バインディングのリファレンス」を参照してください。binding.atmi 要素で使用できるすべての値について説明されています。
すべての要素が揃ったら、buildscacomponent コマンドを使用してコンポーネントをビルドできます。
コンポーネントを Oracle Tuxedo 環境でサポートするには、Tuxedo サーバ ホストをビルドする必要があります。ビルドには、buildscaserver コマンドを使用します。
例 : $ buildscaserver -c myComponent -s . -o mySCAServer
これで、mySCAServer が使用できるようになります。SCDL に従ってデプロイすべきコンポーネントが自動的に検索され、Tuxedo と SCA の間の適切な関連付けが行われます。
Web サービス バインディング (binding.ws) では、Web サービスのトラフィックを GWWS ゲートウェイ経由にすることで、以前からの Oracle SALT 機能を利用します。SCA コンポーネントは Tuxedo サーバでホストし、それらのサーバとの通信は GWWS ゲートウェイ経由で行います。
サーバを実行する環境が Tuxedo 環境であっても、ネイティブな Tuscany 環境 (たとえば Axis2 Web サービス バインディングでコンポーネントをエクスポーズした環境) であっても、Web サービス バインディングを使用する SCA クライアントを変える必要はありません。
| 注意 : | 現時点で、HTTPS はサポートされていません。 |
SCA コンポーネントを Web サービス バインディング (binding.ws) を使用してエクスポーズする場合、WSDF 情報、メタデータ エントリ、および FML32 フィールド定義の生成はツールによって実行されます。
SCA コンポーネントの SCDL コードを、<binding.ws> 要素を含む Tuxedo ドメイン (たとえばサービス要素) でホストする場合、buildscaserver コマンドを実行すると、service.wsdf (service はエクスポーズするサービスの名前) というファイルに WSDF エントリが生成されます。これに伴い、Web サービスに関連付けられた WSDL インタフェースの内容に基づいて、service.mif および service.fml32 フィールド テーブル ファイルも生成されます。WSDL インタフェースはユーザが作成する必要があります。WSDL インタフェースが見つからない場合は、エラー メッセージが生成されます。
Tuxedo ドメインから Web サービス バインディング (たとえば SCDL の reference 要素) を使用してアクセスする Web サービスは、次の手順に従って手動でコンフィグレーションする必要があります。
wsdlcvt ツールを使用して、WSDL ファイルを WSDF エントリに変換します。その際、サービス メタデータ エントリ ファイル (.mif) と fml32 マッピング ファイルも生成されます。wsloadcf を使用して、SALTDEPLOY ファイルをバイナリに変換します。tmloadrepos コマンドを使用して、サービス メタデータ エントリ ファイル (.mif) をサービス メタデータ リポジトリにロードします。
Web サービス バインディングの参照拡張によって、Web サービス呼び出しが初期化されます。
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="bigbank.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"/>
<reference name="accountDataService">
AccountDataServiceComponent
</reference>
</component>
...
</composite>
対応するサービスをエクスポーズするための手順は次のとおりです。
buildscacomponent を使用してアプリケーション コンポーネント ランタイムをビルドします。buildscaserver -w を使用して、SCDL コードを WSDF エントリに変換し、デプロイ可能なサーバ (Tuxedo サーバ + ライブラリ + SCDL) を作成します。
上に示した SCDL のサービスは、コード リスト 6-21 のような WSDF エントリになります。
<Definition>
<WSBinding id="AccountService_binding">
<ServiceGroup id="AccountService">
<Service name="TuxAccountService"/>
</ServiceGroup>
</WSBinding>
</Definition>
buildscaserver -w でも、SCDL およびインタフェースの解析に基づいてサービス メタデータ リポジトリ エントリが作成されます。インタフェースは WSDL 形式でなければならず、このリリースでは手動で作成する必要があります。tmloadrepos コマンドにより、サービス メタデータ リポジトリ エントリがサービス メタデータ リポジトリにロードされます。wsloadcf を使用して、WSDF ファイルを SALTDEPLOY ファイルし、SALTDEPLOY をバイナリに変換する必要があります。.mif) がサービス メタデータ リポジトリにロードされます。
Web サービス処理 (たとえば GWInstance やサーバ レベル プロパティのコンフィグレーション) に使用する GWWS ゲートウェイを設定するためには、SALTDEPLOY のコンフィグレーションに加え、この手順を実行する必要があります。手順を完了すると、SCA または他の Web サービス クライアントから Web サービスにアクセスできるようになります。
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="bigbank.account">
...
<reference name="StockQuoteWebService">
<interface.wsdl interface="http://www.webserviceX.NET/#
wsdl.interface(StockQuoteSoap)"/>
<binding.ws endpoint="http://www.webserviceX.NET/#
wsdl.endpoint(StockQuote/StockQuoteSoap)"/>
</reference>
...
</composite>
wsdlcvt ツールを使用して WSDF エントリに変換する必要があります。その際、サービス メタデータ エントリ ファイル (.mif) と fml32 マッピング ファイも生成されます。wsloadcf を使用して、WSDF ファイルを SALTDEPLOY ファイルし、SALTDEPLOY をバイナリに変換する必要があります。tmloadrepos コマンドによって、サービス メタデータ エントリ ファイル (.mif) がサービス メタデータ リポジトリにロードされます。
Web サービス処理 (たとえば GWInstance やサーバ レベル プロパティのコンフィグレーション) に使用する GWWS ゲートウェイを設定するためには、SALTDEPLOY のコンフィグレーションに加え、この手順を実行する必要があります。手順を完了すると、SCA クライアントから Web サービスにアクセスできるようになります。
この手順は、スタンドアロン SCA プログラムのクライアントでも、Web サービス バインディングを使用して他の SCA コンポーネントを参照する SCA コンポーネント (すでにサーバ) のクライアントでも変わりません。
Tuxedo SCA 呼び出しでは、以下のリモート プロトコルがサポートされます。
SCA コンテナを使用して行う SCA 呼び出しは、Tuxedo WorkStation プロトコル (/WS) を使用して実行できます。その場合は、<binding.atmi> 要素内の <remoteAccess> 要素の値として WorkStation を指定します (WebService との混同を避けるため短縮しません)。
このモードで使用できるのは、参照タイプの呼び出しのみです。サービス タイプの呼び出しは、/WS を使用して透過的に実行する場合もあります (動作やコンフィグレーションに違いはなく、SCA サービスの <remoteAccess> 要素を WorkStation に設定しても影響はありません)。
ネイティブなライブラリと WorkStation ライブラリを同じプロセス内に混在させることはできないため、選択したリモート アクセスのタイプに応じてクライアント プロセスを個別にビルドする必要があります。
| 注意 : | /binding.atmi/@requires の値として propagatesTransaction を指定すると、ATMI バインディングの動作としては、トランザクションの伝播が一切実行されなくなります。このプロトコルは、Tuxedo (SCA または非 SCA) アプリケーションに対するクライアントサイド アクセスにしか使用できないことになっているため、実際にはトランザクションが開始されます。詳細については、「SCA ATMI バインディング」を参照してください。 |
SCA コンテナを使用して行う SCA 呼び出しは、Tuxedo /Domains プロトコルを使用して実行できます。SCDL ファイル内の <binding.atmi> の宣言に、さらにコンフィグレーションする必要はありません。
| 注意 : | /Domains の相互運用コンフィグレーションは Tuxedo 管理者が管理します。 |
| 注意 : | Tuxedo /Domains では、SCA サービス名を以下のようにコンフィグレーションします。 |
| 注意 : | 詳細については、「Tuxedo SCA の相互運用性」を参照してください。 |
Java ATMI (JATMI) バインディングを使用すると、Java で記述した SCA クライアントから Tuxedo サービスや SCA コンポーネントを呼び出すことができます。Tuxedo WorkStation プロトコル (/WS) に基づいて、Tuxedo サービスの一方向呼び出しを提供します。この呼び出しは、Java 環境からサーバとして動作する Tuxedo への発信にのみ使用できます。SCDL バインディング宣言のコンポジット ファイルと異なり、外部コンフィグレーションは必要ありません。サービス名、ワークステーション アドレス、および認証データは、バインディング宣言内で提供されます。
| 注意 : | 現時点で、SSL および LLE は両方ともサポートされていません。 |
JATMI バインディングは、Tuxedo CPP ATMI バインディング要素のほとんどでサポートされており使い方も同じです。ただし、基底のテクノロジと実行環境の違いにより、サポートされない要素や、サポートされていても要素名が異なる場合があります。
以下の Tuxedo CPP ATMI バインディング要素はサポートされません。
Tuxedo CPP ATMI バインディングの以下の workStationParameters 要素はサポートされません。
次の Tuxedo CPP ATMI バインディング要素はサポートされますが一部制限があります。
以下に示す要素内のすべてのクラスは、Java の CLASSPATH に指定する必要があります。
binding.atmi/fieldTables - weblogic.wtc.jatmi.TypedFML 基本クラスから拡張された Java クラスのリストをカンマ区切りで指定します。binding.atmi/fieldTables32 - weblogic.wtc.jatmi.TypedFML32 基本クラスから拡張された Java クラスのリストをカンマ区切りで指定します。binding.atmi/viewFiles - weblogic.wtc.jatmi.TypedView 基本クラスから拡張された Java クラスのリストをカンマ区切りで指定します。これらの派生クラスは、通常は weblogic.wtc.jatmi.viewj コンパイラを使用して Tuxedo VIEW から生成されます。これらには、weblogic.wtc.jatmi.TypedXCType および weblogic.wtc.jatmi.TypedXCommon からの派生クラスも含まれます。
詳細については、『Oracle WebLogic Tuxedo Connector プログラマーズ ガイド』の「viewj コンパイラの使用方法」を参照してください。
binding.atmi/viewFiles32 - webogic.wtc.jatmi.TypedView32 基本クラスから拡張された Java クラスのリストをカンマ区切りで指定します。これらの派生クラスは、通常は weblogic.wtc.jatmi.viewj32 コンパイラを使用して Tuxedo VIEW から生成されます。
コード リスト 6-23 に、Tuxedo サービスのバインディング宣言を記述した「ECHO」という名前のコンポジット ファイルのサンプルを示します。
<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:f="binding-atmi.xsd"
name="ECHO">
<reference name="ECHO" promote="EchoComponent/ECHO">
<interface.java interface="com.abc.sca.jclient.Echo" />
<f:binding.atmi requires="legacy">
<f:inputBufferType target="echoStr">STRING</f:inputBufferType>
<f:outputBufferType target="echoStr">STRING</f:outputBufferType>
<f:errorBufferType target="echoStr">STRING</f:errorBufferType>
<f:workStationParameters>
<f:networkAddress>//STRIATUM:9999,//STRIATUM:1881</f:networkAddr
ess>
</f:workStationParameters>
<f:remoteAccess>WorkStation</f:remoteAccess>
</f:binding.atmi>
</reference>
<component name="EchoComponent">
<implementation.java class="com.abc.sca.jclient.EchoComponentImpl" />
</component>
</component>
コード リスト 6-24 に、上のサンプルのインタフェースを示します。
package com.abc.sca.jclient;
import com.oracle.jatmi.AtmiBindingException;
public interface Echo {String echoStr(String requestString) throws AtmiBindingException;
}
コード リスト 6-25 に、SCA クライアント実装のサンプルを示します。
package com.abc.sca.jclient;
import org.osoa.sca.annotations.Constructor;
import org.osoa.sca.annotations.Reference;
import com.oracle.jatmi.AtmiBindingException;
/**
* JATMI バインディングと参照を使用する単純なクライアント コンポーネント
*/
public class EchoComponentImpl implements Echo {private Echo echoReference;
@Constructor
public EchoComponentImpl(@Reference(name = "ECHO", required = true) Echo
echoReference) {this.echoReference = echoReference;
}
public String echoStr(String requestString) throws AtmiBindingException {return echoReference.echoStr(requestString);
}
}
既存の Tuxedo サービスと相互運用するには、 /binding.atmi/@requires 属性の値として「legacy」を指定します。「legacy」を指定した場合の呼び出しの動作は次のとおりです。
また、/binding.atmi/@requires 属性を使用して内部的にデータ マッピングを管理するため、FML32 や FML のフィールド テーブルは必要ありません。
| 注意 : | 指定しない場合は、SCA -> SCA のセマンティクスで通信するものとみなされ、実際の Tuxedo サービス名は /service/@name または /reference/@name と実際のメソッド名から生成されます (コード リスト 6-26 の擬似スキーマを参照)。 |
ATMI バインディング スキーマでは、/binding.atmi/@requires 属性と 3 つのトランザクション値を使用して SCA トランザクション ポリシーをサポートします。これらのトランザクション値によって、ATMI バインディングの使用時にバインディング拡張が従うべきトランザクション動作が決まります (コード リスト 6-26 の擬似スキーマを参照)。
すべてのトランザクション動作は、Tuxedo コンフィグレーションに応じて決まります。Tuxedo コンフィグレーションでトランザクションがサポートされている場合は、トランザクションが存在していればそのトランザクションを伝播できます。Tuxedo コンフィグレーションでトランザクションがサポートされていないのにトランザクションが存在する場合はエラーになります。ただし、既に存在しているトランザクションでないと開始されません。
suspendsTransaction
この値を指定すると、トランザクション コンテキストは呼び出されたサービスには伝播されません。<service> の場合は、トランザクションが存在していれば、アプリケーション コードを呼び出す前に自動的に中断され、後で呼び出しの結果に関係なく再開されます。<reference> の場合は、TPNOTRAN フラグを指定して tpcall() を実行したのと同じになります。
propagatesTransaction
<reference> 要素にのみ提供されるため、<service> 要素の場合は無視されます。トランザクションが存在しない場合は新しいトランザクションが開始されます。存在する場合は、既存のトランザクションに参加します。このような動作は、UBBCONFIG で <service> を AUTOTRAN にコンフィグレーションすることで、コンポーネントまたはコンポジット内で取得できます。Tuxedo サーバが SCA コンポーネントをホストしており、UBBCONFIG でトランザクション グループにコンフィグレーションされていない場合はエラーが生成されます。
SCA 参照は、binding.atmi SCDL 要素の <authentication> 要素を使用して資格を渡します。
SCA サービスは、内部名を参照することによって ACL で保護できます。SCA -> SCA モードの場合は /binding.atmi/service/@name 属性の後に「/」とメソッド名を付加し、legacy モード (SCA -> Tux 相互運用モード) の場合は /binding.atmi/service/@name 属性を使用します。
「Tuxedo SCA の相互運用性」も参照してください。
Tuxedo の通信は、<binding.atmi> 要素を使用して SCDL でコンフィグレーションします。この方法であれば、TUXCONFIG ファイルの場所、ネイティブな Tuxedo バッファ タイプの使用、Tuxedo 独自の認証、/WS (WorkStation) コンフィグレーション要素など、ATMI 転送に固有のコンフィグレーション要素を指定できます。
コード リスト 6-26 に、<binding.atmi> 要素の要約を示します。
| 注意 : | ? は、0 または 1 回指定できるパラメータを表します。 |
| 注意 : | * は、0 回以上指定できるパラメータを表します。 |
詳細については、『リファレンス ガイド』の「Oracle SALT SCA ATMI バインディングのリファレンス」を参照してください。
<binding.atmi requires="transactionalintent legacyintent"?>
<tuxconfig>...</tuxconfig>?
<map target="name">...</map>*
<serviceType target="name">...</serviceType>*
<inputBufferType target="name">...</inputBufferType>*
<outputBufferType target="name">...</outputBufferType>*
<errorBufferType target="name">...</errorBufferType>*
<workStationParameters>?
<networkAddress>...</networkAddress>?
<secPrincipalName>...</secPrincipalName>?
<secPrincipalLocation>...</secPrincipalLocation>?
<secPrincipalPassId>...</secPrincipalPassId>?
<encryptBits>...</encryptBits>?
</workStationParameters>
<authentication>?
<userName>...</userName>?
<clientName>...</clientName>?
<groupName>...</groupName>?
<passwordIdentifier>...</passwordIdentifier>?
<userPasswordIdentifier>...
</userPasswordIdentifier>?
</authentication>
<fieldTablesLocation>...</fieldTablesLocation>?
<fieldTables>...</fieldTables>?
<fieldTablesLocation32>...</fieldTablesLocation32>?
<fieldTables32>...</fieldTables32>?
<viewFilesLocation>...</viewFilesLocation>?
<viewFiles>...</viewFiles>?
<viewFilesLocation32>...</viewFilesLocation32>?
<viewFiles32>...</viewFiles32>?
<remoteAccess>...</remoteAccess>?
<transaction timeout="xsd:long"/>?
</binding.atmi>
ATMI バインディングを使用すると、Tuxedo インフラストラクチャをより有効に活用できます。そのため、SCA コンポーネント間のデータ交換や、Tuxedo クライアント/サービスと SCA クライアント/コンポーネントの間のデータ交換は、Tuxedo タイプ バッファを使用して行われます。以下の表に、ネイティブ タイプと Tuxedo バッファ/タイプの間の対応 (または SOAP タイプとの対応) をまとめます。
コード リスト 6-27 のサンプルでは、実装が Tuxedo STRING バッファを送受信しています。ソフトウェア (バインディングおよび参照の拡張実装) においては、SCDL コンフィグレーション内の /binding.atmi/inputBufferType、/binding.atmi/outputBufferType、または /binding.atmi/errorBufferType 要素の内容と、サーバ (またはクライアント) から返された (または送信された) バッファのタイプに従って、実際に使用する Tuxedo バッファを決定します。ここでは、クライアントやサーバが ATMI プログラムであるか SCA コンポーネントであるかは関係ありません。
なお、Tuxedo の simpapp サービスには、namespace services 内に独自の namespace があります。C++ の toupper メソッドは、このサービスに関連付けられています。
#include <string>
namespace services
{namespace simpapp
{/**
* ビジネス インタフェース
*/
class ToupperService
{public:
virtual std::string
toupper(const std::string inputString) = 0;
};
} // simpapp の終わり
} // services の終わり
単純な Tuxedo バッファとみなされるのは以下のバッファです。
表 6-1 に、SCA バインディングにマップされる単純な Tuxedo バッファ タイプをまとめます。
SCA クライアントから呼び出したサービスが正常に返されると、サービスによって返されたデータへのポインタが、buildscaclient によって生成されたプロキシ スタブに渡されます。プロキシ スタブは、このポインタを逆参照し、データをアプリケーションに返します。
表 6-1 は次のように解釈できます。
char*、char array、std::string パラメータ、または return タイプを探します。別のタイプが見つかると、何が起きたかを説明するメッセージとともに例外が送出されます。char* を単一のパラメータまたは戻り値型として見るときは、binding.atmi 要素内のバッファ タイプとしての STRING を探します。別の Tuxedo バッファ タイプが見つかると、何が起きたかを説明するメッセージとともに例外が送出されます。
Tuxedo では、マルチバイト文字列を使用してマルチバイト文字データを表現します。使用するエンコーディング名は、Tuxedo で定義されている iconv に基づきます。C++ では、wstring、wchar_t*、または wchar_t[] データ型を使用してマルチバイト文字データを表現します。使用するエンコーディング名は、C++ ライブラリで定義されています。
特定のマルチバイト エンコーディングを表すエンコーディング名が、Tuxedo と C++ で異なる場合があります。Tuxedo エンコーディング名と C++ エンコーディング名のマッピングは以下のとおりです。
SCA クライアントまたはサーバが、MBSTRING バッファや、FLD_MBSTRING フィールドを含む FML32 バッファを受信した場合は、以下のケースに当てはまる最初のロケールがそのマルチバイト文字列のエンコーディングとみなされます。
| 注意 : | 詳細については、「表 6-2」を参照してください。 |
ケース 1 または 2 に当てはまる場合は、受信したバッファのロケールで、ロケール タイプ LC_CTYPE の setlocale() 関数が呼び出されます。指定したロケールが存在しないために setlocale() が失敗し、省略可能な $TUXDIR/locale/setlocale_alias ファイルでこのロケールに代替名が関連付けられている場合は、LC_CTYPE ロケールに代替ロケールを設定できるかどうかが試されます。
$TUXDIR/locale/setlocale_alias ファイルは、必要に応じて Tuxedo 管理者が作成します。このファイルが存在する場合は、Tuxedo MBSTRING コードセット名と、setlocale() 関数で受け付けることのできるオペレーティング システム ロケールとのマッピングが記述されていいます。
Tuxedo MBSTRING コードセット名を含む行の後には、ホワイトスペースと OS ロケール名が続きます。特定の MBSTRING コードセット名に対応する最初の行のみが考慮されます。コメント行は # で始めます。
SALT SCA ソフトウェアでは、$TUXDIR/locale/setlocale_alias ファイルを使用して、MBSTRING データを C++ の wstring または wchar_t[] に変換します。Tuxedo MBSTRING コードセット名を使用している場合に setlocale() が失敗した場合、エリアス名が存在すればそれを使用できるかどうかが試されます。たとえば、ファイルに「GB2312 zh_CN.GB2312」という行が含まれている場合は、setlocale(LC_CTYPE, 'GB2312') が失敗すると setlocale(LC_CTYPE, 'zh_CN.GB2312') が試されます。
SCA クライアントまたはサーバが wstring、wchar_t[]、または wchar_t* を MBSTRING バッファまたは FLD_MBSTRING フィールドに変換する際には、C++ のワイド文字をマルチバイト文字列に変換する際に設定するロケールとして TPMBENC 環境変数の値が使用されます。このロケールがオペレーティング システムで認識されない場合、$TUXDIR/locale/setlocale_alias ファイルが存在していればその代替ロケールが使用されます。
| 注意 : | SALT 10g リリース 3 (10.3) では、Tuxedo MBSTRING バッファ、FML32 FLD_MBSTRING フィールド、または VIEW32 mbstring フィールドから受信したマルチバイト データを転送できます。また、SDO setString() メソッドを使用して入力したマルチバイト データを転送することも可能です。 |
| 注意 : | ただし、マルチバイト文字を XML ドキュメントに直接入力し、このデータを SALT 10g リリース 3 (10.3) 経由で転送することはできません。これは、SDO では wchar_t 配列を使用してマルチバイト文字を表現するのに対し、XML ドキュメントに直接入力したマルチバイト文字はマルチバイト文字列に変換されるためです。 |
C++ の以下の組み込み型は、戻り値型として使用します。複雑な型とみなされ、「複雑な Tuxedo バッファ データのマッピング」に示すバッファ マッピング ルールに従って、単一の汎用フィールドとして FML/FML32 バッファに自動的にカプセル化されます。この仕組みによって、対応する Tuxedo バッファを使用できない場合でも、必要な型が返されるようにしています。
| 注意 : | 組み込み型を返すインタフェースでは、FML/FML32 が出力バッファ タイプとみなされます。この汎用フィールドの名前は、返されるデータの型に基づいて TUX_RTNdatatype になります。TUX_RTNdatatype フィールドは、Tuxedo に付属の Usysflds.h/Usysfl32.h および Usysflds/Usysfl32 で定義されます。 |
bool : TUX_RTNCHAR フィールドにマップされるchar: TUX_RTNCHAR フィールドにマップされるsigned char: TUX_RTNCHAR フィールドにマップされるunsigned char: TUX_RTNCHAR フィールドにマップされるshort: TUX_RTNSHORT フィールドにマップされるunsigned short: TUX_RTNSHORT フィールドにマップされるint: TUX_RTNLONG フィールドにマップされるunsigned int: TUX_RTNLONG フィールドにマップされるlong: TUX_RTNLONG フィールドにマップされるunsigned long: TUX_RTNLONG フィールドにマップされるlong long : TUX_RTNLONG フィールドにマップされるunsigned long long: TUX_RTNLONG フィールドにマップされるfloat: TUX_RTNFLOAT フィールドにマップされるdouble: TUX_RTNDOUBLE フィールドにマップされる
複雑な Tuxedo バッファとみなされるのは以下のバッファです。
表 6-1 に、SCA バインディングにマップされる単純な Tuxedo バッファ タイプをまとめます。
FML および FML32 バッファの場合は、インタフェース内のパラメータ名をフィールド名に対応させ、Tuxedo フィールドに適用される制限 (長さ、使用可能な文字) に従う必要があります。これらのインタフェースを tuxscagen(1) を使用してメタデータから生成した場合は、生成されたコードに適切なフォーマットのパラメータ名が含まれています。
パラメータ名を使用せずに手動でインタフェースを開発したインタフェースが間違っていたり、SALT によって生成されたインタフェースに不適切な変更を加えたりすると、誤った結果が生成される可能性があります。
VIEW (および等価の X_*) バッファと VIEW32 バッファでは、SDO の DataObject ラッパーを使用する必要があります。
コード リスト 6-28 に、インタフェースのサンプルを示します。インタフェースの後に関連付けされているフィールド定義は、プロセス環境内に配置する必要があります。
...
int myService(int param1, float param2); ...
Field table definitions
#name number type flag comment
#---------------------------------------------------------
param1 20 int - Parameter 1
param2 30 float - Parameter 2
...
|
|
||||
|
|
||||
パラメータまたは戻り値型として commonj::sdo::DataObjectPtr オブジェクトを使用する C++ のメソッド プロトタイプは、FML、FML32、VIEW、または VIEW32 バッファにマップされます。
SDO オブジェクトを記述する XML スキーマを提供する必要があります。このスキーマをサービスや参照の拡張ランタイムから使用するには、それらのサービスや参照の定義が格納されている SCDL コンポジット ファイルと同じ場所に、スキーマ ファイル (.xsd ファイル) を配置する必要があります。このスキーマは、要素名とフィールド名の関連付けのため内部的に使用されます。
| 注意 : | view または view32 を使用する場合は、使用する view または view32 に適合する名前のスキーマ タイプ (たとえば complexType) が必要になります。 |
詳細については、SALT 10g リリース 3 (10.3) の『リファレンス ガイド』の「mkfldfromschema」および「mkfld32fromschema」を参照してください。
C++ のメソッド プロトタイプは、ヘッダ内にたとえば次のように定義されています。
long myMethod(commonj::sdo::DataObjectPtr data);
コード リスト 6-29 に関連付けるスキーマを示します。
<xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema
xmlns="http://www.example.com/myExample"
targetNamespace="http://www.example.com/myExample">
<xsd:element name="bike" type="BikeType"/>
<xsd:element name="comment" type="xsd:string"/>
<xsd:complexType name="BikeType">
<xsd:sequence>
<xsd:element name="serialNO" type="xsd:string"/>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="type" type="xsd:string"/>
<xsd:element name="price" type="xsd:float"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
表 6-3 に、生成されるフィールド テーブルを示します。
http://www.osoa.org/download/attachments/36/CPP-SDO-Spec-v2.1.0-FINAL.pdf?version=2
http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V096.pdf?version=1
http://www.osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforCpp_V0.95.pdf?version=1
  
|