JP2009054142A - 分散タスク処理 - Google Patents

Abstract

【課題】分散タスク処理において使用することが可能なシステム、方法、ソフトウェア、および、データ構造を提供する。
【解決手段】ある実施形態は、ユーザ定義されるタスク記述の中でのグローバルに管理されるタスクおよび製作物の疎結合の対応付けのための汎用アーキテクチャを含む。結果として、そのような実施形態は、柔軟で順応可能なタスクモデルを提供する。
【選択図】図１

Description

本発明は、分散タスク処理において使用することが可能なシステム、方法、ソフトウェア、および、データ構造に関する。

組織の内部プロセスは、一般的に、タスクまたはプロジェクト管理ソフトウェアを使用して追跡される。そのようなソフトウェアはプロジェクトおよびタスクのモデル化を可能とする。これらのモデルは典型的に静的である。しかし、多くの組織内の運用は、予測できない形態で変化しうる、緩く定義された、または、動的なプロセスを利用する。
なお、従来技術として非特許文献１〜５が知られている。
DUURSMA, CUNO他、"Task Model Definition and Task Analysis Process. KADS-II, Deliverable M.5, Version 2.0"、（ベルギー）、Vrije University, Brussels、１９９４年８月８日、p.1-51 GREBNER, O.他、"Task Management Model"、（ドイツ）、The Social Semantic Desktop Nepomuk、２００７年、p.1-91 MORI, G.他、"CTTE: Support for Developing and Analyzing Task Models for Interactive System Design"、（米国）、IEEE Transactions on Software Engineering, 28(9)、２００２年９月、p.1-17 OUDSHOORN, MICHAEL J.他、"Conditional Task Scheduling on Loosely-Coupled Distributed Processors"、（米国）、The 10th International Conference on Parallel and Distributed Computer Systems、The International Society for Computers and Their Applications. New Orleans, USA、１９９７年、p.136-140 SINNIG, DANIEL他、"Patterns, Tools and Models for Interaction Design"、（ポルトガル）、MBUI 2004, Proceedings of the First International Workshop on Making model-based user interface design practical: usable and open methods and tools, 103, Funchal, Madeira, Portugal、２００４年、p.1-4

同時に、そのようなタスクおよびプロジェクト管理ソフトウェアは、他のソフトウェアツールを使用してわずかな統合でスタンドアロンアプリケーション内に供給される。結果として、タスクおよびプロジェクト管理ソフトウェアのユーザは、高価で時間がかかりうるアプリケーションに固有の訓練を受けなければならなかった。さらに、訓練が提供されなければ、そのソフトウェアをどのように使用すべきか理解することはユーザ自身に任される。タスクおよびプロジェクト管理ソフトウェアはいくらかの組織内で使用されているが、ソフトウェアの静的な特質の結果として、ソフトウェア開発およびエンジニアリングのような特定のプロジェクト類型に使用されているにとどまる。

さらに、そのようなソフトウェアアプリケーションのプロジェクトまたはタスクのファイルは、一般に、プロジェクトのフォーマット毎のデータ構造を利用してきた。プロジェクトファイルの複数の実例が存在するので、プロジェクトファイルは、複数回、複製されなければならない。結果として、プロジェクトのためのファイルは、非常に大きくなりうる。プロジェクトファイルの実例の間の同期も課題となっている。さらに、複数のプロジェクトの一部である組織のプロセスが修正されると、各々のプロジェクトファイルは個々に変更されなければならない。

本発明は、タスク管理フロントエンドインタフェースを介してタスクモデル更新要求を受信するステップと、前記タスクモデル更新要求をタスク管理サーバに転送するステップと、前記タスク管理サーバから前記タスクモデル更新要求の成功確認を受信するステップと、前記タスクモデル更新要求の成功確認において受信された少なくともいくつかのデータを使用して前記タスク管理フロントエンドインタフェースを更新するステップと、を含む方法である。

また、本発明は、タスク管理フロントエンドモジュールと、タスク管理バックエンドモジュールと、を含むシステムであって、前記タスク管理フロントエンドモジュールは、人の相互作用を可能とするユーザインタフェースクライアントと、前記ユーザインタフェースクライアントにタスクモデルデータサービスを提供するタスククライアントと、前記ユーザインタフェースクライアントに製作物データサービスを提供する製作物クライアントと、を含み、前記タスク管理バックエンドモジュールは、前記タスク管理フロントエンドモジュールの前記タスククライアントにタスクモデルデータサービスを提供するタスクインタフェースと、前記タスク管理フロントエンドモジュールの前記製作物クライアントに製作物データサービスを提供する製作物インタフェースと、製作物のタスクモデルへのマッピングに関する製作物マッピングサービスを提供するタスク−製作物マッピングインタフェースと、を含むシステムである。

また、本発明は、符号化された命令を有するコンピュータ読み取り可能な媒体であって、適切に構成されたコンピュータ装置によって実行されるとき前記コンピュータ装置に、タスクモデルを表示する要求を受信する処理と、前記タスクモデルがタスクモデルキャッシュ内にローカルに記憶されていないならば、前記要求されたタスクモデルを検索する処理と、前記タスクモデルを表示する処理と、を実行させるコンピュータ読み取り可能な媒体である。

また、本発明は、タスクの表現を保持するデータ構造であって、ユニークなタスクの識別子を保持するタスク識別子と、前記タスクの記述を保持するタスク記述と、タスクが割り当てられるエンティティを表現するデータを保持するフィールドへの割り当てと、前記タスクのサブタスクとして指定されたゼロから多数の他のタスクのタスク識別子と、を含むデータ構造である。

人々は、多くの場合、彼らの毎日の作業の実務においてタスクを取り扱う。タスクは、一般に、作業の自己完結した単位である。ここでの本発明は、タスクを定義し、記憶し、管理するシステム、ソフトウェア、方法、および、データ構造のうち１つまたは複数を含みうる各種の実施形態を提供する。

個々の作業から発生するタスク構造は、多くの場合、組織レベルで決定されうる広範囲に承認されたビジネスの実務およびプロセスに関係しうる。ここでの各種の実施形態は、進行中の組織運営への阻害または悪影響なしにタスクが定義および修正されうるメカニズムを提供する。あるそのような実施形態は、より大きなタスクのための構成単位として使用される、文書およびテンプレートのような共有のタスク構造および製作物（artifact）を利用する。より大きなタスクのサブタスクでありうる１つのタスク、または、他のタスクまたはサブタスクと共有されうる製作物を修正することは、より大きなタスクへの修正が自動的に行われることを引き起こす。そのような修正は、定義されたタスクのプロセス、または、タスク定義を伴う文書のような製作物に行われうる。ここで説明される各種の実施形態は、ユーザ定義されるタスク記述の中でのグローバルに管理されるタスクおよび製作物の疎結合の対応付けのための汎用アーキテクチャを提供する。これは、結果として、柔軟で順応可能なタスク構造を提供するタスクモデルとなる。これらの実施形態および他の実施形態を以下でより詳細に説明する。

続く詳細な説明において、その一部を構成する添付図面を参照する。これは本発明が実施されうる例示の特定の実施形態によって表わされている。これらの実施形態は、この技術分野の当業者がそれらを実施することを可能とするように十分に詳細に説明される。他の実施形態が利用されうること、本発明の範囲を逸脱することなく構造的、論理的、電気的な変更が行われうることを理解すべきである。本発明のそのような実施形態は、個々におよび／または集合的に、便宜のために、および、１つより多くが実際に開示されるならば、本願の範囲をいずれか１つの発明または発明概念に自発的に限定することを意図することなく、単にここで用語“発明”と呼ぶ。

従って、続く説明は、限定の意味に捉えるのではなく、本発明の範囲は特許請求の範囲によって定義される。

