bea ホーム | 製品 | dev2dev | support | askBEA
BEA Logo Tuxedo
 ドキュメントのダウンロード   サイトマップ   用語集 
検索
0
e-docs > Tuxedo > Tuxedo CORBA プログラミング・リファレンス > TP フレームワーク

Tuxedo CORBA プログラミング・リファレンス

 Previous Next Contents View as PDF  

TP フレームワーク

ここでは、以下の内容について説明します。

BEA Tuxedo CORBA TP フレームワークでは、ユーザが高性能の TP アプリケーション用のサーバを作成することを可能にするプログラミング TP フレームワークを提供します。ここでは、TP フレームワークのプログラミング・モデルおよびアプリケーション・プログラミング・インターフェイス (API) について詳しく説明します。この API については、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』でも説明しています。

BEA Tuxedo CORBA サーバを開発する場合、TP フレームワークは必須です。この要件は今後のリリースで緩和される予定ですが、多くの場合、TP フレームワークはアプリケーションの主要な構成部分として使用されると考えられます。

BEA Tuxedo では、ロード・バランシング、トランザクション機能、および管理機能を備えたインフラストラクチャを提供します。TP フレームワークで使用される基本 API は、BEA が拡張した CORBA API です。TP フレームワークの API は、顧客にエクスポーズされます。BEA Tuxedo ATMI は、TP フレームワークの API と混在して利用可能なオプションの API です。この API を使用すると、CORBA サーバと ATMI サーバが混在する環境で分散アプリケーションをデプロイできます。

BEA Tuxedo CORBA 以前、ORB 製品は大規模環境では BEA Tuxedo の性能に及びませんでした。BEA Tuxedo システムは、1 秒あたり数百のトランザクションを処理するアプリケーションをサポートしています。こうしたアプリケーションは、各要求で使用するシステム・リソースを最小限に抑え、したがってスループットおよびコスト・パフォーマンスを最大限に引き出す、BEA Tuxedo のステートレス・サービス・プログラミング・モデルを使用してビルドされます。

現在では、BEA Tuxedo CORBA と TP フレームワークによって、BEA Tuxedo ATMI アプリケーションと同等の性能を持つ CORBA アプリケーションを開発できます。BEA Tuxedo CORBA サーバは、CORBA プログラミング・モデルを使用しながら、BEA Tuxedo ステートレス・サービス・プログラミング・モデルに近いスループット、応答時間、およびプライス・パフォーマンスを実現します。

 

単純なプログラミング・モデル

TP フレームワークでは、単純で便利な CORBA オブジェクトのさまざまなインプリメンテーションのサブセットを選択できます。使用できるのは、サーバ側オブジェクトのインプリメンテーションを開発する場合のみです。クライアント側 CORBA ORB を使用する場合、クライアントは、TP フレームワークが管理するサーバ側インプリメンテーションを持つ CORBA オブジェクトと対話します。クライアントでは TP フレームワークの存在が意識されません。非 BEA Tuxedo サーバ環境で実行される CORBA オブジェクトにアクセスするように作成されたクライアントは、クライアント・インターフェイスの変更や制約もなく、BEA Tuxedo サーバ環境で実行される同じ CORBA オブジェクトにアクセスできます。

TP フレームワークでは、CORBA ポータブル・オブジェクト・アダプタ (POA) よりも使いやすく、理解も簡単で、特にエンタープライズ・アプリケーション向けに準備されたサーバ環境および API が提供されます。これは、単純なサーバ・プログラミング・モデルと、ORBIX や VisiBroker などの ORB を使用していたプログラマにはなじみのある従来の CORBA モデルのインプリメンテーションです。

TP フレームワークを使用すると、次の方法でサーバ環境の複雑さを抑えて、BEA Tuxedo CORBA サーバのプログラミングが容易になります。

TP フレームワークでは以下の機能を利用できます。

制御フロー

