bea ホーム | 製品 | dev2dev | support | askBEA
BEA Logo Tuxedo
 ドキュメントのダウンロード   サイトマップ   用語集 
検索
0
e-docs > Tuxedo > Tuxedo CORBA クライアント・アプリケーションの開発方法 > CORBA クライアント・アプリケーションの開発概念

Tuxedo CORBA クライアント・アプリケーションの開発方法

 Previous Next Contents Index View as PDF  

CORBA クライアント・アプリケーションの開発概念

この章では、BEA Tuxedo 製品の CORBA 環境でサポートされるクライアント・アプリケーションのタイプと、CORBA クライアント・アプリケーションの開発前に理解しておく必要がある概念について説明します。

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

 

クライアント・アプリケーションの概要

BEA Tuxedo ソフトウェアは、以下のタイプのクライアント・アプリケーションをサポートしています。

 

OMG IDL

どのような分散アプリケーションでも、クライアント/サーバ・アプリケーションは通信を行うための基本的な情報を必要とします。たとえば、CORBA クライアント・アプリケーションは、要求できるオペレーションとその引数を知る必要があります。

Object Management Group (OMG) インターフェイス定義言語 (IDL) を使用すると、クライアント・アプリケーションへの CORBA インターフェイスを定義できます。OMG IDL で記述したインターフェイス定義を使用すると、完全に CORBA インターフェイスを定義し、各オペレーションの引数を指定できます。OMG IDL は、純粋な宣言型言語です。つまり、インプリメンテーションの詳細は含まれていません。OMG IDL で指定されるオペレーションは、CORBA バインディングを提供する任意の言語で記述し、呼び出すことができます。サポートされる言語には、C++ と Java が含まれます。

一般に、アプリケーション設計者が使用可能な CORBA インターフェイスとオペレーション用の OMG IDL ファイルをプログラマに提供し、プログラマがクライアント・アプリケーションを開発します。

OMG IDL と C++ のマッピング

BEA Tuxedo ソフトウェアは、「The Common Object Request Broker:Architecture and Specification, Version 2.3」に準拠しています。OMG IDL と C++ のマッピングの詳細については、「The Common Object Request Broker:Architecture and Specification, Version 2.3」を参照してください。

OMG IDL と Java のマッピング

BEA Tuxedo ソフトウェアは、「The Common Object Request Broker:Architecture and Specification, Version 2.2」に準拠しています。OMG IDL と Java のマッピングの詳細については、「The Common Object Request Broker:Architecture and Specification, Version 2.2」を参照してください。

OMG IDL と COM のマッピング

BEA Tuxedo ソフトウェアは、「The Common Object Request Broker:Architecture and Specification, Version 2.3」に定義されている OMG IDL と COM のマッピングに準拠しています。OMG IDL と COM のマッピングの詳細については、「The Common Object Request Broker:Architecture and Specification, Version 2.3」を参照してください。

 

静的起動と動的起動

BEA Tuxedo 製品の CORBA ORB は、静的と動的という 2 種類のクライアント/サーバ起動をサポートしています。どちらのケースでも、CORBA クライアント・アプリケーションは CORBA オブジェクトのリファレンスへのアクセスを取得し、要求を満たすオペレーションを呼び出すことによってその要求を実行します。CORBA サーバ・アプリケーションは、静的起動と動的起動の違いを区別できません。

静的起動を使用する場合、CORBA クライアント・アプリケーションはクライアント・スタブ上でオペレーションを直接呼び出します。静的起動は、最も簡単で、最も一般的な呼び出し方式です。スタブは、IDL コンパイラによって生成されます。静的起動は、呼び出す必要があるオペレーションの詳細をコンパイル時に認識し、その呼び出しの同期的性質内で処理できるアプリケーションに適しています。図1-1 に、静的起動のしくみを示します。

図 1-1 静的起動


 

動的起動は、より複雑です。ただし、動的起動を使用すると、CORBA クライアント・アプリケーションはコンパイル時に CORBA オブジェクトのインターフェイスを認識しなくても CORBA オブジェクトのオペレーションを呼び出すことができます。図1-2 に、動的起動のしくみを示します。

図 1-2 動的起動


 

