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

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

 Previous Next Contents View as PDF  

FactoryFinder インターフェイス

FactoryFinder インターフェイスは、BEA Tuxedo ドメインへの唯一のエントリ・ポイントとして作用する 1 つのオブジェクト・リファレンスをクライアントに提供します。BEA Tuxedo NameManager により、FactoryFinder のオブジェクト・リファレンスに対するファクトリ名のマッピングが提供されます。複数の FactoryFinder と NameManager が一緒になると、可用性と信頼性が向上します。このリリースでは、機能性のレベルを拡張して、複数ドメインをサポートしています。

注記 NameManager は CORBA サービス・ネーミング・サービスのようなネーミング・サービスではなく、登録されたファクトリを格納するための単なる手段です。

BEA Tuxedo 環境では、アプリケーション・ファクトリ・オブジェクトを使用して、クライアントがビジネス・オペレーション (TellerFactory、Teller など) の実行のためにやり取りするオブジェクトを作成します。一般に、アプリケーション・ファクトリはサーバの初期化中に作成され、リモート・クライアントと、サーバ・アプリケーション内に置かれたクライアントの双方からアクセスされます。

FactoryFinder インターフェイスと NameManager サービスは、アプリケーション・サーバではない個別のサーバに格納されています。クライアントとサーバの両アプリケーションがファクトリ情報にアクセスしてこれを更新できるように、アプリケーション・プログラミング・インターフェイス (API) のセットが提供されています。

このリリースで複数ドメインをサポートしたことにより、多数のマシンを使用するようスケーリングしたり、アプリケーション環境を分割したりする必要のある顧客にとっての利便性が向上しています。複数ドメインをサポートするために、BEA Tuxedo 環境内でファクトリを見つけるためのメカニズムが拡張され、あるドメインのファクトリを別のドメインでも認識できるようになっています。別のドメインのファクトリの可視性は、システム管理者によって制御されます。

 

機能、制限事項、および要件

アプリケーション・ファクトリは、サーバ・アプリケーションの初期化中に NameManager で登録する必要があります。それにより、クライアントに FactoryFinder のオブジェクト・リファレンスを提供し、それらがファクトリ登録時に作成された関連する名前に基づくファクトリ・オブジェクト・リファレンスを取得することを可能にします。

以下の機能、制限事項、および要件が、このリリースに適用されます。

 

機能説明

BEA Tuxedo CORBA 環境では、クライアントがオブジェクトへのリファレンスを取得するための主な手段として、ファクトリ・デザイン・パターンの使用が促進されます。このデザイン・パターンを使用することにより、クライアント・アプリケーションには、別のオブジェクトのファクトリとして動作するオブジェクトへのリファレンスを取得するメカニズムが必要となります。BEA Tuxedo 環境では、CORBA を可視プログラミング・モデルとして選択しているため、ファクトリをロケートするためのメカニズムは、Object Management Group の CORBA サービス仕様 (1997 年 12 月) の第 6 章「Life Cycle Service」で示されているように、FactoryFinder を モデルとしています。

CORBA FactoryFinder モデルでは、アプリケーション・サーバは活性化されたファクトリを FactoryFinder に登録します。アプリケーション・サーバのファクトリが不活性になると、アプリケーション・サーバは FactoryFinder から対応する登録を削除します。クライアント・アプリケーションは、FactoryFinder に問い合せを行うことによって、ファクトリをロケートします。クライアント・アプリケーションは、1 つまたは複数のリファレンスの選択に使用される基準を指定することによって、返されたファクトリ・オブジェクトへのリファレンスを制御できます。

FactoryFinder のロケート

クライアント・アプリケーションは、適切なファクトリを探し始める前に、FactoryFinder へのリファレンスを取得する必要があります。クライアント・アプリケーションが関連付けられているドメイン内の FactoryFinder へのリファレンスを取得するには、クライアント・アプリケーションは次の 2 つのブートストラップ処理メカニズムのうち、いずれかを使用します。

