WebSphere ESBのキャッシュによるWSRRからのカスタム・ポリシー取得時のパフォーマンス向上

IBM WebSphere Registry and Repositoryのポリシーなどのカスタム・メタデータを取得するためにカスタム・メディエーションを作成する場合、リクエストの数が非常に大きくなり、必要なリソースが大幅に増加してしまいますことがあります。負荷を軽減し、応答時間を短縮するための 1 つの方法が、キャッシュの利用です。この記事では、WebSphere Enterprise Service Bus (ESB) にデプロイされたメディエーション・プリミティブを拡張し、キャッシュのサポートを追加する方法について説明します。この内容は IBM WebSphere Developer Technical Journal の一部です。

Arnauld Desprets, IT Architect, IBM

Arnauld DespretsArnauld Desprets はイギリスのIBM Software Services for WebSphere チームの IT アーキテクトです。ヨーロッパ各国のさまざまな企業に対して、10 年以上コンサルティングを行い、WebSphere Application Server に関して 8 年以上の経験があります。現在は、SOA と Web サービス、特に WS-Security を専門としており、最近の関心は、SOA におけるガバナンスの役割とレジストリー (WebSphere Services Registry and Repository など) です。



2009年 6月 24日

はじめに

IBM WebSphere Enterprise Service Bus (ESB) や IBM WebSphere Service Registry and Repository (以下、Service Registry と呼びます) をカスタム・メディエーションと統合しようとすると、パフォーマンスが問題になりやすくなります。実際、応答時間の短縮に加え、Service Registry サーバーそのものによるリソース使用量の削減を図るためには、ほとんどの状況において、メディエーションにキャッシュ機能を追加することが必要となります。

この記事は Andre Tost が以前執筆した記事のフォローアップです。その記事、「Establish a policy-driven SOA using WebSphere Service Registry and Repository and WebSphere ESB」では、Service Registry で定義され WebSphere ESB で適用されるカスタムの WS-Policy ポリシーを利用した、メディエーションの実装方法を説明しています。今回の記事では、キャッシュの実装に焦点を絞るだけではなく、その他の重要な考慮事項として、キャッシュの監視方法や調整方法などにも重点を置いて説明します。

André の記事では「監査」ポリシーの例を使用していました。このシナリオは以下のようなものです。

TemperatureConverter サービスの前に置かれたメディエーションが、このサービスに (Service Registry での定義に従って) Audit ポリシーが添付されているかどうかをチェックします。添付されている場合には、リクエスト・メッセージ処理の一部として Audit プリミティブが呼び出されます。図 1 は CelciusToFahrenheit (セ氏から華氏) 操作のフロー図を示しており、この図を見るとカスタムのプリミティブがあることがわかります。

図 1. フロー図
フロー図

この記事の後の方で、Java™ によるカスタムの PolicyRetrieval プリミティブを変更してキャッシュを追加する方法について説明します。


アーキテクチャーに関する考慮事項

実装を始める前に、まずキャッシュを使用する場合のシナリオを調べることから始めましょう。

  • 単純なシナリオ

    最も単純なシナリオでは、WebSphere ESB サーバーのインスタンスは 1 つしかなく、従ってメディエーションも 1 つしかデプロイされていません。データの複製について気にする必要はありません。しばらく時間が経過するとキャッシュのデータは有効ではなくなる可能性がありますが、それを踏まえ、単純にキャッシュにデータを書き込み、そしてキャッシュからデータを取得します。データの無効化はキャッシュ自体のタイムアウトによって行われます。そして後ほど説明しますが、このシナリオでのキャッシュの追加は非常に容易です。

  • より複雑なシナリオ

    このシナリオでは、どの時点においてもキャッシュが無効なデータを含むことは許されません。あるいは最低限の要求として、データが無効となる期間を可能な限り最小にする必要があります。そのためには、サービス操作に添付されたポリシーに特定の変更が発生した場合に、キャッシュに通知することを検討する必要があります。つまり、ポリシーを変更するとキャッシュ・データの無効化がトリガーされるようにするのです。これをレジストリー側で実装するためには、Service Registry の「通知」プラグインを使います。キャッシュ側の実装に関しては、キャッシュはエントリーを無効化するためのメソッドを既に公開しているため、非常に単純です。唯一難しい点は、どのようにして Service Registry からキャッシュにアクセスするかという点です。キャッシュはさまざまなセルで実行される可能性があるからです。この対策はいくつかあり、比較的単純なのは、Web サービスまたは Web アプリケーションを作成し、それをキャッシュが存在するサーバーにデプロイする方法です。そして Service Registry が、そのインターフェースを使ってキャッシュのインスタンスを呼び出すようにするのです。


