JP5007041B2 - ジョブ管理装置およびジョブ管理方法 - Google Patents
ジョブ管理装置およびジョブ管理方法 Download PDFInfo
- Publication number
- JP5007041B2 JP5007041B2 JP2005350643A JP2005350643A JP5007041B2 JP 5007041 B2 JP5007041 B2 JP 5007041B2 JP 2005350643 A JP2005350643 A JP 2005350643A JP 2005350643 A JP2005350643 A JP 2005350643A JP 5007041 B2 JP5007041 B2 JP 5007041B2
- Authority
- JP
- Japan
- Prior art keywords
- job
- class
- processing
- function
- list information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Stored Programmes (AREA)
Description
このような背景から、JAVA(登録商標)によってエンタープライズシステムを開発する必要性が顕在化しつつあると本発明者は認識した。
この装置は、ジョブのタイプに応じてあらかじめ定義されたクラスからジョブオブジェクトを生成し、各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成する。そして、ジョブの処理内容を示す処理関数を、ジョブオブジェクトが生成された後に設定した上で、ジョブリスト情報に基づいて選択したジョブオブジェクトの処理関数を実行させる。
エンタープライズシステム204は、企業や公共施設のような組織の業務管理のために導入されるシステムである。エンタープライズシステム204は、地理的に分散された複数の組織を統合するシステムとして構成されてもよい。
ジョブ管理装置100は、各ジョブの関係を定義したデータフローダイアグラム(DFD:Data Flow Diagram)にしたがって複数のジョブを順次実行する。データフローダイアグラム(以下、「DFD」ともよぶ)については、後に図3等に関連して詳述する。また、ジョブ管理装置100の機能については、次の図2以降に関連して詳述する。
ここに示す各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
ここでは、主として各機能ブロックの発揮すべき機能について述べ、その具体的な作用については、図3以降に関連して説明する。
ユーザインタフェース処理部110は、ユーザからの入力処理やユーザに対する情報表示のようなユーザインタフェース全般に関する処理を担当する。通信部120は、ノード端末200やデータベース206との通信処理を担当する。データ処理部130は、ユーザインタフェース処理部110や通信部120から取得されたデータを元にして各種のデータ処理を実行する。データ処理部130は、ユーザインタフェース処理部110および通信部120の間のインタフェースの役割も果たす。
モデル管理部140は、各ジョブの依存関係を示す「静的なモデル」に関するデータを管理する。フロー制御部150は、各ジョブの処理内容を定義するとともに、各ジョブの実行を制御する。ここで注目すべきは、本実施例におけるジョブ管理装置100においては、ジョブの静的な依存関係を管理するモデル管理部140と、ジョブの動的な処理内容を管理するフロー制御部150が機能上分離されていることである。そのため、ジョブの「依存関係の定義」と「処理内容の定義」について、一方の設計作業が他方の設計内容によって制約されない枠組み(フレームワーク)となっている。
以上をふまえて、より具体的なソフトウェア構造について説明する。
同図に示すデータフローダイアグラム312は、所定の期間における4つCD(Compact Disc)店のCDの売上枚数を集計して、地域別および店別の売上枚数を計算するという処理過程を示している。このデータフローダイアグラム312には、売上データ300、売上集約処理302、地区別売上データ304、店マスタデータ306、店名追加処理308および店別売上データ310の6つの構成要素(Entity)が定義されている。
UriageSourceクラス400は、売上データ300に対応するジョブクラスであり、売上データ300を各CD店のノード端末200から収集して保持するクラスである。UriageAggregatorクラス402は、売上集約処理302に対応するジョブクラスである。以下、同様に、AreaUriageTotalSinkクラス404は地区別売上データ304、MiseMaSourceクラス406は店マスタデータ306、MiseMaMatcherクラス408は店名追加処理308、MiseUriageTotalSinkクラス410は店別売上データ310にそれぞれ対応するジョブクラスである。
そこで、本実施例においては、UriageSourceクラス400からMiseUriageTotalSinkクラス410までの各ジョブクラスに対して、後述するNodeFlowControllerクラス500によって後天的に「処理を注入する(inject)」という手法を採用している。すなわち、ジョブクラスそのものは、先天的には依存関係を持たないかたちで設計されている。
UriageProcessingModelクラス440は、データフローダイアグラム312に示した各ジョブクラスの関係を定義するクラスである。UriageProcessingModelクラス440は、図4に示した6つのジョブクラスを含むジョブクラス群420を持つ。同図に示す菱形記号は、UML(Unified Modeling Language)の表記法に基づき、「集約(aggregation)」を示す記号である。すなわち、UriageProcessingModelクラス440は、その一部としてジョブクラス群420を持つ。したがって、UriageProcessingModelクラス440がインスタンス化されるときには、その一部であるジョブクラス群420も付随してインスタンス化される。UriageProcessingModelオブジェクトは、各ジョブオブジェクトを持つことになる。
前の図5に示したように、UriageProcessingModelクラス440は、UriageSourceクラス400からMiseUriageTotalSinkクラス410までの6つのジョブクラスを持つ。UriageProcessingModelクラス440自体は、SingleThreadFlowControllerクラス450に持たれている。UriageProcessingModelクラス440は、ProcessingModelクラス460を継承するモデルクラスである。すなわちUriageProcessingModelクラス440は、ProcessingModelクラス460において定義された機能を受け継ぎつつ、CDの売上処理を管理するために特有の機能が追加されたクラスとして定義される。ProcessingModelクラス460の作成にあたっては、CDの売上処理を管理するために特有の機能のみを追加すればよいので、スクラッチからUriageProcessingModelクラス440自体を作成するのに比べて、開発や保守にともなう負担が軽減される。以下、ProcessingModelクラス460のように、モデルクラスの継承元となる、基本的なクラスのことを「モデルベースクラス」とよぶことにする。ProcessingModelクラス460は、Connectionクラス430を持つ。したがって、ProcessingModelクラス460を継承するUriageProcessingModelクラス440も、Connectionクラス430を持つことになる。
このように、6つのジョブクラスは、4種類のクラス(以下、「ジョブベースクラス」とよぶ)のいずれかを継承している。更に遡ると、すべてのジョブベースクラスは、Nodeクラス490を継承する。Nodeクラス490は、ジョブのタイプによらない基本的な仕様が定義されたクラスである。
前の図6で見たように、NodeFlowControllerクラス500は、ジョブオブジェクトの処理内容を定義するための処理クラスである。NodeFlowControllerクラス500からSTNodeFlowControllerクラス502が継承され、更に、STRecordStreamSourceクラス510、STRecordStreamMatcherクラス512、STRecordStreamAggregatorクラス514およびSTRecordStreamSinkクラス516の4種類の処理クラスが継承されている。STRecordStreamSourceクラス510は、RecordStreamSourceクラス480に対応して、その処理内容を定義するためのクラスである。STRecordStreamMatcherクラス512、STRecordStreamAggregatorクラス514およびSTRecordStreamSinkクラス516は、それぞれ、RecordStreamMatcherクラス484、RecordStreamAggregatorクラス482およびRecordStreamSinkクラス486に対応してそれらの処理内容を定義するクラスである。NodeFlowControllerクラス500から継承された4種類の処理クラスによって、ジョブクラスの処理内容が定義されることになる。
以上のクラス図をふまえ、サンプルのソースコードを参照しながら、基幹的な処理の内容を処理順序にしたがって説明する。以下に示すソースコードはJAVA(登録商標)にて記述されている。
この関数(メソッド:method)はdoTest関数である。doTest関数は、UriageProcessingModelクラス440のpublicでstaticなメンバ関数であり、UriageProcessingModelクラス440の外からコール可能である。doTest関数が実行されると、UriageProcessingModelクラス440がインスタンス化され、testProcessingModelという名前のモデルオブジェクトが生成される(S100)。インスタンス化にともなって実行される詳細な処理内容については、次の図9に関連して説明する。
S100において、UriageProcessingModelクラス440がインスタンス化されるときには、まず、UriageProcessingModel()として示されるコンストラクタ関数が実行される(S102)。このコンストラクタ関数の実行に際して、各ジョブクラスがインスタンス化される(S104)。ここでは、UriageProcessingModelクラス440のメンバ変数として、UriageSourceクラス400、MiseMaSourceクラス406、UriageAggregatorクラス402、MiseMaMatcherクラス408、MiseUriageTotalSinkクラス410およびAreaUriageTotalSinkクラス404の各ジョブクラスがインスタンス化され、それぞれ、uriageSource、miseMaSource、uriageAggregator、miseMaMatcher、miseUriageTotalSinkrおよびareaUriageTotalSinkという名前のジョブオブジェクトが生成される。なお、各ジョブオブジェクトの生成に際しては、それぞれ、NodeFlowControllerクラス500から処理オブジェクトが生成される。ただし、この段階では処理オブジェクトには特段の処理内容は定義されない。また、UriageProcessingModelクラス440のインスタンス化に際しては、モデルベースクラスが持っている関係クラス、すなわち、Connectionクラス430もインスタンス化される。Connectionクラス430は、リスト形式にて各ジョブオブジェクトのつながりを管理するためのクラスである。
前の図8に示したdoTest関数のS200において、SingleThreadFlowControllerクラス450がインスタンス化される。このとき、まず、SingleThreadFlowController()として示されるコンストラクタ関数が実行される(S202)。このコンストラクタ関数の実行によって、ProcessingModelクラス460からmodelという名前の変数が用意される。このProcessingModelクラス460は、UriageProcessingModelクラス440の継承元となるモデルベースクラスであるから、この段階では、modelという名前の変数には、CDの売上処理に関する具体的なモデルは設定されない。そして、SingleThreadFlowControllerクラス450からsingleThreadFlowControllerという名前のコントロールオブジェクトが生成されることになる。
前の図10に示したdoTask関数のS320の実行にともなって、injectRecordStream関数が実行される。これによって、ジョブオブジェクト間でデータを受け渡すためのオブジェクトとして、STRecordStreamクラスがインスタンス化される。このように、ジョブオブジェクト間においてデータ受け渡しするためのフォーマットも、コントロールオブジェクト側にて定義される。次に、doTask関数のS330の実行にともなって、injectFlowController関数が実行される。injectFlowController関数は、関係オブジェクトを走査して、順次ジョブオブジェクトを選択し、各ジョブオブジェクトについてinjectFlowControllerToNode関数を実行する(S332)。
COBOLなどの手続き型言語の場合、これら2種類の定義は一体としてなされることが多かった。そのため、開発者は、ジョブの静的な関係定義と動的な処理定義を同時に意識しながらシステムを設計する必要があった。これに対して、本実施例にて示したフレームワークによれば、これら2種類の定義を明確に分離できる。そのため、ジョブの処理定義に過度に影響されることなく、ジョブの関係定義を行うことができる。また、その逆も真である。このような、分離設計を可能とするフレームワークは、エンタープライズシステム204の拡張性・保守性・堅牢性を高めることができる。
具体例として、100個のジョブオブジェクトによって構成されるエンタープライズシステム204のうち、3個のジョブオブジェクトの機能だけをテストしたい場合について説明する。このような場合、まず、100個のジョブオブジェクトを生成しておく。そして、実際には、この3個のジョブオブジェクトにだけ処理を注入する。次に、さきほどの3個のジョブオブジェクトを含む5個のジョブオブジェクトの機能をテストしたい場合には、生成済の100個のジョブオブジェクトのうち、今度は5個のジョブオブジェクトに処理を注入する。すなわち、はじめに100個のジョブオブジェクトを生成しておけば、2回目のテストのために新たにテスト対象として加わった2個のジョブオブジェクトを生成する必要がない。このような処理方法によると、最初に全てのジョブオブジェクトを生成しておけば、テスト対象の変更により新たなインスタンス化処理を実行しなくて済むというメリットがある。
まず、SingleThreadFlowControllerクラス450は、各ジョブオブジェクトの処理オブジェクトの処理関数であるdoTask関数に実行を指示する。ここで、各doTask関数はマルチスレッド化されており、時間的に並行して実行可能な関数である。この指示によって、各doTask関数は実行待機状態に移行するが、UriageSourceオブジェクトについての処理関数だけは即座に実行開始となる。
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
Claims (8)
- 前段にあたるジョブの出力データに基づいて後段にあたるジョブが実行されるように依存関係が定められた複数のジョブを実行するための装置であって、
ジョブのタイプに応じてあらかじめ定義されたクラスから、ジョブオブジェクトを生成するジョブオブジェクト生成部と、
各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成し、メモリに記憶するジョブリスト情報生成部と、
ジョブの処理内容を示す処理関数が定義された処理クラスをインスタンス化した処理オブジェクトを、ジョブオブジェクトが生成された後に当該ジョブオブジェクトに設定する処理注入部と、
メモリに記憶された前記ジョブリスト情報を検索してジョブオブジェクトを選択し、そのジョブオブジェクトに、設定された処理関数を実行させる実行指示部と、
を備えることを特徴とするジョブ管理装置。 - 前記実行指示部は、選択したジョブオブジェクトの処理関数により、メモリに記憶された前記ジョブリスト情報を検索して次に出力データを渡すべきジョブを特定し、特定したジョブに、設定された処理関数を実行させることを特徴とする請求項1に記載のジョブ管理装置。
- ジョブオブジェクトは、他のジョブオブジェクトによって生成されることはなく、前記ジョブオブジェクト生成部によって直接生成されることを特徴とする請求項1または2に記載のジョブ管理装置。
- 前記ジョブオブジェクト生成部と前記ジョブリスト情報生成部の各機能をその機能の一部として含むオブジェクトとしてモデルオブジェクトを生成するモデルオブジェクト生成部と、
前記処理注入部と前記実行指示部の各機能をその機能の一部として含むオブジェクトとしてコントロールオブジェクトを生成するコントロールオブジェクト生成部と、を更に備え、
前記コントロールオブジェクトは、前記モデルオブジェクトを処理対象とすることによって、前記処理注入部と前記実行指示部の各機能を発揮することを特徴とする請求項1から3のいずれかに記載のジョブ管理装置。 - 各処理関数は時間的に並行して実行可能であって、
前記実行指示部は、選択した所定のジョブオブジェクトの処理関数により、メモリに記憶された前記ジョブリスト情報を検索して次に実行すべき複数のジョブを特定し、特定した前記複数のジョブに、それぞれに設定された処理関数を時間的に並行して実行させることを特徴とする請求項1から4のいずれかに記載のジョブ管理装置。 - 前記ジョブオブジェクト生成部は、ネットワークを介して接続された複数の外部装置に対して複数のジョブオブジェクトを分散配置可能であり、
前記複数の外部装置に分散配置された各ジョブオブジェクトの処理関数は時間的に並行して実行可能であることを特徴とする請求項1から5のいずれかに記載のジョブ管理装置。 - ジョブオブジェクト生成部が、組織業務の構成単位としてのジョブに対応するジョブオブジェクトを、ジョブのタイプに応じてあらかじめ定義されたクラスから生成するステップと、
ジョブリスト情報生成部が、各ジョブオブジェクトの依存関係を示すジョブリスト情報を生成し、メモリに記憶するステップと、
処理注入部が、ジョブの処理内容を示す処理関数が定義された処理クラスをインスタンス化した処理オブジェクトを、ジョブオブジェクト生成後に当該ジョブオブジェクトに設定するステップと、
実行指示部が、メモリに記憶された前記ジョブリスト情報を検索してジョブオブジェクトを選択し、そのジョブオブジェクトに、設定された処理関数を実行させるステップと、
を備えることを特徴とするジョブ管理方法。 - 前段にあたるジョブの出力データに基づいて後段にあたるジョブが実行されるように、複数のジョブの依存関係を定義するオブジェクトとしてモデルオブジェクトを生成し、メモリに記憶する機能と、
各ジョブの処理内容を定義するコントロールオブジェクトを生成する機能と、
コントロールオブジェクトの第1のメンバ関数を実行することにより、モデルオブジェクトにおいて定義されるジョブの処理内容を設定する機能と、
コントロールオブジェクトの第2のメンバ関数を実行することにより、第1のジョブに処理を実行させる機能と、
メモリに記憶された前記依存関係を検索し、前記第1のジョブの出力データを渡すべき第2のジョブを特定する機能と、
前記第2のジョブに処理を実行させる機能と、
をコンピュータに実現させるためのジョブ管理プログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005350643A JP5007041B2 (ja) | 2005-12-05 | 2005-12-05 | ジョブ管理装置およびジョブ管理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005350643A JP5007041B2 (ja) | 2005-12-05 | 2005-12-05 | ジョブ管理装置およびジョブ管理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2007156791A JP2007156791A (ja) | 2007-06-21 |
JP5007041B2 true JP5007041B2 (ja) | 2012-08-22 |
Family
ID=38241083
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005350643A Expired - Fee Related JP5007041B2 (ja) | 2005-12-05 | 2005-12-05 | ジョブ管理装置およびジョブ管理方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5007041B2 (ja) |
-
2005
- 2005-12-05 JP JP2005350643A patent/JP5007041B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2007156791A (ja) | 2007-06-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Rosenberg et al. | An end-to-end approach for QoS-aware service composition | |
US20180173606A1 (en) | Hybrid testing automation engine | |
JP5140067B2 (ja) | ワークフローにおいて継続をモデル化するフレームワーク | |
JP5354601B2 (ja) | プロデューサグラフ指向のプログラミングフレームワークにおけるパラレル化及びインスツルメンテーション | |
US7904416B2 (en) | Provisioning of software components via workflow management systems | |
US9021419B2 (en) | System and method for supporting intelligent design pattern automation | |
US9037595B2 (en) | Creating graphical models representing control flow of a program manipulating data resources | |
US8589864B2 (en) | Automating the creation of an application provisioning model | |
US20030200533A1 (en) | Method and apparatus for creating software objects | |
US7640538B2 (en) | Virtual threads in business process programs | |
US20090144703A1 (en) | Method and system for versioning a software system | |
JP2004520635A (ja) | 石油会社のモデル資産のアプリケーション・フレームワークを有するオブジェクト指向ソフトウェア・アプリケーション | |
JP2009532754A (ja) | 継続ベースのメタランタイムのための抽象実行モデル | |
JP5396979B2 (ja) | ソフトウェア開発支援装置、システム、ソフトウェア開発支援装置の機能拡張方法、及びプログラム | |
Gedik et al. | A model‐based framework for building extensible, high performance stream processing middleware and programming language for IBM InfoSphere Streams | |
CN106600226B (zh) | 用于优化流程管理系统的方法及装置 | |
US20120060141A1 (en) | Integrated environment for software design and implementation | |
JP5007060B2 (ja) | ジョブ管理装置およびジョブ管理方法 | |
US20090138621A1 (en) | System and method for delegating a dependent business object | |
JP3712984B2 (ja) | 業務進捗制御装置及びその方法と、業務進捗制御プログラム及びそのプログラムを記録した記録媒体 | |
CN114721647B (zh) | 一种基于无代码应用开发的面向对象编程方法 | |
JP5007041B2 (ja) | ジョブ管理装置およびジョブ管理方法 | |
CN111124386B (zh) | 基于Unity的动画事件处理方法、装置、设备和存储介质 | |
JP5033343B2 (ja) | ジョブ管理装置およびジョブ管理方法 | |
Heller et al. | Graph-based specification of a management system for evolving development processes |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080908 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20111115 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120111 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20120131 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120426 |
|
A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20120507 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20120522 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120528 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150601 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 5007041 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |