アプリケーション開発ガイド

     前  次    新しいウィンドウで目次を開く     
ここから内容の開始

Oracle CEP キャッシングの使用

この節では、以下の項目について説明します。

 

Oracle Complex Event Processing キャッシングの概要

Oracle Complex Event Processing (略称 Oracle CEP) アプリケーションでは、必要に応じてイベントをキャッシュにパブリッシュしたり、キャッシュのイベントを使用したりすることで、イベントの可用性を高め、アプリケーションのパフォーマンスを向上させることができます。キャッシュは、アプリケーション全体のパフォーマンス向上という目的専用に作成された、イベント用の一時的なストレージ領域です。アプリケーションが正常に機能するためにキャッシュは必ずしも必要ではありません。

Oracle CEP にはローカル single-JVM キャッシュ用の独自のキャッシング実装が含まれています。この実装はインメモリ ストアを使用します。レプリケートや分割などによるキャッシングを提供する異なる種類のキャッシュが必要な場合は、Oracle Coherence などの異なるキャッシュ プロバイダを接続できます。Oracle Coherence の使用に関する詳細については、「Coherence のサポート」を参照してください。

このマニュアルの「キャッシング システム」とは、製品に付属のローカル キャッシングまたはサードパーティ製のキャッシングのいずれかのうち、コンフィグレーションされたキャッシング実装のインスタンスを表します。キャッシング システムでは、コンフィグレーションされた「キャッシュ」の名前付きセットと、複数のマシンにキャッシュが分散されている場合のリモート通信用のコンフィグレーションが定義されます。

実装 (Oracle CEP またはサードパーティ) に関係なく、キャッシング システムは常にアプリケーション レベルでコンフィグレーションされます。別のバンドルの他の Oracle CEP アプリケーションがキャッシング システムを使用することも可能です。

キャッシュは、外部の要素 (キャッシュ) によってイベントが使用または生成される、イベント処理ネットワークのステージとして考えることができます。これは、JMS 送り先を使用するアダプタと同じです。アプリケーションのキャッシング システムをコンフィグレーションする際は、1 つまたは複数のキャッシュと共に、EPN アセンブリ ファイルを使用して宣言します。ただし、キャッシュが実際にネットワークのステージである必要はありません。他のコンポーネントまたは Spring Bean ではプログラムからキャッシング API を使用してキャッシュにアクセスできます。

以下の節では、Oracle CEP キャッシング機能の具体的な使用例について説明します。

使用例 : キャッシュへのイベントのパブリッシュ

この使用例は、金融マーケットが開いている間はイベントをキャッシュにパブリッシュし、マーケット終了後にキャッシュのデータを処理する金融アプリケーションです。

キャッシュにイベントをパブリッシュすることで、サーバで実行中の他の Oracle CEP アプリケーションでイベントを使用できるようになります。また、キャッシュにイベントをパブリッシュすることで、キャッシュ実装による 2 次ストレージへの非同期書き込みも許可されます。イベントを生成し (入力アダプタ、ストリーム、ビジネス POJO、またはプロセッサ)、キャッシュにイベントをパブリッシュする、Oracle CEP アプリケーションの任意のステージをコンフィグレーションできます。

使用例 : キャッシュのデータの使用

Oracle CEP アプリケーションでは、ときには処理を実行するためストリーミング以外のデータにアクセスする必要があります。このようなデータをキャッシュすることで、アプリケーションのパフォーマンスが向上します。

プログラムによりキャッシュに直接アクセスできる Oracle CEP アプリケーションの標準のコンポーネントは、入力および出力アダプタ、およびビジネス POJO です。

また、アプリケーションではユーザ定義の EPL 関数を通じて、または EPL 文から直接アクセスすることで、EPL からキャッシュにアクセスできます。ユーザ定義 EPL 関数の場合、プログラマは Spring を使用してキャッシュ リソースを関数の実装に挿入します。アプリケーションは、プロセッサで実行する EPL 文から直接キャッシュにクエリを実行することもできます。この場合、キャッシュは本質的にプロセッサに対して別のタイプのストリーム データ ソースとして機能するため、キャッシュへのクエリの実行は、キャッシュからデータが取り出されることを除けばストリームへのクエリの実行とほぼ同じです。

EPL を使用してキャッシュへのクエリを実行する例には、金融アプリケーションが注文や注文の実行に使用された取引をキャッシュにパブリッシュする場合があります。マーケットが終了する一日の終わりに、アプリケーションはキャッシュへのクエリを実行し、特定の注文に関連するすべての取引を検索します。

使用例 : キャッシュのデータの更新と削除

Oracle CEP アプリケーションでは、必要に応じてキャッシュのデータを更新および削除できます。

たとえば、金融アプリケーションでは注文を実現する個々の取引が実行されるたびにキャッシュ内の注文を更新し、注文が取り消された場合はこれを削除する必要があります。キャッシュ内のデータの使用が許可されたアプリケーションのコンポーネントには、データの更新も許可されます。

その他のキャッシング機能

上記に示す主なキャッシング機能のほか、Oracle CEP キャッシングには以下の機能もあります。

キャッシング API

Oracle CEP には、アプリケーションで特定のタスクを実行するために使用できる多数のキャッシング API が用意されています。API の 2 つのパッケージがあります。

キャッシング システムとキャッシュの作成、コンフィグレーション、および接続はすべて EPN アセンブリ ファイルとコンポーネント コンフィグレーション ファイルを使用して行います。このため、通常はアプリケーションで Cache および CachingSystem インタフェースを明示的に使用することはありません。標準のコンフィグレーション以外の追加要件がある場合にのみ、これらのインタフェースを使用します。たとえば、サードパーティ製キャッシュ プロバイダとの統合を提供する場合は、CachingSystem インタフェースを使用する必要があります。キャッシュで java.util.Map インタフェース以外の操作を実行する必要がある場合は、Cache インタフェースを使用できます。

キャッシュ リスナ、ローダ、またはストアを作成する場合は、Spring Bean で CacheListener、CacheLoader、または CacheStore インタフェースを実装する必要があります。以下の節では、追加の詳細について説明します。

 

Oracle CEP キャッシングを使用する一般的な手順

以下の手順で説明しているとおり、キャッシュを使用する方法に応じて異なるタスクを実行する必要があります。追加の詳細を示す節を参照してください。