キャッシュに関する考慮事項

キャッシュを使用する場合には、いくつかの重要な点について検討する必要があり、その一部は他の記事でも説明されています。まず、developerWorks に公開された記事、「The requester side caching pattern specification, Part 1: Overview of the requester side caching pattern」で解説されている重要な考慮事項から始めることにしましょう。下記では、その記事からの引用部分を斜字体にしてあります。

  • データ・キー

    キャッシングの基本要件として、キャッシュされたデータを明示的かつ一意に特定できる必要があります。キャッシュされるデータ項目に対する識別子はキーと呼ばれます。キャッシュでは基本的に、指定されたキーを使ってデータ項目を挿入し、その同じキーを使って後からそのデータ項目を取得します。つまり 2 つのデータ項目の表す情報が異なる場合には、その 2 つのデータ項目はそれぞれ異なるキーを持つ必要があります。また、各データ項目が持つキーは 1 つのみでなければなりません。

    この記事では単純な方法を使うことにし、サービス操作の名前と名前空間によって一意の指定をすることにします。またこの記事では、Service Registry の論理インスタンスは 1 つのみとし、このインスタンスにポリシーおよび操作用のポリシー添付の定義が含まれているものとします。

  • データの揮発性

    あるキーに関連付けられているデータがキャッシュに置かれた後で新しいバージョンに変更された場合、このキーを使ってキャッシュからデータを取得すると、古いデータを取得することになります。通常、キャッシュを使用する上で、このデータの揮発性の問題が最大の制約となります。この問題への基本的な対処方法は 2 つあり、1 つはキャッシュの中のデータ項目がタイムアウトになるようにする方法、もう 1 つはキャッシュの中のデータ項目を明示的に無効にする方法です。

    • タイムアウトになるようにする方法: データは頻繁に変更されますが、短期間であれば古くなったデータを取得しても構わないものとします。

      このパターンに従うキャッシュでは、タイムアウト値を設定することができます。

    • 明示的に無効にする方法: キャッシュに保持されているデータ項目に対して変更を行ったときに、それがどのような変更であれ、変更されたデータ項目を即座にキャッシュから削除しなければならないことがあります。この場合は無効なデータを明示的にキャッシュから削除する必要があります。

      ただし、確実にデータを削除する作業は、このパターンを使用するユーザーの責任です。今回の記事の場合について言えば、データが変更されたことを Service Registry がキャッシュに通知する必要があります。これは Service Registry のプラグインを使えば比較的簡単に行うことができます。しかし後で説明するように、この方法の難しい点は、キャッシュは複数 (WebSphere ESB のインスタンスごとに 1 つ) あるため、これらのインスタンスすべてに対して通知しなければならないことです。DRS (Data Replication Service) を使用する場合には、すべてのキャッシュ・インスタンスにエントリーがあるはずですが、DRS を使用しない場合には、すべてのキャッシュ・インスタンスにエントリーがあるとは限りません。そのため、エントリーを無効にしようとすると例外が発生する可能性があります。

  • ワーキング・セット・サイズ

    キャッシュにはワーキング・セット・サイズがあります。ワーキング・セット・サイズとは、要求の大部分にキャッシュで対応できるようにするために、キャッシュ内に保持すべき項目の数です。一般的に、キャッシュとして動作する上でキャッシュに含め得る項目数には制限があり、その制限を容量と呼びます。この容量よりも多くの項目が追加されると、一部の項目は破棄されます。キャッシュの実装における破棄のポリシーは LRU (least-recently-used) です。このポリシーでは、参照されなかった期間が最も長い項目から破棄されます。このポリシーの下でキャッシュ容量が十分に大きければ、そのキャッシュのワーキング・セットはキャッシュの中に保持され、ターゲット・コンポーネントに対するリクエストの高速化に有効となります。ただしキャッシュ容量が大きすぎるとスペースの浪費になりますし、小さすぎるとワーキング・セットが収容できず、キャッシュの効果が大きく損なわれます。

    従って、キャッシュ動作をモニタリングする重要性とは、それによってキャッシュ効率を最大限まで高めることにあります。そこでこの記事では、キャッシュのモニタリング方法について説明します。

  • プリロードとキャッシュのリフレッシュ

    負荷が非常に重い場合には、キャッシュと Service Registry を使う上での他のトラブルを防ぐために、さらにいくつかの点に注意する必要があります。非常に稀なケースとして、まだエントリーがキャッシュの中にない場合や、あるいは何らかの理由でエントリーが無効化されている場合があります (例えば、キャッシュが満杯である場合や、キャッシュ・サイズが非常に小さい場合など)。このような状況では、ある値を取得するための同じリクエストが大量に Service Registry サーバーに送信されることとなります。これにより、下記の 2 つの影響があります。

    • Service Registry サーバーが大量の同じリクエストを受信することとなります。
    • 負荷が重いため、結果を取得するための応答時間が長くなります。

    この影響を軽減するには、共有リソースへの排他アクセスを可能にする、mutex という手法を使います。この場合には、mutex を使用することで、(可能であれば) キャッシュの 1 つのエントリーからのみ情報を取得できるようにし、同じ ESB リソースに対する他のリクエストをブロックします。mutex のための Java 実装については Web で見つけることができます (「参考文献」を参照)。

    もう 1 つの方法は、プリロード・メカニズムを使う方法です。この方法は、ある意味で上記の方法のバリエーションです。この場合には、アプリケーションが最初に起動する時点で、あるいは他の、高負荷をトリガーする可能性のある任意の事前定義のイベントが発生した時点で、キャッシュにデータをロードします。こうすることで、最初のリクエストに対する応答時間を短縮することができます。このための実装方法もいくつかあり、例えばカスタム・アプリケーションを使用して、ESB または ESB インスタンスを調べながらサービスにテスト・データを送信するする方法などがあります。

