JP5033343B2

JP5033343B2 - ジョブ管理装置およびジョブ管理方法

Info

Publication number: JP5033343B2
Application number: JP2006089277A
Authority: JP
Inventors: 綾太郎木村
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2006-03-28
Filing date: 2006-03-28
Publication date: 2012-09-26
Anticipated expiration: 2026-03-28
Also published as: JP2007265029A

Description

この発明は、ジョブの実行を制御するための技術、特に、依存関係を有する複数のジョブを実行制御するための技術、に関する。

企業や公共施設などの運用を支えるエンタープライズシステム（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クラス４５０とMultiThreadFlowControllerクラス４５２は、各ジョブクラスの処理内容を定義するクラスである。SingleThreadFlowControllerクラス４５０やMultiThreadFlowControllerクラス４５２の機能によって、エンタープライズシステム２０４が実際に駆動されることになる。SingleThreadFlowControllerクラス４５０は、シングルスレッドモデルにてエンタープライズシステム２０４を駆動するクラスである。MultiThreadFlowControllerクラス４５２は、マルチスレッドモデルにてエンタープライズシステム２０４を駆動するクラスである。エンタープライズシステム２０４の処理開始に際して、SingleThreadFlowControllerクラス４５０とMultiThreadFlowControllerクラス４５２のいずれかの実行モデルがユーザによって選択される。実行モデルの選択方法については、図８に関連して詳述する。

SingleThreadFlowControllerクラス４５０とMultiThreadFlowControllerクラス４５２は、共にUriageProcessingModelクラス４４０を持つことになる。より厳密には、SingleThreadFlowControllerクラス４５０やMultiThreadFlowControllerクラス４５２には、UriageProcessingModelクラス４４０への参照（reference）が設定されているが、本明細書では、参照も含めて「持つ」と定義する。したがって、SingleThreadFlowControllerクラス４５０かMultiThreadFlowControllerクラス４５２のいずれかの実行モデルが選択され、UriageProcessingModelクラス４４０がインスタンス化されるときには、更に、ジョブクラス群４２０とConnectionクラス４３０が連鎖的ににインスタンス化されることになる。

先の図２に示した機能ブロック図と対比すると、モデル管理部１４０の機能はUriageProcessingModelクラス４４０、ジョブクラス群４２０、Connectionクラス４３０の各機能によって実現され、フロー制御部１５０の機能はSingleThreadFlowControllerクラス４５０またはMultiThreadFlowControllerクラス４５２の機能によって実現されることになる。以下、UriageProcessingModelクラス４４０のようなジョブの内容とその依存関係を定義するクラスことを「モデルクラス」、SingleThreadFlowControllerクラス４５０やMultiThreadFlowControllerクラス４５２のようなジョブの処理内容を定義するクラスのことを「コントロールクラス」とよぶ。
以下においては、MultiThreadFlowControllerクラス４５２によるマルチスレッドモデルを題材として説明する。なお、参考までに、シングルスレッドモデルについては本件の関連案件である特願２００５−３５０６４３に詳しい。

図６は、ジョブクラスとモデルクラスの関係を示すクラス図である。
前の図４に示したように、UriageProcessingModelクラス４４０は、UriageSourceクラス４００からMiseUriageTotalSinkクラス４１０までの６つのジョブクラスを持つ。UriageProcessingModelクラス４４０自体は、MultiThreadFlowControllerクラス４５２に持たれている。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クラス５００は、ジョブオブジェクトの処理内容を決定するためのクラスである（以下、このようなクラスのことを「処理クラス」とよぶ）。そのため、ジョブクラスがインスタンス化されると、ジョブオブジェクトごとに処理オブジェクトも生成されることになる。ただし、ジョブクラスがインスタンス化される時点においては、処理オブジェクトには特定の処理内容は設定されない。後に詳述する方法にて、MultiThreadFlowControllerクラス４５２、すなわち、コントロールクラスが処理を注入するときに、具体的な処理内容が設定される。

同図に示すクラス図によれば、データフローダイアグラム３１２に対応するクラスであるジョブクラスやモデルクラスのほかに、ジョブベースクラスやモデルベースクラスが定義されている。したがって、開発者がエンタープライズシステム２０４を設計するときには、あらかじめ用意されているジョブベースクラスやモデルベースクラスの基本仕様を利用しながら、設計対象となるエンタープライズシステム２０４に特有の機能をジョブクラスやモデルクラスに定義すればよい。これにより、クラスの再利用性というオブジェクト指向言語の特性を効果的に利用できる。エンタープライズシステム２０４の場合、何百、何千というジョブの基本仕様は数パターンに集約できることが多いため、オブジェクト指向言語の継承機能は特に有効である。

図７は、処理クラスの継承に関するクラス図である。
前の図６で見たように、NodeFlowControllerクラス５００は、ジョブオブジェクトの処理内容を定義するための処理クラスである。NodeFlowControllerクラス５００からMTNodeFlowControllerクラス５０２が継承され、更に、MTRecordStreamSourceクラス５１０、MTRecordStreamMatcherクラス５１２、MTRecordStreamAggregatorクラス５１４およびMTRecordStreamSinkクラス５１６の４種類の処理クラスが継承されている。MTRecordStreamSourceクラス５１０は、RecordStreamSourceクラス４８０に対応して、その処理内容を定義するためのクラスである。MTRecordStreamMatcherクラス５１２、MTRecordStreamAggregatorクラス５１４およびMTRecordStreamSinkクラス５１６は、それぞれ、RecordStreamMatcherクラス４８４、RecordStreamAggregatorクラス４８２およびRecordStreamSinkクラス４８６に対応してそれらの処理内容を定義するクラスである。NodeFlowControllerクラス５００から継承された４種類の処理クラスによって、ジョブクラスの処理内容が定義されることになる。

なお、図示しないが、NodeFlowControllerクラス５００からはSTNodeFlowControllerクラスも継承され、更に、STNodeFlowControllerクラスからSTRecordStreamSourceクラス、STRecordStreamMatcherクラス、STRecordStreamAggregatorクラスおよびSTRecordStreamSinkクラスの４種類の処理クラスが継承されている。これらのクラスはシングルスレッドモデルのための処理クラスである。マルチスレッドモデルの場合には、MT系のプレフィックスを持つ処理クラス、すなわち、MTNodeFlowControllerクラス５０２のサブクラス群によって処理内容が定義され、シングルスレッドモデルの場合には、ST系のプレフィックスを持つ処理クラス、すなわち、STNodeFlowControllerクラスのサブクラス群によって処理内容が定義される。
以上のクラス図をふまえ、サンプルのソースコードを参照しながら、基幹的な処理の内容を処理順序にしたがって説明する。以下に示すソースコードはＪＡＶＡ（登録商標）にて記述されている。

図８は、エンタープライズシステムの実行開始にあたって、最初に実行される関数を示す図である。
この最初に実行される関数（メソッド：method）は、main関数である（Ｓ１０）。main関数は、UriageProcessingModelクラス４４０のpublicでstaticなメンバ関数であり、UriageProcessingModelクラス４４０の外からコール可能である。ユーザは、main関数に引数を指定するか否かによって、シングルスレッドモデルか（Ｓ１２）、マルチスレッドモデルかを選択できる（Ｓ１４）。引数が指定され、マルチスレッドモデルが選択されたとして説明する（Ｓ１４）。

マルチスレッドモデルが選択されると、doTestWithMultiThread関数が実行される。doTestWithMultiThread関数が実行されると、UriageProcessingModelクラス４４０がインスタンス化され、testProcessingModelという名前のモデルオブジェクトが生成される（Ｓ１００）。インスタンス化にともなって実行される詳細な処理内容については、次の図９に関連して説明する。

