12 HTTPパブリッシュ/サブスクライブ・サーバーの使用

この章では、WebLogic WebアプリケーションでWebLogic Server 12.1.3に含まれているHTTPパブリッシュ・サブスクライブ・サーバーを使用する方法について説明します。

この章の内容は以下のとおりです。

• HTTPパブリッシュ/サブスクライブ・サーバーの概要

• HTTPパブリッシュ/サブスクライブ・サーバーの使用例

• HTTPパブリッシュ/サブスクライブ・サーバーの使用: 標準の手順

• Pub-Subサーバーおよびチャネルの実行時情報の取得

• セキュリティの有効化

• 高度なトピック: プロバイダとしてJMSを使用することによるクラスタのサポート

• 高度なトピック: 物理ストレージへのメッセージの永続化

HTTPパブリッシュ/サブスクライブ・サーバーの概要

HTTPパブリッシュ/サブスクライブ・サーバー(pub-subサーバーともいう)は、WebクライアントがHTTPで非同期メッセージを使用してチャネルのサブスクライブおよびメッセージのパブリッシュを行うためのメカニズムです。

標準のWebアプリケーションの単純なリクエスト/レスポンス機能では、クライアントがすべての通信を開始する必要がありますが、この場合、サーバーは明示的なリクエストを受け取った場合に、更新されたデータをクライアントへプッシュすることしかできません。このメカニズムは、クライアントがリクエストした場合にのみサーバーからのデータが必要となるショッピング・カートなどの従来のアプリケーションには適していますが、クライアントが明示的にリクエストしていない場合でもサーバーがデータを送信する必要のあるチャット・ルームやオークションの更新などの動的かつリアルタイムなアプリケーションには不適切です。クライアントは従来のHTTPプル手法を使用して最新データを定期的にチェックおよび取得することができますが、この手法にはスケーラビリティがなく、チェックの重複によりネットワーク・トラフィックの増加につながります。HTTPパブリッシュ/サブスクライブ・サーバーは、クライアントによるチャネル(JMSでのトピックに相当)のサブスクライブとメッセージ(利用可能な場合)の受信を可能にすることにより、この問題を解決しています。