動的起動を使用すると、CORBA クライアント・アプリケーションは、インターフェイス・リポジトリに格納されている CORBA オブジェクト・インターフェイス用のオペレーション要求を動的に構築できます。CORBA サーバ・アプリケーションは、特別な設計を必要とせずに動的起動要求を受け付けて処理できます。通常、動的起動は CORBA クライアント・アプリケーションで遅延同期通信が必要なときに使用されるか、または対話の性質が未定義の場合に動的クライアント・アプリケーションによって使用されます。動的起動の詳細については、「動的起動インターフェイスの使い方」を参照してください。

 

クライアント・スタブ

クライアント・スタブは、CORBA オブジェクトが実行できるオペレーションへのプログラミング・インターフェイスを提供します。クライアント・スタブは、CORBA オブジェクトのローカル・プロキシです。クライアント・スタブは、CORBA オブジェクトのオブジェクト・リファレンスの同期呼び出しを実行するためのメカニズムを提供します。CORBA クライアント・アプリケーションは、特別なコードを必要とせずに CORBA オブジェクトまたはその引数を処理できます。CORBA クライアント・アプリケーションは、スタブをローカル・オブジェクトとして取り扱います。

CORBA クライアント・アプリケーションは、使用するインターフェイスごとにスタブを持つ必要があります。idl コマンド (または Java ORB 製品の同等コマンド) を使用すると、CORBA インターフェイスの OMG IDL 定義からクライアント・スタブを生成できます。このコマンドにより、C++ や Java などのプログラミング言語からクライアント・スタブを使用する場合に必要なすべてのものが定義されたスタブ・ファイルとヘッダ・ファイルが生成されます。このため、CORBA クライアント・アプリケーション内からメソッドを呼び出すだけで、CORBA オブジェクトのオペレーションを要求できます。

 

インターフェイス・リポジトリ

インターフェイス・リポジトリには、CORBA オブジェクトのインターフェイスとオペレーションの定義が含まれています。インターフェイス・リポジトリに格納される情報は OMG IDL ファイルに定義される情報と同じですが、この情報には実行時にプログラマティックにアクセス可能です。CORBA クライアント・アプリケーションがインターフェイス・リポジトリを使用する理由は以下のとおりです。

静的起動を使用する CORBA クライアント・アプリケーションは、実行時にインターフェイス・リポジトリにアクセスしません。CORBA オブジェクトのインターフェイスに関する情報は、クライアント・スタブに含まれています。

インターフェイス・リポジトリを管理するには、以下の BEA Tuxedo 開発コマンドを使用します。

インターフェイス・リポジトリの開発コマンドについては、『BEA Tuxedo コマンド・リファレンス』を参照してください。

 

ドメイン

ドメインとは、オブジェクトとサービスを管理エンティティとして 1 つのグループにまとめる手段のことです。BEA Tuxedo ドメインは、少なくとも 1 つの IIOP リスナ/ハンドラを持ち、名前で識別されます。異なる Bootstrap オブジェクトを使用することで、1 つの CORBA クライアント・アプリケーションが複数の BEA Tuxedo ドメインに接続できます。BEA Tuxedo ドメインごとに、CORBA クライアント・アプリケーションはその BEA Tuxedo ドメイン内で提供されるサービス (トランザクション、セキュリティ、ネーミング、イベントなど) に対応するオブジェクトを取得できます。Bootstrap オブジェクトと BEA Tuxedo ドメインで使用可能な CORBA サービスについては、「環境オブジェクト」を参照してください。

注記 サービスごとに 1 つの環境オブジェクトだけが同時に存在でき、環境オブジェクトは同じ Bootstrap オブジェクトに関連付けられる必要があります。

図1-3 に、BEA Tuxedo ドメインの機能を示します。

図 1-3 BEA Tuxedo ドメインの機能


 

 

環境オブジェクト

BEA Tuxedo ソフトウェアには、CORBA クライアント・アプリケーションと BEA Tuxedo ドメイン内の CORBA サーバ・アプリケーション間の通信を設定し、そのドメインで提供される CORBA サービスへのアクセスを提供する環境オブジェクト・セットが用意されています。BEA Tuxedo ソフトウェアには、以下の環境オブジェクトが用意されています。

BEA Tuxedo ソフトウェアには、以下のプログラミング環境用の環境オブジェクトが用意されています。

Bootstrap オブジェクト

CORBA クライアント・アプリケーションは、IIOP リスナ/ハンドラのアドレスを定義する Bootstrap オブジェクトを作成します。IIOP リスナ/ハンドラは、BEA Tuxedo ドメインおよびそのドメインによって提供される CORBA サービスへのアクセス・ポイントです。IIOP リスナ/ハンドラのリストは、パラメータとして提供されるか、TOBJADDR 環境変数または Java プロパティを介して提供されます。1 つの IIOP リスナ/ハンドラは、次のように指定されます。

 
//host:port

