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