注記 クライアント・アプリケーションに返される FactoryFinder へのリファレンスは、その FactoryFinder と同じマシンに登録されたファクトリ・オブジェクトへのリファレンス、別のマシンに登録されたファクトリ・オブジェクトへのリファレンス、または別のドメインに登録されたファクトリ・オブジェクトへのリファレンスである可能性があります。

ファクトリの登録

クライアント・アプリケーションがファクトリへのリファレンスを取得できるようになるには、アプリケーション・サーバが、FactoryFinder によるインプリメンテーションの提供先となる任意のファクトリ・オブジェクトへのリファレンスを登録する必要があります (図5-1 を参照)。BEA Tuxedo CORBA TP フレームワークにより、ファクトリ・オブジェクトのリファレンスの登録は、それが作成された後に TP::register_factory オペレーションを使用することにより行われます。ファクトリ・オブジェクトへのリファレンスは、そのファクトリを識別する値と共に、このオペレーションに渡されます。ファクトリ・オブジェクトのリファレンスの登録は、通常はアプリケーションの初期化手順の一部 (普通は、オペレーション Server::initialize のインプリメンテーションの一部) として行われます。

図 5-1 ファクトリ・オブジェクトの登録


 

サーバ・アプリケーションは、シャットダウン時には以前にアプリケーション・サーバに登録されたファクトリ・オブジェクトへのリファレンスを、すべて登録を削除する必要があります。これは、ファクトリ・オブジェクトへの同じリファレンスと、ファクトリの識別に使用する対応する値を、TP::unregister_factory オペレーションに渡すことによって行われます。登録が削除されると、ファクトリ・オブジェクトへのリファレンスは破棄できるようになります。FactoryFinder でのファクトリの登録を削除するプロセスは、通常は Server::release オペレーションのインプリメンテーションの一環として行われます。これらのオペレーションの詳細については、「Server インターフェイス」を参照してください。

C++ マッピング

リスト5-1 では、C++ のクラスの (静的) メソッドを示します。これらのメソッドの詳細については、「TP::register_factory()」および「TP::unregister_factory()」を参照してください。

コードリスト 5-1 ファクトリ登録のための C++ マッピングの擬似 OMG IDL

 
#include <TP.h>
 
static void TP::register_factory(
              CORBA::Object_ptr factory_or, const char* factory_id);
 
static void TP::unregister_factory (
               CORBA::Object_ptr factory_or, const char* factory_id);

TP.h ヘッダ・ファイルには、2 つのメソッド宣言が含まれています。このファイルは、これらのメソッドを使用するすべてのサーバ・アプリケーションに含める必要があります。

一般に、サーバ・アプリケーションはこのヘッダ・ファイルを、アプリケーション・サーバの初期化と解放のためのメソッドを含むアプリケーション・ファイル内に格納しています。

ファクトリのロケート

クライアントが、オブジェクトへのリファレンスを作成するファクトリを要求するためには、まずファクトリ・オブジェクトへのリファレンスを取得することが必要です。ファクトリ・オブジェクトへのリファレンスは、特定の選択基準で FactoryFinder に問い合せを行うことによって、取得します (図5-2 参照)。基準は、使用されている特定の FactoryFinder インターフェイスおよびメソッドの形式によって決まります。

図 5-2 ファクトリ・オブジェクトのロケート


 

BEA Tuxedo CORBAは、FactoryFinder 用に宣言された find_factories() メソッドに加えて、4 つのメソッドを導入することによって、CosLifeCycle::FactoryFinder インターフェイスを拡張します。したがって、Tobj の拡張により、クライアントは find_factories() メソッドまたは find_factories_by_id() メソッドのいずれかを使って、アプリケーション・ファクトリのリストを取得できます。またクライアントは、単一のアプリケーション・ファクトリを取得するために find_one_factory() メソッドまたは find_one_factory_by_id() メソッドを使用し、登録されている全ファクトリのリストを取得するために list_factories () メソッドを使用します。