例: //myserver:4000

Bootstrap オブジェクトがインスタンス化されると、resolve_initial_references メソッドが呼び出され、文字列 ID が受け渡されて使用可能なオブジェクトへのリファレンスが取得されます。文字列 ID の有効値は、FactoryFinder、Interface Repository、SecurityCurrent、TransactionCurrent、NotificationService、TObj_SimpleEventsService、および NameService です。

図1-4 に、BEA Tuxedo ドメインでの Bootstrap オブジェクトの機能を示します。

図 1-4 Bootstrap オブジェクトの機能


 

サードパーティ・クライアント ORB は、CORBA インターオペラブル・ネーミング・サービス (INS) メカニズムを使用して BEA Tuxedo ドメインとそのサービスにアクセスできます。インターオペラブル・ネーミング・サービスを使用すると、サードパーティ・クライアント ORB は、自身の resolve_initial_references() 関数を使用して BEA Tuxedo ドメインによって提供される CORBA サービスにアクセスし、標準 OMG IDL から生成されたスタブを使用してドメインから返されたインスタンスを処理できます。インターオペラブル・ネーミング・サービスの使い方については、『BEA Tuxedo CORBA プログラミング・リファレンス』を参照してください。

ファクトリと FactoryFinder オブジェクト

CORBA クライアント・アプリケーションは、CORBA オブジェクトへのリファレンスをファクトリから取得します。ファクトリは、別の CORBA オブジェクトへのリファレンスを返し、自身を FactoryFinder オブジェクトに登録する任意の CORBA オブジェクトです。

CORBA クライアント・アプリケーションが CORBA オブジェクトを使用するには、その CORBA オブジェクトへのオブジェクト・リファレンスを作成するファクトリを検索する必要があります。BEA Tuxedo ソフトウェアには、そのために FactoryFinder オブジェクトが用意されています。CORBA クライアント・アプリケーションで使用可能なファクトリは、起動時に CORBA サーバ・アプリケーションによって FactoryFinder オブジェクトに登録されたファクトリです。

CORBA クライアント・アプリケーションは、次の一連のステップを使用して CORBA オブジェクトへのリファレンスを取得します。

  1. Bootstrap オブジェクトが作成されると、resolve_initial_references メソッドが呼び出され、FactoryFinder オブジェクトへのリファレンスが取得されます。

  2. CORBA クライアント・アプリケーションは、FactoryFinder オブジェクトに目的のファクトリへのオブジェクト・リファレンスを問い合わせます。

  3. 次に、CORBA クライアント・アプリケーションはそのファクトリを呼び出して CORBA オブジェクトへのオブジェクト・リファレンスを取得します。

図1-5 に、CORBA クライアント・アプリケーションと FactoryFinder オブジェクトの対話を示します。

図 1-5 クライアント・アプリケーションによる FactoryFinder オブジェクトの使用


 

FactoryFinder オブジェクトの命名規則と BEA Tuxedo 拡張

CORBA クライアント・アプリケーションで使用可能なファクトリは、起動時に CORBA サーバ・アプリケーションによって FactoryFinder オブジェクトに登録されたファクトリです。ファクトリは、以下のフィールドで構成されるキーを使用して登録されます。

BEA Tuxedo ソフトウェアによって使用される FactoryFinder オブジェクトは、CORBA サービス・ライフサイクル・サービスで定義されます。BEA Tuxedo ソフトウェアは、COS::LifeCycle::FactoryFinder の拡張を実装します。この拡張により、クライアント・アプリケーションは FactoryFinder オブジェクトを使用してより簡単にファクトリを検索できるようになります。

CORBA サービス・ライフサイクル・サービスは、CORBA サービス・ネーミング・サービスに定義された名前を使用して、COS::LifeCycle::FactoryFinder インターフェイスを介してファクトリを検索するよう指定しています。これらの名前は一連の NameComponent 構造で構成され、この構造は ID フィールドと kind フィールドで構成されています。

CORBA 名を使用したファクトリの検索は、クライアント・アプリケーションにとっては面倒です。数多くの呼び出しを行って適切な名前構造を構築し、CORBA ネーム・サービス名を構築して COS::LifeCycle::FactoryFinder インターフェイスの find_factories メソッドに渡す必要があるからです。また、メソッドは複数のファクトリを返す場合があるため、クライアント・アプリケーションは適切なファクトリの選択と不要なオブジェクト・リファレンスの破棄を行う必要があります。