TP フレームワークは、ORB および POA と連携して、次の方法でアプリケーション・プログラムのフローを制御します。

オブジェクトの状態管理

TP フレームワーク API には、アプリケーション・コードに CORBA オブジェクトの柔軟な状態管理スキーマを実装するためのコールバック・メソッドが用意されています。状態管理では、オブジェクトを非活性化したり活性化したりするときのオブジェクトの状態を保存および復元する必要があります。状態管理は、サーバの性能およびリソース使用量に影響を与える、活性化されたオブジェクトの有効期間にも関係します。活性化されたオブジェクトのデフォルトの有効期間は、IDL のコンパイル時にインプリメンテーションに割り当てた方針によって制御されます。

トランザクションの統合

TP フレームワークのトランザクション統合には次の機能があります。

オブジェクトのハウスキーピング

TP フレームワークでは、サーバのシャットダウン時に、サーバが関与しているすべてのトランザクションがロールバックされ、活性化されているすべての CORBA オブジェクトが非活性化されます。

高レベルのサービス

TP フレームワーク API の TP インターフェイスには、オブジェクトの登録とユーティリティ関数を実行するメソッドが用意されています。以下のサービスが提供されます。

こうした高レベル・サービスのメソッドは、開発者が CORBA POA、CORBA ネーミング・サービス、および BEA Tuxedo API を理解しなくても、基となるインプリメンテーションとして使用できるようにすることを目的としています。基となる API 呼び出しを高レベルのメソッドのセットと一緒にカプセル化することで、プログラマは、より複雑な基本機能を理解したり使用したりすることなく、ビジネス・ロジックの実現に集中することが可能となります。

 

状態管理

状態管理では、オブジェクトを非活性化したり活性化したりするときのオブジェクトの状態を保存および復元する必要があります。状態管理は、サーバの性能およびリソース使用量に影響を与える、活性化されたオブジェクトの有効期間にも関係します。TP フレームワークの外部 API には、activate_object および deactivate_object メソッドが用意されています。これらのメソッドは、状態管理コードを配置可能な場所を示します。

活性化方針

TP フレームワークでは、状態管理は活性化方針によって提供されます。この方針は、サーバントの作成および破棄ではなく、特定の IDL インターフェイスに対するサーバントの活性化および非活性化を制御します。この方針が適用されるのは、TP フレームワークを使用する CORBA オブジェクトのみです。

活性化方針は、CORBA オブジェクトがメモリ内で活性化しているデフォルトの期間を決定します。CORBA オブジェクトが POA 内で活性化されているのは、POA のアクティブ・オブジェクト・マップにオブジェクト ID と既存のサーバントを関連付けるエントリが入っている場合です。オブジェクトを非活性化すると、オブジェクト ID と活性化されたサーバントとの関連付けが削除されます。選択できる活性化方針は、 method (デフォルト)、transaction、process のいずれかです。

注記 活性化方針は、OMG IDL のコンパイル時に設定する ICF ファイルで設定されます。ICF ファイルの詳細については、「インプリメンテーション・コンフィギュレーションファイル (ICF)」を参照してください。

各活性化方針の内容は次のとおりです。

アプリケーション制御の活性化および非活性化

通常、活性化と非活性化は、既に説明したように、TP フレームワークによって決定されます。ここで説明するテクニックでは、代替メカニズムの使い方を示します。アプリケーションでは、特定の方針が設定されたオブジェクトを明示的に活性化および非活性化するタイミングを制御できます。

明示的な活性化

アプリケーション・コードでは、process 活性化方針を使用するオブジェクトに関して、TP フレームワークのオン・デマンド活性化機能を無効にすることができます。アプリケーションでは、TP::create_active_object_reference 呼び出しを使用して、オブジェクトを「事前活性化」、つまり呼び出しの前に活性化することができます。

