(57)【要約】通信サービスをプロビジョニングするためのプロビジョニング・エンジン、及びプロビジョニング・エンジン（１００）を構成するためのパターン言語。複数のオブジェクトをアセンブルして、共通のプロビジョニング・オペレーションを実行するための状態マシンを表すプロビジョニング・モデルを定義することができる。状態マシンは、プロビジョニング・モデルの１組の複数の現在状態（１１０）、信号生成のためのメカニズム（１３２）、タスク、及び、タスク（１３８）が実行され、状態（１３６）が１組の現在状態（１１０）に追加又はそこから除去される条件を定義するように動作可能な少なくとも１つの遷移を含む。信号（１３２）は、即座に実行することも、又は後で実行するようにスケジュールすることができ、それによってプロビジョニング・オペレーションを、時間を考慮した方法で制御することができる。プロビジョニング・モデルは、特定のインスタンスとして実行することができ、インスタンスは、サブインスタンスとして実行するべき他のモデルへの呼出しを含むことができる。
2004505333.tif 000002
【特許請求の範囲】
【請求項１】
共通のプロビジョニング作業プロセスを実行するための少なくとも１つのプロビジョニング・モデルを含む、通信サービスをプロビジョニングするためのプロビジョニング・エンジンであって、状態マシンを定義する前記プロビジョニング・モデルが、
前記プロビジョニング・モデルの１組の複数の現在状態と、
信号を生成する手段と、
状態が、前記１組の現在状態に追加、又はそれから除去される条件を定義するように動作可能な少なくとも１つの遷移と、を含む
ことを特徴とするプロビジョニング・エンジン。
【請求項２】
前記遷移が、信号タイプと、１組のｆｒｏｍ状態と、１組のｔｏ状態とを含み、前記モデルの実行インスタンスが前記信号タイプに一致する信号を受信し、かつ前記ｆｒｏｍ状態が前記１組の現在状態のサブセットである場合に、前記ｔｏ状態を前記１組の現在状態に追加し、かつ前記ｆｒｏｍ状態を前記１組の現在状態から除去するように動作可能な、請求項１に記載のプロビジョニング・エンジン。
【請求項３】
前記遷移が、信号の引数を修正して、前記信号を生成する手段に信号を返すように動作可能な、請求項２に記載のプロビジョニング・エンジン。
【請求項４】
前記信号を生成する手段が、プロビジョニング・エンジンの外部ＡＰＩを含む、請求項１に記載のプロビジョニング・エンジン。
【請求項５】
前記信号を生成する手段が、前記遷移の１つを含む、請求項１に記載のプロビジョニング・エンジン。
【請求項６】
前記信号を生成する手段が、信号ＡＰＩ呼出しを生成する手段と、対応する信号ＡＰＩ呼出しの後、所定の時間に信号を送信する手段とを含む、請求項１に記載のプロビジョニング・エンジン。
【請求項７】
前記モデルが、それぞれがインスタンスに固有のデータを記憶する手段を有する複数の実行インスタンスを含む、請求項１に記載のプロビジョニング・エンジン。
【請求項８】
前記モデルが、前記インスタンスのそれぞれが使用するデータを記憶する手段を含む、請求項７に記載のプロビジョニング・エンジン。
【請求項９】
前記遷移が、少なくとも１つのタスクと、前記モデルのインスタンスが前記信号タイプに一致する信号を受信し、かつ前記ｆｒｏｍ状態が前記現在状態のサブセットである場合に、前記少なくとも１つのタスクを実行する手段とをさらに含む、請求項２に記載のプロビジョニング・エンジン。
【請求項１０】
前記遷移が、前記実行手段によって実行された前記少なくとも１つのタスクに通信される遷移引数を含む、請求項９に記載のプロビジョニング・エンジン。
【請求項１１】
前記インスタンスの少なくとも１つが、サブインスタンスとして別のモデルへの呼出しを含む、請求項７に記載のプロビジョニング・エンジン。
【請求項１２】
前記サブインスタンスが、前記少なくとも１つのインスタンスと通信する手段を含む、請求項１１に記載のプロビジョニング・エンジン。
【請求項１３】
前記少なくとも１つのインスタンスの遷移が、前記サブインスタンスが実行している間に実行を停止し、前記サブインスタンスが実行を終えたときに実行を続けるように構成されている、請求項１２に記載のプロビジョニング・エンジン。
【請求項１４】
共通のプロビジョニング・オペレーションを実行するための状態マシンを定義するプロビジョニング・モデルを含む、通信サービスをプロビジョニングするためのプログラミング・エンジンのためのパターン言語であって、状態マシンの機能を表す複数のオブジェクトを含み、前記オブジェクトのそれぞれが、
前記プロビジョニング・モデルの１組の複数の現在状態と、
状態が、前記１組の現在状態に追加、又はそれから除去される条件を定義するように動作可能な少なくとも１つの遷移と、を含む
ことを特徴とするパターン言語。
【請求項１５】
前記オブジェクトの少なくとも１つが、サブインスタンスとして別のプロビジョニング・モデルへの呼出しを含むサブインスタンス・オブジェクトである、請求項１４に記載のパターン言語。
【請求項１６】
前記サブインスタンス・オブジェクトが、前記サブインスタンスと通信する手段を含む、請求項１５に記載のパターン言語。
【請求項１７】
前記呼出しが、前記サブインスタンスのＩＤを指定するＵＲＬを含む、請求項１６に記載のパターン言語。
【請求項１８】
前記呼出しがさらに引数を含む、請求項１７に記載のパターン言語。
【請求項１９】
前記通信手段が、前記引数を変更する手段を含む、請求項１８に記載のパターン言語。
【請求項２０】
前記遷移が、信号タイプと、１組のｆｒｏｍ状態と、１組のｔｏ状態とを含み、前記モデルの実行インスタンスが前記信号タイプに一致する信号を受信し、かつ前記ｆｒｏｍ状態が前記１組の現在状態のサブセットである場合に、前記ｔｏ状態を前記１組の現在状態に追加し、前記ｆｒｏｍ状態を前記１組の現在状態から除去するように動作可能な、請求項１１に記載のパターン言語。
【請求項２１】
前記遷移が、信号の引数を修正し、信号の起点源に信号を返すように動作可能な、請求項２に記載のパターン言語。
【請求項２２】
前記信号起点源が、プロビジョニング・エンジンの外部ＡＰＩである、請求項１３に記載のパターン言語。
【請求項２３】
前記信号起点源が前記遷移の１つである、請求項１３に記載のパターン言語。
【請求項２４】
信号ＡＰＩ呼出しを生成する手段と、対応する信号ＡＰＩ呼出しの後、所定の時間に信号を送信する手段とをさらに含む、請求項１１に記載のパターン言語。
【請求項２５】
前記遷移が、少なくとも１つのタスクと、前記モデルの実行インスタンスが前記信号タイプに一致する信号を受信し、前記ｆｒｏｍ状態が前記現在状態のサブセットである場合に、前記少なくとも１つのタスクを実行する手段とをさらに含む、請求項１２に記載のパターン言語。
【請求項２６】
前記遷移が、前記実行手段によって実行された前記少なくとも１つのタスクに通信される遷移引数をさらに含む、請求項１７に記載のパターン言語。
【発明の詳細な説明】
（関連出願データ）
本出願は、本出願人が以前に２０００年３月１７日付けで出願した、参照によりその全体が本明細書に組み込まれている、米国特許仮出願第６０／１８９，９８８号に関連する。
【０００１】
（発明の背景）
（発明の技術分野）
本発明は、通信サービスのプロビジョニングに関し、より詳細には、プロビジョニング・プロセスの時間的制御のための方法及び装置、及びプロビジョニング・モデルを開発するためのオブジェクト・プログラミング言語に関する。
【０００２】
（関連技術の説明）
用語「プロビジョニング」は、様々な当事者のために、通信サービスの据付け、構成及び管理を提供するのに必要な作業プロセスを遂行することを指す。例えば、顧客から新規の電話サービスの注文があったとき、電話会社が、回路を構築するために様々な物理的接続を行い、かつ顧客データベース、伝票発行システムなどに様々なデータを入力しなければならない可能性がある。インターネット・サービスの場合、プロビジョニング・プロセスはより一層複雑になる。例えば、新しい顧客のために、ダイヤルアップ、ケーブル、又はデジタル加入者線（ＤＳＬ）によるインターネット・サービスをプロビジョニングする場合、インターネット・サービス・プロバイダ（ＩＳＰ）は、電子メールのアカウントの構成及び作成、ホスト・アカウントの構成及び作成、ＤＨＣＰ（動的ホスト構成プロトコル）の設定など、複数の作業プロセスを遂行しなければならない。
【０００３】
米国特許第５，７７４，６８９号、第５，７９０，６３３号、第５，８８１，１３１号、及び第５，９３７，０４８号は、通信プロビジョニング・システムの最新技術の代表である。米国特許第５，７７４，６８９号は、インフラ構成要素に関する情報が、オブジェクトとしてデータベースに記憶される、プロビジョニング・システムを開示している。しかし、これらの特許は、柔軟なプロビジョニング・エンジン又はそのためのプログラミング方法を開示していない。具体的には、従来のプロビジョニング方法は、遂行しなければならない様々な作業プロセスの柔軟な時間的制御が可能ではない。例えば、複雑な通信ネットワークに固有のエラー及び遅延のために、いくつかのプロビジョニング作業プロセスは、達成に成功するまでに、複数回試みることがしばしば必要である。さらに、作業プロセスによっては、別の作業プロセスを始める前に、達成に成功しなければならないものもある。これらの理由のために、プロビジョニングは非常に複雑であり、従来は、顧客サービス代理人が介在して、顧客からサービス要求情報を入手し、すべての作業プロセスが達成に成功し、かつ正しい順序であるように確実化することが必要とされてきた。
【０００４】
米国特許第５，９４６，４８５号、第５，０１９，９６１号、第５，８６２，３７２号、及び第６，０１４，１３８号は、柔軟なプログラミングを容易にするための様々なオブジェクト指向プログラミング技術を開示している。これらの特許は、他のオブジェクト指向プログラミング例と同様に、作業プロセスの時間的制御を提供しておらず、したがって、プロビジョニング・プロセスの複雑さには適していない。
【０００５】
米国特許第５，２８３，８９６号は、ペトリネット（Ｐｅｔｒｉ　Ｎｅｔ）技術を使って、コンピュータの周辺装置など、相互に排他的な資源を制御するためのシステムを開示している。各タスクは、単一のトークン、すなわち状態を有する、下にある状態マシンによって表される。タスクは、それらを実行すべき順序に基づいて、順次に、又は並行して配列される。この参照文献は、通信プロビジョニング技術に関するものではなく、また、プロビジョニング・システムにおいては望ましい、作業プロセスの時間的制御を教示又は提案するものでもない。
【０００６】
通信サービス・プロバイダがサービス据付けの量、及びサービス引渡し要件の管理を処理する能力は、無数の商業顧客管理及びネットワーク装置構成システムがあるという事実によってさらに制限される。システムの不適合性により現行サービスが影響を受ける可能性を最小限に抑えるために、サービス・プロバイダは、しばしば、顧客への対処の適用例のために単一ベンダからのシステムを使用しなければならず、またネットワーク・ソリューションのために単一ベンダを使用しなければならない。しかし、この手法は、プロバイダをベンダとの長期的関係に縛りつけ、プロバイダが新しいサービスを創造し、引き渡す能力を限定する可能性がある。より柔軟なプロビジョニング・エンジンによりこの制限は緩和されよう。
【０００７】
（発明の概要）
本発明の一目的は、通信サービスのプロビジョニングを自動化し、管理することである。
【０００８】
本発明の別の目的は、加入者による通信サービスの自主管理を容易にすることである。
【０００９】
本発明の別の目的は、多数の複雑なプロビジョニング作業プロセスを非常に効率的に、かつ時間を考慮した方法で実行することである。
【００１０】
本発明の別の目的は、完了していないプロビジョニング作業プロセスの自動再スケジューリングを可能にすることである。
【００１１】
本発明の別の目的は、標準プロビジョニング機能のオブジェクトを使って、プロビジョニング・モデルの構成及び再構成が容易にできるようにすることにより、様々な通信サービスのプロビジョニングを容易にすることである。
【００１２】
本発明の別の目的は、複数のプロビジョニング作業プロセスの現在状態を正確に追跡することである。
【００１３】
本発明の別の目的は、様々なベンダからの複数システムを伴う通信サービスのプロビジョニングを可能にすることである。
【００１４】
本発明の別の目的は、事前定義オブジェクトを使って、プロビジョニング・モデルを容易に構成することができるようにすることである。
【００１５】
上記及びその他の目的は、共通のプロビジョニング作業プロセスを実行するためのプロビジョニング・モデルを含む、通信サービスをプロビジョニングするためのプロビジョニング・エンジンである、本発明の第１の態様によって達成される。プロビジョニング・モデルは、プロビジョニング・モデルの１組の複数の現在状態と、状態がこの１組の現在状態に追加、又はそれから除去される条件を定義するように動作可能な少なくとも１つの遷移とを含む。
【００１６】
本発明の第２の態様は、共通のプロビジョニング・オペレーションを実行するためのプロビジョニング・モデルを開発することによって通信サービスをプロビジョニングするための、パターン言語である。このパターン言語は、それぞれが状態マシンを表す複数のオブジェクトを含む。各オブジェクトは、１組の複数の現在状態と、状態がこの１組の現在状態に追加、又はそれから除去され、また、作業プロセスを遂行するタスクが実行される条件を定義するように動作可能な少なくとも１つの遷移とを含む。
【００１７】
（好ましい実施形態の詳細な説明）
本発明を、好ましい実施形態及び添付の図面によって説明する。
【００１８】
図１は、好ましい実施形態のプロビジョニング・エンジンの構成図である。プロビジョニング・エンジン１００は、プロビジョニング・プロセスを実行するように設計されたプロビジョニング・モデル１０２の実行インスタンス１１０を含む。例えば、プロビジョニング・モデル１０２を、新規加入者のためにインターネット・ダイヤルアップ・サービスをプロビジョニングするように設計することができる。モデル１０２は、例えば、電子メール・アカウントの作成、ホスト・アカウントの作成、ＤＨＣＰ構成などの作業プロセスを含むことができる。プロビジョニング・モデル１０２は、状態マシンを定義して、プロビジョニング・プロセスの複雑さを管理する。後述するように、プロビジョニング・モデル１０２は、作業プロセスの流れを適時に制御するためのメカニズムを組み込んでいる。したがって、プロビジョニング・エンジン１００は、プロビジョニングに関連してしばしば生じる複雑な時間的問題を管理することができる。
【００１９】
エンジン１００は、サーバなど、汎用コンピュータ上で実行されるソフトウェア・コードの形をとることができる。エンジン１００は、様々な既知のプログラミング言語でプログラムし、Ｗｉｎｄｏｗｓ（商標）やＵｎｉｘなど、様々な既知のオペレーティング・システム下で実行できるようにコンパイルすることができる。モデル１０２は、タスク１３８を実行することによって、プロビジョニング作業プロセスを実行する。好ましい実施形態では、タスク１３８は、全体的なスループット及びフレキシビリティを高めるためにエンジン１００自体から動的にロード及びアンロードされる、外部プログラム、スクリプト、又はその他のコードであってよい。タスク１３８は、Ｊａｖａ（商標）などの従来のプログラミング言語、又は独自開発のスクリプティング言語で書くことができる。タスク１３８については、以下にさらに詳説する。
【００２０】
エンジン１００を利用して、それぞれが、ダイヤルアップ・インターネット・アカウントのセットアップなど、特定のプロビジョニング・オペレーションを遂行するために従わなければならないプラン、すなわち一連の作業プロセスを定義する、任意の数のプロビジョニング・モデル１０２を構成することができる。さらに、各プロビジョニング・モデル１０２は、１つ又は複数の実行インスタンス１１０として実行することができる。インスタンス１１０は、特定のプロビジョニング・オペレーションのために、プロビジョニング・モデル１０２の作業プロセスを遂行する責任を持つ。上述のように、モデル１０２は、個々のダイヤルアップ顧客のためにインターネット・サービスを起動するために必要な作業プロセスを定義する場合もある。この場合、新規の顧客がダイヤルアップ・インターネット・サービスを要求するたびに、モデル１０２のインスタンス１１０が生成されて走る、すなわち実行される。
【００２１】
好ましい実施形態のエンジン１００は、時間的な方法で制御しなければならないタスク１３８をエンジン１００が容易に管理できるようにする、修正版ペトリネット・アルゴリズムを組み込んでいる状態マシンを利用する。各プロビジョニング・モデル１０２は、このような状態マシンを定義し、各インスタンス１１０は、その状態マシンの特定の実行を表す。各モデル１０２、従って各インスタンス１１０は、１組の現在状態１２０と、少なくとも１つの遷移１３０を含む。現在状態１２０は、単に、「ｎｏｔＤｏｎｅ」（プロセスは遂行されていない）」又は「ｄｏｉｎｇ＿ｄｈｃｐ」（現在、ＤＨＣＰプロセスを実行中）、「ｕｎｄｏｉｎｇ＿ｅｍａｉｌ」（現在、電子メール・アカウント設定を取り消し中）など、現実のプロビジョニング作業プロセスの状態に対応する、任意の文字列でよい。現在状態１２０については、以下にさらに詳説する。
【００２２】
従来の状態マシンは、単一の現在状態を有する。好ましい実施形態のプロビジョニング・エンジン１００は、１組の複数の現在状態１２０を有する状態マシンとして、インスタンス１１０を利用する。例えば、好ましい実施形態のインスタンス１１０では、現在状態１２０には「ｄｏｉｎｇ＿ｏｐｅｒａｔｉｏｎ１」、「ｎｏｔｄｏｎｅ＿ｏｐｅｒａｔｉｏｎ２」、及び「ｄｏｎｅ＿ｏｐｅｒａｔｉｏｎ３」が含まれる。下記のように、単一の現在状態ではなく１組の複数の現在状態１２０を使用することによって、作業プロセス、特に、初回でうまく実行し得るかどうかわからない時間的な作業プロセスを制御する場合には明らかな利点がある。もちろん、各インスタンス１１０は、それ自体の１組の現在状態１２０を、独立して保持する。
【００２３】
信号１４０（図２を参照）は、ｓｔａｒｔ、ｇｏ、ｄｏ、又はｕｎｄｏなどの文字列として表すことができる、プロビジョニング・インスタンス１１０に送られるコマンドである。信号１４０は、下記のように、様々な方法で生成することができる。信号１４０は、遷移１３０をトリガして、作業プロセスの実行及び流れを制御することができる。遷移１３０（そのうち１つだけを図１に示す）は、状態がインスタンス１１０の１組の現在状態１２０に追加、又はそれから除去され、また、作業プロセスを定義するタスクが遂行される条件を定義する。各遷移は、３つの構成要素、すなわち、信号タイプ１３２、１組のｆｒｏｍ状態１３４、１組のｔｏ状態１３６を含む。遷移１３０はまた、１つ又は複数のタスク１３８も含むことができる。
【００２４】
各遷移１３０は、１つの信号タイプ１３２だけを有する。しかし、所与の信号タイプ１３２を、任意の数の遷移１３０に関連させることができる。ｆｒｏｍ状態１３４及び信号タイプ１３２は、遷移１３０を適用するのに必要な前提条件を定義する。遷移１３０は、そのｆｒｏｍ状態１３４が、インスタンス１１０の１組の現在状態１２０のサブセットであって、遷移１３０の信号タイプ１３２に対応する信号１４０が受信された場合に、そしてその場合にのみ適用される。遷移１３０が適用されると、そのｔｏ状態１３６が、インスタンス１１０の１組の現在状態１２０に追加され、そのタスク１３８が、プロビジョニング・プロセスの特定の作業プロセスを遂行するために実行される。遷移１３０は、プロビジョニング・モデル１０２によって定義される。その結果、同じモデル１０２のすべてのインスタンス１１０は、同じ１組の遷移１３０を共用する。
【００２５】
インスタンス１１０は、信号１４０を受信するたびに、対応するプロビジョニング・モデル１０２によって定義された各遷移１３０を反復する。各遷移１３０について、ｆｒｏｍ状態１３４が、現在状態１２０のサブセットであり、信号タイプ１３２が信号１４０に対応するならば、遷移１３０は「適用可能」である。適用可能遷移１３０のｆｒｏｍ状態１３４を１組の現在状態１２０から削除し、次いで適用可能遷移１３０のｔｏ状態１３６を１組の現在状態１２０に追加することにより、遷移１３０の適用可能なものがインスタンス１１０に適用される。最後に、適用可能遷移１３０の各タスク１３８が実行される。単一の遷移の処理の例として、２つの遷移１３０を表す次の表１を考察されたい。
【００２６】
【表１】
2004505333.tif 000003
【００２７】
上記の遷移Ｎｏ．１は、タイプ「ｓｔａｒｔ」の信号１４０が受信されるたびに、その状態「ｓ」が１組の現在状態１２０のサブセットであるならば、インスタンス１１０が、状態「ｓ」を１組の現在状態１２０から削除し、状態「ａ」及び「ｂ」を１組の現在状態１２０に追加し、「Ｔａｓｋ１」「Ｔａｓｋ２」を実行すべきであることを表している。遷移Ｎｏ．２は、タイプ「ｓｔｏｐ」の信号１４０が受信されるたびに、「ａ」と「ｂ」の両方が１組の現在状態１２０のメンバであるならば、「ａ」と「ｂ」が、１組の現在状態１２０から削除され、状態「ｄｏｎｅ」が１組の現在状態１２０に追加されることを述べている。タスクＮｏ．２では、タスク１３８の欄が空になっているが、これは、「ｄｏｎｅ」状態に遷移した後、何もタスクが遂行されていないことを意味することに注意されたい。
【００２８】
遷移１３０の処理は、表１に関連して説明した例よりももっと複雑になり得る。特に、好ましい実施形態のプロビジョニング・エンジン１００は、遷移１３０がどのような順番で処理されても、結果は常に同じであることを保証する。これは、すべての適用可能遷移１３０を、それらを反復してではなく、同時に処理することによってなし遂げられる。すべての適用可能遷移１３０のすべてのｆｒｏｍ状態１３４の合併を形成することにより、１組の「削除」状態が生成される。適用可能遷移１３０のすべてのｔｏ状態１３６の合併を形成することにより、１組の「追加」状態が生成される。次いで、各適用可能遷移１３０のすべてのタスク１３８を連結することにより、タスク・リストが作成される。そのときに、そしてそのときにのみ、すべての削除状態が１組の現在状態１２０から削除され、すべての追加状態が１組の現在状態１２０に追加され、適用可能遷移１３０のすべてのタスク１３８が実行される。
【００２９】
信号１４０をプロビジョニング・インスタンスに送信するプロセスを、ここでは「シグナリング」と呼ぶ。上述のように、信号１４０を受信すると、適用可能遷移１３０は、トリガされて、タスク１３８を実行し、現在状態１２０を修正する。多くの信号１４０は、プロビジョニング・エンジン１００の外部ＡＰＩを介してインスタンス１１０に送信される。このような信号は、一般に、インスタンス１１０のアクティビティを開始させるために、又はインスタンス１１０を更新して、変化している外部条件を反映させるために使用される。あるいは、遷移１３０のタスク１３８が、信号１４０を自動的に生成及び送信することもできる。信号１４０がどこを起点としようと、すなわち外部であろうと内部であろうと、シグナリングＡＰＩの呼出しは同様に見えるはすである。例えば、好ましい実施形態のシグナリングＡＰＩは、下記の簡易Ｊａｖａの形で表現される。
【００３０】
ｓｉｇｎａｌ（Ｓｔｒｉｎｇ ｉｎｓｔａｎｃｅＩｄ， Ｓｔｒｉｎｇ ｓｉｇｎａｌ）；
このコード・フラグメントは、所与の識別子「ｉｎｓｔａｎｃｅＩｄ」を有するプロビジョニング・インスタンス１１０に信号１４０を送信する命令を表す。実際には、シグナリングＡＰＩでは、信号ごとに、ディクショナリ又はマップなどの形で表現される任意の数の引数に関連させることができる。これらの引数をここでは「信号引数」と呼び、それについて以下に例示する。
【００３１】
ｓｉｇｎａｌ（Ｓｔｒｉｎｇ ｉｎｓｔａｎｃｅＩｄ， Ｓｔｒｉｎｇ ｓｉｇｎａｌ， Ｍａｐ ｓｉｇｎａｌＡｒｇｕｍｅｎｔｓ）；
上記のフォーマットの信号１４０が処理され、それによってタスク１３８が実行すると、実行されたタスク１３８は、マップの内容へのプログラマティック・アクセスができるようになる。これは、外部からのデータがそれによってプロビジョニング・インスタンス１１０に通信される、メカニズムである。実行中のタスク１３８は、その「信号引数」マップの内容を自由に修正することができる。タスク１３８が実行を終えると、修正されている、又は修正されていない信号引数は、遷移１３０をトリガして、タスク１３８実行させた信号１４０を生成又は発行したオブジェクトに戻される。したがって、この信号メソッドのフォーム全体は以下のようになる。
【００３２】
Ｍａｐ ｓｉｇｎａｌ（Ｓｔｒｉｎｇ ｉｎｓｔａｎｃｅＩｄ， Ｓｔｒｉｎｇ ｓｉｇｎａｌ， Ｍａｐ ｓｉｇｎａｌＡｒｇｕｍｅｎｔｓ）；
したがって、信号ＡＰＩ呼出しの返却値は、「ｓｉｇｎａｌＡｒｇｕｍｅｎｔｓ」引数であり、これは、信号１４０の結果、実行されたタスク１３８があれば、それによる呼出しの時から修正されている可能性がある。信号引数は、単に、キー／値の対を含むマップであってよい。Ｊａｖａコード又はその他の方法で定義することも可能であるが、わかりやすいように、中括弧「｛｝」内にマップを表現し、コロン「：」を使って各キーをそれが関連する値から分離する表記法を使用することができる。例として、次のマップを考察されたい。
【００３３】
｛ｓｕｐｐｌｉｅｒ： ”Ａｃｍｅ Ｔｏｏｌｓ， Ｉｎｃ．” ａｄｄｒｅｓｓ： ”２５２３ ＧｌｅｎＷｏｏｄ Ｒｄ．， Ｓｏｍｅｗｈｅｒｅｖｉｌｌｅ” ｝
このマップは、キー「ｓｕｐｐｌｉｅｒ」及び「ａｄｄｒｅｓｓ」で２つのエントリを定義している。この例では、これらのキーの値は共にストリングであるが、実際はそうでなくてもよい。値は、ストリング、整数、ブール演算式、浮動小数点数など、単純なスカラー・データ型であってもよいし、又は、セット、リスト、又は他のマップでもよい。次の例は、１対のキー：値でマップを定義しており、ここで、値は、セットのリストである。
【００３４】
｛ｓｃｈｅｄｕｌｉｎｇＤａｙｓ：［（Ｍｏｎｄａｙ Ｗｅｄｎｅｓｄａｙ Ｆｒｉｄａｙ）（Ｔｕｅｓｄａｙ Ｔｈｕｒｓｄａｙ）］｝
リストを閉じるのに大括弧「［］」を使用していること、セットを閉じるのに丸括弧「（）」を使用していることに注意されたい。この表記法は、プロビジョニング・エンジン１００において役立つことがわかっている。信号１４０へのＡＰＩ呼出しがプロビジョニング・インスタンス１１０に送られると、信号１４０は、通常、直ちにインスタンス１１０の遷移１３０に送信される。しかし、好ましい実施形態は、いつ信号１４０を送信すべきかを正確に指定する能力を追加する、「スケジュールＡＰＩ呼出し」と呼ばれる第２のフォームの信号１４０へのＡＰＩ呼出しを含む。このようなフォームは、強力な時間的制御を可能にし、次の形を取る。
【００３５】
Ｍａｐ ｓｃｈｅｄｕｌｅ（Ｓｔｒｉｎｇ ｉｎｓｔａｎｃｅＩｄ， Ｓｔｒｉｎｇ ｓｉｇｎａｌ， Ｍａｐ ｓｉｇｎａｌＡｒｇｕｍｅｎｔｓ， ｌｏｎｇ ｔｉｍｅＳｔａｍｐ）；
この例は、信号１４０に追加引数「ｔｉｍｅｓｔａｍｐ」を追加する。タイム・スタンプは、単に、信号１４０が送信されるべき時間を１９７０年１月１日ＵＴＣなどの基準日からのミリ秒で表現したものである。プロビジョニング・インスタンス１１０がこのようなＡＰＩ呼出しを処理すると、信号１４０が直ちに遷移１３０に送信される代わりに、信号１４０及びその引数が、インスタンス１１０が内部的に保持している永続的メモリ・キューに置かれる。信号１４０は、指定時間までは遷移１４０に送達されない。この指定時間は、信号１４０へのＡＰＩ呼出し後の未来の何ミリ秒から何年にまでわたり、いつでも可能である。信号１４０を様々な時間にスケジュールする能力は、エンジン１００の強力な特徴であり、遠隔通信サービスをプロビジョニングする仕事においては非常に役立つ。例えば、信号１４０のスケジューリングによって、あるネットワーク・システムが一時的にオフ・ラインになり、誤動作し、又はそうではないが正しく応答しないことを主な原因として、１つ又は複数の作業プロセスが失敗した場合に、タスク１３８が再実行するように再スケジュールすることができる。
【００３６】
スケジュールＡＰＩ呼出しは、上述の単一信号と同様の値を返す。しかし、スケジュールＡＰＩ呼出しが返した値は、単に、「ｓｉｇｎａｌＡｒｇｕｍｅｎｔｓ」の入力引数のコピーでしかない。ＡＰＩ呼出し自体は、その呼出しの結果として実行するいずれのタスクも引数の修正を行う機会を得ないうちに、直ちに戻る。タスク１３８は、自分が即時信号１４０の結果、又は待機信号１４０の結果、実行されたのかを知る方法はない。しかし、待機信号１４０の場合、未来のある時まで信号１４０がディスパッチされないこともあるため、タスク１３８は、スケジュール呼出しが戻ったずっと後まで、実行しない場合もある。したがって、タスク１３８が信号１４０の引数を修正したとしても、待機信号１４０のＡＰＩ呼出しがそれらの修正を見ることはない。
【００３７】
上述のように、タスク１３８は、遷移１３０をインスタンス１１０で適用可能にする信号１４０に応答して実行する、任意の単位のＪａｖａコードという形であってもよい。例えば、タスク１３８は、最も基本的な形では、単に、Ｊａｖａインタフェースを実装するＪａｖａクラスであってもよい。タスク１３８は、Ｊａｖａ又はその他の標準コードだと、書くのがきわめて容易であり、開発者側はほんの基礎的な知識しか要求されない。タスク１３８は、大括弧に入れた説明コメントが伴う、次のような基本的フォームになり得る。
【００３８】
［「ｍｙＰａｃｋａｇｅ」と称するパッケージ型の変数を宣言する。］
［プログラマが、パッケージ及びクラスに簡略化した名前を使用できるようにするパッケージをインポートする。］
［クラスＭｙ　Ｔａｓｋを定義して、Ｔａｓｋを実装する。］
［この関数は、ｓｅｒｖｉｃｅと名付けられたパブリック関数である。パブリックであるとは、それが公けにアクセス可能である、すなわち、どのようなオブジェクトでもこの関数を呼び出すことができるということを意味する。ｖｏｉｄ関数は、何も値を返さず、単に、演算を実行するだけである。この関数のパラメータは、ｃｏｎｔｅｘｔという名前のＴａｓｋＣｏｎｔｅｘｔ型の変数である。｛｝は、単に、コード・グループの開始と終了を表し、コンパイラがコードを構文解析し易くしている。］
ｐａｃｋａｇｅ ｍｙＰａｃｋａｇｅ；
ｉｍｐｏｒｔ ｃｏｍ．ｍｕｌｔｉｆｌｏｗ．ｔａｓｋ．Ｔａｓｋ；
ｉｍｐｏｒｔ ｃｏｍ．ｍｕｌｔｉｆｌｏｗ．ｔａｓｋ．ＴａｓｋＣｏｎｔｅｘｔ；
ｐｕｂｌｉｃ ｃｌａｓｓ ＭｙＴａｓｋ ｉｍｐｌｅｍｅｎｔｓ Ｔａｓｋ
｛ ｐｕｂｌｉｃ ｖｏｉｄ ｓｅｒｖｉｃｅ（ＴａｓｋＣｏｎｔｅｘｔ ｃｏｎｔｅｘｔ）；
｛ ／／ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｃｏｄｅ ｇｏｅｓ ｈｅｒｅ｝｝
このフォームでは、タスク１３８は、ｃｏｍ．ｍｕｌｔｉｆｌｏｗ．ｔａｓｋパッケージからＴａｓｋとＴａｓｋＣｏｎｔｅｘｔの両方をインポートしなければならない。タスク１３８のクラスは、タスク１３８のインタフェースを実装しなければならず、これは、１つのメソッド、ｓｅｒｖｉｃｅ（ＴａｓｋＣｏｎｔｅｘｔ）を定義する。タスク１３８が実行されると、そのサービス・メソッドで実行が開始する。このメソッドは、単一の引数、すなわち「ＴａｓｋＣｏｎｔｅｘｔ」インタフェースを実装するオブジェクトで呼び出される。このオブジェクトは、タスク・ライタに、エンジン１００を使って作業するための豊富なＡＰＩを与え、信号１４０の引数を調べ、修正するための方法を提供し、インスタンス１１０及び対応モデル用のデータ、及び信号１４０に対する信号ＡＰＩ呼出しを送信及びスケジューリングするためのデータを提供する。
【００３９】
上述のように、プロビジョニング・オペレーションを遂行するためのプロビジョニング・モデル１０２を定義するにあたっては、タスク１３８を遷移１３８に関連付け、ＵＲＬの形で完全にパケット化したＪａｖａのクラス名を指定することによりそれらを定義することができる。通常、これは、次の形のファイルＵＲＬになる。
【００４０】
ｆｉｌｅ：／／ｍｙＰａｃｋａｇｅ．ＭｙＰａｃｋａｇｅ
ｆｉｌｅ：／／ＵＲＬの場合は、ｈｔｔｐ：／／やｆｉｌｅ：／／などのＵＲＬプロトコルの接頭部を省くことができる。タスク１３８は、それぞれ別個のコードで定義されるため、それらをプロビジョニング・エンジン１００にロード、そこからアンロード、そこにリロードすることができる。
【００４１】
好ましい実施形態のあらゆるプロビジョニング・インスタンス１１０は、インスタンスに固有のデータを記憶するために使用することができるデータ・マップを保持している。このデータ・マップは、信号又はスケジュールＡＰＩ呼出しを使って信号引数を渡すために使用されるマップ構造と全く同じ形をとることができる。このインタフェースによって、インスタンスのデータ・マップにおけるエントリの照会、追加、修正、又は削除が可能になる。同様に、あらゆるプロビジョニング・モデル１０２は、モデル固有のデータを記憶するために使用することができるそれ自体のデータ・マップを有する。モデルのデータ・マップが、モデル１０２のすべてのインスタンス１１０に見えることに注意されたい。一般に、このマップは、モデル１０２のすべてのインスタンス１１０が共用しなければならない情報を記憶するために使用され、インスタンス１１０のデータ・マップは、この特定のインスタンス１１０にのみ関連する情報を記憶する。
【００４２】
上述のように、信号１４０がプロビジョニング・インスタンス１１０に送信されるとき、信号１４０には「信号引数」と呼ばれる任意のデータ・マップが伴う。これは、信号１４０の結果実行するどのタスク１３８にも利用可能になる。タスク１３８は、プロビジョニング・モデルの遷移１３０の定義の一部として指定される、第２の同様の１組の遷移引数にアクセスすることができる。より詳細には、下の表２に示すように、タスク１３８が遷移１３０に関連する場合はいつでも、任意のデータ・マップをタスク１３８に関連させることができる。
【００４３】
【表２】
2004505333.tif 000004
【００４４】
この例では、Ｔａｓｋ１は、２つの遷移１３０に関連する。Ｔａｓｋ１が、遷移１３０の第１を適用した結果、実行するならば、Ｔａｓｋ１には遷移引数｛ｃｏｍｍａｎｄ：ｓｔａｒｔ｝が供給される。しかし、Ｔａｓｋ１が、遷移１３０の第２を適用した結果、実行するならば、Ｔａｓｋ１には遷移引数｛ｃｏｍｍａｎｄ：ｓｔｏｐ｝が供給される。
【００４５】
遷移引数は、２つの主要な機能を有する。第１に、遷移引数によって、プログラマは、タスク１３８に１組のデフォルト引数を指定することができる。例えば、タスク１３８は、その信号引数中に期待するキー：値の対を見つけなかった場合、その遷移引数中でデフォルト定義を探すことができる。第２に、遷移引数によって、開発者は、そのタスクが何の機能を行うべきかを決定する遷移引数を指定することによって、異なる遷移中で異なる機能を実行するために同じタスク１３８を使用することができる。表２の例を参照すると、同じタスク１３８、すなわちＴａｓｋ１は、ある場合には、ある「開始」オペレーションを実行するように、別の場合には、ある「停止」オペレーションを実行するようにコード化することができる。
【００４６】
好ましい実施形態のプロビジョニング・エンジン１００内では、上記の表記法を拡張して使用している。したがって、プロビジョニング・エンジン１００は、例えば、表記を読み込んでＪａｖａデータ構造などのデータに変換するための、あるいは、逆に、データ構造を表記に変換するためのソフトウェア・モジュールであるパーサ２００を含んでいる。
【００４７】
単純な変換を使って、表記で信号を定義することができる。前述のシグナリングＡＰＩを思い出されたい。
【００４８】
Ｍａｐ ｓｉｇｎａｌ（Ｓｔｒｉｎｇ ｉｎｓｔａｎｃｅＩｄ， Ｓｔｒｉｎｇ ｓｉｇｎａｌ， Ｍａｐ ｓｉｇｎａｌＡｒｇｕｍｅｎｔｓ）；
このＡＰＩのｓｉｇｎａｌＡｒｇｕｍｅｎｔｓは、単なるマップなので、簡単に表記で表現することができる。ｉｎｓｔａｎｃｅＩｄ及びｓｉｇｎａｌを表現するには、新たにに２つのエントリをｓｉｇｎａｌＡｒｇｕｍｅｎｔｓマップに追加する。第１の新しいエントリは、ストリング「ｉｄ」をキーとし、ｉｎｓｔａｎｃｅｌｅｄ引数を含む。第２の新しいエントリは、ストリング「ｓｉｇｎａｌ」をキーとし、信号引数を含む。エンジン１００のパーサ２００は、特別なキー、ｉｄ及びｓｉｇｎａｌが定義されている表記マップを渡されると、その表記を適切な信号メソッド呼出しに変えて、そのメソッド呼出しを実行するロジックを含む。例示のために、表記法で定義された信号１４０の例を以下に示す。
【００４９】
｛ｉｄ：ｓｏｍｅＩｎｓｔａｎｃｅＩｄ
ｓｉｇｎａｌ：ｓｏｍｅＳｉｇｎａｌ
ｄａｔａ１：ｓｏｍｅＤａｔａ
．．．
｝
さらに、信号１４０がいつか後で実行されるようにスケジュールされている第２の例を以下に示す。
【００５０】
｛ｉｄ：ｓｏｍｅＩｎｓｔａｎｃｅＩｄ
ｓｉｇｎａ１：ｓｏｍｅＳｉｇｎａｌ
ｄａｔａ１：ｓｏｍｅＤａｔａ
ｄｅｌａｙ：１０００Ｌ
｝
好ましい実施形態では、パーサ２００は、これがスケジュール呼出し（すなわち、スケジュールされた時間に信号を実行する呼出し）なのか、あるいは信号呼出し（すなわち、即座に信号を実行する呼出し）なのかを、現在時刻から信号１４０が実際に送信されるまでの差をミリ秒で指定、又は信号１４０が送信される絶対時間を指定する、遅延キーやタイムスタンプ・キーなどがあるかないかにのみ基づいて判定する。エンジン１００を、完全にこのシグナリング用表記法を使ってプログラムすることもできる。しかし、このようなプログラミングは、同等のＪａｖａベースのＡＰＩ又は他のＡＰＩを使うよりも効率がよくない。
【００５１】
したがって、好ましい実施形態のプロビジョニング・エンジン１００は、ソフトウェア・モジュールとして、拡張可能ＡＰＩ２１０を含む。これは、ＲＭＩ（遠隔メソッド呼出し）、ＣＯＲＢＡ（一般オブジェクト要求ブローカー・アーキテクチャ）、ＤＣＯＭ（分散コンポーネント・オブジェクト・モデル）、及び様々なソケット・インタフェースなど、様々な異なるプロトコルを介して移送することができる。ＡＰＩ２１０は、完全に、上記の信号メソッドを介してアクセスすることができる。ＡＰＩ２１０は、一般的な管理機能のための管理ＡＰＩ２１２、及びインスタンスに固有の機能のためのコアＡＰＩ２１４で構成される。
【００５２】
アドミンＡＰＩ２１２は、「ルート・インスタンス」と呼ばれる特別な事前定義プロビジョニング・インスタンス１１０に「管理」信号を送信することによって呼び出される。好ましい実施形態のプロビジョニング・エンジン１００では、ルート・インスタンスは自動的にインストールされ、したがって常に利用可能である。ルート・インスタンスは、次の遷移を定義する。
【００５３】
［ａｄｍｉｎ （） （） ［Ａｄｍｉｎ］］
この遷移は、「管理」信号によってトリガされる。それは、ｆｒｏｍ状態１３４もｔｏ状態１３６も持っていず、したがって、この「管理」信号１４０を受信する以外、何も実行する条件を持っていない。その結果、事前定義ルート・インスタンスは、「管理」信号１４０を受信すると必ず、管理タスク１３８を実行する。管理タスク１３８自体は、管理ＡＰＩ２１２全体を提供することができる。タスク１３８は、しばしば、単一オペレーションを実行するように設計される。しかし、管理タスク１３８は、複数オペレーションを実行するように設計することもできる。それが実行する特定のオペレーションは、その「ｍｅｓｓａｇｅ」キーの値によって決定される。管理タスク１３８は、単に、このキーの値を抽出して、所望のオペレーションを実装するメソッドにディスパッチする。
【００５４】
例として、現在、あるエンジンに定義されているすべてのモデルのＩＤをリストアップする信号を以下に示す。
【００５５】
｛ｉｄ：ｒｏｏｔ
ｓｉｇｎａｌ：ａｄｍｉｎ
ｍｅｓｓａｇｅ：ｇｅｔＭｏｄｅｌｓ
｝
管理ＡＰＩ２１２で定義されているメソッドの多くは、「ｍｅｓｓａｇｅ」引数に加えて追加引数を期待している。例えば、キー／値の対をモデルのデータ・マップに書き込む「ｓｅｔＭｏｄｅｌＤａｔａ」メソッドは、以下のように、キー「ｍｏｄｅｌＩｄ」、キー、及び値を期待している。
【００５６】
｛ｉｄ：ｒｏｏｔ
ｓｉｇｎａｌ：ａｄｍｉｎ
ｍｅｓｓａｇｅ：ｓｅｔＭｏｄｅｌＤａｔａ
ｍｏｄｅｌＩｄ：ｓｏｍｅＭｏｄｅｌ
ｋｅｙ：ａＫｅｙ
ｖａｌｕｅ：（ｔｈｉｓ ｉｓ ａ ｓｅｔ）
｝
コアＡＰＩ２１２は、「コア」信号をいずれかのプロビジョニング・インスタンス１１０に送信することによって呼び出される。モデルが作成されると必ず、常に次の遷移がそれに追加される。
【００５７】
［ｃｏｒｅ （） （） ［Ｃｏｒｅ］］
これは、システム中のいずれかのインスタンスがコア信号１４０を受信すると必ず、コア・タスク１３８が実行することを意味する。管理タスク１３８と同様に、コア・タスク１３８も、多数のオペレーションを実装することができ、それが実行する特定のオペレーションは、その信号引数マップ中の「ｍｅｓｓａｇｅ」キーの値によって決定される。例として、キー／値の対をモデルのデータ・マップに書き込む信号を以下に示す。
【００５８】
｛ｉｄ：ｉｎｓｔａｎｃｅＩｄ
ｓｉｇｎａｌ：ｃｏｒｅ
ｍｅｓｓａｇｅ：ｓｅＤａｔａ
ｋｅｙ：ａＫｅｙ
ｖａｌｕｅ：［Ｉ ａｍ ａ ｌｉｓｔ］ ｝
好ましい実施形態は、プロビジョニング・エンジン１００にグラフィカル・ユーザ・インタフェースを提供するための、また、作業プロセス・オブジェクトを使って、オブジェクト指向でプロビジョニング・エンジン１００をプログラミングするためのソフトウェア・ツール２３０も含む。図３に示すように、ソフトウェア・ツール２３０は、プロセス・ブラウザ２４０（これによって、ユーザは、定義したモデル及びそれらのインスタンス１１０を表示し、いずれかのインスタンスの現在状態を問い合わせることができる）、タスク・ブラウザ２５０（これによって、ユーザは、タスク１３８のロード及びアンロードを行うことができ、また、ロードしたタスク１３８に関する情報を得ることができる）、モデル・ディベロッパ２６０（これによって、共通の状態マシン機能オブジェクトをまとめて作業プロセス・オブジェクトにし、その作業プロセス・オブジェクトをグラフィックとして処理してプロビジョニング・モデルを定義するオブジェクト指向手法を使って、モデルの開発を行うことができる）、インスタンス・モニタ２７０（これを使って、インスタンス１１０の実行を試験、制御、監視することができる）、及びワークスペース・ツール２８０（これは、上述のコマンド言語を使ってコマンドを直接、呼び出すことができるメカニズムを提供する）を含む。ソフトウェア・ツール２３０は、任意の適切なプログラミング言語で書くことができ、Ｗｉｎｄｏｗｓ９５（商標）、Ｗｉｎｄｏｗｓ９８（商標）、ＷｉｎｄｏｗｓＭＥ（商標）、Ｗｉｎｄｏｗｓ　ＮＴ（商標）、Ｗｉｎｄｏｗｓ２０００（商標）、ＵＮＩＸ、ＬＩＮＵＸなどの、任意の適切なオペレーティング・システムに移植することができる。ソフトウェア・ツール２３０は、通常、プロビジョニング・エンジン１００を走らせているコンピュータとネットワークを介して通信を行っているクライアント・コンピュータ上にインストールし、実行する。
【００５９】
図４は、モデル・リスト・ペイン２４２、インスタンス・リスト・ペイン２４４、及び現在選択されているモデル１０２又はインスタンス１１０に関する詳細情報を示す情報ペイン２４６で構成される、プロセス・ブラウザ２４０のスクリーン・ショットを示す。標準Ｗｉｎｄｏｗｓユーザ・インタフェースに従って、メニュー・バー２４８は、ファイル及び編集メニューを含む。ファイルメニューは、２つのグループに分割されている。１つのグループは、モデルの作成、削除及び編集のためのツールを提供し、もう１つのグループは、インスタンスに関する同じ選択を提供する。編集メニューは、テキスト編集用の標準的な切り取り、コピー、貼り付けの選択を含むことができる。
【００６０】
ユーザは、モデル１０２の上でマウスをクリックすることによって、モデル・リスト・ペイン２４２からモデル１０２を選択し、モデル１０２の遷移１３０及びデータを調べるか、又はモデル・ディベロッパ・ツール２６０（下記に詳述）を起動して、選択したモデル１０２を編集することができる。モデル・リスト・ペイン２４２からモデル１０２を選択すると、モデル１０２の遷移１３０及びデータがエンジン１００から取り出され、情報ペイン２４６の遷移タブの下に表示される。遷移タブ２４１をクリックすると、遷移１３０及びモデル１０２のデータ（例えば、上記に開示した表記法のフォームの文字列で）が表示される。モデル・データ・タブ２４３をクリックすると、モデル１０２のデータがツリー・ビューワの形で表示される。集合体データ型用の場合、表示は、マップ用の中括弧（｛ｎ｝）、リスト用の大括弧（［ｎ］）、セット用の括弧（（ｎ））で構成された画像になる。ここで、ｎは、集合体中の構成要素数を表す整数である。さらに、選択されたモデル１０２の個々のインスタンス１１０がデータベースから取り出され、インスタンス・リスト・ペイン２４２に表示される。
【００６１】
他の２つのＦｉｌｅメニュー項目は、モデル１０２を使った作業に専用の項目である。「ｃｒｅａｔｅ　ｍｏｄｅｌ」項目は、作成すべきモデル１０２のＵＲＬを要求する入力ダイアログを起動する。通常、これは、モデル・ディベロッパ２６０を使って作成されたモデルへのパスを示すファイルＵＲＬになる。典型的なファイルＵＲＬは、以下のフォームになる。
【００６２】
ｆｉｌｅ：／／ｆｉｌｅ ＿ ｐａｔｈ （例えば、「 ｆｉｌｅ：／／ｍｙＰａｔｈ／ｍｙＭｏｄｅｌ．ｗｄｌ 」 ）
変数「ｆｉｌｅ＿ｐａｔｈ」は、クライアント・マシンのファイル・システム上ではなく、プロビジョニング・エンジン１００を走らせているサーバのファイル・システム上で解決することができる。モデル１０２が、所与のＩＤを与えられて、すでにエンジン１００に存在している場合、継続する前にこの以前のモデル１０２を削除するか否かを、ダイアログ・ボックスがユーザにたずねてくる。既存のインスタンス１１０に関連するモデル１０２がすでに存在している場合は、ダイアログ・ボックスによって、継続する前にインスタンス１１０及びモデル１０２を削除するか否かのプロンプトが出される。「ｄｅｌｅｔｅ　ｍｏｄｅｌ」を選択すると、現在選択されているモデル１０２が削除される。このモデル１０２が既存のインスタンス１１０を有する場合は、ダイアログ・ボックスが、それらを削除するか否かをユーザにたずねてくる。プロセス・ブラウザ２４０からモデル・ディベロッパ２６０を起動するには、ユーザは、ファイル・メニューから「ｅｄｉｔ　ｍｏｄｅｌ」を選択すればよい。図５は、プロビジョニング・モデル１０２を、それぞれがオブジェクト３００を表す、相互接続されたアイコンの形態で表示している、モデル・ディベロッパ２６０のスクリーン・ショットである。図５のオブジェクト３００は、作業プロセス・オブジェクト、すなわち、電子メール・アカウントの設定など、特定のプロビジョニング作業プロセスを遂行するためにグループ化した状態マシンの機能である。あるオブジェクト３００は他のオブジェクトの内側にネストされており、したがって「サブオブジェクト」と呼ばれることに注意されたい。作業プロセス・オブジェクト及びそれらの配列について以下に詳説する。
【００６３】
ユーザは、インスタンス・リスト・ペイン２４４から、インスタンス１１０のデータを調べることができる。マウスをシングル・クリックして、インスタンス・リスト・ペイン２４４から個別のワークフローを選択することにより、選択されたインスタンス１１０のデータがエンジン１００から読み出され、情報ペイン２４６に表示される。例えば、１組の現在状態１２０、遷移１３０及びそれらのステータス、信号キュー、及び選択されたインスタンス１１０のデータを、階層ツリー構造のデータ・ビューで表示することができ、したがって、ブランチを拡大又は縮小することによって、望むだけ少なく又は多くを見ることができる。「ｃｒｅａｔｅ　ｉｎｓｔａｎｃｅ」ファイル・メニュー項目は、生成すべきインスタンス１１０のＩＤの入力を促す入力ダイアログ・ボックスを起動する。インスタンス１１０は、現在、選択されているモデル１０２に関連付けられる。ダイアログ・ボックスは、新たに生成されたインスタンス１１０に初期化信号を送付するべきかどうかをたずねるチェック・ボックスを含み得る。「ｄｅｌｅｔｅ　ｉｎｓｔａｎｃｅ」メニュー項目は、現在、選択されているインスタンス１１０を削除する。インスタンス１１０用のインスタンス・モニタ２７０（下記に説明）を起動するには、ユーザは、インスタンス・リスト２４４からインスタンス１１０を選択し、ファイル・メニューから「ｅｄｉｔ　ｉｎｓｔａｎｃｅ」を選択すればよい。図６は、以下に説明するように、相互接続されたオブジェクト３００（作業プロセス・オブジェクト）としてのインスタンス１１０、及びそれらのステータスを示す、インスタンス・モニタ２７０のスクリーン・ショットである。
【００６４】
タスク・ブラウザ２５０は、タスク１３８を監視するためのツールである。これによって、タスク１３８を、ロード、アンロードすることができ、また、現在、ロードされているタスク１３８に関する情報にアクセスするためにこれを使用することができる。図７に示すように、タスク・ブラウザ２５０の画面は、進行中のタスク１３８のリストを示すタスク・リスト・ペイン２５４、タスク・リスト・ペイン２５４で選択されている各タスク１３８の属性を示す属性ペイン２５６で構成されている。
【００６５】
タスク・ブラウザ２５０のメニュー・バーは、Ｌｏａｄ、Ｒｅｌｏａｄ、Ｅｘｐｉｒｅ、及びＣｌｏｓｅの４種類のメニュー選択ができるＦｉｌｅメニューを含む。Ｌｏａｄ及びＲｅｌｏａｄは、選択したタスク１３８のインストール又は再インストールするために使用する。「Ｅｘｐｉｒｅ」を選択すると、タスク１３８の選択した１つが削除、すなわちアンロードされる。Ｃｌｏｓｅは、タスク・ブラウザ２５０を閉じるために使用する。タスク１３８をインスタンス１１０にロードするには、ユーザは、ＦｉｌｅメニューからＬｏａｄを選択し、ロードすべきタスク１３８のクラス名を、ＵＲＬとしてダイアログ・ボックスに入力する。ＵＲＬは、例えば次のフォームになり得る。
【００６６】
「 ｆｉｌｅ：ｄ：／ｕｓｒ／ｘｙｚ／ｍｕｌｔｉｆｌｏｗ／ｃｏｍ．ａｂｃ．ｔａｓｋ．Ｍｙｔａｓｋ 」
タスク１３８をリロード又はアンロードするには、ユーザは、Ｆｉｌｅメニューから、それぞれ「ｒｅｌｏａｄ」又は「ｅｘｐｉｒｅ」を選択する。タスク１３８は、タスク・マップ中の属性「ＣａｎＥｘｐｉｒｅ」の値が真である場合にのみリロード又はアンロードすることができる。ワークフロー中に遷移１３０が発生すると、ユーザ定義のタスク１３８を実行する機会がある。ユーザ定義のタスクは、Ｊａｖａなど、タスク１３８に使用されているプログラミング言語が許容する限り、多様であり得る。上述のように、タスク１３８は、ワークフロー中の適用可能な遷移１３０に応答して実行する、任意のコード単位であり得る。Ｊａｖａを使ってタスク１３８をプログラムした場合、タスク１３８は、単に、タスク１３８のインタフェースを実装するＪａｖａのクラスであり得る。各ユーザ定義アクションは、上記のＡＰＩによって定義された１組の制約に適合したものでなければならない。
【００６７】
上述のように、状態マシンの機能を表すオブジェクト３００をアセンブルして、所与の時点において実行を開始し、何か特定のアクションがとられない限り、終了するまで順次に実行するという意味において、汎用プログラミング言語と同様に挙動するプロビジョニング・プロセス・ワークフローを生成することができる。オブジェクト３００の特定の型に応じて、ワークフローを、他のオブジェクト３００中にネストされている一連のサブオブジェクト３０２（以下、場合によっては、それらをともにオブジェクト３００と呼ぶ）を繰り返しループする、２つ又はそれ以上の独立したワークフローに分割することができる。プログラミング言語のフローとは異なり、好ましい実施形態の制御フローは、順方向にも逆方向にも実行することができる。すなわち、モデル１０２に基づくいずれかのワークフローは、あるワークを遂行すると、ロジックを逆の順に実行して、すでに終えたワークを取り消しながら、遡ることができる。この特徴は、遠隔通信のプロビジョニングにおいては重要となり得る。状態マシンの機能を表すオブジェクト３００は、電子メール・アカウントの設定、請求書アカウントの設定、モデム及びＰＣの情報の収集、ＤＨＣＰ構成など、どのようなプロビジョニング作業プロセスでも遂行するように構成することができる。また、プロビジョニング・モデルにフレキシビリティ及びパワーを追加するために、オブジェクト３００を「ｄｏ　ｗｈｉｌｅ」、「ｏｒ　ｓｐｌｉｔ」、又はその他の論理演算として構成することもできる。
【００６８】
いずれかのある一時点において、オブジェクト３００は、次の４種類の状態の１つのみの状態である。すなわち、ｎｏｔＤｏｎｅ（そのオブジェクトによって定義された作業がまだなされていないことを示す）、ｄｏｉｎｇ（そのオブジェクトによって定義されたいずれかの作業が現在なされていることを意味する）、ｕｎｄｏｉｎｇ（そのオブジェクトによってなされたいずれかの作業が現在、取り消されていることを示す）、及びｄｏｎｅ（そのオブジェクトの作業が完了し、制御が次のオブジェクト３００に移ったことを示す）。オブジェクト３００は、いつでも、信号「ｄｏ＿ｉｄ」又は「ｕｎｄｏ＿ｉｄ」に応答する。ここでｉｄは、単に、オブジェクト３００のＩＤである。オブジェクト３００は、ｄｏ＿ｉｄ信号１４０を受信したときにｎｏｔＤｏｎｅ状態であるならば、ｄｏｉｎｇ状態に遷移して、それが遂行すべき作業プロセスを開始する。オブジェクト３００は、ｄｏｉｎｇ状態のときにｄｏ＿ｉｄ信号１４０を受信すると、作業を続ける。同様に、オブジェクト３００は、ｄｏｎｅ状態のときにｕｎｄｏ＿ｉｄ信号１４０を受信すると、それが行ったいかなることも取り消し始める。オブジェクト３００は、ｕｎｄｏｉｎｇ状態のときにｕｎｄｏ＿ｉｄ信号１４０を受信すると、単に、その作業を取り消し続ける。したがって、いずれかのインスタンス１１０を通るワークフローは、いずれの方向にも可能であり、プロビジョニング作業プロセスは、遂行又は取消しが可能である。
【００６９】
オブジェクト３００は、その作業プロセスを終了するたびに、ｄｏｉｎｇ状態からｄｏｎｅ状態に遷移する。同時に、オブジェクト３００は、信号「ｄｉｄ＿ｉｄ」をワークフローに送信して、それが終了したことを他のオブジェクト３００に知らせる。同様に、オブジェクト３００は、その作業の取消しを終了するたびに、ｕｎｄｏｉｎｇ状態からｎｏｔＤｏｎｅ状態に遷移し、ワークフローにｕｎｄｉｄ＿ｉｄ信号を送信する。オブジェクト３００は、ｄｏｎｅ状態のときにｄｏ＿ｉｄ信号１４０を受信すると、単に、すでにプロビジョニング・プロセスを遂行したことを示すｄｉｄ＿ｉｄ信号１４０を送信するだけである。同様に、ｎｏｔＤｏｎｅ状態のときにｕｎｄｉｄ＿ｉｄ信号１４０を受信すると、単に、取消しを終了したこと（又は、もともと行われなかったこと）を示すｕｎｄｉｄ＿ｉｄ信号１４０を送信するだけである。最後に、オブジェクト３００は、ｕｎｄｏｉｎｇ状態のときにｄｏ＿ｉｄ信号１４０を受信すると、ｄｏｉｎｇ状態に遷移し、その作業プロセスを開始する。同様に、ｄｏｉｎｇ状態にあるときのｕｎｄｏ＿ｉｄ信号１４０は、ｕｎｄｏｉｎｇ状態への遷移をもたらし、いずれかのｕｎｄｏｉｎｇロジックに実行開始させる。
【００７０】
好ましい実施形態のプロビジョニング・モデル１０２は、他のいずれかが遂行される前に、まず初期化信号を受信する。初期化信号は、あらゆるオブジェクト３００をｎｏｔＤｏｎｅ状態に初期化し、ルート・シーケンスにｄｏ＿ｉｄ信号を送信する。これによって、ルート・シーケンスはｄｏｉｎｇ状態に入り、その作業プロセスを開始する。具体的には、モデルの構成における第１のオブジェクト３００にｄｏ＿ｉｄ信号を送信し、この第１のオブジェクト３００がｄｏｉｎｇ状態に入って、その作業プロセスを開始するようにさせる。
【００７１】
プロビジョニング・モデル１０２は、状態マシンの機能を表すオブジェクト３００を、所望のプロビジョニング作業プロセスを遂行するための所望のワークフローにアセンブルするためのモデル・ディベロッパ・ツール２６０を使って、パターン言語で開発される。図８は、モデル・ディベロッパ２６０のモデル開発画面を示す。モデル開発画面は、メニュー・バー３１０、オブジェクト・ツール・バー３２０、及びワークスペース３３０を含む。メニュー・バー３１０は、ファイル、編集、ビュー、及びツールメニューを含む。ファイルメニューは、ファイル・システムに、かつファイル・システムから、プロビジョニング・モデルを作成し、開き、保存するための「新規作成」、「開く」、「上書き保存」、「名前を付けて保存」メニュー項目を含む。Ｏｐｅｎ　Ｍｏｄｅｌを選択すると、エンジン・サーバのデータベースにインストールされているモデル１０２にアクセスすることができる。Ｉｎｓｔａｌｌ　Ｍｏｄｅｌを選択すると、モデル１０２がデータベースにロードされ、そこで、モデルは、新しいインスタンスの生成に使用するために利用可能になる。ビューメニューでは、モデルの構造の表示を使用可能及び使用不能にするトグルである、Ｓｈｏｗ　Ｓｔｒｕｃｔｕｒｅの選択だけができる。ツールメニューでは、他のソフトウェア・ツールの選択ができる。
【００７２】
オブジェクト・ツールバー３２０は、それぞれが、モデル１０２を構築するために利用可能な１組のオブジェクト３００を表す、複数のアイコンを含む。オブジェクト３００は、状態マシンのオペレーションのグループ、すなわち特定の論理機能を実行する遷移１０３である。オブジェクト３００は、図９に関連して下記に説明するように、それに信号タイプ１３２、タスク１３８、及びその他のパラメータを関連付けることによって、特定の作業プロセスを遂行するように構成することができる。アイコン４００で表されるＡｎｄＳｐｌｉｔＡｎｄＪｏｉｎオブジェクト３００は、ｄｏ＿ｉｄ信号を受信し、そのサブオブジェクト３０２（すなわち、ＡｎｄＳｐｌｉｔＡｎｄＪｏｉｎオブジェクト３００内にネストされているオブジェクト）のそれぞれに、ｄｏ＿ｉｄ信号を送信する。サブオブジェクト３０２は、次いで、それらの機能を並行して実行する（オペレーションの「及び分割（ａｎｄ　ｓｐｌｉｔ）」部分）。ＡｎｄＳｐｌｉｔＡｎｄＪｏｉｎオブジェクト３００は、そのサブオブジェクト３０２がすべてｄｏｎｅ状態に入る（オペレーションの「及び結合（ａｎｄ　ｊｏｉｎ）部分」と、初めて制御を移す。そのときにのみ、ＡｎｄＳｐｌｉｔＡｎｄＪｏｉｎオブジェクト３００は、ｄｉｄ＿ｉｄ信号１４０を送信する。ＡｎｄＳｐｌｉｔＡｎｄＪｏｉｎオブジェクト３００を取り消すことは、単に、このロジックを逆に行うことである。ここで言っている並行実行とは、諸サブオブジェクト３０２が、互いに独立して、それらの間に何もシーケンス上の制約なく実行することを意味する。これは、必ずしも、すべてのサブオブジェクト３０２が実際に同時に実行することを意味しない。
【００７３】
アイコン４１０で表されるＯｒＳｐｌｉｔＡｎｄＪｏｉｎオブジェクト３００は、制御を、所与の１組のサブオブジェクト３０２から選択されている即時サブオブジェクト３０２に渡す、スイッチのような働きをする（オペレーションの「又は分割（ｏｒ　ｓｐｌｉｔ）」部分）。選択されている即時サブオブジェクト３０２のそれぞれは、次いで、ｄｏ＿ｉｄ信号１４０を受信する。選択されている即時サブオブジェクト３０２のそれぞれは、次いで、ＯｒＳｐｌｉｔＡｎｄＪｏｉｎオブジェクト３００自体がｄｉｄ＿ｉｄ信号１４０を送信する前に、それらの実行を完了しなければならない（オペレーションの「そして結合（ａｎｄ　ｊｏｉｎ）」部分）。取消しの際、ｄｏｉｎｇ又はｄｏｎｅ状態にあるサブオブジェクトのみがｕｎｄｏ＿ｉｄ信号を受信する。ＯｒＳｐｌｉｔＡｎｄＪｏｉｎオブジェクト３００は、ここでＳｅｌｅｃｔＴａｓｋと呼ぶ一意のプロパティを有する。ＳｅｌｅｃｔＴａｓｋは、どのサブオブジェクト３０２が制御を受け取るべきかを決定するために実行されるタスク１３８である。ＳｅｌｅｃｔＴａｓｋは、実行されると、ｓｉｇｎａｌＭａｐと呼ばれるマップとして渡され、これは、オブジェクト３００のすべてのサブオブジェクト３０２の表示名を決定するために使用され得る。このマップは、タスク１３８の遷移引数からＳｉｇｎａｌＭａｐキーを抽出することにより得られる。
【００７４】
シーケンス・アイコン４２０は、あるサブオブジェクト３０２から次のサブオブジェクト３０２に、順次、制御を移すために使用されるオブジェクト３００を表す。シーケンス・オブジェクト３００は、ｄｏ＿ｉｄ信号１４０を受信すると、今度は、そのサブオブジェクト３０２のそれぞれにｄｏ＿ｉｄ信号を送信する。各サブオブジェクト３０２は、次いで、次のサブオブジェクト３０２がそのｄｏ＿ｉｄ信号１４０を受信できる前に、その作業を完了し、ｄｏｎｅ状態に遷移し、ｄｉｄ＿ｉｄ信号１４０を送信しなければならない。同様に、シーケンス・オブジェクト３００は、ｕｎｄｏ＿ｉｄ信号１４０を受信すると、その最後のサブオブジェクト３０２に、次いで前のサブオブジェクト３０２に、というように、シーケンス・オブジェクト３００の全作業が取り消されるまで、ｕｎｄｏ＿ｉｄ信号１４０を送信する。
【００７５】
ループ・アイコン４３０は、多くのプログラミング言語で見られる通常のルーピング構成にだいたい類似したオブジェクト３００を表す。一般に、このようなループは、条件付きロジックを繰り返し評価して、ループ本体を実行すべきかどうかを判定する。条件付きロジックが真であるならば、本体は実行される。条件付きロジックが偽であるならば、本体は実行されず、制御はループ後も続く。ループ・オブジェクト３００の場合の条件付きロジックは、１つ又は複数のタスク１３８によって提供される。ループ・オブジェクト３００の本体は、１つ又は複数のサブオブジェクト３０２で構成される。ループ・オブジェクト３００は、どのように構成されているかに応じて、ループ本体の前に条件付きロジックを有するｄｏ　ｌｏｏｐのように、あるいは、ループ本体の最後に条件付きロジックを有するｗｈｉｌｅ　ｌｏｏｐのように挙動する。ｄｏ　ｌｏｏｐとは異なり、ｗｈｉｌｅ　ｌｏｏｐは、常に、少なくとも１回はその本体を実行する。ｄｏ　ｌｏｏｐをつくるには、タスク１３８を、オブジェクト３００のプレ・タスクの値として指定する。あるいは、ｗｈｉｌｅ　ｌｏｏｐをつくるには、タスク１３８を、オブジェクト３００のポスト・タスクのプロパティの値として指定する。どちらの場合も、タスク１３８は、特定の成功又は失敗信号１４０を送信するコードを含むことができる。成功信号が送信されると、ｄｏ＿ｉｄ信号をループ本体に送信することにより、ループの実行が続く。失敗信号が送信されると、ループの実行は終了する。簡単に言えば、プレ・タスクは、オブジェクト３００がｄｏｉｎｇ状態に入る前に実行するタスク１３８であり、ポスト・タスクは、オブジェクト３００がｄｏｎｅ状態に入った後に実行するタスクである。ループ型オブジェクト３００の場合、プレ・タスクは、プロパティを定義し、その際、ループはｄｏ　ｌｏｏｐで実行し、ポスト・タスクは、プロパティをｄｏ　ｗｈｉｌｅループで定義する。
【００７６】
ブランチ・アイコン４４０は、ワークフローを２つの別個の独立した実行パスに分割するオブジェクト３００を表す。メイン・パスはモデル１０２中のブランチ・オブジェクト３００に続くオブジェクト３００に通じ、もう一方のパスはブランチ・オブジェクト３００のサブオブジェクト３０２に通ずる。ＡｎｄＳｐｌｉｔＡｎｄＪｏｉｎオブジェクト３００とは異なり、ブランチ・オブジェクト３００後のこの２つのパスは、再結合することはない。ＤｏＵｎｄｏアイコン４５０は、単一のプロビジョニング・アクションを実行するために使用されるオブジェクト３００を表す。下記に説明するＤｏオブジェクト３００とは異なり、ＤｏＵｎｄｏオブジェクト３００は、プロビジョニング・アクションを、それが実行された後に取り消すために、特定のアクションが必要とされる場合に使用される。例えば、プロビジョニング・アクションが、データベースにレコードを書き込むことであれば、その対応するｕｎｄｏアクションは、そのレコードを削除することであり得る。ＤｏＵｎｄｏオブジェクト３００は、ｄｏＴａｓｋ及びｕｎｄｏＴａｓｋの２つのタスク１３８を定義する。これらのタスクは、Ｄｏオブジェクト３００上で定義されているｄｏＴａｓｋと同様の働きをする。両方とも、成功信号１４０又は失敗信号１４０のいずれかをスケジュールするために必要とされる。取消しタスクは、失敗すると、後で実行するように再スケジュールされる。
【００７７】
Ｄｏアイコン４６０は、単一のプロビジョニング・アクションを実行するために使用されるオブジェクト３００を表す。それは、プロビジョニング・アクションを実行するためのコードを含む、「ｄｏＴａｓｋ」と呼ばれる単一のプロパティを定義する。ｄｏＴａｓｋは、プロビジョニング・アクションが成功したかどうかに応じて、特定の成功又は失敗信号１４０を送信するコードを含んでいなければならない。成功信号１４０が送信された場合には、Ｄｏオブジェクト３００は、ｄｏｎｅ状態に入り、ｄｉｄ＿ｉｄ信号１４０を送信する。しかし、プロビジョニング・アクションが失敗すると、Ｄｏオブジェクト３００は失敗信号１４０をスケジュールし、これによって、ｄｏＴａｓｋは未来のある時に再び実行する。一般に、失敗の場合、上述の非同期信号メッセージ（すなわち、ｓｃｈｅｄｕｌｅＡｔ又はｓｃｈｅｄｕｌｅＤｅｌａｙ）を使って、失敗信号１４０が未来のある時にスケジュールされる。Ｄｏオブジェクト３００のアクションは、「取消可能」ではない。具体的には、いったんＤｏオブジェクト３００がｄｏｎｅ状態に入ると、ほとんどの他のプロセス・オブジェクトができるようには、取消しすることはできない。このルールの例外は、Ｄｏオブジェクト３００がループのサブオブジェクト３０２の場合である。通常、Ｄｏオブジェクト３００は、決して取り消す必要がないアクションの場合に使用される。例えば、ウェブ・ページのＵＲＬをウェブ・サーバに戻すことである。
【００７８】
信号アイコン４７０は、特定の信号タイプ１３２の信号１４０がある外部ソースから受信されるまで、オブジェクト３００の実行のフローを中断するように設計されたオブジェクト３００を表す。通常、このソースは、ネットワーク・ベースのトランスポート・メカニズムを介して、プロビジョニング・エンジン１００と通信を行っている、ある外部クライアント・アプリケーションである。信号オブジェクト３００は、ｄｏｉｎｇ状態にある場合、期待信号１４０を受信するまでは何もしない。信号オブジェクト３００が受信を期待する特定の信号タイプ１３２は、信号オブジェクト３００のｄｏＳｉｇｎａｌプロパティの値である。この値は、デフォルトで「ｇｏ」に設定されているが、遂行されるべきアクションに適するように設定することもできる。ｄｏＳｉｇｎａｌプロパティが空ストリング「」に設定されている場合、信号オブジェクト３００は、異なった挙動をする。ｄｏＳｉｇｎａｌの値が受信されるまで実行が阻止される代わりに、制御のフローはプロセス・オブジェクト３００中で続く。より詳細には、ｄｏＳｉｇｎａｌが空ストリングであって、信号オブジェクト３００がｎｏｔＤｏｎｅ状態のときにｄｏ＿ｉｄ信号を受信したならば、それは、単にｄｏｎｅ状態に遷移し、ｄｉｄ＿ｉｄ信号を発行する。
【００７９】
信号オブジェクト３００はまた、取消し信号のプロパティも定義する。このプロパティが定義されると、プロセス実行のフローは、この値を有する信号１４０が受信されるまで信号オブジェクト３００で阻止される。プロパティが定義されないと、信号１４０は自動的に取り消される。すなわち、信号オブジェクト３００は、ｄｏｎｅ状態のときに取消し信号１４０が送信されると、単にｎｏｔＤｏｎｅ状態に遷移し、ｄｉｄ＿ｉｄ信号１４０を送信する。外部信号での遷移は、信号オブジェクト３００がｄｏｉｎｇ状態（ｄｏＳｉｇｎａｌの場合）又はｕｎｄｏｉｎｇ状態（ｕｎｄｏＳｉｇｎａｌの場合）の場合にのみ生じる。信号オブジェクト３００がｎｏｔＤｏｎｅ状態（又はｄｏｎｅ状態）のときに、インスタンス１１０が所与のｄｏ（ｕｎｄｏ）信号１４０を受信した場合、信号１４０は無視される。より簡単に言えば、これは、信号オブジェクト３００が、「準備完了」した場合、すなわち実行が渡された場合にのみ、信号１４０に反応することを意味する。
【００８０】
ターミナル・アイコン４８０は、オブジェクト３００の実行のフローを終了するオブジェクト３００を表す。ターミナル・オブジェクト３００は、ｄｏ＿ｉｄ信号１４０を受信すると、即座にｄｏｎｅ状態に遷移するが、ｄｉｄ＿ｉｄ信号１４０を発行しない。ターミナル・オブジェクト３００がシーケンスの一部であるならば、ターミナル・オブジェクト３００が実行されると、シーケンス中のその後のものは何も実行されない。ＤｏＴａｓｋなど、上記のタスク１３８は、前述のように、単一のタスクであっても、又は１組の複数タスク１３８であってもよい。
【００８１】
サブインスタンス・アイコン４７５は、サブインスタンスを生成するために使用される。図１３は、好ましい実施形態によるサブインスタンス８００の例を示す。サブインスタンス８００はモデル１０２と同様であり、オブジェクト３００で構成される。しかし、サブインスタンス８００は、モデル１０２のインスタンス１１０から遠隔に呼び出すことができ、したがって、プログラミング及びプロビジョニングにおいて、驚異的なフレキシビリティ、分配、効率が実現される。例えば、サブインスタンス８００を複数のインスタンス１１０から呼び出すことができ、したがって、コードの再使用が容易になる。さらに、サブインスタンス８００はそれら自体のスレッドで容易に実行することができ、したがって同時実行、すなわちマルチタスキングが提供される。サブインスタンス８００を使用することにより、複雑なプロビジョニング・プロセスを、より小さい、より管理し易い機能ユニットに分解することができる。これらのユニット、すなわちサブインスタンス８００は、いったん定義すると、他の実行しているインスタンス１１０から生成し、送信することができる。
【００８２】
具体的には、サブインスタンス８００は、ある呼出しインスタンス１１０から間接的に生成され、送信される、モデル１０２のインスタンスである。すべてのインスタンス化及びシグナリング・ロジックは、呼出しインスタンス１１０に埋め込まれているサブインスタンス・オブジェクト中に組み込まれる。どのモデル１０２も、どのインスタンス１１０からでもサブインスタンス８００としてインスタンス化することができる。サブインスタンス８００は、モデル１０２から除去され、独立したユニットとして実行されたオブジェクト３００のグループとみなすことができる。図１３は、信号アイコン４７０、２つのＤｏＵｎｄｏアイコン４５０、及びターミナル・パターン・アイコン４８０で表される４つのオブジェクト３００を含むモデル１０２の単純な例を示す。
【００８３】
図１４は、図１３のモデル１０２と同等の機能を有するが、２つの別個のモデル１０２に分解されている、モデル１０２を示す。第１のモデル１０２は、２つのＤｏＵｎｄｏアイコン４５０の代わりにサブインスタンス・アイコン４７５（サブインスタンス・オブジェクト３００を表す）を含む。第２のモデル１０２は、元の２つのＤｏＵｎｄｏアイコン４５０で構成されているが、サブインスタンス８００として実行するように、元のモデル１０２から取り出されている。
【００８４】
どのモデル１０２も、サブインスタンス８００として使用することができ、モデル１０２中に特別なコーディングは何も必要とされない。したがって、所与のモデル１０２は、状況に応じて、インスタンス１１０として、かつサブインスタンス８００として実行することができる。インスタンス１１０は、他のインスタンス１１０中のサブインスタンス・オブジェクト３００の遷移によって呼び出された場合、すなわち生成された場合は、常にサブインスタンス８００であるとみなされる。サブインスタンス８００が非常駐であることに注意されたい。それらは、それらの呼び出し側インスタンス１１０がｄｏｉｎｇ状態に遷移するたびにモデル１０２から自動的に生成され、それらの呼び出し側インスタンス１１０がｄｏｎｅ状態に遷移するたびに自動的に除去される。
【００８５】
より詳細には、サブインスタンス８００のライフ・サイクルは、サブインスタンス・オブジェクト３００がＤｏ信号を受信するたびに開始する。サブインスタンス・オブジェクト３００はｄｏｉｎｇ状態に入り、次いで、そのサブインスタンスＵＲＬ（下記に詳述する）を調べて、何のモデル１０２のインスタンス化すべきか、すなわち何のモデル１０２を実行するために呼び出すか、及び、そのインスタンス化を行うために、何のネットワーク・サービスを呼び出すべきかを決定する。多くの場合、サブインスタンス８００が、呼び出し側サブインスタンス・オブジェクト３００を有するモデル１０２と同じプロビジョニング・エンジン１００上でインスタンス化される。しかし、ＵＲＬを使ってサブインスタンス８００を定義すると、サブインスタンス８００を任意の適切なプロビジョニング・エンジン１００上で、遠隔からインスタンス化することができる。
【００８６】
サブインスタンス８００がインスタンス化されると、そのルート・インスタンスに初期化信号１４０が送られる。ルート・インスタンス中の遷移１３０は、サブインスタンス８００中のすべてのオブジェクト３００をｎｏｔＤｏｎｅ状態に設定し、次いで、ｄｏ信号をサブインスタンス８００に送信して、その実行を開始する。呼び出し側サブインスタンス・オブジェクト３００は、サブインスタンス８００のルート・インスタンスがｄｏｎｅ状態に遷移するまで、ｄｏｉｎｇ状態のままである。この時点で、呼び出し側サブインスタンス・オブジェクト３００は、それ自体のｄｏｎｅ状態に入り、呼び出されているサブインスタンス８００を除去する。
【００８７】
呼び出し側サブインスタンス・オブジェクト３００が、ｄｏｉｎｇ状態のときに受信したｄｏ又はｕｎｄｏ信号は、いずれも呼び出されているサブインスタンス８００にリレーされる。これら２つの信号に関して、呼び出されたサブインスタンス８００は、ちょうど呼び出し側インスタンス１１０中でインラインにコード化されているかのように挙動する。サブインスタンス８００のルート・インスタンスは、ｄｏｎｅ状態に入ると、その呼び出し側インスタンス１１０に信号を送って、それがそれ自体のｄｏｎｅ状態に入るようにさせる。呼び出されたサブインスタンス８００は、このとき、作業を終了し、信号１４０によって呼び出し側インスタンス１１０から除去される。
【００８８】
サブインスタンス・オブジェクト３００は、上記のロジックとは逆の方法でｕｎｄｏ信号に応答する。サブインスタンス・オブジェクト３００は、ｕｎＤｏｉｎｇ状態に遷移するたびに、指定されたモデル１０２のインスタンス１１０として、サブインスタンス８００を生成する。サブインスタンス８００は、初期化解除信号で実行され、そのパターンのすべてをｄｏｎｅ状態に設定し、呼び出し側インスタンス１１０にｕｎｄｏ信号を送信する。最後に、サブインスタンス８００のルート・インスタンスがｎｏｔＤｏｎｅ状態に入ると、サブインスタンス・オブジェクト３００がそれ自体のｎｏｔＤｏｎｅ状態に入り、サブインスタンス８００を除去する。
【００８９】
好ましい実施形態のサブインスタンス８００を制御する信号１４０は、上述のように、すべての信号１４０と同じセキュリティ・メカニズムを通る。これは、サブインスタンス・オブジェクト３００が、サブインスタンス８００を生成できる前に、サブインスタンス８００が実行されるエンジン１００と共に認証することができることを意味する。呼び出し側インスタンス１１０と同じホスト上で走っているローカル・サブインスタンス８００の場合、呼び出し側インスタンス１１０は、単に、それ自体のセキュリティ・クリデンシャルを渡して、サブインスタンス８００を生成することができるので、これは、きわめて直送式のプロセスである。しかし、遠隔から実行するサブインスタンス８００の場合、サブインスタンス８００は、明示ａｕｔｈｅｎｔｉｃａｔｅＵｓｅｒ信号を送信して、そのクリデンシャルを確立しなければならない。
【００９０】
モデル・ディベロッパ２６０は、このセキュリティ・メカニズムをトランスペアレントに処理する遷移１３０を含むオブジェクト３００を含むことができる。すなわちさらなるプログラミング又は構成は必要ない。好ましい実施形態では、エンジン１００の構成マップ引数は、以下に示すように、サブインスタンス・オブジェクト３００がエンジン１００に対する（遠隔からの可能性もある）認証を得るために使用することができる、２つのキー、ｓｕｂｉｎｓｔａｎｃｅｌｏｇｉｎ及びｓｕｂｉｎｓｔａｎｃｅｐａｓｓｗｏｒｄを定義することができる。
【００９１】
ｓｕｂｉｎｓｔａｎｃｅｌｏｇｉｎ： ｛ｖａｌｕｅ：ｓｏｍｅＵｓｅｒＩｄ｝
ｓｕｂｉｎｓｔａｎｃｅｐａｓｓｗｏｒｄ：｛ｖａｌｕｅ：ｓｏｍｅＰａｓｓｗｏｒｄ｝
このログインとパスワードの対は、サブインスタンス８００が、呼び出し側インスタンス１１０のエンジン１００に対する認証を得るために使用することもできる。従って、サブインスタンス８００を介して互いに信号を送るすべてのエンジン１００は、これらのキーについて同一の値を持っているべきであり、これらのキーは、これらのエンジン１００すべてに対して有効なログイン／パスワード対を表すべきである。多くの場合、サブインスタンス８００は、呼び出し側インスタンス１１０からの入力データを必要とする。同様に、サブインスタンス８００は、実行を終えた後、呼び出し側インスタンス１１０に戻す必要がある出力データを持っている可能性がある。どちらの場合も、このようなデータは、上記の方法で信号引数に渡すことができる。
【００９２】
データをサブインスタンス８００に渡すために、サブインスタンス・オブジェクト３００がｄｏｉｎｇ状態に遷移する前に、入力データを、呼び出し側インスタンス１１０中の信号引数に書き込むことができる。この時点より前に実行する、呼び出し側インスタンス１１０中のいずれかの都合のよいタスク１３０が、この機能を実行することができる。ただし、サブインスタンス・オブジェクト３００は、特にこの目的のために設計され、サブインスタンス８００が生成される直前に実行するプレ・タスクを含むこともできる。
【００９３】
呼び出し側インスタンス１１０の信号引数中のどのデータも、そのサブインスタンス・オブジェクト３００がｄｏｉｎｇ状態に遷移する時点で、呼び出されたサブインスタンス８００の信号引数中へコピーすることができる。このデータは、次いで、信号引数として、サブインスタンス８００の第１のタスク１３８が利用できるようになる。もちろん、このタスク１３８がその信号引数を伝播するならば、データは次に続くタスク１３８にも利用可能になる。プレ・タスクは、サブインスタンス８００が要求に応じて、信号引数を追加するように動作可能である。サブインスタンス８００からその呼び出し側インスタンス１１０に出力データを戻して渡すためには、サブインスタンス８００が実行を終えたとき、すなわち、サブインスタンス８００の呼び出されたルート・インスタンスがｄｏｎｅ状態に遷移したときに、そのデータを信号引数中に定義しなければならない。呼び出し側サブインスタンス・オブジェクト３００では、サブインスタンス・オブジェクト３００がｄｏｎｅ状態に入った後に実行する第１のタスク１３８は、その信号引数中にデータを見つける。
【００９４】
サブインスタンス８００のポスト・タスクは、このようなタスク１３８を位置付けるのに便利な場所である。非ヌルの場合、ポスト・タスクは、サブインスタンス・オブジェクト３００がｄｏｉｎｇ状態からｄｏｎｅ状態に遷移した後、サブインスタンス８００が除去される直前に、実行する。サブインスタンス８００のルート・インスタンスがｄｏｎｅ状態に遷移したときにサブインスタンス８００の信号引数に書き込まれたデータはどれも、ポスト・タスクの信号引数に利用可能になる。
【００９５】
プレ・タスク同様、サブインスタンス８００のポスト・タスクも、それ自体が成功又は失敗信号を送信するべきではない。その唯一の目的は、サブインスタンス８００の要求に応じて、信号引数を入手することである。成功及び失敗信号によって提供される順序付けは、サブインスタンス・オブジェクト３００中に定義されている遷移によって暗黙に提供される。
【００９６】
デフォルトで、モデル・ディベロッパは、サブインスタンス・オブジェクト３００のポスト・タスクのプロパティに以下のデフォルト値をインストールする。
【００９７】
ｃｏｍ．ｗｉｄｇｅｔ．ｔａｓｋＣｏｒｅ ｛ｍｅｓｓａｇｅ：ａｐｐｌｙ ｝
このメッセージは、信号引数中で、キー、ｉｎｓｔａｎｃｅ：及びｍｏｄｅｌ：を探す。どちらも定義されている場合は、それらの値を、呼び出し側インスタンス１１０のインスタンス・データ・マップ及び／又はモデル・データ・マップに適用するリストとして取る。この技術は、呼び出されたサブインスタンス８００の信号引数と、呼び出し側インスタンス１１０のモデル・データ・マップの間のブリッジとして機能する。これによって、データ、及びサブインスタンス８００中で計算された結果は、呼び出し側インスタンス１１０に対応するインスタンス・データ・マップ及び／又はモデル・データ・マップを容易に修正することができる。
【００９８】
モデル・ディベロッパ２６０では、図１５に示すパターン・インスペクタ画面を使って、サブインスタンス８００としてモデル１０２が実行されるようにサブインスタンスＵＲＬ８０２を指定することにより、各サブインスタンス・オブジェクト３００を構成することができる。サブインスタンスＵＲＬ８０２のプロトコル、ホスト、及びポート部分は、エンジン・サービス、したがって、サブインスタンス８００が実行されるホスト・エンジン１００を指定する。サブインスタンス８００自体は、サブインスタンスＵＲＬ８０２のクエリ・ストリングとして指定されたデータ・マップ中に定義される。このデータ・マップは、サブインスタンス８００のモデル１０２を指定するストリング値のキーを含むことができる。エンジンは、マップ中のその他のキー：値の対をどれも無視するが、アプリケーション固有の用途のために生成されたサブインスタンス８００には利用可能である。
【００９９】
エンジン１００では、サブインスタンスＵＲＬ８０２のプロトコル部分は、常に、デフォルトがローカルになっている。したがって、その呼び出し側インスタンス１０２と同じエンジン１００中に生成されるサブインスタンスＵＲＬ８０２は、以下のようにクエリ・ストリング・ストックを指定する必要があるだけである。
【０１００】
？｛ｓｕｂｉｎｓｔａｎｃｅ：ａＭｏｄｅｌＩｄ｝
多くの場合、サブインスタンスＵＲＬ８０２は、「ｐｒｐ：」擬似プロトコルを使って便利に指定することができる。このプロトコルは、以下に示すように、サブインスタンスＵＲＬ８０２のファイル部分をエンジン１００の構成引数中のキーとして使用し、次いで、関連する値をルックアップすることにより解決される。
【０１０１】
ｐｒｐ ＵＲＬ： ｐｒｐ：ｓｏｍｅｋｅｙ
ＣｏｎｆｉｇＡｒｇｓ：
ｓｏｍｅＫｅｙ：｛ｖａｌｕｅ：”ｓｏｃｋｅｔ：／／ｓｐａｒｋｙ：１０６７？｛ｓｕｂｉｎｓｔａｎｃｅ：ａＭｏｄｅｌＩｄ｝” ｝
ｐｒｐ：擬似プロトコルは、サブインスタンス８００の実装モデル１００の最終指定を構成引数メカニズムに任せて、間接の一形態を提供する。ｐｒｐ：ＵＲＬを別のｐｒｐ：ＵＲＬに分解させて、２重（３重、４重など）の間接を提供することさえ可能である。無限ループを防ぐために、エンジンは、このような間接の総数を、例えば考案した値、１０までに制限することができる。
【０１０２】
サブインスタンスＵＲＬ８０２を、対応するサブインスタンス・オブジェクト３００用に、パターン・インスペクタ・ウィンドウ中で指定することができる。しかし、サブインスタンスＵＲＬ８０２を、タスク１３８のコード中に動的に指定することも可能である。サブインスタンス・オブジェクト３００の遷移がｎｏｔＤｏｎｅからｄｏｉｎｇに遷移する間に、サブインスタンスＵＲＬのキー、ｃｏｍ．ｗｉｄｇｅｔ．ｕｔｉｌ．ＥｎｇｉｎｅＣｏｓｔａｎｔｓを信号引数中に定義すると、この信号引数の定義は、パターン・インスペクタ中のサブインスタンスＵＲＬのプロパティの設定よりも優先する。ほとんどの場合、これは、サブインスタンス・オブジェクト３００のプレ・タスク中で信号引数キーを設定することによってなされる。
【０１０３】
好ましい実施形態のエンジン１００においては、あらゆるインスタンス１０２は、シングルスレッドである。タスク１３８は、ＯｒＳｐｌｉｔＡｎｄＪｏｉｎ又はＡｎｄＳｐｌｉｔＡｎｄＪｏｉｎオブジェクト３００内に埋め込まれている場合にさえも、必ずしも並行して実行するわけではない（ただし、分割ブランチ中のいずれかのタスク１３８がスケジュールされた再試行で失敗した場合には、制御は直ちに他のブランチの１つに移る）。このセマンティックによって、プログラマの仕事が簡略化される。これにもかかわらず、本発明は、マルチスレッド機能を有している。
【０１０４】
しかし、呼び出されたサブインスタンス８００のそれぞれがそれ自体のスレッド中で実行するため、サブインスタンス８００は、好ましい実施形態のモデル１０２に、真の同時並行、すなわちマルチスレッディング機能を提供する。分割されたオブジェクト３００の１つのＤｏ及びＤｏＵｎｄｏオブジェクトをサブインスタンス８００と置き換えることは、同時並行をうまく利用している。
【０１０５】
好ましい実施形態では、サブインスタンス・オブジェクト３００及びその呼び出されたサブインスタンス８００の間に生じるシグナリングのすべてが非同期である。これは、分散スレッド及び非分散スレッド両方のデッドロックの可能性を著しく軽減する。サブインスタンス８００中のユーザ定義のタスク１３８が、その呼び出し側インスタンス１０２を同期信号で呼び出すときは必ず、スレッドのデッドロックが現実に起こり得ることになる。この理由から、サブインスタンス８００と他のインスタンス１０２の間のすべての通信が、上記のように信号引数を介して行われることが好ましい。
【０１０６】
ワークスペース３３０は、オブジェクト３００のパターン言語で、モデル１０２を実際に構築する場所である。ユーザがツール・バー３２０中のアイコンをクリックすると、カーソルは十字線、又はオブジェクト３００を表すアイコンが選択されていることを示す他のインジケータに変わる。ワークスペース３３０の内側をクリックすると、対応するオブジェクト３００がモデル１０２中へ挿入される。モデル１０２は、表示にも非表示にもできる下にある構造で表示することができる。この構造が表示される場合、モデル１０２は、図５及び６に示すように、一連の積み上げた長方形として表示される。あるいは、図９に関連して以下に説明するように、この構造を非表示にして、下にあるモデルの別のビューを表示させることもできる。ツール・メニューのＨｉｄｅ　Ｓｔｒｕｃｔｕｒｅ／Ｓｈｏｗ　Ｓｔｒｕｃｔｕｒｅボタンで、この２種類のビューを切り替えることができる。
【０１０７】
オブジェクト３００の順番は、オブジェクト３００をマウス・クリックし、ワークスペース３３０中の所望の位置にマウス・ドラッグすることにより、モデル１０２中で再配列することができる。ワークスペース３３０中のすべてのレイアウトは自動的に行われる。具体的には、ドラッグ操作の後、マウス・ボタンを放すと、モデル・ディベロッパ・ツール２６０が、オブジェクト３００をどこに配置すべきかを正確に決定する。例えば、「ａｌｉｇｎ　ｔｏ　ｇｒｉｄ（グリッドに合わせる）」機能を使用することができる。多くのオブジェクト３００を互いの上に積み重ねて、オブジェクト３００中にサブオブジェクト３２０をネストさせることができる。このような積み重ねの深さについて制限はない。モデル・ディベロッパ・ツール２６０はオブジェクト３００を左から右に、上から下にレイアウトする。ワークスペース３３０中でオブジェクトの１つをクリックすると、そのオブジェクト３００が選択される。いつでも、現在選択されているオブジェクト３００を、凹んだ囲み枠や強調表示などで識別することができる。さらに、各オブジェクト３００は、オブジェクト３００の型、及びそれに続くマシン生成文字シーケンスで構成される一意の識別子を有する。現在、選択されている（又は、複数選択の場合は、最初に選択されている）オブジェクト３００の識別子は、モデル・ディベロッパ・ツール２６０の画面のツールの左下角に表示される。
【０１０８】
図９は、現在のモデルのオブジェクト３００を表形式で表示し、オブジェクト３００が、特定のプロビジョニング作業プロセスに構成されるように、すなわち、作業プロセス・オブジェクトを構成するようにすることができる、モデル・ディベロッパ・プロパティ画面を示す。モデル・ディベロッパ・プロパティ画面では、各オブジェクト３００について、コラム５１０にオブジェクト３００の型（タイプ）が表示される。プログラマは、オブジェクト３００の表示名を指定することにより、そのオブジェクトのプロビジョニング・プロセスをコラム５２０に記載することができる。オブジェクト３００のさらに詳細な説明を、コラム５３０に入力することができる。オブジェクト３００のタスク１３８は、５４０に入力して表示させることができる。オブジェクト３００のプレ・タスクはどれもコラム５５０に、ポスト・タスクはどれもコラム５６０に入力して表示させることができる。オブジェクト３００を強調表示すると、その表示名、説明、及びタスク１３８が、編集用の編集ペイン５９０に表示される。画面の右下角にある適用ボタン５７０をクリックすると、編集が受諾される。リセットボタン５８０をクリックすると、編集ウィンドウ中でなされたどのような変更も無視され、クリアされる。オブジェクト３００のタスクは、上述のフォームになり得、オブジェクトが遂行するプロビジョニング作業を決定することに留意されたい。例えば、図９の強調表示されたＤｏ　Ｕｎｄｏオブジェクト３００のＤｏＴａｓｋは、ウィンドウ５９０中のＪａｖａコードの呼び出しとして表示されている。
【０１０９】
オブジェクト３００をダブル・クリックすると、選択したオブジェクト３００に関連するプロパティのリストが表示される。これらのプロパティのいくつかは、好ましくは読み取り専用であるが、多くは編集することができ、モデルが動作する方法に影響を与える。すべてのオブジェクト３００は共通の１組のプロパティを共用し、これらは調べることができ、場合によっては編集することができる。編集できるプロパティには、ｃｏｌｏｒ（オブジェクト３００を表すアイコンを表示するカラーを指定するために使用される）及びｄｉｓｐｌａｙＮａｍｅ（オブジェクト３００の意味のあるラベルを指定するために使用され、例えば、図６に示すように、画面上に、オブジェクト３００を表すアイコンの最上部に横に表示される）が含まれる。好ましくは変更できないプロパティには、ｉｄ（エンジン１００がオブジェクト３００に割り当てる一意のＩＤ）及びｔｙｐｅ（対応するオブジェクト３００の型を識別）が含まれる。
【０１１０】
図１０に示すように、インスタンス・モニタ２７０の表示は、インスタンス・モニタ２７０がモデル１０２の特定のインスタンス１１０にリンクされていることを除けば、モデル・ディベロッパ２６０の表示と同様である。いかなる時点においても、インスタンス１１０に含まれるすべてのオブジェクト３００は、４種類の現在状態のうち１つ、すなわちｎｏｔｄｏｎｅ、ｄｏｉｎｇ、ｕｎｄｏｉｎｇ、又はｄｏｎｅでなければならない。オブジェクト３００は、多くの他の状態であることもできるが、しかし、常に、それら４状態のうちの１つでなければならない。インスタンス・モニタ２７０に表示されるあらゆるオブジェクト３００は、これら４状態のそれぞれに対応する４つのボタン６０２、６０４、６０６、及び６０８を表示する状態アイコン６００を有する。各オブジェクト３００の現在状態に対応するアイコン６０２、６０４、６０６、又は６０８が強調表示されて、オブジェクト３００の現在状態を知らせる。ボタン６０４及び６０６は「クリック可能」である。ボタン６０４をクリックすると、関連するオブジェクト３００にｄｏ＿ｉｄ信号１４０が送信され（そのオブジェクトの機能を遂行するために）、ボタン６０６をクリックすると、関連するオブジェクト３００にｕｎｄｏ＿ｉｄ信号１４０が送信される（その機能を取り消すために）。もちろん、これは、操作中のモデルを妨害することを避けるために、インスタンス１１０のテスト・フォームでのみ試みるべきである。
【０１１１】
図１１に示すように、ワークスペース・ツール２８０は、ディスクからのテキスト・ファイルのロード及び保存、カット・アンド・ペースト、行番号指定などを含め、通常のテキスト編集機能を備えたテキスト編集ウィンドウ２８２を提供する。さらに、「コマンド・テキスト」と呼ばれる任意の一片のテキストを選択して、プロビジョニング・エンジン１００に送って、解釈及び実行させることができる。コマンド・テキストをエンジン１００に送るには、ユーザは、「選択を送信」ボタン２８４をクリックする。コマンド・テキストの実行後、プロビジョニング・エンジン１００から応答を返してきた場合には、それは、コマンド・テキストの直後にテキストとして挿入される。何も応答がない場合は、代わりに空ストリングが挿入される。コマンド・テキストは選択解除され、応答が選択される。ワークスペースからこの応答を除去するには、ユーザは、エンター又はバックスペース・キーを押して、それを削除すればよい。プロビジョニング・エンジン１００は、例外の形でエラーを返す。ワークスペース・ツール２８０は、例外を受け取ると、その例外の型を説明のテキスト（例外メッセージ）とともにポップアップ・ウィンドウに表示する。このウィンドウが終了すると、例外メッセージ自体はコマンド・テキストの直後にテキストとして挿入され、選択される。ワークスペース・ツール２８０によって、オペレータは、単に、他のＧＵＩコンポーネントにより操作が容易になっているＡＰＩのサブセットだけでなく、ＡＰＩ全体にアクセスすることができる。
【０１１２】
ワークスペース・ツール２８０はまた、マップ、リスト、及びセットを含めて、完全な構文ユニットを自動的に選択する機能も有する。含まれているマップ、リスト、又はセット全体の選択は、そのようなユニットの内側をコントロール・キーを押しながらクリックすることにより行うことができる。そのようなユニット内をシフト・キーを押しながらクリックしても同様の機能が提供されるが、選択されているユニットも送られる。ワークスペース・ツール２８０を使用するには、上記のシグナリング表記法について、及び、上記に詳説したように、言語をどのように使ってエンジン１００のＡＰＩ２１０を形成する信号を定義するかについて理解する必要がある。エンジン１００のＡＰＩ２１０には、上記のシグナリング・インタフェースを介してアクセスする。
【０１１３】
ユーザが、デバッギングやトラブルシューティングのために、エンジン１００によって実行されているアクションを調べることができるように、ログ・ビューワ画面（図１２）を提供することができる。エンジン１００は、そのアクション（「イベント」と呼ばれる）を、カテゴリに基づいて、様々なファイル及び出力ストリームに書き出すことによって記録する。ログ・ビューワ画面７００は、これらのログのどれでも表示することができるユーザ・インタフェースであり、ログ・イベント・リスト表７０２及び情報テキスト・エリア７０４で構成される。タイトル・バー７０４には、括弧で囲んだイベント・カテゴリ、及びそのログが適用されるエンジン１００が一覧表示される。メニュー・バー７０８には、ファイル、ビュー、ツールの選択メニューが表示される。イベント・リスト表７０２は、イベントのカテゴリ及び時間、及びイベント・メッセージが記載される３つのコラムに分けられたログのリストを含む。このリストは、該当するコラムをクリックすることにより、これらのどの要素の順にでもソートすることができる。２度目にクリックすると、リストが逆にソートされる。リスト中のいずれかのイベントを選択すると、それが強調表示され、情報テキスト・エリアに説明又は追加情報が表示される。
【０１１４】
エンジン１００のイベントを追跡するためにログすることができるイベント・カテゴリは複数ある。カテゴリは、システムによる事前定義、又はユーザによる定義が可能である。カテゴリを所望に定義して、ユーザに様々な状況が警告されるようにすることができる。ログをフィルタにかけて、かつ／又は関連する情報の解析を期待することができる。
【０１１５】
以下は、このようなカテゴリの例である。
【０１１６】
ＦＡＴＡＬ：これらは、エンジン１００の致命的なシャットダウンを引き起こしたイベントである。
【０１１７】
ＣＲＩＴＩＣＡＬ：これらは、エンジン１００の終了を引き起こしてはいないが、それでもエンジン１００の動作に致命的であるとみなされるログ・イベントである。
【０１１８】
ＷＡＲＮ：これらは、特に注意する必要はあるが、クリティカル・イベントほどの心配はないイベントである。
ＴＡＳＫ＿ＥＸＣＥＰＴＩＯＮ：期待通りに実行しなかったタスクである。
ＬＯＧ：エンジン１００の実行において正常なイベント。
ＤＥＢＵＧ：エンジン１００のデバッギングに役立つイベント・メッセージ。
【０１１９】
本発明が、オブジェクト指向のパターン・プログラミング言語、及び関連するプロビジョニング・エンジン用グラフィカル・インタフェースを提供することがわかるであろう。１組の複数の状態、及びタスクを後で実行するようにスケジュールできる能力を有する状態マシンを使用することにより、プロビジョニング・エンジンは、作業プロセスを、時間を考慮した方法で遂行し、制御することができる。プロビジョニング・エンジン及びパターン言語は、いかなる言語で書いたコンピュータ・ソフトウェアとしても実装することができ、また、いかなる適切なハードウェア・プラットフォーム上でも実行することができる。様々な信号、データ、マップなどはどのような型又はプロトコルのものでもかまわない。遷移又は他の状態マシンをいずれかの適切な方法で結合して、様々なプロビジョニング機能又は作業プロセスを実行するオブジェクトを定義することができる。様々なタスクを、状態マシンによって定義及び実行することが可能である。信号を、どのような方法で、どのような適切な装置によっても生成することができる。
【０１２０】
本発明を、好ましい実施形態及び図面によって説明してきた。しかし、添付の請求項及びその法的に同等なものの範囲から逸脱することなく、様々な変更を施すことができることが、当業者には明らかであろう。
【図面の簡単な説明】
【図１】
好ましい実施形態によるプロビジョニング・エンジンの構成図である。
【図２】
信号に応答する適用可能遷移のアクションを示す、図１のプロビジョニング・エンジンの構成図である。
【図３】
好ましい実施形態のソフトウェア・ツールの構成図である
【図４】
好ましい実施形態のプロセス・ブラウザの画面を示す図である。
【図５】
好ましい実施形態のモデル・ディベロッパのモデル表示画面を示す図である。
【図６】
好ましい実施形態のインスタンス・モニタの画面を示す図である。
【図７】
好ましい実施形態のタスク・ブラウザの画面を示す図である。
【図８】
好ましい実施形態のモデル・ディベロッパのモデル開発画面を示す図である。
【図９】
好ましい実施形態のモデル・ディベロッパ・プロパティ画面を示す図である。
【図１０】
好ましい実施形態のインスタンス・モニタの画面を示す図である。
【図１１】
好ましい実施形態のワークスペース・ツールの画面を示す図である。
【図１２】
好ましい実施形態のログ・ビューワ画面を示す図である。
【図１３】
好ましい実施形態による単純なモデルを示す図である。
【図１４】
図１３のモデルと同等の単純なモデル及びサブインスタンスを示す図である。
【図１５】
好ましい実施形態のモデル・ディベロッパのパターン・インスペクタ画面を示す図である。
【図１】
2004505333.tif 000005
【図２】
2004505333.tif 000006
【図３】
2004505333.tif 000007
【図４】
2004505333.tif 000008
【図５】
2004505333.tif 000009
【図６】
2004505333.tif 000010
【図７】
2004505333.tif 000011
【図８】
2004505333.tif 000012
【図９】
2004505333.tif 000013
【図１０】
2004505333.tif 000014
【図１１】
2004505333.tif 000015
【図１２】
2004505333.tif 000016
【図１３】
2004505333.tif 000017
【図１４】
2004505333.tif 000018
【図１５】
2004505333.tif 000019
【国際公開パンフレット】
2004505333.tif 000020
2004505333.tif 000021
2004505333.tif 000022
2004505333.tif 000023
2004505333.tif 000024
2004505333.tif 000025
2004505333.tif 000026
2004505333.tif 000027
2004505333.tif 000028
2004505333.tif 000029
2004505333.tif 000030
2004505333.tif 000031
2004505333.tif 000032
2004505333.tif 000033
2004505333.tif 000034
2004505333.tif 000035
2004505333.tif 000036
2004505333.tif 000037
2004505333.tif 000038
2004505333.tif 000039
2004505333.tif 000040
2004505333.tif 000041
2004505333.tif 000042
2004505333.tif 000043
2004505333.tif 000044
2004505333.tif 000045
2004505333.tif 000046
2004505333.tif 000047
2004505333.tif 000048
2004505333.tif 000049
2004505333.tif 000050
2004505333.tif 000051
2004505333.tif 000052
2004505333.tif 000053
2004505333.tif 000054
2004505333.tif 000055
2004505333.tif 000056
2004505333.tif 000057
2004505333.tif 000058
2004505333.tif 000059
2004505333.tif 000060
2004505333.tif 000061
2004505333.tif 000062
2004505333.tif 000063
2004505333.tif 000064
2004505333.tif 000065
2004505333.tif 000066
2004505333.tif 000067
2004505333.tif 000068
2004505333.tif 000069
2004505333.tif 000070
2004505333.tif 000071
2004505333.tif 000072
2004505333.tif 000073
2004505333.tif 000074
2004505333.tif 000075
2004505333.tif 000076
2004505333.tif 000077
2004505333.tif 000078
2004505333.tif 000079
【国際調査報告】
2004505333.tif 000080