|
|
|
|
|
|
CORBA ブートストラップ処理のプログラミング・リファレンス
ここでは、次の内容について説明します。
ブートストラップ処理が必要な理由
クライアント・アプリケーションが BEA Tuxedo オブジェクトと通信するためには、オブジェクト・リファレンスを取得する必要があります。オブジェクト・リファレンスがないと、通信はできません。この問題を解決するために、クライアント・アプリケーションではブートストラップ処理メカニズムを使用して BEA Tuxedo ドメインのオブジェクトのオブジェクト・リファレンスを取得します。
サポートされているブートストラップ処理メカニズム
リリース 8.0 以降の Tuxedo では、2 つのブートストラップ処理メカニズムがサポートされます。
BEA クライアント ORB を使用する場合に使用します。
別のベンダのクライアント ORB を使用する場合に使用します。
注記 BEA Tuxedo ソフトウェアに付属の CORBA C++ クライアントおよび Java クライアントでは、インターオペラブル・ネーミング・サービスのブートストラップ処理メカニズムを使用できますが、性能上の理由により推奨はできません。
BEA ブートストラップ処理メカニズム
BEA ブートストラップ処理メカニズムでは、Bootstrap オブジェクトを使用します。Bootstrap オブジェクトは、クライアントとサーバ両方の (リモート CORBA オブジェクトではなく) ローカル・プログラミング・オブジェクトです。Bootstrap オブジェクトが作成されるとき、そのコンストラクタは BEA Tuxedo IIOP リスナ/ハンドラのネットワーク・アドレスを必要とします。その情報が提供されると、ブートストラップ処理オブジェクトでは BEA Tuxedo ドメインの主要なリモート・オブジェクトのオブジェクト・リファレンスを生成できます。それらのオブジェクト・リファレンスは、BEA Tuxedo ドメインで利用可能なサービスにアクセスするために使用できます。
Bootstrap オブジェクトの機能
Bootstrap オブジェクトは、次の BEA Tuxedo CORBA インターフェイスのオブジェクト・リファレンスにアクセスする必要のあるクライアントまたはサーバ・アプリケーションによって作成されます。
Bootstrap オブジェクトは、IIOP リスナ/ハンドラのアドレスの形式によっては特定の BEA Tuxedo ドメインへの最初の接続を表す場合があります。ヌル・スキーマ Universal Resource Locator (URL) 形式が使用される場合に (バージョン 5.1 以前の BEA WebLogic Enterprise リリースと BEA Tuxedo リリース 8.0 でサポートされている唯一のアドレス形式)、Bootstrap オブジェクトは最初の接続を表します。ただし、この URL 形式が使用される場合は、Bootstrap オブジェクトが作成されるまで接続は行われません。アドレス形式と接続回数の詳細については、「Tobj_Bootstrap」を参照してください。
BEA Tuxedo CORBA リモート・クライアントについては、Bootstrap オブジェクトは BEA Tuxedo IIOP リスナ/ハンドラのホストとポートを使用して作成されます。しかし、BEA Tuxedo ネイティブのクライアント・アプリケーションとサーバ・アプリケーションでは、ホストとポートを指定する必要はありません (特定の BEA Tuxedo ドメインで実行されるため)。IIOP リスナ/ハンドラのホストとポート ID は、BEA Tuxedo ドメインのコンフィギュレーション情報に含まれています。
Bootstrap オブジェクトは、その作成後に、特定の BEA Tuxedo ドメインにあるオブジェクトのオブジェクト・リファレンスに対する要求を満たします。異なる Bootstrap オブジェクトを使用すると、アプリケーションで複数のドメインを使用できます。
Bootstrap オブジェクトを使用すると、次のオブジェクトのオブジェクト・リファレンスを取得できます。
SecurityCurrent オブジェクトは、BEA Tuxedo ドメイン内のセキュリティ・コンテキストを確立するために使用します。クライアントは、SecurityCurrent オブジェクトの principal_authenticator 属性から PrincipalAuthenticator を取得できます。
TransactionCurrent オブジェクトは、BEA Tuxedo トランザクションに参加するために使用します。基本的なオペレーションは以下の通りです。
トランザクションを開始します。以降のオペレーションは、このトランザクションのスコープ内で発生します。
トランザクションを終了します。このクライアント・アプリケーションですべてのオペレーションが正常に終了しています。
トランザクションをアボートします。ほかのすべてのパーティシパントにロールバックを指示します。
現在のトランザクションの参加を一時停止します。このオペレーションは、トランザクションを示すオブジェクトを返し、クライアント・アプリケーションが後でトランザクションを再開できるようにします。
指定したトランザクションの参加を再開します。
FactoryFinder オブジェクトは、ファクトリを取得するために使用します。BEA Tuxedo システムで、ファクトリはアプリケーション・オブジェクトを作成するために使用します。FactoryFinder では、次のような方法でファクトリを検索できます。
find_factories)。id と種類で構成される名前コンポーネントと一致するファクトリを取得する (find_one_factory)。find_one_factory_by_id)。find_factories_by_id)。list_factories)。インターフェイス・リポジトリには、BEA Tuxedo ドメイン内でインプリメントされる CORBA オブジェクトのインターフェイス記述が含まれています。動的起動インターフェイス (DII) を使用するクライアントでは、インターフェイス・リポジトリのリファレンスがないと CORBA 要求の構造体を構築できません。ActiveX クライアントはこの特殊なケースです。COM/IIOP ブリッジのインプリメンテーションでは内部で DII が使用されるので、インターフェイス・リポジトリのリファレンスを取得しなければなりません (ただしこれはデスクトップ・クライアントに対して透過的)。
NamingService オブジェクトは、ルート名前空間のリファレンスを取得するために使用します。このオブジェクトを使用すると、ORB は名前空間のルートを検索します。
NotificationService オブジェクトは、CosNotification サービス内のイベント・チャネル・ファクトリ (CosNotifyChannelAdmin::EventChannelFactory) のリファレンスを取得するために使用します。BEA Tuxedo システムで、EventChannelFactory はノーティフィケーション・サービス・チャネルの検索に使用します。
Tobj_SimpleEventsService オブジェクトは、BEA シンプル・イベント・サービス内のイベント・チャネル・ファクトリ (Tobj_SimpleEvents::ChannelFactory) のリファレンスを取得するために使用します。BEA Tuxedo システムで、ChannelFactory は BEA シンプル・イベント・サービス・チャネルの検索に使用します。
FactoryFinder オブジェクトとインターフェイス・リポジトリ・オブジェクトは、環境オブジェクト・ライブラリでインプリメントされません。しかし、それらのオブジェクトは BEA Tuxedo ドメインに固有であり、したがって概念的には SecurityCurrent オブジェクトおよび TransactionCurrent オブジェクトと似ています。
Bootstrap オブジェクトは、クライアント・アプリケーションと BEA Tuxedo ドメインの間の関連 (セッション) を意味します。この関連のコンテキストで、Bootstrap オブジェクトはほかの Current オブジェクト (SecurityCurrent と TransactionCurrent) との包含関係を強制します。Current オブジェクトは、このドメインの範囲内で、Bootstrap オブジェクトが存在している間のみ有効です。
注記 新しい URL アドレス形式 (corbaloc://hostname:port_number) を使用している場合の SecurityCurrent の解決はローカルの処理です。つまり、クライアントから IIOP リスナ/ハンドラへの接続は行われません。
また、クライアントでは各 Current オブジェクトにつきインスタンスは 1 つしか利用できません。Current オブジェクトが既に存在する場合でも、新たな Current オブジェクトの作成が失敗することはありません。失敗するのではなく、既存のオブジェクトのもう 1 つのリファレンスが渡されます。つまり、クライアント・アプリケーションは Current オブジェクトの単一インスタンスの複数のリファレンスを持つことになります。
Current オブジェクトの新しいインスタンスを作成するには、まず Bootstrap オブジェクトの destroy_current() メソッドを呼び出す必要があります。この呼び出しですべての Current オブジェクトが無効になりますが、BEA Tuxedo ドメインとのセッションは破棄されません。destroy_current() を呼び出した後は、既存の Bootstrap オブジェクトを使用して BEA Tuxedo ドメイン内で Current オブジェクトの新しいインスタンスを作成できます。
別のドメインの Current オブジェクトを取得するには、別の Bootstrap オブジェクトを作成する必要があります。同時に複数の Bootstrap オブジェクトを持つこともできますが、「アクティブ」にできる (Current オブジェクトを関連付けることができる) のは 1 つの Bootstrap オブジェクトだけです。したがって、アプリケーションでは「アクティブ」な Bootstrap オブジェクトの destroy_current() を呼び出してから別の Bootstrap オブジェクト (アクティブな Bootstrap オブジェクトになる) の新しい Current オブジェクトを取得する必要があります。
注記 複数のドメインのオブジェクトにアクセスする必要がある場合は、オブジェクトをローカル・ドメインにインポートするか、複数のドメインにアクセスするようにアプリケーションをコンフィギュレーションします。マルチ・ドメイン・コンフィギュレーションの詳細については、『BEA Tuxedo Domains コンポーネント』の「Configuring Multiple CORBA Domains」を参照してください。
サーバとネイティブ・クライアントは BEA Tuxedo ドメインの中に存在します。したがって、「セッション」は確立されません。ただし、同じ包含関係が強制されます。サーバとネイティブ・クライアントは、//host:port ではなく空の文字列を指定してそれらが含まれているドメインにアクセスします。
注記 Bootstrap オブジェクトを使用する場合、クライアント・アプリケーションとサーバ・アプリケーションでは ORB::resolve_initial_references() メソッドではなく Tobj_Bootstrap::resolve_initial_references() メソッドを使用する必要があります。
サポートされている BEA リモート・クライアントの種類
表 4-1 は、Bootstrap オブジェクトを使用してほかの環境オブジェクト (FactoryFinder、SecurityCurrent、TransactionCurrent、InterfaceRepository など) にアクセスできるリモート・クライアントの種類を示しています。これらのクライアントは、BEA Tuxedo CORBA ソフトウェアに付属しています。サード・パーティ製のクライアント ORB では、CORBA インターオペラブル・ネーミング・サービスを使用する必要があります。
機能と制限事項
Bootstrap オブジェクトには、以下の機能と制限があります。
destroy_current() を呼び出してから、別のドメインの Current オブジェクトを取得する必要があります。別々の BEA Tuxedo ドメインと接続を確立する複数の Bootstrap オブジェクトを持つこともできますが、Current オブジェクトは 1 組しか有効になりません。既存の Current オブジェクトを破棄しないと、ほかの Current オブジェクトを取得することはできません。 CORBA::NO_PERMISSION 例外が返されます。
Bootstrap オブジェクト API
Bootstrap オブジェクト・アプリケーション・プログラミング・インターフェイス (API) は、まず OMG 定義言語 (IDL) で記述し (移植性のため)、その後に C++、Java、および ActiveX で記述します。C++ および Java の記述では、特定の BEA Tuxedo ドメインの Bootstrap オブジェクトをビルドするために必要なコンストラクタが追加されます。
Tobj モジュール
表 4-2 は、各 ID で返されるオブジェクト・リファレンスを示しています。
表 4-3 は、Tobj モジュールの例外を示しています。
C++ のマッピング
リスト 4-1 は、Tobj_bootstrap.h ファイルでの C++ の宣言を示しています。
リスト 4-1 Tobj_boostrap.h の宣言
#include <CORBA.h>
class Tobj_Bootstrap {
public:
Tobj_Bootstrap(CORBA::ORB_ptr orb, const char* address);
CORBA::Object_ptr resolve_initial_references(
const char* id);
void register_callback_port(CORBA::Object_ptr objref);void destroy_current( );
};
Java のマッピング
リスト 4-2 は、Tobj_Bootstrap.java のマッピングを示しています。
リスト 4-2 Tobj_Bootstrap.java のマッピング
package com.beasys;
public class Tobj_Bootstrap {
public Tobj_Bootstrap(org.omg.CORBA.ORB orb,
String address)
throws org.omg.CORBA.SystemException;
public class Tobj_Bootstrap {
public Tobj_Bootstrap(org.omg.CORBA.ORB orb, String address,
java.applet.Applet applet)
throws org.omg.CORBA.SystemException;
public void register_callback_port(orb.omg.CORBA.Object objref)throws org.omg.CORBA.SystemException;
public org.omg.CORBA.Object
resolve_initial_references(String id)
throws Tobj.InvalidName,
org.omg.CORBA.SystemException;
public void destroy_current()
throws org.omg.CORBA.SystemException;
}
Microsoft デスクトップ・クライアントのマッピング
Bootstrap オブジェクトは、Microsoft デスクトップでインプリメントされるクライアントが使用できるように BEA ActiveX クライアント・ソフトウェアで提供されます。デスクトップ・クライアントでは、次の 2 つのインターフェイスを使用できます。
オートメーションのマッピング
リスト 4-3 は、オートメーション Bootstrap インターフェイスのマッピングを示しています。
リスト 4-3 オートメーション (デュアル) Bootstrap インターフェイスのマッピング
interface DITobj_Bootstrap : IDispatch
{
HRESULT Initialize(
[in] BSTR address);
HRESULT CreateObject(
[in] BSTR progid,
[out, retval] IDispatch** rtrn);
HRESULT destroy_current();
};
C++ メンバ関数
この節では、BEA ブートストラップ処理メカニズムでサポートされる C++ メンバ関数について説明します。
Tobj_Bootstrap
概要
Bootstrap オブジェクトのコンストラクタです。
C++ マッピング
Tobj_Bootstrap(CORBA::ORB_ptr orb, const char* address);
throws Tobj::BAD_PARAM
org.omg.CORBA.SystemException;
パラメータ
クライアントの ORB オブジェクトへのポインタ。Bootstrap オブジェクトの内部では、orb の string_to_object メソッドが使用されます。
address
BEA Tuxedo ドメインの IIOP リスナ/ハンドラのアドレス。このアドレスは、クライアントの種類と必要なセキュリティのレベルに応じて異なる形式で指定します。クライアントには次の 3 種類があります。
BEA Tuxedo CORBA でサポートされるリモート・クライアントの説明については、「サポートされている BEA リモート・クライアントの種類」という節を参照してください。
リモート・クライアントの場合、address では、クライアント・アプリケーションが BEA Tuxedo ドメインにアクセスするために使用する IIOP リスナ/ハンドラのネットワーク・アドレスを指定します。
アドレスは、次のいずれかの形式で指定できます。
"//hostname:port_number"
"//#.#.#.#:port_number"
"corbaloc://hostname:port_number"
"corbalocs://hostname:port_number"
最初の形式の場合、ドメインではローカルの名前解決機能 (通常は DNS) を使用して hostname のアドレスが検索されます。ホスト名はリモート・マシンでなければならず、ローカルの名前解決機能では hostname がそのリモート・マシンのアドレスに明確に解決されなければなりません。
注記 hostname は、先頭を文字で始める必要があります。
2 番目の形式の場合、#.#.#.# にはドット区切りの 10 進数を指定します。ドット区切りの 10 進数形式では、それぞれの # に 0 〜 255 の数字を指定します。このドット区切りの 10 進数は、リモート・マシンの IP アドレスを表します。
最初と 2 番目の両方の形式で、port_number ではドメイン・プロセスが要求をリッスンする TCP ポート番号を指定します。port_number は、0 〜 65535 の数字でなければなりません。
TCP/IP アドレスは 1 つまたは複数を指定できます。複数のアドレスは、カンマ区切りのリストを使用して指定します。次に例を示します。
//m1.acme:3050
//m1.acme:3050,//m2.acme:3050,//m3.acme:3051
複数のアドレスを指定すると、BEA Tuxedo ソフトウェアでは接続が確立されるまで左から右の順序でアドレスが試されます。接続が試行されているときにアドレスの構文エラーが検出されると、BAD_PARAM 例外が直ちに呼び出し側に返され、BEA Tuxedo ソフトウェアによって接続の試行がアボートされます。たとえば、上記のカンマ区切りリストの最初のアドレスが //m1.3050 である場合は、構文エラーが検出され、接続の試行がアボートされます。BEA Tuxedo ソフトウェアがアドレス・リストの最後まで達しても有効なアドレスで接続を試行できない場合、つまりリストのどのアドレスにも接続を確立できない場合は、INVALID_DOMAIN 例外が呼び出し側に返されます。INVALID_DOMAIN 以外の例外が生成された場合、その例外は呼び出し側に直ちに返されます。
BEA Tuxedo では、ランダムなアドレスの選択もサポートされています。ランダムなアドレスの選択を使用する場合は、アドレス・リストの任意のメンバをかっこで囲まれたパイプ区切り (|) のネットワーク・アドレス・グループとして指定します。次に例を示します。
(//m1.acme:3050|//m2.acme:3050),//m1.acme:7000
この形式を使用すると、BEA Tuxedo システムではかっこで囲まれたアドレスのいずれか (//m1.acme:3050 または //m2.acme:3050) がランダムに選択されます。INVALID_DOMAIN 以外の例外が生成された場合、その例外は呼び出し側に直ちに返されます。選択したアドレスで接続を確立できない場合は、かっこの後にある次の要素で接続が試行されます。接続を確立できないうちに文字列の最後に達してしまった場合は、INVALID_DOMAIN 例外が呼び出し側にスローされます。
注記 次の形式でアドレス・リストを指定した場合、
(//m1.acme:3050||//m2.acme:3050),//r1.acme:7000
パイプ区切りリスト内のヌル・アドレスは無効と判断されます。BEA Tuxedo ソフトウェアで無効なアドレスがランダムに選択された場合は、BAD_PARAM 例外が呼び出し側に返され、BEA Tuxedo ソフトウェアによって接続の試行がアボートされます。
アドレス文字列は、TOBJADDR 環境変数または Tobj_Bootstrap コンストラクタのアドレス・パラメータで指定できます。
TOBJADDR 環境変数の詳細については、『BEA Tuxedo アプリケーションの設定
Tobj_Bootstrap で指定されたアドレスの方が常に TOBJADDR 環境変数よりも優先されます。TOBJADDR 環境変数を使用してアドレス文字列を指定するには、Tobj_Bootstrap の address パラメータで空の文字列を指定する必要があります。
注記 C++ アプリケーションでは TOBJADDR は環境変数であり、Java アプリケーションの場合はプロパティ、Java アプレットの場合は HTML パラメータです。
3 番目と 4 番目の形式は Uniform Resource Locator (URL) アドレス形式と呼ばれ、BEA WebLogic Enterprise バージョン 5.1 で導入されました。ヌル・スキーマ URL アドレス形式 (//hostname:port_number) の場合と同じように、URL アドレス形式を使用して IIOP リスナ/ハンドラの位置を指定します。ただし、corbaloc URL アドレス形式を使用する場合、IIOP リスナ/ハンドラへのクライアント・アプリケーションの初期接続はプリンシパル (クライアント) の ID が認証されるまで、またはユーザが最初のオペレーションを開始するまで遅延されます。corbalocs URL アドレス形式を使用する場合でも corbaloc と同じ接続の遅延がありますが、それに加えて、クライアント・アプリケーションがセキュア・ソケット・レイヤ (SSL) プロトコルを使用して ISL/ISH との初期接続を行います。表 4-4 は、2 つの URL アドレス形式の違いを示しています。
これらの URL アドレス形式は、インターオペラブル・ネーミング・サービスの一部として OMG によって採用されたオブジェクト URL の定義のサブセットです。BEA Tuxedo ソフトウェアでは、BEA WebLogic Enterprise 4.2 で追加されたランダマイズ機能だけでなく、セキュア HTTP の URL に基づいてモデル化される安全な形式をサポートするようにも、OMG 提案のインターオペラブル・ネーミング・サービスで規定された URL 形式が拡張されます。
corbaloc および corbalocs URL スキーマは、TCP/IP 中心の環境と DNS 中心の環境の両方で簡単に操作される位置を提供します。これらの URL スキーマでは、DNS 形式の hostname または IP アドレスと port_number を指定します。次に例を示します。
corbaloc://curly:1024,larry:1022,joe:1999
corbalocs://host1:1024,{host2:1022|host3:1999}
BEA WebLogic Enterprise バージョン 5.1 ソフトウェアでは、スキーマが異なる複数の URL のリストをサポートするように、OMG 提案のインターオペラブル・ネーミング・サービスで規定された URL 構文が拡張されています。次に例を示します。
corbaloc
s://curly:1024,corbaloc://larry:1111,
corbalocs://ctxobj:3434,mthd:3434,corbaloc://force:1111
上の例で、パーサが URL corbaloc://force:1111 に達した場合は、安全な接続が試行されなかったかのようにパーサの内部状態がリセットされ、保護なしの接続の試行が開始されます。
警告 ヌル・スキーマ URL アドレス (//hostname:port_number) と corbaloc および corbalocs URL アドレスは一緒に使用しないでください。
注記 Netscape の埋め込み型 Java ORB および JavaSoft JDK ORB で使用するように提供される Bootstrap オブジェクトでは、corbaloc および corbalocs URL はサポートされていません。
注記 corbaloc および corbalocs URL アドレス形式の使い方の詳細については、『BEA Tuxedo CORBA アプリケーションのセキュリティ機能』を参照してください。
注記 Bootstrap コンストラクタまたは TOBJADDR で指定するネットワーク・アドレスは、サーバ・アプリケーションの UBBCONFIG ファイルのネットワーク・アドレスと (大文字と小文字の区別を含めて) 正確に同じでなければなりません。アドレスが一致しない場合、Bootstrap コンストラクタの呼び出しは失敗し、見たところ関係のなさそうな次のエラー・メッセージが表示されます。 ERROR: Unofficial connection from client atたとえば、ネットワーク・アドレスがサーバ・アプリケーションの
<tcp/ip address>/<port-number>UBBCONFIG ファイルの ISL コマンド行オプション文字列で (ヌル URL アドレス形式を使用して) //TRIXIE:3500 として指定されている場合、Bootstrap コンストラクタまたは TOBJADDR で //192.12.4.6:3500 または //trixie:3500 を指定すると接続の試行は失敗します。UNIX システムで大文字、小文字の区別を調べるには、ホスト・システムで uname -n コマンドを使用します。Windows 2000 システムで正確な大文字と小文字の区別を調べるには、コントロール・パネルでホスト・システムのネットワーク設定を確認します。
注記 前の注記のエラーは、URL アドレス形式が使用される場合は遅延されます。つまり、ISL/ISH への接続が遅延させるので Bootstrap オブジェクトの作成時にそのエラーは発生しません。
ネイティブ・クライアントの場合、Tobj_Bootstrap コンストラクタの address パラメータは常に (ヌル・ポインタではなく) 空の文字列でなければなりません。ネイティブ・クライアントは、TUXCONFIG 環境変数で指定されたアプリケーションに接続します。アドレスが空でない場合は、コンストラクタによって CORBA::BAD_PARAM が生成されます。
Bootstrap オブジェクトにアクセスする必要がある場合、サーバでは TP.bootstrap() を呼び出して TP フレームワークを使用してそのオブジェクト・リファレンスを取得しなければなりません。Bootstrap オブジェクトの新しいインスタンスを作成することは避ける必要があります。
applet (Java メソッドのみに適用)
これは、クライアント・アプレットへのポインタです。クライアント・アプレットから Bootstrap オブジェクトに明示的に ISH ホストとポートが渡されない場合は、この引数を渡すことができます。この引数を渡すと、Bootstrap オブジェクトはアプレットの HTML ファイルで TOBJADDR の定義を検索します。
例外
BAD_PARAM
オブジェクトがニルである場合、あるいはオブジェクトに格納されているホストが接続と一致しないか、ホスト・アドレス (//hostname:port_number) が有効な形式ではない場合に発生します。
説明
Bootstrap オブジェクトを作成する C++ メンバ関数 (または Java メソッド)。
戻り値
新しく作成された Bootstrap オブジェクトへのポインタ。
Tobj_Bootstrap::register_callback_port
概要
IIOP ハンドラ (ISH) で共同クライアント/サーバの受信ポートを登録します。
C++ マッピング
void register_callback_port(CORBA::Object_ptr objref);
パラメータ
objref
共同クライアント/サーバによって作成されたオブジェクト・リファレンス。
例外
BAD_PARAM
オブジェクトがニルである場合、またはオブジェクトに格納されているホストが接続と一致しない場合に発生します。
IMP_LIMIT
register_callback_port メソッドが複数回呼び出された場合に発生します。
説明
この C++ メンバ関数 (または Java メソッド) は、共同クライアント/サーバの受信ポートを ISH に通知するために呼び出します。このメソッドは、GIOP 1.2 の双方向機能をサポートしていない共同クライアント/サーバ ORB (つまり GIOP 1.0 および 1.1 のクライアント ORB) でのみ使用します。GIOP 1.0 および 1.1 の場合、ISH では共同クライアント/サーバごとに 1 つの受信ポートのみをサポートします。このため、register_callback_port メソッドは接続されている共同クライアント/サーバごとに 1 度だけ呼び出すようにします。
使用上の注意
このメソッドを使用するときには、以下の情報を考慮に入れてください。
register_callback_port メソッドが共同クライアント/サーバから呼び出されない場合、コールバック・ポートは ISH に登録されず、デフォルトで非対称アウトバウンド IIOP が使用されます。この場合は、-O オプションを使用してサーバの IIOP リスナ (ISL) を起動する必要があります。-O オプションは、非対称アウトバウンド IIOP を有効にします。非対称アウトバウンド IIOP を有効にしないと、サーバからクライアントの呼び出しが ISL/ISH によって許可されません。register_callback_port メソッドを呼び出す必要があります。 register_callback_port メソッドを呼び出してからコールバック・オブジェクトのオブジェクト・リファレンスをサーバに渡す必要があります。 戻り値
特にありません。
Tobj_Bootstrap::resolve_initial_references
概要
CORBA オブジェクト・リファレンスを取得します。
C++ マッピング
CORBA::Object_ptr resolve_initial_references(
const char* id);
throws Tobj::InvalidName,
org.omg.CORBA.SystemException;
パラメータ
id
このパラメータの値は次のいずれかです。
"FactoryFinder"
"InterfaceRepository"
"NameService"
"NotificationService"
"SecurityCurrent"
"TransactionCurrent"
"Tobj_SimpleEventsService"
例外
InvalidName
id が上記のどの名前でもない場合に発生します。サーバでは、SecurityCurrent が渡された場合にも resolve_initial_references で Tobj::InvalidName が生成されます。
CORBA::NO_PERMISSION
id が TransactionCurrent または SecurityCurrent で、クライアントの別の Bootstrap オブジェクトが Current オブジェクトを所有している場合に発生します。
説明
この C++ メンバ関数 (または Java メソッド) は、FactoryFinder オブジェクト、SecurityCurrent オブジェクト、TransactionCurrent オブジェクト、NotificationService オブジェクト、Tobj_SimpleEventsService オブジェクト、および InterfaceRepository オブジェクトの CORBA オブジェクト・リファレンスを取得します。特定のオブジェクト・リファレンスについては、_narrow 関数を呼び出します。たとえば、FactoryFinder の場合は Tobj::FactoryFinder::_narrow を呼び出します。
戻り値
表 4-2 は、各 id で返されるオブジェクト・リファレンスを示しています。
Tobj_Bootstrap::destroy_current()
概要
Bootstrap オブジェクトで表されるドメインの Current オブジェクトを破棄します。
C++ マッピング
void destroy_current();
例外
Bootstrap オブジェクトが Current オブジェクトの所有者でない場合に CORBA::NO_PERMISSION が生成されます。
説明
この C++ メンバ関数は、Bootstrap オブジェクトで表されるドメインの Current オブジェクトを無効にします。destroy_current() メソッドを呼び出した後、Current オブジェクトは無効になります。それ以降に古い Current オブジェクトを使用しようとすると、CORBA::BAD_INV_ORDER 例外がスローされます。プログラミングでは、すべての Current オブジェクトを解放してから destroy_current() を呼び出すようにしてください。
注記 destroy_current() メソッドは、2 つの Current オブジェクト (Transaction と Security) を所有しているドメインの Bootstrap オブジェクトで呼び出す必要があります。このメソッドを呼び出すと、セキュリティの logoff が暗黙的に呼び出され、クライアントによって開始されたトランザクションがすべて暗黙的にロールバックされます。
アプリケーションでは、まず destroy_current() を呼び出してから別のドメインの TransactionCurrent または SecurityCurrent の resolve_initial_references を呼び出す必要があります。そうしないと、resolve_initial_references で CORBA::NO_PERMISSION が生成されます。
戻り値
特にありません。
Java のメソッド
Java BEA ブートストラップ処理 API では、次のメソッドがサポートされています。
これらのメソッドの詳細については、Javadoc API を参照してください。
オートメーションのメソッド
この節では、BEA ブートストラップ処理メカニズムでサポートされているオートメーションのメソッドについて説明します。
Initialize
概要
Bootstrap オブジェクトを BEA Tuxedo ドメインに初期化します。
MIDL マッピング
HRESULT Initialize([in] BSTR host);
オートメーション・マッピング
Sub Initialize(address As String)
パラメータ
address
BEA Tuxedo ドメインの IIOP リスナ/ハンドラのホスト名とポート。1 つまたは複数の TCP/IP アドレスを指定できます。複数のアドレスは、C++ のマッピングと同じようにカンマ区切りのリストで指定します。アドレスを指定しない場合は、TOBJADDR 環境変数の値が使用されます。
注記 Bootstrap コンストラクタまたは TOBJADDR で指定するネットワーク・アドレスは、アプリケーションの UBBCONFIG ファイルのネットワーク・アドレスと (形式および大文字と小文字の区別を含めて) 正確に同じでなければなりません。アドレスが一致しない場合、Bootstrap コンストラクタの呼び出しは失敗し、見たところ関係のなさそうな次のエラー・メッセージが表示されます。 ERROR: Unofficial connection from client at
<tcp/ip address>/<port-number>
たとえば、ネットワーク・アドレスが ISL コマンド行オプション文字列で //TRIXIE:3500 として指定された場合、Bootstrap コンストラクタまたは TOBJADDR で //192.12.4.6:3500 または //trixie:3500 を指定すると接続の試行が失敗します。UNIX システムで大文字、小文字の区別を調べるには、ホスト・システムで uname -n コマンドを使用します。Windows システムで正確な大文字と小文字の区別を調べるには、コントロール・パネルでホスト・システムのネットワーク設定を確認します。
戻り値
特にありません。
例外
表 4-5 は例外を示しています。
CreateObject
概要
Current 環境オブジェクトのインスタンスを作成します。
MIDL マッピング
HRESULT CreateObject(
[in] BSTR progid,
[out, retval] IDispatch** rtrn);
オートメーション・マッピング
Function CreateObject(progid As String) As Object
パラメータ
progid
作成する環境オブジェクトの progid。有効な progid は次のとおりです。
Tobj.FactoryFinder
Tobj.SecurityCurrent
Tobj.TransactionCurrent
戻り値
作成された環境オブジェクトのインターフェイス・ポインタの参照。
例外
表 4-6 は例外を示しています。
DestroyCurrent
概要
BEA Tuxedo ドメインからログアウトし、TransactionCurrent オブジェクトと SecurityCurrent オブジェクトを無効にします。
MIDL マッピング
HRESULT destroy_current();
オートメーション・マッピング
Sub destroy_current()
パラメータ
特にありません。
戻り値
特にありません。
例外
特にありません。
Bootstrap オブジェクトのプログラミング例
この節では、Bootstrap オブジェクトを使用する次のプログラミング例を紹介します。
Java クライアントの例: SecurityCurrent オブジェクトの取得
リスト 4-4 は、SecurityCurrent オブジェクトを取得する Java クライアントのプログラミング方法を示しています。
リスト 4-4 SecurityCurrent オブジェクトを取得する Java クライアントのプログラミング
import java.util.*;
import org.omg.CORBA.*;
import com.beasys.*;
class client {
public static void main(String[] args)
{
Properties prop = null;
Tobj.PrincipalAuthenticator auth = null;
String host_port = "//COLORMAGIC:10000";
// ホストとポートを設定
if (args.length == 1) host_port = args[0];
try {
// ORB を初期化
ORB orb = ORB.init(args, prop);
// Bootstrap オブジェクトを作成
Tobj_Bootstrap bs=new Tobj_Bootstrap(orb,host_port);
// SecurityCurrent を取得
org.omg.CORBA.Object ocur =
bs.resolve_initial_references("SecurityCurrent");
SecurityLevel2.Current cur =
SecurityLevel2.CurrentHelper.narrow(ocur);
}
catch (Tobj.InvalidName e) {
System.out.println("Invalid name: "+e);
System.exit(1);
}
catch (Tobj.InvalidDomain e) {
System.out.println("Invalid domain address: "+host_port +" "+e);
System.exit(1);
}
catch (SystemException e) {
System.out.println("Exception getting security current: "+e);
e.printStackTrace();
System.exit(1);
}
}
}
Visual Basic クライアントの例: Bootstrap オブジェクトの使用
リスト 4-5 は、Bootstrap オブジェクトを使用する Visual Basic クライアントのプログラミング方法を示しています。
リスト 4-5 Visual Basic クライアントのプログラミング
'Bootstrap オブジェクトを宣言
Public oBootstrap As DITobj_Bootstrap
'FactoryFinder オブジェクトを宣言
Public oBsFactoryFinder As DITobj_FactoryFinder
'Registrar オブジェクトのファクトリを宣言
Public oRegistrarFactory As DIUniversityB_RegistrarFactory
'実際の Registrar オブジェクトを宣言
Public oRegistrarFactory As DIUniversityB_RegistrarFactory
....
'Bootstrap オブジェクトを作成
Set oBootstrap = CreateObject("Tobj.Bootstrap")
'BEA Tuxedo ドメインに接続
oBootstrap.Initialize "//host:port"
'BEA Tuxedo ドメインの FactoryFinder を取得
Set oBSFactoryFinder = oBootstrap.CreateObject("Tobj.FactoryFinder")
'Registrar オブジェクトのファクトリを取得
'using the FactoryFinder method find_one_factory_by_id
Set oRegistrarFactory = oBSFactoryFinder.find_one_factory_by_id("RegistrarFactoryID")
'Registrar オブジェクトを作成
Set oRegistrar = oRegistrarFactory.find_registrar(exc)
インターオペラブル・ネーミング・サービス・ブートストラップ処理メカニズム
ここでは、次の内容について説明します。
はじめに
リリース 8.0 以降の BEA Tuxedo ORB では、CORBA 仕様 2.4.2 の第 4 章と第 13 章で規定されている CORBA ネーミング・サービス (このマニュアルではインターオペラブル・ネーミング・サービスと呼ぶ) ブートストラップ処理メカニズムがサポートされています。
このサポートにより、インターオペラブル・ネーミング・サービス (INS) ブートストラップ処理メカニズムをインプリメントする ORB で、BEA Tuxedo サーバ側 ORB に問い合わせて初期オブジェクト (FactoryFinder など) および BEA Tuxedo 環境に対する PrincipalAuthenticator のオブジェクト・リファレンスを取得できます。このサポートと、インターオペラブル初期オブジェクト・リファレンスのクライアント・サポートにより、クライアントでは BEA ブートストラップ処理メカニズムではなく INS ブートストラップ処理メカニズムを使用できます。
注記 BEA Tuxedo ソフトウェアに付属の CORBA C++ クライアントおよび Java クライアントでは INS ブートストラップ処理メカニズムを使用できますが、性能上の理由により推奨はできません。
INS オブジェクト・リファレンス
表 4-7 は、各 ID で返されるオブジェクト・リファレンスを示しています。
INS コマンド行オプション
リリース 8.0 以降の BEA Tuxedo CORBA では、-ORBInitRef および -ORBDefaultInitRef コマンド行オプションがサポートされています。これらのオプションの詳細については、ORB 初期化メンバ関数を参照してください。
次の例は、BEA Tuxedo CORBA IIOP クライアントが BEA Tuxedo CORBA IIOP サーバ環境と通信しているものと想定しています。
client_app -ORBid BEA_IIOP -ORBInitRef
FactoryFinder=corbaloc::myhost:2468/FactoryFinder
この例で、FactoryFinder の ORB::resolve_initial_references を呼び出すと、インターオペラブル初期リファレンスの要求がポート 2468 を使用して myhost の ISL/ISH に送信されます。myhost は、tuxconfig ファイルで ISL/ISH に指定されたホストと大文字と小文字の区別まで正確に同じでなければなりません。
INS 初期化オペレーション
INS ブートストラップ処理メカニズムを使用するには、アプリケーション・プログラマは以下の要件を満たす必要があります。
Tobj_Bootstrap::resolve_initial_references 関数ではなく ORB::resolve_initial_references 関数を呼び出す必要があります。ORB::resolve_initial_references の構文の説明については、第 14 章の 79 ページ「CORBA::ORB::resolve_initial_references」を参照してください。注記 Tobj_Bootstrap API は依然としてサポートされており、その振る舞いは従来のまま変更されていません。
Tobj_Bootstrap::list_initial_services 関数ではなく ORB::list_initial_services 関数を使用する必要があります。ORB::list_initial_services の構文の説明については、CORBA::ORB::list_initial_servicesを参照してください。INS オブジェクトの URL スキーマ
リリース 8.0 以降の BEA Tuxedo CORBA では、BEA Tuxedo CORBA サーバ環境にアクセスし、初期オブジェクトのリファレンスを取得するための位置を指定するために使用する追加の Uniform Resource Locator (URL) 形式がサポートされています。その新しい URL 形式は、INS 仕様の一部として OMG で採用されたオブジェクト URL の定義に従うとともに、それを拡張します。INS 仕様で規定されている URL 形式は、BEA WebLogic Enterprise バージョン 5.1 で導入されたランダマイズ機能だけでなく、セキュア HTTP の URL に基づいてモデル化される安全な形式をサポートするようにも拡張されています。
CORBA 2.4.2 仕様は、仕様に準拠する ORB が 3 つのオブジェクト URL スキーマをサポートすることを要求します。それらのスキーマは、IOR、corbaloc、および corbaname として定義されています。
注記 新しい URL 文字列形式は、ORB::string_to_object 関数にも渡すことができます。
IOR URL スキーマ
IOR スキーマは、IOR:hex_octets という形式の文字列です。スキーマ名は IOR で、「:」の後のテキストは CORBA 仕様で定義されます。IOR URL スキーマは堅牢であり、オブジェクトのリファレンスに使用されるカプセル化された転送情報とオブジェクト・キーからクライアントを切り離します。
corbaloc URL スキーマ
その長さとバイナリ情報のテキスト符号化が原因で、IOR を非電子的な手段で人間同士が交換するのは困難です。corbaloc および corbalocs URL スキーマでは、一般に普及している FTP や HTTP の URL スキーマに似た形式の文字列化されたオブジェクト・リファレンスが提供されます。corbaloc および corbalocs で定義された URL スキーマは、TCP/IP 中心の環境と DNS 中心の環境の両方で簡単に操作されます。corbaloc および corbalocs URL の構成要素は次のとおりです。
デフォルトでは、corbaloc URL は IIOP 経由でアクセスできるオブジェクトを示し、corbalocs URL は IIOP over SSL を使用してアクセスできるオブジェクトを示します。
表 4-8 は、各 URL 要素の BNF 構文を示しています。
表 4-9 は、各 URL 要素を説明しています。
次に、新しい URL 形式の使用例を示します。
corbaloc::555xyz.com:1024,555backup.com:1022,555last.com:1999
corbalocs::555xyz.com:1024,{555backup.com:1022|555last.com:1999}
corbaloc::1.2@555xyz.com:1111
corbalocs::1.1@24.128.122.32:1011,1.0@24.128.122.34
BEA Tuxedo 8.0 では、スキーマの異なる複数の URL のリストをサポートするように、INS の提案で規定されている URL 構文が拡張されています。次に、拡張例を示します。
corbalocs::555xyz.com:1024,corbaloc::1.2@555xyz.com:1111
corbalocs::ctxobj:3434,mthd:3434,corbaloc::force:1111
上の例で、パーサが URL corbaloc::force.com:1111 に達した場合は、安全な接続が試行されなかったかのようにパーサの内部状態がリセットされ、保護なしの接続の試行が開始されます。
corbaname URL スキーマ
corbaname URL スキーマは、URL でネーミング・サービスのエントリを示せるように corbaloc スキーマの機能を拡張します。corbaname URL は、ORB コアにネーミング・サービスのインプリメンテーションがなくても解決できます。corbaname URL の例を次に示します。
corbaname:555objs.com#a/string/path/to/obj
この URL は、ホスト 555objs.com で NamingContext 型のオブジェクト (オブジェクト・キーが NamingService) を見つけることができるか、その位置で動作しているエージェントが NamingContext のリファレンスを返すことを示します。文字列化された名前 a/string/path/to/obj は、その NamingContext の resolve オペレーションの引数として使用されます。
corbaname URL は corbaloc URL と似ていますが、corbaname URL にはネーミング・コンテキストのバインディングを識別する文字列化された名前が含まれます。# 文字は、文字列化された名前の開始を示します。
URL の BNF 構文は、表 4-10 で示してあります。
corbaname URL の解決は、corbaloc URL 処理の単純な拡張としてインプリメントされます。そのインプリメンテーションを説明するために、次の corbaname URL を使用します。
corbaname:<corbaloc_obj>["#"<string_name>]
解決は以下のように行われます。
corbaloc::<corbaloc_obj> 形式の corbaloc URL を作
成します。
CORBA::ORB::string_to_object を呼び出して
CosNaming::NamingContext オブジェクトを取得し、corbaloc URL をネー
ミング・コンテキストのオブジェクト・リファレンスに変換します。
<string_name> を CosNaming::Name に変換します。
CosNaming::Name を渡して、CosNaming::NamingContext の
resolve オペレーションを呼び出します。
CosNaming::NamingContext::resolve から返されるオブジェクト・リファ
レンスは、呼び出し側に返されなければなりません。
この解決プロセスに従うことで、ネーミング・サービスに存在しないネーミング・コンテキストのオブジェクト・リファレンスを返すことがなくなります。この手法の 1 つの副作用は、ネーミング・サービスのスタブが ORB コアの一部であるか、resolve オペレーションの要求を送信する内部メカニズムがなければならないことです。複雑な手間を避けるため、ネーミング・サービスのスタブを ORB コアに埋め込むことをお勧めします。
INS を使用した FactoryFinder オブジェクト・リファレンスの取得
リスト 4-6 は、クライアント・アプリケーションが INS を使用して FactoryFinder オブジェクトのオブジェクト・リファレンスを取得するしくみを示しています。完全なコード例については、University Sample のクライアント・アプリケーションを参照してください。
リスト 4-6 FactoryFinder オブジェクト取得のコード例
// レジストラを取得するユーティリティ
static UniversityW::Registrar_ptr get_registrar(
CORBA::ORB_ptr orb
)
{
// ORB からファクトリ・ファインダを取得
CORBA::Object_var v_fact_finder_oref =
orb->resolve_initial_references("FactoryFinder");
// ファクトリ・ファインダをナロー変換
Tobj::FactoryFinder_var v_fact_finder_ref =
Tobj::FactoryFinder::_narrow(v_fact_finder_oref.in());
// ファクトリ・ファインダを使用して University の
// レジストラ・ファクトリを検索する
CORBA::Object_var v_reg_fact_oref =
v_fact_finder_ref->find_one_factory_by_id(
UniversityW::_tc_RegistrarFactory->id()
);
// レジストラ・ファクトリをナロー変換
UniversityW::RegistrarFactory_var v_reg_fact_ref =
UniversityW::RegistrarFactory::_narrow(
v_reg_fact_oref.in()
);
// University のレジストラを返す
return v_reg_fact_ref->find_registrar();
}
INS を使用した PrincipalAuthenticator オブジェクト・リファレンスの取得
リスト 4-7 は、クライアント・アプリケーションが INS を使用して PrincipalAuthenticator オブジェクトのオブジェクト・リファレンスを取得するしくみを示しています。完全なコード例については、University Sample のクライアント・アプリケーションを参照してください。
リスト 4-7 PrincipalAuthenticator オブジェクト取得のコード例
// セキュリティ・システムにログオンするユーティリティ
static SecurityLevel2::PrincipalAuthenticator_ptr logon(
CORBA::ORB_ptr orb,
const char* program_name,
UniversityW::StudentId stu_id
)
{
// ORB から直接 Principal Authenticator を取得
CORBA::Object_var v_pa_obj =
orb->resolve_initial_references("PrincipalAuthenticator");
// Principal Authenticator をナロー変換
SecurityLevel2::PrincipalAuthenticator_var v_pa =
SecurityLevel2::PrincipalAuthenticator::_narrow(
v_pa_obj.in());
INS を使用した TransactionFactory オブジェクト・リファレンスの取得
リリース 8.0 以降の BEA Tuxedo CORBA では、CORBA トランザクション・サービス・インターフェイスを使用してトランザクションを開始できます。クライアントは、ORB::resolve_initial_references("FactoryFinder") 関数を使用して FactoryFinder のオブジェクト・リファレンスを取得します。次にクライアントは、FactoryFinder を使用して (トランザクションの開始に使用する) TransactionFactory のリファレンスを取得します。
リスト 4-8 は、クライアント・アプリケーションが INS を使用して TransactionFactory オブジェクトのオブジェクト・リファレンスを取得するしくみを示しています。完全なコード例については、University Sample のクライアント・アプリケーションを参照してください。
リスト 4-8 INS を使用したクライアント・アプリケーションのコード例
// ORB からファクトリ・ファインダを取得
CORBA::Object_var v_fact_finder_oref =
orb->resolve_initial_references("FactoryFinder");
// ファクトリ・ファインダをナロー変換
Tobj::FactoryFinder_var v_fact_finder_ref =
Tobj::FactoryFinder::_narrow(v_fact_finder_oref.in());
// FactoryFinder から TransactionFactory を取得
CORBA::Object_var v_txn_fac_oref =
v_fact_finder_ref->find_one_factory_by_id(
"IDL:omg.org/CosTransactions/TransactionFactory:1.0");
// TransactionFactory オブジェクト・リファレンスをナロー変換
CosTransactions::TransactionFactory_var v_txn_fac_ref =
CosTransactions::TransactionFactory::_narrow(
v_txn_fac_oref.in());
INS ブートストラップ処理メカニズムを使用したイベントのシーケンスは次のとおりです。
ORB::resolve_initial_references を使用して FactoryFinder を取得しま
す。
get_terminator メソッドを使用してトランザクションの Terminator イン
ターフェイスを取得します。
TransactionFactory は、BEA の委譲型インターフェイスではなく、標準の CORBA のトランザクション・サービス・インターフェイスに準拠したオブジェクトを返します。これは、サード・パーティの ORB が、それぞれの ORB の resolve_initial_references 関数を使用して BEA Tuxedo CORBA サーバから TransactionFactory のリファレンスを取得し、標準 OMG IDL で生成されたスタブを使用して、返されたインスタンス上で機能できることを意味します。
制限
BEA Tuxedo 8.0 リリースでは、TransactionFactory とクライアントの Current のアクションが調整されません。つまり、クライアントでは 2 つのメカニズムのいずれかを使用してトランザクションのステータスを管理および取得する必要があります。また、インターフェイスとオペレーションは表 4-11 で示されているものしかサポートされていません。OMG IDL で規定されているほかのオペレーションでは、CORBA::NO_IMPLEMENT 例外が返されます。
|
|
|
|
|
|
Copyright © 2001, BEA Systems, Inc. All rights reserved.
|