注記 Tobj_Bootstrap オブジェクトを使用する場合は、CosLifeCycle::FactoryFinder インターフェイスに BEA Tuxedo CORBA の拡張を使用できますが、このオブジェクトはファクトリを見つけるために必須のものではありません。CORBA INS を使用していれば、CosLifeCycle::FactoryFinder インターフェイスにより提供される find_factories() メソッドを使用できます。

CosLifeCycle::FactoryFinder インターフェイスは、factory_key を定義します。これは、下記の CosNaming 名に準拠した、id 文字列と kind 文字列のシーケンスです。アプリケーション・ファクトリの登録時に、TP フレームワークによって、全アプリケーション・ファクトリの NameComponent における kind フィールドが、文字列 FactoryInterface に設定されます。アプリケーションは、id フィールドの値を自身で指定します。

次のリストでは、CORBA サービス・ライフサイクル・サービスのモジュールが、自身のファイル (それぞれ ns.idl および lcs.idl) 内にあると仮定して、BEA Tuxedo FactoryFinder の使用に適した両ファイルのサブセットのための OMG IDL コードのみが示されます。

CORBA サービス・ネーミング・サービス・モジュールの OMG IDL

リスト5-2 では、FactoryFinder に関連の ns.idl ファイルを部分的に示します。

コードリスト 5-2 CORBA サービス・ネーミングの OMG IDL

 
// ------  ns.idl  ------
 
module CosNaming {
       typedef string Istring;
       struct NameComponent {
              Istring id;
              Istring kind;
       };
       typedef sequence <NameComponent> Name;
 
};
 
// この情報は、「CORBAservices: Common Object Services 
// Specification」(1995 年 3 月 31 日改訂版、1997 年 11 月更新) 
// の 6 〜 10 ページから、OMG の許可を得て転載

CORBA サービス・ライフサイクル・サービス・モジュールの OMG IDL

リスト5-3 では、FactoryFinder に関連の lcs.idl ファイルを部分的に示します。

コードリスト 5-3 ライフサイクル・サービスの OMG IDL

 
// -----  lcs.idl  -----
 
#include “ns.idl”
 
module CosLifeCycle{
       typedef CosNaming::Name Key;
       typedef Object Factory;
        typedef sequence<Factory> Factories;
 
       exception NoFactory{ Key search_key; }
 
       interface FactoryFinder {
            Factories find_factories(in Key factory_key)
                  raises(NoFactory);
 
        };
 
};
 
// この情報は、「CORBAservices: Common Object Services 
// Specification」(1995 年 3 月 31 日改訂版、1997 年 11 月更新) 
// の 6 〜 10 ページから、OMG の許可を得て転載

Tobj モジュールの OMG IDL

リスト5-4 は、Tobj モジュールの OMG IDL を示します。

コードリスト 5-4 Tobj モジュールの OMG IDL

 
// -----  Tobj.idl  -----
 
module Tobj {
 
   // 定数
 
   const string FACTORY_KIND = "FactoryInterface";
 
   // 例外
 
   exception CannotProceed { };
   exception InvalidDomain {};
   exception InvalidName { };
   exception RegistrarNotAvailable { };
 
   // LifeCycle サービスへの拡張
 
   struct FactoryComponent {
        CosLifeCycle::Key factory_key;
        CosLifeCycle::Factory factory_ior;
   };
 
   typedef sequence<FactoryComponent> FactoryListing;
 