次に、MultiThreadFlowControllerクラス４５２がインスタンス化され、multiThreadFlowControllerという名前のコントロールオブジェクトが生成される（Ｓ２００）。インスタンス化にともなって実行される詳細な処理内容については、後の図１０に関連して説明する。

最後に、コントロールオブジェクトのdoTask関数にモデルオブジェクトが引数として渡されている（Ｓ３００）。このときにモデルオブジェクトが管理するジョブオブジェクトに対して、コントロールオブジェクトによる「処理の注入」が実行される。doTask関数に関する詳細な処理内容については、後の図１０以降に関連して説明する。

まとめると、doTestWithMultiThread関数は、モデルオブジェクトとコントロールオブジェクトを生成し、コントロールオブジェクトにモデルオブジェクトを渡して、コントロールオブジェクトに所定の処理を実行させている。

図９は、モデルオブジェクト生成時に実行されるソースコードを示す図である。
Ｓ１００において、UriageProcessingModelクラス４４０がインスタンス化されるときには、まず、UriageProcessingModel()として示されるコンストラクタ関数が実行される（Ｓ１０２）。このコンストラクタ関数の実行に際して、各ジョブクラスがインスタンス化される（Ｓ１０４）。ここでは、UriageProcessingModelクラス４４０のメンバ変数として、UriageSourceクラス４００、MiseMaSourceクラス４０６、UriageAggregatorクラス４０２、MiseMaMatcherクラス４０８、MiseUriageTotalSinkクラス４１０およびAreaUriageTotalSinkクラス４０４の各ジョブクラスがインスタンス化され、それぞれ、uriageSource、miseMaSource、uriageAggregator、miseMaMatcher、miseUriageTotalSinkrおよびareaUriageTotalSinkという名前のジョブオブジェクトが生成される。なお、各ジョブオブジェクトの生成に際しては、それぞれ、NodeFlowControllerクラス５００から処理オブジェクトが生成される。継承元のNodeクラス４９０がNodeFlowControllerクラス５００を持つためである。ただし、この段階では処理オブジェクトにはジョブオブジェクトごとに対応した具体的な処理内容は定義されない。また、UriageProcessingModelクラス４４０のインスタンス化に際しては、モデルベースクラスが持っている関係クラス、すなわち、Connectionクラス４３０もインスタンス化される。Connectionクラス４３０は、リスト形式にて各ジョブオブジェクトのつながりを管理するためのクラスである。

ジョブクラスの中には、後述する「プールクラス」や「アイテムクラス」を持つクラスもある。このようなタイプのジョブクラスがインスタンス化されるときには、プールクラスやアイテムクラスも付随的にインスタンス化される。アイテムクラスは、ノード端末２００やデータベース２０６から取得されるデータや、ジョブオブジェクト間で送受されるデータを保持するためのクラスである。プールクラスは、アイテムオブジェクトを所定個数を上限として保持するためのクラスである。プールクラスやアイテムクラスについては、図１４以降に関連して詳述する。

次に、コンストラクタ関数の中の、createModel関数が実行される（Ｓ１０６）。これにより、Ｓ１０４にて生成された各ジョブオブジェクトが関係オブジェクトにノードとして登録される。こうして、必要なジョブオブジェクトとそのつながりが定義される。いいかえれば、モデルオブジェクトは、その生成時に、登場キャラクタたるジョブオブジェクトと、その関係を示す関係オブジェクトを生成する。

図１０は、コントロールオブジェクト生成時とデータフローの実行開始に対応する部分のソースコードを示す図である。
前の図８に示したdoTestWithMultiThread関数のＳ２００において、MultiThreadFlowControllerクラス４５２がインスタンス化される。このとき、まず、MultiThreadFlowController()として示されるコンストラクタ関数が実行される（Ｓ２０２）。このコンストラクタ関数の実行によって、ProcessingModelクラス４６０のインスタンスを保持するmodelという名前の変数が用意される（Ｓ２０４）。このProcessingModelクラス４６０は、UriageProcessingModelクラス４４０の継承元となるモデルベースクラスであるから、この段階では、modelという名前の変数には、ＣＤの売上処理に関する具体的なモデルは設定されない。コンストラクタ関数の実行により、MultiThreadFlowControllerクラス４５２からmultiThreadFlowControllerという名前のコントロールオブジェクトが生成される（図８のＳ２００）。

こうして、図８のＳ１００とＳ２００に示した、モデルオブジェクトとコントロールオブジェクトの生成が完了し、図６に示した各クラスに基づいてさまざまなオブジェクトが生成されることになる。ここまでの処理のことを「生成初期化処理」とよぶことにする。

先に示した図８のdoTestWithMultiThread関数は、生成初期化処理が終了すると、コントロールオブジェクトのdoTask関数をコールしている（図８のＳ３００）。このとき、モデルオブジェクトがコントロールオブジェクトのdoTask関数の引数として渡されている。モデルオブジェクトは、setModel関数によって、Ｓ２０４にて生成されたmodelという名前のオブジェクトに、図８のＳ１００にて生成されたＣＤの売上処理に関するtestProcessingModelという名前のモデルオブジェクトを設定している（Ｓ３１０）。こうして、コントロールオブジェクトは、コントロール対象となる具体的なモデルオブジェクトを取得する。

次に、doTask関数は、ジョブオブジェクト間でアイテムオブジェクトを送受するための「キュークラス」をインスタンス化する（Ｓ３２０）。キュークラスは、前段にあたるジョブオブジェクトが後段にあたるジョブオブジェクトにアイテムオブジェクトを転送するときのキューとなるクラスである。キュークラスについては図１４以降に関連して詳述する。次に、各ジョブオブジェクトに処理を注入するためのinjectFlowController関数を実行する（Ｓ３３０）。なお、Ｓ３１０からＳ３３０までの処理のことを「注入初期化処理」とよぶことにする。最後に、mainTask関数を実行して、モデルオブジェクトが集約する各ジョブオブジェクトに実行開始を指示する（Ｓ３４０）。

図１１は、図１０のＳ３２０およびＳ３３０までの処理に対応するソースコードを示す図である。
前の図１０に示したdoTask関数のＳ３２０の実行にともなって、injectRecordStream関数が実行される。これによって、ジョブオブジェクト間でデータを受け渡すためのオブジェクトとして、MTRecordStreamクラスがインスタンス化される。このMTRecordStreamクラスがキュークラスに相当する。このクラスは、前段にあたるジョブオブジェクトから投入されたアイテムオブジェクトを所定個数を上限として保持するキューとして機能する。後段にあたるジョブオブジェクトは、キューオブジェクトからアイテムオブジェクトを取得し、アイテムオブジェクトが保持するデータを読み出す。たとえば、前段にあたるジョブオブジェクトのUriageSourceオブジェクトは、後段にあたるジョブオブジェクトのUriageAggregatorオブジェクトとの関係で設定されたキューオブジェクトにアイテムオブジェクトを格納し、後段のUriageAggregatorオブジェクトは、このキューオブジェクトからアイテムオブジェクトを取得する。ジョブオブジェクト間においてデータの受け渡しをするための基本的なインタフェースも、コントロールオブジェクト側にて定義される。
次に、doTask関数のＳ３３０（図１０）の実行にともなって、injectFlowController関数が実行される。injectFlowController関数は、関係オブジェクトを走査して、順次ジョブオブジェクトを選択し、各ジョブオブジェクトについてinjectFlowControllerToNode関数を実行する（Ｓ３３２）。

