この節では、次の項目について説明します。
キャッシュとはイベントの一時保存領域で、Oracle CEPアプリケーションの全体のパフォーマンスを向上するために排他的に作成されます。アプリケーションが正常に機能するためには必要ありません。Oracle CEPアプリケーションは、オプションでイベントをキャッシュにパブリッシュしたりキャッシュから消費したりして、イベントの可用性およびアプリケーションのパフォーマンスを向上できます。
キャッシュ・システムとは、キャッシュ実装の構成されたインスタンスです。キャッシュ・システムは、構成されたキャッシュの名前付きセットを定義すると共に、任意のキャッシュが複数のマシンに渡って配信される場合、リモート通信用の構成を定義します。
Oracle CEPは、次のキャッシュ・システムをサポートします。
Oracle Coherence: クラスタリングされたアプリケーションおよびアプリケーション・サーバーのJCacheに準拠したメモリー内の分散型データ・グリッドソリューション。クラスタ全体の同時実行性制御を使用してデータへの更新を調整し、利用可能な最高性能のクラスタ・プロトコルを使用してクラスタ全体のデータ変更をレプリケートして、データ修正の通知を要求する任意のサーバーへの通知を分散化します。標準Java collections APIを使用してOracle Coherenceの機能を利用してデータへのアクセスおよびデータ変更を行い、標準JavaBeanイベント・モデルを使用してデータ変更通知を受信します。
注意: Oracle Coherenceと共にOracle CEPを使用する前に、Coherence Enterprise Edition、Coherence Grid Edition、またはOracle WebLogic Application Grid用ライセンスなどの有効なOracle Coherenceライセンスを取得する必要があります。Oracle Coherenceに関する詳細は、http://www.oracle.com/technology/products/coherence/index.html を参照してください。 |
サードパーティのキャッシュ: Oracle CEPをサードパーティの他のキャッシュ実装で機能することを可能にするプラグインを作成できます。
キャッシュは、イベント処理ネットワーク内のステージとみなされ、ここでは外部要素(キャッシュ)の消費やイベントの作成が行われます。これはJMSの宛先を使用するアダプタに似ています。ただし、キャッシュはネットワーク内の実際のステージである必要はなく、別のコンポーネントまたはSpring BeanがキャッシュAPIを使用し、プログラムによってキャッシュにアクセスできます。
キャッシュ・システムは、アプリケーション・レベルで常に構成されます。個別のバンドルで他のOracle CEPアプリケーションもキャッシュ・システムを使用できます。
アプリケーション内の各キャッシュ・システムの場合、コンポーネント構成ファイル内でcaching-system
要素を作成する必要があります。このcaching-system
要素では、キャッシュ・システム名および1つ以上のcache
要素を指定します。cache
要素では、次のようなオプションのキャッシュ構成を定義します。
最大キャッシュ・サイズ
削除ポリシー
存続時間
アイドル時間
書込みポリシー(write-none、write-through、またはwrite-behind)
ワーク・マネージャ
コンポーネント構成ファイルのcaching-system
要素のname
要素は、EPNアセンブリ・ファイルのcaching-system
要素のid
属性に一致する必要があります。たとえば、例12-1に示すようにEPNアセンブリ・ファイルのcaching-system
要素の場合、対応するコンポーネント構成ファイルのcaching-system
要素は例12-2で示されます。
例12-1 EPNアセンブリ・ファイルのキャッシュ・システムID: cacheSystem
<wlevs:caching-system id="cacheSystem"
>
...
</wlevs:caching-system>
<wlevs:cache id="cache1">
<wlevs:caching-system ref="cacheSystem"/>
</wlevs:cache>
例12-2 コンポーネント構成ファイルのキャッシュ・システム名: cacheSystem
<caching-system>
<name>cacheSystem</name>
<cache>
<name>cache1</name>
...
</cache>
</caching-system>
同様に、コンポーネント構成ファイルのcache
要素のname
要素は、EPNアセンブリ・ファイルのcache
要素のid
属性に一致する必要があります。たとえば、例12-1に示すようにEPNアセンブリ・ファイルのcache
要素の場合、対応するコンポーネント構成ファイルのcache
要素は例12-2で示されます。
例12-3 EPNアセンブリ・ファイルのキャッシュID: cache1
<wlevs:caching-system id="cacheSystem">
...
</wlevs:caching-system>
<wlevs:cache id="cache1">
<wlevs:caching-system ref="cacheSystem"/>
</wlevs:cache>
例12-4 コンポーネント構成ファイルのキャッシュ名: cache1
<caching-system>
<name>cacheSystem</name>
<cache>
<name>cache1</name>
...
</cache>
</caching-system>
次のコンポーネント構成ファイルのいずれかでcaching-system
要素を作成できます。
デフォルトのOracle CEPアプリケーションの構成ファイル(デフォルトでは、META-INF/wlevs/config.xml
)。
個別の構成ファイル。
アプリケーションが1つ以上のキャッシュ・システムを持つ場合、デフォルトのconfig.xml
ファイル内でそれぞれのキャッシュのcaching-system
要素を作成したり、それぞれのMETA-INF/wlevs
で個別のXMLファイルを作成したり、すべてのキャッシュ・システムの構成またはアプリケーションのすべてのコンポーネント(アダプタ、プロセッサ、およびチャネル)さえも含むMETA-INF/wlevs
で単一のXMLファイルを作成したりできます。開発環境に最適なメソッドを選択します。
デフォルトでは、Oracle CEP IDE for Eclipseは1つのコンポーネント構成ファイルと1つのEPNアセンブリ・ファイルを作成します。Oracle CEP IDE for Eclipseを使用してEPNにキャッシュを追加するとき、キャッシュ要素をEPNアセンブリ・ファイルに追加します。手動でcaching-system
要素をEPNアセンブリ・ファイルおよびコンポーネント構成ファイルに追加する必要があります。
コンポーネント構成ファイルは、Oracle CEPアプリケーション・バンドルの一部としてデプロイされます。Oracle CEP Visualizer、wlevs.Admin
ユーティリティを使用するか、または適切なJMX Mbeanを直接操作して、後で実行時にこの構成を更新できます。
詳細は、次を参照してください:
Oracle Complex Event Processing Visualizerユーザーズ・ガイド
『Oracle Complex Event Processing管理者ガイド』のwlevs.Adminコマンドライン・リファレンスに関する項
『Oracle Complex Event Processing管理者ガイド』のOracle CEP用のJMX構成に関する項
キャッシュの構成に関する詳細は、次を参照してください。
次の項では、主要なOracle CEPキャッシュのユース・ケースを説明します。
このユース・ケースは、金融市場が開いている間はイベントをキャッシュにパブリッシュし、マーケット終了後にキャッシュのデータを処理する金融アプリケーションです。
イベントをキャッシュにパブリッシュすると、イベントを高可用性にしたり、サーバー上で稼働する他のOracle CEPアプリケーションで使用可能になったりします。イベントをキャッシュにパブリッシュすると、キャッシュの実装によってセカンダリ・ストレージへの非同期的書込みも可能になります。イベント(入力アダプタ、チャネル、ビジネスPOJO、またはプロセッサ)を生成し、そのイベントをキャッシュにパブリッシュするOracle CEPアプリケーション内の任意のステージを構成できます。
Oracle CEPアプリケーションでは、ときには処理を実行するためストリーミング以外のデータにアクセスする必要があります。このようなデータをキャッシュすることで、アプリケーションのパフォーマンスが向上します。
プログラムによりキャッシュに直接アクセスできるOracle CEPアプリケーションの標準のコンポーネントは、入力および出力アダプタ、およびビジネスPOJOです。
また、アプリケーションは、ユーザー定義関数またはOracle CQL/EPL文から直接のいずれの方法でも、Oracle CQL/EPLからキャッシュにアクセスできます。
ユーザー定義関数の場合、プログラマはSpringを使用してキャッシュ・リソースを関数の実装に組み込みます。詳細は、1.4項「Oracle CEPのリソース・アクセスの構成」を参照してください。
アプリケーションは、プロセッサ内で実行されるOracle CQL/EPL文から直接キャッシュに問い合せることもできます。この場合、データがキャッシュから抽出される場合を除いて、キャッシュへの問合せがチャネルへの問合せに酷似するように、キャッシュは必然的にプロセッサへの別の種類のストリーム・データ・ソースとして機能します。
キャッシュに問い合せるためにOracle CQLを使用する例は、注文や注文をキャッシュに実行するために使用される取引をパブリッシュする金融アプリケーションにみられます。一日の最後のマーケット終了時に、アプリケーションは、特定の注文に関連したすべての取引を検索するためにキャッシュに問い合せます。
Oracle CEPアプリケーションでは、必要に応じてキャッシュのデータを更新および削除できます。
たとえば、金融アプリケーションでは注文を実現する個々の取引が実行されるたびにキャッシュ内の注文を更新し、注文が取り消された場合はこれを削除する必要があります。キャッシュ内のデータの使用が許可されたアプリケーションのコンポーネントには、データの更新も許可されます。
キャッシュを使用するOracle CEPアプリケーションを構築する場合、そのアプリケーションをマルチサーバー・ドメインでデプロイし、分散型キャッシュをサポートするキャッシュ・システムを使用する必要があります。
この場合、Oracle Coherenceまたは分散型キャッシュをサポートするサードパーティのキャッシュ・システムのいずれかを使用する必要があります。
詳細は、次を参照してください:
『Oracle Complex Event Processing管理者ガイド』のOracle CEPネイティブ・クラスタリングを使用したマルチサーバー・ドメインの管理に関する項
上記に示す主なキャッシング機能のほか、Oracle CEPキャッシングには次の機能もあります。
アプリケーションのデプロイ前にキャッシュにデータをあらかじめロードします。
キャッシュのデータを定期的にリフレッシュ、無効化、およびフラッシュします。これらのタスクはすべてインクリメンタルに行われ、アプリケーションの停止や待機時間スパイクは発生しません。
動的にキャッシュの構成を更新します。
Oracle CEPには、アプリケーションで特定のタスクを実行するために使用できる多数の キャッシングAPI が用意されています。APIの2つのパッケージがあります。
com.bea.cache.jcache
: キャッシュへのアクセスおよびキャッシュ・ローダー、キャッシュ・リスナー、キャッシュ・ストアの作成に使用されるAPIを含みます。
com.bea.wlevs.cache.spi
: キャッシュ・システムへのアクセスに使用されるAPIを含みます。
キャッシュ・システムおよびキャッシュの作成、構成、書込みは、すべてEPNアセンブリ・ファイルおよびコンポーネント構成ファイルによって行われます。つまり、通常は、アプリケーションでCache
およびCachingSystem
インタフェースを明示的に使用しないことになります。それらを使用する唯一の理由は、標準の構成に追加する要件がある場合のみです。例: サードパーティのキャッシュ・プロバイダに統合する場合、CachingSystem
インタフェースを使用する必要があります。java.util.Map
インタフェースの一部ではないキャッシュ上の操作を行う場合、Cache
インタフェースを使用できます。
Oracle CEPのローカル・キャッシュ用のキャッシュ・リスナー、キャッシュ・ローダー、またはキャッシュ・ストアを作成する場合、書き込むSpring BeanはCacheListener
、CacheLoader
、またはCacheStore
インタフェースを実装する必要があります。
Oracle Coherenceキャッシュ用のキャッシュ・リスナー、キャッシュ・ローダー、またはキャッシュ・ストアを作成する場合、書き込むSpring Beanは適切なOracle Coherenceインタフェースを実装する必要があります。
サードパーティのキャッシュ用のキャッシュ・リスナー、キャッシュ・ローダー、またはキャッシュ・ストアを作成する場合、書き込むSpring Beanは適切なサードパーティのキャッシュ・インタフェースを実装する必要があります。
詳細は、次を参照してください:
Oracle Fusion Middleware Oracle Complex Event Processing Java APIリファレンス
Oracle CEPローカル・キャッシュ・システムおよびキャッシュを使用するようにアプリケーションを構成できます。Oracle CEPローカル・キャッシュ・システムは、アプリケーションをマルチサーバー・ドメインにデプロイしようと計画しない場合に適切です。アプリケーションをマルチサーバー・ドメインにデプロイしようと計画する場合、Oracle Coherenceのキャッシュを使用することを考慮してください(詳細は、12.3項「Oracle Coherenceキャッシュ・システムおよびキャッシュの構成」を参照)。
注意: この項では、EPNアセンブリ・ファイルを伴うOracle CEPアプリケーションを作成済で、アプリケーションを更新してキャッシュを使用すると仮定します。作成済でない場合、詳細は第1章「Oracle CEPアプリケーションの作成の概要」を参照してください。 |
Oracle CEPローカル・キャッシュ・システムおよびキャッシュを構成するには:
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"/>
EPNアセンブリ・ファイルでキャッシュ・システムに1つ以上のキャッシュを宣言します。
アプリケーションのキャッシュ・システムを宣言した後、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
の子要素は、キャッシュを含む宣言済のキャッシュ・システムを参照します。この子要素は、キャッシュ・システムが曖昧な場合のみ指定する必要があります。1つ以上のキャッシュ・システムが(明示的または黙示的のいずれかで)宣言されているか、またはキャッシュ・システムが異なるアプリケーションやバンドルにある場合です。
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内のコンポーネントはキャッシュを参照できます。次の例では、1つのバンドル内のプロセッサが、個別のバンドル(cacheprovider
と呼ばれます)内に配置されたcache-id
というIDを持つキャッシュをキャッシュ・ソースとして使用できる仕組みを示しています。
<wlevs:processor id="myProcessor2">
<wlevs:cache-source ref="cacheprovider:cache-id"/>
</wlevs:processor>
キャッシュ・システムは、特定の名前に関連付けられたキャッシュの作成およびキャッシュへの参照の戻しに関する処理を行います。結果のキャッシュBeanは、java.util.Map
インタフェースを実装します。
お気に入りのXMLエディタを使用してアプリケーションのコンポーネント構成XMLファイルを開きます。
config
ルート要素を更新し、caching-system
子要素に追加します。name
子要素を使用して一意でそれを識別します。
この名前は、ステップ1においてEPNアセンブリ・ファイルで指定したwlevs:caching-system
要素のid
属性と一致する必要があります。これが、このキャッシュ構成が適用される対象の、EPNアセンブリ・ファイル内の特定のキャッシュ・システムをOracle CEPが認識する仕組みです。
たとえば、構成ファイルにはすでにプロセッサとアダプタが含まれているとします(簡略化のため内容は省略します)。更新されたファイルは、次のようになります。
<?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>
作成する各キャッシュでは、caching-system
要素を更新し、cache
子要素を追加します。name
子要素を使用すると、一意でそれを識別できます。
このname
は、ステップ2においてEPNアセンブリ・ファイルで指定したwlevs:cache
要素のid
属性と一致する必要があります。これが、この構成が適用される対象の、EPNアセンブリ・ファイル内の特定のキャッシュをOracle CEPが認識する仕組みです。
次の例は、キャッシュ・システムにおける2つのキャッシュを示します。
<caching-system> <name>caching-system-id</name> <cache> <name>cache-id</name> ... </cache> <cache> <name>second-cache-id</name> ... </cache> </caching-system>
各キャッシュについて、必要に応じて次の単純データ型の要素を追加して、キャッシュを構成します。
max-size
: 削除/ページングの発生後のメモリー内のキャッシュ要素の数です。最大キャッシュサイズは231-1エントリで、デフォルトは64です。
eviction-policy
: max-size
に達した時に使用する削除ポリシーです。サポートされる値: FIFO、LRU、LFU、およびNRUで、デフォルト値はLFUです。
存続時間
: エントリがキャッシュされる最大時間数で、単位はミリ秒です。デフォルト値は無限です。
idle-time
: キャッシュされたエントリが実際にキャッシュから削除された後の時間数で、単位はミリ秒です。デフォルト値は無限です。
work-manager-name
: ワーク・マネージャは、すべての非同期操作に使用されます。この要素の値は、サーバーのconfig.xml
構成ファイル内のwork-manager
要素のname
子要素に対応します。
詳細は、 F.44項「work-manager」を参照してください。
例:
<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>
オプションで、write-through
またはwrite-behind
のいずれかをcache
の子要素として追加し、それぞれのキャッシュ・ストアへの同期/非同期書込みを指定します。デフォルトでは、ストアへの書込みは同期的(<rite-through
)で、エントリが作成または更新されるとすぐに書込みが発生することになります。
write-behind
要素を指定する場合、キャッシュ・ストアは、キャッシュ・エントリの作成または更新後に個別のスレッドから起動されます。次のオプションの子要素を使用すると、ストアへの非同期書込みを構成することもできます。
work-manager-name
: キャッシュ・ストアへの非同期書込みを処理するワーク・マネージャです。ワーク・マネージャがキャッシュそのものに指定されている場合、この値はストア操作のみのためにオーバーライドします。この要素の値は、サーバーのconfig.xml
構成ファイル内のwork-manager
要素のname
子要素に対応します。
詳細は、 F.44項「work-manager」を参照してください。
batch-size
: バッキング・ストアに書込みを戻すためにストア・バッファからピック・アップされる更新の数です。デフォルト値は1です。
buffer-size
: ストアに書き込まれる必要がある非同期更新を一時的に保存する内部ストア・バッファのサイズです。デフォルト値は100です。
buffer-write-attempts
: ユーザー・スレッドがストア・バッファへの書込みを試行する回数です。ユーザー・スレッドとは、キャッシュ・エントリの作成または更新を行うスレッドです。ユーザー・スレッドによるストア・バッファへの書込み試行がすべて失敗した場合、同期的にストアを起動します。デフォルト値は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>
オプションで、cache
要素のlisteners
子要素を追加し、キャッシュをリスニングするコンポーネントの動作を構成できます。
asynchronous
のブール属性を使用すると、リスナーを起動するかどうかを指定できます。
非同期: true
。
同期: false
で、リスナーは同期的に起動されることになります(デフォルト)。
listeners
要素には、work-manager-name
という単一の子要素があり、これが非同期的なリスナーの起動に使用されるワーク・マネージャを指定します。この値は、同期的起動が有効化されている場合は無視されます。ワーク・マネージャがキャッシュそのものに指定されている場合、この値はリスナーのみを起動するためにオーバーライドします。この要素の値は、Oracle CEPサーバーの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>
詳細は、 F.44項「work-manager」を参照してください。
オプションで、1つ以上の追加cache
要素の子要素を持つEPNアセンブリ・ファイルを更新することによって、デフォルトのキャッシュ構成をオーバーライドします。
イベント・シンクをイベント処理ネットワーク内で別のコンポーネントへのリスナーとして構成することによって、キャッシュがイベント・シンクであると指定します。
詳細は、12.2.1項「イベント・リスナーとしてのOracle CEPローカル・キャッシュの構成」を参照してください。
キャッシュが、イベント処理ネットワーク内の別のコンポーネントがリスニングする対象のイベント・ソースであると指定します。
詳細は、12.2.2項「イベント・ソースとしてのOracle CEPローカル・キャッシュの構成」を参照してください。
キャッシュのキャッシュ・ローダーを構成します。
詳細は、12.2.3項「Oracle CEPローカル・キャッシュ・ローダーの構成」を参照してください。
キャッシュのキャッシュ・ストアを構成します。
詳細は、12.2.4項「Oracle CEPローカル・キャッシュ・ストアの構成」を参照してください。
Oracle CEPローカル・キャッシュへのアクセス。
オプションで、問合せ文内でOracle CEPローカル・キャッシュを参照します。
参照:
オプションで、カスタム・アダプタ、ビジネスPOJO、またはOracle CQL/EPLのユーザー定義関数を構成およびプログラムし、Oracle CEPローカル・キャッシュにアクセスします。
構成はEPNアセンブリ・ファイルで実行され、プログラミングはアダプタ、POJO、またはユーザー定義関数を実装するJavaファイルで実行されます。
参照:
オプションで、JMXを使用してOracle CEPローカル・キャッシュにアクセスします。
詳細は、12.11項「JMXの使用によるキャッシュへのアクセス」を参照してください。
アプリケーションをアセンブルする場合は、図12-1に示すように、META-INF/MANIFEST.MF
ファイルに次のインポートが含まれていることを確認してください。
com.bea.wlevs.cache.spi; version ="11.1.0.0"
MANIFEST.MF
ファイルがこのインポートを含まない場合、MANIFEST.MF
ファイルを更新し、アプリケーションをデプロイする前にこのインポートを追加します。
Oracle CEPローカル・キャッシュは、イベントを受信するためのイベント処理ネットワーク内の明示的なリスナーとして構成可能です。
たとえば、キャッシュがチャネルをリスニングすることを指定するには、次に示すようにwlevs:channel
要素の子要素としてキャッシュへの参照を持つ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:channel id="tradeStream">
<wlevs:listener ref="cache-id"/>
</wlevs:channel>
チャネルが新しいイベントをキャッシュに送信するとき、新しいイベントはキャッシュに挿入されます。remove event(出力ウィンドウに存在する古いイベント)がチャネルによって送信される場合、そのイベントはキャッシュから削除されます。
Oracle CEPローカル・キャッシュがリスナーとなるように構成するとき、イベントはキャッシュに挿入されます。この項では、このインスタンスでキャッシュの作成に使用されるキーを指定するために利用可能な各種オプションを説明します。
明示的にキーを指定しない場合、イベントがキャッシュに挿入されるときにイベント・オブジェクト自体はキーおよび値の両方として提供されます。この場合、イベント・クラスには、キー・プロパティ値を考慮するequals
およびhashcode
メソッドの有効な実装が含まれる必要があります。
キーの明示的な指定方法については、次を参照してください。
第1オプションは、次の例で示されるように、key-properties
属性を使用してEPNアセンブリ・ファイル内でキャッシュが宣言されるときにキー・プロパティのプロパティ名を指定することです。
<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オプションは、イベント型を実装するJavaクラスにおけるイベント・プロパティに注釈を付けるためのメタデータ注釈com.bea.wlevs.ede.api.Key
を使用することです。この注釈には属性がありません。
メタデータ注釈を使用してキーを指定するには、次のステップを実行します。
com.bea.wlevs.ede.api.Key
パッケージをインポートします。
詳細は、4.7.5項「パッケージのインポート方法」を参照してください。
@Key
注釈をメソッドに適用します。
次の例は、MyEvent
イベント型のkey
プロパティがキーであることを指定する方法を示します。関連コードのみを次に示します。
import com.bea.wlevs.ede.api.Key; public class MyEvent { private String key; public MyEvent() { } public MyEvent(String key) { this.key = key; } public String getKey() { return key; } @Key public void setKey(String key) { this.key = key; } ... }
Oracle CEPローカル・キャッシュは、イベント処理ネットワーク内の別のコンポーネントがリスニングする対象のイベント・ソースとして構成可能です。リスニングするコンポーネントは、アダプタまたは標準の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
クラスは自分でプログラムする必要があります。
Oracle CEPローカル・キャッシュ・ローダーは、オブジェクトをOracle CEPローカル・キャッシュにロードするオブジェクトです。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
メソッドも含まれます。
カスタム・ストアを持つOracle CEPローカル・キャッシュを構成することができます。これは、データベースの表などのバッキング・ストアにキャッシュからのデータを書き込む処理を行います。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
メソッドも含みます。
Oracle Coherenceキャッシュ・システムおよびキャッシュを使用するようにアプリケーションを構成できます。アプリケーションをマルチサーバー・ドメインにデプロイしようとする場合は、このキャッシュ・システムを使用します。
Oracle Coherenceを使用すると、第1キャッシュ・システムのみがサーバー内に構成されます。Oracle CEPは、構成する可能性がある他のキャッシュ・システムは無視します。
注意: Oracle Coherenceと共にOracle CEPを正式に使用する前に、Coherence Enterprise Edition、Coherence Grid Edition、またはOracle WebLogic Application Grid用ライセンスなどの有効なCoherenceライセンスを取得する必要があります。Oracle Coherenceに関する詳細は、http://www.oracle.com/technology/products/coherence/index.html を参照してください。 |
注意: この項では、EPNアセンブリ・ファイルを伴うOracle CEPアプリケーションを作成済で、アプリケーションを更新してキャッシュを使用すると仮定します。作成済でない場合、詳細は第1章「Oracle CEPアプリケーションの作成の概要」を参照してください。 |
Oracle Coherenceキャッシュ・システムおよびキャッシュを構成するには:
Oracle Coherenceキャッシュをこのアプリケーションだけが使用するか、2つ以上のアプリケーションで共有するかを決定します。
詳細は、12.3.5項「共有Oracle Coherenceキャッシュの構成」を参照してください。
EPNアセンブリ・ファイル内でOracle Coherenceキャッシュ・システムを宣言します。
Oracle Coherenceの実装をEPNアセンブリ・ファイルで宣言して使用するキャッシュ・システムを宣言するには、次の例に示すように、wlevs:caching-system
要素を使用します。
<wlevs:caching-system id="caching-system-id" provider="coherence" advertise="false"/>
id
属性値は、アプリケーションのコンポーネント構成ファイル内でキャッシュ・システムに指定する名前と一致する必要があります(ステップ4を参照)。
EPNアセンブリ・ファイルでキャッシュ・システムに1つ以上のキャッシュを宣言します。
アプリケーションのキャッシュ・システムを宣言した後、wlevs:cache
要素を使用して1つ以上のキャッシュを構成します。
<wlevs:caching-system id="caching-system-id" provider="coherence" advertise="false"/> ... <wlevs:cache id="myCache" advertise="false"> <wlevs:caching-system ref="caching-system-id"/> </wlevs:cache>
wlevs:cache
要素のid
属性は必須です。この属性は、Oracle Coherence構成ファイル内のキャッシュ名にマップします(ステップ4を参照)。
name
属性はオプションです。キャッシュ・システムでキャッシュ名がそのIDと異なる場合のみ指定します。wlevs:caching-system
の子要素は、キャッシュを含む宣言済のキャッシュ・システムを参照します。この子要素は、キャッシュ・システムが曖昧な場合のみ指定する必要があります。1つ以上のキャッシュ・システムが(明示的または黙示的のいずれかで)宣言されているか、またはキャッシュ・システムが異なるアプリケーションやバンドルにある場合です。
キャッシング・システムでは、特定の名前に関連付けられたキャッシュが作成され、そのキャッシュへの参照が返されます。生成されたキャッシュBeanはjava.util.Map
インタフェースを実装します。
詳細は、12.3.5項「共有Oracle Coherenceキャッシュの構成」を参照してください。
アプリケーションのキャッシュ構成ファイルを更新することによって、キャッシュ・システムおよびそのキャッシュを構成します。
詳細は、12.3.1項「Oracle Coherenceキャッシュ・システムおよびキャッシュの構成」を参照してください。
オプションで、1つ以上の追加cache
要素の子要素を持つEPNアセンブリ・ファイルを更新することによって、デフォルトのキャッシュ構成をオーバーライドします。
イベント・シンクをイベント処理ネットワーク内で別のコンポーネントへのリスナーとして構成することによって、キャッシュがイベント・シンクであると指定します。
詳細は、12.3.1項「Oracle Coherenceキャッシュ・システムおよびキャッシュの構成」を参照してください。
キャッシュが、イベント処理ネットワーク内の別のコンポーネントがリスニングする対象のイベント・ソースであると指定します。
詳細は、12.3.2項「イベント・リスナーとしてのOracle Coherenceキャッシュの構成」を参照してください。
EPNアセンブリ・ファイル内の<wlevs:cache>
要素の<wlevs:cache-loader>
または<wlevs:cache-store>
子要素のいずれかを構成します。ただし、両方は構成できません。
これは、Oracle Coherenceがローダーとストアを組み合せて単一のコンポーネントにするからです。バッキング・ストアが読取り専用の場合にキャッシュ・ローダーを指定し、バッキング・ストアが読取り/書込みの場合にキャッシュ・ストアを指定します。
詳細は、12.3.4項「Oracle Coherenceキャッシュ・ローダーまたはストアの構成」を参照してください。
Oracle Coherenceキャッシュへのアクセス:
オプションで、問合せ文内でOracle Coherenceキャッシュを参照します。
参照:
オプションで、カスタム・アダプタ、ビジネスPOJO、またはOracle CQL/EPLのユーザー定義関数を構成およびプログラムし、Oracle Coherenceキャッシュにアクセスします。
構成はEPNアセンブリ・ファイルで実行され、プログラミングはアダプタ、POJO、またはユーザー定義関数を実装するJavaファイルで実行されます。
参照:
オプションで、JMXを使用してOracle Coherenceキャッシュにアクセスします。
詳細は、12.11項「JMXの使用によるキャッシュへのアクセス」を参照してください。
パッケージcom.bea.wlevs.cache.spi
をインポートするようにMANIFEST.MF
を編集します。
詳細は、4.7.5項「パッケージのインポート方法」を参照してください。
アプリケーションをアセンブルし、デプロイします。
詳細は、第24章「Oracle CEPアプリケーションのアセンブルとデプロイ」を参照してください。
Oracle CEPは、Oracle Coherenceによって提供されるネイティブ構成を活用します。Oracle Coherenceキャッシュを使用するアプリケーション・バンドル内で、指定の名前を持つ次の2つのOracle Coherenceファイルをパッケージ化することによって、これを行います。
coherence-cache-config.xml
: Oracle Coherenceキャッシュの構成情報です。各キャッシュはcache-name
要素で識別され、この要素の値は、EPNアセンブリ・ファイル内のwlevs:cache
要素のid
属性にマップします。このファイルとマッピング例の詳細は、12.3.1.1項「coherence-cache-config.xmlファイル」を参照してください。
tangosol-coherence-override.xml
: Oracle Coherenceクラスタ構成です。このファイルおよび例の詳細は、12.3.1.2項「tangosol-coherence-override.xmlファイル」を参照してください。
アプリケーションをアセンブルするとき、次を考慮します。
coherence-cache-config.xml
は、アプリケーションごとの構成ファイルで、このファイルをバンドルJARのMETA-INF/wlevs/coherence
ディレクトリに配置してください。このディレクトリは、メモリー内のローカルOracle CEPキャッシュ・プロバイダのコンポーネント構成ファイルを保存するディレクトリ(META-INF/wlevs
)とは異なることに注意してください。
tangosol-coherence-override.xml
は、サーバーごとのグローバル・ファイル(Oracle Coherenceドキュメント内では「操作構成」と呼ばれます)で、このファイルはOracle CEPサーバーのconfig
ディレクトリに配置します。
例12-5で示すように、アプリケーション構成ファイルを更新します。
例12-5 アプリケーション構成ファイル: Coherenceキャッシュ
<coherence-caching-system> <name>caching-system-id</name> <coherence-cache-config> ../wlevs/coherence/coherence-cache-config.xml </coherence-cache-config> </coherence-caching-system>
キャッシュ・システムがOracle Coherenceプロバイダを使用することを宣言するとき、このキャッシュ・システムのすべてのキャッシュは、Oracle CEPローカル構成ではなく、必ずOracle Coherence構成にマップします。そうしない場合、Oracle CEPが例外をスローします。
coherence-cache-config.xml
ファイルは基本的なOracle Coherence構成ファイルで、任意のOracle Coherenceアプリケーションでtrueとなるように、Oracle 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> <local-scheme> <scheme-ref>my-local-scheme</scheme-ref> </local-scheme> </backing-map-scheme> </replicated-scheme> <local-scheme> <scheme-name>my-local-scheme</scheme-name> <eviction-policy>LRU</eviction-policy> <high-units>100</high-units> <low-units>50</low-units> </local-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>
Oracle Coherence構成ファイルでは、cache-mapping
の子要素であるcache-name
要素が、Oracle Coherenceキャッシュ名を識別します。この要素の値は、EPNアセンブリ・ファイル内のwlevs:cache
要素のid
属性値と完全に一致する必要があります。たとえば、次のEPNアセンブリ・ファイルのスニペットは、Oracle 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>
Oracle Coherence構成ファイルは、Oracle CEPと共にOracle Coherenceを使用する場合、別の要件例示します。Oracle Coherenceファクトリは、キャッシュのローダーまたはストアを構成するためにSpringを使用するときに宣言される必要があります。これは、ファクトリ・クラスを指定するためにOracle Coherence構成ファイル内でcachestore-scheme
要素を使用することによって行います。このファクトリ・クラスによって、Oracle CoherenceはOracle CEPにコールして、キャッシュに構成されるローダーまたはストアへの参照を取得できるようになります。ローダーまたはストアの構成における唯一の差異は、method-name
要素が、ローダーが使用されるときはgetLoader
の値を持ち、ストアが使用されているときはgetStore
の値を持つことです。キャッシュ名を入力パラメータとしてファクトリに渡します。
coherence-cache-config.xml
ファイルの詳細は、Oracle Coherenceドキュメント(http://www.oracle.com/technology/products/coherence/index.html
)を参照してください。
tangosol-coherence-override.xml
ファイルは、Oracle Coherenceのキャッシュ処理を構成します。Oracle Coherenceをキャッシュ処理のみに使用している場合、このファイルを含めることができます。Oracle 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>
...
</coherence>
構成ファイルはかなり標準的です。主な注意点は、cluster-name
要素を指定し、Oracle CEPの起動時にOracle Coherenceが既存のOracle Coherenceクラスタに結合しないようにすることです。これが起こると問題が発生したり、Oracle CEPが起動しなくなることもあります。
tangosol-coherence-override.xml
ファイルの詳細は、Oracle Coherenceドキュメント(http://www.oracle.com/technology/products/coherence/index.html
)を参照してください。
Oracle CEPクラスタの詳細は、『Oracle Complex Event Processing管理者ガイド』の「Oracle CEPネイティブ・クラスタリングによるマルチサーバー・ドメインの管理」を参照してください。
Oracle Coherenceキャッシュは、イベントを受信するためのイベント処理ネットワーク内の明示的なリスナーとして構成可能です。
たとえば、キャッシュがチャネルをリスニングすることを指定するには、次に示すようにwlevs:channel
要素の子要素としてキャッシュへの参照を持つwlevs:listener
要素を指定します。
<wlevs:coherence-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:channel id="tradeStream">
<wlevs:listener ref="cache-id"/>
</wlevs:channel>
チャネルが新しいイベントをキャッシュに送信するとき、新しいイベントはキャッシュに挿入されます。remove event(出力ウィンドウに存在する古いイベント)がチャネルによって送信される場合、そのイベントはキャッシュから削除されます。
Oracle Coherenceキャッシュがリスナーとなるように構成するとき、イベントはキャッシュに挿入されます。この項では、このインスタンスでキャッシュの作成に使用されるキーを指定するために利用可能な各種オプションを説明します。
明示的にキーを指定しない場合、イベントがキャッシュに挿入されるときにイベント・オブジェクト自体はキーおよび値の両方として提供されます。この場合、イベント・クラスには、キー・プロパティ値を考慮するequals
およびhashcode
メソッドの有効な実装が含まれる必要があります。
キーの明示的な指定方法については、次を参照してください。
第1オプションは、次の例で示されるように、key-properties
属性を使用してEPNアセンブリ・ファイル内でキャッシュが宣言されるときにキー・プロパティのプロパティ名を指定することです。
<wlevs:cache id="myCache" 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="myCache" key-properties="key">
<wlevs:caching-system ref="caching-system-id"/>
</wlevs:cache>
第2オプションは、イベント型を実装するJavaクラスにおけるイベント・プロパティに注釈を付けるためのメタデータ注釈com.bea.wlevs.ede.api.Key
を使用することです。この注釈には属性がありません。
メタデータ注釈を使用してキーを指定するには、次のステップを実行します。
com.bea.wlevs.ede.api.Key
パッケージをインポートします。
詳細は、4.7.5項「パッケージのインポート方法」を参照してください。
@Key
注釈をメソッドに適用します。
次の例は、MyEvent
イベント型のkey
プロパティがキーであることを指定する方法を示します。関連コードのみを次に示します。
import com.bea.wlevs.ede.api.Key; public class MyEvent { private String key; public MyEvent() { } public MyEvent(String key) { this.key = key; } public String getKey() { return key; } @Key public void setKey(String key) { this.key = key; } ... }
最後のオプションは、複数のプロパティがキーを形成する複合キーを指定するためのwlevs:cache
要素のkey-class
属性を使用することです。key-class
属性値は、パブリック・フィールドがイベント・クラスのフィールドに一致するJavaBeanとなる必要があります。照合はフィールド名に従って実行されます。例:
<wlevs:cache id="myCache" key-class="key-class-name"> <wlevs:caching-system ref="caching-system-id"/> </wlevs:cache>
Oracle Coherenceキャッシュは、イベント処理ネットワーク内の別のコンポーネントがリスニングする対象のイベント・ソースとして構成可能です。リスニングするコンポーネントは、アダプタまたは標準のSpring Beanです。キャッシュをリスニングする任意のコンポーネントは、com.tangosol.util.MapListener
インタフェースを実装する必要があります。次の例では、Oracle CoherenceキャッシュをSpring Beanのイベント・ソースとなるように構成する方法を示します。
<wlevs:coherence-caching-system id="caching-system-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="localListener" class="com.bea.wlevs.example.provider.coherence.LocalListener"/>
この例では、cache-listener-id
のSpring Beanはキャッシュからのイベントをリスニングし、このコンポーネントを実装するクラス、com.bea.wlevs.example.provider.coherence.LocalListener
は、com.tangosol.util.MapListener
などの適切なOracle Coherence専用のJavaインタフェースを実装する必要があります。例12-6で示すように、このLocalListener
クラスは自分でブログラムする必要があります。
例12-6 Oracle CoherenceキャッシュのLocalListenerの実装
package com.bea.wlevs.example.provider.coherence; import com.tangosol.util.MapEvent; import com.tangosol.util.MapListener; public class LocalListener implements MapListener { public static int deleted = 0; public static int inserted = 0; public static int updated = 0; public void entryDeleted(MapEvent event) { deleted++; } public void entryInserted(MapEvent event) { inserted++; } public void entryUpdated(MapEvent event) { updated++; } }
Oracle Coherenceキャッシュを使用すると、EPNアセンブリ・ファイル内でwlevs:cache
要素のwlevs:cache-loader
またはwlevs:cache-store
子要素のいずれかを構成できます。ただし、両方を構成することはできません。これは、Oracle Coherenceがローダーとストアを組み合わせて単一のコンポーネントにするからです。
バッキング・ストアが読取り専用の場合にキャッシュ・ローダーを指定します。
詳細は、12.3.4.1項「Oracle Coherenceキャッシュ・ローダーの構成」を参照してください。
バッキング・ストアが読取り/書込みの場合にキャッシュ・ストアを指定します。
詳細は、12.3.4.2項「Oracle Coherenceキャッシュ・ストアの構成」を参照してください。
例12-7では、localLoader
のSpring Beanは、バッキング・ストアが読取り専用のときにイベントをOracle Coherenceキャッシュにロードします。バッキング・ストアが読取り/書込みの場合は、キャッシュ・ストアを使用します(詳細は、12.3.4.2項「Oracle Coherenceキャッシュ・ストアの構成」を参照)。
このコンポーネントを実装するクラス、com.bea.wlevs.example.provider.coherence.LocalLoader
は、com.tangosol.net.cache.CacheLoader
などの適切なOracle Coherence専用Javaインタフェースを実装する必要があります。例12-8で示すように、このLocalLoader
クラスは自分でブログラムする必要があります。
例12-7 キャッシュ・ローダー用Oracle CoherenceキャッシュのEPNアセンブリ・ファイル
<wlevs:coherence-caching-system id="caching-system-id"/> <wlevs:cache id="myCache" advertise="false"> <wlevs:caching-system ref="caching-system-id"/> <wlevs:cache-loader ref="localLoader"/> </wlevs:cache> <bean id="localLoader" class="com.bea.wlevs.example.provider.coherence.LocalLoader"/>
例12-8 Oracle CoherenceキャッシュのLocalLoaderの実装
package com.bea.wlevs.example.provider.coherence; import java.util.Collection; import java.util.HashMap; import java.util.HashSet; import java.util.Map; import java.util.Set; import com.bea.wlevs.example.provider.event.ProviderData; import com.tangosol.net.cache.CacheLoader; public class LocalLoader implements CacheLoader { public static int loadCount = 0; public static Set keys = new HashSet(); public LocalLoader() { } public Object load(Object key) { loadCount++; keys.add(key); return new ProviderData((String) key); } public Map loadAll(Collection keys) { Map result = new HashMap(); for (Object key : keys) { result.put(key, load(key)); } return result; } }
例12-9では、localStore
のSpring Beanは、バッキング・ストアが読取り/書込みのときにイベントをキャッシュにロードします。バッキング・ストアが読取り専用の場合は、キャッシュ・ローダーを使用します(詳細は、12.3.4.1項「Oracle Coherenceキャッシュ・ローダーの構成」を参照)。
このコンポーネントを実装するクラス、com.bea.wlevs.example.provider.coherence.LocalStore
は、com.tangosol.net.cache.CacheStore
などの適切なOracle Coherence専用Javaインタフェースを実装する必要があります。例12-10で示すように、このLocalStore
クラスは自分でブログラムする必要があります。
例12-9 キャッシュ・ストア用Oracle CoherenceキャッシュのEPNアセンブリ・ファイル
<wlevs:coherence-caching-system id="caching-system-id"/> <wlevs:cache id="myCache" advertise="false"> <wlevs:caching-system ref="caching-system-id"/> <wlevs:cache-store ref="localStore"/> </wlevs:cache> <bean id="localStore" class="com.bea.wlevs.example.provider.coherence.LocalStore"/>
例12-10 Oracle CoherenceキャッシュのLocalStoreの実装
package com.bea.wlevs.example.provider.coherence; import java.util.Collection; import java.util.HashMap; import java.util.Map; import java.util.Set; import com.bea.wlevs.example.provider.event.ProviderData; import com.tangosol.net.cache.CacheStore; public class LocalStore implements CacheStore { public static int eraseCount = 0; public static int storeCount = 0; public static int loadCount = 0; public void erase(Object key) { eraseCount++; } public void eraseAll(Collection keys) { for (Object key : keys) { erase(key); } } public void store(Object key, Object value) { // // Do the store operation here. // } public void storeAll(Map entries) { for (Map.Entry entry : (Set <Map.Entry>)entries.entrySet()) { store(entry.getKey(), entry.getValue()); } } public Object load(Object key) { loadCount++; return new ProviderData((String) key); } public Map loadAll(Collection keys) { Map result = new HashMap(); for (Object key : keys) { result.put(key, load(key)); } return result; } }
同一のOracle CEPサーバーにデプロイされた1つ以上のアプリケーションのEPNアセンブリ・ファイル内で、Oracle Coherenceキャッシュを宣言するとき、ローダーまたはストアを使用して同一キャッシュの複数のインスタンスを絶対に構成しないでください。各EPNアセンブリ・ファイル内でローダーまたはストアを使用して同一のOracle Coherenceキャッシュをそれぞれ構成する、複数のアプリケーションを使用することによって、これを不注意で行う可能性があります。複数のインスタンスを構成した場合、Oracle CEPは例外をスローします。
複数のアプリケーション・バンドルがOracle Coherenceキャッシュを共有する必要がある場合、個別のバンドル内で適切なwlevs:cache
およびwlevs:caching-system
を含むEPNアセンブリ・ファイルを配置し、それらのadvertise
属性をtrue
に設定する必要があります。
キャッシュ・システムおよびキャッシュをOSGiサービスとしてエクスポートするには、advertise
属性をtrue
に設定します。
<wlevs:caching-system id="caching-system-id" provider="coherence" advertise="true"/> ... <wlevs:cache id="cache-id" name="alternative-cache-name" advertise="true" > <wlevs:caching-system ref="caching-system-id"/> </wlevs:cache>
キャッシュが通知される場合、個別のバンドル内のアプリケーションのEPN内のコンポーネントはキャッシュを参照できます。次の例では、1つのバンドル内のプロセッサが、cacheprovider
と呼ばれる個別のバンドル内に配置されたcache-id
というIDを持つキャッシュをキャッシュ・ソースとして使用できる仕組みを示しています。
<wlevs:processor id="myProcessor2">
<wlevs:cache-source ref="cacheprovider:cache-id"/>
</wlevs:processor>
サードパーティのキャッシュ・システムおよびキャッシュを使用するようにアプリケーションを構成できます。
注意: この項では、EPNアセンブリ・ファイルを伴うOracle CEPアプリケーションを作成済で、アプリケーションを更新してキャッシュを使用すると仮定します。作成済でない場合、詳細は第1章「Oracle CEPアプリケーションの作成の概要」を参照してください。 |
サードパーティのキャッシュ・システムおよびキャッシュを構成するには:
サードパーティのキャッシュ・システムをOracle CEPキャッシュ・システム・プロバイダとして定義するためのプラグインを作成します。
構成:
com.bea.wlevs.cache.spi.CachingSystem
インタフェースの実装
この種類のキャッシュ・システムを作成するファクトリの作成。
プロバイダ・タイプを識別する属性を持つファクトリの登録。
EPNアセンブリ・ファイルでキャッシング・システムを宣言します。
wlevs:caching-system
要素を使用すると、サードパーティの実装を宣言できます。class
またはprovider
属性を使用すると、追加情報を指定できます。
簡略化するために、Oracle CEPアプリケーション・バンドル自体の内部にサードパーティの実装を組み込み、パッケージのインポート/エクスポート、サードパーティの実装を含む個別のバンドルのライフサイクル管理を避けることができます。この場合、wlevs:caching-system
要素は、次の例で示すようにEPNアセンブリ・ファイル内で表示されます。
<wlevs:caching-system id="caching-system-id" class="third-party-implementation-class"/>
class
属性は、com.bea.wlevs.cache.spi.CachingSystem
インタフェースを実装する必要があるJavaクラスを指定します。このインタフェースの詳細は、Oracle Fusion Middleware Oracle Complex Event Processing Java APIリファレンスに関する項を参照してください。
ただし、サードパーティのキャッシュ処理実装を、それを使用しているOracle CEPアプリケーションとして同一のバンドル内に組み込むことができないか、または組み込みたくない場合があります。この場合、Springアプリケーション・コンテキストが必ずadvertise
属性を持つwlevs:caching-system
要素を含む、個別のバンドルを作成する必要があります。
<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
インタフェースを実装する必要があります。このインタフェースはcreate
という単一のメソッドを持ち、このメソッドはcom.bea.wlevs.cache.spi.CachingSystem
インスタンスを戻します。
アプリケーション・バンドルが実装の使用を開始できるよう、アプリケーション・バンドルと共にこのバンドルをデプロイする必要があります。
EPNアセンブリ・ファイルでキャッシュ・システムに1つ以上のキャッシュを宣言します。
アプリケーションのキャッシュ・システムを宣言した後、wlevs:cache
要素を使用して1つ以上のキャッシュを構成します。
<wlevs:caching-system id ="caching-system-id" provider="caching-provider"/> ... <wlevs:cache id="cache-id" name="alternative-cache-name"> <wlevs:caching-system ref="caching-system-id"/> </wlevs:cache>
name
属性はオプションです。キャッシュ・システムでキャッシュ名がそのIDと異なる場合のみ指定します。wlevs:caching-system
の子要素は、キャッシュを含む宣言済のキャッシュ・システムを参照します。この子要素は、キャッシュ・システムが曖昧な場合のみ指定する必要があります。1つ以上のキャッシュ・システムが(明示的または黙示的のいずれかで)宣言されているか、またはキャッシュ・システムが異なるアプリケーションやバンドルにある場合です。
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内のコンポーネントはキャッシュを参照できます。次の例では、1つのバンドル内のプロセッサが、個別のバンドル(cacheprovider
と呼ばれます)内に配置されたcache-id
というIDを持つキャッシュをキャッシュ・ソースとして使用できる仕組みを示しています。
<wlevs:processor id="myProcessor2">
<wlevs:cache-source ref="cacheprovider:cache-id"/>
</wlevs:processor>
キャッシング・システムでは、特定の名前に関連付けられたキャッシュが作成され、そのキャッシュへの参照が返されます。生成されたキャッシュBeanはjava.util.Map
インタフェースを実装します。
サードパーティのキャッシュ構成ファイルまたはアプリケーションのファイルを更新することによって、サードパーティのキャッシュ・システムおよびそのキャッシュを構成します。
サードパーティのキャッシュのドキュメントを参照してください。
オプションで、1つ以上の追加cache
要素の子要素を持つ適切な構成ファイルを更新することによって、デフォルトのサードパーティのキャッシュ構成をオーバーライドします。
イベント・シンクをイベント処理ネットワーク内で別のコンポーネントへのリスナーとして構成することによって、キャッシュがイベント・シンクであると指定します。
サードパーティのキャッシュのドキュメントを参照してください。
キャッシュが、イベント処理ネットワーク内の別のコンポーネントがリスニングする対象のイベント・ソースであると指定します。
サードパーティのキャッシュのドキュメントを参照してください。
キャッシュ・ローダーまたはストアを構成します。
サードパーティのキャッシュのドキュメントを参照してください。
サードパーティのキャッシュへのアクセス:
オプションで、問合せ文内でサードパーティのキャッシュを参照します。
参照:
オプションで、カスタム・アダプタ、ビジネスPOJO、またはOracle CQL/EPLのユーザー定義関数を構成およびプログラムし、サードパーティのキャッシュにアクセスします。
構成はEPNアセンブリ・ファイルで実行され、プログラミングはアダプタ、POJO、またはユーザー定義関数を実装するJavaファイルで実行されます。
参照:
オプションで、JMXを使用してサードパーティのキャッシュにアクセスします。
詳細は、12.11項「JMXの使用によるキャッシュへのアクセス」を参照してください。
アプリケーションをアセンブルする場合は、図12-1に示すように、META-INF/MANIFEST.MF
ファイルに次のインポートが含まれていることを確認してください。
com.bea.wlevs.cache.spi; version ="11.1.0.0"
MANIFEST.MF
ファイルがこのインポートを含まない場合、MANIFEST.MF
ファイルを更新し、アプリケーションをデプロイする前にこのインポートを追加します。
チャネルを参照するのとまったく同じ方法でOracle CQL文からキャッシュを参照できます。この機能によって、標準ストリーミング・データを個別ソースからのデータを使用して質を高めることができます。例12-11は、S1
という標準チャネルからの取引イベントとstockCache
というキャッシュからのストック・シンボル・データを結合する、有効なOracle CQL問合せを示します。
例12-11 キャッシュに対して有効なOracle CQL問合せ
SELECT S1.symbol, S1.lastPrice, stockCache.description FROM S1 [Now], stockCache WHERE S1.symbol = stockCache.symbol
Oracle CQL問合せにおいてキャッシュを使用するとき、次の制約を遵守する必要があります。
キャッシュに問い合せる場合は、常に[Now]
ウィンドウに対して結合する必要があります。
これによって、問合せはキャッシュのスナップショットに対して実行されることが保証されます。他のウィンドウ・タイプに対して結合する場合、ウィンドウの有効期限が切れる前にキャッシュが変更されると、問合せは正しくなりません。
次の例は、キャッシュに対してRange
ウィンドウを結合する無効なOracle CQL問合せを示します。このウィンドウの有効期限が切れる前にキャッシュが変更される場合、問合せは正しくなりません。その結果、この問合せはOracle CEPサーバー・エラー「外部リレーションはs[now]と結合している必要があります
」を表示します。
SELECT trade.symbol, trade.price, trade.numberOfShares, company.name FROM TradeStream [Range 8 hours] as trade, CompanyCache as company WHERE trade.symbol = company.id
Oracle CQL問合せでキャッシュからのデータを使用する場合、チャネルの場合と同様に、データが押し出されるのではなく、Oracle CEPがデータを抽出します。つまり、例12-11のケースを継続し、問合せはチャネルがtrade
イベントを問合せに押し出すときのみ実行されます。キャッシュ内のストック・シンボル・データは問合せを実行せず、必要に応じて問合せによって抽出されるのみです。
キャッシュ・キーに基づいて参照を行うには、必要なすべてのキー・プロパティを指定する必要があります。
スキーマ(id
、group
、value
)を持つ(キャッシュ・キーはid
、group
)、2つのストリームS
およびC
を検討してください。
次の問合せは、WHERE
句でid
とgroup
の両方のキー・プロパティを指定しているが、問合せでキー・プロパティの1つ(id
)に値を設定していないため無効です。
select count(*) as n from S [now], C where S.group = C.group and S.id is not null
有効な問合せは次のとおりです。
select count(*) as n from S [now], C where S.group = C.group and S.id = C.id
キャッシュ・キーの指定に関する命令は、次を参照してください。
結合はキャッシュのキーを参照することでのみ実行される必要があります。
ビューでキャッシュは使用できません。かわりに、結合を使用します。
キャッシュ・データ・ソースを結合するOracle CQL文のFROM
句では、1つのチャネル・ソースのみが発生できます。
キャッシュがプロセッサ・ソースである場合は、図12-3に示すように、キャッシュをEPNのプロセッサに直接接続します。
キャッシュがプロセッサ・シンクである場合は、図12-4に示すように、チャネルを使用してプロセッサをキャッシュに接続します。
この項では、Oracle CQL問合せ文でキャッシュを参照する方法を説明します。
この手順では、キャッシュ・システムおよびキャッシュを構成済と仮定します。詳細は次を参照してください。
Oracle CQL文からキャッシュへのアクセス:
まだ構成済でない場合、キャッシュ・データに対応するイベント型を作成し、イベント・リポジトリに登録します。
第2章「Oracle CEPイベント・タイプの作成」を参照してください。
キャッシュ内のデータからキー・プロパティを指定します。
キャッシュ・キーの指定に関する命令は、次を参照してください。
EPNアセンブリ・ファイルで、キャッシュの構成を更新してその値のイベント型を宣言します。wlevs:cache
要素のvalue-type
属性を使用します。例:
<wlevs:caching-system id="caching-system-id"/>
...
<wlevs:cache id="cache-id"
name="alternative-cache-name"
value-type="CompanyEvent">
<wlevs:caching-system ref="caching-system-id"/>
</wlevs:cache>
value-type属性は、キャッシュに含まれる値のタイプを指定します。これは、イベント型リポジトリで有効なタイプ名にする必要があります。
この属性は、Oracle CQL問合せでキャッシュが参照される場合に必要です。これは、問合せプロセッサがキャッシュ内のイベント型を認識する必要があるからです。
EPNアセンブル・ファイルで、キャッシュを参照するOracle CQL問合せを実行するプロセッサの構成を更新します。
キャッシュがプロセッサ・ソースである場合は、図12-3に示すように、キャッシュをEPNのプロセッサに直接接続します。
キャッシュを参照するwlevs:processor
要素のwlevs:cache-source
子要素を更新します。例:
<wlevs:channel id="S1"/>
<wlevs:processor id="cacheProcessor">
<wlevs:source ref="S1">
<wlevs:cache-source ref="cache-id">
</wlevs:processor>
この例では、プロセッサは従来とおりにS1
チャネルから押し出されるデータを持ちます。ただし、プロセッサで実行するOracle CQL問合せは、cache-id
キャッシュからデータを抽出することもできます。問合せプロセッサが、FROM
句のイベント・タイプをCompanyEvent
などのキャッシュによって提供されるイベント・タイプに一致するとき、プロセッサはキャッシュからそのイベント・タイプのインスタンスを抽出します。
キャッシュがプロセッサ・シンクである場合は、図12-4に示すように、EPNのチャネルを使用してプロセッサをキャッシュに接続します(つまり、プロセッサとキャッシュ・シンクの間にチャネルが必要です)。
この場合、アプリケーション・アセンブリ・ファイルは次のようになります。
<wlevs:channel id="channel1" event-type="StockTick">
<wlevs:listener ref="processor" />
</wlevs:channel>
<wlevs:processor id="processor">
<wlevs:listener ref="channel2" />
</wlevs:processor>
<wlevs:channel id="channel2" event-type="StockTick">
<wlevs:listener ref="cache-id" />
</wlevs:channel>
チャネルを参照するのとまったく同じ方法で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問合せでキャッシュを使用する場合は、以下の制限に従う必要があります。
キャッシュ内のデータのキー・プロパティを指定する必要があります。
キャッシュ・キーの指定に関する命令は、次を参照してください。
結合はキャッシュのキーを参照することでのみ実行される必要があります。
RETAIN
句をキャッシュから抽出したデータに指定することはできません。キャッシュからデータを取得するイベント型がRETAIN
句に含まれる場合、Oracle CEPはそれを無視します。
相関サブ問合せではキャッシュを使用できません。かわりに、結合を使用します。
キャッシュ・データ・ソースを結合するEPL文のFROM
句では、1つのチャネル・ソースのみが発生できます。1つ以上のキャッシュ・ソースおよびパラメータ化したSQL問合せの使用がサポートされています。
この項では、EPL問合せ文でキャッシュを参照する方法を説明します。
この手順では、キャッシュ・システムおよびキャッシュを構成済と仮定します。詳細は次を参照してください。
EPL文からキャッシュへのアクセス:
まだ構成済でない場合、前述の例におけるCompany
などのキャッシュ・データに対応するイベント・タイプを作成し、イベント・リポジトリに登録します。詳細は、第2章「Oracle CEPイベント・タイプの作成」を参照してください。
キャッシュにあるデータ用のキー・プロパティを指定します。これを行う方法は各種あります。次を参照してください。
EPNアセンブリ・ファイルで、EPNアセンブリ・ファイル内のキャッシュの構成を更新してその値のイベント型を宣言します。wlevs:cache
要素のvalue-type
属性を使用します。例:
<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>
value-type属性は、キャッシュに含まれる値のタイプを指定します。これは、イベント型リポジトリで有効なタイプ名にする必要があります。
この属性は、キャッシュがEPL問合せで参照されている場合にのみ必須です。問合せプロセッサはキャッシュ内のイベントのタイプを知る必要があるからです。
EPNアセンブリ・ファイルで、キャッシュを参照するEPL問合せを実行するプロセッサの構成を更新して、キャッシュを参照するwlevs:cache-source
子要素を追加します。例:
<wlevs:channel 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
などのキャッシュによって提供されるイベント型に一致するとき、プロセッサはキャッシュからそのイベント型のインスタンスを抽出します。
アダプタも、他のBeanを参照するための標準Springメカニズムを使用してキャッシュに組み込むことができます。キャッシュBeanは、java.util.Map
インタフェースを実装します。このインタフェースは、組み込まれたキャッシュにアクセスするためにアダプタが使用します。
まず、EPNアセンブリ・ファイル内のアダプタの構成は、次の例で示すように、wlevs:instance-property
子要素を使用して更新する必要があります。
<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) {...}
}
EPNアセンブリ・ファイルで標準のSpring Beanとして構成されたビジネスPOJOでは、他のBeanを参照するための標準のSpringメカニズムを使用して、キャッシュを挿入することができます。この方法によって、POJOではキャッシュを表示および操作できます。キャッシュBeanでは、ビジネスPOJOが挿入されたキャッシュにアクセスするために使用するjava.util.Map
インタフェースが実装されます。キャッシュBeanではjava.util.Map
のベンダー固有のサブインタフェースを実装することもできますが、移植性のためにMap
を実装することをお薦めします。
まず、EPNアセンブリ・ファイル内のビジネスPOJOの構成は、FX例(『Oracle Complex Event Processingスタート・ガイド』のHelloWorld例に関する項を参照)のOutput Beanに基づいた次の例で示されるように、property
子要素を使用して更新する必要があります。
<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は、自動的にビジネスPOJO Beanにキャッシュ(java.util.Map
として実装)を組み込みます。
ビジネスPOJO BeanのJavaソースでは、POJOによるキャッシュ処理の機能を実装するコードを持つsetMap
(Map)
メソッドを追加します。
package com.bea.wlevs.example.helloworld;
…
import java.util.Map;
public class HelloWorldBean implements EventSink {
...
public void setMap (Map map) {...}
}
標準イベント・ストリームに加えて、Oracle CQLルールはユーザー定義関数のメンバー・メソッドも起動できます。
これらのユーザー定義関数は標準Javaクラスとして実装され、次の例で示すように、Oracle CQLプロセッサのコンポーネント構成ファイル内で宣言されます。
<bean id="orderFunction" class="orderFunction-impl-class"/>
関連するOracle CQLルールが実行されるプロセッサは、ref
属性を持つSpring Beanを参照し、wlevs:function
子要素を使用してユーザー定義関数に組み込まれる必要があります。
<wlevs:processor id= "tradeProcessor">
<wlevs:function ref="orderFunction"/>
</wlevs:processor>
また、wlevs:function
要素でBeanクラスを指定できます。
<wlevs:processor id="testProcessor"> <wlevs:listener ref="providerCache"/> <wlevs:listener ref="outputCache"/> <wlevs:cache-source ref="testCache"/> <wlevs:function function-name="mymod" exec-method=”execute” /> <bean class="com.bea.wlevs.example.function.MyMod"/> </wlevs:function> </wlevs:processor>
次のOracle CQLルールは、tradeProcessor
プロセッサに構成されると仮定され、orderFunction
ユーザー定義関数のexistsOrder
メソッドを起動する方法を示します。
INSERT INTO InstitutionalOrder
SELECT er.orderKey AS key, er.symbol AS symbol, er.shares as cumulativeShares
FROM ExecutionRequest er [Range 8 hours]
WHERE NOT orderFunction.existsOrder(er.orderKey)
別のBeanを参照する標準Springメカニズムを使用してキャッシュを持つ関数を組み込むことによって、キャッシュにアクセスするためのユーザー定義関数を構成することもできます。キャッシュBeanは、java.util.Map
インタフェースを実装します。このインタフェースは、組み込まれたキャッシュにアクセスするためにユーザー定義関数が使用します。
まず、EPNアセンブリ・ファイル内のユーザー定義関数の構成は、次の例で示すように、wlevs:property
子要素を使用して更新する必要があります。
<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) {...}
}
ユーザー定義関数の詳細は、『Oracle Complex Event Processing CQL言語リファレンス』の関数: ユーザー定義に関する項を参照してください。
標準のイベント・ストリームのほか、EPLルールでもユーザー定義関数のメンバー・メソッドを呼び出すことができます。
これらのユーザー定義関数は、標準のJavaクラスとして実装され、次の例のようにEPNアセンブリ・ファイルで標準のSpring Beanタグを使用して宣言されています。
<bean id="orderFunction" class="orderFunction-impl-class"/>
関連するEPLルールが実行されるプロセッサは、ref
属性を持つSpringを参照し、wlevs:function
子要素を使用してユーザー定義関数に組み込まれる必要があります。
<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
インタフェースを実装します。このインタフェースは、組み込まれたキャッシュにアクセスするためにユーザー定義関数が使用します。
まず、EPNアセンブリ・ファイル内のユーザー定義関数の構成は、次の例で示すように、wlevs:property
子要素を使用して更新する必要があります。
<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) {...}
}
ユーザー定義関数の詳細は、『Oracle Complex Event Processing EPL言語リファレンス』のユーザー定義関数に関する項を参照してください。
実行時、Oracle CEPがキャッシュ・システムと定義するキャッシュにデプロイするMBeansおよびJMXを使用して、キャッシュにプログラムからアクセスできます。
この項では次について説明します:
詳細は、『Oracle Complex Event Processing管理者ガイド』のOracle CEP用のJMXの構成に関する項を参照してください。
JMXを使用してキャッシュ・システムまたはキャッシュにアクセスする最も単純かつエラーの少ない方法は、Oracle CEP Visualizerを使用することです。
詳細は、『Oracle Complex Event Processing Visualizerユーザー・ガイド』のサーバーおよびドメイン・タスクに関する項を参照してください。
JMXを使用してキャッシュ・システムまたはキャッシュにアクセスする最も単純かつエラーの少ない方法は、Oracle CEP Visualizerを使用することです(12.11.1項『Oracle CEP Visualizerを使用したJMXによるキャッシュへのアクセス方法』)に関する項を参照)。あるいは、書き込まれるJavaコードを使用したJMXによるキャッシュ・システムまたはキャッシュにアクセスできます。
Oracle CEPは、アプリケーションがステージとして使用する各キャッシュのStageMBean
を作成します。このMBeanのType
はStage
です。
Javaを使用したJMXでキャッシュにアクセスするには:
Oracle CEPサーバーが提供するJMXサービスに接続します。
詳細は、『Oracle Complex Event Processing管理者ガイド』のOracle CEP用のJMXの構成に関する項を参照してください。
次のいずれかを使用してキャッシュStageMbean
のリストを取得します。
CachingSystemMBean.getCacheMBeans()
ApplicationMBean.getStageMBeans()
キャッシュ・システム内でキャッシュを表す所定のStageMBean
のObjectName
を取得します。
ObjectName cacheName = ObjectName.getInstance ( 'com.bea.wlevs:Name = newCache,Type=Stage,CachingSystem=newCachingSystem,Application=provider' );
このObjectName
を持つStageMBean
のプロキシ・インスタンスを取得します。
StageMBean cache = (StageMBean) MBeanServerInvocationHandler.newProxyInstance( server, cacheName, StageMBean.class, false );
StageMBean
のメソッドを使用してキャッシュにアクセスします。