ここで説明される機能（function）またはアルゴリズムは、一実施形態において、ハードウェア、ソフトウェア、または、ハードウェアおよびソフトウェアの組み合わせにおいて実現される。ソフトウェアは、メモリまたは他の種類の記憶装置のようなコンピュータ読み取り可能な媒体に記憶されたコンピュータ実行可能な命令を含む。用語“コンピュータ読み取り可能な媒体”は、ソフトウェアが送信される搬送波を表わすためにも使用される。さらに、そのような機能は、ソフトウェア、ハードウェア、ファームウェア、または、それらの任意の組み合わせであるモジュールに対応する。複数の機能は、望むならば１つまたは複数のモジュール内で実行され、説明される実施形態は単なる例示である。ソフトウェアは、デジタル信号プロセッサ、ＡＳＩＣ（application specific integrated circuit）、マイクロプロセッサ、または、パーソナルコンピュータ、サーバ、ルータ、または、ネットワーク相互接続装置を含むデータ処理が可能な他の装置のようなシステム上で動作する他の種類のプロセッサ上で実行される。

ある実施形態は、モジュール間で、および、モジュールを通して伝達される関係する制御およびデータ信号を使用して、２つまたはより多くの特定の相互接続されたハードウェアモジュールまたは装置内で、または、ＡＳＩＣの部分として、機能を実現する。従って、例示の処理フローは、ソフトウェア、ファームウェア、ハードウェアの実装に適用可能である。

ある実施形態において、中央のリポジトリ内のグローバルに管理されるタスク構造を指し示すユニークなタスク識別子の取り込みによって、グローバルに管理されるタスクの関係が与えられる。それによって、グローバルに管理されるタスク構造は、それらは、現在、リポジトリ内に記述されるので、それらの最新の形態で要求に応じて検索されうる。

ある実施形態において、製作物の表現は、タスク構造と並列にソフトウェアによって管理可能である。並列の製作物のシステムは、典型的に、タスクモデル内に含まれる最低限の製作物の表現に基づいて、中央の製作物リポジトリから１つまたは複数のタスクモデルに、異なる製作物および同一の製作物の異なるバージョンを供給および対応付けることができる。

上述した表現の管理のためのアーキテクチャは、典型的に、次の８つの構成単位のいくつかまたは全てからなる。
・タスクモデル（タスク記述）。
・クライアント側アプリケーション。これは、新たなタスク構造を生成し、既存のタスク構造に文書を対応付けることによって、バックエンドシステムから既存のタスク構造を読み出すことができる。
・一旦、検索されたグローバルに管理されるタスクモデルをローカルに記憶することによって、最適化の目的のために供するクライアント側のタスクモデルのローカルなキャッシュリポジトリ。ローカルなタスクモデルのキャッシュリポジトリは、典型的に、クライアントの応答性を向上させるために含まれるので、オプションである。
・一旦、検索された製作物をローカルに記憶することによって、最適化の目的のために供するクライアント側の製作物のローカルなキャッシュリポジトリ。ローカルなキャッシュリポジトリは、典型的に、クライアントの応答性を向上させるために含まれるので、オプションである。
・中央のタスクおよび製作物の管理サービスを含むサーバアプリケーション。これは、クライアント側アプリケーションを利用する複数のクライアントのために集中化された方法で、タスク構造および製作物の記憶、対応付け、および、供給の責任を負う。
・各種ユーザから生成されるタスクのために、管理されるタスクモデルおよびデータを保持する、サーバ側のタスクリポジトリ。
・分散モデルのために中央の製作物の記憶メカニズムとしての役割を果たす、サーバ側の製作物リポジトリ。
・製作物のタスクへのマッピングのためのデータを保持する対応付け記憶装置。

上述した要素の他の例は、タスクモデル記述としてのＸＭＬ文書、付属物とともにグループウェアのタスクを活用してタスクおよび付属コンテンツの送信のためにウェブサービスクライアントを提供するグループウェア・アドイン・アプリケーション、データ記憶としてデータベースを使用してタスクおよび製作物の管理のためにウェブサービスを提供するｊａｖａ（登録商標）アプリケーションサーバを含みうる。データベースは典型的に次を含む。
・タスクテーブル − グローバルに管理されるタスクモデルのための、および、ユーザによって生成されるタスク構造のためのデータを保持する。
・製作物テーブル − 製作物の属性を保持し、製作物のコンテンツを保持する物理的なサーバ側ファイルへのポインタを含む。
・製作物−タスクテーブル − 製作物およびタスクデータの結合から外部のキーテーブルとして構成され、それによって、製作物のタスクへの対応付けを実現する。

典型的な実施形態において、ユーザはグループウェアアプリケーションにおいてタスクを生成し、デフォルトのグループウェア機能を使用してタスクに付属物を付加する。タスクが保存されると、タスク構造が読み出され、ウェブサービス上での保持のためにバックエンドに送信される。これはタスクリポジトリ内にタスクエントリを生成し、それによって、渡されるタスクのために中央のバックエンドタスクのインスタンスを生成する。タスク構造が保持されると、フロントエンドはタスクのために全ての付属物を読み出し、それらを製作物管理ウェブサービス上で（例えば、Simple Object Access Protocolすなわち“ＳＯＡＰ”上で）バックエンドに送信する。

製作物は、典型的に、サーバ上の製作物リポジトリ内に記憶され、それによって、同一の名称を有する各々の利用可能な製作物は、既に存在する製作物について重複して生成されないように、チェックサムにより明示的に検査される。各々の製作物についてユニークなＩＤが生成され、タスクＩＤおよび製作物ＩＤによって製作物を使用してタスクが製作物に対応付けされる。タスク送信およびタスク付属物の送信の両方は単一のウェブサービスを使用して実行することが可能であり、それによって、対応付けが正しく行われることができるように、タスクが生成された後に、それは付属物を記憶するためにのみ重要でありうるということに留意すべきである。また、タスクおよび製作物ウェブサービスは、物理的に異なるホスト上に設けることが可能である。

ある実施形態において、製作物管理サービスは付属物を記憶し、製作物管理サービスはクライアントフロントエンドにＩＤを返却し、クライアントフロントエンドは、バックエンド上で、保持される製作物をユニークに識別する。それによって、全てのクライアントは、付属物が正しく識別されることを確実にするために同一の製作物サービスを使用することが可能であるが、高等な識別方式が作り上げられるならば、クライントは、製作物リポジトリが複数のホストにわたって分散されるクラスタ化された製作物サービスを活用することが可能である。そして、サーバから返却されるＩＤは、クライアントフロントエンド上で、タスク構造内に記憶されうる。ユーザがクライアントフロントエンド内の既存のタスクからタスクモデルをエクスポートするならば、適切な製作物への参照は、典型的に、製作物ＩＤによってタスクモデル内にエクスポートされる。そして、生成されるタスクモデルを適用する各ユーザは、このＩＤを使用して製作物を問い合わせ、それを製作物サーバから取得することができる。上述した処理は、各システムユーザによって実行されるパーソナルなタスクの生成を参照する。それによって、特定の役割を有するユーザは、タスク構造を生成することができ、そのタスク構造は企業内の共通の実務として承認される。生成されるタスク構造は、上述した処理に準拠し、それらのタスクＩＤによってグローバルにアクセス可能である。そして、他のユーザはそれらのＩＤによってこれらのグローバルに管理されるタスクを参照し、それらのパーソナルなプロセスモデル内にそれらのタスクを取り込む。

