WebLogic Events の概要



\| WebLogic Server ホーム \| Event ユーザーズガイド (非推奨) \| 前へ \| 次へ \| 目次 \| 索引 \| PDF 版

WebLogic Events の概要

WebLogic Event API は、パブリッシュ/サブスクライブパラダイムを使用した軽量のイベント管理システムを提供します。たとえば、WebLogic/JDBC クライアントは、WebLogic Server にイベントを送信（パブリッシュ）できます。WebLogic Server の他のクライアントは、これらのイベントへの関心を登録（つまりイベントをサブスクライブ）できます。新しいイベントが発生すると、WebLogic Server はそれをサブスクライバに通知します。

クライアントは、エバリュエータと呼ばれる条件を指定することができ、その条件が満たされないと、イベントはクライアントに送られません。エバリュエータは不必要なネットワークトラフィックを防止できます。エバリュエータは WebLogic Server 上で実行されます。

クライアントは、イベントが発生したときのアクションも指定します。イベントの結果から発生するアクションは、サーバサイドにもクライアントサイドにも実装できます。このマニュアルの「イベントへの関心の登録」を参照してください。

サービスの 1つである WebLogic Event は、JDBC、RMI、ロギング、インスツルメンテーション、ワークスペースなど、WebLogic の他のすべてのサービスを利用することができます。これらのサービスはすべて、WebLogic に統合されています。これらの API は共通の側面を多く共有しているので、複雑なネットワークアプリケーションの構築が容易になります。アプリケーションは複数のサービスを利用でき、それらはすべてオブジェクトとクライアントリソースへのアクセスを共有することができます。

どの WebLogic Server も他のサーバ上のイベントに対してパブリッシュとサブスクライブを同時に行えるので、複数の WebLogic Server が WebLogic クラスタとして連動して、通知と登録を管理することができます。

WebLogic Server は、JavaSoft の Java Messaging Service（JMS）仕様を実装しています。WebLogic Event を使用できるどのアプリケーションでも、WebLogic JMS を使用できます。WebLogic JMS は、WebLogic Event に備わっていない、メソッド永続性、ポイントツーポイントメッセージング、保証付きメッセージ配信シーケンスなどの機能を提供します。WebLogic JMS は業界標準インタフェースなので、WebLogic JMS を使用して新しいイベントベースアプリケーションを実装することをお勧めします。もちろん、JMS が提供する高度な機能を必要としないアプリケーションでは、WebLogic Event を使用してもかまいません。WebLogic Event サービスは小規模で高速に動作しますが、JMS に比べると機能が限定されています。WebLogic JMS の詳細については、『WebLogic JMS プログラマーズガイド』を参照してください。

WebLogic Event のアーキテクチャ

トピックツリー

トピックツリーは、WebLogic Event のアーキテクチャ上の主要機能です。トピックツリーは WebLogic Server 上に存在し、その中には、クライアントがサブスクライブしたすべてのイベントトピックが入っています。これは、WebLogic クライアントが WebLogic Event のサブスクライブおよびパブリッシュを行うときに、それらのイベントを記憶し処理するのに用いられるデータ構造です。

トピックツリーの構造

このツリー構造によって、イベントタイプをカテゴリへ、さらにサブカテゴリへグループ化できるようになり、ツリー内の分岐は、その分岐元のイベントのサブカテゴリを表します。適切に構成されたトピックツリーでは、ルートノードからリーフノードへ進むにつれて、イベントトピックはより具体的なものになります。

ツリー内のイベントを記述するための表記は、ドメインアドレスのドット表記に似ています。それぞれの単語が、ツリー内の特定の分岐でのイベントを表します。たとえば、comms.devices.telephone.ring または comms.devices.telephone.page です。これにより、クライアントは、完全イベント修飾子を使って特定のイベントトピックをサブスクライブできるようになります。また、このモデルによって、クライアントは分岐レベルへの関心を指定するだけで、イベントトピックの一般カテゴリをサブスクライブできるようにもなります。たとえば、comms.devices.telephone の場合、電話に関係するあらゆるイベントをリスンすることになります。

ただし、ツリーの編成は、WebLogic のフレームワークを構成するクライアントアプリケーションが処理する必要があります。開発者は、イベントを適切に組織化して、この構造を最大限に利用するようにシステムをプログラミングする必要があります。

構造化ツリーの例

どのトピックツリーでも頂点（つまりルート）には、本質的に「あらゆる種類のイベント」を意味するワイルドカードトピックがあり、これはアスタリスク（*）で表記されます。それ以外のトピックはすべて、ルートトピックより具体的なものとみなされます。ルートトピックへの関心を登録するアプリケーションは、WebLogic Server 上で発生する、トピックツリー内のすべてのイベントを評価することができます。