このinjectFlowControllerToNode関数においては、一時的な処理オブジェクトnfcが生成される。次に、処理対象となるジョブオブジェクトがどのタイプのジョブベースクラスから継承されているかが判定される。たとえば、処理対象のジョブオブジェクトが、RecordStreamSourceクラス４８０を継承するときには、nfcという名前の処理オブジェクトには、MTRecordStreamSourceクラス５１０を継承する処理オブジェクトが設定される。たとえば、UriageAggregatorオブジェクトは、RecordStreamAggregatorクラス４８２に基づくので、nfcにはMTRecordStreamAggregatorオブジェクトが設定される。こうして、処理オブジェクトnfcには、４種類の処理オブジェクトのいずれかが設定される。そして、setTargetNode関数によって、各ジョブオブジェクトに処理オブジェクトが設定される（Ｓ３３４）。この段階で、ジョブオブジェクトの処理内容が決定することになる。すなわち、コントロールオブジェクトによってジョブオブジェクトに処理が「注入」される。各処理オブジェクトは、doTask関数という名前の処理関数を備えており、この処理関数の内容が実際の処理内容を定義づけることになる。
ここでは、ジョブベースクラスに応じて割り当てるべき処理クラスを選択するアルゴリズムを示しているが、ジョブクラスごとに割り当てるべき処理クラスを選択するアルゴリズムは、これ以外にも任意に設計可能である。たとえば、外部イベントの検出等、所定の条件の成否に応じて、割り当てるべき処理クラスを選択・変更してもよい。

図１２は、図１０のＳ３４０の処理に対応するソースコードを示す図である。
注入初期化処理が完了すると、エンタープライズシステム２０４を実際に稼働させるためのmainTask関数が実行される（Ｓ３４０）。mainTask関数は、関係オブジェクトを走査してジョブオブジェクトを順次選択し、各ジョブオブジェクトに設定されている処理オブジェクトを取得する（Ｓ３４２）。

そして、処理オブジェクトのメンバ関数として提供されるstartThread関数を実行させる（Ｓ３４４）。こうして処理オブジェクトには、別々のスレッド（以下、「ワーカスレッド」とよぶ）が割り当てられ、各ジョブは別々のコンテキスト（context）で実行されることになる。図４に示したように、エンタープライズシステム２０４には６つのジョブクラスが定義され、それにあわせて６つの処理クラスがインスタンス化される。ジョブオブジェクトが６つあるためＳ３４４は６回実行され、６つのワーカスレッドが次々に実行指示されることになる。mainTask関数の実行スレッド（以下、「メインスレッド」とぶ）を含めると、計７つのスレッドが同時並行的に実行されることになる。６つのワーカスレッドのうち、MiseMaSourceクラス４０６以外についてのワーカスレッドが、threadListという名前のリストに登録される（Ｓ３４６）。

６つのワーカスレッドの実行が開始されると、mainTask関数は、threadListをチェックして登録されている各ワーカスレッドが終了しているかをjoin関数によって判定する（Ｓ３４８）。join関数は、判定対象ワーカスレッドが終了していなければブロックされる。そのため、threadListに登録されている５つのワーカスレッドのうちのいずれかが終了していなければ、join関数のブロックによってmainTask関数は終了しない。threadListに登録されている５つのワーカスレッドが終了すると、join関数によるメインスレッドのブロックが解除され、mainTask関数が終了する。これによりエンタープライズシステム２０４の全体としての処理が終了する。

MiseMaSourceクラス４０６についてのワーカスレッドは、threadListに登録されない。したがって、このワーカスレッドが終了していなくても、メインスレッドは終了可能である。MiseMaSourceクラス４０６についてのワーカスレッドをthreadListに登録しない理由は、以下の通りである。
MiseMaSourceオブジェクトの処理内容は、店マスタデータ３０６という所定のマスタデータを読み出して、MiseMaMatcherオブジェクトに転送することである。MiseMaSourceオブジェクトは、必ずしも店マスタデータ３０６の全てを読み出す必要はなく、後段にあたるMiseMaMatcherオブジェクトの処理に必要なだけ読み出せばよい。このような理由から、MiseMaSourceオブジェクトのワーカスレッドは、join関数による終了の待ち合わせ対象から除外されている。一方、UriageSourceオブジェクトは、ノード端末２００から取得された全ての売上データ３００を処理対象とするため、待ち合わせの対象となっている。すなわち、UriageSourceオブジェクトが売上データ３００の全てを取得してUriageAggregatorオブジェクトに渡し終わらなければ、mainTaskは終了しない。

図１３は、図１２のＳ３４４の処理に対応するソースコードを示す図である。
MTNodeFlowControllerクラス５０２から継承されるマルチスレッド系の処理クラスは、startThread関数をメンバ関数として備える。この関数が、MultiThreadFlowControllerクラス４５２からコールされると、新たにワーカスレッドを生成し（Ｓ３５０）、実行開始させる（Ｓ３５２）。こうして、処理関数に相当するdoTask関数がワーカスレッドにて実行される。

ただし、実行開始させられたあと、ワーカスレッドが実行状態となるか待機状態となるかは、ＤＦＤによって定義されたジョブの依存関係の影響を受ける。たとえば、MiseMaSourceオブジェクトの処理内容は、データベース２０６から店マスタデータ３０６を取得して後段のMiseMaMatcherオブジェクトに渡すことなので、MiseMaSourceオブジェクトは、通常、他のジョブの処理状態の影響を受けることなくジョブを実行可能である。一方、MiseMaMatcherオブジェクトは、MiseMaSourceオブジェクトから渡されたデータを受け取らなければジョブを実行できない。
このように、６つのワーカスレッドは実行開始されても、必ずしも全てが即時に実行状態となるわけではなく、他のジョブの処理状態に応じて待機状態と実行状態のいずれかの状態に遷移する。結果として、ＤＦＤに定義された依存関係にしたがいつつも、複数のジョブが非同期的に実行されることになる。

図１４は、ジョブオブジェクト間におけるデータ送受方法を説明するための模式図である。
ジョブ間には、関係クラスの定義にしたがって前段と後段という依存関係が定義される。図４の場合、MiseMaSourceオブジェクトの後段のジョブは、MiseMaMatcherオブジェクトであるが、MiseUriageTotalSinkオブジェクトにとってMiseMaMatcherオブジェクトは前段のジョブにあたる。図１４においては、簡単のため、依存関係を有するジョブ１からジョブ４を対象として説明する。ここでいうジョブ１からジョブ４の各ジョブはジョブオブジェクトに対応する。ジョブ１の後段のジョブはジョブ２である。ジョブ２の後段のジョブはジョブ３とジョブ４である。各ジョブは、前段にあたるジョブからその処理結果を示すデータを取得したことを条件として自処理を実行する。

前段にあたるジョブは、アイテムオブジェクトにデータを記録して、そのアイテムオブジェクトを後段のジョブに渡す。ジョブ間では、データはアイテムオブジェクトによってパッケージされたかたちで送受される。アイテムクラスは、バイナリ形式にてデータを格納するためのバイナリデータ配列を持つ。このバイナリデータ配列に受け渡し対象となるデータが格納される。詳細なデータ構造については図１７に関連して詳述する。ジョブ１とジョブ２、ジョブ２とジョブ３、ジョブ２とジョブ４のように前後段の関係にあるジョブ間には、それぞれアイテムオブジェクトが所定個数ずつ設定される。図１４においては、各ジョブ間について、それぞれ５個ずつ、計１５個のアイテムオブジェクトが生成されている。丸印がアイテムオブジェクトを示し、斜線が施されているアイテムオブジェクトは、データが記録済であることを示す。