事前活性化のしくみは次のとおりです。アプリケーションは、オブジェクト・リファレンスを作成する前に、サーバントをインスタンス化して、その状態を初期化します。アプリケーションは TP::create_active_object_reference を使用して、オブジェクトをアクティブ・オブジェクト・マップに追加、つまりサーバントと ObjectId を関連付けます。最初の呼び出しが行われると、TP フレームワークが、オブジェクト・リファレンスを作成したプロセスに直ちに要求を転送してから、既存のサーバントに転送します。この際、オブジェクトに対する 2 番目以降の呼び出しと同じように、Server::create_servant に次いでサーバントの activate_object メソッドを呼び出す必要はありません。こうしたオブジェクトのオブジェクト・リファレンスは別のサーバを指さないので、活性化されている限り、オブジェクトがオン・デマンドで活性化されることはありません。

事前活性化されたオブジェクトには process 活性化方針が設定されているので、プロセスの終了または TP::deactivateEnable 呼び出しのいずれかのイベントが発生するまで、オブジェクトは活性化されたままとなります。

使用上の注意

事前活性化は、アプリケーションが共用メモリなどを使用して状態を初期化して、初期状態のサーバントを同じプロセスで確立する必要がある場合に特に有用です。状態にポインタ、オブジェクト・リファレンス、または複雑なデータ構造が含まれている場合、後で別のプロセスで状態が初期化されるまで待機する処理は非常に難しくなるからです。TP::create_active_object_reference を使用すると、事前活性化されたオブジェクトは、事前活性化を実行したコードと必ず同じプロセスにあります。事前活性化によってリソースがあらかじめ割り当てられるので、便利な手法であっても、事前活性化を多用することは控える必要があります。ただし、必要に応じて適切に使用すれば、事前活性化はその他の方法よりもはるかに効率的です。

適切な使い方の例として、「イテレータ」パターンを使用するオブジェクトがあります。たとえば、database_query メソッドから電話帳の内容のような長い項目リストがアンバウンディッド IDL シーケンスで返される可能性があるとします。メッセージ・サイズも必要なメモリ量も非常に大きくなるので、こうした項目をすべてシーケンスで返すことは非効率的です。

イテレータ・パターンを使用するオブジェクトは、リストを取得する最初の呼び出しで、一定数の項目をシーケンスで返し、さらに要素を取得する場合に呼び出せる「イテレータ」オブジェクトへのリファレンスも返します。イテレータ・オブジェクトは初期オブジェクトによって初期化されます。つまり、初期オブジェクトはサーバントを作成してその状態を設定し、反復処理が長い項目リストのどの位置で止まっているか (データベース、問い合わせパラメータ、カーソルなどを指すポインタ) をトラッキングします。

初期オブジェクトは、TP::create_active_object_reference を使用して、イテレータ・オブジェクトを事前初期化します。また、初期オブジェクトは、そのオブジェクトへのオブジェクト・リファレンスを作成してクライアントに返します。クライアントは、イテレータ・オブジェクトを繰り返し呼び出して、たとえば、呼び出しごとにリスト内の 100 項目を取得します。こうした場合の事前初期化の利点は、複雑な状態を使用できるということです。通常は、初期オブジェクトに制御がある間に、すべての情報をコンテキスト (呼び出しフレーム) に持っているメソッドを使用して、そうした状態を最初に設定する方法が最も簡単です。

クライアントがイテレータ・オブジェクトの操作を終了したら、初期オブジェクトで最終メソッドを呼び出して、イテレータ・オブジェクトを非活性化します。初期オブジェクトは、TP::deactivateEnable メソッドを呼び出すイテレータ・オブジェクトのメソッドを呼び出すことで、イテレータ・オブジェクトを非活性化します。つまり、イテレータ・オブジェクトは、TP::deactivateEnable メソッドを自身に対して呼び出します。

注意事項

通常、この方法で事前活性化されたオブジェクトの場合、クラッシュすると状態を回復することはできません。最初の遅延活性化で設定するには、状態が複雑すぎるか、一貫性を維持できないと考えられるからです。これは、基本的にオブジェクトが 1 回の活性化期間のみ有効であることを示しており、効果的なオブジェクトのテクニックです。

