|
|
|
|
|
|
共同クライアント/サーバ
ここでは、次の内容について説明します。
この章では、CORBA 共同クライアント/サーバおよび C++ BEAWrapper Callbacks API のプログラミング要件を説明します。Java BEAWrapper パッケージおよび Java Callbacks インターフェイス API については、Javadoc API を参照してください。
はじめに
プログラマは、BEA Tuxedo の CORBA クライアントと共同クライアント/サーバ (オブジェクト呼び出しの受信と処理が可能なクライアント) のどちらかに合わせて、クライアントの main() を記述します。main() は BEA Tuxedo CORBA 環境オブジェクトを使用して接続を確立し、セキュリティを設定し、トランザクションを開始します。
BEA Tuxedo クライアントは、オブジェクトのオペレーションを呼び出します。DII の場合、クライアント・コードによって DII Request オブジェクトが作成され、その DII Request の 2 つのオペレーションのうち一方が呼び出されます。静的呼び出しの場合は、クライアント・コードによって、通常の呼び出しに似た呼び出しが実行されます。これは結果的には、生成されたクライアント・スタブ内のコードを呼び出すことになります。加えて、クライアントのプログラマは OMG によって定義される ORB インターフェイスと、BEA Tuxedo ソフトウェアと共に供給される BEA Tuxedo CORBA 環境オブジェクトを使用して、BEA Tuxedo 固有の機能を実行します。
BEA Tuxedo 共同クライアント/サーバ・アプリケーションでは、クライアント・コードはコールバック BEA Tuxedo オブジェクト用のサーバとして動作できるように構成する必要があります。そのようなクライアントは TP フレームワークを使用しません。また、BEA Tuxedo システムの管理下には置かれません。これはプログラミングに影響を及ぼすほか、CORBA 共同クライアント/サーバには BEA Tuxedo CORBA サーバと同じようなスケーラビリティや信頼性がなく、また TP フレームワークで使用できるような状態管理機能やトランザクション機能もないということを意味します。これらの特性を必要とするユーザは、BEA Tuxedo CORBA のクライアントではなくサーバに、オブジェクトをインプリメントするようアプリケーションを構成する必要があります。
以下の節では、BEA Tuxedo クライアントにコールバックのサポートを追加するために使用するメカニズムを説明します。場合によっては、このメカニズムは TP フレームワークを使用する BEA Tuxedo サーバのメカニズムと対比されます。
メイン・プログラムおよびサーバの初期化
BEA Tuxedo サーバでは、buildobjserver コマンドを使用して、C++ サーバ用のメイン・プログラムを作成します。BEA Tuxedo のリリース 8.0 以降では、Java サーバはサポートされていません。サーバのメイン・プログラムは、サーバ機能における BEA Tuxedo および CORBA 関連の初期化を担当します。しかし、Server オブジェクトのインプリメントを行うので、サーバ・アプリケーションの初期化とシャットダウンの方法をカスタマイズする機会があります。サーバのメイン・プログラムは、Server オブジェクトに対し、適切な時点で自動的にメソッドを呼び出します。
対照的に、BEA Tuxedo CORBA 共同クライアント/サーバでは、BEA Tuxedo CORBA クライアントと同様に、ユーザがメイン・プログラムを作成し、すべての初期化を担当します。メイン・プログラムの完全な制御権があり、都合の良いように初期化およびシャットダウンのコードを指定することができるため、Server オブジェクトをインプリメントする必要はありません。
共同クライアント/サーバのみで必要な初期化については、サーバントで説明します。
サーバント
共同クライアント/サーバ用のサーバント (メソッド・コード) は、サーバ用のサーバントに非常に似ています。すべてのビジネス・ロジックが、同じように記述されます。違いは、TP フレームワークを使用しないことによって生じたものです。つまり主な相違点は、CORBA 関数を TP フレームワーク経由で間接的に使用するのではなく、直接使用するということです。
BEA Tuxedo CORBA サーバでは、Server インターフェイスを使用して、ORB がオブジェクトに対する要求を受信したときに、TP フレームワークがそのオブジェクトのためのサーバントの作成をユーザに求められるようにします。しかし、共同クライアント/サーバでは、要求が届く前にサーバントを作成する役割をユーザ・プログラムが担います。したがって、Server インターフェイスは不要です。通常、プログラムはサーバントを作成してから、オブジェクトへのリファレンスを渡す前に、そのオブジェクトを活性化します。これには、サーバントと ObjectId を使用します。ObjectId はおそらく、システムで生成されています。そのようなオブジェクトは、コールバックの処理に使用されていると考えられます。したがって、サーバントは既に存在しており、オブジェクトは、そのオブジェクトに対する要求が届く前に、活性化されます。
共同クライアント/サーバは、使用されているのが C++ クライアント ORB なのか Java クライアント ORB なのかによって、動作が少し異なります。
TP インターフェイスを呼び出すのではなく、TP インターフェイスの内部機能である ORB と POA の呼び出しをクライアント・サーバントから直接行います。また、ORB および POA との対話の多くは、すべてのアプリケーションで同じなので、使いやすくするため、クライアント・ライブラリにより、単一のオペレーションを使用して同じことを行う便利なラッパー・オブジェクトを提供することもできます。便利なラッパー・オブジェクトの使い方については、「サポートされているコールバック・オブジェクト・モデル」および「BEAWrapper Callbacks を使用してのコールバック・オブジェクトの準備」を参照してください。TP インターフェイスを呼び出すのではなく、クライアント・サーバが直接、Java JDK 1.2 ORB に基づくクライアントである ORB と BOA の呼び出しを行います。また、ORB および BOA との対話の多くは、すべてのアプリケーションで同じなので、共同クライアント/サーバ・ライブラリ (wleclient.jar) により、単一のオペレーションを使用して同じことを行う、便利なラッパー・オブジェクト (Callbacks) を提供することもできます。加えて、ラッパー・オブジェクトは、ObjectIds 用に POA に類似する追加の寿命方針を提供します。「サポートされているコールバック・オブジェクト・モデル」および「BEAWrapper Callbacks を使用してのコールバック・オブジェクトの準備」を参照してください。Java 共同クライアント/サーバの例については、『BEA Tuxedo CORBA ノーティフィケーション・サービス』を参照してください。スケルトンからのサーバントの継承
コールバックをサポートするクライアントでは、サーバの場合と同様に、IDL コンパイラ (idl) によって生成されたものと同じスケルトン・クラス名から継承したインプリメンテーション・クラスを記述します。
C++ におけるスケルトンからの継承例
以下は、次の IDL を想定した C++ の例です。
interface Hospital{ ... };
idl コマンドによって生成されたスケルトンには、次のように、ユーザ記述クラスの継承元である「スケルトン」クラス POA_Hospital が包含されます。
class Hospital_i : public POA_Hospital { ... };
サーバでは、スケルトン・クラスは TP フレームワーク・クラス Tobj_ServantBase から継承します。これがさらに、定義済みの PortableServer::ServantBase から継承しています。
共同クライアント/サーバのコールバック・オブジェクトのインプリメンテーションにおける継承ツリーは、サーバにおけるものとは異なります。スケルトン・クラスは TP フレームワーク・クラス Tobj_ServantBase からは継承しませんが、直接 PortableServer::ServantBase から継承します。この振る舞いは、idl コマンドで -P オプションを指定することによって行われます。
サーバントの継承ツリーに Tobj_ServantBase クラスがないということは、そのサーバントに activate_object メソッドと deactivate_object メソッドがないことを意味します。サーバでは、これらのメソッドは TP フレームワークによって呼び出され、サーバントに対してあるメソッドを呼び出す前に、そのサーバントの状態を動的に初期化して保存します。コールバックをサポートするクライアントの場合は、明示的にサーバントを作成し、サーバントの状態を初期化するコードを記述する必要があります。
Java におけるスケルトンからの継承例
以下は、次の IDL を想定した Java の例です。
interface Hospital{ ... };
idltojava によって生成されたスケルトンには、次のようにユーザ記述クラスの継承元であるスケルトン・クラス _HospitalImplBase が包含されます。
class HospitalImpl extends _HospitalImplBase {...};
BEA Tuxedo サーバ・アプリケーションでは、スケルトン・クラスは TP フレームワーク・クラス com.beasys.Tobj_Servant から継承します。これがさらに、CORBA 定義のクラス org.omg.PortableServer.Servant から継承しています。
共同クライアント/サーバ・アプリケーションのコールバック・オブジェクトのインプリメンテーションにおける継承ツリーは、クライアントにおけるものとは異なります。スケルトン・クラスは TP フレームワーク・クラスからは継承しませんが、org.omg.CORBA.DynamicImplementation クラスから継承します。これがさらに、org.omg.CORBA.portable.ObjectImpl クラスから継承しています。
サーバントの継承ツリーに Tobj_Servant クラスがないということは、そのサーバントに activate_object メソッドと deactivate_object メソッドがないことを意味します。BEA Tuxedo サーバ・アプリケーションでは、これらのメソッドは TP フレームワークによって呼び出され、サーバントに対してあるメソッドを呼び出す前に、そのサーバントの状態を動的に初期化して保存します。共同クライアント/サーバ・アプリケーションでは、ユーザ・コードは明示的にサーバントを作成し、サーバントの状態を初期化する必要があります。したがって、Tobj_Servant オペレーションは不要です。
サポートされているコールバック・オブジェクト・モデル
BEA Tuxedo CORBA は、4 種類のコールバック・オブジェクトをサポートしており、その中で一般的である 3 種類に対してはラッパーを提供しています。これらのオブジェクトは、POA 方針における 3 つの組み合わせに対応しています。POA 方針は、使用可能なオブジェクトの型と、オブジェクト・リファレンスの型の両方を制御します。
適用できる POA 方針は、以下のとおりです。
ObjectId を割り当てるかを制御します。これらのオブジェクトについては、ORB と POA による扱われ方の詳細ではなく、主に動作特性との関連で説明します。これらの詳細は、直接的な ORB および POA の呼び出し (CORBA サーバに関して特別な知識が少し必要) を使用するか、または ORB および POA の呼び出しを隠ぺいする BEAWrapper Callbacks インターフェイス (詳細については考慮しないユーザ向け) を使用して、以下の節で説明します。
ObjectId はクライアント・アプリケーションによって割り当てられるのではなく、システムによって割り当てられる、一意の値です。この型のオブジェクトは、クライアントが終了するまでの間のみクライアントによって受信される呼び出しに有用です。対応する POA LifeSpanPolicy 値は TRANSIENT で、IdAssignmentPolicy は SYSTEM_ID です。 ObjectId はクライアント・アプリケーションによって割り当てられるのではなく、システムによって割り当てられる、一意の値です。この型のオブジェクトおよびオブジェクト・リファレンスは、クライアントがある一定期間内で起動したり終了する場合に有用です。稼動中のクライアントは、その特定のオブジェクト・リファレンスに対するコールバック・オブジェクトを受信できます。 PERSISTENT および SYSTEM_ID です。ObjectId がクライアント・アプリケーションによって割り当てられなければならない点を除いては、Persistent/SystemId と同じです。該当する ObjectId としては、たとえばクライアントに対してのみ意味を持つデータベース・キーなどが考えられます。対応する POA 方針の値は、PERSISTENT および USER_ID です。注記 Transient/UserId 方針の組み合わせ は、特に重要なものであるとは見なされません。永続的なケースのどちらかに類似した方式で、ユーザが POA を使用して自給することは可能ですが、BEA Tuxedo ラッパーは、特にそのために有用なわけではありません。
注記 BEA Tuxedo CORBA のネイティブ共同クライアント/サーバでは、永続方針はどちらもサポートされません。一時方針のみがサポートされます。
リモート共同クライアント/サーバ・オブジェクトを呼び出すためのサーバのコンフィギュレーション
BEA Tuxedo サーバがリモート共同クライアント/サーバ・オブジェクト、すなわち BEA Tuxedo ドメイン外部の共同クライアント/サーバ・オブジェクトを呼び出せるようにするには、アウトバウンド IIOP が有効になるようにサーバをコンフィギュレーションする必要があります。この機能は、IIOP サーバ・リスナ (ISL) コマンドで -O (大文字の O) オプションを指定することによって有効化されます。-O オプションを設定すると、IIOP リスナ・ハンドラ (ISH) に接続されていない共同クライアント/サーバ・オブジェクトに対するアウトバウンド呼び出し (アウトバウンド IIOP) が有効になります。
ISL コマンド・オプションの設定は、サーバの UBBCONFIG ファイルの SERVERS セクションで行います。アウトバウンド IIOP のサポートには、少量の予備資源が必要なので、デフォルトではアウトバウンド IIOP は無効になっています。詳細については、『BEA Tuxedo アプリケーションの設定』の「ISL コマンドを使用してアウトバウンド IIOP を設定する」と、『
ISL(1)」を参照してください。
CORBA を使用してのコールバック・オブジェクトの準備 (C++ 共同クライアント/サーバのみ)
CORBA を使用して BEA Tuxedo C++ コールバック・オブジェクトを設定するには、クライアントは次の処理を行う必要があります。
activate すること、つまりサーバントと
ObjectId を POA のアクティブ・オブジェクト・マップに入れることを意味
します。
クライアントが既に ORB へのリファレンスを取得済みであれば、このタスクの実行に必要な ORB および POA との対話は 4 回です。リスト 11-1 に示すモデルのようになります。このモデルでは、ルート POA のみが必要とされます。
リスト 11-1 Transient/SystemId モデル
// コールバック・オブジェクトのサーバントを作成
Catcher_i* my_catcher_i = new Catcher_i();
// ルート POA リファレンスを取得して、POA を活性化
1 CORBA::Object_var oref =
orb->resolve_initial_references("RootPOA");
2 PortableServer::POA_var root_poa =
PortableServer::POA::_narrow(oref);
3 root_poa -> the_POAManager() -> activate();
4 PortableServer::objectId_var temp_Oid =
root_poa ->activate_object ( my_catcher_i );
5 oref = root_poa->create_reference_with_id(
temp_Oid, _tc_Catcher->id() );
6 Catcher_var my_catcher_ref = Catcher::_narrow( oref );
Persistent/UserId モデルを使用するには、POA 作成時に、いくつかの追加手順が必要です。さらに、クライアント側で ObjectId を指定します。これには、さらに別の手順が必要です。これは リスト 11-2 に示すモデルのようになります。
リスト 11-2 Persistent/UserId モデル
Catcher_i* my_catcher_i = new Catcher_i();
const char* oid_str = "783";
1 PortableServer::objectId_var oid =
PortableServer::string_to_objectId(oid_str);
// ルート POA を見つける
2 CORBA::Object_var oref =
orb->resolve_initial_references("RootPOA");
3 PortableServer::POA_var root_poa =
PortableServer::POA::_narrow(oref);
// Persistent/UserId POA を作成して活性化
4 CORBA::PolicyList policies(2);
5 policies.length(2);
6 policies[0] = root_poa->create_lifespan_policy(
PortableServer::PERSISTENT);
7 policies[1] = root_poa->create_id_assignment_policy(
PortableServer::USER_ID );
8 PortableServer::POA_var my_poa_ref =
root_poa->create_POA(
"my_poa_ref", root_poa->the_POAManager(), policies);
9 root_poa->the_POAmanager()->activate();
// コールバック・オブジェクトのオブジェクト・リファレンスを作成
10 oref = my_poa_ref -> create_reference_with_id(
oid, _tc_Catcher->id());
11 Catcher_var my_catcher_ref = Catcher::_narrow( oref );
// オブジェクトを活性化
12 my_poa_ref -> activate_object_with_id( oid, my_catcher_i );
// callback ref を渡す呼び出しを行う
foo -> register_callback ( my_catcher_ref );
ここに記載したインターフェイスとオペレーションはすべて、標準的な CORBA インターフェイスおよびオペレーションです。
BEAWrapper Callbacks を使用してのコールバック・オブジェクトの準備
C++ または Java の共同クライアント/サーバのどちらかを記述するには、BEAWrapper Callbacks API を使用します。
C++ での BEAWrapper Callbacks の使用
コールバック・オブジェクトに必要なコードは、コールバックをサポートするどのクライアントについてもほぼ同一であるため、共同クライアント/サーバ用のライブラリで提供されている BEAWrapper を使用すると便利なことがあります。
リスト 11-3 に示すように、BEAWrapper は IDL で記述されます。
リスト 11-3 BEAWrapper IDL
// ファイル: BEAWrapper
#ifndef _BEA_WRAPPER _IDL_
#define _BEA_WRAPPER _IDL_
#include <orb.idl>
#include <PortableServer.idll>
#pragma prefix "beasys.com"
module
BEAWrapper{
interfaceCallbacks
{
exception ServantAlreadyActive{ };
exception ObjectAlreadyActive { };
exception NotInRequest{ };
// 一時コールバック・オブジェクトを設定raises (ServantAlreadyActive);
// POA を準備し、オブジェクトを活性化し、objref を返す
Object start_transient(
in PortableServer::Servant Servant,
in CORBA::RepositoryId rep_id)
// persistent/systemid コールバック・オブジェクトを設定
Object start_persistent_systemid(
in PortableServer::Servant servant,
in CORBA::Repository rep_id,
out string stroid)
raises (ServantAlreadyActive);
// persistent/systemid コールバック・オブジェクト
// の設定に戻す
Object restart_persistent_systemid(
in PortableServer::Servant servant,
in CORBA::RepositoryId rep_id,
in string stroid)
raises (ServantAlreadyActive, ObjectAlreadyActive);
// persistent/userid コールバック・オブジェクトを設定
Object start_persistent_userid(
in PortableServer::Servant servant,
in CORBA::RepositoryId rep_id,
in string stroid)
raises (ServantAlreadyActive, ObjectAlreadyActive);
// 所定のサーバントによる、特定のコールバック・オブジェクトの
// 処理を停止
void stop_object( in PortableServer::Servant servant);
// すべてのコールバック・オブジェクト処理を停止
void stop_all_objects();
// 現在の要求に対する oid 文字列を取得;
string get_string_oid() raises (NotInRequest)
};
}
#endif /* _BEA_WRAPPER _IDL_ */
リスト 11-4 に示すように、BEAWrapper は C++ で記述されます。
リスト 11-4 C++ 宣言 (beawrapper.h 内)
#ifndef _BEAWRAPPER_H_
#define _BEAWRAPPER_H_
#include <PortableServer.h>
class BEAWrapper{
class Callbacks{
public:
Callbacks (CORBA::ORB_ptr init_orb);
CORBA::Object_ptr start_transient (
PortableServer::Servant servant,
const char * rep_id);
CORBA::Object_ptr start_persistent_systemid (
PortableServer::Servant servant,
const char * rep_id,
char * & stroid);
CORBA::Object_ptr restart_persistent_systemid (
PortableServer::Servant servant,
const char * rep_id,
const char * stroid);
CORBA::Object_ptr start_persistent_userid (
PortableServer::Servant servant,
const char * rep_id,
const char * stroid);
void stop_object(PortableServer::Servant servant);
char* get_string_oid ();
void stop_all_objects();
~Callbacks();
private:
static CORBA::ORB_var orb_ptr;
static PortableServer::POA_var root_poa;
static PortableServer::POA_var trasys_poa;
static PortableServer::POA_var persys_poa;
static PortableServer::POA_var peruser_poa;
};
};
#endif // _BEAWRAPPER_H_
以下に、BEAWrapper::Callbacks インターフェイスの各オペレーションを上記で宣言された順に説明します。
Java での BEAWrapper Callbacks の使用
コールバック・オブジェクトの準備をするためのコードは、すべての共同クライアント/サーバ・アプリケーションについてほぼ同一であり、Java JDK ORB は POA をインプリメントしないため、BEA Tuxedo は C++ で提供されるラッパー・クラスと事実上同一のラッパー・クラスを共同クライアント/サーバ・ライブラリ内で提供します。このラッパー・クラスは、3 種類のコールバック・オブジェクトをサポートするのに必要な POA 方針をエミュレートします。
リスト 11-5 は、Java Callback ラッパー・インターフェイスを示します。
リスト 11-5 Java Callback ラッパー・インターフェイス
package com.beasys.BEAWrapper;
class Callbacks{
public Callbacks ();
public Callbacks (org.omg.CORBA.Object init_orb);
public org.omg.CORBA.Object start_transient (
org.omg.PortableServer.ObjectImpl servant,
java.lang.String rep_id)
throws ServantAlreadyActive,
org.omg.CORBA.BAD_PARAMETER;
public org.omg.CORBA.Object start_persistent_systemid (
org.omg.PortableServer.ObjectImpl servant,
java.lang.String rep_id,
org.omg.CORBA.StringHolder stroid)
throws ServantAlreadyActive,
org.omg.CORBA.BAD_PARAMETER,
org.omg.CORBA.IMP_LIMIT;
public org.omg.CORBA.Object restart_persistent_systemid (
org.omg.PortableServer.ObjectImpl servant,
java.lang.String rep_id,
java.lang.String stroid)
throws ServantAlreadyActive,
ObjectAlreadyActive,
org.omg.CORBA.BAD_PARAMETER,
org.omg.CORBA.IMP_LIMIT;
public org.omg.CORBA.Object start_persistent_userid (
org.omg.PortableServer.ObjectImpl servant,
java.lang.String rep_id,
java.lang.String stroid)
throws ServantAlreadyActive,
ObjectAlreadyActive,
org.omg.CORBA.BAD_PARAMETER,
org.omg.CORBA.IMP_LIMIT;
public void stop_object(
org.omg.PortableServer.ObjectImpl
servant);
public String get_string_oid ()
throws NotInRequest;
public void stop_all_objects();
};
Java 共同クライアント/サーバのプログラミング上の考慮事項
ここでは、次の Java のプログラミング上のトピックについて説明します。
メイン・プログラムのスレッドに関する考慮事項
プログラムが Java クライアントにおいて、Java 共同クライアント/サーバの場合と同様にクライアントとサーバの両方の機能を持つとき、この 2 つの部分を別々のスレッドで同時に実行できます。実行環境としての Java は本来マルチスレッドなので、Java クライアントから org.omg.CORBA.orb.work_pending メソッドおよび org.omg.CORBA.orb.perform_work メソッドを呼び出す理由はありません。実際、Java クライアントがこれらのメソッドを呼び出そうとすると、メソッドからは org.omg.CORBA.NO_IMPLEMENT 例外が発生します。クライアントが org.omg.CORBA.orb.run メソッドを呼び出す必要はありません。すべてのマルチスレッド環境の場合と同じく、クライアント・アプリケーション内で同時に実行できるコード (コールバック用のクライアントとサーバント) はすべて、スレッド・セーフになるようにコーディングする必要があります。
複数のスレッドのしくみ
Java では、クライアントはメイン・スレッドで起動します。次にクライアントは、Callbacks ラッパー・クラスで提供される (re)start_xxxx メソッドのうちの任意のものに対する呼び出しを通じて、コールバック・オブジェクトを設定します。ラッパー・クラスは、サーバント、および ORB のオブジェクト・マネージャにおける関連の OID の登録を処理します。これでアプリケーションは、(re)start_xxxx メソッドから返されたオブジェクト・リファレンスを、サーバントのコールバックが必要なアプリケーションへ、自由に渡せるようになります。
注記 ORB は、サーバントを効果的に初期化し、別のアプリケーションに正しくマーシャリングできる有効なオブジェクト・リファレンスを作成するために、(re)start_xxxx メソッドの 1 つに対する明示的な呼び出しを必要とします。これは、アプリケーションがまだオブジェクト・リファレンスをマーシャリングしていない場合、それを行う際に orb.connect メソッドを内部的に呼び出すことによって、暗黙的なオブジェクト・リファレンス作成を可能とする、基本的な JDK 1.2 ORB の振る舞いからは逸脱しています。
コールバック・オブジェクトに対する呼び出しは、ORB によって処理されます。各要求を受信すると、ORB はその要求をオブジェクト・マネージャに対して評価し、その要求のスレッドを作成します。ORB は各要求について新規スレッドを作成するので、同じオブジェクトに同時に複数の要求を行うことができます。これが、コールバックのサーバント・コードをスレッド・セーフになるように記述する必要がある理由です。各要求が終了すると、サーバントを実行するスレッドも終了します。
メイン・クライアント・スレッドは、クライアント呼び出しを何度でも必要なだけ行うことができます。stop_(all_)object メソッドに対する呼び出しは、単にオブジェクト・マネージャのリストからオブジェクトを取り出し、それに対するこれ以上の呼び出しを防止するだけです。停止されたオブジェクトの呼び出しは、そのオブジェクトがまったく存在しない場合と同様に失敗します。
別のスレッドからコールバックの結果を取得する必要がある場合、クライアント・アプリケーションはそのために通常のスレッド同期化技術を使用する必要があります。
BEA Tuxedo のリモート的なクライアント・アプリケーション内のスレッド (クライアント・メインまたはサーバント) が終了すると、すべてのクライアント・プロセス・アクティビティが停止され、Java 実行環境が終了します。return メソッドの呼び出しはスレッドを終了させる場合にのみ行うことをお勧めします。
Java クライアント ORB の初期化
クライアント・アプリケーションは、BEA 提供のプロパティによって ORB を初期化する必要があります。これは、ORB が Callbacks ラッパー・クラスおよび Bootstrap オブジェクトをサポートする、BEA 提供のクラスおよびメソッドを利用できるようにするためです。これらのクラスは、$TUXDIR/udataobj/java/jdk (Soloaris の場合) または %TUXDIR%\udataobj\java\jdk (Windows の場合) にインストールされる wleclient.jar にあります。アプリケーションは、これを行うために、リスト 11-6 に示すいくつかのシステム・プロパティを設定する必要があります。
リスト 11-6 システム・プロパティの設定
Properties prop = new Properties(System.getProperties());
prop.put("org.omg.CORBA.ORBClass","com.beasys.CORBA.iiop.ORB");
prop.put("org.omg.CORBA.ORBSingletonClass",
"com.beasys.CORBA.idl.ORBSingleton");
System.setProperties(prop);
//ORB を初期化
ORB orb = ORB.init(args, prop);
IIOP のサポート
IIOP は、ORB 間の通信に使用するプロトコルです。IIOP は、さまざまなベンダ製の ORB の相互運用を可能にします。Java サーバ・アプリケーションの場合、永続オブジェクト・リファレンス方針またはユーザ ID オブジェクト・リファレンス方針について、クライアント側でポート番号を指定する必要があります。
Java アプレットのサポート
コールバックまたはコールアウトを受信するアプレットのための IIOP のサポートは、アプレットのセキュリティ・メカニズムにより制限されています。独自の環境またはプロトコルによるソケットの作成およびリッスンが可能なアプレット実行時環境であれば、BEA Tuxedo 共同クライアント/サーバ・アプリケーションとして動作できます。アプレットの実行時環境がソケット通信を制限している場合、そのアプレットを BEA Tuxedo アプリケーションに対する共同クライアント/サーバ・アプリケーションにはできません。
永続オブジェクト・リファレンスのためのポート番号
BEA Tuxedo Java リモート共同クライアント/サーバ・アプリケーションで IIOP をサポートするには、サーバ・コンポーネント用に作成されたオブジェクト・リファレンスにホストとポートが含まれている必要があります。一時オブジェクト・リファレンスの場合、どのポートでも条件は満たされ、ORB で動的に取得できます。しかし、これは永続オブジェクト・リファレンスには不適当です。
永続リファレンスは、ORB の再起動後に同じポート上で処理する必要があります。つまり、ORB はオブジェクト・リファレンスを作成したのと同じポート上で要求を受け付けるように準備されなければなりません。したがって、特定のポートを使用するように ORB をコンフィギュレーションする方法が必要です。
永続リファレンスのコールバック用サーバとして動作する予定の Java クライアントを、まず指定のポートで起動する必要があります。これは、システム・プロパティ org.omg.CORBA.ORBPort を次のコマンドのように設定することによって行います。
Windows:
java -DTOBJADDR=//
host:port-Dorg.omg.CORBA.ORBPort=xxxx-classpath=%CLASSPATH% client
UNIX:
java -DTOBJADDR=//
host:port
-Dorg.omg.CORBA.ORBPort=xxxx-classpath=$CLASSPATH client
通常、システム管理者は、動的範囲ではなくポート番号のユーザ範囲からクライアントのポート番号を割り当てます。これにより、共同クライアント/サーバ・アプリケーションでポートの競合を防ぐことができます。
BEA Tuxedo リモート共同クライアント/サーバ・アプリケーションが、上記のコマンド行のようにポートの設定をせずに永続オブジェクト・リファレンスを作成しようとすると、オペレーションにより例外 IMP_LIMIT が発生し、真に永続的なオブジェクト・リファレンスが作成できないことをユーザに通知します。
C++ BEAWrapper Callbacks インターフェイス API
この C++ BEAWrapper Callbacks インターフェイス API については、以下の節で説明します。
Callbacks
概要
Callbacks インターフェイスへのリファレンスを返します。
C++ バインディング
BEAWrapper::Callbacks( CORBA::ORB_ptr init_orb);
Java バインディング
public Callbacks(org.omg.CORBA.Object init_orb);
引数
init_orb
これ以降のすべてのオペレーションに使用する ORB。
例外
CORBA::IMP_LIMIT
BEAWrapper::Callbacks クラスは既に ORB ポインタでインスタンス化されています。プロセス内で使用できるこのクラスのインスタンスは 1 つだけです。より柔軟性が必要なユーザは、POA を直接使用する必要があります。
説明
コンストラクタは、Callbacks インターフェイスへのリファレンスを返します。複数のスレッドが使用されている場合でも、プロセスのために作成するそのようなオブジェクトは 1 つのみとします。複数のオブジェクトを使用すると、未定義の振る舞いが発生します。
戻り値
Callbacks オブジェクトへのリファレンス。
start_transient
概要
オブジェクトを活性化し、ORB および POA を適切な状態に設定し、活性化したオブジェクトへのオブジェクト・リファレンスを返します。
IDL
Object start_transient( in PortableServer::Servant servant,
in CORBA::RepositoryId rep_id)
raises ( ServantAlreadyActive );
C++ バインディング
CORBA::Object_ptr start_transient(
PortableServer::Servant servant,
const char* rep_id);
Java バインディング
org.omg.CORBA.Object start_transient(
org.omg.PortableServer.Servant servant,
java.lang.String rep_id);
引数
servant
インターフェイスの C++ インプリメンテーション・クラスのインスタンス。
rep_id
インターフェイスのリポジトリ id。
例外
ServantAlreadyActive
サーバントは既にコールバックに使用されています。サーバントは、ObjectId が 1 つのコールバックのみに使用できます。複数の ObjectId があるオブジェクトに対するコールバックを受信するには、複数のサーバントを作成して、個別に活性化する必要があります。同じサーバントを再利用できるのは、stop_object オペレーションがシステムに対して、サーバントを元の ObjectId について使用することを止めるように指示する場合のみです。
CORBA::BAD_PARAM
リポジトリ ID が NULL 文字列であったか、サーバントが NULL ポインタでした。
説明
このオペレーションは、次の作業を実行します。
rep_id 型のサービス・オブジェクトに与えられた Servant を使用するオブジェクトを活性化します。これには、システムによって生成された ObjectId を使用します。 stop_object オペレーションによってユーザがコールバック・サーバントを停止するまでのみです。それ以降は、そのオブジェクト・リファレンスに対する呼び出しは無効となり、絶対に有効化できません。戻り値
CORBA::Object_ptr
システムが生成した ObjectId と、ユーザが指定した rep_id で作成されたオブジェクトへのリファレンス。オブジェクト・リファレンスは、特定のオブジェクト用に定義された _narrow() オペレーションを呼び出すことによって、特定のオブジェクト型に変換する必要があります。変換が終了したときにオブジェクトを解放するのは、呼び出し側の役割です。
start_persistent_systemid
概要
オブジェクトを活性化し、ORB および POA を適切な状態に設定し、出力パラメータ stroid を設定し、活性化したオブジェクトへのオブジェクト・リファレンスを返します。
IDL
Object
start_persistent_systemid(
in PortableServer::Servant servant,
in CORBA::RepositoryId rep_id,
out string stroid)
raises ( ServantAlreadyActive );
C++ バインディング
CORBA::Object_ptr
start_persistent_systemid(
PortableServer::Servant servant,
const char* rep_id,
char*& stroid);
Java バインディング
org.omg.CORBA.Object
start_persistent_systemid(
org.omg.PortableServer.Servant servant,
java.lang.String rep_id,
java.lang.String stroid);
引数
servant
インターフェイスの C++ インプリメンテーション・クラスのインスタンス。
rep_id
インターフェイスのリポジトリ ID。
stroid
この引数はシステムによって設定され、ユーザにとってはオペークです。クライアントは、後になって、おそらくはクライアント・プロセスが終了して再起動してから、この引数が restart_persistent_systemid でオブジェクトを再活性化する場合に、これを使用します。
例外
ServantAlreadyActive
サーバントは既にコールバックに使用されています。サーバントは、ObjectId が 1 つのコールバックのみに使用できます。複数の ObjectId があるコールバックを受信するには、複数のサーバントを作成して、個別に活性化する必要があります。同じサーバントを再利用できるのは、stop オペレーションがシステムに対して、元の ObjectId についてこのサーバントを使用することを止めるように指示する場合のみです。
CORBA::BAD_PARAMETER
リポジトリ ID が NULL 文字列であったか、サーバントが NULL ポインタでした。
CORBA::IMP_LIMIT
この例外のほかのシステム上の理由に加えて、この状況に特有の理由は、共同クライアント/サーバがポート番号付きでは初期化されておらず、したがって永続オブジェクト・リファレンスが作成できないことです。
説明
このオペレーションは、次の作業を実行します。
rep_id 型のサービス・オブジェクトに与えられた Servant を使用するオブジェクトを活性化します。これには、システムによって生成された ObjectId を使用します。 stroid を、システムによって割り当てられた ObjectId の文字列化されたバージョンに設定します。 rep_id で、同じ ObjectId についてサーバントを活性化した場合に、サーバントはその同じオブジェクト・リファレンスに対して行われた要求を受け付けます。ObjectId はシステムによって生成されているため、アプリケーションはその ObjectId を保存しておく必要があります。戻り値
CORBA::Object_ptr
システムが生成した ObjectId と、ユーザが指定した rep_id で作成されたオブジェクト・リファレンス。オブジェクト・リファレンスは、特定のオブジェクト用に定義された _narrow() オペレーションを呼び出すことによって、特定のオブジェクト型に変換する必要があります。変換が終了したときにオブジェクトを解放するのは、呼び出し側の役割です。
restart_persistent_systemid
概要
オブジェクトを活性化し、ORB および POA を適切な状態に設定し、活性化したオブジェクトへのオブジェクト・リファレンスを返します。
IDL
Object
restart_persistent_systemid(
in PortableServer::Servant servant,
in CORBA::RepositoryId rep_id,
in string stroid)
raises (ServantAlreadyActive, ObjectAlreadyActive);
C++ Binding
CORBA::Object_ptr
restart_persistent_systemid(PortableServer::Servant servant,
const char* rep_id
const char* stroid);
Java バインディング
org.omg.CORBA.Object
restart_persistent_systemid(
org.omg.PortableServer.Servant servant,
java.lang.String rep_id,
java.lang.String stroid);
引数
servant
インターフェイスの C++ インプリメンテーション・クラスのインスタンス。
rep_id
インターフェイスのリポジトリ ID。
stroid
作成されているオブジェクト・リファレンス内で設定される、ユーザ指定の ObjectId の文字列化されたバージョン。start_persistent_systemid に対する以前の呼び出しから返されたものである必要があります。
例外
ServantAlreadyActive
サーバントは既にコールバックに使用されています。サーバントは、ObjectId が 1 つのコールバックのみに使用できます。複数の ObjectId があるオブジェクトに対するコールバックを受信するには、複数のサーバントを作成して、個別に活性化する必要があります。同じサーバントを再利用できるのは、stop_object オペレーションがシステムに対して、サーバントを元の ObjectId について使用することを止めるように指示する場合のみです。
ObjectAlreadyActive
文字列化された ObjectId は既にコールバックに使用されています。ある特定の ObjectId には、1 つのサーバントしか関連付けられません。別のサーバントに変更する場合は、まず現在使用しているサーバントで stop_object を呼び出す必要があります。
CORBA::BAD_PARAM
リポジトリ ID が NULL 文字列であったか、またはサーバントが NULL ポインタであったか、または指定された ObjectId が事前にシステムによって割り当てられていませんでした。
CORBA::IMP_LIMIT
この例外のほかのシステム上の理由に加えて、この状況に特有の理由は、共同クライアント/サーバがポート番号付きでは初期化されておらず、したがって永続オブジェクト・リファレンスが作成できないことです。
説明
このオペレーションは、次の作業を実行します。
rep_id 型のサービス・オブジェクトに与えられた Servant を使用するオブジェクトを活性化します。これには、指定の stroid (文字列化された ObjectId) を使用します。これは、事前に start_persistent_systemid に対する呼び出しによって取得されている必要があります。 restart_persistent_systemid メソッドを使用して行われます。戻り値
CORBA::Object_ptr
文字列化された ObjectId stroid と、ユーザが指定した rep_id で作成されたオブジェクト・リファレンス。オブジェクト・リファレンスは、特定のオブジェクト用に定義された _narrow() オペレーションを呼び出すことによって、特定のオブジェクト型に変換する必要があります。終了したときにオブジェクトを解放するのは、呼び出し側の役割です。
start_persistent_userid
概要
オブジェクトを活性化し、ORB および POA を適切な状態に設定し、活性化したオブジェクトへのオブジェクト・リファレンスを返します。
IDL
Object
start_persistent_userid(portableServer::Servant a_servant,
in CORBA::RepositoryId rep_id,
in string stroid)
raises ( ServantAlreadyActive, ObjectAlreadyActive );
C++ バインディング
CORBA::Object_ptr start_persistent_userid (
PortableServer::Servant servant,
const char* rep_id,
const char* stroid);
Java バインディング
org.omg.CORBA.Object
start_persistent_userid(
org.omg.PortableServer.Servant servant,
java.lang.String rep_id,
java.lang.String stroid);
引数
servant
インターフェイスの C++ インプリメンテーション・クラスのインスタンス。
rep_id
インターフェイスのリポジトリ ID。
stroid
作成されているオブジェクト・リファレンス内で設定される、ユーザ指定の ObjectId の文字列化されたバージョン。stroid は、アプリケーション固有のデータを保持しており、ORB 側からはオペークです。
例外
ServantAlreadyActive
サーバントは既にコールバックに使用されています。サーバントは、ObjectId が 1 つのコールバックのみに使用できます。複数の ObjectId があるオブジェクトに対するコールバックを受信するには、複数のサーバントを作成して、個別に活性化する必要があります。同じサーバントを再利用できるのは、stop_object オペレーションがシステムに対して、サーバントを元の ObjectId について使用することを止めるように指示する場合のみです。
ObjectAlreadyActive
文字列化された ObjectId は既にコールバックに使用されています。ある特定の ObjectId には、1 つのサーバントしか関連付けられません。別のサーバントに変更する場合は、まず現在使用しているサーバントで stop_object を呼び出す必要があります。
CORBA::BAD_PARAM
リポジトリ ID が NULL 文字列であったか、サーバントが NULL ポインタでした。
CORBA::IMP_LIMIT
この例外のほかのシステム上の理由に加えて、この状況に特有の理由は、共同クライアント/サーバがポート番号付きでは初期化されておらず、したがって永続オブジェクト・リファレンスが作成できないことです。
説明
このオペレーションは、次の作業を実行します。
rep_id 型のサービス・オブジェクトに与えられた Servant を使用するオブジェクトを活性化します。これには、オブジェクト ID stroid を使用します。 rep_id で、同じ ObjectId についてサーバントを活性化した場合に、サーバントはその同じオブジェクト・リファレンスに対して行われた要求を受け付けます。戻り値
CORBA::Object_ptr
文字列化された ObjectId stroid と、ユーザが指定した rep_id で作成されたオブジェクト・リファレンス。オブジェクト・リファレンスは、特定のオブジェクト用に定義された _narrow() オペレーションを呼び出すことによって、特定のオブジェクト型に変換する必要があります。変換が終了したときにオブジェクトを解放するのは、呼び出し側の役割です。
stop_object
概要
所定のサーバントを使用しているオブジェクトに対する要求の受け付けを止めるように ORB に指示します。
IDL
void stop_object( in PortableServer::Servant servant);
C++ バインディング
void
stop_object(PortableServer::Servant servant);
Java バインディング
void
stop_object(org.omg.PortableServer.Servant servant);
引数
servant
インターフェイスの C++ インプリメンテーション・クラスのインスタンス。このサーバントと、ObjectId の間の関連付けは、アクティブ・オブジェクト・マップから削除されます。
例外
特にありません。
説明
このオペレーションは、所定のサーバントに対する要求の受け付けを止めるように ORB に指示します。サーバントの状態は、活性化されていても、不活性化されていてもかまいません。エラーが報告されることはありません。
注記 stop_object オペレーションの呼び出し後にコールバック・オブジェクトを呼び出すと、呼び出し側に OBJECT_NOT_EXIST 例外が返されます。これは、stop_object オペレーションが事実上、オブジェクトを削除するためです。
戻り値
特にありません。
stop_all_objects
概要
すべてのサーバントに対する要求の受け付けを止めるように ORB に指示します。
IDL
void stop_all_objects ();
C++ バインディング
void stop_all_objects ();
Java バインディング
void stop_all_objects ();
例外
特にありません。
説明
このオペレーションは、このプロセスで設定されたすべてのサーバントに対する要求の受け付けを止めるように ORB に指示します。
使用上の注意
ORB::shutdown メソッドを呼び出したクライアントが、その後に stop_all_objects を呼び出さないようにしてください。
戻り値
特にありません。
get_string_oid
概要
現在の要求の ObjectId の文字列バージョンを要求します。
IDL
string get_string_oid() raises (NotInRequest);
C++ バインディング
char* get_string_oid();
Java バインディング
java.lang.String get_string_oid();
例外
NotInRequest
ORB が要求のコンテキスト内に入っていなかったとき、つまり ORB がメソッド・コード内の要求を処理していないときに、関数が呼び出されました。この関数をクライアント・コードから呼び出さないでください。これは、コールバック・オブジェクト (すなわちサーバント) のメソッド実行中のみ有効です。
説明
このオペレーションは、現在の要求の ObjectId の文字列バージョンを返します。
戻り値
char*
現在の要求の ObjectId の文字列バージョン。これは、オブジェクト・リファレンスの作成時に指定された文字列です。この文字列がユーザにとって意味を持つのは、オブジェクト・リファレンスが start_persistent_userid 関数によって作成された場合のみです。つまり、start_transient および start_persistent_systemid によって作成された ObjectId は、ORB によって作成されており、ユーザ・アプリケーションとの間に関係はありません。
~Callbacks
概要
コールバック・オブジェクトを破棄します。
C++ バインディング
BEAWrapper::~Callbacks( );
Java バインディング
public~Callbacks();
引数
特にありません。
例外
特にありません。
説明
このデストラクタは、コールバック・オブジェクトを破棄します。
使用上の注意
ラッパーは破棄するが ORB はシャットダウンしない場合、クライアントは stop_all_objects メソッドを呼び出す必要があります。
戻り値
特にありません。
Java BEAWrapper Callbacks インターフェイス API
BEAWrapper.Callbacks インターフェイス API の完全な説明については、Javadoc API を参照してください。
|
|
|
|
|
|
Copyright © 2001, BEA Systems, Inc. All rights reserved.
|