Oracle® Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSP の開発 11g リリース1 (10.3.5) B60993-03 |
|
前 |
次 |
次の項では、WebLogic Serverに含まれているHTTPパブリッシュ/サブスクライブ・サーバーの概要と、Webアプリケーションにおけるこのサーバーの使用方法を示します。
HTTPパブリッシュ/サブスクライブ・サーバー (pub-subサーバーともいう)は、WebクライアントがHTTPで非同期メッセージを使用してチャネルのサブスクライブおよびメッセージのパブリッシュを行うためのメカニズムです。
標準のWebアプリケーションの単純なリクエスト/レスポンス機能では、クライアントがすべての通信を開始する必要がありますが、この場合、サーバーは明示的なリクエストを受け取った場合に、更新されたデータをクライアントへプッシュすることしかできません。このメカニズムは、クライアントがリクエストした場合にのみサーバーからのデータが必要となるショッピング・カートなどの従来のアプリケーションには適していますが、クライアントが明示的にリクエストしていない場合でもサーバーがデータを送信する必要のあるチャット・ルームやオークションの更新などの動的かつリアルタイムなアプリケーションには不適切です。クライアントは従来のHTTPプル手法を使用して最新データを定期的にチェックおよび取得することができますが、この手法にはスケーラビリティがなく、チェックの重複によりネットワーク・トラフィックの増加につながります。HTTPパブリッシュ/サブスクライブ・サーバーは、クライアントによるチャネル(JMSでのトピックに相当)のサブスクライブとメッセージ(利用可能な場合)の受信を可能にすることにより、この問題を解決しています。
pub-subサーバーはBayeuxプロトコルに基づきます(http://svn.xantus.org/shortbus/trunk/bayeux/bayeux.html
を参照)。Bayeuxプロトコルには、クライアントとサーバーがHTTPを介して非同期メッセージで通信するための規約が定義されています。これによって、クライアントは、イベントのソースまたは指定されている宛先であるチャネルに対して登録およびサブスクライブすることができます。次に、登録されたクライアントまたはpub-subサーバー自体がこれらのチャネルへメッセージをパブリッシュすると、サブスクライブしているすべてのクライアントがそのメッセージを受信します。
pub-subサーバーはBayeuxプロトコルを理解するすべてのクライアントと通信することができます。pub-subサーバーは、クライアントの識別、信頼のネゴシエーション、Bayeuxメッセージの交換、そして最も重要なことですが、サブスクライブ済みクライアントへのイベント・メッセージのパブリッシュを担当します。
次の図は、WebLogic Serverに含まれているpub-subサーバーの基本的なアーキテクチャについて説明しています。
Webアプリケーションとpub-subサーバーは1対1の関係にあります。つまり、各Webアプリケーションは、1つの一意のpub-subサーバーへアクセスします。各pub-subサーバーには独自のチャネル・リストがあります。これは、同じエンタープライズ・アプリケーション内の異なるWebアプリケーションで同じ名前のチャネルが使用される場合があることを意味します。Webアプリケーションはコンテキスト・オブジェクトを使用して、関連付けられているpub-subサーバーへのハンドルを取得します。
pub-subサーバー自体はJava EEライブラリとして実装されます。このライブラリは、関連付けられているWebアプリケーションがweblogic.xml
デプロイメント記述子で参照します。
pub-subサーバーは独自のデプロイメント記述子weblogic-pubsub.xml
を持ちます。この記述子は、他のWebアプリケーション記述子と同じディレクトリ(WEB-INF
)に格納されます。開発者はこの記述子を使用して、pub-subサーバーの初期チャネルの構成、トランスポートおよびメッセージ・ハンドラの指定、およびユーザーの認証と認可の設定を行います。
Webアプリケーション開発者は必要に応じて、サーバー側のpub-sub APIをサーブレットやJavaクラスで使用し、pub-subサーバーのコンテキストの取得、チャネルの管理、およびクライアントとの間で送受信されるメッセージの管理を行うことができます。しかし、サーバー側のpub-sub APIは使用する必要はありません。たとえば、開発者はpub-subサーバーを使用して、Webアプリケーションにチャット機能を実装することができます。通常のチャット・アプリケーションでは、サーバー側で別途コーディングしなくても、クライアント自体ですべてのサブスクライブ/パブリッシュ・タスクを実行することができます。しかし、クライアントから受信するメッセージのモニター、収集、解釈などの追加手順をpub-subサーバーで実行する必要がある場合、開発者はサーバー側のpub-subサーバーAPIを使用して、こうした機能をプログラミングする必要があります。
Web 2.0 Ajaxクライアントがpub-subサーバーと通信するには、BayeuxプロトコルをサポートするJavaScriptライブラリがクライアント側で必要となります。pub-subサーバーでは、配布キットのサンプルの一部としてDojo JavaScriptライブラリ実装が提供されます。このDojo JavaScriptライブラリでは4つの異なるトランスポート手段が提供され、そのうちのlong-pollingおよびcallback-pollingがWebLogic pub-subサーバーでサポートされています。
JMSを使用してpub-subサーバーをクラスタリング環境で実行すると、クラスタの複数のノード間でメッセージを共有することができます。この場合、pub-subサーバーは原則的にメッセージ処理をJMSプロバイダに委任します。
メッセージは、ファイル・システムまたはデータベースなどの物理ストレージに永続化されるよう指定することもできます。メッセージはデフォルトでは永続化されません。
次の項では、pub-subサーバーのその他の情報について説明します。
チャネルは、クライアントがサブスクライブおよびメッセージをパブリッシュする対象の、指定された宛先です。プログラマは、weblogic-pubsub.xml
デプロイメント記述子ファイルを作成し、そのファイルを標準のweb.xml
およびweblogic.xml
ファイルと一緒にWebアプリケーションのWEB-INF
ディレクトリ内にパッケージ化することによって、初期チャネル、チャネル・マッピング、およびセキュリティを定義します。プログラマは必要に応じてpub-subサーバーAPIをサーブレットで使用し、チャネルを動的に検出、作成、および破棄することもできます。
クライアント側でチャネルを作成および破棄できるようにするかどうかは、プログラマが決定します。つまり、クライアントの認可に基づいてcreateおよびdestroyメソッドの使用を制約するようプログラミングしなければならない場合があります。認可されていないクライアントがチャネルを作成または破棄しようとすると、エラー・メッセージが生成されます。
pub-subサーバーが既存のチャネルを破棄すると、そのチャネルをサブスクライブ済みのすべてのクライアントと、そのチャネルのすべてのサブチャネルが自動的にアンサブスクライブされます。クライアントは、pub-subサーバーによるチャネルの破棄によってアンサブスクライブされると、pub-subサーバーから切断レスポンス・メッセージを受け取るため、その他のチャネルへの再接続および再サブスクライブを試行することができます。
チャネルのネームスペースは階層的です。つまり、*
および**
などのワイルドカードを使用したチャネル取得パターンによって、複数のチャネルをまとめてサブスクリプション対象として指定できます。クライアントは、ワイルドカード・パターンによってサブスクライブした後に作成されたすべてのチャネルに自動的に登録されます。
クライアントとpub-subサーバー間では、メッセージの配信順序は保証されません。つまり、pub-subサーバーがmessage1、message2の順にパブリッシュした場合、クライアントはその順番でメッセージを受け取る場合もあれば、その逆の順序で受け取る場合もあります。
Web上では、クライアントは本質的に疎結合であるため、pub-subサーバーがメッセージをパブリッシュしたときにサブスクライバがアクティブでないか接続されていない可能性があります。この場合のメッセージの配信動作には、以下のルールが適用されます。
クライアントにアクセスできない場合、pub-subサーバーがパブリッシュしたメッセージはそのクライアントに配信されません。
クライアントは、再接続時に「新たに」パブリッシュされたメッセージを引続き受信します。
パブリッシュ済みメッセージを回復するには、pub-subサーバーを永続メッセージ用に構成し、チャネルを永続チャネルとして構成する必要があります。
このトピックでは、簡単な例を使用してHTTP pub-subサーバーを使用する際の基本的な機能および必要となる作業について説明します。サンプルのWebアプリケーションに含まれる構成要素は以下のもののみです。
pub-sub J2EEライブラリを構成するためのweb.xml
デプロイメント記述子。
pub-subサーバー自体を構成するためのweblogic-pubsub.xml
デプロイメント記述子。
ユーザーによるサブスクライブおよびメッセージのパブリッシュを可能にするHTMLファイル。このHTMLファイルでは、プログラミング・モデルとしてDOJOクライアントJavaScriptライブラリを使用します。
このサンプルでは、pub-sub APIによるサーバー側のプログラミング手法は使われていません。
WebLogic Server配布キットには、より複雑なサンプルが含まれています。このサンプルでは、株取引に基づく実際のシナリオが表され、サーバーとクライアントの両方の構成要素内でpub-sub APIが幅広く活用されています。このサンプルではクライアント側のプログラミング・フレームワークとしてDojoが使用され、各自のテスト用にDojo JavaScriptライブラリの一部が提供されます。また、pub-subサーバーおよびクライアントへセキュリティを追加する方法も示されています。このサンプルは次のディレクトリにあります。
WL_HOME/samples/server/examples/src/examples/webapp/pubsub/stock
WL_HOME
は、メインのWebLogic Serverのインストール・ディレクトリ(/oraclehome/wlserver_10.3
など)です。
次に、HTTPパブリッシュ/サブスクライブ・サーバーを使用する高度な手順について説明します。
注意: この手順では、基本のWebアプリケーション、そのweb.xml およびweblogic.xml デプロイメント記述子ファイル、JSP、サーブレットをすでに作成しているものとします。Webアプリケーションの作成方法の詳細は、第3章「Webアプリケーションの作成と構成」を参照してください。 |
WEB-INF
ディレクトリにあるWebアプリケーションのweblogic.xml
デプロイメント記述子で、pub-subサーバーがバンドルされる共有Java EEライブラリ(pubsub
)への参照を追加します(コード内の太字を参照)。
<?xml version='1.0' encoding='UTF-8'?> <weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <library-ref> <library-name>pubsub</library-name> <specification-version>1.0</specification-version> </library-ref> </weblogic-web-app>
<library-ref>
のその他の子要素および共有Java EEライブラリに関する詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。
weblogic-pubsub.xml
ファイルを作成し、初期チャネルの構成、トランスポートおよびメッセージ・ハンドラの指定、ユーザーの認証および認可の設定を行います。「weblogic-pubsub.xmlファイルの作成」を参照してください。
pub-subサーバーによるチャネルへのメッセージのパブリッシュ、クライアントからのメッセージのフィルタ処理、またはチャネルの動的な作成あるいは破棄が必要な場合、サーブレットなどのWebアプリケーション・コンポーネントにJavaコードを追加します。この手順は省略可能です。「サーバー側のPub-Sub APIによるプログラミング」を参照してください。
クライアントから受け取るメッセージを事前処理する必要がある場合、メッセージ・フィルタ・チェーンをプログラミングおよび構成します。「メッセージ・フィルタ・チェーンの構成とプログラミング」を参照してください。
HTMLファイル、JSPなど、ブラウザ・クライアントを更新し、ユーザーがチャネルをサブスクライブし、メッセージを送受信できるようにします。「Pub-Subサーバーと通信するためのブラウザ・クライアントの更新」を参照してください。
更新済みの新しいデプロイメント記述子ファイルとブラウザ・クライアントを使用してWebアプリケーションを再アセンブルします。pub-subサーバー・コードを追加した場合は、サーブレットを再コンパイルします。
新しいweblogic-pubsub.xml
デプロイメント記述子を、web.xml
およびweblogic.xml
ファイルが格納されているWebアプリケーションの同じWEB-INFディレクトリに配置します。
Webアプリケーションのアセンブル方法に関する全般的な情報の詳細は、第3章「Webアプリケーションの作成と構成」を参照してください。
まだ実行していない場合、pub-subサーバーがバンドルされる共有Java EEライブラリWARファイルをデプロイします。この手順は、pub-subサーバーを使用するWebアプリケーションを再デプロイする前に実行しますが、実行するのはWebLogic Server全体に対して1回のみです。
pub-sub共有Java EEライブラリWARファイルpubsub-1.0.war
は、次のディレクトリにあります。
WL_HOME/common/deployable-libraries
WL_HOME
は、メインのWebLogic Serverのインストール・ディレクトリ(/oraclehome/wlserver_10.3
など)です。
管理コンソールまたはweblogic.Deployer
コマンド・ライン・ツールのいずれかを使用することができます。管理コンソールの使用手順については「Java EEライブラリのインストール」を、weblogic.Deployer
の使用方法の詳細は「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。
管理コンソールまたはweblogic.Deployer
コマンド・ライン・ツールを使用して、更新したWebアプリケーションを再デプロイします。
管理コンソールの使用手順については「Webアプリケーションのインストール」を、weblogic.Deployer
の使用方法の詳細は「weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ」を参照してください。
この時点で、ブラウザ・クライアントを使用してweblogic-pubsub.xml
ファイルで構成されているチャネルをサブスクライブし、メッセージを送受信することができます。
pub-subアプリケーションのプログラミング後に、そのアプリケーションの実行時情報をモニタリングする必要がある場合があります。詳細は、「Pub-Subサーバーおよびチャネルの実行時情報の取得」を参照してください。
実装可能なpub-subサーバーのより高度な機能については、次の項を参照してください。
weblogic-pubsub.xml
デプロイメント記述子は、pub-subサーバーの構成に使用するXMLファイルです。特に、初期チャネル、pub-subサーバーの構成プロパティ、およびチャネルをサブスクライブするクライアントのセキュリティ仕様を指定します。この情報の一部は、サーバー側のAPIを使用してpub-subサーバーによって実行時にリフレッシュできます。
デプロイメント記述子のルート要素は<wlps:weblogic-pubsub>
であり、wlps
ネームスペースはhttp://xmlns.oracle.com/weblogic/weblogic-pubsub
です。
weblogic-pubsub.xml
ファイルの要素の詳細については、このスキーマを参照してください。以下に、一般的に使用される要素の一部を示します。この節の最後に一般的なweblogic-pubsub.xml
ファイルの例を示します。
<wlps:server-config>
: pub-subサーバーを構成します。この要素の子要素には以下の要素があります。
<wlps:work-manager>
:クライアントへメッセージを配信するワーク・マネージャの名前を指定します。
<wlps:publish-without-connect-allowed>
: pub-subサーバーに明示的に接続せずに、クライアントでメッセージをパブリッシュするかどうかを指定します。
<wlps:supported-transport>
:サポートされているトランスポート方法を指定します。現時点でサポートされているトランスポート方法はlong-polling
およびcallback-polling
の2つです。
<wlps:client-timeout-secs>
:クライアントが接続/再接続メッセージを返信していない場合に、pub-subサーバーが接続を切断するまでの秒数を指定します。
<wlps:channel>
:初期チャネルを定義および構成します。この要素の子要素には以下の要素があります。
<wlps:channel-pattern>
:サーブレットURLパターンの指定と同様の方法でチャネル・パターンを指定します(/foo/bar, /foo/bar/*
、/foo/bar/**
など)。
<wlps:channel-persistence>
:チャネルを永続化するかどうかを指定します。詳細は、「高度なトピック:物理ストレージへのメッセージの永続化」を参照してください。
<wlps:jms-handler-name>
:チャネルで、デフォルトのハンドラではなく、JMSハンドラを使用するように指定します。詳細は、「高度なトピック:プロバイダとしてJMSを使用することによるクラスタのサポート」を参照してください。
<wlps:message-filter>
:メッセージ・フィルタ・チェーンを構成します。詳細は、「メッセージ・フィルタ・チェーンの構成とプログラミング」を参照してください。
<wlps:channel-constraints>
:特定のチャネルに対してどの操作をどのロールで実行できるかなど、チャネルのセキュリティを構成します。詳細は、「セキュリティの有効化」を参照してください。
<wlps:jms-handler-mapping>
: JMSハンドラを構成します。詳細は、「高度なトピック:プロバイダとしてJMSを使用することによるクラスタのサポート」を参照してください。
次のサンプルweblogic-pubsub.xml
ファイルでは、pub-subサーバーを使用するアプリケーションの簡単な構成を示します。詳細は、このサンプルの後の説明を参照してください。
<?xml version="1.0" encoding="UTF-8"?> <wlps:weblogic-pubsub xmlns:wlps="http://xmlns.oracle.com/weblogic/weblogic-pubsub"> <wlps:server-config> <wlps:publish-without-connect-allowed>true</wlps:publish-without-connect-allowed> <wlps:supported-transport/> <wlps:client-timeout-secs>100</wlps:client-timeout-secs> <wlps:persistent-client-timeout-secs>400</wlps:persistent-client-timeout-secs> <wlps:interval-millisecs>1000</wlps:interval-millisecs> <wlps:multi-frame-interval-millisecs>2000</wlps:multi-frame-interval-millisecs> </wlps:server-config> <wlps:channel> <wlps:channel-pattern>/chatrooms/**</wlps:channel-pattern> </wlps:channel> <wlps:channel-constraint> <wlps:channel-resource-collection> <wlps:channel-resource-name>all-permissions</wlps:channel-resource-name> <wlps:description>Grant all permissions for everything by everyone</wlps:description> <wlps:channel-pattern>/chatrooms/*</wlps:channel-pattern> </wlps:channel-resource-collection> </wlps:channel-constraint> </wlps:weblogic-pubsub>
上記の例では:
<wlps:server-config>
要素で、pub-subサーバー自体を構成しています。特に、この要素では、クライアントがpub-subサーバーに明示的に接続せずにメッセージをパブリッシュできること、および、クライアントが再接続メッセージを送信していない期間が100秒を超えるとサーバーがクライアントの接続を切断することを指定しています。<wlps:persistent-client-timeout-secs>
要素では、永続チャネルの場合に、クライアントの接続が切断されるまでの期間が最大400秒間であり、クライアントがこの間に再接続すると、それまでにパブリッシュされたメッセージを受信できることを指定しています。<wlps:interval-milliseconds>
要素では、クライアントが/meta/connectチャネルへの以降のリクエストを最大で1000ミリ秒間遅延できることを指定しています。最後に、<wlps:multi-frame-interval-millisecs>
要素では、マルチフレームの検出時に、クライアントが/meta/connectチャネルへの以降のリクエストを最大で2000ミリ秒間遅延できることを指定しています。
<wlps:channel>
要素で、ユーザーがサブスクライブ可能な1つの初期チャネルを構成しています。このチャネルはパターン/chatrooms/**
によって識別されます。このパターンはチャネル階層の最上位を表しています。
<wlps:channel-constraints>
要素で、/chatrooms/**
チャネルをどのように使用できるかに関するセキュリティ制約を指定しています。ここでは、すべてのチャネルに対するすべての操作に関して、すべてのユーザーにすべての許可が与えられています。
情報をモニターするため、またはサブスクライブ済みクライアントへパブリッシュされる前に受信データをインターセプトするために、pub-subサーバー自身がチャネルからメッセージを定期的に取得しなければならない場合があります。また、pub-subサーバーは、サブスクライブ済みのすべてのクライアントへ通知を行ったり、追加のサービスを提供するために、チャネルへ直接メッセージをパブリッシュしなければならない場合もあります。さらに、新しいチャネルを作成したり、既存のチャネルを破棄したりといった、チャネルのメンテナンスを行わなければならない場合もあります。
WebLogic Serverでは、これらのすべてのタスクを実行するために、com.bea.httppubsub
パッケージでpub-sub APIを提供しています。pub-subプログラマは、pub-subアプリケーションを格納するWebアプリケーションのサーブレットまたはPOJO (プレーンな従来型Javaオブジェクト)でこのAPIを使用します。APIを使用したプログラミングは省略可能であり、pub-subサーバーがクライアント側で標準のパブリッシュ/サブスクライブ以外のタスクを実行しなければならない場合にのみ必要となります。
次に、pub-subサーバーAPIの主なインタフェースおよびクラスについて説明します。
com.bea.httppubsub.PubSubServer
—これはpub-subサーバーAPI.の最も重要なインタフェースです。これは、現在のWebアプリケーションに関連付けられているpub-subサーバーのインスタンスを表します。関連付けられているpub-subサーバーを取得するには、現在のサーブレットのコンテキスト・パスを利用します。プログラマはこのインタフェースを使用して、チャネルの管理、pub-subサーバーのコ構成、およびチャネルへのパブリッシュとサブスクライブに使用されるローカル・クライアントの作成を行うことができます。
com.bea.httppubsub.LocalClient
—プログラマはPubSubServer
インタフェースを使用して現在のpub-subサーバーのインスタンスを作成したら、サーバー側のクライアント表現であるLocalClient
を作成する必要があります。このクライアントは、pub-subサーバーに常に接続されます。プログラマはこのクライアントを使用して、チャネルへのパブリッシュおよびサブスクライブを実行できます。ブラウザ・ベースのクライアントなどのリモート・クライアントは、com.bea.httppubsub.Client
インタフェースによって表します。
com.bea.httppubsub.ClientManager
—新しいLocalClient
を作成するためのインタフェースです。
com.bea.httppubsub.Channel
—チャネルとそのすべてのサブチャネルを表すインタフェースです。プログラマはこのインタフェースにより、チャネルおよびそのサブチャネルを現在サブスクライブしているクライアントの一覧の取得、チャネルへのメッセージのパブリッシュ、すべてのサブチャネルの一覧の取得、チャネルのサブスクライブまたはアンサブスクライブ、およびチャネルの破棄を実行することができます。
com.bea.httppubsub.MessageFilter
—クライアントがチャネルへパブリッシュするメッセージのインターセプトを行うメッセージ・フィルタを作成するためのインタフェースです。詳細は、「メッセージ・フィルタ・チェーンの構成とプログラミング」を参照してください。
com.bea.httppubsub.DeliveredMessageListener
—このインタフェースは、クライアント(リモート・クライアントまたはローカル・クライアント)がチャネルへメッセージをパブリッシュするたびに通知される、チャネルをリスニングするオブジェクトを作成するために使用します。
com.bea.httppubsub.BayeuxMessage
— pub-subサーバーとBayeuxクライアント間で交換されるメッセージを表すインタフェースです。
com.bea.httppubsub
パッケージにはこの他にもサポート・クラス、インタフェース、列挙、例外があります。詳細は、JavadocのHTTP Pub-Sub APIを参照してください。
以降の節では、チャネルへのメッセージのパブリッシュやサブスクライブなど、最も一般的なサーバー側のタスクをpub-sub APIを使用して実行する方法について説明します。サンプル・コードは、WL_HOME
/samples/server/examples/src/examples/webapp/pubsub/stock/src/stockWar
にある配布キットのpub-subサーバー・サンプルのJavaソース・ファイルから抜粋しています。WL_HOME
は、メインのWebLogic Serverのインストール・ディレクトリ(/oraclehome/wlserver_10.3
など)を示しています。
pub-subサーバーおよびそのチャネルでサーバー側のタスクを実行するには、pub-subサーバーを表すPubSubServer
オブジェクトを最初にインスタンス化してから、pub-subに代わってチャネルを操作するために使用するローカル・クライアントを作成する必要があります。
例として次のサンプル・コードがあります。
import com.bea.httppubsub.FactoryFinder; import com.bea.httppubsub.LocalClient; import com.bea.httppubsub.PubSubSecurityException; import com.bea.httppubsub.PubSubServer; import com.bea.httppubsub.PubSubServerException; import com.bea.httppubsub.PubSubServerFactory; import org.json.JSONObject; public class ApiBasedClient implements Client { private PubSubServer pubSubServer; private LocalClient localClient; public ApiBasedClient(String serverName) throws PubSubServerException { PubSubServerFactory pubSubServerFactory = (PubSubServerFactory)FactoryFinder.getFactory(FactoryFinder.PUBSUBSERVER_FACTORY); pubSubServer = pubSubServerFactory.lookupPubSubServer(serverName); localClient = pubSubServer.getClientManager().createLocalClient(); } ... }
FactoryFinder
クラスはPubSubServerFactory
の実装を検索し、この実装がPubSubServer
インスタンスの作成に使用されます。PubSubServerFactory
のlookupPubSubServer()
メソッドは、メソッドが実行されるサーブレットのコンテキスト・パスに基づいて、PubSubServer
インスタンスを返します。最後に、PubSubServer
インスタンスのClientManager
のcreateLocalClient()
メソッドがLocalClient
オブジェクトを返します。このオブジェクトは、チャネルのサブスクライブおよびチャネルへのパブリッシュを行うためにpub-subサーバーが使用します。
チャネルへメッセージをパブリッシュするには、次のサンプル・コードに示すように、PubSubServer.publishToChannel()
メソッドを使用して、LocalClient
オブジェクト、チャネル名、およびメッセージ・テキストを渡します。
public void publish(String channel, JSONObject data) throws IOException { try { pubSubServer.publishToChannel(localClient, channel, data.toString()); } catch (PubSubSecurityException e) { throw new IOException(e); } }
この例のチャネル変数には、/my/channel/**
などのチャネル名が含まれます。
publishToChannel()
メソッドは非同期であり、すぐに戻り値を返します。つまり、サブスクライブ済みクライアントがメッセージを受信するまで待機しません。
サーバー側からチャネルをサブスクライブするには2つの手順があります。
メッセージ・リスナーを作成し、LocalClient
に登録します。
チャネルを明示的にサブスクライブします。
メッセージ・リスナーは、DeliveredMessageListener
インタフェースを実装するクラスです。このインタフェースでは単一のコールバック・メソッドonPublish()
が定義されており、このメソッドは、ローカル・クライアントがメッセージを受信すると通知されます。このコールバック・メソッドは、ローカル・クライアントへの送信メッセージを表すDeliveredMessageEvent
インスタンスへ送信されます。
チャネルをサブスクライブするには、PubSubServer.subscribeToChannel()
メソッドを使用して、LocalClient
オブジェクトおよびチャネル名を渡します。
次のサンプル・コードでは、これらの両方の手順の例を示します。サンプル・コードの直後の説明を参照してください。
pubSubServer.subscribeToChannel(localClient, "/management/publisher"); localClient.registerMessageListener(new DeliveredMessageListener() { private InWebPublisher publisher = new InWebPublisher(contextPath); private boolean publishing = false; public void onPublish(DeliveredMessageEvent event) { Object payLoad = event.getMessage().getPayLoad(); if (payLoad instanceof String) { String command = (String)payLoad; if ("start".equals(command) && !publishing) { publisher.startup(); publishing = true; } else if ("halt".equals(command) && publishing) { publisher.halt(); publishing = false; } } } });
上記の例では:
pub-subサーバーは/management/publisher
というチャネルをサブスクライブしています。
メッセージ・リスナー・クラスは、LocalClient.registerMessageListener()
メソッド呼出し内に直接実装されています。
pub-subサーバー・アプリケーション開発者は、1つまたは複数のメッセージ・フィルタをプログラミングし、チャネルに対してそれらのフィルタを構成して、クライアントから届くメッセージをインターセプトしたり、特定の方法でメッセージを変換または追加処理することができます。メッセージ・フィルタ・チェーンは、1つのチャネルに複数のフィルタがアタッチされることを意味します。つまり、最初のフィルタとして構成されているフィルタがメッセージを事前処理し、2番目のフィルタとして構成されているフィルタにそのメッセージを渡す、などのように処理されます。この機能は、サーブレット2.3仕様で導入されたフィルタに似ています。
メッセージ・フィルタは、さまざまな理由から役立ちます。まず、メッセージ・フィルタを使用すると、再利用可能なユニットで反復タスクをカプセル化できます。2つ目として、メッセージ・フィルタでは、クライアントからのメッセージをpub-subサーバーが取得してチャネルのサブスクライバに送信する前に事前処理するための容易かつ一貫性のある手段が提供されることです。メッセージを事前処理するのは、受信データの検証、モニター情報の収集、pub-subアプリケーション・ユーザーの追跡、キャッシングなどを行うためです。
メッセージ・フィルタ・チェーンを実装するには、主に次の2つの手順があります。
チェーンの各フィルタには、ユーザーがプログラミングした独自のフィルタ・クラスが含まれている必要があります。このフィルタ・クラスはcom.bea.httppubsub.MessageFilter
インタフェースを実装する必要があります。MessageFilter
インタフェースには単一のメソッドhandleMessage(EventMessage)
があり、そのシグネチャは次のとおりです。
boolean handleMessage(EventMessage message);
com.bea.httppubsub.EventMessage
インタフェースは、JSON (JavaScript Object Notation) (http://www.json.org/を参照)エンコード・オブジェクトであるBayeaxMessage
を拡張します。JSONは、Bayeuxプロトコルで使用される軽量なデータ交換形式です。EventMessage
インタフェースでは、getPayload()
およびsetPayload()
の2つのメソッドが定義されています。これらのメソッドは、受信メッセージへのアクセス、およびそのメッセージの処理を行うために使用します。
handleMessage()
メッセージはboolean
値を戻すため、プログラマは、チェーン内の任意のフィルタ・クラスでfalse
を戻すことによって、メッセージ・フィルタ・チェーンにおける以降のすべてのプロセスに割込みをかけることができます。これによってフィルタ・プロセスが割り込まれるのみでなく、メッセージをチャネルのサブスクライバへ送信せずに、パブリッシュ元のクライアントへすばやく返信することができます。これは、プログラマにとって、受信メッセージに問題がないことを確認し、問題が検出された場合でも、そのメッセージがサブスクライバへパブリッシュされないようにすることができる優れた手段です。
以下に、MessageFilter
インタフェースの簡単な実装例を示します。
package msgfilters; public static class Filter1 implements MessageFilter { public boolean handleMessage(EventMessage message) { String msg = (String) message.getPayLoad(); message.setPayLoad("[" + msg.substring(1, msg.length()-1)); return true; } }
この例では、getPayload()
メソッドが、入力されたmessage
パラメータからString
メッセージを取得します。このmessage
は、クライアントから直接届くか(Filter1
がチェーン内で最初のフィルタとして構成されている場合)、別のフィルタ・クラスの結果です(Filter1
がチェーン内で最初のフィルタではない場合)。setPayLoad()
メソッドはメッセージをリセットしつつ、特定のデータ処理を実行しています。この例では、メッセージの最初の文字を[
に置換しています。
メッセージ・フィルタは、pub-subサーバーのweblogic-pubsub.xml
デプロイメント記述子で構成します。
最初に、ルート<wlps:weblogic-pubsub>
要素の<wlps:message-filter>
子要素を使用してメッセージ・フィルタを宣言します。次に、チェーン内の各フィルタの<wlps:message-filter>
要素を追加して特定のチャネルを構成します。<wlps:channel>
要素でのフィルタの構成順が、各フィルタの実行順になります。
次に、weblogic-pubsub.xml
デプロイメント記述子でメッセージ・フィルタを構成する方法の例を示します(関連する情報のみ示しています)。サンプルの後の説明を参照してください。
<?xml version="1.0" encoding="UTF-8"?> <wlps:weblogic-pubsub xmlns:wlps="http://xmlns.oracle.com/weblogic/weblogic-pubsub"> <wlps:server-config> ... </wlps:server-config> <wlps:message-filter> <wlps:message-filter-name>filter1</wlps:message-filter-name> <wlps:message-filter-class>msgfilters.Fiter1</wlps:message-filter-class> </wlps:message-filter> <wlps:message-filter> <wlps:message-filter-name>filter2</wlps:message-filter-name> <wlps:message-filter-class>msgfilters.Filter2</wlps:message-filter-class> </wlps:message-filter> <wlps:channel> <wlps:channel-pattern>/firstchannel/*</wlps:channel-pattern> <wlps:message-filter>filter1</wlps:message-filter> </wlps:channel> <wlps:channel> <wlps:channel-pattern>/secondchannel/*</wlps:channel-pattern> <wlps:message-filter>filter2</wlps:message-filter> <wlps:message-filter>filter1</wlps:message-filter> </wlps:channel> </wlps:weblogic-pubsub>
この例では、<wlps:message-filter>
要素を使用して2つのフィルタを宣言しています。filter1
はmsgfilters.Filter1
クラスで、filter2
はmsgfilters.Filter2
クラスで実装しています。
次に、/firstchannel/*
のパターンのチャネルがfilter1
で構成されています。これは、実行時に/firstchannel
の直接のサブチャネルにパブリッシュされたすべてのメッセージがmsgfilters.Filter1
クラスによって最初に処理されることを意味します。
/secondchannel/*
のパターンのチャネルは、filter2
およびfilter1
の2つのフィルタで構成されています。これらの2つのフィルタの構成順が重要となります。実行時には、/secondchannel
の直接のサブチャネルにパブリッシュされたすべてのメッセージがmsgfilters.Filter2
クラスによってインターセプトおよび処理され、この処理結果はmsgfilters.Filter1
に送信され、ここで独自の処理が行われた後、チャネルのサブスクライバに送信されます。
ブラウザまたはその他のWebベースのクライアントを更新してpub-subサーバーと通信するには、BayeuxプロトコルをサポートするJavaScriptライブラリを使用します。クライアント側のプログラミング・フレームワークには、Bayeuxプロトコルをサポートするものであれば任意のフレームワークを使用することができます。通常、このJavaScriptは、JSPやHTMLファイル、またはWebクライアントを実装するファイルに追加します。
この節では、クライアント側のプログラミング・フレームワークとしてDojoを使用してJSPを更新する例を示します。DojoはJavaScriptベースのツールキットであり、BayeuxプロトコルだけでなくAJAXもサポートします。WebLogic Serverでは、このツールキットを統合機能として提供していませんが、インストール済みのpub-subサンプルの一部としてライブラリのサブセットが含まれています。詳細については、「HTTPパブリッシュ/サブスクライブ・サーバーの使用例」を参照してください。
pub-subサーバーと通信するようにWebクライアントをプログラミングする際は、以下の主要な3つのタスクを実行する必要があります。
Dojo cometd環境を初期化します。
次に、この手順を実行するための標準的な方法の例を示します。
dojo.io.cometd.init({}, "/context/cometd");
context
は、pub-subアプリケーションをホストするWebアプリケーションのコンテキスト・パスを指します。この初期化手順では、接続のトランスポート・タイプを決定するためにpub-subサーバーとのハンドシェークを作成します。クライアントは、このハンドシェークに成功すると、pub-subサーバーに接続します。
初期化文字列のcometd
部分はpubsub
Java EEライブラリのデフォルトのサーブレット・マッピングを明示的にオーバーライドしない限り必須です。このマッピングは、ライブラリ自身のweb.xml
ファイルで定義されています。この実行方法の詳細については、「pubsub Java EEライブラリのデフォルト・サーブレット・マッピングのオーバーライド」を参照してください。
チャネルへメッセージをパブリッシュします。
メッセージは、単純な文字列メッセージやJSONメッセージの場合があります。次に、単純なメッセージのパブリッシュ方法の例を示します。
dojo.io.cometd.publish("/a/channel", "message content");
/a/channel
は、メッセージのパブリッシュ先チャネルの名前を指し、2つ目のパラメータはメッセージのテキストです。次に、JSONメッセージのパブリッシュ方法の例を示します。
dojo.io.cometd.publish("/a/channel", {"data": "content"});
この例の2つ目のパラメータには、任意のJSONオブジェクトを指定できます。
チャネルをサブスクライブします。
チャネルを実際にサブスクライブするには、コールバックJavaScript関数を実装しておく必要があります。この関数には任意の名前を付けることができます。この関数は、チャネルをサブスクライブする際に後で参照します。次に、onUpdate
というJavaScript関数を実装する方法の例を示します。
function onUpdate(message) { if (!message.data) { alert("bad message format "+message); return; } // fetch the data published by other clients var data = message.data; }
チャネルを実際にサブスクライブするには、次のJavaScriptを使用します。
dojo.io.cometd.subscribe("/a/channel", null, "onUpdate");
/a/channel
はサブスクライブ対象チャネルを指し、onUpdate
は定義済みのコールバックJavaScript関数の名前です。
この項では、Dojoツールキットを使用してWebベースのクライアントを更新し、WebLogic pub-subサーバーと通信する方法に関する最小限の情報のみ提供しています。詳細は、http://www.dojotoolkit.org/documentation
を参照してください。
pubsub
Java EEライブラリのweb.xml
では、次に示すように、pub-subサーバーを実装する、PubSubServlet
と呼ばれる内部サーブレットが定義されています。
<web-app>
<servlet>
<servlet-name>PubSubServlet</servlet-name>
<servlet-class>com.bea.httppubsub.servlet.ControllerServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>PubSubServlet</servlet-name>
<url-pattern>/cometd/*</url-pattern>
</servlet-mapping>
</web-app>
太字のコードで示すように、PubSubServletのURLパターンは/cometd/*
です。これが、pub-subサーバーと通信するWebクライアントを初期化する際に/mywebapp/cometd
などの文字列をデフォルトで使用しなければならない理由です。
このデフォルトURLパターンをオーバーライドするには、次のようなコードでWebアプリケーションのweb.xml
ファイルを更新します。
<servlet-mapping> <servlet-name>PubSubServlet</servlet-name> <url-pattern>/web2/*</url-pattern> </servlet-mapping>
これによって、Dojoを使用してWebクライアントを初期化する際に、cometd
ではなく、この新しいURLパターンを指定することができます。
dojo.io.cometd.init({}, "/context/web2");
pub-subサーバーは、すべての実行時監視情報をJava Management Extensions (JMX) MBeanを使用して公開します。実行時に収集可能な情報の例として、登録済クライアントの詳細、チャネルのサブスクリプション数、メッセージ数などがあります。
pub-subサーバーでは、次の2種類の実行時MBeanを使用します。
weblogic.management.runtime.WebPubSubRuntimeMBean
— pub-subサーバー自体の実行時情報をカプセル化します。このMBeanを使用して取得可能なpub-subサーバーに関する情報の例として、関連付けられているWebアプリケーションのコンテキスト・ルートおよび構成済のチャネルのハンドルがあります。
weblogic.management.runtime.ChannelRuntimeMBean
— pub-subサーバーに対して構成されているチャネルに関する情報をカプセル化します。このMBeanを使用して取得可能なチャネルに関する情報の例として、このチャネルへパブリッシュされたメッセージの数、現在のサブスクライバ数、およびサブスクライバの一覧があります。
どちらのMBeanもWebLogic Server MBeanツリーに登録され、そのツリーを移動することによってアクセスできます。具体的には、WebPubSubRuntimeMBean
は現在のWebアプリケーションのWebAppComponentRuntimeMBean
の下に、すべてのChannelRuntimeMBean
はWebPubSubRuntimeMBean
の下に登録されます。
これらのMBeanの詳細は、WebLogic Server MBeanリファレンスの左側のペインにある「Runtime MBeans」ノードをオープンします。実行時MBeanがアルファベット順にリストされています。
JMX MBeanのプログラミングに関する全般的な情報については、『Oracle WebLogic Server JMXによる管理の容易なアプリケーションの開発』を参照してください。
pub-subサーバーでは、以下のセキュリティ機能が提供されます。
次の項では、これらの機能の使用方法について説明します。
pub-subサーバーでは、チャネル制約と認可制約という2つのメカニズムを組み合わせてチャネルを保護する機能が提供されます。
チャネル制約は、概念的には、保護対象のリソースの集合と、必要に応じてその集合内の特定のリソースに関する認可制約を格納するコンテナです。認可制約は、WebLogic Serverのロールおよびポリシーを表し、「この集合内のこのリソースに対して特定の操作を実行できるのは誰か」といった問いに答えます。
pub-sub制約は、構成ファイルのweblogic-pub-sub.xml
で指定します。pub-subサーバーは、weblogic-pub-sub.xml
構成ファイルのチャネル制約および認可制約を使用し、チャネルに対してロールおよびポリシーを設定します。
例として、例 12-1に示すサンプルを考えます。重要な箇所は太字で示しています。
例 12-1 Pub/Sub制約
<wlps:channel-constraint> <wlps:channel-resource-collection> <wlps:channel-resource-name>publish</wlps:channel-resource-name> <wlps:description>publish channel constraint</wlps:description> <wlps:channel-pattern>/stock/* *</wlps:channel-pattern> <wlps:channel-pattern>/management/publisher</wlps:channel-pattern> <wlps:channel-operation>publish</wlps:channel-operation> </wlps:channel-resource-collection> <wlps:auth-constraint> <wlps:description>publisher</wlps:description> <wlps:role-name>publisher</wlps:role-name> </wlps:auth-constraint> </wlps:channel-constraint>
この例では、/stock/* *
チャネルと/management/publisher
チャネルに対して操作publish
を実行できるのが、WebLogic Serverロールpublisher
を持つユーザーに限定されています。
チャネルに関しては、以下の4種類のアクション(操作)が許可されています。
create
delete
subscribe
publish
subscribe操作はデフォルトで(チャネル制約が定義されていない場合)、どのようなユーザーがどのチャネルに対しても実行することができます。
同様に、create、delete、およびpublish操作はデフォルトで、どのようなユーザーがどのチャネルに対しても実行することはできません。create、delete、およびpublish操作は、チャネル制約で明示的に構成されている場合にのみ許可されます。
特定のロールに対して任意のチャネル操作へのアクセスを指定するには、<wlps:channel-operation>
と<wlps:auth-constraint>
を組み合わせて使用します。
たとえば、例 12-2では、publish操作が、publisherロールを持つ認証される対象に対しては許可され、その他のすべてのロールに対しては許可されていません。
例 12-2 publisherロールの制約
<wlps:channel-constraint> <wlps:channel-resource-collection> <wlps:channel-resource-name>publish</wlps:channel-resource-name> <wlps:description>publish channel constraint</wlps:description> <wlps:channel-pattern>/stock/* *</wlps:channel-pattern> <wlps:channel-pattern>/management/publisher</wlps:channel-pattern> <wlps:channel-operation>publish</wlps:channel-operation> </wlps:channel-resource-collection> <wlps:auth-constraint> <wlps:description>publisher</wlps:description> <wlps:role-name>publisher</wlps:role-name> </wlps:auth-constraint> </wlps:channel-constraint>
空の認可制約(<wlps:auth-constraint>
</wlps:auth-constraint>
)を指定すると、指定したチャネル操作(<wlps:channel-operation>
が指定されていない場合はすべてのチャネル操作)に対して、すべてのアクセスが禁止されます。
したがって、すべてのユーザーに対してチャネルに対するすべての操作を制限するには、次に示すように、weblogic-pub-sub.xml
構成ファイルに空の<wlps:auth-constraint>
要素を含めて設定します。
<wlps:channel-constraint> <wlps:channel-resource-collection> <wlps:description>Restrict All Acesss</wlps:description> <wlps:channel-pattern>/**</wlps:channel-pattern> </wlps:channel-resource-collection> <wlps:auth-constraint> </wlps:auth-constraint> </wlps:channel-constraint>
チャネル制約内に認可制約がない場合、指定したチャネル操作(<wlps:channel-operation>
が指定されていない場合はすべてのチャネル操作)に対してアクセスが制限されません。
一方、空の認可制約(<wlps:auth-constraint> </wlps:auth-constraint>
)を指定すると、指定したチャネル操作(<wlps:channel-operation>
が指定されていない場合はすべてのチャネル操作)に対して、すべてのアクセスが禁止されます。
したがって、すべてのユーザーに対してチャネルに対するすべての操作を許可するには、次に示すように、weblogic-pub-sub.xml
構成ファイルに<wlps:channel-operation>
または<wlps:auth-constraint>
要素を含めずに設定します。
<wlps:channel-constraint> <wlps:channel-resource-collection> <wlps:description>All Acesss</wlps:description> <wlps:channel-pattern>/**</wlps:channel-pattern> </wlps:channel-resource-collection> <!-- Not defining an auth-constraint will open up access to everyone --> </wlps:channel-constraint>
注意: pub-subサーバーは認証を直接行いません。かわりに、pub-subサーバーはWebLogic Server (サーブレット・コンテナ)の最上位で動作し、WebLogic認証サービスを利用します。具体的には、pub-subサーバーは、特定のクライアントからのリクエストに対して、現在認証されているユーザー(匿名ユーザー)を利用します。 |
主要なpub-subセキュリティ・メカニズムは認可です。前述したように、pub-subサーバーは<wlps:channel-operation>
要素と<wlps:auth-constraint>
要素を組み合わせてチャネルに対するロールおよびポリシーの設定を行います。各bayeuxパケットは、1つのbayeuxリクエストに対応します。1つのHTTPリクエストは、1つまたは複数のbayeuxリクエストに変換されます。WebLogic Server (サーブレット・コンテナ)はHTTPリクエストに対して認可チェックを何度か実行し、pub-subサーバーは各bayeuxリクエストに対して認可チェックを1回実行します。
pub-sub認可を設定するにはロール名(weblogic-pub-sub.xml
ファイルで<wlps:role-name>
some-role-name
</wlps:role-name>
として指定)をプリンシパル名にマップする必要があります。これには、weblogic.xml
ファイルで構成されたsecurity-role-assignment
要素を使用します。
注意: weblogic.xml ファイルにこのようなマッピングがない場合、そのロールは暗黙的に使用され、警告が生成されます。 |
「security-role-assignment」
で説明しているように、security-role-assignment
要素は、WebLogic Serverセキュリティ・レルム内の1つまたは複数のプリンシパルとセキュリティ・ロール間のマッピングを宣言します。
例 12-3は、security-role-assignment
要素を使用してプリンシパルをpublisherロールに割り当てる方法を示しています。
デフォルトでは、すべてのpub-sub通信はHTTPを介します。ただし、web.xml
ファイルの変更により、pub-subサーバーがSSLを要請するように構成できます。SSLを要請すると、pub-subサーバーとWeb 2.0クライアント間のすべての通信がSSLを介して行われます。
WebLogic Serverは、INTEGRALまたはCONFIDENTIALトランスポート保証(web.xml
ファイルで指定)を使用してユーザーが認証を受けた場合にSSL接続を確立します。例 12-4では、トランスポート保証がINTEGRALに設定されています。
例 12-4 web.xmlによるSSLの要請
<security-constraint>
<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/cometd/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>INTEGRAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
この項では、以下のpub-subセキュリティに関するその他の考慮事項について説明します。
WebLogic Serverでは、セッション・データを失うことなく、HTTPを使用して開始されたセッションでHTTPSリソースにユーザーが安全にアクセスできます。この機能を有効にするには、config.xml
のWebServer要素にAuthCookieEnabled="true"を追加します。
<WebServer Name="myserver" AuthCookieEnabled="true"/>
AuthCookieEnabledをtrue (デフォルト設定)に設定すると、新しいセキュアなCookie(_WL_AUTHCOOKIE_JSESSIONID)が、HTTPS接続を介した認証時にブラウザに送信されるようになります。一度セキュアなCookieが設定されると、セッションはそのCookieがブラウザから送信された場合しかセキュリティ制約のある他のHTTPSリソースにアクセスできません。
注意: この機能はCookieが無効になっていても動作します。WebLogic Serverでは、URL中のauthCookieIDをJSESSIONIDとともにエンコードするために、セキュアな接続でのURL書換えを使用してセキュアなURLを書き換えるためです。 |
この項では、pub-subサーバーをロックして権限のないアクセスを防ぐ方法について説明します。ここで説明する手順では、アクセスの制限と引換えに追加のセキュリティを提供します。現在の環境に適したセキュリティ・レベルを決定してください。
pub-subサーバーをロックするには、次の手順に従います。
pub-sub通信に対してSSLを構成します。「パブリッシュ/サブスクライブ通信でのSSLの構成」を参照してください。
認証(BASIC、FORMなど)を要求します。
WebLogic Serverでは、Webアプリケーションに要求される認証方式をweb.xml
ファイルで設定します。
以下の例では、HTTP BASIC認証方式が要求されています。
<login-config> <auth-method>BASIC</auth-method> <realm-name>default</realm-name> </login-config>
auth-cookieがWebアプリケーションで有効化されていることを確認します。「AuthCookieEnabledによるリソースへのアクセス」を参照してください。
すべてのチャネルがweblogic-pubsub.xml
ファイルで制約されていることを確認します。
デフォルトで許可されているsubscribe操作をロックします。
<wlps:channel-constraint> <wlps:channel-resource-collection> <wlps:channel-resource-name>publish</wlps:channel-resource-name> <wlps:description>publish channel constraint</wlps:description> <wlps:channel-pattern>/stock/*</wlps:channel-pattern> <wlps:channel-pattern>/management/publisher</wlps:channel-pattern> <wlps:channel-operation>publish</wlps:channel-operation> </wlps:channel-resource-collection> <wlps:auth-constraint> <wlps:description>publisher</wlps:description> <wlps:role-name>publisher</wlps:role-name> </wlps:auth-constraint> </wlps:channel-constraint> <wlps:channel-constraint> <wlps:channel-resource-collection> <wlps:channel-resource-name>subscribe</wlps:channel-resource-name> <wlps:description>subscribe channel constraint</wlps:description> <wlps:channel-pattern>/stock/*</wlps:channel-pattern> <wlps:channel-operation>subscribe</wlps:channel-operation> </wlps:channel-resource-collection> <wlps:auth-constraint> <wlps:description>subscriber</wlps:description> <wlps:role-name>subscriber</wlps:role-name> </wlps:auth-constraint> </wlps:channel-constraint>
pub-subサーバー・アプリケーションは、スケーラビリティとサーバーのフェイルオーバー機能を提供できるように、WebLogic Serverのクラスタリング環境で動作できます。しかし、pub-subアプリケーションの動作は、パブリッシュされたメッセージを処理するメッセージ・ハンドラ(pub-subサーバー自体またはJMSプロバイダ)によって異なります。デフォルトの非JMSの場合、pub-subサーバーがすべてのメッセージを処理し、各クラスタ・ノード上のpub-subサーバーの各インスタンスは独立かつ孤立しています。これは、異なるサーバー・インスタンス間でイベント・メッセージを共有できないことを意味します。たとえば、クラスタのノードA上のチャネル/chat
をサブスクライブしているクライアントは、同じクラスタのノードB上のチャネル/chat
にパブリッシュされたメッセージを受信することができません。
クラスタのすべてのノードにパブリッシュされたすべてのメッセージを、特定のチャネルをサブスクライブしているすべてのクライアントが共有できるようにするには、そのチャネルをJMS用に構成する必要があります。これは、アプリケーションのweblogic-pubsub.xml
デプロイメント記述子内の適切な<wlps:channel>
要素を更新して行います。
JMSが構成されたチャネルへクライアントがメッセージをパブリッシュすると、pub-subサーバーはそのメッセージをJMSトピックに再送します。JMSトピックからのメッセージは、クラスタの各ノードで実行されているJMSメッセージ・リスナーが取得した上で、ノード上のサブスクライブ済みクライアントへ配信します。
JMSをアプリケーションのメッセージ・ハンドラとして構成するには、pub-subサーバーのweblogic-pubsub.xml
デプロイメント記述子を使用します。
まず、ルート<wlps:weblogic-pubsub>
要素の<wlps:jms-handler-mapping>
子要素を使用して、JMSハンドラの構成を宣言します。ここに、JMSプロバイダのURL、接続ファクトリJNDI名、およびJMSトピックJNDI名を指定します。次に、<wlps:jms-handler-name>
子要素を追加して、特定のチャネルがJMSチャネルになるよう構成します。
以下に、JMSハンドラとチャネルをweblogic-pubsub.xml
デプロイメント記述子で構成する方法の例を示します(関連箇所のみ太文字で示しています)。サンプルの後の説明を参照してください。
注意: この項では、JMSプロバイダを構成済で、pub-sub JMSチャネルに使用される接続ファクトリおよびトピックを作成済であるものとします。WebLogic JMSの詳細は、『Oracle WebLogic Server JMSのプログラミング』または使用しているプロバイダのドキュメントを参照してください。 |
<?xml version="1.0" encoding="UTF-8"?> <wlps:weblogic-pubsub xmlns:wlps="http://xmlns.oracle.com/weblogic/weblogic-pubsub"> <wlps:server-config> ... </wlps:server-config> <wlps:jms-handler-mapping> <wlps:jms-handler-name>DefaultJmsHandler</wlps:jms-handler-name> <wlps:jms-handler> <wlps:jms-provider-url>t3://localhost:7001</wlps:jms-provider-url> <wlps:connection-factory-jndi-name>ConnectionFactoryJNDI</wlps:connection-factory-jndi-name> <wlps:topic-jndi-name>TopicJNDI</wlps:topic-jndi-name> </wlps:jms-handler> </wlps:jms-handler-mapping> <wlps:channel> <wlps:channel-pattern>/chat/**</wlps:channel-pattern> <wlps:jms-handler-name>DefaultJmsHandler</wlps:jms-handler-name> </wlps:channel> </wlps:weblogic-pubsub>
上記の例では:
<wlps:jms-handler-mapping>
要素で、DefaultJmsHandler
という名前のJMSハンドラを定義しています。<wlps:jms-handler>
子要素では、pub-subサーバーがJMSトピックにメッセージを委託する際に使用するDefaultJmsHandler
の特定のプロパティを構成しています。具体的には、JMSプロバイダのJNDIツリーにアクセスするためにpub-subサーバーで使用されるJMSプロバイダURLがt3://localhost:7001
であり、接続ファクトリJNDI名がConnectionFactoryJNDI
であり、メッセージの委託先トピックのJNDI名がTopicJNDI
です。
<wlps:channel>
の<wlps:jms-handler-name>
子要素では、/chat
のパターンのチャネルが実際には、DefaultJmsHandler
で指定されるJMS構成オプションを持つJMSチャネルであることが指定されています。
weblogic-pubsub.xml
デプロイメント記述子に指定できるJMSハンドラに関連するXML要素の一覧は、weblogic-pubsub.xsd
スキーマ(http://xmlns.oracle.com/weblogic/weblogic-pubsub/1.0/weblogic-pubsub.xsd
)を参照してください。
サーバーのフェイルオーバーに加え、pub-subサーバーでは、クラスタリング環境におけるクライアント・セッションのフェイルオーバーもサポートします。クライアント・フェイルオーバーでは、チャネルのサブスクライブ時またはアンサブスクライブ時など、クライアントのステータスが変化すると、レプリケートされたHTTPセッション内にクライアントの最新ステータスが格納されます。クラスタ内の1つのノードがクラッシュすると、クラッシュしたノード上のクライアントは、レプリケートされたHTTPセッションを利用して別の利用可能なノードに移動され、回復が試行されます。
クライアント・セッション・フェイルオーバーを構成するには、次に示すように、pub-subアプリケーションをホストするWebアプリケーションのweblogic.xml
デプロイメント記述子ファイルで、ルート<weblogic-web-app>
要素に<session-descriptor>
子要素を追加し、永続ストアのタイプとしてreplicated_if_clustered
を指定します(関連箇所のみ太字で示しています)。
<?xml version='1.0' encoding='UTF-8'?> <weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ... <session-descriptor> <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor> </weblogic-web-app>
特定のチャネルへパブリッシュされたメッセージを永続化するには、そのチャネルを永続チャネルとして構成する必要があります。この場合、このチャネルにパブリッシュされるすべてのメッセージは、データベースまたはファイル・システムなどの物理記憶域へ永続化されます。具体的には、この物理記憶域は、事前構成済WebLogic永続ストアである必要があります。WebLogicの永続ストアは、永続性を必要とするWebLogic Serverのサブシステムおよびサービスに対し、組込みの高性能ストレージ・ソリューションを提供します。永続ストアは、ファイルベースのストアまたはJDBC対応データベースの永続性をサポートします。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使用方法に関する項を参照してください。
Oracleでは、永続メッセージを格納するためのファイルまたはJDBCストアを独自に作成し、このストアを永続チャネル用に構成することをお薦めします。ただし、構成された名前のストアが検出されない場合は、メッセージの格納にはデフォルトのWebLogic永続ストアが使用され、警告メッセージがログ・ファイルに記録されます。
永続ストア内のメッセージは無期限には保存されず、構成された最大存続期間プロパティに基づき、その期間の経過後にストアから古いメッセージが定期的に削除されます。この最大期間のデフォルト値は3600秒ですが、永続チャネルごとに異なる値を構成することができます。
永続チャネルをサブスクライブするクライアントは、永続クライアントと呼ばれます。通常のクライアントとの主な違いは、pub-subサーバーによるタイムアウトの処理方法にあります。pub-subサーバーを構成する際は、2つの異なるタイムアウト構成オプションを使用できます; 以下の要素は、weblogic-pubsub.xml
ファイルの<wlps:server-config>
の子要素です:
<wlps:client-timeout-secs>
—通常の(非永続)クライアントが接続/再接続メッセージ送信しない場合に、削除(永続クライアントの場合は非アクティブ化)されるまでの秒数を指定します。非アクティブ化時には、そのクライアントがサブスクライブ済みの永続チャネルはすべて保持され、非永続チャネルはアンサブスクライブされます。デフォルト値は60秒です。
<wlps:persistent-client-timeout-secs>
—永続クライアントが接続/再接続メッセージ送信しない場合に、接続が切断および削除されるまでの秒数を指定します。この要素には、client-timeout-secs
より大きな値を指定する必要があります。永続クライアントは、この永続タイムアウト値に達する前に再接続した場合はその期間内に永続チャネルにパブリッシュされたすべてのメッセージを受信できますが、このタイムアウト値より後に再接続した場合はそれらのメッセージを受信できません。デフォルト値は600秒です。
永続チャネルは、pub-subサーバーのweblogic-pubsub.xml
デプロイメント記述子ファイルで構成します。
まず、デフォルトの永続タイムアウト値の600秒を変更する場合は、<wlps:server-config>
の<wlps:persistent-client-timeout-secs>
子要素を追加してpub-subを構成します。次に、<wlps:channel>
の<wlps:channel-persistence>
子要素を追加して永続チャネルを構成し、そのチャネルのメッセージが保持される最大期間と、メッセージの格納先となる永続ストアの名前を指定します。次の例では、weblogic-pubsub.xml
ファイルの関連箇所を示します。
<?xml version="1.0" encoding="UTF-8"?> <wlps:weblogic-pubsub xmlns:wlps="http://xmlns.oracle.com/weblogic/weblogic-pubsub"> <wlps:server-config> ... <wlps:persistent-client-timeout-secs>400</wlps:persistent-client-timeout-secs> </wlps:server-config> <wlps:channel> <wlps:channel-pattern>/chat/**</wlps:channel-pattern> <wlps:channel-persistence> <wlps:max-persistent-message-duration-secs>3000</wlps:max-persistent-message-duration-secs> <wlps:persistent-store>PubSubFileStore</wlps:persistent-store> </wlps:channel-persistence> </wlps:channel> </wlps:weblogic-pubsub>
上記の例では:
永続クライアントのタイムアウト値が400秒です。この値は、このpub-subサーバーのすべての永続チャネルに適用されます。
/chat
のパターンのチャネルとそのすべてのサブチャネルが、永続チャネルとして構成されています。メッセージは、PubSubFileStore
という名前のWebLogic永続ストアに格納され、そのストア内で最大3000秒間存続します。
PubSubFileStore
は、WebLogic Server管理コンソールを使用してすでに作成し、構成しているものとします。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使用方法に関する項を参照してください。