ただし、「1 回」という使い方のために問題が発生する場合があります。クライアントが状態を含むプロセスにつながるオブジェクト・リファレンスを保持しており、クラッシュするとその状態を再度作成することができないので、クライアントの次の呼び出しが自動的にオブジェクトを新しく活性化することがないように注意を払う必要があります。新しく活性化するとオブジェクトが不当な状態を持つことになるからです。

この問題を解決する方法は、オブジェクトが TP フレームワークによって自動的に活性化されないようにすることです。activate_object 呼び出しの結果として TobjS::ActivateObjectFailed 例外を TP フレームワークに提供した場合、TP フレームワークは活性化を実行せず、CORBA::OBJECT_NOT_EXIST 例外をクライアントに返します。クライアントにはイテレータ (または類似) パターンについての知識があるので、こうした状況について想定しています。クライアントは反復を再度開始するように準備する必要があります。

注記 TP フレームワーク自体でオブジェクト・リファレンスが有効ではなくなったことを検出できるようになれば、こうした保護措置は不要になります。特に、activate_object メソッドが呼び出される可能性を考慮せずに済みます。TP フレームワークが変更される場合、activate_object は呼び出されず、フレームワーク自体が OBJECT_NOT_EXIST 例外を生成するようになります。

自己非活性化

process 活性化方針を設定したオブジェクトを事前活性化できるように、process 活性化方針を設定したオブジェクトを非活性化するよう要求することもできます。事前活性化する機能と非活性化を要求する機能は独立しています。つまり、オブジェクトがどのように活性化されたかに関係なく、オブジェクトを明示的に非活性化することができます。

アプリケーションのメソッドは、TP::deactivateEnable 使用して、オブジェクトを非活性化するように要求できます。TP::deactivateEnable を呼び出して、オブジェクトが非活性化された場合、CORBA オブジェクトに対する以降の呼び出しによって、以前に活性化されたように、同じプロセスで再度活性化されるとは限りません。ObjectId とサーバントとの関連付けは、CORBA オブジェクトが活性化されてから、サーバ・プロセスがシャットダウンされるか、アプリケーションが TP::deactivateEnable を呼び出すまで持続します。関連付けが解除された後、オブジェクトをもう一度呼び出すと、BEA Tuxedo コンフィギュレーション・パラメータで許可された場所で再度活性化することができます。

TP::deactivateEnable には 2 つの形式があります。最初の形式 (パラメータなし) では、実行中のオブジェクトは、呼び出しが行われたメソッドの終了後に非活性化されます。非活性化するかどうかはオブジェクト自身が決定します。通常、この非活性化は、「サインオフ」シグナルとして機能するメソッド呼び出しで行われます。

2 番目の形式の TP::deactivateEnable では、サーバは、オブジェクトが実行中かどうかにかかわりなく、活性化されている任意のオブジェクトを非活性化するよう要求できます。つまり、どのサーバもオブジェクトを非活性化するよう要求できます。この形式では、非活性化するオブジェクトを識別するパラメータを指定します。transaction 活性化方針が設定されたオブジェクトを明示的に非活性化することはできません。トランザクションが終了するまで、そうしたオブジェクトを安全に非活性化することができないからです。

TP::deactivateEnable 呼び出しで、TP フレームワークはサーバントの deactivate_object メソッドを呼び出します。TP フレームワークが deactivate_object を呼び出す正確なタイミングは、非活性化されるオブジェクトの状態によって異なります。オブジェクトが実行中でない場合、TP フレームワークは、制御が呼び出し元に戻る前に、オブジェクトを非活性化します。オブジェクトが実行中の場合もあります。これは常にパラメータを持たない TP::deactivateEnable の場合です。この形式では、実行中のオブジェクトが参照されるからです。この場合、TP::deactivateEnable には、オブジェクトが直ちに非活性化されたかどうか通知されません。