注意 : この節では、Oracle CEP アプリケーションが EPN アセンブリ ファイルを使用してすでに作成済みであり、キャッシングを使用するようにアプリケーションを更新する必要があると想定しています。まだ作成していない場合は、詳細について「Oracle Complex Event Processing アプリケーションの作成の概要」を参照してください。
  1. アプリケーションのキャッシング コンフィグレーション ファイルを更新することで、キャッシング システムと、1 つまたは複数のキャッシュをコンフィグレーションします。

    2. 「Oracle CEP キャッシング システムとキャッシュのコンフィグレーション」を参照してください。

  2. EPN アセンブリ ファイルでキャッシング システムを宣言します。

    3. 「EPN アセンブリ ファイルでのキャッシング システムの宣言」を参照してください。

  3. EPN アセンブリ ファイルでキャッシュを宣言します。

    4. EPN アセンブリ ファイルでのキャッシュの宣言

  4. 必要に応じて、キャッシュにアクセスするアダプタ、ビジネス POJO、または EPL ユーザ定義関数をコンフィグレーションおよびプログラミングします。コンフィグレーションは EPN アセンブリ ファイルで行います。プログラミングは POJO、アダプタ、または EPL ユーザ定義関数を実装する Java ファイルで行います。以下を参照してください。
  5. 必要に応じて、イベント処理ネットワークの別のコンポーネントに対するリスナとしてコンフィグレーションすることによって、キャッシュをイベント シンクとして指定します。

    6. 「リスナとしてのキャッシュのコンフィグレーション」を参照してください。

  6. 必要に応じて、キャッシュをイベント処理ネットワークの別のコンポーネントによってリスンされるイベント ソースとして指定します。

    7. 「イベント ソースとしてのキャッシュのコンフィグレーション」を参照してください。

  7. 必要に応じて、キャッシュのキャッシュ ローダまたはキャッシュ ストアをコンフィグレーションします。以下を参照してください。
  8. 必要に応じて、EPL 文でキャッシュを参照します。「EPL 文からのキャッシュの参照」を参照してください。

Oracle CEP キャッシング システムとキャッシュのコンフィグレーション

キャッシング システムおよびキャッシュのコンフィグレーションは、プロセッサやアダプタなどのイベント処理ネットワークの他のコンポーネントをコンフィグレーションする場合と同じように、キャッシング コンフィグレーション ファイルで行います。これらのコンフィグレーション ファイルの概要については、「コンポーネント コンフィグレーション ファイル」を参照してください。

Oracle CEP インスタンスごとにコンフィグレーションできるキャッシング システムの数は、使用するキャッシング実装によって異なります。たとえば、サードパーティ製のキャッシング実装 Gemfire では、Oracle CEP のインスタンス 1 つにつきキャッシング システムを 1 つのみコンフィグレーションできることが指定されます。ただし、Oracle CEP で提供されるキャッシング実装を使用する場合は、1 つのアプリケーションにつき複数のキャッシング システムをコンフィグレーションできます。

以下の手順では、Oracle CEP でアプリケーションに提供されるキャッシング システムをコンフィグレーションするための主な手順を示します。簡略化のため、この手順ではキャッシング システムを含むアプリケーションのすべてのコンポーネントが 1 つのコンフィグレーション XML ファイルにコンフィグレーションされ、アプリケーションのこのファイルがすでに作成されていると想定します。

