| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo CORBA プログラミング・リファレンス > 共同クライアント/サーバ |
|
Tuxedo CORBA プログラミング・リファレンス
|
共同クライアント/サーバ
ここでは、以下の内容について説明します。
この章では、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 なのかによって、動作が少し異なります。
スケルトンからのサーバントの継承
コールバックをサポートするクライアントでは、サーバの場合と同様に、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 方針は、以下のとおりです。
これらのオブジェクトについては、ORB と POA による扱われ方の詳細ではなく、主に動作特性との関連で説明します。これらの詳細は、直接的な ORB および POA の呼び出し (CORBA サーバに関して特別な知識が少し必要) を使用するか、または ORB および POA の呼び出しを隠ぺいする BEAWrapper Callbacks インターフェイス (詳細については考慮しないユーザ向け) を使用して、以下の節で説明します。
注記 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Ｑ を設定する」と、
『BEA Tuxedo コマンド・リファレンス』の「ISL(1)」を参照してください。CORBA を使用してのコールバック・オブジェクトの準備 (C++ 共同クライアント/サーバのみ)
CORBA を使用して BEA Tuxedo C++ コールバック・オブジェクトを設定するには、クライアントは次の処理を行う必要があります。
クライアントが既に 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 {
interface Callbacks
{
exception ServantAlreadyActive{ };
exception ObjectAlreadyActive { };
exception NotInRequest{ };
// 一時コールバック・オブジェクトを設定
// POA を準備し、オブジェクトを活性化し、objref を返す
Object start_transient(
in PortableServer::Servant Servant,
in CORBA::RepositoryId rep_id)
raises (ServantAlreadyActive);// 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 については、以下の節で説明します。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||