図１は、一例の実施形態によるシステム１００の論理的なブロック図である。システム１００のアーキテクチャは、上述したように、８つの構成単位のいくつかまたは全てを含みうる。これらの構成単位は、クライアント層１０２、サーバ層１０４、パーシステンス層１０６にわたって広がる。クライアント層１０２内に、タスクモデル１２６の抽出、タスク管理フロントエンドアプリケーション１０８、ローカルタスクモデルキャッシュリポジトリ１２２、ローカル製作物キャッシュリポジトリ１２４が存在する。サーバ層１０４内に、タスク管理バックエンドアプリケーション１２８が存在する。パーシステンス層１０６内に、タスクリポジトリ１３６、製作物リポジトリ１３８、対応付けデータ記憶装置１４０が存在する。

タスクモデル１２６の抽出は、典型的に、抽出され、標準化されたタスク記述を与える。タスク管理フロントエンドアプリケーション１０８は、各クライアントのためにローカルにタスク構造および製作物を管理し、タスク管理バックエンドアプリケーション１２８に更新および問い合わせの要求を発行する。タスク管理バックエンドアプリケーション１２８は、タスクおよび製作物の管理のために集中化されたサービスを提供する。タスクモデル１２６はフォーマットを提供し、そのフォーマットでタスクはローカルに記憶され、クライアント層１０２とサーバ層１０４との間で送信される。クライアント層１０２とサーバ層１０４との間でタスクデータを送信するために、タスクはＸＭＬ（Extensible Markup Language）フォーマットで表現されうる。

タスク管理フロントエンドアプリケーション１０８は、タスクオブジェクト実行時表現１１０、製作物クライアント１２０、タスククライアント１１８、ローカル製作物キャッシュコンポーネント１１６、ローカルタスクモデルキャッシュコンポーネント１１４のうちいくつかまたは全てを含むいくつかの構成要素を含む。タスククライアント１１８は、タスクオブジェクトへの更新をタスク管理バックエンドアプリケーション１２８に送信し、サーバ層１０４において管理され、パーシステンス層１０６において記憶されるタスク構造を問い合わせる。製作物クライアント１２０は、製作物への更新を送信し、サーバ層１０４において管理され、パーシステンス層１０６において記憶される製作物のコンテンツを問い合わせる。

ある実施形態において、製作物クライアント１２０およびタスククライアント１１８は、タスク管理バックエンドアプリケーション１２８のウェブサービスを利用してサーバ層１０４とインタフェースする。ウェブサービスは、１つまたは複数のタスクウェブサービス１３０および１つまたは複数の製作物ウェブサービス１３２を含みうる。

ローカルタスクモデルキャッシュ１１４は、典型的に、グローバルに管理されるタスクモデルは増加したサイズおよびサーバ層１０４からの繰り返しの検索を有し、過大な通信オーバーヘッドを引き起こしうるので、要求に応じて、グローバルに管理されるタスクモデルのローカル記憶装置を提供する。ローカルタスクモデルキャッシュ１１４は、ローカルタスクモデルキャッシュリポジトリ１２２内に記憶され、問い合わせされるモデルをユニークなＩＤに対応付け、モデルのコンテンツをローカルに利用可能とする。

ローカル製作物キャッシュ１１６は、典型的に、製作物は大きなサイズおよびサーバ層１０４からのそれらの繰り返しの検索を有し、過大な通信オーバーヘッドを引き起こしうるので、要求に応じて、製作物のローカル記憶装置を提供する。ローカル製作物キャッシュ１１６は、ローカル製作物キャッシュリポジトリ１２４内に記憶され、問い合わせされる製作物をユニークな識別子に対応付け、それらのコンテンツをローカルに利用可能とする。

しかし、ローカルタスクモデルキャッシュ１１４およびローカル製作物キャッシュ１１６は必須とされず、オプションである。省略されるとき、製作物およびタスクモデルのコンテンツは、要求される毎にサーバ層１０４から検索される。

タスク管理バックエンドアプリケーション１２８は、典型的に、タスクおよび製作物の管理のためのウェブサービスを提供する。これらのサービスは並列に存在し、クライアントと通信し、かつ更新および問い合わせを実行することによって、それぞれタスクおよび製作物を管理する。ある実施形態において、タスクウェブサービス１３０は、クライアント層１０２のタスク管理フロントエンドアプリケーション１０８から供給される、パーシステンス層１０６のタスクリポジトリ１３６内のタスク記述を更新する。タスク管理フロントエンドアプリケーション１０８においてタスクの発展を通して更新が実行されるので、グローバルに管理されるタスクモデルは単にタスクとして記述することができ、特定の役割または職能を有するユーザのような特定の関係者によってタスクが生成および管理される。そのような役割または職能の例は、管理者、プロジェクトマネージャー、チームリーダー等を含みうる。これらの役割または職能は、典型的に、そのような人々に、グローバルに管理されるタスクまたは対応付けされる製作物のいくつかまたは全てを生成、更新、削除する特権を与える。

更新のための製作物のコンテンツは、クライアント層１０２のタスク管理フロントエンドアプリケーション１０８から送信され、サーバ層１０４のタスク管理バックエンドアプリケーション１２８の製作物ウェブサービス１３２を通して、パーシステンス層１０６の製作物リポジトリ１３８内に記憶される。ある実施形態において、製作物のコンテンツは、複製のコンテンツを有する製作物の生成を防止するために役立つようにチェックサムに基づいて検査される。

製作物のタスクへの対応付けがリポジトリマッパー１３４を使用して行われる。リポジトリマッパー１３４は、製作物リポジトリ１３８からの製作物記述をタスクリポジトリ１３６内のタスク記述にマッピングする機能を有する。そして、パーシステンス層１０６の対応付けデータ記憶装置１４０内にマッピングが保持される。そして、これらの対応付けは、リポジトリマッパー１３４によって再び読み出され、タスクウェブサービス１３０および製作物ウェブサービス１３２に取り戻されうる。

タスクモデル１２６は、抽出され、標準化されたタスクの表現であり、タスクは、異なるユーザによる使用においてタスク管理フロンドエンドアプリケーション１０８のインスタンスの間で交換し合うことができる。図２は、一例の実施形態によるタスクモデル１２６の論理的なデータ関係図である。タスクモデルは、論理的にツリー状の構造であり、ＸＭＬ文書におけるようなマークアップ言語で記述することができる（図２のタスクモデル例を参照）。タスク管理フロントエンドアプリケーション１０８内のタスクオブジェクト１１２は、グループウェアアプリケーションのタスク項目における付属物のような、ローカルに記憶される完全な製作物のコンテンツへの参照を保持するのに対し、そのオブジェクトに起因するタスクモデルは、グローバルに記憶される製作物への参照、例えば製作物ＩＤのみを保持することが可能である。それによって、製作物の物理的なコンテンツは、必ずしもタスクモデル１２６内に含まれるとは限らないが、タスク管理バックエンドアプリケーション１２８内または製作物リポジトリ１３８内に存在し、製作物ウェブサービス１３２を通して供給することができる。タスクモデル１２６は、おそらく、タスク管理フロントエンドアプリケーション１０８内に存在するタスクオブジェクトからエクスポートされる。また、モデルのフォーマットは、サーバ層１０４またはパーシステンス層１０６からタスク構造の供給のためのフォーマットとして使用されうる。

図２の説明は、ある実施形態による、右側のタスクモデル例とともにタスクモデルの設計の一例を表わす。タスク構造は典型的にツリー状の文書構造であり、各タスクはサブタスクおよび適切なＸＭＬタグ内に記述された特定の特性を有しうる。それによって、タスクのコンテンツは、明示的に含まれ、または、タスクリポジトリ１３６からの取り込みのために示されうる。