キャッシング システムのコンフィグレーション ファイルの要素を記述する完全な XSD スキーマについては、コンポーネント コンフィグレーション ファイルの XSD スキーマ リファレンスを参照してください。

  1. 任意の XML エディタを使用してコンフィグレーション XML ファイルを開きます。
  2. <config> ルート要素の <caching-system> 子要素を追加します。<name> 子要素を使用してユニークに識別します。この name 値は、後で必要に応じて、アプリケーションのイベント処理ネットワークを定義する EPN アセンブリ ファイルで <wlevs:caching-system> タグの id 属性として使用します。このように指定することで、Oracle CEP では、このキャッシング コンフィグレーションが適用される EPN アセンブリ ファイル内の特定のキャッシング システムを認識します。詳細については、「EPN アセンブリ ファイルでのキャッシング システムの宣言」を参照してください。

    3. たとえば、コンフィグレーション ファイルにはすでにプロセッサとアダプタが含まれているとします (簡略化のため内容は省略します)。更新されたファイルは、以下のようになります。 

    <?xml version="1.0" encoding="UTF-8"?>
    <n1:config xmlns:n1="http://www.bea.com/ns/wlevs/config/application"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <processor>
       ...
    </processor>
      <adapter>
       ...
    </adapter
      <caching-system>
         <name>caching-system-id</name>
      </caching-system>
    </n1:config>
  3. 作成する必要のある各キャッシュについて、<caching-system> 要素の <cache> 子要素を追加します。<name> 子要素を使用してユニークに識別します。この name 値は、後からアプリケーションのイベント処理ネットワークを定義する EPN アセンブリ ファイルで <wlevs:cache> タグの id 属性として使用します。このように指定することで、Oracle CEP では、このコンフィグレーションが適用される EPN アセンブリ ファイル内の特定のキャッシュを認識します。次の例は、キャッシング システムの 2 つのキャッシュを示します。
    4.   <caching-system>
         <name>caching-system-id</name>
         <cache>
            <name>cache-id</name>
           ...
    </cache>
         <cache>
            <name>second-cache-id</name>
           ...
    </cache>
      </caching-system>
  4. 各キャッシュについて、必要に応じて以下の単純データ型の要素を追加して、キャッシュをコンフィグレーションします。
    • <max-size> : 追い出しまたはページングの発生を引き起こすメモリ内のキャッシュ要素の数。キャッシュの最大サイズは 231 -1 エントリです。デフォルトは 64 です。
    • <eviction-policy> : max-size に達した場合に使用される追い出しポリシー。サポートされている値は FIFO、LRU、LFU、および NRU です。デフォルト値は LFU です。
    • <time-to-live> : エントリがキャッシュされるミリ秒単位の最大時間数。デフォルト値は無限です。
    • <idle-time> : キャッシュされたエントリが実際にキャッシュから削除されるまでのミリ秒単位の時間数。デフォルト値は無限です。
    • <work-manager-name> : すべての非同期操作に使用されるワーク マネージャ。この要素の値は、サーバの config.xml コンフィグレーション ファイル内の <work-manager> 要素の <name> 子要素に対応しています。

      • 例を示します。 

        <caching-system>
           <name>caching-system-id</name>
           <cache>
             <name>cache-id</name>
             <max-size>100000</max-size>
             <eviction-policy>LRU</eviction-policy
             <time-to-live>3600</time-to-live>
           </cache>
        </caching-system>
  5. 必要に応じて、<cache> の <write-through> または <write-behind> 子要素を追加して、キャッシュ ストアへの同期または非同期の書き込みをそれぞれ指定します。デフォルトでは、ストアへの同期書き込みが行われ (<write-through>)、エントリが作成または更新されるとすぐに書き込みが発生します。

    6. <write-behind> 要素を指定した場合は、キャッシュ エントリの作成または更新後に別のスレッドからキャッシュ ストアが呼び出されます。以下の省略可能な子要素を使用して、ストアへの非同期書き込みをさらにコンフィグレーションします。

    • <work-manager-name> : キャッシュ ストアへの非同期書き込みを処理するワーク マネージャ。キャッシュ自身にワーク マネージャが指定されている場合は、ストアの操作についてのみこの値でオーバーライドされます。この要素の値は、サーバの config.xml コンフィグレーション ファイル内の <work-manager> 要素の <name> 子要素に対応しています。
    • <batch-size> : バッキング ストアに書き込むためにストア バッファから選択される更新の数。デフォルト値は 1 です。
    • <buffer-size> : ストアへの書き込みが必要な非同期の更新が一時的に格納される内部ストア バッファのサイズ。デフォルト値は 100 です。
    • <buffer-write-attemps> : ユーザ スレッドがストア バッファへの書き込みを試行する回数。ユーザ スレッドはキャッシュ エントリを作成または更新するスレッドです。ユーザ スレッドによるストア バッファへの書き込みの試行がすべて失敗した場合は、ストアが同期的に呼び出されます。デフォルト値は 1 です。
    • <buffer-write-timeout> : ストア バッファへの書き込みの試行が中止されるまでユーザ スレッドが待機するミリ秒単位の時間。ストア バッファへの書き込みの試行が失敗するのは、バッファが一杯になった場合のみです。タイムアウト後は、buffer-write-attempts の値に基づいてバッファへの書き込みがさらに試行されます。デフォルト値は 100 です。

      • 例を示します。 

        <caching-system>
           <name>caching-system-id</name>
           <cache>
              <name>cache-id</name>
              <max-size>100000</max-size>
              <eviction-policy>LRU</eviction-policy
              <time-to-live>3600</time-to-live>
              <write-behind>
                <buffer-size>200</buffer-size>
                <buffer-write-attempts>2</buffer-write-attempts>
                <buffer-write-timeout>200</buffer-write-timeout>
              </write-behind>
           </cache>
        </caching-system>
  6. 必要に応じて、<cache> の <listeners> 子要素を追加してキャッシュをリスンするコンポーネントの動作をコンフィグレーションします。

    7. asynchronous ブール属性を使用して、リスナが非同期で呼び出されるかどうかを指定します。デフォルトではこの属性は false であるため、リスナは同期的に呼び出されます。

    <listeners> 要素には 1 つの子要素 <work-manager-name> があり、これはリスナの非同期呼び出しに使用されるワーク マネージャを指定します。同期呼び出しが有効な場合、この値は無視されます。キャッシュ自身にワーク マネージャが指定されている場合は、リスナの呼び出しについてのみこの値でオーバーライドされます。この要素の値は、サーバの config.xml コンフィグレーション ファイル内の <work-manager> 要素の <name> 子要素に対応しています。

    例を示します。 

      <caching-system>
         <name>caching-system-id</name>
         <cache>
            <name>cache-id</name>
            <max-size>100000</max-size>
            <eviction-policy>LRU</eviction-policy
            <time-to-live>3600</time-to-live>
            <write-behind>
              <buffer-size>200</buffer-size>
              <buffer-write-attempts>2</buffer-write-attempts>
              <buffer-write-timeout>200</buffer-write-timeout>
            </write-behind>
            <listeners asynchronous="true">
              <work-manager-name>cachingWM</work-manager-name>
            </listeners>
         </cache>
      </caching-system>

EPN アセンブリ ファイルでのキャッシング システムの宣言

Oracle CEP 実装を使用するキャッシング システムを EPN アセンブリ ファイルで宣言するには、次の例のように、追加属性なしで <wlevs:caching-system> タグを使用します。 

  <wlevs:caching-system id="caching-system-id"/>

id 属性の値は外部コンフィグレーション メタデータでキャッシング システムに指定された名前と一致している必要があります。アプリケーションで他のアプリケーションにキャッシング システムの使用を許可する場合は、advertise 属性を使用してキャッシング システムが公開されるよう指定できます (デフォルトの設定は false です)。 

  <wlevs:caching-system id="caching-system-id" advertise="true"/>

<wlevs:caching-system> タグは、サードパーティ実装の宣言にも使用します。class または provider 属性を使用して追加情報を指定します。

注意 : キャッシング プロバイダとして Oracle Coherence を使用する場合の具体的な手順については、「Coherence のサポート」を参照してください。

簡略化のため、Oracle CEP アプリケーション バンドル自身の内部にサードパーティ実装コードを含めると、パッケージをインポートまたはエクスポートする必要がなくなり、サードパーティ実装が含まれる別のバンドルのライフサイクルを管理せずに済みます。この場合、EPN アセンブリ ファイルの <wlevs:caching-system> タグは、次の例のようになります。 

  <wlevs:caching-system id="caching-system-id" 
                         class="third-party-implementation-class"/>

class 属性で指定する Java クラスは、com.bea.wlevs.cache.spi.CachingSystem インタフェースを実装する必要があります。このインタフェースの詳細については、Oracle CEP の Javadoc を参照してください。

ときには、使用する側の Oracle CEP アプリケーションと同じバンドルにサードパーティのキャッシング実装を含めることができない場合があります。この場合は、別のバンドルを作成し、Spring アプリケーション コンテキストの <wlevs:caching-system> タグに必須の advertise 属性を指定する必要があります。 

  <wlevs:caching-system id ="caching-system-id" 
                         class="third-party-implementation-class"
                          advertise="true"/>