ジョブ１とジョブ２の関係においては、前段にあたるジョブ１にはアイテムオブジェクトを一時的に保持するためのプールオブジェクト２１０が生成される。プールクラスは、アイテムオブジェクトを所定数を上限として保持するためのクラスである。ジョブ２とジョブ３、ジョブ２とジョブ４のそれぞれの関係についてもプールオブジェクト２１２、プールオブジェクト２１４が生成される。プールオブジェクト２１０には、ジョブ１とジョブ２の関係について設定された所定個数のアイテムオブジェクトが格納される。プールオブジェクト２１２やプールオブジェクト２１４についても同様である。なお、ジョブ２は、プールオブジェクト２１２とプールオブジェクト２１４のように後段のジョブの数に対応した数だけプールオブジェクトを生成せず、共用のプールオブジェクトを一つだけ生成するとしてもよい。この場合、ジョブ２は共用のプールオブジェクトから取得したアイテムオブジェクトに処理結果を記録して、ジョブ３やジョブ４に転送する。ジョブ３やジョブ４は、ジョブ２から受け取ったアイテムオブジェクトからデータを読み出した後は、この共用プールオブジェクトにアイテムオブジェクトを戻す。このように、後段に複数のジョブがある場合にも、１つのプールオブジェクトでアイテムオブジェクトを管理してもよい。

ジョブ１は、自処理を実行するとプールオブジェクト２１０からアイテムオブジェクトを取り出し、その処理結果を記録する。具体的には、取り出したアイテムオブジェクトのバイナリデータ配列に処理結果を示すデータを記録するが、このような記録方法のことを単に「アイテムオブジェクトに記録する」とよぶことにする。ジョブ１は、処理結果を記録したアイテムオブジェクトを、後段にあたるジョブ２との関係で設定されているキューオブジェクト２２０に投入する。ジョブ２は、キューオブジェクト２２０からアイテムオブジェクトを取り出し、ジョブ１の処理結果を示すデータを取得する。こうして、ジョブ２は、ジョブ１の処理結果を示すデータに基づいて自処理を実行する。ジョブ２は、データを取得すると、ジョブ１から受け取ったアイテムオブジェクトをプールオブジェクト２１０に戻す。したがって、ジョブ１とジョブ２の間では、最初に生成された５個のアイテムオブジェクトを再利用しつつ、キューオブジェクト２２０を介してデータが転送されることになる。同様に、ジョブ２とジョブ３との関係においてはキューオブジェクト２２２、ジョブ２とジョブ４との関係においてはキューオブジェクト２２４が設定される。

ジョブ１はプールオブジェクト２１０にアイテムオブジェクトが無いときやキューオブジェクト２２０がアイテムオブジェクトで一杯のときにはブロックされる。同様に、ジョブ２はキューオブジェクト２２０が空のときにはブロックされる。ジョブ２とジョブ３、ジョブ２とジョブ４との関係についても同様である。
以上に示した処理方法を採用する理由について説明する。

（１）ジョブ間ごとにアイテムオブジェクトをあらかじめ用意する。
仮に、ジョブ１の処理結果が記録されたアイテムオブジェクトをジョブ２が取得し、ジョブ２がこのアイテムオブジェクトにジョブ２の処理結果を上書きして更にジョブ３に渡すとする。このように、１つのアイテムオブジェクトがジョブ１からジョブ２、ジョブ３へと順次転送されていくモデルの場合、各ジョブがブロックされやすくなる。なぜならば、ジョブ１は、ジョブ３がアイテムオブジェクトをジョブ１に返還するか、新たにアイテムオブジェクトを生成しなければ、次の処理結果をジョブ２に渡せなくなるからである。アイテムオブジェクトの生成するというアプローチは、次の、（２）に示す理由により望ましくない。
これに対して、ジョブ１とジョブ２、ジョブ２とジョブ３、ジョブ２とジョブ４の関係ごとにあらかじめアイテムオブジェクトを用意しておけば、ジョブ１は、ジョブ３やジョブ４の処理状態に直接的な影響を受けることなく自処理を実行できる。ジョブ間ごとにアイテムオブジェクトを用意することにより、ジョブ間におけるデータ受け渡し処理をシンプルにすると共に、ブロッキングの発生を抑制できる。

（２）アイテムオブジェクトを再利用する。
ジョブ１はジョブ２へのデータ転送時にアイテムオブジェクトを生成し、ジョブ２はジョブ１からデータを取得するとそのアイテムオブジェクトを破棄（destroy）して、メモリ領域を解放するとしてもよい。しかし、多くのバッチ処理を実行するエンタープライズシステムにおいてこのような方法を採用した場合、アイテムオブジェクトの生成・破棄にともなうオーバーヘッドがシステム全体のパフォーマンスを悪化させかねない。
そこで、ジョブ間ごとにあらかじめアイテムオブジェクトを生成し、これをジョブ間で再利用することによりアイテムオブジェクトの生成・破棄にともなう処理コストを低減している。アイテムオブジェクトの生成コストはエンタープライズシステム２０４の実行開始時、アイテムオブジェクトの破棄コストは実行終了時に局在化されるため、スループットを向上させることができる。

（３）ジョブ間で再利用対象となるアイテムオブジェクトの数を複数個とする。
前後段のジョブ間でデータ送受のために利用されるアイテムオブジェクトは、複数個、たとえば、５個生成される。アイテムオブジェクトの数は、ジョブの性質やテスト実行の結果に応じて好適な数を求めればよい。仮に、ジョブ１とジョブ２の間でデータを送受するためのアイテムオブジェクトが１つだけの場合、ジョブ２がアイテムオブジェクトからデータを読み出しているときには、ジョブ１はそのアイテムオブジェクトが返還されるまで新たな処理結果をアイテムオブジェクトに記録できない。このため、ジョブ１の処理状態は後段のジョブ２の処理状態の影響を受けやすくなる。
これに対して、複数個のアイテムオブジェクトを再利用対象とすれば、ジョブ１の処理とジョブ２の処理を非同期実行しやすくなる。特にマルチスレッドモデルにおいて、ジョブ間ごとに複数個のアイテムオブジェクトを再利用することにより、システム全体としてのスループットを向上させることができる。

（４）キューオブジェクトを介してアイテムオブジェクトを転送する。
ジョブ１からキューを介さずにアイテムオブジェクトを直接ジョブ２に渡すとすれば、ジョブ１はジョブ２がアイテムオブジェクトを受け取り可能な状態となるまでブロックされることになる。これに対して、キューオブジェクトは、前段のジョブと後段のジョブを非同期的に動作させるため、システム全体としてのスループットを向上させることができる。

なお、本発明者が簡単なＤＦＤを定義してシングルスレッドモデルにてテスト実行してみたところ、上記（２）、（３）の方式を採用する場合には合計処理時間は１３．３秒であった。これに対し上記（２）、（３）の機能を無効化した場合、同じＤＦＤについてのシステムの合計処理時間は８０．５秒であった。特に、アイテムオブジェクトの生成や破棄にともなう処理コストをシステム実行開始時と実行終了時に限定できることが、全体としてのスループット向上に大きく寄与している。

図１５は、アイテムオブジェクトに処理結果を記録してキューに投入する過程に対応したソースコードを示す図である。
同図に示すソースコードは、MiseMaMatcherクラス４０８が、自処理が完了したときに呼び出すdoProcessMatching関数を示す。doProcessMatching関数が実行されると、プールオブジェクトからアイテムオブジェクトrecordが取得される（Ｓ３６４）。プールオブジェクトにアイテムオブジェクトがなければブロックされる。取得されたアイテムオブジェクトrecordには、処理結果が書き込まれ（Ｓ３６６）、キューオブジェクトに投入される（Ｓ３６８）。キューが一杯のときには、Ｓ３６８の処理はブロックされる。