ある実施形態において、タスクリポジトリ１３６はファイルシステムを基にすることが可能であり、各タスクは別個の文書内に記述される。他実施形態において、タスクリポジトリ１３６はタスクのコンテンツを保持するデータベースのテーブルとして実現することが可能である。データベースの実施形態において、データベースは、タスクＩＤのような、取り込まれるタスクのユニークな識別子についての検索を容易にする。しかし、取り込まれるタスクのユニークな識別子は、‘名称’および‘バージョン’の属性が適切に保持され、同様にユニークな識別子の制約を与えることができるならば、‘名称’および‘バージョン’の属性を使用して実行することが可能である。

タスクの取り込みとは異なり、製作物は大きなサイズを有しうる文書および他の付属物であるので、タスクモデル１２６は製作物のコンテンツの取り込みのために有効である。製作物の取り込みは、製作物リポジトリ１３８から製作物を検索する。様々な実施形態において、製作物リポジトリ１３８は、サーバのファイルシステム上の物理的なファイル、または、サーバのファイルシステム上の全ての製作物の特性および物理的なファイルの位置を保持するデータベースのエントリから構成されうる。製作物リポジトリ１３８内の製作物についての検索は、製作物ウェブサービス１３２を利用する。しかし、ある実施形態において、希望および指定するならば、製作物が定義または修正されるとき、完全な製作物のコンテンツは、例えば、タスクモデル内にベース６４エンコードされた２進数データを埋め込むことによって、タスクモデル内に取り込まれうる。

タスクモデル１２６は、タスクリポジトリ１３６内に含まれるタスクについて、図２のタスクモデル例のような単なるタスク記述文書として検索することが可能である。それによって、異なる検索モードを選択することが可能である。例えば、最低限のモードは、取り込みタグのみを使用してタスクを検索することが可能である。その代わりに、最大限のモードは、グローバルに管理されるタスクおよび製作物の完全なコンテンツをタスク管理フロントエンドアプリケーション１０８に取得することが可能である。ある実施形態において、完全なタスクモデルおよび製作物の最小部分を取得するような、組み合わせを指定することが可能である。

タスクオブジェクトは、タスク管理フロントエンドアプリケーション１０８内のタスクの実行時の表現である。タスクオブジェクトは、図２のタスクモデル例におけるように、タスクモデル１２６の文書内にエクスポートされうる。典型的な実施形態において、タスクオブジェクトは、ローカルに記憶される完全な製作物のコンテンツへの参照を保持する。しかし、タスクの実行時のオブジェクトから生じるタスクモデルは、グローバルに記憶される製作物への参照のみを保持することが可能である。製作物の参照は、製作物オブジェクトとしてタスクオブジェクト内で表現される。製作物オブジェクトは、サーバ層１０４およびパーシステンス層１０６におけるタスクのコンテンツの更新の結果に基づいて生成される。それによって、各々の含まれる製作物オブジェクトは１つのタスクの付属物に対応する。製作物オブジェクトは、製作物のタスクモデルへの参照をエクスポートするために使用される。それによって、製作物の物理的なコンテンツは、デフォルトでタスクモデル内に含まれるが、パーシステンス層１０６内に存在し、製作物ウェブサービス１３２を通して供給することができる。望まれるならば、製作物の完全なコンテンツは、タスクモデル１２６内にエクスポートすることが可能である。

また、タスクの実行時のオブジェクトは、実行時のサブタスクオブジェクトへの参照を含みうる。典型的な実施形態において、タスクオブジェクトは１つまたは複数のサブタスクオブジェクトを参照し、または、サブタスクオブジェクトは親のタスクオブジェクトを参照しうる以外は、タスクオブジェクトおよびサブタスクオブジェクトは、事実上、同一である。これらのオブジェクトは、全ての関係するタスク記述データで完全に満たされ、または、それらは、グローバルに管理されるタスクモデルとしてバックエンドにおいて記憶される部分的に満たされたタスクオブジェクトを表現するのみでありうる。例えば、グローバルに管理されるタスクモデルを参照するタスクノードがタスクツリー内で拡張され、全ての関係する情報が表示されるとき、完全なコンテンツは、典型的に、バックエンドからの要求に応じて検索される。

タスク管理フロントエンドアプリケーション１０８のタスククライアント１１８は、タスク管理バックエンドアプリケーション１２８にローカルなタスク構造を送信し、タスク管理バックエンドアプリケーション１２８から既存のタスク構造を検索する責任を負う。タスク構造は、典型的に、十分に定義されたタスクモデル記述でタスク管理バックエンドアプリケーション１２８から検索される。また、タスククライアント１１８は、特定の実施形態が含むならば、ローカルタスクモデルキャッシュリポジトリ１２２を更新するために使用されうる。

タスク管理フロントエンドアプリケーション１０８の製作物クライアント１２０は、タスク管理バックエンドアプリケーション１２８に、概念的にタスクモデルの付属物である製作物を供給し、タスク管理バックエンドアプリケーション１２８から製作物を検索する責任を負う。製作物クライアント１２０は、典型的に、バックエンドの製作物リポジトリ１３８を更新するためにタスクの付属物への更新が送信されるときに利用される。また、製作物クライアント１２０は、特定の実施形態が含むならば、ローカル製作物キャッシュリポジトリ１２４を更新するために使用されうる。

ある実施形態において、ローカルタスクモデルキャッシュ１１４は、必要に応じて、要求されるタスクモデルをローカルに記憶するために使用される。タスクモデルはクライアントから要求されるとき、例えば、表示されるタスクモデル内のグローバルに管理されるタスクをクライアントが閲覧することを望み、タスクツリーノード上でダブルクリックするとき、ローカルタスクモデルキャッシュ１１４は、そのようなタスクモデルがローカルに存在するかどうか、および、タスク管理バックエンドアプリケーション１２８のタスクウェブサービス１３０にタスククライアントを使用して要求を発行していないかどうかを検査する。そして、完全なタスクモデルは、ローカルタスクモデルキャッシュリポジトリ１２２内に供給され、ローカルに記憶される。それによって、ローカルタスクモデルキャッシュ１１４は、検索されるタスクモデルのユニークなタスクモデル識別子をリンクする。検索されるグローバルに管理されるタスクを閲覧する続く要求は、結果として、追加の通信オーバーヘッドを防止するためにローカルな複製を供給することになる。

ローカル製作物キャッシュ１１６は、典型的に、必要に応じて、要求される製作物をローカルに記憶するために使用される。製作物がクライアントから要求されるとき、例えば、表示されるタスクモデル内の製作物をクライアントが閲覧することを望み、製作物ノード上でダブルクリックするとき、ローカル製作物キャッシュ１１６は、そのような製作物がローカルに存在するかどうか、および、タスク管理バックエンドアプリケーション１２８の製作物ウェブサービス１３２に製作物クライアントを使用して要求を発行していないかどうかを検査する。製作物の物理的なコンテンツは、ローカル製作物キャッシュリポジトリ１２４内に供給され、ローカルに記憶される。それによって、ローカル製作物キャッシュ１１６は、生成されるローカルな記憶装置にユニークな製作物の識別子をリンクする。製作物を閲覧する続く要求は、結果として、追加の通信オーバーヘッドを防止するためにローカルな複製を供給することになる。

ローカルタスクモデルキャッシュリポジトリ１２２は、検索されるグローバルに管理されるタスクモデルのコンテンツをクライアントシステム上にローカルに記憶する。ローカルタスクモデルキャッシュリポジトリ１２２は、検索されるタスクモデルのコンテンツが物理的なファイルとして書き込まれる単なるローカルなファイルシステムフォルダとして組織化されうる。ある実施形態において、既存のモデルの更新が要求されるならば、キャッシュは自動的にクリアされる。他の実施形態は、タスクモデルを保持する指定された時間に基づいて、または、タスクリポジトリ１３６内に記憶されるタスクモデルにおける変更が検出されるときに、自動的にクリアすることを含む。他の実施形態は、タスク管理フロントエンドアプリケーション１０８が停止されるときローカルタスクモデルキャッシュリポジトリ１２２をクリアすることを含む。