または、実装のバンドルを参照元のバンドルから切り離す必要がある場合や、Java プロセスを通じて複数のキャッシング システムがサポートされるキャッシング実装を接続している場合は、プロバイダとしてファクトリを指定できます。 

  <wlevs:caching-system id ="caching-system-id" 
                         provider="caching-provider"/>
  <factory id="factory-id" provider-name="caching-provider">
     <class>the.factory.class.name</class>
  </factory>

ファクトリ クラス (この例の the.factory.class.name) は、com.bea.wlevs.cache.spi.CachingSystemFactory インタフェースを実装する必要があります。このインタフェースに含まれている 1 つのメソッド create() では、com.bea.wlevs.cache.spi.CachingSystem インスタンスが返されます。

アプリケーション バンドルが実装の使用を開始できるよう、アプリケーション バンドルと共にこのバンドルをデプロイする必要があります。

EPN アセンブリ ファイルでのキャッシュの宣言

アプリケーションのキャッシング システムを宣言した後、<wlevs:cache> タグを使用して 1 つまたは複数のキャッシュをコンフィグレーションできます。 

    <wlevs:caching-system id="caching-system-id"/>
    ...
<wlevs:cache id="cache-id" name="alternative-cache-name">
        <wlevs:caching-system ref="caching-system-id"/>
    </wlevs:cache>

name 属性は省略可能です。これは、キャッシング システム内のキャッシュの名前が ID と異なる場合にのみ指定します。<wlevs:caching-system> 子要素は、キャッシュを包含している、すでに宣言されたキャッシング システムを参照します。この子要素はキャッシング システムがあいまいな場合にのみ指定する必要があります。複数のキャッシング システムが (暗黙的または明示的に) 宣言されている場合や、キャッシング システムが異なるアプリケーションまたはバンドルに含まれている場合などです。

advertise 属性を使用して、キャッシング システムとキャッシュの両方を OSGI サービスとしてエクスポートできます。 

    <wlevs:caching-system id="caching-system-id" advertise="true"/>
    ...
<wlevs:cache id="cache-id" name="alternative-cache-name" advertise="true" >
        <wlevs:caching-system ref="caching-system-id"/>
    </wlevs:cache>

公開されたキャッシュは、別のバンドルにあるアプリケーションの EPN のコンポーネントから参照できるようになります。次の例は、あるバンドルのプロセッサが、別のバンドル (cacheprovider) にある ID が cache-id のキャッシュをキャッシュ ソースとして使用する方法を示します。 

 <wlevs:processor id="myProcessor2">
      <wlevs:cache-source ref="cacheprovider:cache-id"/>
  </wlevs:processor>

キャッシング システムでは、特定の名前に関連付けられたキャッシュが作成され、そのキャッシュへの参照が返されます。生成されたキャッシュ Bean は java.util.Map インタフェースを実装します。

キャッシュにアクセスするビジネス POJO のコンフィグレーションとプログラミング

EPN アセンブリ ファイルで標準の Spring Bean としてコンフィグレーションされたビジネス POJO では、他の Bean を参照するための標準の Spring メカニズムを使用して、キャッシュを挿入することができます。この方法によって、POJO ではキャッシュを表示および操作できます。キャッシュ Bean では、ビジネス POJO が挿入されたキャッシュにアクセスするために使用する java.util.Map インタフェースが実装されます。キャッシュ Bean では java.util.Map のベンダ固有のサブインタフェースを実装することもできますが、移植性のために Map を実装することをお勧めします。

まず、FX サンプルの Output Bean に基づいた以下の例のように、EPN アセンブリ ファイルのビジネス POJO のコンフィグレーションを <property> 子要素を使用して更新する必要があります (「Helloworld のサンプル」を参照)。 

    <wlevs:caching-system id="caching-system-id"/>
    ...
<wlevs:cache id="cache-id" name="alternative-cache-name">
        <wlevs:caching-system ref="caching-system-id"/>
    </wlevs:cache>
    ...
<bean class="com.bea.wlevs.example.helloworld.HelloWorldBean">
        <property name="map" ref="cache-id"/>
    </bean>

この例で、<property> の ref 属性は <wlevs:cache> タグの id 値を参照しています。Oracle CEP では java.util.Map として実装されたキャッシュがビジネス POJO Bean に自動的に挿入されます。

ビジネス POJO Bean の Java ソースで、setMap (Map) メソッドを追加し、POJO がキャッシュを操作する任意の処理を実装するコードを作成します。 

  package com.bea.wlevs.example.helloworld;
  …
  import java.util.Map;
  public class HelloWorldBean implements EventSink {
  ...
    public void setMap (Map map) {...}
  }

キャッシュにアクセスするアダプタのコンフィグレーションとプログラミング

アダプタにも、他の Bean を参照するための標準の Spring メカニズムを使用してキャッシュを挿入することができます。キャッシュ Bean では、アダプタが挿入されたキャッシュにアクセスするために使用する java.util.Map インタフェースが実装されます。

まず、次の例のように、<wlevs:instance-property> 子要素を使用して EPN アセンブリ ファイルのアダプタのコンフィグレーションを更新する必要があります。 

    <wlevs:caching-system id="caching-system-id"/>
    ...
<wlevs:cache id="cache-id" name="alternative-cache-name">
        <wlevs:caching-system ref="caching-system-id"/>
    </wlevs:cache>
    ...
<wlevs:adapter id="myAdapter" provider="myProvider">
         <wlevs:instance-property name="map" ref="cache-id"/>
    </wlevs:adapter>

この例で、<wlevs:instance-property> の ref 属性は <wlevs:cache> タグの id 値を参照しています。Oracle CEP では java.util.Map として実装されたキャッシュがアダプタに自動的に挿入されます。

アダプタの Java ソースで、setMap (Map) メソッドを追加し、アダプタがキャッシュを操作する任意の処理を実装するコードを作成します。 

  package com.bea.wlevs.example;
  …
  import java.util.Map;
  public class MyAdapter implements Runnable, Adapter, EventSource, SuspendableBean  {
  ...
    public void setMap (Map map) {...}
  }

