ジョブ管理装置およびジョブ管理方法
【課題】オブジェクト指向言語に基づいてエンタープライズシステムを開発する。
【解決手段】UriageProcessingModelクラス４４０は、各ジョブオブジェクトの関係を定義する。UriageProcessingModelクラス４４０は、ジョブオブジェクトのクラス群４２０（以下「ジョブクラス」）と、各ジョブオブジェクトの依存関係をリストとして管理するConnectionクラス４３０のオブジェクトを持つ。UriageProcessingModelクラス４４０は、ジョブとその依存関係をジョブオブジェクトのクラス群４２０とConnectionクラス４３０の機能を使って管理することになる。SingleThreadFlowControllerクラス４５０は、各ジョブオブジェクトで必要とする処理内容を定義するクラスである。SingleThreadFlowControllerクラス４５０によって各ジョブに後天的に処理が注入される。
【解決手段】UriageProcessingModelクラス４４０は、各ジョブオブジェクトの関係を定義する。UriageProcessingModelクラス４４０は、ジョブオブジェクトのクラス群４２０（以下「ジョブクラス」）と、各ジョブオブジェクトの依存関係をリストとして管理するConnectionクラス４３０のオブジェクトを持つ。UriageProcessingModelクラス４４０は、ジョブとその依存関係をジョブオブジェクトのクラス群４２０とConnectionクラス４３０の機能を使って管理することになる。SingleThreadFlowControllerクラス４５０は、各ジョブオブジェクトで必要とする処理内容を定義するクラスである。SingleThreadFlowControllerクラス４５０によって各ジョブに後天的に処理が注入される。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ジョブの実行を制御するための技術、特に、依存関係を有する複数のジョブを実行制御するための技術、に関する。
【背景技術】
【０００２】
企業や公共施設などの運用を支えるエンタープライズシステム（Enterprise System）は、今や、大小さまざまな組織の基盤システムとして導入されている。エンタープライズシステムは、ノード端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力する。エンタープライズシステムは複雑化する組織マネジメントをより効率化するために発展を続けている。
【０００３】
このようなエンタープライズシステムは、ジョブの集合体としてモデリングされることが多い。ジョブとは、データベースの更新処理や、各ノード端末から得られたデータに対する演算処理など、システムにおいて基本的な実行単位となる処理である。これらのジョブは、前段にあたるジョブの実行結果に基づいて後段にあたるジョブが実行されるように互いに依存関係を有したかたちで設計される。
【０００４】
エンタープライズシステムの構築にあたっては、ＣＯＢＯＬ（COmmon Business Oriented Language）などの手続き型言語が広く採用されている。ＣＯＢＯＬは、その文法がシンプルであることから、エンタープライズシステムにおいてジョブを順次処理するという処理モデルにおいては実績のある言語である。
【特許文献１】特開平７−１２９４１５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
その一方、ＪＡＶＡ（登録商標）やＣ＋＋などのオブジェクト指向言語が、ソフトウェア開発の現場において急速に普及しつつある。オブジェクト指向言語は、データとそのデータにアクセスするためのインタフェースをクラス（class）としてカプセル化する。クラスという一種の構造体によってデータが保護されるため、オブジェクト指向言語は、コードの再利用性・保守性・堅牢性などの諸点において手続き型言語よりも優れている。オブジェクト指向言語が普及するにつれて、開発現場でもＣＯＢＯＬプログラマよりもＪＡＶＡ（登録商標）プログラマの方が増加しつつある。とりわけ、中国・台湾・インドをはじめとする東アジア諸国では、ＣＯＢＯＬプログラマよりもＪＡＶＡ（登録商標）プログラマの方が確保しやすい。加えて、団塊の世代が一斉に定年退職する、いわゆる２００７年問題によって、熟練したＣＯＢＯＬプログラマの多くが現場を去るという直近の事情もある。
このような背景から、ＪＡＶＡ（登録商標）によってエンタープライズシステムを開発する必要性が顕在化しつつあると本発明者は認識した。
【０００６】
ただし、大量のデータをバッチ処理する形態となることが多いエンタープライズシステムにおいてオブジェクト指向言語の優位性を発揮させるためには、手続き型言語による設計思想とは異なる設計思想に基づく必要がある。オブジェクト指向言語の特徴はソフトウェアの部品化であり、クラスの機能をいかに定義するかによってそのクラスの有用性が決まる。本発明者は、オブジェクト指向言語を前提としてエンタープライズシステムを設計するための新たなフレームワークを提供することにより、その優位性を好適に発揮させることができると想到した。
【０００７】
本発明はこうした状況に鑑みてなされたものであり、その主たる目的は、オブジェクト指向言語に基づいて、複数のジョブを実行制御するシステムを効率的に設計するための技術、を提供することにある。
【課題を解決するための手段】
【０００８】
本発明のある態様は、前段にあたるジョブの実行結果に基づいて後段にあたるジョブが実行されるように依存関係が定められた複数のジョブを実行するためのジョブ管理装置である。
この装置は、ジョブのタイプに応じてあらかじめ定義されたクラスからジョブオブジェクトを生成し、各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成する。そして、ジョブの処理内容を示す処理関数を、ジョブオブジェクトが生成された後に設定した上で、ジョブリスト情報に基づいて選択したジョブオブジェクトの処理関数を実行させる。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明を方法、装置、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、オブジェクト指向言語に基づくジョブの実行制御システムを効率的に設計する上で効果がある。
【発明を実施するための最良の形態】
【００１１】
図１は、エンタープライズシステムのハードウェア構成図である。
エンタープライズシステム２０４は、企業や公共施設のような組織の業務管理のために導入されるシステムである。エンタープライズシステム２０４は、地理的に分散された複数の組織を統合するシステムとして構成されてもよい。
【００１２】
本実施例におけるエンタープライズシステム２０４は、ジョブ管理装置１００、ノード端末２００およびデータベース２０６を含む。これらは、インターネット２０２を介して互いに接続されている。
ジョブ管理装置１００は、各ジョブの関係を定義したデータフローダイアグラム（DFD:Data Flow Diagram）にしたがって複数のジョブを順次実行する。データフローダイアグラム（以下、「ＤＦＤ」ともよぶ）については、後に図３等に関連して詳述する。また、ジョブ管理装置１００の機能については、次の図２以降に関連して詳述する。
【００１３】
ノード端末２００は、ユーザが業務遂行のために使用するコンピュータ端末である。ノード端末２００は業務上のさまざまなデータを取得する。ジョブ管理装置１００は、ジョブの実行に際して、ノード端末２００やデータベース２０６とデータを送受する。ジョブ管理装置１００は、ノード端末２００やデータベース２０６から取得したデータに基づいて各種のジョブを実行する。
【００１４】
まとめると、ノード端末２００やデータベース２０６から得られるデータを変数として、ジョブ管理装置１００はさまざまなジョブを実行する。また、ジョブ管理装置１００は、各ジョブの実行タイミングを統合的に制御する。このように、ノード端末２００やデータベース２０６から得られるデータに基づいて、あらかじめ処理内容が定義されたジョブが順次実行されることにより、エンタープライズシステム２０４全体としての運用がなされている。
【００１５】
図２は、ジョブ管理装置の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
ここでは、主として各機能ブロックの発揮すべき機能について述べ、その具体的な作用については、図３以降に関連して説明する。
【００１６】
ジョブ管理装置１００は、ユーザインタフェース処理部１１０、通信部１２０およびデータ処理部１３０を含む。
ユーザインタフェース処理部１１０は、ユーザからの入力処理やユーザに対する情報表示のようなユーザインタフェース全般に関する処理を担当する。通信部１２０は、ノード端末２００やデータベース２０６との通信処理を担当する。データ処理部１３０は、ユーザインタフェース処理部１１０や通信部１２０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部１３０は、ユーザインタフェース処理部１１０および通信部１２０の間のインタフェースの役割も果たす。
【００１７】
データ処理部１３０は、モデル管理部１４０とフロー制御部１５０を含む。
モデル管理部１４０は、各ジョブの依存関係を示す「静的なモデル」に関するデータを管理する。フロー制御部１５０は、各ジョブの処理内容を定義するとともに、各ジョブの実行を制御する。ここで注目すべきは、本実施例におけるジョブ管理装置１００においては、ジョブの静的な依存関係を管理するモデル管理部１４０と、ジョブの動的な処理内容を管理するフロー制御部１５０が機能上分離されていることである。そのため、ジョブの「依存関係の定義」と「処理内容の定義」について、一方の設計作業が他方の設計内容によって制約されない枠組み（フレームワーク）となっている。
以上をふまえて、より具体的なソフトウェア構造について説明する。
【００１８】
図３は、本実施例におけるデータフローダイアグラムを示す図である。
同図に示すデータフローダイアグラム３１２は、所定の期間における４つＣＤ（Compact Disc）店のＣＤの売上枚数を集計して、地域別および店別の売上枚数を計算するという処理過程を示している。このデータフローダイアグラム３１２には、売上データ３００、売上集約処理３０２、地区別売上データ３０４、店マスタデータ３０６、店名追加処理３０８および店別売上データ３１０の６つの構成要素（Entity）が定義されている。
【００１９】
売上データ３００は、４つのＣＤ店におけるＣＤ売上枚数を示すデータである。ここで、ＣＤ店を識別するために、各ＣＤ店には「０１」〜「０４」として示す「店ＩＤ」が付与されている。また、各ＣＤ店が所属する地区を識別するために、各地区には「Ａ」または「Ｂ」として示す「地区ＩＤ」が付与されている。売上データ３００によれば、「０１」および「０２」のＣＤ店は、「Ａ」地区に属し、「０３」と「０４」のＣＤ店は「Ｂ」地区に属している。ここで「０１」のＣＤ店には、２つのノード端末２００が設置されており、それぞれのノード端末２００からは、ＣＤ売上枚数として「１枚」と「２枚」が入力されている。同様に「０２」や「０４」のＣＤ店にも、２つのノード端末２００が設置されている。すなわち、売上データ３００は、２つの地区、４つのＣＤ店、７つのノード端末２００から得られるデータである。
【００２０】
売上集約処理３０２は、各ＣＤ店に設置されるノード端末２００から得られた売上データ３００をまとめて、ＣＤ店ごとのＣＤ売上枚数を計算する。そして、このＣＤ店ごとのＣＤ売上枚数に関する情報（以下、「中間データ」とよぶ）を店名追加処理３０８に渡す。その一方、地区ごとのＣＤ売上枚数を計算して地区別売上データ３０４を生成する。
【００２１】
店名追加処理３０８は、売上集約処理３０２から受け取った中間データと店マスタデータ３０６に基づいて、店別売上データ３１０を生成する。店マスタデータ３０６は、店ＩＤと店名を対応づけるデータであり、データベース２０６から得られるデータである。店別売上データ３１０は、ＣＤ店ごとのＣＤ売上枚数を集計したデータであり、かつ、店ＩＤだけでなく対応する店名も含むデータである。
【００２２】
仮に、データフローダイアグラム３１２をＣＯＢＯＬによって実装するとする。ＣＯＢＯＬはマルチスレッド環境を想定して設計された言語ではない。そのため、売上集約処理３０２と店名追加処理３０８をマルチタスク処理として定義する場合、売上集約処理３０２のメモリ空間と、店名追加処理３０８のメモリ空間は別々に割り当てられることになる。したがって、売上集約処理３０２は、中間データをいったんファイル化し、店名追加処理３０８はこのファイルから中間データを読み出すという処理方法になる。
【００２３】
これに対し、本実施例において使用されるプログラミング言語であるＪＡＶＡ（登録商標）は、マルチスレッド環境にて使用されることを充分に想定して設計された言語である。そのため、売上集約処理３０２と店名追加処理３０８をマルチタスク処理として定義する場合でも、各処理は別々のスレッドにて実行可能である。同一プロセス空間に属するスレッド間でメモリを共有するのは簡単であることから、売上集約処理３０２は、中間データをファイル化しなくても、店名追加処理３０８に渡すことができる。このようなマルチスレッドに関する優位性と実現性については後に詳述する。
【００２４】
本実施例においては、データフローダイアグラム３１２に含まれる６つの構成要素を「ジョブ」として定義し、各ジョブごとにクラス（以下、「ジョブクラス」ともよぶ）を定義する。フロー制御部１５０は、ジョブクラスをインスタンス化することにより生成されるオブジェクト（以下、「ジョブオブジェクト」ともよぶ）に対して、その処理内容を設定することになる。以下においては、「Ｘクラス（「Ｘ」は文字列）」をインスタンス化して生成されるオブジェクトのことを単に「Ｘオブジェクト」と表記するものとする。
【００２５】
図４は、図３のＤＦＤに対応するジョブクラスの依存関係を示す図である。
UriageSourceクラス４００は、売上データ３００に対応するジョブクラスであり、売上データ３００を各ＣＤ店のノード端末２００から収集して保持するクラスである。UriageAggregatorクラス４０２は、売上集約処理３０２に対応するジョブクラスである。以下、同様に、AreaUriageTotalSinkクラス４０４は地区別売上データ３０４、MiseMaSourceクラス４０６は店マスタデータ３０６、MiseMaMatcherクラス４０８は店名追加処理３０８、MiseUriageTotalSinkクラス４１０は店別売上データ３１０にそれぞれ対応するジョブクラスである。
【００２６】
ここで、UriageSourceクラス４００が、UriageAggregatorクラス４０２へ売上データ３００を渡したり、UriageAggregatorクラス４０２をインスタンス化するための処理が記述されると、UriageSourceクラス４００とUriageAggregatorクラス４０２の結合が強くなってしまう。ジョブクラス同士の結合が強くなると、あるジョブクラスの依存関係や処理内容の変更が他の多くのジョブクラスのパフォーマンスに影響しやすくなってしまうため望ましくない。いいかえれば、再利用性・保守性・堅牢性に優れたジョブクラスを設計するためには、ジョブクラス同士の結合が弱い方が望ましい。
そこで、本実施例においては、UriageSourceクラス４００からMiseUriageTotalSinkクラス４１０までの各ジョブクラスに対して、後述するNodeFlowControllerクラス５００によって後天的に「処理を注入する（inject）」という手法を採用している。すなわち、ジョブクラスそのものは、先天的には依存関係を持たないかたちで設計されている。
【００２７】
図５は、ジョブ管理装置の基本的な機能を実現するためのクラスの関係を示す模式図である。より詳細には、次の図６および図７に関連して説明するが、同図において、まず、クラスの関係の概要を示す。
UriageProcessingModelクラス４４０は、データフローダイアグラム３１２に示した各ジョブクラスの関係を定義するクラスである。UriageProcessingModelクラス４４０は、図４に示した６つのジョブクラスを含むジョブクラス群４２０を持つ。同図に示す菱形記号は、ＵＭＬ（Unified Modeling Language）の表記法に基づき、「集約（aggregation）」を示す記号である。すなわち、UriageProcessingModelクラス４４０は、その一部としてジョブクラス群４２０を持つ。したがって、UriageProcessingModelクラス４４０がインスタンス化されるときには、その一部であるジョブクラス群４２０も付随してインスタンス化される。UriageProcessingModelオブジェクトは、各ジョブオブジェクトを持つことになる。
【００２８】
UriageProcessingModelクラス４４０は、Connectionクラス４３０も持つ。Connectionクラス４３０は、ジョブクラス群４２０における各ジョブクラスの依存関係をリストとして管理するクラスである（以下、このようなタイプのクラスのことを「関係クラス」とよぶ）。UriageProcessingModelクラス４４０は、ジョブとその依存関係をジョブクラス群４２０とConnectionクラス４３０の機能を使って管理することになる。
【００２９】
SingleThreadFlowControllerクラス４５０は、各ジョブクラスの処理内容を定義するクラスである。SingleThreadFlowControllerクラス４５０の機能によって、エンタープライズシステム２０４が実際に稼働することになる。SingleThreadFlowControllerクラス４５０は、UriageProcessingModelクラス４４０を持っている。より厳密には、SingleThreadFlowControllerクラス４５０は、UriageProcessingModelクラス４４０への参照（reference）を設定されているが、本明細書では、参照も含めて「持つ」と定義する。したがって、UriageProcessingModelクラス４４０がインスタンス化されるときには、UriageProcessingModelクラス４４０、更に、ジョブクラス群４２０とConnectionクラス４３０が連鎖的ににインスタンス化されることになる。
【００３０】
先の図２に示した機能ブロック図と対比すると、モデル管理部１４０の機能はUriageProcessingModelクラス４４０、ジョブクラス群４２０、Connectionクラス４３０の各機能によって実現され、フロー制御部１５０の機能はSingleThreadFlowControllerクラス４５０の機能によって実現されることになる。以下、UriageProcessingModelクラス４４０のようなジョブの関係を定義するクラスことを「モデルクラス」、SingleThreadFlowControllerクラス４５０のようなジョブの処理内容を定義するクラスのことを「コントロールクラス」とよぶ。
【００３１】
図６は、ジョブクラスとモデルクラスの関係を示すクラス図である。
前の図５に示したように、UriageProcessingModelクラス４４０は、UriageSourceクラス４００からMiseUriageTotalSinkクラス４１０までの６つのジョブクラスを持つ。UriageProcessingModelクラス４４０自体は、SingleThreadFlowControllerクラス４５０に持たれている。UriageProcessingModelクラス４４０は、ProcessingModelクラス４６０を継承するモデルクラスである。すなわちUriageProcessingModelクラス４４０は、ProcessingModelクラス４６０において定義された機能を受け継ぎつつ、ＣＤの売上処理を管理するために特有の機能が追加されたクラスとして定義される。ProcessingModelクラス４６０の作成にあたっては、ＣＤの売上処理を管理するために特有の機能のみを追加すればよいので、スクラッチからUriageProcessingModelクラス４４０自体を作成するのに比べて、開発や保守にともなう負担が軽減される。以下、ProcessingModelクラス４６０のように、モデルクラスの継承元となる、基本的なクラスのことを「モデルベースクラス」とよぶことにする。ProcessingModelクラス４６０は、Connectionクラス４３０を持つ。したがって、ProcessingModelクラス４６０を継承するUriageProcessingModelクラス４４０も、Connectionクラス４３０を持つことになる。
【００３２】
６つのジョブクラスのうち、UriageSourceクラス４００とMiseMaSourceクラス４０６はRecordStreamSourceクラス４８０を継承するジョブクラスである。RecordStreamSourceクラス４８０は、売上データ３００や店マスタデータ３０６のようにジョブの前提となるデータを管理するための基本仕様が定義されたクラスである。UriageAggregatorクラス４０２は、RecordStreamAggregatorクラス４８２を継承する。RecordStreamAggregatorクラス４８２は、売上集約処理３０２のようにデータを集約するジョブについての基本仕様が定義されたクラスである。MiseMaMatcherクラス４０８は、RecordStreamMatcherクラス４８４を継承する。RecordStreamMatcherクラス４８４は、店名追加処理３０８のように２種類のデータを結合するジョブについての基本仕様が定義されたクラスである。MiseUriageTotalSinkクラス４１０とAreaUriageTotalSinkクラス４０４は、RecordStreamSinkクラス４８６を継承する。RecordStreamSinkクラス４８６は、地区別売上データ３０４や店別売上データ３１０のようにジョブの処理結果として生成されるデータを管理するための基本仕様が定義されたクラスである。
このように、６つのジョブクラスは、４種類のクラス（以下、「ジョブベースクラス」とよぶ）のいずれかを継承している。更に遡ると、すべてのジョブベースクラスは、Nodeクラス４９０を継承する。Nodeクラス４９０は、ジョブのタイプによらない基本的な仕様が定義されたクラスである。
【００３３】
Nodeクラス４９０は、NodeFlowControllerクラス５００を包含する。NodeFlowControllerクラス５００は、ジョブオブジェクトの処理内容を決定するためのクラスである（以下、このようなクラスのことを「処理クラス」とよぶ）。そのため、ジョブクラスがインスタンス化されると、ジョブオブジェクトごとに処理オブジェクトが生成されることになる。ただし、ジョブクラスがインスタンス化される時点においては、処理クラスには特定の処理内容は設定されない。後に詳述する方法にて、SingleThreadFlowControllerクラス４５０、すなわち、コントロールクラスが処理を注入するときに、具体的な処理内容が設定される。
【００３４】
同図に示すクラス図によれば、データフローダイアグラム３１２に対応するクラスでありジョブクラスやモデルクラスのほかに、ジョブベースクラスやモデルベースクラスが定義されている。したがって、開発者がエンタープライズシステム２０４を設計するときには、あらかじめ用意されているジョブベースクラスやモデルベースクラスの基本仕様を利用しながら、設計対象となるエンタープライズシステム２０４に特有の機能をジョブクラスやモデルクラスに定義すればよい。これにより、クラスの再利用性というオブジェクト指向言語の特性を効果的に利用できる。エンタープライズシステム２０４の場合、何百、何千というジョブの基本仕様は数パターンに集約できることが多いため、オブジェクト指向言語の継承機能は特に有効である。
【００３５】
図７は、処理クラスの継承に関するクラス図である。
前の図６で見たように、NodeFlowControllerクラス５００は、ジョブオブジェクトの処理内容を定義するための処理クラスである。NodeFlowControllerクラス５００からSTNodeFlowControllerクラス５０２が継承され、更に、STRecordStreamSourceクラス５１０、STRecordStreamMatcherクラス５１２、STRecordStreamAggregatorクラス５１４およびSTRecordStreamSinkクラス５１６の４種類の処理クラスが継承されている。STRecordStreamSourceクラス５１０は、RecordStreamSourceクラス４８０に対応して、その処理内容を定義するためのクラスである。STRecordStreamMatcherクラス５１２、STRecordStreamAggregatorクラス５１４およびSTRecordStreamSinkクラス５１６は、それぞれ、RecordStreamMatcherクラス４８４、RecordStreamAggregatorクラス４８２およびRecordStreamSinkクラス４８６に対応してそれらの処理内容を定義するクラスである。NodeFlowControllerクラス５００から継承された４種類の処理クラスによって、ジョブクラスの処理内容が定義されることになる。
以上のクラス図をふまえ、サンプルのソースコードを参照しながら、基幹的な処理の内容を処理順序にしたがって説明する。以下に示すソースコードはＪＡＶＡ（登録商標）にて記述されている。
【００３６】
図８は、エンタープライズシステムの実行開始にあたって、最初に実行される関数を示す図である。
この関数（メソッド：method）はdoTest関数である。doTest関数は、UriageProcessingModelクラス４４０のpublicでstaticなメンバ関数であり、UriageProcessingModelクラス４４０の外からコール可能である。doTest関数が実行されると、UriageProcessingModelクラス４４０がインスタンス化され、testProcessingModelという名前のモデルオブジェクトが生成される（Ｓ１００）。インスタンス化にともなって実行される詳細な処理内容については、次の図９に関連して説明する。
【００３７】
次に、SingleThreadFlowControllerクラス４５０がインスタンス化され、singleThreadFlowControllerという名前のコントロールオブジェクトが生成される（Ｓ２００）。インスタンス化にともなって実行される詳細な処理内容については、後の図１０に関連して説明する。
【００３８】
最後に、コントロールオブジェクトのdoTask関数に生成されたばかりのモデルオブジェクトが引数として渡されている（Ｓ３００）。doTask関数に関する詳細な処理内容については、後の図１０以降に関連して説明する。
【００３９】
まとめると、doTest関数は、モデルオブジェクトとコントロールオブジェクトを生成し、コントロールオブジェクトにモデルオブジェクトを渡して、コントロールオブジェクトに所定の処理を実行させている。
【００４０】
図９は、モデルオブジェクト生成時に実行されるソースコードを示す図である。
Ｓ１００において、UriageProcessingModelクラス４４０がインスタンス化されるときには、まず、UriageProcessingModel()として示されるコンストラクタ関数が実行される（Ｓ１０２）。このコンストラクタ関数の実行に際して、各ジョブクラスがインスタンス化される（Ｓ１０４）。ここでは、UriageProcessingModelクラス４４０のメンバ変数として、UriageSourceクラス４００、MiseMaSourceクラス４０６、UriageAggregatorクラス４０２、MiseMaMatcherクラス４０８、MiseUriageTotalSinkクラス４１０およびAreaUriageTotalSinkクラス４０４の各ジョブクラスがインスタンス化され、それぞれ、uriageSource、miseMaSource、uriageAggregator、miseMaMatcher、miseUriageTotalSinkrおよびareaUriageTotalSinkという名前のジョブオブジェクトが生成される。なお、各ジョブオブジェクトの生成に際しては、それぞれ、NodeFlowControllerクラス５００から処理オブジェクトが生成される。ただし、この段階では処理オブジェクトには特段の処理内容は定義されない。また、UriageProcessingModelクラス４４０のインスタンス化に際しては、モデルベースクラスが持っている関係クラス、すなわち、Connectionクラス４３０もインスタンス化される。Connectionクラス４３０は、リスト形式にて各ジョブオブジェクトのつながりを管理するためのクラスである。
【００４１】
次に、コンストラクタ関数の中の、createModel関数が実行される（Ｓ１０６）。これにより、Ｓ１０４にて生成された各ジョブオブジェクトが関係オブジェクトにノードとして登録される。こうして、必要なジョブオブジェクトとそのつながりが定義される。いいかえれば、モデルオブジェクトは、その生成時に、登場キャラクタたるジョブオブジェクトと、その関係を示す関係オブジェクトを生成する。
【００４２】
図１０は、コントロールオブジェクト生成時とデータフローの実行開始に際して実行されるソースコードを示す図である。
前の図８に示したdoTest関数のＳ２００において、SingleThreadFlowControllerクラス４５０がインスタンス化される。このとき、まず、SingleThreadFlowController()として示されるコンストラクタ関数が実行される（Ｓ２０２）。このコンストラクタ関数の実行によって、ProcessingModelクラス４６０からmodelという名前の変数が用意される。このProcessingModelクラス４６０は、UriageProcessingModelクラス４４０の継承元となるモデルベースクラスであるから、この段階では、modelという名前の変数には、ＣＤの売上処理に関する具体的なモデルは設定されない。そして、SingleThreadFlowControllerクラス４５０からsingleThreadFlowControllerという名前のコントロールオブジェクトが生成されることになる。
【００４３】
こうして、図８のＳ１００とＳ２００に示した、モデルオブジェクトとコントロールオブジェクトの生成が完了し、図６に示した各クラスに基づいてさまざまなオブジェクトが生成されることになる。ここまでの処理のことを「生成初期化処理」とよぶことにする。
【００４４】
先に示した図８のdoTest関数は、生成初期化処理が終了すると、コントロールオブジェクトのdoTask関数をコールしている。このとき、モデルオブジェクトがコントロールオブジェクトのdoTask関数の引数として渡されている。モデルオブジェクトは、setModel関数によって、Ｓ２０４にて生成されたmodelという名前のオブジェクトに、Ｓ１００にて生成されたＣＤの売上処理に関するtestProcessingModelという名前のモデルオブジェクトを設定している（Ｓ３１０）。こうして、コントロールオブジェクトは、処理の対象とすべき具体的なモデルオブジェクトを取得する。
【００４５】
次に、doTask関数は、ジョブオブジェクト間でデータを送受するための容れ物となるオブジェクトを設定するためのinjectRecordStream関数を実行し（Ｓ３２０）、各ジョブオブジェクトの処理を注入するためのinjectFlowController関数を実行する（Ｓ３３０）。最後に、mainTask関数を実行して、モデルオブジェクトが包含する各ジョブオブジェクトに処理を実行させる（Ｓ３４０）。なお、Ｓ３１０からＳ３３０までの処理のことを「注入初期化処理」とよぶことにする。
【００４６】
図１１は、図１０のＳ３１０からＳ３４０までの処理に対応するソースコードを示す図である。
前の図１０に示したdoTask関数のＳ３２０の実行にともなって、injectRecordStream関数が実行される。これによって、ジョブオブジェクト間でデータを受け渡すためのオブジェクトとして、STRecordStreamクラスがインスタンス化される。このように、ジョブオブジェクト間においてデータ受け渡しするためのフォーマットも、コントロールオブジェクト側にて定義される。次に、doTask関数のＳ３３０の実行にともなって、injectFlowController関数が実行される。injectFlowController関数は、関係オブジェクトを走査して、順次ジョブオブジェクトを選択し、各ジョブオブジェクトについてinjectFlowControllerToNode関数を実行する（Ｓ３３２）。
【００４７】
このinjectFlowControllerToNode関数においては、一時的な処理オブジェクトnfcが生成される。次に、処理対象となるジョブオブジェクトがどのタイプのジョブベースクラスに基づくかが判定される。たとえば、処理対象のジョブオブジェクトが、RecordStreamSourceクラス４８０に基づくときには、nfcという名前の処理オブジェクトには、STRecordStreamSourceクラス５１０に基づく処理オブジェクトが設定される。たとえば、UriageAggregatorオブジェクトは、RecordStreamAggregatorクラス４８２に基づくので、nfcにはSTRecordStreamAggregatorオブジェクトが設定される。こうして、処理オブジェクトnfcには、４種類のオブジェクトのうちのいずれかが設定される。そして、setTargetNode関数によって、処理対象のジョブオブジェクトに対応する処理オブジェクトとして設定される（Ｓ３３４）。この段階で、ジョブオブジェクトの処理内容が決定することになる。すなわち、コントロールオブジェクトによってジョブオブジェクトに処理が「注入」される。
【００４８】
注入初期化処理が完了すると、エンタープライズシステム２０４を実際に稼働させるためのmainTask関数が実行される（Ｓ３４０）。図３のデータフローダイアグラム３１２に示したように、全体としての処理は、売上データ３００を前提として開始される。そのため、まず、関係オブジェクトを走査して、RecordStreamSourceクラス４８０に基づくジョブオブジェクトを特定する（Ｓ３４２）。ただし、MiseMaSourceオブジェクトのように、他のジョブオブジェクトによる中間データと共に利用されるジョブオブジェクトの場合には、RecordStreamSourceクラス４８０に基づくジョブオブジェクトであっても、ここでは処理対象としない（Ｓ３４４）。isMaSource関数は、これを調べるための関数である。
【００４９】
MiseMaSourceクラス４０６に基づくUriageSourceオブジェクトが検出されると、対応する処理オブジェクトが取り出され（Ｓ３４６）、その処理オブジェクトのdoTask関数が実行される（Ｓ３４８）。以後は図示しないが、UriageSourceオブジェクトに対応する処理オブジェクトのdoTask関数は、自分の処理が終了するときに、関係オブジェクトを参照して次の処理対象となるジョブであるUriageAggregatorオブジェクトを特定する。UriageAggregatorオブジェクトの処理オブジェクトが取り出され、その処理オブジェクトの処理関数であるdoTask関数が実行される。このdoTask関数も、自分の処理が終了するときには、AreaUriageTotalSinkオブジェクトとMiseMaMatcherオブジェクトを次の処理対象として特定する。なお、MiseMaMatcherクラス４０８の処理オブジェクトは、自分の処理に先立って、MiseMaSourceクラス４０６の処理オブジェクトにdoTask関数の実行を指示し、その実行結果を待ってから、自分の処理を実行し、MiseUriageTotalSinkオブジェクトを次の処理対象として特定する。
【００５０】
このように、データフローダイアグラム３１２に示された、いいかえれば、関係オブジェクトに管理されている依存関係にしたがって、複数のジョブオブジェクトが連鎖的に処理を実行することになる。
【００５１】
以上の実施例に示したジョブ管理装置１００によれば、モデルオブジェクトとコントロールオブジェクトによって、ジョブの静的な関係定義と、ジョブの動的な処理定義を明確に分離することができる。
ＣＯＢＯＬなどの手続き型言語の場合、これら２種類の定義は一体としてなされることが多かった。そのため、開発者は、ジョブの静的な関係定義と動的な処理定義を同時に意識しながらシステムを設計する必要があった。これに対して、本実施例にて示したフレームワークによれば、これら２種類の定義を明確に分離できる。そのため、ジョブの処理定義に過度に影響されることなく、ジョブの関係定義を行うことができる。また、その逆も真である。このような、分離設計を可能とするフレームワークは、エンタープライズシステム２０４の拡張性・保守性・堅牢性を高めることができる。
【００５２】
たとえば、一部のジョブオブジェクトにだけ処理を注入することにより、エンタープライズシステム２０４の一部の機能だけをテストする作業を、コントロールオブジェクト側の変更操作だけで実現できる。
具体例として、１００個のジョブオブジェクトによって構成されるエンタープライズシステム２０４のうち、３個のジョブオブジェクトの機能だけをテストしたい場合について説明する。このような場合、まず、１００個のジョブオブジェクトを生成しておく。そして、実際には、この３個のジョブオブジェクトにだけ処理を注入する。次に、さきほどの３個のジョブオブジェクトを含む５個のジョブオブジェクトの機能をテストしたい場合には、生成済の１００個のジョブオブジェクトのうち、今度は５個のジョブオブジェクトに処理を注入する。すなわち、はじめに１００個のジョブオブジェクトを生成しておけば、２回目のテストのために新たにテスト対象として加わった２個のジョブオブジェクトを生成する必要がない。このような処理方法によると、最初に全てのジョブオブジェクトを生成しておけば、テスト対象の変更により新たなインスタンス化処理を実行しなくて済むというメリットがある。
【００５３】
本実施例に示すエンタープライズシステム２０４の場合、ジョブオブジェクトはすべてモデルクラスによって生成され、他のジョブクラスから生成されることはない。このため、ジョブオブジェクトの生成に関しても、ジョブクラスに先天的な依存関係を持たさなくて済む。これにより、各ジョブクラスの独立性を高めることができる。また、プログラマは、UriageProcessingModelクラス４４０を参照することにより、処理対象となるジョブクラスを一元的に参照できるため、ソースコードの可読性を高める効果もある。
【００５４】
また、図６に関連して説明したように、ジョブクラスは典型的な４つのジョブベースクラスのいずれかを継承するかたちで定義されているため、何十、何百、何千というジョブオブジェクトを制御する場合であっても、ジョブクラスの設計負担が大幅に軽減される。これは、処理クラスやモデルクラスなど他のクラスについても同様である。
【００５５】
更に、Ｓ３３２のinjectFlowControllerToNode関数に示したように、各ジョブクラスの由来に応じて、割り当てるべき処理クラスが特定されている。したがって、多種類のジョブクラスに対して、多種類の処理クラスを割り当てる場合であっても、ジョブクラスのタイプに応じて、処理クラスのタイプを結びつけるという方法により、ジョブクラスと処理クラスの対応関係に関するソースコードの可読性が向上する。
【００５６】
本実施例においては、シングルスレッドモデルを前提としてシステムを説明したが、これをマルチスレッド化することも容易である。たとえば、SingleThreadFlowControllerクラス４５０のmainTask関数は、RecordStreamSourceクラス４８０に基づくジョブオブジェクトであるか否かにかかわらず、全てのジョブオブジェクトに対して一斉にdoTask関数の開始を指示してもよい。
【００５７】
マルチスレッドモデルについて図４を再度参照しながら説明する。
まず、SingleThreadFlowControllerクラス４５０は、各ジョブオブジェクトの処理オブジェクトの処理関数であるdoTask関数に実行を指示する。ここで、各doTask関数はマルチスレッド化されており、時間的に並行して実行可能な関数である。この指示によって、各doTask関数は実行待機状態に移行するが、UriageSourceオブジェクトについての処理関数だけは即座に実行開始となる。
【００５８】
UriageSourceオブジェクトについての処理関数が実行を完了すると、UriageAggregatorオブジェクトの処理関数が実行開始となる。UriageAggregatorクラス４０２の処理関数が実行完了すると、AreaUriageTotalSinkクラス４０４とMiseMaMatcherクラス４０８は同時並行的に実行開始を指示される。AreaUriageTotalSinkクラス４０４とMiseMaMatcherクラス４０８は依存関係を持たないので結果として並行処理が可能となる。MiseMaMatcherクラス４０８は自己の処理関数を実行するために、MiseMaSourceクラス４０６の処理関数に実行を指示し、その処理結果を受けたときに自分の処理関数を実行開始することになる。このときに、並行してAreaUriageTotalSinkオブジェクトの処理関数は実行されている。このため、ＣＯＢＯＬが苦手なマルチタスク処理を、マルチスレッド処理として実現できるため、システム全体としてのパフォーマンスを向上させることができる。特に、ＤＦＤにおいて、フローが枝分かれするほど、同時並行的に実行できる処理関数を増やすことができる。
【００５９】
また、ジョブ管理装置１００の機能は、複数のハードウェア資源によって実現されてもよい。たとえば、ジョブオブジェクトは、複数のジョブ実行装置に分散配置されてもよい。このような態様によれば、ジョブ実行装置Ａでジョブオブジェクトαの処理を実行しつつ、ジョブ実行装置Ｂでジョブオブジェクトβの処理を実行するという処理方法が可能となる。これにより、時間的な効率化だけでなく、処理負荷の分散も効率的に行うことができる。コントロールクラスは、ジョブ実行装置群において処理負荷が局所化しないように、他のジョブ実行装置よりも処理負荷が軽い状態にあるジョブ実行装置に対して優先的にジョブを割り当ててもよい。従来、ジョブの分散配置を実現するためには、複数のジョブ実行装置への分散配置を前提とした設計が必要であったが、本実施例に示した設計方法によれば、ジョブ管理装置１００から外部のジョブ実行装置にジョブの実行主体を移行させるのが容易となる。
【００６０】
以上、実施の形態をもとに本発明を説明した。なお本発明はこの実施の形態に限定されることなく、そのさまざまな変形例もまた、本発明の態様として有効である。たとえば、本実施例においては、エンタープライズシステムを想定して説明したが、より具体的には、電子商取引、物流管理などへの応用が考えられる。また、本実施例において示したフレームワークは、ワークフロー管理のように、複数のジョブを定義して制御するというモデルに広く応用可能である。
【００６１】
請求項に記載のジョブオブジェクト生成部の機能は、本実施例においては主としてUriageProcessingModelクラス４４０によって実現される。請求項に記載のジョブリスト情報生成部の機能は、本実施例においては主としてUriageProcessingModelクラス４４０やConnectionクラス４３０によって実現される。請求項に記載の処理注入部と実行制御部の機能は、本実施例においては、主としてSingleThreadFlowControllerクラス４５０によって実現される。したがって、請求項に記載のモデルオブジェクト生成部の機能は、本実施例においては主としてモデル管理部１４０、とりわけ、UriageProcessingModelクラス４４０によって実現される。請求項に記載のコントロールオブジェクト生成部の機能は、本実施例においてはフロー制御部１５０、とりわけ、SingleThreadFlowControllerクラス４５０によって実現される。請求項に記載の処理関数は、本実施例においては、たとえば、Ｓ３４８にて示したdoTask関数が相当する。
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【図面の簡単な説明】
【００６２】
【図１】エンタープライズシステムのハードウェア構成図である。
【図２】ジョブ管理装置の機能ブロック図である。
【図３】本実施例におけるデータフローダイアグラムを示す図である。
【図４】図３のＤＦＤに対応するジョブクラスの依存関係を示す図である。
【図５】ジョブ管理装置の基本的な機能を実現するためのクラスの関係を示す模式図である。
【図６】ジョブクラスとモデルクラスの関係を示すクラス図である。
【図７】処理クラスの継承に関するクラス図である。
【図８】エンタープライズシステムの実行開始にあたって、最初に実行される関数を示す図である。
【図９】モデルオブジェクト生成時に実行されるソースコードを示す図である。
【図１０】コントロールオブジェクト生成時とデータフローの実行開始に際して実行されるソースコードを示す図である。
【図１１】図１０のＳ３１０からＳ３４０までの処理に対応するソースコードを示す図である。
【符号の説明】
【００６３】
１００ ジョブ管理装置、 １１０ ユーザインタフェース処理部、 １２０ 通信部、 １３０ データ処理部、 １４０ モデル管理部、 １５０ フロー制御部、 ２００ ノード端末、 ２０２ インターネット、 ２０４ エンタープライズシステム、 ２０６ データベース、 ３００ 売上データ、 ３０２ 売上集約処理、 ３０４ 地区別売上データ、 ３０６ 店マスタデータ、 ３０８ 店名追加処理、 ３１０ 店別売上データ、 ３１２ データフローダイアグラム、 ４００ UriageSourceクラス、 ４０２ UriageAggregatorクラス、 ４０４ AreaUriageTotalSinkクラス、 ４０６ MiseMaSourceクラス、 ４０８ MiseMaMatcherクラス、 ４１０ MiseUriageTotalSinkクラス、 ４２０ ジョブクラス群、 ４３０ Connectionクラス、 ４４０ UriageProcessingModelクラス、 ４５０ SingleThreadFlowControllerクラス、 ４６０ ProcessingModelクラス、 ４８０ RecordStreamSourceクラス、 ４８２ RecordStreamAggregatorクラス、 ４８４ RecordStreamMatcherクラス、 ４８６ RecordStreamSinkクラス、 ４９０ Nodeクラス、 ５００ NodeFlowControllerクラス、 ５０２ STNodeFlowControllerクラス、 ５１０ STRecordStreamSourceクラス、 ５１２ STRecordStreamMatcherクラス、 ５１４ STRecordStreamAggregatorクラス、 ５１６ STRecordStreamSinkクラス。
【技術分野】
【０００１】
この発明は、ジョブの実行を制御するための技術、特に、依存関係を有する複数のジョブを実行制御するための技術、に関する。
【背景技術】
【０００２】
企業や公共施設などの運用を支えるエンタープライズシステム（Enterprise System）は、今や、大小さまざまな組織の基盤システムとして導入されている。エンタープライズシステムは、ノード端末やデータベースから得られるデータを集計、蓄積、解析、加工した上でより付加価値の高い情報を出力する。エンタープライズシステムは複雑化する組織マネジメントをより効率化するために発展を続けている。
【０００３】
このようなエンタープライズシステムは、ジョブの集合体としてモデリングされることが多い。ジョブとは、データベースの更新処理や、各ノード端末から得られたデータに対する演算処理など、システムにおいて基本的な実行単位となる処理である。これらのジョブは、前段にあたるジョブの実行結果に基づいて後段にあたるジョブが実行されるように互いに依存関係を有したかたちで設計される。
【０００４】
エンタープライズシステムの構築にあたっては、ＣＯＢＯＬ（COmmon Business Oriented Language）などの手続き型言語が広く採用されている。ＣＯＢＯＬは、その文法がシンプルであることから、エンタープライズシステムにおいてジョブを順次処理するという処理モデルにおいては実績のある言語である。
【特許文献１】特開平７−１２９４１５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
その一方、ＪＡＶＡ（登録商標）やＣ＋＋などのオブジェクト指向言語が、ソフトウェア開発の現場において急速に普及しつつある。オブジェクト指向言語は、データとそのデータにアクセスするためのインタフェースをクラス（class）としてカプセル化する。クラスという一種の構造体によってデータが保護されるため、オブジェクト指向言語は、コードの再利用性・保守性・堅牢性などの諸点において手続き型言語よりも優れている。オブジェクト指向言語が普及するにつれて、開発現場でもＣＯＢＯＬプログラマよりもＪＡＶＡ（登録商標）プログラマの方が増加しつつある。とりわけ、中国・台湾・インドをはじめとする東アジア諸国では、ＣＯＢＯＬプログラマよりもＪＡＶＡ（登録商標）プログラマの方が確保しやすい。加えて、団塊の世代が一斉に定年退職する、いわゆる２００７年問題によって、熟練したＣＯＢＯＬプログラマの多くが現場を去るという直近の事情もある。
このような背景から、ＪＡＶＡ（登録商標）によってエンタープライズシステムを開発する必要性が顕在化しつつあると本発明者は認識した。
【０００６】
ただし、大量のデータをバッチ処理する形態となることが多いエンタープライズシステムにおいてオブジェクト指向言語の優位性を発揮させるためには、手続き型言語による設計思想とは異なる設計思想に基づく必要がある。オブジェクト指向言語の特徴はソフトウェアの部品化であり、クラスの機能をいかに定義するかによってそのクラスの有用性が決まる。本発明者は、オブジェクト指向言語を前提としてエンタープライズシステムを設計するための新たなフレームワークを提供することにより、その優位性を好適に発揮させることができると想到した。
【０００７】
本発明はこうした状況に鑑みてなされたものであり、その主たる目的は、オブジェクト指向言語に基づいて、複数のジョブを実行制御するシステムを効率的に設計するための技術、を提供することにある。
【課題を解決するための手段】
【０００８】
本発明のある態様は、前段にあたるジョブの実行結果に基づいて後段にあたるジョブが実行されるように依存関係が定められた複数のジョブを実行するためのジョブ管理装置である。
この装置は、ジョブのタイプに応じてあらかじめ定義されたクラスからジョブオブジェクトを生成し、各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成する。そして、ジョブの処理内容を示す処理関数を、ジョブオブジェクトが生成された後に設定した上で、ジョブリスト情報に基づいて選択したジョブオブジェクトの処理関数を実行させる。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明を方法、装置、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、オブジェクト指向言語に基づくジョブの実行制御システムを効率的に設計する上で効果がある。
【発明を実施するための最良の形態】
【００１１】
図１は、エンタープライズシステムのハードウェア構成図である。
エンタープライズシステム２０４は、企業や公共施設のような組織の業務管理のために導入されるシステムである。エンタープライズシステム２０４は、地理的に分散された複数の組織を統合するシステムとして構成されてもよい。
【００１２】
本実施例におけるエンタープライズシステム２０４は、ジョブ管理装置１００、ノード端末２００およびデータベース２０６を含む。これらは、インターネット２０２を介して互いに接続されている。
ジョブ管理装置１００は、各ジョブの関係を定義したデータフローダイアグラム（DFD:Data Flow Diagram）にしたがって複数のジョブを順次実行する。データフローダイアグラム（以下、「ＤＦＤ」ともよぶ）については、後に図３等に関連して詳述する。また、ジョブ管理装置１００の機能については、次の図２以降に関連して詳述する。
【００１３】
ノード端末２００は、ユーザが業務遂行のために使用するコンピュータ端末である。ノード端末２００は業務上のさまざまなデータを取得する。ジョブ管理装置１００は、ジョブの実行に際して、ノード端末２００やデータベース２０６とデータを送受する。ジョブ管理装置１００は、ノード端末２００やデータベース２０６から取得したデータに基づいて各種のジョブを実行する。
【００１４】
まとめると、ノード端末２００やデータベース２０６から得られるデータを変数として、ジョブ管理装置１００はさまざまなジョブを実行する。また、ジョブ管理装置１００は、各ジョブの実行タイミングを統合的に制御する。このように、ノード端末２００やデータベース２０６から得られるデータに基づいて、あらかじめ処理内容が定義されたジョブが順次実行されることにより、エンタープライズシステム２０４全体としての運用がなされている。
【００１５】
図２は、ジョブ管理装置の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
ここでは、主として各機能ブロックの発揮すべき機能について述べ、その具体的な作用については、図３以降に関連して説明する。
【００１６】
ジョブ管理装置１００は、ユーザインタフェース処理部１１０、通信部１２０およびデータ処理部１３０を含む。
ユーザインタフェース処理部１１０は、ユーザからの入力処理やユーザに対する情報表示のようなユーザインタフェース全般に関する処理を担当する。通信部１２０は、ノード端末２００やデータベース２０６との通信処理を担当する。データ処理部１３０は、ユーザインタフェース処理部１１０や通信部１２０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部１３０は、ユーザインタフェース処理部１１０および通信部１２０の間のインタフェースの役割も果たす。
【００１７】
データ処理部１３０は、モデル管理部１４０とフロー制御部１５０を含む。
モデル管理部１４０は、各ジョブの依存関係を示す「静的なモデル」に関するデータを管理する。フロー制御部１５０は、各ジョブの処理内容を定義するとともに、各ジョブの実行を制御する。ここで注目すべきは、本実施例におけるジョブ管理装置１００においては、ジョブの静的な依存関係を管理するモデル管理部１４０と、ジョブの動的な処理内容を管理するフロー制御部１５０が機能上分離されていることである。そのため、ジョブの「依存関係の定義」と「処理内容の定義」について、一方の設計作業が他方の設計内容によって制約されない枠組み（フレームワーク）となっている。
以上をふまえて、より具体的なソフトウェア構造について説明する。
【００１８】
図３は、本実施例におけるデータフローダイアグラムを示す図である。
同図に示すデータフローダイアグラム３１２は、所定の期間における４つＣＤ（Compact Disc）店のＣＤの売上枚数を集計して、地域別および店別の売上枚数を計算するという処理過程を示している。このデータフローダイアグラム３１２には、売上データ３００、売上集約処理３０２、地区別売上データ３０４、店マスタデータ３０６、店名追加処理３０８および店別売上データ３１０の６つの構成要素（Entity）が定義されている。
【００１９】
売上データ３００は、４つのＣＤ店におけるＣＤ売上枚数を示すデータである。ここで、ＣＤ店を識別するために、各ＣＤ店には「０１」〜「０４」として示す「店ＩＤ」が付与されている。また、各ＣＤ店が所属する地区を識別するために、各地区には「Ａ」または「Ｂ」として示す「地区ＩＤ」が付与されている。売上データ３００によれば、「０１」および「０２」のＣＤ店は、「Ａ」地区に属し、「０３」と「０４」のＣＤ店は「Ｂ」地区に属している。ここで「０１」のＣＤ店には、２つのノード端末２００が設置されており、それぞれのノード端末２００からは、ＣＤ売上枚数として「１枚」と「２枚」が入力されている。同様に「０２」や「０４」のＣＤ店にも、２つのノード端末２００が設置されている。すなわち、売上データ３００は、２つの地区、４つのＣＤ店、７つのノード端末２００から得られるデータである。
【００２０】
売上集約処理３０２は、各ＣＤ店に設置されるノード端末２００から得られた売上データ３００をまとめて、ＣＤ店ごとのＣＤ売上枚数を計算する。そして、このＣＤ店ごとのＣＤ売上枚数に関する情報（以下、「中間データ」とよぶ）を店名追加処理３０８に渡す。その一方、地区ごとのＣＤ売上枚数を計算して地区別売上データ３０４を生成する。
【００２１】
店名追加処理３０８は、売上集約処理３０２から受け取った中間データと店マスタデータ３０６に基づいて、店別売上データ３１０を生成する。店マスタデータ３０６は、店ＩＤと店名を対応づけるデータであり、データベース２０６から得られるデータである。店別売上データ３１０は、ＣＤ店ごとのＣＤ売上枚数を集計したデータであり、かつ、店ＩＤだけでなく対応する店名も含むデータである。
【００２２】
仮に、データフローダイアグラム３１２をＣＯＢＯＬによって実装するとする。ＣＯＢＯＬはマルチスレッド環境を想定して設計された言語ではない。そのため、売上集約処理３０２と店名追加処理３０８をマルチタスク処理として定義する場合、売上集約処理３０２のメモリ空間と、店名追加処理３０８のメモリ空間は別々に割り当てられることになる。したがって、売上集約処理３０２は、中間データをいったんファイル化し、店名追加処理３０８はこのファイルから中間データを読み出すという処理方法になる。
【００２３】
これに対し、本実施例において使用されるプログラミング言語であるＪＡＶＡ（登録商標）は、マルチスレッド環境にて使用されることを充分に想定して設計された言語である。そのため、売上集約処理３０２と店名追加処理３０８をマルチタスク処理として定義する場合でも、各処理は別々のスレッドにて実行可能である。同一プロセス空間に属するスレッド間でメモリを共有するのは簡単であることから、売上集約処理３０２は、中間データをファイル化しなくても、店名追加処理３０８に渡すことができる。このようなマルチスレッドに関する優位性と実現性については後に詳述する。
【００２４】
本実施例においては、データフローダイアグラム３１２に含まれる６つの構成要素を「ジョブ」として定義し、各ジョブごとにクラス（以下、「ジョブクラス」ともよぶ）を定義する。フロー制御部１５０は、ジョブクラスをインスタンス化することにより生成されるオブジェクト（以下、「ジョブオブジェクト」ともよぶ）に対して、その処理内容を設定することになる。以下においては、「Ｘクラス（「Ｘ」は文字列）」をインスタンス化して生成されるオブジェクトのことを単に「Ｘオブジェクト」と表記するものとする。
【００２５】
図４は、図３のＤＦＤに対応するジョブクラスの依存関係を示す図である。
UriageSourceクラス４００は、売上データ３００に対応するジョブクラスであり、売上データ３００を各ＣＤ店のノード端末２００から収集して保持するクラスである。UriageAggregatorクラス４０２は、売上集約処理３０２に対応するジョブクラスである。以下、同様に、AreaUriageTotalSinkクラス４０４は地区別売上データ３０４、MiseMaSourceクラス４０６は店マスタデータ３０６、MiseMaMatcherクラス４０８は店名追加処理３０８、MiseUriageTotalSinkクラス４１０は店別売上データ３１０にそれぞれ対応するジョブクラスである。
【００２６】
ここで、UriageSourceクラス４００が、UriageAggregatorクラス４０２へ売上データ３００を渡したり、UriageAggregatorクラス４０２をインスタンス化するための処理が記述されると、UriageSourceクラス４００とUriageAggregatorクラス４０２の結合が強くなってしまう。ジョブクラス同士の結合が強くなると、あるジョブクラスの依存関係や処理内容の変更が他の多くのジョブクラスのパフォーマンスに影響しやすくなってしまうため望ましくない。いいかえれば、再利用性・保守性・堅牢性に優れたジョブクラスを設計するためには、ジョブクラス同士の結合が弱い方が望ましい。
そこで、本実施例においては、UriageSourceクラス４００からMiseUriageTotalSinkクラス４１０までの各ジョブクラスに対して、後述するNodeFlowControllerクラス５００によって後天的に「処理を注入する（inject）」という手法を採用している。すなわち、ジョブクラスそのものは、先天的には依存関係を持たないかたちで設計されている。
【００２７】
図５は、ジョブ管理装置の基本的な機能を実現するためのクラスの関係を示す模式図である。より詳細には、次の図６および図７に関連して説明するが、同図において、まず、クラスの関係の概要を示す。
UriageProcessingModelクラス４４０は、データフローダイアグラム３１２に示した各ジョブクラスの関係を定義するクラスである。UriageProcessingModelクラス４４０は、図４に示した６つのジョブクラスを含むジョブクラス群４２０を持つ。同図に示す菱形記号は、ＵＭＬ（Unified Modeling Language）の表記法に基づき、「集約（aggregation）」を示す記号である。すなわち、UriageProcessingModelクラス４４０は、その一部としてジョブクラス群４２０を持つ。したがって、UriageProcessingModelクラス４４０がインスタンス化されるときには、その一部であるジョブクラス群４２０も付随してインスタンス化される。UriageProcessingModelオブジェクトは、各ジョブオブジェクトを持つことになる。
【００２８】
UriageProcessingModelクラス４４０は、Connectionクラス４３０も持つ。Connectionクラス４３０は、ジョブクラス群４２０における各ジョブクラスの依存関係をリストとして管理するクラスである（以下、このようなタイプのクラスのことを「関係クラス」とよぶ）。UriageProcessingModelクラス４４０は、ジョブとその依存関係をジョブクラス群４２０とConnectionクラス４３０の機能を使って管理することになる。
【００２９】
SingleThreadFlowControllerクラス４５０は、各ジョブクラスの処理内容を定義するクラスである。SingleThreadFlowControllerクラス４５０の機能によって、エンタープライズシステム２０４が実際に稼働することになる。SingleThreadFlowControllerクラス４５０は、UriageProcessingModelクラス４４０を持っている。より厳密には、SingleThreadFlowControllerクラス４５０は、UriageProcessingModelクラス４４０への参照（reference）を設定されているが、本明細書では、参照も含めて「持つ」と定義する。したがって、UriageProcessingModelクラス４４０がインスタンス化されるときには、UriageProcessingModelクラス４４０、更に、ジョブクラス群４２０とConnectionクラス４３０が連鎖的ににインスタンス化されることになる。
【００３０】
先の図２に示した機能ブロック図と対比すると、モデル管理部１４０の機能はUriageProcessingModelクラス４４０、ジョブクラス群４２０、Connectionクラス４３０の各機能によって実現され、フロー制御部１５０の機能はSingleThreadFlowControllerクラス４５０の機能によって実現されることになる。以下、UriageProcessingModelクラス４４０のようなジョブの関係を定義するクラスことを「モデルクラス」、SingleThreadFlowControllerクラス４５０のようなジョブの処理内容を定義するクラスのことを「コントロールクラス」とよぶ。
【００３１】
図６は、ジョブクラスとモデルクラスの関係を示すクラス図である。
前の図５に示したように、UriageProcessingModelクラス４４０は、UriageSourceクラス４００からMiseUriageTotalSinkクラス４１０までの６つのジョブクラスを持つ。UriageProcessingModelクラス４４０自体は、SingleThreadFlowControllerクラス４５０に持たれている。UriageProcessingModelクラス４４０は、ProcessingModelクラス４６０を継承するモデルクラスである。すなわちUriageProcessingModelクラス４４０は、ProcessingModelクラス４６０において定義された機能を受け継ぎつつ、ＣＤの売上処理を管理するために特有の機能が追加されたクラスとして定義される。ProcessingModelクラス４６０の作成にあたっては、ＣＤの売上処理を管理するために特有の機能のみを追加すればよいので、スクラッチからUriageProcessingModelクラス４４０自体を作成するのに比べて、開発や保守にともなう負担が軽減される。以下、ProcessingModelクラス４６０のように、モデルクラスの継承元となる、基本的なクラスのことを「モデルベースクラス」とよぶことにする。ProcessingModelクラス４６０は、Connectionクラス４３０を持つ。したがって、ProcessingModelクラス４６０を継承するUriageProcessingModelクラス４４０も、Connectionクラス４３０を持つことになる。
【００３２】
６つのジョブクラスのうち、UriageSourceクラス４００とMiseMaSourceクラス４０６はRecordStreamSourceクラス４８０を継承するジョブクラスである。RecordStreamSourceクラス４８０は、売上データ３００や店マスタデータ３０６のようにジョブの前提となるデータを管理するための基本仕様が定義されたクラスである。UriageAggregatorクラス４０２は、RecordStreamAggregatorクラス４８２を継承する。RecordStreamAggregatorクラス４８２は、売上集約処理３０２のようにデータを集約するジョブについての基本仕様が定義されたクラスである。MiseMaMatcherクラス４０８は、RecordStreamMatcherクラス４８４を継承する。RecordStreamMatcherクラス４８４は、店名追加処理３０８のように２種類のデータを結合するジョブについての基本仕様が定義されたクラスである。MiseUriageTotalSinkクラス４１０とAreaUriageTotalSinkクラス４０４は、RecordStreamSinkクラス４８６を継承する。RecordStreamSinkクラス４８６は、地区別売上データ３０４や店別売上データ３１０のようにジョブの処理結果として生成されるデータを管理するための基本仕様が定義されたクラスである。
このように、６つのジョブクラスは、４種類のクラス（以下、「ジョブベースクラス」とよぶ）のいずれかを継承している。更に遡ると、すべてのジョブベースクラスは、Nodeクラス４９０を継承する。Nodeクラス４９０は、ジョブのタイプによらない基本的な仕様が定義されたクラスである。
【００３３】
Nodeクラス４９０は、NodeFlowControllerクラス５００を包含する。NodeFlowControllerクラス５００は、ジョブオブジェクトの処理内容を決定するためのクラスである（以下、このようなクラスのことを「処理クラス」とよぶ）。そのため、ジョブクラスがインスタンス化されると、ジョブオブジェクトごとに処理オブジェクトが生成されることになる。ただし、ジョブクラスがインスタンス化される時点においては、処理クラスには特定の処理内容は設定されない。後に詳述する方法にて、SingleThreadFlowControllerクラス４５０、すなわち、コントロールクラスが処理を注入するときに、具体的な処理内容が設定される。
【００３４】
同図に示すクラス図によれば、データフローダイアグラム３１２に対応するクラスでありジョブクラスやモデルクラスのほかに、ジョブベースクラスやモデルベースクラスが定義されている。したがって、開発者がエンタープライズシステム２０４を設計するときには、あらかじめ用意されているジョブベースクラスやモデルベースクラスの基本仕様を利用しながら、設計対象となるエンタープライズシステム２０４に特有の機能をジョブクラスやモデルクラスに定義すればよい。これにより、クラスの再利用性というオブジェクト指向言語の特性を効果的に利用できる。エンタープライズシステム２０４の場合、何百、何千というジョブの基本仕様は数パターンに集約できることが多いため、オブジェクト指向言語の継承機能は特に有効である。
【００３５】
図７は、処理クラスの継承に関するクラス図である。
前の図６で見たように、NodeFlowControllerクラス５００は、ジョブオブジェクトの処理内容を定義するための処理クラスである。NodeFlowControllerクラス５００からSTNodeFlowControllerクラス５０２が継承され、更に、STRecordStreamSourceクラス５１０、STRecordStreamMatcherクラス５１２、STRecordStreamAggregatorクラス５１４およびSTRecordStreamSinkクラス５１６の４種類の処理クラスが継承されている。STRecordStreamSourceクラス５１０は、RecordStreamSourceクラス４８０に対応して、その処理内容を定義するためのクラスである。STRecordStreamMatcherクラス５１２、STRecordStreamAggregatorクラス５１４およびSTRecordStreamSinkクラス５１６は、それぞれ、RecordStreamMatcherクラス４８４、RecordStreamAggregatorクラス４８２およびRecordStreamSinkクラス４８６に対応してそれらの処理内容を定義するクラスである。NodeFlowControllerクラス５００から継承された４種類の処理クラスによって、ジョブクラスの処理内容が定義されることになる。
以上のクラス図をふまえ、サンプルのソースコードを参照しながら、基幹的な処理の内容を処理順序にしたがって説明する。以下に示すソースコードはＪＡＶＡ（登録商標）にて記述されている。
【００３６】
図８は、エンタープライズシステムの実行開始にあたって、最初に実行される関数を示す図である。
この関数（メソッド：method）はdoTest関数である。doTest関数は、UriageProcessingModelクラス４４０のpublicでstaticなメンバ関数であり、UriageProcessingModelクラス４４０の外からコール可能である。doTest関数が実行されると、UriageProcessingModelクラス４４０がインスタンス化され、testProcessingModelという名前のモデルオブジェクトが生成される（Ｓ１００）。インスタンス化にともなって実行される詳細な処理内容については、次の図９に関連して説明する。
【００３７】
次に、SingleThreadFlowControllerクラス４５０がインスタンス化され、singleThreadFlowControllerという名前のコントロールオブジェクトが生成される（Ｓ２００）。インスタンス化にともなって実行される詳細な処理内容については、後の図１０に関連して説明する。
【００３８】
最後に、コントロールオブジェクトのdoTask関数に生成されたばかりのモデルオブジェクトが引数として渡されている（Ｓ３００）。doTask関数に関する詳細な処理内容については、後の図１０以降に関連して説明する。
【００３９】
まとめると、doTest関数は、モデルオブジェクトとコントロールオブジェクトを生成し、コントロールオブジェクトにモデルオブジェクトを渡して、コントロールオブジェクトに所定の処理を実行させている。
【００４０】
図９は、モデルオブジェクト生成時に実行されるソースコードを示す図である。
Ｓ１００において、UriageProcessingModelクラス４４０がインスタンス化されるときには、まず、UriageProcessingModel()として示されるコンストラクタ関数が実行される（Ｓ１０２）。このコンストラクタ関数の実行に際して、各ジョブクラスがインスタンス化される（Ｓ１０４）。ここでは、UriageProcessingModelクラス４４０のメンバ変数として、UriageSourceクラス４００、MiseMaSourceクラス４０６、UriageAggregatorクラス４０２、MiseMaMatcherクラス４０８、MiseUriageTotalSinkクラス４１０およびAreaUriageTotalSinkクラス４０４の各ジョブクラスがインスタンス化され、それぞれ、uriageSource、miseMaSource、uriageAggregator、miseMaMatcher、miseUriageTotalSinkrおよびareaUriageTotalSinkという名前のジョブオブジェクトが生成される。なお、各ジョブオブジェクトの生成に際しては、それぞれ、NodeFlowControllerクラス５００から処理オブジェクトが生成される。ただし、この段階では処理オブジェクトには特段の処理内容は定義されない。また、UriageProcessingModelクラス４４０のインスタンス化に際しては、モデルベースクラスが持っている関係クラス、すなわち、Connectionクラス４３０もインスタンス化される。Connectionクラス４３０は、リスト形式にて各ジョブオブジェクトのつながりを管理するためのクラスである。
【００４１】
次に、コンストラクタ関数の中の、createModel関数が実行される（Ｓ１０６）。これにより、Ｓ１０４にて生成された各ジョブオブジェクトが関係オブジェクトにノードとして登録される。こうして、必要なジョブオブジェクトとそのつながりが定義される。いいかえれば、モデルオブジェクトは、その生成時に、登場キャラクタたるジョブオブジェクトと、その関係を示す関係オブジェクトを生成する。
【００４２】
図１０は、コントロールオブジェクト生成時とデータフローの実行開始に際して実行されるソースコードを示す図である。
前の図８に示したdoTest関数のＳ２００において、SingleThreadFlowControllerクラス４５０がインスタンス化される。このとき、まず、SingleThreadFlowController()として示されるコンストラクタ関数が実行される（Ｓ２０２）。このコンストラクタ関数の実行によって、ProcessingModelクラス４６０からmodelという名前の変数が用意される。このProcessingModelクラス４６０は、UriageProcessingModelクラス４４０の継承元となるモデルベースクラスであるから、この段階では、modelという名前の変数には、ＣＤの売上処理に関する具体的なモデルは設定されない。そして、SingleThreadFlowControllerクラス４５０からsingleThreadFlowControllerという名前のコントロールオブジェクトが生成されることになる。
【００４３】
こうして、図８のＳ１００とＳ２００に示した、モデルオブジェクトとコントロールオブジェクトの生成が完了し、図６に示した各クラスに基づいてさまざまなオブジェクトが生成されることになる。ここまでの処理のことを「生成初期化処理」とよぶことにする。
【００４４】
先に示した図８のdoTest関数は、生成初期化処理が終了すると、コントロールオブジェクトのdoTask関数をコールしている。このとき、モデルオブジェクトがコントロールオブジェクトのdoTask関数の引数として渡されている。モデルオブジェクトは、setModel関数によって、Ｓ２０４にて生成されたmodelという名前のオブジェクトに、Ｓ１００にて生成されたＣＤの売上処理に関するtestProcessingModelという名前のモデルオブジェクトを設定している（Ｓ３１０）。こうして、コントロールオブジェクトは、処理の対象とすべき具体的なモデルオブジェクトを取得する。
【００４５】
次に、doTask関数は、ジョブオブジェクト間でデータを送受するための容れ物となるオブジェクトを設定するためのinjectRecordStream関数を実行し（Ｓ３２０）、各ジョブオブジェクトの処理を注入するためのinjectFlowController関数を実行する（Ｓ３３０）。最後に、mainTask関数を実行して、モデルオブジェクトが包含する各ジョブオブジェクトに処理を実行させる（Ｓ３４０）。なお、Ｓ３１０からＳ３３０までの処理のことを「注入初期化処理」とよぶことにする。
【００４６】
図１１は、図１０のＳ３１０からＳ３４０までの処理に対応するソースコードを示す図である。
前の図１０に示したdoTask関数のＳ３２０の実行にともなって、injectRecordStream関数が実行される。これによって、ジョブオブジェクト間でデータを受け渡すためのオブジェクトとして、STRecordStreamクラスがインスタンス化される。このように、ジョブオブジェクト間においてデータ受け渡しするためのフォーマットも、コントロールオブジェクト側にて定義される。次に、doTask関数のＳ３３０の実行にともなって、injectFlowController関数が実行される。injectFlowController関数は、関係オブジェクトを走査して、順次ジョブオブジェクトを選択し、各ジョブオブジェクトについてinjectFlowControllerToNode関数を実行する（Ｓ３３２）。
【００４７】
このinjectFlowControllerToNode関数においては、一時的な処理オブジェクトnfcが生成される。次に、処理対象となるジョブオブジェクトがどのタイプのジョブベースクラスに基づくかが判定される。たとえば、処理対象のジョブオブジェクトが、RecordStreamSourceクラス４８０に基づくときには、nfcという名前の処理オブジェクトには、STRecordStreamSourceクラス５１０に基づく処理オブジェクトが設定される。たとえば、UriageAggregatorオブジェクトは、RecordStreamAggregatorクラス４８２に基づくので、nfcにはSTRecordStreamAggregatorオブジェクトが設定される。こうして、処理オブジェクトnfcには、４種類のオブジェクトのうちのいずれかが設定される。そして、setTargetNode関数によって、処理対象のジョブオブジェクトに対応する処理オブジェクトとして設定される（Ｓ３３４）。この段階で、ジョブオブジェクトの処理内容が決定することになる。すなわち、コントロールオブジェクトによってジョブオブジェクトに処理が「注入」される。
【００４８】
注入初期化処理が完了すると、エンタープライズシステム２０４を実際に稼働させるためのmainTask関数が実行される（Ｓ３４０）。図３のデータフローダイアグラム３１２に示したように、全体としての処理は、売上データ３００を前提として開始される。そのため、まず、関係オブジェクトを走査して、RecordStreamSourceクラス４８０に基づくジョブオブジェクトを特定する（Ｓ３４２）。ただし、MiseMaSourceオブジェクトのように、他のジョブオブジェクトによる中間データと共に利用されるジョブオブジェクトの場合には、RecordStreamSourceクラス４８０に基づくジョブオブジェクトであっても、ここでは処理対象としない（Ｓ３４４）。isMaSource関数は、これを調べるための関数である。
【００４９】
MiseMaSourceクラス４０６に基づくUriageSourceオブジェクトが検出されると、対応する処理オブジェクトが取り出され（Ｓ３４６）、その処理オブジェクトのdoTask関数が実行される（Ｓ３４８）。以後は図示しないが、UriageSourceオブジェクトに対応する処理オブジェクトのdoTask関数は、自分の処理が終了するときに、関係オブジェクトを参照して次の処理対象となるジョブであるUriageAggregatorオブジェクトを特定する。UriageAggregatorオブジェクトの処理オブジェクトが取り出され、その処理オブジェクトの処理関数であるdoTask関数が実行される。このdoTask関数も、自分の処理が終了するときには、AreaUriageTotalSinkオブジェクトとMiseMaMatcherオブジェクトを次の処理対象として特定する。なお、MiseMaMatcherクラス４０８の処理オブジェクトは、自分の処理に先立って、MiseMaSourceクラス４０６の処理オブジェクトにdoTask関数の実行を指示し、その実行結果を待ってから、自分の処理を実行し、MiseUriageTotalSinkオブジェクトを次の処理対象として特定する。
【００５０】
このように、データフローダイアグラム３１２に示された、いいかえれば、関係オブジェクトに管理されている依存関係にしたがって、複数のジョブオブジェクトが連鎖的に処理を実行することになる。
【００５１】
以上の実施例に示したジョブ管理装置１００によれば、モデルオブジェクトとコントロールオブジェクトによって、ジョブの静的な関係定義と、ジョブの動的な処理定義を明確に分離することができる。
ＣＯＢＯＬなどの手続き型言語の場合、これら２種類の定義は一体としてなされることが多かった。そのため、開発者は、ジョブの静的な関係定義と動的な処理定義を同時に意識しながらシステムを設計する必要があった。これに対して、本実施例にて示したフレームワークによれば、これら２種類の定義を明確に分離できる。そのため、ジョブの処理定義に過度に影響されることなく、ジョブの関係定義を行うことができる。また、その逆も真である。このような、分離設計を可能とするフレームワークは、エンタープライズシステム２０４の拡張性・保守性・堅牢性を高めることができる。
【００５２】
たとえば、一部のジョブオブジェクトにだけ処理を注入することにより、エンタープライズシステム２０４の一部の機能だけをテストする作業を、コントロールオブジェクト側の変更操作だけで実現できる。
具体例として、１００個のジョブオブジェクトによって構成されるエンタープライズシステム２０４のうち、３個のジョブオブジェクトの機能だけをテストしたい場合について説明する。このような場合、まず、１００個のジョブオブジェクトを生成しておく。そして、実際には、この３個のジョブオブジェクトにだけ処理を注入する。次に、さきほどの３個のジョブオブジェクトを含む５個のジョブオブジェクトの機能をテストしたい場合には、生成済の１００個のジョブオブジェクトのうち、今度は５個のジョブオブジェクトに処理を注入する。すなわち、はじめに１００個のジョブオブジェクトを生成しておけば、２回目のテストのために新たにテスト対象として加わった２個のジョブオブジェクトを生成する必要がない。このような処理方法によると、最初に全てのジョブオブジェクトを生成しておけば、テスト対象の変更により新たなインスタンス化処理を実行しなくて済むというメリットがある。
【００５３】
本実施例に示すエンタープライズシステム２０４の場合、ジョブオブジェクトはすべてモデルクラスによって生成され、他のジョブクラスから生成されることはない。このため、ジョブオブジェクトの生成に関しても、ジョブクラスに先天的な依存関係を持たさなくて済む。これにより、各ジョブクラスの独立性を高めることができる。また、プログラマは、UriageProcessingModelクラス４４０を参照することにより、処理対象となるジョブクラスを一元的に参照できるため、ソースコードの可読性を高める効果もある。
【００５４】
また、図６に関連して説明したように、ジョブクラスは典型的な４つのジョブベースクラスのいずれかを継承するかたちで定義されているため、何十、何百、何千というジョブオブジェクトを制御する場合であっても、ジョブクラスの設計負担が大幅に軽減される。これは、処理クラスやモデルクラスなど他のクラスについても同様である。
【００５５】
更に、Ｓ３３２のinjectFlowControllerToNode関数に示したように、各ジョブクラスの由来に応じて、割り当てるべき処理クラスが特定されている。したがって、多種類のジョブクラスに対して、多種類の処理クラスを割り当てる場合であっても、ジョブクラスのタイプに応じて、処理クラスのタイプを結びつけるという方法により、ジョブクラスと処理クラスの対応関係に関するソースコードの可読性が向上する。
【００５６】
本実施例においては、シングルスレッドモデルを前提としてシステムを説明したが、これをマルチスレッド化することも容易である。たとえば、SingleThreadFlowControllerクラス４５０のmainTask関数は、RecordStreamSourceクラス４８０に基づくジョブオブジェクトであるか否かにかかわらず、全てのジョブオブジェクトに対して一斉にdoTask関数の開始を指示してもよい。
【００５７】
マルチスレッドモデルについて図４を再度参照しながら説明する。
まず、SingleThreadFlowControllerクラス４５０は、各ジョブオブジェクトの処理オブジェクトの処理関数であるdoTask関数に実行を指示する。ここで、各doTask関数はマルチスレッド化されており、時間的に並行して実行可能な関数である。この指示によって、各doTask関数は実行待機状態に移行するが、UriageSourceオブジェクトについての処理関数だけは即座に実行開始となる。
【００５８】
UriageSourceオブジェクトについての処理関数が実行を完了すると、UriageAggregatorオブジェクトの処理関数が実行開始となる。UriageAggregatorクラス４０２の処理関数が実行完了すると、AreaUriageTotalSinkクラス４０４とMiseMaMatcherクラス４０８は同時並行的に実行開始を指示される。AreaUriageTotalSinkクラス４０４とMiseMaMatcherクラス４０８は依存関係を持たないので結果として並行処理が可能となる。MiseMaMatcherクラス４０８は自己の処理関数を実行するために、MiseMaSourceクラス４０６の処理関数に実行を指示し、その処理結果を受けたときに自分の処理関数を実行開始することになる。このときに、並行してAreaUriageTotalSinkオブジェクトの処理関数は実行されている。このため、ＣＯＢＯＬが苦手なマルチタスク処理を、マルチスレッド処理として実現できるため、システム全体としてのパフォーマンスを向上させることができる。特に、ＤＦＤにおいて、フローが枝分かれするほど、同時並行的に実行できる処理関数を増やすことができる。
【００５９】
また、ジョブ管理装置１００の機能は、複数のハードウェア資源によって実現されてもよい。たとえば、ジョブオブジェクトは、複数のジョブ実行装置に分散配置されてもよい。このような態様によれば、ジョブ実行装置Ａでジョブオブジェクトαの処理を実行しつつ、ジョブ実行装置Ｂでジョブオブジェクトβの処理を実行するという処理方法が可能となる。これにより、時間的な効率化だけでなく、処理負荷の分散も効率的に行うことができる。コントロールクラスは、ジョブ実行装置群において処理負荷が局所化しないように、他のジョブ実行装置よりも処理負荷が軽い状態にあるジョブ実行装置に対して優先的にジョブを割り当ててもよい。従来、ジョブの分散配置を実現するためには、複数のジョブ実行装置への分散配置を前提とした設計が必要であったが、本実施例に示した設計方法によれば、ジョブ管理装置１００から外部のジョブ実行装置にジョブの実行主体を移行させるのが容易となる。
【００６０】
以上、実施の形態をもとに本発明を説明した。なお本発明はこの実施の形態に限定されることなく、そのさまざまな変形例もまた、本発明の態様として有効である。たとえば、本実施例においては、エンタープライズシステムを想定して説明したが、より具体的には、電子商取引、物流管理などへの応用が考えられる。また、本実施例において示したフレームワークは、ワークフロー管理のように、複数のジョブを定義して制御するというモデルに広く応用可能である。
【００６１】
請求項に記載のジョブオブジェクト生成部の機能は、本実施例においては主としてUriageProcessingModelクラス４４０によって実現される。請求項に記載のジョブリスト情報生成部の機能は、本実施例においては主としてUriageProcessingModelクラス４４０やConnectionクラス４３０によって実現される。請求項に記載の処理注入部と実行制御部の機能は、本実施例においては、主としてSingleThreadFlowControllerクラス４５０によって実現される。したがって、請求項に記載のモデルオブジェクト生成部の機能は、本実施例においては主としてモデル管理部１４０、とりわけ、UriageProcessingModelクラス４４０によって実現される。請求項に記載のコントロールオブジェクト生成部の機能は、本実施例においてはフロー制御部１５０、とりわけ、SingleThreadFlowControllerクラス４５０によって実現される。請求項に記載の処理関数は、本実施例においては、たとえば、Ｓ３４８にて示したdoTask関数が相当する。
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【図面の簡単な説明】
【００６２】
【図１】エンタープライズシステムのハードウェア構成図である。
【図２】ジョブ管理装置の機能ブロック図である。
【図３】本実施例におけるデータフローダイアグラムを示す図である。
【図４】図３のＤＦＤに対応するジョブクラスの依存関係を示す図である。
【図５】ジョブ管理装置の基本的な機能を実現するためのクラスの関係を示す模式図である。
【図６】ジョブクラスとモデルクラスの関係を示すクラス図である。
【図７】処理クラスの継承に関するクラス図である。
【図８】エンタープライズシステムの実行開始にあたって、最初に実行される関数を示す図である。
【図９】モデルオブジェクト生成時に実行されるソースコードを示す図である。
【図１０】コントロールオブジェクト生成時とデータフローの実行開始に際して実行されるソースコードを示す図である。
【図１１】図１０のＳ３１０からＳ３４０までの処理に対応するソースコードを示す図である。
【符号の説明】
【００６３】
１００ ジョブ管理装置、 １１０ ユーザインタフェース処理部、 １２０ 通信部、 １３０ データ処理部、 １４０ モデル管理部、 １５０ フロー制御部、 ２００ ノード端末、 ２０２ インターネット、 ２０４ エンタープライズシステム、 ２０６ データベース、 ３００ 売上データ、 ３０２ 売上集約処理、 ３０４ 地区別売上データ、 ３０６ 店マスタデータ、 ３０８ 店名追加処理、 ３１０ 店別売上データ、 ３１２ データフローダイアグラム、 ４００ UriageSourceクラス、 ４０２ UriageAggregatorクラス、 ４０４ AreaUriageTotalSinkクラス、 ４０６ MiseMaSourceクラス、 ４０８ MiseMaMatcherクラス、 ４１０ MiseUriageTotalSinkクラス、 ４２０ ジョブクラス群、 ４３０ Connectionクラス、 ４４０ UriageProcessingModelクラス、 ４５０ SingleThreadFlowControllerクラス、 ４６０ ProcessingModelクラス、 ４８０ RecordStreamSourceクラス、 ４８２ RecordStreamAggregatorクラス、 ４８４ RecordStreamMatcherクラス、 ４８６ RecordStreamSinkクラス、 ４９０ Nodeクラス、 ５００ NodeFlowControllerクラス、 ５０２ STNodeFlowControllerクラス、 ５１０ STRecordStreamSourceクラス、 ５１２ STRecordStreamMatcherクラス、 ５１４ STRecordStreamAggregatorクラス、 ５１６ STRecordStreamSinkクラス。
【特許請求の範囲】
【請求項１】
前段にあたるジョブの出力データに基づいて後段にあたるジョブが実行されるように依存関係が定められた複数のジョブを実行するための装置であって、
ジョブのタイプに応じてあらかじめ定義されたクラスから、ジョブオブジェクトを生成するジョブオブジェクト生成部と、
各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成するジョブリスト情報生成部と、
ジョブの処理内容を示す処理関数を、ジョブオブジェクトが生成された後に設定する処理注入部と、
前記ジョブリスト情報を参照してジョブオブジェクトを選択し、そのジョブオブジェクトについて設定された処理関数を実行させる実行指示部と、
を備えることを特徴とするジョブ管理装置。
【請求項２】
前記実行指示部によって選択されたジョブオブジェクトの処理関数は、前記ジョブリスト情報に基づいて次に出力データを渡すべきジョブを特定し、特定したジョブについての処理関数を実行させることを特徴とする請求項１に記載のジョブ管理装置。
【請求項３】
ジョブオブジェクトは、他のジョブオブジェクトによって生成されることはなく、前記ジョブオブジェクト生成部によって直接生成されることを特徴とする請求項１または２に記載のジョブ管理装置。
【請求項４】
前記ジョブオブジェクト生成部と前記ジョブリスト情報生成部の各機能をその機能の一部として含むオブジェクトとしてモデルオブジェクトを生成するモデルオブジェクト生成部と、
前記処理注入部と前記実行指示部の各機能をその機能の一部として含むオブジェクトとしてコントロールオブジェクトを生成するコントロールオブジェクト生成部と、を更に備え、
前記コントロールオブジェクトは、前記モデルオブジェクトを処理対象とすることによって、前記処理注入部と前記実行指示部の各機能を発揮させることを特徴とする請求項１から３のいずれかに記載のジョブ管理装置。
【請求項５】
ジョブオブジェクトは、処理関数をメンバ関数として含む処理オブジェクトと関連づけられ、
前記処理注入部は、ジョブオブジェクトの生成後に、ジョブオブジェクトに処理オブジェクトを設定することにより、ジョブオブジェクトについての処理関数を設定することを特徴とする請求項１から４のいずれかに記載のジョブ管理装置。
【請求項６】
前記処理注入部は、ジョブオブジェクトが基づくクラスのタイプに応じて、設定すべき処理オブジェクトを選択することを特徴とする請求項５に記載のジョブ管理装置。
【請求項７】
各処理関数は時間的に並行して実行可能であって、
所定の処理関数は、前記ジョブリスト情報を参照して次に実行すべき複数の処理関数を特定し、前記複数の処理関数を時間的に並行して実行させることを特徴とする請求項１から６のいずれかに記載のジョブ管理装置。
【請求項８】
前記ジョブオブジェクト生成部は、ネットワークを介して接続された複数の外部装置に対して複数のジョブオブジェクトを分散配置可能であり、
前記複数の外部装置に分散配置された各ジョブオブジェクトの処理関数は時間的に並行して実行可能であることを特徴とする請求項１から７のいずれかに記載のジョブ管理装置。
【請求項９】
組織業務の構成単位としてのジョブに対応するジョブオブジェクトを、ジョブのタイプに応じてあらかじめ定義されたクラスから生成するステップと、
各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成するステップと、
ジョブの処理内容を示す処理関数を、ジョブオブジェクト生成後に設定するステップと、
前記ジョブリスト情報を参照してジョブオブジェクトを選択し、そのジョブオブジェクトについて設定された処理関数を実行させるステップと、
を備えることを特徴とするジョブ管理方法。
【請求項１０】
前段にあたるジョブの出力データに基づいて後段にあたるジョブが実行されるように、複数のジョブの依存関係を定義するオブジェクトとしてモデルオブジェクトを生成する機能と、
各ジョブの処理内容を定義するコントロールオブジェクトを生成する機能と、
コントロールオブジェクトの第１のメンバ関数を実行することにより、モデルオブジェクトにおいて定義されるジョブの処理内容を設定する機能と、
コントロールオブジェクトの第２のメンバ関数を実行することにより、第１のジョブについての処理を実行させる機能と、
前記依存関係にしたがって、前記第１のジョブの出力データを渡すべき第２のジョブを特定する機能と、
前記第２のジョブについての処理を実行させる機能と、
をコンピュータに発揮させることにより、複数のジョブを依存関係にしたがって実行させることを特徴とするジョブ管理プログラム。
【請求項１】
前段にあたるジョブの出力データに基づいて後段にあたるジョブが実行されるように依存関係が定められた複数のジョブを実行するための装置であって、
ジョブのタイプに応じてあらかじめ定義されたクラスから、ジョブオブジェクトを生成するジョブオブジェクト生成部と、
各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成するジョブリスト情報生成部と、
ジョブの処理内容を示す処理関数を、ジョブオブジェクトが生成された後に設定する処理注入部と、
前記ジョブリスト情報を参照してジョブオブジェクトを選択し、そのジョブオブジェクトについて設定された処理関数を実行させる実行指示部と、
を備えることを特徴とするジョブ管理装置。
【請求項２】
前記実行指示部によって選択されたジョブオブジェクトの処理関数は、前記ジョブリスト情報に基づいて次に出力データを渡すべきジョブを特定し、特定したジョブについての処理関数を実行させることを特徴とする請求項１に記載のジョブ管理装置。
【請求項３】
ジョブオブジェクトは、他のジョブオブジェクトによって生成されることはなく、前記ジョブオブジェクト生成部によって直接生成されることを特徴とする請求項１または２に記載のジョブ管理装置。
【請求項４】
前記ジョブオブジェクト生成部と前記ジョブリスト情報生成部の各機能をその機能の一部として含むオブジェクトとしてモデルオブジェクトを生成するモデルオブジェクト生成部と、
前記処理注入部と前記実行指示部の各機能をその機能の一部として含むオブジェクトとしてコントロールオブジェクトを生成するコントロールオブジェクト生成部と、を更に備え、
前記コントロールオブジェクトは、前記モデルオブジェクトを処理対象とすることによって、前記処理注入部と前記実行指示部の各機能を発揮させることを特徴とする請求項１から３のいずれかに記載のジョブ管理装置。
【請求項５】
ジョブオブジェクトは、処理関数をメンバ関数として含む処理オブジェクトと関連づけられ、
前記処理注入部は、ジョブオブジェクトの生成後に、ジョブオブジェクトに処理オブジェクトを設定することにより、ジョブオブジェクトについての処理関数を設定することを特徴とする請求項１から４のいずれかに記載のジョブ管理装置。
【請求項６】
前記処理注入部は、ジョブオブジェクトが基づくクラスのタイプに応じて、設定すべき処理オブジェクトを選択することを特徴とする請求項５に記載のジョブ管理装置。
【請求項７】
各処理関数は時間的に並行して実行可能であって、
所定の処理関数は、前記ジョブリスト情報を参照して次に実行すべき複数の処理関数を特定し、前記複数の処理関数を時間的に並行して実行させることを特徴とする請求項１から６のいずれかに記載のジョブ管理装置。
【請求項８】
前記ジョブオブジェクト生成部は、ネットワークを介して接続された複数の外部装置に対して複数のジョブオブジェクトを分散配置可能であり、
前記複数の外部装置に分散配置された各ジョブオブジェクトの処理関数は時間的に並行して実行可能であることを特徴とする請求項１から７のいずれかに記載のジョブ管理装置。
【請求項９】
組織業務の構成単位としてのジョブに対応するジョブオブジェクトを、ジョブのタイプに応じてあらかじめ定義されたクラスから生成するステップと、
各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成するステップと、
ジョブの処理内容を示す処理関数を、ジョブオブジェクト生成後に設定するステップと、
前記ジョブリスト情報を参照してジョブオブジェクトを選択し、そのジョブオブジェクトについて設定された処理関数を実行させるステップと、
を備えることを特徴とするジョブ管理方法。
【請求項１０】
前段にあたるジョブの出力データに基づいて後段にあたるジョブが実行されるように、複数のジョブの依存関係を定義するオブジェクトとしてモデルオブジェクトを生成する機能と、
各ジョブの処理内容を定義するコントロールオブジェクトを生成する機能と、
コントロールオブジェクトの第１のメンバ関数を実行することにより、モデルオブジェクトにおいて定義されるジョブの処理内容を設定する機能と、
コントロールオブジェクトの第２のメンバ関数を実行することにより、第１のジョブについての処理を実行させる機能と、
前記依存関係にしたがって、前記第１のジョブの出力データを渡すべき第２のジョブを特定する機能と、
前記第２のジョブについての処理を実行させる機能と、
をコンピュータに発揮させることにより、複数のジョブを依存関係にしたがって実行させることを特徴とするジョブ管理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００７−１５６７９１（Ｐ２００７−１５６７９１Ａ）
【公開日】平成１９年６月２１日（２００７．６．２１）
【国際特許分類】
【出願番号】特願２００５−３５０６４３（Ｐ２００５−３５０６４３）
【出願日】平成１７年１２月５日（２００５．１２．５）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【公開日】平成１９年６月２１日（２００７．６．２１）
【国際特許分類】
【出願日】平成１７年１２月５日（２００５．１２．５）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
[ Back to top ]