こうしたことを念頭に置いた上で、比較的よく知られた WebSphere Application Server の実装について調べてみることにしましょう。


DistributedMap を使う

キャッシュを実装するためには、DistributedMap インターフェースと J2EE® アプリケーション、そして Java オブジェクトをキャッシュに入れて共有するシステム・コンポーネントを使います (このシステム・コンポーネントは、オブジェクトへの参照をキャッシュに保管することでそのオブジェクトを共有します)。図 2 は DistributedMap の詳細の一部を示しています。これを見るとわかるように、高度なキャッシュには多様な機能があり、例えば複数のキャッシュ・インスタンス間で複製を行う機能や、キャッシュ内容をディスクに移動して負荷を軽減する機能、置換ポリシーの実装などがあります。

図 2. DistributedMap の概要
DistributedMap の概要

この例では、WebSphere Application Server の管理コンソールを使ってキャッシュ・インスタンスを構成します。(これ以外の方法については、WebSphere Application Server インフォメーション・センターを参照してください。)

コードの変更

これから説明するように、キャッシュを実装するために必要なコードは、ほんの数行です。ここで最も重要なクラスは、PolicyQueryTest です。キャッシュの呼び出しは hasPolicyDefined(String, String, String) メソッドによって行います。下記のリスト 1 は、このメソッドから抜粋したものです。