ローカル製作物キャッシュリポジトリ１２４は、製作物のコンテンツをクライアントシステム上にローカルに記憶する。ローカル製作物キャッシュリポジトリ１２４は、サーバから検索される製作物のコンテンツが物理的なファイルとして書き込まれる単なるローカルなファイルシステムフォルダとして組織化されうる。既存の製作物の更新が明示的に要求されるならば、キャッシュは自動的にクリアされ、または、それは、ローカルタスクモデルキャッシュリポジトリ１２２と同様に自動的にクリアされうる。

タスクウェブサービス１３０は、タスク管理バックエンドアプリケーション１２８の一部である。タスクウェブサービス１３０は、典型的に、バックエンドにおいてタスク構造を更新し、タスクリポジトリ１３６内にそれらを記憶する責任を負う。また、タスクウェブサービス１３０は、タスクリポジトリ１３６からタスク構造を読み出し、それらをタスクモデルに変換し、それらをタスク管理フロントエンドアプリケーション１０８のタスククライアント１１８に供給する責任を負う。

製作物ウェブサービス１３２は、典型的に、タスク管理バックエンドアプリケーション１２８内で製作物の管理の責任を負う。製作物の管理は、典型的に、クライアントから供給される製作物のコンテンツを製作物リポジトリ１３８内に記憶し、必要に応じて、製作物のコンテンツおよび情報を製作物クライアント１２０に供給することを含む。それによって、製作物ウェブサービス１３２は、製作物の名称および製作物のコンテンツのチェックサム、例えば、製作物のコンテンツをユニークに識別するＣＲＣ３２チェックサムに応じて、異なる製作物のバージョンを識別し、クライアントに供給する。

ある実施形態において、リポジトリマッパー１３４は、タスクリポジトリ１３６および製作物リポジトリ１３８の両方をアクセスすることによってタスク内の製作物を対応付ける機能を実行する。また、リポジトリマッパー１３４は、製作物ウェブサービス１３２およびタスクウェブサービス１３０の一方または両方の一部として実現されうる。また、リポジトリマッパー１３４は、対応付けデータ記憶装置１４０内に対応付けデータを書き込む責任を負いうる。製作物のタスクへの対応付けは、多対多の関係における製作物およびタスクのユニークな識別子の結合から生じる。それによって、１つの製作物は、複数のタスクによって使用され、製作物リポジトリ１３８内の単一のエントリを通して表現されうる。タスクが製作物の改訂されたバージョンを要求するならば、改訂された製作物のバージョンのために新たな製作物のエントリが生成され、対応付けが、新たな製作物リポジトリ１３８のエントリに切り換えられる。

タスクリポジトリ１３６は、タスクおよびそれらのコンテンツを保持する。タスクリポジトリ１３６は、タスク構造のための中央の記憶装置である。リポジトリは、ファイルシステムフォルダとして組織化することができる。しかし、ある実施形態は、データベースを基にして実現される。

製作物リポジトリ１３８は、名称、ＩＤ、チェックサム、文書、テンプレート、等を含みうる製作物の記述属性のような１つまたは複数の製作物データを含みうるものを記憶する。製作物リポジトリ１３８は、いくつかのデータベーステーブルまたは電子ファイルおよびファイルフォルダにわたって分散された方法で組織化されうる。

システム１００のアーキテクチャは、タスク管理アプリケーションによって使用されうる。そのようなアプリケーションは、生成されたタスクモデルを送信することができ、特定のグローバルに管理されるタスク構造の変更、製作物のサイズ、または、記憶装置の位置について注意する必要はない。ユーザは、分散タスクモデルとしてそれら自身を記述するグローバルに管理される再使用可能な実務を活用することによってタスクモデルを構成することができる。それによって、グローバルに管理されるタスクモデルの連鎖は、様々な企業ドメイン上に広がり、エンドユーザは特定の、ネストされた、グローバルに管理されるタスクモデルの正確さについて心配する必要はない。さらに、そのようなタスクモデルを活用するアプリケーションは、透過的で軽量な方法で、製作物のコンテンツへのアクセス、および、製作物への修正を可能とする。

図１に関して一例を説明したアーキテクチャの使用プロセスは、いくつかのフェーズに分割される。これらのフェーズは、タスクモデルの更新および検索、製作物の更新、消去および検索を含む。図４において、タスクモデルの検索フェーズの一例の実施形態が説明され、図３において、タスクモデルの更新フェーズの一例の実施形態が説明される。さらに、図５（ＡおよびＢ）、図６、図７において、それぞれ、製作物の更新、製作物の消去、製作物の検索のフェーズが説明される。

図３は、一例の実施形態による方法３００のブロックフロー図である。方法３００はタスクモデルを更新する一例の実施形態である。

タスクモデルは、一般に、タスクを記述し、バックエンドシステム上のタスクリポジトリ内に保持されるタスクエントリとして表現される。上述したように、グローバルに管理されるタスクモデルは、特定のユーザグループによってアクセス可能かつ管理可能であるタスクに他ならない。フロントエンド上で実行時のタスクオブジェクトが変更されると（３０２）、タスクサービスクライアントは、名称、期限、説明、主題、等のような変更されるタスク属性の表現を含むタスク更新要求を生成する（３０４）。タスク更新要求はサーバに送信され（３０６）、そこで解析される（３０８）。したがって、データは、タスクリポジトリ内のタスクエントリ内で更新される（３１０）。そのタスクについてまだエントリが存在しないならば、新たなタスクエントリが生成される。結果の状態およびデータがクライアントに返却される（３１２）。クライアントは状態およびデータを解析し（３１４）、更新が成功したかどうか判定する（３１６）。成功ならば、フロンドエンドは更新される（３２０）。更新が成功でなかったならば、ユーザインタフェースを介してエラーが表示される（３１８）。ある実施形態において、更新要求は非同期に引き起こされる。そのような実施形態において、更新操作は透過的に実行し、フロントエンドはサーバからの結果を待たない。

図４は、一例の実施形態による方法４００のブロックフロー図である。方法４００はタスクモデルを検索する一例の実施形態である。

例えば、タスクツリービュー内でグローバルに管理されるタスクのツリーノードを展開するユーザによって、グローバルに管理されるタスクへのリンクがクライアント内で活性化されると、クライアントアプリケーションは、特定のタスクについてのエントリがローカルタスクモデルキャッシュ内に存在するかどうか（４０４）を検査する（４０２）。クライアント上に記憶されるタスク記述文書へのローカルファイルパスまたはメモリアドレスのようなローカルなリンクが発見されたならば、タスクのコンテンツがローカルファイルから検索される（４３２）。ローカルタスクモデルキャッシュ内にタスクエントリが発見されないならば、タスクＩＤまたはタスク名とバージョンの組み合わせのようなユニークなタスク識別子に基づいてタスク問い合わせ要求が生成される（４０８）。そして、要求はサーバに送信される（４１０）。

サーバは要求データを解析し（４１２）、タスクリポジトリからタスクデータを検索する（４１４）。タスクモデルが存在しないならば（４１６）、要求しているクライアントにエラー状態が返却される（４１８）。タスクモデルが存在するならば（４１６）、要求されるモード（問い合わせデータにおいて指定される最低限および最大限の表現）においてリポジトリデータから共通のタスクモデル記述が生成される（４２０）。それによって、（例えば、ＸＭＬ内のベース６４エンコードされた２進数データとして）完全な製作物のコンテンツの明示的な取り込みが要求されるならば、タスクウェブサービスは製作物のコンテンツを問い合わせるために製作物ウェブサービスにアクセスすることが可能である。生成されたタスクモデルは、応答データとして返却される（４１８）。