キャッシュにアクセスするユーザ定義 EPL 関数のコンフィグレーションとプログラミング

標準のイベント ストリームのほか、EPL ルールでもユーザ定義関数のメンバー メソッドを呼び出すことができます。

これらのユーザ定義関数は、標準の Java クラスとして実装され、次の例のように EPN アセンブリ ファイルで標準の Spring Bean タグを使用して宣言されています。 

    <bean id="orderFunction" class="orderFunction-impl-class"/>

関連する EPL ルールが実行されるプロセッサでは、<wlevs:function> 子要素を使用してユーザ定義関数を挿入する必要があり、ref 属性で Spring を参照します。 

    <wlevs:processor id= "tradeProcessor">
        <wlevs:function ref="orderFunction"/>
    </wlevs:processor>

次の EPL ルールは、tradeProcessor プロセッサにコンフィグレーションされていると想定され、orderFunction ユーザ定義関数の existsOrder() メソッドを呼び出す方法を示します。 

INSERT INTO InstitutionalOrder
SELECT er.orderKey AS key, er.symbol AS symbol, er.shares as cumulativeShares
FROM ExecutionRequest er RETAIN 8 HOURS WITH UNIQUE KEY
WHERE NOT orderFunction.existsOrder(er.orderKey)

キャッシュにアクセスするユーザ定義関数をコンフィグレーションする際は、他の Bean を参照するための標準の Spring メカニズムを使用して関数にキャッシュを挿入することもできます。キャッシュ Bean では、ユーザ定義関数が挿入されたキャッシュにアクセスするために使用する java.util.Map インタフェースが実装されます。

まず、次の例のように、<wlevs:property> 子要素を使用して EPN アセンブリ ファイルのユーザ定義関数のコンフィグレーションを更新する必要があります。 

    <wlevs:caching-system id="caching-system-id"/>
    ...
<wlevs:cache id="cache-id" name="alternative-cache-name">
        <wlevs:caching-system ref="caching-system-id"/>
    </wlevs:cache>
    ...
<bean id="orderFunction" class="orderFunction-impl-class">
        <wlevs:property name="cache" ref="cache-id"/>
    </bean>

この例で、<wlevs:property> の ref 属性は <wlevs:cache> タグの id 値を参照しています。Oracle CEP では java.util.Map として実装されたキャッシュがユーザ定義関数に自動的に挿入されます。

ユーザ定義関数の Java ソースで、setMap (Map) メソッドを追加し、関数がキャッシュを操作する任意の処理を実装するコードを作成します。 

  package com.bea.wlevs.example;
  …
  import java.util.Map;
  public class OrderFunction {
  ...
    public void setMap (Map map) {...}
  }

リスナとしてのキャッシュのコンフィグレーション

イベントを受信するために、イベント処理ネットワークでキャッシュを明示的なリスナとしてコンフィグレーションできます。

たとえば、ストリームをリスンするキャッシュを指定するには、<wlevs:stream> タグの子要素として <wlevs:listener> タグでキャッシュへの参照を指定します。 

    <wlevs:caching-system id="caching-system-id"/>
    ...
<wlevs:cache id="cache-id" name="alternative-cache-name">
        <wlevs:caching-system ref="caching-system-id"/>
    </wlevs:cache>
    ...
<wlevs:stream id="tradeStream">
        <wlevs:listener ref="cache-id"/>
    </wlevs:stream>

ストリームから新しいイベントがキャッシュに送信されると、それらのイベントはキャッシュに挿入されます。削除イベント (出力枠を離れる古いイベント) がストリームから送信されると、イベントがキャッシュから削除されます。

キャッシュのインデックスに使用されるキーの指定

キャッシュをリスナとしてコンフィグレーションした場合は、イベントがキャッシュに挿入されます。この節では、このインスタンスのキャッシュのインデックス作成に使用されるキーを指定する場合のさまざまなオプションについて説明します。

キーを明示的に指定しない場合は、イベントがキャッシュに挿入された場合に、イベント オブジェクト自体がキーおよび値の両方として機能します。この場合、イベント クラスにはキー プロパティの値を考慮する equals および hashcode メソッドの有効な実装が含まれている必要があります。

キーの明示的な指定方法については、以下を参照してください。

EPN アセンブリ ファイルでのキー プロパティの指定

最初のオプションは、次の例のように、EPN アセンブリ ファイルでキャッシュを宣言するときに key-properties 属性を使用してキー プロパティのプロパティ名を指定する方法です。 

    <wlevs:cache id="cache-id" key-properties="key-property-name">
        <wlevs:caching-system ref="caching-system-id"/>
    </wlevs:cache>

この場合、キャッシュに挿入されるすべてのイベントで実行時にこの名前のプロパティを保持することが要求され、それ以外の場合は Oracle CEP で例外が送出されます。

たとえば、以下のようなイベント タイプがキャッシュに挿入されるとします。key プロパティに注意してください (ここでは、関連する Java ソースのみを示します)。 

public class MyEvent {
    private String key;
    public MyEvent() {
    }
    public MyEvent(String key) {
        this.key = key;
    }
    public String getKey() {
        return key;
    }
    public void setKey(String key) {
        this.key = key;
    }
 ...
}

EPN アセンブリ ファイルの対応する宣言は、以下のようになります。 

    <wlevs:cache id="cache-id" key-properties="key">
        <wlevs:caching-system ref="caching-system-id"/>
    </wlevs:cache>
メタデータ アノテーションを使用したキーの指定

2 つ目のオプションは、メタデータ アノテーション com.bea.wlevs.ede.api.Key を使用して、イベント タイプを実装する Java クラスのイベント プロパティにアノテーションを付ける方法です。このアノテーションに属性はありません。

次の例は、MyEvent イベント タイプの key プロパティをキーとして指定する方法を示します。ここでは、関連するコードのみを示します。 

import com.bea.wlevs.ede.api.Key;
public class MyEvent {
    @Key
    private String key;
    public MyEvent() {
    }
    public MyEvent(String key) {
        this.key = key;
    }
    public String getKey() {
        return key;
    }
    public void setKey(String key) {
        this.key = key;
    }
 ...
}
複合キーの指定