図１６は、キューからアイテムオブジェクトを取得して前段のジョブの処理結果を取得する過程に対応したソースコードを示す図である。
MiseMaMatcherオブジェクトの後段のジョブオブジェクトは、図４によるとMiseUriageTotalSinkオブジェクトである。同図に示すソースコードは、MiseUriageTotalSinkの処理オブジェクトとなるMTRecordStreamSinkクラス５１６が、自処理の開始に際して呼び出すdoTask関数を示す。まず、前段のジョブオブジェクトとの関係で設定されているキューオブジェクトからアイテムオブジェクトrecordを取得する（Ｓ３７０）。キューが空であれば、Ｓ３７０の処理はブロックされる。

そのあと、MiseUriageTotalSinkクラス４１０のメンバ関数であるdoWrite関数を実行し、doWrite関数によって、MiseUriageTotalSinkクラス４１０で実装された具体的な出力処理が実行される（Ｓ３７２）。次に、RecordUtil.releaseIfNeeded関数が実行され、前段のジョブのプールオブジェクトにＳ３７０で取得したアイテムオブジェクトを返還している（Ｓ３７４）。

図１７は、アイテムオブジェクトの構造を説明するための模式図である。
アイテムオブジェクトは、前後段のジョブ間のみならず、MiseMaSourceクラス４０６やUriageSourceクラス４００がノード端末２００やデータベース２０６からデータを取得するときにも利用される。ここでは、データＡ、データＢ、データＣおよびデータＤの４種類のデータの構造体として示されるデータＸを対象として説明する。データＸは、データＡ、データＢ、データＹを含み、データＹはデータＣとデータＤを含む。データＡ〜データＤのように基本単位となるデータのことを「要素データ」、データＸやデータＹのように、要素データを複数含んで構成される構造体型のデータのことを「集合データ」とよぶことにする。

オブジェクト指向言語で記述されたコンピュータプログラムの場合、ファイルやデータベースからデータを読み出すときには、通常、読み出したデータに応じて型変換処理が実行される。たとえば、バイナリ形式で読み出したデータＡのデータ型が整数型として定義されていれば、データＡを整数として保持するためのメモリ領域を確保した上で、データＡをメモリに記録する。また、データＸのような集合データであれば、データＸのデータ構造に対応してメモリを確保し、各要素データが記録される。データＸの場合であれば、データＡ、Ｂ、Ｃ、Ｄ、Ｙ、Ｘの５つのデータ型に対応して、数値データや文字列データ、あるいは、構造体データとしてメモリに記録されることになる。データ型に対応して一種のデータオブジェクトを生成することにより、プログラマがデータを扱いやすくなっている。しかし、本発明者は、多くのバッチ処理を実行するエンタープライズシステムにおいては、型変換処理による処理コストがシステム全体としてのパフォーマンスを大きく低下させかねないと想到した。

そこで、本実施例においては、データベース２０６として形成されるファイルシステムから読み出したデータや、ジョブの処理結果を示すデータは、アイテムオブジェクトのバイナリデータ配列にバイナリ形式のまま格納するものとしている。すなわち、ファイルシステムからデータを取得するときには、データの型変換処理を実行しない。ここでは、図１４のジョブ１が、所定のデータベースからデータＸを読み出す場合を例として説明する。

ジョブ１とデータベースとの関係において、１個のアイテムオブジェクトＲＩＸが生成されているとする。ジョブ１は、データベースからデータＸを取得すると、そのままアイテムオブジェクトＲＩＸのバイナリデータ配列にデータＸを記録する。データＸは、計６４バイトのデータであり、２４バイトのデータＡ、１６バイトのデータＢ、８バイトのデータＣ、１６バイトのデータＤの４種類の要素データを含む。ジョブ１がデータベースから取得するデータＸのデータ構造は、ジョブ１にとって既知であるとする。そのため、アイテムクラスＲＩＸにおいては、バイナリデータ配列のサイズが、あらかじめ６４バイトに設定されている。

アイテムクラスＲＩＸは、更に、オフセット値とサイズ値、バイナリデータ配列へのポインタ（pointer）を保持する。オフセット値は、管理対象となるデータＸのバイナリデータ配列における開始位置、サイズ値はデータＸのサイズを示す。データＸは、バイナリデータ配列の１バイト目から６４バイト目までのデータなので、オフセット値は０、サイズ値は６４（バイト）となる。データＸは、データＡ、データＢ、データＹを含むため、アイテムクラスＲＩＸがインスタンス化されるときには、データＡ、データＢ、データＹを管理するためのアイテムクラスＲＩＡ、ＲＩＢ、ＲＩＹも付随してインスタンス化される。アイテムオブジェクトＲＩＸは、下位のアイテムオブジェクトＲＩＡ、ＲＩＢ、ＲＩＹにアクセスするためのポインタもメンバ変数として保持する。

アイテムクラスＲＩＡはデータＡを管理する。データＡの実体は上位のアイテムクラスＲＩＸのバイナリデータ配列に格納されている。アイテムクラスＲＩＡは、データＡについてのオフセット値、サイズ値およびデータＡを格納するバイナリデータ配列へのポインタを保持する。アイテムオブジェクトＲＩＡのオフセット値は０、サイズ値は２４となる。バイナリデータ配列の１バイト目から２３バイト目までが、データＡだからである。処理オブジェクトは、たとえば、
int dataA = RIX.RIA.getNum();
のような形式にて、アイテムオブジェクトＲＩＸを介して、アイテムオブジェクトＲＩＡのgetNum関数により、データＡを整数値として取り出すことができる。処理オブジェクトがデータＡを必要としたときに、バイナリデータ配列中のデータＡが抽出され、getNum関数による型変換処理が実行されることになる。いいかえれば、データＡを取り出す必要が生じない限り、データＡはバイナリデータの一部として扱われる。たとえば、データＸの複製やデータＸと別のデータとの比較の場合には、データＡの型変換は実行する必要がない。

少なくとも、データベースからデータＸを取り出す段階では、データＸに関して型変換処理を実行する必要がない。このような処理方式により型変換にともなう処理負荷を抑制している。実際、本発明者が簡単なＤＦＤについてのシステムをテスト実行してみたところ、データベースからのデータ読み出し時に型変換処理を実行しない上記方式を採用すれば１３．３秒の処理時間ですむところ、常に型変換処理を実行する方式に変更すると、３７．１秒の処理時間がかかった。オブジェクト指向言語においては、「データをユーザが取り扱いやすいかたちに構造化する」のが基本的な思想となる。これに対して、本発明者は、型変換処理によるデータの構造化するための処理負荷が、オブジェクトの生成・破棄と同様に、エンタープライズシステムではスループットの低下要因となりやすいと考えた。そこで、上記したように、実際に必要になるまで型変換処理を実行せず、必要でない限りバイナリデータのままでデータを取り扱うというアプローチによって、システム全体のスループットを向上させることに成功した。

以下同様に、アイテムクラスＲＩＢはデータＢを管理する。オフセット値は２４、サイズ値は１６となる。アイテムクラスＲＩＹは、データＣおよびデータＤの構造体であるデータＹを管理するクラスである。オフセット値は４０、サイズ値は２４となる。データＹは、要素データであるデータＣとデータＤを含む構造体なので、アイテムクラスＲＩＹがインスタンス化されるときには、データＣ、データＤを管理するためのアイテムクラスＲＩＣ、ＲＩＤも付随してインスタンス化される。アイテムオブジェクトＲＩＹは、下位のアイテムオブジェクトＲＩＣ、ＲＩＤにアクセスするためのポインタをメンバ変数として保持する。
たとえば、処理オブジェクトは、
string dataD = RIX.RIY.RID.getString();
のような形式にて、アイテムオブジェクトＲＩＸを介してアイテムオブジェクトＲＩＤのgetString関数により、データＤを文字列型として取り出すことができる。

