| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo CORBA ノーティフィケーション・サービス > CORBA ノーティフィケーション・サービス API のリファレンス |
|
Tuxedo CORBA ノーティフィケーション・サービス
|
CORBA ノーティフィケーション・サービス API のリファレンス
ここでは、以下の内容について説明します。
はじめに
BEA Tuxedo CORBA ノーティフィケーション・サービスでは、2 つのアプリケーション・プログラミング・インターフェイスがサポートされます。1 つは、「CORBAservices: Common Object Services Specification」で定義されている CORBA ベースのノーティフィケーション・サービスに基づいています。このインターフェイスは、このマニュアルでは CosNotification サービス・インターフェイスと呼びます。もう 1 つのインターフェイス (BEA シンプル・イベント・インターフェイス) は、使いやすく設計された BEA 独自のインターフェイスです。
それらのインターフェイスは互いに互換性があり、どちらも CORBA ベースのノーティフィケーション・サービス仕様で定義された構造化イベントを渡します。つまり、CosNotification サービス・インターフェイスを使用してポストされたイベントは BEA シンプル・イベント・インターフェイスでサブスクライブできるということです (逆方向も可)。
ノーティフィケーション・サービス API を使用する前に、次のトピックに目を通してください。
サービスの品質
サブスクリプションが永続的かどうか、およびイベント配信の失敗後に配信が再試行されるかどうかを指定するために、サブスクライバではサービスの品質 (QoS) を指定します。サービスの品質には、永続的と一時的の 2 つの設定があります。QoS は、サブスクリプションのプロパティです。
永続的なサブスクリプション
永続的なサブスクリプションでは、イベントの配信とサブスクリプションの永続性が強固に保証されます。ただし、システム・リソース (ディスク領域や CPU サイクルなど) がより多く消費されるとともに、より多くの管理タスク (キューの管理やデッド・サブスクライバの検出など) が必要になります。
永続的なサブスクリプションには以下の特性があります。
一時的なサブスクリプション
一時的なサブスクリプションでは、最小限のオーバーヘッドで最高の性能が実現します。一時的なサブスクリプションには、次の特性があります。
サブスクリプションは、イベント配信の失敗が検出されるまで有効です。配信の失敗が検出された時点で、サブスクリプションは終了します。通常、ノーティフィケーション・サービスでは、性能上の理由のために一時的なサブスクライバに正常にイベントが配信されたかどうかが確認されません。ただし、イベントを一時的なサブスクライバに配信する場合に、ノーティフィケーション・サービスで配信が成功したかどうかが確認されることもあります。イベントが正常に配信されず、CORBA::TRANSIENT 例外が返されないときは、ノーティフィケーション・サービスではサブスクリプションが無くなったものと判断し、サブスクリプションを取り消します。配信が失敗して CORBA::TRANSIENT 例外を受信した場合、ノーティフィケーション・サービスではサブスクライバがビジー状態であると判断してイベントを破棄しますが、サブスクリプションは取り消されません。
デッド状態の一時的なサブスクリプションの自動的な取り消しでは、アンサブスクライブされていない一時的なサブスクライバのクリーンアップ・メカニズムが提供されます。ただし、ノーティフィケーション・サービスによる配信の確認はイベントがサブスクライバに最初に送信されたときに行われますが、それから 5 分が経過し、別のイベントが配信されるまでは次の確認は行われません。したがって、確認が実行される間隔は短くて 5 分であり、5 分経過後に配信するイベントがない場合その間隔はさらに長くなります。5 分という最短の間隔は固定であり、変更することはできません。このため、イベント配信の失敗は必ずしも最初の失敗の時点で検出されるわけではありません。イベント配信の失敗は、ノーティフィケーション・サービスで確認が行われたときにのみ検出されます。
チャネル・ファクトリの取得
チャネル・ファクトリは、イベント・チャネルを探すためにイベント・ポスト元のアプリケーションとサブスクライバ・アプリケーションによって使用されます。イベント・チャネルは、イベントのポスト、サブスクリプションのサブスクライブ (作成)、およびサブスクリプションのアンサブスクライブ (取り消し) に使用します。
ノーティフィケーション・サービス・アプリケーションでは、Bootstrap オブジェクトを使用してイベント・チャネル・ファクトリのオブジェクト・リファレンスを取得します。その際には、Tobj_Bootstrap::resolve_initial_references オペレーションが使用されます。Bootstrap オブジェクトでは、ノーティフィケーション・サービス・アプリケーションの 2 つのサービス ID (NotificationService および Tobj_SimpleEventsService) がサポートされています。NotificationService オブジェクトは、CosNotification サービス API を使用するアプリケーションで使用します。Tobj_SimpleEventsService オブジェクトは、BEA シンプル・イベント API を使用するアプリケーションで使用します。
注記 リリース 8.0 の BEA Tuxedo CORBA には、BEA WebLogic Enterprise の旧バージョンで提供されていた BEA クライアント環境オブジェクトが従来のまま含まれており、Tuxedo 8.0 CORBA クライアントで利用することができます。BEA Tuxedo 8.0 クライアントでは、ブートストラップ処理オブジェクト、セキュリティ・オブジェクト、およびトランザクション・オブジェクトの初期リファレンスの解決に引き続きそれらの環境オブジェクトを使用する必要があります。リリース 8.0 の BEA Tuxedo CORBA では、OMG インターオペラブル・ネーミング・サービス (INS) を使用してもブートストラップ処理オブジェクト、セキュリティ・オブジェクト、およびトランザクション・オブジェクトの初期リファレンスを解決できます。INS の詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』
トランザクションの使い方
トランザクションに関する振る舞いは、BEA シンプル・イベント API と CosNotification サービス API で同じです。トランザクションの振る舞いをサポートする唯一のオペレーションは push_structured_event です。このオペレーションは、CosNotifyChannelAdmin::StructuredProxyPushConsumer インターフェイスと Tobj_SimpleEvents::Channel インターフェイスでサポートされています。ほかのすべてのオペレーションは、トランザクションのコンテキストで使用できますが、トランザクションで実行されても、それ以外で実行されても同じように機能します。
イベントをポストするときの振る舞いは、サブスクリプションの QoS に依存します。サブスクリプションのイベント配信 QoS が永続的である場合に、イベントがトランザクションのコンテキストでポストされると、その配信はトランザクションの結果に左右されます。つまり、トランザクションがコミットされる場合、ノーティフィケーション・サービスでは通常どおりにサブスクライバにイベントが配信されます。トランザクションがロールバックされる場合は、イベントは配信されません。
サブスクライバのサブスクリプションのイベント配信 QoS が一時的である場合に、イベントがトランザクションのコンテキストでポストされると、トランザクションの結果に関係なくそのイベントの配信が 1 度試行されます。つまり、トランザクションはイベントが配信されるかどうかに影響を与えず、イベントの配信が 1 度試行されます。
注記 イベントの配信に関連付けられるトランザクション・コンテキストはありません。ただし、永続的なサブスクリプションの場合は、ポスト元のトランザクションがコミットされたときには、イベントがサブスクライバに配信されるか、管理上のアクションを待つためにエラー・キューに入れられることがノーティフィケーション・サービスによって保証されます。
構造化イベントのフィールド、型、およびフィルタ
ポスト元からノーティフィケーション・サービスにプッシュされるか、サブスクライバに配信されるイベントはすべて COS 構造化イベントです。つまり、すべてのイベントは CORBA ベースのノーティフィケーション・サービスで指定されている構造化イベントの定義に適合しています。CORBA ベースのノーティフィケーション・サービスは、CORBAservices イベント・サービスを拡張したサービスです (図2-1 を参照)。イベントが (ドメインや型ではなく) 内容に基づいてフィルタ処理される場合、またはイベントが BEA Tuxedo アプリケーションによってサブスクライブされる場合は、適用される制限が増えます。それらの制限は、データ型、および内容に基づくフィルタ処理に適用されます。次に、それらの制限について説明します。
図 2-1 構造化イベント
イベントの設計
イベントの設計は、あらゆるノーティフィケーション・サービスの基本です。イベントの設計は、一致するサブスクリプションに配信される情報の量だけでなく、ノーティフィケーション・サービスの効率と性能にも影響します。したがって、計画を慎重に行って、ノーティフィケーション・サービスが現在のニーズだけでなく将来の規模拡大にも対応できるようにする必要があります。
ノーティフィケーション・サービスでは、(1) ドメイン名、(2) 型名、(3) 優先順位、(4) フィルタ処理可能データ、および (5) 残りの本文の 5 段階のイベント設計がサポートされています。イベントを設計するときには、ドメイン名と型名を指定する必要があります (優先順位とフィルタ処理可能データは任意指定)。ドメイン名は、ビジネスに基づいて選択することができます。たとえば病院は医療ビジネス (health care business) に属しているので、病院のノーティフィケーション・サービス・アプリケーションでは「HEALTHCARE」をドメイン名として選択できます。保険業者の種類に基づいてイベントを分類する必要がある場合は、「HMO」または「UNINSURED」を型名として選択できます。支払い義務のあるエンティティを基準にイベントをさらに細かく定義する必要がある場合は、フィルタ処理可能データを使用して、特定の "HMO_Account" または特定の "Patient_Account" に対する "billing" としてエンティティを識別することも可能です。リスト2-1 は、このタイプのイベント設計の例を示しています。
コード リスト 2-1 イベントの設計
domain_name = “HEALTHCARE”
type_name = “HMO”
#Filterable data name/value pairs.
filterable_data.name = “billing”
filterable_data.value = 4498
filterable_data.name = “patient_account”
filterable_data.value = 37621
当然、ノーティフィケーション・サービス・アプリケーションでポストおよび受信されるイベントの設計が詳細かつ厳密になればなるほど、ノーティフィケーション・サービスで処理しなければならないイベントの数が少なくなります。このことは、システム・リソースとコンフィギュレーションの要件に直接的に影響します。したがって、イベントを設計するときには十分な考慮が必要です。
イベントの FML フィールド・テーブル・ファイルの作成
イベントのフィールド操作言語 (FML) フィールド・テーブル・ファイルは、次の機能のいずれかが必要な場合のみ作成する必要があります。どの機能も必要でない場合は、FML テーブルは不要です。
構造化イベントの filterable_data フィールドには、名前/値 (NV) ペアのリストが格納されます。イベントのデータは通常はこのリストに格納されます。FML フィールド・テーブル・ファイルのフィールド名は、構造化イベント内の名前と一致していなければなりません。フィールドの型には、carray を除くすべての FML 型 (long、short、double、float、char、string) を使用できます。構造化イベントの値は、フィールド・テーブルで定義されている型と同じでなければなりません。表 2-1 は、BEA Tuxedo でサポートされている CORBA Any 型を示しています。これらの Any 型を使用して、データのフィルタ処理と BEA Tuxedo の相互運用性を実現できます。
リスト2-2 は、FML フィールド・テーブル・ファイルの例です。*base 2000 は、フィールドのベース番号です。最初のエントリでは、フィールド名が billing、フィールド番号が 1 (ベース番号に基づく値)、フィールドの型が long となっています。 コード リスト 2-2 データ・フィルタ処理の FML フィールド・テーブル・ファイル BEA Tuxedo の FML フィールド・テーブル・ファイルには、次のガイドラインと制限が適用されます。
*base 2000
#Field Name Field # Field Type Flags Comments
#----------- ------- ---------- ------ --------
billing 1 long - -
stock_name 2 string - -
price_per_share 3 double - -
number_of_shares 5 long - -
FML フィールド・テーブル・ファイルの作成とコンフィギュレーションの方法については、『BEA Tuxedo コマンド・リファレンス』の「field_tables」および『FML を使用した BEA Tuxedo アプリケーションのプログラミング』を参照してください。
BEA Tuxedo アプリケーションとの相互運用性
BEA Tuxedo CORBA ノーティフィケーション・サービスを使用するアプリケーションは、BEA Tuxedo EventBroker を使用する BEA Tuxedo アプリケーションと相互運用できます。BEA Tuxedo ノーティフィケーション・サービスを使用するアプリケーションでは、BEA Tuxedo EventBroker のサブスクライバに配信されるイベントをポストでき、BEA Tuxedo EventBroker によってポストされたイベントを受信できます。
この相互運用性を実現するには、BEA Tuxedo で FML フィールド・テーブルの内容を調整できるように、CosNotification 構造化イベントと BEA Tuxedo FML バッファのマッピングを理解する必要があります。考慮すべき状況は 2 つあります。BEA Tuxedo EventBroker を介して BEA Tuxedo アプリケーションによって受信されるイベントのポストと、BEA Tuxedo アプリケーションによってノーティフィケーション・サービスのイベント・チャネルにポストされたイベントの受信です。
イベントのポスト
BEA Tuxedo アプリケーションによってポストされたイベントを BEA Tuxedo アプリケーションでサブスクライブするには、BEA Tuxedo 構造化イベントがポスト時にどのように FML32 およびイベント名にマッピングされるのかを理解する必要があります。マッピングは次のように行われます。
イベントの受信
BEA Tuxedo のシステム・イベントとユーザ・イベントは、BEA Tuxedo アプリケーションで受信できます。システム・イベントを生成するのは、アプリケーションではなく、BEA Tuxedo システムです。ユーザ・イベントは、BEA Tuxedo アプリケーションによって生成されます。システム・イベントのリストについては、『BEA Tuxedo コマンド・リファレンス』の「EVENTS」を参照してください。システム・イベントとユーザ・イベントは、CosNotification 構造化イベントで次のようにマッピングされます。
BEA Tuxedo システムでは、システムの警告と障害に関連する定義済みの特定のイベントが検出されてポストされます。たとえば、システム生成のイベントでは、コンフィギュレーションの変更、状態の変化、接続の障害、およびマシンの分断が報告されます。 BEA Tuxedo アプリケーションによってポストされたイベントを BEA Tuxedo アプリケーションで受信するには、BEA Tuxedo イベントが格納されている FML バッファをどのように使用して BEA Tuxedo 構造化イベントが作成されるのかを理解する必要があります。また、domain_name と type_name の BEA Tuxedo イベント名との関連を理解することも必要です。システム・イベントとユーザ・イベントの 2 つのケースを考慮する必要があります。 BEA Tuxedo では、イベント名の先頭にドット (.) を使用してシステム生成のイベントをアプリケーション定義のイベントから区別します。たとえば、システム・イベントには .SysNetworkDropped があります。ユーザ・イベントの例としては、eventsdropped があります。それらのイベントをサブスクライブするために、ノーティフィケーション・サービスのサブスクライバ・アプリケーションではサブスクリプションを次のように定義する必要があります。
domain_name =“TMEVT”
type_name=“.SysNetworkDropped”
domain_name =“TMEVT”
type_name=“eventsdropped”
イベントが受信されると、ノーティフィケーション・サービスのサブスクライバ・アプリケーションで各イベントが次のように解析されます。
domain_name=” TMEVT”
type_name=” ”
event_name=” ”
variable_header=empty
Filterable_data=(FML バッファの内容)
サブスクリプションの作成時に使用するパラメータ
サブスクリプションを作成するときには、次のパラメータを指定できます。これらのパラメータでは、BEA のシンプル・イベント API と CosNotification サービス API がサポートされています。
データのフィルタ処理を利用するには、FML テーブルを設定し、サブスクリプションにフィルタを含めて、データをフィルタ処理し、イベントをポストします。リスト2-3 は、それらのタスクの例を示しています。
コード リスト 2-3 データのフィルタ処理の要件
//FML テーブルを設定
Field table file.
----------------
*base 2000
*Field Name Field # Field Type Flags Comments
----------- ------- --------- ------ ------
StockName 1 string - -
PricePerShare 2 double - -
CustomerId 3 long - -
CustomerName 4 string - -
//サブスクリプション・データのフィルタ処理
1) "NumberOfShares > 100 && NumberOfShares < 1000"
2) "CustomerId == 3241234"
3) "PricePerShare > 125.00"
4) "StockName == 'BEAS'"
5) "CustomerName %% '.*Jones.*'" // CustomerName が「Jones」を格納
6) "StockName == 'BEAS' && PricePerShare > 150.00"
//イベントをポスト
// C++
CosNotification::StructuredEvent ev;
...
ev.filterable_data[0].name = CORBA::string_dup("StockName");
ev.filterable_data[0].value <<= "BEAS";
ev.filterable_data[1].name = CORBA::string_dup("PricePerShare");
ev.filterable_data[1].value <<= CORBA::Double(175.00);
ev.filterable_data[2].name = CORBA::string_dup("CustomerId");
ev.filterable_data[2].value <<= CORBA::Long(1234567);
ev.filterable_data[3].name = CORBA::string_dup("CustomerName");
ev.filterable_data[3].value <<= "Jane Jones";
// Java
StructuredEvent ev;
...
ev.filterable_data[0].name = "StockName";
ev.filterable_data[0].value.insert_string("BEAS");
ev.filterable_data[1].name = "PricePerShare";
ev.filterable_data[1].value.insert_double(175.00);
ev.filterable_data[2].name = "CustomerId";
ev.filterable_data[2].value.insert_long(1234567);
ev.filterable_data[3].name = "CustomerName";
ev.filterable_data[3].value.insert_string("Jane Jones");
注記 一時的または永続的のいずれかのオブジェクト・リファレンスをコールバック・オブジェクトとして使用できます。どのタイプのオブジェクト・リファレンスを使用するのかを決めるときには、QoS とアプリケーションの実行回数の両方を考慮に入れる必要があります。使用するオブジェクト・リファレンスのタイプを決める際の参考情報については、表 2-3 を参照してください。
注記 永続的なサブスクリプションの場合、ノーティフィケーション・サービスでは常にコールバック・オブジェクトを二方向で呼び出してイベントを配信します。共同クライアント/サーバが orb->run を呼び出す前にコールバック・オブジェクト (イベントの受信側) をアクティブにしない状況で、ノーティフィケーション・サービスがコールバック・オブジェクトを呼び出した場合、POA に関する限り、コールバック・オブジェクトは存在しません。この場合は、CORBA::OBJECT_NOT_EXIST 例外が返されます。CORBA::OBJECT_NOT_EXIST 例外を受信した場合、ノーティフィケーション・サービスではサブスクリプションとイベントを削除します。その例外を受信しない場合は、サブスクリプションは維持され、イベントは再試行されます。
BEA シンプル・イベント API
単純さと使いやすさが、BEA シンプル・イベント・アプリケーション・プログラミング・インターフェイス (API) の特徴と言えます。その機能は、BEA Tuxedo EventBroker の機能と似ています。
BEA シンプル・イベント API は、次のインターフェイスで構成されます (図2-2 を参照)。
図 2-2 BEA シンプル・イベント・インターフェイス
Tobj_SimpleEvents::Channel インターフェイスと Tobj_SimpleEvents::ChannelFactory インターフェイスは、ノーティフィケーション・サービスによってインプリメントされます (説明は後述)。
CosNotifyComm::StructuredPushConsumer インターフェイスは、サブスクライバによってインプリメントされます。このインターフェイスの説明については、第 2 章の 71 ページ「CosNotifyComm::StructuredPushConsumer::push_structured_event」を参照してください。
注記 この節で言及されている CosNotification サービスのクラスは、tuxdir¥include ディレクトリにある CosNotification サービス IDL ファイルで完全に記述されています。
注記 サポートされていないクラス・オペレーションを使用すると、CORBA::NO_IMPLEMENT 例外が発生します。
TOBJ_SimpleEvents::Channel インターフェイス
Channel インターフェイスは次のように使用されます。
このインターフェイスには、次のオペレーションがあります。
このインターフェイスの CORBA IDL は次のとおりです。
module Tobj_SimpleEvents
{
typedef long SubscriptionID;
typedef string RegularExpression;
typedef string FilterExpression;
const SubscriptionType TRANSIENT_SUBSCRIPTION = 0;
const SubscriptionType PERSISTENT_SUBSCRIPTION = 1;
interface Channel
{
void push_structured_event(
in CosNotification::StructuredEvent event);
SubscriptionID subscribe (
in string subscription_name,
in RegularExpression domain,
in RegularExpression type,
in FilterExpression data_filter,
in CosNotification::QoSProperties qos,
in CosNotifyComm::StructuredPushConsumer push_consumer);
boolean exists( in SubscriptionID id );
void unsubscribe( in SubscriptionID id );
};
};
これらのオペレーションについては、次の節を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
