|
|
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 を使用するアプリケーションで使用します。
サービス ID |
オブジェクト型 |
---|---|
|
|
|
|
注記 リリース 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 構造化イベント
any
、long
、unsigned long
、short
、unsigned short
、octet、char
、float
、double
、string
、boolean
、void
、および null
に制限されています。これらのフィールドは、フィルタ式で使用できます。ANY
です。値の型は、any
、long
、unsigned long
、short
、unsigned short
、octet、char
、float
、double
、string
、boolean
、void
、および null
に制限されています。このフィールドは、フィルタ式で使用できません。イベントの設計
イベントの設計は、あらゆるノーティフィケーション・サービスの基本です。イベントの設計は、一致するサブスクリプションに配信される情報の量だけでなく、ノーティフィケーション・サービスの効率と性能にも影響します。したがって、計画を慎重に行って、ノーティフィケーション・サービスが現在のニーズだけでなく将来の規模拡大にも対応できるようにする必要があります。
ノーティフィケーション・サービスでは、(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 の相互運用性を実現できます。
CORBA Any 型 |
データのフィルタ処理と Tuxedo の相互運用性のサポート |
---|---|
|
あり |
|
あり |
|
なし |
|
なし |
|
あり |
|
あり |
|
あり |
|
なし |
|
なし |
|
あり |
|
なし |
|
なし |
|
なし |
リスト 2-2 は、FML フィールド・テーブル・ファイルの例です。*base 2000
は、フィールドのベース番号です。最初のエントリでは、フィールド名が billing
、フィールド番号が 1
(ベース番号に基づく値)、フィールドの型が long
となっています。
リスト 2-2 データ・フィルタ処理の 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 - -
BEA Tuxedo の FML フィールド・テーブル・ファイルには、次のガイドラインと制限が適用されます。
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 およびイベント名にマッピングされるのかを理解する必要があります。マッピングは次のように行われます。
domain_name.type_name
という形式にまとめられます。これは、tppost
オペレーションで使用されるイベント名 (eventname パラメータ) です。"TMEVT"
に設定した場合、イベント名は型名と同じになります。イベントの受信
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 がサポートされています。
subscription_name
ノーティフィケーション・サービスのサブスクリプションとサブスクライバを識別する名前を指定します。アプリケーションでは、システム管理者にとって意味のある名前を使用しなければなりません。なぜならこれが、管理者がアプリケーションとサブスクリプション、およびそのサブスクリプションを介してサブスクライバに配信されるイベントを関連付ける主要な手段だからです。このパラメータはオプションです (つまり、空の文字列を渡すことができる)。複数のサブスクリプションで同じ名前を使用できます。
subscription_name
の長さは最大で 128 文字です。
domain_type
CORBA ベースのノーティフィケーション・サービス仕様で定義されている、構造化イベントの Fixed ヘッダ部分の domain_type
フィールドと同じパラメータです。このフィールドは、「Telecommunications」、「Finance」、および「Health Care」など、イベントの型が定義されている特定垂直産業のドメインを識別する文字列です。このパラメータは正規表現なので、フィルタ処理の基準となるドメイン・パターンを設定するために使用することもできます。たとえば、文字 F で始まるすべてのドメインをサブスクライブするには、ドメインを「F.*
」に設定します。正規表現を作成する方法については、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』で recomp
コマンドを参照してください。
type_name
CORBA ベースのノーティフィケーション・サービス仕様で定義されている、構造化イベントの Fixed ヘッダ部分の type_name
フィールドと同じパラメータです。これは、Comm_alarm、StockQuote、VitalSigns など、ドメイン内で一意にイベントの型を分類する文字列です。このパラメータは正規表現なので、フィルタ処理の基準となるイベントの型のパターンを設定するために使用することもできます。たとえば、文字 F で始まるすべてのイベントの型をサブスクライブするには、型を「F.*
」に設定します。正規表現を作成する方法については、『BEA Tuxedo CORBA サーバ・アプリケーションの開発方法』で recomp
コマンドを参照してください。
data_filter
フィルタ処理が行われるフィルタ処理可能データと Variable ヘッダのフィールドの値を指定します。たとえば、ニュース記事のサブスクリプションでは、ドメインが「News」、型が「Sports」、そして data_filter が「Scores > 20」になる場合が考えられます。
このパラメータでは、論理式でサブスクリプションが一致しなければならないデータを定義します。サポートされているデータ型は、short
、long
、char
、float
、double
、および string
です。表 2-2 は、サポートされている論理式の演算子を示しています。
式 |
演算子 |
---|---|
単項 |
+, -, !, |
倍数 |
*, /, % |
加法 |
+, - |
比較 |
< , >, <=, >=, ==, != |
等価、一致 |
==, !=, %%, !% |
排他論理和 |
^ |
論理積 |
&& |
論理和 |
|| |
データのフィルタ処理を利用するには、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");
フィルタの文法の詳細については、イベントの FML フィールド・テーブル・ファイルの作成および『FML を使用した BEA Tuxedo アプリケーションのプログラミング』の「フィールド化バッファの論理式」を参照してください。
push_consumer
ノーティフィケーション・サービスで構造化イベントを配信するために使用されるコールバック・オブジェクトを識別します。サブスクライバ・アプリケーションでは、ノーティフィケーション・サービスから呼び出してイベントを配信できるように CosNotifyComm::StructuredPushConsumer インターフェイスをインプリメントする必要があります。
注記 一時的または永続的のいずれかのオブジェクト・リファレンスをコールバック・オブジェクトとして使用できます。どのタイプのオブジェクト・リファレンスを使用するのかを決めるときには、QoS とアプリケーションの実行回数の両方を考慮に入れる必要があります。使用するオブジェクト・リファレンスのタイプを決める際の参考情報については、表 2-3 を参照してください。
qos
(サービスの品質)
サブスクリプションのサービスの品質を指定します。一時的または永続的のいずれかを指定できます。
一時的なサブスクリプションの場合、ノーティフィケーション・サービスではサブスクライバへのイベント配信が 1 回だけ試行されます。その試行が失敗した場合は、イベントは破棄されます。ノーティフィケーション・サービスに CORBA::TRANSIENT
例外が届かない場合は、サブスクライバがシャットダウンしているかほかの理由で利用できないと判断され、サブスクリプションが取り消されます。配信が失敗して CORBA::TRANSIENT
例外を受信した場合、ノーティフィケーション・サービスではサブスクライバがビジー状態であると判断してイベントを破棄しますが、サブスクリプションは取り消されません。
永続的なサブスクリプションの場合、配信の最初の試行が失敗すると、ノーティフィケーション・サービスではそのイベントが保留キューに保持され、コンフィギュレーション可能な再試行回数の上限に達するまでサブスクリプションの配信が繰り返されます。再試行回数の上限に達すると、イベントはエラー・キューに移動されます。エラー・キューに保持されたイベントは、システム管理者によって処理されます。システム管理者は、エラー・キューからイベントを削除するか (事実上の破棄)、または再び配信できるように保留キューに戻します。
注記 永続的なサブスクリプションの場合、ノーティフィケーション・サービスでは常にコールバック・オブジェクトを二方向で呼び出してイベントを配信します。共同クライアント/サーバが orb->run
を呼び出す前にコールバック・オブジェクト (イベントの受信側) をアクティブにしない状況で、ノーティフィケーション・サービスがコールバック・オブジェクトを呼び出した場合、POA に関する限り、コールバック・オブジェクトは存在しません。この場合は、CORBA::OBJECT_NOT_EXIST
例外が返されます。CORBA::OBJECT_NOT_EXIST
例外を受信した場合、ノーティフィケーション・サービスではサブスクリプションとイベントを削除します。その例外を受信しない場合は、サブスクリプションは維持され、イベントは再試行されます。
BEA シンプル・イベント API
単純さと使いやすさが、BEA シンプル・イベント・アプリケーション・プログラミング・インターフェイス (API) をの定義特性です。その機能は、BEA Tuxedo EventBroker の機能と似ています。
BEA シンプル・イベント API は、次のインターフェイスで構成されます (図 2-2 を参照)。
Tobj_SimpleEvents::Channel
Tobj_SimpleEvents::ChannelFactory
CosNotifyComm::StructuredPushConsumer
図2-2 BEA シンプル・イベント・インターフェイス
Tobj_SimpleEvents::Channel
インターフェイスと Tobj_SimpleEvents::ChannelFactory
インターフェイスは、ノーティフィケーション・サービスによってインプリメントされます (説明は後述)。
CosNotifyComm::StructuredPushConsumer
インターフェイスは、サブスクライバによってインプリメントされます。このインターフェイスの説明については、CosNotifyComm::StructuredPushConsumer::push_structured_eventを参照してください。
注記 この節で言及されている CosNotification サービスのクラスは、tuxdir
\include
ディレクトリにある CosNotification サービス IDL ファイルで完全に記述されています。
注記 サポートされていないクラス・オペレーションを使用すると、CORBA::NO_IMPLEMENT
例外が発生します。
TOBJ_SimpleEvents::Channel インターフェイス
Channel インターフェイスは次のように使用されます。
このインターフェイスには、次のオペレーションがあります。
subscribe()
unsubscribe()
exists()
push_structured_event()
このインターフェイスの 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 );
};
};
これらのオペレーションについては、次の節を参照してください。
Channel::subscribe
CORBA IDL
SubscriptionID subscribe (
in string subscription_name,
in RegularExpression domain,
in RegularExpression type,
in FilterExpression data_filter,
// フィルタ式の長さは 1 で、名前は TRANSIENT_SUBSCRIPTION
// または PERSISTENT_SUBSCRIPTION でなければならない
in CosNotification::QoSProperties qos,
in CosNotifyComm::StructuredPushConsumer push_consumer
);
パラメータ
このオペレーションでサポートされているパラメータの説明については、サブスクリプションの作成時に使用するパラメータを参照してください。
例外
CORBA::BAD_PARAM
次のいずれかの問題を示します。Tobj_Events::SUB_INVALID_FILTER_EXPRESSION
Tobj_Events::SUB_UNSUPPORTED_QOS_VALUE
CORBA::IMP_LIMIT
次のいずれかの問題を示します。 Tobj_Events::SUB_DOMAIN_BEGINS_WITH_SYSEV
Tobj_Events::SUB_EMPTY_DOMAIN
Tobj_Events::SUB_EMPTY_TYPE
Tobj_Events::SUB_DOMAIN_AND_TYPE_TOO_LONG
Tobj_Events::SUB_FILTER_TOO_LONG
Tobj_Events::SUB_NAME_TO_LONG
Tobj_Events::TRANSIENT_ONLY_CONFIGURATION
CORBA::INV_OBJREF
次の問題を示します。Tobj_Events::SUB_NIL_CALLBACK_REF
注記 例外および対応するマイナー・コードの詳細については、例外のマイナー・コードを参照してください。
説明
このオペレーションを使用すると、イベントをサブスクライブできます。このオペレーションは、特定のイベントのサブスクリプションを作成するために、ノーティフィケーション・サービスのサブスクライバ・アプリケーションによって呼び出されます。サブスクリプション名、ドメイン名、型名、データ・フィルタ、サービスの品質、およびサブスクライバのコールバック・オブジェクトのオブジェクト・リファレンスが渡されます。コールバック・オブジェクトでは、CosNotifyComm::StructuredPushConsumer IDL インターフェイスがインプリメントされます。
注記 シャットダウンおよび再起動するサブスクライバについては、subscription_id
を永続ストレージに書き込む必要があります。
データのフィルタ処理を利用するか、あるいは BEA Tuxedo システム・イベントまたは BEA Tuxedo アプリケーションでポストされたイベントをサブスクライブするには、イベントの FML フィールド・テーブル・ファイルの作成およびBEA Tuxedo アプリケーションとの相互運用性を参照してください。
戻り値
一意のサブスクリプション識別子が返されます。このオペレーションの結果は即時には現れません。このオペレーションからの復帰とイベント配信の実際の開始の間には遅延があります。遅延期間の長さは、コンフィギュレーション次第ではかなり長くなります。この遅延期間に影響する要素の詳細については、データベースの同期を参照してください。
注記 1 度だけ起動およびシャットダウンされるノーティフィケーション・サービス・アプリケーションでは、subscription_id
を使用してサブスクリプションが自動的にまたはシステム管理者によって取り消されているかどうかを確認できます。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、サブスクリプションの作成を参照してください。
C++ コード例
subscription_id = channel->subscribe(
subscription_name,
"News", // ドメイン
"Sports", // 型
"", // データ・フィルタなし
qos,
news_consumer.in()
);
Java コード例
Channel::unsubscribe
CORBA IDL
void
unsubscribe
( in SubscriptionID id );
パラメータ
subscription_id
サブスクリプション識別子
例外
CORBA::BAD_PARAM
次の問題を示します。Tobj_Events::INVALID_SUBSCRIPTION_ID
注記 例外および対応するマイナー・コードの詳細については、例外のマイナー・コードを参照してください。
説明
アンサブスクライブに使用します。サブスクライバ・アプリケーションでは、このオペレーションを使用してサブスクリプションを終了します。このオペレーションから復帰すると、それ以降にイベントは配信できません。入力パラメータは、サブスクライブ時に取得した SubscriptionID
1 つです。
注記 このオペレーションの結果は即時には現れません。このオペレーションからの復帰後も、サブスクライバでは一定の期間は継続してイベントを受信できます。その期間は、コンフィギュレーション次第ではかなり長くなります。この期間に影響する要素の詳細については、データベースの同期を参照してください。
例
C++ コード例
channel->unsubscribe(subscription_id);
Java コード例
channel.unsubscribe(subscription_id);
Channel::push_structured_event
CORBA IDL
void
push_structured_event
(
in CosNotification::StructuredEventnotification
);
パラメータ
notification
このパラメータは、CosNotification サービス仕様で定義されている構造化イベントを格納します。
例外
CORBA_IMP_LIMIT
サブスクリプションに関する次のいずれかの問題を示します。Tobj_Events::POST_UNSUPPORTED_VALUE_IN_ANY
Tobj_Events::POST_UNSUPPORTED_PRIORITY_VALUE
Tobj_Events::POST_DOMAIN_CONTAINS_SEPARATOR
Tobj_Events::POST_TYPE_CONTAINS_SEPARATOR
Tobj_Events::POST_SYSTEM_EVENTS_UNSUPPORTED
Tobj_Events::POST_EMPTY_DOMAIN
Tobj_Events::POST_EMPTY_TYPE
Tobj_Events::POST_DOMAIN_AND_TYPE_TOO_LONG
注記 例外および対応するマイナー・コードの詳細については、例外のマイナー・コードを参照してください。
説明
ノーティフィケーション・サービスにイベントをポストするためにポスト元アプリケーションで使用されます。
注記 このオペレーションには、トランザクションのコンテキストで使用される際のトランザクションの振る舞いがあります。詳細については、トランザクションの使い方を参照してください。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、イベントの作成とポストを参照してください。
C++ コード例
channel->push_structured_event(notification);
Java コード例
channel.push_structured_event(notification);
Channel::exists
CORBA IDL
boolean exists(in SubscriptionID subscription_id);
パラメータ
subscription_id
サブスクリプション識別子
例外
CORBA::BAD_PARAM
次の問題を示します。 Tobj_Events::INVALID_SUBSCRIPTION_ID
subscription_id
が CosNotification サービス API を使用して作成されたサブスクリプションの識別子ではない場合は、常にこの例外が返されます。
注記 例外および対応するマイナー・コードの詳細については、例外のマイナー・コードを参照してください。
説明
サブスクリプションが存在するかどうかを確認するためにサブスクライバ・アプリケーションによって使用されます。システム管理者はサブスクリプションを手動で削除でき、ノーティフィケーション・サービスでは一時的なサブスクリプションを自動的に削除できるので、サブスクライバ・アプリケーションでは必要に応じてサブスクリプションを再作成できるようにこのオペレーションを使用する必要があります。このオペレーションで使用する subscription_id
は、サブスクライブ時に取得した同じ識別子です。
戻り値
サブスクリプションが存在する場合は true、存在しない場合は false が返されます。
例
C++ コード例
if channel->exists (subscription_id) {
// サブスクリプションは依然として有効
} else {
// サブスクリプションはもう存在しない
}
Java コード例
if channel.exists (subscription_id) {
// サブスクリプションは依然として有効
} else {
// サブスクリプションはもう存在しない
}
TOBJ_SimpleEvents::ChannelFactory インターフェイス
ChannelFactory
インターフェイスは、イベント・チャネルの検索に使用します。このインターフェイスには、find_channel
という 1 つのオペレーションがあります。
このインターフェイスの CORBA IDL は次のとおりです。
module Tobj_SimpleEvents
{
typedef long ChannelID;
interface ChannelFactory
{
Channel find_channel(
in ChannelID channel_id // DEFAULT_CHANNEL でなければならない
);
};
};
Channel_Factory::find_channel
CORBA IDL
Channel
find_channel
(
in ChannelID channel_id );
パラメータ
このリリースの BEA Tuxedo では、イベント・チャネルは 1 つだけです。したがって、ChannelID
は Tobj_SimpleEvents::DEFAULT_CHANNEL
(C++) または Tobj_SimpleEvents.DEFAULT_CHANNEL.Value
(Java) に設定する必要があります。
例外
CORBA::BAD_PARAM
次の問題を示します。 Tobj_Events::INVALID_CHANNEL_ID
注記 例外および対応するマイナー・コードの詳細については、例外のマイナー・コードを参照してください。
説明
ポスト元アプリケーションとサブスクライバ・アプリケーションによって使用されます。このオペレーションを使用すると、イベント・チャネルを見つけて、ポスト元ではイベントをポストし、サブスクライバではイベントをサブスクライブおよびアンサブスクライブできます。
戻り値
デフォルト・イベント・チャネルのオブジェクト・リファレンスが返されます。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、イベント・チャネルの取得を参照してください。
C++ コード例
channel_factory->find_channel(
Tobj_SimpleEvents::DEFAULT_CHANNEL);
Java コード例
channel_factory.find_channel(DEFAULT_CHANNEL.value);
CosNotification サービス API
この節では、BEA Tuxedo CORBA ノーティフィケーション・サービスによってインプリメントされる CosNotification サービスで定義されるオペレーションについて説明します。それらのオペレーションは、オペレーション・セット全体のサブセットです。このサブセットは、BEA シンプル・イベント API の代わりとして使用できる機能的に完全な API です。
この API は、BEA シンプル・イベント API よりも複雑です。それには、2 つの理由があります。まず、CosNotification サービス API がより複雑になっています。次に、CosNotification サービス API の BEA Tuxedo インプリメンテーションでは、サポートされるオペレーションに制限が追加されます。このように複雑でも、性能または柔軟性の点で利点はないので、できる限りに BEA シンプル・イベント API を使用することをお勧めします。
CosNotification API は、可搬性を実現するため、できる限り標準の API を使用する必要がある場合のために用意されています。この API では、機能の点で、シンプル・イベント API を上回る利点は提供されません。この API を使用して開発されたアプリケーションは、ほぼ可搬性がありますが、完全ではありません。その理由は、完全な可搬性を実現できるほど CosNotification サービス API が十分にサポートされていないことです。たとえば、CORBA ベースのノーティフィケーション・サービスで使用するフィルタ処理の文法は COS Trader 文法に基づいています。BEA Tuxedo ではこの文法がサポートされていず、BEA Tuxedo EventBroker の文法に基づく別の文法がサポートされているので、フィルタ処理を必要とするアプリケーションは可搬になりません。同じことが QoS についても言えます。つまり、CosNotification サービス API では CORBA ベースのノーティフィケーション・サービスの標準のサービス品質がサポートされていず、別のサービス品質がサポートされています。
サポートされている CosNotification サービスのクラスの概要
図 2-3 は、このリリースの BEA Tuxedo で (完全または部分的に) インプリメントされている CosNotification サービスのクラスとそれらの関係を示しています。
図2-3 インプリメントされている CosNotification サービスのクラス
各クラスでサポートされているオペレーションについては、以下に要約があります。詳細については、CosNotification サービスのクラスの詳しい説明を参照してください。
このクラスは、イベント・ポスト元とサブスクライバ・アプリケーションによって使用されます。このクラスでは、イベントをポスト、サブスクライブ、およびアンサブスクライブするときにチャネル・ファクトリを取得するために使用される get_channel_factory
オペレーションがサポートされています。
このクラスは、イベント・ポスト元とサブスクライバ・アプリケーションによって使用されます。このクラスでは、次の 3 つのオペレーションがサポートされています。
default_consumer_admin
− コンシューマ管理オブジェクトを取得するためにイベント・サブスクライバ・アプリケーションによって使用されます。default_supplier_admin
− サプライヤ管理オブジェクトを取得するためにイベント・ポスト元アプリケーションによって使用されます。default_filter_factory
− フィルタ・ファクトリ・オブジェクトを取得するためにイベント・サブスクライバ・アプリケーションによって使用されます。このクラスは、イベント・ポスト元アプリケーションによって使用されます。このクラスでは、obtain_notification_push_consumer
オペレーションがサポートされています。ポスト元アプリケーションでは、このオペレーションを使用して、ノーティフィケーション・サービスにイベントをポストするために使用するプロキシ・プッシュ・コンシューマ・オブジェクトを作成します。
このクラスは、イベント・ポスト元アプリケーションによって使用されます。このクラスでは、次のオペレーションがサポートされています。
connect_structured_push_supplier
− プロキシ・プッシュ・サプライヤをノーティフィケーション・サービスのイベント・チャネルに接続するためにイベント・ポスト元アプリケーションによって使用されます。push_structured_event
− ノーティフィケーション・サービスのイベント・チャネルにイベントをポストするためにイベント・ポスト元アプリケーションによって使用されます。disconnect_structured_push_consumer
− ノーティフィケーション・サービスのイベント・チャネルからプロキシ・プッシュ・サプライヤの接続を解除するためにイベント・ポスト元アプリケーションによって使用されます。このクラスは、フィルタ・オブジェクトを作成するためにイベント・サブスクライバ・アプリケーションによって使用されます。このクラスでは、create_filter
オペレーションがサポートされています。フィルタ・オブジェクトでは、ドメイン、型、およびフィルタ処理可能データを含めたすべてのデータのフィルタ処理が提供されます。
このクラスは、イベント・サブスクライバ・アプリケーションによって使用されます。このクラスでは、次のオペレーションがサポートされています。
add_contraints
オペレーション − フィルタのドメイン、型、およびデータ・フィルタを設定するために使用します。 destroy
オペレーション − フィルタ・オブジェクトを破棄するために使用します。このクラスは、イベント・サブスクライバ・アプリケーションによって使用されます。このクラスでは、次のオペレーションがサポートされています。
obtain_notification_push_supplier
− サブスクライバのコールバック・オブジェクトにイベントを配信するために使用されるプロキシ・プッシュ・サプライヤ・オブジェクトを作成するためにイベント・サブスクライバ・アプリケーションによって使用されます。get_proxy_supplier
− プロキシ・プッシュ・サプライヤ・オブジェクトのオブジェクト・リファレンスを取得するためにイベント・サブスクライバ・アプリケーションによって使用されます。このオペレーションは、サブスクライバ・アプリケーションがシャットダウンして再起動し、サブスクリプションを取り消す場合にのみ使用されます。その理由は、サブスクライバでは最初の実行のオブジェクト・リファレンスを破棄し、次の実行でオブジェクト・リファレンスを再び取得する必要があるからです。サブスクライバでは、実行をまたがってオブジェクト・リファレンスを再利用することはできません。このクラスは、イベント・サブスクライバ・アプリケーションによって使用されます。このクラスでは、次のオペレーションがサポートされています。
connect_structured_push_consumer
− サブスクライバをプロキシ・プッシュ・サプライヤに接続するためにイベント・サブスクライバ・アプリケーションによって使用されます。set_qos
− サブスクリプションのサービスの品質を設定するためにイベント・サブスクライバ・アプリケーションによって使用されます。add_filter
− フィルタ・オブジェクトをサブスクリプションに追加するためにイベント・サブスクライバ・アプリケーションによって使用されます。get_filter
− サブスクリプションと関連付けられているフィルタを取得するためにアンサブスクライブ処理の実行時にイベント・サブスクライバ・アプリケーションによって使用されます。このオペレーションは、サブスクライバ・アプリケーションがシャットダウンして再起動する場合にのみ使用されます。disconnect_structured_push_supplier
− アンサブスクライブするためにイベント・サブスクライバ・アプリケーションによって使用されます。このインターフェイスは、イベント・サブスクライバ・アプリケーションによってインプリメントされます。このインターフェイスでは、push_structured_event
オペレーションがサポートされています。ノーティフィケーション・サービスでは、このオペレーションを呼び出してイベントをサブスクライバに配信します。
CosNotification サービスのクラスの詳しい説明
この節では、このリリースの BEA Tuxedo でインプリメントされる CosNotification サービスのクラスについて説明します。それらのクラスは、tuxdir
\include
ディレクトリにある CosNotification サービスの IDL ファイルで完全に記述されています。
注記 サポートされていないクラス・オペレーションを使用すると、CORBA::NO_IMPLEMENT
例外が発生します。
CosNotifyFilter::Filter クラス
このクラスは、イベント・サブスクライバ・アプリケーションによって使用されます。このクラスの OMG IDL は次のとおりです。
Module CosNotifyFilter
{
interface Filter {
ConstraintInfoSeqadd_constraints
(
in ConstraintExpSeq constraint)
raises (InvalidConstraint);
void
destroy
();
};
}; //CosNotifyFilter
CosNotifyFilter::Filter::add_constraints
概要
フィルタ・オブジェクトでドメイン、型、およびデータ・フィルタの各パラメータを設定します。
OMG IDL
ConstraintInfoSeq
add_constraints
(
in ConstraintExpSeq constraint)
raises (InvalidConstraint);
例外
CosNotifyFilter::InvalidConstraint
発生することはありません。
CORBA::BAD_PARAM
次の問題を示します。Tobj_Events::SUB_INVALID_FILTER_EXPRESSION.
CORBA_IMP_LIMIT
次のいずれかの問題を示します。Tobj_Notification::SUB_ADD_CONS_ON_TIMED_OUT_FILTER
Tobj_Notification::SUB_MULTIPLE_CALLS_TO_ADD_CONS
Tobj_Notification::SUB_MULTIPLE_CONSTRAINTS_IN_LIST
Tobj_Notification::SUB_MULTIPLE_TYPES_IN_CONSTRAINT
Tobj_Notification::SUB_SYSTEM_EVENTS_UNSUPPORTED
Tobj_Events::SUB_DOMAIN_BEGINS_WITH_SYSEV
Tobj_Events::SUB_EMPTY_DOMAIN
Tobj_Events::SUB_EMPTY_TYPE
Tobj_Events::SUB_FILTER_TOO_LONG
注記 例外および対応するマイナー・コードの詳細については、例外のマイナー・コードを参照してください。
説明
サブスクライブするときに使用します。このオペレーションは、サブスクライブするイベントの種類を定義するためにサブスクライバ・アプリケーションで使用されます。フィルタ・オブジェクトのドメイン、型、およびデータ・フィルタの各パラメータを設定します。これらのパラメータの説明については、サブスクリプションの作成時に使用するパラメータを参照してください。
注記 add_constraints
オペレーションの BEA Tuxedo インプリメンテーションは、呼び出しが 1 回限りであり、プロキシ・オブジェクトにフィルタが追加される前に呼び出す必要があり、イベント型が 1 つの 1 つの制約のみで構成される必要があります。
戻り値
空のリストが返されます。呼び出し側では無視することをお勧めします。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、サブスクリプションの作成を参照してください。
C++ コード例
// フィルタ処理パラメータを設定
// (ドメイン = "News"、型、およびデータ・フィルタなし)
CosNotifyFilter::ConstraintExpSeq constraints;
constraints.length(1);
constraints[0].event_types.length(1);
constraints[0].event_types[0].domain_name =
CORBA::string_dup("News");
constraints[0].event_types[0].type_name =
CORBA::string_dup ("Sports");
// データ・フィルタなし
constraints[0].constraint_expr = CORBA::string_dup("");
CosNotifyFilter::ConstraintInfoSeq_var
add_constraints_results = // この戻り値は無視
filter->add_constraints(constraints);
Java コード例
CosNotifyFilter::Filter::destroy
概要
フィルタ・オブジェクトを破棄します。
OMG IDL
void
destroy
();
例外
CORBA::BAD_PARAM
次の問題を示します。Tobj_Events::SUB_INVALID_FILTER_EXPRESSION.
注記 例外および対応するマイナー・コードの詳細については、例外のマイナー・コードを参照してください。
説明
アンサブスクライブするときに使用します。このオペレーションは、フィルタ・オブジェクトを破棄するためにサブスクライバ・アプリケーションで使用されます。
注記 対応するサブスクリプションを取り消す準備ができるまでは、フィルタ・オブジェクトを破棄しないでください。
CosNotifyFilter::FilterFactory クラス
このクラスは、イベント・サブスクライバ・アプリケーションによって使用されます。このクラスの OMG IDL は次のとおりです。
Module CosNotifyFilter
{
interface FilterFactory {
Filtercreate_filter
(
in string constraint_grammar)
raises (InvalidGrammar);
destroy
();
}; //
};CosNotifyFilter
CosNotifyFilter::FilterFactory::create_filter
概要
どのイベントがサブスクリプションに配信されるのかを指定します。
OMG IDL
Filter
create_filter
(
in string constraint_grammar)
raises (InvalidGrammar);
例外
CosNotifyFilter::InvalidGrammar
constraint_grammar
がサポートされていないことを示します。
説明
新しいフィルタ・オブジェクトを作成するためにサブスクライバ・アプリケーションで使用されます。このフィルタは、どのイベントがサブスクリプションに配信されるのかを指定するために使用します。サブスクライバでは、フィルタを設定して 5 分以内にプロキシに追加する必要があります。5 分以内に追加しないと、フィルタは破棄されます。フィルタの文法は、Tobj_Notification::Constraint_grammar
に設定する必要があります。そうしないと、InvalidGrammar
例外が発生します。
戻り値
新しいフィルタのオブジェクト・リファレンスが返されます。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、サブスクリプションの作成を参照してください。
C++ コード例
filter_factory->create_filter(
Tobj_Notification::CONSTRAINT_GRAMMAR
);
Java コード例
CosNotifyChannelAdmin::StructuredProxyPushSupplier クラス
このクラスは、イベント・サブスクライバ・アプリケーションによって使用されます。このクラスの OMG IDL は次のとおりです。
Module CosNotifyChannelAdmin
{
interface StructuredProxyPushSupplier :
ProxySupplier,
CosNotifyComm::StructuredPushSupplier {
void
connect_structured_push_consumer
(
// 次のオペレーションが継承される
in CosNotifyComm::StructuredPushConsumer push_consumer)
raises(CosEventChannelAdmin::AlreadyConnected,
CosEventChannelAdmin::TypeError );
};
voidset_qos
(in QoSProperties qos)
raises (UnsupportedQoS);
FilterIDadd_filter
(in Filter new_filter );
Filterget_filter
( in FilterID filter )
raises ( FilterNotFound);
voiddisconnect_structured_push_supplier
();
readonly attribute ProxyTypeMyType
;
};}; //CosNotifyChannelAdmin
CosNotifyChannelAdmin::StructuredProxyPushSupplier:: connect_structured_push_consumer
概要
サブスクリプションを完了します。
OMG IDL
void
connect_structured_push_consumer
(
in CosNotifyComm::StructuredPushConsumer push_consumer)
raises(CosEventChannelAdmin::AlreadyConnected,
CosEventChannelAdmin::TypeError );
例外
CosEventChannelAdmin::TypeError
発生することはありません。
CORBA::INV_OREF
Tobj_Events::SUB_NIL_CALLBACK_REF
CORBA::IMP_LIMIT
次のいずれかの問題を示します。Tobj_Events::SUB_DOMAIN_AND_TYPE_TOO_LONG
Tobj_Events::SUB_NAME_TO_LONG
Tobj_Events::TRANSIENT_ONLY_CONFIGURATION
Tobj_Notification::SUBSCRIPTION_DOESNT_EXIST.
CORBA::OBJECT_NOT_EXIST
プロキシが存在しません。
CosEventChannelAdmin::AlreadyConnected
connect_structured_push_consumer
オペレーションが既に呼び出されていることを示します。
注記 例外の定義および対応するマイナー・コードについては、例外のマイナー・コードを参照してください。
説明
このオペレーションは、サブスクライブするときに使用します。このオペレーションは、イベントをサブスクライブするためにサブスクライバ・アプリケーションで使用されます。push_consumer
パラメータは、サブスクライバのコールバック・オブジェクトを識別します。
connect_structured_push_consumer
が呼び出されると、ノーティフィケーション・サービスはコールバック・オブジェクトの push_structured_event
オペレーションを呼び出してサブスクライバにイベントを送信します。connect_structured_push_consumer
が既に呼び出されている場合は、AlreadyConnected
例外が発生します。
注記 set_qos
と add_filter
は、connect_structured_push_consumer
を呼び出す前に呼び出す必要があります。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、サブスクリプションの作成を参照してください。
C++ コード例
subscription->connect_structured_push_consumer(
news_consumer.in()
);
Java コード例
CosNotifyChannelAdmin::StructuredProxyPushSupplier::set_qos
概要
サブスクリプションの QoS を設定します。
OMG IDL
void set_qos(in QoSProperties qos)
raises (UnsupportedQoS);
Exceptions
UnsupportedQoS
発生することはありません。
ORBA::IMP_LIMIT
次のいずれかの問題を示します。Tobj_Notification::SUB_MULTIPLE_CALLS_TO_SET_QOS
Tobj_Notification::SUB_CANT_SET_QOS_AFTER_CONNECT
Tobj_Notification::SUBSCRIPTION_DOESNT_EXIST
Tobj_Notification::SUB_UNSUPPORTED_QOS_VALUE
注記 例外および対応するマイナー・コードの詳細については、例外のマイナー・コードを参照してください。
説明
サブスクライブするときに使用します。このオペレーションは、サブスクリプションの QoS を設定するためにサブスクライバ・アプリケーションで使用されます。このオペレーションは、サブスクライバが要求しているサービス品質プロパティ設定をカプセル化する名前と値のペアのシーケンスを入力パラメータとしてとります。
QoS は、サブスクリプションの種類とサブスクリプションの名前という 2 つ要素で構成されます。サブスクリプションの種類は、名前と値のペアを作成して設定します。その名前は Tobj_Notification::SUBSCRIPTION_TYPE
で、値は Tobj_Notification::PERSISTENT_SUBSCRIPTION
または Tobj_Notification::TRANSIENT_SUBSCRIPTION
です。詳細については、サービスの品質を参照してください。
サブスクリプションの名前は、名前と値のペアを作成して設定します。その名前は Tobj_Notification::SUBSCRIPTION_NAME
で、値はユーザ定義の文字列です。
このパラメータの詳細については、サブスクリプションの作成時に使用するパラメータを参照してください。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、サブスクリプションの作成を参照してください。
C++ コード例
CosNotification::QoSProperties qos;
qos.length(2);
qos[0].name =
CORBA::string_dup(Tobj_Notification::SUBSCRIPTION_NAME);
qos[0].value <<= "MySubsription";
qos[1].name =
CORBA::string_dup(Tobj_Notification::SUBSCRIPTION_TYPE);
qos[1].value <<=
Tobj_Notification::TRANSIENT_SUBSCRIPTION;
subscription->set_qos(qos);
Java コード例
CosNotifyChannelAdmin::StructuredProxyPushSupplier::add_filter
概要
サブスクライバのコールバック・オブジェクトでフィルタ・オブジェクトを設定します。
OMG IDL
add_filter(
in Filter new_filter);
例外
CORBA::IMP_LIMIT
次のいずれかの問題を示します。Tobj_Notification::SUB_MULTIPLE_CALLS_TO_SET_FILTER
Tobj_Notification::SUB_ADD_FILTER_AFTER_CONNECT
Tobj_Notification::SUB_NIL_FILTER_REF
Tobj_Notification::SUB_NO_CUSTOM_FILTERS
CORBA::OBJECT_NOT_EXIST
サブスクリプションが存在しないことを示します。
注記 例外および対応するマイナー・コードの詳細については、例外のマイナー・コードを参照してください。
説明
サブスクライブするときに使用します。このオペレーションは、サブスクライバのコールバック・オブジェクトのフィルタ・オブジェクトを設定するためにサブスクライバ・アプリケーションで使用されます。このオペレーションを使用するアプリケーションがシャットダウンされて再起動される場合は、filter_id
を永続ストレージに書き込む必要があります。
注記 このオペレーションは、サブスクライバのコールバック・オブジェクトが接続された後に呼び出すことはできません (上記の connect_structured_push_consumer
を参照)。また、複数回呼び出すこともできません。さらに、このオペレーションを呼び出すときには、フィルタの制約式が既にフィルタに存在していなくてはなりません (CosNotifyFilter::Filter add_constraints
を参照)。
注記 イベント・チャネルのデフォルト・フィルタ・ファクトリで作成されたフィルタのみ追加することができます。
戻り値
filter_id
が返されます。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、サブスクリプションの作成を参照してください。
C++ コード例
CosNotifyFilter::FilterID filter_id =
subscription->add_filter(filter.in());
Java コード例
CosNotifyChannelAdmin::StructuredProxyPushSupplier::get_filter
概要
サブスクライバのコールバック・オブジェクトに現在関連付けられているフィルタのオブジェクト・リファレンスを取得します。
OMG IDL
Filter get_filter( in FilterID filter )
raises ( FilterNotFound);
例外
CosNotifyChannelAdmin::FilterNotFound
フィルタを見つけることができなかったことを示します。
説明
再起動可能なサブスクライバでアンサブスクライブする必要があるときに使用します。このオペレーションは、サブスクライバのコールバック・オブジェクトと現在関連付けられているフィルタのオブジェクト・リファレンスを取得するためにサブスクライバ・アプリケーションで使用されます。渡される FilterID
は、サブスクライバの StructuredProxyPushSupplier オブジェクトで有効でなければなりません。FilterID
がイベント・チャネルと関連付けられているプロキシ・オブジェクトで有効ではない場合は、FilterNotFound
例外がスローされます。このオペレーションは、シャットダウンして再起動されるサブスクライバでのみ使用されます。
制限
このオペレーションでは、次の制限とガイドラインが適用されます。
CosNotifyFilter::Filter::destroy
オペレーションで使用でき
ますが、修正したりプロキシ・オブジェクトに追加したりできないので
ほとんど役に立ちません。
戻り値
サブスクライバのコールバック・オブジェクトに現在関連付けられているフィルタのオブジェクト・リファレンスが返されます。
例
C++ コード例
CosNotify::Filter_var filter =
subscription->get_filter( filter_id() );
Java コード例
CosNotifyChannelAdmin::StructuredProxyPushSupplier::
disconnect_structured_push_supplier
概要
アンサブスクライブに使用します。
OMG IDL
void disconnect_structured_push_supplier();
例外
CORBA::OBJECT_NOT_EXIST
接続を解除するサブスクリプションが存在しないことを示します。
注記 例外および対応するマイナー・コードの詳細については、例外のマイナー・コードを参照してください。
説明
アンサブスクライブするときにサブスクライバ・アプリケーションによって使用されます。このオペレーションは、ノーティフィケーション・サービスとサブスクライバのコールバック・オブジェクトの接続を終了するためにサブスクライバ・アプリケーションで使用されます。
注記 このオペレーションで、イベントの配信が即座に停止することはありません。このオペレーションからの復帰後も、サブスクライバでは一定の期間は継続してイベントを受信できます。
例
C++ コード例
subscription->disconnect_structured_push_supplier();
Java コード例
CosNotifyChannelAdmin::StructuredProxyPushSupplier::MyType
概要
常に CosNotifyChannelAdmin::PUSH_STRUCTURED
プロキシを返します。
OMG IDL
readonly attribute ProxyType MyType
説明
常に CosNotifyChannelAdmin::PUSH_STRUCTURED
プロキシを返します。
CosNotifyChannelAdmin::StructuredProxyPushConsumer クラス
このクラスは、イベント・ポスト元アプリケーションによって使用されます。このクラスの OMG IDL は次のとおりです。
Module CosNotifyChannelAdmin
{
interface StructuredProxyPushConsumer :
ProxyConsumer,
CosNotifyComm::StructuredPushConsumer {
void
connect_structured_push_supplier
(
in CosNotifyComm::StructuredPushSupplier push_supplier)
raises(CosEventChannelAdmin::AlreadyConnected);
// 次のオペレーションが継承される
readonly attributeMyType
;
voidpush_structured_event
(
in CosNotification::StructuredEvent notification )
raises( CosEventComm::Disconnected );
voiddisconnect_structured_push_consumer
();
\\
};
};StructuredProxyPushConsumer
CosNotifyChannelAdmin::StructuredProxyPushConsumer::
connect_structured_push_supplier
概要
イベントを受信するようにノーティフィケーション・サービスを準備をします。
OMG IDL
void
connect_structured_push_supplier
(
in CosNotifyComm::StructuredPushSupplier push_supplier)
raises(CosEventChannelAdmin::AlreadyConnected);
例外
CosEventChannelAdmin::AlreadyConnected
発生することはありません。
説明
イベントのポスト時にポスト元アプリケーションによって使用されます。このオペレーションを呼び出さないと、ノーティフィケーション・サービスではイベント受信の準備ができません。また、このオペレーションを使用するときには NIL を渡す必要があります。次の順序で使用します。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、イベントの作成とポストを参照してください。
C++ コード例
proxy_push_consumer->connect_structured_push_supplier(
CosNotifyComm::StructuredPushSupplier::_nil()
);
Java コード例
proxy_push_consumer.connect_structured_push_supplier(null);
CosNotifyChannelAdmin::StructuredProxyPushConsumer::
push_structured_event
概要
イベント・チャネルにイベントをポストします。
OMG IDL
void
push_structured_event
(
in CosNotification::StructuredEvent notification )
raises( CosEventComm::Disconnected );
例外
CosEventComm::Disconnected
発生することはありません。
CORBA::IMP_LIMIT
次のいずれかの問題を示します。Tobj_Events::POST_UNSUPPORTED_VALUE_IN_ANY
Tobj_Events::POST_UNSUPPORTED_PRIORITY_VALUE
Tobj_Events::POST_DOMAIN_CONTAINS_SEPARATOR
Tobj_Events::POST_TYPE_CONTAINS_SEPARATOR
Tobj_Events::POST_SYSTEM_EVENTS_UNSUPPORTED
Tobj_Events::POST_EMPTY_DOMAIN
Tobj_Events::POST_EMPTY_TYPE
Tobj_Events::POST_DOMAIN_AND_TYPE_TOO_LONG
注記 例外および対応するマイナー・コードの詳細については、例外のマイナー・コードを参照してください。
説明
イベントをポストするときに使用します。このオペレーションは、イベント・チャネルにイベントをポストするためにポスト元アプリケーションで使用されます。
注記 このオペレーションは、次の点で標準の CORBA 定義とは異なります。
short
値でなければなりません。
注記 このオペレーションには、トランザクションのコンテキストで使用される際のトランザクションの振る舞いがあります。詳細については、トランザクションの使い方を参照してください。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、イベントの作成とポストを参照してください。
C++ コード例
proxy_push_consumer->push_structured_event(notification);
Java コード例
proxy_push_consumer.push_structured_event(notification);
CosNotifyChannelAdmin::StructuredProxyPushConsumer::
disconnect_structured_push_consumer
概要
イベントのポストを停止します。
OMG IDL
void
disconnect_structured_push_consumer
();
説明
イベントをポストするときに使用します。このオペレーションは、イベントのポストを停止するためにポスト元アプリケーションによって使用されます。入力パラメータは不要で、値は返されません。次の順序で使用することをお勧めします。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、イベントの作成とポストを参照してください。
C++ コード例
proxy_push_consumer->disconnect_structured_push_consumer();
Java コード例
proxy_push_consumer.disconnect_structured_push_consumer();
CosNotifyChannelAdmin::StructuredProxyPushConsumer::MyType
概要
常に CosNotifyChannelAmdmin::PUSH_STRUCTURED
プロキシを返します。
OMG IDL
readonly attribute ProxyType MyType
説明
常に CosNotifyChannelAmdmin::PUSH_STRUCTURED
プロキシを返します。
CosNotifyChannelAdmin::ConsumerAdmin クラス
このクラスは、イベント・サブスクライバ・アプリケーションによって使用されます。このクラスの OMG IDL は次のとおりです。
Module CosNotifyChannelAdmin
{
interface ConsumerAdmin :
CosNotification::QoSAdmin,
CosNotifyComm::NotifySubscribe,
CosNotifyFilter::FilterAdmin,
CosEventChannelAdmin::ConsumerAdmin {
ProxySupplier
obtain_notification_push_supplier
(
in ClientType ctype,
out ProxyID proxy_id)
raises ( AdminLimitExceeded )
ProxySupplier
get_proxy_supplier
(
in ProxyID proxy_id )
raises ( ProxyNotFound );
};
CosNotifyChannelAdmin
}; //
CosNotifyChannelAdmin::ConsumerAdmin::
obtain_notification_push_supplier
概要
プロキシ・プッシュ・サプライヤ・オブジェクトを作成します。
OMG IDL
ProxySupplier
obtain_notification_push_supplier
(
in ClientType ctype,
out ProxyID proxy_id)
raises ( AdminLimitExceeded )
例外
CosNotifyChannelAdmin::AdminLimitExceeded
発生することはありません。
CORBA::IMP_LIMIT
次の問題を示します。Tobj_Notification::SUB_UNSUPPORTED_CLIENT_TYPE
説明
サブスクライブするときに使用します。このオペレーションは、プロキシ・プッシュ・サプライヤ・オブジェクトを作成するためにサブスクライバ・アプリケーションで使用されます。構造化イベントのみがサポートされています。つまり、ANY_EVENT
と SEQUENCE_EVENT ClientTypes
はサポートされていません。したがって、ClientType
入力パラメータは CosNotifyComm::STRUCTURED_EVENT
に設定する必要があります。サブスクライバをシャットダウンして再起動する場合で、サブスクリプションがプログラムの複数の実行にまたがって存続する場合は、このオペレーションで返される ProxyID
を永続的に保存する必要があります。サブスクライバでは、プロキシ・サプライヤを CosNotifyChannelAdmin::StructuredProxyPushSupplier
にナロー変換する必要があります。必要なすべてのオペレーションは 5 分間で完了する必要があります。
注記 1 度だけ起動およびシャットダウンされるノーティフィケーション・サービス・アプリケーションでは、proxy_id
を使用してサブスクリプションが自動的にまたはシステム管理者によって取り消されているかどうかを確認できます。
戻り値
このオペレーションでは、新しいプロキシのオブジェクト・リファレンスが返されます。新しい proxy_id
も、proxy_id
出力パラメータを通じて返されます。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、サブスクリプションの作成を参照してください。
C++ コード例
CosNotifyChannelAdmin::ProxySupplier_var generic_proxy =
consumer_admin->obtain_notification_push_supplier(
CosNotifyChannelAdmin::STRUCTURED_EVENT,
proxy_id
);
CosNotifyChannelAdmin::StructuredProxyPushSupplier_var proxy =
CosNotifyChannelAdmin::StructuredProxyPushSupplier::_narrow(
generic_proxy.in ()
);
Java コード例
CosNotifyChannelAdmin::ConsumerAdmin::get_proxy_supplier
概要
コンシューマ管理オブジェクトの obtain_notification_push_supplier
オペレーションを使用して作成されたプロキシ・プッシュ・サプライヤ・オブジェクトを返します。
OMG IDL
ProxySupplier
get_proxy_supplier
(
in ProxyID proxy_id )
raises ( ProxyNotFound );
例外
CosNotifyChannelAdmin::ProxyNotFound
ProxyID
を見つけることができなかったことを示します。
説明
アンサブスクライブするときに使用します。このオペレーションは、コンシューマ管理オブジェクトの obtain_notification_push_supplier
オペレーションを使用して作成されたプロキシ・プッシュ・サプライヤ・オブジェクトを返すためにサブスクライバ・アプリケーションで使用されます。ProxyID
入力パラメータは、プロキシ・オブジェクトを一意に識別します。呼び出し側では、一時的なサブスクリプションの配信エラーまたは ntsadmin
管理コマンドによってプロキシ・オブジェクトが破棄される可能性があることを認識していなければなりません。プロキシ・オブジェクトが破棄されると、関連付けられている ProxyID
が無効になります。ProxyID
が無効な場合は、ProxyNotFound
例外が発生します。サブスクライバでは、プロキシ・サプライヤを CosNotifyChannelAdmin::StructuredProxyPushSupplier
にナロー変換する必要があります。
戻り値
既存のプロキシのオブジェクト・リファレンスが返されます。
例
C++ コード例
CosNotifyChannelAdmin::ProxySupplier_var generic_proxy =
m_consumer_admin->get_proxy_supplier(
m_subscription_info.news_proxy_id()
);
CosNotifyChannelAdmin::StructuredProxyPushSupplier_var proxy =
CosNotifyChannelAdmin::StructuredProxyPushSupplier::_narrow(
generic_proxy.in()
);
Java コード例
CosNotifyChannelAdmin::SupplierAdmin クラス
このクラスは、イベント・ポスト元アプリケーションによって使用されます。このクラスの OMG IDL は次のとおりです。
Module CosNotifyChannelAdmin
{
interface SupplierAdmin :
CosNotification::QoSAdmin,
CosNotifyComm::NotifyPublish,
CosNotifyFilter::FilterAdmin,
CosEventChannelAdmin::SupplierAdmin {
ProxyConsumer
obtain_notification_push_consumer
(
SupplierAdmin
in ClientType ctype,
out ProxyID proxy_id)
raises ( AdminLimitExceeded );
};
}; //
CosNotifyChannelAdmin::SupplierAdmin::
obtain_notification_push_consumer
概要
プロキシ・プッシュ・コンシューマ・オブジェクトを作成します。
OMG IDL
ProxyConsumer
obtain_notification_push_consumer
(
in ClientType ctype,
out ProxyID proxy_id)
raises ( AdminLimitExceeded );
例外
CosNotifyChannelAdmin::AdminLimitExceeded
発生することはありません。
CORBA::IMP_LIMIT
次の問題を示します。Tobj_Notification::SUB_UNSUPPORTED_CLIENT_TYPE
説明
イベントをポストするときに使用します。このオペレーションは、プロキシ・プッシュ・コンシューマ・オブジェクトを作成するためにポスト元アプリケーションで使用されます。ClientType
は、"CosNotifyChannelAdmin::STRUCTURED_EVENT"
に設定する必要があります。返される ProxyID
は無視してください。プロキシ・コンシューマは、CosNotifyChannelAdmin::StructuredProxyPushConsumer
にナロー変換する必要があります。
注記 1 度だけ起動およびシャットダウンされるノーティフィケーション・サービス・アプリケーションでは、proxy_id
を使用してサブスクリプションが自動的にまたはシステム管理者によって取り消されているかどうかを確認できます。
戻り値
このオペレーションでは、新しいプロキシのオブジェクト・リファレンスが返されます。新しい proxy_id
も、proxy_id
出力パラメータを通じて返されます。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、イベントの作成とポストを参照してください。
C++ コード例
CosNotifyChannelAdmin::ProxyConsumer_var generic_proxy_consumer =
supplier_admin->obtain_notification_push_consumer(
CosNotifyChannelAdmin::STRUCTURED_EVENT,
proxy_id
);
CosNotifyChannelAdmin::StructuredProxyPushConsumer_var
proxy_push_consumer =
CosNotifyChannelAdmin::StructuredProxyPushConsumer::_narrow(
generic_proxy_consumer
);
Java コード例
supplier_admin
.obtain_notification_push_consumer
(
ClientType.STRUCTURED_EVENT, proxy_id );
CosNotifyChannelAdmin::EventChannel クラス
このクラスは、イベント・ポスト元アプリケーションによって使用されます。このクラスの OMG IDL は次のとおりです。
Module CosNotifyChannelAdmin
{
interface EventChannel :
CosNotification::QoSAdmin,
CosNotification::AdminPropertiesAdmin,
CosEventChannelAdmin::EventChannel {
readonly attribute
ConsumerAdmindefault_consumer_admin
;
SupplierAdmin
readonly attributedefault_supplier_admin
;
readonly attribute CosNotifyFilter::FilterFactory
default_filter_factory
;
CosNotifyChannelAdmin
};
}; //
CosNotifyChannelAdmin::EventChannel::
ConsumerAdmin default_consumer_admin
概要
ConsumerAdmin オブジェクトを取得します。
OMG IDL
readonly attribute
ConsumerAdmindefault_consumer_admin
;
説明
サブスクライブおよびアンサブスクライブするときに使用します。このオペレーションは、ConsumerAdmin オブジェクトを取得するためにサブスクライバ・アプリケーションで使用されます。
戻り値
ConsumerAdmin オブジェクトのオブジェクト・リファレンスが返されます。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、イベント・チャネル、ConsumerAdmin オブジェクト、およびフィルタ・ファクトリ・オブジェクトの取得を参照してください。
C++ コード例
channel->default_consumer_admin();
Java コード例
注記
CosNotifyChannelAdmin::EventChannel::
ConsumerAdmin default_supplier_admin
概要
SupplierAdmin オブジェクトを取得します。
OMG IDL
readonly attribute
SupplierAdmindefault_supplier_admin
;
説明
イベントをポストするときに使用します。このオペレーションは、SupplierAdmin オブジェクトを取得するためにイベント・ポスト元アプリケーションで使用されます。
戻り値
SupplierAdmin のオブジェクト・リファレンスが返されます。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、イベントの作成とポストを参照してください。
C++ コード例
channel->default_supplier_admin();
Java コード例
channel.default_supplier_admin();
CosNotifyChannelAdmin::EventChannel::default_filter_factory
概要
デフォルトの FilterFactory オブジェクトを取得します。
OMG IDL
readonly attribute CosNotifyFilter::FilterFactory
default_filter_factory
;
説明
サブスクライブするときに使用します。このオペレーションは、デフォルトの FilterFactory オブジェクトを取得するためにサブスクライバ・アプリケーションで使用されます。
戻り値
デフォルトの FilterFactory オブジェクトのオブジェクト・リファレンスが返されます。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、イベント・チャネル、ConsumerAdmin オブジェクト、およびフィルタ・ファクトリ・オブジェクトの取得を参照してください。
C++ コード例
channel->
default_filter_factory();
Java コード例
CosNotifyChannelAdmin::EventChannelFactory クラス
このクラスは、イベント・ポスト元アプリケーションによって使用されます。このクラスの OMG IDL は次のとおりです。
Module CosNotifyChannelAdmin
{
interface EventChannelFactory {
EventChannelget_event_channel
( in ChannelID id )
CosNotifyChannelAdmin
raises (ChannelNotFound);
};
}; //
CosNotifyChannelAdmin::EventChannelFactory::get_event_channel
概要
EventChannel
オブジェクトを取得します。
OMG IDL
EventChannel
get_event_channel
( in ChannelID id )
raises (ChannelNotFound);
例外
CosNotifyChannelAdmin::ChannelNotFound
チャネルを見つけることができないことを示します。
説明
イベントをサブスクライブ、アンサブスクライブ、およびポストするときに使用します。このオペレーションは、EventChannel
オブジェクトを取得するためにアプリケーションで使用されます。サブスクライブのときには、EventChannel オブジェクトを使用してフィルタ・ファクトリ・オブジェクトと ConsumerAdmin オブジェクトを取得します。アンサブスクライブのときには、EventChannel オブジェクトを使用して ConsumerAdmin オブジェクトを取得します。イベントをポストするときには、EventChannel オブジェクトを使用して SupplierAdmin オブジェクトを取得します。ChannelID
パラメータは、Tobj_Notification::DEFAULT_CHANNEL
に設定しなければなりません。そのように設定しないと、ChannelNotFound
例外が発生します。
戻り値
デフォルト・イベント・チャネルのオブジェクト・リファレンスが返されます。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、イベント・チャネルの取得およびイベント・チャネル、ConsumerAdmin オブジェクト、およびフィルタ・ファクトリ・オブジェクトの取得を参照してください。
C++ コード例
channel_factory->
get_event_channel(
Tobj_Notification::DEFAULT_CHANNEL );
Java コード例
channel_factory.
get_event_channel(DEFAULT_CHANNEL.value);
CosNotifyComm::StructuredPushConsumer インターフェイス
このインターフェイスは、イベントの配信を目的としてイベント・サブスクライバ・アプリケーションによって使用されます。このインターフェイスをインプリメントしないと、ノーティフィケーション・サービスではサブスクライバにイベントを配信できません。このインターフェイスには、インプリメントしなければならない 3 つのメソッドがあります。
このクラスの OMG IDL は次のとおりです。
Module CosNotifyComm
{
interface StructuredPushConsumer : NotifyPublish {
void
push_structured_event
(
event
in CosNotification::StructuredEvent)
CosNotifyComm
raises(CosEventComm::Disconnected);
void disconnect_structured_push_consumer:
// 次のオペレーションが継承される
void offer_change(
in CosNotification::EventTypeSeq added,
in CosNotification::EventTypeSeq removed )
raises ( InvalidEventType );
};
}; //
CosNotifyComm::StructuredPushConsumer::push_structured_event
概要
構造化イベントを配信します。
OMG IDL
void
push_structured_event
(
event
in CosNotification::StructuredEvent)
raises(CosEventComm::Disconnected);
例外
CosEventComm::Disconnected
サブスクライバではこの例外を発生させてはなりません。
説明
サブスクライブするときに使用します。このオペレーションは、サブスクライバのコールバック・オブジェクトによってインプリメントされ、構造化イベントが配信されるたびにノーティフィケーション・サービスによって呼び出されます。このオペレーションには、1 つの入力パラメータ (構造化イベント) があります。
注記 このオペレーションは、トランザクションでは呼び出されません。また、このオペレーションは呼び出されてもすぐに復帰しなければなりません。その理由は、このオペレーションが復帰するまで、ノーティフィケーション・サービスではほかのサブスクライバへのイベント配信が開始されないからです。
例
注記 ここで紹介するコード例は全体の一部分です。完全なコード例については、CosNotifyComm::StructuredPushConsumer インターフェイスのインプリメントを参照してください。
C++ コード例
virtual void push_structured_event(
const CosNotification::StructuredEvent& notification );
{
// イベントを処理
}
Java コード例
CosNotifyComm::StructuredPushConsumer::
disconnect_structured_push_consumer
概要
呼び出されることはありません。
OMG IDL
void disconnect_structured_push_consumer;
説明
このオペレーションが呼び出されることはありません。サブスクライバ・アプリケーションでは、このオペレーションのスタブ・アウト・バージョンを用意する必要があります。
例
C++ コード例
virtual void push_structured_event(
const CosNotification::StructuredEvent& notification );
{
throw new CORBA::NO_IMPLEMENT();
}
Java コード例
public void disconnect_structured_push_consumer()
{
throw new CORBA::NO_IMPLEMENT();
}
CosNotifyComm::StructuredPushConsumer::Offer_change
概要
呼び出されることはありません。
OMG IDL
void offer_change(
in CosNotification::EventTypeSeq added,
in CosNotification::EventTypeSeq removed )
raises ( InvalidEventType );
例外
CosNotifyComm::InvalidEventType
サブスクライバではこの例外を発生させてはなりません。
説明
このオペレーションが呼び出されることはありません。サブスクライバ・アプリケーションでは、このオペレーションのスタブ・アウト・バージョンを用意する必要があります。
例
C++ コード例
virtual void offer_change(
const CosNotification::EventTypeSeq& added,
const CosNotification::EventTypeSeq& removed )
{
throw CORBA::NO_IMPLEMENT();
}
Java コード例
public void offer_change(EventType[] added, EventType[] removed)
{
throw new NO_IMPLEMENT();
}
例外のマイナー・コード
この節では、ノーティフィケーション・サービスの例外シンボルとマイナー・コードについて説明します。マイナー・コードは、Tobj_Events.idl
ファイルと Tobj_Notification.idl
ファイルにあります。それらのファイルは、tuxdir
\include
ディレクトリ (Microsoft Windows の場合) および tuxdir/include
ディレクトリ (UNIX の場合) に配置されています。
表 2-4 と 表 2-5 は、それぞれ Tobj_Events 例外と Tobj_Notification 例外の例外シンボルと対応するマイナー・コードを示しています。CORBA システム・イベントにはマイナー・コード・フィールドがあり、それらのマイナー・コードも以下の表で定義されています。
注記 表の中の例外シンボルは、より高いレベルの例外 (CORBA::IMP_LIMIT
、CORBA::CORBA::BAD_PARAM
、CORBA::BAD_INV_ORDER
、CORBA::INV_OBHJREF
、および CORBA::OBJECT_NOT_EXIST
) に基づいて構成されており、アルファベット順にリストされています。
|
Copyright © 2001, BEA Systems, Inc. All rights reserved.
|