ジョブ１とジョブ２のように、ジョブ間におけるデータの送受についても同様である。ジョブ１は、ジョブ１とジョブ２との関係で生成されるアイテムオブジェクトのバイナリデータ配列に処理結果を示すデータを記録して、キューオブジェクト２２０に投入する。このとき、ジョブ２は、アイテムオブジェクトからバイナリデータを読み出して、バイナリデータに含まれる要素データのうち、型変換が必要なデータだけについて型変換処理を実行すればよい。このような処理方法によれば、スループットを向上させつつ、データ取り扱い時の利便性を担保することができる。型変換処理にともなう処理コストは、通常、微々たるものであるが、大量のデータをバッチ処理するエンタープライズシステム２０４の場合には、無視しがたいものとなる。必要なときだけ型変換を実行するジョブ管理装置１００は、このような処理コストを最小限度に抑制することができる。

以上の実施例に示したジョブ管理装置１００によれば、モデルオブジェクトとコントロールオブジェクトによって、ジョブの静的な関係定義と、ジョブの動的な処理定義を明確に分離できる。
ＣＯＢＯＬなどの手続き型言語の場合、これら２種類の定義は一体としてなされることが多かった。そのため、開発者は、ジョブの静的な関係定義と動的な処理定義を同時に意識しながらシステムを設計する必要があった。これに対して、本実施例にて示したフレームワークによれば、これら２種類の定義を明確に分離できる。そのため、ジョブの処理定義に過度に影響されることなく、ジョブの関係定義を行うことができる。また、その逆も真である。このような分離設計を可能とするフレームワークは、エンタープライズシステム２０４の拡張性・保守性・堅牢性を高める上で効果がある。

たとえば、一部のジョブオブジェクトにだけ処理を注入することにより、エンタープライズシステム２０４の一部の機能だけのテストを、コントロールオブジェクト側の変更操作だけで実現できる。
具体例として、１００個のジョブオブジェクトによって構成されるエンタープライズシステム２０４のうち、３個のジョブオブジェクトの機能だけをテストしたい場合について説明する。このような場合、まず、１００個のジョブオブジェクトを生成しておく。そして、実際には、この３個のジョブオブジェクトにだけ処理を注入する。次に、さきほどの３個のジョブオブジェクトを含む５個のジョブオブジェクトの機能をテストしたい場合には、生成済の１００個のジョブオブジェクトのうち、今度は５個のジョブオブジェクトに処理を注入する。すなわち、はじめに１００個のジョブオブジェクトを生成しておけば、２回目のテストのために新たにテスト対象として加わった２個のジョブオブジェクトを生成する必要がない。このような処理方法によると、最初に全てのジョブオブジェクトを生成しておけば、テスト対象の変更により新たなインスタンス化処理を実行しなくて済むというメリットがある。

本実施例に示すエンタープライズシステム２０４の場合、ジョブオブジェクトはすべてモデルクラスによって生成され、他のジョブクラスから生成されることはない。このため、ジョブオブジェクトの生成に関しても、ジョブクラスに先天的な依存関係を持たさなくて済む。これにより、各ジョブクラスの独立性を高めることができる。また、プログラマは、UriageProcessingModelクラス４４０を参照することにより、処理対象となるジョブクラスを一元的に参照できるため、ソースコードの可読性を高める効果もある。

また、図６に関連して説明したように、ジョブクラスは典型的な４つのジョブベースクラスのいずれかを継承するかたちで定義されているため、何十、何百、何千というジョブオブジェクトを制御する場合であっても、ジョブクラスの設計負担が大幅に軽減される。これは、処理クラスやモデルクラスなど他のクラスについても同様である。

本実施例においては、マルチスレッドモデルとして、複数のジョブを別々のワーカスレッドで実行している。そのため、コントロールクラスや処理クラスを設計するプログラマはジョブの依存関係をほとんど意識する必要がない。各ジョブは前段のジョブや後段のジョブの処理状態に応じて自動的に実行状態と待機状態のいずれかに遷移するため、複数のジョブが関係クラスにおいて定義された依存関係にしたがって実行されることになる。マルチスレッドモデルは、ＤＦＤにおいてフローが枝分かれするほど、全体としてのスループットを向上させる上で有効となる。

ジョブ管理装置１００では、シングルスレッドモデルとマルチスレッドモデルを実行時に簡単に切り換えることができる。ＤＦＤにおける依存関係によっては、シングルスレッドモデルの方が、マルチスレッドモデルよりもシステム全体のスループットが高くなることもある。モデルクラスとコントロールクラスが明確に分離されているために、このようなマルチスレッドとシングルスレッドの切り換えを簡単に設定できる。このため、ＤＦＤの定義がなされた後や変更後でも、好適な実行モデルを適宜選択できることになる。

ジョブ管理装置１００では、ジョブオブジェクトはアイテムオブジェクトを介してデータを取り扱っている。アイテムクラスという所定クラスによってデータを取り扱うためのインタフェースがフォーマット化されている。データを扱うジョブクラスと、具体的な処理内容が定義される処理クラスと共に、ジョブクラスが取り扱うデータを格納するためのアイテムクラスを定義することによって、プログラム全体としての可読性を高める効果がある。たとえば、UriageProcessingModelクラス４４０に新しいジョブクラスが追加されたときにも、そのジョブクラスから出力されるデータや入力されるデータも、アイテムクラスのインタフェースを使って扱える。このように、アイテムクラスによりデータを取り扱うためのインタフェースを統一することにより、エンタープライズシステム２０４の機能拡張や変更が容易となる。

ＣＯＢＯＬのような手続き型言語に比べて、ＪＡＶＡ（登録商標）のようなオブジェクト指向言語は、コードの再利用性・保守性・堅牢性などの諸点において優れている。その反面、手続き型言語よりもオーバーヘッドが発生しやすいという難点がある。本実施例においては、オブジェクト指向言語の優位性を確保しつつ、このようなオーバーヘッドを抑制するために、主として、以下のような方式を採用している。
１．複数のアイテムオブジェクトを初期生成しておき、これらを循環的に再利用することにより、アイテムオブジェクトの生成・破棄にともなう処理コストを抑制する。
２．アイテムオブジェクトの受け渡しのためのキューを用意することにより、各ジョブの非同期性を高める。
３．アイテムオブジェクトはバイナリ形式にてデータを取り扱い、抽出が必要なときだけ型変換処理を実行することにより、型変換にともなう処理コストを低減する。
本実施例に示したジョブ管理装置１００によれば、オブジェクト指向の枠組みを維持することによりオブジェクト指向言語の優位性を活かしつつも、データの送受や変換に関するオーバーヘッドの発生を抑制することにより、手続き型言語並のスループットと、オブジェクト指向言語の利点を両立させている。

なお、ジョブ管理装置１００の機能は、複数のハードウェア資源によって実現されてもよい。たとえば、ジョブオブジェクトは、複数のジョブ実行装置に分散配置されてもよい。このような態様によれば、ジョブ実行装置Ａでジョブオブジェクトαの処理を実行しつつ、ジョブ実行装置Ｂでジョブオブジェクトβの処理を実行するという処理方法が可能となる。これにより、時間的な効率化だけでなく、処理負荷の分散も効率的に行うことができる。コントロールクラスは、ジョブ実行装置群において処理負荷が局所化しないように、他のジョブ実行装置よりも処理負荷が軽い状態にあるジョブ実行装置に対して優先的にジョブを割り当ててもよい。従来、ジョブの分散配置を実現するためには、複数のジョブ実行装置への分散配置を前提とした設計が必要であったが、本実施例に示した設計方法によれば、ジョブ管理装置１００から外部のジョブ実行装置にジョブの実行主体を移行させるのが容易となる。