FactoryFinder オブジェクトは、単純なメソッド呼び出しによってインターフェイスを拡張することで、CORBA クライアント・アプリケーションがファクトリをより簡単に検索できるよう設計されています。

FactoryFinder 拡張の目的は、CORBA クライアント・アプリケーションに対して以下の簡素化を提供することです。

最も単純なアプリケーション設計は、CORBA クライアント・アプリケーションで Tobj::FactoryFinder::find_one_factory_by_id メソッドを使用することで達成できます。このメソッドは、入力としてファクトリ ID 用の単純な文字列を受け付け、1 つのファクトリを CORBA クライアント・アプリケーションに返します。CORBA クライアント・アプリケーションは、名前コンポーネントを操作し、多くのファクトリから選択する必要がなくなります。

Tobj::FactoryFinder::find_one_factory_by_id メソッドを使用するには、アプリケーション設計者は CORBA クライアント・アプリケーションが特定の CORBA オブジェクト・インターフェイス用のファクトリを簡単に検索するために使用できるファクトリの命名規則を定義する必要があります。この命名規則では、特定のタイプの CORBA オブジェクト・インターフェイスのオブジェクト・リファレンスを提供するファクトリの複数のニーモニック型が定義されるのが理想的です。ファクトリは、これらの規則を使用して登録されます。たとえば、Student オブジェクトのオブジェクト・リファレンスを返すファクトリであれば、StudentFactory と呼ばれます。FactoryFinder オブジェクトへのファクトリの登録については、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』を参照してください。

OMG IDL ファイルでファクトリの実際のインターフェイス ID を使用するか、OMG IDL ファイルでファクトリ ID を定数として指定することをお勧めします。このテクニックを使用することにより、CORBA クライアント・アプリケーションと CORBA サーバ・アプリケーション間の命名の一貫性が保証されます。

InterfaceRepository オブジェクト

InterfaceRepository オブジェクトは、BEA Tuxedo ドメインのインターフェイス・リポジトリに関する情報を返します。InterfaceRepository オブジェクトは、インターフェイス・リポジトリの CORBA 定義に基づいています。このオブジェクトは、「Common Request Broker Architecture and Specification Version 2.2」で定義されている適切な CORBA インターフェイス・セットを提供します。

動的起動インターフェイス (DII) を使用する CORBA クライアント・アプリケーションは、インターフェイス・リポジトリにプログラマティックにアクセスする必要があります。インターフェイス・リポジトリにアクセスするための正確な手順は、CORBA クライアント・アプリケーションが特定の CORBA インターフェイスに関する情報を検索するのか、またはあるインターフェイスを見つけるためにリポジトリを参照するのかによって異なります。どちらの場合でも、CORBA クライアント・アプリケーションはインターフェイス・リポジトリへの読み込みだけを行うことができ、書き込みは行うことができません。

DII を使用する CORBA クライアント・アプリケーションが BEA Tuxedo ドメインのインターフェイス・リポジトリを参照するには、CORBA クライアント・アプリケーションがあらかじめそのドメインの InterfaceRepository オブジェクトのオブジェクト・リファレンスを取得しておく必要があります。DII を使用する CORBA クライアント・アプリケーションは、Bootstrap オブジェクトを使用してオブジェクト・リファレンスを取得します。

また、ActiveX クライアント・アプリケーションもインターフェイス・リポジトリを使用します。CORBA クライアント・アプリケーションと同様、ActiveX クライアント・アプリケーションも Bootstrap オブジェクトを使用して InterfaceRepository オブジェクトへのリファレンスを取得します。

DII を使用する CORBA クライアント・アプリケーションで InterfaceRepository オブジェクトを使用する方法については、「動的起動インターフェイスの使い方」を参照してください。InterfaceRepository オブジェクトについては、『BEA Tuxedo CORBA プログラミング・リファレンス』を参照してください。

SecurityCurrent オブジェクト

CORBA C++、CORBA Java、および ActiveX クライアント・アプリケーションは、セキュリティを使用して BEA Tuxedo ドメインの認証を受けます。認証とは、クライアント・アプリケーションの ID を検証するプロセスです。正確なログオン情報を入力することによって、クライアント・アプリケーションは BEA Tuxedo ドメインの認証を受けます。BEA Tuxedo ソフトウェアは、CORBA サービス・セキュリティ・サービスで定義された認証を使用し、使い勝手を良くするための拡張を提供します。

