| Oracle® Fusion Middleware Oracle Complex Event Processing開発者ガイド 11gリリース1 (11.1.1.6.2) for Eclipse B61654-04 |
|
![]() 前 |
![]() 次 |
この章では、Oracle Complex Event Processing (Oracle CEP)イベント処理ネットワークで使用するためのキャッシュ・システムの構成方法について説明します。これには、Oracle Coherence、Oracle CEPおよびサードパーティのキャッシュ・プロバイダに基づくキャッシュを構成し、Oracle Continuous Query Language、Javaクラスおよびその他のコードからアクセスする方法に関する情報が含まれます。
キャッシュとはイベントの一時保存領域で、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に関する詳細は、 |
サードパーティのキャッシュ: 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 Fusion Middleware Oracle Complex Event Processing Visualizerユーザーズ・ガイド』
『Oracle Fusion Middleware Oracle Complex Event Processing管理者ガイド』のwlevs.Adminコマンドライン・リファレンスに関する項
『Oracle Fusion Middleware 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 Fusion Middleware 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の子要素は、キャッシュを含む宣言済のキャッシュ・システムを参照します。この子要素はキャッシング・システムがあいまいな場合にのみ指定する必要があります。複数のキャッシング・システムが(暗黙的または明示的に)宣言されている場合や、キャッシング・システムが異なるアプリケーションまたはバンドルに含まれている場合などです。
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.45項「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.45項「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.45項「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に関する詳細は、 |
|
注意: この項では、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の子要素は、キャッシュを含む宣言済のキャッシュ・システムを参照します。この子要素はキャッシング・システムがあいまいな場合にのみ指定する必要があります。複数のキャッシング・システムが(暗黙的または明示的に)宣言されている場合や、キャッシング・システムが異なるアプリケーションまたはバンドルに含まれている場合などです。
キャッシュ・システムは、特定の名前に関連付けられたキャッシュの作成およびキャッシュへの参照の戻しに関する処理を行います。その結果となるキャッシュ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>
この構成ファイルは完全に標準のファイルです。Oracle CEPの起動時にOracle Coherenceが既存のOracle Coherenceクラスタに結合しようとするのを防ぐために、cluster-name要素を指定する必要がある点に注意してください。結合すると、問題の原因になり、Oracle CEPが起動できなくなる場合があります。
tangosol-coherence-override.xmlファイルの詳細は、Oracle Coherenceドキュメント(http://www.oracle.com/technology/products/coherence/index.html)を参照してください。
Oracle CEPクラスタの詳細は、『Oracle Fusion Middleware 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クラスは自分でブログラムする必要があります。
Spring構成ファイルでキャッシュ・ローダーを指定した場合、Coherenceキャッシュ構成ファイルで対応するクラス・ファクトリ・メソッド名も指定する必要があることに注意してください。キャッシュ・ローダーには、com.bea.wlevs.cache.coherence.configuration.SpringFactoryのgetLoaderメソッドを指定します。サンプル・コードは、12.3.1.1項「coherence-cache-config.xmlファイル」を参照してください。
例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クラスは自分でブログラムする必要があります。
Spring構成ファイルでキャッシュ・ストアを指定した場合、Coherenceキャッシュ構成ファイルで対応するクラス・ファクトリ・メソッド名も指定する必要があることに注意してください。キャッシュ・ストアには、com.bea.wlevs.cache.coherence.configuration.SpringFactoryのgetStoreメソッドを指定します。サンプル・コードは、12.3.1.1項「coherence-cache-config.xmlファイル」を参照してください。
例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の子要素は、キャッシュを含む宣言済のキャッシュ・システムを参照します。この子要素はキャッシング・システムがあいまいな場合にのみ指定する必要があります。複数のキャッシング・システムが(暗黙的または明示的に)宣言されている場合や、キャッシング・システムが異なるアプリケーションまたはバンドルに含まれている場合などです。
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 Fusion Middleware 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 Fusion Middleware 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 Fusion Middleware Oracle Complex Event Processing EPL言語リファレンス』のユーザー定義関数に関する項を参照してください。
実行時、Oracle CEPがキャッシュ・システムと定義するキャッシュにデプロイするMBeansおよびJMXを使用して、キャッシュにプログラムからアクセスできます。
この項では次について説明します:
詳細は、『Oracle Fusion Middleware Oracle Complex Event Processing管理者ガイド』のOracle CEPのJMXの構成に関する項を参照してください。
JMXを使用してキャッシュ・システムまたはキャッシュにアクセスする最も単純かつエラーの少ない方法は、Oracle CEP Visualizerを使用することです。
詳細は、『Oracle Fusion Middleware 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 Fusion Middleware 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のメソッドを使用してキャッシュにアクセスします。