以上、実施の形態をもとに本発明を説明した。なお本発明はこの実施の形態に限定されることなく、そのさまざまな変形例もまた、本発明の態様として有効である。たとえば、本実施例においては、エンタープライズシステムを想定して説明したが、より具体的には、電子商取引、物流管理などへの応用が考えられる。また、本実施例において示したフレームワークは、ワークフロー管理のように、複数のジョブを定義して制御するというモデルに広く応用可能である。

請求項に記載のジョブオブジェクト生成部の機能は、本実施例においては主としてUriageProcessingModelクラス４４０によって実現される。請求項に記載のジョブリスト情報生成部の機能は、本実施例においては主としてUriageProcessingModelクラス４４０やConnectionクラス４３０によって実現される。請求項に記載の処理注入部と実行制御部の機能は、本実施例においては、主としてMultiThreadFlowControllerクラス４５２によって実現される。したがって、請求項に記載のモデルオブジェクト生成機能は、本実施例においては主としてモデル管理部１４０、とりわけ、UriageProcessingModelクラス４４０によって実現される。請求項に記載のコントロールオブジェクト生成機能は、本実施例においてはフロー制御部１５０、とりわけ、MultiThreadFlowControllerクラス４５２によって実現される。請求項に記載の処理関数は、本実施例においては、たとえば、図１３にて示したdoTask関数が相当する。請求項に記載のアイテムオブジェクト生成部の機能は、各ジョブオブジェクトのコンストラクタや初期化用関数によって実現される。請求項に記載のアイテムオブジェクト保持部の機能は、プールクラスによって実現される。請求項に記載のキュー生成部の機能は、コントロールクラスによって実現され、キューの機能はキュークラスによって実現される。
このほかにも、請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。

以上の実施の形態および変形例から把握される発明のいろいろな態様をすでに特許請求の範囲に記載したものも含む形にて以下に例示する。

Ａ１．前段にあたるジョブの出力データに基づいて後段にあたるジョブが実行されるように依存関係が定められた複数のジョブを実行するための装置であって、
ジョブのタイプに応じてあらかじめ定義されたクラスから、ジョブオブジェクトを生成するジョブオブジェクト生成部と、
各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成するジョブリスト情報生成部と、
ジョブの処理内容を示す処理関数を、ジョブオブジェクトが生成された後に設定する処理注入部と、
前記ジョブリスト情報を参照してジョブオブジェクトを選択し、そのジョブオブジェクトについて設定された処理関数を実行させる実行指示部と、
を備えることを特徴とするジョブ管理装置。

Ａ２．前記実行指示部によって選択されたジョブオブジェクトの処理関数は、前記ジョブリスト情報に基づいて次に出力データを渡すべきジョブを特定し、特定したジョブについての処理関数を実行させることを特徴とするＡ１に記載のジョブ管理装置。

Ａ３．ジョブオブジェクトは、他のジョブオブジェクトによって生成されることはなく、前記ジョブオブジェクト生成部によって直接生成されることを特徴とするＡ１またはＡ２に記載のジョブ管理装置。

Ａ４．前記ジョブオブジェクト生成部と前記ジョブリスト情報生成部の各機能をその機能の一部として含むオブジェクトとしてモデルオブジェクトを生成するモデルオブジェクト生成部と、
前記処理注入部と前記実行指示部の各機能をその機能の一部として含むオブジェクトとしてコントロールオブジェクトを生成するコントロールオブジェクト生成部と、を更に備え、
前記コントロールオブジェクトは、前記モデルオブジェクトを処理対象とすることによって、前記処理注入部と前記実行指示部の各機能を発揮させることを特徴とするＡ１からＡ３のいずれかに記載のジョブ管理装置。

Ａ５．ジョブオブジェクトは、処理関数をメンバ関数として含む処理オブジェクトと関連づけられ、
前記処理注入部は、ジョブオブジェクトの生成後に、ジョブオブジェクトに処理オブジェクトを設定することにより、ジョブオブジェクトについての処理関数を設定することを特徴とするＡ１からＡ４のいずれかに記載のジョブ管理装置。

Ａ６．前記処理注入部は、ジョブオブジェクトが基づくクラスのタイプに応じて、設定すべき処理オブジェクトを選択することを特徴とするＡ５に記載のジョブ管理装置。

Ａ７．各処理関数は時間的に並行して実行可能であって、
所定の処理関数は、前記ジョブリスト情報を参照して次に実行すべき複数の処理関数を特定し、前記複数の処理関数を時間的に並行して実行させることを特徴とするＡ１からＡ６のいずれかに記載のジョブ管理装置。

Ａ８．前記ジョブオブジェクト生成部は、ネットワークを介して接続された複数の外部装置に対して複数のジョブオブジェクトを分散配置可能であり、
前記複数の外部装置に分散配置された各ジョブオブジェクトの処理関数は時間的に並行して実行可能であることを特徴とするＡ１からＡ７のいずれかに記載のジョブ管理装置。

Ａ９．組織業務の構成単位としてのジョブに対応するジョブオブジェクトを、ジョブのタイプに応じてあらかじめ定義されたクラスから生成するステップと、
各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成するステップと、
ジョブの処理内容を示す処理関数を、ジョブオブジェクト生成後に設定するステップと、
前記ジョブリスト情報を参照してジョブオブジェクトを選択し、そのジョブオブジェクトについて設定された処理関数を実行させるステップと、
を備えることを特徴とするジョブ管理方法。

Ａ１０．前段にあたるジョブの出力データに基づいて後段にあたるジョブが実行されるように、複数のジョブの依存関係を定義するオブジェクトとしてモデルオブジェクトを生成する機能と、
各ジョブの処理内容を定義するコントロールオブジェクトを生成する機能と、
コントロールオブジェクトの第１のメンバ関数を実行することにより、モデルオブジェクトにおいて定義されるジョブの処理内容を設定する機能と、
コントロールオブジェクトの第２のメンバ関数を実行することにより、第１のジョブについての処理を実行させる機能と、
前記依存関係にしたがって、前記第１のジョブの出力データを渡すべき第２のジョブを特定する機能と、
前記第２のジョブについての処理を実行させる機能と、
をコンピュータに発揮させることにより、複数のジョブを依存関係にしたがって実行させることを特徴とするジョブ管理プログラム。

エンタープライズシステムのハードウェア構成図である。ジョブ管理装置の機能ブロック図である。本実施例におけるデータフローダイアグラムを示す図である。図３のＤＦＤに対応するジョブクラスの依存関係を示す図である。ジョブ管理装置の基本的な機能を実現するためのクラスの関係を示す模式図である。ジョブクラスとモデルクラスの関係を示すクラス図である。処理クラスの継承に関するクラス図である。エンタープライズシステムの実行開始にあたって、最初に実行される関数を示す図である。モデルオブジェクト生成時に実行されるソースコードを示す図である。コントロールオブジェクト生成時とデータフローの実行開始に際して実行されるソースコードを示す図である。図１０のＳ３２０およびＳ３３０までの処理に対応するソースコードを示す図である。図１０のＳ３４０の処理に対応するソースコードを示す図である。図１２のＳ３４４の処理に対応するソースコードを示す図である。ジョブオブジェクト間におけるデータ送受方法を説明するための模式図である。アイテムオブジェクトに処理結果を記録してキューに投入する過程に対応したソースコードを示す図である。キューからアイテムオブジェクトを取得して前段のジョブの処理結果を取得する過程に対応したソースコードを示す図である。アイテムオブジェクトの構造を説明するための模式図である。

符号の説明

