Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発

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

以下の節では、WebLogic Server に含まれている HTTP パブリッシュ/サブスクライブ サーバの概要と、Web アプリケーションにおけるこのサーバの使用方法を示します。

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

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

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

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

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

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

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 サーバがメッセージをパブリッシュしたときにサブスクライバがアクティブでないか接続されていない可能性があります。この場合のメッセージの配信動作には、以下のルールが適用されます。

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

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

このサンプルでは、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 のインストール ディレクトリ (/beahome/wlserver_10.3 など) です。

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

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

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

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

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

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

weblogic-pubsub.xml デプロイメント記述子は、pub-sub サーバのコンフィグレーションに使用する XML ファイルです。特に、初期チャネル、pub-sub サーバのコンフィグレーション プロパティ、およびチャネルをサブスクライブするクライアントのセキュリティ仕様を指定します。この情報の一部は、サーバサイドの API を使用して pub-sub サーバによって実行時に更新することができます。

デプロイメント記述子のルート要素は <wlps:weblogic-pubsub> であり、wlps ネームスペースは http://www.bea.com/ns/weblogic/weblogic-pubsub です。

weblogic-pubsub.xml ファイルの要素の詳細については、このスキーマを参照してください。以下に、一般的に使用される要素の一部を示します。この節の最後に一般的な weblogic-pubsub.xml ファイルの例を示します。

次のサンプル weblogic-pubsub.xml ファイルでは、pub-sub サーバを使用するアプリケーションの簡単なコンフィグレーションを示します。詳細については、このサンプルの後の説明を参照してください。

<?xml version="1.0" encoding="UTF-8"?>

<wlps:weblogic-pubsub
    xmlns:wlps="http://www.bea.com/ns/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>

上記の例で注目すべき点は以下のとおりです。

サーバサイドの 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 パッケージにはこの他にもサポート クラス、インタフェース、列挙、例外があります。詳細については、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 のインストール ディレクトリ (/beahome/wlserver_10.3 など) を示しています。

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

メッセージ リスナは、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 サーバ アプリケーション開発者は、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) エンコード オブジェクトである 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://www.bea.com/ns/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 ツールキットを使用して Web ベースのクライアントを更新し、WebLogic pub-sub サーバと通信する方法に関する最小限の情報のみ提供しています。詳細については、Dojo のドキュメントを参照してください。

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 を使用します。

どちらの MBean も WebLogic Server MBean ツリーに登録され、そのツリーを移動することによってアクセスできます。具体的には、WebPubSubRuntimeMBean は現在の Web アプリケーションの WebAppComponentRuntimeMBean の下に、すべての ChannelRuntimeMBean は WebPubSubRuntimeMBean の下に登録されます。

これらの MBean の詳細については、『WebLogic Server MBean リファレンス』の左ペインにある「Runtime MBeans」ノードを開きます。実行時 MBean がアルファベット順にリストされています。

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

セキュリティの有効化

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

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

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

pub-sub サーバでは、チャネル制約と認可制約という 2 つのメカニズムを組み合わせてチャネルを保護する機能が提供されます。

チャネル制約は、概念的には、保護対象のリソースの集合と、必要に応じてその集合内の特定のリソースに関する認可制約を格納するコンテナです。認可制約は、WebLogic Server のロールおよびポリシーを表し、「この集合内のこのリソースに対して特定の操作を実行できるのは誰か」といった問いに答えます。

pub-sub 制約は、コンフィグレーション ファイルの weblogic-pub-sub.xml で指定します。pub-sub サーバは、weblogic-pub-sub.xml コンフィグレーション ファイルのチャネル制約および認可制約を使用し、チャネルに対してロールおよびポリシーを設定します。

例として、コード リスト 12-1 に示すサンプルを考えます。重要な箇所は太字で示しています。

<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 種類のアクション (操作) が許可されています。

subscribe 操作はデフォルトで (チャネル制約が定義されていない場合)、どのようなユーザがどのチャネルに対しても実行することができます。

