| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo CORBA ノーティフィケーション・サービス > 概要 |
|
Tuxedo CORBA ノーティフィケーション・サービス
|
概要
ここでは、以下の内容について説明します。
はじめに
ノーティフィケーション・サービスは、BEA Tuxedo CORBA 環境でイベント・サービスを提供します。ノーティフィケーション・サービスはスタンドアロンで機能する製品というよりは、BEA Tuxedo のレイヤード・プロダクトといえます。
ノーティフィケーション・サービスは BEA Tuxedo EventBroker と同様の機能を備えていますが、そのプログラミング・モデルとインターフェイスは CORBA ユーザ向けに設計されています。この手法の副作用は、BEA Tuxedo EventBroker と互換性がないか、EventBroker をはるかに超える機能が提供されるために、CORBA ベースのノーティフィケーション・サービスの大部分がサポートされていないことです。
ノーティフィケーション・サービスは、イベント・ポスト・メッセージを受信してフィルタ処理し、それらのメッセージをサブスクライバに配信する BEA Tuxedo サブシステムです。ポスト元は、対象となるイベントがいつ発生したかを検出し、それをノーティフィケーション・サービスに報告 (ポスト) する BEA Tuxedo CORBA アプリケーションです。サブスクライバは、対象となるイベントがポストされたときに通知アクションの実行を要求する BEA Tuxedo CORBA アプリケーションです。
メッセージを受信して配信する「無名」サービス (ノーティフィケーション・サービス) の概念は、BEA Tuxedo CORBA 環境に新たなクライアント/サーバ通信パラダイムをもたらします。要求側とプロバイダの 1 対 1 の関係ではなく、任意の数のポスト元が任意の数のサブスクライバに対してメッセージをポストできます。ポスト元は単にイベントをポストするだけで、どこで情報が受信されるのか、何が行われるのかについては関知しません。サブスクライバは、ポスト元を知ることなく、対象となるどのような情報でもノーティフィケーション・サービスから受信できます。また、サブスクライバはさまざまな方法で通知を受けてアクションを実行できます。
通常、ノーティフィケーション・サービス・アプリケーションは例外イベントを処理します。アプリケーション設計者は、アプリケーションでどのイベントを監視するのかを決めなければなりません。たとえば銀行業務アプリケーションでは、非常に高額な払出しについてイベントがポストされるかもしれませんが、すべての払出しでイベントをポストしても特に便利というわけではありません。また、すべてのユーザがそのイベントをサブスクライブする必要はありません。支店長だけに通知すれば十分です。
ノーティフィケーション・サービスのプログラミング・モデルは、CORBA のプログラミング・モデルに基づいています。インターフェイスには 2 つのセットがあります。1 つはこのマニュアルで CosNotification サービス・インターフェイスと呼んでいる CORBA ベースのノーティフィケーション・サービス・インターフェイスのサブセット、もう 1 つは使いやすいように設計された BEA シンプル・イベント・インターフェイス (BEA 独自のインターフェイス) です。どちらのインターフェイスも、CORBA ベースのノーティフィケーション・サービス仕様で定義される標準の構造化されたイベントを渡します。
2 つのインターフェイスはお互いに互換性があります。つまり、CosNotification サービス・インターフェイスを使用してポストされたイベントは、BEA シンプル・イベント・インターフェイスでサブスクライブできます (逆方向も可)。
機能の概要
ノーティフィケーション・サービス・システムには、3 つの基本的な構成要素があります (図1-1 を参照)。
サプライヤは、イベントを生成します。サプライヤは、イベントを作成してノーティフィケーション・サービスにポストします。
ノーティフィケーション・サービスはイベントを処理します。
コンシューマは、イベントを受信します。コンシューマは、ノーティフィケーション・サービスに接続してイベントをサブスクライブします。
コンシューマのサブスクリプションに一致するイベントがノーティフィケーション・サービスで受信されると、ノーティフィケーション・サービスではそのイベントをコンシューマに配信しようとします。サプライヤとコンシューマは多数存在することができます。ノーティフィケーション・サービスは複製できますが、論理的にはノーティフィケーション・サービスは 1 つだけです。
図 1-1 ノーティフィケーション・サービス・モデル
CORBA ベースのノーティフィケーション・サービス仕様に従って、イベント・ポスト元では常にプッシュ・モデルを使用します。このため、イベント・ポスト元ではオペレーションを呼び出してノーティフィケーション・サービスにイベントをプッシュします。ノーティフィケーション・サービスでは、イベントのフィルタ処理と配信を行います。イベント・ポスト元とイベント・サブスクライバの間に直接的な関連はありません。イベント・ポスト元およびイベント・サブスクライバの数は、ゼロであったり、1 であったり、または多数であったりします。 また、CORBA ベースのノーティフィケーション・サービス仕様では、サブスクライバはプッシュまたはプルのいずれかのイベント配信モデルを選択できます。このリリースの BEA Tuxedo でサポートされているのはプッシュ・モデルだけです。したがって、ノーティフィケーション・サービスではコンシューマのオペレーションを呼び出してコンシューマにイベントをプッシュします。一致するサブスクリプションのサービスの品質 (QoS) によっては、イベントは永続的に格納され、コンシューマへの配信が保留される場合もあります。
製品の構成要素
BEA Tuxedo CORBA ノーティフィケーション・サービスでは、以下のサポートが提供されます。
一時的なサブスクリプションの場合、ノーティフィケーション・サービスではサブスクライバへのイベント配信が 1 回だけ試行されます。その試行が失敗するとイベントは破棄され、サブスクライバがシャットダウンされているかほかの理由で利用できないとノーティフィケーション・サービスで判断された場合は、サブスクリプションが取り消されます。
永続的なサブスクリプションの場合、配信の最初の試行が失敗すると、ノーティフィケーション・サービスではそのイベントが保持され、コンフィギュレーション可能な再試行回数の上限に達するまでサブスクリプションの配信が繰り返されます。再試行回数の上限に達すると、イベントはエラー・キューに移動されます。エラー・キューに保持されたイベントは、システム管理者によって処理されます。システム管理者は、エラー・キューからイベントを削除するか (事実上の破棄)、または再び配信できるように保留キューに戻します。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
