目次 前 次 PDF


概要

概要
このトピックには次の項が含まれます:
はじめに
通知サービスは、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つだけです。
図1-1 通知サービス・モデル
 
CORBAベースの通知サービス仕様に従って、イベント・ポスト元では常にプッシュ・モデルを使用します。このため、イベント・ポスト元ではオペレーションを呼び出して通知サービスにイベントをプッシュします。通知サービスでは、イベントのフィルタリングと配信を行います。イベント・ポスト元とイベント・サブスクライバの間に直接的な関連はありません。イベント・ポスト元およびイベント・サブスクライバの数は、ゼロであったり、1であったり、または多数であったりします。
また、CORBAベースの通知サービス仕様では、サブスクライバはプッシュまたはプルのいずれかのイベント配信モデルを選択できます。このリリースのOracle Tuxedoでサポートされているのはプッシュ・モデルだけです。したがって、通知サービスではコンシューマのオペレーションを呼び出してコンシューマにイベントをプッシュします。一致するサブスクリプションのサービスの品質(QoS)によっては、イベントは永続的に格納され、コンシューマへの配信が保留される場合もあります。
製品の構成要素
Oracle Tuxedo CORBA通知サービスでは、以下のサポートが提供されます。
使いやすさを実現するOracleシンプル・イベント・アプリケーション・プログラミング・インタフェース(API)
CosNotificationサービスAPIで定義される最低限のオペレーション・セット
一時的および永続的の、サブスクリプションの2つのサービスの品質(QoS)
一時的なサブスクリプションの場合、通知サービスではサブスクライバへのイベント配信が1回だけ試行されます。その試行が失敗するとイベントは破棄され、サブスクライバがシャットダウンされているかほかの理由で利用できないと通知サービスで判断された場合は、サブスクリプションが取り消されます。
永続的なサブスクリプションの場合、配信の最初の試行が失敗すると、通知サービスではそのイベントが保持され、構成可能な再試行回数の上限に達するまでサブスクリプションの配信が繰り返されます。再試行回数の上限に達すると、イベントはエラー・キューに移動されます。エラー・キューに保持されたイベントは、システム管理者によって処理されます。システム管理者は、エラー・キューからイベントを削除するか(事実上の破棄)、または再び配信できるように保留キューに戻します。
システム、イベント・キュー、およびサーバー・プロセスの初期構成のためのUBBCONFIGファイルの使用
Oracle Tuxedo形式のFMLフィールド表の使用。FMLフィールド表を使用することで、通知サービスでは次のサポートが可能となります。
イベント・ポスト元とイベント・サブスクライバの間のイベント・データのフィルタリング
Oracle Tuxedo EventBrokerとの相互運用性。通知サービスでポストされたイベントをTuxedo EventBrokerで消費できます(逆方向も可)。
次のOracle Tuxedo通知サービス・サーバーを使用したイベントの処理
TMNTS
TMNTSFWD_P
TMNTSFWD_T
次のOracle Tuxedoシステム・サーバーを使用したイベントの処理
TMSYSEVT
TMUSREVT
TMQUEUE
TMQFORWARD
Oracle Tuxedo ntsadmin管理ユーティリティを使用したイベント・キューの管理
Oracle Tuxedo qmadmin管理ユーティリティを使用したイベント・キューの構成と管理
Oracle Tuxedo tmadmin管理ユーティリティを使用したトランザクション・ログの構成と管理
 

Copyright ©1994, 2017,Oracle and/or its affiliates. All rights reserved