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