   interface FactoryFinder : CosLifeCycle::FactoryFinder {
     CosLifeCycle::Factory find_one_factory(in CosLifeCycle::Key
                                            factory_key)
                  raises (CosLifeCycle::NoFactory,
                          CannotProceed,
                          RegistrarNotAvailable);
      CosLifeCycle::Factory find_one_factory_by_id(in string
                                                   factory_id)
                   raises (CosLifeCycle::NoFactory,
                           CannotProceed,
                           RegistrarNotAvailable);
      CosLifeCycle::Factories find_factories_by_id(in string
                                                   factory_id)
                     raises (CosLifeCycle::NoFactory,
                             CannotProceed,
                             RegistrarNotAvailable);
      FactoryListing list_factories()
                       raises (CannotProceed,
                               RegistrarNotAvailable);
   };
};

別ドメイン内のファクトリのロケート

通常、FactoryFinder は自身と同じドメイン内にあるファクトリ・オブジェクトへのリファレンスを返します。しかし、FactoryFinder が存在しているドメイン以外のドメイン内のファクトリ・オブジェクトへのリファレンスを返すこともできます。これは、FactoryFinder に別ドメイン内のファクトリの情報が含まれている場合に実現可能です (図5-3 参照)。FactoryFinderは、これらのほかのファクトリ・オブジェクトの場所を説明するコンフィギュレーション情報から、これらドメイン間のファクトリ・オブジェクトについて調べます。

FactoryFinder は、ファクトリ・オブジェクトをロケートする要求を受信すると、まず指定された基準に合致するファクトリ・オブジェクトへのリファレンスが存在するかどうかを判断する必要があります。基準に合致するファクトリ・オブジェクトの登録情報があれば、FactoryFinder はそれが現在のドメインから見てローカルな場所にあるのか、それとも別ドメインからのインポートを必要とするのかを判断する必要があります。ファクトリ・オブジェクトがローカル・ドメインからのものであれば、FactoryFinder はファクトリ・オブジェクトへのリファレンスをクライアントに返します。

図e 5-3 ドメイン間の FactoryFinder の対話


 

その一方で、もしその情報が、実際のファクトリ・オブジェクトが別ドメインからのものであることを示していれば、FactoryFinder は要求を適切なドメインにあるドメイン間の FactoryFinder に委譲します。その結果、ファクトリ・オブジェクトと同じドメイン内の FactoryFinder のみが、ファクトリ・オブジェクトへの実際のリファレンスを含むこととなります。ドメイン間の FactoryFinder は、ファクトリ・オブジェクトのリファレンスをローカルの FactoryFinder に返す役割を果たします。そこからその要求は、クライアントに返されます。

BEA Tuxedo CORBA の拡張を使用する理由

BEA Tuxedo ソフトウェアは、Object Management Group の CORBAサービス仕様 (1997 年 12 月) の第 6 章「Life Cycle Service」で定義されているインターフェイスを、以下の理由により拡張しています。

したがって、BEA Tuxedo は FactoryFinder を使いやすくするために、CORBA サービスの仕様で定義されているインターフェイスを拡張します。拡張は、CORBA サービスの仕様で指定されたインターフェイスから派生する、FactoryFinder の高度化したインターフェイスとなります。

アプリケーション・ファクトリ・キーの作成

FactoryFinder インターフェイスで提供される 5 つのメソッドのうち 2 つが、CosNaming::Name に対応する CosLifeCycle::Keys を受け付けます。クライアントは、これらのキーを構築できなければなりません。

CosNaming の仕様では、CosLifeCycle::Keys の作成と操作に使用可能な名前ライブラリ・インターフェイスを構成する、2 つのインターフェイスが説明されています。これらのインターフェイスの擬似 OMG IDL 文については、次の節で説明します。

名前ライブラリ・インターフェイスの擬似 OMG IDL

注記 この情報は、「CORBAservices: Common Object Services Specification」(1995 年 3 月 31 日改訂版、1997 年 11 月更新) の 3-14 〜 3-18 ページから、OMG の許可を得て転載しています。

既存のクライアント・アプリケーションに影響を与えることなく名前の表現を生成するには、名前の表現をクライアント・アプリケーションから認識できないようにしたほうがよいでしょう。名前自体がオブジェクトとなることが理想ですが、名前は作成、操作、送信が効率的に行える、ライトウェイトのエンティティでなければなりません。したがって、名前は名前ライブラリからプログラムに提示されます。