CORBA クライアント・アプリケーションは、SecurityCurrent オブジェクトを使用して BEA Tuxedo ドメインにログオンし、セキュリティ・クリデンシャルをドメインに渡します。SecurityCurrent オブジェクトは、CORBA サービス・セキュリティ・サービスの BEA Tuxedo の実装です。BEA Tuxedo 製品の CORBA セキュリティ・モデルは、認証をベースとしています。

SecurityCurrent オブジェクトを使用することによって、ドメインの適切なセキュリティ・レベルを指定します。利用できる認証レベルは以下のとおりです。

注記 CORBA クライアント・アプリケーションが認証を受けず、セキュリティ・レベルが TOBJ_NOAUTH の場合、BEA Tuxedo ドメインの IIOP リスナ/ハンドラはその IIOP リスナ/ハンドラに送信されるユーザ名とクライアント・アプリケーション名に CORBA クライアント・アプリケーションを登録します。

BEA Tuxedo ソフトウェアでは、SecurityCurrent オブジェクトのプロパティとして PrincipalAuthenticator と Credentials だけがサポートされます。

クライアント・アプリケーションでの SecurityCurrent オブジェクトの使い方については、『BEA Tuxedo CORBA アプリケーションのセキュリティ機能』を参照してください。SecurityLevel1::Current インターフェイスと SecurityLevel2::Current インターフェイスについては、『BEA Tuxedo CORBA プログラミング・リファレンス』を参照してください。

TransactionCurrent オブジェクト

TransactionCurrent オブジェクトは、CORBA のオブジェクト・トランザクション・サービスの BEA Tuxedo の実装です。TransactionCurrent オブジェクトは、CORBA クライアント・アプリケーションと CORBA サーバ・アプリケーション間の現行セッションのトランザクション・コンテキストを維持します。TransactionCurrent オブジェクトを使用すると、CORBA クライアント・アプリケーションは、トランザクションの開始と終了や、トランザクションのステータスの取得などのトランザクション・オペレーションを実行できます。

トランザクションは、インターフェイス単位で使用されます。アプリケーション設計者は、設計時に CORBA アプリケーション内のどのインターフェイスでトランザクションを処理するかを決定します。次に、各インターフェイスのトランザクション方針をインプリメンテーション・コンフィギュレーション・ファイル (ICF) に定義します。トランザクション方針は以下のとおりです。

CORBA クライアント・アプリケーションでの TransactionCurrent オブジェクトの使い方については、『BEA Tuxedo CORBA トランザクション』を参照してください。TransactionCurrent オブジェクトについては、『BEA Tuxedo CORBA プログラミング・リファレンス』を参照してください。

NotificationService オブジェクトと Tobj_SimpleEventsService オブジェクト

NotificationService オブジェクトと Tobj_SimpleEventsService オブジェクトは、CORBA イベント・サービスへのアクセスを提供します。BEA Tuxedo 製品の CORBA 環境のイベント・サービスは、ATMI 環境の EventBroker のイベント・サービスとほぼ同じ機能を提供します。ただし、CORBA イベント・サービスは、プログラミング・モデルと、CORBA プログラマにとって自然なインターフェイスを提供します。

CORBA イベント・サービスは、イベント・ポスト・メッセージを受信し、それらをフィルタして、サブスクライバに配布します。ポスト元は、関心のあるイベントがいつ発生したかを検出し、それをイベント・サービスに報告 (ポスト) する CORBA アプリケーションです。サブスクライバは、関心のあるイベントがポストされたときに実行される通知アクションを要求する CORBA アプリケーションです。

CORBA イベント・サービスは、以下の 2 種類のインターフェイス・セットを提供します。

どちらのインターフェイス・セットも、CORBA ノーティフィケーション・サービス仕様で定義される標準の構造化されたイベントを渡します。この 2 つのインターフェイス・セットは、相互に互換性があります。このため、NotificationService インターフェイスを使用してポストされたイベントを Tobj_SimpleEventsService インターフェイスでサブスクライブでき、その逆も可能です。

NotificationServer オブジェクトと Tobj_SimpleEventsService オブジェクトの使い方については、『BEA Tuxedo CORBA ノーティフィケーション・サービス』を参照してください。

