自動判定装置、処理型判定方法および処理型判定プログラム
【課題】バッチ処理かリアルタイム処理かの違いを意識することなく容易にプログラムを作成することを課題とする。
【解決手段】自動判定装置は、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部を有する。自動判定装置は、少なくとも記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける。そして、自動判定装置は、受け付けられたフロー定義に記述される処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から処理型が定義された要素を検索する。その後、自動判定装置は、検索された要素の処理型を未定義のコンポーネントの処理型と判定する。
【解決手段】自動判定装置は、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部を有する。自動判定装置は、少なくとも記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける。そして、自動判定装置は、受け付けられたフロー定義に記述される処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から処理型が定義された要素を検索する。その後、自動判定装置は、検索された要素の処理型を未定義のコンポーネントの処理型と判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、自動判定装置、処理型判定方法および処理型判定プログラムに関する。
【背景技術】
【０００２】
従来、大量のデータを分類や分析するといったバッチ処理と、イベント発生に応じて逐次に処理するリアルタイム処理とは、それぞれの特性に応じて別々に発展してきた。例えば、バッチ処理とリアルタイム処理とでは、蓄積ファイルデータやキューイングデータなどのように利用可能なデータの性質の違いがある。
【０００３】
また、蓄積ファイルを入力として蓄積ファイル内のデータ処理を一括で行いデータがなくなれば処理を終了するか、システムに常駐してキューにイベントデータが登録されるたびに処理の実行を繰り返すかという処理形態の違いもある。また、処理の違いに応じて使用するＯＳ（Operating System）やミドルウェアの機能の違いなどもある。このように、バッチ処理とリアルタイム処理とでは、処理を実行する環境や要求される性能等の様々な違いがあり、各特性に応じたパフォーマンスが最大限有効になるように、別々にコンポーネントが開発されて別々の実装として発展している。
【０００４】
例えば、バッチ処理用のコンポーネントと、リアルタイム処理用のコンポーネントとをそれぞれ用意しておき、ユーザによって処理型が指定されたフロー定義に基づいて、該当するコンポーネントを実行する技術が知られている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１０７４７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来の技術では、コンポーネントを用いることでプログラム作成が容易になったとはいえ、プログラムに精通していないユーザにとっては依然として難しく、容易にプログラムを作成できないという問題がある。
【０００７】
例えば、コンポーネントを利用してプログラムを作成する場合、作成対象の処理がバッチ処理かリアルタイム処理かを正しく理解した上でなければ、フロー定義を作成することができない。したがって、プログラムに精通していないユーザにとっては、フロー定義の作成そのものが難しい。
【０００８】
一例を挙げると、システムやプログラムに精通していない分析者が、システムで処理されるデータに対して所望の分析を実行するプログラムを作成する場合を想定する。この場合、分析者は、どのような分析処理を実行させるのかを決定することはできても、バッチ処理かリアルタイム処理かの違いを意識した上で、決定した処理をどのように実行させるのかまで決定するのは難しく、正しいフロー定義を生成するのは難しい。
【０００９】
また、バッチ処理での分析に用いるデータと、分析結果の反映対象のリアルタイム処理に反映されるデータとが、必要なデータや項目といった条件が同じ場合を想定する。この場合でも、バッチ処理とリアルタイム処理それぞれのフロー定義手法に則り、それぞれコンポーネントを用意し、正しく組み合わせてそれぞれに異なるフロー定義を行わなければ正常に動作可能なプログラムが作成できない。
【００１０】
また、分析者が、システムやプログラムに精通する開発者に所望の処理を実行するプログラムの生成を依頼することも考えられる。しかし、分析者と開発者とは、部署が異なったり会社が異なったりすることが一般的である。このため、分析者が、開発者にプログラム作成依頼を行って所望のプログラムを得るまでに、関係各所との調整、発注のための書類作成、発注処理、開発者の作業などいくつかのステップを要するので時間がかかる。したがって、経営に関係する情報など早急な対応が要求される場合には、この方法を用いることは現実的ではない。また、ビジネスのスピードが速い近年では、この手法を用いる機会も少なく、利用価値が高いものでもない。
【００１１】
開示の技術は、上記に鑑みてなされたものであって、バッチ処理かリアルタイム処理かの違いを意識することなく容易にプログラムを作成することができる自動判定装置、処理型判定方法および処理型判定プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本願の開示する自動判定装置、処理型判定方法および処理型判定プログラムは、一つの態様において、以下の処理部を有する。本願の開示する自動判定装置は、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、前記バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部を有する。本願の開示する自動判定装置は、少なくとも前記記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける受付部を有する。本願の開示する自動判定装置は、前記受付部によって受け付けられたフロー定義に記述される前記処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から前記処理型が定義された要素を検索する。そして、本願の開示する自動判定装置は、検索された要素の処理型を前記未定義のコンポーネントの処理型と判定する。
【発明の効果】
【００１３】
本願の開示する自動判定装置、処理型判定方法および処理型判定プログラムの一つの態様によれば、バッチ処理かリアルタイム処理かの違いを意識することなく容易にプログラムを作成することができるという効果を奏する。
【図面の簡単な説明】
【００１４】
【図１】図１は、システムの全体構成例を示す図である。
【図２】図２は、複数の処理方式に対応したコンポーネントの例を示す図である。
【図３】図３は、自動判定装置の構成を示す機能ブロック図である。
【図４】図４は、テンプレート記憶部に記憶されるHiveクエリのテンプレート例を示す図である。
【図５】図５は、テンプレート記憶部に記憶されるEPLのテンプレート例を示す図である。
【図６】図６は、テンプレート記憶部に記憶されるEsperによる絞込み処理のテンプレート例を示す図である。
【図７】図７は、コンポーネントリポジトリ記憶部に記憶される処理管理情報の例を示す図である。
【図８】図８は、コンポーネントリポジトリ記憶部に記憶されるコンポーネント管理情報の例を示す図である。
【図９】図９は、フロー定義編集画面の例を示す図である。
【図１０】図１０は、フロー定義の保存形式の例を示す図である。
【図１１】図１１は、処理型の判定例を示す図である。
【図１２】図１２は、処理型の判定例を示す図である。
【図１３】図１３は、Hiveクエリテンプレートの変換例を示す図である。
【図１４】図１４は、EPLクエリテンプレートの変換例を示す図である。
【図１５】図１５は、蓄積データを絞り込む実行用アセンブリの例を示す図である。
【図１６】図１６は、イベントデータを絞り込む実行用アセンブリの例を示す図である。
【図１７】図１７は、処理実行装置の構成を示す機能ブロック図である。
【図１８】図１８は、イベント記憶部に記憶される情報の例を示す図である。
【図１９】図１９は、各クラス間のインタフェースの定義例を示す図である。
【図２０】図２０は、Hiveクエリを実行するコンポーネントの実装例を示す図である。
【図２１】図２１は、EPLクエリを実行するコンポーネントの実装例を示す図である。
【図２２】図２２は、イベント処理結果の例を示す図である。
【図２３】図２３は、アセンブリ作成までの流れを説明する図である。
【図２４】図２４は、イベント処理システムによる処理の流れを示すフローチャートである。
【図２５】図２５は、処理型判定処理の流れを示すフローチャートである。
【図２６】図２６は、処理型判定の結果によって処理型が異なった例１を示す図である。
【図２７】図２７は、自動判定装置が生成する、蓄積データのイベント送信を実行する実行用アセンブリの例を示す図である。
【図２８】図２８は、自動判定装置が生成する、蓄積データの絞込みを実行する実行用アセンブリの例を示す図である。
【図２９】図２９は、処理型判定の結果によって処理型が異なった例２を示す図である。
【図３０】図３０は、自動判定装置が生成する、データの蓄積および通知を実行する実行用アセンブリの例を示す図である。
【図３１】図３１は、処理実行装置が記憶する、蓄積データを送信するコンポーネントの実装例を示す図である。
【図３２】図３２は、処理実行装置が記憶する、イベントデータを蓄積するコンポーネントの実装例を示す図である。
【図３３】図３３は、処理型判定プログラムを実行するコンピュータのハードウェア構成の例を示す図である。
【発明を実施するための形態】
【００１５】
以下に、本願の開示する自動判定装置、処理型判定方法および処理型判定プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例１】
【００１６】
実施例１では、開示する自動判定装置を含むシステムの全体構成、システムが有する各装置の構成、処理の流れを説明する。なお、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【００１７】
［全体構成］
図１は、システムの全体構成例を示す図である。図１に示すように、このシステムは、クライアント装置１と、イベント通知装置５と、イベント処理システム１０とを有する。また、クライアント装置１とイベント処理システム１０とがネットワークなどを介して接続され、同様に、イベント通知装置５とイベント処理システム１０とがネットワークなどを介して接続される。
【００１８】
クライアント装置１は、プログラム作成者が使用するコンピュータであり、Ｗｅｂブラウザを用いてイベント処理システム１０の自動判定装置２０にアクセスする。そして、クライアント装置１は、自動判定装置２０から受信したＷｅｂ画面上で、入出力データおよびコンポーネントを要素とするフロー定義の作成や編集を実行する。なお、このクライアント装置１は、パーソナルコンピュータに限ったものではなく、例えばスマートフォンやＰＤＡ（Personal Digital Assistant）端末も使用することができる。
【００１９】
イベント通知装置５は、図示しないサーバ等から継続的にイベントを受信して、継続的にイベント処理システム１０に通知するサーバ装置である。一例を挙げると、イベント通知装置５は、各駅の改札口の出入り情報を管理する管理サーバから、出入り情報をイベントとして受信してイベント処理システム１０に通知する。なお、ここでは、駅の出入り情報を例にしたが、これに限定されるものではなく、例えばシステム監視ログなど様々な情報を用いることができる。
【００２０】
イベント処理システム１０は、自動判定装置２０と処理実行装置４０とを有し、クライアント装置１から受け付けたフロー定義に基づいてプログラムを自動生成し、生成したプログラムを実行して所望の結果を得るシステムである。ここでは、自動判定装置２０と処理実行装置４０とが別々の筐体で実現される場合で説明するが、これに限定されるものではなく、１つの筐体で実現することもでき、３つ以上の筐体に機能を分割してもよい。
【００２１】
自動判定装置２０は、クライアント装置１からフロー定義を受け付けてプログラムを自動生成し、生成したプログラムを処理実行装置４０に出力するサーバ装置である。ここで、自動判定装置２０が有するコンポーネントについて説明する。図２は、複数の処理方式に対応したコンポーネントの例を示す図である。図２に示すように、ここでは、イベントデータを記憶するデータベースから、フィールドＡが値ａのデータを絞り込むコンポーネントを例にしている。そして、蓄積されたイベントデータは、例えばHadoop上に格納され、Hiveでアクセス可能とした場合、Hiveでデータの絞り込みを行う。また、リアルタイムなイベントデータを絞り込む場合は、ここではJMSキューに格納されたイベントデータを順次Esperエンジンを使って次のキューにデータを受け渡すことを想定する。
【００２２】
このような自動判定装置２０は、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する。そして、自動判定装置２０は、少なくとも記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける。その後、自動判定装置２０は、受け付けられたフロー定義に記述される処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から処理型が定義された要素を検索する。そして、自動判定装置２０は、検索された要素の処理型を未定義のコンポーネントの処理型と判定する。このようにすることで、自動判定装置２０は、どのような処理を実行したいかを示したフロー定義からプログラムを自動生成し、生成したプログラムを処理実行装置４０に出力する。
【００２３】
処理実行装置４０は、自動判定装置２０から入力されたプログラムを実行して所望の結果を取得し、取得した結果をクライアント装置１に応答するサーバ装置である。例えば、処理実行装置４０は、イベントデータを所定数または所定時間蓄積した後に、蓄積したイベントデータ（以下、蓄積データと表記する）から所望のデータを絞り込んで抽出するバッチ処理を実行する。また、処理実行装置４０は、自動判定装置２０からイベントデータを受信するたびに、当該イベントデータをフィルタリングして絞り込むリアルタイム処理を実行する。
【００２４】
このように、自動判定装置２０は、バッチ処理かリアルタイム処理かを意識することなく作成したフロー定義を受信した場合でも、当該フロー定義で定義されるコンポーネントの処理型を自動で判定することができる。この結果、プログラムやシステムに精通していないユーザであっても、バッチ処理かリアルタイム処理かの違いを意識することなく容易にプログラムを作成することができる。
【００２５】
［装置の構成］
次に、図１に示した自動判定装置２０と処理実行装置４０の構成について説明する。なお、図１に示したクライアント装置１は一般的なパーソナルコンピュータと同様の構成を有し、イベント通知装置５も一般的なイベント通知処理と同様の構成を有するので、詳細な説明は省略する。
【００２６】
（自動判定装置の構成）
図３は、自動判定装置の構成を示す機能ブロック図である。図３に示すように、自動判定装置２０は、通信制御Ｉ／Ｆ部２１と、作業領域２２ａと、テンプレート記憶部２２ｂと、コンポーネントリポジトリ記憶部２２ｃと、アセンブリ記憶部２２ｄと、制御部２５とを有する。なお、各記憶部は、例えば半導体メモリ素子やハードウェアなどの記憶装置である。制御部２５は、例えばＣＰＵ（Central Processing Unit）などの電子回路やＦＰＧＡ（Field-Programmable Gate Array）などの集積回路である。
【００２７】
通信制御Ｉ／Ｆ部２１は、例えばＮＩＣ（Network Interface Card）などのように、他の装置と通信を制御するインタフェースである。例えば、通信制御Ｉ／Ｆ部２１は、クライアント装置１からＷｅｂアクセスを受け付けると、クライアント装置１と自動判定装置２０との間にコネクションを確立して、フロー定義を受け付ける。また、通信制御Ｉ／Ｆ部２１は、制御部２５によって作成されたプログラムを処理実行装置４０に出力する。
【００２８】
作業領域２２ａは、制御部２５の各処理部が処理を実行する際に、データ等の処理途中結果を一時的に格納する領域である。
【００２９】
テンプレート記憶部２２ｂは、蓄積データに対して絞り込みを実行するクエリのテンプレートやイベントデータに対して絞り込みを実行するクエリのテンプレートを記憶する。また、テンプレート記憶部２２ｂは、クエリを埋め込む各SCA（Service Component Architecture）テンプレートも記憶する。なお、テンプレート記憶部２２ｂは、各テンプレートに識別子やテンプレート名を付与し、テンプレートと識別子等を対応付けて格納することで各テンプレートを区別する。
【００３０】
図４は、テンプレート記憶部に記憶されるHiveクエリのテンプレート例を示す図である。図４に示すように、このHiveクエリのテンプレートは、$fieldで示す特定のフィールド（カラム）が$equalsで示す特定の値であるデータを$input1で示す入力テーブルから抽出して$output1で示す出力テーブルに書き込むことが記述されたクエリである。図５は、テンプレート記憶部に記憶されるEPLのテンプレート例を示す図である。図５に示すように、このEPLのテンプレートは、$fieldで示す特定のフィールドが$equalsで示す特定の値であるデータを$input1で示すキューから抽出することが記述されたクエリである。
【００３１】
また、図６は、テンプレート記憶部に記憶されるEsperによる絞込み処理のテンプレート例を示す図である。この図６は、SCA定義による実行可能なアセンブリを生成するためのテンプレートである。図６に示すように、このテンプレートは、入出力データ名をキュー名として利用し、テンプレートで生成したクエリを属性として埋め込み、コンポーネント１つを含むコンポジットとして生成する。
【００３２】
コンポーネントリポジトリ記憶部２２ｃは、フロー定義で定義された処理を管理する処理管理情報と、処理とコンポーネントと対応付けたコンポーネント管理情報とを記憶する。図７は、コンポーネントリポジトリ記憶部に記憶される処理管理情報の例を示す図である。図７に示すように、コンポーネントリポジトリ記憶部２２ｃは、処理管理情報として「ID、処理名、処理型」を対応付けて記憶する。ここで記憶される「ID」は、処理を識別する識別子であり、「処理名」は、フロー定義で定義される処理の名称であり、「処理型」は、処理名に格納される処理が実行可能な処理型を示す。
【００３３】
図７の場合、IDが「01」である処理名「値範囲指定」は、ストリーム処理または蓄積処理の両方が実行可能である、すなわち、リアルタイム処理またはバッチ処理が実行可能であることを示す。同様に、IDが「02」である処理名「値指定」は、ストリーム処理または蓄積処理の両方が実行可能であることを示し、IDが「03」である処理名「値集計」は、蓄積処理のみが実行可能であることを示す。
【００３４】
図８は、コンポーネントリポジトリ記憶部に記憶されるコンポーネント管理情報の例を示す図である。図８に示すように、コンポーネントリポジトリ記憶部２２ｃは、コンポーネント管理情報として「ID、処理ID、処理型、コンポーネント名、クエリテンプレート、SCAテンプレート」を対応付けて記憶する。ここで記憶される「ID」は、コンポーネントを識別する識別子であり、「処理ID」は、処理管理情報のコンポーネントに対応する処理のIDであり、「コンポーネント名」は、コンポーネントの名称である。「クエリテンプレート」は、SCAテンプレートに埋め込むクエリのテンプレートのファイル名などの識別子や名称であり、「SCAテンプレート」は、クエリを埋め込む対象のSCA定義が記述されたテンプレートのファイル名などの識別子や名称である。
【００３５】
図８を例にして具体例を説明する。ID「01」が割り与えられたコンポーネント名「StreamFilter」は、処理ID「01」の「値範囲指定」を「ストリーム処理」で実行するコンポーネントであり、SCAテンプレート「01-sca.vm」にクエリテンプレート「01-query.vm」を用いて生成したクエリを埋め込んで生成されることを示す。同様に、ID「02」が割り与えられたコンポーネント名「AccumulateFilter」は、処理ID「01」の「値範囲指定」を「蓄積処理」で実行するコンポーネントであり、SCAテンプレート「02-sca.vm」にクエリテンプレート「02-query.vm」を用いて生成したクエリを埋め込んで生成されることを示す。
【００３６】
アセンブリ記憶部２２ｄは、制御部２５によって生成された、SCAによる実行可能なアセンブリを記憶する。すなわち、アセンブリ記憶部２２ｄは、クライアント装置１によって生成されたフロー定義を実行するコンポーネントを組み合わせたアセンブリを記憶する。
【００３７】
制御部２５は、フロー定義受付部２６と処理型判定部２７とアセンブリ自動生成部２８とを有し、これらによって、クライアント装置１から受け付けたフロー定義に基づいて実行可能なアセンブリを生成する処理部である。
【００３８】
フロー定義受付部２６は、少なくともコンポーネントリポジトリ記憶部２２ｃ等に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける処理部である。例えば、フロー定義受付部２６は、クライアント装置１からフロー定義を作成または編集を実行するＷｅｂアクセスを受け付けた場合に、通信制御Ｉ／Ｆ部２１を介して、フロー定義編集画面をクライアント装置１に送信する。そして、フロー定義受付部２６は、フロー定義編集画面でフロー定義の作成や編集を受け付けて、受け付けた情報を作業領域２２ａに格納する。
【００３９】
図９は、フロー定義編集画面の例を示す図である。フロー定義受付部２６は、図９に示すフロー定義編集画面をクライアント装置１に送信して、フロー定義の編集作業を受け付ける。クライアント装置１は、図９に示すフロー定義編集画面の画面左にある「クラスタＩＤ追加」や「距離計算」などの処理（プロセス）をドラックアンドドロップで中央に移動させてフロー定義を作成する。
【００４０】
このフロー定義では、ドラム缶や四角で表すデータを入力として、丸（アクティビティ）で表す処理を行い、データを出力する。最初の入力となるデータについては、処理型を蓄積型（バッチ処理型）かストリーム型（リアルタイム処理型）かのどちらかとして指定し、その他の処理やデータについては、必要であれば処理型を指定する。なお、ここで作成されるフロー定義としては、例えばDFD（Data Flow Diagram）などがある。また、図９の例では、キュー１からイベントデータを読み出して、値範囲指定のフィルター処理を実行し、実行した結果をキュー２に出力するフロー定義が図示されている。
【００４１】
そして、フロー定義受付部２６は、クライアント装置１によるフロー定義作成が終了した場合、作成されたフロー定義を例えばXML（Extensible Markup Language）形式などに変換して作業領域２２ａに格納する。図１０は、フロー定義の保存形式の例を示す図である。図１０に示すように、データ（data）と処理（process）についてはbehavior属性として処理型を保存しており、処理に対応するXMLタグからは、入出力となるデータに対応するIDが属性として保存される。なお、ここでは、XML形式で保存する例で説明したが、保存形式はXMLに限定されるものではなく、任意の保存形式を用いることができる。
【００４２】
図３に戻り、処理型判定部２７は、フロー定義受付部２６によってフロー定義が作業領域２２ａに格納されたことを検出する。すると、処理型判定部２７は、フロー定義受付部２６によって受け付けられたフロー定義に記述される処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から処理型が定義された要素を検索する。そして、処理型判定部２７は、検索された要素の処理型を未定義のコンポーネントの処理型と判定する処理部である。また、処理型判定部２７は、判定した結果をアセンブリ自動生成部２８に出力する。
【００４３】
ここで、図１１と図１２を用いて処理型判定の例を説明する。図１１と図１２は、処理型の判定例を示す図である。図１１は、フロー定義受付部２６によって受け付けられたフロー定義をDFDで表した図である。すなわち、クライアント装置１は、鉄道イベントを記憶するデータベースの「蓄積データ」を入力データとして、処理型が「未判定」の「駅での絞り込み」処理を実行し、処理型が「未判定」の「鉄道イベント」を出力するフロー定義を作成したとする。この場合、処理型判定部２７は、処理型判定対象が「駅での絞り込み」処理であり、当該処理の後続の「鉄道イベント」が「未判定」であり、当該処理の前方の入力データが「蓄積データ」であることを特定する。そして、処理型判定部２７は、「駅での絞り込み」処理および当該処理の後続の「鉄道イベント」各々の処理型を「蓄積型」すなわち「バッチ処理型」と判定する。
【００４４】
同様に、図１２に示した図は、フロー定義受付部２６によって受け付けられたフロー定義をDFDで表した図である。すなわち、クライアント装置１は、鉄道イベントを記憶するキューの「イベントデータ」を入力データとして、処理型が「未判定」の「駅での絞り込み」処理を実行し、処理型が「未判定」の「鉄道イベント」を出力するフロー定義を作成したとする。この場合、処理型判定部２７は、処理型判定対象が「駅での絞り込み」処理であり、当該処理の後続の「鉄道イベント」が「未判定」であり、当該処理の前方の入力データが「イベントデータ」であることを特定する。そして、処理型判定部２７は、「駅での絞り込み」処理および当該処理の後続の「鉄道イベント」各々の処理型を「イベント処理型」すなわち「リアルタイム処理型」と判定する。
【００４５】
具体的な判定の一例として、図１０に示したフロー定義がXML形式で作業領域２２ａに格納された場合を例にして説明する。この場合、処理型判定部２７は、XML形式で格納されるフロー定義から、behavior属性がDefineLaterのprocessタグを検索する。そして、処理型判定部２７は、該当するprocessタグが検索できた場合には、処理型が未定義のコンポーネントが存在すると判定する。
【００４６】
続いて、処理型判定部２７は、検索したprocessの直後のデータの型として、当該processのoutputdataに対応するdataタグのbehavior属性を参照する。そして、処理型判定部２７は、参照したdataタグのbehavior属性がaccumulateであれば、当該processの処理型を「蓄積処理型」すなわち「バッチ処理型」と特定する。また、処理型判定部２７は、参照したdataタグのbehavior属性がstreamであれば、当該processの処理型を「ストリーム処理型」すなわち「リアルタイム処理型」と特定する。一方、処理型判定部２７は、参照したdataタグのbehavior属性がdefinelaterであれば、processのinputdataに対応するdataタグのbehavior属性を参照して、上述した処理と同様の処理を実行する。
【００４７】
また、処理型判定部２７は、検索したprocessの後続のdataやprocessのbehavior属性が全部definelaterである場合に、検索したprocessの直前のdataについて同様の処理を実行する。つまり、処理型判定部２７は、処理型判定対象のprocessの後続の要素から処理型が特定できなかった場合に、処理型判定対象のprocessの直前の要素から前方に向かって順に処理型を参照する。そして、処理型判定部２７は、definelater以外を検索した場合に、検索されたbehavior属性を、処理型判定対象のprocessの処理型と判定する。なお、ここでは、判定対象のprocessの後続の要素から順に検索する場合を例にしたが、これに限定されるものではなく、例えば判定対象のprocessの前の要素から順に検索するなど、検索順序は任意に設定変更することができる。
【００４８】
図３に戻り、アセンブリ自動生成部２８は、テンプレート変換部２８ａと生成部２８ｂとを有し、特定された処理型の処理を実行するクエリをコンポーネントに挿入する。そして、アセンブリ自動生成部２８は、フロー定義受付部２６によって受け付けられたフロー定義で定義される処理を実行するアセンブリを生成する処理部である。
【００４９】
このアセンブリ自動生成部２８は、処理型判定部２７によって処理型が判定されたコンポーネント、言い換えると、処理型が特定された処理の名称をDFDまたはXMLから特定する。そして、アセンブリ自動生成部２８は、例えば図９の「値範囲指定」のように、特定した処理の名称に対応する処理IDをコンポーネントリポジトリ記憶部２２ｃから特定する。続いて、アセンブリ自動生成部２８は、特定した処理IDと処理型判定部２７から通知された処理型とに基づいて、SCAテンプレートの識別子とクエリテンプレートの識別子とを特定する。その後、アセンブリ自動生成部２８は、特定したクエリテンプレートの識別子をテンプレート変換部２８ａに通知し、SCAテンプレートの識別子を生成部２８ｂに通知する。
【００５０】
例えば、処理型が特定された処理の名称が「値範囲指定」であり、特定された処理型が「蓄積処理型」である場合を例にして説明する。この場合、アセンブリ自動生成部２８は、図７の記憶部を参照して「値範囲指定」に対応する処理IDが「01」であることを特定する。続いて、アセンブリ自動生成部２８は、図８の記憶部を参照し、処理ID「01」と処理型「蓄積」との組み合わせが記憶されるレコードがID「02」のレコードであることを特定する。そして、アセンブリ自動生成部２８は、特定したレコードのクエリテンプレートに格納される「02-query.vm」をテンプレート変換部２８ａに通知し、SCAテンプレート格納される「02-sca.vm」を生成部２８ｂに通知する。
【００５１】
テンプレート変換部２８ａは、フロー定義受付部２６によって受け付けられたフロー定義にしたがって、アセンブリ自動生成部２８から通知されたクエリテンプレートを変換する処理部である。そして、テンプレート変換部２８ａは、変換したクエリを生成部２８ｂに出力する。ここで、図１３と図１４を用いてクエリテンプレートの変換例を説明する。
【００５２】
図１３は、Hiveクエリテンプレートの変換例を示す図である。図１３に示すように、この例では、フロー定義として、データベースの「蓄積データ」を入力データ「data1」として、「駅での絞り込み」処理を実行し、出力データを「data2」としてデータベースに格納することが定義されている。すなわち、図１３に示した全要素はいずれも「バッチ処理型」に該当する。また、この「駅での絞り込み」処理に、プロパティとして、「Field＝station、value＝1」が与えられたとする。その場合、テンプレート変換部２８ａは、図１３に示すように、図４に示したHiveクエリのテンプレートに対して、「field」を「station」、「equals」を「1」、「input」を「data1」、「output」を「data2」に変換したクエリを生成する。
【００５３】
図１４は、EPLクエリテンプレートの変換例を示す図である。図１４に示すように、この例では、フロー定義として、キューの「イベントデータ」を入力データ「data1」とし、「駅での絞り込み」処理を実行して、出力データを「data2」としてキューに格納することが定義されている。すなわち、図１４に示した全要素はいずれも「リアルタイム処理型」に該当する。また、この「駅での絞り込み」処理に、プロパティとして、「Field＝station、value＝1」が与えられたとする。この場合、テンプレート変換部２８ａは、図１４に示すように、図５に示したEPLクエリのテンプレートに対して、「field」を「station」、「equals」を「1」、「input」を「data1」に変換したクエリを生成する。
【００５４】
生成部２８ｂは、アセンブリ自動生成部２８から通知されたSCAテンプレートに、テンプレート変換部２８ａから通知されたクエリを埋め込んで、フロー定義受付部２６によって受け付けられたフロー定義で定義される処理を実行するアセンブリを生成する。そして、生成部２８ｂは、生成したアセンブリをアセンブリ記憶部２２ｄに格納し、また、処理実行装置４０に送信する。
【００５５】
例えば、アセンブリ自動生成部２８から通知されたSCAテンプレートが「01-sca.vm」であり、テンプレート変換部２８ａから通知されたクエリがテンプレート「01-query.vm」を変換した、図１３に示すクエリであるとする。この場合、生成部２８ｂは、「01-sca.vm」に該当するテンプレートをテンプレート記憶部２２ｂから読み出し、読み出したSCAテンプレート「01-sca.vm」に図１３に示したクエリを埋め込んで、蓄積データを絞り込む実行用アセンブリを生成する。図１５は、蓄積データを絞り込む実行用アセンブリの例を示す図である。図１５に示すコンポーネントには、アセンブリを実行するJava（登録商標）クラスとして「example.ExecuteHiveUpdate」が定義される。また、このコンポーネントには、実行するクエリとして、図１３に示した変換後の「HiveQL」クエリが「sca:property name＝”HiveQL”」タグの値に埋め込まれる。ここで用いられているJava（登録商標）クラスは例えば図２０のようになる。
【００５６】
また、アセンブリ自動生成部２８から通知されたSCAテンプレートが「02-sca.vm」であり、テンプレート変換部２８ａから通知されたクエリがテンプレート「02-query.vm」を変換した、図１４に示すクエリであるとする。この場合、生成部２８ｂは、「02-sca.vm」に該当する図６に示したテンプレートをテンプレート記憶部２２ｂから読み出す。そして、生成部２８ｂは、読み出したSCAテンプレート「02-sca.vm」に、図１４に示したクエリを埋め込んで、イベントデータを絞り込む実行用アセンブリを生成する。図１６は、イベントデータを絞り込む実行用アセンブリの例を示す図である。図１６に示すコンポーネントには、アセンブリを実行するJava（登録商標）クラスとして「example.EsperProcessor」を定義される。また、このコンポーネントには、実行するクエリとして、図１４に示した変換後の「EPL」クエリが「sca:property name＝”EPL”」タグの値に埋め込まれる。ここで用いられているJava（登録商標）クラスは例えば図２１のようになる。
【００５７】
（処理実行装置の構成）
次に、図１に示した処理実行装置４０の構成について説明する。図１７は、処理実行装置の構成を示す機能ブロック図である。図１７に示すように、処理実行装置４０は、通信制御Ｉ／Ｆ部４１と、イベント記憶部４２ａと、アセンブリ記憶部４２ｂと、実行プログラム記憶部４２ｃと、制御部４５とを有する。なお、各記憶部は、例えば半導体メモリ素子やハードウェアなどの記憶装置である。制御部４５は、例えばＣＰＵなどの電子回路やＦＰＧＡなどの集積回路である。これら以外にも、例えば、制御部２５の各処理部が処理を実行する際に、データ等の処理途中結果を一時的に格納する作業領域等も有していてもよい。
【００５８】
通信制御Ｉ／Ｆ部４１は、例えばＮＩＣなどのように、他の装置と通信を制御するインタフェースである。例えば、通信制御Ｉ／Ｆ部４１は、自動判定装置２０から実行可能なアセンブリを受信し、また、イベント通知装置５からイベントデータを受信する。また、通信制御Ｉ／Ｆ部４１は、イベントデータに対して実行した処理の結果をクライアント装置１に送信する。
【００５９】
イベント記憶部４２ａは、イベント通知装置５から受信したイベントデータを記憶する。図１８は、イベント記憶部に記憶される情報の例を示す図である。図１８に示すように、イベント記憶部４２ａは、「発生時刻、ID、Station、Type」を対応付けて記憶する。ここで記憶される「発生時刻」は、イベントが発生した日であり、「ID」は、イベントを識別する識別子であり、「Station」は、イベントが発生した駅を識別する識別子であり、「Type」は、発生したイベントの内容を示す情報である。
【００６０】
図１８の場合、「2011/4/19」に発生した「ID」が「001」のイベントは、「Station」が「1」が割り当てられた駅で発生した「改札に入る」イベントであることを示す。また、「2011/4/19」に発生した「ID」が「003」のイベントは、「Station」が「2」が割り当てられた駅で発生した「改札から出る」イベントであることを示す。
【００６１】
アセンブリ記憶部４２ｂは、自動判定装置２０から受信した実行可能なアセンブリを記憶する。例えば、アセンブリ記憶部４２ｂは、図１５に示した蓄積データを絞り込む実行用アセンブリや図１６に示したイベントデータを絞り込む実行用アセンブリを記憶する。
【００６２】
実行プログラム記憶部４２ｃは、アセンブリ記憶部４２ｂに格納される実行可能なアセンブリを実行するプログラムを記憶する。例えば、実行プログラム記憶部４２ｃは、自動判定装置２０によって生成されたアセンブリを呼び出して実行するJava（登録商標）プログラムを記憶する。
【００６３】
例を挙げると、実行プログラム記憶部４２ｃは、図１９に示した、各コンポーネントの実装で利用している共通の入出力インタフェースを記述したプログラムを記憶する。図１９は、各クラス間のインタフェースの定義例を示す図である。図１９に示すように、インタフェースとして「MapEventReceiver」が定義されており、コンポーネントを呼び出す側がインタフェースを参照する形で、複数のコンポーネントを連携させる。
【００６４】
また、実行プログラム記憶部４２ｃは、図２０に示したプログラムを記憶する。図２０は、Hiveクエリを実行するコンポーネントの実装例を示す図である。図２０に示したコンポーネントは、「boolean res = hiveStatement.execute（hiveQL）」が定義され、図１５のアセンブリに埋め込んだHiveクエリを実行する。
【００６５】
また、実行プログラム記憶部４２ｃは、図２１に示したプログラムを記憶する。図２１は、EPLクエリを実行するコンポーネントの実装例を示す図である。図２１に示したコンポーネントは、「EPStatement statement = epSrevice.getEPAdministrator().createEPL(epl)」が定義され、図１６のアセンブリに埋め込んだEPLクエリを実行する。
【００６６】
制御部４５は、イベントデータ受信部４５ａとアセンブリ受信部４５ｂとイベント処理部４５ｃとを有し、これらによって、クライアント装置１からフロー定義を用いて生成した処理を実行し、その結果をクライアント装置１に応答する処理部である。
【００６７】
イベントデータ受信部４５ａは、イベント通知装置５からイベントデータを受信してイベント記憶部４２ａに格納する処理部である。イベントデータを受信する契機としては、例えばイベント通知装置５から送信されるのを待つだけでなく、イベントデータ受信部４５ａが定期的にイベント通知装置５から取得してもよい。
【００６８】
アセンブリ受信部４５ｂは、自動判定装置２０から実行可能なアセンブリを受信してアセンブリ記憶部４２ｂに格納する処理部である。すなわち、アセンブリ受信部４５ｂは、図１５や図１６に示した、SCAで定義された実行可能なアセンブリを受信して格納する。
【００６９】
イベント処理部４５ｃは、実行プログラム記憶部４２ｃに記憶されるプログラムを実行して、アセンブリ記憶部４２ｂに記憶されアセンブリを実行し、所望の結果を取得して、クライアント装置１に応答する処理部である。例えば、イベント処理部４５ｃが、図２０に示したコンポーネントで実行して、図１３に示したHiveクエリが埋め込まれた図１５のアセンブリを実行したとする。すなわち、図１８に示した蓄積データから「station=1」のイベントデータを抽出する例を説明する。
【００７０】
この場合、イベント処理部４５ｃは、「2011/4/19、001、1、Enter」、「2011/4/19、002、1、Enter」、「2011/4/19、003、2、Exit」、「2011/4/19、004、2、Enter」から「station」が「1」のイベントデータを絞り込む。その結果、イベント処理部４５ｃは、図２２に示すように、「2011/4/19、001、1、Enter」、「2011/4/19、002、1、Enter」を抽出する。図２２は、イベント処理結果の例を示す図である。そして、イベント処理部４５ｃは、抽出したイベントデータをイベント処理結果、すなわちクライアントがフロー定義によって得ようとした結果としてクライアント装置１に送信する。
【００７１】
なお、イベント処理を実行するタイミングは、実行可能なアセンブリがアセンブリ記憶部４２ｂに格納されたタイミングや、自動判定装置２０やクライアント装置１などから処理開始指示を受信した場合など任意のタイミングで実行することができる。また、イベント処理部４５ｃは、様々な手法を用いて、実行プログラム記憶部４２ｃに記憶されるプログラムから、実行すべきプログラムを特定することができる。例えば、イベント処理部４５ｃは、アセンブリ記憶部４２ｂに記憶されたアセンブリに埋め込まれたクエリから特定することもでき、自動判定装置２０等から実行対象の処理やプログラムを特定する情報を受信してもよい。
【００７２】
［処理の流れ］
次に、図１に示したイベント処理システムが実行する処理の流れを説明する。ここでは、アセンブリ生成までの処理とフローチャートについて説明する。
【００７３】
（アセンブリ生成までの処理の説明）
図２３は、アセンブリ作成までの流れを説明する図である。図２３に示すように、自動判定装置２０は、図４から図６に示したクエリテンプレートとSCAテンプレートとをテンプレート記憶部２２ｂに記憶する。そして、自動判定装置２０は、フロー定義受付部２６によって受け付けられたフロー定義とクエリテンプレートとから、図１３や図１４に示した実行可能なクエリを生成する。
【００７４】
その後、自動判定装置２０は、図６などに示したSCAテンプレートに、生成した実行可能なクエリを埋め込み、図１５や図１６に示す実行可能なSCAコンポーネント定義を生成する。また、フロー定義が複数の処理で構成されている場合には、各処理ごとに生成したSCAコンポーネントを組み合わせて、実行可能なアセンブリであるSCAコンポジット定義を生成する。
【００７５】
自動判定装置２０は、このように作成したアセンブリであるSCAコンポジット定義を処理実行装置４０が稼動させるSCAのエンジンに渡し、処理実行装置４０が実行する。例えばApache Tuscanyであれば、Java（登録商標）アプリケーションから「import org.apache.tuscany.sca.host.embedded.SCADomain;SCADomain.newInstance("SCA定義のファイル名");」として実行される。
【００７６】
（フローチャート）
図２４は、イベント処理システムによる処理の流れを示すフローチャートである。図２４に示すように、自動判定装置２０のフロー定義受付部２６がクライアント装置１からフロー定義を受け付けると（Ｓ１０１肯定）、処理型判定部２７は、フロー定義内に処理型が未定義の処理またはデータが存在するか否かを判定する（Ｓ１０２）。
【００７７】
そして、処理型判定部２７は、処理型が未定義の処理またはデータが存在する場合（Ｓ１０２肯定）、処理型判定処理を実行する（Ｓ１０３）。なお、処理型判定部２７は、フロー定義内に存在する、処理型が未定義の処理またはデータの処理型が判定されるまで、処理型判定処理を実行する。
【００７８】
その後、処理型判定部２７によって処理型が判定されると（Ｓ１０２否定）、テンプレート変換部２８ａは、コンポーネントリポジトリ記憶部２２ｃを参照し、フロー定義内の処理に該当するクエリテンプレートから実行可能なクエリを生成する（Ｓ１０４）。
【００７９】
続いて、生成部２８ｂは、コンポーネントリポジトリ記憶部２２ｃを参照して、生成された実行可能なクエリを埋め込むSCAテンプレートを特定し、特定したSCAテンプレートに実行可能なクエリを埋め込んで、SCAコンポーネント定義を生成する（Ｓ１０５）。すなわち、生成部２８ｂは、フロー定義によって定義された一連の処理を実行可能なアセンブリを生成する。そして、生成部２８ｂは、生成したアセンブリを処理実行装置４０に送信する（Ｓ１０６）。
【００８０】
処理実行装置４０のアセンブリ受信部４５ｂが自動判定装置２０からアセンブリを受信し、イベント処理部４５ｃは、受信されたアセンブリに対応するJava（登録商標）プログラム等を実行する（Ｓ１０７）。また、処理実行装置４０のイベント処理部４５ｃは、Java（登録商標）プログラムで呼び出されたアセンブリの実行によって得られた処理結果をクライアント装置１に送信する。
【００８１】
（処理型判定処理の流れ）
図２５は、処理型判定処理の流れを示すフローチャートである。この処理は、図２４に示したＳ１０３で実行される。なお、ここでは、一例として、後続の要素の処理型を優先して、処理型を判定する例を説明する。
【００８２】
図２５に示すように、自動判定装置２０の処理型判定部２７は、処理型が未定義の処理（以下、未定義処理と表記する）の直後のデータの処理型が定義済みであるか否かを判定する（Ｓ２０１）。そして、処理型判定部２７は、直後のデータの処理型が定義済みである場合には（Ｓ２０１肯定）、定義済みの処理型を未定義処理の処理型と判定する（Ｓ２０７）。
【００８３】
一方、処理型判定部２７は、直後のデータの処理型が定義済みでない場合には（Ｓ２０１否定）、未定義処理の直後の処理の処理型が定義済みであるか否かを判定する（Ｓ２０２）。そして、処理型判定部２７は、直後の処理の処理型が定義済みである場合には（Ｓ２０２肯定）、定義済みの処理型を未定義処理の処理型と判定する（Ｓ２０７）。
【００８４】
一方、処理型判定部２７は、直後の処理の処理型が定義済みでない場合には（Ｓ２０２否定）、さらに後続にデータが存在するか否かを、受け付けられた定義フローから判定する（Ｓ２０３）。そして、処理型判定部２７は、さらに後続にデータが存在すると判定した場合（Ｓ２０３肯定）、Ｓ２０１以降の処理を実行する。
【００８５】
また、処理型判定部２７は、さらに後続にデータが存在しないと判定した場合（Ｓ２０３否定）、未定義処理の直前のデータの処理型が定義済みであるか否かを判定する（Ｓ２０４）。そして、処理型判定部２７は、直前のデータの処理型が定義済みである場合には（Ｓ２０４肯定）、定義済みの処理型を未定義処理の処理型と判定する（Ｓ２０７）。
【００８６】
一方、処理型判定部２７は、直前のデータの処理型が定義済みでない場合には（Ｓ２０４否定）、未定義処理の直前の処理の処理型が定義済みであるか否かを判定する（Ｓ２０５）。そして、処理型判定部２７は、直前の処理の処理型が定義済みである場合には（Ｓ２０５肯定）、定義済みの処理型を未定義処理の処理型と判定する（Ｓ２０７）。
【００８７】
一方、処理型判定部２７は、直前の処理の処理型が定義済みでない場合には（Ｓ２０５否定）、さらに前にデータが存在するか否かを、受け付けられた定義フローから判定する（Ｓ２０６）。そして、処理型判定部２７は、さらに前にデータが存在すると判定した場合（Ｓ２０６肯定）、Ｓ２０３以降の処理を実行する。
【００８８】
また、処理型判定部２７は、さらに前にデータが存在しないと判定した場合（Ｓ２０６否定）、処理を終了する。また、処理型判定部２７は、Ｓ２０７で未定義処理の処理型が判定された場合にも処理を終了する。
【００８９】
［実施例１による効果］
このように、実施例１に係る自動判定装置２０は、利用者がデータの性質の違いを意識することなく、フロー定義で利用したいコンポーネントやデータを配置し、いずれか一つの要素の型を定義するだけで自動的にコンポーネントの型を判定することができる。そして、自動判定装置２０は、判定した型に応じたクエリ定義やSCA定義を含むアセンブリを生成することができる。また、自動判定装置２０は、いずれの型でも動作可能なコンポーネントを用意することで、処理型が違うことに起因するコンポーネントの種類の数を半減させることができる。
【００９０】
したがって、分析者などのプログラムに精通していないユーザは、いずれの型でも動作するコンポーネントとして、入力データをどう加工するものなのかという処理内容の違いだけを意識すればよく、簡単にフロー定義を生成することができる。つまり、ユーザは、数多あるコンポーネントから処理型は何ら考慮することなく処理内容の違いだけを意識して必要なコンポーネントを選択してフローを作成することができる。例えば、バッチ処理とオンライン処理とで同一のフロー定義を使うといったフロー編集作業が可能となり、プログラム作成の負荷が軽減され、開発効率を向上させることが出来る。また、バッチ処理またはリアルタイム処理の両方の処理型で利用可能な任意のデータまたはコンポーネントを要素として用い、フロー内で１つの要素の型を指定すれば残りの要素の型を自動判定することもでき、プログラム作成や処理型の変更の負荷をより軽減することができる。
【００９１】
また、ユーザは、開発者等に依頼することなく、簡単なプログラム等を自分で生成することができるので、近年の早いビジネススピードに遅れることなく、経営戦略の分析などスピードが要求される各種対応を迅速に処理することができる。
【実施例２】
【００９２】
実施例１では、未定義処理の処理型を当該未定義処理の直前の処理と同じ処理型と判定された例について説明したが、実施例２では、未定義処理の処理型を当該未定義処理の直前の処理と異なる処理型と判定された例について説明する。
【００９３】
図２６は、処理型判定の結果によって処理型が異なった例１を示す図である。図２６に示すように、フロー定義受付部２６が、「蓄積データ」−「駅での絞り込み処理」−「イベントデータ」が定義されたフロー定義を受け付けたとする。この場合、「駅での絞り込み処理」の処理型が直後の「イベントデータ」と同じ「イベント処理型」すなわち「リアルタイム処理型」と判定される。つまり、「駅での絞り込み処理」の直前の「蓄積データ」の処理型が「バッチ処理型」であるので、「駅での絞り込み処理」と「蓄積データ」との処理型が異なることとなる。
【００９４】
この場合、図２６に示すように、アセンブリ自動生成部２８は、「蓄積データ」と「駅での絞り込み処理」との間に、「蓄積データ」に対して「イベント送信処理を実行し、その結果をキューに格納する」処理を埋め込む。このようにデータ変換処理を実施することで、「リアルタイム処理型」と判定された「駅での絞り込み処理」へ入力されるデータの型が「リアルタイム処理型」となり、「駅での絞り込み処理」が実行可能な処理となる。
【００９５】
一例を挙げると、生成部２８は、データ変換処理として「イベント送信処理を実行し、その結果をキューに格納する」処理を実行するアセンブリを生成する。図２７は、自動判定装置が生成する、蓄積データのイベント送信を実行する実行用アセンブリの例を示す図である。図２７に示すコンポーネントには、アセンブリを実行するJava（登録商標）クラスとして「example.ExecuteHiveQuery」が定義される。また、このコンポーネントは、「sca:property name＝”HiveQL”」タグの値に「select * from data1」が定義され、「data1」に格納されている全イベントデータを「destination」タグに定義される「data2」キューに送信するクエリを実行する。
【００９６】
さらに、生成部２８は、図２６の下図に示す「データ変換処理」と「駅での絞り込み処理」とを実行するアセンブリを生成する。図２８は、自動判定装置が生成する、蓄積データの絞込みを実行する実行用アセンブリの例を示す図である。図２８に示すコンポジットには、「ExcuteHiveQuery」コンポーネントのJava（登録商標）クラスとして「example.ExecuteHiveQuery」が定義され、「sca:property nama＝”HiveQL”」タグの値に「select * from data1」が定義される。この結果、このコンポジットは、「data1」に格納されている全イベントデータを「destination」に定義される「data2」キューに送信するクエリを実行する。
【００９７】
また、図２８に示すこのコンポジットは、「EsperProcessor」コンポーネントのJava（登録商標）クラスとして「example.EsperProcessor」が定義され、「data2」に格納されたイベントデータの絞り込みを行うクエリを実行する。そして、このコンポジットは、上記「ExecuteHiveQuery」コンポーネントと「EsperProcessor」コンポーネントとを接続する「wire」要素を定義する。このようにして、生成部２８は、「ExecuteHiveQuery」と「EsperProcessor」との各々を連携して実行させるコンポジットを作成する。
【００９８】
図２９は、処理型判定の結果によって処理型が異なった例２を示す図である。図２９に示すように、フロー定義受付部２６が、「イベントデータ」−「駅での絞り込み処理」−「蓄積データ」が定義されたフロー定義を受け付けたとする。この場合、「駅での絞り込み処理」の処理型が直後の「蓄積データ」と同じ「蓄積処理型」すなわち「バッチ処理型」と判定される。つまり、「駅での絞り込み処理」の直前の「イベントデータ」の処理型が「リアルタイム処理型」であるので、「駅での絞り込み処理」と「イベントデータ」との処理型が異なることとなる。
【００９９】
この場合、図２９に示すように、アセンブリ自動生成部２８は、「イベントデータ」と「駅での絞り込み処理」との間に、「イベントデータ」に対して「データ蓄積処理を実行し、その結果をデータベースに格納する」処理を埋め込む。このようにデータ変換処理を実施することで、「バッチ処理型」と判定された「駅での絞り込み処理」へ入力されるデータの型が「バッチ処理型」となり、「駅での絞り込み処理」が実行可能な処理となる。
【０１００】
そして、生成部２８は、データ変換処理として「データ蓄積処理を実行し、その結果をデータベースに格納する」処理を実行するアセンブリを生成する。図３０は、自動判定装置が生成する、データの蓄積および通知を実行する実行用アセンブリの例を示す図である。図３０に示すコンポーネントには、アセンブリを実行するJava（登録商標）クラスとして「example.StoreEventDataIntoHdfs」が定義される。また、当該コンポーネントは、「sca:property」タグに「hdfsPath」や「hdfsUri」が定義され、data1から出力されるイベントデータを「data2」に蓄積する処理を実行する。
【０１０１】
次に、上述したアセンブリを実行するコンポーネント例について説明する。図３１は、処理実行装置が記憶する、蓄積データを送信するコンポーネントの実装例を示す図である。図３１に示すように、処理実行装置４０は、「boolean res = hiveStatement.execute（hiveQL）」が定義され、図２７に示したHiveクエリを実行するコンポーネントを記憶する。図３２は、処理実行装置が記憶する、イベントデータを蓄積するコンポーネントの実装例を示す図である。図３２に示すコンポーネントは、Hadoop上でHDFSへのアクセスを定義し、取得したイベントデータを蓄積することが定義される。
【０１０２】
このように、実施例２に係る自動判定装置２０は、フロー定義に記述される処理において、前後の処理で処理型が異なる場合でも、データの型を変換する変換処理を挿入して、フロー定義に記述される処理を実行させるプログラムを作成することができる。したがって、ユーザが、処理型の繋がりなどプログラムの知識がなくてもフロー定義を作成すればよく、ユーザの負担が軽減する。
【０１０３】
また、蓄積されたデータの分析で用いたフィルタやパラメータなどを、ストリーム処理に流用できる。また、蓄積されたイベントデータに対して、ストリーム処理を行った結果を擬似的にシミュレートできる。また、イベントの到着間隔に応じてストリーム処理を停止することで、サービスの運用コストを下げることができる。
【実施例３】
【０１０４】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【０１０５】
（テンプレート）
例えば、上記実施例では、Hiveクエリ、EPL、SCA等のテンプレートを用いる例を説明したが、これらはあくまで例示であり、開示する自動判定装置を限定するものではない。例えば、公知の様々なプログラム言語を用いることができ、開示する自動判定装置のみで使用するプログラム言語等を用いることもできる。
【０１０６】
また、上記実施例では、テンプレートを変換したクエリをSCA定義に埋め込む方式を例にして説明したが、これに限定されるものではない。例えば、両方のクエリをSCA定義に組み込んでおき、使用しない方のクエリをコメント文に変更するなどして、一方のクエリを実行させることもできる。
【０１０７】
（処理型）
また、上記実施例で説明したバッチ処理は、いわゆる蓄積処理であり、データを一定期間蓄積して蓄積されたデータに対して所望の処理を実行する処理型を例示したものである。また、リアルタイム処理型は、いわゆるストリーム処理であり、データが入力されるごとに所望の処理を実行する処理型を例示したものである。
【０１０８】
（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１０９】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１１０】
（プログラム）
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。
【０１１１】
図３３は、処理型判定プログラムを実行するコンピュータのハードウェア構成の例を示す図である。図３３に示すように、コンピュータ１００は、ＣＰＵ１０２、入力装置１０３、出力装置１０４、通信インタフェース１０５、媒体読取装置１０６、ＨＤＤ（Hard Disk Drive）１０７、ＲＡＭ（Random Access Memory）１０８を有する。また、図７に示した各部は、バス１０１で相互に接続される。
【０１１２】
入力装置１０３は、マウスやキーボードであり、出力装置１０４は、ディスプレイなどであり、通信インタフェース１０５は、ＮＩＣ（Network Interface Card）などのインタフェースである。ＨＤＤ１０７は、処理型判定プログラム１０７ａととともに、図３に示した記憶部に記憶される各情報を記憶する。記録媒体の例としてＨＤＤ１０７を例に挙げたが、ＲＯＭ（Read Only Memory）、ＲＡＭ、ＣＤ−ＲＯＭ等の他のコンピュータ読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記憶媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身の記録媒体に格納して用いてもよい。
【０１１３】
ＣＰＵ１０２は、処理型判定プログラム１０７ａを読み出してＲＡＭ１０８に展開することで、図１等で説明した各機能を実行する処理型判定プロセス１０８ａを動作させる。すなわち、処理型判定プロセス１０８ａは、図３に記載したフロー定義受付部２６、処理型判定部２７、アセンブリ自動生成部２８、テンプレート変換部２８ａ、生成部２８ｂと同様の機能を実行する。このようにコンピュータ１００は、プログラムを読み出して実行することで処理型判定方法を実行する情報処理装置として動作する。
【０１１４】
例えば、コンピュータ１００は、媒体読取装置１０６によって記録媒体から処理型判定プログラム１０７ａを読み出し、読み出された処理型判定プログラム１０７ａを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、コンピュータ１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
【符号の説明】
【０１１５】
１ クライアント装置
５ イベント通知装置
１０ イベント処理システム
２０ 自動判定装置
２１ 通信制御Ｉ／Ｆ部
２２ａ 作業領域
２２ｂ テンプレート記憶部
２２ｃ コンポーネントリポジトリ記憶部
２２ｄ アセンブリ記憶部
２５ 制御部
２６ フロー定義受付部
２７ 処理型判定部
２８ アセンブリ自動生成部
２８ａ テンプレート変換部
２８ｂ 生成部
４０ 処理実行装置
４１ 通信制御Ｉ／Ｆ部
４２ａ イベント記憶部
４２ｂ アセンブリ記憶部
４２ｃ 実行プログラム記憶部
４５ 制御部
４５ａ イベントデータ受信部
４５ｂ アセンブリ受信部
４５ｃ イベント処理部
【技術分野】
【０００１】
本発明は、自動判定装置、処理型判定方法および処理型判定プログラムに関する。
【背景技術】
【０００２】
従来、大量のデータを分類や分析するといったバッチ処理と、イベント発生に応じて逐次に処理するリアルタイム処理とは、それぞれの特性に応じて別々に発展してきた。例えば、バッチ処理とリアルタイム処理とでは、蓄積ファイルデータやキューイングデータなどのように利用可能なデータの性質の違いがある。
【０００３】
また、蓄積ファイルを入力として蓄積ファイル内のデータ処理を一括で行いデータがなくなれば処理を終了するか、システムに常駐してキューにイベントデータが登録されるたびに処理の実行を繰り返すかという処理形態の違いもある。また、処理の違いに応じて使用するＯＳ（Operating System）やミドルウェアの機能の違いなどもある。このように、バッチ処理とリアルタイム処理とでは、処理を実行する環境や要求される性能等の様々な違いがあり、各特性に応じたパフォーマンスが最大限有効になるように、別々にコンポーネントが開発されて別々の実装として発展している。
【０００４】
例えば、バッチ処理用のコンポーネントと、リアルタイム処理用のコンポーネントとをそれぞれ用意しておき、ユーザによって処理型が指定されたフロー定義に基づいて、該当するコンポーネントを実行する技術が知られている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１０７４７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来の技術では、コンポーネントを用いることでプログラム作成が容易になったとはいえ、プログラムに精通していないユーザにとっては依然として難しく、容易にプログラムを作成できないという問題がある。
【０００７】
例えば、コンポーネントを利用してプログラムを作成する場合、作成対象の処理がバッチ処理かリアルタイム処理かを正しく理解した上でなければ、フロー定義を作成することができない。したがって、プログラムに精通していないユーザにとっては、フロー定義の作成そのものが難しい。
【０００８】
一例を挙げると、システムやプログラムに精通していない分析者が、システムで処理されるデータに対して所望の分析を実行するプログラムを作成する場合を想定する。この場合、分析者は、どのような分析処理を実行させるのかを決定することはできても、バッチ処理かリアルタイム処理かの違いを意識した上で、決定した処理をどのように実行させるのかまで決定するのは難しく、正しいフロー定義を生成するのは難しい。
【０００９】
また、バッチ処理での分析に用いるデータと、分析結果の反映対象のリアルタイム処理に反映されるデータとが、必要なデータや項目といった条件が同じ場合を想定する。この場合でも、バッチ処理とリアルタイム処理それぞれのフロー定義手法に則り、それぞれコンポーネントを用意し、正しく組み合わせてそれぞれに異なるフロー定義を行わなければ正常に動作可能なプログラムが作成できない。
【００１０】
また、分析者が、システムやプログラムに精通する開発者に所望の処理を実行するプログラムの生成を依頼することも考えられる。しかし、分析者と開発者とは、部署が異なったり会社が異なったりすることが一般的である。このため、分析者が、開発者にプログラム作成依頼を行って所望のプログラムを得るまでに、関係各所との調整、発注のための書類作成、発注処理、開発者の作業などいくつかのステップを要するので時間がかかる。したがって、経営に関係する情報など早急な対応が要求される場合には、この方法を用いることは現実的ではない。また、ビジネスのスピードが速い近年では、この手法を用いる機会も少なく、利用価値が高いものでもない。
【００１１】
開示の技術は、上記に鑑みてなされたものであって、バッチ処理かリアルタイム処理かの違いを意識することなく容易にプログラムを作成することができる自動判定装置、処理型判定方法および処理型判定プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本願の開示する自動判定装置、処理型判定方法および処理型判定プログラムは、一つの態様において、以下の処理部を有する。本願の開示する自動判定装置は、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、前記バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部を有する。本願の開示する自動判定装置は、少なくとも前記記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける受付部を有する。本願の開示する自動判定装置は、前記受付部によって受け付けられたフロー定義に記述される前記処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から前記処理型が定義された要素を検索する。そして、本願の開示する自動判定装置は、検索された要素の処理型を前記未定義のコンポーネントの処理型と判定する。
【発明の効果】
【００１３】
本願の開示する自動判定装置、処理型判定方法および処理型判定プログラムの一つの態様によれば、バッチ処理かリアルタイム処理かの違いを意識することなく容易にプログラムを作成することができるという効果を奏する。
【図面の簡単な説明】
【００１４】
【図１】図１は、システムの全体構成例を示す図である。
【図２】図２は、複数の処理方式に対応したコンポーネントの例を示す図である。
【図３】図３は、自動判定装置の構成を示す機能ブロック図である。
【図４】図４は、テンプレート記憶部に記憶されるHiveクエリのテンプレート例を示す図である。
【図５】図５は、テンプレート記憶部に記憶されるEPLのテンプレート例を示す図である。
【図６】図６は、テンプレート記憶部に記憶されるEsperによる絞込み処理のテンプレート例を示す図である。
【図７】図７は、コンポーネントリポジトリ記憶部に記憶される処理管理情報の例を示す図である。
【図８】図８は、コンポーネントリポジトリ記憶部に記憶されるコンポーネント管理情報の例を示す図である。
【図９】図９は、フロー定義編集画面の例を示す図である。
【図１０】図１０は、フロー定義の保存形式の例を示す図である。
【図１１】図１１は、処理型の判定例を示す図である。
【図１２】図１２は、処理型の判定例を示す図である。
【図１３】図１３は、Hiveクエリテンプレートの変換例を示す図である。
【図１４】図１４は、EPLクエリテンプレートの変換例を示す図である。
【図１５】図１５は、蓄積データを絞り込む実行用アセンブリの例を示す図である。
【図１６】図１６は、イベントデータを絞り込む実行用アセンブリの例を示す図である。
【図１７】図１７は、処理実行装置の構成を示す機能ブロック図である。
【図１８】図１８は、イベント記憶部に記憶される情報の例を示す図である。
【図１９】図１９は、各クラス間のインタフェースの定義例を示す図である。
【図２０】図２０は、Hiveクエリを実行するコンポーネントの実装例を示す図である。
【図２１】図２１は、EPLクエリを実行するコンポーネントの実装例を示す図である。
【図２２】図２２は、イベント処理結果の例を示す図である。
【図２３】図２３は、アセンブリ作成までの流れを説明する図である。
【図２４】図２４は、イベント処理システムによる処理の流れを示すフローチャートである。
【図２５】図２５は、処理型判定処理の流れを示すフローチャートである。
【図２６】図２６は、処理型判定の結果によって処理型が異なった例１を示す図である。
【図２７】図２７は、自動判定装置が生成する、蓄積データのイベント送信を実行する実行用アセンブリの例を示す図である。
【図２８】図２８は、自動判定装置が生成する、蓄積データの絞込みを実行する実行用アセンブリの例を示す図である。
【図２９】図２９は、処理型判定の結果によって処理型が異なった例２を示す図である。
【図３０】図３０は、自動判定装置が生成する、データの蓄積および通知を実行する実行用アセンブリの例を示す図である。
【図３１】図３１は、処理実行装置が記憶する、蓄積データを送信するコンポーネントの実装例を示す図である。
【図３２】図３２は、処理実行装置が記憶する、イベントデータを蓄積するコンポーネントの実装例を示す図である。
【図３３】図３３は、処理型判定プログラムを実行するコンピュータのハードウェア構成の例を示す図である。
【発明を実施するための形態】
【００１５】
以下に、本願の開示する自動判定装置、処理型判定方法および処理型判定プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
【実施例１】
【００１６】
実施例１では、開示する自動判定装置を含むシステムの全体構成、システムが有する各装置の構成、処理の流れを説明する。なお、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【００１７】
［全体構成］
図１は、システムの全体構成例を示す図である。図１に示すように、このシステムは、クライアント装置１と、イベント通知装置５と、イベント処理システム１０とを有する。また、クライアント装置１とイベント処理システム１０とがネットワークなどを介して接続され、同様に、イベント通知装置５とイベント処理システム１０とがネットワークなどを介して接続される。
【００１８】
クライアント装置１は、プログラム作成者が使用するコンピュータであり、Ｗｅｂブラウザを用いてイベント処理システム１０の自動判定装置２０にアクセスする。そして、クライアント装置１は、自動判定装置２０から受信したＷｅｂ画面上で、入出力データおよびコンポーネントを要素とするフロー定義の作成や編集を実行する。なお、このクライアント装置１は、パーソナルコンピュータに限ったものではなく、例えばスマートフォンやＰＤＡ（Personal Digital Assistant）端末も使用することができる。
【００１９】
イベント通知装置５は、図示しないサーバ等から継続的にイベントを受信して、継続的にイベント処理システム１０に通知するサーバ装置である。一例を挙げると、イベント通知装置５は、各駅の改札口の出入り情報を管理する管理サーバから、出入り情報をイベントとして受信してイベント処理システム１０に通知する。なお、ここでは、駅の出入り情報を例にしたが、これに限定されるものではなく、例えばシステム監視ログなど様々な情報を用いることができる。
【００２０】
イベント処理システム１０は、自動判定装置２０と処理実行装置４０とを有し、クライアント装置１から受け付けたフロー定義に基づいてプログラムを自動生成し、生成したプログラムを実行して所望の結果を得るシステムである。ここでは、自動判定装置２０と処理実行装置４０とが別々の筐体で実現される場合で説明するが、これに限定されるものではなく、１つの筐体で実現することもでき、３つ以上の筐体に機能を分割してもよい。
【００２１】
自動判定装置２０は、クライアント装置１からフロー定義を受け付けてプログラムを自動生成し、生成したプログラムを処理実行装置４０に出力するサーバ装置である。ここで、自動判定装置２０が有するコンポーネントについて説明する。図２は、複数の処理方式に対応したコンポーネントの例を示す図である。図２に示すように、ここでは、イベントデータを記憶するデータベースから、フィールドＡが値ａのデータを絞り込むコンポーネントを例にしている。そして、蓄積されたイベントデータは、例えばHadoop上に格納され、Hiveでアクセス可能とした場合、Hiveでデータの絞り込みを行う。また、リアルタイムなイベントデータを絞り込む場合は、ここではJMSキューに格納されたイベントデータを順次Esperエンジンを使って次のキューにデータを受け渡すことを想定する。
【００２２】
このような自動判定装置２０は、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する。そして、自動判定装置２０は、少なくとも記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける。その後、自動判定装置２０は、受け付けられたフロー定義に記述される処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から処理型が定義された要素を検索する。そして、自動判定装置２０は、検索された要素の処理型を未定義のコンポーネントの処理型と判定する。このようにすることで、自動判定装置２０は、どのような処理を実行したいかを示したフロー定義からプログラムを自動生成し、生成したプログラムを処理実行装置４０に出力する。
【００２３】
処理実行装置４０は、自動判定装置２０から入力されたプログラムを実行して所望の結果を取得し、取得した結果をクライアント装置１に応答するサーバ装置である。例えば、処理実行装置４０は、イベントデータを所定数または所定時間蓄積した後に、蓄積したイベントデータ（以下、蓄積データと表記する）から所望のデータを絞り込んで抽出するバッチ処理を実行する。また、処理実行装置４０は、自動判定装置２０からイベントデータを受信するたびに、当該イベントデータをフィルタリングして絞り込むリアルタイム処理を実行する。
【００２４】
このように、自動判定装置２０は、バッチ処理かリアルタイム処理かを意識することなく作成したフロー定義を受信した場合でも、当該フロー定義で定義されるコンポーネントの処理型を自動で判定することができる。この結果、プログラムやシステムに精通していないユーザであっても、バッチ処理かリアルタイム処理かの違いを意識することなく容易にプログラムを作成することができる。
【００２５】
［装置の構成］
次に、図１に示した自動判定装置２０と処理実行装置４０の構成について説明する。なお、図１に示したクライアント装置１は一般的なパーソナルコンピュータと同様の構成を有し、イベント通知装置５も一般的なイベント通知処理と同様の構成を有するので、詳細な説明は省略する。
【００２６】
（自動判定装置の構成）
図３は、自動判定装置の構成を示す機能ブロック図である。図３に示すように、自動判定装置２０は、通信制御Ｉ／Ｆ部２１と、作業領域２２ａと、テンプレート記憶部２２ｂと、コンポーネントリポジトリ記憶部２２ｃと、アセンブリ記憶部２２ｄと、制御部２５とを有する。なお、各記憶部は、例えば半導体メモリ素子やハードウェアなどの記憶装置である。制御部２５は、例えばＣＰＵ（Central Processing Unit）などの電子回路やＦＰＧＡ（Field-Programmable Gate Array）などの集積回路である。
【００２７】
通信制御Ｉ／Ｆ部２１は、例えばＮＩＣ（Network Interface Card）などのように、他の装置と通信を制御するインタフェースである。例えば、通信制御Ｉ／Ｆ部２１は、クライアント装置１からＷｅｂアクセスを受け付けると、クライアント装置１と自動判定装置２０との間にコネクションを確立して、フロー定義を受け付ける。また、通信制御Ｉ／Ｆ部２１は、制御部２５によって作成されたプログラムを処理実行装置４０に出力する。
【００２８】
作業領域２２ａは、制御部２５の各処理部が処理を実行する際に、データ等の処理途中結果を一時的に格納する領域である。
【００２９】
テンプレート記憶部２２ｂは、蓄積データに対して絞り込みを実行するクエリのテンプレートやイベントデータに対して絞り込みを実行するクエリのテンプレートを記憶する。また、テンプレート記憶部２２ｂは、クエリを埋め込む各SCA（Service Component Architecture）テンプレートも記憶する。なお、テンプレート記憶部２２ｂは、各テンプレートに識別子やテンプレート名を付与し、テンプレートと識別子等を対応付けて格納することで各テンプレートを区別する。
【００３０】
図４は、テンプレート記憶部に記憶されるHiveクエリのテンプレート例を示す図である。図４に示すように、このHiveクエリのテンプレートは、$fieldで示す特定のフィールド（カラム）が$equalsで示す特定の値であるデータを$input1で示す入力テーブルから抽出して$output1で示す出力テーブルに書き込むことが記述されたクエリである。図５は、テンプレート記憶部に記憶されるEPLのテンプレート例を示す図である。図５に示すように、このEPLのテンプレートは、$fieldで示す特定のフィールドが$equalsで示す特定の値であるデータを$input1で示すキューから抽出することが記述されたクエリである。
【００３１】
また、図６は、テンプレート記憶部に記憶されるEsperによる絞込み処理のテンプレート例を示す図である。この図６は、SCA定義による実行可能なアセンブリを生成するためのテンプレートである。図６に示すように、このテンプレートは、入出力データ名をキュー名として利用し、テンプレートで生成したクエリを属性として埋め込み、コンポーネント１つを含むコンポジットとして生成する。
【００３２】
コンポーネントリポジトリ記憶部２２ｃは、フロー定義で定義された処理を管理する処理管理情報と、処理とコンポーネントと対応付けたコンポーネント管理情報とを記憶する。図７は、コンポーネントリポジトリ記憶部に記憶される処理管理情報の例を示す図である。図７に示すように、コンポーネントリポジトリ記憶部２２ｃは、処理管理情報として「ID、処理名、処理型」を対応付けて記憶する。ここで記憶される「ID」は、処理を識別する識別子であり、「処理名」は、フロー定義で定義される処理の名称であり、「処理型」は、処理名に格納される処理が実行可能な処理型を示す。
【００３３】
図７の場合、IDが「01」である処理名「値範囲指定」は、ストリーム処理または蓄積処理の両方が実行可能である、すなわち、リアルタイム処理またはバッチ処理が実行可能であることを示す。同様に、IDが「02」である処理名「値指定」は、ストリーム処理または蓄積処理の両方が実行可能であることを示し、IDが「03」である処理名「値集計」は、蓄積処理のみが実行可能であることを示す。
【００３４】
図８は、コンポーネントリポジトリ記憶部に記憶されるコンポーネント管理情報の例を示す図である。図８に示すように、コンポーネントリポジトリ記憶部２２ｃは、コンポーネント管理情報として「ID、処理ID、処理型、コンポーネント名、クエリテンプレート、SCAテンプレート」を対応付けて記憶する。ここで記憶される「ID」は、コンポーネントを識別する識別子であり、「処理ID」は、処理管理情報のコンポーネントに対応する処理のIDであり、「コンポーネント名」は、コンポーネントの名称である。「クエリテンプレート」は、SCAテンプレートに埋め込むクエリのテンプレートのファイル名などの識別子や名称であり、「SCAテンプレート」は、クエリを埋め込む対象のSCA定義が記述されたテンプレートのファイル名などの識別子や名称である。
【００３５】
図８を例にして具体例を説明する。ID「01」が割り与えられたコンポーネント名「StreamFilter」は、処理ID「01」の「値範囲指定」を「ストリーム処理」で実行するコンポーネントであり、SCAテンプレート「01-sca.vm」にクエリテンプレート「01-query.vm」を用いて生成したクエリを埋め込んで生成されることを示す。同様に、ID「02」が割り与えられたコンポーネント名「AccumulateFilter」は、処理ID「01」の「値範囲指定」を「蓄積処理」で実行するコンポーネントであり、SCAテンプレート「02-sca.vm」にクエリテンプレート「02-query.vm」を用いて生成したクエリを埋め込んで生成されることを示す。
【００３６】
アセンブリ記憶部２２ｄは、制御部２５によって生成された、SCAによる実行可能なアセンブリを記憶する。すなわち、アセンブリ記憶部２２ｄは、クライアント装置１によって生成されたフロー定義を実行するコンポーネントを組み合わせたアセンブリを記憶する。
【００３７】
制御部２５は、フロー定義受付部２６と処理型判定部２７とアセンブリ自動生成部２８とを有し、これらによって、クライアント装置１から受け付けたフロー定義に基づいて実行可能なアセンブリを生成する処理部である。
【００３８】
フロー定義受付部２６は、少なくともコンポーネントリポジトリ記憶部２２ｃ等に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける処理部である。例えば、フロー定義受付部２６は、クライアント装置１からフロー定義を作成または編集を実行するＷｅｂアクセスを受け付けた場合に、通信制御Ｉ／Ｆ部２１を介して、フロー定義編集画面をクライアント装置１に送信する。そして、フロー定義受付部２６は、フロー定義編集画面でフロー定義の作成や編集を受け付けて、受け付けた情報を作業領域２２ａに格納する。
【００３９】
図９は、フロー定義編集画面の例を示す図である。フロー定義受付部２６は、図９に示すフロー定義編集画面をクライアント装置１に送信して、フロー定義の編集作業を受け付ける。クライアント装置１は、図９に示すフロー定義編集画面の画面左にある「クラスタＩＤ追加」や「距離計算」などの処理（プロセス）をドラックアンドドロップで中央に移動させてフロー定義を作成する。
【００４０】
このフロー定義では、ドラム缶や四角で表すデータを入力として、丸（アクティビティ）で表す処理を行い、データを出力する。最初の入力となるデータについては、処理型を蓄積型（バッチ処理型）かストリーム型（リアルタイム処理型）かのどちらかとして指定し、その他の処理やデータについては、必要であれば処理型を指定する。なお、ここで作成されるフロー定義としては、例えばDFD（Data Flow Diagram）などがある。また、図９の例では、キュー１からイベントデータを読み出して、値範囲指定のフィルター処理を実行し、実行した結果をキュー２に出力するフロー定義が図示されている。
【００４１】
そして、フロー定義受付部２６は、クライアント装置１によるフロー定義作成が終了した場合、作成されたフロー定義を例えばXML（Extensible Markup Language）形式などに変換して作業領域２２ａに格納する。図１０は、フロー定義の保存形式の例を示す図である。図１０に示すように、データ（data）と処理（process）についてはbehavior属性として処理型を保存しており、処理に対応するXMLタグからは、入出力となるデータに対応するIDが属性として保存される。なお、ここでは、XML形式で保存する例で説明したが、保存形式はXMLに限定されるものではなく、任意の保存形式を用いることができる。
【００４２】
図３に戻り、処理型判定部２７は、フロー定義受付部２６によってフロー定義が作業領域２２ａに格納されたことを検出する。すると、処理型判定部２７は、フロー定義受付部２６によって受け付けられたフロー定義に記述される処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から処理型が定義された要素を検索する。そして、処理型判定部２７は、検索された要素の処理型を未定義のコンポーネントの処理型と判定する処理部である。また、処理型判定部２７は、判定した結果をアセンブリ自動生成部２８に出力する。
【００４３】
ここで、図１１と図１２を用いて処理型判定の例を説明する。図１１と図１２は、処理型の判定例を示す図である。図１１は、フロー定義受付部２６によって受け付けられたフロー定義をDFDで表した図である。すなわち、クライアント装置１は、鉄道イベントを記憶するデータベースの「蓄積データ」を入力データとして、処理型が「未判定」の「駅での絞り込み」処理を実行し、処理型が「未判定」の「鉄道イベント」を出力するフロー定義を作成したとする。この場合、処理型判定部２７は、処理型判定対象が「駅での絞り込み」処理であり、当該処理の後続の「鉄道イベント」が「未判定」であり、当該処理の前方の入力データが「蓄積データ」であることを特定する。そして、処理型判定部２７は、「駅での絞り込み」処理および当該処理の後続の「鉄道イベント」各々の処理型を「蓄積型」すなわち「バッチ処理型」と判定する。
【００４４】
同様に、図１２に示した図は、フロー定義受付部２６によって受け付けられたフロー定義をDFDで表した図である。すなわち、クライアント装置１は、鉄道イベントを記憶するキューの「イベントデータ」を入力データとして、処理型が「未判定」の「駅での絞り込み」処理を実行し、処理型が「未判定」の「鉄道イベント」を出力するフロー定義を作成したとする。この場合、処理型判定部２７は、処理型判定対象が「駅での絞り込み」処理であり、当該処理の後続の「鉄道イベント」が「未判定」であり、当該処理の前方の入力データが「イベントデータ」であることを特定する。そして、処理型判定部２７は、「駅での絞り込み」処理および当該処理の後続の「鉄道イベント」各々の処理型を「イベント処理型」すなわち「リアルタイム処理型」と判定する。
【００４５】
具体的な判定の一例として、図１０に示したフロー定義がXML形式で作業領域２２ａに格納された場合を例にして説明する。この場合、処理型判定部２７は、XML形式で格納されるフロー定義から、behavior属性がDefineLaterのprocessタグを検索する。そして、処理型判定部２７は、該当するprocessタグが検索できた場合には、処理型が未定義のコンポーネントが存在すると判定する。
【００４６】
続いて、処理型判定部２７は、検索したprocessの直後のデータの型として、当該processのoutputdataに対応するdataタグのbehavior属性を参照する。そして、処理型判定部２７は、参照したdataタグのbehavior属性がaccumulateであれば、当該processの処理型を「蓄積処理型」すなわち「バッチ処理型」と特定する。また、処理型判定部２７は、参照したdataタグのbehavior属性がstreamであれば、当該processの処理型を「ストリーム処理型」すなわち「リアルタイム処理型」と特定する。一方、処理型判定部２７は、参照したdataタグのbehavior属性がdefinelaterであれば、processのinputdataに対応するdataタグのbehavior属性を参照して、上述した処理と同様の処理を実行する。
【００４７】
また、処理型判定部２７は、検索したprocessの後続のdataやprocessのbehavior属性が全部definelaterである場合に、検索したprocessの直前のdataについて同様の処理を実行する。つまり、処理型判定部２７は、処理型判定対象のprocessの後続の要素から処理型が特定できなかった場合に、処理型判定対象のprocessの直前の要素から前方に向かって順に処理型を参照する。そして、処理型判定部２７は、definelater以外を検索した場合に、検索されたbehavior属性を、処理型判定対象のprocessの処理型と判定する。なお、ここでは、判定対象のprocessの後続の要素から順に検索する場合を例にしたが、これに限定されるものではなく、例えば判定対象のprocessの前の要素から順に検索するなど、検索順序は任意に設定変更することができる。
【００４８】
図３に戻り、アセンブリ自動生成部２８は、テンプレート変換部２８ａと生成部２８ｂとを有し、特定された処理型の処理を実行するクエリをコンポーネントに挿入する。そして、アセンブリ自動生成部２８は、フロー定義受付部２６によって受け付けられたフロー定義で定義される処理を実行するアセンブリを生成する処理部である。
【００４９】
このアセンブリ自動生成部２８は、処理型判定部２７によって処理型が判定されたコンポーネント、言い換えると、処理型が特定された処理の名称をDFDまたはXMLから特定する。そして、アセンブリ自動生成部２８は、例えば図９の「値範囲指定」のように、特定した処理の名称に対応する処理IDをコンポーネントリポジトリ記憶部２２ｃから特定する。続いて、アセンブリ自動生成部２８は、特定した処理IDと処理型判定部２７から通知された処理型とに基づいて、SCAテンプレートの識別子とクエリテンプレートの識別子とを特定する。その後、アセンブリ自動生成部２８は、特定したクエリテンプレートの識別子をテンプレート変換部２８ａに通知し、SCAテンプレートの識別子を生成部２８ｂに通知する。
【００５０】
例えば、処理型が特定された処理の名称が「値範囲指定」であり、特定された処理型が「蓄積処理型」である場合を例にして説明する。この場合、アセンブリ自動生成部２８は、図７の記憶部を参照して「値範囲指定」に対応する処理IDが「01」であることを特定する。続いて、アセンブリ自動生成部２８は、図８の記憶部を参照し、処理ID「01」と処理型「蓄積」との組み合わせが記憶されるレコードがID「02」のレコードであることを特定する。そして、アセンブリ自動生成部２８は、特定したレコードのクエリテンプレートに格納される「02-query.vm」をテンプレート変換部２８ａに通知し、SCAテンプレート格納される「02-sca.vm」を生成部２８ｂに通知する。
【００５１】
テンプレート変換部２８ａは、フロー定義受付部２６によって受け付けられたフロー定義にしたがって、アセンブリ自動生成部２８から通知されたクエリテンプレートを変換する処理部である。そして、テンプレート変換部２８ａは、変換したクエリを生成部２８ｂに出力する。ここで、図１３と図１４を用いてクエリテンプレートの変換例を説明する。
【００５２】
図１３は、Hiveクエリテンプレートの変換例を示す図である。図１３に示すように、この例では、フロー定義として、データベースの「蓄積データ」を入力データ「data1」として、「駅での絞り込み」処理を実行し、出力データを「data2」としてデータベースに格納することが定義されている。すなわち、図１３に示した全要素はいずれも「バッチ処理型」に該当する。また、この「駅での絞り込み」処理に、プロパティとして、「Field＝station、value＝1」が与えられたとする。その場合、テンプレート変換部２８ａは、図１３に示すように、図４に示したHiveクエリのテンプレートに対して、「field」を「station」、「equals」を「1」、「input」を「data1」、「output」を「data2」に変換したクエリを生成する。
【００５３】
図１４は、EPLクエリテンプレートの変換例を示す図である。図１４に示すように、この例では、フロー定義として、キューの「イベントデータ」を入力データ「data1」とし、「駅での絞り込み」処理を実行して、出力データを「data2」としてキューに格納することが定義されている。すなわち、図１４に示した全要素はいずれも「リアルタイム処理型」に該当する。また、この「駅での絞り込み」処理に、プロパティとして、「Field＝station、value＝1」が与えられたとする。この場合、テンプレート変換部２８ａは、図１４に示すように、図５に示したEPLクエリのテンプレートに対して、「field」を「station」、「equals」を「1」、「input」を「data1」に変換したクエリを生成する。
【００５４】
生成部２８ｂは、アセンブリ自動生成部２８から通知されたSCAテンプレートに、テンプレート変換部２８ａから通知されたクエリを埋め込んで、フロー定義受付部２６によって受け付けられたフロー定義で定義される処理を実行するアセンブリを生成する。そして、生成部２８ｂは、生成したアセンブリをアセンブリ記憶部２２ｄに格納し、また、処理実行装置４０に送信する。
【００５５】
例えば、アセンブリ自動生成部２８から通知されたSCAテンプレートが「01-sca.vm」であり、テンプレート変換部２８ａから通知されたクエリがテンプレート「01-query.vm」を変換した、図１３に示すクエリであるとする。この場合、生成部２８ｂは、「01-sca.vm」に該当するテンプレートをテンプレート記憶部２２ｂから読み出し、読み出したSCAテンプレート「01-sca.vm」に図１３に示したクエリを埋め込んで、蓄積データを絞り込む実行用アセンブリを生成する。図１５は、蓄積データを絞り込む実行用アセンブリの例を示す図である。図１５に示すコンポーネントには、アセンブリを実行するJava（登録商標）クラスとして「example.ExecuteHiveUpdate」が定義される。また、このコンポーネントには、実行するクエリとして、図１３に示した変換後の「HiveQL」クエリが「sca:property name＝”HiveQL”」タグの値に埋め込まれる。ここで用いられているJava（登録商標）クラスは例えば図２０のようになる。
【００５６】
また、アセンブリ自動生成部２８から通知されたSCAテンプレートが「02-sca.vm」であり、テンプレート変換部２８ａから通知されたクエリがテンプレート「02-query.vm」を変換した、図１４に示すクエリであるとする。この場合、生成部２８ｂは、「02-sca.vm」に該当する図６に示したテンプレートをテンプレート記憶部２２ｂから読み出す。そして、生成部２８ｂは、読み出したSCAテンプレート「02-sca.vm」に、図１４に示したクエリを埋め込んで、イベントデータを絞り込む実行用アセンブリを生成する。図１６は、イベントデータを絞り込む実行用アセンブリの例を示す図である。図１６に示すコンポーネントには、アセンブリを実行するJava（登録商標）クラスとして「example.EsperProcessor」を定義される。また、このコンポーネントには、実行するクエリとして、図１４に示した変換後の「EPL」クエリが「sca:property name＝”EPL”」タグの値に埋め込まれる。ここで用いられているJava（登録商標）クラスは例えば図２１のようになる。
【００５７】
（処理実行装置の構成）
次に、図１に示した処理実行装置４０の構成について説明する。図１７は、処理実行装置の構成を示す機能ブロック図である。図１７に示すように、処理実行装置４０は、通信制御Ｉ／Ｆ部４１と、イベント記憶部４２ａと、アセンブリ記憶部４２ｂと、実行プログラム記憶部４２ｃと、制御部４５とを有する。なお、各記憶部は、例えば半導体メモリ素子やハードウェアなどの記憶装置である。制御部４５は、例えばＣＰＵなどの電子回路やＦＰＧＡなどの集積回路である。これら以外にも、例えば、制御部２５の各処理部が処理を実行する際に、データ等の処理途中結果を一時的に格納する作業領域等も有していてもよい。
【００５８】
通信制御Ｉ／Ｆ部４１は、例えばＮＩＣなどのように、他の装置と通信を制御するインタフェースである。例えば、通信制御Ｉ／Ｆ部４１は、自動判定装置２０から実行可能なアセンブリを受信し、また、イベント通知装置５からイベントデータを受信する。また、通信制御Ｉ／Ｆ部４１は、イベントデータに対して実行した処理の結果をクライアント装置１に送信する。
【００５９】
イベント記憶部４２ａは、イベント通知装置５から受信したイベントデータを記憶する。図１８は、イベント記憶部に記憶される情報の例を示す図である。図１８に示すように、イベント記憶部４２ａは、「発生時刻、ID、Station、Type」を対応付けて記憶する。ここで記憶される「発生時刻」は、イベントが発生した日であり、「ID」は、イベントを識別する識別子であり、「Station」は、イベントが発生した駅を識別する識別子であり、「Type」は、発生したイベントの内容を示す情報である。
【００６０】
図１８の場合、「2011/4/19」に発生した「ID」が「001」のイベントは、「Station」が「1」が割り当てられた駅で発生した「改札に入る」イベントであることを示す。また、「2011/4/19」に発生した「ID」が「003」のイベントは、「Station」が「2」が割り当てられた駅で発生した「改札から出る」イベントであることを示す。
【００６１】
アセンブリ記憶部４２ｂは、自動判定装置２０から受信した実行可能なアセンブリを記憶する。例えば、アセンブリ記憶部４２ｂは、図１５に示した蓄積データを絞り込む実行用アセンブリや図１６に示したイベントデータを絞り込む実行用アセンブリを記憶する。
【００６２】
実行プログラム記憶部４２ｃは、アセンブリ記憶部４２ｂに格納される実行可能なアセンブリを実行するプログラムを記憶する。例えば、実行プログラム記憶部４２ｃは、自動判定装置２０によって生成されたアセンブリを呼び出して実行するJava（登録商標）プログラムを記憶する。
【００６３】
例を挙げると、実行プログラム記憶部４２ｃは、図１９に示した、各コンポーネントの実装で利用している共通の入出力インタフェースを記述したプログラムを記憶する。図１９は、各クラス間のインタフェースの定義例を示す図である。図１９に示すように、インタフェースとして「MapEventReceiver」が定義されており、コンポーネントを呼び出す側がインタフェースを参照する形で、複数のコンポーネントを連携させる。
【００６４】
また、実行プログラム記憶部４２ｃは、図２０に示したプログラムを記憶する。図２０は、Hiveクエリを実行するコンポーネントの実装例を示す図である。図２０に示したコンポーネントは、「boolean res = hiveStatement.execute（hiveQL）」が定義され、図１５のアセンブリに埋め込んだHiveクエリを実行する。
【００６５】
また、実行プログラム記憶部４２ｃは、図２１に示したプログラムを記憶する。図２１は、EPLクエリを実行するコンポーネントの実装例を示す図である。図２１に示したコンポーネントは、「EPStatement statement = epSrevice.getEPAdministrator().createEPL(epl)」が定義され、図１６のアセンブリに埋め込んだEPLクエリを実行する。
【００６６】
制御部４５は、イベントデータ受信部４５ａとアセンブリ受信部４５ｂとイベント処理部４５ｃとを有し、これらによって、クライアント装置１からフロー定義を用いて生成した処理を実行し、その結果をクライアント装置１に応答する処理部である。
【００６７】
イベントデータ受信部４５ａは、イベント通知装置５からイベントデータを受信してイベント記憶部４２ａに格納する処理部である。イベントデータを受信する契機としては、例えばイベント通知装置５から送信されるのを待つだけでなく、イベントデータ受信部４５ａが定期的にイベント通知装置５から取得してもよい。
【００６８】
アセンブリ受信部４５ｂは、自動判定装置２０から実行可能なアセンブリを受信してアセンブリ記憶部４２ｂに格納する処理部である。すなわち、アセンブリ受信部４５ｂは、図１５や図１６に示した、SCAで定義された実行可能なアセンブリを受信して格納する。
【００６９】
イベント処理部４５ｃは、実行プログラム記憶部４２ｃに記憶されるプログラムを実行して、アセンブリ記憶部４２ｂに記憶されアセンブリを実行し、所望の結果を取得して、クライアント装置１に応答する処理部である。例えば、イベント処理部４５ｃが、図２０に示したコンポーネントで実行して、図１３に示したHiveクエリが埋め込まれた図１５のアセンブリを実行したとする。すなわち、図１８に示した蓄積データから「station=1」のイベントデータを抽出する例を説明する。
【００７０】
この場合、イベント処理部４５ｃは、「2011/4/19、001、1、Enter」、「2011/4/19、002、1、Enter」、「2011/4/19、003、2、Exit」、「2011/4/19、004、2、Enter」から「station」が「1」のイベントデータを絞り込む。その結果、イベント処理部４５ｃは、図２２に示すように、「2011/4/19、001、1、Enter」、「2011/4/19、002、1、Enter」を抽出する。図２２は、イベント処理結果の例を示す図である。そして、イベント処理部４５ｃは、抽出したイベントデータをイベント処理結果、すなわちクライアントがフロー定義によって得ようとした結果としてクライアント装置１に送信する。
【００７１】
なお、イベント処理を実行するタイミングは、実行可能なアセンブリがアセンブリ記憶部４２ｂに格納されたタイミングや、自動判定装置２０やクライアント装置１などから処理開始指示を受信した場合など任意のタイミングで実行することができる。また、イベント処理部４５ｃは、様々な手法を用いて、実行プログラム記憶部４２ｃに記憶されるプログラムから、実行すべきプログラムを特定することができる。例えば、イベント処理部４５ｃは、アセンブリ記憶部４２ｂに記憶されたアセンブリに埋め込まれたクエリから特定することもでき、自動判定装置２０等から実行対象の処理やプログラムを特定する情報を受信してもよい。
【００７２】
［処理の流れ］
次に、図１に示したイベント処理システムが実行する処理の流れを説明する。ここでは、アセンブリ生成までの処理とフローチャートについて説明する。
【００７３】
（アセンブリ生成までの処理の説明）
図２３は、アセンブリ作成までの流れを説明する図である。図２３に示すように、自動判定装置２０は、図４から図６に示したクエリテンプレートとSCAテンプレートとをテンプレート記憶部２２ｂに記憶する。そして、自動判定装置２０は、フロー定義受付部２６によって受け付けられたフロー定義とクエリテンプレートとから、図１３や図１４に示した実行可能なクエリを生成する。
【００７４】
その後、自動判定装置２０は、図６などに示したSCAテンプレートに、生成した実行可能なクエリを埋め込み、図１５や図１６に示す実行可能なSCAコンポーネント定義を生成する。また、フロー定義が複数の処理で構成されている場合には、各処理ごとに生成したSCAコンポーネントを組み合わせて、実行可能なアセンブリであるSCAコンポジット定義を生成する。
【００７５】
自動判定装置２０は、このように作成したアセンブリであるSCAコンポジット定義を処理実行装置４０が稼動させるSCAのエンジンに渡し、処理実行装置４０が実行する。例えばApache Tuscanyであれば、Java（登録商標）アプリケーションから「import org.apache.tuscany.sca.host.embedded.SCADomain;SCADomain.newInstance("SCA定義のファイル名");」として実行される。
【００７６】
（フローチャート）
図２４は、イベント処理システムによる処理の流れを示すフローチャートである。図２４に示すように、自動判定装置２０のフロー定義受付部２６がクライアント装置１からフロー定義を受け付けると（Ｓ１０１肯定）、処理型判定部２７は、フロー定義内に処理型が未定義の処理またはデータが存在するか否かを判定する（Ｓ１０２）。
【００７７】
そして、処理型判定部２７は、処理型が未定義の処理またはデータが存在する場合（Ｓ１０２肯定）、処理型判定処理を実行する（Ｓ１０３）。なお、処理型判定部２７は、フロー定義内に存在する、処理型が未定義の処理またはデータの処理型が判定されるまで、処理型判定処理を実行する。
【００７８】
その後、処理型判定部２７によって処理型が判定されると（Ｓ１０２否定）、テンプレート変換部２８ａは、コンポーネントリポジトリ記憶部２２ｃを参照し、フロー定義内の処理に該当するクエリテンプレートから実行可能なクエリを生成する（Ｓ１０４）。
【００７９】
続いて、生成部２８ｂは、コンポーネントリポジトリ記憶部２２ｃを参照して、生成された実行可能なクエリを埋め込むSCAテンプレートを特定し、特定したSCAテンプレートに実行可能なクエリを埋め込んで、SCAコンポーネント定義を生成する（Ｓ１０５）。すなわち、生成部２８ｂは、フロー定義によって定義された一連の処理を実行可能なアセンブリを生成する。そして、生成部２８ｂは、生成したアセンブリを処理実行装置４０に送信する（Ｓ１０６）。
【００８０】
処理実行装置４０のアセンブリ受信部４５ｂが自動判定装置２０からアセンブリを受信し、イベント処理部４５ｃは、受信されたアセンブリに対応するJava（登録商標）プログラム等を実行する（Ｓ１０７）。また、処理実行装置４０のイベント処理部４５ｃは、Java（登録商標）プログラムで呼び出されたアセンブリの実行によって得られた処理結果をクライアント装置１に送信する。
【００８１】
（処理型判定処理の流れ）
図２５は、処理型判定処理の流れを示すフローチャートである。この処理は、図２４に示したＳ１０３で実行される。なお、ここでは、一例として、後続の要素の処理型を優先して、処理型を判定する例を説明する。
【００８２】
図２５に示すように、自動判定装置２０の処理型判定部２７は、処理型が未定義の処理（以下、未定義処理と表記する）の直後のデータの処理型が定義済みであるか否かを判定する（Ｓ２０１）。そして、処理型判定部２７は、直後のデータの処理型が定義済みである場合には（Ｓ２０１肯定）、定義済みの処理型を未定義処理の処理型と判定する（Ｓ２０７）。
【００８３】
一方、処理型判定部２７は、直後のデータの処理型が定義済みでない場合には（Ｓ２０１否定）、未定義処理の直後の処理の処理型が定義済みであるか否かを判定する（Ｓ２０２）。そして、処理型判定部２７は、直後の処理の処理型が定義済みである場合には（Ｓ２０２肯定）、定義済みの処理型を未定義処理の処理型と判定する（Ｓ２０７）。
【００８４】
一方、処理型判定部２７は、直後の処理の処理型が定義済みでない場合には（Ｓ２０２否定）、さらに後続にデータが存在するか否かを、受け付けられた定義フローから判定する（Ｓ２０３）。そして、処理型判定部２７は、さらに後続にデータが存在すると判定した場合（Ｓ２０３肯定）、Ｓ２０１以降の処理を実行する。
【００８５】
また、処理型判定部２７は、さらに後続にデータが存在しないと判定した場合（Ｓ２０３否定）、未定義処理の直前のデータの処理型が定義済みであるか否かを判定する（Ｓ２０４）。そして、処理型判定部２７は、直前のデータの処理型が定義済みである場合には（Ｓ２０４肯定）、定義済みの処理型を未定義処理の処理型と判定する（Ｓ２０７）。
【００８６】
一方、処理型判定部２７は、直前のデータの処理型が定義済みでない場合には（Ｓ２０４否定）、未定義処理の直前の処理の処理型が定義済みであるか否かを判定する（Ｓ２０５）。そして、処理型判定部２７は、直前の処理の処理型が定義済みである場合には（Ｓ２０５肯定）、定義済みの処理型を未定義処理の処理型と判定する（Ｓ２０７）。
【００８７】
一方、処理型判定部２７は、直前の処理の処理型が定義済みでない場合には（Ｓ２０５否定）、さらに前にデータが存在するか否かを、受け付けられた定義フローから判定する（Ｓ２０６）。そして、処理型判定部２７は、さらに前にデータが存在すると判定した場合（Ｓ２０６肯定）、Ｓ２０３以降の処理を実行する。
【００８８】
また、処理型判定部２７は、さらに前にデータが存在しないと判定した場合（Ｓ２０６否定）、処理を終了する。また、処理型判定部２７は、Ｓ２０７で未定義処理の処理型が判定された場合にも処理を終了する。
【００８９】
［実施例１による効果］
このように、実施例１に係る自動判定装置２０は、利用者がデータの性質の違いを意識することなく、フロー定義で利用したいコンポーネントやデータを配置し、いずれか一つの要素の型を定義するだけで自動的にコンポーネントの型を判定することができる。そして、自動判定装置２０は、判定した型に応じたクエリ定義やSCA定義を含むアセンブリを生成することができる。また、自動判定装置２０は、いずれの型でも動作可能なコンポーネントを用意することで、処理型が違うことに起因するコンポーネントの種類の数を半減させることができる。
【００９０】
したがって、分析者などのプログラムに精通していないユーザは、いずれの型でも動作するコンポーネントとして、入力データをどう加工するものなのかという処理内容の違いだけを意識すればよく、簡単にフロー定義を生成することができる。つまり、ユーザは、数多あるコンポーネントから処理型は何ら考慮することなく処理内容の違いだけを意識して必要なコンポーネントを選択してフローを作成することができる。例えば、バッチ処理とオンライン処理とで同一のフロー定義を使うといったフロー編集作業が可能となり、プログラム作成の負荷が軽減され、開発効率を向上させることが出来る。また、バッチ処理またはリアルタイム処理の両方の処理型で利用可能な任意のデータまたはコンポーネントを要素として用い、フロー内で１つの要素の型を指定すれば残りの要素の型を自動判定することもでき、プログラム作成や処理型の変更の負荷をより軽減することができる。
【００９１】
また、ユーザは、開発者等に依頼することなく、簡単なプログラム等を自分で生成することができるので、近年の早いビジネススピードに遅れることなく、経営戦略の分析などスピードが要求される各種対応を迅速に処理することができる。
【実施例２】
【００９２】
実施例１では、未定義処理の処理型を当該未定義処理の直前の処理と同じ処理型と判定された例について説明したが、実施例２では、未定義処理の処理型を当該未定義処理の直前の処理と異なる処理型と判定された例について説明する。
【００９３】
図２６は、処理型判定の結果によって処理型が異なった例１を示す図である。図２６に示すように、フロー定義受付部２６が、「蓄積データ」−「駅での絞り込み処理」−「イベントデータ」が定義されたフロー定義を受け付けたとする。この場合、「駅での絞り込み処理」の処理型が直後の「イベントデータ」と同じ「イベント処理型」すなわち「リアルタイム処理型」と判定される。つまり、「駅での絞り込み処理」の直前の「蓄積データ」の処理型が「バッチ処理型」であるので、「駅での絞り込み処理」と「蓄積データ」との処理型が異なることとなる。
【００９４】
この場合、図２６に示すように、アセンブリ自動生成部２８は、「蓄積データ」と「駅での絞り込み処理」との間に、「蓄積データ」に対して「イベント送信処理を実行し、その結果をキューに格納する」処理を埋め込む。このようにデータ変換処理を実施することで、「リアルタイム処理型」と判定された「駅での絞り込み処理」へ入力されるデータの型が「リアルタイム処理型」となり、「駅での絞り込み処理」が実行可能な処理となる。
【００９５】
一例を挙げると、生成部２８は、データ変換処理として「イベント送信処理を実行し、その結果をキューに格納する」処理を実行するアセンブリを生成する。図２７は、自動判定装置が生成する、蓄積データのイベント送信を実行する実行用アセンブリの例を示す図である。図２７に示すコンポーネントには、アセンブリを実行するJava（登録商標）クラスとして「example.ExecuteHiveQuery」が定義される。また、このコンポーネントは、「sca:property name＝”HiveQL”」タグの値に「select * from data1」が定義され、「data1」に格納されている全イベントデータを「destination」タグに定義される「data2」キューに送信するクエリを実行する。
【００９６】
さらに、生成部２８は、図２６の下図に示す「データ変換処理」と「駅での絞り込み処理」とを実行するアセンブリを生成する。図２８は、自動判定装置が生成する、蓄積データの絞込みを実行する実行用アセンブリの例を示す図である。図２８に示すコンポジットには、「ExcuteHiveQuery」コンポーネントのJava（登録商標）クラスとして「example.ExecuteHiveQuery」が定義され、「sca:property nama＝”HiveQL”」タグの値に「select * from data1」が定義される。この結果、このコンポジットは、「data1」に格納されている全イベントデータを「destination」に定義される「data2」キューに送信するクエリを実行する。
【００９７】
また、図２８に示すこのコンポジットは、「EsperProcessor」コンポーネントのJava（登録商標）クラスとして「example.EsperProcessor」が定義され、「data2」に格納されたイベントデータの絞り込みを行うクエリを実行する。そして、このコンポジットは、上記「ExecuteHiveQuery」コンポーネントと「EsperProcessor」コンポーネントとを接続する「wire」要素を定義する。このようにして、生成部２８は、「ExecuteHiveQuery」と「EsperProcessor」との各々を連携して実行させるコンポジットを作成する。
【００９８】
図２９は、処理型判定の結果によって処理型が異なった例２を示す図である。図２９に示すように、フロー定義受付部２６が、「イベントデータ」−「駅での絞り込み処理」−「蓄積データ」が定義されたフロー定義を受け付けたとする。この場合、「駅での絞り込み処理」の処理型が直後の「蓄積データ」と同じ「蓄積処理型」すなわち「バッチ処理型」と判定される。つまり、「駅での絞り込み処理」の直前の「イベントデータ」の処理型が「リアルタイム処理型」であるので、「駅での絞り込み処理」と「イベントデータ」との処理型が異なることとなる。
【００９９】
この場合、図２９に示すように、アセンブリ自動生成部２８は、「イベントデータ」と「駅での絞り込み処理」との間に、「イベントデータ」に対して「データ蓄積処理を実行し、その結果をデータベースに格納する」処理を埋め込む。このようにデータ変換処理を実施することで、「バッチ処理型」と判定された「駅での絞り込み処理」へ入力されるデータの型が「バッチ処理型」となり、「駅での絞り込み処理」が実行可能な処理となる。
【０１００】
そして、生成部２８は、データ変換処理として「データ蓄積処理を実行し、その結果をデータベースに格納する」処理を実行するアセンブリを生成する。図３０は、自動判定装置が生成する、データの蓄積および通知を実行する実行用アセンブリの例を示す図である。図３０に示すコンポーネントには、アセンブリを実行するJava（登録商標）クラスとして「example.StoreEventDataIntoHdfs」が定義される。また、当該コンポーネントは、「sca:property」タグに「hdfsPath」や「hdfsUri」が定義され、data1から出力されるイベントデータを「data2」に蓄積する処理を実行する。
【０１０１】
次に、上述したアセンブリを実行するコンポーネント例について説明する。図３１は、処理実行装置が記憶する、蓄積データを送信するコンポーネントの実装例を示す図である。図３１に示すように、処理実行装置４０は、「boolean res = hiveStatement.execute（hiveQL）」が定義され、図２７に示したHiveクエリを実行するコンポーネントを記憶する。図３２は、処理実行装置が記憶する、イベントデータを蓄積するコンポーネントの実装例を示す図である。図３２に示すコンポーネントは、Hadoop上でHDFSへのアクセスを定義し、取得したイベントデータを蓄積することが定義される。
【０１０２】
このように、実施例２に係る自動判定装置２０は、フロー定義に記述される処理において、前後の処理で処理型が異なる場合でも、データの型を変換する変換処理を挿入して、フロー定義に記述される処理を実行させるプログラムを作成することができる。したがって、ユーザが、処理型の繋がりなどプログラムの知識がなくてもフロー定義を作成すればよく、ユーザの負担が軽減する。
【０１０３】
また、蓄積されたデータの分析で用いたフィルタやパラメータなどを、ストリーム処理に流用できる。また、蓄積されたイベントデータに対して、ストリーム処理を行った結果を擬似的にシミュレートできる。また、イベントの到着間隔に応じてストリーム処理を停止することで、サービスの運用コストを下げることができる。
【実施例３】
【０１０４】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【０１０５】
（テンプレート）
例えば、上記実施例では、Hiveクエリ、EPL、SCA等のテンプレートを用いる例を説明したが、これらはあくまで例示であり、開示する自動判定装置を限定するものではない。例えば、公知の様々なプログラム言語を用いることができ、開示する自動判定装置のみで使用するプログラム言語等を用いることもできる。
【０１０６】
また、上記実施例では、テンプレートを変換したクエリをSCA定義に埋め込む方式を例にして説明したが、これに限定されるものではない。例えば、両方のクエリをSCA定義に組み込んでおき、使用しない方のクエリをコメント文に変更するなどして、一方のクエリを実行させることもできる。
【０１０７】
（処理型）
また、上記実施例で説明したバッチ処理は、いわゆる蓄積処理であり、データを一定期間蓄積して蓄積されたデータに対して所望の処理を実行する処理型を例示したものである。また、リアルタイム処理型は、いわゆるストリーム処理であり、データが入力されるごとに所望の処理を実行する処理型を例示したものである。
【０１０８】
（システム）
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１０９】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１１０】
（プログラム）
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。
【０１１１】
図３３は、処理型判定プログラムを実行するコンピュータのハードウェア構成の例を示す図である。図３３に示すように、コンピュータ１００は、ＣＰＵ１０２、入力装置１０３、出力装置１０４、通信インタフェース１０５、媒体読取装置１０６、ＨＤＤ（Hard Disk Drive）１０７、ＲＡＭ（Random Access Memory）１０８を有する。また、図７に示した各部は、バス１０１で相互に接続される。
【０１１２】
入力装置１０３は、マウスやキーボードであり、出力装置１０４は、ディスプレイなどであり、通信インタフェース１０５は、ＮＩＣ（Network Interface Card）などのインタフェースである。ＨＤＤ１０７は、処理型判定プログラム１０７ａととともに、図３に示した記憶部に記憶される各情報を記憶する。記録媒体の例としてＨＤＤ１０７を例に挙げたが、ＲＯＭ（Read Only Memory）、ＲＡＭ、ＣＤ−ＲＯＭ等の他のコンピュータ読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記憶媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身の記録媒体に格納して用いてもよい。
【０１１３】
ＣＰＵ１０２は、処理型判定プログラム１０７ａを読み出してＲＡＭ１０８に展開することで、図１等で説明した各機能を実行する処理型判定プロセス１０８ａを動作させる。すなわち、処理型判定プロセス１０８ａは、図３に記載したフロー定義受付部２６、処理型判定部２７、アセンブリ自動生成部２８、テンプレート変換部２８ａ、生成部２８ｂと同様の機能を実行する。このようにコンピュータ１００は、プログラムを読み出して実行することで処理型判定方法を実行する情報処理装置として動作する。
【０１１４】
例えば、コンピュータ１００は、媒体読取装置１０６によって記録媒体から処理型判定プログラム１０７ａを読み出し、読み出された処理型判定プログラム１０７ａを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、コンピュータ１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
【符号の説明】
【０１１５】
１ クライアント装置
５ イベント通知装置
１０ イベント処理システム
２０ 自動判定装置
２１ 通信制御Ｉ／Ｆ部
２２ａ 作業領域
２２ｂ テンプレート記憶部
２２ｃ コンポーネントリポジトリ記憶部
２２ｄ アセンブリ記憶部
２５ 制御部
２６ フロー定義受付部
２７ 処理型判定部
２８ アセンブリ自動生成部
２８ａ テンプレート変換部
２８ｂ 生成部
４０ 処理実行装置
４１ 通信制御Ｉ／Ｆ部
４２ａ イベント記憶部
４２ｂ アセンブリ記憶部
４２ｃ 実行プログラム記憶部
４５ 制御部
４５ａ イベントデータ受信部
４５ｂ アセンブリ受信部
４５ｃ イベント処理部
【特許請求の範囲】
【請求項１】
入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、前記バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部と、
少なくとも前記記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける受付部と、
前記受付部によって受け付けられたフロー定義に記述される前記処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から前記処理型が定義された要素を検索し、検索された要素の処理型を前記未定義のコンポーネントの処理型と判定する判定部と
を有することを特徴とする自動判定装置。
【請求項２】
前記判定部は、前記フロー定義に記述される前記処理型が未定義のコンポーネントについて、前記フロー定義において該コンポーネントより後段に記述される要素から前記処理型が定義された要素を検索し、検索できなかった場合に、前記フロー定義において該コンポーネントより前段に記述される要素から前記処理型が定義された要素を検索することを特徴とする請求項１に記載の自動判定装置。
【請求項３】
前記特定された処理型の処理を実行するクエリを前記コンポーネントに挿入して、前記受付部によって受け付けられたフロー定義で定義される処理を実行するアセンブリを生成する生成部をさらに有することを特徴とする請求項１または２に記載の自動判定装置。
【請求項４】
前記判定部によって判定された前記未定義のコンポーネントの処理型が、該コンポーネントにデータを入力する要素の処理型と異なる場合に、当該要素で処理されたデータの性質を前記判定された処理型に変換するコンポーネントを、前記未定義のコンポーネントと前記未定義のコンポーネントにデータを入力する要素との間に挿入する挿入部をさらに有することを特徴とする請求項１または２に記載の自動判定装置。
【請求項５】
前記特定された処理型の処理を実行するクエリを前記コンポーネントに挿入し、当該コンポーネントと前記挿入されたコンポーネントとを組み合わせて、前記受付部によって受け付けられたフロー定義で定義される処理を実行するアセンブリを生成する生成部をさらに有することを特徴とする請求項４に記載の自動判定装置。
【請求項６】
コンピュータが、
少なくとも、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、前記バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付け、
前記受け付けられたフロー定義に記述される前記処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から前記処理型が定義された要素を検索し、検索された要素の処理型を前記未定義のコンポーネントの処理型と判定する
ことを含んだことを特徴とする処理型判定方法。
【請求項７】
コンピュータが、
少なくとも、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、前記バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付け、
前記受け付けたフロー定義に記述される前記処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から前記処理型が定義された要素を検索し、検索された要素の処理型を前記未定義のコンポーネントの処理型と判定する
処理を実行させることを特徴とする処理型判定プログラム。
【請求項１】
入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、前記バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部と、
少なくとも前記記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける受付部と、
前記受付部によって受け付けられたフロー定義に記述される前記処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から前記処理型が定義された要素を検索し、検索された要素の処理型を前記未定義のコンポーネントの処理型と判定する判定部と
を有することを特徴とする自動判定装置。
【請求項２】
前記判定部は、前記フロー定義に記述される前記処理型が未定義のコンポーネントについて、前記フロー定義において該コンポーネントより後段に記述される要素から前記処理型が定義された要素を検索し、検索できなかった場合に、前記フロー定義において該コンポーネントより前段に記述される要素から前記処理型が定義された要素を検索することを特徴とする請求項１に記載の自動判定装置。
【請求項３】
前記特定された処理型の処理を実行するクエリを前記コンポーネントに挿入して、前記受付部によって受け付けられたフロー定義で定義される処理を実行するアセンブリを生成する生成部をさらに有することを特徴とする請求項１または２に記載の自動判定装置。
【請求項４】
前記判定部によって判定された前記未定義のコンポーネントの処理型が、該コンポーネントにデータを入力する要素の処理型と異なる場合に、当該要素で処理されたデータの性質を前記判定された処理型に変換するコンポーネントを、前記未定義のコンポーネントと前記未定義のコンポーネントにデータを入力する要素との間に挿入する挿入部をさらに有することを特徴とする請求項１または２に記載の自動判定装置。
【請求項５】
前記特定された処理型の処理を実行するクエリを前記コンポーネントに挿入し、当該コンポーネントと前記挿入されたコンポーネントとを組み合わせて、前記受付部によって受け付けられたフロー定義で定義される処理を実行するアセンブリを生成する生成部をさらに有することを特徴とする請求項４に記載の自動判定装置。
【請求項６】
コンピュータが、
少なくとも、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、前記バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付け、
前記受け付けられたフロー定義に記述される前記処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から前記処理型が定義された要素を検索し、検索された要素の処理型を前記未定義のコンポーネントの処理型と判定する
ことを含んだことを特徴とする処理型判定方法。
【請求項７】
コンピュータが、
少なくとも、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、前記バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付け、
前記受け付けたフロー定義に記述される前記処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から前記処理型が定義された要素を検索し、検索された要素の処理型を前記未定義のコンポーネントの処理型と判定する
処理を実行させることを特徴とする処理型判定プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【公開番号】特開２０１２−２４７９５５（Ｐ２０１２−２４７９５５Ａ）
【公開日】平成２４年１２月１３日（２０１２．１２．１３）
【国際特許分類】
【出願番号】特願２０１１−１１８４９２（Ｐ２０１１−１１８４９２）
【出願日】平成２３年５月２６日（２０１１．５．２６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２４年１２月１３日（２０１２．１２．１３）
【国際特許分類】
【出願日】平成２３年５月２６日（２０１１．５．２６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]