名前ライブラリは、名前を擬似オブジェクトとしてインプリメントします。クライアント・アプリケーションは、通常のオブジェクトを呼び出す場合と同じやり方で、擬似オブジェクトに対し呼び出しを行います。ライブラリ名は、擬似 IDL で記述されます。これにより、適切な言語バインディングが示唆されます。C++ クライアント・アプリケーションは、擬似 IDL (PIDL) でも、IDL の場合と同じクライアント言語バインディングを使用します。

擬似オブジェクト・リファレンスは、OMG IDL インターフェイス間で渡すことはできません。「CORBAservices: Common Object Services Specification」の第 3 章の「The CosNaming Module」で説明されるように、CORBA サービス・ネーミング・サービスは、NamingContext OMG IDL インターフェイスをサポートしています。名前ライブラリは、NamingContext インターフェイスを通じてライブラリ名をネーム・サービスに渡せる値に変換するオペレーションをサポートしています。

注記 CORBA サービス・ネーミング・サービスを使用するのに、名前ライブラリの使用は必須ではありません。

名前ライブラリは、リスト5-5 に示すように LNameComponent インターフェイスおよび LName インターフェイスという 2 つの擬似 IDL インターフェイスで構成されています。

コードリスト 5-5 擬似 IDL による名前ライブラリ・インターフェイス

 
interface LNameComponent { //  PIDL
    const short MAX_LNAME_STRLEN = 128;
 
    exception NotSet{ };
    exception OverFlow{ };
 
    string get_id
           raises (NotSet);
    void set_id(in string i)
           raises (OverFlow); 
    string get_kind()
           raises(NotSet);
    void set_kind(in string k)
           raises (OverFlow);
    void destroy();
};
 
interface LName {		// PIDL
       exception NoComponent{ };
       exception OverFlow{ };
       exception InvalidName{ };
       LName insert_component(in unsigned long i, 
                     in LNameComponent n)
              raises (NoComponent, OverFlow);
       LNameComponent get_component(in unsigned long i)
              raises (NoComponent);
       LNameComponent delete_component(in unsigned long i)
              raises (NoComponent);
       unsigned long num_components();
       boolean equal(in LName ln);
       boolean less_than(in LName ln);
       Name to_idl_form()
              raises (InvalidName);
       void from_idl_form(in Name n);
       void destroy();
};
 
LName create_lname();			// C/C++
LNameComponent create_lname_component();	// C/C++

ライブラリ名コンポーネントの作成

ライブラリ名コンポーネントの擬似オブジェクトを作成するには、次の C/C++ 関数を使用します。

LNameComponent create_lname_component(); // C/C++

返された擬似オブジェクトは、その後 リスト5-5 に示すオペレーションを使用して、操作できます。

ライブラリ名の作成

ライブラリ名の擬似オブジェクトを作成するには、次の C/C++ 関数を使用します。

LName create_lname(); // C/C++

返された擬似オブジェクト・リファレンスは、その後 リスト5-5 に示すオペレーションを使用して、操作できます。

LNameComponent インターフェイス

名前コンポーネントは、identifier および kind という 2 つの属性で構成されています。LNameComponent インターフェイスは、次のように、これらの属性と関連付けられたオペレーションを定義します。

 
string get_id()
raises(NotSet);
void set_id(in string k);
string get_kind()
raises(NotSet);
void set_kind(in string k);

get_id

get_id オペレーションは、identifier 属性の値を返します。属性が設定されていなければ、NotSet 例外が発生します。

set_id

set_id オペレーションは、identifier 属性を文字列引数に設定します。

get_kind

get_kind オペレーションは、kind 属性の値を返します。属性が設定されていなければ、NotSet 例外が発生します。

set_kind