最後のオプションは、<wlevs:cache> タグの key-class 属性を使用して、複数のプロパティによってキーが形成される複合キーを指定する方法です。key-class 属性の値は、パブリック フィールドがイベント クラスのフィールドに一致する JavaBean である必要があります。照合はフィールド名に基づいて行われます。例を示します。 

    <wlevs:cache id="cache-id" key-class="key-class-name">
        <wlevs:caching-system ref="caching-system-id"/>
    </wlevs:cache>

イベント ソースとしてのキャッシュのコンフィグレーション

キャッシュは、イベント処理ネットワークの別のコンポーネントによってリスンされるイベント ソースとしてコンフィグレーションできます。リスンするコンポーネントは、アダプタまたは標準の Spring Bean です。キャッシュをリスンするコンポーネントは com.bea.cache.jcache.CacheListener インタフェースを実装する必要があります。次の例は、Spring Bean のイベント ソースとしてキャッシュをコンフィグレーションする方法を示します。 

    <wlevs:caching-system id="caching-system-id"/>
    ...
<wlevs:cache id="cache-id" name="alternative-cache-name">
        <wlevs:caching-system ref="caching-system-id"/>
        <wlevs:cache-listener ref="cache-listener-id" />
    </wlevs:cache>
    ...
<bean id="cache-listener-id" class="wlevs.example.MyCacheListener"/>

この例では、cache-listener-id Spring Bean はキャッシュから送られてくるイベントをリスンします。このコンポーネントを実装するクラスである wlevs.example.MyCacheListener は、com.bea.jcache.CacheListener インタフェースを実装する必要があります。wlevs.example.MyCacheListener クラスはユーザ自身がプログラミングする必要があります。

キャッシュ ローダのコンフィグレーション

キャッシュ ローダはキャッシュにオブジェクトをロードするオブジェクトです。キャッシュ ローダをコンフィグレーションするには、以下の例のように <wlevs:cache> タグの <wlevs:cache-loader> 子要素を使用して、ロードを実行する Bean を指定します。 

    <wlevs:caching-system id="caching-system-id"/>
    ...
<wlevs:cache id="cache-id" name="alternative-cache-name">
        <wlevs:caching-system ref="caching-system-id"/>
        <wlevs:cache-loader ref="cache-loader-id" />
    </wlevs:cache>
    ...
<bean id="cache-loader-id" class="wlevs.example.MyCacheLoader"/>

この例では、cache-loader-id Spring Bean によってキャッシュへのロードが実行されます。キャッシュからは、<wlevs:cache-loader> 子要素の ref 属性を使用してこれを参照します。

wlevs.example.MyCacheLoader クラスはユーザ自身がプログラミングする必要があります。このクラスでは、com.bea.cache.jcache.CacheLoader インタフェースを実装する必要があります。このインタフェースには、キャッシュへの単一のオブジェクトのロードをカスタマイズする load() メソッドが含まれています。要求されたオブジェクトがキャッシュに存在しない場合は、Oracle CEP によってこのメソッドが呼び出されます。インタフェースには、キャッシュ全体のロードのカスタマイズが実装される loadAll() メソッドも含まれています。

キャッシュ ストアのコンフィグレーション

キャッシュからバッキング ストア (データベース内のテーブルなど) へのデータの書き込みを処理するカスタム ストアを持つキャッシュをコンフィグレーションできます。キャッシュ ストアをコンフィグレーションするには、以下の例のように <wlevs:cache> タグの <wlevs:cache-store> 子要素を使用して、実際の格納を実行する Bean を指定します。 

    <wlevs:caching-system id="caching-system-id"/>
    ...
<wlevs:cache id="cache-id" name="alternative-cache-name">
        <wlevs:caching-system ref="caching-system-id"/>
        <wlevs:cache-store ref="cache-store-id" />
    </wlevs:cache>
    ...
<bean id="cache-store-id" class="wlevs.example.MyCacheStore"/>

この例では、cache-store-id Spring Bean によってキャッシュからバッキング ストアへのデータの書き込みが実行されます。キャッシュからは、<wlevs:cache-store> 子要素の ref 属性を使用してこれを参照します。

wlevs.example.MyCacheStore クラスはユーザ自身がプログラミングする必要があります。このクラスでは、com.bea.cache.jcache.CacheStore インタフェースを実装する必要があります。このインタフェースには、渡されたキーを使用してデータをバッキング ストアに格納する store() メソッドが含まれています。キャッシュにデータが挿入されると、Oracle CEP によってこのメソッドが呼び出されます。このインタフェースには、<write-behind> コンフィグレーション要素を使用してキャッシュの非同期書き込みをコンフィグレーションした場合に、バッキング ストアにデータのバッチを格納する storeAll() メソッドも含まれています。

 

EPL 文からのキャッシュの参照

ストリームの参照とほとんど同じ方法で、EPL 文からキャッシュを参照できます。この機能では、標準のストリーミング データを異なるソースからのデータで拡張できます。たとえば、次の EPL クエリは標準のストリームからの取引イベントをキャッシュからの会社データと結合します。 

INSERT INTO EnrichedTradeEvent
SELECT trade.symbol, trade.price, trade.numberOfShares, company.name
FROM TradeEvent trade RETAIN 8 hours, Company company
WHERE trade.symbol = company.id

この例で、TradeEvent と Company は両方ともリポジトリに登録されたイベント タイプですが、TradeEvents は標準のイベントのストリームから送信され、Company はイベント処理ネットワークのキャッシュにマップされるようにコンフィグレーションされています。このコンフィグレーションは EPL クエリの外部で行われ、これはクエリ内でデータのソースが透過的であることを意味します。

EPL クエリでキャッシュからのデータを使用する場合、Oracle CEP ではストリームのようにデータがプッシュされる代わりに、データが取り出されます。このため、上記の例の場合、クエリはストリームによって取引イベントがプッシュされた場合にのみ実行されます。キャッシュ内の会社データによってクエリの実行が起動されることはなく、このデータは必要な場合にのみクエリによって取り出されます。

EPL 文でキャッシュを使用する場合の制限

EPL クエリでキャッシュを使用する場合は、以下の制限に従う必要があります。

EPL 文でキャッシュを参照する一般的な手順

