![]() |
![]() |
![]() |
![]() |
![]() |
• 概要。この項では、次の内容について説明します。
• プログラマは、Oracle TuxedoのCORBAクライアントと共同クライアント/サーバー(オブジェクト呼出しの受信と処理が可能なクライアント)のいずれかにあわせて、クライアントのmain()を記述します。main()はOracle Tuxedo CORBA環境オブジェクトを使用して接続を確立し、セキュリティを設定し、トランザクションを開始します。Oracle Tuxedoサーバーでは、buildobjserverコマンドを使用して、C++サーバー用のメイン・プログラムを作成します。(Oracle Tuxedoのリリース8.0以降では、Javaサーバーはサポートされていません。)サーバーのメイン・プログラムは、サーバー機能におけるOracle TuxedoおよびCORBA関連の初期化を担当します。しかし、Serverオブジェクトの実装を行うので、サーバー・アプリケーションの初期化と停止の方法をカスタマイズする機会があります。サーバーのメイン・プログラムは、Serverオブジェクトに対し、適切な時点で自動的にメソッドを呼び出します。共同クライアント/サーバーのみで必要な初期化の詳細は、11-3ページの「サーバント」という項を参照してください。Oracle Tuxedo CORBAサーバーでは、Serverインタフェースを使用して、ORBがオブジェクトに対するリクエストを受信したときに、TPフレームワークがそのオブジェクトのためのサーバントの作成をユーザーに求められるようにします。しかし、共同クライアント/サーバーでは、リクエストが届く前にサーバントを作成する役割をユーザー・プログラムが担います。したがって、Serverインタフェースは不要です。通常、プログラムはサーバントを作成してから、オブジェクトへのリファレンスを渡す前に、そのオブジェクトをアクティブ化します。これには、サーバントとObjectIdを使用します。ObjectIdはおそらく、システムで生成されています。そのようなオブジェクトは、コールバックの処理に使用されていると考えられます。したがって、サーバントは既に存在しており、オブジェクトは、そのオブジェクトに対するリクエストが届く前に、アクティブ化されます。C++共同クライアント/サーバーの場合、ある特定の操作を実行するには、TPインタフェースを呼び出すのではなく、TPインタフェースの内部機能であるORBとPOAの呼出しをクライアント・サーバントから直接実行します。また、ORBおよびPOAとの対話の多くは、すべてのアプリケーションで同じなので、使いやすくするため、クライアント・ライブラリにより、単一の操作を使用して同じことを行う便利なラッパー・オブジェクトを提供することもできます。便利なラッパー・オブジェクトを使用する方法の詳細は、「サポートされているコールバック・オブジェクト・モデル」および「OracleWrapper Callbacksを使用してのコールバック・オブジェクトの準備」を参照してください。コールバックをサポートするクライアントでは、サーバーの場合と同様に、IDLコンパイラ(idlコマンド)によって生成されたものと同じスケルトン・クラス名から継承した実装クラスを記述します。サーバーでは、スケルトン・クラスはTPフレームワーク・クラスTobj_ServantBaseから継承します。これがさらに、定義済のPortableServer::ServantBaseから継承しています。共同クライアント/サーバー内のコールバック・オブジェクト実装の継承ツリーは、サーバーのものとは異なります。スケルトン・クラスはTPフレームワーク・クラスTobj_ServantBaseからは継承しませんが、直接PortableServer::ServantBaseから継承します。この振る舞いは、idlコマンドで-Pオプションを指定することによって行われます。サーバントの継承ツリーにTobj_ServantBaseクラスがないということは、そのサーバントにactivate_objectメソッドとdeactivate_objectメソッドがないことを意味します。サーバーでは、これらのメソッドはTPフレームワークによって呼び出され、サーバントに対してあるメソッドを呼び出す前に、そのサーバントの状態を動的に初期化して保存します。コールバックをサポートするクライアントの場合は、明示的にサーバントを作成し、サーバントの状態を初期化するコードを記述する必要があります。
• IdAssignmentPolicy。ユーザーとシステムのどちらがObjectIdを割り当てるかを制御します。
• Transient/SystemId - オブジェクト参照は、クライアント・プロセスが存続する間のみ有効です。ObjectIdは、クライアント・アプリケーションによって割り当てられるのではなく、システムによって割り当てられる一意の値です。この型のオブジェクトは、クライアントが終了するまでの間のみクライアントによって受信される呼出しに有用です。(対応するPOA LifeSpanPolicy値はTRANSIENTで、IdAssignmentPolicyはSYSTEM_IDです。)
• Persistent/SystemId - オブジェクト参照は、複数回のアクティブ化にわたって有効です。ObjectIdはクライアント・アプリケーションによって割り当てられるのではなく、システムによって割り当てられる、一意の値です。この型のオブジェクトおよびオブジェクト参照は、クライアントがある一定期間内で起動したり終了する場合に有用です。稼動中のクライアントは、その特定のオブジェクト参照に対するコールバック・オブジェクトを受信できます。
通常、クライアントは一度オブジェクト参照を作成し、それを自身の恒久的なストレージに保存し、そのオブジェクトが復帰するたびに、オブジェクトのサーバントを再アクティブ化します。たとえばOracle Tuxedo CORBA通知サービスのアプリケーションと共に使用した場合、これらは永続的なサブスクリプションの概念に対応するコールバックです。つまり、通知サービスはコールバック・リファレンスを記憶しており、クライアントが起動して再びイベントを受信する準備が整ったことを宣言すると、イベントを送達します。これにより、通知サービスのサブスクリプションは、クライアントの障害やオフライン時間の影響を受けずに済みます。(対応するPOAポリシーの値は、PERSISTENTおよびSYSTEM_IDです。)
• Persistent/UserId - ObjectIdがクライアント・アプリケーションによって割り当てられる必要がある点を除いては、Persistent/SystemIdと同じです。該当するObjectIdとしては、たとえばクライアントに対してのみ意味を持つデータベース・キーなどが考えられます。(対応するPOAポリシーの値は、PERSISTENTおよびUSER_IDです。)
注意: Transient/UserIdポリシーの組合せは、特に重要なものであるとはみなされません。永続的なケースのどちらかに類似した方式で、ユーザーがPOAを使用して自給することは可能ですが、Oracle Tuxedoラッパーは、特にそのために有用なわけではありません。Oracle Tuxedoサーバーがリモート共同クライアント/サーバー・オブジェクト、つまりOracle Tuxedoドメイン外部の共同クライアント/サーバー・オブジェクトを呼び出せるようにするには、アウトバウンドIIOPが有効になるようにサーバーを構成する必要があります。この機能を有効にするには、IIOPサーバー・リスナー(ISL)サーバー・コマンドで-O (大文字のO)オプションを指定します。-Oオプションを設定すると、IIOPリスナー・ハンドラ(ISH)に接続されていない共同クライアント/サーバー・オブジェクトに対するアウトバウンド呼出し(アウトバウンドIIOP)が有効になります。ISLコマンド・オプションは、サーバーのUBBCONFIGファイルのSERVERSセクションで設定します。アウトバウンドIIOPのサポートには、少量の予備リソースが必要なので、デフォルトではアウトバウンドIIOPは無効になっています。詳細は、『Oracle Tuxedoアプリケーションの設定』のISLコマンドを使用したアウトバウンドIIOPの構成に関する項および『BEA Tuxedoコマンド・リファレンス』のISL(1)に関する項を参照してください。
3. サーバントでコールバック・オブジェクトに対するリクエストを受け付ける準備ができていることをPOAに通知します。技術的には、これはクライアントがPOA内のオブジェクトをactivateすること、つまりサーバントとObjectIdをPOAのアクティブ・オブジェクト・マップに入れることを意味します。クライアントがORBへの参照を取得済であれば、このタスクの実行に必要なORBおよびPOAとの対話は4回です。リスト11-1に示すモデルのようになります。このモデルでは、ルートPOAのみが必要とされます。リスト11-1 Transient/SystemIdモデルPersistent/UserIdモデルを使用するには、POAを作成するときに追加でいくつかの手順が必要になります。さらに、ObjectIdがクライアントによって指定されることから、そのための手順もさらに必要になります。リスト11-2に示すモデルのようになります。リスト11-2 Persistent/UserIdモデルリスト11-3に示すように、OracleWrapperはIDLで記述されます。リスト11-3 OracleWrapper IDLmodule BEAWrapper {
interface Callbacks
{
exception ServantAlreadyActive{ };
exception ObjectAlreadyActive { };
exception NotInRequest{ };
// set up transient callback Object
// -- prepare POA, activate object, return objref
Object start_transient(
in PortableServer::Servant Servant,
in CORBA::RepositoryId rep_id)
raises (ServantAlreadyActive);// set up persistent/systemid callback Object
Object start_persistent_systemid(
in PortableServer::Servant servant,
in CORBA::Repository rep_id,
out string stroid)
raises (ServantAlreadyActive);// set up persistent/userid callback Object
Object start_persistent_userid(
in PortableServer::Servant servant,
in CORBA::RepositoryId rep_id,
in string stroid)
raises (ServantAlreadyActive, ObjectAlreadyActive);// get oid string for the current request
string get_string_oid() raises (NotInRequest);
};
}
#endif /* _BEA_WRAPPER _IDL_ */リスト11-4に示すように、OracleWrapperはC++で記述されます。リスト11-4 C++宣言(beawrapper.h内)BEAWrapper::CallbacksクラスはすでにORBポインタでインスタンス化されています。プロセス内で使用できるこのクラスのインスタンスは1つだけです。より柔軟性が必要なユーザーは、POAを直接使用する必要があります。サーバントはすでにコールバックに使用されています。サーバントは、ObjectIdが1つのコールバックのみに使用できます。複数のObjectIdがあるオブジェクトに対するコールバックを受信するには、複数のサーバントを作成して、個別にアクティブ化する必要があります。同じサーバントを再利用できるのは、stop_object操作がシステムに対して、サーバントを元のObjectIdについて使用することを止めるように指示する場合のみです。
•
• アクティブ化したオブジェクトへのオブジェクト参照を返します。返されたオブジェクト参照が有効である期間は、クライアントが終了するまで、またはstop_object操作によってユーザーがコールバック・サーバントを停止するまでのみです。それ以降は、そのオブジェクト参照に対する呼出しは無効となり、有効にすることができなくなります。システムが生成したObjectIdと、ユーザーが指定したrep_idで作成されたオブジェクトへの参照。オブジェクト参照は、特定のオブジェクト用に定義された_narrow()操作を呼び出すことによって、特定のオブジェクト型に変換する必要があります。変換が終了したときにオブジェクトを解放するのは、呼出し側の役割です。オブジェクトをアクティブ化し、ORBおよびPOAを適切な状態に設定し、出力パラメータstroidを設定し、アクティブ化したオブジェクトへのオブジェクト参照を返します。Object start_persistent_systemid(
in PortableServer::Servant servant,
in CORBA::RepositoryId rep_id,
out string stroid)
raises ( ServantAlreadyActive );CORBA::Object_ptr start_persistent_systemid(
PortableServer::Servant servant,
const char* rep_id,
char*& stroid);
この引数は、システムによって設定され、ユーザーにとっては非透過的です。クライアントは、後になって、おそらくはクライアント・プロセスが終了して再起動してから、restart_persistent_systemidでオブジェクトを再アクティブ化する場合に、これを使用します。サーバントはすでにコールバックに使用されています。サーバントは、ObjectIdが1つのコールバックのみに使用できます。複数のObjectIdがあるコールバックを受信するには、複数のサーバントを作成して、個別にアクティブ化する必要があります。同じサーバントを再利用できるのは、stop操作がシステムに対して、元のObjectIdについてこのサーバントを使用することを止めるように指示する場合のみです。
•
•
• アクティブ化したオブジェクトへのオブジェクト参照を返します。つまり、クライアントが終了してから再起動され、その後同じrep_idで、同じObjectIdについてサーバントをアクティブ化した場合に、サーバントはその同じオブジェクト参照に対して作成されたリクエストを受け付けます。ObjectIdはシステムによって生成されているため、アプリケーションはそのObjectIdを保存しておく必要があります。システムが生成したObjectIdと、ユーザーが指定したrep_idで作成されたオブジェクト参照。オブジェクト参照は、特定のオブジェクト用に定義された_narrow()操作を呼び出すことによって、特定のオブジェクト型に変換する必要があります。変換が終了したときにオブジェクトを解放するのは、呼出し側の役割です。Object restart_persistent_systemid(
in PortableServer::Servant servant,
in CORBA::RepositoryId rep_id,
in string stroid)
raises (ServantAlreadyActive, ObjectAlreadyActive);CORBA::Object_ptr restart_persistent_systemid(
PortableServer::Servant servant,
const char* rep_id
const char* stroid);
作成されているオブジェクト参照内で設定される、ユーザー指定のObjectIdの文字列化されたバージョン。start_persistent_systemidに対する以前の呼出しから返されたものである必要があります。サーバントはすでにコールバックに使用されています。サーバントは、ObjectIdが1つのコールバックのみに使用できます。複数のObjectIdがあるオブジェクトに対するコールバックを受信するには、複数のサーバントを作成して、個別にアクティブ化する必要があります。同じサーバントを再利用できるのは、stop_object操作がシステムに対して、サーバントを元のObjectIdについて使用することを止めるように指示する場合のみです。文字列化されたObjectIdはすでにコールバックに使用されています。ある特定のObjectIdには、1つのサーバントしか関連付けられません。別のサーバントに変更する場合は、まず現在使用しているサーバントでstop_objectを呼び出す必要があります。リポジトリIDがNULL文字列であったか、またはサーバントがNULLポインタであったか、または指定されたObjectIdが事前にシステムによって割り当てられていませんでした。
•
• 再アクティブ化は、restart_persistent_systemidメソッドを使用して実行されます。文字列化されたObjectId stroidと、ユーザーが指定したrep_idで作成されたオブジェクト参照。オブジェクト参照は、特定のオブジェクト用に定義された_narrow()操作を呼び出すことによって、特定のオブジェクト型に変換する必要があります。終了したときにオブジェクトを解放するのは、呼出し側の役割です。Object start_persistent_userid(
portableServer::Servant a_servant,
in CORBA::RepositoryId rep_id,
in string stroid)
raises ( ServantAlreadyActive, ObjectAlreadyActive );サーバントはすでにコールバックに使用されています。サーバントは、ObjectIdが1つのコールバックのみに使用できます。複数のObjectIdがあるオブジェクトに対するコールバックを受信するには、複数のサーバントを作成して、個別にアクティブ化する必要があります。同じサーバントを再利用できるのは、stop_object操作がシステムに対して、サーバントを元のObjectIdについて使用することを止めるように指示する場合のみです。文字列化されたObjectIdはすでにコールバックに使用されています。ある特定のObjectIdには、1つのサーバントしか関連付けられません。別のサーバントに変更する場合は、まず現在使用しているサーバントでstop_objectを呼び出す必要があります。
•
• アクティブ化したオブジェクトへのオブジェクト参照を返します。つまり、クライアントが終了してから再起動され、その後同じrep_idで、同じObjectIdについてサーバントをアクティブ化した場合に、サーバントはその同じオブジェクト参照に対して作成されたリクエストを受け付けます。文字列化されたObjectId stroidと、ユーザーが指定したrep_idで作成されたオブジェクト参照。オブジェクト参照は、特定のオブジェクト用に定義された_narrow()操作を呼び出すことによって、特定のオブジェクト型に変換する必要があります。変換が終了したときにオブジェクトを解放するのは、呼出し側の役割です。void stop_object(PortableServer::Servant servant);インタフェースのC++実装クラスのインスタンス。このサーバントとそのObjectIdとの関連付けは、アクティブ・オブジェクト・マップから削除されます。
注意: 現在のリクエストのObjectIdの文字列バージョンをリクエストします。この操作は、現在のリクエストのObjectIdの文字列バージョンを返します。現在のリクエストのObjectIdの文字列バージョン。これは、オブジェクト参照の作成時に指定された文字列です。この文字列は、オブジェクト参照がstart_persistent_userid関数によって作成された場合にのみ、ユーザーにとって意味があります。(つまり、start_transientおよびstart_persistent_systemidによって作成されたObjectIdは、ORBによって作成されており、ユーザー・アプリケーションとの間に関係はありません。)ラッパーは破棄するがORBは停止しない場合、クライアントはstop_all_objectsメソッドを呼び出す必要があります。