set_kind オペレーションは、kind 属性を文字列引数に設定します。

LName インターフェイス

この節では、以下のオペレーションについて説明します。

ライブラリ名コンポーネント擬似オブジェクトの破棄

destroy オペレーションは、ライブラリ名コンポーネント擬似オブジェクトを破棄します。

void destroy();

名前コンポーネントの挿入

名前には、1 つまたは複数のコンポーネントがあります。各コンポーネントは、最後のもの以外は、サブコンテキストの名前を識別するために使用されます。最後のコンポーネントは、バウンド・オブジェクトを示します。insert_component オペレーションは、位置 i の後にコンポーネントを挿入します。

LName insert_component(in unsigned long i, in LNameComponent lnc)
raises(NoComponent, OverFlow);

コンポーネント i-1 が未定義で、コンポーネント i が 1 より大きい場合、insert_component オペレーションは、NoComponent 例外を生成します。

ライブラリが、挿入されたコンポーネントに資源を割り当てられない場合は、OverFlow 例外が発生します。

i 番目の名前コンポーネントの取得

get_component オペレーションは、i 番目のコンポーネントを返します。最初のコンポーネントの番号を「1」とします。

LNameComponent get_component(in unsigned long i)
raises(NoComponent);

コンポーネントが存在しない場合は、NoComponent 例外が発生します。

名前コンポーネントの削除

delete_component オペレーションは、i 番目のコンポーネントを削除して返します。

LNameComponent delete_component(in unsigned long i)
raises(NoComponent);

コンポーネントが存在しない場合は、NoComponent 例外が発生します。

delete_component オペレーションの実行後は、複合名のコンポーネントが 1 つ減り、それまで i+1...n と認識されてきたコンポーネントが、i...n-1 と認識されるようになります。

名前コンポーネントの数

num_componentsオペレーションは、ライブラリ名に含まれるコンポーネントの数を返します。

unsigned long num_components();

等価性のテスト

equal オペレーションは、ライブラリ名 ln との等価性をテストします。

boolean equal(in LName ln);

順序のテスト

less_than オペレーションは、ライブラリ名 ln に対しての、ライブラリ名の順序をテストします。

boolean less_than(in LName ln);

このオペレーションは、ライブラリ名が、引数として渡されたライブラリ名 ln よりも小さい値の場合に、TRUE を返します。ライブラリのインプリメンテーションは、名前の順序付けを定義します。

OMG IDL 形式の生成

擬似オブジェクトは、OMG IDL インターフェイス間で渡すことはできません。ライブラリ名は、擬似オブジェクトです。したがって、CORBA サービス・ネーミング・サービスの OMG IDL インターフェイスを越えて渡すことはできません。NamingContext インターフェイスのいくつかのオペレーションには、OMG IDL 定義の構造体 Name の引数があります。ライブラリ名に対する次の PIDL オペレーションは、OMG IDL 要求にわたって渡すことが可能な構造体を生成します。

Name to_idl_form()
raises(InvalidName);

名前の長さが 0 (ゼロ) の場合、InvalidName 例外が返されます。

IDL 形式の変換

擬似オブジェクトは、OMG IDL インターフェイス間で渡すことはできません。ライブラリ名は、擬似オブジェクトです。したがって、CORBA サービス・ネーミング・サービスの OMG IDL インターフェイスを越えて渡すことはできません。NamingContext インターフェイスは、Name 型の IDL struct を返すオペレーションを定義します。ライブラリ名に対する次の PIDL オペレーションは、返された OMG IDL 構造体 Name からのライブラリ名のコンポーネントおよび kind 属性を設定します。

void from_idl_form(in Name n);

ライブラリ名擬似オブジェクトの破棄

destroy オペレーションは、ライブラリ名擬似オブジェクトを破棄します。

void destroy();

C++ マッピング