注記 TP::deactivateEnable(interface, object id, servant) method を使用すると、オブジェクトを非活性化できます。ただし、オブジェクトがトランザクションに参加している場合、オブジェクトが非活性化されるのは、トランザクションがコミットまたはロールバックしたときです。トランザクションがコミットまたはロールバックする前にオブジェクトに対して呼び出しが行われた場合、オブジェクトは非活性化されません。

必要な動作が確実に実行されるようにするには、オブジェクトがトランザクションに参加していないことを確認するか、TP::deactivateEnable() を呼び出してからトランザクションが終了するまでオブジェクトに対して呼び出しが行われないようにします。

サーバントの存続期間

サーバントとは、IDL インターフェイスのオペレーションを実装するメソッドを格納した C++ クラスのことです。ユーザはサーバントのコードを記述します。TP フレームワークは、サーバント・コードのメソッドを呼び出して要求を満たします。サーバントは、C++ の「new」文で作成され、C++ の「delete」文で破棄されます。ここでは、作成と破棄、および作成と破棄のタイミングについて説明します。

通常のケース

通常、TP フレームワークはサーバントの存続期間を完全に制御します。基本モデルでは、活性化されていないオブジェクトに対する要求を受け取ると、TP フレームワークがサーバントを取得してから、activate_object メソッドを呼び出してサーバントを活性化します。非活性化する場合、TP フレームワークはサーバントの deactivate_object メソッドを呼び出してから、サーバントを破棄します。

「TP フレームワークがサーバントを取得」するフェーズは、TP フレームワークが、サーバントを作成する必要がある場合に、ユーザ作成のサーバ・メソッド、Server::create_servant または ServerBase::create_servant_with_id を呼び出す、ということです。このとき、アプリケーション・コードは要求されたサーバントを指すポインタを返す必要があります。ほとんどの場合、アプリケーションは、サーバントの新しいインスタンスを作成する C++ 「new」文を使用することで、この処理を行います。「サーバントを破棄」するフェーズは、TP フレームワークが、実際に削除するサーバントへのリファレンスを削除する、ということです。

アプリケーションでは、サーバントを作成および削除する動作が将来のバージョンの製品で変更される可能性があることを考慮しておく必要があります。アプリケーションは現在の動作に依存してはなりませんが、サーバントを再利用するサーバント・コードを記述する必要があります。具体的には、サーバント・コードは、サーバントが C++ 「new」文によって作成されていない場合でも、動作しなければなりません。TP フレームワークは、サーバントが非活性化されてからも削除しないで、後で再度活性化することができます。つまり、サーバントは、コンストラクタでサーバントが作成されたときではなく、サーバントの activate_object メソッドでコールバックされたときに自身を初期化しなければならないということです。

特殊なケース

アプリケーションで TP フレームワークの標準的なサーバントの使い方を変更するには、2 つのテクニックがあります。サーバントの取得に関するものとサーバントの破棄に関するものです。

アプリケーションでは、明示的な事前活性化により、「取得」メカニズムを変更できます。この場合、アプリケーションはサーバントを作成して初期化してから、サーバントを活性化された状態として宣言するように TP フレームワークに要求します。こうしたサーバントは、TP::create_active_object_reference 呼び出しによって TP フレームワークに渡されると、その他のサーバントとまったく同じように TP フレームワークによって扱われます。唯一の違いは、作成および初期化の方法です。

アプリケーションは、サーバントの破棄を TP フレームワークに任せる代わりに自身で処理することで、「破棄」メカニズムを変更できます。サーバントが Server::create_servant、ServerBase::create_servant_with_id または TP::create_active_object_reference によって TP フレームワークに通知されると、TP フレームワークのデフォルト動作は、そのサーバント自体を削除することになります。この場合、アプリケーション・コードでは、非活性化後にそのサーバントへのリファレンスを使用してはなりません。