そして、クライアントは、受信した問い合わせの応答の状態およびデータを解析する（４２２）。検索が成功でなかったならば（４２４）、ユーザインタフェースにおいてエラーが表示される（４２６）。しかし、動作が成功であったならば（４２４）、取得したタスクモデルはローカルタスクモデルキャッシュリポジトリ内に記憶される（４２８）。そして、キーを使用してローカルタスクモデルキャッシュリポジトリが更新され、グローバルに管理されるタスクのユニークな識別子および記憶されるタスクモデルのローカルな位置を含むローカルタスクモデルキャッシュエントリを生成する（４３０）。ローカルなタスクモデルが検索され（４３２）、クライアントによって解析され、フロントエンドは更新される。そのような実施形態において、グローバルに管理されるタスクモデルのコンテンツの続く要求は、ローカルタスクモデルキャッシュがクリアされるまで、ローカルな複製を利用する。

タスクモデルのローカルキャッシュはオプションであり、性能を向上させることを目的とすることに留意すべきである。キャッシュが省略されるならば、ローカルキャッシュは検査されない（４０２）。タスクモデルが要求される毎に、問い合わせが生成され（４０８）、送信される（４１０）。従って、サーバから検索されたコンテンツはローカルに記憶されず、ローカルタスクモデルキャッシリポジトリ内の記憶（４２８）およびローカルタスクモデルキャッシュエントリの生成は省略される。さらに、ローカルなタスクモデルは検索されず、その代わりに、コンテンツはサーバから供給される。

図５Ａは、一例の実施形態による方法５００の第１部分のブロックフロー図である。図５Ｂは、一例の実施形態による図５Ａの方法５００の第２部分のブロックフロー図である。例示の方法５００は、製作物の更新プロセスの一実施形態である。図５Ａに表わされている方法５００の部分は、方法５００を実現するシステムのクライアント層内で実行される。図５Ｂに表わされている方法５００の部分は、方法５００を実現するシステムのサーバ層内で実行される。

図５Ａを参照すると、フロントエンド上でタスクオブジェクトへの変更が行われるとき、まず、タスクが更新される（５０２）。タスクを更新すること（５０２）は、タスク項目のリポジトリ内に新たなタスクエントリを追加することを含みうる。タスクを更新する一例の方法が図３に表わされている。タスクの更新（５０２）が成功でないならば、ユーザインタフェースにおいてエラーが表示される（５０６）。タスクの更新（５０２）が成功であるならば（５０４）、タスクオブジェクト内の全ての物理的な付属物についてループが実行される（５０８）。アプリケーションは含まれる製作物オブジェクトの参照を利用して、物理的な付属物がタスクオブジェクト内で製作物の参照を使用して既に記述されているかどうか検査する（５１０）。これは、製作物オブジェクトが、例えば、ＣＲＣ３２チェックサムのような製作物のコンテンツ（バイト）のユニークな識別子の役割を果たすチェックサム属性を含み、製作物オブジェクト内に記憶される名称の属性と同一の名称を有する付属物の物理的なコンテンツについてそのようなチェックサムが計算されるとき、実行されうる。付属物が適切な製作物オブジェクトの参照を通してタスクオブジェクト内で表現されていないならば、製作物ウェブサービスクライアントは、適切な付属物の全てのコンテンツ（バイト）を含みうる製作物更新要求を生成（５１２）および送信（５１４）する。

ここで、図５Ｂを参照すると、サーバ上で要求が解析され（５１６）、受信したコンテンツについてチェックサムを作成する（５１８）。そして、製作物がサーバ上に既に存在するかどうか確認するために、サーバ上の既存の製作物が検査される（５２０）。製作物が存在しないならば、製作物は製作物リポジトリ内に保存される（５２４）。製作物が存在するならば、記憶されているデータソースから製作物が取得される（５２６）。そして、いずれの場合においても、製作物は更新されたタスクと対応付けされる（５２８）。そして、サーバはクライアントに状態およびデータを返却する（５３０）。

そして、図５Ａに戻り、クライアントは受信した状態およびデータを解析する。その状態がサーバ上での失敗を示すならば、ユーザインタフェースを介してエラーが表示される（５３６）。その状態が成功を示すならば（５３４）、方法５００は、タスクに製作物オブジェクトの参照を追加することによって完了する（５３８）。

ある実施形態において、既存の製作物についての検査はクライアント上で実行される。これは、クライアント側がローカル製作物キャッシュおよびローカル製作物キャッシュリポジトリの一方または両方を含む実施形態において実行される。これらの検査は、重複した製作物の生成の防止に役立つ。

図６は、一例の実施形態による方法６００のブロックフロー図である。方法６００は、図１のシステム１００のようなシステムから製作物を消去する一例の実施形態である。方法６００は、対応する付属物がフロントエンド上のタスクから消去されたならば、特定の製作物のタスクへの対応付けを単に消去する目的を有する。フロントエンド上のタスクオブジェクトへの変更が検出され、アプリケーションが全ての含まれる付属物について製作物を更新したとき、アプリケーションは、以前に含まれた製作物オブジェクトの参照のいくつかが、含まれる付属物にもはや対応していないかどうか検査する。もはや対応していないならば、クライアントは、もはや使用されていない製作物オブジェクトの参照および現在の修正されたタスクについてのタスクＩＤを単に渡すことによって、バックエンドへの消去要求を引き起こす。バックエンド上のリポジトリマッパーは、与えられた製作物ＩＤについて製作物リポジトリから製作物エントリを問い合わせ、与えられたタスクＩＤについてその対応付けを消去する。

あるそのような実施形態において、例示の方法６００は、製作物への対応付けを消去するためにタスクを更新すること（６０２）を含む。タスクの更新（６０２）が成功でないならば、ユーザインタフェースを介してエラーメッセージが表示される（６０６）。タスクの更新（６０２）が成功であるならば、方法６００は、各々の消去される製作物の参照について繰り返し（６０８）、製作物消去要求を生成する（６１２）。そして、製作物消去要求はサーバに送信される（６１４）。

そして、サーバは要求データを解析し（６１６）、製作物消去要求に対応付けされたタスクについて検査する（６１８）。製作物の参照が存在するならば、参照はマッピングから消去される（６２２）。製作物の参照が存在しないならば（６２０）、または、全てがマッピングから消去された後（６２２）、サーバはクライアントに状態およびデータを返却する（６２４）。

そして、クライアントは状態およびデータを解析して（６１２）、製作物消去要求がサーバによって完了したかどうかを判定する（６２８）。完了していないならば、ユーザインタフェースを介してエラーが表示される（６３０）。完了したならば、クライアント上でタスク内の製作物オブジェクトの参照が消去される（６３２）。

図７は、一例の実施形態による方法７００のブロックフロー図である。方法７００は、製作物を検索する一例の実施形態である。

あるそのような実施形態において、クライアントアプリケーションは、まず、ローカル製作物キャッシュを使用して、与えられた製作物のローカルな複製がローカル製作物キャッシュ内に記憶されているかどうか検査する（７０２）。そのようなエントリが含まれるならば（７０４）、ローカルな製作物のコンテンツが検索される（７０６）。ローカルな製作物のエントリが発見されないならば、製作物サービスクライアントは製作物問い合わせ要求を生成し（７０８）、それを製作物ウェブサービスに送信する（７１０）。サーバは要求データを解析し（７１２）、リポジトリから製作物を問い合わせる（７１３）。製作物エントリが存在するならば（７１４）、アプリケーションはリポジトリから製作物のコンテンツを読み出し（７１６）、応答を用いてそれを返却する（７１８）。クライアントは応答の状態およびデータを解析する（７２０）。状態が否定的ならば（７２２）、クライアントはエラーメッセージを表示する（７２４）。しかし、成功が検出されたならば（７２２）、クライアントは問い合わせされた製作物についてローカル製作物リポジトリエントリを生成する（７２６）。また、フロントエンドアプリケーションにおいて、ローカル製作物キャッシュエントリが生成される（７２８）。そして、製作物のコンテンツはローカル記憶装置から検索される（７０６）。