pub-subサーバーはBayeuxプロトコルに基づきます(http://archive.is/http://svn.cometd.com/trunk/bayeux/bayeux.htmlを参照)。Bayeuxプロトコルには、クライアントとサーバーがHTTPを介して非同期メッセージで通信するための規約が定義されています。これによって、クライアントは、イベントのソースまたは指定されている宛先であるチャネルに対して登録およびサブスクライブすることができます。次に、登録されたクライアントまたはpub-subサーバー自体がこれらのチャネルへメッセージをパブリッシュすると、サブスクライブしているすべてのクライアントがそのメッセージを受信します。

pub-subサーバーはBayeuxプロトコルを理解するすべてのクライアントと通信することができます。pub-subサーバーは、クライアントの識別、信頼のネゴシエーション、Bayeuxメッセージの交換、そして最も重要なことですが、サブスクライブ済みクライアントへのイベント・メッセージのパブリッシュを担当します。

次の図は、WebLogic Serverに含まれているpub-subサーバーの基本的なアーキテクチャについて説明しています。

図12-1 WebLogic ServerのHTTPパブリッシュ/サブスクライブ・サーバー

「図12-1 WebLogic ServerのHTTPパブリッシュ/サブスクライブ・サーバー」の説明

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パブリッシュ/サブスクライブ・サーバーの使用例

このトピックでは、簡単な例を使用してHTTP pub-subサーバーを使用する際の基本的な機能および必要となる作業について説明します。サンプルのWebアプリケーションに含まれる構成要素は以下のもののみです。

• pub-sub Java EEライブラリを構成するためのweb.xmlデプロイメント記述子。

• pub-subサーバー自体を構成するためのweblogic-pubsub.xmlデプロイメント記述子。

• ユーザーによるサブスクライブおよびメッセージのパブリッシュを可能にするHTMLファイル。このHTMLファイルでは、プログラミング・モデルとしてDOJOクライアントJavaScriptライブラリを使用します。

このサンプルでは、pub-sub APIによるサーバー側のプログラミング手法は使われていません。

WebLogic Server配布キットには、必要に応じてより複雑なサンプルが含まれています。このサンプルでは、株取引に基づく実際のシナリオが表され、サーバーとクライアントの両方の構成要素内でpub-sub APIが幅広く活用されています。このサンプルではクライアント側のプログラミング・フレームワークとしてDojoが使用され、各自のテスト用にDojo JavaScriptライブラリの一部が提供されます。また、pub-subサーバーおよびクライアントへセキュリティを追加する方法も示されています。このサンプルは次のディレクトリにあります。

EXAMPLES_HOME/wl_server/examples/src/examples/webapp/pubsub/stock

EXAMPLES_HOMEは、WebLogic Serverサンプル・コードが構成されているディレクトリを表します。WebLogic Serverサンプル・コードの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

HTTPパブリッシュ/サブスクライブ・サーバーの使用: 標準の手順

次に、HTTPパブリッシュ/サブスクライブ・サーバーを使用する高度な手順について説明します。

注意: この手順では、基本のWebアプリケーション、そのweb.xmlおよびweblogic.xmlデプロイメント記述子ファイル、JSP、サーブレットをすでに作成しているものとします。Webアプリケーションの作成方法については、「Webアプリケーションの作成と構成」を参照してください。

1. 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ライブラリおよびオプション・パッケージの作成に関する項を参照してください。

2. weblogic-pubsub.xmlファイルを作成し、初期チャネルの構成、トランスポートおよびメッセージ・ハンドラの指定、ユーザーの認証および認可の設定を行います。「weblogic-pubsub.xmlファイルの作成」を参照してください。

3. pub-subサーバーによるチャネルへのメッセージのパブリッシュ、クライアントからのメッセージのフィルタ処理、またはチャネルの動的な作成あるいは破棄が必要な場合、サーブレットなどのWebアプリケーション・コンポーネントにJavaコードを追加します。この手順は省略可能です。「サーバー側のPub-Sub APIによるプログラミング」を参照してください。

4. クライアントから受け取るメッセージを事前処理する必要がある場合、メッセージ・フィルタ・チェーンをプログラミングおよび構成します。「メッセージ・フィルタ・チェーンの構成とプログラミング」を参照してください。

5. HTMLファイル、JSPなど、ブラウザ・クライアントを更新し、ユーザーがチャネルをサブスクライブし、メッセージを送受信できるようにします。「Pub-Subサーバーと通信するためのブラウザ・クライアントの更新」を参照してください。

6. 更新済みの新しいデプロイメント記述子ファイルとブラウザ・クライアントを使用してWebアプリケーションを再アセンブルします。pub-subサーバー・コードを追加した場合は、サーブレットを再コンパイルします。

   新しいweblogic-pubsub.xmlデプロイメント記述子を、web.xmlおよびweblogic.xmlファイルが格納されているWebアプリケーションの同じWEB-INFディレクトリに配置します。

   Webアプリケーションのアセンブリに関する全般的な情報は、「Webアプリケーションの作成と構成」を参照してください。

7. まだ実行していない場合、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のインストール・ディレクトリです。

   WebLogic Server管理コンソールか、weblogic.Deployerコマンド・ライン・ツールを使用できます。WebLogic Serve管理コンソールの使用手順については「Java EEライブラリのインストール」を、weblogic.Deployerの使用方法の詳細は「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。

8. WebLogic Serve管理コンソールまたはweblogic.Deployerコマンド・ライン・ツールを使用して、更新したWebアプリケーションを再デプロイします。

   WebLogic Serve管理コンソールの使用手順については「Webアプリケーションのインストール」を、weblogic.Deployerの使用方法の詳細は「weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ」を参照してください。

この時点で、ブラウザ・クライアントを使用してweblogic-pubsub.xmlファイルで構成されているチャネルをサブスクライブし、メッセージを送受信することができます。

pub-subアプリケーションのプログラミング後に、そのアプリケーションの実行時情報をモニタリングする必要がある場合があります。詳細は、「Pub-Subサーバーおよびチャネルの実行時情報の取得」を参照してください。

実装可能なpub-subサーバーのより高度な機能については、次の項を参照してください。

• セキュリティの有効化

• 高度なトピック: プロバイダとしてJMSを使用することによるクラスタのサポート

• 高度なトピック: 物理ストレージへのメッセージの永続化

weblogic-pubsub.xmlファイルの作成

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 APIによるプログラミング

情報をモニターするため、またはサブスクライブ済みクライアントへパブリッシュされる前に受信データをインターセプトするために、pub-subサーバー自身がチャネルからメッセージを定期的に取得しなければならない場合があります。また、pub-subサーバーは、サブスクライブ済みのすべてのクライアントへ通知を行ったり、追加のサービスを提供するために、チャネルへ直接メッセージをパブリッシュしなければならない場合もあります。さらに、新しいチャネルを作成したり、既存のチャネルを破棄したりといった、チャネルのメンテナンスを行わなければならない場合もあります。

WebLogic Serverでは、これらのすべてのタスクを実行するために、com.bea.httppubsubパッケージでpub-sub APIを提供しています。pub-subプログラマは、pub-subアプリケーションを格納するWebアプリケーションのサーブレットまたはPOJO (プレーンな従来型Javaオブジェクト)でこのAPIを使用します。APIを使用したプログラミングは省略可能であり、pub-subサーバーがクライアント側で標準のパブリッシュ/サブスクライブ以外のタスクを実行しなければならない場合にのみ必要となります。

APIの主なクラスおよびインタフェースの概要

次に、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を使用して実行する方法について説明します。サンプル・コードは、EXAMPLES_HOME/wl_server/examples/src/examples/webapp/pubsub/stock/src/stockWarにある配布キットのpub-subサーバー・サンプルのJavaソース・ファイルから抜粋しています。EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを表します。WebLogic Serverサンプル・コードの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

Pub-Subサーバー・インスタンスの取得とローカル・クライアントの作成

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つの手順があります。

1. メッセージ・リスナーを作成し、LocalClientに登録します。

2. チャネルを明示的にサブスクライブします。

メッセージ・リスナーは、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インタフェースは、JavaScript Object Notation (JSON) (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に送信され、ここで独自の処理が行われた後、チャネルのサブスクライバに送信されます。

Pub-Subサーバーと通信するためのブラウザ・クライアントの更新

ブラウザまたはその他の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ライブラリのデフォルト・サーブレット・マッピングのオーバーライド

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サーバーおよびチャネルの実行時情報の取得

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の詳細は、Oracle WebLogic Server MBeanリファレンスの左側のペインにある「実行時MBean」ノードをオープンします。実行時MBeanがアルファベット順にリストされています。

JMX MBeanのプログラミングに関する一般的な情報は、『Oracle WebLogic Server JMXによる管理可能アプリケーションの開発』を参照してください。

セキュリティの有効化

pub-subサーバーでは、以下のセキュリティ機能が提供されます。

• パブリッシュ/サブスクライブの制約の使用

• プリンシパルへのロールのマップ

• パブリッシュ/サブスクライブ通信でのSSLの構成

• セキュリティのその他の考慮事項

次の項では、これらの機能の使用方法について説明します。

パブリッシュ/サブスクライブの制約の使用

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>

Webアプリケーションの再デプロイによる制約の更新

制約は動的に更新することができません。新しい設定を有効化するには、Webアプリケーションを再デプロイする必要があります。

プリンシパルへのロールのマップ

注意: 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ロールに割り当てる方法を示しています。

例12-3 security-role-assignment要素

<weblogic-web-app>  
 <security-role-assignment>        
    <role-name>publisher</role-name>
    <principal-name>Tanya</principal-name>
    <principal-name>Fred</principal-name>
    <principal-name>system</principal-name>
 </security-role-assignment>

</weblogic-web-app> 

パブリッシュ/サブスクライブ通信でのSSLの構成

デフォルトでは、すべての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セキュリティに関するその他の考慮事項について説明します。

• AuthCookieEnabledによるリソースへのアクセス

• Pub-Subサーバーのロック

AuthCookieEnabledによるリソースへのアクセス

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サーバーをロックするには、次の手順に従います。

1. pub-sub通信に対してSSLを構成します。「パブリッシュ/サブスクライブ通信でのSSLの構成」を参照してください。

2. 認証(BASIC、FORMなど)を要求します。

   WebLogic Serverでは、Webアプリケーションに要求される認証方式をweb.xmlファイルで設定します。

   以下の例では、HTTP BASIC認証が要求されています。

   <login-config> 
   <auth-method>BASIC</auth-method> 
   <realm-name>default</realm-name> 
   </login-config> 
   

3. auth-cookieがWebアプリケーションで有効化されていることを確認します。「AuthCookieEnabledによるリソースへのアクセス」を参照してください。

4. すべてのチャネルがweblogic-pubsub.xmlファイルで制約されていることを確認します。

5. デフォルトで許可されている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>
   

高度なトピック: プロバイダとしてJMSを使用することによるクラスタのサポート

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の構成

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-provider-urlを定義しない場合、Pub-Subサーバーではweblogic-pubsub.xmlで構成されたconnection-factory-jndi-name要素およびtopic-jndi-name要素を使用して、web.xmlのresource-ref要素およびweblogic.xmlのres-ref-name要素で定義されているように、接続ファクトリおよびトピックへの参照をルックアップします。

次のサンプル・コードの機能を示します。

• web.xmlのresource-refを定義します(例12-5)

• res-ref-nameをweblogic.xmlのJMSリソースの実際のJNDI名にマッピングします(例12-6)

• weblogic-pubsub.xmlのconnection-factory-jndi-name要素およびtopic-jndi-name要素を使用して、jms-provider-urlを指定せずに、接続ファクトリおよびトピックを参照します(例12-7)

例12-5 web.xmlのresource-refでの接続ファクトリおよびトピックの定義

<resource-ref>
  <res-ref-name>web20/connectionFactory</res-ref-name>
  <res-type>javax.jms.ConnectionFactory</res-type>
</resource-ref>
<resource-ref>
  <res-ref-name>web20/topic</res-ref-name>
  <res-type>javax.jms.Topic</res-type>
</resource-ref>

例12-6 res-ref-nameのweblogic.xmlのJNDI名とのマッピング

<resource-description>
  <res-ref-name>web20/connectionFactory</res-ref-name>
  <jndi-name> weblogic.web20.jms.TopicConnectionFactory</jndi-name>
</resource-description>

<resource-description>
  <res-ref-name>web20/topic</res-ref-name>
  <jndi-name>weblogic.web20.jms.chatTopic</jndi-name>
</resource-description>

例12-7 weblogic-pubsub.xmlのconnection-factory-jndi-nameおよびtopic-jndi-nameの使用

<jms-handler-mapping>
  <jms-handler-name>jms-fortest</jms-handler-name>
  <jms-handler>
    <connection-factory-jndi-name>
      web20/connectionFactory
    </connection-factory-jndi-name>
    <topic-jndi-name>
      web20/topic
    </topic-jndi-name>
  </jms-handler>
</jms-handler-mapping>

weblogic-pubsub.xmlデプロイメント記述子に指定できるJMSハンドラ関連のXML要素の一覧は、weblogic-pubsub.xsdスキーマ(http://xmlns.oracle.com/weblogic/weblogic-pubsub)を参照してください。

クライアント・セッション・フェイルオーバーの構成

サーバーのフェイルオーバーに加え、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永続ストアの使用方法に関する項を参照してください。