名前ライブラリの擬似 OMG IDL インターフェイスは、リスト5-6 に示す C++ クラスにマッピングします。このリストは、NamesLib.h ヘッダ・ファイルにあります。

スケーラビリティをサポートするために、CORBA に対する 2 つの BEA Tuxedo 拡張が含まれています。具体的には、入力文字列の長さが MAX_LNAME_STRLEN を超えると、LNameComponent::set_id() メソッドおよび LNameComponent::set_kind() メソッドが、OverFlow 例外を生成します。この長さは、BEA Tuxedo オブジェクト ID (OID) およびインターフェイス名の最大長に一致します。 ライブラリ名クラスの詳細については、「名前ライブラリ・インターフェイスの擬似 OMG IDL」を参照してください。

コードリスト 5-6 ライブラリ名クラス

 
const short MAX_LNAME_STRLEN = 128;
 
class LNameComponent {
public:
      class NotSet{ };
      class OverFlow{ };
      static LNameComponent* create_lname_component();
      void   destroy();
      const char*   get_id() const throw (NotSet);
      void          set_id(const char* i) throw (OverFlow);
      const char*   get_kind() const throw (NotSet);
      void          set_kind(const char* k) throw (OverFlow);
};
 
class LName {
public:
       class NoComponent{ };
       class OverFlow{ };
       class InvalidName{ };
       static LName* create_lname();
       void destroy();
       LName* insert_component(const unsigned long i,
                     LNameComponent* n)
              throw (NoComponent, OverFlow);
       const LNameComponent* get_component(
                     const unsigned long i) const
              throw (NoComponent);
       const LNameComponent* delete_component(
                     const unsigned long i)
              throw (NoComponent);
       unsigned long num_components() const;
       CORBA::Boolean equal(const LName* ln) const;
       CORBA::Boolean less_than(
               const LName* ln) const; // インプリメントされていない
       CosNaming::Name* to_idl_form()
              throw (InvalidName);
       void from_idl_form(const CosNaming::Name& n);
};

Java マッピング

名前ライブラリ擬似 OMG IDL インターフェイスは、リスト5-7 で示す com.beasys.Tobj パッケージに含まれている Java クラスにマッピングします。例外はすべて、同じパッケージ内に包含されています。

ライブラリ名クラスの詳細については、「CORBAservices: Common Object Services Specification」の第 3 章を参照してください。

コードリスト 5-7 LNameComponent の Java マッピング

 
public class LNameComponent {
    public static LNameComponent create_lname_component();
    public static final short MAX_LNAME_STRING = 128;
    public void	 destroy();
    public String get_id() throws NotSet;
    public void   set_id(String i) throws OverFlow;
    public String get_kind() throws NotSet;
    public void   set_kind(String k) throws OverFlow;
};
 
public class LName {
 
   public static LName create_lname();
   public void destroy();
   public LName insert_component(long i, LNameComponent n)
     throws NoComponent, OverFlow;
   public LNameComponent get_component(long i)
     throws NoComponent;
   public LNameComponent delete_component(long i)
     throws NoComponent;
   public long num_components();
   public boolean equal(LName ln);
   public boolean less_than(LName ln);	// インプリメントされていない
   public org.omg.CosNaming.NameComponent[] to_idl_form()
     throws InvalidName;
   public void from_idl_form(org.omg.CosNaming.NameComponent[] nr);
};

 

C++ メンバ関数と Java メソッド

この節では、FactoryFinder の C++ メンバ関数と Java メソッドについて説明します。

注記 LName の less_than メンバ関数を除き、FactoryFinder メンバ関数はすべて、C++ でも Java でもインプリメントされます。

ここでは、以下のメソッドについて説明します。

注記 CosLifeCycle::FactoryFinder::find_factories メソッドは、標準的な CORBA CosLifeCycle メソッドです。4 つの Tobj メソッドは、CosLifeCycle インターフェイスに対する拡張であり、したがって、CosLifeCycle インターフェイスの属性を継承しています。

 

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