ローカル製作物キャッシュはオプションであり、性能の最適化を目的とすることに留意すべきである。キャッシュがないならば、ローカルキャッシュの検査（７０２）は省略され、各々の製作物要求について製作物問い合わせが生成される。さらに、ローカル製作物リポジトリ内に記憶すること（７２６）、および、ローカル製作物キャッシュエントリを生成すること（７２８）も省略され、ローカルコンテンツの検索（７０６）は行われない。そのような実施形態において、要求される製作物のコンテンツは製作物毎に供給される。

図８は、一例の実施形態による方法８００のブロックフロー図である。例示の方法８００は、タスク管理フロントエンドインタフェースを介してタスクモデル更新要求を受信すること（８０２）、タスク管理サーバにタスクモデル更新要求を転送すること（８０４）、タスク管理サーバからタスクモデル更新要求の成功確認を受信すること（８０６）を含む。方法８００は、タスクモデル更新要求の成功確認において受信される少なくともいくつかのデータを使用してフロントエンドインタフェースを更新すること（８０８）をさらに含みうる。

方法８００のある実施形態において、タスク管理フロントエンドインタフェースは、１つまたは複数の表示可能なユーザインタフェースを含むグループウェアクライアントアプリケーション内のインタフェースである。グループウェアクライアントは、スケジューリングおよびタスク定義の一方または両方を可能とする事実上の任意グループウェアクライアントとすることが可能である。

図９は、一例の実施形態によるコンピュータ装置のブロック図である。一実施形態において、複数のそのようなコンピュータシステムは、トランザクションを基にした環境において複数のコンポーネントを実装するために分散ネットワーク内で利用される。例えば、１つのコンピュータシステムはサーバとすることが可能であり、１つまたは複数の他のコンピュータシステムはクライアントとすることが可能である。オブジェクト指向アーキテクチャは、そのような機能を実現し、複数のシステムおよびコンポーネントの間で通信するために使用することが可能である。コンピュータ９１０の形態における一例のコンピュータ装置は、処理ユニット９０２、メモリ９０４、取り外し可能な記憶装置９１２、取り外し可能でない記憶装置９１４を含みうる。メモリ９０４は、揮発性メモリ９０６および不揮発性メモリ９０８を含みうる。コンピュータ９１０は、揮発性メモリ９０６、不揮発性メモリ９０８、取り外し可能な記憶装置９１２、取り外し可能でない記憶装置９１４のような各種のコンピュータ読み取り可能な媒体を含むコンピュータ環境を含み、または、そのコンピュータ環境へのアクセスを有しうる。コンピュータ記憶装置は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、消去可能プログラム可能ＲＯＭ（ＥＰＲＯＭ）、電気的消去可能プログラム可能ＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、コンパクトディスクＲＯＭ（ＣＤ−ＲＯＭ）、ＤＶＤ（Digital Versatile Disk）、または、他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、または、他の磁気記憶装置、または、コンピュータ読み取り可能な命令を記憶することが可能な任意の他の媒体を含む。コンピュータ９１０は、入力９１６、出力９１８、通信接続９２０を含むコンピュータ環境を含み、または、そのコンピュータ環境へのアクセスを有しうる。コンピュータは、通信接続を使用してデータベースサーバのような１つまたは複数のリモートコンピュータに接続するために、ネットワーク環境内で動作することが可能である。リモートコンピュータは、パーソナルコンピュータ（ＰＣ）、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または、他の共通ネットワークノード、等を含みうる。通信接続は、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、グローバルコンピュータネットワーク、１つまたは複数の他のネットワーク、のうち１つまたは複数を含みうる。

コンピュータ読み取り可能な媒体に記憶されたコンピュータ読み取り可能な命令は、コンピュータ９１０の処理ユニット９０２によって実行可能である。ハードドライブ、ＣＤ−ＲＯＭ、ＲＡＭは、コンピュータ読み取り可能な媒体を含む物品のいくつかの例である。例えば、本発明の開示によるコンポーネントオブジェクトモデル（ＣＯＭ）を基にしたシステム内のサーバの１つにおいてデータをアクセスするために、および／または、動作を行うためにアクセス制御検査を実行する包括的な技術を提供することが可能なコンピュータプログラム９２５は、ＣＤ−ＲＯＭ上に含まれ、ＣＤ−ＲＯＭからハードドライブにロードされうる。コンピュータ読み取り可能な命令は、複数のユーザおよびサーバを有するＣＯＭを基にしたコンピュータネットワークシステム内で、コンピュータ９１０が包括的なアクセス制御を提供することを可能とする。ある実施形態において、コンピュータプログラム９２５は、グループウェアアプリケーション、および、ここで説明された方法の１つまたは複数を実現するアプリケーションを含みうる。

要約は、要約を要求する特許法の要件を満たすために提供され、技術開示の特質および要点を読者が迅速に突きとめることを可能とするものであることを強調する。これは請求項の範囲または意義を解釈または限定するために使用されないことを理解すべきである。

上述した詳細な説明において、開示を能率的にするために単一の実施形態において様々な特徴が一緒にまとめられている。この開示方法は、特許請求されている本発明の実施形態が各請求項に明示的に記載されているより多くの特徴を必要とする意図を反映するものとして解釈すべきでない。むしろ、請求項が示すように、本発明には単一の開示された実施形態の全ての特徴より少ない特徴が存在する。従って、請求項はここで詳細な説明に組み込まれ、各請求項は個々の実施形態としてそれ自身に基づく。

この技術分野の当業者は、請求項に表現された本発明の原理および範囲から逸脱することなく、本発明の特質を説明するために記載および説明された細部、素材、部分の配置、方法の段階における様々な他の変更を行うことが可能であることを容易に理解する。

一例の実施形態によるシステムの論理的なブロック図である。 一例の実施形態によるタスクモデルの論理的なデータ関係図である。 一例の実施形態による方法のブロックフロー図である。 一例の実施形態による方法のブロックフロー図である。 一例の実施形態による方法の第１部分のブロックフロー図である。 一例の実施形態による図５Ａの方法の第２部分のブロックフロー図である。 一例の実施形態による方法のブロックフロー図である。 一例の実施形態による方法のブロックフロー図である。 一例の実施形態による方法のブロックフロー図である。 一例の実施形態によるシステムのブロック図である。

符号の説明

１００ システム
１０２ クライアント層
１０４ サーバ層
１０６ パーシステンス層
１０８ タスク管理フロントエンドアプリケーション
１１０ タスクオブジェクト実行時表現
１１４ ローカルタスクモデルキャッシュ
１１６ ローカル製作物キャッシュ
１１８ タスククライアント
１２０ 製作物クライアント
１２２ ローカルタスクモデルキャッシュリポジトリ
１２４ ローカル製作物キャッシュリポジトリ
１２６ タスクモデル
１２８ タスク管理バックエンドアプリケーション
１３０ タスクウェブサービス
１３２ 製作物ウェブサービス
１３４ リポジトリマッパー
１３６ タスクリポジトリ
１３８ 製作物リポジトリ
１４０ 対応付けデータ記憶装置

Claims (28)

