|
|
CORBA クライアント・アプリケーションの開発概念
この章では、BEA Tuxedo 製品の CORBA 環境でサポートされるクライアント・アプリケーションのタイプと、CORBA クライアント・アプリケーションの開発前に理解しておく必要がある概念について説明します。
ここでは、次の内容について説明します。
クライアント・アプリケーションの概要
BEA Tuxedo ソフトウェアは、以下のタイプのクライアント・アプリケーションをサポートしています。
このタイプのクライアント・アプリケーションは、C++ 環境オブジェクトを使用して BEA Tuxedo ドメイン内の CORBA オブジェクトにアクセスし、CORBA C++ Object Request Broker (ORB) を使用して CORBA オブジェクトへの要求を処理します。CORBA C++ クライアント・アプリケーションをビルドするには、BEA Tuxedo 開発コマンドを使用します。CORBA C++ クライアント・アプリケーションは、OBV (Object-by-Value) と CORBA インターオペラブル・ネーミング・サービス (INS) をサポートしています。
このタイプのクライアント・アプリケーションは、Java 環境オブジェクトを使用して BEA Tuxedo ドメイン内の CORBA オブジェクトにアクセスします。しかし、これらのクライアント・アプリケーションは、BEA Tuxedo CORBA ORB 以外の ORB 製品を使用して CORBA オブジェクトへの要求を処理します。CORBA Java クライアント・アプリケーションは、ORB 製品の Java 開発ツールを使用してビルドします。BEA Tuxedo ソフトウェアは、Sun Java Development Kit (JDK) Java クライアントとの相互運用性をサポートしています。
注記 サポートされるソフトウェアのバージョンについては、『BEA Tuxedo システムのインストール』を参照してください。
このタイプのクライアント・アプリケーションは、オートメーション環境オブジェクトを使用して BEA Tuxedo ドメイン内の CORBA オブジェクトにアクセスし、BEA ActiveX Client を使用して CORBA オブジェクトへの要求を処理します。Application Builder を使用すると、ActiveX クライアント・アプリケーションで使用可能な CORBA インターフェイスを選択して、その CORBA インターフェイスの ActiveX ビューと、その ActiveX ビューをクライアント・マシンにデプロイするためのパッケージを作成できます。これらのクライアント・アプリケーションは、Visual Basic や PowerBuilder などのオートメーション開発ツールを使用してビルドします。
OMG IDL
どのような分散アプリケーションでも、クライアント/サーバ・アプリケーションは通信を行うための基本的な情報を必要とします。たとえば、CORBA クライアント・アプリケーションは、要求できるオペレーションとその引数を知る必要があります。
Object Management Group (OMG) インターフェイス定義言語 (IDL) を使用すると、クライアント・アプリケーションへの CORBA インターフェイスを定義できます。OMG IDL で記述されたインターフェイス定義では、CORBA インターフェイスが完全に定義され、各オペレーションの引数が完全に指定されます。OMG IDL は、純粋な宣言型言語です。このため、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 開発コマンドを使用します。
idl2ir
コマンドを使用すると、インターフェイス・リポジトリに CORBA インターフェイスを追加できます。インターフェイス・リポジトリが存在しない場合は、このコマンドでインターフェイス・リポジトリを作成できます。また、インターフェイス・リポジトリ内の CORBA インターフェイスを更新できます。ir2idl
コマンドを使用すると、インターフェイス・リポジトリの内容から OMG IDL ファイルを作成できます。irdel
コマンドを使用すると、インターフェイス・リポジトリから CORBA インターフェイスを削除できます。インターフェイス・リポジトリの開発コマンドについては、『BEA Tuxedo コマンド・リファレンス』を参照してください。
ドメイン
ドメインは、オブジェクトとサービスを管理エンティティとしてグループ化するための方法です。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 ソフトウェアには、以下の環境オブジェクトが用意されています。
このオブジェクトは、CORBA クライアント・アプリケーションと BEA Tuxedo ドメイン間の通信を確立します。また、BEA Tuxedo ドメイン内のほかの環境オブジェクトのオブジェクト・リファレンスを取得します。
注記 サードパーティ・クライアント ORB は、CORBA インターオペラブル・ネーミング・サービス (INS) を使用して BEA Tuxedo ドメイン内のサービスにアクセスできます。詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』の「CORBA ブートストラップ処理のプログラミング・リファレンス」を参照してください。
この CORBA オブジェクトは、ファクトリを検索します。このファクトリは、CORBA オブジェクトのオブジェクト・リファレンスを作成できます。
この CORBA オブジェクトには、使用可能なすべての CORBA インターフェイスのインターフェイス定義と、CORBA インターフェイスへのオブジェクト・リファレンスを作成するためのファクトリが含まれています。
この BEA 固有のオブジェクトは、CORBA クライアント・アプリケーションが適切なセキュリティ・クリデンシャルを使用して BEA Tuxedo ドメインにログインするために使用されます。BEA Tuxedo ソフトウェアは、CORBA サービス・セキュリティ・サービスの実装を提供します。
この BEA 固有のオブジェクトは、CORBA クライアント・アプリケーションがトランザクションに参加できるようにします。TransactionCurrent オブジェクトは、 CORBA のオブジェクト・トランザクション・サービス (OTS) の実装を提供します。
この CORBA オブジェクトを使用すると、CORBA クライアント・アプリケーションは CosNotification サービス内のイベント・チャネル・ファクトリ (CosNotifyChannelAdmin::EventChannelFactory
) へのリファレンスを取得できます。EventChannelFactory は、ノーティフィケーション・サービス・チャネルの検索に使用されます。
また、Tobj_SimpleEventsService
オブジェクトも用意されています。この BEA 固有のオブジェクトを使用すると、CORBA クライアント・アプリケーションは BEA 固有のイベント・インターフェイスへのリファレンスを取得できます。このイベント・インターフェイスは、CosNotification サービスで定義される標準の構造化されたイベントを受け渡しますが、API は簡単に使用できるよう簡素化されています。
この CORBA オブジェクトを使用すると、CORBA クライアント・アプリケーションは名前空間を使用してオブジェクト・リファレンスを解決できます。BEA Tuxedo ソフトウェアは、CORBA サービス・ネーミング・サービスの実装を提供します。
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 オブジェクトへのリファレンスを取得します。
resolve_initial_references
メ
ソッドが呼び出され、FactoryFinder オブジェクトへのリファレンスが取得さ
れます。
図 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 クライアント・アプリケーションは認証を受け、ユーザ名とクライアント・アプリケーション名を指定することができます。パスワードは不要です。
CORBA クライアントは BEA Tuxedo ドメインの認証を受け、ユーザ名、クライアント・アプリケーション名、およびアプリケーション・パスワードを指定する必要があります。
TOBJ_SYSAUTH 情報のほかに、CORBA クライアント・アプリケーションはアプリケーション固有の情報を指定する必要があります。デフォルトの BEA Tuxedo 認証サービスがアプリケーション・コンフィギュレーションで使用される場合、CORBA クライアント・アプリケーションはユーザ・パスワードを指定する必要があります。それ以外の場合、CORBA クライアント・アプリケーションはそのアプリケーションのカスタム認証サービスによって解釈される認証データを指定します。
注記 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) に定義します。トランザクション方針は以下のとおりです。
インターフェイスはトランザクションに関与しません。このインターフェイス用に作成されるオブジェクトは、トランザクションに関与できません。BEA Tuxedo ソフトウェアは、この方針が設定されているインターフェイスがトランザクションに関与した場合に例外 (INVALID_TRANSACTION
) を生成します。
インターフェイスはトランザクションに関与できます。要求がトランザクションに関係する場合、オブジェクトはトランザクションに関与できます。
インターフェイスは常にトランザクションの一部である必要があります。インターフェイスがトランザクションの一部ではない場合、トランザクションは TP フレームワークによって自動的に開始されます。
インターフェイスはトランザクションに関与しません。インターフェイスはトランザクションの一部になることができますが、UBBCONFIG
ファイルでこのインターフェイスに対して指定された AUTOTRAN 方針が無視されます。
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 種類のインターフェイス・セットを提供します。
NotificationService
オブジェクトは、CORBA ベースのノーティフィケーション・サービス・インターフェイス (CosNotification
サービス・インターフェイス) のサブセットを提供します。Tobj_SimpleEventsService
オブジェクトは、使いやすいように設計された BEA 固有のインターフェイスを提供します。どちらのインターフェイス・セットも、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
に変換します。
|
Copyright © 2001, BEA Systems, Inc. All rights reserved.
|