NameService オブジェクト

NameService オブジェクトは、CORBA ネーム・サービスへのアクセスを提供します。CORBA ネーム・サービスを使用すると、CORBA サーバ・アプリケーションは論理名を使用してオブジェクト・リファレンスを宣言できます。CORBA クライアント・アプリケーションは、CORBA ネーム・サービスに名前のルックアップを依頼することによってオブジェクトをロケートできます。

CORBA ネーム・サービスは、以下の機能を提供します。

CORBA クライアント・アプリケーションでの NameService オブジェクトの使い方については、『BEA Tuxedo CORBA ネーム・サービス』を参照してください。

 

ActiveX クライアント・アプリケーションの概念

以下の節では、ActiveX クライアント・アプリケーションに固有の概念について説明します。

ActiveX とは

ActiveX は、ネットワーク環境下のソフトウェア・コンポーネントどうしがそれぞれの開発言語に関係なく対話できるようにするための Microsoft の技術です。ActiveX は、Component Object Model (COM) をベースに構築されており、Object Linking and Embedding (OLE) と統合されています。OLE は、ドキュメントの埋め込み用のアーキテクチャを提供します。オートメーションは COM の一部です。オートメーションを使用すると、Visual Basic、Delphi、PowerBuilder などのアプリケーションはオートメーション・オブジェクト、ActiveX コントロール、および ActiveX ドキュメントを処理できます。

BEA ActiveX Client は、BEA Tuxedo と COM オブジェクト・システム間の相互運用性を提供します。ActiveX Client は、BEA Tuxedo ドメインの CORBA オブジェクトのインターフェイスをオートメーション・オブジェクトのメソッドに変換します。

ビューとバインディング

ActiveX クライアント・アプリケーションは、CORBA インターフェイスのビューを使用します。ビューは、BEA Tuxedo ドメインの CORBA インターフェイスをオートメーション・オブジェクトとしてローカルに表します。CORBA オブジェクトの ActiveX ビュー (ActiveX ビュー) を使用するには、ActiveX のバインディングを作成する必要があります。バインディングは、CORBA オブジェクトと ActiveX のインターフェイスを定義します。CORBA オブジェクトのインターフェイスは、インターフェイス・リポジトリにロードされます。次に、BEA Application Builder を使用して、インターフェイスのオートメーション・バインディングを作成します。

開発ツールの Application Builder は、ActiveX クライアント・アプリケーションの対話先となる BEA Tuxedo ドメイン内の CORBA オブジェクトを選択するためにクライアント開発ツール (Visual Basic など) と一緒に使用します。Application Builder とその機能については、Application Builder のグラフィカル・ユーザ・インターフェイス (GUI) に統合されているオンライン・ヘルプを参照してください。

ActiveX クライアント・アプリケーションと生成されたバインディングの組み合わせにより、オブジェクトの ActiveX ビューが作成されます。

ActiveX クライアント・アプリケーションの作成方法と使い方の詳細については、「ActiveX クライアント・アプリケーションの作成」を参照してください。

図1-6 に、ActiveX Client の機能を示します。

図 1-6 ActiveX Client の機能


 

ActiveX ビューの命名規則

命名規則では、CORBA インターフェイスを ActiveX にマッピングして型と変数名の不整合を回避するためのアルゴリズムが定義されます。また、命名規則では、特定のオブジェクトの使い方も指定されます。すべての ActiveX メソッドの名前は、DI で始まります。

ActiveX Client は、CORBA インターフェイスのオートメーション・バインディングを作成するときにこの命名規則を参照します。CORBA インターフェイス名が Account の場合、そのインターフェイスのオートメーション・バインディング名は DIAccount となります。

多くの場合、CORBA インターフェイス名はモジュールと呼ばれる入れ子になったレベルの中でスコープ指定されますが、ActiveX ではスコープ指定は存在しません。名前の不整合を避けるため、ActiveX Client は異なるスコープの名前をインターフェイスの先頭に追加して、CORBA インターフェイスを ActiveX にマッピングします。

たとえば、Account という名前の CORBA インターフェイスが、OMG IDL ファイルで次のように定義されているとします。

 
module University
{
   module Student
     {
       interface Account
           {//Account インターフェイスのオペレーションと属性
           };
     };

};

CORBA では、このインターフェイスの名前は University::Student::Account です。ActiveX Client は、この名前を ActiveX 用に DIUniversity_Student_Account に変換します。

 

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