入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、前記バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部と、少なくとも前記記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける受付部と、前記受付部によって受け付けられたフロー定義に記述される前記処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から前記処理型が定義された要素を検索し、検索された要素の処理型を前記未定義のコンポーネントの処理型と判定する判定部とを有することを特徴とする自動判定装置。前記判定部は、前記フロー定義に記述される前記処理型が未定義のコンポーネントについて、前記フロー定義において該コンポーネントより後段に記述される要素から前記処理型が定義された要素を検索し、検索できなかった場合に、前記フロー定義において該コンポーネントより前段に記述される要素から前記処理型が定義された要素を検索することを特徴とする請求項1に記載の自動判定装置。前記特定された処理型の処理を実行するクエリを前記コンポーネントに挿入して、前記受付部によって受け付けられたフロー定義で定義される処理を実行するアセンブリを生成する生成部をさらに有することを特徴とする請求項1または2に記載の自動判定装置。前記判定部によって判定された前記未定義のコンポーネントの処理型が、該コンポーネントにデータを入力する要素の処理型と異なる場合に、当該要素で処理されたデータの性質を前記判定された処理型に変換するコンポーネントを、前記未定義のコンポーネントと前記未定義のコンポーネントにデータを入力する要素との間に挿入する挿入部をさらに有することを特徴とする請求項1または2に記載の自動判定装置。前記特定された処理型の処理を実行するクエリを前記コンポーネントに挿入し、当該コンポーネントと前記挿入されたコンポーネントとを組み合わせて、前記受付部によって受け付けられたフロー定義で定義される処理を実行するアセンブリを生成する生成部をさらに有することを特徴とする請求項4に記載の自動判定装置。コンピュータが、少なくとも、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、前記バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付け、前記受け付けられたフロー定義に記述される前記処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から前記処理型が定義された要素を検索し、検索された要素の処理型を前記未定義のコンポーネントの処理型と判定することを含んだことを特徴とする処理型判定方法。コンピュータが、少なくとも、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、前記バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付け、前記受け付けたフロー定義に記述される前記処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から前記処理型が定義された要素を検索し、検索された要素の処理型を前記未定義のコンポーネントの処理型と判定する処理を実行させることを特徴とする処理型判定プログラム。しかしながら、従来の技術では、コンポーネントを用いることでプログラム作成が容易になったとはいえ、プログラムに精通していないユーザにとっては依然として難しく、容易にプログラムを作成できないという問題がある。例えば、コンポーネントを利用してプログラムを作成する場合、作成対象の処理がバッチ処理かリアルタイム処理かを正しく理解した上でなければ、フロー定義を作成することができない。したがって、プログラムに精通していないユーザにとっては、フロー定義の作成そのものが難しい。一例を挙げると、システムやプログラムに精通していない分析者が、システムで処理されるデータに対して所望の分析を実行するプログラムを作成する場合を想定する。この場合、分析者は、どのような分析処理を実行させるのかを決定することはできても、バッチ処理かリアルタイム処理かの違いを意識した上で、決定した処理をどのように実行させるのかまで決定するのは難しく、正しいフロー定義を生成するのは難しい。また、バッチ処理での分析に用いるデータと、分析結果の反映対象のリアルタイム処理に反映されるデータとが、必要なデータや項目といった条件が同じ場合を想定する。この場合でも、バッチ処理とリアルタイム処理それぞれのフロー定義手法に則り、それぞれコンポーネントを用意し、正しく組み合わせてそれぞれに異なるフロー定義を行わなければ正常に動作可能なプログラムが作成できない。また、分析者が、システムやプログラムに精通する開発者に所望の処理を実行するプログラムの生成を依頼することも考えられる。しかし、分析者と開発者とは、部署が異なったり会社が異なったりすることが一般的である。このため、分析者が、開発者にプログラム作成依頼を行って所望のプログラムを得るまでに、関係各所との調整、発注のための書類作成、発注処理、開発者の作業などいくつかのステップを要するので時間がかかる。したがって、経営に関係する情報など早急な対応が要求される場合には、この方法を用いることは現実的ではない。また、ビジネスのスピードが速い近年では、この手法を用いる機会も少なく、利用価値が高いものでもない。開示の技術は、上記に鑑みてなされたものであって、バッチ処理かリアルタイム処理かの違いを意識することなく容易にプログラムを作成することができる自動判定装置、処理型判定方法および処理型判定プログラムを提供することを目的とする。本願の開示する自動判定装置、処理型判定方法および処理型判定プログラムは、一つの態様において、以下の処理部を有する。本願の開示する自動判定装置は、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、前記バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する記憶部を有する。本願の開示する自動判定装置は、少なくとも前記記憶部に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける受付部を有する。本願の開示する自動判定装置は、前記受付部によって受け付けられたフロー定義に記述される前記処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から前記処理型が定義された要素を検索する。そして、本願の開示する自動判定装置は、検索された要素の処理型を前記未定義のコンポーネントの処理型と判定する。本願の開示する自動判定装置、処理型判定方法および処理型判定プログラムの一つの態様によれば、バッチ処理かリアルタイム処理かの違いを意識することなく容易にプログラムを作成することができるという効果を奏する。以下に、本願の開示する自動判定装置、処理型判定方法および処理型判定プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。実施例1では、開示する自動判定装置を含むシステムの全体構成、システムが有する各装置の構成、処理の流れを説明する。なお、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。[全体構成]図1は、システムの全体構成例を示す図である。図1に示すように、このシステムは、クライアント装置1と、イベント通知装置5と、イベント処理システム10とを有する。また、クライアント装置1とイベント処理システム10とがネットワークなどを介して接続され、同様に、イベント通知装置5とイベント処理システム10とがネットワークなどを介して接続される。クライアント装置1は、プログラム作成者が使用するコンピュータであり、Webブラウザを用いてイベント処理システム10の自動判定装置20にアクセスする。そして、クライアント装置1は、自動判定装置20から受信したWeb画面上で、入出力データおよびコンポーネントを要素とするフロー定義の作成や編集を実行する。なお、このクライアント装置1は、パーソナルコンピュータに限ったものではなく、例えばスマートフォンやPDAPersonalDigitalAssistant端末も使用することができる。イベント通知装置5は、図示しないサーバ等から継続的にイベントを受信して、継続的にイベント処理システム10に通知するサーバ装置である。一例を挙げると、イベント通知装置5は、各駅の改札口の出入り情報を管理する管理サーバから、出入り情報をイベントとして受信してイベント処理システム10に通知する。なお、ここでは、駅の出入り情報を例にしたが、これに限定されるものではなく、例えばシステム監視ログなど様々な情報を用いることができる。イベント処理システム10は、自動判定装置20と処理実行装置40とを有し、クライアント装置1から受け付けたフロー定義に基づいてプログラムを自動生成し、生成したプログラムを実行して所望の結果を得るシステムである。ここでは、自動判定装置20と処理実行装置40とが別々の筐体で実現される場合で説明するが、これに限定されるものではなく、1つの筐体で実現することもでき、3つ以上の筐体に機能を分割してもよい。自動判定装置20は、クライアント装置1からフロー定義を受け付けてプログラムを自動生成し、生成したプログラムを処理実行装置40に出力するサーバ装置である。ここで、自動判定装置20が有するコンポーネントについて説明する。図2は、複数の処理方式に対応したコンポーネントの例を示す図である。図2に示すように、ここでは、イベントデータを記憶するデータベースから、フィールドAが値aのデータを絞り込むコンポーネントを例にしている。そして、蓄積されたイベントデータは、例えばHadoop上に格納され、Hiveでアクセス可能とした場合、Hiveでデータの絞り込みを行う。また、リアルタイムなイベントデータを絞り込む場合は、ここではJMSキューに格納されたイベントデータを順次Esperエンジンを使って次のキューにデータを受け渡すことを想定する。このような自動判定装置20は、入力データに対するバッチ処理またはリアルタイム処理各々の加工処理を含み、バッチ処理またはリアルタイム処理の処理型が未指定であるコンポーネントを記憶する。そして、自動判定装置20は、少なくとも記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける。その後、自動判定装置20は、受け付けられたフロー定義に記述される処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から処理型が定義された要素を検索する。そして、自動判定装置20は、検索された要素の処理型を未定義のコンポーネントの処理型と判定する。このようにすることで、自動判定装置20は、どのような処理を実行したいかを示したフロー定義からプログラムを自動生成し、生成したプログラムを処理実行装置40に出力する。処理実行装置40は、自動判定装置20から入力されたプログラムを実行して所望の結果を取得し、取得した結果をクライアント装置1に応答するサーバ装置である。例えば、処理実行装置40は、イベントデータを所定数または所定時間蓄積した後に、蓄積したイベントデータ以下、蓄積データと表記するから所望のデータを絞り込んで抽出するバッチ処理を実行する。また、処理実行装置40は、自動判定装置20からイベントデータを受信するたびに、当該イベントデータをフィルタリングして絞り込むリアルタイム処理を実行する。このように、自動判定装置20は、バッチ処理かリアルタイム処理かを意識することなく作成したフロー定義を受信した場合でも、当該フロー定義で定義されるコンポーネントの処理型を自動で判定することができる。この結果、プログラムやシステムに精通していないユーザであっても、バッチ処理かリアルタイム処理かの違いを意識することなく容易にプログラムを作成することができる。[装置の構成]次に、図1に示した自動判定装置20と処理実行装置40の構成について説明する。なお、図1に示したクライアント装置1は一般的なパーソナルコンピュータと同様の構成を有し、イベント通知装置5も一般的なイベント通知処理と同様の構成を有するので、詳細な説明は省略する。自動判定装置の構成図3は、自動判定装置の構成を示す機能ブロック図である。図3に示すように、自動判定装置20は、通信制御I/F部21と、作業領域22aと、テンプレート記憶部22bと、コンポーネントリポジトリ記憶部22cと、アセンブリ記憶部22dと、制御部25とを有する。なお、各記憶部は、例えば半導体メモリ素子やハードウェアなどの記憶装置である。制御部25は、例えばCPUCentralProcessingUnitなどの電子回路やFPGAFieldProgrammableGateArrayなどの集積回路である。通信制御I/F部21は、例えばNICNetworkInterfaceCardなどのように、他の装置と通信を制御するインタフェースである。例えば、通信制御I/F部21は、クライアント装置1からWebアクセスを受け付けると、クライアント装置1と自動判定装置20との間にコネクションを確立して、フロー定義を受け付ける。また、通信制御I/F部21は、制御部25によって作成されたプログラムを処理実行装置40に出力する。作業領域22aは、制御部25の各処理部が処理を実行する際に、データ等の処理途中結果を一時的に格納する領域である。テンプレート記憶部22bは、蓄積データに対して絞り込みを実行するクエリのテンプレートやイベントデータに対して絞り込みを実行するクエリのテンプレートを記憶する。また、テンプレート記憶部22bは、クエリを埋め込む各SCAServiceComponentArchitectureテンプレートも記憶する。なお、テンプレート記憶部22bは、各テンプレートに識別子やテンプレート名を付与し、テンプレートと識別子等を対応付けて格納することで各テンプレートを区別する。図4は、テンプレート記憶部に記憶されるHiveクエリのテンプレート例を示す図である。図4に示すように、このHiveクエリのテンプレートは、fieldで示す特定のフィールドカラムがequalsで示す特定の値であるデータをinput1で示す入力テーブルから抽出してoutput1で示す出力テーブルに書き込むことが記述されたクエリである。図5は、テンプレート記憶部に記憶されるEPLのテンプレート例を示す図である。図5に示すように、このEPLのテンプレートは、fieldで示す特定のフィールドがequalsで示す特定の値であるデータをinput1で示すキューから抽出することが記述されたクエリである。また、図6は、テンプレート記憶部に記憶されるEsperによる絞込み処理のテンプレート例を示す図である。この図6は、SCA定義による実行可能なアセンブリを生成するためのテンプレートである。図6に示すように、このテンプレートは、入出力データ名をキュー名として利用し、テンプレートで生成したクエリを属性として埋め込み、コンポーネント1つを含むコンポジットとして生成する。コンポーネントリポジトリ記憶部22cは、フロー定義で定義された処理を管理する処理管理情報と、処理とコンポーネントと対応付けたコンポーネント管理情報とを記憶する。図7は、コンポーネントリポジトリ記憶部に記憶される処理管理情報の例を示す図である。図7に示すように、コンポーネントリポジトリ記憶部22cは、処理管理情報としてID、処理名、処理型を対応付けて記憶する。ここで記憶されるIDは、処理を識別する識別子であり、処理名は、フロー定義で定義される処理の名称であり、処理型は、処理名に格納される処理が実行可能な処理型を示す。図7の場合、IDが01である処理名値範囲指定は、ストリーム処理または蓄積処理の両方が実行可能である、すなわち、リアルタイム処理またはバッチ処理が実行可能であることを示す。同様に、IDが02である処理名値指定は、ストリーム処理または蓄積処理の両方が実行可能であることを示し、IDが03である処理名値集計は、蓄積処理のみが実行可能であることを示す。図8は、コンポーネントリポジトリ記憶部に記憶されるコンポーネント管理情報の例を示す図である。図8に示すように、コンポーネントリポジトリ記憶部22cは、コンポーネント管理情報としてID、処理ID、処理型、コンポーネント名、クエリテンプレート、SCAテンプレートを対応付けて記憶する。ここで記憶されるIDは、コンポーネントを識別する識別子であり、処理IDは、処理管理情報のコンポーネントに対応する処理のIDであり、コンポーネント名は、コンポーネントの名称である。クエリテンプレートは、SCAテンプレートに埋め込むクエリのテンプレートのファイル名などの識別子や名称であり、SCAテンプレートは、クエリを埋め込む対象のSCA定義が記述されたテンプレートのファイル名などの識別子や名称である。図8を例にして具体例を説明する。ID01が割り与えられたコンポーネント名StreamFilterは、処理ID01の値範囲指定をストリーム処理で実行するコンポーネントであり、SCAテンプレート01scavmにクエリテンプレート01queryvmを用いて生成したクエリを埋め込んで生成されることを示す。同様に、ID02が割り与えられたコンポーネント名AccumulateFilterは、処理ID01の値範囲指定を蓄積処理で実行するコンポーネントであり、SCAテンプレート02scavmにクエリテンプレート02queryvmを用いて生成したクエリを埋め込んで生成されることを示す。アセンブリ記憶部22dは、制御部25によって生成された、SCAによる実行可能なアセンブリを記憶する。すなわち、アセンブリ記憶部22dは、クライアント装置1によって生成されたフロー定義を実行するコンポーネントを組み合わせたアセンブリを記憶する。制御部25は、フロー定義受付部26と処理型判定部27とアセンブリ自動生成部28とを有し、これらによって、クライアント装置1から受け付けたフロー定義に基づいて実行可能なアセンブリを生成する処理部である。フロー定義受付部26は、少なくともコンポーネントリポジトリ記憶部22c等に記憶されたコンポーネント及び入出力データを要素として記述されたフロー定義を受け付ける処理部である。例えば、フロー定義受付部26は、クライアント装置1からフロー定義を作成または編集を実行するWebアクセスを受け付けた場合に、通信制御I/F部21を介して、フロー定義編集画面をクライアント装置1に送信する。そして、フロー定義受付部26は、フロー定義編集画面でフロー定義の作成や編集を受け付けて、受け付けた情報を作業領域22aに格納する。図9は、フロー定義編集画面の例を示す図である。フロー定義受付部26は、図9に示すフロー定義編集画面をクライアント装置1に送信して、フロー定義の編集作業を受け付ける。クライアント装置1は、図9に示すフロー定義編集画面の画面左にあるクラスタID追加や距離計算などの処理プロセスをドラックアンドドロップで中央に移動させてフロー定義を作成する。このフロー定義では、ドラム缶や四角で表すデータを入力として、丸アクティビティで表す処理を行い、データを出力する。最初の入力となるデータについては、処理型を蓄積型バッチ処理型かストリーム型リアルタイム処理型かのどちらかとして指定し、その他の処理やデータについては、必要であれば処理型を指定する。なお、ここで作成されるフロー定義としては、例えばDFDDataFlowDiagramなどがある。また、図9の例では、キュー1からイベントデータを読み出して、値範囲指定のフィルター処理を実行し、実行した結果をキュー2に出力するフロー定義が図示されている。そして、フロー定義受付部26は、クライアント装置1によるフロー定義作成が終了した場合、作成されたフロー定義を例えばXMLExtensibleMarkupLanguage形式などに変換して作業領域22aに格納する。図10は、フロー定義の保存形式の例を示す図である。図10に示すように、データdataと処理processについてはbehavior属性として処理型を保存しており、処理に対応するXMLタグからは、入出力となるデータに対応するIDが属性として保存される。なお、ここでは、XML形式で保存する例で説明したが、保存形式はXMLに限定されるものではなく、任意の保存形式を用いることができる。図3に戻り、処理型判定部27は、フロー定義受付部26によってフロー定義が作業領域22aに格納されたことを検出する。すると、処理型判定部27は、フロー定義受付部26によって受け付けられたフロー定義に記述される処理型が未定義のコンポーネントについて、該コンポーネントの前後に記述される要素から処理型が定義された要素を検索する。そして、処理型判定部27は、検索された要素の処理型を未定義のコンポーネントの処理型と判定する処理部である。また、処理型判定部27は、判定した結果をアセンブリ自動生成部28に出力する。ここで、図11と図12を用いて処理型判定の例を説明する。図11と図12は、処理型の判定例を示す図である。図11は、フロー定義受付部26によって受け付けられたフロー定義をDFDで表した図である。すなわち、クライアント装置1は、鉄道イベントを記憶するデータベースの蓄積データを入力データとして、処理型が未判定の駅での絞り込み処理を実行し、処理型が未判定の鉄道イベントを出力するフロー定義を作成したとする。この場合、処理型判定部27は、処理型判定対象が駅での絞り込み処理であり、当該処理の後続の鉄道イベントが未判定であり、当該処理の前方の入力データが蓄積データであることを特定する。そして、処理型判定部27は、駅での絞り込み処理および当該処理の後続の鉄道イベント各々の処理型を蓄積型すなわちバッチ処理型と判定する。同様に、図12に示した図は、フロー定義受付部26によって受け付けられたフロー定義をDFDで表した図である。すなわち、クライアント装置1は、鉄道イベントを記憶するキューのイベントデータを入力データとして、処理型が未判定の駅での絞り込み処理を実行し、処理型が未判定の鉄道イベントを出力するフロー定義を作成したとする。この場合、処理型判定部27は、処理型判定対象が駅での絞り込み処理であり、当該処理の後続の鉄道イベントが未判定であり、当該処理の前方の入力データがイベントデータであることを特定する。そして、処理型判定部27は、駅での絞り込み処理および当該処理の後続の鉄道イベント各々の処理型をイベント処理型すなわちリアルタイム処理型と判定する。具体的な判定の一例として、図10に示したフロー定義がXML形式で作業領域22aに格納された場合を例にして説明する。この場合、処理型判定部27は、XML形式で格納されるフロー定義から、behavior属性がDefineLaterのprocessタグを検索する。そして、処理型判定部27は、該当するprocessタグが検索できた場合には、処理型が未定義のコンポーネントが存在すると判定する。続いて、処理型判定部27は、検索したprocessの直後のデータの型として、当該processのoutputdataに対応するdataタグのbehavior属性を参照する。そして、処理型判定部27は、参照したdataタグのbehavior属性がaccumulateであれば、当該processの処理型を蓄積処理型すなわちバッチ処理型と特定する。また、処理型判定部27は、参照したdataタグのbehavior属性がstreamであれば、当該processの処理型をストリーム処理型すなわちリアルタイム処理型と特定する。一方、処理型判定部27は、参照したdataタグのbehavior属性がdefinelaterであれば、processのinputdataに対応するdataタグのbehavior属性を参照して、上述した処理と同様の処理を実行する。また、処理型判定部27は、検索したprocessの後続のdataやprocessのbehavior属性が全部definelaterである場合に、検索したprocessの直前のdataについて同様の処理を実行する。つまり、処理型判定部27は、処理型判定対象のprocessの後続の要素から処理型が特定できなかった場合に、処理型判定対象のprocessの直前の要素から前方に向かって順に処理型を参照する。そして、処理型判定部27は、definelater以外を検索した場合に、検索されたbehavior属性を、処理型判定対象のprocessの処理型と判定する。なお、ここでは、判定対象のprocessの後続の要素から順に検索する場合を例にしたが、これに限定されるものではなく、例えば判定対象のprocessの前の要素から順に検索するなど、検索順序は任意に設定変更することができる。図3に戻り、アセンブリ自動生成部28は、テンプレート変換部28aと生成部28bとを有し、特定された処理型の処理を実行するクエリをコンポーネントに挿入する。そして、アセンブリ自動生成部28は、フロー定義受付部26によって受け付けられたフロー定義で定義される処理を実行するアセンブリを生成する処理部である。このアセンブリ自動生成部28は、処理型判定部27によって処理型が判定されたコンポーネント、言い換えると、処理型が特定された処理の名称をDFDまたはXMLから特定する。そして、アセンブリ自動生成部28は、例えば図9の値範囲指定のように、特定した処理の名称に対応する処理IDをコンポーネントリポジトリ記憶部22cから特定する。続いて、アセンブリ自動生成部28は、特定した処理IDと処理型判定部27から通知された処理型とに基づいて、SCAテンプレートの識別子とクエリテンプレートの識別子とを特定する。その後、アセンブリ自動生成部28は、特定したクエリテンプレートの識別子をテンプレート変換部28aに通知し、SCAテンプレートの識別子を生成部28bに通知する。例えば、処理型が特定された処理の名称が値範囲指定であり、特定された処理型が蓄積処理型である場合を例にして説明する。この場合、アセンブリ自動生成部28は、図7の記憶部を参照して値範囲指定に対応する処理IDが01であることを特定する。続いて、アセンブリ自動生成部28は、図8の記憶部を参照し、処理ID01と処理型蓄積との組み合わせが記憶されるレコードがID02のレコードであることを特定する。そして、アセンブリ自動生成部28は、特定したレコードのクエリテンプレートに格納される02queryvmをテンプレート変換部28aに通知し、SCAテンプレート格納される02scavmを生成部28bに通知する。テンプレート変換部28aは、フロー定義受付部26によって受け付けられたフロー定義にしたがって、アセンブリ自動生成部28から通知されたクエリテンプレートを変換する処理部である。そして、テンプレート変換部28aは、変換したクエリを生成部28bに出力する。ここで、図13と図14を用いてクエリテンプレートの変換例を説明する。図13は、Hiveクエリテンプレートの変換例を示す図である。図13に示すように、この例では、フロー定義として、データベースの蓄積データを入力データdata1として、駅での絞り込み処理を実行し、出力データをdata2としてデータベースに格納することが定義されている。すなわち、図13に示した全要素はいずれもバッチ処理型に該当する。また、この駅での絞り込み処理に、プロパティとして、Field=station、value=1が与えられたとする。その場合、テンプレート変換部28aは、図13に示すように、図4に示したHiveクエリのテンプレートに対して、fieldをstation、equalsを1、inputをdata1、outputをdata2に変換したクエリを生成する。図14は、EPLクエリテンプレートの変換例を示す図である。図14に示すように、この例では、フロー定義として、キューのイベントデータを入力データdata1とし、駅での絞り込み処理を実行して、出力データをdata2としてキューに格納することが定義されている。すなわち、図14に示した全要素はいずれもリアルタイム処理型に該当する。また、この駅での絞り込み処理に、プロパティとして、Field=station、value=1が与えられたとする。この場合、テンプレート変換部28aは、図14に示すように、図5に示したEPLクエリのテンプレートに対して、fieldをstation、equalsを1、inputをdata1に変換したクエリを生成する。生成部28bは、アセンブリ自動生成部28から通知されたSCAテンプレートに、テンプレート変換部28aから通知されたクエリを埋め込んで、フロー定義受付部26によって受け付けられたフロー定義で定義される処理を実行するアセンブリを生成する。そして、生成部28bは、生成したアセンブリをアセンブリ記憶部22dに格納し、また、処理実行装置40に送信する。例えば、アセンブリ自動生成部28から通知されたSCAテンプレートが01scavmであり、テンプレート変換部28aから通知されたクエリがテンプレート01queryvmを変換した、図13に示すクエリであるとする。この場合、生成部28bは、01scavmに該当するテンプレートをテンプレート記憶部22bから読み出し、読み出したSCAテンプレート01scavmに図13に示したクエリを埋め込んで、蓄積データを絞り込む実行用アセンブリを生成する。図15は、蓄積データを絞り込む実行用アセンブリの例を示す図である。図15に示すコンポーネントには、アセンブリを実行するJava登録商標クラスとしてexampleExecuteHiveUpdateが定義される。また、このコンポーネントには、実行するクエリとして、図13に示した変換後のHiveQLクエリがscapropertyname=HiveQLタグの値に埋め込まれる。ここで用いられているJava登録商標クラスは例えば図20のようになる。また、アセンブリ自動生成部28から通知されたSCAテンプレートが02scavmであり、テンプレート変換部28aから通知されたクエリがテンプレート02queryvmを変換した、図14に示すクエリであるとする。この場合、生成部28bは、02scavmに該当する図6に示したテンプレートをテンプレート記憶部22bから読み出す。そして、生成部28bは、読み出したSCAテンプレート02scavmに、図14に示したクエリを埋め込んで、イベントデータを絞り込む実行用アセンブリを生成する。図16は、イベントデータを絞り込む実行用アセンブリの例を示す図である。図16に示すコンポーネントには、アセンブリを実行するJava登録商標クラスとしてexampleEsperProcessorを定義される。また、このコンポーネントには、実行するクエリとして、図14に示した変換後のEPLクエリがscapropertyname=EPLタグの値に埋め込まれる。ここで用いられているJava登録商標クラスは例えば図21のようになる。処理実行装置の構成次に、図1に示した処理実行装置40の構成について説明する。図17は、処理実行装置の構成を示す機能ブロック図である。図17に示すように、処理実行装置40は、通信制御I/F部41と、イベント記憶部42aと、アセンブリ記憶部42bと、実行プログラム記憶部42cと、制御部45とを有する。なお、各記憶部は、例えば半導体メモリ素子やハードウェアなどの記憶装置である。制御部45は、例えばCPUなどの電子回路やFPGAなどの集積回路である。これら以外にも、例えば、制御部25の各処理部が処理を実行する際に、データ等の処理途中結果を一時的に格納する作業領域等も有していてもよい。通信制御I/F部41は、例えばNICなどのように、他の装置と通信を制御するインタフェースである。例えば、通信制御I/F部41は、自動判定装置20から実行可能なアセンブリを受信し、また、イベント通知装置5からイベントデータを受信する。また、通信制御I/F部41は、イベントデータに対して実行した処理の結果をクライアント装置1に送信する。イベント記憶部42aは、イベント通知装置5から受信したイベントデータを記憶する。図18は、イベント記憶部に記憶される情報の例を示す図である。図18に示すように、イベント記憶部42aは、発生時刻、ID、Station、Typeを対応付けて記憶する。ここで記憶される発生時刻は、イベントが発生した日であり、IDは、イベントを識別する識別子であり、Stationは、イベントが発生した駅を識別する識別子であり、Typeは、発生したイベントの内容を示す情報である。図18の場合、2011419に発生したIDが001のイベントは、Stationが1が割り当てられた駅で発生した改札に入るイベントであることを示す。また、2011419に発生したIDが003のイベントは、Stationが2が割り当てられた駅で発生した改札から出るイベントであることを示す。アセンブリ記憶部42bは、自動判定装置20から受信した実行可能なアセンブリを記憶する。例えば、アセンブリ記憶部42bは、図15に示した蓄積データを絞り込む実行用アセンブリや図16に示したイベントデータを絞り込む実行用アセンブリを記憶する。実行プログラム記憶部42cは、アセンブリ記憶部42bに格納される実行可能なアセンブリを実行するプログラムを記憶する。例えば、実行プログラム記憶部42cは、自動判定装置20によって生成されたアセンブリを呼び出して実行するJava登録商標プログラムを記憶する。例を挙げると、実行プログラム記憶部42cは、図19に示した、各コンポーネントの実装で利用している共通の入出力インタフェースを記述したプログラムを記憶する。図19は、各クラス間のインタフェースの定義例を示す図である。図19に示すように、インタフェースとしてMapEventReceiverが定義されており、コンポーネントを呼び出す側がインタフェースを参照する形で、複数のコンポーネントを連携させる。また、実行プログラム記憶部42cは、図20に示したプログラムを記憶する。図20は、Hiveクエリを実行するコンポーネントの実装例を示す図である。図20に示したコンポーネントは、booleanreshiveStatementexecutehiveQLが定義され、図15のアセンブリに埋め込んだHiveクエリを実行する。また、実行プログラム記憶部42cは、図21に示したプログラムを記憶する。図21は、EPLクエリを実行するコンポーネントの実装例を示す図である。図21に示したコンポーネントは、EPStatementstatementepSrevicegetEPAdministratorcreateEPLが定義され、図16のアセンブリに埋め込んだEPLクエリを実行する。制御部45は、イベントデータ受信部45aとアセンブリ受信部45bとイベント処理部45cとを有し、これらによって、クライアント装置1からフロー定義を用いて生成した処理を実行し、その結果をクライアント装置1に応答する処理部である。イベントデータ受信部45aは、イベント通知装置5からイベントデータを受信してイベント記憶部42aに格納する処理部である。イベントデータを受信する契機としては、例えばイベント通知装置5から送信されるのを待つだけでなく、イベントデータ受信部45aが定期的にイベント通知装置5から取得してもよい。アセンブリ受信部45bは、自動判定装置20から実行可能なアセンブリを受信してアセンブリ記憶部42bに格納する処理部である。すなわち、アセンブリ受信部45bは、図15や図16に示した、SCAで定義された実行可能なアセンブリを受信して格納する。イベント処理部45cは、実行プログラム記憶部42cに記憶されるプログラムを実行して、アセンブリ記憶部42bに記憶されアセンブリを実行し、所望の結果を取得して、クライアント装置1に応答する処理部である。例えば、イベント処理部45cが、図20に示したコンポーネントで実行して、図13に示したHiveクエリが埋め込まれた図15のアセンブリを実行したとする。すなわち、図18に示した蓄積データからstation1のイベントデータを抽出する例を説明する。この場合、イベント処理部45cは、2011419、001、1、Enter、2011419、002、1、Enter、2011419、003、2、Exit、2011419、004、2、Enterからstationが1のイベントデータを絞り込む。その結果、イベント処理部45cは、図22に示すように、2011419、001、1、Enter、2011419、002、1、Enterを抽出する。図22は、イベント処理結果の例を示す図である。そして、イベント処理部45cは、抽出したイベントデータをイベント処理結果、すなわちクライアントがフロー定義によって得ようとした結果としてクライアント装置1に送信する。なお、イベント処理を実行するタイミングは、実行可能なアセンブリがアセンブリ記憶部42bに格納されたタイミングや、自動判定装置20やクライアント装置1などから処理開始指示を受信した場合など任意のタイミングで実行することができる。また、イベント処理部45cは、様々な手法を用いて、実行プログラム記憶部42cに記憶されるプログラムから、実行すべきプログラムを特定することができる。例えば、イベント処理部45cは、アセンブリ記憶部42bに記憶されたアセンブリに埋め込まれたクエリから特定することもでき、自動判定装置20等から実行対象の処理やプログラムを特定する情報を受信してもよい。[処理の流れ]次に、図1に示したイベント処理システムが実行する処理の流れを説明する。ここでは、アセンブリ生成までの処理とフローチャートについて説明する。アセンブリ生成までの処理の説明図23は、アセンブリ作成までの流れを説明する図である。図23に示すように、自動判定装置20は、図4から図6に示したクエリテンプレートとSCAテンプレートとをテンプレート記憶部22bに記憶する。そして、自動判定装置20は、フロー定義受付部26によって受け付けられたフロー定義とクエリテンプレートとから、図13や図14に示した実行可能なクエリを生成する。その後、自動判定装置20は、図6などに示したSCAテンプレートに、生成した実行可能なクエリを埋め込み、図15や図16に示す実行可能なSCAコンポーネント定義を生成する。また、フロー定義が複数の処理で構成されている場合には、各処理ごとに生成したSCAコンポーネントを組み合わせて、実行可能なアセンブリであるSCAコンポジット定義を生成する。自動判定装置20は、このように作成したアセンブリであるSCAコンポジット定義を処理実行装置40が稼動させるSCAのエンジンに渡し、処理実行装置40が実行する。例えばApacheTuscanyであれば、Java登録商標アプリケーションからimportorgapachetuscanyscahostembeddedSCADomainSCADomainnewInstanceとして実行される。フローチャート図24は、イベント処理システムによる処理の流れを示すフローチャートである。図24に示すように、自動判定装置20のフロー定義受付部26がクライアント装置1からフロー定義を受け付けるとS101肯定、処理型判定部27は、フロー定義内に処理型が未定義の処理またはデータが存在するか否かを判定するS102。そして、処理型判定部27は、処理型が未定義の処理またはデータが存在する場合S102肯定、処理型判定処理を実行するS103。なお、処理型判定部27は、フロー定義内に存在する、処理型が未定義の処理またはデータの処理型が判定されるまで、処理型判定処理を実行する。その後、処理型判定部27によって処理型が判定されるとS102否定、テンプレート変換部28aは、コンポーネントリポジトリ記憶部22cを参照し、フロー定義内の処理に該当するクエリテンプレートから実行可能なクエリを生成するS104。続いて、生成部28bは、コンポーネントリポジトリ記憶部22cを参照して、生成された実行可能なクエリを埋め込むSCAテンプレートを特定し、特定したSCAテンプレートに実行可能なクエリを埋め込んで、SCAコンポーネント定義を生成するS105。すなわち、生成部28bは、フロー定義によって定義された一連の処理を実行可能なアセンブリを生成する。そして、生成部28bは、生成したアセンブリを処理実行装置40に送信するS106。処理実行装置40のアセンブリ受信部45bが自動判定装置20からアセンブリを受信し、イベント処理部45cは、受信されたアセンブリに対応するJava登録商標プログラム等を実行するS107。また、処理実行装置40のイベント処理部45cは、Java登録商標プログラムで呼び出されたアセンブリの実行によって得られた処理結果をクライアント装置1に送信する。処理型判定処理の流れ図25は、処理型判定処理の流れを示すフローチャートである。この処理は、図24に示したS103で実行される。なお、ここでは、一例として、後続の要素の処理型を優先して、処理型を判定する例を説明する。図25に示すように、自動判定装置20の処理型判定部27は、処理型が未定義の処理以下、未定義処理と表記するの直後のデータの処理型が定義済みであるか否かを判定するS201。そして、処理型判定部27は、直後のデータの処理型が定義済みである場合にはS201肯定、定義済みの処理型を未定義処理の処理型と判定するS207。一方、処理型判定部27は、直後のデータの処理型が定義済みでない場合にはS201否定、未定義処理の直後の処理の処理型が定義済みであるか否かを判定するS202。そして、処理型判定部27は、直後の処理の処理型が定義済みである場合にはS202肯定、定義済みの処理型を未定義処理の処理型と判定するS207。一方、処理型判定部27は、直後の処理の処理型が定義済みでない場合にはS202否定、さらに後続にデータが存在するか否かを、受け付けられた定義フローから判定するS203。そして、処理型判定部27は、さらに後続にデータが存在すると判定した場合S203肯定、S201以降の処理を実行する。また、処理型判定部27は、さらに後続にデータが存在しないと判定した場合S203否定、未定義処理の直前のデータの処理型が定義済みであるか否かを判定するS204。そして、処理型判定部27は、直前のデータの処理型が定義済みである場合にはS204肯定、定義済みの処理型を未定義処理の処理型と判定するS207。一方、処理型判定部27は、直前のデータの処理型が定義済みでない場合にはS204否定、未定義処理の直前の処理の処理型が定義済みであるか否かを判定するS205。そして、処理型判定部27は、直前の処理の処理型が定義済みである場合にはS205肯定、定義済みの処理型を未定義処理の処理型と判定するS207。一方、処理型判定部27は、直前の処理の処理型が定義済みでない場合にはS205否定、さらに前にデータが存在するか否かを、受け付けられた定義フローから判定するS206。そして、処理型判定部27は、さらに前にデータが存在すると判定した場合S206肯定、S203以降の処理を実行する。また、処理型判定部27は、さらに前にデータが存在しないと判定した場合S206否定、処理を終了する。また、処理型判定部27は、S207で未定義処理の処理型が判定された場合にも処理を終了する。[実施例1による効果]このように、実施例1に係る自動判定装置20は、利用者がデータの性質の違いを意識することなく、フロー定義で利用したいコンポーネントやデータを配置し、いずれか一つの要素の型を定義するだけで自動的にコンポーネントの型を判定することができる。そして、自動判定装置20は、判定した型に応じたクエリ定義やSCA定義を含むアセンブリを生成することができる。また、自動判定装置20は、いずれの型でも動作可能なコンポーネントを用意することで、処理型が違うことに起因するコンポーネントの種類の数を半減させることができる。したがって、分析者などのプログラムに精通していないユーザは、いずれの型でも動作するコンポーネントとして、入力データをどう加工するものなのかという処理内容の違いだけを意識すればよく、簡単にフロー定義を生成することができる。つまり、ユーザは、数多あるコンポーネントから処理型は何ら考慮することなく処理内容の違いだけを意識して必要なコンポーネントを選択してフローを作成することができる。例えば、バッチ処理とオンライン処理とで同一のフロー定義を使うといったフロー編集作業が可能となり、プログラム作成の負荷が軽減され、開発効率を向上させることが出来る。また、バッチ処理またはリアルタイム処理の両方の処理型で利用可能な任意のデータまたはコンポーネントを要素として用い、フロー内で1つの要素の型を指定すれば残りの要素の型を自動判定することもでき、プログラム作成や処理型の変更の負荷をより軽減することができる。また、ユーザは、開発者等に依頼することなく、簡単なプログラム等を自分で生成することができるので、近年の早いビジネススピードに遅れることなく、経営戦略の分析などスピードが要求される各種対応を迅速に処理することができる。実施例1では、未定義処理の処理型を当該未定義処理の直前の処理と同じ処理型と判定された例について説明したが、実施例2では、未定義処理の処理型を当該未定義処理の直前の処理と異なる処理型と判定された例について説明する。図26は、処理型判定の結果によって処理型が異なった例1を示す図である。図26に示すように、フロー定義受付部26が、蓄積データ-駅での絞り込み処理-イベントデータが定義されたフロー定義を受け付けたとする。この場合、駅での絞り込み処理の処理型が直後のイベントデータと同じイベント処理型すなわちリアルタイム処理型と判定される。つまり、駅での絞り込み処理の直前の蓄積データの処理型がバッチ処理型であるので、駅での絞り込み処理と蓄積データとの処理型が異なることとなる。この場合、図26に示すように、アセンブリ自動生成部28は、蓄積データと駅での絞り込み処理との間に、蓄積データに対してイベント送信処理を実行し、その結果をキューに格納する処理を埋め込む。このようにデータ変換処理を実施することで、リアルタイム処理型と判定された駅での絞り込み処理へ入力されるデータの型がリアルタイム処理型となり、駅での絞り込み処理が実行可能な処理となる。一例を挙げると、生成部28は、データ変換処理としてイベント送信処理を実行し、その結果をキューに格納する処理を実行するアセンブリを生成する。図27は、自動判定装置が生成する、蓄積データのイベント送信を実行する実行用アセンブリの例を示す図である。図27に示すコンポーネントには、アセンブリを実行するJava登録商標クラスとしてexampleExecuteHiveQueryが定義される。また、このコンポーネントは、scapropertyname=HiveQLタグの値にselectfromdata1が定義され、data1に格納されている全イベントデータをdestinationタグに定義されるdata2キューに送信するクエリを実行する。さらに、生成部28は、図26の下図に示すデータ変換処理と駅での絞り込み処理とを実行するアセンブリを生成する。図28は、自動判定装置が生成する、蓄積データの絞込みを実行する実行用アセンブリの例を示す図である。図28に示すコンポジットには、ExcuteHiveQueryコンポーネントのJava登録商標クラスとしてexampleExecuteHiveQueryが定義され、scapropertynama=HiveQLタグの値にselectfromdata1が定義される。この結果、このコンポジットは、data1に格納されている全イベントデータをdestinationに定義されるdata2キューに送信するクエリを実行する。また、図28に示すこのコンポジットは、EsperProcessorコンポーネントのJava登録商標クラスとしてexampleEsperProcessorが定義され、data2に格納されたイベントデータの絞り込みを行うクエリを実行する。そして、このコンポジットは、上記ExecuteHiveQueryコンポーネントとEsperProcessorコンポーネントとを接続するwire要素を定義する。このようにして、生成部28は、ExecuteHiveQueryとEsperProcessorとの各々を連携して実行させるコンポジットを作成する。図29は、処理型判定の結果によって処理型が異なった例2を示す図である。図29に示すように、フロー定義受付部26が、イベントデータ-駅での絞り込み処理-蓄積データが定義されたフロー定義を受け付けたとする。この場合、駅での絞り込み処理の処理型が直後の蓄積データと同じ蓄積処理型すなわちバッチ処理型と判定される。つまり、駅での絞り込み処理の直前のイベントデータの処理型がリアルタイム処理型であるので、駅での絞り込み処理とイベントデータとの処理型が異なることとなる。この場合、図29に示すように、アセンブリ自動生成部28は、イベントデータと駅での絞り込み処理との間に、イベントデータに対してデータ蓄積処理を実行し、その結果をデータベースに格納する処理を埋め込む。このようにデータ変換処理を実施することで、バッチ処理型と判定された駅での絞り込み処理へ入力されるデータの型がバッチ処理型となり、駅での絞り込み処理が実行可能な処理となる。そして、生成部28は、データ変換処理としてデータ蓄積処理を実行し、その結果をデータベースに格納する処理を実行するアセンブリを生成する。図30は、自動判定装置が生成する、データの蓄積および通知を実行する実行用アセンブリの例を示す図である。図30に示すコンポーネントには、アセンブリを実行するJava登録商標クラスとしてexampleStoreEventDataIntoHdfsが定義される。また、当該コンポーネントは、scapropertyタグにhdfsPathやhdfsUriが定義され、data1から出力されるイベントデータをdata2に蓄積する処理を実行する。次に、上述したアセンブリを実行するコンポーネント例について説明する。図31は、処理実行装置が記憶する、蓄積データを送信するコンポーネントの実装例を示す図である。図31に示すように、処理実行装置40は、booleanreshiveStatementexecutehiveQLが定義され、図27に示したHiveクエリを実行するコンポーネントを記憶する。図32は、処理実行装置が記憶する、イベントデータを蓄積するコンポーネントの実装例を示す図である。図32に示すコンポーネントは、Hadoop上でHDFSへのアクセスを定義し、取得したイベントデータを蓄積することが定義される。このように、実施例2に係る自動判定装置20は、フロー定義に記述される処理において、前後の処理で処理型が異なる場合でも、データの型を変換する変換処理を挿入して、フロー定義に記述される処理を実行させるプログラムを作成することができる。したがって、ユーザが、処理型の繋がりなどプログラムの知識がなくてもフロー定義を作成すればよく、ユーザの負担が軽減する。また、蓄積されたデータの分析で用いたフィルタやパラメータなどを、ストリーム処理に流用できる。また、蓄積されたイベントデータに対して、ストリーム処理を行った結果を擬似的にシミュレートできる。また、イベントの到着間隔に応じてストリーム処理を停止することで、サービスの運用コストを下げることができる。さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。テンプレート例えば、上記実施例では、Hiveクエリ、EPL、SCA等のテンプレートを用いる例を説明したが、これらはあくまで例示であり、開示する自動判定装置を限定するものではない。例えば、公知の様々なプログラム言語を用いることができ、開示する自動判定装置のみで使用するプログラム言語等を用いることもできる。また、上記実施例では、テンプレートを変換したクエリをSCA定義に埋め込む方式を例にして説明したが、これに限定されるものではない。例えば、両方のクエリをSCA定義に組み込んでおき、使用しない方のクエリをコメント文に変更するなどして、一方のクエリを実行させることもできる。処理型また、上記実施例で説明したバッチ処理は、いわゆる蓄積処理であり、データを一定期間蓄積して蓄積されたデータに対して所望の処理を実行する処理型を例示したものである。また、リアルタイム処理型は、いわゆるストリーム処理であり、データが入力されるごとに所望の処理を実行する処理型を例示したものである。システムまた、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。プログラムところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。図33は、処理型判定プログラムを実行するコンピュータのハードウェア構成の例を示す図である。図33に示すように、コンピュータ100は、CPU102、入力装置103、出力装置104、通信インタフェース105、媒体読取装置106、HDDHardDiskDrive107、RAMRandomAccessMemory108を有する。また、図7に示した各部は、バス101で相互に接続される。入力装置103は、マウスやキーボードであり、出力装置104は、ディスプレイなどであり、通信インタフェース105は、NICNetworkInterfaceCardなどのインタフェースである。HDD107は、処理型判定プログラム107aととともに、図3に示した記憶部に記憶される各情報を記憶する。記録媒体の例としてHDD107を例に挙げたが、ROMReadOnlyMemory、RAM、CD-ROM等の他のコンピュータ読み取り可能な記録媒体に各種プログラムを格納しておき、コンピュータに読み取らせることとしてもよい。なお、記憶媒体を遠隔地に配置し、コンピュータが、その記憶媒体にアクセスすることでプログラムを取得して利用してもよい。また、その際、取得したプログラムをそのコンピュータ自身の記録媒体に格納して用いてもよい。CPU102は、処理型判定プログラム107aを読み出してRAM108に展開することで、図1等で説明した各機能を実行する処理型判定プロセス108aを動作させる。すなわち、処理型判定プロセス108aは、図3に記載したフロー定義受付部26、処理型判定部27、アセンブリ自動生成部28、テンプレート変換部28a、生成部28bと同様の機能を実行する。このようにコンピュータ100は、プログラムを読み出して実行することで処理型判定方法を実行する情報処理装置として動作する。例えば、コンピュータ100は、媒体読取装置106によって記録媒体から処理型判定プログラム107aを読み出し、読み出された処理型判定プログラム107aを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、コンピュータ100によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。