図1-1 WebLogic のトピックツリー

図 1-1に示された例には、ルートから派生するトピックの大きな分枝が 2 つあります。stocks（株式）と weather（天気）です。ここで作成したのは、カリフォルニア州の 2 つの都市、ロサンゼルスとサンフランシスコの天気への関心を登録するための典型的なトピックツリーです。これらのトピックは、以下のように表記されます。

weather.northamerica.us.california.la

および

weather.northamerica.us.california.sf

イベントへの関心の登録

トピックツリーの作成方法

トピックツリーは、クライアントがイベントトピックをサブスクライブするときに、WebLogic Server 内部に動的に作成されます。クライアントがトピックツリー内に存在しないイベントトピックをサブスクライブすると、新しいノードと、そのノードに到達するのに必要な新しい分枝が自動的に作成されます。これで、サブスクライブ側のクライアントは、新しいイベントが発行されるたびにその通知を受け取ることになります。

クライアントがイベントトピックへの関心を登録する方法

WebLogic クライアントは、イベントが発行されたときにそれらを評価し、それらに基づいて動作するために、トピックへの関心を WebLogic Server に登録しなければなりません。ネットワーク上のどの WebLogic クライアントアプリケーションも、WebLogic EventRegistration サービスを通じて、任意の数のイベントトピックへの関心を登録することができます。

登録は、通常は以下の情報と一緒に WebLogic Server に提出されます。

どのイベントをサブスクライブするか。これは登録パラメータで記述されます。

イベントが発生したときに、それをどのように評価するか。これは、EvaluateDef オブジェクトを通じて指定されます。
イベントの評価結果が true の場合には、何が起こるか。ActionDef オブジェクトを通じて指定されます。

この点については、後でコード例を使って詳しく説明します。「イベントへの関心の登録」を参照してください。

クライアントがイベントトピックへの関心を登録解除する方法

クライアントアプリケーションは、以下の 2 つの方法のいずれかで関心を登録解除することができます。

count プロパティを使用して、関心をいつ登録解除するかを制御します。イベント登録期間を制御する方法は複数あります。

EventRegistration.unregister() メソッドを呼び出します。

注意: evaluate() メソッドと action() メソッドが両方とも WebLogic Server に存在する場合のイベント登録については、クライアントが関心の登録を解除する必要があります。一方、action() メソッドがクライアントに存在する場合には、WebLogic クライアントが接続を解除すると、登録解除が自動的に行われます。

イベントの処理

この節では、イベントの伝播の仕組みについて説明します。これを理解すれば、ネットワークアプリケーション内での WebLogic Event の使い方を理解する上で役に立ちます。

トピックツリーの走査方法

どのようなアプリケーションでも、WebLogic Server にイベントを提出することができます。イベントは、そのスコープを限定する一連のイベントパラメータを付けて提出されます。イベントが提出されると、WebLogic Server は、トピックツリー内の特定のイベントに完全に一致するものを見つけようとします。それが見つかった場合、その EventTopic の EventRegistration が処理されます（次に説明します）。完全に一致するものが見つからない場合、またはその EventTopic への関心を登録したクライアントがない場合、そのイベントは、この時点で、送信されないものとみなされます。次いで、具体性の一段低い EventTopic までトピックツリーをさかのぼり、そのノードの EventRegistration が処理されます。この処理がトピックツリーの頂点に達するまで繰り返されます。

各 EventRegistration の処理方法

特定の EventTopic に関心がある各クライアントは、そのトピックに対する EventRegistration を登録済みでなければなりません。そのため、トピックツリー内の各 EventTopic は EventRegistration のリストを備えており、このリストには各クライアントがその EventTopic にどのように関心を持っているかが記述されています。ある EventTopic がある Event に一致すると、そのイベントトピックは各 EventRegistration を以下のように処理します。

EventTopic が Event に完全に一致する場合、その Event は EventRegistration によって評価されます（つまり、以下の条件は省かれます）。
ただし、これが実際にパブリッシュされたイベントよりも具体性の低いイベントトピックである場合、つまり、それがトピックツリーの上位にあるイベントトピックである場合には、以下の点が考慮されます。
- そのイベントがより具体的なイベントトピックに送信されなかった場合には、EventRegistration によって評価されます。
- そのイベントがより具体的なイベントトピックに送信された場合には、EventRegistration の sink フラグが考慮されます。

sink