ただし、アプリケーションから TP フレームワークに対して、TP フレームワークがサーバントを非活性化した後にサーバントを破棄しないように指示することはできます。サーバントの処理は、サーバントのクラス全体について行うのではなく、サーバントを識別するパラメータを付けて Tobj_ServantBase::_add_ref を呼び出すことで、個別に行います。

注記 BEA Tuxedo リリース 8.0 以降で作成するアプリケーションでは、TP::application_responsibility() メソッドの代わりに Tobj_ServantBase::_add_ref メソッドを使用します。TP::application_responsibility() メソッドと違い、add_ref() メソッドは引数を取りません。

サーバントの処理を行うアプリケーションの利点は、サーバントを新しく作成せずに済むことです。サーバントの取得に大きなコストが伴う場合、アプリケーションではサーバントを保存しておいて、後でそれを再利用すると便利です。特に便利なのは事前活性化されたオブジェクトのサーバントの場合ですが、一般的にも言えることです。たとえば、TP フレームワークが次に Server::create_servant または ServerBase::create_servant_with_id を呼び出した場合、アプリケーションは以前に保存しておいたサーバントを返すことができます。

また、アプリケーションがサーバントの処理を行うようにすると、アプリケーションは、サーバントが必要でなくなったとき、つまりほかの C++ インスタンスと同じように、リファレンス数がゼロになったときに、Tobj_ServantBase::_remove_ref を使用してサーバントを削除しなければなりません。_remove_ref() メソッドのしくみについては、「Tobj_ServantBase::_remove_ref()」を参照してください。

シングル・スレッドおよびマルチスレッドのサーバ・アプリケーションの作成方法については、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』を参照してください。

オブジェクトの状態の保存と復元

CORBA オブジェクトが活性化されている間、オブジェクトの状態はサーバント内に格納されます。TP::create_active_object_reference を使用するアプリケーションと違い、状態は、オブジェクトが最初に呼び出されたとき、つまりオブジェクト・リファレンスの作成後に CORBA オブジェクトに対してメソッドが最初に呼び出されたときと、オブジェクトが非活性化されて以降の呼び出しで初期化しなければなりません。CORBA オブジェクトが非活性化されている間、オブジェクトの状態をサーバントが活性化されていたプロセスの外部に保存する必要があります。オブジェクトの状態は、共用メモリ、ファイル、データベースなどに保存できます。CORBA オブジェクトを非活性化する前に、オブジェクトの状態を保存して、オブジェクトが活性化されたときに状態を復元する必要があります。

プログラマは、オブジェクトの状態の構成要素と、オブジェクトを非活性化する前に何を保存し、オブジェクトを活性化した後に何を復元するかを決定する必要があります。

CORBA オブジェクトのコンストラクタおよびデストラクタの使い方に関する注記

CORBA オブジェクトの状態をサーバント・クラスのコンストラクタまたはデストラクタで初期化、保存、または復元してはなりません。TP フレームワークが、サーバントのインスタンスを非活性化するときに削除しないで、再利用する可能性があるからです。サーバントのインスタンスの作成および削除のタイミングについては、一切保証されません。

 

トランザクション

以降の節では、トランザクション方針とトランザクションの使い方について説明します。

トランザクション方針

CORBA オブジェクトがグローバル・トランザクションに参加できるかどうかは、コンパイル時にインプリメンテーションに割り当てられたトランザクション方針によって制御されます。以下の方針を割り当てることができます。

注記 トランザクション方針は、OMG IDL のコンパイル時に設定する ICF ファイルで設定されます。ICF ファイルの詳細については、「インプリメンテーション・コンフィギュレーションファイル (ICF)」を参照してください。

注記 optional 方針は、管理コンフィギュレーションによって影響を受ける唯一のトランザクション方針です。システム管理者が UBBCONFIG ファイルまたは管理ツールを使用して、AUTOTRAN 属性をインターフェイスに対して設定すると、既にトランザクションに関与している場合を除いて、オブジェクトの呼び出し時にトランザクションが自動的に開始されます。つまり、always 方針を指定した場合と同じ動作になります。