以下の手順では、キャッシング システムとキャッシュがすでにコンフィグレーションされていることを想定しています。詳細については、「Oracle CEP キャッシングを使用する一般的な手順」を参照してください。

  1. まだ作成していない場合は、上記の例の Company などのキャッシュ データに対応するイベント タイプを作成し、イベント リポジトリに登録します。「イベント タイプの作成」を参照してください。
  2. キャッシュのデータにキー プロパティを指定します。これを行うにはいくつかの方法があります。詳細については、「キャッシュのインデックスに使用されるキーの指定」を参照してください。
  3. EPN アセンブリ ファイルで、EPN アセンブリ ファイルのキャッシュのコンフィグレーションを更新し、値のイベント タイプを更新します。<wlevs:cache> の value-type 属性を使用します。例を示します。
    4. <wlevs:caching-system id="caching-system-id"/>
    ...
    <wlevs:cache id="cache-id" 
                   name="alternative-cache-name"
                   value-type="Company">
        <wlevs:caching-system ref="caching-system-id"/>
      </wlevs:cache>
  4. EPN アセンブリ ファイルで、キャッシュを参照する <wlevs:cache-source> 子要素を追加して、キャッシュを参照する EPL クエリが実行されるプロセッサのコンフィグレーションを更新します。例を示します。
    5. <wlevs:stream id="stream-id"/>
    <wlevs:processor id="processor-id">
        <wlevs:cache-source ref="cache-id">
        <wlevs:source ref="stream-id">
      </wlevs:processor>

    この例では、通常どおり stream-id ストリームからプロセッサにデータがプッシュされます。ただし、プロセッサ内で実行される EPL クエリも、cache-id キャッシュからデータを取り出すことができます。クエリ プロセッサが FROM 句のイベント タイプとキャッシュによって提供されたイベント タイプ (Company など) を照合するとき、プロセッサはそのイベント タイプのインスタンスをキャッシュから取り出します。

 

Coherence のサポート

この節では、Oracle Coherence をキャッシュ プロバイダとして使用する方法について説明します。この手順はローカルのインメモリ Oracle CEP キャッシュを使用する手順とほぼ同じであるため、最初に以下の節を必ずお読みください。

異なる点は、アプリケーションの EPN アセンブリ ファイルで Coherence キャッシュ プロバイダを宣言する方法と、Oracle CEP に Coherence のコンフィグレーションを渡す方法です。

また、キャッシュ リスナ、キャッシュ ローダ、およびキャッシュ ストアとして機能する Spring Bean を作成する場合は、上記の「キャッシュ ローダのコンフィグレーション」や「キャッシュ ストアのコンフィグレーション」などの節で説明しているインタフェースの代わりに、Coherence 固有の Java インタフェースを使用する必要があります。

EPN アセンブリ ファイルでの Coherence プロバイダの宣言

キャッシング プロバイダとしての Coherence の使用を指定するには、以下のように、アプリケーションの EPN アセンブリ ファイルで <wlevs:caching-system> タグの provider="coherence" 属性を使用します。 

   <wlevs:caching-system id="caching-system-id" provider="coherence"/>

このキャッシング システムのキャッシュは通常の方法で宣言され、上で宣言したキャッシング システムの ID を参照します。 

  <wlevs:cache id="myCache" advertise="false"> 
        <wlevs:caching-system ref="caching-system-id"/>
        <wlevs:cache-loader ref="localLoader"/> 
        <wlevs:cache-listener ref="localListener"/>
  </wlevs:cache>
  <bean id="localLoader" 
        class="com.bea.wlevs.example.provider.coherence.LocalLoader"/>
   <bean id="localListener" 
      class="com.bea.wlevs.example.provider.coherence.LocalListener"/>

<wlevs:cache> 要素の id="myCache" 属性は、Coherence コンフィグレーション ファイル内のキャッシュの名前にマップされます。これについては後述します。

Coherence プロバイダとローカルのインメモリ プロバイダの宣言での重要な違いは、Coherence を使用する場合、EPN アセンブリ ファイルの <wlevs:cache> 要素の <wlevs:cache-loader> または <wlevs:cache-store> の子要素はいずれもコンフィグレーションできますが、両方はコンフィグレーションできない点です。これは、Coherence ではローダとストアが 1 つのコンポーネントに結合されるためです。バッキング ストアが読み取り専用の場合はキャッシュ ローダを指定し、バッキング ストアが読み取り/書き込み可能な場合はキャッシュ ストアを指定します。

複数のアプリケーション バンドルで Coherence キャッシュを共有する必要がある場合は、適切な <wlevs:cache> および <wlevs:caching-system> が含まれた EPN アセンブリ ファイルを個別のバンドルに配置し、advertise 属性を true に設定する必要があります。

Coherence キャッシング システムのコンフィグレーション

Oracle CEP では Coherence で提供されるネイティブのコンフィグレーションが利用されます。これを行うには、Coherence キャッシングを使用するアプリケーション バンドルで、指定された名前を使用して以下の 2 つの Coherence コンフィグレーション ファイルをパッケージ化します。

アプリケーションをアセンブルする際に、これらの 2 つのファイルをバンドル JAR の META-INF/wlevs/coherence ディレクトリに配置します。このディレクトリがローカルのインメモリ Oracle CEP キャッシング プロバイダのコンポーネント コンフィグレーション ファイルが収められたディレクトリ (META-INF/wlevs) とは異なることに注意します。

キャッシング システムで Coherence プロバイダの使用を宣言する場合は、このキャッシング システムのすべてのキャッシュについても、ローカル コンフィグレーションの代わりに Coherence コンフィグレーションにマップされることを必ず確認してください。それ以外の場合は、Oracle CEP で例外が送出されます。

coherence-cache-config.xml ファイル

coherence-cache-config.xml ファイルは基本的な Coherence コンフィグレーション ファイルであり、他の Coherence アプリケーションと同様、Coherence DTD に準拠している必要があります。

以下の例は単純なコンフィグレーションを示します。太字部分に関する説明は例の後にあります。 