登録には sink というフラグが付けられることがあります。これは、関心が登録されたすべてのイベントだけでなく、トピックツリー内でその登録より下位にあるもっと具体的なトピックに関連付けられているすべてののイベントも評価する機会が必ず与えられることを意味します（sink フラグを true に設定してルートトピック（*）を登録すると、WebLogic Server に提出されるすべてのイベントを評価する機会が保証されます。このような登録の evaluate メソッドが true を返すだけであれば、WebLogic Server に提出されるすべてのイベントに基づいて効率的に動作します）。

登録の sink フラグを false（デフォルト）に設定した場合、クライアントは、正確に一致するイベントが発生したときにのみ通知を受け取り、その分岐より下位のもっと具体的なイベントが発生したときには通知を受け取りません。ただし、この規則には以下のような例外があります。

sink フラグが false に設定されていても、そのイベントがより具体的なイベントトピックに正しく送信されなかった場合には、EventRegistration はより具体的なイベントを評価します。こうしたことは、その時点であるより具体的なイベントトピックに関心を登録しているクライアントがない場合に起こります。トピックは、クライアントがそのトピックへの関心を登録して初めてツリー内に存在するので、イベントを評価する際には注意しなければなりません。sink を false に設定しても、クライアントがそのトピックに関連するイベントだけを受け取るとはかぎりません。

イベントはこのようにして評価されるので、受信登録したクライアントがないイベントを捕捉する EventRegistration をセットアップすることができます。

EventRegistration によるイベントの評価方法

クライアントは、EventRegistration を通じてイベントへの関心を登録するときには、その EventRegistration に関連付けられる Evaluate オブジェクトを指定しなければなりません。一致する登録にイベントが到達すると、WebLogic Server はその Evaluate オブジェクトの evaluate() メソッドを呼び出します。Evaluate クラスはインタフェース weblogic.event.evaluators.EvaluateDef を実装するもので、必ずこのメソッドを実装します。通常はユーザが作成したクラスか、または Weblogic のデフォルトエバリュエータの 1 つです。Evaluate クラスは、サーバ上にインストールされなければならず、またサーバの CLASSPATH 内に含まれていなければなりません。

evaluate() メソッドには、イベントに付随するパラメータが渡されます。カスタムメソッドでは、これらのイベントパラメータを解析して、true か false のいずれかを返すことができます。true の場合には、phase が false に設定されていないかぎり、WebLogic Server は Action オブジェクトの action() メソッドを呼び出します。

phase

クライアントがトピックへの関心を登録する場合、phase を設定することがあります。これは、Action を呼び出すロジックを反転させるものです。たとえば、あるアプリケーションが、いつサンフランシスコの天気が晴れになるかに関心がある場合には、登録は以下のようになります。

トピックは weather.northamerica.california.sf です。
Evaluate パラメータは、SKYINDICATOR="fogginess"、INDICATORLEVEL="over"、および INDICATORVALUE="40%" です。
phase は false です。
これでこのロジックが反転されるので、このクライアントには、サンフランシスコで霧が出ていないときに通知が行われます。クライアントではこれが晴れを意味すると見込んでいます。

アクションプロセスの動作の仕組み

評価プロセスが成功すると、その登録のアクションクラスが呼び出されます。

アクションクラスはユーザが作成するクラスで、インタフェース weblogic.event.actions.ActionDef を実装しています。アクションクラスは、Java で記述可能なアクションのすべてを実行できます。アクションクラスの例は ActionEmail、ActionUDP、および ActionNull で、これらは weblogic.event.actions パッケージに入っています。

Action クラスは、関心の登録を発行した WebLogic クライアントに、エバリュエータが true を返したことを通知できます。クライアントサイドの通知の例については、以下を参照してください。

パラメータの詳細

パラメータには以下のものがあり、WebLogic Server 内のオブジェクトによって使われます。

登録管理。管理パラメータは登録管理に使われるもので、エバリュエータが呼び出される回数の制限やその他の管理上の詳細を設定します。
関心の登録。登録パラメータは名前=値の組の集合で、それらが全体としてイベントへの関心のスコープを定義します。これらのパラメータを使って、WebLogic Server はイベントをフィルタ処理して、イベントを評価すべきかどうかをさらに限定できます。登録は、常に一群の登録パラメータ（それ自体がその登録の管理パラメータのサブセット）を付けて、WebLogic Server に提出されます。
イベントパラメータ。イベントパラメータは、登録パラメータと同様に、イベントをさらに限定する一群の名前=値の組です。イベントは、常に一群のイベントパラメータを付けて WebLogic Server に提出されます。

パラメータは ParamSet オブジェクトとして作成され、それ自体が ParamSet の配列である場合もあります。ParamSet の各パラメータに関連付けられる値は ParamValue オブジェクトで、それ自体が ParamValue の配列である場合があります。