bea ホーム | 製品 | dev2dev | support | askBEA
BEA Logo Tuxedo
 ドキュメントのダウンロード   サイトマップ   用語集 
検索
0

Tuxedo CORBA ActiveX

 Previous Next Contents Index View as PDF  

概要

ここでは、ActiveX クライアント・アプリケーション開発プロセスの概要、および BEA Tuxedo CORBA 環境用に 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 ActiveX Application Builder を使用してインターフェイスのオートメーション・バインディングを作成します。

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

 


しくみ

BEA ActiveX Client を使用すると、ActiveX クライアント・アプリケーションは、BEA Tuxedo ドメインの CORBA オブジェクトとやり取りできます。ActiveX クライアント・アプリケーションは、オートメーション環境オブジェクトを使用して、BEA Tuxedo ドメインの CORBA オブジェクトにアクセスします。ActiveX Client は、CORBA オブジェクトの ActiveX ビューを作成します。CORBA オブジェクトの ActiveX ビューは、ActiveX クライアント・アプリケーションから受信したすべての要求を、BEA Tuxedo ドメインの適切な CORBA オブジェクトに変換および転送します。

開発ツールの Application Builder は、ActiveX クライアント・アプリケーションの対話先となる BEA Tuxedo ドメイン内の CORBA オブジェクトを選択するためにクライアント開発ツール (Visual Basic など) と一緒に使用します。

Application Builder は、ActiveX Client への主要なユーザ・インターフェイスです。Application Builder を使用すると、デスクトップ・アプリケーションで使用可能な CORBA オブジェクトを選択し、その CORBA オブジェクトの ActiveX ビューと、その ActiveX ビューをクライアント・コンピュータにデプロイするためのパッケージを作成できます。

図1-1 に、ActiveX Client のしくみを示します。

図 1-1 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
{//Operations and attributes of the Account interface
};
};

};

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

ActiveX クライアント・アプリケーションは、OLE オートメーション環境オブジェクトを使用して BEA Tuxedo ドメインで CORBA オブジェクトにアクセスします。ActiveX クライアント・アプリケーションは、BEA ActiveX Client を使用して CORBA オブジェクトへの要求を処理します。Active X Application Builder を使用すると、ActiveX クライアント・アプリケーションで使用可能な CORBA インターフェイスを選択して、その CORBA インターフェイスの ActiveX ビューと、その ActiveX ビューをクライアント・マシンにデプロイするためのパッケージを作成できます。これらのクライアント・アプリケーションは、Visual Basic や PowerBuilder などのオートメーション開発ツールを使用してビルドします。

 


OMG IDL

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

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

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

 


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

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

ActiveX クライアント・アプリケーションは、インターフェイス・リポジトリを使用していることを認識しません。BEA ActiveX Client は、CORBA オペレーションを使用して、インターフェイス・リポジトリから CORBA オブジェクトに関する情報を取得します。

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

 


ドメイン

ドメインとは、オブジェクトとサービスを管理エンティティとして 1 つのグループにまとめる手段のことです。BEA Tuxedo ドメインは、最低 1 つの IIOP サーバ・リスナ/ハンドラ(ISL/ISH) を持ち、名前で識別されます。1 つのクライアント・アプリケーションから、複数の Bootstrap オブジェクトを使用して複数の BEA Tuxedo ドメインに接続できます。BEA Tuxedo ドメインごとに、クライアント・アプリケーションは、FactoryFinder オブジェクト、InterfaceRepository オブジェクト、SecurityCurrent オブジェクト、および TransactionCurrent オブジェクトを取得できます。各オブジェクトは、BEA Tuxedo ドメイン内で提供されるサービスに対応しています。Bootstrap オブジェクト、FactoryFinder オブジェクト、InterfaceRepository オブジェクト、SecuritiyCurrent オブジェクト、TransactionCurrent オブジェクトの説明については、この章の環境オブジェクトを参照してください。

注記 TransactionCurrent オブジェクトと SecurityCurrent オブジェクトが同時に存在できるのは、それぞれ 1 つだけです。また、ともに同じ Bootstrap オブジェクトに関連付けられている必要があります。

図1-2 に、BEA Tuxedo ドメインのしくみを示します。

図 1-2 BEA Tuxedo ドメインのしくみ


 

 


環境オブジェクト

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

BEA Tuxedo ソフトウェアは、オートメーション・プログラミング環境用の環境オブジェクトを提供します。

Bootstrap オブジェクト

クライアント・アプリケーションは、Bootstrap オブジェクトを作成します。ISL/ISH のリストは、パラメータの形で、または環境変数 TOBJADDR や Java プロパティを介して提供できます。単一の ISL/ISH は、次の形式で指定します。

//host:port

例: //myserver:4000

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

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

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


 

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

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

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

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

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

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

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

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

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


 

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

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

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

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

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

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

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

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

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

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

SecurityCurrent オブジェクト

SecurityCurrent オブジェクトは、CORBA サービス・セキュリティ・サービスの BEA Tuxedo インプリメンテーションです。BEA Tuxedo セキュリティ・モデルは、認証に基づいています。SecurityCurrent オブジェクトを使用すると、適切なセキュリティのレベルを指定できます。利用できる認証レベルは以下のとおりです。

注記 クライアント・アプリケーションが認証されておらず、セキュリティ・レベルが TOBJ_NOAUTH の場合、BEA Tuxedo ドメインの ISL/ISH は、ISL/ISH に送信されるユーザ名とクライアント・アプリケーション名でクライアント・アプリケーションを登録します。

BEA Tuxedo CORBA の SecurityCurrent オブジェクトでは、PrincipalAuthenticator プロパティと Credentials プロパティのみがサポートされています。クライアント・アプリケーションでの SecurityCurrent オブジェクトの使い方については、セキュリティの使い方を参照してください。

TransactionCurrent オブジェクト

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

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

クライアント・アプリケーションでの TransactionCurrent オブジェクトの使い方については、トランザクションの使い方を参照してください。

InterfaceRepository オブジェクト

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

ActiveX クライアント・アプリケーションは、InterfaceRepository オブジェクトを使用していることを認識しません。ActiveX クライアント・アプリケーションは、Bootstrap オブジェクトを使用して InterfaceRepository オブジェクトへのオブジェクト・リファレンスを取得します。

 

Back to Top Previous Next
Contact e-docsContact BEAwebmasterprivacy