１００ジョブ管理装置、１１０ユーザインタフェース処理部、１２０通信部、１３０データ処理部、１４０モデル管理部、１５０フロー制御部、２００ノード端末、２０４エンタープライズシステム、２０６データベース、３００売上データ、３０２売上集約処理、３０４地区別売上データ、３０６店マスタデータ、３０８店名追加処理、３１０店別売上データ、３１２データフローダイアグラム、４００ UriageSourceクラス、４０２ UriageAggregatorクラス、４０４ AreaUriageTotalSinkクラス、４０６ MiseMaSourceクラス、４０８ MiseMaMatcherクラス、４１０ MiseUriageTotalSinkクラス、４２０ジョブクラス群、４３０ Connectionクラス、４４０ UriageProcessingModelクラス、４５０ SingleThreadFlowControllerクラス、４５２ MultiThreadFlowControllerクラス、４６０ ProcessingModelクラス、４８０ RecordStreamSourceクラス、４８２ RecordStreamAggregatorクラス、４８４ RecordStreamMatcherクラス、４８６ RecordStreamSinkクラス、４９０ Nodeクラス、５００ NodeFlowControllerクラス、５０２ MTNodeFlowControllerクラス、５１０ MTRecordStreamSourceクラス、５１２ MTRecordStreamMatcherクラス、５１４ MTRecordStreamAggregatorクラス、５１６ MTRecordStreamSinkクラス。

Claims

前段にあたるジョブの出力データに基づいて後段にあたるジョブが実行されるように依存関係が定められた複数のジョブを実行するための装置であって、
ジョブのタイプに応じてあらかじめ定義されたクラスから、ジョブオブジェクトを生成するジョブオブジェクト生成部と、
各ジョブオブジェクトのデータの利用関係である依存関係を示すジョブリスト情報を生成するジョブリスト情報生成部と、
ジョブの処理した結果を返す処理関数を、ジョブオブジェクトが生成された後に当該ジョブオブジェクトの変数に注入する処理注入部と、
複数の処理関数に対して別々のスレッドを割り当てることにより、複数の処理関数を時間的に並行して実行させる実行指示部と、を備え、
前段にあたるジョブオブジェクトと後段にあたるジョブオブジェクトの関係において、前記後段にあたるジョブオブジェクトの処理関数であって、当該後段にあたるジョブオブジェクトが生成された後に注入された処理関数は、前記前段にあたるジョブオブジェクトの処理関数であって、当該前段にあたるジョブオブジェクトが生成された後に注入された処理関数が生成する出力データを変数として所定の処理を実行し、出力データが未生成の段階においては出力データが生成されるまで待機することを特徴とするジョブ管理装置。
データを送受するためにあらかじめ定義されたクラスから、アイテムオブジェクトを生成するアイテムオブジェクト生成部と、
前段にあたるジョブオブジェクトと後段にあたるジョブオブジェクトのセットごとに設定され、アイテムオブジェクトを保持するアイテムオブジェクト保持部と、を更に備え、
前記アイテムオブジェクト生成部は、前段にあたるジョブオブジェクトと後段にあたるジョブオブジェクトのセットごとにアイテムオブジェクトを生成して、対応するアイテムオブジェクト保持部に生成したアイテムオブジェクトを格納し、
前段にあたるジョブオブジェクトの処理関数は、後段にあたるジョブオブジェクトとの関係で設定されたアイテムオブジェクト保持部からアイテムオブジェクトを取り出して出力データを記録した上で、後段にあたるジョブオブジェクトにアイテムオブジェクトを転送し、
前記後段にあたるジョブオブジェクトの処理関数は、転送された前記アイテムオブジェクトから出力データを読み出したあと、前記アイテムオブジェクトを前記アイテムオブジェクト保持部に戻すことを特徴とする請求項１に記載のジョブ管理装置。
前記アイテムオブジェクト保持部は、複数個のアイテムオブジェクトを保持可能であって、
前記アイテムオブジェクト生成部は、前段にあたるジョブオブジェクトと後段にあたるジョブオブジェクトのセットに対応して複数個のアイテムオブジェクトを生成して、対応するアイテムオブジェクト保持部に前記複数個のアイテムオブジェクトを格納することを特徴とする請求項２に記載のジョブ管理装置。
前段にあたるジョブオブジェクトの処理関数から後段にあたるジョブオブジェクトの処理関数に転送されるアイテムオブジェクトを所定の上限個数まで保持するキューを、前段にあたるジョブオブジェクトと後段にあたるジョブオブジェクトのセットごとに生成するキュー生成部、を更に備え、
前段にあたるジョブオブジェクトの処理関数は後段にあたるジョブオブジェクトの処理関数に対して前記キューを介して、アイテムオブジェクトを転送し、
前記前段にあたるジョブオブジェクトの処理関数は、前記キューに投入されているアイテムオブジェクトの数が前記所定の上限個数に達しているときには前記キューに空きができるまで待機し、
前記後段にあたるジョブオブジェクトの処理関数は、前記キューにアイテムオブジェクトが存在しないときには、前記前段にあたるジョブオブジェクトの処理関数がアイテムオブジェクトを投入するまで待機することを特徴とする請求項２または３に記載のジョブ管理装置。
前記アイテムオブジェクト生成部は、データ型に関わらずバイナリ形式でデータを保持するためのバイナリデータ配列にデータを格納して管理するクラスからアイテムオブジェクトを生成することを特徴とする請求項２から４のいずれかに記載のジョブ管理装置。
組織業務の構成単位としてのジョブに対応するジョブオブジェクトを、ジョブのタイプに応じてあらかじめ定義されたクラスから生成するステップと、
各ジョブオブジェクトのデータの利用関係である依存関係を示すジョブリスト情報を生成するステップと、
ジョブの処理した結果を返す処理関数を、ジョブオブジェクト生成後に当該ジョブオブジェクトの変数に注入するステップと、
複数の処理関数に対して別々のスレッドを割り当てることにより、複数の処理関数を時間的に並行して実行させるステップと、を備え、
前段にあたるジョブオブジェクトと後段にあたるジョブオブジェクトの関係において、前記後段にあたるジョブオブジェクトの処理関数であって、当該後段にあたるジョブオブジェクトが生成された後に注入された処理関数には、前記前段にあたるジョブオブジェクトの処理関数であって、当該前段にあたるジョブオブジェクトが生成された後に注入された処理関数が生成する出力データを変数として所定の処理を実行させ、出力データが未生成の段階においては出力データが生成されるまで待機させることを特徴とするジョブ管理方法。
前段にあたるジョブの出力データに基づいて後段にあたるジョブが実行されるように、複数のジョブのデータの利用関係である依存関係を定義するオブジェクトとしてモデルオブジェクトを生成する機能と、
各ジョブの処理内容を定義するコントロールオブジェクトを生成する機能と、
コントロールオブジェクトの第１のメンバ関数を実行することにより、ジョブの処理した結果を返す処理関数をジョブごとに当該ジョブオブジェクトの変数に注入する機能と、
コントロールオブジェクトの第２のメンバ関数を実行することにより、複数のジョブの処理関数に別々のスレッドを割り当て、複数の処理関数を時間的に並行して実行させる機能と、
前段にあたるジョブと後段にあたるジョブの関係において、前記後段にあたるジョブの処理関数であって、当該後段にあたるジョブオブジェクトが生成された後に注入された処理関数には、前記前段にあたるジョブの処理関数であって、当該前段にあたるジョブオブジェクトが生成された後に注入された処理関数が生成する出力データを変数として所定の処理を実行させ、出力データが未生成の段階においては出力データが生成されるまで待機させる機能と、
をコンピュータに発揮させることにより、複数のジョブを依存関係にしたがって実行させることを特徴とするジョブ管理プログラム。