リスト 1
1 List<String> policies = null;
2 long beforeCache = System.currentTimeMillis();
3 CacheKey cKey = new CacheKey(policyElementName, namespace, operation);
4 logger.logp(Level.FINEST, CLASS_NAME, METHOD_NAME, "Checking if there is not already 
an entry in the cache with key {" + cKey + "}");
5 policies = (List) CacheManager.getInstance().get(cKey.toString());
6 if (policies == null) {
7   try {
8     policies = runQuery(namespace, operation);
9     long afterMiss = System.currentTimeMillis();
10    logger.logp(Level.FINEST, CLASS_NAME, METHOD_NAME, "CACHE Miss: key {" + cKey + "} 
retrieved in " + (afterMiss - beforeCache) + " ms");
11    // If policies are null should we add it
12    if (policies == null) {
13      logger.logp(Level.FINEST, CLASS_NAME, METHOD_NAME, "No policies applies to this 
operation");
14    } else {
15      logger.logp(Level.FINEST, CLASS_NAME, METHOD_NAME, "Adding the polices in the 
cache");
16      CacheManager.getInstance().put(cKey.toString(), policies);
17    }
18   } catch (Exception x) {
19    logger.logp(Level.SEVERE, CLASS_NAME, METHOD_NAME, "Exception during policy retrieval
: " + x.toString());
20    throw new RuntimeException(x);
21  }
22 } else {
23   long afterHit = System.currentTimeMillis();
24   logger.logp(Level.FINEST, CLASS_NAME, METHOD_NAME, "CACHE HIT: key {" + cKey + "} 
retrieved from cache in " + (afterHit - beforeCache) + " ms");
25 }
  • リスト 1 の3 行目ではキーを作成し、そのキーを、ポリシーの名前、操作名、そして名前空間と関連付けています。操作名と名前空間はメディエーション・プリミティブのインターフェースの一部です。CacheKey クラスはそれらを単純に連結しているにすぎません。同じ操作に別バージョンがある場合には、操作名または名前空間のいずれかに操作またはサービスのバージョン情報が含まれる場合を除き、取得するキーは同じです。一般的に、こうすることがサービス管理を行う場合の適切な習慣です。また、キャッシュ・モニタリング・アプリケーションを使ってエントリーを削除する必要がある場合のために、CacheKey を人間が読み取れるものにする必要があります。(キャッシュ自体を削除する場合を除いて) プログラムを使わない限りキャッシュのエントリーを削除できない場合には、例えばハッシュ値を使うなどの方法でエントリーを削除します。
  • 5 行目では、上で生成されたキーを使ってキャッシュから値を取得しようとしています。エントリーがない場合には、名前空間と操作を使ってレジストリーに対し照会を行い (8 行目)、その結果をキャッシュに保存します (16 行目)。

リスト 2 は CacheKey のメイン・コードを示しています。これを見るとわかるように、このコードは名前と名前空間を単純に連結しているにすぎません。ただしこれをもっと複雑にし、各ケースの独自性を出すこともできます。このリストの中で興味深い行は、キーの値が含まれた 11 行目です。

リスト 2
1 public class CacheKey {
2   private String policyElementName;
3   private String namespace;
4   private String operation;
5   public CacheKey(String policyElementName, String namespace, String operation) {
6     this.policyElementName = policyElementName;
7     this.namespace = namespace;
8     this.operation = operation;
9   }
10  public String toString() {
11    return policyElementName + "." + namespace + "." + "." + operation;
12  }
13 }

この記事に付属しているコードの構成

皆さんの環境でテストを行えるように、この記事にはサンプル・コードが付属しています。下記は、このコードの構成を簡単に説明したものです。表 1 は完全なテストを実行するためのモジュールの一覧です。「以前公開された記事」とは異なり、この例ではサービス・プロバイダーをローカルで実装しています。

表 1
プロジェクト説明
TemperatureConverterProviderEARTemperatureConverter サービスの実装を含む EAR
TemperatureConverterTemperatureConverter サービスの実装
TemperatureConverterClientEARTemperatureConverter サービス・コンシューマーの実装を含む EAR
TemperatureConverterClientTemperatureConverter サービス・コンシューマーの実装。このコードはメディエーション・モジュールによって公開される WSDL から生成されます。
PolicyMediationメディエーション・モジュール
PolicyQueryメディエーション・モジュールの Java 実装 (つまりキャッシュの実装) を含むライブラリー

WebSphere ESB でキャッシュを構成する

まず、WebSphere Application Server の管理コンソールでキャッシュを構成します。「Resources (リソース)」 => 「Cache instances (キャッシュ・インスタンス)」 => 「Object cache instances (オブジェクト・キャッシュ・インスタンス)」の順に選択します。「New (新規)」ボタンをクリックし、下記のように各フィールドに値を入力して、「OK」をクリックします (図 3)。

  • Name: WSRRPolicyCache
  • JNDI Name: services/cache/PoliciesQueries (先ほどのコードで参照しています)
図 3. キャッシュ・インスタンスの構成
キャッシュ・インスタンスの構成

アプリケーションをテストする

この時点での前提として、TemperatureConverter のコンシューマーとプロバイダーという 2 つのエンタープライズ・アーカイブ・ファイルをインストールしてあり、さらに Policy メディエーション・モジュールを WebSphere ESB に公開してあるものとします。

Service Registry の中のテスト・データは以下のもので構成されています。

  • TemperatureConverter サービス用のサービス・プロバイダーの WSDL: TemperatureConversions.wsdl (図 4)
    図 4. WSRR での WSDL 文書
    WSRR での WSDL 文書
  • 監査ポリシーを含むポリシー・ファイル: audit.xml
  • ポリシー添付サービス: auditatachment.xml (図 5)
    図 5. ポリシー・ファイル
    ポリシー・ファイル

これでテストを実行する準備が整いました。

  1. キャッシュのトレースを表示するためには、トレースが *=info: com.ibm.sample=all に設定されていることを WebSphere の管理コンソールで確認します。
  2. ブラウザーで、Web サービス・クライアントをテストするアプリケーションの URL を入力します (ここでは https://localhost:9443/TemperatureConverterClient/jsps/TestClient.jsp)
  3. 「celciusToFahrenheit(java.math.BigDecimal)」リンクをクリックし、任意の値を入力します。
  4. 「Invoke (呼び出し)」ボタンをクリックします。このボタンを初めてクリックした際には、Service Registry のポリシーが照会され、その結果がキャッシュに書き込まれます。その結果は図 6 のようになるはずです。
    図 6. Web サービス呼び出しの結果
    Web サービス呼び出しの結果
  5. ここで任意の新しい値を入力し、そして再度「Invoke」をクリックします。2 度目のクリックでは、キャッシュの中のポリシーが発見されるはずです。
  6. トレース出力の中で、リスト 3 のような行を探します。
    リスト 3
    TT T1 SystemOut O   Operation name is : CelciusToFahrenheit
    TT T1 SystemOut O   Operation namespace is : http://webservices.daehosting.co
    m/temperature
    TT T1 sample    > com.ibm.sample.PolicyQueryTest hasPolicyDefined ENTRY
    TT T1 sample    3 com.ibm.sample.PolicyQueryTest hasPolicyDefined policyEleme
    ntName: tns:Audit
    TT T1 sample    3 com.ibm.sample.PolicyQueryTest hasPolicyDefined Checking if
    there is not already an entry in the cache with key {tns:Audit.http://webserv
    ices.daehosting.com/temperature..CelciusToFahrenheit}
    TT T1 sample    3 com.ibm.sample.PolicyQueryTest runQuery Policy document: [B
    @43fc43fc
    TT T1 sample    3 com.ibm.sample.PolicyQueryTest hasPolicyDefined CACHE Miss:
    key {tns:Audit.http://webservices.daehosting.com/temperature..CelciusToFahren
    heit} retrieved in 344 ms
    TT T1 sample    3 com.ibm.sample.PolicyQueryTest hasPolicyDefined Adding the 
    polices in the cache
    TT T1 sample    3 com.ibm.sample.PolicyQueryTest hasPolicyDefined Policy name
    : tns:Audit
    TT T2 SystemOut O   Operation name is : CelciusToFahrenheit
    TT T2 SystemOut O   Operation namespace is : http://webservices.daehosting.co
    m/temperature
    TT T2 sample    > com.ibm.sample.PolicyQueryTest hasPolicyDefined ENTRY
    TT T2 sample    3 com.ibm.sample.PolicyQueryTest hasPolicyDefined policyEleme
    ntName: tns:Audit
    TT T2 sample    3 com.ibm.sample.PolicyQueryTest hasPolicyDefined Checking if 
    there is not already an entry in the cache with key {tns:Audit.http://webserv
    ices.daehosting.com/temperature..CelciusToFahrenheit}
    TT T2 sample    3 com.ibm.sample.PolicyQueryTest hasPolicyDefined CACHE HIT: 
    key {tns:Audit.http://webservices.daehosting.com/temperature..CelciusToFahren
    heit} retrieved from cache in 0 ms

    これらのトレースを見るとわかるように、最初に「Invoke」をクリックした時にはキャッシュにエントリーがなく、このリクエストに要した時間は 344 ミリ秒であることがわかります (リスト 3 に太字で示した CACHE Miss というメッセージを見てください)。しかし 2 度目に「Invoke」をクリックした時には、キャッシュの中にポリシーがあるため、Service Registry を照会する必要がなく、そして応答は 0 ミリ秒で瞬時に行われています (同じく太字で示した CACHE HITというメッセージを見てください)。(これらの数値は、実際の本番環境を反映したものではありません。)

ここで有効なヒントを挙げておきます。以下の REST インターフェースを使用すると、ポリシーが適切に適用されているかどうかを検証することができます。

https://localhost:9444/WSRR/6.1/Metadata/XML/GraphQuery?query=
/WSRR/WSDLPortType[@name=%27TemperatureConversionsSoapType%27%20and%20@namespace=%27http:
//webservices.daehosting.com/temperature%27]/operations[@name=%27CelciusToFahrenheit%27]

通知を使用するキャッシュ・シナリオを検証する

ここまでは、メディエーション・プリミティブへのキャッシュの追加が非常に容易であることを見てきました。次に、より複雑なシナリオを考えます。このシナリオでは、先ほどと同じようにキャッシュを使うだけではなく、ポリシーの変更が必要であることを明示的にキャッシュに通知する必要があります。このシナリオでは、先ほど説明した Service Registry の通知機能を使用し、ポリシーに関連するキャッシュ・エントリーをプログラムによって無効化します。

まず、Service Registry におけるポリシーのモデルを簡単に説明しましょう。このモデルを理解することで、ポリシーへの変更によって影響される操作を見つける方法を理解しやすくなります。要するに、キャッシュの中で更新が必要なキーを (1 つまたは複数) 計算する必要があるということです。

図 7. Service Registry のポリシー・モデル
Service Registry のポリシー・モデル

このシナリオでは、明示的にポリシーを変更すること以外にも、メディエーションの結果に影響するエンティティーについて考慮する必要があります。その一例として、別の操作で新しいエンティティーにポリシーが添付され、その結果として添付が変更される場合があります。ポリシーや他のエンティティーの更新方法の詳細については、この記事の対象外となるため割愛します。ここでは、ポリシー変更のきっかけとなるイベントをキャプチャーする方法について説明します。

ここで注目すべきなのは論理オブジェクトです。このポリシーに添付されたすべての操作を調べると、更新の必要なオブジェクトがキャッシュの中に見つかります。キャッシュ・キーが、操作のpolicyElementName と名前、そして名前空間を連結したものであることを思い出してください。このキーを使用することで、キャッシュされたポリシー情報をホストするメディエーションをすべて更新することができます。

この記事では、このシナリオの完全な実装については説明しませんが、実装の重要要素をいくつか説明します。例えば、さまざまなメディエーションの構成が頻繁に変更され (例えば WebSphere ESB の新しいインスタンスが追加されるなど)、それらの構成に容易にアクセスして更新できるようにしておく必要があるケースを考えてみてください。このケースをサポートするためには、Service Registry 標準の「ユーザー構成」を使用してサーバーのプロパティーを指定します。そうすると、構成パースペクティブを使って Service Registry の内部でユーザー構成を直接操作することができます。リスト 4 はユーザー構成ファイルの例を示しています。

リスト 4
<ServerConfigurations>
	<ServerConfiguration hostname="127.0.0.1" port="2819" />
	<ServerConfiguration hostname="127.0.0.1" port="2820" />
</ServerConfigurations>

ユーザー構成ファイルをロードするためには、Service Registry の管理コンソールを使います。構成パースペクティブを開き、「Active Configuration Profile (アクティブ構成プロファイル)」 => 「Plug-ins (プラグイン) => User Configurations (ユーザー構成)」の順に選択します。「Load User Configuration (ユーザー構成のロード)」を選択し、対象のファイル名を入力します。

リスト 5 は、この構成ファイルを利用するコード部分を示しています。このコードは CacheNotifier Java プロジェクトの com.ibm.sample.wsrr.notifier.userconfig パッケージの中にあります。

リスト 5
AdminService adminService = AdminServiceFactory.getAdminService();
byte[] bytes = null;
// Locate the ServiceRegistryRepository MBean
ObjectName queryName;
try {
	queryName = new ObjectName("WebSphere:type=ServiceRegistryRepository,*");
	Set s = adminService.queryNames(queryName, null);
		// Find the first MBean reference
	Iterator iter = s.iterator();
	ObjectName mBean = null;
	if (iter.hasNext()) {
		mBean = (ObjectName) iter.next();
		// got one
		// Format the call parameters
		String[] signature = new String[] { String.class.getName(), 
			String.class.getName() };
		Object[] params = new Object[] { configName, configType.toString() };
		bytes = (byte[]) adminService.invoke(mBean, "retrieveConfiguration", 
			params, signature);
	}
} catch (MalformedObjectNameException e) {
...
}

このコードは単純に Service Registry の通知プラグインによって呼び出されます。非常に単純なサンプルが、CacheNotifier Java プロジェクトの com.ibm.sample.wsrr.notifier パッケージの中に含まれています。この通知プラグインを構成する方法については、Service Registry インフォメーション・センターの「プラグインの構成」セクションを参照してください。


拡張キャッシュ・モニターを使う

今度は最初の実行シナリオに戻り、キャッシュの調整方法を調べてみましょう。ここでは、キャッシュ・モニターを使用してキャッシュ動作の有用な情報を得る方法のみを説明します。キャッシュ・モニターによって得られた統計を使用することで、キャッシュの構成、サイズ、タイムアウト、ディスクへの移動を有効にするかどうか、などを変更し、キャッシュを微調整することができます。また、キャッシュ・ヒットとキャッシュ・ミスの回数を検証してキャッシュの効率をチェックすることもできます。

キャッシュ・モニター・アプリケーションをインストールするためには、WebSphere Application Server に用意されているデフォルトのキャッシュ・モニター・アプリケーションをインストールした後、このアプリケーションを、「Extended Cache Monitor technology preview」に用意されているアプリケーションを使って更新する必要があります。このインストールが完了したら、セキュリティー・ロールでサインインし、以下のようにしてユーザーとグループのマッピングを実行します。

  1. ブラウザーで、キャッシュ・モニター用 Web アプリケーションの URL (この場合は http://127.0.0.1:9080/cachemonitor/logon.jsp) を入力します。
  2. 有効な組み合わせのユーザー ID とパスワードを入力します。
  3. オプション・メニュー (図 8) からモニター対象のキャッシュ・インスタンスを選択します。この場合は services/cache/PoliciesQueries を選択します。「OK」をクリックします。
    図 8. キャッシュ統計 - 適切なインスタンスを選択する
    キャッシュ統計 - 適切なインスタンスを選択する
  4. 左側のナビゲーション・パネルで「Cache Statistics (キャッシュ統計)」リンクをクリックします。このテストから、キャッシュにはエントリーが 1 つあり、ヒットは 17 回であったこと、そのうちの 3 回で検索対象の値が含まれていなかったことがわかります (図 9)。
    図 9. キャッシュ統計 - 結果
    キャッシュ統計 - 結果
  5. 「Cache Contents (キャッシュ内容)」リンクをクリックすると、そのキャッシュ・インスタンスの内容が表示されます (図 10)。
    図 10. キャッシュの内容
    キャッシュの内容

必要に応じて、キャッシュをクリアしたり、あるいは特定のエントリーを無効化したりすることも、キャッシュ・モニター・アプリケーションから行うことができます。


まとめ

この記事では、WebSphere Enterprise Service Bus の DistributedMap 機能を使用するとメディエーション・フロー・コンポーネントに手軽にキャッシュを追加できることを説明しました。この記事ではまず、キャッシュを追加するシナリオをいくつか検証しました。次に、この記事のダウンロード・セクションに用意したサンプルを利用して、キャッシュの追加方法を説明しました。そして最後に、拡張キャッシュ・モニター・アプリケーションの概要を簡単に説明しました。


謝辞

この記事の執筆に協力くださった、IBM Software Services for WebSphere チームの André Tost 氏に感謝いたします。


ダウンロード

内容ファイル名サイズ
Code samplePMWC_example_materials.zip334 KB

参考文献

学ぶために

製品や技術を入手するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=481396
ArticleTitle=WebSphere ESBのキャッシュによるWSRRからのカスタム・ポリシー取得時のパフォーマンス向上
publish-date=06242009