トランザクションの初期化

トランザクションの初期化には、次の 2 つの方法があります。

トランザクションの終了

一般に、トランザクションの結果を処理することは、イニシエータの責任です。したがって、次のことが言えます。

BEA Tuxedo システムによって、以下の動作が強制的に実行されます。

トランザクションの一時停止と再開

CORBA オブジェクトは、メソッド呼び出し内のトランザクションの一時停止および再開に関する規則に厳密に従う必要があります。以下に、これらの規則と規則に違反した場合のエラーについて説明します。

CORBA オブジェクト・メソッドが実行を開始すると、トランザクションに関する状態は次の 3 つのいずれかになります。

注記 オペレーション呼び出しを受信したときにトランザクションを自動的に開始する場合、各 CORBA インターフェイスに対して、AUTOTRAN を Yes に設定します。AUTOTRAN を Yes に設定しても、インターフェイスが既にトランザクション・モードにある場合は無効です。AUTOTRAN の詳細については、『BEA Tuxedo CORBA トランザクション』を参照してください。

トランザクションに関する制約

BEA Tuxedo CORBA トランザクションには、以下の制約が適用されます。

SQL とグローバル・トランザクション

SQL およびグローバル・トランザクションを使用する場合には、次のガイドラインに従ってください。

トランザクションの結果に関する判断

CORBA オブジェクトは、トランザクション処理の 2 つの段階で、トランザクションの結果に関与することができます。

注記 SQL カーソルのユーザは、method または process 活性化方針が設定されたオブジェクトを使用する場合に注意する必要があります。プロセスは、クライアントが開始したトランザクション内で SQL カーソルをオープンします。典型的な SQL データベース製品の場合、クライアントがトランザクションをコミットすると、そのトランザクション内でオープンされていたすべてのカーソルは自動的にクローズされますが、オブジェクトにはカーソルがクローズされたことが通知されません。

トランザクションのタイムアウト

トランザクションのタイムアウトが発生すると、トランザクションをロールすることが唯一の結果になるようにトランザクションにマークされ、CORBA::TRANSACTION_ROLLEDBACK 標準例外がクライアントに返されます。新しい要求を送信しようとすると、トランザクションがアボートされるまで、必ず CORBA::TRANSACTION_ROLLEDBACK 例外となって失敗します。

 

パラレル・オブジェクト

リリース 8.0 の BEA Tuxedo CORBA には、性能の拡張を目的としてパラレル・オブジェクトのサポートが追加されています。パラレル・オブジェクト機能を利用すると、特定アプリケーションのすべてのビジネス・オブジェクトを状態を持たないオブジェクトとして指定できます。1 つのドメインの 1 つのサーバでしか実行できない、状態を持つビジネス・オブジェクトと異なり、状態を持たないビジネス・オブジェクトは 1 つのドメインのすべてのサーバで実行できます。パラレル・オブジェクトの利点は以下のとおりです。

パラレル・オブジェクトの詳細については、『BEA Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング』を参照してください。

パラレル・オブジェクトを実装するために、同時実行方針オプションが ICF ファイルに追加されています。特定のアプリケーションに対してパラレル・オブジェクトを選択するには、同時実行方針オプションをユーザ制御に設定します。ユーザ制御の同時実行を選択すると、ビジネス・オブジェクトはアクティブ・オブジェクト・マップ (AOM) に登録されないので状態を持たなくなり、同時に複数のサーバ上で活性化されることができます。このため、こうしたオブジェクトは「パラレル・オブジェクト」と呼ばれます。

ユーザ制御の同時実行を選択した場合、サーバントのインプリメンテーションは以下のいずれかの記述に該当しなければなりません。