1. タスク管理フロントエンドインタフェースを介してタスクモデル更新要求を受信するステップと、
   前記タスクモデル更新要求をタスク管理サーバに転送するステップと、
   前記タスク管理サーバから前記タスクモデル更新要求の成功確認を受信するステップと、
   前記タスクモデル更新要求の成功確認において受信された少なくともいくつかのデータを使用して前記タスク管理フロントエンドインタフェースを更新するステップと、
   を含む方法。
2. 前記タスクモデル更新要求は、ウェブサービス呼び出しによって前記タスク管理サーバに送信される請求項１に記載の方法。
3. 前記タスク管理フロントエンドインタフェースは、１つまたは複数の表示可能なユーザインタフェースを含むグループウェアクライアントアプリケーション内のインタフェースである請求項１に記載の方法。
4. ローカルタスクモデルキャッシュ内に前記タスクモデル更新要求のタスクモデルの表現を記憶するステップをさらに含む請求項１に記載の方法。
5. 前記ローカルタスクモデルキャッシュ内に前記タスクモデルの表現を記憶するステップは、持続的なタスクモデルキャッシュリポジトリ内に前記タスクモデルの表現を記憶するステップを含む請求項４に記載の方法。
6. 第１のタスクモデルは１つまたは複数のサブタスクを含む請求項１に記載の方法。
7. 前記１つまたは複数のサブタスクの各々は、前記第１のタスクモデル内の各サブタスクのタスクモデルへの参照によって前記第１のタスクモデルに対応付けされたスタンドアロンのタスクモデルを含む請求項６に記載の方法。
8. 前記タスクモデル更新要求は製作物更新要求を含む請求項１に記載の方法。
9. 製作物は、製作物リポジトリ内に記憶され、１つまたは複数のタスクモデルと対応付けされた電子ファイルである請求項８に記載の方法。
10. 製作物の１つまたは複数のタスクモデルとの対応付けは、前記製作物の前記１つまたは複数のタスクモデルの各々への記憶されたマッピングである請求項９に記載の方法。
11. 製作物更新要求を受信し、前記タスク管理サーバに前記製作物更新要求を送信するステップと、
    前記製作物更新要求の成功確認を受信するステップと、
    前記製作物更新要求の製作物の前記タスクモデルへのマッピングを含むように前記タスク管理フロントエンドインタフェースを更新するステップと、
    をさらに含む請求項９に記載の方法。
12. タスク管理フロントエンドモジュールと、
    タスク管理バックエンドモジュールと、
    を含むシステムであって、
    前記タスク管理フロントエンドモジュールは、
    人の相互作用を可能とするユーザインタフェースクライアントと、
    前記ユーザインタフェースクライアントにタスクモデルデータサービスを提供するタスククライアントと、
    前記ユーザインタフェースクライアントに製作物データサービスを提供する製作物クライアントと、
    を含み、
    前記タスク管理バックエンドモジュールは、
    前記タスク管理フロントエンドモジュールの前記タスククライアントにタスクモデルデータサービスを提供するタスクインタフェースと、
    前記タスク管理フロントエンドモジュールの前記製作物クライアントに製作物データサービスを提供する製作物インタフェースと、
    製作物のタスクモデルへのマッピングに関する製作物マッピングサービスを提供するタスク−製作物マッピングインタフェースと、
    を含むシステム。
13. タスクモデルを記憶するタスクモデルリポジトリと、
    製作物データを記憶する製作物リポジトリと、
    前記製作物リポジトリ内に記憶された製作物の、前記タスクモデルリポジトリ内に記憶されたタスクモデルへの対応付けを記憶するタスク−製作物マッピングリポジトリと、
    をさらに含む請求項１２に記載のシステム。
14. 前記タスクインタフェースは、前記タスククライアントからの要求に応答して、前記タスクリポジトリにタスクモデルを記憶させ、前記タスクリポジトリからタスクモデルを検索する動作が可能であり、
    前記製作物インタフェースは、前記製作物クライアントからの要求に応答して、前記製作物リポジトリに製作物を記憶させ、前記製作物リポジトリから製作物を検索する動作が可能である請求項１３に記載のシステム。
15. 前記タスク管理フロントエンドモジュールは、
    前記タスク管理バックエンドモジュールの前記タスクインタフェースから検索したタスクモデルを記憶するローカルタスクモデルキャッシュと、
    前記タスク管理バックエンドモジュールの前記製作物インタフェースから検索した製作物を記憶するローカル製作物キャッシュと、
    をさらに含む請求項１２に記載のシステム。
16. 前記ローカルタスクモデルキャッシュおよび前記ローカル製作物キャッシュの一方または両方は、不揮発性メモリ装置に配置される請求項１５に記載のシステム。
17. 前記タスクインタフェース、前記製作物インタフェース、前記タスク−製作物マッピングインタフェースのうち１つまたは複数は、ネットワーク上で前記タスク管理フロントエンドモジュールに利用可能なウェブサービスである請求項１２に記載のシステム。
18. 前記タスク管理フロントエンドモジュールはグループウェアクライアントのアドオンである請求項１２に記載のシステム。
19. 前記グループウェアクライアントは、マイクロソフト（登録商標）アウトルックを含む請求項１８に記載のシステム。
20. 符号化された命令を有するコンピュータ読み取り可能な媒体であって、
    適切に構成されたコンピュータ装置によって実行されるとき前記コンピュータ装置に、
    タスクモデルを表示する要求を受信する処理と、
    前記タスクモデルがタスクモデルキャッシュ内にローカルに記憶されていないならば、前記要求されたタスクモデルを検索する処理と、
    前記タスクモデルを表示する処理と、
    を実行させるコンピュータ読み取り可能な媒体。
21. 適切に構成されたコンピュータ装置によって実行されるとき前記コンピュータ装置に、
    タスクモデルと対応付けされた１つまたは複数の製作物のリストを表示する処理と、
    前記タスクモデルと対応付けされた１つまたは複数の製作物のうち少なくとも１つの選択を受信する処理と、
    それぞれの製作物が製作物キャッシュ内にローカルに記憶されていないならば、１つまたは複数の要求された製作物の各々を検索する処理と、
    前記１つまたは複数の選択された製作物を表示する処理と、
    をさらに実行させる命令をさらに含む請求項２０に記載のコンピュータ読み取り可能な媒体。
22. タスクモデルと対応付けされた１つまたは複数の製作物のリストを表示する命令は、前記コンピュータ装置に、
    前記タスクモデルにマッピングされた１つまたは複数の製作物のリストを検索する処理を実行させる命令を含む請求項２１に記載のコンピュータ読み取り可能な媒体。
23. 前記要求されたタスクモデルを検索する処理は、ウェブサービスを利用して前記要求されたタスクモデルを検索する処理を含む請求項２０に記載のコンピュータ読み取り可能な媒体。
24. 前記タスクモデルを表示する要求はグループウェアクライアントアプリケーション内で受信され、
    前記タスクモデルは前記グループウェアクライアントアプリケーション内で表示される請求項２０に記載のコンピュータ読み取り可能な媒体。
25. タスクの表現を保持するデータ構造であって、
    ユニークなタスクの識別子を保持するタスク識別子と、
    前記タスクの記述を保持するタスク記述と、
    タスクが割り当てられるエンティティを表現するデータを保持するフィールドへの割り当てと、
    前記タスクのサブタスクとして指定されたゼロから多数の他のタスクのタスク識別子と、
    を含むデータ構造。
26. 前記タスクと対応付けされた１つまたは複数の製作物をさらに含む請求項２５に記載のデータ構造。
27. 少なくとも１つの製作物はテキスト文書である請求項２６に記載のデータ構造。
28. 前記データ構造はデータベーステーブルの１レコードである請求項２５に記載のデータ構造。