同様に、create、delete、および publish 操作はデフォルトで、どのようなユーザがどのチャネルに対しても実行することはできません。create、delete、および publish 操作は、チャネル制約で明示的にコンフィグレーションされている場合にのみ許可されます。

特定のロールに対して任意のチャネル操作へのアクセスを指定するには、<wlps:channel-operation> と <wlps:auth-constraint> を組み合わせて使用します。

たとえば、コード リスト 12-2 では、publish 操作が、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>

    <!-- auth-constraint を定義しない場合、すべてのユーザがアクセスできる -->

  </wlps:channel-constraint>

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

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

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

主要な 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 要素を使用します。

「security-role-assignment」で説明しているように、security-role-assignment 要素は、WebLogic Server セキュリティ レルム内の 1 つまたは複数のプリンシパルとセキュリティ ロール間のマッピングを宣言します。

コード リスト 12-3 は、security-role-assignment 要素を使用してプリンシパルを publisher ロールに割り当てる方法を示しています。

<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 に設定されています。

<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 によるリソースへのアクセス

WebLogic Server では、セッション データを失うことなく、HTTP を使用して開始されたセッションで HTTPS リソースにユーザが安全にアクセスできます。この機能を有効にするには、config.xml の WebServer 要素に AuthCookieEnabled="true" を追加します。

<WebServer Name="myserver" AuthCookieEnabled="true"/>

AuthCookieEnabled を true (デフォルト設定) に設定すると、新しいセキュアなクッキー (_WL_AUTHCOOKIE_JSESSIONID) が、HTTPS 接続を介した認証時にブラウザに送信されるようになります。一度セキュアなクッキーが設定されると、セッションはそのクッキーがブラウザから送信された場合しかセキュリティ制約のある他の HTTPS リソースにアクセスできません。

Pub-Sub サーバのロック

この節では、pub-sub サーバをロックして権限のないアクセスを防ぐ方法について説明します。ここで説明する手順では、アクセスの制限と引き換えに追加のセキュリティを提供します。現在の環境に適したセキュリティ レベルを決定してください。

pub-sub サーバをロックするには、次の手順に従います。

高度なトピック : プロバイダとして 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 デプロイメント記述子でコンフィグレーションする方法の例を示します (関連箇所のみ太文字で示しています)。サンプルの後の説明を参照してください。

<?xml version="1.0" encoding="UTF-8"?>

<wlps:weblogic-pubsub
    xmlns:wlps="http://www.bea.com/ns/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>

上記の例で注目すべき点は以下のとおりです。

weblogic-pubsub.xml デプロイメント記述子に指定できる JMS ハンドラに関連する XML 要素の一覧については、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://www.bea.com/ns/weblogic/90"
  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 対応データベースの永続性をサポートします。詳細については、「WebLogic 永続ストアの使い方」を参照してください。

Oracle では、永続メッセージを格納するためのファイルまたは JDBC ストアを独自に作成し、このストアを永続チャネル用にコンフィグレーションすることをお勧めします。ただし、コンフィグレーションされた名前のストアが検出されない場合は、メッセージの格納にはデフォルトの WebLogic 永続ストアが使用され、警告メッセージがログ ファイルに記録されます。

永続ストア内のメッセージは無期限には保存されず、コンフィグレーションされた最大存続期間プロパティに基づき、その期間の経過後にストアから古いメッセージが定期的に削除されます。この最大期間のデフォルト値は 3600 秒ですが、永続チャネルごとに異なる値をコンフィグレーションすることができます。

永続チャネルをサブスクライブするクライアントは、永続クライアントと呼ばれます。通常のクライアントとの主な違いは、pub-sub サーバによるタイムアウトの処理方法にあります。pub-sub サーバをコンフィグレーションする際は、以下に示す 2 つの異なるタイムアウト コンフィグレーション オプションを使用できます。これらは、weblogic-pubsub.xml ファイルの <wlps:server-config> の子要素です。

永続チャネルのコンフィグレーション

永続チャネルは、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://www.bea.com/ns/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>

上記の例で注目すべき点は以下のとおりです。