リリース 8.0 の BEA Tuxedo ソフトウェアでは、インプリメンテーション・コンフィギュレーションファイル (ICF) が変更されてユーザ制御の同時実行をサポートするようになりました。リスト3-1 では、このサポートのための変更箇所が太字で強調されています。ICF の構文の説明については、「ICF の構文」を参照してください。

コードリスト 3-1 ICF の構文

 
[#pragma activation_policy method|transaction|process]
[#pragma transaction_policy never|ignore|optional|always]
[#pragma concurrency_policy user_controlled|system_controlled]
[Module module-name {]
   implementation [implementation-name]
     {
     implements (module-name::interface-name);
     [activation_policy (method|transaction|process);]
     [transaction_policy (never|ignore|optional|always);]
     [concurrency_policy (user_controlled|system_controlled);]
     };
  [};]

ユーザ制御の同時実行は、ファクトリ・ベース・ルーティング、すべての活性化方針、およびすべてのトランザクション方針で使用できます。これらの機能との対話は次のとおりです。

注記 ユーザ制御の同時実行に関して次の制約があります。TP::create_active_object_reference は、ユーザ制御の同時実行が設定されたインターフェイスを渡されると、TobjS::IllegalOperation 例外をスローします。AOM はユーザ制御の同時実行が設定されている場合に使用されないので、TP フレームワークには活性化されたオブジェクトをこのサーバに接続する方法がありません。

 

TP フレームワーク API

ここでは、TP フレームワーク API について説明します。この API については、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』でも説明しています。

TP フレームワークは以下のコンポーネントで構成されています。

TP フレームワークの可視部分は、2 種類のオペレーションで構成されています。

Server インターフェイス

Server インターフェイスには、アプリケーション固有のサーバ初期化および終了ロジック用のコールバック・メソッドが用意されています。このインターフェイスには、オブジェクトを活性化するためにサーバントが必要な場合に、サーバントを作成するためのコールバック・メソッドも用意されています。

Server インターフェイスには次の特徴があります。

Server インターフェイスのメソッドの説明については、「ServerBase インターフェイス」を参照してください。

C++ 宣言

C++ マッピングについては、「ServerBase インターフェイス」を参照してください。

ServerBase インターフェイス

serverBase インターフェイスを使用すると、マルチスレッド処理機能の利点を最大限に活用できます。ServerBase クラスを継承する独自の Server クラスを作成することもできます。このクラスでは以下のものが提供されます。

ServerBase クラスでは、以前のリリースの Server クラスで利用可能だったオペレーションを使用できます。Server クラスは、ServerBase クラスを継承します。

これらのオペレーションは、シングル・スレッド・アプリケーションでもマルチスレッド・アプリケーションでも使用できます。

これらのメソッドは、マルチスレッド・サーバ・アプリケーションでのみ使用できます。

注記 プログラマは、Server クラスのメソッドを定義する必要があります。ServerBase クラスのメソッドには、デフォルトのインプリメンテーションがあります。

C++ 宣言 (Server.h 内)

C++ のマッピングは次のとおりです。

 
class OBBEXPDLLUSER ServerBase {
public:
 
    virtual CORBA::Boolean
        initialize(int argc, char** argv) = 0;
 
    virtual void
        release() = 0;
 
    virtual Tobj_Servant
        create_servant(const char* interfaceName) = 0;
 
       // デフォルト・インプリメンテーションの指定
       virtual Tobj_Servant
           create_servant_with_id(const char* interfaceName,
                                   const char* stroid);
 
       virtual CORBA::Boolean
           thread_initialize(int argc, char** argv);
 
       virtual void
           thread_release();
 
};
 
class Server : public ServerBase {
public:
 
    CORBA::Boolean initialize(int argc, char** argv);
    void release();
    Tobj_Servant create_servant(const char* interfaceName);
};

 

Back to Top Previous Next
dev2devesupportedocs.bea.compartner net
Contact e-docsContact BEAwebmasterprivacy