| Oracle Fusion Middleware Oracle Event Processing開発者ガイド 11gリリース1 (11.1.1.9) B61654-07 |
|
 前 |
 次 |
この章では、プログラミング・モデル、アプリケーションの仕組み、主要な概念および技術を含むOracle Event Processingアプリケーションを作成できるツール、技術およびプロセスについて説明します。
この章の内容は次のとおりです。
この項では、Oracle Event Processingアプリケーションの作成の一部である概念、技術およびツールの概要を示します。
Oracle Event Processingアプリケーションは、イベント・ソースからのデータ・ストリーミングを受信および処理します。データは、監視デバイス、金融サービス企業または車両を含む様々な場所のいずれかから受信する可能性があります。データを使用して、アプリケーションはパターンを識別して応答し、異常なイベントを検索して他のアプリケーションに警告し、迅速に変更されるデータに基づいた即時アクションを必要とする他の処理を実行する場合があります。
Oracle Event Processingアプリケーションを開発する場合、それぞれデータを処理するロールを持つコンポーネントのネットワークをアセンブルします。このイベント処理ネットワークは基本的に線形で、端から端にイベントが通過します。途中で、コンポーネントはデータをストリーミングするために特に設計された言語の問合せを実行し、Javaのロジックを実行し、他の外部コンポーネントとの接続を作成します。
1.1.1項「Oracle Event Processingアプリケーションの主要な概念」
1.1.2項「イベント処理ネットワークのコンポーネント・ロール」
1.1.3項「アプリケーションを開発するツールおよびサポートしている技術」
Oracle Event Processingを使用して作成するアプリケーションは、既知および(イベントベース・アプリケーションを初めて使用する場合)未知が混在する概念および技術に基づいています。次のリストは、イベント処理ネットワークの仕組みの基礎となる主要な概念および技術を簡潔に示します。
アプリケーションは、データベース・プログラミング・モデルを利用します。Oracle Event Processingアプリケーションの一部のプログラミング・モデルは、データベース・プログラミングの内容を概念的に拡張したものです。問合せを実行できるタプルである点で、イベントはデータベース行と類似しています(SQLを拡張する言語を使用)。つまり、リレーショナル・データベースを理解している場合、ほとんどの処理に精通します。
データベース・プログラミングとOracle Event Processingアプリケーション間の類似性を詳細に参照する場合、1.3項「イベント、ストリームおよびリレーションの概要」を参照してください。
ステージは、個別の機能ロールを表します。イベント処理ネットワーク(EPN)のステージングされた構造は、ネットワークを通過するイベントに対する様々なロジックを実行する手段を提供します。これには、Oracle Continuous Query Language (Oracle CQL)を使用した問合せロジックおよびJavaのロジックが含まれています。コードの検出に基づいて複数のダウンストリーム方向に分岐するネットワークで複数の処理パスを取得する方法も提供します。
EPNのステージのロールのリストは、1.1.2項「イベント処理ネットワークのコンポーネント・ロール」を参照してください。EPNの一部を詳細に調べるには、1.2項「Oracle Event Processingアプリケーションの仕組み」を参照してください。
ステージは、イベント・シンクおよびイベント・ソースとして、EPNを介してイベントを送信します。EPNのステージは、(イベント・シンクとして)イベントを受信したり、(イベント・ソースとして)イベントを送信できます。これには、固有のアダプタやBeanなどの作成するコンポーネントとともにOracle Event Processingに付属するステージ・コンポーネントが含まれます。
固有のイベント・シンクおよびソースの実装の詳細は、第16章「Javaでのイベントの処理」を参照してください。
イベントは、ストリームまたはリレーションとして処理されます。イベントベース・アプリケーションのストリーミングに一意であるストリームの概念は、イベントがタイムスタンプ順でアプリケーションに到着する事実を示します。これと表の行がスキーマを除いて相互に固有の関係を持たないデータベースの行を対比します。ただし、ストリームの多くの問合せのイベントはリレーションになり、時間の相対順序以外の方法でイベントを関連付けることができます(データベース問合せ結果に類似しています)。
ストリームおよびリレーションの詳細は、1.3項「イベント、ストリームおよびリレーションの概要」を参照してください。
作成するOracle Event Processingアプリケーションの中心は、イベント処理ネットワーク(EPN)です。それぞれにネットワークを通過するイベントを処理するロールを持つコンポーネント(ステージとも呼ばれます)を接続して、EPNを作成します。Oracle Event Processingアプリケーションを開発する場合、必要なコンポーネントの種類を識別します。コンポーネントをEPNに追加する場合、相互の接続とともにそれぞれを構成します。IDEを使用してEPNを作成する場合、イベントを左端から届いてEPNを通過して右端で終了するほぼ線形の形状でコンポーネントを配置および接続します。
含まれる技術の詳細な説明を含むアプリケーションの例を使用したEPNの上位レベルの概要は、1.2項「Oracle Event Processingアプリケーションの仕組み」を参照してください。
使用するEPNコンポーネントは、次の方法を提供します。
イベント・データと外部ソースの交換。アダプタおよび他のステージを介して、外部コンポーネントをアプリケーションのEPNに接続して、イベント・データを含むデータをEPNの内外に渡す方法を追加できます。
外部コンポーネントには、次のリストの外部コンポーネントが含まれます(固有の外部コンポーネントも作成できます)。
リレーショナル・データベース。SQLと同様にデータベースに問い合せて、Oracle CQLコード内からデータベース表にアクセスできます。
キャッシュ。キャッシュ・ステージをEPNに追加して、キャッシュを使用してデータを交換できます。
Java Message Service (JMS)。JMSアダプタを使用すると、通常必要になるJavaコードを書き込まずにJMS宛先を使用してメッセージを交換できます。
HTTPパブリッシュ・サブスクライブ・サーバー。HTTP Pub-Subアダプタは、HTTPパブリッシュ・サブスクライブ・サーバーでのメッセージの交換を単純化します。
アプリケーション・コードで処理できるよう、イベント・データをモデル化します。アプリケーション・コードで使用できるよう、イベント・データをモデル化するイベント・タイプを実装または定義します。詳細は、第9章「イベント・タイプの定義および使用」を参照してください。
イベントを問い合せてフィルタ処理します。Oracle Continuous Query Language (Oracle CQL)は、SQL言語の拡張機能であり、データベースのデータのようにイベントを問い合せることができます。Oracle CQLには、特にストリーミング・データを問い合せる機能が含まれます。プロセッサを追加して、Oracle CQLコードをイベント処理ネットワークに追加します。詳細は、第17章「Oracle CQLでのイベント・ストリームの問合せ」を参照してください。
イベントを処理するJavaロジックを実行します。EPNに対して、他のEPNステージのようにイベントを送受信するJavaクラスを追加できます。これらのクラスのロジックでは、イベントから値を取得したり、新しいイベントを作成したりできます。詳細は、第16章「Javaでのイベントの処理」を参照してください。
イベント処理ネットワークの作成のIDEの詳細なリファレンスは、7.4項「EPNエディタの使用」を参照してください。
アプリケーションを開発するために使用できる一連のツールおよびサポートしている技術には、Oracle Event Processingが含まれます。アプリケーションの作成およびデバッグ、負荷のかからないアプリケーションのテスト、Javaによる基本機能へのアクセス、およびOracle CQL問合せの設計のためのツールが含まれます。
次のリストは、このようなツールおよび技術の一部を示します。
Oracle Event Processing IDE for Eclipseは、イベント処理ネットワークをグラフィカルに設計するEPNエディタを含むOracle Event Processingの開発を容易にするよう特に設計された機能を提供します。詳細は、第4章「Oracle Event Processing IDE for Eclipseの概要」を参照してください。
IDEを使用して単純なアプリケーションを作成する手順を追った説明は、第8章「ウォークスルー: 単純なアプリケーションのアセンブル」を参照してください。
csvgenアダプタとともにロード・ジェネレータを使用して、開発の早期段階でアプリケーションをより簡単にデバッグできます。ロード・ジェネレータは、カンマ区切りテキスト・ファイルからデータを読み取り、イベント・データとしてデータをEPNにフィードするツールです。詳細は、第21章「ロード・ジェネレータおよびcsvgenアダプタによるアプリケーションのテスト」を参照してください。
Oracle Event Processing Java APIには、イベント処理ネットワークのステージの実装、含まれる機能の拡張、サーバーの管理などの処理のためのクラスが含まれます。詳細は、1.5項「Oracle Event Processing API」を参照してください。
Oracle Event Processing Visualizerは、Oracle CQL問合せを設計してサーバーのOracle Event Processingアプリケーションを構成できるWebベースのユーザー・インタフェースです。詳細は、『Oracle Fusion Middleware Oracle Event Processing Visualizerユーザーズ・ガイド』のOracle Event Processing Visualizerの概要に関する項を参照してください。
標準のXML構成ファイルを介して、コンポーネントを接続および構成します。IDEを使用してイベント処理ネットワークをアセンブルする場合、ほとんどのこれらのファイルの書込み処理が実行されます。ただし、ファイルを直接編集して実行する必要がある場合がある多くの設定が存在します。構成ファイルの詳細は、1.4項「アプリケーション構成の概要」を参照してください。
特定のアプリケーション設計パターン、サーバー・リソースおよび構成規則を使用して、スケーラビリティを向上し、高可用性を促進できます。詳細は、第25章「スケーラブルなアプリケーションの開発」および第24章「高可用性のためのアプリケーションの開発」を参照してください。
多くの企業規模のアプリケーションと同様に、Oracle Event Processingアプリケーションは接続関係が多くあります。たとえば、アダプタはプロセッサに接続され、プロセッサはイベントBeanに接続され、イベントBeanは外部データ・ソースに接続される場合などがあります。接続は必ずしもこの順序ではありませんが、概念がわかります。
イベントは外部ソースから受信し、アプリケーションのイベント処理ネットワーク(EPN)を移動します。途中で、フィルタ処理、問合せおよび配置するEPNコンポーネントの必要に応じた処理が行われる場合があります。
たとえば、単純なTradeReportアプリケーションの場合、第8章「ウォークスルー: 単純なアプリケーションのアセンブル」に記載されているトピックを使用して作成できます。
次の項では、アプリケーションの各コンポーネントのロールについて説明します。
イベント情報をRaw形式で受信します
TradeReportの例では、イベント・データ・ソースは、カンマ区切り値の行を使用したテキスト・ファイルです。試行するには、Oracle Event Processingに付属しているロード・ジェネレータと組み合せてそのようなファイルを使用できます。
イベント・データ・ソースはアプリケーションの外部にありますが、データの取得方法を認識するアダプタを介して接続されます。イベント・ソースは物理的に近い可能性があるか(組織内の別のアプリケーションなど)、非常に遠い可能性があります(他の都市のサーバー室の温度センサーなど)。
イベント・データおよびイベント・タイプの作成の詳細は、第9章「イベント・タイプの定義および使用」を参照してください。
TradeReportアプリケーションのイベント・タイプの取得の段階を追った内容は、8.3項「イベント・データを移動するイベント・タイプの作成」を参照してください。
アダプタは外部コンポーネントをEPNに接続します
TradeReportの例で、イベント・データ・ソースは、CSVファイルから送信されるイベント・データの受信方法を認識するアダプタを介してイベント処理ネットワークに接続されます。アダプタは、着信データをEPNで使用できるイベント・タイプのインスタンスに変換します。
アダプタを使用して、着信データの受信または発信データの送信を行うことができます。Oracle Event Processingに付属のアダプタは、CSVファイルおよびJava Message ServiceやHTTPパブリッシュ・サブスクライブ・サーバーなどのシステムへのアクセスを提供します。デフォルトでサポートされていないシステムを統合する固有のアダプタも開発できます。
入力アダプタを構成する場合、イベント・データをEPNで定義したイベント・タイプのインスタンスにバインドする方法を指定します。
詳細は、次を参照してください。
第12章「HTTPパブリッシュ・サブスクライブ・サーバーの統合」
第15章「カスタム・アダプタを使用した外部コンポーネントの統合」
第21章「ロード・ジェネレータおよびcsvgenアダプタを使用したアプリケーションのテスト」
csvgenアダプタを追加してTradeReportアプリケーションのCSVの内容を受信する段階を追った内容は、8.4項「イベント・データを受信する入力アダプタの追加」を参照してください。
イベント・タイプはイベント・データの便利な構造を提供します
TradeReportアプリケーションでは、入力アダプタは、一連のカンマ区切り値からJavaクラスとして定義されるイベント・タイプ・インスタンスのプロパティ値に着信イベント・データを変換します。
イベント・タイプは、アプリケーションの他のコードで使用できるイベント・データの予測可能な構造を提供します。このコードの例には、イベントをフィルタ処理して動作対象のイベントを検出するOracle CQL問合せ、アプリケーションで受信した内容に基づいた新しい種類のイベントを作成するBeanのJavaコード、値を取得して別のデータ・ソースの値とマージするコードが含まれます。
イベント・タイプは、イベント・データへのアクセスを提供するプロパティを定義します。アダプタはJavaメッセージ・システム(JMS)または金融マーケット・データ・フィードなどの様々なイベント・ソースからの着信イベントを受信します。コードで使用する前に、これらのイベントのOracle Event Processingイベント・タイプを定義する必要があります。
EPNを構成する場合、イベント・タイプを指定します。所有しているrawイベント・データの構造を使用して、アプリケーションのニーズに最適なイベント・タイプを定義できます。イベント・タイプを定義する一般的なベスト・プラクティスは、プロパティをアプリケーションで使用するイベント・データにマップするJavaBeanクラスを書き込むことです。単純なタプルおよびJavaマップ・インスタンスとしてイベント・タイプを定義することもできます。
詳細は、第9章「イベント・タイプの定義および使用」を参照してください。
TradeReportアプリケーションのイベント・タイプの定義の段階を追った内容は、8.3項「イベント・データを移動するイベント・タイプの作成」を参照してください。
チャネルはステージ間でイベントを転送します
TradeReportアプリケーションでは、入力アダプタは、チャネルを介してイベントを送信して、イベントをOracle CQLプロセッサに送信します。
チャネルは、イベント処理ネットワークのステージを接続します。ほとんどのコンポーネント間で、ステージからのイベントをリスニングするチャネルを追加し、それらのイベントを別のステージに送信します。
チャネルの追加の詳細は、第10章「チャネルを使用したEPNステージの接続」を参照してください。
TradeReportアプリケーションへのチャネルの追加の段階を追った内容は、8.5項「イベントを伝達するチャネルの追加」を参照してください。
プロセッサはイベントを調査する問合せコードを含みます
TradeReportアプリケーションには、受信したイベントのストリームを特定の基準を満たすイベントのみにフィルタ処理する単純なOracle Continuous Query Language (Oracle CQL)問合せを含むプロセッサが含まれます。イベントは、次のステージに渡すイベントを決定するフィルタとして機能するOracle CQLコードで実行されるプロセッサを通過します。
アプリケーションのロジックは、通過するイベントの特性に依存します。このアプリケーションでは、プロセッサ・ステージは、特定のデータまたはトレンドの発生を検索するOracle CQLコードを使用してそれらの品質を検出する場所です。
より静的なリレーショナル・データ・ソースの問合せに使用されるSQL言語に非常に類似しているため、Oracle CQL言語は、イベントで表されるデータの情報を検出する強力なツールです。たとえば、Oracle CQLには、単純なcount()およびsum()関数から高度な統計関数まで、様々な関数が含まれます。
Oracle CQLはSQLと類似していますが、通常は静的データベースの問合せ時ほど重要ではない特性、つまり時間の経過を表す問合せを書き込むことを対象にした機能も含まれます。このような時間に関連する機能を介して、現在から5ミリ秒前などの特定のウィンドウを定義するコードを書き込むことなどができます。問合せを実行して、イベントが通過する際にこのウィンドウを分離できます。
Oracle CQLプロセッサのコードを使用して、キャッシュおよびリレーショナル・データベースを含む様々なソースからデータを収集および結合することもできます。たとえば、キャッシュを使用すると、パフォーマンスが高速になる頻繁に取得するデータを配置する場所が提供されます。
Oracle CQLエンジンは、Oracle CQLコードで追加機能を使用できるカートリッジでも拡張できます。
Oracle CQLの詳細は、第17章「Oracle CQLでのイベント・ストリームの問合せ」を参照してください。
TradeReportアプリケーションのOracle CQL問合せの定義の段階を追った情報は、8.8項「イベントをフィルタ処理するOracle CQLプロセッサの追加」を参照してください。
BeanはJavaロジックの場所を提供します
TradeReportアプリケーションはOracle CQLを使用してイベントを処理すると、イベントを受信して各イベント・タイプ・インスタンスに含まれるコンソール・データに出力するイベントBeanに結果イベントを渡します。
EPNでは、Beanは、通過するイベント上でJavaコードを実行する場所を提供します。Beanは、イベントを送受信できます。たとえば、Beanは特定のタイプのイベントを受信し、データを取得してデータを使用した計算または検索を実行します。Beanは、新しいイベントを別のステージに渡す前に、新しく生成したデータから新しいイベントを作成できます。
Spring BeanまたはイベントBeanとしてBeanを書き込んで構成することができます。Spring Beanは、Springフレームワークで管理され、Beanを既存のSpringデプロイメントに統合する場合に適切な選択肢です。一方、イベントBeanは、Oracle Event Processingサーバーで管理するよう、Beanを構成するOracle Event Processing規則を使用します。たとえば、イベントBeanを使用して、監視やイベントの記録および再生などのOracle Event Processingサーバー機能のサポートを取得します(アプリケーションのデバッグに役立ちます)。
イベントを処理するJavaクラスの書込みおよび使用の詳細は、第16章「Javaでのイベントの処理」を参照してください。
TradeReportアプリケーションへのイベントBeanの追加の段階を追った内容は、8.6項「イベントを受信およびレポートするリスナーの作成」を参照してください。
構成ファイルはEPNおよびコンポーネントを定義します
TradeReportアプリケーション・ステージ間のEPNプレゼンスおよび接続は、EPNアセンブリXMLファイルで構成されます。この場合は使用されませんが、コンポーネントのランタイム構成を定義できるコンポーネント構成ファイルもあります。
EPNアセンブリ・ファイルは、IDEを使用してイベント処理ネットワークをアセンブルする場合に書き込む内容です(EPNエディタは、基本的にEPNアセンブリ・ファイルを設計するユーザー・インタフェースです)。EPNアセンブリ・ファイルの内容はステージを宣言し、あるステージから別のステージに移動する場合のイベントの方向を含む対話方法を決定します。EPNアセンブリ・ファイルは、コンポーネント設定のデフォルト値または実行時に変更する必要がない値も設定します。
一方、コンポーネント構成ファイルを使用して、アプリケーションの実行中に管理者が後で変更できる構成データを指定できます。コンポーネント構成ファイルは、通常Oracle CQLコードが書き込まれます(プロセッサ・コンポーネントの構成として)。
構成ファイルの詳細は、1.4項「アプリケーション構成の概要」を参照してください。
設計および構成規則のスケーラビリティおよび高可用性
単純なTradeReportアプリケーションではわかりませんが、アプリケーションを引き続き使用して十分なスケーラビリティを確保するために使用できる設計パターンがあります。
アプリケーションの高可用性を維持する場合、ソフトウェアまたはハードウェアで障害が発生した場合でもデプロイされたアプリケーションで引き続き役割を果たすよう、アプリケーションの設計パターン、サーバー・リソースおよび構成規則を統合します。
スケーラブルなOracle Event Processingアプリケーションは、設計パターンに実装および構成規則を組み込んで、イベント・ロードが増える場合のアプリケーションの十分な動作を保証します。
詳細は、次を参照してください。
Oracle Event Processingアプリケーションは、rawイベント・データとしてストリームに到着し、アプリケーション内のイベント・タイプ・インスタンスに変換され、イベント処理ネットワークのあるアプリケーション・ステージから別のアプリケーション・ステージに移動するイベントを処理します。途中で、イベントは、Oracle CQL問合せでフィルタ処理され、Javaコードで処理され、キャッシュに格納され、他のアプリケーションに転送される場合などがあります。
イベントとは何ですか。イベント・データのストリーミングという視点を重視すると、どれくらいのイベントがデータベース内の行となるかを忘れがちです。アプリケーションの用語では、イベントはタプルまたは一連の値です。リレーショナル・データベース行と同様に、イベントには、各値が特定のデータ型などの特定の制約を持つスキーマがあります。イベントのスキーマは、プロパティ(値の場所)およびタイプのセットを定義します。
イベントとデータベース行の相違点は時間の重要性です。イベントのストリームでは、別のイベントの前後のイベントの到着を含むイベントが到着する時間が非常に重要になります。そのため、アプリケーションで時間および順序を説明できる必要があります。
たとえば、株式取引を処理するアプリケーションでは、銘柄記号、価格、終値、変化率および量で構成されるイベント・タプルは、各取引を実行した順序で順に到着します。アプリケーションのロジックでは、別の取引の直後に発生した株式の取引を検索する場合があります。
つまり、イベント処理アプリケーションでは、イベントがストリームで発生する順序は、各イベント・プロパティのデータ型および値と同じように重要です。その結果、Oracle Event Processingプログラミング・モデルの規則は、時間および順序の重要性を反映します。コードによって、特定の基準(銘柄記号など)に基づいて相互に関連するイベントを検出できます。ただし、順序パターン(相互に15秒以内の取引など)も検出できる必要があります。アプリケーションにイベントが到着する場合に低待機時間で、これらを検出できる必要があります。
イベント・データのシーケンシャルおよびリレーショナルな側面を説明するには、Oracle Event Processingはストリームおよびリレーションの概念を使用します。
ストリームは、ほぼ無制限の連続するイベントです。データベースの行と同様に、イベントはタプルですが、それぞれ固有のタイムスタンプがあります。ストリームでは、あるイベントから次のイベントにタイムスタンプが古くならないよう、イベントを時系列に並べる必要があります(ただし、同じタイムスタンプを持つストリームのイベントが存在する場合があります)。
リレーションでは、順序は重要ではありません(データベース問合せの結果と同様)。かわりに、特定の基準を満たすため、通常リレーションのイベントが関連します。たとえば、リレーションのイベントは、問合せで特定のレベルを超える取引量を検索した場合、株式取引のストリームに対して実行される問合せの結果である可能性があります。
株式取引イベントのストリームを考えてみます。イベントが順に到着し、それぞれ固有のタイムスタンプ(取引が発生した時間)があります。相互に5秒以内で発生した取引の株価を分離するには、次のOracle CQLコードを使用して、ストリーム(StockTradeChannelから受信)を問い合せます。
select price from StockTradeChannel [range 5 seconds]
期間[range 5 seconds]を使用してイベントを分離するため、この問合せの出力はリレーションです。問合せから返されたイベントはタイムスタンプを持ちますが、リレーションで順序付けされません。着信イベントがストリームにあるため、問合せは、問合せプロセッサに渡す場合に5秒分のイベントごとに継続的に実行されます。新しいイベントが到着すると、問合せの条件を満たすイベントはリレーションに挿入されますが、離れる(実際に押し出される)イベントはリレーションから削除されます。
これはなぜ重要なのでしょうか。ストリームとしてのストリームの完全性は重要です。技術的に、ストリームは、タプルの継続的に移動(ストリーミング)する順序付けされたセットです。ストリームでは、ソースで順番にストリームに配置して各イベントを挿入できます。問合せを使用してストリームのサブセットを取得すると、順序付けされるものが必要ありません。サブセットを所有した後、ストリームの問合せ結果のリレーションを問い合せるOracle CQLコードを実行して、イベントをさらに分離できます。
このため、Oracle CQL参照の例では、問合せ結果として特定の時点で挿入または削除されるイベントとして問合せの出力を示します。
EPNの次のステージにリレーションを渡す前に、IStreamなどの演算子を使用してストリームに変換できます。
詳細は、次を参照してください:
『Oracle Fusion Middleware Oracle Event Processing CQL言語リファレンス』のストリームとリレーションに関する項
標準スキーマに基づくXMLファイルを介して、Oracle Event Processingアプリケーションを構成します。Oracle Event Processingをインストールすると、これらのスキーマのXSDファイルは、ディレクトリMIDDLEWARE_HOME\ocep_11.1\xsdに含まれます。
イベント処理ネットワーク(EPN)をアセンブルすると、IDEを使用している場合でも、EPNアセンブリXMLファイルを作成します。このファイルのステージのエントリは、ステージをEPNに追加し、他のステージとの接続を定義します。このファイルの詳細は、1.4.1項「EPNアセンブリ・ファイルの概要」を参照してください。
イベント処理ネットワークの各コンポーネント(アダプタ、プロセッサ、チャネルまたはイベントBean)は、関連付けられた構成XMLを持つことができます。この構成を提供して、実行時にコンポーネントの構成を編集する方法を提供します。(構成ファイルを所有するには、プロセッサのみが必要です。)開発プロセスのニーズに応じて、コンポーネントの構成XMLを単一のコンポーネント構成ファイルにグループ化し、複数のファイルに分割できます。コンポーネント構成ファイルの詳細は、1.4.2項「コンポーネント構成ファイルの概要」を参照してください。
Oracle Event Processingアプリケーションの他の側面では、固有の構成ファイルが必要な場合があります。Oracle Coherenceで提供されるキャッシュが含まれます。他の構成の詳細は、それらの技術に関連するドキュメントの項を参照してください。
IDEを使用してイベント処理ネットワーク(EPN)をアセンブルする場合、アセンブリ・ファイルでEPNを定義します。EPNアセンブリ・ファイルは、SpringフレームワークのXML構成ファイルに基づいた形状のXMLファイルです。EPNアセンブリ・ファイル・スキーマは、Spring構成スキーマを拡張します。
spring-wlevs-v11_1_1_6.xsdスキーマ・ファイルでは、EPNアセンブリ・ファイルの構造について説明しています。Oracle Event Processingをインストールすると、このようなXSDファイルは、ディレクトリMIDDLEWARE_HOME\ocep_11.1\xsdに含まれます。
EPNアセンブリ・ファイルの構造は次のとおりです。beansという最上位ルート要素に、サブ要素のシーケンスが含まれています。個々のサブ要素には、Oracle Event Processingコンポーネントの構成データが含まれています。例:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:osgi="http://www.springframework.org/schema/osgi"
xmlns:wlevs="http://www.bea.com/ns/wlevs/spring"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/osgi
http://www.springframework.org/schema/osgi/spring-osgi.xsd
http://www.bea.com/ns/wlevs/spring
http://www.bea.com/ns/wlevs/spring/spring-wlevs-v11_1_1_6.xsd">
<wlevs:event-type-repository>
<wlevs:event-type type-name="HelloWorldEvent">
<wlevs:class>com.bea.wlevs.event.example.helloworld.HelloWorldEvent</wlevs:class>
</wlevs:event-type>
</wlevs:event-type-repository>
<wlevs:adapter id="helloworldAdapter"
class="com.bea.wlevs.adapter.example.helloworld.HelloWorldAdapter" >
<wlevs:instance-property name="message" value="HelloWorld - the current time is:"/>
</wlevs:adapter>
<wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
<wlevs:listener ref="helloworldProcessor"/>
<wlevs:source ref="helloworldAdapter"/>
</wlevs:channel>
<wlevs:processor id="helloworldProcessor" />
<wlevs:channel id="helloworldOutputChannel"
event-type="HelloWorldEvent" advertise="true">
<wlevs:listener>
<bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
</wlevs:listener>
<wlevs:source ref="helloworldProcessor"/>
</wlevs:channel>
</beans>
一部のOracle Event Processing機能では、EPNアセンブリ・ファイルおよびコンポーネント構成ファイルで一部の構成を指定します。
詳細は、次を参照してください:
EPNの親ステージ内に子ステージを定義した場合、子ステージはネストと言われます。親ステージのみが子ステージをリスナーとして指定できます。
例1-1は、HelloWorldBeanがhelloworldOutputChannel内にネストされているEPNアセンブリ・ソースです。親helloworldOutputChannelのみが、ネストされたBeanをリスナーとして指定できます。
例1-1 ネストされたBeanによるEPNアセンブリ・ファイル
<wlevs:adapter id="helloworldAdapter" class="com.bea.wlevs.adapter.example.helloworld.HelloWorldAdapter" >
<wlevs:instance-property name="message" value="HelloWorld - the current time is:"/>
</wlevs:adapter>
<wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
<wlevs:listener ref="helloworldProcessor"/>
<wlevs:source ref="helloworldAdapter"/>
</wlevs:channel>
<wlevs:processor id="helloworldProcessor" />
<wlevs:channel id="helloworldOutput" event-type="HelloWorldEvent" advertise="true">
<wlevs:listener>
<bean class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
</wlevs:listener>
<wlevs:source ref="helloworldProcessor"/>
</wlevs:channel>
かわりに、例1-2に示すように、すべてにノードがネストされるようにこのEPNを定義できます。helloworldAdapterは最も外側の親ステージであり、EPNの他のステージにアクセスできる単一ステージです。
例1-2 ネストされたすべてのノードによるEPNアセンブリ・ファイル
<wlevs:adapter id="helloworldAdapter" class="com.bea.wlevs.adapter.example.helloworld.HelloWorldAdapter" >
<wlevs:instance-property name="message"
value="HelloWorld - the current time is:"/>
<wlevs:listener>
<wlevs:channel id="helloworldInputChannel" event-type="HelloWorldEvent" >
<wlevs:listener>
<wlevs:processor id="helloworldProcessor">
<wlevs:listener>
<wlevs:channel id="helloworldOutputChannel"
event-type="HelloWorldEvent">
<wlevs:listener>
<bean
class="com.bea.wlevs.example.helloworld.HelloWorldBean"/>
</wlevs:listener>
</wlevs:channel>
</wlevs:listener>
</wlevs:processor>
</wlevs:listener>
</wlevs:channel>
</wlevs:listener>
</wlevs:adapter>
詳細は、7.2.9項「ネストされたステージ」を参照してください。
別のOracle Event Processingアプリケーションのステージを参照できます。別のアプリケーションのステージは、外部ステージと見なされます。同じアプリケーションのソースおよびターゲット・ステージを定義する場合、idでこれを実行します。
|
注意: プロセッサ・ステージを外部ステージのチャネルに接続できません。 |
別のアプリケーションで定義したステージを参照するには、次の構文を使用します。
FOREIGN-APPLICATION-NAME:FOREIGN-STAGE-ID
ここでは、FOREIGN-APPLICATION-NAMEは、外部ステージを定義したアプリケーションの名前であり、FOREIGN-STAGE-IDは、外部ステージのid属性です。
例1-3では、アプリケーションapplication2で定義した外部ステージHelloWorldBeanSourceをapplication1が参照する方法について説明しています。
例1-3 アプリケーション2の外部ステージを参照するアプリケーション1
<wlevs:stream id="helloworldInstream" >
<wlevs:listener ref="helloworldProcessor"/>
<wlevs:source ref="application2:HelloWorldBeanSource"/>
</wlevs:stream>
例1-4 アプリケーション2の外部ステージ
<wlevs:event-bean id="HelloWorldBeanSource"
class="com.bea.wlevs.example.helloworld.HelloWorldBeanSource"
advertise="true"/>
次の各ステージは外部ステージにはできません。
キャッシュ
外部ステージを伴うOracle Event Processingアプリケーションを作成する場合、アプリケーションのアセンブリ、デプロイおよび再デプロイのときに外部ステージの依存関係を考慮する必要があります。詳細は、23.2.3項「外部ステージによるアプリケーションのアセンブリ」を参照してください。
イベント処理ネットワークの各コンポーネント(アダプタ、プロセッサ、チャネル、またはイベントBean)には構成ファイルを関連付けることができますが、構成ファイルが必須なのはプロセッサのみです。イベント処理ネットワークのステージであるかどうかにかかわらず、キャッシング・システムも構成ファイルを使用します。Oracle Event Processingのコンポーネント構成ファイルは、標準のXMLスキーマを使用して定義された構造を持つXMLドキュメントです。アプリケーションのすべてのコンポーネントの構成を含む単一のファイルを作成するか、または各コンポーネントごとに個別のファイルを作成できます。これらのうち、管理しやすい方を選択します。
wlevs_application_config.xsdスキーマ・ファイルでは、コンポーネント構成ファイルの構造について説明しています。Oracle Event Processingをインストールすると、このようなXSDファイルは、ディレクトリMIDDLEWARE_HOME\ocep_11.1\xsdに含まれます。
このXSDスキーマでは、次のスキーマがインポートされます。
wlevs_base_config.xsd: アプリケーション構成ファイルとサーバー構成ファイルの間で共有される共通要素を定義します。
wlevs_eventstore_config.xsd: イベント・ストア固有の要素を定義します。
wlevs_diagnostic_config.xsd: 診断要素を定義します。
アプリケーション構成ファイルの構造は次のとおりです。configという最上位ルート要素に、サブ要素のシーケンスが含まれています。個々のサブ要素には、Oracle Event Processingコンポーネント(プロセッサ、チャネルまたはアダプタ)の構成データが含まれています。例:
<?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>
<name>helloworldProcessor</name>
<rules>
<query id="helloworldRule">
<![CDATA[ select * from helloworldInputChannel [Now] ]]>
</query>
</rules>
</processor>
<channel>
<name>helloworldInputChannel</name>
<max-size>10000</max-size>
<max-threads>2</max-threads>
</channel>
<channel>
<name>helloworldOutputChannel</name>
<max-size>10000</max-size>
<max-threads>2</max-threads>
</channel>
</n1:config>
詳細は、次を参照してください:
ConfigurationPropertyPlaceholderConfigurerクラスを使用すると、シンボリック・プレースホルダーでコンポーネント構成ファイルおよびサーバー構成ファイルの両方で既存の構成ファイル・プロパティを参照できます。そうすると、複数の場所で同じ値をハードコードするのではなく、1つの場所に値を定義して、その1つの定義を参照できます。
この機能を使用するには、例1-5に示すように、アプリケーション・バンドルのアプリケーション・コンテキスト構成ファイルにConfigurationPropertyPlaceholderConfigurer Beanを挿入します。
例1-5 ConfigurationPropertyPlaceholderConfigurerの追加
<bean class="com.bea.wlevs.spring.support.ConfigurationPropertyPlaceholderConfigurer"/>
詳細は、Oracle Fusion Middleware Oracle Event Processing Java APIリファレンスのcom.bea.wlevs.spring.support.ConfigurationPropertyPlaceholderConfigurerクラスを参照してください。
プロパティ・ファイルのアクセスの詳細は、5.7.3項「Oracle Event Processingプロジェクトにプロパティ・ファイルを追加する方法」を参照してください。
Oracle Event Processingアプリケーションは、低待機時間、イベントドリブンかつ高性能駆動型のアプリケーションであるため、軽量なコンテナ上で実行し、POJOベースのプログラミング・モデルを使用して開発されています。POJO (Plain Old Java Object)プログラミングでは、ビジネス・ロジックはPOJO形式で実装され、必要とするサービスが注入されます。これは一般に、依存関係インジェクションと呼ばれます。インジェクトされたサービスは、構成管理などのOracle Event Processingサービスで提供されるものから、Oracle Kodoなどの他のOracle製品で提供されるサービスやサード・パーティ製のサービスまで多岐に渡ります。
Oracle Event Processingおよび標準のJava注釈およびデプロイメントXMLを使用することによって、Oracle Event Processing Springコンテナを構成して、リソース(データ・ソースや永続性マネージャなど)をOracle Event Processingアプリケーション・コンポーネントにインジェクトできます。
一般的に、コンポーネント初期化中に、Springコンテナでリソースがインジェクトされます。しかし、これによって、ランタイム時にリソースがインジェクトおよび再インジェクトされます。また、ランタイム時に、JNDIルックアップがサポートされます。
Oracle Event Processingでは、次のタイプのリソース・アクセスがサポートされます。
リソース名解決の詳細は、1.4.3.4項「リソース名解決について」を参照してください。
すべてのOracle Event Processing注釈の詳細は、付録I「Oracle Event Processingメタデータ注釈リファレンス」を参照してください。
次の項では、例1-6に示す例のリソースを考慮します。これは、Oracle Event Processingサーバーconfig.xmlファイルに指定するStockDSと呼ばれるデータ・ソース・リソースです。
例1-6 サンプル・リソース: データ・リソースStockDS
<config ...>
<data-source>
<name>StockDs</name>
...
<driver-params>
<url>jdbc:derby:</url>
...
<driver-params>
</data-source>
...
</config>
静的リソース・インジェクションは、コンポーネント・ライフサイクルの初期化フェーズ中にリソースのインジェクションを参照します。一度インジェクトされると、コンポーネントがアクティブまたは実行中の間、リソースは固定または静的になります。
次を使用して、静的リソース・インジェクションを構成できます。
静的リソース名を使用して静的リソース・インジェクションを構成する場合、@Resource注釈またはOracle Event ProcessingアセンブリXMLファイルに使用されるリソース名は、定義されたリソース名と完全一致する必要があります。リソース名は静的であるため、再コンパイルしないと変更できません。
設計のときに静的リソース名を使用して静的リソース・インジェクションを構成するには、例1-7に示すように、標準のjavax.annotation.Resource注釈を使用します。
設計タイムの構成をデプロイ・タイムにオーバーライドするには、例1-8に示すように、Oracle Event Processingアセンブリ・ファイルXMLを使用します。
例1-7および例1-8では、例1-6に示すように、リソース名StockDsは、Oracle Event Processingサーバーconfig.xmlファイルのデータ・ソース名と正確に一致する必要があります。
例1-7 静的リソース名を使用する静的リソース・インジェクション: 注釈
import javax.annotation.Resource;
public class SimpleBean implements EventBean {
...
@Resource (name="StockDs")
public void setDataSource (DataSource dataSource){
this.dataSource = dataSource;
}
}
例1-8 静的リソース名を使用する静的リソース・インジェクション: XML
< wlevs:event-bean id="simpleBean" class="...SimpleBean"/>
<wlevs:resource property="dataSource" name="StockDs"/>
</wlevs:event-bean>
EventBeanセット・メソッド名がリソース名と一致する場合、例1-9に示すように、@Resource注釈name属性は必要ではありません。また、この場合、例1-10に示すように、wlevs:resource要素name属性は必要ではありません。
動的リソース名は、アプリケーションの動的または外部構成の一部として指定されます。動的リソース名を使用することによって、デプロイヤまたは管理者は、アプリケーション開発者がアプリケーション・コードまたはSpringアプリケーション・コンテキストを変更する必要なくリソース名を変更できます。
アダプタまたはPOJOなどのコンポーネントに動的リソース名を追加するには、例1-11に示すように、まず、リソース名を含むコンポーネントのためにカスタム構成を指定する必要があります。
例1-11 カスタム・コンポーネント構成
<simple-bean>
<name>SimpleBean</name>
<trade-datasource>StockDs</trade-datasource>
</simple-bean>
設計のときに動的リソース名を使用して静的リソース・インジェクションを構成するには、例1-12に示すように、標準のjavax.annotation.Resource注釈を使用します。
設計タイムの構成をデプロイ・タイムにオーバーライドするには、例1-13に示すように、Oracle Event Processingアセンブリ・ファイルXMLを使用します。
動的リソース・インジェクションは、Springコンテナ・メソッド・インジェクションを使用して変更した動的構成に対して、コンポーネントがアクティブである間、動的リソースのインジェクションを参照します。
設計のときに動的リソース・インジェクションを構成するには、例1-14に示すように、標準のjavax.annotation.Resource注釈を使用します。
例1-14 動的リソース・インジェクション: 注釈
import javax.annotations.Resource;
public class SimpleBean implements EventBean {
...
@Resource ("trade-datasource")
public abstract DataSource getDataSource ();
...
}
リソース名trade-datasourceが参照するリソースの新しいインスタンスを取得する必要がある場合は、ランタイム時にコンポーネントによって、getDataSourceメソッドが呼び出されます。
一般的に、動的構成の変更が処理されている場合、@Prepareまたは@Activateメソッド中に、コンポーネントによって、getDataSourceメソッドが呼び出されます。詳細は、次を参照してください。
他の方法では、データ・ソースを使用する前に必ずgetDataSourceが呼び出されます。つまり、アプリケーション・コードでは参照をコンポーネントのフィールドとしてデータ・ソースに格納されません。
Oracle Event Processingでは、例1-15に示すように、リソースを動的に参照するためにJNDIの使用がサポートされます。
例1-15 JNDIによる動的リソース参照
import javax.naming.InitialContext;
public class SimpleBean implements EventBean {
...
public abstract void getDataSource () throws Exception {
InitialContext initialContext= new InitialContext ();
return initialContext.lookup ("StockDs”);
}
}
例1-15では、例1-6に示すように、JNDI名StockDsは、Oracle Event Processingサーバーconfig.xmlファイルのデータ・ソース名と正確に一致する必要があります。
|
注意: JNDIを使用するために、Oracle Event Processingサーバーを起動するときにセキュリティを無効にする必要があります。この理由から、JNDIの使用はお薦めしません。詳細は、『Oracle Fusion Middleware Oracle Event Processing管理者ガイド』のOracle Event Processingのセキュリティの構成に関する項を参照してください。 |
Oracle Event Processingサーバーでは、表1-1にリストされたネーミング・スコープを調べて、リソース名が解決されます。
表1-1 リソース名解決
| ネーミング・スコープ | 目次 | 解決動作 |
|---|---|---|
|
コンポーネント |
コンポーネントのカスタム構成のプロパティ名 |
マッピング |
|
アプリケーション |
アプリケーション構成ファイルの構成要素名 |
マッチング |
|
サーバー |
サーバー構成ファイルの構成要素名 |
マッチング |
|
JNDI |
サーバーのJNDIレジストリに登録された名前 |
マッチング |
各ネーミング・スコープには一意の名前のセットが含まれます。名前解決動作は、ネーミング・スコープ固有の動作です。一部のネーミング・スコープでは、簡単な一致によって名前を解決します。他のスコープでは、新しい名前を参照するために使用する名前をマップすることで名前を解決します。一度名前がマップされると、参照は現在のスコープで再帰的に続行します。
Oracle Event Processingには、アダプタまたはイベントBeanの実装に使用される様々なJava APIが用意されています。
この項では、アダプタおよびイベントBeanで最も一般的に使用されるcom.bea.wlevs.ede.apiパッケージ内のAPIについて説明しています。
AdapterFactory: アダプタ・ファクトリではこのインタフェースを実装する必要があります。
詳細は、15.6項「カスタム・アダプタ・ファクトリの作成」を参照してください。
コンポーネント・ライフサイクル・インタフェース—プログラミングするコンポーネントのライフサイクルを制御する必要がある場合は、コンポーネントで次の1つまたは複数のインタフェースを実装する必要があります。
ライフサイクルの詳細は、1.7項「Oracle Event Processingアプリケーション・ライフサイクル」を参照してください。
InitializingBean: Oracle Event Processingでコンポーネントのすべてのプロパティが設定された後でカスタムを初期化する必要がある場合に使用します。afterPropertiesSetメソッドを実装します。
ActivatableBean: すべての動的な構成が設定され、イベント処理ネットワークがアクティブ化された後でコードを実行する場合に使用します。afterConfigurationActiveメソッドを実装します。
RunnableBean: コンポーネントをスレッドで実行する場合に使用します。
Springフレームワークでも同様のBeanライフサイクル・インタフェースが実装されますが、同等のSpringインタフェースを使用してもファクトリによって作成されたBeanを操作することはできず、一方でOracle Event Processingインタフェースではこの操作が可能です。
SuspendableBean: イベント処理ネットワークが一時停止されたときにリソースを一時停止したり、イベントの処理を停止したりする場合に使用します。suspendメソッドを実装します。
ResumableBean: コンポーネントの作業が再開される前に、リソースの取得や構成などのタスクを実行する場合に使用します。
DisposableBean: アプリケーションがアンデプロイされたときにリソースを解放する場合に使用します。コンポーネントのコードにdestroyメソッドを実装します。
また、追加ライフサイクル注釈の詳細は、付録I「Oracle Event Processingメタデータ注釈リファレンス」を参照してください。
イベント・タイプ・インスタンス化インタフェース: EPNで使用するためにイベント・タイプをインスタンス化する方法のより詳細な制御にこれらのインタフェースを使用します。
イベント・タイプの詳細は、第1章「Oracle Event Processingアプリケーションの作成の概要」を参照してください。
EventBuilder: たとえば、イベント・タイプ・ビルダーを使用して、構成されたイベントのプロパティがJavaBeanとして実装したクラスなどのイベント・タイプ・クラスのプロパティに正しくバインドされていることを確認する場合など、イベント・タイプのインスタンス化を制御するために使用されます。
詳細は、9.3.1.5項「イベント・タイプ・ビルダー・クラスでのイベント・タイプのインスタンス化の制御」を参照してください。
EventBuilder.Factory: EventBuildersを作成するファクトリ。
イベント・ソースおよびシンク・インタフェース: クラスを有効にしてイベント処理ネットワークの一部としてイベントを送受信するために使用します。
イベント・ソースおよびシンクの詳細は、16.2項「ソースおよびシンクでのイベントの処理」を参照してください。
StreamSinkおよびBatchStreamSink: Oracle Event Processingストリームとしてイベントを受信するコンポーネントでは、このインタフェースを実行する必要があります。Oracle Event Processingストリームには、次の特性があります。
追加のみ。つまり、イベントはいつもストリームの終わりに追加されます。
バインドなし。一般的に、これを処理する前にウィンドウを定義する必要があります。
イベントには、非減少のタイムスタンプがあります。
実装の詳細は、16.2.1項「イベント・シンクの実装」を参照してください。
StreamSource、StreamSenderおよびBatchStreamSender: アダプタなど、Oracle Event Processingストリームをモデル化するイベントを送信するコンポーネントでは、StreamSourceを実装する必要があります。インタフェースには、イベントを実際にネットワーク内の次のコンポーネントに送信するStreamSenderまたはBatchStreamSenderを設定するためのsetEventSenderメソッドが含まれています。
実装の詳細は、16.2.2項「イベント・ソースの実装」を参照してください。
RelationSinkおよびBatchRelationSink: Oracle Event Processingリレーションをモデル化するイベントを受信するコンポーネントでは、これらのインタフェースのいずれかを実行する必要があります。Oracle Event Processingリレーションには、次の特性があります。
コンテントを挿入、削除または更新できるイベントをサポートします。
いつも、インスタント・タイムと呼ばれます。
イベントには、非減少のタイムスタンプがあります。
実装の詳細は、16.2.1項「イベント・シンクの実装」を参照してください。
RelationSource、RelationSenderおよびBatchRelationSender—アダプタなど、Oracle Event Processingリレーションをモデル化するイベントを送信するコンポーネントではこのインタフェースを実装する必要があります。インタフェースには、イベントを実際にネットワーク内の次のコンポーネントに送信するRelationSenderまたはBatchRelationSenderを設定するためのsetEventSenderメソッドが含まれています。
実装の詳細は、16.2.2項「イベント・ソースの実装」を参照してください。
詳細は、次を参照してください:
すべてのクラスおよびインタフェースの参照ドキュメントについては、Oracle Fusion Middleware Oracle Event Processing Java APIリファレンスを参照してください。
これらのAPIを使用するサンプルJavaコードについては、以下を参照してください。
Oracle Event Processing注釈およびデプロイメントXMLを使用したリソース・インジェクションの構成の詳細は、1.4.3項「Oracle Event Processingリソース・アクセスの構成」を参照してください。
アプリケーションをアセンブルした後、Oracle Event Processingにデプロイできるよう、パッケージ化する必要があります。この処理は簡単です。アプリケーションのデプロイメント単位はプレーンJARファイルであり、少なくとも次のアーティファクトが含まれている必要があります。
ビジネス・ロジックPOJOのコンパイル済アプリケーションJavaコード。
コンポーネント構成ファイル。各プロセッサには構成ファイルが必須ですが、アダプタとストリームに関しては、デフォルトの十分な構成があり、これらのコンポーネントをモニターしない場合は、構成ファイルは必要ではありません。
EPNアセンブリ・ファイル。
いくつかの追加のOSGiエントリを含むMANIFEST.MFファイル。
JARファイルへのアーティファクトのアセンブルが完了したら、着信データの受信を直ちに開始できるようOracle Event Processingにこのバンドルをデプロイします。
詳細は、第23章「Oracle Event Processingアプリケーションのアセンブルとデプロイ」を参照してください。
図1-1では、Oracle Event Processingアプリケーション・ライフサイクルの状態図を示します。この図では、状態名(STARTING、INITIALIZING、RUNNING、SUSPENDING、SUSPENDEDおよびFAILED)がApplicationRuntimeMBeanメソッドgetState戻り値に対応します。この状態は、Oracle Event Processing固有の状態であり、OSGiバンドル状態ではありません。
図1-1 Oracle Event Processingアプリケーション・ライフサイクルの状態図
|
注意: Oracle Event Processingサーバー・ライフサイクルの詳細は、『Oracle Fusion Middleware Oracle Event Processing管理者ガイド』のOracle Event Processingサーバー・ライフサイクルに関する項を参照してください。 |
この項では、Oracle Event Processingサーバーにデプロイされたアプリケーションのライフサイクルと、com.bea.wlevs.ede.apiAPIコールバックのシーケンスについて説明します。
この情報で、Oracle Event Processingのアプリケーション・ライフサイクルを管理する方法が説明されます。これによって、アプリケーションのライフサイクルAPIをより良く使用できます。
これらのライフサイクルAPI (RunnableBeanおよびSuspendableBeanなど)の詳細に付いては、以下を参照してください。
Oracle Fusion Middleware Oracle Event Processing Java APIリファレンス
ライフサイクルの説明は、次の項に記載されているアクションを含むユーザーが実行するアクションに分類されます。
アプリケーションのインストールまたはすでにデプロイされているアプリケーションを使用したサーバーの起動
Oracle Event Processingでは、次のアクションが実行されます。
Oracle Event ProcessingでアプリケーションがOSGIバンドルとしてインストールされます。OSGIでインポートおよびエクスポートが解決され、サービスがパブリッシュされます。
Oracle Event Processingは、Beanを作成します(標準のSpring BeanおよびEPNアセンブリ・ファイルのOracle Event Processingタグに対応するBeanの両方)。各Beanでは、Oracle Event Processingは次を実行します。
Spring Beanのプロパティが設定されます。<wlevs:instance-property>値はアダプタおよびイベントBeanで設定されます。
@Serviceまたは@ServiceReference注釈で指定されたサービスに適切な依存関係がインジェクションされます。
静的な構成プロパティに適切な依存関係が注入されます。
InitializingBean.afterPropertiesSetメソッドが呼び出されます。
構成コールバック(@Prepare、@Activate)がSpring Beanおよびファクトリで作成されたステージで呼び出されます。
詳細は、1.4.3項「Oracle Event Processingリソース・アクセスの構成」を参照してください。
アプリケーションの現在の状態はINITIALIZINGです。
Oracle Event Processingは、MBeanを登録します。
Oracle Event Processingは、すべてのActivatableBeansのActivatableBean.afterConfigurationActiveメソッドを呼び出します。
Oracle Event Processingは、すべてのResumableBeansのResumableBean.beforeResumeメソッドを呼び出します。
RunnableBeanを実装する各Beanについて、Oracle Event Processingでスレッドでの実行が開始されます。
アプリケーションの現在の状態はRUNNINGです。
アプリケーションの一時停止
Oracle Event Processingでは、次のアクションが実行されます。
Oracle Event Processingは、すべてのSuspendableBeansのSuspendableBean.suspendメソッドを呼び出します。
アプリケーションの現在の状態はSUSPENDEDです。
アプリケーションの再開
Oracle Event Processingでは、次のアクションが実行されます。
Oracle Event Processingは、すべてのResumableBeansのResumableBean.beforeResumeメソッドを呼び出します。
RunnableBeanを実装する各Beanについて、Oracle Event Processingでスレッドでの実行が開始されます。
アプリケーションの現在の状態はRUNNINGです。
アプリケーションのアンインストール
Oracle Event Processingでは、次のアクションが実行されます。
Oracle Event Processingは、すべてのSuspendableBeansのSuspendableBean.suspendメソッドを呼び出します。
Oracle Event ProcessingはMBeanを登録解除します。
Oracle Event Processingは、すべてのDisposableBeansのDisposableBean.disposeメソッドを呼び出します。
Oracle Event Processingでアプリケーション・バンドルがOSGIからアンインストールされます。
アプリケーションの更新
これは、最初にアプリケーションをアンインストールしてから再びインストールするのと同等です。
このリストのユーザー・アクションを参照してください。
ストリームおよびリレーション・ソースおよびシンクのメソッドの呼出し
ストリーム、リレーション・ソースまたはシンクでは、アプリケーション・ライフサイクルでこれらのフェーズが完了するまでコンポーネントはイベントを受信する準備ができない場合があるので、ライフサイクル・コールバックからメソッドを呼び出すべきではありません。
たとえば、afterConfigurationActiveまたはbeforeResumeなど、ライフサイクル・コールバックからStreamSenderメソッドのsendInsertEventは呼び出しません。
RunnableBeanを実装するBeanの実行メソッドから、ストリーム、リレーション・ソースまたはシンクでメソッドを呼び出すことができます。
詳細は、アプリケーションのインストールの説明を参照してください。16.2項「ソースおよびシンクでのイベントの処理」も参照してください。