<?xml version="1.0"?>
<!DOCTYPE cache-config SYSTEM "cache-config.dtd">
<cache-config>
  <caching-scheme-mapping>
    <cache-mapping>
       <cache-name>myCoherenceCache</cache-name>
       <scheme-name>new-replicated</scheme-name>
     </cache-mapping>
     <cache-mapping>
       <cache-name>myLoaderCache</cache-name>
       <scheme-name>test-loader-scheme</scheme-name>
     </cache-mapping>
     <cache-mapping>
       <cache-name>myStoreCache</cache-name>
       <scheme-name>test-store-scheme</scheme-name>
     </cache-mapping>
  </caching-scheme-mapping>
  <caching-schemes>
    <replicated-scheme>
      <scheme-name>new-replicated</scheme-name>
      <service-name>ReplicatedCache</service-name>
      <backing-map-scheme>
        <class-scheme>
          <scheme-ref>my-local-scheme</scheme-ref>					
        </class-scheme>
      </backing-map-scheme>
    </replicated-scheme>
    <class-scheme>
       <scheme-name>my-local-scheme</scheme-name>
       <class-name>com.tangosol.net.cache.LocalCache</class-name>
       <eviction-policy>LRU</eviction-policy>
       <high-units>100</high-units>
       <low-units>50</low-units> 
    </class-scheme>
    <local-scheme>
       <scheme-name>test-loader-scheme</scheme-name>
       <eviction-policy>LRU</eviction-policy>
       <high-units>100</high-units>
       <low-units>50</low-units>
       <cachestore-scheme>
          <class-scheme>
             <class-factory-name>com.bea.wlevs.cache.coherence.configuration.SpringFactory</class-factory-name>
            <method-name>getLoader</method-name>
            <init-params>
              <init-param>
                <param-type>java.lang.String</param-type>
                <param-value>{cache-name}</param-value>
              </init-param>
            </init-params>
          </class-scheme>
       </cachestore-scheme>
    </local-scheme>
    <local-scheme>
      <scheme-name>test-store-scheme</scheme-name>
      <eviction-policy>LRU</eviction-policy>
      <high-units>100</high-units>
      <low-units>50</low-units>
      <cachestore-scheme>
        <class-scheme>
           <class-factory-name>com.bea.wlevs.cache.coherence.configuration.SpringFactory</class-factory-name>
          <method-name>getStore</method-name>
          <init-params>
            <init-param>
               <param-type>java.lang.String</param-type>
               <param-value>{cache-name}</param-value>
            </init-param>
          </init-params>
        </class-scheme>
      </cachestore-scheme>
    </local-scheme>
  </caching-schemes>
</cache-config>

Coherence コンフィグレーション ファイルでは、<cache-mapping> の子要素の <cache-name> 要素によって Coherence キャッシュの名前が識別されます。この要素の値は、EPN アセンブリ ファイルの <wlevs:cache> 要素の id 属性の値に厳密に一致している必要があります。たとえば、EPN アセンブリ ファイル内の以下のコードは、Coherence コンフィグレーション ファイルの myCoherenceCache キャッシュを参照します。 

  <wlevs:cache id="myCoherenceCache" advertise="false"> 
        <wlevs:caching-system ref="coherence-cache"/>
        <wlevs:cache-loader ref="localLoader"/> 
        <wlevs:cache-listener ref="localListener"/>
  </wlevs:cache>

Coherence コンフィグレーション ファイルでは、Oracle CEP で Coherence を使用する際のもう 1 つの要件が示されます。Spring を使用してキャッシュのローダまたはストアをコンフィグレーションする場合は、Coherence ファクトリを宣言する必要があります。これを行うには、Coherence コンフィグレーション ファイルで <cachestore-scheme> 要素を使用してファクトリ クラスを指定します。これにより、Coherence では Oracle CEP を呼び出し、キャッシュにコンフィグレーションされたローダまたはストアへの参照を取得することができます。ローダとストアのコンフィグレーションでの唯一の違いは、<method-name> 要素の値がローダの使用時は getLoader、ストアの使用時は getStore になる点です。ファクトリへの入力パラメータとしてキャッシュ名を渡します。

同一の Oracle CEP サーバにデプロイされる 1 つまたは複数のアプリケーションの EPN アセンブリ ファイルで Coherence キャッシュを宣言する場合、ローダまたはストアを持つ同じキャッシュについて、複数のインスタンスをコンフィグレーションしてはなりません。意図せずに、ローダまたはストアを持つ同じ Coherence キャッシュをそれぞれの EPN アセンブリ ファイルで個別にコンフィグレーションしている複数のアプリケーションを使用したために、このような結果になる場合があります。この場合は Oracle CEP で例外が送出されます。

複数のアプリケーション バンドルで Coherence キャッシュを共有する必要がある場合は、適切な <wlevs:cache> および <wlevs:caching-system> が含まれた EPN アセンブリ ファイルを個別のバンドルに配置し、advertise 属性を true に設定する必要があります。

coherence-cache-config.xml ファイルに関する詳細な情報については、Coherence のマニュアルを参照してください。

tangasol-coherence-override.xml ファイル

tangasol-coherence-override.xml ファイルでは Coherence クラスタがコンフィグレーションされます。

以下の例は単純なコンフィグレーションを示します。太字部分に関する説明は例の後にあります。 

<?xml version='1.0'?>
<coherence xml-override="/tangosol-coherence-override.xml">
  <cluster-config>
    <member-identity>
      <cluster-name>com.bea.wlevs.example.provider</cluster-name>
    </member-identity>
    <multicast-listener>
      <time-to-live system-property="tangosol.coherence.ttl">4</time-to-live>
      <join-timeout-milliseconds>3000</join-timeout-milliseconds>
    </multicast-listener>
    <packet-publisher>
      <packet-delivery>
        <timeout-milliseconds>30000</timeout-milliseconds>
      </packet-delivery>
    </packet-publisher>
  </cluster-config>
  <logging-config>
    <severity-level system-property="tangosol.coherence.log.level">5</severity-level>
    <character-limit system-property="tangosol.coherence.log.limit">0</character-limit>
  </logging-config>
</coherence>

このコンフィグレーション ファイルは標準的です。主に注意する点は、Oracle CEP の起動時に Coherence によって既存の Coherence クラスタの結合が試行されるのを防ぐため、<cluster-name> 要素を指定する必要がある点です。これは問題を引き起こす可能性があり、場合によっては Oracle CEP が起動しないこともあります。

tangasol-coherence-override.xml ファイルに関する詳細な情報については、Coherence のマニュアルを参照してください。


  ページの先頭       前  次