JP2004501436A - ウェブサイト開発及び維持のためのワークフロープロセスを遂行する方法 - Google Patents

Abstract

ウェブサイト開発及び維持（１０４）のためのワークフロープロセスを遂行する方法が提供される。ウェブサイトの開発及び維持は、複数の個人（１０２）の協働した努力を含む。仕事が予想可能で且つ整然とした形態で進行するように、ワークフローに基づいてタスクが指定されそして実行される。ワークフローは、シリアルな順序、互いにパラレル、又はシリアルとパラレルの組み合わせである。特定のワークフローを遂行するために、本発明は、ワークフローに基づいて仕事を強制的に進行させる環境を提供する。「ウェブマスター」のような監督者（１２０）は、ユーザ（又は貢献者）の努力をいかに進行させるべきか指示するワークフローファイルを開発する。従って、ウェブマスターは、ウェブサイトを開発して更新するプロセスに対して高い制御性を有する。その結果、多数の個人がその努力に含まれる場合でもウェブサイトの開発は効率的に進行する（１２４）。

Description

【０００１】
【関連出願】
本出願は、１９９９年１１月２９日に出願された米国プロビジョナル特許出願第６０／１６８，１５６号の優先権を請求する。本出願は、１９９９年２月３日に出願された米国特許出願第０９／２４４，３３３号の一部継続出願である。
【技術分野】
本発明は、ウェブサイト開発及び維持の分野に係る。より詳細には、本発明は、ウェブサイト開発及び維持に使用されるプロセスの制御及び管理に係る。
【０００２】
【背景技術】
インターネットは、商取引において大きな役割を演じ、そしてほとんどの会社は、ウェブサイトをもつ傾向にある。多数の貢献者の努力を整合する必要があるために大きなウェブサイトを開発するためのチャレンジがしばしばなされている。更に、多数のウェブサイトをしばしば変更する必要があり、そして貢献者は、通常、それを特別なプロセスで変更する。その結果、ウェブサイトのコンテンツを最新で、正確で且つ良好に一体化された状態に保つ進行中プロセスがしばしば大きなチャレンジとなる。インターネットサイトは、数百に達するチームにより、日、時又は分で更新される。同様に、イントラネットコンテンツの貢献者は、常に新たなコンテンツを提示するか又は既存のコンテンツに変更を行い、そして新たなコンテンツが迅速且つ正確に一体化されない限り、基本的な通信リソースとしてのイントラネットの有用性が制限される。
【０００３】
大きなウェブサイトは、ウェブ貢献者の数が指数関数的に増加するにつれて、多数の問題に直面する。これらサイトの量及びコンテンツは、急速に増加しており、従って、サイトのトラフィック及びインターネット商取引が成長するにつれて、サイトをより頻繁に更新しなければならない。貢献者の数、コンテンツの量及び複雑さが増すにつれて、ウェブサイトのマネージャー（ウェブマスター）が各々の変更を監督しそして品質制御を行うことが益々困難になってきている。
ウェブサイトの開発は複雑であるために、中央システムがウェブサイトの開発を管理しそして制御する必要がある。ウェブサイトの開発を管理しそして制御するための既知のシステムは、ソフトウェアコンフィギュレーションマネージメントシステム、ドキュメントマネージメントシステム、及びデータベースパブリッシングシステムを含む。
【０００４】
このような既知のウェブサイト開発システムに関連して多数の欠点がある。例えば、ウェブサイトを維持するのに数十又は数百人の人々の努力がしばしば必要であるから、ウェブサイト貢献者を並列に作業させることが望ましい。ソフトウェアコンフィギュレーションマネージメントシステムは、貢献者がウェブサイトの同じエリアに同時に変更を行うのを許さない。更に、既知のシステムは、いずれも、並列に作業する貢献者が、ウェブサイトへの変更を実際に行わずにそれら自身の仕事を個別にテストするのを許さない。従って、矛盾するような変更がウェブサイトに送られて、ウェブサイトを崩壊することがある。
【０００５】
貢献者は、他の貢献者と結合されたときにそれらの仕事の影響を個々のレベルで予見できないので、既知のシステムは、ウェブマスターがウェブサイトに送られた全ての変更を一体化しそしてそれらの変更をエラーについてチェックすることに依存している。しかしながら、ウェブマスターは、しばしば、ウェブサイト開発プロセスのボトルネックとなる。というのは、ウェブマスターは、ウェブサイトへの変更の全ての一体化及びテストを行わねばならないからである。多数のユーザの仕事を一体化することは、手で行われそして時間がかかり、バグの固定及び矛盾の分析に多大な時間が浪費され、一方、設計、革新及び戦略にはほとんど時間が費やされない。更に、ウェブマスターは、貢献者がウェブマスターに変更を提示する準備ができるまで、変更に対する貢献者の進行状態を容易に予見できない。従って、ウェブマスターは、エラーを早期に修正することができず、そして貢献者がどれほど進行しているか決定することができない。
【０００６】
既知のウェブサイト開発システムの別の欠点は、ウェブマスターが、ウェブサイトの更新に含まれる仕事がいかに進行すべきかを前もって決定し、そしてプランに基づいて仕事を進行させるメカニズムを備えるのを許さないことである。このようなプランニング機能がないと、ウェブマスターは、貢献者の努力に対して制限された制御しか行えず、その結果、低い効率となり、そして貢献者が変更を提示するときに多数の変更を行う必要が生じる。例えば、ウェブサイトの開発又は維持に関する多数の異なるタスクが、異なるワークステーションに各々存在する異なる個人に割り当てられた場合には、それらが組織化されて整合された場合にそれらの努力が最も効率的となる。
それ故、ウェブサイトの開発及び維持を組織化するための技術が要望される。より詳細には、監督者が多数のウェブサイト開発者の努力を制御できるような技術が要望される。
【０００７】
【発明の開示】
本発明は、ウェブサイト開発及び維持のためのワークフロープロセスを遂行する方法を提供する。ウェブサイト開発及び維持は、複数の個人の協働した努力を含む。従って、仕事が予想可能で且つ整然とした形態で進行するように、ワークフロー（ここではジョブとも称する）に従ってタスクが指定されて実行される。ワークフロー（即ち、ジョブ）は、実行されるべきタスクの構成体である。この構成体は、シリアルな順序、互いにパラレル、又はシリアルとパラレルの組合せで実行されるタスクを含む。特定のワークフローを実施するために、本発明は、ワークフローに基づいて仕事を強制的に進行させる環境を提供する。
【０００８】
各個人は、対応するワークエリアにおいて指定のタスクを実行することによりウェブサイトへ貢献することができる。各タスクは、特定のファイル（１つ又は複数）に含まれたデータに追加、削除又は修正のような変更を行うことを含む。従って、タスクは、既存のファイルを変更することを含むが、新たなファイルを生成することを含んでもよい。ワークエリアは、通常、中央サーバーに存在する。しかしながら、分散型処理環境では、ワークエリアは、指定されたメモリスペースを例えばワークステーションに含む。
【０００９】
タスクが完了すると、それにより生じるファイル（１つ又は複数）に対して更なる仕事が行われる前に、その遂行された仕事の承認が１つ以上のエンティティにより要求される。その仕事が拒絶された場合には、更なる変更のためにファイルが返送される。例えば、タスクは、新たなマーケット情報を反映するようにウェブサイトのページを更新することを含む。仕事は、会社の情報システム部門にいるウェブプログラマーのような第１の個人によって行うことができる。新たなマーケット情報がウェブサイトに一体化されるように得られたファイルを配備する前に、その仕事の再調査及び承認が要求される。完了した仕事の再調査及び承認は、会社のマーケッティング部門の代表者のような第２の個人によって行われる。
「ウェブマスター」のような監督者は、ユーザ（又は貢献者）の努力をいかに進行させるべきかを指示するワークフローファイルを開発する。従って、ウェブマスターは、ウェブサイトを開発しそして更新するプロセスに対し高い制御権を有する。その結果、ウェブサイト開発は、多数の個人がその努力に含まれる場合でも効率的に進行する。
【００１０】
【発明を実施するための最良の形態】
図１は、ウェブサイト開発のためのコンピュータネットワークシステム１００を示す。開発ワークステーション１０２において、ウェブサイト開発者は、ウェブサイトのためのファイルを追加、除去、編集及び検査することができる。開発ワークステーション１０２は、従来のパーソナルコンピュータ、ＵＮＩＸ（登録商標）ワークステーション、又はコンテンツを開発するよう構成できる他のワークステーションを含むことができる。開発ワークステーション１０２は、インターネット又はローカルエリアネットワーク（ＬＡＮ）のようなコンピュータネットワーク１０６を経て開発サーバー１０４に接続される。
開発サーバー１０４は、ウェブブラウザへコンテンツを供給するためのウェブサーバー１０８と、ウェブサイトコンテンツのバージョンを記憶するためのバックアップ記憶装置１１０とを備えている。サーバー１０８は、ウェブサイトコンテンツ（例えば、ファイル）に対する開発ステーション１０２からのハイパーテキスト転送プロトコル（ＨＴＴＰ）要求を処理する。ウェブサイトファイルは、例えば、マイクロソフトコーポレーションから商業的に入手できるＷｉｎｄｏｗｓ（登録商標）　ＮＴファイルシステムのような従来型のバックアップ記憶装置１１０に物理的に記憶される。
【００１１】
又、開発サーバー１０４は、従来型メモリ１１２（例えばＲＡＭ）及び従来型プロセッサ１１４も備え、これは、メモリ１１２に記憶されたソフトウェア１１６を実行することにより本発明のウェブサイト開発方法を実施する。ウェブサーバー１０８が多数のサーバーであるかのように動作するのを許すためにプロセッサ１１４が実行するＨＴＴＰプロトコル視覚化モジュール１１８も、メモリ１１２に記憶することができる。
開発サーバー１０４は、ネットワーク１２２を経てウェブサイト生成ウェブサーバー１２０に接続される。ネットワーク１２２は、ネットワーク１０６と同じネットワークでもよいし、又は異なるネットワークでもよい。ウェブサーバー１２０は、インターネット又はイントラネット１２４にも接続される。ウェブサイトがワールドワイドウェブ又はイントラネットに送られる準備ができると、開発サーバー１０４は、ウェブサイトのコンテンツを生成ウェブサーバー１２０へ送信し、該サーバー１２０は、次いで、ウェブサイトへのインターネット又はイントラネットアクセスを与える。
【００１２】
ウェブサイトは、一般に、任意のファイルシステムのコンテンツで構成される。本発明のウェブサイト開発システム１００は、ハイアラーキー型ファイルシステムを備えている。本発明のこのようなファイルシステムは、個々のファイルを管理及び操作するための環境を与える。ファイルシステムのウェブサイト開発ソフトウェア１１６の部分は、実行時に、ファイルを管理及び操作できるようにする。バックアップ記憶装置１１０には、ファイル及びそれに対応するメタデータ（例えば、所有者の識別、グループ識別、アクセス制御、ファイル名、変更時刻、生成時刻、等）が物理的に記憶される。
本発明のハイアラーキー型ファイルシステムは、「エリア」と称される。ワークエリア、ステージエリア及び編集エリアを含む種々の形式のエリアがある。ワークエリアは、通常、ウェブサイトに最終的に使用されるウェブコンテンツを生成しそして維持する個人により使用される変更可能なファイルシステムである。
【００１３】
ステージエリアは、通常、コンテンツが公表される前にそれが組み立てられるエリアである。ワークエリアは、一般に、コンテンツを排他的に生成しそして維持するためのエリアであるから、ステージエリア（及び編集エリア）は、コンテンツの組み立て及び表示のみに制限される。設計により、ステージエリア及び編集エリアは、読み出し専用のファイルシステムとして構成することができる。コンテンツに対する変更は、編集者からワークステーションへ送信され、必要な変更が行われる。従って、コンテンツを変更するタスクは、ステージ又は編集エリアのコンテンツを参照するが、変更は実際にはワークエリアで行われる。これは、コンテンツの完全性を維持しそしてプロセスを簡単化する上で助けとなる。しかしながら、業務上、システム１００により柔軟性があって、編集者のような他の人々がコンテンツを公表の前に直接変更できるようにすることが望まれる。従って、ステージ及び編集エリアは、変更可能なファイルシステムとして構成することができる。従って、このような実施形態では、ワークエリアから提出されるコンテンツがステージエリア又は編集エリアにおいて編集される。
【００１４】
ワークエリアは、最初に、全ウェブサイトの仮想コピーを含む（既存のウェブサイトがない場合を除いて。その場合には、ワークエリアは空である）。換言すれば、ワークエリアは、最初に、ウェブサイトとして設計されたファイルシステムと同じコンテンツを有する。ワークエリアは、開発者がウェブサイトに貢献するところの開発者個人のウェブサイトビューを与える。例えば、ワークエリアでは、開発者は、ウェブサイトのコンテンツを自由に追加、削除及び修正し、そしてそれらの変更が全ウェブサイトのコンテキストにいかに適合するか見ることができる。ワークエリアにおいて開発者によりなされる変更は、他のワークエリアにおける他の貢献者の仕事又はウェブサイトに影響しないのが好ましい。このため、各ワークエリアは、個別のファイルシステムである。通常、ワークエリアは、ワークステーション１０２に配置される。
【００１５】
開発者は、それらのワークエリアのコンテンツをステージエリアへ提出することによりステージエリアにおいてそれらの仕事を一体化することができる。ステージエリアは、多数の開発者に使用できてウェブサイトの共有ビューを与えるファイルシステムである。従って、ステージエリアは、多数の開発者のワークエリアの集合的な仕事を保持し、開発者がそれらの変更を分担及び一体化できるようにする。ステージエリアでは、開発者は、それらの変更が互いにいかに適合するか見ることができる。ステージエリアは、通常、開発サーバー１０４に配置される。
コピーは、「仮想」であると言われ、エリアがディレクトリツリーを共有し、ディレクトリツリーを物理的にコピーする必要がない。ステージエリアにおける集合的な仕事は、異なる貢献者がワークエリアから新たなコンテンツを提出するときに変化する。ワークエリアは、ステージエリアにおけるコンテンツ及び他の情報が１つ以上のプライベートワークエリアに仮想的にコピーされて戻されるときに最も効果的である。これは、貢献者が、コンテンツを生成しそして維持するようなウェブサイト関連タスクを実行する間に、個々のワークエリアをステージエリアに対して最新の状態に維持する助けをする。
【００１６】
ステージエリアにおける集合的な仕事が終了したと思われるときに、そのコンテンツを公表してウェブサイトの編集を生成することができる。これは、ステージエリアのコンテンツを編集エリアに仮想的にコピーすることにより達成される。編集は、通常、読み出し専用のファイルシステムであるので、これは、全ウェブサイトのコンテンツの凍結スナップショットである。ウェブサイトの開発において逐次のポイントで行われる各編集は、記録保管され、そして全ての開発者にアクセスすることができ、従って、開発者は、ファイル、全ディレクトリを瞬時に呼び出し、又はウェブサイトの過去の全バージョンを再構成することができる。例えば、編集のコンテンツは、ワークエリアに仮想的にコピーされ、ウェブサイトの更なる開発のための基礎として使用することができる。編集エリアは、通常、開発サーバー１０４に配置される。開発サーバー１０４のコンテンツ（例えば、編集）は、生成サーバー１２０へ配備される。
【００１７】
ウェブサイトの開発及び維持作業が予想可能な整然とした形態で進行するように、ワークフローコンフィギュレーション（ここでは、ジョブとも称される）に基づいてタスクが割り当てられて実行される。ワークフロー（即ちジョブ）は、実行されるべきタスクの構成体である。この構成体は、シリアルな順序、互いにパラレル、又はシリアルとパラレルの組合せで実行されるタスクを含む。本発明は、ワークフローに基づいて仕事を強制的に進行させる環境を提供する。
ワークフローモデルは、繰り返し使用することのできる一般的なワークフローコンフィギュレーションである。各ワークフローモデルは、ユーザタスク及び種々様々な自動化タスクを含むことのできるプロセスを記述する。ワークフローモデルは、通常、業務管理者により設計され、そしてシステム監督者により構成される。
【００１８】
システム１００の２つの要素は、本発明に基づいてワークフロー技術を実施することができる。第１に、ウェブサイト生成を制御するためのフレームワークを与えるサーバー側サブシステム（「ワークフローサブシステム」とも称される）は、開発サーバーソフトウェア１１２に含まれる。第２に、クライアント側ユーザインターフェイスは、ワークステーション１０２に与えられる。例えば、クライアント側ユーザインターフェイスは、開発者がデータを入力して特定のワークフローアクションを制御できるようにする。クライアント側ユーザインターフェイスは、通常、ＨＴＭＬで書かれそしてパール（Ｐｅｒｌ）スクリプトの付いたウェブブラウザのようなウェブベースの共通ゲートウェイインターフェイス（ＣＧＩ）である。
図２は、簡単な指定−編集−承認ワークフローモデル２００を示す。Ｅメールは、プロセスの各段階において参加者（例えば、著者及び編集者の役割を果たす開発者）へ送信され、そしてその終りに自動化タスクが実行される。
【００１９】
１組の相互依存性タスクを「ジョブ」と称する。ジョブの一例は、新製品の着手をサポートするためにマーケッティングウェブサイトにおいて新たなセクションを準備するのに必要な１組のタスクである。ワークフローモデルの記述は、「ジョブ仕様」とも称される。ジョブ仕様ファイルは、単一のジョブを記述し、そしてメモリ１１２（図１）に記憶される。ジョブ仕様ファイルは、ジョブパラメータの制御を与えるエレメント定義を各々含むセクションのハイアラーキーとして構成されるのが好ましい。最初の「＜ワークフロー＞」セクションは、ジョブの全特徴を定義する。これは、ジョブの名前、所有者、創作者、及びそのジョブが何を行うかの記述を含む。
タスクとは、単一のユーザ又はプロセスにより実行される仕事の単位である。ジョブにおける各タスクは、特定のエリア（例えばワークエリア）に関連され、そして１組のファイルを保持する。タスクを所有するユーザ又はプロセスは、タスクを変更し、そこにファイルを追加し、又はそこからファイルを除去することができる（タスクが、例えば、コンテンツ承認の場合の読み出し専用タスクでなければ）。
【００２０】
ジョブの一部分として生じる特定のタスクを記述する１つ以上のタスクセクションは、ジョブ仕様ファイルの初期＜ワークフロー＞セクションに従う。ジョブ仕様においてセクションを定義できるエレメントの例示的リストは、次の通りである。＜ｕｓｅｒｔａｓｋ＞、＜ｕｐｄａｔｅｔａｓｋ＞、＜ｓｕｂｍｉｔｔａｓｋ＞、＜ｅｘｔｅｒｎａｌｔａｓｋ＞、＜ｅｎｄｔａｓｋ＞、＜ｇｒｏｕｐｔａｓｋ＞及び＜ｃｇｉｔａｓｋ＞。これらタスクエレメントの各々は、タスクを完了する責任のあるユーザであるタスクの所有者と、ジョブ内のタスクを独特に識別するタスクの名前と、タスクを含むジョブを呼び出す際にタスクがアクティブでなければならないかどうか指定するスタート属性と、タスクが何を行うかの記述と、タスクがアクティブになったときにその関連ファイルに対するロックを得るように試みる（これは、別のタスクがファイルを変更しようとした場合に生じる矛盾を防止する）かどうか指定するロック属性と、ユーザがファイルを追加、除去又は修正するのを制限する読み出し専用属性と、タスクを実行すべきエリアを識別するエリア経路と、タスクを完了するための時間切れ限界（例えば、これを越えると、タスクがデアクチベートされ、そして次のタスクエレメントがアクチベートされる）と、タスクにより影響されるファイルの識別と、タスクをいつアクティブにすべきか（手前のタスクによりシグナリングされるとき）の指示と、タスクをいつインアクティブにすべきか（一般に、各タスクは、次のタスクをシグナリングするときにインアクティブとなるが、多数の再調査者の１人が完了したタスクを拒絶して、他の再調査者が不必要にそれを再調査するのを防止するときのように、他の環境のもとでインアクチベートするのにも必要である）の指示と、タスクをアクチベートする際にリセットされるべき他のタスクの指示（リセット時に、これらのタスクは、別のタスクによってアクチベートされなかった状態にセットされる）と、タスクのアクチベート又はデアクチベートの際に、セット、変更又は削除されるべきタスクに関連したファイルの拡張属性の指示とを含む。
【００２１】
上記に加えて、＜ｕｓｅｒｔａｓｋ＞エレメントは、特定のユーザのタスクリストに現れるユーザタスクを定義することもできる。＜ｕｓｅｒｔａｓｋ＞のサブエレメントは、タスクが完了したときにそれを信号するために、考えられる別の組の後継タスクを特定する（例えば、マーク「ｄｏｎｅ」、拒絶、承認）。＜ｇｒｏｕｐｔａｓｋ＞エレメントは、特定のユーザグループのタスクリストに現れるユーザタスクを定義する。＜ｇｒｏｕｐｔａｓｋ＞のサブエレメントは、グループタスクを分担する任意の１組のユーザを特定する。＜ｅｘｔｅｒｎａｌｔａｓｋ＞エレメントは、それがアクティブになったときに実行されるべき外部プログラムと、タスクと外部プログラムとの間に通過されるべきアーギュメントとを指定する。ワークフローサブシステムは、外部プログラムが完了したときに通知されるのが好ましい。＜ｓｕｂｍｉｔｔａｓｋ＞エレメントは、その含まれたファイルに対し（ステージエリアへの）提出オペレーションを実行する。成功の場合には、指定の後継タスクがシグナリングされる。成功でない場合には、ユーザは、何らかの矛盾を分析するように通知される。＜ｕｐｄａｔｅｔａｓｋ＞エレメントは、その関連ファイルの最新のバージョンを得ることができる（例えば、ステージエリア又は別のワークステーションから）。＜ｅｎｄｔａｓｋ＞エレメントは、ジョブの終りを指示する。＜ｅｎｄｔａｓｋ＞エレメントがアクティブになると、それを含むジョブが終りとなり、ジョブにより保持された全てのロックが解除される。＜ｃｇｉｔａｓｋ＞エレメントは、外部タスクに非常によく似た振舞いをするが、特定の外部プログラムを実行するものではなく、むしろ、ユーザがユーザインターフェイスを経てプログラムを実行することに依存する。従って、＜ｅｘｔｅｒｎａｌｔａｓｋ＞と同様に、指定の外部プログラムが完了したときにワークフローサブシステムにそれが通知されるのが好ましい。
【００２２】
ジョブ生成は、一般に、２段階プロセスである。第１段階は、例えば、ジョブ仕様をワークフローサブシステムにロードすることによりそれをアクチベートすることである。従って、ジョブ仕様は、「ジョブインスタンス」であると言える。しかしながら、ジョブは、それが呼び出されるまではアクティブでないのが好ましい。従って、第２段階は、ジョブをアクチベートすることである。各ジョブは、ワークフローモデルの特定のインスタンスである。ジョブが生成されるときには、ジョブ生成者は、そのジョブに対する全ての特定情報を供給しなければならない。例えば、図２のワークフローモデルは、図３に示すジョブインスタンス３００を生成するように使用される。
ジョブは、その生成時に、所定のワークフローモデルに従う。それ故、タスクを一般に個々のジョブに追加したり又はそこから除去したりすることができない。しかしながら、ジョブ生成時に指定された場合には、ジョブのある属性、例えば、その所有者を、ユーザ又はシステム監督者によって変更することができる。ジョブを指定しそしてそれらを変更するユーザの能力を限定することにより、ウェブサイト監督者は、ウェブサイトの開発を制御し、そしてワークフローモデル及びジョブ仕様によりプロセスを維持する。
【００２３】
タスクは、２つの考えられる状態、即ちアクティブと、インアクティブとを有するのが好ましい。タスクは、先行タスクがそれを行うと信号するときにアクティブとなり、即ち先行タスク及びアクチベーションの条件は、ワークフローモデルの一部分として構成することができる。タスクがアクチベートされた後、ユーザ又は外部プログラムがそれに対して作業を行うことができる。例えば、ユーザタスクがアクチベートされた後に、ユーザは、そのタスクに含まれたファイルに対して作業することができる。外部タスクがアクチベートされた後に、そのタスクに含まれたファイルに対して適当な外部プログラムを実行することができる。インアクティブなタスクは、完了したタスク又はまだアクチベートされていないタスクである。又、タスクは、読み出し専用又は編集可能として設計することもできる。読み出し専用タスクは、ユーザが、ファイルを編集、削除、タスクに追加又はタスクから除去できるようにせずに、コンテンツを承認及びコメントできるようにする。
【００２４】
ジョブは、２つの方法の一方で生成するのが好ましい。第１に、単一ジョブを定義するジョブ仕様ファイル（例えば、拡張可能なマークアップ言語（ＸＭＬ）ファイル）は、直接編集することができる。或いは又、ワークフローテンプレートファイル（例えば、ＸＭＬファイル）に定義されたワークフロールールと、ブラウザインターフェイスからのエンドユーザ入力との結合によってジョブを生成することもできる。この第２の技術では、どんな入力が与えられるかに基づいて相違する多数のジョブを定義するために、単一ワークフローテンプレートファイルを生成することができる。テンプレート及びユーザ入力（例えば、ウェブサイト監督者からの）のワークフロールールは、共通のゲートウェイインターフェイス（ＣＧＩ）によりジョブ仕様ファイルを動的に生成するように解釈される。これは、上述した「手動」直接編集技術を使用して生成される同じ形式のファイルである。いったん構成されると、この技術は、ジョブを定義するプロセスを簡単化する。というのは、これは、ユーザ入力に対するブラウザインターフェイスを与え、そしてユーザ入力の各個別のセットに対して個別のジョブ仕様ファイルを自動的に発生するからである。
【００２５】
ジョブ仕様ファイルを直接編集して単一ジョブを定義するときには、開発サーバー１０４に配置されたディレクトリにファイルが存在する。ジョブ仕様が生成されると、そのインスタンスをサーバー１０４において生成することができる（インスタンス生成）。単一ジョブ仕様の多数のインスタンス生成を行うことができる。ジョブの各インスタンスは、終了状態に到達するまでサーバー１０４において実行される。ジョブを再び実行するために、同じジョブ仕様を再結合して、新たなジョブインスタンスを生成することができる。次いで、新たなジョブインスタンスを呼び出すことができる。
【００２６】
ジョブを生成するワークフローテンプレートを設定するために、次の５つの主要素が使用される。
（１）ワークフローテンプレートファイルそれ自体。これは、１組のワークフローマークアップ及び１組の一般的コンフィギュレーション命令によりワークフロールールを定義する。
（２）インスタンチエーターＣＧＩ。これは、ワークフロールール及びユーザからのデータを解釈し、ブラウザグラフィック及びプロンプトを形成し、ジョブ仕様を発生し、そしてジョブをインスタンス生成する。
（３）ブラウザベースのグラフィックユーザインターフェイス（ＧＵＩ）。
（４）インスタンチエーターＣＧＩにより発生できるジョブ使用ファイル。
（５）サーバー側のワークフローサブシステム。
【００２７】
図４は、これらの要素と、それらがどのように一緒に作用するかを示す。インスタンチエーターＣＧＩ４０２は、一般に、ワークフローテンプレートファイル４０４における情報に基づいてワークフロー情報フォームを生成しそして表示する。更に、インスタンチエーターＣＧＩ４０２は、ワークフローテンプレートファイル４０４におけるワークフロールールに基づいてユーザにより入力されたデータを評価し、そのユーザ入力データを一般的なワークフローコンフィグレーション命令と結合してジョブ使用を生成し、開発サーバー１０４（図１）においてジョブ仕様をインスタンス生成し、そしてジョブをスタートする（呼び出す）。インスタンチエーターＣＧＩ４０２は、好ましくはサーバー１０４にある実行可能なファイルである。ユーザは、ブラウザインターフェイスＧＵＩ４０６を使用してワークフローフォームにデータを入力する。
【００２８】
ブラウザインターフェイスＧＵＩ４０６では、ユーザが、例えば、「Ｆｉｌｅ＞Ｎｅｗ Ｆｉｌｅ」、「Ｆｉｌｅ＞Ｅｄｉｔ Ｆｉｌｅ」、又は「Ｆｉｌｅ＞Ｃｒｅａｔｅ Ｎｅｗ Ｊｏｂ」メニュー項目からワークフローテンプレートを選択する。これは、図４に矢印４０８で示されている。インスタンチエーターＣＧＩ４０２は、特定のワークフローテンプレートファイル４０４へ進み、そしてワークフローマークアップを読み取り、これは、ワークフローテンプレートファイルのテンプレートスクリプトエレメント（「＜ｔｅｍｐｌａｔｅ＿ｓｃｒｉｐｔ＞」エレメントとも称する）に存在するパール命令より成る。これは、図４に矢印４１０で示されている。
【００２９】
ワークフローマークアップに基づいて、インスタンチエーターＣＧＩ４０２は、１つ以上のワークフローフォームを生成し、ユーザは、ブラウザ４０６を経てワークフローコンフィギュレーション情報をこれに入力することができる。これは、図４に矢印４１２で示されている。ＧＵＩ４０６を経て作業するユーザは、ワークフローフォームを満たし、そしてそれをインスタンチエーターＣＧＩ４０２へ返送する。これは、図４に矢印４１４で示されている。
インスタンチエーターＣＧＩ４０２は、ワークフローテンプレートファイル４０４のワークフローマークアップにおけるルールを調べて、ユーザにより入力されたデータの有効性を照合する。これは、図４に矢印４１２で示されている。データが必要な全ての基準を満足する場合には、それがインスタンチエーターＣＧＩ４０２によりパーズされる。データが全ての必要な基準を満足しない場合には、インターフェイス４０６は、データを再入力できるように再びユーザを促す。
【００３０】
ワークフローフォームが有効なデータを含むと決定した後に、インスタンチエーターＣＧＩ４０２は、データをワークフローテンプレートファイル４０４からの一般的な命令と結合し、特定ジョブに対するジョブ仕様４１８（及び任意であるがジョブ仕様ファイル）を生成する。これは、図４に矢印４２０で示されている。ジョブ仕様が生成される場合には、上述した手動の直接編集技術を使用して生成されたファイルと同等である。このジョブは、サーバー１０４（図１）へとインスタンス生成され、そしてサーバー側のワークフローサブシステム４２２においてスタートされる。これは、図４に矢印４２４で示されている。これらのアクションは、手動の直接編集技術を使用する場合には、手動で行われる。
【００３１】
ジョブ仕様が生成されない（典型的なケース）ときには、インスタンチエーターＣＧＩ４０２は、ジョブ仕様ファイルをディスクに書き込み、そしてジョブインスタンスを生成して呼び出すための命令を呼び出すという同等の機能を実行する。
ワークフローテンプレートファイル４０４は、ジョブ仕様ファイルにおいて有効であるエレメントのいずれか又は全部を含むＸＭＬファイルであるのが好ましい。これらのエレメントは、図４に示す１組の一般的なワークフローコンフィギュレーション命令を形成する。更に、ワークフローテンプレートファイル４０４は、図４に示すワークフローマークアップを定義するための１組のディレクティブを含む＜ｔｅｍｐｌｅｔｅ＿ｓｃｒｉｐｔ＞エレメントを含むことができる。
【００３２】
＜ｔｅｍｐｌｅｔｅ＿ｓｃｒｉｐｔ＞ファイル内に存在する全ての命令は、インスタンチエーターＣＧＩ４０２によりパール（Ｐｅｒｌ）コードとして解釈される。テンプレートファイルは、有効なＸＭＬ文書でなければならないので、＜ｔｅｍｐｌｅｔｅ＿ｓｃｒｉｐｔ＞エレメント内の全てのコンテンツは、ＸＭＬパーザーによる解釈からそれを保護するためにＣＤＡＴＡとして宣言されねばならない。ワークフローテンプレートファイルにおける全ての＜ｔｅｍｐｌｅｔｅ＿ｓｃｒｉｐｔ＞エレメントが一緒に単一のパールプログラムを形成してもよい。ワークフローテンプレートファイルが２つ以上の＜ｔｅｍｐｌｅｔｅ＿ｓｃｒｉｐｔ＞エレメントを含む場合には、１つのエレメントにおける全ての変数、関数及びライブラリーセットが他のエレメントにも得られるのが好ましい。
【００３３】
各＜ｔｅｍｐｌｅｔｅ＿ｓｃｒｉｐｔ＞エレメントは、次のことを行える任意のパールコードを含むのが好ましい。即ち、ユーザが入力したデータを、ワークフローテンプレートファイルからのハードコード化ワークフローＸＭＬ及び／又は＜ｔｅｍｐｌｅｔｅ＿ｓｃｒｉｐｔ＞エレメント内に形成されたプログラムで発生されたワークフローＸＭＬと結合するためにインスタンチエーターＣＧＩ４０２が使用するルールを定義し、ジョブ仕様をプログラムで発生し（及び／又はハードコード化ＸＭＬジョブ仕様情報を、プログラムで発生したＸＭＬと共に散在させ）、ジョブ仕様を、ワークフローサブシステムにインスタンス生成するのに加えて又はそれに代わって、ファイルへ任意に送信し（これは、どんなＸＭＬが形成されるかを正確に決定するのに役立つ）、ユーザが入力したデータを妥当性検査するルールを定義し、データの妥当性検査ルールを満足しないときに表示されるべき顧客エラーメッセージを定義し、到来するデータを検査しそしてこのデータに基づいてコード化ルールを実行し（例えば、著者の名前が「Ａｎｄｒｅ」であるときには、３つの承認が必要となるが、著者の名前が「Ｊｏｎ」であるときには、１つの承認しか必要でない）、到来するデータを、ワークフローテンプレートファイルからのハードコード化ワークフローＸＭＬと合併し、そしてワークフローフォームの「ルック・アンド・フィール」を決定する。
【００３４】
従って、ディレクティブは、インスタンチエーターＣＧＩ４０２により発生されたワークフローフォームの「ルック・アンド・フィール」を制御し、ワークフローフォームに表示されるデータ収集、妥当性検査及びエラーメッセージを制御し、タグにおいてエレメントの数を返送し、フォームに関連したＨＴＭＬエンコードデータをジョブ仕様に挿入し、そしてテキストをジョブ仕様にプログラムで挿入する。
図５は、簡単なワークフローの別の例を示す。図５に示すように、タスクは、ファイル５０４が変更されるワークエリア５０２において実行される。ファイル５０４が変更されると、それらはワークエリア５０６に与えられる。ワークエリア５０６では、更に別のタスクがファイル５０４において実行される。
【００３５】
図６は、ワークフローの別の例を示す。タスクは、ワークエリア６０２においてファイル６０４に対して実行される。仕事が完了すると、ファイル６０４がエリア６０６において再検討される。更に仕事が要求される場合には、拒絶指示がエリア６０６からエリア６０２へ送信される。しかしながら、ファイル６０４がエリア６０６で承認されたと仮定すれば、ファイル６０４はワークエリア６０８へ送信される。エリア６０８では、リンクチェックが行われて、ワークエリア６０２で行われた変更がリンク（例えば、ハイパーリンク）に悪影響しないことが保証される。リンクが悪影響を受ける場合には、エリア６０８からエリア６０２へ拒絶指示を送信することによりエリア６０２へファイルが返送される。しかしながら、リンクチェックにより問題がないことが分かると、ファイル６０４がエリア６１０、６１２、６１４へ送信され、そこで、付加的な仕事がファイルに行われるか、又はファイルの再検討が行われる。ファイルは、エリア６１０、６１２、６１４へ同時に転送されてもよいし、エリア６１０、６１２、６１４において同時に変更又は再検討されてもよい。
【００３６】
図７は、ワークフローの更に別の例を示す。ワークエリア７０２において、ファイル７０４は、特定タスクの実行により変更される。ファイル７０４は、次いで、ワークエリア７０６及び７０８へ通され、そこで、付加的なタスクが実行される。ファイルは、タスクによって新たなワークエリアにコピーでき、又は同じファイルに対して新たなタスクを実行できることに注意されたい。ワークエリア７０６及び７０８において仕事が完了すると、これらのワークエリア７０６及び７０８の各々で変更されたファイル７０４が、更なる処理の前に、ワークエリア７１０において合併される。タスクは、エリア７０６及び７０８においてパラレルに実行されるので、ファイル７０４は、オリジナルからコピー又は複写されてもよく、そしてコピー７０４’、７０４”は、エリア７０６及び７０８の各々により異なるやり方で変更されてもよい。従って、各エリア７０６及び７０８からのファイル７０４’、７０４”が合併され、そしてその相違が、更なるタスクの実行の前に融和される。この合併は、種々のやり方で実行できるが、好ましい実施形態では、コピーされたファイルに対する変更をオリジナルファイルに組み込むオペレーションを実行することにより合併が実行される。合併は、最後の１つのタスクが行われたとき、全てのタスクが行われたとき、又はいずれか１つのタスクが行われたときに行うことができる。コードのコンフィギュレーションは、合併をいつ行うべきか定義することができる。
【００３７】
合併の一例として、合併されるべき第１組のファイルがワークエリアにコピーされる。次いで、第２組のファイルがエリアにコピーされる。第２組のファイルをコピーする際に、第２組と第１組との間の矛盾が識別されそして融和される。例えば、第２組のファイルを形成したタスクの所有者は、ユーザインターフェイスを経て融和を実行することができる。
図７を参照すれば、ファイルの合併は、ファイル７０４’、７０４”を互いに比較し、同じエレメントを保持し、いずれかのエリア７０６又は７０８において削除されたエレメントを削除し、いずれかのエリア７０６又は７０８において追加されたエレメントを追加し、そしていずれかのエリア７０６又は７０８において変更されたエレメントを変更することを含む。エリア７０６及び７０８において同じエレメントが異なるやり方で変更されるような矛盾が存在する場合には、更なる融和が実行される。例えば、これは、ファイルをエリア７０６及び７０８へ戻すことを含む。しかしながら、このような矛盾は、パラレルに実行されるタスクを、ファイルの同じエレメントに対して矛盾する変更を生じることがあり得ないタスクに制限することにより、回避される。
【００３８】
図８は、ワークフローの更に別の例を示す。ワークエリア８０２において、ファイル８０４は、指定されたタスクに基づいて変更される。ファイル８０４は、次いで、再検討のためにエリア８０６及び８０８へ送信される。編集者は、タスクが読み出し専用として設計されているかどうかに基づき、ファイルを再検討するか及び／又はファイルへの変更を行う。ファイル８０４が両エリア８０６及び８０８において承認された場合には、ファイルが、更に別のタスクを実行するためにワークエリア８１０へ送信される。これは、ファイルに対する変更を、オリジナルファイルに組み込むために公表することを含む。
エリア８１０においてタスクを実行する前に各エリア８０６及び８０８から承認を得るよう確保するために、各エリア８０６及び８０８に対応する承認フラグが設けられる。両フラグがセットされると、これは、ファイルがエリア８１０を進行していることを指示する。或いは、各再検討者による承認を必要とするのではなく、１人の再検討者の承認だけでもよい。この場合には、ファイルをエリア８１０へ通す前に１つのフラグだけセットすればよい。付加的なエンティティが再検討者であると仮定すれば、再検討者の種々の組合せ、例えば過半数の再検討者の承認が必要とされてもよいし、或いは指定の再検討者の承認が、他の再検討者のグループの１人以上の承認と共に必要とされてもよい。
【００３９】
しかしながら、両エリア８０６及び８０８において承認が要求され、そしてエリア８０８においてファイル８０４が再検討されて承認されると仮定する。この場合には、エリア８０８に対する承認フラグがセットされる。又、ファイル８０４がエリア８０６において再検討されたが、拒絶されたと仮定する。次いで、拒絶指示子がエリア８０６からエリア８０２へ送信され、そしてファイル８０４が更なる変更のためにエリア８０２へ返送される。この拒絶に応答して、エリア８０６に対して既にセットされた承認フラグがリセットされるのが好ましい。これは、ワークエリア８０６において拒絶に応答して変更されたファイル８０４が、エリア８１０において更に処理される前に、ワークエリア８０８において更に再検討されるよう確保する。従って、ファイルに対して行われた仕事に対して多数の承認タスクが要求される場合には、ファイルが承認されたときにフラグがセットされ、そして他のいずれか１つの承認でも拒絶されれば、それがリセットされる。従って、拒絶に応答してファイルが変更される場合には、全ての承認者が、その変更されたファイルを承認しなければならない。このようなフラグが全てセットされたときに、ファイルは、更なる作業のために、例えば、別のワークステーションへ送られる。
【００４０】
以上、本発明の特定の実施形態について説明したが、特許請求の範囲によって限定された本発明の精神及び範囲から逸脱せずに、これら実施形態の変更がなされ得ることが当業者に明らかであろう。例えば、本発明は、専用のプロセッサ、ブラウザ要求を受信してルーティングするように構成されたウェブサーバー、アプリケーションサーバー、状態サーバー、及び互いに通信するように構成されそしてローカルエリアネットワーク（ＬＡＮ）、イントラネット及びインターネットを含む１つ以上のネットワークに接続される他の形式のコンピュータプロセッサを利用することも含む。しかしながら、このような装置及びシステムのこのような実施は、本発明を利用する幾つかの例に過ぎず、本発明は、１つ以上のネットワーク内のデータの効率的なルーティング及び処理が含まれる多数の他の用途にも利用できることが当業者に明らかであろう。このような用途に対し、本発明の精神及び範囲から逸脱せずに、本発明を用いた同等の構造体を構成することができる。この実施形態は、コンピュータシステム又はネットワークのユーザ間でデータを交換するための装置及びシステムに関して図示して説明したが、本発明は、同様の特徴が有用な他の用途にも拡張される。本発明は、パーソナルコンピュータ、アプリケーションサーバー、状態サーバー、又はコンピュータに対して設計及び実施されて他のコンピュータと通信するためにネットワークに接続されて本発明を実施するようなインターネットウェブサーバーを包含する。本発明により動作するように構成されたシステムは、個々のモデム又は他の通信手段、例えば、ワイヤレス通信を経てインターネットに接続された複数のパーソナルコンピュータを含む。
【００４１】
又、本発明は、マイクロプロセッサのような１つ以上のコンピュータプロセッサにより実行されるべき多数のファンクションも含む。マイクロプロセッサは、特定のタスクを定義するマシン読み取り可能なソフトウェアコードを実行することにより特定のタスクを実行するよう構成された特殊な又は専用のマイクロプロセッサである。又、マイクロプロセッサは、直接メモリアクセスモジュール、メモリ記憶装置、インターネット関連ハードウェアのような他の装置、並びに本発明によるデータの送信に関連した他の装置と共に動作し且つ通信するように構成することもできる。ソフトウェアコードは、Ｊａｖａ（登録商標）、Ｃ＋＋、ＸＭＬ（拡張可能なマークアップ言語）、及び本発明に関連した機能的オペレーションを実行するのに必要な装置の動作に関連したファンクションを定義するのに使用できる他の言語のようなソフトウェアフォーマットを使用して構成することができる。コードは、種々のフォーム及びスタイルで書くことができ、その多くは当業者に知られたものである。本発明によるマイクロプロセッサのオペレーションを定義するためのコードを構成するソフトウェアプログラム及び他の手段の異なるコードフォーマット、コードコンフィギュレーション、スタイル及びフォームは、特許請求の範囲により限定された本発明の精神及び範囲から逸脱するものではない。
【００４２】
本発明を利用するコンピュータサーバーのような種々の形式のコンピュータ内には、本発明によるファンクションを遂行する間に情報を記憶しそして検索するための種々の形式のメモリ装置が存在する。このようなコンピュータにはキャッシュメモリ装置がしばしば含まれ、頻繁に記憶及び検索される情報のための便利な記憶位置として中央処理ユニットにより使用される。同様に、このようなコンピュータには、キャッシュメモリとは異なり、中央処理ユニットによって頻繁に検索されるが、頻繁に変更されない情報を維持するための永続的メモリもしばしば使用される。又、通常、中央処理ユニットにより実行されるときに、本発明によるファンクションを遂行するように構成されたデータ及びソフトウェアアプリケーションのような多量の情報を記憶及び検索するためにメインメモリも含まれる。これらのメモリ装置は、ランダムアクセスメモリ（ＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、フラッシュメモリ、及び情報を記憶及び検索するために中央処理ユニットによりアクセスされる他のメモリ記憶装置として構成することができる。本発明は、特定の形式のメモリ装置に限定されるものではなく、これらのメモリ装置に各々情報を記憶してそこから検索するための通常使用のプロトコルに限定されるものでもない。
【図面の簡単な説明】
【図１】
本発明によるウェブサイト開発のためのコンピュータネットワークシステムを示す図である。
【図２】
本発明による例示的な指定−編集−承認ワークフローモデルを示す図である。
【図３】
図２のワークフローモデルから生成される例示的ジョブインスタンスを示す図である。
【図４】
ジョブを生成するためのワークフローテンプレートを設定するために本発明により使用される５つの主たる要素を示す図である。
【図５】
本発明による例示的なワークフローを示す図である。
【図６】
本発明による例示的なワークフローを示す図である。
【図７】
本発明による例示的なワークフローを示す図である。
【図８】
本発明による例示的なワークフローを示す図である。

Claims (33)

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. ワークフローテンプレートを使用してジョブ仕様を生成することを更に含む請求項２６に記載の方法。
29. 上記ワークフローテンプレートは、ＸＭＬファイルである請求項２８に記載の方法。
30. ユーザが上記変更を行い、そして少なくとも１つのタスクは、少なくとも１つの他のタスクに関してユーザの１人へのＥメール通知の送信を特定する請求項２５に記載の方法。
31. 上記変更は、上記ウェブサイトコンテンツファイルをシリアルな順序で変更することを含む請求項２５に記載の方法。
32. 上記変更は、上記ウェブサイトコンテンツファイルをパラレルに変更することを含む請求項３１に記載の方法。
33. パラレルに変更された上記ウェブサイトコンテンツファイルを合併することを更に含む請求項３２に記載の方法。

Images