JPH0683784A - 分散型計算システムにおいて動作経路上にオブジェクトを経路指定する方法及び装置 - Google Patents
分散型計算システムにおいて動作経路上にオブジェクトを経路指定する方法及び装置Info
- Publication number
- JPH0683784A JPH0683784A JP3228231A JP22823191A JPH0683784A JP H0683784 A JPH0683784 A JP H0683784A JP 3228231 A JP3228231 A JP 3228231A JP 22823191 A JP22823191 A JP 22823191A JP H0683784 A JPH0683784 A JP H0683784A
- Authority
- JP
- Japan
- Prior art keywords
- boss
- routed
- motion
- path
- stop
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Operations Research (AREA)
- Economics (AREA)
- Marketing (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Multi Processors (AREA)
- Computer And Data Communications (AREA)
Abstract
(57)【要約】 （修正有）
【目的】分散型計算システム内の動作経路に沿ってオブ
ジェクトを経路指定する。 【構成】オブジェクトは、オブジェクトが進行する論理
経路である動作経路（それ自体がオブジェクトである）
に沿ってシステム内で経路指定される。動作経路オブジ
ェクトは順番に操作する予定の上司のいる動作ストップ
の順序を示す。システムはオブジェクトを前記動作経路
に沿って伝播させ、終端までその進行を監視し制御す
る。システムは、オブジェクトを上司間にディスパッチ
するメカニズム、オブジェクトに操作を加える上司を見
出すメカニズム、必要な操作順に上司を通知するメカニ
ズム、オブジェクトを上司のノードに再配置するメカニ
ズムを含む。また、任意選択として末済操作に小言を言
うメカニズム、操作の欠落または進行停止を報告するメ
カニズム、複数のオブジェクトの、動作経路共用を支持
するメカニズム、オブジェクトの並行経路指定を容易に
するメカニズムを含む。
ジェクトを経路指定する。 【構成】オブジェクトは、オブジェクトが進行する論理
経路である動作経路（それ自体がオブジェクトである）
に沿ってシステム内で経路指定される。動作経路オブジ
ェクトは順番に操作する予定の上司のいる動作ストップ
の順序を示す。システムはオブジェクトを前記動作経路
に沿って伝播させ、終端までその進行を監視し制御す
る。システムは、オブジェクトを上司間にディスパッチ
するメカニズム、オブジェクトに操作を加える上司を見
出すメカニズム、必要な操作順に上司を通知するメカニ
ズム、オブジェクトを上司のノードに再配置するメカニ
ズムを含む。また、任意選択として末済操作に小言を言
うメカニズム、操作の欠落または進行停止を報告するメ
カニズム、複数のオブジェクトの、動作経路共用を支持
するメカニズム、オブジェクトの並行経路指定を容易に
するメカニズムを含む。
Description
【産業上の利用分野】本発明は分散型計算システムに関
し、具体的にはこれらのシステム内の動作経路に沿って
オブジェクトを経路指定する方法及び装置に関する。
し、具体的にはこれらのシステム内の動作経路に沿って
オブジェクトを経路指定する方法及び装置に関する。
【従来の技術】コンピュータシステムを接続するための
通信回路網の出現は、オフィス、工場及び販売所のよう
な分散したステーションを互いに接続することによって
巨大な分散型コンピュータシステムの構成を可能にし
た。これらのステーションはメールメッセージ、データ
及び状態情報を交換できる。遠隔手続き呼出し（ＲＰ
Ｃ）、ネームサービス、及び分散型データベータのよう
な分散型システムサービス及びツール（即ち分散型シス
テム内のノード上で走るソフトウエア）が開発され、そ
の国または世界に広がる数百または数千にも及ぶ真に分
散した適用業務を構成できるようになった。多くのこれ
らの分散した適用業務においては、データに若干の処理
を遂行しなければならない各利用者の間で制御及びデー
タを転送可能とすることが望まれるようになってきた。
このような適用業務の例には、例えば（１）精査または
承認のために指定された職務（通常は職員）に、書式、
メモまたはホルダーを転送するオフィス適用業務、
（２）指定された病院、診療所及び研究室間に患者の医
療カードまたは試験結果を評価するために回覧する医療
適用業務、（３）種々のシステム管理者の間でステータ
ス報告を交換する回路網管理システム、または（４）制
御センター、生産工場、または販売オフィス間に仕入れ
命令、生産計画、及び作業カードを回送する製造適用業
務が含まれる。これらの分散した適用業務は従来は物理
的なオブジェクト（例えば用紙書式、所要経費報告書、
作業カード、“外勤簿”等）を、指定されたステーショ
ン間に渡すことに頼っていた工程を自動化する。各物理
的オブジェクト、または分散型計算システム内のその対
照は、そのオブジェクトに例えば署名、更新、またはそ
のオブジェクトの読み取り、及びそれの引き渡し等の必
要操作を遂行する職務（通常は組織及び任務によって規
定された職員）を位置付ける限定された論理経理を有す
る。この経路は人名及び位置に翻訳され、オブジェクト
は位置から位置へ物理的に転送される。これらの適用業
務は、分散したオブジェクトが商用書式、医療記録、及
び製造業務カードのような物理的構成要素を表すオブジ
ェクト向きアプローチに役立つ。オブジェクトは独特な
識別子を有し、分散型システムのノードに全体として存
在し、ノード間を移動することが可能であり、そして維
持することができる。自動化適用業務においては、オブ
ジェクトはそれらを操作する必要職務を捜してノード間
を論理的に（そして多分物理的に）移動する。後述する
ように、このオブジェクト向きサービスを支持するため
にそのオブジェクトのための動作経路が指定され、その
オブジェクトをこの経路に沿って伝播させ且つその進行
を監視し制御するメカニズムが設けられる。これらのメ
カニズムを本発明ではオブジェクト経路指定システムと
呼ぶ。動作経路は、どの上司（計算システム内の他の職
務を表す）がどのような順番でオブジェクトを操作する
のかを、そして多分経路指定されたオブジェクトを次の
上司のノードへ物理的に移動させるか否かのような付加
的な情報をも指定する。分散型システムにおけるオブジ
ェクトの論理経路指定の例は巨大な商社組織における書
式の経路指定である。一人の社員が書式に記入し、経路
指定適用業務（プログラム）はそれをある動作経路に割
り付ける。書式は承認のためにその社員の管理者へ（次
いで多分若干の別の管理者へ）、次いで制御者（自動化
プログラムであってよい）へ、そして最終的には（コン
ピュータ化された）企業の記録保管所へ論理的に移動す
る。動作経路は、オブジェクトがその経路を出発する前
に、そして同様に経路を完了した後にシステムが遂行す
べき付加的な動作を指示することができる。このような
オブジェクト経路指定システムには幾つかの機構が設け
られる。第１に、上司間にオブジェクトを発送するメカ
ニズムは、それらの機能記述（企業規定、または名前の
ような）が与えられている上司を見出し、それらに順番
に通知し、そしてオブジェクトをそれらに引き渡す責を
負う。第２に、例外を指定し、それらを処理することを
上司に警告する手段が必要である。さらに、上司は所定
の適用業務に特定される期間内に動作が発生しなかった
か否かに気づく必要があるかも知れず、また他の上司は
オブジェクトが経路に沿って進行するのを知りたいかも
知れない。最後に、共用及び並行化が望ましい場合に
は、オブジェクト経路指定システムは動作経路の並行経
路指定及び同時共用を可能ならしめるべきである。以下
に説明するオブジェクト経路指定は、従来の通信回路網
におけるメッセージ経路指定及び製造または類似適用業
務における作業の流れとは同一ではない。メッセージ経
路指定がメッセージ（即ちこの場合にはオブジェクト）
を分散型システム内の１つの点から別の点へ転送するた
めに最も効率的な一組のリンクを選択することに関して
いるのに対して、オブジェクト経路指定はオブジェクト
を論理ステーション間に順番に伝播させることに関する
のである。作業の流れ制御とは異なってオブジェクト経
路指定は、各ステーションにおいて遂行される動作を指
定することも、またこれらの動作をスケジュールするこ
ともない。その代わりに、これらの動作は適用業務また
はオブジェクト自体に任されるのである。分散型計算シ
ステムのノードの間で構成要素を論理的に経路指定する
タスクのためのシステム及び適用業務ソフトウエアは既
に開発されている。これらは、主としてオフィス自動化
環境におけるメールメッセージまたは書類の経路指定に
関する。例えば、ＩＥＥＥ Ｔｒａｎｓ．ｏｎ Ｃｏｍ
ｍｕｎｉｃａｔｉｏｎ ＣＯＭ−３０：１（１９８２年
１月）６６−７３頁に所載の論文「構造化されたメッセ
ージを管理するシステム」においてＴｓｉｃｈｒｉｔｚ
ｉｓらは、メールメッセージシステム及びデータベース
管理システムの機能を統合したシステムを提唱してい
る。このシステムは１つの制御ノードと複数の衛星ノー
ドとからなる論理スターとして構成され、各ステーショ
ンはメッセージ識別子を登録しメッセージ内容のコピー
を保持するために“ステーションデータベース”を維持
する。メッセージは構成され、独特の識別子を有し、制
御ノードのメールボックスデータベース内に記憶され
る。利用者は、メッセージを遠隔検索し、移動中のメッ
セージの経路を調べ、経路を変更することができる（こ
れによりある程度メッセージの追跡が可能である）。し
かしながらこのシステムのアーキテクチャは、その拡張
性（スケーラビリティ；性能の低下を招くことなく、も
しくは複雑さを増すことなく大きいシステムへ拡張でき
る能力）、信頼性（制御ノードがクラッシュの場合）、
及び１つの経路を複数のオブジェクトが共用する能力を
制約している。メッセージ管理システム（ＭＭＳ）のた
めに設計された巧妙な経路指定システムが ＡＣＭ Ｔ
ｒａｎｓ．ｏｎ Ｏｆｆｉｃｅ Ｉｎｆｏｒｍａｔｉｏ
ｎ Ｓｙｓｔｅｍｓ ２：４（１９８４年１０月）３０
３−３３０頁に所載のＭ．Ｓ．Ｍａｚｅｒらの論文「オ
フィス情報システムにおける論理経路指定仕様」に記載
されている。この経路指定システムはプログラミング言
語を定義し、論理経路を指定するコンパイラを設け、メ
ッセージ型に基づく型経路指定と、メッセージ作成時の
仕様に基づくインスタンス経路指定と、例外のための特
別及び手動経路指定とを支持する。この経路は、メッセ
ージ内容、利用者が設定した条件、またはそれらによっ
て増した例外に基づいて動的に更新される。またこの設
計は、メッセージとそれらの経路とを記憶するために論
理的に中央に集めたデータベースを使用して、共用及び
並行経路指定をも支持する。別の機能として、各受領者
毎にタイムアウトを指定することと、機能記述から名前
を検索するためにある役割回路網を使用することとを含
む。しかしこの設計は維持に注意を向けていない（設計
の目的としていない）。この経路評価及び拡張はメール
システムだけのための適合業務依存型であり、このシス
テムを一般的な経路指定サービスに採用することは困難
である。このシステムはメッセージ（及び経路）の一貫
性及び追跡性のためのデータベースに依存しており、こ
の依存性がＭＭＳを大きい分散型システムに拡張するこ
とを制約することになろう。“知能メール”（Ｉメー
ル）システムは、１９８５年にベルリンの Ｓｐｒｉｎ
ｇｅｒ−Ｖｅｒｌａｇから刊行されたＤ．Ｃ．Ｔｓｉｃ
ｈｒｉｔｚｉｓ編Ｏｆｆｉｃｅ Ａｕｔｏｍａｔｉｏｎ
Ｃｏｎｃｅｐｔｓ ａｎｄ Ｔｏｏｌｓの１１３−１
３３頁にＪ．Ｈｏｇｇが「知能メッセージシステム（第
６章）」として述べている。ＩメールシステムはＩメッ
セージを、利用者間を巡回する活動オブジェクトとして
見る。スクリプトは考え得る経路を所要動作と共に指定
し、各ステーションの利用者に一組の質問が出され、経
路はそれらの返答及びメッセージの状態に基づいて動的
に評価または変更される。このシステムには、この経路
指定システムによって自動的に制御され得る明確に定義
された動作経路の支持は存在せず、また利用者に未済動
作を思い出させるための機能は設けられていない。経路
の共用及び並行経路指定を支持するためには、システム
はメッセージの複数のコピーを必要とし、それらの交換
を同期させるためにかなり複雑なメカニズムを使用する
ので、システムの拡張性が制約される。オフィス自動化
システムにおいて作業を分散処理するためのオブジェク
ト向きモデルがＣ．Ｃ．Ｗｏｏらによって示されている
（１９８６年７月ＡＣＭ Ｔｒａｎｓ．ｏｎ Ｏｆｆｉ
ｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ ４：
３ １８５−２０４頁「組織内の分散型オフィス問題解
消の支持」参照）。所与のオブジェクトの経路は明示的
に指定されないが、オブジェクトの処理の副産物であ
る。即ち、タスクオブジェクト（所与のオブジェクトの
計画表を指定する）と、タスクモニタオブジェクト（ポ
リシーメーカーの対照）と、協議規則（ポリシー）との
共働によって動的に誘導される。結果として得られた経
路はその適用業務に特定の条件で表され、経路指定サー
ビスはその適用業務にしっかりと結合され、そしてこの
モデルは経路共用及び並行経路指定の発行には関わらな
い。異質環境内のオブジェクト移動を支持する経路指定
システムは、１９８９年６月の ＩＥＥＥ Ｃｏｍｐｕ
ｔｅｒ Ｓｏｃｉｅｔｙ，Ｐｒｏｃ．ｏｆ ｔｈｅ９ｔ
ｈ Ｉｎｔ’ｌ Ｃｏｎｆ．ｏｎ Ｄｉｓｔｒｉｂｕｔ
ｅｄ Ｃｏｍｐｕｔｉｎｇ Ｓｙｓｔｅｍｓ，３７１−
３７６頁のＣ．Ｄ．Ｗｏｌｆｓｏｎらの論文「知的経路
指定」に示されている。Ｗｏｏらのモデルにおけるよう
に、この経路は実行中に暗示的に誘導され、明示的に変
化させたりまたは調べることはできない。このシステム
の本質から、オブジェクトは動作経路を並行経路指定し
たりまたは他のオブジェクトと共用することはできず、
思い出させ及び例外処理サービスを提供することはな
い。
通信回路網の出現は、オフィス、工場及び販売所のよう
な分散したステーションを互いに接続することによって
巨大な分散型コンピュータシステムの構成を可能にし
た。これらのステーションはメールメッセージ、データ
及び状態情報を交換できる。遠隔手続き呼出し（ＲＰ
Ｃ）、ネームサービス、及び分散型データベータのよう
な分散型システムサービス及びツール（即ち分散型シス
テム内のノード上で走るソフトウエア）が開発され、そ
の国または世界に広がる数百または数千にも及ぶ真に分
散した適用業務を構成できるようになった。多くのこれ
らの分散した適用業務においては、データに若干の処理
を遂行しなければならない各利用者の間で制御及びデー
タを転送可能とすることが望まれるようになってきた。
このような適用業務の例には、例えば（１）精査または
承認のために指定された職務（通常は職員）に、書式、
メモまたはホルダーを転送するオフィス適用業務、
（２）指定された病院、診療所及び研究室間に患者の医
療カードまたは試験結果を評価するために回覧する医療
適用業務、（３）種々のシステム管理者の間でステータ
ス報告を交換する回路網管理システム、または（４）制
御センター、生産工場、または販売オフィス間に仕入れ
命令、生産計画、及び作業カードを回送する製造適用業
務が含まれる。これらの分散した適用業務は従来は物理
的なオブジェクト（例えば用紙書式、所要経費報告書、
作業カード、“外勤簿”等）を、指定されたステーショ
ン間に渡すことに頼っていた工程を自動化する。各物理
的オブジェクト、または分散型計算システム内のその対
照は、そのオブジェクトに例えば署名、更新、またはそ
のオブジェクトの読み取り、及びそれの引き渡し等の必
要操作を遂行する職務（通常は組織及び任務によって規
定された職員）を位置付ける限定された論理経理を有す
る。この経路は人名及び位置に翻訳され、オブジェクト
は位置から位置へ物理的に転送される。これらの適用業
務は、分散したオブジェクトが商用書式、医療記録、及
び製造業務カードのような物理的構成要素を表すオブジ
ェクト向きアプローチに役立つ。オブジェクトは独特な
識別子を有し、分散型システムのノードに全体として存
在し、ノード間を移動することが可能であり、そして維
持することができる。自動化適用業務においては、オブ
ジェクトはそれらを操作する必要職務を捜してノード間
を論理的に（そして多分物理的に）移動する。後述する
ように、このオブジェクト向きサービスを支持するため
にそのオブジェクトのための動作経路が指定され、その
オブジェクトをこの経路に沿って伝播させ且つその進行
を監視し制御するメカニズムが設けられる。これらのメ
カニズムを本発明ではオブジェクト経路指定システムと
呼ぶ。動作経路は、どの上司（計算システム内の他の職
務を表す）がどのような順番でオブジェクトを操作する
のかを、そして多分経路指定されたオブジェクトを次の
上司のノードへ物理的に移動させるか否かのような付加
的な情報をも指定する。分散型システムにおけるオブジ
ェクトの論理経路指定の例は巨大な商社組織における書
式の経路指定である。一人の社員が書式に記入し、経路
指定適用業務（プログラム）はそれをある動作経路に割
り付ける。書式は承認のためにその社員の管理者へ（次
いで多分若干の別の管理者へ）、次いで制御者（自動化
プログラムであってよい）へ、そして最終的には（コン
ピュータ化された）企業の記録保管所へ論理的に移動す
る。動作経路は、オブジェクトがその経路を出発する前
に、そして同様に経路を完了した後にシステムが遂行す
べき付加的な動作を指示することができる。このような
オブジェクト経路指定システムには幾つかの機構が設け
られる。第１に、上司間にオブジェクトを発送するメカ
ニズムは、それらの機能記述（企業規定、または名前の
ような）が与えられている上司を見出し、それらに順番
に通知し、そしてオブジェクトをそれらに引き渡す責を
負う。第２に、例外を指定し、それらを処理することを
上司に警告する手段が必要である。さらに、上司は所定
の適用業務に特定される期間内に動作が発生しなかった
か否かに気づく必要があるかも知れず、また他の上司は
オブジェクトが経路に沿って進行するのを知りたいかも
知れない。最後に、共用及び並行化が望ましい場合に
は、オブジェクト経路指定システムは動作経路の並行経
路指定及び同時共用を可能ならしめるべきである。以下
に説明するオブジェクト経路指定は、従来の通信回路網
におけるメッセージ経路指定及び製造または類似適用業
務における作業の流れとは同一ではない。メッセージ経
路指定がメッセージ（即ちこの場合にはオブジェクト）
を分散型システム内の１つの点から別の点へ転送するた
めに最も効率的な一組のリンクを選択することに関して
いるのに対して、オブジェクト経路指定はオブジェクト
を論理ステーション間に順番に伝播させることに関する
のである。作業の流れ制御とは異なってオブジェクト経
路指定は、各ステーションにおいて遂行される動作を指
定することも、またこれらの動作をスケジュールするこ
ともない。その代わりに、これらの動作は適用業務また
はオブジェクト自体に任されるのである。分散型計算シ
ステムのノードの間で構成要素を論理的に経路指定する
タスクのためのシステム及び適用業務ソフトウエアは既
に開発されている。これらは、主としてオフィス自動化
環境におけるメールメッセージまたは書類の経路指定に
関する。例えば、ＩＥＥＥ Ｔｒａｎｓ．ｏｎ Ｃｏｍ
ｍｕｎｉｃａｔｉｏｎ ＣＯＭ−３０：１（１９８２年
１月）６６−７３頁に所載の論文「構造化されたメッセ
ージを管理するシステム」においてＴｓｉｃｈｒｉｔｚ
ｉｓらは、メールメッセージシステム及びデータベース
管理システムの機能を統合したシステムを提唱してい
る。このシステムは１つの制御ノードと複数の衛星ノー
ドとからなる論理スターとして構成され、各ステーショ
ンはメッセージ識別子を登録しメッセージ内容のコピー
を保持するために“ステーションデータベース”を維持
する。メッセージは構成され、独特の識別子を有し、制
御ノードのメールボックスデータベース内に記憶され
る。利用者は、メッセージを遠隔検索し、移動中のメッ
セージの経路を調べ、経路を変更することができる（こ
れによりある程度メッセージの追跡が可能である）。し
かしながらこのシステムのアーキテクチャは、その拡張
性（スケーラビリティ；性能の低下を招くことなく、も
しくは複雑さを増すことなく大きいシステムへ拡張でき
る能力）、信頼性（制御ノードがクラッシュの場合）、
及び１つの経路を複数のオブジェクトが共用する能力を
制約している。メッセージ管理システム（ＭＭＳ）のた
めに設計された巧妙な経路指定システムが ＡＣＭ Ｔ
ｒａｎｓ．ｏｎ Ｏｆｆｉｃｅ Ｉｎｆｏｒｍａｔｉｏ
ｎ Ｓｙｓｔｅｍｓ ２：４（１９８４年１０月）３０
３−３３０頁に所載のＭ．Ｓ．Ｍａｚｅｒらの論文「オ
フィス情報システムにおける論理経路指定仕様」に記載
されている。この経路指定システムはプログラミング言
語を定義し、論理経路を指定するコンパイラを設け、メ
ッセージ型に基づく型経路指定と、メッセージ作成時の
仕様に基づくインスタンス経路指定と、例外のための特
別及び手動経路指定とを支持する。この経路は、メッセ
ージ内容、利用者が設定した条件、またはそれらによっ
て増した例外に基づいて動的に更新される。またこの設
計は、メッセージとそれらの経路とを記憶するために論
理的に中央に集めたデータベースを使用して、共用及び
並行経路指定をも支持する。別の機能として、各受領者
毎にタイムアウトを指定することと、機能記述から名前
を検索するためにある役割回路網を使用することとを含
む。しかしこの設計は維持に注意を向けていない（設計
の目的としていない）。この経路評価及び拡張はメール
システムだけのための適合業務依存型であり、このシス
テムを一般的な経路指定サービスに採用することは困難
である。このシステムはメッセージ（及び経路）の一貫
性及び追跡性のためのデータベースに依存しており、こ
の依存性がＭＭＳを大きい分散型システムに拡張するこ
とを制約することになろう。“知能メール”（Ｉメー
ル）システムは、１９８５年にベルリンの Ｓｐｒｉｎ
ｇｅｒ−Ｖｅｒｌａｇから刊行されたＤ．Ｃ．Ｔｓｉｃ
ｈｒｉｔｚｉｓ編Ｏｆｆｉｃｅ Ａｕｔｏｍａｔｉｏｎ
Ｃｏｎｃｅｐｔｓ ａｎｄ Ｔｏｏｌｓの１１３−１
３３頁にＪ．Ｈｏｇｇが「知能メッセージシステム（第
６章）」として述べている。ＩメールシステムはＩメッ
セージを、利用者間を巡回する活動オブジェクトとして
見る。スクリプトは考え得る経路を所要動作と共に指定
し、各ステーションの利用者に一組の質問が出され、経
路はそれらの返答及びメッセージの状態に基づいて動的
に評価または変更される。このシステムには、この経路
指定システムによって自動的に制御され得る明確に定義
された動作経路の支持は存在せず、また利用者に未済動
作を思い出させるための機能は設けられていない。経路
の共用及び並行経路指定を支持するためには、システム
はメッセージの複数のコピーを必要とし、それらの交換
を同期させるためにかなり複雑なメカニズムを使用する
ので、システムの拡張性が制約される。オフィス自動化
システムにおいて作業を分散処理するためのオブジェク
ト向きモデルがＣ．Ｃ．Ｗｏｏらによって示されている
（１９８６年７月ＡＣＭ Ｔｒａｎｓ．ｏｎ Ｏｆｆｉ
ｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ ４：
３ １８５−２０４頁「組織内の分散型オフィス問題解
消の支持」参照）。所与のオブジェクトの経路は明示的
に指定されないが、オブジェクトの処理の副産物であ
る。即ち、タスクオブジェクト（所与のオブジェクトの
計画表を指定する）と、タスクモニタオブジェクト（ポ
リシーメーカーの対照）と、協議規則（ポリシー）との
共働によって動的に誘導される。結果として得られた経
路はその適用業務に特定の条件で表され、経路指定サー
ビスはその適用業務にしっかりと結合され、そしてこの
モデルは経路共用及び並行経路指定の発行には関わらな
い。異質環境内のオブジェクト移動を支持する経路指定
システムは、１９８９年６月の ＩＥＥＥ Ｃｏｍｐｕ
ｔｅｒ Ｓｏｃｉｅｔｙ，Ｐｒｏｃ．ｏｆ ｔｈｅ９ｔ
ｈ Ｉｎｔ’ｌ Ｃｏｎｆ．ｏｎ Ｄｉｓｔｒｉｂｕｔ
ｅｄ Ｃｏｍｐｕｔｉｎｇ Ｓｙｓｔｅｍｓ，３７１−
３７６頁のＣ．Ｄ．Ｗｏｌｆｓｏｎらの論文「知的経路
指定」に示されている。Ｗｏｏらのモデルにおけるよう
に、この経路は実行中に暗示的に誘導され、明示的に変
化させたりまたは調べることはできない。このシステム
の本質から、オブジェクトは動作経路を並行経路指定し
たりまたは他のオブジェクトと共用することはできず、
思い出させ及び例外処理サービスを提供することはな
い。
【発明の概要】本発明の一実施例によれば、“オブジェ
クト”（オブジェクトとは周知の操作のリストまたはデ
ータへのアクセス方法を有する周知の方式でデータをカ
プセル封じするある概念を意味し、独特の識別を有し、
移動可能であり、そして多分維持される）を経路指定す
るシステムが提供される。“オブジェクト”は、そのオ
ブジェクトが辿る論理経路を定義する動作経路（それ自
体が“オブジェクト”である）に沿って分散型計算シス
テム内で経路指定される。動作経路は、経路指定済オブ
ジェクトを規定された順番に操作する必要がある上司
（人々または自動化メカニズム）を名指す複数の動作ス
トップからなる。オブジェクト経路指定システムはこの
動作経路に沿ってオブジェクトを伝播させ、経路伝播が
完了するまでその進行を監視し、制御する。システム
は、経路指定済オブジェクトを動作ストップ間で移動さ
せ、経路指定済オブジェクトの操作を要求した上司を
（機能情報に基づいて）見出し、上司にそれらの必要動
作の順番を知らせ、そして経路指定済オブジェクトを上
司のノードへ潜在的に再配置する。このオブジェクト経
路指定システムは、オブジェクト管理、移動、維持、及
びオブジェクト間通信のためにサービスより上位の汎用
サービス層として構成される。本発明の別の実施例の重
要な特色は、思い出させメカニズム、つまり“小言”メ
カニズムを任意選択的に付加したことである。オブジェ
クト経路指定システムは、未済動作（もし指定した時間
内に進行が行われなければ）及び他の上司へのこのよう
な動作または進行の欠如の両方または何れか一方につい
て上司へ口喧しく言うメカニズムを使用することができ
る。一実施例によるオブジェクト経路指定システムの別
の重要な特色は、複数の上司による動作経路の共用を支
持し、複数の上司へのオブジェクトの並行経路指定を容
易ならしめることである。本発明のオブジェクト経路指
定システムは、適用業務には依存しない汎用の分散型シ
ステムサービスであること、並行及び共用経路指定を支
持すること、上司の動作が必要な場合に如何にしてそれ
を知らせるかを上司に選択せしめること、若干の事象を
思い出させるために上司に要求するかまたは未済動作に
ついて他の上司に口喧しく言うこと、及びもし必要なら
ばオブジェクトをノード間に“物理的に”移動させるこ
とが、当分野における上述の先行技術とは根本的に異な
る。この経路指定方法は小規模システムにも、または数
百乃至数千のノードからなる広域分散システムにも適し
ている。本発明の特徴であると信ぜられる新しい特色は
特許請求の範囲に記載した。しかし本発明自体並びに他
の特色及び長所は、以下の添付図面に基づく特定実施例
の説明から完全に理解できよう。
クト”（オブジェクトとは周知の操作のリストまたはデ
ータへのアクセス方法を有する周知の方式でデータをカ
プセル封じするある概念を意味し、独特の識別を有し、
移動可能であり、そして多分維持される）を経路指定す
るシステムが提供される。“オブジェクト”は、そのオ
ブジェクトが辿る論理経路を定義する動作経路（それ自
体が“オブジェクト”である）に沿って分散型計算シス
テム内で経路指定される。動作経路は、経路指定済オブ
ジェクトを規定された順番に操作する必要がある上司
（人々または自動化メカニズム）を名指す複数の動作ス
トップからなる。オブジェクト経路指定システムはこの
動作経路に沿ってオブジェクトを伝播させ、経路伝播が
完了するまでその進行を監視し、制御する。システム
は、経路指定済オブジェクトを動作ストップ間で移動さ
せ、経路指定済オブジェクトの操作を要求した上司を
（機能情報に基づいて）見出し、上司にそれらの必要動
作の順番を知らせ、そして経路指定済オブジェクトを上
司のノードへ潜在的に再配置する。このオブジェクト経
路指定システムは、オブジェクト管理、移動、維持、及
びオブジェクト間通信のためにサービスより上位の汎用
サービス層として構成される。本発明の別の実施例の重
要な特色は、思い出させメカニズム、つまり“小言”メ
カニズムを任意選択的に付加したことである。オブジェ
クト経路指定システムは、未済動作（もし指定した時間
内に進行が行われなければ）及び他の上司へのこのよう
な動作または進行の欠如の両方または何れか一方につい
て上司へ口喧しく言うメカニズムを使用することができ
る。一実施例によるオブジェクト経路指定システムの別
の重要な特色は、複数の上司による動作経路の共用を支
持し、複数の上司へのオブジェクトの並行経路指定を容
易ならしめることである。本発明のオブジェクト経路指
定システムは、適用業務には依存しない汎用の分散型シ
ステムサービスであること、並行及び共用経路指定を支
持すること、上司の動作が必要な場合に如何にしてそれ
を知らせるかを上司に選択せしめること、若干の事象を
思い出させるために上司に要求するかまたは未済動作に
ついて他の上司に口喧しく言うこと、及びもし必要なら
ばオブジェクトをノード間に“物理的に”移動させるこ
とが、当分野における上述の先行技術とは根本的に異な
る。この経路指定方法は小規模システムにも、または数
百乃至数千のノードからなる広域分散システムにも適し
ている。本発明の特徴であると信ぜられる新しい特色は
特許請求の範囲に記載した。しかし本発明自体並びに他
の特色及び長所は、以下の添付図面に基づく特定実施例
の説明から完全に理解できよう。
【実施例】図１に示す分散型コンピュータシステムは複
数のノード１０、１１、１２及び１３を含み、各ノード
は典型的にはＣＰＵ１４及びメモリ１５を有するワーク
ステーションであり、またハードディスク記憶装置１６
及びコンソール（キーボード及び表示装置）１７をも有
することができる。これらは全てシステムバス１８によ
って相互に接続されている。各ノードをリンク２０によ
って他の全てのノードに接続するために通信アダプタ１
９が使用される。図には４つのノード１０−１３だけを
示してあるが典型的には数百乃至数千のノードが存在
し、またリンク２０は、例えばＤＥＣネット、トークン
リング、スターＬＡＮ、またはイーサネット型の構内通
信網、並びに光ファイバリンク（ＦＤＤＩ）及び衛星リ
ンク、またはブリッジノードを使用するこれらの組合せ
（これらは全て広域通信網の一部であってよい）を含む
ことができる。ノード１０−１３はメモリからのコード
を実行するＣＰＵを有するワークステーションとして示
してあるが、勿論、以下に説明する論理処理を実現する
ためのステートマシーンの如きあるメカニズムを含む単
なるディスク記憶装置等のような別の型の資源であって
差し支えない。通常図１の例の各ノード１０−１３はオ
ペテーシィングシステム（例えばユニックスまたはＤＯ
Ｓ）のそれぞれのコピーを実行して論理ノードを作成す
るが、個々の利用者がユニックスのようなマルチユーザ
オペレーティングシステムを実行する中央コンピュータ
のバスに接続されている端末を有するような場合には、
複数のノードが単一のＣＰＵを利用して実行してもよ
い。ノード１０−１３の位置及びそれらの通信メカニズ
ムはオブジェクト経路指定システムに対して透明であ
り、後述するようにこのオブジェクト経路指定システム
はオブジェクトハンドルを使用してオブジェクト呼出し
を処理する。図１の物理ノード１０−１３は大きい距離
に亙って離間するかも知れず、本発明の方法において操
作されるオブジェクトは通常これらのノードの１つの利
用者と、あるオブジェクト内のデータ構造との間にある
型の対話を必要とするからそのオブジェクトをローカル
にする、即ち現在オブジェクトを操作中のノード１０−
１３に維持することが望ましい。もしノード間の距離が
大きければ、そのオブジェクトを１つのノードに維持し
て置いて回路網リンク２０を通して他の必要ノードによ
って操作することは、応答時間が不当に長くなり、また
通信リンク２０に過大な負荷を課すことになるので、容
認し難い。勿論、呼び出される全てのノードが相互に接
近していれば、オブジェクトを１つのノードから別のノ
ードに移動させる必要はないが、もし必要ならば移動能
力を使用しなければならない。図２に、図１の中の１つ
のような分散型システムのサービス層及び適用業務オブ
ジェクトを論理フォーマットで示す。図２内の論理ノー
ド１０′、１１′、１２′または１３′は、コードを実
行するために図１のＣＰＵ１４によってアクセスされる
アドレス空間に物理的に関係付けることができる。図１
のシステム（即ちワークステーションで実現した型）で
は物理アドレス空間は主としてメモリ１５内にあるが、
前述のように物理ノードはワークステーション以外のメ
カニズムであって差し支えない。即ち、論理ノード１
０′−１３′は通常は（しかし必須ではない）図１の単
一物理機械１０−１３に写像（マップ）される。どのよ
うな事象においても図２の各論理ノードはオブジェクト
向き適用業務を支持する。この場合、適用業務は複数の
論理ノードに亙って分散できるオブジェクトからなり、
また適用業務はオブジェクトを共用できる。人または自
動化職務であるシステム利用者は、オブジェクトによっ
て論理システム内に表される。図２の論理ノード１０′
−１３′は複数の適用業務オブジェクトＡ１、Ｂ１、Ａ
２、Ｂ２等を有し、これらはローカルオブジェクトとし
て知られるオブジェクトインスタンス（例示されたオブ
ジェクト）である。あるオブジェクトは独特に識別され
る自己包含型論理構成要素であって、論理ノード間に再
配置可能である。オブジェクトとは、本質的に周知の操
作のリストまたはデータへのアクセス方法を有する周知
の方式でデータをカプセル封じするある概念と定義さ
れ、独特の識別を有し、移動可能であり、そして多分持
続するものである。ここでは、引き継ぎの特性（この用
語をオブジェクト向きプログラミングに用いているの
で）は必要としないことに注目されたい。あるオブジェ
クトは、所与の時点に図２の少なくとも１つの論理ノー
ド１０′−１３′に全体として存在している。厳格に言
えば、あるオブジェクトは、そのオブジェクトが呼出さ
れ、そのオブジェクト自身がそれを用いて何ができるか
を定義しない限り変更することはできない。オブジェク
トは、オブジェクトと共に移動するコード（定義された
操作または方法）、またはオブジェクトが移動して行く
論理ノードに存在するコードを含み、このコードはオブ
ジェクトによって許容されるとそのオブジェクトを変更
することができる。オブジェクトはファイルとして、ま
たは一群のファイルとしてディスク１６に記憶させるこ
とができるが、“例示された”時にはメモリ１５内にあ
り、ハンドルまたはオブジェクト名によって識別され
る。後述するように、ノード１０−１３は本発明による
経路指定システム（実行可能なコード）２１を含む。経
路指定システム２１は下位のシステム層に対して若干の
サービスを要求する。例えば、オペレーティングシステ
ム及びＣＰＵは、オブジェクトが物理メモリ１５内にあ
る間にその上に書き込まれたり、そのデータまたはコー
ドが変更されたりすることを防ぐある保護メカニズムを
設けなければならず、この機能は通常は基本サービス２
２のメモリ管理メカニズムの一部になっている。通常、
オブジェクトは回送、思い出させ、承認等のような適用
業務にある動作を起こさせるあるメカニズムを含む。オ
ブジェクト向き適用業務を支持するために、オブジェク
トスーパバイザ２２と呼ぶサービスの基礎が各ノードに
含まれている。オブジェクトスーパバイザ２２はオブジ
ェクト作成、管理、維持、及びオブジェクト間通信を支
持する。オブジェクト経路指定システム２１はオブジェ
クトスーパバイザのサービス上に確立される適用業務レ
ベルのサービスである。オブジェクトは、それを探知す
るために使用される世界的に独自の識別子を有してい
る。しかし適用業務レベルではオブジェクトはオブジェ
クトスーパバイザ２２によって維持されているオブジェ
クトハンドルによって互いに参照し合う。あるオブジェ
クトが作成されると、オブジェクトスーパバイザ２２は
そのオブジェクトのハンドルをその作成者に戻す。オブ
ジェクトはそれらが知っているオブジェクトのハンドル
を互いに渡し合うことができる。オブジェクトは、それ
らの公に知られたインタフェースの操作を呼出すことに
よって互いに通信し合う。呼出しは位置には無関係であ
り、全ての呼出し者は目標オブジェクトのハンドルを知
っていなければならず、また全ての呼出し者は呼出され
るオブジェクトの位置に、または呼出しを意図している
時に呼出されるオブジェクトが移動できる事実にさえも
関わってはならない。呼出しの目標オブジェクトを探知
するために所与のハンドルを使用すること、所要操作を
呼出すこと、及び結果を呼出し者へ戻すように伝播させ
ることがオブジェクトスーパバイザ２２の役割である。
位置独立型呼出し（ＬＩＩ）を達成するためにオブジェ
クトスーパバイザ２２が使用する通信メカニズム及び方
法は適用業務レベルにおいては透明であり、ハンドルは
呼出しパラメタ及び結果内で渡すことができる。この位
置独立型呼出し（ＬＩＩ）層は、１９８９年４月６日付
け Ａｎｄｒｅｗ Ｐ．Ｂｌａｃｋ 及び Ｙｅｓｈａ
ｙａｈｕ Ａｒｔｓｙの関連出願（ＰＤ８９−０１４
２）「分散型計算システムにおける移動オブジェクトの
探知」、及び１９８９年６月の ＩＥＥＥ Ｃｏｍｐｕ
ｔｅｒ Ｓｏｃｉｅｔｙ，Ｐｒｏｃ．ｏｆ ｔｈｅ ９
ｔｈＩｎｔ’ｌ Ｃｏｎｆ．ｏｎ Ｄｉｓｔｒｉｂｕｔ
ｅｄ ＣｏｍｐｕｔｉｎｇＳｙｓｔｅｍｓ，５５０−５
５９頁に所載の両氏の論文「位置独立型呼出しの実現」
（この論文の改定及び拡大バージョンは１９９０年１月
の ＩＥＥＥ Ｔｒａｎｓ．ｏｎ Ｐａｒａｌｌｅｌ
ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ
１：１に記載されている）に記載されている型の各ノー
ド１０−１３に含まれる。各ノードは、使用可能なユー
ティリティである遠隔手続き呼出し（ＲＰＣ）層のよう
なノード間通信用メカニズムをも有している。ノード間
通信の支持は、１９８９年４月６日の ２ｎｄ Ｉｎ
ｔ’ｌ Ｗｏｒｋｓｈｏｐ ｏｎＤｉｓｔｒｉｂｕｔｉ
ｏｎ ａｎｄ Ｏｂｊｅｃｔｓ の Ｙ．Ａｒｔｓｙの
論文「高度に分散した移動オブジェクト間の通信」に記
載されている。以上のように、適用業務オブジェクト
は、通常は他のオブジェクトにある操作を遂行するため
に、他のオブジェクトを“呼出し”たり、または他のオ
ブジェクトを探知したりする必要が屡々ある。例えば単
にオブジェクトの位置を決定する必要があるだけでその
オブジェクトに何等の操作を遂行しなくともそのオブジ
ェクトを呼出すことができるが、これは異状であって殆
どの呼出しはそのオブジェクトに操作を遂行する目的か
らである。適用業務オブジェクトＡ１はローカル手続き
呼出し（ＬＩＩ層を介して、透明に）を用いてＢ１を呼
出すことができる。何故ならば、両オブジェクトは同一
ノード内に位置しているが、ＬＩＩはＡ２のような他の
ノード内のオブジェクトにアクセスするために遠隔手続
き呼出しまたは他の遠隔通信手段を使用できるからであ
る。ローカル及び遠隔通信は通信しているオブジェクト
に対して透明である。図１または２の回路網は、どのよ
うなクラッシュに対しても記憶したデータを維持するこ
とを保証する分散型安定記憶サービス（図示せず）を含
み、オブジェクトスーパバイザ２２はこのサービスへの
インタフェースを提供する。安定した記憶場所は回路網
サービス内であろう。これは例えばノード１０−１３に
似た付加的なノードであってもよく、またはノード自身
のディスク記憶装置１６によって実現してもよい。各記
憶場所は１またはそれ以上のノード上に存在する１また
はそれ以上のオブジェクト（の非揮発性コピーを）支持
（維持）し、あるノードがクラシュしてもそのオブジェ
クトが含んでいるデータを回復できるように機能する。
この安定記憶サービスは、オブジェクトがそれらの状態
の保存するのを可能ならしめ、また状態を変化させるの
で、あるノードがクラシュの場合にはそのノード内に含
まれているオブジェクトは、そのノードが修復された時
にそのオブジェクトスーパバイザ２２によって自動的に
復元されるか、または他の（多分異なるノードの）スー
パバイザによって復元される。同様に、非活動オブジェ
クトをそのノードから除去し、後刻呼出された時には回
復することができる。オブジェクト経路指定システム２
１は、呼出しを要求したオブジェクトが、ノード１０−
１３の何れかに存在しているか、またはオブジェクトス
ーパバイザ２２によって安定記憶装置から復元できるも
のとしている。ノードが一時的に到達不能である間はこ
の復元を遅延させることができる。オブジェクト経路指
定システム２１は、若干の型のオブジェクト向きプログ
ラミングシステムとは異なり、オブジェクト間に何等の
クラス階層または引き継ぎを必要としない。このシステ
ムは３つのオブジェクト型と、オブジェクト接続機構の
概念とを支持することを要求するが、それ以外にオブジ
ェクト型及びそれらが互いにどのように機能的に関わり
合っているかには関心がない。３つのオブジェクト型と
は、プリンオブジェクト、ホルダー、及び動作経路であ
る。システムの上司は、そのオブジェクトを経路指定で
きるような、例えば（人の）利用者、利用者の群、自動
化された社員、または記録保管所のような何らかの構成
要素である。これがプリンオブジェクトと縮めて呼ばれ
る（プリンシパルオブジェクトの略）オブジェクトによ
って表される。上司が自動化プログラムである場合には
その上司は事実上そのプリンオブジェクト内に統合でき
る。ホルダーは、幾つかのオブジェクトを群にして一緒
に経路指定または移動させるために使用されるオブジェ
クトである。これらのオブジェクトは経路指定システム
２１によって“アップコール”することができ（１９８
５年１２月の、Ｐｒｏｃ．ｏｆ ｔｈｅ１０ｔｈ Ｓｙ
ｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔ
ｅｍｓＰｒｉｎｃｉｐａｌｓ の１７１−１８０頁に所
載の Ｄ．Ｄ．Ｃｌａｒｋの論文「アップコールを使用
するシステムの構造」を参照されたい）、従って僅かな
インタフェース要求がこれらに課せられる。動作経路オ
ブジェクト（ＡＰＯ型）は、後述するように、経路指定
された（どのような型の）オブジェクトの動作経路を指
定するために使用される。接続機構（アタッチメント）
は、経路指定及び移動を簡易化するために使用される。
どのような種類のオブジェクトでもホルダーに接続する
ことができ、各オブジェクトはそれに接続された動作経
路オブジェクトを有することができる。接続機構は単に
オブジェクトスーパバイザ２２によって維持されている
相互参照にしか過ぎない。接続機構はオブジェクト間の
どのような機能依存性をも暗示しないが、動作経路オブ
ジェクトと経路指定されたオブジェクトとを統合する、
または幾つかのオブジェクトをまとめて経路指定もしく
は移動させる便利な方式でる。経路指定は、あるオブジ
ェクトをある動作経路オブジェクトによって定義された
関連動作経路に沿って論理的に伝播させることである。
動作経路オブジェクトは、予め定義されたテンプレート
から作成し、別の経路インスタンスからコピーし、また
は特別な経路として利用者によって対話的に定義するこ
とができる。このオブジェクトは経路指定されたオブジ
ェクトに、オブジェクト作成時に静的に、またはその後
に動的に接続することができる。図３に示すように、動
作経路オブジェクト２５は概念的に３つの部分、即ち見
出し２６、本体２７（動作ストップ２８のグラフ）及び
後書き２９からなる。見出し２６は、誰が経路指定され
たオブジェクトの提出者（即ち、そのオブジェクトを特
定の動作経路上に経路指定することを要求した最初の上
司）であるのかを指定する。また見出し２６は経路指定
されたオブジェクトに関するある情報をも含む。後書き
２９は、オブジェクトがその経路の終端に到達した時に
何をするのかを指定する。両者の間のグラフ２７は、オ
ブジェクトが進むべき実際の経路である。図４の動作経
路は、経路指定されたオブジェクトが操作のＡＤＳ群内
の働く一人の上司、アンによって作成された経費伝票で
あるような例を示す。経費償還適用業務は、伝票に彼女
の管理者ベンと、経費が請求されるコストセンターの管
理者チェンと、このコストセンターを制御する会計系ダ
ンの承認（署名）を必要とする。その後に伝票は税金及
び会計監査の目的のために記録される。伝票（オブジェ
クト）に取り付けられた動作経路オブジェクト２５はこ
れらの上司を動作ストップ２８として指定する。経路指
定システム２１はそれらの各々を見出し、それらに順番
に（計算機化された）書式を引き渡す。この例では、ア
ンがシステムにオブジェクトを提出すると（即ち、後述
するように、彼女がそれを発送した時に）動作経路が例
示され、適切な情報で設定されそしてアンの伝票オブジ
ェクトに接続される。動作経路はあるオブジェクト内に
カプセル封じされるから、その内部表現は利用者または
他のオブジェクトには不可視であるが、利用者またはオ
ブジェクトはその経路の論理構造を視ることはできるこ
とに注意されたい。あるオブジェクト内にあるため、活
動経路はそれへのハンドルを入手した誰でもが呼出し、
追跡し、そして安定な記憶装置内に保存することができ
る。保護の理由から、オブジェクト経路指定システムの
みが経路を拡張し、変更することができる。例えば異例
の事象のために利用者がある経路を変更する必要があれ
ば、利用者はシステムに制御された方法でそのようにす
ることを要求するか、或は後述するように、特別な経路
を有するホルダーを使用してそのオブジェクトを異なる
経路上に転送することができる。見出し２６内の提出者
の情報は、その名前及びそのプリンオブジェクトのハン
ドル（例えば“アン”及び彼女の個人識別オブジェク
ト）を含む。この情報は、その経路に沿う他の上司が使
用して経路指定されたオブジェクトに操作を要求したの
は誰かを見出すことができ、またオブジェクト経路指定
システムが使用して特別な事象を提出者に報告すること
ができる。見出し２６内の付加情報は適用業務セレクタ
または適用業務ＩＤ（これは汎用記号であっても、また
はある適用業務のための特定ＩＤであってもよい）と、
この経路指定の主題の本文記述とを示す。この例では、
これらは経費償還適用業務のセレクタ（例えば“１２
３”）、及び本文“アンの１９９０年第１０回ＩＣＤＣ
Ｓ出席経費”であろう。主題本文は、経路指定されたオ
ブジェクトを拾い読みさせることなくそのオブジェクト
は何に関するものであるかを上司（そのオブジェクトが
経路指定された本人）に告げる。適用業務セレクタまた
はＩＤは、上司の利用者インタフェース（またはプリン
オブジェクト）が、上司に対する通知を待ち合わさせ
る、または経路指定されたオブジェクトを他の誰かに向
かわせるのような動作の経過を自動的に選択するのを援
助する。さらに見出し２６は、クラッシュ中その経路を
維持しなければならないか否かを指示できる。これは、
オブジェクトがその経路指定を完了することを提出者ま
たは適用業務が予測するための完了時間値を含むことが
できる。以下に説明するように、システムはこの値を使
用して、この締め切り期限が守られない場合に上司に思
い出させるようにする。後書き２９は、経路が不足する
場合にオブジェクト経路指定システム２１が取るべき動
作をリストする。これらの動作には、動作経路自体の破
棄（欠乏）、提出者アンへ完了の通知、またはその適用
業務に特定の手続きの呼出しが含まれよう。後書き２９
が経路指定されたオブジェクトに何をするかは指定しな
いことに注目されたい。これは適用業務に決定を任せて
いるのである。例えば、適用業務が経路指定されたオブ
ジェクトをその経路の終端で記録することを要求すれ
ば、最後のストップとして経路に記録所を付加する（上
例の場合のように）か、または最後の上司がオブジェク
トに操作し終えた後にオブジェクトは自分自身を記録所
のノードまで移動させる。一組の動作ストップは、経路
指定されたオブジェクトに操作することを要求した各上
司毎に１つの記述子の指示されたグラフによって記述さ
れる。図５を参照する。一人の上司Ｐが同一オブジェク
トＯを２回以上操作しなければならない（例えばＰの後
のＯに操作された動作を検査するために）ような場合に
は、循環を回避するためにＰのための分離した動作スト
ップがその都度現れる。上司Ｐの識別及びその位置は、
Ｐへのディスパッチが呼出される度に翻訳されるので、
もし変化（再配置、休暇、再編成等）があればこれらは
考慮されることになる。動作ストップ２８は図６に示さ
れており、上司の名前とその組織上の役割とを指定して
いる。役割は、何故このオブジェクトがその上司へ経路
指定されるのかを示し、上司は従来の設計のように複数
の役割を有することができる。典型的には動作経路オブ
ジェクト２５が作成される時、１つの役割だけが各動作
ストップ２８内に指定され、それはオブジェクト経路指
定システム２１によってその役割を満たす上司の名前に
拡張される。上司に彼等が要求した操作を通知するため
に、システムは役割から彼等の名前を見出し、彼等の名
前から彼等のプリンオブジェクトを見出す。役割から名
前への翻訳及びプリンオブジェクトの探索の繰り返しを
避けるために、プリンオブジェクトのハンドルがそれぞ
れの動作ストップ内に配置される。この例では、ＡＤＳ
の管理者、ＡＢＺの管理者、及びＡＢＺの制御者の役割
だけが初めに指定される。これらは後にそれぞれベン、
チェン、及びダンに拡張され、彼等のプリンオブジェク
トのハンドルがそれぞれの動作ストップに付加される。
別の例では、ある人が彼の幾人かの同僚にメモを経路指
定したいような場合に、かれは目標上司の名前を直接指
定することができる。図６に示す動作ストップ２８は、
経路指定の並行比（即ちどの上司に同時操作を許可する
か）、移動（経路指定されたオブジェクトと、多分動作
経路オブジェクトとを同じ次の上司に配置するか否
か）、及び上司に思い出させるタイマ（指定された時間
枠内にオブジェクトを操作するのを忘れないように）を
案内する付加情報を含む。この情報の詳細に関しては後
述する。図３及び図４は名前拡張後の２つの動作経路
（図３の順次動作経路２５、図４の並行動作経路３０）
の例を示す。各動作経路は見出し２６、本体２７及び後
書き２９を有している。直列経路２５（上述した例を表
す）では、経路指定されたオブジェクトはアンから動作
ストップ２８として名付けられた４人の上司まで直列に
進む。図４の並行経路３０においては、動作ストップ２
８は直列だけではなく並列出あることができる。即ち、
アルがオブジェクトに対する彼の操作を完了したことを
示すと、ビル、ベス及びボブはそのオブジェクトを操作
するように同時にトリガされ、ベスが終了するとサイが
開始可能となり、ボブが終了するとキャシーが開始でき
る。彼等は全て、オブジェクトが接合点３１を介してデ
イブへ（次いでエレンへ）向かう前に終了させなければ
ならない。図示のように、各経路２５または３０は（１
つまたは複数の）現在のストップを示すカーソル３２を
含む。動作ストップ２８は、オブジェクト経路指定シス
テムがその関連上司に予期される操作を通知する（また
は通知することを企図する）と「現在の」となり、上司
がそのオブジェクトを後任（即ち次の）動作ストップへ
発送することを要求すると「先行の」となる（後任が
「現在の」になる）。それぞれの上司は動作経路に対し
ても「先行の」、「現在の」及び「次の」と呼ばれる。
図６は動作ストップ２８の内容を示す。思い出させ情報
は、もし上司がオブジェクトに対して操作しなければこ
の上司に小言を言うことと、操作が行われていないこと
及び他の上司への発送が成功していないことを報告する
ことの要求を指定する。並行標識は、もしこのストップ
が数人の後任社または前任者に同時に関連していれば、
例えばこれらの何れかの、各、または全ての上司が操作
を終了した後に、オブジェクトをどのように経路指定す
るかを指定する。代人フラグは、それがセットされた場
合には、例えば前の上司が休暇のために次の（１つまた
は複数の）ストップの上司がその上司に代わったことを
示す。動作経路を作成し、使用し、そして操作する利用
者インタフェースはエディタに似た機能であり、例えば
アイコンベース型図形エディプログラムで実現すること
ができる。利用者インタフェースは、新しいけいろを作
成し、ある経路を所与のオブジェクトに接続し、経路の
現状を示す基本動作を支持するものとしている。他の動
作に関しては後述する。経路を作成すると、作成者は見
出し、後書き及び各ストップ毎に１つずつ、順組のリス
トを論理用語で供給する。この例ではこのリストは以下
のようになろう（若干のデフォルト値を使用） 上記構文法はエディタプログラムによって翻訳され、見
出し、後書き及び動作ストップの内容が作成される。図
４の並行動作経路３０の例は以下のようになる。但し、
大括弧はどの組の動作ストップが並行化できるかを示
し、また名前は提出者によって与えられ、マーケティン
グのためのセレクタが４５６であるものとする。 オブジェクト経路指定しすてむ２１は、２群の相互関係
にあるメカニズムからなる。以下にオブジェクト経路指
定のプロセスの概要を説明し、このプロセスを履行する
ためにメカニズムが如何に共働するかを説明し、そして
オブジェクト経路指定のために必要な基本的メカニズム
の詳細を説明する。その後に、制御、ハンドルの誤り及
び例外、支持共用、及び並行経路指定を改善するための
付加的なメカニズムを説明する。しかしこれらの付加的
なメカニズムを必ずしも本オブジェクト経路指定システ
ムの一部とする必要はない。これらのサービスは、たと
え効率がやや低く、一貫性がやや欠け、利用者に取って
やや不便ではあっても、たのメカニズム（手動関与を含
む）から得ることができる。図７を参照する。オブジェ
クト経路指定を実現するために必要な基本的メカニズム
は、（１）図８−１１にも詳細を示してあるディスパッ
チ機能３３は、経路指定されたオブジェクトを動作スト
ップ間に伝播させ、他のメカニズムを順番にトリガする
責を負うこと、（２）図１２にも詳細を示してある機能
翻訳３４は企業構造及び役割の機能記述から上司の名前
を見出すために使用されること、（３）図１３にも詳細
を示してある通知３５は上司との通信に、特に経路指定
されたオブジェクトに注意を向けるように上司に告げる
のに使用されること、（４）図１４にも詳細を示してあ
る引き渡し３６は経路指定されたオブジェクトの次の上
司への論理的または物理的移動を取り扱うことである。
図７及び図８−１４の詳細な流れ図は、経路指定された
オブジェクトが１つの動作ストップから次の動作ストッ
プへディスパッチされる時のこれらのメカニズム間の制
御の流れを示す。図１５及び図１６は、後述する２つの
例外呼出し、即ち警告とディスパッチバックのための制
御の流れを示す。これらのメカニズムの芯はディスパッ
チ３３であり、これは経路に沿う各上司によって、そし
て初めは提出者によって呼出され、経路指定されたオブ
ジェクトについて終了したこと、従って経路内の（一人
または複数の）後任者に制御を転送できることを指示す
る。メカニズムは後者の上司の名前及びハンドルが既に
次の動作ストップ内に含まれているか否化を調べ、もし
含まれていなければ、そのストップ内の機能記述から失
われたアイテムを満たすために機能翻訳３４を呼出す。
新上司のオブジェクトへのハンドルを入手すると、それ
はその上司へ経路指定されたオブジェクトに関する情報
を渡すために呼出される。通知メカニズム３５内のプリ
ンオブジェクトは予め選択されている何等かの方法、例
えばメールメッセージまたは特別な合図を使用して上司
に通報する。（変形として、プリンオブジェクト自身が
必要動作を遂行してもよいし、また経路指定されたオブ
ジェクトを全て拒絶してもよい。）次に引き渡しメカニ
ズム３６はプリンオブジェクトを用いて経路指定された
オブジェクトのハンドルを通知する。もし動作経路内に
移動が示唆されていればメカニズム３６はその便益を考
え、もし移動が適切であることが見出されればスーパバ
イザの移動サービスが使用されて経路指定されたオブジ
ェクトを移動させる。このようなシナリオが各動作スト
ップ毎に繰り返される。経路の終端において、ディスパ
ッチ３３は動作経路後書き内に指定されている完了動作
を遂行し、もし要求されていれば、提出者に“良いニュ
ーズ”を告げる。後掲の［表１］は、オブジェクト経路
指定システムの全てのインタフェース操作をモジュラ２
＋文法でリストしたものである。これらの操作は利用者
インタフェースによって、プリンオブジェクトによっ
て、または実際に如何なるオブジェクトによっても呼出
すことはできるが、何れの場合もその呼出しはその目的
を遂行する上司を示す。簡易化のために、呼出者の識別
のような安全要求によって生ずる付加的なパラメタ及び
結果は表１及び以下の説明から省いてある。［表２］
は、オブジェクト経路指定システム２１が呼出すかも知
れない（アップコール）オブジェクト操作をリストした
ものである。ディスパッチメカニズム３３は、現在の上
司が経路指定されたオブジェクトにおける操作を終了す
ると付活され、ディスパッチを呼出す。ハンドルパラメ
タは動作経路オブジェクトか、またはそれに取り付けら
れたオブジェクトの何れであってもよい。（従って、オ
ブジェクトを経路指定するためには経路指定されたオブ
ジェクトへのハンドルだけが必要である。後述するよう
に、これは、別の上司がそのオブジェクトの経路を変更
できること、またはそれを別の経路を有するホルダー内
に配置できることから重要である。）もし参照したオブ
ジェクトが動作経路を有していないか、または経路が既
に使い尽くされていれば、ディスパッチは拒絶される。
そうでない場合には、例えば次のプリンオブジェクトに
到達できないために、たとえ制御の実際の転送が遅れる
ようなことがあっても、ディスパッチは成功裏に戻され
る。ディスパッチは一般的な操作であり、呼出者が経路
指定されたオブジェクトに必要操作を遂行したことを示
す。これは、どのような特定の適用業務の意味（セマン
ティクス）からも自由である。この操作は、制御を実際
に次の上司に転送できるかを確かめるために経路指定さ
れたオブジェクトの状態を調べることはしない。（これ
は本発明のシステムと、前述の適用業務専用設計との主
な差異である。）前の上司が彼等の所要操作を正確に完
了したことを確かめるのは適用業務及び各ステーション
の上司に任されている。もし誤りが発見されれば、後述
するように現在の上司は他のメカニズムを使用してその
オブジェクトを再経路指定することができる。経路指定
されたオブジェクトの状態を調べる能力をディスパッチ
３３に付加すると、オブジェクトの偶発的な早過ぎるデ
ィスパッチのような過ちを防ぐことはできるが、異なる
適用業務の意味に十分に対処することを要求して経路指
定システムを複雑化させるため、この能力は含まれてい
ない。ディスパッチメカニズム３３は、次のストップが
その上司のオブジェクトのハンドルを含むか否かを調べ
る。もし含まなければ、必要ならば機能翻訳メカニズム
３４（図１２）に次の上司の名前を請求し、スーパバイ
ザからその上司のためのハンドルを入手する。次いで、
後述するように通知操作３５を呼出し、次のストップを
「現在の」にセットする。通知は２つの理由から失敗す
るかもしれない。第１に、通信障害のためにプリンオブ
ジェクトを使用できない恐れがある。このような場合、
ディスパッチは後刻呼出しを再び試み、オブジェクトが
使用できるようになるまで所定の間隔で再度試みる。
（プリンオブジェクトは、それが現在存在しているノー
ドがクラッシュしていることを確認できなければ、簡単
に他所で復元できない。そのようにしなければ、オブジ
ェクトは複製される恐れがある。）もし回路網が極めて
長い時間に亙って区切られれば、この遅れが経路指定さ
れたオブジェクトの停止をもたらす可能性がある。幸い
にも、この状態はある思い出させがタイムアウトになる
と発見することができ、思い出した上司が例外処理メカ
ニズムに頼って手詰まりを解消することができる。第２
に、例えば通知される上司が休暇中で、この経路指定さ
れたオブジェクトは別の（代わりの）上司へ向かわせる
べきであるとして通知操作が拒絶されるかもしれない。
この場合、ディスパッチメカニズムは前の上司の代わり
として新上司を動作経路に付加し、前述のようにそのプ
リンオブジェクトのハンドルを入手し、改めてそれを呼
出す。動作経路オブジェクトを維持しなければならない
のであれば、安定装置内のディスパッチチェックポイン
トはその初期状態であり、その後、現在の動作ストップ
の集合への変化と、役割から名前への翻訳とを含む経路
への全ての変更を記録している。動作経路がノードのク
ラッシュで失われたものとすれば、それは安定記憶装置
から復元することができる。効率を高めるために、動作
経路オブジェクトは経路指定されたオブジェクトと共に
移動させてもよく、またそのログ記録はローカルまたは
最寄りの安定記憶装置内に記憶させることができる。デ
ィスパッチメカニズムの設計には幾つかの問題が発生す
る。このメカニズムは経路指定されたオブジェクトが次
のストップへ転送される“準備が整って”いるか否かを
調べないから、少なくともオブジェクトがこのような準
備について調べるべきである。換言すれば、ディスパッ
チはオブジェクトに特定の操作を呼出してこのディスパ
ッチを承認すべきである。この操作は、もし必要ならば
若干の予備ディスパッチ雑用の遂行、移動の評価、また
はオブジェクト経路指定システムの適用業務からの独立
性を低下させることなく適用業務に特定のポリシーの付
加であることができる。この拡張は、特に幾つかのオブ
ジェクトがある経路を共用できまた一緒にディスパッチ
されることから、簡易化のために省かれている。ディス
バッチを承認するために各オブジェクトを呼出すことは
メカニズムを複雑にし、若干のオブジェクトを承認し、
他のオブジェクトのディスパッチを不承認とするには何
をなすべきかが明白ではない。別の問題は、現在の上司
のみに対して、経路上の他の上司に対しても、または多
分どの上司に対してもディスパッチを許可すべきか否か
である。簡易化及び保護の理由から、現在の（１または
複数の）上司のみに操作を制約することが決定されてい
る。もし任意の時点に任意のオブジェクトをディスパッ
チすることをどの上司にも許容すれば、混雑と誤りが広
がることになろう。若干の場合には他の上司が介入する
ことが望ましいかも知れないが（例えば、現在の上司が
オブジェクトを操作することを拒否した場合）、これら
の場合は他の手段によって処理することができる。例え
ば、無視されたオブジェクトを適切な問題処理職へ再経
路指定するために、特別な経路を有するホルダーを使用
してもよい。図７及び図１１の機能翻訳メカニズム３４
は組織内の役割を上司の名前に、そしてその逆に翻訳す
る。このメカニズムは、システム内の全ての組織、全て
の上司、及びそれらの間の結合をリストするシステム規
模の情報ベースを必要とする。この仮定を明確にするた
めに、「システム規模」とは経路指定の範囲内の全ての
組織、即ち経路指定システムがオブジェクトの経路指定
を予定している全ての公認組織単位（例えば群、研究
室、コストセンター）を意味することにする。例えばあ
る会社にあっては、この用語は会社全体に分散している
システムを言う。もしこのようなシステムがより大きい
回路網（例えば幾つかの会社を１つの分散型システムに
接続する回路網）の一部であって、オブジェクトがこれ
らの会社間を流れるのであれば、システム規模はこの結
合された回路網を含む。情報ベースは、中央に集められ
た、区切られた、または複製された名前サービス、また
はエキスパートシステムのような幾つかの方法で実現す
ることができる。結合は、互いに相互参照し合う組織及
び上司の十分に定義された属性である。明白な属性に
は、社員（ある組織内の上司を列挙）、管理者及び秘
書、並びにある組織の親及び子組織が含まれる。この機
能翻訳メカニズム３４の役割は、その経路に与えられた
情報を使用して情報ベースに質問し、必要な名前を取り
込むことである。上例では、情報ベースに照会して順組
（ＡＤＳ管理者）、（ＡＢＺ管理者）、及び（ＡＢＺ制
御者）の上司名を入手することになる。ＡＢＺ制御者の
名前を入手するためには、先ずＡＢＺ（会計組織）の親
組織の名前、次いで適切な制御子組織、次いで制御者の
名前を入手する必要があるかも知れない。次にベン、チ
ェン及びダンのオブジェクトハンドルを取り込み、それ
らを書式の動作経路内へ配置する。もし承認鎖がベンの
管理者の署名も必要とすれば、このメカニズムは効果的
に複合機能「ハンドル入手」（管理者（組織（ベ
ン）））を呼出す。この機能翻訳メカニズム３４はたと
えデータ及び結合を情報ベースから検索できるとしても
制約されているから、このメカニズムの能力には限度が
ある。例えば、“Ｘ計画の技術的リーダー”または“昨
日のセミナーの全ての出席者”のような役割の翻訳は恐
らく失敗するであろう。従って、例えばこれらの出席者
にメモを送るような、機能翻訳メカニズム３４によって
は拡張することができない経路を作成したい場合には、
経路指定システム以外の他の方法によって彼等の名前を
捜さなくてはならない。情報ベースが基準化するよう
に、メカニズムも基準化する。例えば動作ストップ内に
示されている名前及び役割が一群の社員を暗示する場合
には、翻訳は一組の上司名を戻すことができる。この場
合、対応動作ストップは図４の並行動作経路オブジェク
ト３０に示すように、複数の並行ストップに拡張され
る。オブジェクトはこれらの全てに同時に（デフォルト
によって）、または最初のストップの並行化標識に従っ
て、経路指定される。重要な問題は、翻訳３４を遂行す
る時に発生する。例えば、ある適用業務においてはアン
の伝票に署名するコストセンター管理者は、彼女が伝票
を提出した時の管理者であるべきであり、一方他の適用
業務においては伝票がその管理者へ経路指定される準備
が整った時点の管理者であるべきである。後者の場合、
名前と役割との結合が早過ぎると“目標”管理者によっ
てその伝票が拒絶されかねない。しかしシステムは翻訳
・時間の両任意選択（または実際に他のどれよりも）を
許容すべきである。従って、デフォルト及び動的翻訳が
支持される。デフォルトによって、オブジェクト経路指
定システムに最も都合のよい時に翻訳が行われる。もし
全経路を直ちに翻訳する方が、メカニズムが各ディスパ
ッチの度に別個に呼出すよりも経済的であれば、経路作
成時に全てのストップを拡張する（現在行っているよう
に）。そうでない場合には、情報の失効を避けるために
翻訳をできる限り遅くなるように遅延させる。さらに、
経路指定システムは「翻訳」操作（表１参照）を提供
し、これらの適用業務はそれらの都合で呼出すことがで
き、次の動作ストップまたは残りの動作ストップを翻訳
するか否かを指示する。次いでこの適用業務は、メカニ
ズムの単調な細部に関わることなく翻訳する時点を選択
する。それにも拘らず、翻訳後に役割が変化したり、情
報ベース内のデータが最新ではないために、翻訳は誤り
易い。このような場合、オブジェクトは間違った上司に
経路指定される恐れがあり、この上司は例外処理メカニ
ズム（後述）を使用してこの問題を解消できる。上司へ
のハンドルを機能翻訳３４が入手すると、これは図７、
図１４及び表２に示されている通知メカニズム３５によ
って、操作を要求した上司に通知するのに使用される。
しかし、異なる上司は多分、明滅するアイコン、メール
メッセージ、指定されたウィンドウ内のメッセージ、あ
るメールボックス内に列化されたノート、または一組の
操作の直接呼出しのような異なる手段によって通知され
ることを好むであろう。上司は、異なる適用業務または
役割に対して異なるスタイルを要求することさえある。
若干の場合には、上司はオブジェクトを別の上司へ経路
指定する必要があるかも知れない。例えばベンは、彼が
休暇中は全ての経費伝票をベスに、また休暇でない場合
には彼の秘密のビルに転送して欲しいかも知れない。汎
用経路指定システムはこれら全てに適合するスタイルを
どのようにして選択するのだろうか？ プリンオブジェクトの単一インタフェース操作「通知」
（表２参照）が、代替インタフェース操作の代わりに使
用される。通知を受けるプリンオブジェクトは、それ自
信の内部コードによって決定されるどのような動作を取
るかを決定する。プリンオブジェクトは、どのようにし
てその上司に通知するかの標識を含むであろう。この標
識はどの役割にも、どの適用業務セレクタ（またはＩ
Ｄ）にも適用されるか、または各役割（または一組の役
割、または全部）毎に、及び各適用業務セレクタまたは
ＩＤ（または一組のセレクタ、または全部）毎に、好ま
しい通知方法を指定する決定表（小さいプロファイル）
からなることができる。利用者インタフェースは、上司
がこれらの標識を動的にセットし、変更することを許容
するものとする。デフォルトは通知のためのパラメタか
らなる記述子をプリンオブジェクトにおいて列化させる
ことができ、これらの記述子を上司に下検分させ、削除
させる。通知は、上司の便宜のために動作経路から取ら
れた（役割及び対象のような）付加的なパラメタを含
む。「通知」の呼出しは、動作経路が経路指定されたオ
ブジェクトを上司と同じ場所に配置することを示唆する
か否かを示す。もし示唆していれば、引き渡しメカニズ
ム３６（宛先ノードの）がトリガされて移動の便益を評
価する。このメカニズムは、移動のコストと経路指定さ
れたオブジェクトへの予測されるアクセスのコストとを
比較する極めて複雑なポリシーか、または要求されれば
何時でも移動を承認する直接的な（そして好ましい）ポ
リシーを使用できる。上司／プリンオブジェクトに何を
するのかを決定させる一般的な通知操作の変形として、
前述のＩメール及びメッセージ管理システムに採用され
ているアプローチに概念的に類似した、オブジェクト経
路指定システムがアップコールする操作（または操作の
スクリプト）を各動作ストップ内に符号化することがで
きる。このアプローチはプリンオブジェクトのインタフ
ェースを簡略化できるが、オブジェクト経路指定システ
ムを複雑にする。即ち、このアプローチは、適用業務に
は関係のない動作経路内に適用業務に特定の異なる引き
数（または引き数のリストさえも）を記憶させ、オブジ
ェクト経路指定システムにそれらを解釈させる必要があ
る。さらにこのアプローチは、パラメタに値を結合する
（深い結合対浅い結合）時の質問を提起し、この質問に
対しては各適用業務が別々に答えることになり得る。簡
略化のためには、十分に定義されたインタフェースを有
する単一の通知操作が好ましい。オブジェクト経路指定
システムを改善するために付加できる幾つかの付加的な
メカニズムが存在する。第１は、上司は経路指定された
オブジェクトを直ちに操作する必要はないから、若干の
上司はそれらの操作を極めて長時間の間延期するかも知
れず、または未済操作を忘れることさえあり得る。従っ
て、もし彼等が十分に注意を払っていなければ彼等に
“小言”を言い、操作または進行の欠如を、知らせるこ
とを欲する他の上司に報告する手段を設けることが望ま
しい。第２は、役割から名前への翻訳に誤りが発生する
かも知れず、予期せざる状況が発生して操作を異なる過
程へ強制するかも知れない。従って、経路指定の誤り及
び例外を処理するメカニズムが必要である。第３は、全
てのオブジェクトを独立動作経路上に順次に経路指定す
る必要はないことである。異なる適用業務または環境で
は、複数のオブジェクトを単一の経路上へ経路指定し、
オブジェクト間の動作経路をコピーまたは移動させ、ま
たはあるオブジェクトを幾つかの上司と同時に経路指定
する必要があるかも知れない。従ってオブジェクト経路
指定システムは経路共用及び並行経路指定を支持するよ
うに拡大される。思い出させサービスについては幾つか
の設計上の問題が存在する。誰に思い出させるのか、ど
のようにそして何時思い出させるのか、そして頑健で効
率的な分散した思い出させメカニズムを如何にして実現
するかである。先ず、誰にそしてどの件を思い出させる
のか？サービスを一般的に保つためにどの上司にも、所
与の動作経路に関連してどちらの事象が発生しても、彼
等が思い出すことを欲する時点を選択せしめることが好
ましい。詳述すれば、上司は次のような変化を選択でき
るのである。（１）もし別の上司（例えば第３の動作ス
トップの１人）が指定された期間内に、またはある時点
までに経路指定されたオブジェクトをディスパッチする
ことに失敗すれば、その上司に小言を言う。しかし、小
言を言われる上司がその時点に未だにオブジェクトを入
手していないかも知れないので、このサービスは注意深
く使用すべきである。従って、最後のディスパッチ要求
に対する時間と共に使用することがより適切である。利
用者がこのサービスを悪用するのを防ぐために、小言を
言われる上司に要求者の識別が提示されるようになろ
う。（２）上記（１）において操作が行われていない場
合に否定報告を請求する。これは進行の欠如を発見する
ために有用である。後述するように、思い出させた上司
は他の手段に訴えて不注意な上司に対してオブジェクト
に操作するように押すか、またはオブジェクトを別の上
司へ転送させる。（３）オブジェクトが所与の動作スト
ップからディスパッチされたことを示す肯定報告を請求
する。このサービスは、経路指定されたオブジェクトの
進行を監視するために使用できる。思い出させサービス
のこれら３つの変化は、その経路に沿うオブジェクトの
進行と、この進行が停止した場合に必要を生じた直後の
反応とを強力に且つ柔軟に監視することを可能にする。
自分自身による思い出させサービスが経路に影響を与え
ることもなく、また経路指定されたオブジェクトの状態
を変化させることもないので、どの上司もそれを使用す
ることが許されることに注目されたい。しかし、若干の
適用業務がどの上司にも（たとえその上司が経路指定さ
れたオブジェクトへのハンドルを有していても）経路の
状態を見せることを欲しないことがあるかも知れない。
この場合には、オブジェクト経路指定システムは、例え
ば動作経路に対する何等かの操作のためのアクセス権利
を使用するより制約的な保護メカニズムを必要としよ
う。第２の問題は、思い出させる時間をどのようにして
指定するかである。タイマのリストまたは次のタイマを
評価するために呼出される機能を指定することはでき
る。支持されるより簡易な機能はｆｏｒループまたは繰
り返し装置に類似している。タイマは対をなしており
（ベース値、間隔用）、ベース値は絶対（例えば１９９
０年９月１３日５時３７分）でも、相対（例えば最後の
ディスパッチから１週間）でもよく、間隔はベースに付
加される反復値である。思い出させ指令はオブジェクト
が再ディスパッチされる時に明示的にでも暗示的にでも
取消されるまでシステムによって再発行させられる。巨
大な分散型システムにおいては、時計が必ずしも同期し
ているとは考えられないので、これはそれ程簡単ではな
いかも知れない。実際に、異なるノードの時計はスキュ
ーしている恐れがある。そこで所与の（絶対）時刻にＰ
がＱに小言を言うものとすれば、何時（実時間）にＱに
小言を言うべきか？好ましい解決法は、各思い出させ指
令は、それを発行したノード（この場合にはＰのノー
ド）において取り扱い、従ってそのノードのローカル時
と呼ぶ。唯一要求されることは、時間が全てのノードに
おいて単調に増して行くことである。思い出させ指令
は、経路作成時に適用業務によって要求することができ
る。さらに、上司は「思い出し指令セット」を呼出すこ
とによって動的に思い出させ指令をセットしてもよい
し、または利用者インタフェースがこの呼出しをディス
パッチと統合してもよい。この呼出しは、それが小言を
言うためのものかまたは報告（肯定または否定）のため
のものか、及びどの動作ストップにそれが関連するのか
を指示する。この呼出しは、実際の小言または報告にあ
るメッセージ（“メッセージ”パラメタ）を含ませ、小
言を言われるまたは思い出さされる上司との関係を確立
する。上司はそれらの思い出させ指令を除去するために
「思い出させ指令取消し」を使用することができる。そ
のようにされない場合には、思い出させ指令はディスパ
ッチ時に、またはそれらが失効した時にディスパッチメ
カニズムによって除去される。第３は、思い出させ指令
をどのように働かせるかである。思い出させ指令は、要
求されると思い出させサービスに列化され、それへの参
照がそれぞれの動作ストップに配置される。タイマが満
期になると小言及び否定報告が開始され、その時点に思
い出させサービスはそれぞれのプリンオブジェクトの小
言または報告操作をアップコールする（表２参照）。こ
れらの操作に渡されるパラメタは「通知」に渡されるパ
ラメタに類似し、メッセージパラメタは「思い出させ指
令セット」へ供給される本文か、またはデフォルトによ
って、その経路に関係付けられた主体本文である。そう
でない場合には、ディスパッチ操作が完了する前に、現
在の動作ストップが思い出させ指令への参照を含むか否
かが調べられる。もし含んでいれば、このストップに関
係付けられている小言及び否定報告の要求の削除と、肯
定報告の全ての要求の遂行とを思い出させサービスに依
頼する。これは適切なプリンオブジェクトの「報告操
作」を呼出しても行われる。最後に、このサービスを設
計する際の重要な問題は、それを如何に頑健に且つ効率
的にするかである。思い出させ指令を１つのノード（例
えば上述のように要求しているノード）内に保持してお
くことは、そのノードがクラッシュした場合には思い出
させ指令が消滅する恐れがあるので、頑健さを保証する
ものではない。複製したデータベース内にそれらを記憶
させておくことは、極めて高価となり、またデータベー
スの一貫性及び完全に回復するその能力に依存すること
になる。好ましい解決法は、安定記憶サービスを使用す
ることと、分散したブートサービスに頼ることである。
これらのサービスは高度に役立つものと考えられ、もし
それらを提供するサーバがクラッシュしても、比較的速
やかに機能を回復する。思い出させ指令は、高度に使用
可能であるとして登録された存続オブジェクト内に保持
される。このようなオブジェクトが存在しているノード
がクラッシュすると、適切な安定記憶サーバがブートサ
ーバをトリガしてそのノードを再トリガし、その後に、
そのオブジェクトを再記憶する。このシナリオでは、思
い出させ指令はやや遅れるかも知れないが、これは殆ど
の適用業務においては問題ではない。（しかし、これは
ハード実時間適用業務に対しては制限であるかも知れな
い。）このサービスの効率に関しては、そのコストを最
適化する試みはなされていないが、コストをその使用に
比例させる試みはなされている。ある動作経路の共用は
本発明のオブジェクト経路指定システムの重要な特色で
ある。ある動作経路を複数の経路指定されたオブジェク
トが共用するには基本的に２つの形、即ち連続と一時的
とがある。第１の形では、経路は概念的に２またはそれ
以上のオブジェクトに接続される。どのディスパッチ操
作もそれら全てに影響を与え、経路のどのような変更も
それらの各々の経路指定に反映される。第２の形では、
経路は１つの経路指定されたオブジェクトから別の経路
指定されたオブジェクトへコピーまたは転送され、その
後はそれらが同一経路を共用することはない。第３の形
も存在でき、この形ではあるオブジェクトが複数の動作
経路を共用するが、この形は例外的であり混雑の源と見
られるから、支持はされない。連続共用の処理を簡略化
するために、ホルダーオブジェクトを使用して包含する
オブジェクトを群にする。経路を複数のオブジェクトに
接続することはせず、他の全てのオブジェクトが接続さ
れている単一のホルダーに経路を接続する。ホルダのデ
ィスパッチは、接続された全てのオブジェクトを一時に
ディスパッチさせるのと意味論的に同等である。例え
ば、ベンがアンの伝票にメモを添付して両者を一緒に同
じ経路に経路指定したいものとすれば、彼は２つのオブ
ジェクトをホルダーに添付し、「転送」操作（表１）を
使用して伝票の動作経路をホルダーへ転送することによ
って、彼はそのようにすることができる。変形として、
例えば去年の経費伝票の全てを一緒に保持するように、
単に集合させるためにあるオブジェクトをホルダー内に
挿入することができる。挿入されたオブジェクトがホル
ダーの動作経路を共用することはない。何れの場合も、
後にそのオブジェクトをホルダーから取り出すことがで
きる。従って、ホルダーオブジェクト型のインタフェー
スは「取り付け」、「挿入」及び「除去」操作を含むべ
きである。ホルダに取り付けられたオブジェクトもホル
ダーであるかも知れず、実際に添付の階層が存在でき
る。動作経路は、添付されたオブジェクトの木全体に経
路指定が影響を与えるようにこの階層を使用して階層の
中の頂レベルのホルダーに添付すべきである。添付され
た各オブジェクトは、添付されるオブジェクトを示すの
で、添付されたオブジェクトの１つのハンドルしか有し
ていなくとも、表示またはディスパッチのために共通経
路を見出すことは可能である。後刻、オブジェクトを前
の経路に経路指定することを再開する意図で、そのオブ
ジェクトを一時的にホルダーに添付することは、時には
有用であるかも知れない。例えば、上例でベンが協議の
ために別のスーパバイザへホルダーを送り（即ち新しい
特別経路上で）、後にその最初の経路に伝票の経路指定
を続けたいかも知れない。この目的のために、オブジェ
クトＯがあるホルダーに添付される時、添付された動作
経路オブジェクトＡＰＯを有するオブジェクトＯにそれ
を失うことを要求しない。しかし、もしホルダーが既に
（活動）動作経路を有しているが、もしくはそれ自身が
活動動作経路を有するホルダーへ添付されていれば、オ
ブジェクトＯは活動動作経路を保持することはできな
い。そのようにしなければ、オブジェクトＯは複数の経
路を同時に共用し、それをディスパッチするから混雑を
もたらすことになる。これを防ぐために、経路を非活動
にする「中断」を、その後にそれを再付活させる「再
開」を呼出すことができる。もし目標オブジェクト自身
が、（活動）動作経路を有する別のオブジェクトに添付
されていれば、「再開」は失敗することに注意された
い。一時的経路共用は２つの操作によって支持される。
「コピー」は単に動作経路オブジェクトを複製し、どの
オブジェクトがそれに接続されるかを呼出し者に決定さ
せるに過ぎず、「転送」は指示された経路を別の動作経
路オブジェクトに再添付し、前の動作経路オブジェクト
から経路を削除する。誰にでも自由に、１つのオブジェ
クトから別のオブジェクトへ動作経路を転送させ、また
は１つのホルダーから別のホルダーへオブジェクトを転
送させるようにすることは、若干の適用業務の保護要求
を犯すことになる。それでも前述したように、若干の状
況の下ではこのような能力が望ましいかも知れない。こ
の矛盾に対処するために、オブジェクト経路指定システ
ムは、それへのハンドルを誰が有していようとも経路転
送、中断及び再開を許容するが、これらの動作はある経
路に組合わされている履歴ログに記録され、追跡するこ
とができる。より厳格な保護メカニズムは、後述するよ
うなこれらの操作のための能力を要求しよう。並行経路
指定は本発明のオブジェクト経路指定システムの別の重
要な特色である。動作ストップは複数の直前の前任者ス
トップまたは直後の後任者ストップ、即ち図４の動作経
路オブジェクト３０に見られる並行経路を有することが
できる。このような場合、ストップのファンアウトまた
はファンインが１よりも大きければ、問題は全てを、何
れかを、または若干をの選択肢を選択することである。
詳述すれば、あるオブジェクトがディスパッチされ、複
数の次のストップが存在する場合、そのオブジェクトを
それらの全てに同時に（全面的に）経路指定するべき
か、またはある選択機能を適用すべきかである。同様
に、あるストップが幾つかの前任者ストップを有してい
る場合、それらの全て（全面的に）、何れか、または若
干がオブジェクトをディスパッチする時に、それは「現
在の」になり得るかである。先に説明（例えば図４に関
して）は、ファンアウト及びファンインが１よりも大き
い場合、並行化を制御する機能がオールアウト（アルの
場合）及びオールイン（デーブの場合）であることを示
唆している。しかし、若干の適用業務は他の可能性を好
むかも知れない。例えば、承認が多かった、または拒否
が多かったかに依存して、複数の検査者に同時にディス
パッチされた提案はコーディネータによって操作され得
る。問題は、適用業務が何を欲しているかを汎用オブジ
ェクト経路指定システムがどのようにして知るかであ
る。１つの変形は条件付き表現式と動作ストップとを対
応付け、例えば「ディスパッチ」を介して上司に諸条件
を可能ならしめることである。（概念的に類似のアプロ
ーチを上述のメッセージ管理システムに使用した。）こ
のアプローチは、適用業務に特定の変数及び意味を経路
内に置くので、ここでは使用されなかった。別の変形
は、「ディスパッチ」を介して上司に並行化機能を選択
させることである。これは、上司が彼等のストップにお
いて動作経路の接続形熊（トポロジ）を知る必要があ
り、並行グラフ内の上司が矛盾する機能を選択する時に
混雑を生じさせる恐れがある。並行経路指定のこれらの
変形の代わりとして、機能オールアウト及びオールイン
がデフォルトとして支持され、適用業務はもし必要なら
ば他の機能を指定することが許容される。詳述すれば、
あるオブジェクトが複数の後任者を有するストップにお
いてディスパッチされる時、そのオブジェクトは（別の
機能が指定されていない限り）全ての後任者へ同時に経
路指定され、もしあるストップが複数の前任者を有して
いれば、そのストップは全ての前任者がオブジェクトを
ディスパッチするまで「現在の」にはなれない。システ
ムは、ファーストイン、多数イン、及び各インのような
機能から選択された付加的な機能を提供する。これは、
図４のオブジェクトの３０の例では、ビル、サイ、また
はキャシーの何れかが完了すると（ファーストイン）、
または彼等の最初の２人が完了すると（多数イン）、ま
たは彼等の各々が完了する度に（各イン）、デーブが現
在の上司になり得ることを意味する。適用業務は、各動
作ストップの並行化標識（図６参照）をこれらの機能の
何れかに、または適用業務専用機能にセットすることが
できる。この標識は経路作成時か、または「並行セッ
ト」（表１参照）を動的に呼出すことによってセットす
ることができる。（表１の“ｗｈｉｃｈ”）パラメタ
は、その動作経路またはデフォルトによる並行動作経路
から検索できる動作ストップに対応付けられた番号であ
り、“ａｒｇ”は指示された機能“ｆ”に渡される未解
釈値である。）保護のために、上司は、その関連動作ス
トップのみに影響を与えるが他には影響を与えないよう
に、この操作を呼出すことができる。この機能は、対応
ストップにおける並行経路指定について決定をなさなけ
ればならない時は、「ディスパッチ」による“未呼出
し”であろう。簡易化及び汎用性のために、全ての適用
業務専用機能は標準インタフェースに固執しなければな
らない（表２のパーイン及びパーアウト機能参照）。パ
ーイン機能は複数の“入ってくる”アークを有するスト
ップが現在のストップになり得る時を決定し、パーアウ
ト機能は“出て行く”アーク上のどのストップが現在の
になり得るかを決定する。並行経路指定に伴う１つの問
題は、移動を如何に処理するかである。基礎をなすシス
テムがオブジェクト複製を支持しないから、経路指定さ
れたオブジェクトは多くとも１つの並行上司へのみ移動
できる。もし殆どの並行上司がとにかく１人の上司の位
置に位置しているか、またはその上司が比較的より屡々
オブジェクトと対話することが予期されれば、オブジェ
クトを１人の上司の位置へ移動させることは合理的であ
る。一方、もしこれら全ての上司が分散していてそのオ
ブジェクトと同じように且つ同時に対話するのであれ
ば、そのオブジェクトはどの位置へも移動させるべきで
はない。そこで問題は、どのような変形を選択するかで
ある。適用業務または経路指定システムの何れかに決定
させると、両者の複雑さが増加する。複数の次のストッ
プが存在する場合に、また移動ヒントが移動を示唆して
いる場合でさえ、オブジェクトを移動させるのを控える
方が好ましい。このポリシーは、若干の場合におけるオ
ブジェクトとの対話の潜在的非効率（これらの対話が遠
隔呼出しを包含するから）と、他の場合における経路指
定システムの簡略さと効率（多重移動がセーブされるか
ら）とをトレードオフする。さて例外を説明する。ある
オブジェクトの滑らかな経路指定は、基本的に３つの状
況において妨害され得る。即ち（１）次のプリンオブジ
ェクトが到達不能であり、従って前に示唆したように
「通知」に失敗する場合、（２）現在の上司が誤りを見
出し、それをその経路を戻ってオブジェクトに報告する
ことを欲した場合（例えばアンの伝票の場合には、チェ
ンが経費のかかり過ぎを発見するか、またはベンが正し
く署名しなかったので伝票をベンまで戻したい場合）、
（３）前の上司が経路指定されたオブジェクトに関係す
る状態を発見し、それを現在の（１人または複数の）上
司の注意をひくために送りたい場合（例えば図４のメモ
の提出者は、全ての指名された上司によるメモの監査が
前に考えていたよりも早く完了するだろうことを見出す
ことができる）。次のプリンオブジェクトに通知のため
に到達できない場合には、経路指定されたオブジェクト
はその動作経路上を進行することができず、従って期限
に遅れるかまたは欠如さえしかねない。前述のように、
「通知」の呼出しに失敗すれば、「ディスパッチ」は成
功するまで一定の（実施によって特定された値）間隔で
再試行する。「通知」の呼出しには成功するが、通信の
諸問題で返答に失敗することが起り得ることに注意され
たい。これは、「通知」または通知された上司は重視呼
出しを認識できるべきであるから、問題とは見做されな
い。もし回路網が区切られており、次のプリンオブジェ
クトに長時間に亘って到達不能であれば、経路指定シス
テムは上述の問題を解消するために思い出させサービス
または若干の上司の短気に頼る。例えばある上司は経路
指定されたオブジェクトの手詰りを、そのオブジェクト
をホルダーに添付することによって打開し、特別な経路
上のその対を適切な職務へ経路指定することができる。
例外の第２例では、現在の上司は経路指定されたオブジ
ェクトを２つの方法で後方へ戻すことができる。「通
知」を呼出す時に誤りが発見されれば、「通知」はその
呼出しを拒絶し、そのオブジェクトを経路指定すべき別
の上司の名前を任意選択的に戻すことができる。変形と
して、もし誤りが後刻発見されれば、現在の上司は「デ
ィスパッチバック」（図１６）を呼出してそのオブジェ
クトを拒絶することができる。この呼出しは、拒絶の際
に拒絶の理由を説明する任意選択本文を通知できるよう
に、代替上司を名指しすることができる。もし代替名が
与えられないか、またはそれが「悪い」に転ずれば、オ
ブジェクトは前の（１人または複数の）上司へ経路指定
され、この（これらの）上司は再び現在の上司になる。
上司はこのことを「例外通知」（表２）を介して通知さ
れる。（もし今度は呼出されたプリンオブジェクトに到
達不能であれば、呼出しは「通知」の場合のように再度
試みられる。また、「ディスパッチバック」はディスパ
ッチと同じようにして先の思い出させを取消す（図１６
のブロック９２ａ参照）。）この操作のパラメタは「通
知」のパラメタに類似し、同じ目的に役立つ。“ｒｅａ
ｓｏｎ”及び“ｄｉｒｅｃｔｉｏｎ”パラメタは付加的
な説明を与える。もし誤りが重大であれば、提出者に戻
される間ずっと上司はオブジェクトを再度「ディスパッ
チバック」できる。これはプログラミング言語における
例外逆伝播に概念的に類似している。上述の例外の第３
例では、「警告」（表１及び図１５参照）を介して順方
向例外を掲げることによって現在の（１人または複数
の）上司の注意を引くことができる。ディスパッチメカ
ニズムは、前述のように「例外通知」を介して（“ｄｉ
ｒｅｃｔｉｏｎ”をＦｏｒｗａｒｄにセットして）現在
の（１人または複数の）上司に通知する。通知された上
司は、例えば経路指定されたオブジェクトを迅速に操作
するか、または誤りの場合には「ディスパッチバック」
を介してそれを戻す等、如何に反応するかを決定する。
図８はディスパッチ操作を実行する際の制御の流れをよ
り詳細に示す。あるノードはエントリ４５において経路
指定されたオブジェクトに関してディスパッチの呼出し
を受ける。この経路指定されたオブジェクトはハンドル
ｈを有し、このｈのための動作経路オブジェクトがブロ
ック４６において入手される。動作経路及び呼出しは、
それらが正しいか及び許容されるかが判断４７及び４８
において調べられ、もしＮであれば誤りは戻される。現
在の動作ストップにおける思い出させ操作の要求はブロ
ック４９で実行される。ブロック４９は図９の流れ図Ａ
１を含み、各要求はそれが小言のためかまたは判断点に
おける否定報告のためかが調べられ、もしＮであればブ
ロック５２において肯定報告のためのプリンオブジェク
トの報告操作を呼出すために、思い出させ機能が呼出さ
れる。もし小言か否定報告の何れかであれば、ブロック
５３において思い出させメカニズムによって要求は破棄
される。全ての要求の後に判断５４においてカーソルが
調べられ、これが動作経路内の最後のストップか否かが
判定され、もしＹならばブロック５５及び第１０図の流
れ図Ａ２において後書き操作が遂行される。もしこれが
最後の動作経路でなければ、ブロック５６においてカー
ソルがリセットされて次のストップが現在のストップに
され、制御は図１１の流れ図Ａ３に示す通知及び引き渡
しメカニズムに渡される。図１１の判断５８は先ずプリ
ンオブジェクトへのハンドルの存否を調べ、Ｎであれば
ブロック５９において機能翻訳操作が呼出される（図１
２の流れ図Ｂ）。もしハンドルが存在すれば、ブロック
６０が通知機能を呼出す（図１３の流れ図Ｃ）。判断６
１は呼出しが成功したか否かを（即ち上司オブジェクト
は到達可能か否かを）調べ、Ｎであればブロック６２に
おいて再試行が列化される。もし呼出しが成功し、返答
を受ければ判断６３は通知が受諾されたか否かを調べ、
もしＹならばブロック６４において引き渡しメカニズム
が呼出される（図１４の流れ図Ｄ）。引き渡し後、もし
あれば、戻す前に小言要求を列化することができる。も
し通知呼出しが判断６３において否定され、判断６５に
おいて代替上司が名指しされていることが見出されれ
ば、ブロック６６は新上司のための動作ストップを動作
経路オブジェクトに付加し、この新ストップを現在のも
のとする。ブロック６７において新プリンオブジェクト
のハンドルが入手され、制御はＦ点に戻されて代替長司
の通知が呼出される。もしその動作ストップが動作経路
内の最後の動作ストップであれば、図８のブロック５５
において後書きが呼出され、制御は図１０の流れ図に移
される。考え得る動作の各組の存否が一連の判断６８、
６９及び７０によって調べられ、ブロック７１、７２及
び７３においてそれぞれの動作の何れかが遂行される。
もし“破棄”が存在しなければ動作経路は安定記憶装置
内に残されるが、もし存在すれば全てのトレースは除去
される。図１２を参照する。機能翻訳は判段６９の決定
に従って全てのまたは１つの動作ストップ上で遂行でき
る。もし全てに対して遂行するのであれば、ブロック７
０に示すように図１２の流れが各動作ストップ毎に繰り
返される。判段７１は上司の名前がその動作ストップ内
にあるか否かを決定し、もし存在しなければブロック７
２においてその名前が情報ベースから回復される。返答
を受けると、それは判断７３において単一の名前である
か否かが調べられる。もしＮであれば群を拡張して群の
各職員を入手し、各名前が回復される。１つの、または
複数の名前を入手した後、制御は経路７４に戻され、判
段７５は上司のプリンオブジェクトのハンドルが動作経
路内に存在するか否かを調べ、Ｎであればブロック７６
においてハンドルがオブジェクトスーパバイザから取り
込まれる。通知機能は図１３に示されている。先ず、判
段７７はプリンオブジェクトが好ましい通知方法のパタ
ーンを有しているか否かを判定する。もしＮであればブ
ロック７８においてデフォルト通知方法が実現される。
もし有していれば、判段７９、８０及び８１を含む判断
の木に進んで、役割及び適用業務セレクタのためのエン
トリの存否が調べられ、その後にエントリが実行され、
判断８２において経路指定されたオブジェクトが受諾さ
れたか否かが調べられる。もしオブジェクトを受諾すべ
きではないことをエントリが示せば、代替上司（もしあ
れば）へ戻される。受託されれば、ブロック８３に示す
ように通知方法が遂行される。図１４は引き渡しメカニ
ズムの流れ図である。判断８４において、移動ポリシー
が協議され、動作経路オブジェクト内の移動ヒントが比
較される。もし移動が推奨されなければ制御は戻される
が、推奨されればブロック８５においてスーパバイザの
移動メカニズムが呼出される。ブロック８６に示すよう
に、もしその動作がポリシーによって推奨されれば、オ
ブジェクトは安定記憶装置内へも移動される。警告及び
ディスパッチバック機能の流れ図を図１５及び１６に示
す。警告の場合、ブロック８７及び判断８８において経
路指定されたオブジェクトｈのための動作経路オブジェ
クトが含まれているか、及び正しい動作経路であるかが
調べられ、次いで例外通知（表２）がブロック８９にお
いて呼出される。判段９０における判定は呼出しが成功
したか否かを調べるものであり、もしＮであればブロッ
ク９１において再試行が列化される。図１６のディスパ
ッチバックメカニズムは、現在の動作ストップに対応付
けられた要求を処理するブロック９２ａまでは図８のデ
ィスパッチメカニズムと同一である。次の判断９２ｂは
代替上司が名指されているか否かを調べ、もしＹがあれ
ばブロック９３はこの代替上司のための動作経路に新動
作ストップを付加する。ハンドルが入手された後図１１
のエントリ点下に戻される。もしＮであれば、ブロック
９４において前の動作ストップが「現在の」にセットさ
れ、点９５において“ｄｉｒｅｃｔｉｏｎ”をｂａｃｋ
ｗａｒｄにセットすることによって例外通知が呼出さ
れ、次いで判段９６において呼出しが成功したか否かが
調べられる。もし呼出しが成功しなければ、ブロック９
７において再試行が列化される。本発明のオブジェクト
経路指定システムの実施例は、前述のＢｉａｃｋ＆Ａｒ
ｔｓｙの刊行書に記載の分散型システム内で実現されて
いる。この刊行書は高度に分散した適用業務を構成する
ための枠組を記述している。例示システムは利用者レベ
ルで走る図１または図２の論理ノード１０−１３からな
り、オブジェクト向きプログラミングを支持し、ＬＩ
Ｉ、オブジェクト移動及びオブジェクト維持のためのサ
ービスを提供する。オブジェクトスーパバイザは各ノー
ドに常駐してこれらのサービスを提供する。システムは
モジュラ２＋で実現され、供給されたＰＲＣとマルチス
レッドサービスを提供する。このモジュラ２＋システム
はＩＥＥＥ Ｓｏｆｔｗａｒｅ３：６（１９８６年１１
月）の４６−５７頁にＰ．Ｒｏｖｎｅｒが「大きい統合
されたシステムへのモジュラ２の拡張」として記述して
いる。実施例は、適用業務が書式、ホルダー、上司及び
メモオブジェクト型からなるある会社内のマイル当り経
費伝票を処理するように実現できる。これは経費報告を
処理する上述の適用業務例に類似している。端末に座す
従業員はグラフィック、ウインドウベース型利用者イン
タフェースを使用して伝票テンプレートをポップアップ
させ、所要の書込みを行い、そしてそれをシステムに提
出する。適用業務は動作経路を、利用者に透明な伝票オ
ブジェクトに割り付ける。典型的には動作経路は従業
員、彼のまたは彼女のコストセンターの管理者、そのコ
ストセンターの責任者である出納係、及び記録保管者を
含む。経費の量及び本質に依存して、伝票は別の管理者
の承認を必要とするかも知れず、経路は長くなるかも知
れない。従業員、管理者、出納係及び記録保管者は典型
的には互に接近している（同一ＬＡＮ）が、若干の場合
には彼等は数乃至数千マイルも離れているかも知れな
い。この適用業務例では従業員、管理者、出納係及び記
録保管者はプリンオブジェクトで表わされる上司であ
る。しかし出納係及び記録保管者は自動化されており、
従って彼等は異なる対話スタイルを使用する。この例示
オブジェクト経路指定システムは上述した機能の部分集
合を含み、全てのデフォルト任意選択を支持する。適用
業務は、伝票オブジェクトがシステムに提示された時に
動作経路を作成する手続きを提供する。この手続きは伝
票（前述の費用償還例におけるアンの伝票の１つに類
似）を操作する（組織役割による）上司のリストを指定
する。名前サービスは情報ベースを記憶するために使用
され、このベースは上司名と彼等の組織的結合とを含
み、またプロトタイプ内の各組織単位毎に従業員、管理
者及び他の幾つかの職務のリストを含む。機能翻訳メカ
ニズムはこの名前サービスを使用して上司の名前を見出
し、彼等のオブジェクトのハンドルをスーパバイザを介
して入手し、そしてそれらを動作経路内の適切なストッ
プに付加する。伝票をディスパッチするために、人間の
利用者（従業員または管理者）が彼のまたは彼女のワー
クステーション画面上のディスパッチアイコンをクリッ
クれせると利用者インタフェースは適切なパラメータを
有する「ディスパッチ」を呼出し、自動化された出納係
または記録保管者のプリンオブジェクトは直接「ディス
パッチ」を呼出す。人間上司のための通知のデフォルト
方法は、経路指定されたオブジェクトハンドルをその経
路の主体を有する上司の“インボックス”ホルダー内に
挿入することである。人間利用者のための利用者インタ
フェースはこのホルダーを周期的にポーリングし、もし
そこに新オブジェクトを発見すれば、インタフェースは
明滅するアイコンによってこの事実を利用者に示す。利
用者は彼等の都合によってホルダーを開くことができ、
彼等の操作を待っているオブジェクトの実体を見、それ
を指すことによって彼等が処理しようとしているものを
選択することができる。しかし自動化された出納係のた
めの通知操作は、伝票の内容を調べ、署名（及び、勿論
小切手の発行）を確認するためのその確認操作を直接呼
出す。記録保管者のプリンオブジェクトの通知操作は単
に伝票をファイルし、それを直ちに再ディスパッチする
だけである。この例示適用業務における移動ヒントは常
にイエスであり、デフォルトポリシーは経路指定された
オブジェクトを現在の上司の位置へ移動させることであ
る。ホルダーオブジェクトは複数のオブジェクトを単一
の経路に経路指定するために使用される。別の実施例で
は、本発明の概念を、種々の拡張機能を有するシステム
内に使用できる。例えば、トランザクション処理がこれ
らの概念を用いることができる。ビジネストランザクシ
ョンは会計または銀行員の予め限定されたリストのよう
な十分に定義された論理経路を有することが多い。動作
経路はこの目的に使用でき、経路指定されたオブジェク
トはトランザクションの“実体”（例えば金銭転送簿）
であるか、または各ストップにおいて遂行されるトラン
ザクションスクリプトである。しかしトランザクション
処理は、トランザクションの打切りまたは若干の操作の
取り消しのような若干の付加的サービスを要求する。こ
れらの付加的サービスを含むように経路指定システムを
拡張するためには、トランザクション処理に必要な独特
なサービスを経路指定システムに付加することになる
か、またはトランザクション処理用意味を経路指定シス
テム内に組入れることになる。例えば、２つのシステム
を統合する一方法は、各動作ストップにおける動作をサ
ブトランザクションとして見ることである（経路全体は
ネストされたトランザクションである）。経路指定シス
テムは、経路指定されたオブジェクトに対する委託、打
切り、取り消し、またはやり直し操作の要求に従って経
路を変更することを許容しよう。変形として、各動作ス
トップはログラベルを用いてタグを付けることができ
る。またディスパッチは各動作ストップにおける変更を
記録または委託することになろう。経路指定されたオブ
ジェクトをそのストップにディスパッチバックするもの
とすれば、経路指定システムは自動的に、または求めに
応じて、経路指定されたオブジェクトの状態をラベルを
付けたログ記録まで戻すようにロールさせることができ
る。本発明は、分散型システム内の完全な“不要部分の
整理”を受入れるために若干の変更を必要としよう。通
常は経路指定されたオブジェクト（Ｏ）が経路を完成さ
せると、動作経路は消滅するが、若干の適用業務がそれ
を後の監査のために残すことを欲するかも知れない。若
干の場合には、もし適用業務が経路の終りにおけるＯか
らのＡＰＯの切離しに注意深く、またＡＰＯを明示的に
処置するかまたは自動的な不要部分の整理メカニズムに
それを取り戻させるようにすれば、ＡＰＯの処置は容易
に達成できる。しかし他の場合には、多くのプリンオブ
ジェクトが未だにＡＰＯへの参照を有しているかも知れ
ないので、ＡＰＯの取り戻しは困難であるかも知れな
い。ＡＰＯへの参照が存在していても“孤児”ＡＰＯを
収集する能力を改善するために、若干の適用業務ヒント
が必要である。上述の実施例では、プリンオブジェクト
に経路指定されたオブジェクトへのハンドルが与えら
れ、従って通常はＯだけがそのＡＰＯへの参照を有して
おり、これは経路の終りに容易に落とされる。変更を必
要とする別の領域は、完全な保護された易変性の供給に
ある。上記説明では、機能翻訳に基づいて経路を拡張で
きるのはディスパッチメカニズムに限られ、現在の上司
は代替を提供していた。そのようにしないと利用者は動
作ストップのグラフを変更することができない。しかし
若干の適用業務においては利用者が動作経路を変更する
ことを許容されるか、または要求さえするかも知れな
い。このような機能が有用である例は初めの群の人々に
メモを送るに当って、各人がメモを見ることに関心があ
るかも知れない他人の名前を要求（そしてそれらをある
順番に経路内に付加する）するような場合である。これ
はメモのコピーをホルダー内に置き、特別な経路を使用
することによって（上品さは欠けるが）達成することが
できる。利用者にグラフの拡張または変更を指定させる
ことは若干の状況では有用であるが、グラフの複雑さ
（経路が極めて複雑になり得る）と経路の一貫性（並行
経路内の異なる利用者が矛盾する枝路を示唆されるかも
知れない）の問題が発生し、考え得る全ての変更を表現
するためには複雑な利用者インタフェースを必要としよ
う。またそれは変更が適用業務によって許容されている
ことをどのようにして確認するかの問題も提起する。さ
らに、若干の適用業務は、事象の報告の入手または経路
の複写を含む経路に対する操作の使用をより多く制約す
ることを要求するかも知れない。何れの方法において
も、経路指定の意味を適用業務内に導入する、または適
用業務の意味をオブジェクト経路指定内へ導入すること
はできるが、両アプローチ共望ましいものではない。オ
ブジェクト経路指定システムを拡張する一方法は、能力
またはアクセス制御リストと動作経路と、を、または各
ストップとでさえ結合し、公認されていない変更から保
護するために確認（オーセンチケーション）サービスを
使用することである。これらのリストは適用業務に特定
の意味を有するが保護メカニズムは適用業務に無関係と
することができる。このような拡張は経路指定システム
の複雑さを増大させよう。以上に、メールメッセージ、
構造化データ型、またはファイルのような各種のオブジ
ェクトを経路指定するために使用できる総合的なオブジ
ェクト経路指定システムを説明した。このオブジェクト
経路指定システムは、人間の利用者の便宜のための幾つ
かの機能（例えば本文記述の使用、思い出させ、及び選
択的通知）を含み、実施例に示したように経路指定の目
標上司を自動化ツールとすることもできる。本オブジェ
クト経路指定システムと従来システムとの差異は、前述
した有用なメカニズムの使用、若干の独特機能によるア
ップグレード、適用業務には無関係の汎用分散型システ
ムサービスの提供にある。経路の評価及び変更に若干の
制約が課せられてはいるが、経路指定されたオブジェク
トの進行を制御し監視する、及び若干の事象が上司の注
意を必要とする場合には上司に通知の方法を選択させる
強力且つ柔軟なツールが提供される。オブジェクト支持
サービスより上位のサービス層としての経路指定システ
ムの構成が、このシステムを使用が簡単で、均一で、強
力なシステムとしている。要約すれば、このシステムの
“オブジェクト指向度”がもたらしたシステムの主な便
益は以下のようである。 （１）保護。動作経路をオブジェクト内にカプセル封じ
したことによって、情報の隠蔽と経路の状態の保護が与
えられる。反対に、もしメールシステムにおいて経路が
メールメッセージの一体部分であれば、その内部状態は
隠蔽されることもないし、利用者から保護されることも
ない。 （２）呼出しの均一性。経路に対する操作は、経路指定
されたオブジェクトに対する操作及び目標上司に対する
操作と同じ方法で呼出される。 （３）インタフェースの均一性。経路指定の目標はオブ
ジェクトであるから、それらが人間であるのか自動化ツ
ールであるのかは経路指定システムの目から区別するこ
とはできず、システムはそれらと通信するのに同一の方
法を使用する。これは通知及び思い出させを簡単にす
る。 （４）通信及び追跡性。下位の位置に無関係のオブジェ
クト間通信メカニズムはオブジェクト経路指定システム
の設計を簡単にする。上司は、彼等が何処にいるかには
関係なく通知されることができる。経路は、それらの現
在位置には関係なく上司によって検査することができ
る。この機能は、動作経路に沿うオブジェクトの進行を
制御する能力を与える重要な便益を提供する。一方、メ
ッセージ経路指定システムでは、このような追跡性はメ
ッセージをオブジェクトとして見、本発明のサービスと
類似のサービスを使用するか、またはメッセージデータ
ベースを使用することによって達成することができる。
中央に集められたデータベースを使用するとシステムの
拡張性が制限され、一方分散したデータベースを使用す
ると一貫性を維持するための通信コストが高くなる。 （５）共用及び並行化。経路共用及び並行経路指定はオ
ブジェクト向きシステムにおいては容易である。これは
対してメッセージベース型システムにおいては複数のメ
ッセージによる同一経路の共用（その更新を含む）は殆
ど不能であり、同様に複数の上司が単一のメッセージ
（そのコピーではない）に同時にアクセスすることも殆
ど許されない。 （６）効率的な対話。オブジェクト移送は、経路指定さ
れたオブジェクトと次の上司とを動作経路上で同位置に
配置することを許容する。一方データベース内に記憶さ
れている経路指定論理構成要素は、それらを対話ノード
へ“移送”するか、または全ノードに常駐するローカル
区切りでデータベースを区切らない限り、この便益は受
けられない。 （７）アドレス指定の簡易化。メッセージベース型、ま
たはメールベース型の経路指定では、システムは名前を
回路網に広がる、従って変化することがあるアドレスに
変換しなければならず、従って誤りが導入され易い。オ
ブジェクトスーパバイザが（使い古された回路網アドレ
スを扱う）目標オブジェクトを捜さなければならない
が、これは経路指定システムから隠蔽され、従ってその
設計を容易ならしめる。勿論、移動するオブジェクトを
追跡し、オブジェクトハンドルをオブジェクト位置へ写
像するためにスーパバイザは複雑になる。しかし、何れ
にしても後者は分散型オブジェクト向き適用業務を支持
するためにこの問題に対処しなければならないから、経
路指定システムはこの簡易性を殆ど“無料で”入手す
る。 以上の説明は、特定プロセスにではなく、経路指定を支
持するメカニズムに焦点を絞った。動作経路を指定する
プログラミングツールは、選択されたシステム及びプロ
グラミング言語に依存して種々の型であってよい。ある
経路は適用業務内の“ハードワイヤード”でよく、ある
経路はテンプレート経路のライブラリから作成でき、ま
たある経路は特別な経路としてグラフィックまたは本文
向き利用者インタフェースによって作成してもよい。言
語ベース型ツールも経路を指定でき、それらを生成する
コンパイラを有し、前述のメッセージ管理システムにや
や似ている。以上に本発明の特定の実施例について説明
したが、この説明は本発明を限定するものではない。説
明した実施例に種々の変更が考えられるがこれらの変更
も本発明の範囲内に含まれることを理解されたい。
数のノード１０、１１、１２及び１３を含み、各ノード
は典型的にはＣＰＵ１４及びメモリ１５を有するワーク
ステーションであり、またハードディスク記憶装置１６
及びコンソール（キーボード及び表示装置）１７をも有
することができる。これらは全てシステムバス１８によ
って相互に接続されている。各ノードをリンク２０によ
って他の全てのノードに接続するために通信アダプタ１
９が使用される。図には４つのノード１０−１３だけを
示してあるが典型的には数百乃至数千のノードが存在
し、またリンク２０は、例えばＤＥＣネット、トークン
リング、スターＬＡＮ、またはイーサネット型の構内通
信網、並びに光ファイバリンク（ＦＤＤＩ）及び衛星リ
ンク、またはブリッジノードを使用するこれらの組合せ
（これらは全て広域通信網の一部であってよい）を含む
ことができる。ノード１０−１３はメモリからのコード
を実行するＣＰＵを有するワークステーションとして示
してあるが、勿論、以下に説明する論理処理を実現する
ためのステートマシーンの如きあるメカニズムを含む単
なるディスク記憶装置等のような別の型の資源であって
差し支えない。通常図１の例の各ノード１０−１３はオ
ペテーシィングシステム（例えばユニックスまたはＤＯ
Ｓ）のそれぞれのコピーを実行して論理ノードを作成す
るが、個々の利用者がユニックスのようなマルチユーザ
オペレーティングシステムを実行する中央コンピュータ
のバスに接続されている端末を有するような場合には、
複数のノードが単一のＣＰＵを利用して実行してもよ
い。ノード１０−１３の位置及びそれらの通信メカニズ
ムはオブジェクト経路指定システムに対して透明であ
り、後述するようにこのオブジェクト経路指定システム
はオブジェクトハンドルを使用してオブジェクト呼出し
を処理する。図１の物理ノード１０−１３は大きい距離
に亙って離間するかも知れず、本発明の方法において操
作されるオブジェクトは通常これらのノードの１つの利
用者と、あるオブジェクト内のデータ構造との間にある
型の対話を必要とするからそのオブジェクトをローカル
にする、即ち現在オブジェクトを操作中のノード１０−
１３に維持することが望ましい。もしノード間の距離が
大きければ、そのオブジェクトを１つのノードに維持し
て置いて回路網リンク２０を通して他の必要ノードによ
って操作することは、応答時間が不当に長くなり、また
通信リンク２０に過大な負荷を課すことになるので、容
認し難い。勿論、呼び出される全てのノードが相互に接
近していれば、オブジェクトを１つのノードから別のノ
ードに移動させる必要はないが、もし必要ならば移動能
力を使用しなければならない。図２に、図１の中の１つ
のような分散型システムのサービス層及び適用業務オブ
ジェクトを論理フォーマットで示す。図２内の論理ノー
ド１０′、１１′、１２′または１３′は、コードを実
行するために図１のＣＰＵ１４によってアクセスされる
アドレス空間に物理的に関係付けることができる。図１
のシステム（即ちワークステーションで実現した型）で
は物理アドレス空間は主としてメモリ１５内にあるが、
前述のように物理ノードはワークステーション以外のメ
カニズムであって差し支えない。即ち、論理ノード１
０′−１３′は通常は（しかし必須ではない）図１の単
一物理機械１０−１３に写像（マップ）される。どのよ
うな事象においても図２の各論理ノードはオブジェクト
向き適用業務を支持する。この場合、適用業務は複数の
論理ノードに亙って分散できるオブジェクトからなり、
また適用業務はオブジェクトを共用できる。人または自
動化職務であるシステム利用者は、オブジェクトによっ
て論理システム内に表される。図２の論理ノード１０′
−１３′は複数の適用業務オブジェクトＡ１、Ｂ１、Ａ
２、Ｂ２等を有し、これらはローカルオブジェクトとし
て知られるオブジェクトインスタンス（例示されたオブ
ジェクト）である。あるオブジェクトは独特に識別され
る自己包含型論理構成要素であって、論理ノード間に再
配置可能である。オブジェクトとは、本質的に周知の操
作のリストまたはデータへのアクセス方法を有する周知
の方式でデータをカプセル封じするある概念と定義さ
れ、独特の識別を有し、移動可能であり、そして多分持
続するものである。ここでは、引き継ぎの特性（この用
語をオブジェクト向きプログラミングに用いているの
で）は必要としないことに注目されたい。あるオブジェ
クトは、所与の時点に図２の少なくとも１つの論理ノー
ド１０′−１３′に全体として存在している。厳格に言
えば、あるオブジェクトは、そのオブジェクトが呼出さ
れ、そのオブジェクト自身がそれを用いて何ができるか
を定義しない限り変更することはできない。オブジェク
トは、オブジェクトと共に移動するコード（定義された
操作または方法）、またはオブジェクトが移動して行く
論理ノードに存在するコードを含み、このコードはオブ
ジェクトによって許容されるとそのオブジェクトを変更
することができる。オブジェクトはファイルとして、ま
たは一群のファイルとしてディスク１６に記憶させるこ
とができるが、“例示された”時にはメモリ１５内にあ
り、ハンドルまたはオブジェクト名によって識別され
る。後述するように、ノード１０−１３は本発明による
経路指定システム（実行可能なコード）２１を含む。経
路指定システム２１は下位のシステム層に対して若干の
サービスを要求する。例えば、オペレーティングシステ
ム及びＣＰＵは、オブジェクトが物理メモリ１５内にあ
る間にその上に書き込まれたり、そのデータまたはコー
ドが変更されたりすることを防ぐある保護メカニズムを
設けなければならず、この機能は通常は基本サービス２
２のメモリ管理メカニズムの一部になっている。通常、
オブジェクトは回送、思い出させ、承認等のような適用
業務にある動作を起こさせるあるメカニズムを含む。オ
ブジェクト向き適用業務を支持するために、オブジェク
トスーパバイザ２２と呼ぶサービスの基礎が各ノードに
含まれている。オブジェクトスーパバイザ２２はオブジ
ェクト作成、管理、維持、及びオブジェクト間通信を支
持する。オブジェクト経路指定システム２１はオブジェ
クトスーパバイザのサービス上に確立される適用業務レ
ベルのサービスである。オブジェクトは、それを探知す
るために使用される世界的に独自の識別子を有してい
る。しかし適用業務レベルではオブジェクトはオブジェ
クトスーパバイザ２２によって維持されているオブジェ
クトハンドルによって互いに参照し合う。あるオブジェ
クトが作成されると、オブジェクトスーパバイザ２２は
そのオブジェクトのハンドルをその作成者に戻す。オブ
ジェクトはそれらが知っているオブジェクトのハンドル
を互いに渡し合うことができる。オブジェクトは、それ
らの公に知られたインタフェースの操作を呼出すことに
よって互いに通信し合う。呼出しは位置には無関係であ
り、全ての呼出し者は目標オブジェクトのハンドルを知
っていなければならず、また全ての呼出し者は呼出され
るオブジェクトの位置に、または呼出しを意図している
時に呼出されるオブジェクトが移動できる事実にさえも
関わってはならない。呼出しの目標オブジェクトを探知
するために所与のハンドルを使用すること、所要操作を
呼出すこと、及び結果を呼出し者へ戻すように伝播させ
ることがオブジェクトスーパバイザ２２の役割である。
位置独立型呼出し（ＬＩＩ）を達成するためにオブジェ
クトスーパバイザ２２が使用する通信メカニズム及び方
法は適用業務レベルにおいては透明であり、ハンドルは
呼出しパラメタ及び結果内で渡すことができる。この位
置独立型呼出し（ＬＩＩ）層は、１９８９年４月６日付
け Ａｎｄｒｅｗ Ｐ．Ｂｌａｃｋ 及び Ｙｅｓｈａ
ｙａｈｕ Ａｒｔｓｙの関連出願（ＰＤ８９−０１４
２）「分散型計算システムにおける移動オブジェクトの
探知」、及び１９８９年６月の ＩＥＥＥ Ｃｏｍｐｕ
ｔｅｒ Ｓｏｃｉｅｔｙ，Ｐｒｏｃ．ｏｆ ｔｈｅ ９
ｔｈＩｎｔ’ｌ Ｃｏｎｆ．ｏｎ Ｄｉｓｔｒｉｂｕｔ
ｅｄ ＣｏｍｐｕｔｉｎｇＳｙｓｔｅｍｓ，５５０−５
５９頁に所載の両氏の論文「位置独立型呼出しの実現」
（この論文の改定及び拡大バージョンは１９９０年１月
の ＩＥＥＥ Ｔｒａｎｓ．ｏｎ Ｐａｒａｌｌｅｌ
ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ
１：１に記載されている）に記載されている型の各ノー
ド１０−１３に含まれる。各ノードは、使用可能なユー
ティリティである遠隔手続き呼出し（ＲＰＣ）層のよう
なノード間通信用メカニズムをも有している。ノード間
通信の支持は、１９８９年４月６日の ２ｎｄ Ｉｎ
ｔ’ｌ Ｗｏｒｋｓｈｏｐ ｏｎＤｉｓｔｒｉｂｕｔｉ
ｏｎ ａｎｄ Ｏｂｊｅｃｔｓ の Ｙ．Ａｒｔｓｙの
論文「高度に分散した移動オブジェクト間の通信」に記
載されている。以上のように、適用業務オブジェクト
は、通常は他のオブジェクトにある操作を遂行するため
に、他のオブジェクトを“呼出し”たり、または他のオ
ブジェクトを探知したりする必要が屡々ある。例えば単
にオブジェクトの位置を決定する必要があるだけでその
オブジェクトに何等の操作を遂行しなくともそのオブジ
ェクトを呼出すことができるが、これは異状であって殆
どの呼出しはそのオブジェクトに操作を遂行する目的か
らである。適用業務オブジェクトＡ１はローカル手続き
呼出し（ＬＩＩ層を介して、透明に）を用いてＢ１を呼
出すことができる。何故ならば、両オブジェクトは同一
ノード内に位置しているが、ＬＩＩはＡ２のような他の
ノード内のオブジェクトにアクセスするために遠隔手続
き呼出しまたは他の遠隔通信手段を使用できるからであ
る。ローカル及び遠隔通信は通信しているオブジェクト
に対して透明である。図１または２の回路網は、どのよ
うなクラッシュに対しても記憶したデータを維持するこ
とを保証する分散型安定記憶サービス（図示せず）を含
み、オブジェクトスーパバイザ２２はこのサービスへの
インタフェースを提供する。安定した記憶場所は回路網
サービス内であろう。これは例えばノード１０−１３に
似た付加的なノードであってもよく、またはノード自身
のディスク記憶装置１６によって実現してもよい。各記
憶場所は１またはそれ以上のノード上に存在する１また
はそれ以上のオブジェクト（の非揮発性コピーを）支持
（維持）し、あるノードがクラシュしてもそのオブジェ
クトが含んでいるデータを回復できるように機能する。
この安定記憶サービスは、オブジェクトがそれらの状態
の保存するのを可能ならしめ、また状態を変化させるの
で、あるノードがクラシュの場合にはそのノード内に含
まれているオブジェクトは、そのノードが修復された時
にそのオブジェクトスーパバイザ２２によって自動的に
復元されるか、または他の（多分異なるノードの）スー
パバイザによって復元される。同様に、非活動オブジェ
クトをそのノードから除去し、後刻呼出された時には回
復することができる。オブジェクト経路指定システム２
１は、呼出しを要求したオブジェクトが、ノード１０−
１３の何れかに存在しているか、またはオブジェクトス
ーパバイザ２２によって安定記憶装置から復元できるも
のとしている。ノードが一時的に到達不能である間はこ
の復元を遅延させることができる。オブジェクト経路指
定システム２１は、若干の型のオブジェクト向きプログ
ラミングシステムとは異なり、オブジェクト間に何等の
クラス階層または引き継ぎを必要としない。このシステ
ムは３つのオブジェクト型と、オブジェクト接続機構の
概念とを支持することを要求するが、それ以外にオブジ
ェクト型及びそれらが互いにどのように機能的に関わり
合っているかには関心がない。３つのオブジェクト型と
は、プリンオブジェクト、ホルダー、及び動作経路であ
る。システムの上司は、そのオブジェクトを経路指定で
きるような、例えば（人の）利用者、利用者の群、自動
化された社員、または記録保管所のような何らかの構成
要素である。これがプリンオブジェクトと縮めて呼ばれ
る（プリンシパルオブジェクトの略）オブジェクトによ
って表される。上司が自動化プログラムである場合には
その上司は事実上そのプリンオブジェクト内に統合でき
る。ホルダーは、幾つかのオブジェクトを群にして一緒
に経路指定または移動させるために使用されるオブジェ
クトである。これらのオブジェクトは経路指定システム
２１によって“アップコール”することができ（１９８
５年１２月の、Ｐｒｏｃ．ｏｆ ｔｈｅ１０ｔｈ Ｓｙ
ｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔ
ｅｍｓＰｒｉｎｃｉｐａｌｓ の１７１−１８０頁に所
載の Ｄ．Ｄ．Ｃｌａｒｋの論文「アップコールを使用
するシステムの構造」を参照されたい）、従って僅かな
インタフェース要求がこれらに課せられる。動作経路オ
ブジェクト（ＡＰＯ型）は、後述するように、経路指定
された（どのような型の）オブジェクトの動作経路を指
定するために使用される。接続機構（アタッチメント）
は、経路指定及び移動を簡易化するために使用される。
どのような種類のオブジェクトでもホルダーに接続する
ことができ、各オブジェクトはそれに接続された動作経
路オブジェクトを有することができる。接続機構は単に
オブジェクトスーパバイザ２２によって維持されている
相互参照にしか過ぎない。接続機構はオブジェクト間の
どのような機能依存性をも暗示しないが、動作経路オブ
ジェクトと経路指定されたオブジェクトとを統合する、
または幾つかのオブジェクトをまとめて経路指定もしく
は移動させる便利な方式でる。経路指定は、あるオブジ
ェクトをある動作経路オブジェクトによって定義された
関連動作経路に沿って論理的に伝播させることである。
動作経路オブジェクトは、予め定義されたテンプレート
から作成し、別の経路インスタンスからコピーし、また
は特別な経路として利用者によって対話的に定義するこ
とができる。このオブジェクトは経路指定されたオブジ
ェクトに、オブジェクト作成時に静的に、またはその後
に動的に接続することができる。図３に示すように、動
作経路オブジェクト２５は概念的に３つの部分、即ち見
出し２６、本体２７（動作ストップ２８のグラフ）及び
後書き２９からなる。見出し２６は、誰が経路指定され
たオブジェクトの提出者（即ち、そのオブジェクトを特
定の動作経路上に経路指定することを要求した最初の上
司）であるのかを指定する。また見出し２６は経路指定
されたオブジェクトに関するある情報をも含む。後書き
２９は、オブジェクトがその経路の終端に到達した時に
何をするのかを指定する。両者の間のグラフ２７は、オ
ブジェクトが進むべき実際の経路である。図４の動作経
路は、経路指定されたオブジェクトが操作のＡＤＳ群内
の働く一人の上司、アンによって作成された経費伝票で
あるような例を示す。経費償還適用業務は、伝票に彼女
の管理者ベンと、経費が請求されるコストセンターの管
理者チェンと、このコストセンターを制御する会計系ダ
ンの承認（署名）を必要とする。その後に伝票は税金及
び会計監査の目的のために記録される。伝票（オブジェ
クト）に取り付けられた動作経路オブジェクト２５はこ
れらの上司を動作ストップ２８として指定する。経路指
定システム２１はそれらの各々を見出し、それらに順番
に（計算機化された）書式を引き渡す。この例では、ア
ンがシステムにオブジェクトを提出すると（即ち、後述
するように、彼女がそれを発送した時に）動作経路が例
示され、適切な情報で設定されそしてアンの伝票オブジ
ェクトに接続される。動作経路はあるオブジェクト内に
カプセル封じされるから、その内部表現は利用者または
他のオブジェクトには不可視であるが、利用者またはオ
ブジェクトはその経路の論理構造を視ることはできるこ
とに注意されたい。あるオブジェクト内にあるため、活
動経路はそれへのハンドルを入手した誰でもが呼出し、
追跡し、そして安定な記憶装置内に保存することができ
る。保護の理由から、オブジェクト経路指定システムの
みが経路を拡張し、変更することができる。例えば異例
の事象のために利用者がある経路を変更する必要があれ
ば、利用者はシステムに制御された方法でそのようにす
ることを要求するか、或は後述するように、特別な経路
を有するホルダーを使用してそのオブジェクトを異なる
経路上に転送することができる。見出し２６内の提出者
の情報は、その名前及びそのプリンオブジェクトのハン
ドル（例えば“アン”及び彼女の個人識別オブジェク
ト）を含む。この情報は、その経路に沿う他の上司が使
用して経路指定されたオブジェクトに操作を要求したの
は誰かを見出すことができ、またオブジェクト経路指定
システムが使用して特別な事象を提出者に報告すること
ができる。見出し２６内の付加情報は適用業務セレクタ
または適用業務ＩＤ（これは汎用記号であっても、また
はある適用業務のための特定ＩＤであってもよい）と、
この経路指定の主題の本文記述とを示す。この例では、
これらは経費償還適用業務のセレクタ（例えば“１２
３”）、及び本文“アンの１９９０年第１０回ＩＣＤＣ
Ｓ出席経費”であろう。主題本文は、経路指定されたオ
ブジェクトを拾い読みさせることなくそのオブジェクト
は何に関するものであるかを上司（そのオブジェクトが
経路指定された本人）に告げる。適用業務セレクタまた
はＩＤは、上司の利用者インタフェース（またはプリン
オブジェクト）が、上司に対する通知を待ち合わさせ
る、または経路指定されたオブジェクトを他の誰かに向
かわせるのような動作の経過を自動的に選択するのを援
助する。さらに見出し２６は、クラッシュ中その経路を
維持しなければならないか否かを指示できる。これは、
オブジェクトがその経路指定を完了することを提出者ま
たは適用業務が予測するための完了時間値を含むことが
できる。以下に説明するように、システムはこの値を使
用して、この締め切り期限が守られない場合に上司に思
い出させるようにする。後書き２９は、経路が不足する
場合にオブジェクト経路指定システム２１が取るべき動
作をリストする。これらの動作には、動作経路自体の破
棄（欠乏）、提出者アンへ完了の通知、またはその適用
業務に特定の手続きの呼出しが含まれよう。後書き２９
が経路指定されたオブジェクトに何をするかは指定しな
いことに注目されたい。これは適用業務に決定を任せて
いるのである。例えば、適用業務が経路指定されたオブ
ジェクトをその経路の終端で記録することを要求すれ
ば、最後のストップとして経路に記録所を付加する（上
例の場合のように）か、または最後の上司がオブジェク
トに操作し終えた後にオブジェクトは自分自身を記録所
のノードまで移動させる。一組の動作ストップは、経路
指定されたオブジェクトに操作することを要求した各上
司毎に１つの記述子の指示されたグラフによって記述さ
れる。図５を参照する。一人の上司Ｐが同一オブジェク
トＯを２回以上操作しなければならない（例えばＰの後
のＯに操作された動作を検査するために）ような場合に
は、循環を回避するためにＰのための分離した動作スト
ップがその都度現れる。上司Ｐの識別及びその位置は、
Ｐへのディスパッチが呼出される度に翻訳されるので、
もし変化（再配置、休暇、再編成等）があればこれらは
考慮されることになる。動作ストップ２８は図６に示さ
れており、上司の名前とその組織上の役割とを指定して
いる。役割は、何故このオブジェクトがその上司へ経路
指定されるのかを示し、上司は従来の設計のように複数
の役割を有することができる。典型的には動作経路オブ
ジェクト２５が作成される時、１つの役割だけが各動作
ストップ２８内に指定され、それはオブジェクト経路指
定システム２１によってその役割を満たす上司の名前に
拡張される。上司に彼等が要求した操作を通知するため
に、システムは役割から彼等の名前を見出し、彼等の名
前から彼等のプリンオブジェクトを見出す。役割から名
前への翻訳及びプリンオブジェクトの探索の繰り返しを
避けるために、プリンオブジェクトのハンドルがそれぞ
れの動作ストップ内に配置される。この例では、ＡＤＳ
の管理者、ＡＢＺの管理者、及びＡＢＺの制御者の役割
だけが初めに指定される。これらは後にそれぞれベン、
チェン、及びダンに拡張され、彼等のプリンオブジェク
トのハンドルがそれぞれの動作ストップに付加される。
別の例では、ある人が彼の幾人かの同僚にメモを経路指
定したいような場合に、かれは目標上司の名前を直接指
定することができる。図６に示す動作ストップ２８は、
経路指定の並行比（即ちどの上司に同時操作を許可する
か）、移動（経路指定されたオブジェクトと、多分動作
経路オブジェクトとを同じ次の上司に配置するか否
か）、及び上司に思い出させるタイマ（指定された時間
枠内にオブジェクトを操作するのを忘れないように）を
案内する付加情報を含む。この情報の詳細に関しては後
述する。図３及び図４は名前拡張後の２つの動作経路
（図３の順次動作経路２５、図４の並行動作経路３０）
の例を示す。各動作経路は見出し２６、本体２７及び後
書き２９を有している。直列経路２５（上述した例を表
す）では、経路指定されたオブジェクトはアンから動作
ストップ２８として名付けられた４人の上司まで直列に
進む。図４の並行経路３０においては、動作ストップ２
８は直列だけではなく並列出あることができる。即ち、
アルがオブジェクトに対する彼の操作を完了したことを
示すと、ビル、ベス及びボブはそのオブジェクトを操作
するように同時にトリガされ、ベスが終了するとサイが
開始可能となり、ボブが終了するとキャシーが開始でき
る。彼等は全て、オブジェクトが接合点３１を介してデ
イブへ（次いでエレンへ）向かう前に終了させなければ
ならない。図示のように、各経路２５または３０は（１
つまたは複数の）現在のストップを示すカーソル３２を
含む。動作ストップ２８は、オブジェクト経路指定シス
テムがその関連上司に予期される操作を通知する（また
は通知することを企図する）と「現在の」となり、上司
がそのオブジェクトを後任（即ち次の）動作ストップへ
発送することを要求すると「先行の」となる（後任が
「現在の」になる）。それぞれの上司は動作経路に対し
ても「先行の」、「現在の」及び「次の」と呼ばれる。
図６は動作ストップ２８の内容を示す。思い出させ情報
は、もし上司がオブジェクトに対して操作しなければこ
の上司に小言を言うことと、操作が行われていないこと
及び他の上司への発送が成功していないことを報告する
ことの要求を指定する。並行標識は、もしこのストップ
が数人の後任社または前任者に同時に関連していれば、
例えばこれらの何れかの、各、または全ての上司が操作
を終了した後に、オブジェクトをどのように経路指定す
るかを指定する。代人フラグは、それがセットされた場
合には、例えば前の上司が休暇のために次の（１つまた
は複数の）ストップの上司がその上司に代わったことを
示す。動作経路を作成し、使用し、そして操作する利用
者インタフェースはエディタに似た機能であり、例えば
アイコンベース型図形エディプログラムで実現すること
ができる。利用者インタフェースは、新しいけいろを作
成し、ある経路を所与のオブジェクトに接続し、経路の
現状を示す基本動作を支持するものとしている。他の動
作に関しては後述する。経路を作成すると、作成者は見
出し、後書き及び各ストップ毎に１つずつ、順組のリス
トを論理用語で供給する。この例ではこのリストは以下
のようになろう（若干のデフォルト値を使用） 上記構文法はエディタプログラムによって翻訳され、見
出し、後書き及び動作ストップの内容が作成される。図
４の並行動作経路３０の例は以下のようになる。但し、
大括弧はどの組の動作ストップが並行化できるかを示
し、また名前は提出者によって与えられ、マーケティン
グのためのセレクタが４５６であるものとする。 オブジェクト経路指定しすてむ２１は、２群の相互関係
にあるメカニズムからなる。以下にオブジェクト経路指
定のプロセスの概要を説明し、このプロセスを履行する
ためにメカニズムが如何に共働するかを説明し、そして
オブジェクト経路指定のために必要な基本的メカニズム
の詳細を説明する。その後に、制御、ハンドルの誤り及
び例外、支持共用、及び並行経路指定を改善するための
付加的なメカニズムを説明する。しかしこれらの付加的
なメカニズムを必ずしも本オブジェクト経路指定システ
ムの一部とする必要はない。これらのサービスは、たと
え効率がやや低く、一貫性がやや欠け、利用者に取って
やや不便ではあっても、たのメカニズム（手動関与を含
む）から得ることができる。図７を参照する。オブジェ
クト経路指定を実現するために必要な基本的メカニズム
は、（１）図８−１１にも詳細を示してあるディスパッ
チ機能３３は、経路指定されたオブジェクトを動作スト
ップ間に伝播させ、他のメカニズムを順番にトリガする
責を負うこと、（２）図１２にも詳細を示してある機能
翻訳３４は企業構造及び役割の機能記述から上司の名前
を見出すために使用されること、（３）図１３にも詳細
を示してある通知３５は上司との通信に、特に経路指定
されたオブジェクトに注意を向けるように上司に告げる
のに使用されること、（４）図１４にも詳細を示してあ
る引き渡し３６は経路指定されたオブジェクトの次の上
司への論理的または物理的移動を取り扱うことである。
図７及び図８−１４の詳細な流れ図は、経路指定された
オブジェクトが１つの動作ストップから次の動作ストッ
プへディスパッチされる時のこれらのメカニズム間の制
御の流れを示す。図１５及び図１６は、後述する２つの
例外呼出し、即ち警告とディスパッチバックのための制
御の流れを示す。これらのメカニズムの芯はディスパッ
チ３３であり、これは経路に沿う各上司によって、そし
て初めは提出者によって呼出され、経路指定されたオブ
ジェクトについて終了したこと、従って経路内の（一人
または複数の）後任者に制御を転送できることを指示す
る。メカニズムは後者の上司の名前及びハンドルが既に
次の動作ストップ内に含まれているか否化を調べ、もし
含まれていなければ、そのストップ内の機能記述から失
われたアイテムを満たすために機能翻訳３４を呼出す。
新上司のオブジェクトへのハンドルを入手すると、それ
はその上司へ経路指定されたオブジェクトに関する情報
を渡すために呼出される。通知メカニズム３５内のプリ
ンオブジェクトは予め選択されている何等かの方法、例
えばメールメッセージまたは特別な合図を使用して上司
に通報する。（変形として、プリンオブジェクト自身が
必要動作を遂行してもよいし、また経路指定されたオブ
ジェクトを全て拒絶してもよい。）次に引き渡しメカニ
ズム３６はプリンオブジェクトを用いて経路指定された
オブジェクトのハンドルを通知する。もし動作経路内に
移動が示唆されていればメカニズム３６はその便益を考
え、もし移動が適切であることが見出されればスーパバ
イザの移動サービスが使用されて経路指定されたオブジ
ェクトを移動させる。このようなシナリオが各動作スト
ップ毎に繰り返される。経路の終端において、ディスパ
ッチ３３は動作経路後書き内に指定されている完了動作
を遂行し、もし要求されていれば、提出者に“良いニュ
ーズ”を告げる。後掲の［表１］は、オブジェクト経路
指定システムの全てのインタフェース操作をモジュラ２
＋文法でリストしたものである。これらの操作は利用者
インタフェースによって、プリンオブジェクトによっ
て、または実際に如何なるオブジェクトによっても呼出
すことはできるが、何れの場合もその呼出しはその目的
を遂行する上司を示す。簡易化のために、呼出者の識別
のような安全要求によって生ずる付加的なパラメタ及び
結果は表１及び以下の説明から省いてある。［表２］
は、オブジェクト経路指定システム２１が呼出すかも知
れない（アップコール）オブジェクト操作をリストした
ものである。ディスパッチメカニズム３３は、現在の上
司が経路指定されたオブジェクトにおける操作を終了す
ると付活され、ディスパッチを呼出す。ハンドルパラメ
タは動作経路オブジェクトか、またはそれに取り付けら
れたオブジェクトの何れであってもよい。（従って、オ
ブジェクトを経路指定するためには経路指定されたオブ
ジェクトへのハンドルだけが必要である。後述するよう
に、これは、別の上司がそのオブジェクトの経路を変更
できること、またはそれを別の経路を有するホルダー内
に配置できることから重要である。）もし参照したオブ
ジェクトが動作経路を有していないか、または経路が既
に使い尽くされていれば、ディスパッチは拒絶される。
そうでない場合には、例えば次のプリンオブジェクトに
到達できないために、たとえ制御の実際の転送が遅れる
ようなことがあっても、ディスパッチは成功裏に戻され
る。ディスパッチは一般的な操作であり、呼出者が経路
指定されたオブジェクトに必要操作を遂行したことを示
す。これは、どのような特定の適用業務の意味（セマン
ティクス）からも自由である。この操作は、制御を実際
に次の上司に転送できるかを確かめるために経路指定さ
れたオブジェクトの状態を調べることはしない。（これ
は本発明のシステムと、前述の適用業務専用設計との主
な差異である。）前の上司が彼等の所要操作を正確に完
了したことを確かめるのは適用業務及び各ステーション
の上司に任されている。もし誤りが発見されれば、後述
するように現在の上司は他のメカニズムを使用してその
オブジェクトを再経路指定することができる。経路指定
されたオブジェクトの状態を調べる能力をディスパッチ
３３に付加すると、オブジェクトの偶発的な早過ぎるデ
ィスパッチのような過ちを防ぐことはできるが、異なる
適用業務の意味に十分に対処することを要求して経路指
定システムを複雑化させるため、この能力は含まれてい
ない。ディスパッチメカニズム３３は、次のストップが
その上司のオブジェクトのハンドルを含むか否かを調べ
る。もし含まなければ、必要ならば機能翻訳メカニズム
３４（図１２）に次の上司の名前を請求し、スーパバイ
ザからその上司のためのハンドルを入手する。次いで、
後述するように通知操作３５を呼出し、次のストップを
「現在の」にセットする。通知は２つの理由から失敗す
るかもしれない。第１に、通信障害のためにプリンオブ
ジェクトを使用できない恐れがある。このような場合、
ディスパッチは後刻呼出しを再び試み、オブジェクトが
使用できるようになるまで所定の間隔で再度試みる。
（プリンオブジェクトは、それが現在存在しているノー
ドがクラッシュしていることを確認できなければ、簡単
に他所で復元できない。そのようにしなければ、オブジ
ェクトは複製される恐れがある。）もし回路網が極めて
長い時間に亙って区切られれば、この遅れが経路指定さ
れたオブジェクトの停止をもたらす可能性がある。幸い
にも、この状態はある思い出させがタイムアウトになる
と発見することができ、思い出した上司が例外処理メカ
ニズムに頼って手詰まりを解消することができる。第２
に、例えば通知される上司が休暇中で、この経路指定さ
れたオブジェクトは別の（代わりの）上司へ向かわせる
べきであるとして通知操作が拒絶されるかもしれない。
この場合、ディスパッチメカニズムは前の上司の代わり
として新上司を動作経路に付加し、前述のようにそのプ
リンオブジェクトのハンドルを入手し、改めてそれを呼
出す。動作経路オブジェクトを維持しなければならない
のであれば、安定装置内のディスパッチチェックポイン
トはその初期状態であり、その後、現在の動作ストップ
の集合への変化と、役割から名前への翻訳とを含む経路
への全ての変更を記録している。動作経路がノードのク
ラッシュで失われたものとすれば、それは安定記憶装置
から復元することができる。効率を高めるために、動作
経路オブジェクトは経路指定されたオブジェクトと共に
移動させてもよく、またそのログ記録はローカルまたは
最寄りの安定記憶装置内に記憶させることができる。デ
ィスパッチメカニズムの設計には幾つかの問題が発生す
る。このメカニズムは経路指定されたオブジェクトが次
のストップへ転送される“準備が整って”いるか否かを
調べないから、少なくともオブジェクトがこのような準
備について調べるべきである。換言すれば、ディスパッ
チはオブジェクトに特定の操作を呼出してこのディスパ
ッチを承認すべきである。この操作は、もし必要ならば
若干の予備ディスパッチ雑用の遂行、移動の評価、また
はオブジェクト経路指定システムの適用業務からの独立
性を低下させることなく適用業務に特定のポリシーの付
加であることができる。この拡張は、特に幾つかのオブ
ジェクトがある経路を共用できまた一緒にディスパッチ
されることから、簡易化のために省かれている。ディス
バッチを承認するために各オブジェクトを呼出すことは
メカニズムを複雑にし、若干のオブジェクトを承認し、
他のオブジェクトのディスパッチを不承認とするには何
をなすべきかが明白ではない。別の問題は、現在の上司
のみに対して、経路上の他の上司に対しても、または多
分どの上司に対してもディスパッチを許可すべきか否か
である。簡易化及び保護の理由から、現在の（１または
複数の）上司のみに操作を制約することが決定されてい
る。もし任意の時点に任意のオブジェクトをディスパッ
チすることをどの上司にも許容すれば、混雑と誤りが広
がることになろう。若干の場合には他の上司が介入する
ことが望ましいかも知れないが（例えば、現在の上司が
オブジェクトを操作することを拒否した場合）、これら
の場合は他の手段によって処理することができる。例え
ば、無視されたオブジェクトを適切な問題処理職へ再経
路指定するために、特別な経路を有するホルダーを使用
してもよい。図７及び図１１の機能翻訳メカニズム３４
は組織内の役割を上司の名前に、そしてその逆に翻訳す
る。このメカニズムは、システム内の全ての組織、全て
の上司、及びそれらの間の結合をリストするシステム規
模の情報ベースを必要とする。この仮定を明確にするた
めに、「システム規模」とは経路指定の範囲内の全ての
組織、即ち経路指定システムがオブジェクトの経路指定
を予定している全ての公認組織単位（例えば群、研究
室、コストセンター）を意味することにする。例えばあ
る会社にあっては、この用語は会社全体に分散している
システムを言う。もしこのようなシステムがより大きい
回路網（例えば幾つかの会社を１つの分散型システムに
接続する回路網）の一部であって、オブジェクトがこれ
らの会社間を流れるのであれば、システム規模はこの結
合された回路網を含む。情報ベースは、中央に集められ
た、区切られた、または複製された名前サービス、また
はエキスパートシステムのような幾つかの方法で実現す
ることができる。結合は、互いに相互参照し合う組織及
び上司の十分に定義された属性である。明白な属性に
は、社員（ある組織内の上司を列挙）、管理者及び秘
書、並びにある組織の親及び子組織が含まれる。この機
能翻訳メカニズム３４の役割は、その経路に与えられた
情報を使用して情報ベースに質問し、必要な名前を取り
込むことである。上例では、情報ベースに照会して順組
（ＡＤＳ管理者）、（ＡＢＺ管理者）、及び（ＡＢＺ制
御者）の上司名を入手することになる。ＡＢＺ制御者の
名前を入手するためには、先ずＡＢＺ（会計組織）の親
組織の名前、次いで適切な制御子組織、次いで制御者の
名前を入手する必要があるかも知れない。次にベン、チ
ェン及びダンのオブジェクトハンドルを取り込み、それ
らを書式の動作経路内へ配置する。もし承認鎖がベンの
管理者の署名も必要とすれば、このメカニズムは効果的
に複合機能「ハンドル入手」（管理者（組織（ベ
ン）））を呼出す。この機能翻訳メカニズム３４はたと
えデータ及び結合を情報ベースから検索できるとしても
制約されているから、このメカニズムの能力には限度が
ある。例えば、“Ｘ計画の技術的リーダー”または“昨
日のセミナーの全ての出席者”のような役割の翻訳は恐
らく失敗するであろう。従って、例えばこれらの出席者
にメモを送るような、機能翻訳メカニズム３４によって
は拡張することができない経路を作成したい場合には、
経路指定システム以外の他の方法によって彼等の名前を
捜さなくてはならない。情報ベースが基準化するよう
に、メカニズムも基準化する。例えば動作ストップ内に
示されている名前及び役割が一群の社員を暗示する場合
には、翻訳は一組の上司名を戻すことができる。この場
合、対応動作ストップは図４の並行動作経路オブジェク
ト３０に示すように、複数の並行ストップに拡張され
る。オブジェクトはこれらの全てに同時に（デフォルト
によって）、または最初のストップの並行化標識に従っ
て、経路指定される。重要な問題は、翻訳３４を遂行す
る時に発生する。例えば、ある適用業務においてはアン
の伝票に署名するコストセンター管理者は、彼女が伝票
を提出した時の管理者であるべきであり、一方他の適用
業務においては伝票がその管理者へ経路指定される準備
が整った時点の管理者であるべきである。後者の場合、
名前と役割との結合が早過ぎると“目標”管理者によっ
てその伝票が拒絶されかねない。しかしシステムは翻訳
・時間の両任意選択（または実際に他のどれよりも）を
許容すべきである。従って、デフォルト及び動的翻訳が
支持される。デフォルトによって、オブジェクト経路指
定システムに最も都合のよい時に翻訳が行われる。もし
全経路を直ちに翻訳する方が、メカニズムが各ディスパ
ッチの度に別個に呼出すよりも経済的であれば、経路作
成時に全てのストップを拡張する（現在行っているよう
に）。そうでない場合には、情報の失効を避けるために
翻訳をできる限り遅くなるように遅延させる。さらに、
経路指定システムは「翻訳」操作（表１参照）を提供
し、これらの適用業務はそれらの都合で呼出すことがで
き、次の動作ストップまたは残りの動作ストップを翻訳
するか否かを指示する。次いでこの適用業務は、メカニ
ズムの単調な細部に関わることなく翻訳する時点を選択
する。それにも拘らず、翻訳後に役割が変化したり、情
報ベース内のデータが最新ではないために、翻訳は誤り
易い。このような場合、オブジェクトは間違った上司に
経路指定される恐れがあり、この上司は例外処理メカニ
ズム（後述）を使用してこの問題を解消できる。上司へ
のハンドルを機能翻訳３４が入手すると、これは図７、
図１４及び表２に示されている通知メカニズム３５によ
って、操作を要求した上司に通知するのに使用される。
しかし、異なる上司は多分、明滅するアイコン、メール
メッセージ、指定されたウィンドウ内のメッセージ、あ
るメールボックス内に列化されたノート、または一組の
操作の直接呼出しのような異なる手段によって通知され
ることを好むであろう。上司は、異なる適用業務または
役割に対して異なるスタイルを要求することさえある。
若干の場合には、上司はオブジェクトを別の上司へ経路
指定する必要があるかも知れない。例えばベンは、彼が
休暇中は全ての経費伝票をベスに、また休暇でない場合
には彼の秘密のビルに転送して欲しいかも知れない。汎
用経路指定システムはこれら全てに適合するスタイルを
どのようにして選択するのだろうか？ プリンオブジェクトの単一インタフェース操作「通知」
（表２参照）が、代替インタフェース操作の代わりに使
用される。通知を受けるプリンオブジェクトは、それ自
信の内部コードによって決定されるどのような動作を取
るかを決定する。プリンオブジェクトは、どのようにし
てその上司に通知するかの標識を含むであろう。この標
識はどの役割にも、どの適用業務セレクタ（またはＩ
Ｄ）にも適用されるか、または各役割（または一組の役
割、または全部）毎に、及び各適用業務セレクタまたは
ＩＤ（または一組のセレクタ、または全部）毎に、好ま
しい通知方法を指定する決定表（小さいプロファイル）
からなることができる。利用者インタフェースは、上司
がこれらの標識を動的にセットし、変更することを許容
するものとする。デフォルトは通知のためのパラメタか
らなる記述子をプリンオブジェクトにおいて列化させる
ことができ、これらの記述子を上司に下検分させ、削除
させる。通知は、上司の便宜のために動作経路から取ら
れた（役割及び対象のような）付加的なパラメタを含
む。「通知」の呼出しは、動作経路が経路指定されたオ
ブジェクトを上司と同じ場所に配置することを示唆する
か否かを示す。もし示唆していれば、引き渡しメカニズ
ム３６（宛先ノードの）がトリガされて移動の便益を評
価する。このメカニズムは、移動のコストと経路指定さ
れたオブジェクトへの予測されるアクセスのコストとを
比較する極めて複雑なポリシーか、または要求されれば
何時でも移動を承認する直接的な（そして好ましい）ポ
リシーを使用できる。上司／プリンオブジェクトに何を
するのかを決定させる一般的な通知操作の変形として、
前述のＩメール及びメッセージ管理システムに採用され
ているアプローチに概念的に類似した、オブジェクト経
路指定システムがアップコールする操作（または操作の
スクリプト）を各動作ストップ内に符号化することがで
きる。このアプローチはプリンオブジェクトのインタフ
ェースを簡略化できるが、オブジェクト経路指定システ
ムを複雑にする。即ち、このアプローチは、適用業務に
は関係のない動作経路内に適用業務に特定の異なる引き
数（または引き数のリストさえも）を記憶させ、オブジ
ェクト経路指定システムにそれらを解釈させる必要があ
る。さらにこのアプローチは、パラメタに値を結合する
（深い結合対浅い結合）時の質問を提起し、この質問に
対しては各適用業務が別々に答えることになり得る。簡
略化のためには、十分に定義されたインタフェースを有
する単一の通知操作が好ましい。オブジェクト経路指定
システムを改善するために付加できる幾つかの付加的な
メカニズムが存在する。第１は、上司は経路指定された
オブジェクトを直ちに操作する必要はないから、若干の
上司はそれらの操作を極めて長時間の間延期するかも知
れず、または未済操作を忘れることさえあり得る。従っ
て、もし彼等が十分に注意を払っていなければ彼等に
“小言”を言い、操作または進行の欠如を、知らせるこ
とを欲する他の上司に報告する手段を設けることが望ま
しい。第２は、役割から名前への翻訳に誤りが発生する
かも知れず、予期せざる状況が発生して操作を異なる過
程へ強制するかも知れない。従って、経路指定の誤り及
び例外を処理するメカニズムが必要である。第３は、全
てのオブジェクトを独立動作経路上に順次に経路指定す
る必要はないことである。異なる適用業務または環境で
は、複数のオブジェクトを単一の経路上へ経路指定し、
オブジェクト間の動作経路をコピーまたは移動させ、ま
たはあるオブジェクトを幾つかの上司と同時に経路指定
する必要があるかも知れない。従ってオブジェクト経路
指定システムは経路共用及び並行経路指定を支持するよ
うに拡大される。思い出させサービスについては幾つか
の設計上の問題が存在する。誰に思い出させるのか、ど
のようにそして何時思い出させるのか、そして頑健で効
率的な分散した思い出させメカニズムを如何にして実現
するかである。先ず、誰にそしてどの件を思い出させる
のか？サービスを一般的に保つためにどの上司にも、所
与の動作経路に関連してどちらの事象が発生しても、彼
等が思い出すことを欲する時点を選択せしめることが好
ましい。詳述すれば、上司は次のような変化を選択でき
るのである。（１）もし別の上司（例えば第３の動作ス
トップの１人）が指定された期間内に、またはある時点
までに経路指定されたオブジェクトをディスパッチする
ことに失敗すれば、その上司に小言を言う。しかし、小
言を言われる上司がその時点に未だにオブジェクトを入
手していないかも知れないので、このサービスは注意深
く使用すべきである。従って、最後のディスパッチ要求
に対する時間と共に使用することがより適切である。利
用者がこのサービスを悪用するのを防ぐために、小言を
言われる上司に要求者の識別が提示されるようになろ
う。（２）上記（１）において操作が行われていない場
合に否定報告を請求する。これは進行の欠如を発見する
ために有用である。後述するように、思い出させた上司
は他の手段に訴えて不注意な上司に対してオブジェクト
に操作するように押すか、またはオブジェクトを別の上
司へ転送させる。（３）オブジェクトが所与の動作スト
ップからディスパッチされたことを示す肯定報告を請求
する。このサービスは、経路指定されたオブジェクトの
進行を監視するために使用できる。思い出させサービス
のこれら３つの変化は、その経路に沿うオブジェクトの
進行と、この進行が停止した場合に必要を生じた直後の
反応とを強力に且つ柔軟に監視することを可能にする。
自分自身による思い出させサービスが経路に影響を与え
ることもなく、また経路指定されたオブジェクトの状態
を変化させることもないので、どの上司もそれを使用す
ることが許されることに注目されたい。しかし、若干の
適用業務がどの上司にも（たとえその上司が経路指定さ
れたオブジェクトへのハンドルを有していても）経路の
状態を見せることを欲しないことがあるかも知れない。
この場合には、オブジェクト経路指定システムは、例え
ば動作経路に対する何等かの操作のためのアクセス権利
を使用するより制約的な保護メカニズムを必要としよ
う。第２の問題は、思い出させる時間をどのようにして
指定するかである。タイマのリストまたは次のタイマを
評価するために呼出される機能を指定することはでき
る。支持されるより簡易な機能はｆｏｒループまたは繰
り返し装置に類似している。タイマは対をなしており
（ベース値、間隔用）、ベース値は絶対（例えば１９９
０年９月１３日５時３７分）でも、相対（例えば最後の
ディスパッチから１週間）でもよく、間隔はベースに付
加される反復値である。思い出させ指令はオブジェクト
が再ディスパッチされる時に明示的にでも暗示的にでも
取消されるまでシステムによって再発行させられる。巨
大な分散型システムにおいては、時計が必ずしも同期し
ているとは考えられないので、これはそれ程簡単ではな
いかも知れない。実際に、異なるノードの時計はスキュ
ーしている恐れがある。そこで所与の（絶対）時刻にＰ
がＱに小言を言うものとすれば、何時（実時間）にＱに
小言を言うべきか？好ましい解決法は、各思い出させ指
令は、それを発行したノード（この場合にはＰのノー
ド）において取り扱い、従ってそのノードのローカル時
と呼ぶ。唯一要求されることは、時間が全てのノードに
おいて単調に増して行くことである。思い出させ指令
は、経路作成時に適用業務によって要求することができ
る。さらに、上司は「思い出し指令セット」を呼出すこ
とによって動的に思い出させ指令をセットしてもよい
し、または利用者インタフェースがこの呼出しをディス
パッチと統合してもよい。この呼出しは、それが小言を
言うためのものかまたは報告（肯定または否定）のため
のものか、及びどの動作ストップにそれが関連するのか
を指示する。この呼出しは、実際の小言または報告にあ
るメッセージ（“メッセージ”パラメタ）を含ませ、小
言を言われるまたは思い出さされる上司との関係を確立
する。上司はそれらの思い出させ指令を除去するために
「思い出させ指令取消し」を使用することができる。そ
のようにされない場合には、思い出させ指令はディスパ
ッチ時に、またはそれらが失効した時にディスパッチメ
カニズムによって除去される。第３は、思い出させ指令
をどのように働かせるかである。思い出させ指令は、要
求されると思い出させサービスに列化され、それへの参
照がそれぞれの動作ストップに配置される。タイマが満
期になると小言及び否定報告が開始され、その時点に思
い出させサービスはそれぞれのプリンオブジェクトの小
言または報告操作をアップコールする（表２参照）。こ
れらの操作に渡されるパラメタは「通知」に渡されるパ
ラメタに類似し、メッセージパラメタは「思い出させ指
令セット」へ供給される本文か、またはデフォルトによ
って、その経路に関係付けられた主体本文である。そう
でない場合には、ディスパッチ操作が完了する前に、現
在の動作ストップが思い出させ指令への参照を含むか否
かが調べられる。もし含んでいれば、このストップに関
係付けられている小言及び否定報告の要求の削除と、肯
定報告の全ての要求の遂行とを思い出させサービスに依
頼する。これは適切なプリンオブジェクトの「報告操
作」を呼出しても行われる。最後に、このサービスを設
計する際の重要な問題は、それを如何に頑健に且つ効率
的にするかである。思い出させ指令を１つのノード（例
えば上述のように要求しているノード）内に保持してお
くことは、そのノードがクラッシュした場合には思い出
させ指令が消滅する恐れがあるので、頑健さを保証する
ものではない。複製したデータベース内にそれらを記憶
させておくことは、極めて高価となり、またデータベー
スの一貫性及び完全に回復するその能力に依存すること
になる。好ましい解決法は、安定記憶サービスを使用す
ることと、分散したブートサービスに頼ることである。
これらのサービスは高度に役立つものと考えられ、もし
それらを提供するサーバがクラッシュしても、比較的速
やかに機能を回復する。思い出させ指令は、高度に使用
可能であるとして登録された存続オブジェクト内に保持
される。このようなオブジェクトが存在しているノード
がクラッシュすると、適切な安定記憶サーバがブートサ
ーバをトリガしてそのノードを再トリガし、その後に、
そのオブジェクトを再記憶する。このシナリオでは、思
い出させ指令はやや遅れるかも知れないが、これは殆ど
の適用業務においては問題ではない。（しかし、これは
ハード実時間適用業務に対しては制限であるかも知れな
い。）このサービスの効率に関しては、そのコストを最
適化する試みはなされていないが、コストをその使用に
比例させる試みはなされている。ある動作経路の共用は
本発明のオブジェクト経路指定システムの重要な特色で
ある。ある動作経路を複数の経路指定されたオブジェク
トが共用するには基本的に２つの形、即ち連続と一時的
とがある。第１の形では、経路は概念的に２またはそれ
以上のオブジェクトに接続される。どのディスパッチ操
作もそれら全てに影響を与え、経路のどのような変更も
それらの各々の経路指定に反映される。第２の形では、
経路は１つの経路指定されたオブジェクトから別の経路
指定されたオブジェクトへコピーまたは転送され、その
後はそれらが同一経路を共用することはない。第３の形
も存在でき、この形ではあるオブジェクトが複数の動作
経路を共用するが、この形は例外的であり混雑の源と見
られるから、支持はされない。連続共用の処理を簡略化
するために、ホルダーオブジェクトを使用して包含する
オブジェクトを群にする。経路を複数のオブジェクトに
接続することはせず、他の全てのオブジェクトが接続さ
れている単一のホルダーに経路を接続する。ホルダのデ
ィスパッチは、接続された全てのオブジェクトを一時に
ディスパッチさせるのと意味論的に同等である。例え
ば、ベンがアンの伝票にメモを添付して両者を一緒に同
じ経路に経路指定したいものとすれば、彼は２つのオブ
ジェクトをホルダーに添付し、「転送」操作（表１）を
使用して伝票の動作経路をホルダーへ転送することによ
って、彼はそのようにすることができる。変形として、
例えば去年の経費伝票の全てを一緒に保持するように、
単に集合させるためにあるオブジェクトをホルダー内に
挿入することができる。挿入されたオブジェクトがホル
ダーの動作経路を共用することはない。何れの場合も、
後にそのオブジェクトをホルダーから取り出すことがで
きる。従って、ホルダーオブジェクト型のインタフェー
スは「取り付け」、「挿入」及び「除去」操作を含むべ
きである。ホルダに取り付けられたオブジェクトもホル
ダーであるかも知れず、実際に添付の階層が存在でき
る。動作経路は、添付されたオブジェクトの木全体に経
路指定が影響を与えるようにこの階層を使用して階層の
中の頂レベルのホルダーに添付すべきである。添付され
た各オブジェクトは、添付されるオブジェクトを示すの
で、添付されたオブジェクトの１つのハンドルしか有し
ていなくとも、表示またはディスパッチのために共通経
路を見出すことは可能である。後刻、オブジェクトを前
の経路に経路指定することを再開する意図で、そのオブ
ジェクトを一時的にホルダーに添付することは、時には
有用であるかも知れない。例えば、上例でベンが協議の
ために別のスーパバイザへホルダーを送り（即ち新しい
特別経路上で）、後にその最初の経路に伝票の経路指定
を続けたいかも知れない。この目的のために、オブジェ
クトＯがあるホルダーに添付される時、添付された動作
経路オブジェクトＡＰＯを有するオブジェクトＯにそれ
を失うことを要求しない。しかし、もしホルダーが既に
（活動）動作経路を有しているが、もしくはそれ自身が
活動動作経路を有するホルダーへ添付されていれば、オ
ブジェクトＯは活動動作経路を保持することはできな
い。そのようにしなければ、オブジェクトＯは複数の経
路を同時に共用し、それをディスパッチするから混雑を
もたらすことになる。これを防ぐために、経路を非活動
にする「中断」を、その後にそれを再付活させる「再
開」を呼出すことができる。もし目標オブジェクト自身
が、（活動）動作経路を有する別のオブジェクトに添付
されていれば、「再開」は失敗することに注意された
い。一時的経路共用は２つの操作によって支持される。
「コピー」は単に動作経路オブジェクトを複製し、どの
オブジェクトがそれに接続されるかを呼出し者に決定さ
せるに過ぎず、「転送」は指示された経路を別の動作経
路オブジェクトに再添付し、前の動作経路オブジェクト
から経路を削除する。誰にでも自由に、１つのオブジェ
クトから別のオブジェクトへ動作経路を転送させ、また
は１つのホルダーから別のホルダーへオブジェクトを転
送させるようにすることは、若干の適用業務の保護要求
を犯すことになる。それでも前述したように、若干の状
況の下ではこのような能力が望ましいかも知れない。こ
の矛盾に対処するために、オブジェクト経路指定システ
ムは、それへのハンドルを誰が有していようとも経路転
送、中断及び再開を許容するが、これらの動作はある経
路に組合わされている履歴ログに記録され、追跡するこ
とができる。より厳格な保護メカニズムは、後述するよ
うなこれらの操作のための能力を要求しよう。並行経路
指定は本発明のオブジェクト経路指定システムの別の重
要な特色である。動作ストップは複数の直前の前任者ス
トップまたは直後の後任者ストップ、即ち図４の動作経
路オブジェクト３０に見られる並行経路を有することが
できる。このような場合、ストップのファンアウトまた
はファンインが１よりも大きければ、問題は全てを、何
れかを、または若干をの選択肢を選択することである。
詳述すれば、あるオブジェクトがディスパッチされ、複
数の次のストップが存在する場合、そのオブジェクトを
それらの全てに同時に（全面的に）経路指定するべき
か、またはある選択機能を適用すべきかである。同様
に、あるストップが幾つかの前任者ストップを有してい
る場合、それらの全て（全面的に）、何れか、または若
干がオブジェクトをディスパッチする時に、それは「現
在の」になり得るかである。先に説明（例えば図４に関
して）は、ファンアウト及びファンインが１よりも大き
い場合、並行化を制御する機能がオールアウト（アルの
場合）及びオールイン（デーブの場合）であることを示
唆している。しかし、若干の適用業務は他の可能性を好
むかも知れない。例えば、承認が多かった、または拒否
が多かったかに依存して、複数の検査者に同時にディス
パッチされた提案はコーディネータによって操作され得
る。問題は、適用業務が何を欲しているかを汎用オブジ
ェクト経路指定システムがどのようにして知るかであ
る。１つの変形は条件付き表現式と動作ストップとを対
応付け、例えば「ディスパッチ」を介して上司に諸条件
を可能ならしめることである。（概念的に類似のアプロ
ーチを上述のメッセージ管理システムに使用した。）こ
のアプローチは、適用業務に特定の変数及び意味を経路
内に置くので、ここでは使用されなかった。別の変形
は、「ディスパッチ」を介して上司に並行化機能を選択
させることである。これは、上司が彼等のストップにお
いて動作経路の接続形熊（トポロジ）を知る必要があ
り、並行グラフ内の上司が矛盾する機能を選択する時に
混雑を生じさせる恐れがある。並行経路指定のこれらの
変形の代わりとして、機能オールアウト及びオールイン
がデフォルトとして支持され、適用業務はもし必要なら
ば他の機能を指定することが許容される。詳述すれば、
あるオブジェクトが複数の後任者を有するストップにお
いてディスパッチされる時、そのオブジェクトは（別の
機能が指定されていない限り）全ての後任者へ同時に経
路指定され、もしあるストップが複数の前任者を有して
いれば、そのストップは全ての前任者がオブジェクトを
ディスパッチするまで「現在の」にはなれない。システ
ムは、ファーストイン、多数イン、及び各インのような
機能から選択された付加的な機能を提供する。これは、
図４のオブジェクトの３０の例では、ビル、サイ、また
はキャシーの何れかが完了すると（ファーストイン）、
または彼等の最初の２人が完了すると（多数イン）、ま
たは彼等の各々が完了する度に（各イン）、デーブが現
在の上司になり得ることを意味する。適用業務は、各動
作ストップの並行化標識（図６参照）をこれらの機能の
何れかに、または適用業務専用機能にセットすることが
できる。この標識は経路作成時か、または「並行セッ
ト」（表１参照）を動的に呼出すことによってセットす
ることができる。（表１の“ｗｈｉｃｈ”）パラメタ
は、その動作経路またはデフォルトによる並行動作経路
から検索できる動作ストップに対応付けられた番号であ
り、“ａｒｇ”は指示された機能“ｆ”に渡される未解
釈値である。）保護のために、上司は、その関連動作ス
トップのみに影響を与えるが他には影響を与えないよう
に、この操作を呼出すことができる。この機能は、対応
ストップにおける並行経路指定について決定をなさなけ
ればならない時は、「ディスパッチ」による“未呼出
し”であろう。簡易化及び汎用性のために、全ての適用
業務専用機能は標準インタフェースに固執しなければな
らない（表２のパーイン及びパーアウト機能参照）。パ
ーイン機能は複数の“入ってくる”アークを有するスト
ップが現在のストップになり得る時を決定し、パーアウ
ト機能は“出て行く”アーク上のどのストップが現在の
になり得るかを決定する。並行経路指定に伴う１つの問
題は、移動を如何に処理するかである。基礎をなすシス
テムがオブジェクト複製を支持しないから、経路指定さ
れたオブジェクトは多くとも１つの並行上司へのみ移動
できる。もし殆どの並行上司がとにかく１人の上司の位
置に位置しているか、またはその上司が比較的より屡々
オブジェクトと対話することが予期されれば、オブジェ
クトを１人の上司の位置へ移動させることは合理的であ
る。一方、もしこれら全ての上司が分散していてそのオ
ブジェクトと同じように且つ同時に対話するのであれ
ば、そのオブジェクトはどの位置へも移動させるべきで
はない。そこで問題は、どのような変形を選択するかで
ある。適用業務または経路指定システムの何れかに決定
させると、両者の複雑さが増加する。複数の次のストッ
プが存在する場合に、また移動ヒントが移動を示唆して
いる場合でさえ、オブジェクトを移動させるのを控える
方が好ましい。このポリシーは、若干の場合におけるオ
ブジェクトとの対話の潜在的非効率（これらの対話が遠
隔呼出しを包含するから）と、他の場合における経路指
定システムの簡略さと効率（多重移動がセーブされるか
ら）とをトレードオフする。さて例外を説明する。ある
オブジェクトの滑らかな経路指定は、基本的に３つの状
況において妨害され得る。即ち（１）次のプリンオブジ
ェクトが到達不能であり、従って前に示唆したように
「通知」に失敗する場合、（２）現在の上司が誤りを見
出し、それをその経路を戻ってオブジェクトに報告する
ことを欲した場合（例えばアンの伝票の場合には、チェ
ンが経費のかかり過ぎを発見するか、またはベンが正し
く署名しなかったので伝票をベンまで戻したい場合）、
（３）前の上司が経路指定されたオブジェクトに関係す
る状態を発見し、それを現在の（１人または複数の）上
司の注意をひくために送りたい場合（例えば図４のメモ
の提出者は、全ての指名された上司によるメモの監査が
前に考えていたよりも早く完了するだろうことを見出す
ことができる）。次のプリンオブジェクトに通知のため
に到達できない場合には、経路指定されたオブジェクト
はその動作経路上を進行することができず、従って期限
に遅れるかまたは欠如さえしかねない。前述のように、
「通知」の呼出しに失敗すれば、「ディスパッチ」は成
功するまで一定の（実施によって特定された値）間隔で
再試行する。「通知」の呼出しには成功するが、通信の
諸問題で返答に失敗することが起り得ることに注意され
たい。これは、「通知」または通知された上司は重視呼
出しを認識できるべきであるから、問題とは見做されな
い。もし回路網が区切られており、次のプリンオブジェ
クトに長時間に亘って到達不能であれば、経路指定シス
テムは上述の問題を解消するために思い出させサービス
または若干の上司の短気に頼る。例えばある上司は経路
指定されたオブジェクトの手詰りを、そのオブジェクト
をホルダーに添付することによって打開し、特別な経路
上のその対を適切な職務へ経路指定することができる。
例外の第２例では、現在の上司は経路指定されたオブジ
ェクトを２つの方法で後方へ戻すことができる。「通
知」を呼出す時に誤りが発見されれば、「通知」はその
呼出しを拒絶し、そのオブジェクトを経路指定すべき別
の上司の名前を任意選択的に戻すことができる。変形と
して、もし誤りが後刻発見されれば、現在の上司は「デ
ィスパッチバック」（図１６）を呼出してそのオブジェ
クトを拒絶することができる。この呼出しは、拒絶の際
に拒絶の理由を説明する任意選択本文を通知できるよう
に、代替上司を名指しすることができる。もし代替名が
与えられないか、またはそれが「悪い」に転ずれば、オ
ブジェクトは前の（１人または複数の）上司へ経路指定
され、この（これらの）上司は再び現在の上司になる。
上司はこのことを「例外通知」（表２）を介して通知さ
れる。（もし今度は呼出されたプリンオブジェクトに到
達不能であれば、呼出しは「通知」の場合のように再度
試みられる。また、「ディスパッチバック」はディスパ
ッチと同じようにして先の思い出させを取消す（図１６
のブロック９２ａ参照）。）この操作のパラメタは「通
知」のパラメタに類似し、同じ目的に役立つ。“ｒｅａ
ｓｏｎ”及び“ｄｉｒｅｃｔｉｏｎ”パラメタは付加的
な説明を与える。もし誤りが重大であれば、提出者に戻
される間ずっと上司はオブジェクトを再度「ディスパッ
チバック」できる。これはプログラミング言語における
例外逆伝播に概念的に類似している。上述の例外の第３
例では、「警告」（表１及び図１５参照）を介して順方
向例外を掲げることによって現在の（１人または複数
の）上司の注意を引くことができる。ディスパッチメカ
ニズムは、前述のように「例外通知」を介して（“ｄｉ
ｒｅｃｔｉｏｎ”をＦｏｒｗａｒｄにセットして）現在
の（１人または複数の）上司に通知する。通知された上
司は、例えば経路指定されたオブジェクトを迅速に操作
するか、または誤りの場合には「ディスパッチバック」
を介してそれを戻す等、如何に反応するかを決定する。
図８はディスパッチ操作を実行する際の制御の流れをよ
り詳細に示す。あるノードはエントリ４５において経路
指定されたオブジェクトに関してディスパッチの呼出し
を受ける。この経路指定されたオブジェクトはハンドル
ｈを有し、このｈのための動作経路オブジェクトがブロ
ック４６において入手される。動作経路及び呼出しは、
それらが正しいか及び許容されるかが判断４７及び４８
において調べられ、もしＮであれば誤りは戻される。現
在の動作ストップにおける思い出させ操作の要求はブロ
ック４９で実行される。ブロック４９は図９の流れ図Ａ
１を含み、各要求はそれが小言のためかまたは判断点に
おける否定報告のためかが調べられ、もしＮであればブ
ロック５２において肯定報告のためのプリンオブジェク
トの報告操作を呼出すために、思い出させ機能が呼出さ
れる。もし小言か否定報告の何れかであれば、ブロック
５３において思い出させメカニズムによって要求は破棄
される。全ての要求の後に判断５４においてカーソルが
調べられ、これが動作経路内の最後のストップか否かが
判定され、もしＹならばブロック５５及び第１０図の流
れ図Ａ２において後書き操作が遂行される。もしこれが
最後の動作経路でなければ、ブロック５６においてカー
ソルがリセットされて次のストップが現在のストップに
され、制御は図１１の流れ図Ａ３に示す通知及び引き渡
しメカニズムに渡される。図１１の判断５８は先ずプリ
ンオブジェクトへのハンドルの存否を調べ、Ｎであれば
ブロック５９において機能翻訳操作が呼出される（図１
２の流れ図Ｂ）。もしハンドルが存在すれば、ブロック
６０が通知機能を呼出す（図１３の流れ図Ｃ）。判断６
１は呼出しが成功したか否かを（即ち上司オブジェクト
は到達可能か否かを）調べ、Ｎであればブロック６２に
おいて再試行が列化される。もし呼出しが成功し、返答
を受ければ判断６３は通知が受諾されたか否かを調べ、
もしＹならばブロック６４において引き渡しメカニズム
が呼出される（図１４の流れ図Ｄ）。引き渡し後、もし
あれば、戻す前に小言要求を列化することができる。も
し通知呼出しが判断６３において否定され、判断６５に
おいて代替上司が名指しされていることが見出されれ
ば、ブロック６６は新上司のための動作ストップを動作
経路オブジェクトに付加し、この新ストップを現在のも
のとする。ブロック６７において新プリンオブジェクト
のハンドルが入手され、制御はＦ点に戻されて代替長司
の通知が呼出される。もしその動作ストップが動作経路
内の最後の動作ストップであれば、図８のブロック５５
において後書きが呼出され、制御は図１０の流れ図に移
される。考え得る動作の各組の存否が一連の判断６８、
６９及び７０によって調べられ、ブロック７１、７２及
び７３においてそれぞれの動作の何れかが遂行される。
もし“破棄”が存在しなければ動作経路は安定記憶装置
内に残されるが、もし存在すれば全てのトレースは除去
される。図１２を参照する。機能翻訳は判段６９の決定
に従って全てのまたは１つの動作ストップ上で遂行でき
る。もし全てに対して遂行するのであれば、ブロック７
０に示すように図１２の流れが各動作ストップ毎に繰り
返される。判段７１は上司の名前がその動作ストップ内
にあるか否かを決定し、もし存在しなければブロック７
２においてその名前が情報ベースから回復される。返答
を受けると、それは判断７３において単一の名前である
か否かが調べられる。もしＮであれば群を拡張して群の
各職員を入手し、各名前が回復される。１つの、または
複数の名前を入手した後、制御は経路７４に戻され、判
段７５は上司のプリンオブジェクトのハンドルが動作経
路内に存在するか否かを調べ、Ｎであればブロック７６
においてハンドルがオブジェクトスーパバイザから取り
込まれる。通知機能は図１３に示されている。先ず、判
段７７はプリンオブジェクトが好ましい通知方法のパタ
ーンを有しているか否かを判定する。もしＮであればブ
ロック７８においてデフォルト通知方法が実現される。
もし有していれば、判段７９、８０及び８１を含む判断
の木に進んで、役割及び適用業務セレクタのためのエン
トリの存否が調べられ、その後にエントリが実行され、
判断８２において経路指定されたオブジェクトが受諾さ
れたか否かが調べられる。もしオブジェクトを受諾すべ
きではないことをエントリが示せば、代替上司（もしあ
れば）へ戻される。受託されれば、ブロック８３に示す
ように通知方法が遂行される。図１４は引き渡しメカニ
ズムの流れ図である。判断８４において、移動ポリシー
が協議され、動作経路オブジェクト内の移動ヒントが比
較される。もし移動が推奨されなければ制御は戻される
が、推奨されればブロック８５においてスーパバイザの
移動メカニズムが呼出される。ブロック８６に示すよう
に、もしその動作がポリシーによって推奨されれば、オ
ブジェクトは安定記憶装置内へも移動される。警告及び
ディスパッチバック機能の流れ図を図１５及び１６に示
す。警告の場合、ブロック８７及び判断８８において経
路指定されたオブジェクトｈのための動作経路オブジェ
クトが含まれているか、及び正しい動作経路であるかが
調べられ、次いで例外通知（表２）がブロック８９にお
いて呼出される。判段９０における判定は呼出しが成功
したか否かを調べるものであり、もしＮであればブロッ
ク９１において再試行が列化される。図１６のディスパ
ッチバックメカニズムは、現在の動作ストップに対応付
けられた要求を処理するブロック９２ａまでは図８のデ
ィスパッチメカニズムと同一である。次の判断９２ｂは
代替上司が名指されているか否かを調べ、もしＹがあれ
ばブロック９３はこの代替上司のための動作経路に新動
作ストップを付加する。ハンドルが入手された後図１１
のエントリ点下に戻される。もしＮであれば、ブロック
９４において前の動作ストップが「現在の」にセットさ
れ、点９５において“ｄｉｒｅｃｔｉｏｎ”をｂａｃｋ
ｗａｒｄにセットすることによって例外通知が呼出さ
れ、次いで判段９６において呼出しが成功したか否かが
調べられる。もし呼出しが成功しなければ、ブロック９
７において再試行が列化される。本発明のオブジェクト
経路指定システムの実施例は、前述のＢｉａｃｋ＆Ａｒ
ｔｓｙの刊行書に記載の分散型システム内で実現されて
いる。この刊行書は高度に分散した適用業務を構成する
ための枠組を記述している。例示システムは利用者レベ
ルで走る図１または図２の論理ノード１０−１３からな
り、オブジェクト向きプログラミングを支持し、ＬＩ
Ｉ、オブジェクト移動及びオブジェクト維持のためのサ
ービスを提供する。オブジェクトスーパバイザは各ノー
ドに常駐してこれらのサービスを提供する。システムは
モジュラ２＋で実現され、供給されたＰＲＣとマルチス
レッドサービスを提供する。このモジュラ２＋システム
はＩＥＥＥ Ｓｏｆｔｗａｒｅ３：６（１９８６年１１
月）の４６−５７頁にＰ．Ｒｏｖｎｅｒが「大きい統合
されたシステムへのモジュラ２の拡張」として記述して
いる。実施例は、適用業務が書式、ホルダー、上司及び
メモオブジェクト型からなるある会社内のマイル当り経
費伝票を処理するように実現できる。これは経費報告を
処理する上述の適用業務例に類似している。端末に座す
従業員はグラフィック、ウインドウベース型利用者イン
タフェースを使用して伝票テンプレートをポップアップ
させ、所要の書込みを行い、そしてそれをシステムに提
出する。適用業務は動作経路を、利用者に透明な伝票オ
ブジェクトに割り付ける。典型的には動作経路は従業
員、彼のまたは彼女のコストセンターの管理者、そのコ
ストセンターの責任者である出納係、及び記録保管者を
含む。経費の量及び本質に依存して、伝票は別の管理者
の承認を必要とするかも知れず、経路は長くなるかも知
れない。従業員、管理者、出納係及び記録保管者は典型
的には互に接近している（同一ＬＡＮ）が、若干の場合
には彼等は数乃至数千マイルも離れているかも知れな
い。この適用業務例では従業員、管理者、出納係及び記
録保管者はプリンオブジェクトで表わされる上司であ
る。しかし出納係及び記録保管者は自動化されており、
従って彼等は異なる対話スタイルを使用する。この例示
オブジェクト経路指定システムは上述した機能の部分集
合を含み、全てのデフォルト任意選択を支持する。適用
業務は、伝票オブジェクトがシステムに提示された時に
動作経路を作成する手続きを提供する。この手続きは伝
票（前述の費用償還例におけるアンの伝票の１つに類
似）を操作する（組織役割による）上司のリストを指定
する。名前サービスは情報ベースを記憶するために使用
され、このベースは上司名と彼等の組織的結合とを含
み、またプロトタイプ内の各組織単位毎に従業員、管理
者及び他の幾つかの職務のリストを含む。機能翻訳メカ
ニズムはこの名前サービスを使用して上司の名前を見出
し、彼等のオブジェクトのハンドルをスーパバイザを介
して入手し、そしてそれらを動作経路内の適切なストッ
プに付加する。伝票をディスパッチするために、人間の
利用者（従業員または管理者）が彼のまたは彼女のワー
クステーション画面上のディスパッチアイコンをクリッ
クれせると利用者インタフェースは適切なパラメータを
有する「ディスパッチ」を呼出し、自動化された出納係
または記録保管者のプリンオブジェクトは直接「ディス
パッチ」を呼出す。人間上司のための通知のデフォルト
方法は、経路指定されたオブジェクトハンドルをその経
路の主体を有する上司の“インボックス”ホルダー内に
挿入することである。人間利用者のための利用者インタ
フェースはこのホルダーを周期的にポーリングし、もし
そこに新オブジェクトを発見すれば、インタフェースは
明滅するアイコンによってこの事実を利用者に示す。利
用者は彼等の都合によってホルダーを開くことができ、
彼等の操作を待っているオブジェクトの実体を見、それ
を指すことによって彼等が処理しようとしているものを
選択することができる。しかし自動化された出納係のた
めの通知操作は、伝票の内容を調べ、署名（及び、勿論
小切手の発行）を確認するためのその確認操作を直接呼
出す。記録保管者のプリンオブジェクトの通知操作は単
に伝票をファイルし、それを直ちに再ディスパッチする
だけである。この例示適用業務における移動ヒントは常
にイエスであり、デフォルトポリシーは経路指定された
オブジェクトを現在の上司の位置へ移動させることであ
る。ホルダーオブジェクトは複数のオブジェクトを単一
の経路に経路指定するために使用される。別の実施例で
は、本発明の概念を、種々の拡張機能を有するシステム
内に使用できる。例えば、トランザクション処理がこれ
らの概念を用いることができる。ビジネストランザクシ
ョンは会計または銀行員の予め限定されたリストのよう
な十分に定義された論理経路を有することが多い。動作
経路はこの目的に使用でき、経路指定されたオブジェク
トはトランザクションの“実体”（例えば金銭転送簿）
であるか、または各ストップにおいて遂行されるトラン
ザクションスクリプトである。しかしトランザクション
処理は、トランザクションの打切りまたは若干の操作の
取り消しのような若干の付加的サービスを要求する。こ
れらの付加的サービスを含むように経路指定システムを
拡張するためには、トランザクション処理に必要な独特
なサービスを経路指定システムに付加することになる
か、またはトランザクション処理用意味を経路指定シス
テム内に組入れることになる。例えば、２つのシステム
を統合する一方法は、各動作ストップにおける動作をサ
ブトランザクションとして見ることである（経路全体は
ネストされたトランザクションである）。経路指定シス
テムは、経路指定されたオブジェクトに対する委託、打
切り、取り消し、またはやり直し操作の要求に従って経
路を変更することを許容しよう。変形として、各動作ス
トップはログラベルを用いてタグを付けることができ
る。またディスパッチは各動作ストップにおける変更を
記録または委託することになろう。経路指定されたオブ
ジェクトをそのストップにディスパッチバックするもの
とすれば、経路指定システムは自動的に、または求めに
応じて、経路指定されたオブジェクトの状態をラベルを
付けたログ記録まで戻すようにロールさせることができ
る。本発明は、分散型システム内の完全な“不要部分の
整理”を受入れるために若干の変更を必要としよう。通
常は経路指定されたオブジェクト（Ｏ）が経路を完成さ
せると、動作経路は消滅するが、若干の適用業務がそれ
を後の監査のために残すことを欲するかも知れない。若
干の場合には、もし適用業務が経路の終りにおけるＯか
らのＡＰＯの切離しに注意深く、またＡＰＯを明示的に
処置するかまたは自動的な不要部分の整理メカニズムに
それを取り戻させるようにすれば、ＡＰＯの処置は容易
に達成できる。しかし他の場合には、多くのプリンオブ
ジェクトが未だにＡＰＯへの参照を有しているかも知れ
ないので、ＡＰＯの取り戻しは困難であるかも知れな
い。ＡＰＯへの参照が存在していても“孤児”ＡＰＯを
収集する能力を改善するために、若干の適用業務ヒント
が必要である。上述の実施例では、プリンオブジェクト
に経路指定されたオブジェクトへのハンドルが与えら
れ、従って通常はＯだけがそのＡＰＯへの参照を有して
おり、これは経路の終りに容易に落とされる。変更を必
要とする別の領域は、完全な保護された易変性の供給に
ある。上記説明では、機能翻訳に基づいて経路を拡張で
きるのはディスパッチメカニズムに限られ、現在の上司
は代替を提供していた。そのようにしないと利用者は動
作ストップのグラフを変更することができない。しかし
若干の適用業務においては利用者が動作経路を変更する
ことを許容されるか、または要求さえするかも知れな
い。このような機能が有用である例は初めの群の人々に
メモを送るに当って、各人がメモを見ることに関心があ
るかも知れない他人の名前を要求（そしてそれらをある
順番に経路内に付加する）するような場合である。これ
はメモのコピーをホルダー内に置き、特別な経路を使用
することによって（上品さは欠けるが）達成することが
できる。利用者にグラフの拡張または変更を指定させる
ことは若干の状況では有用であるが、グラフの複雑さ
（経路が極めて複雑になり得る）と経路の一貫性（並行
経路内の異なる利用者が矛盾する枝路を示唆されるかも
知れない）の問題が発生し、考え得る全ての変更を表現
するためには複雑な利用者インタフェースを必要としよ
う。またそれは変更が適用業務によって許容されている
ことをどのようにして確認するかの問題も提起する。さ
らに、若干の適用業務は、事象の報告の入手または経路
の複写を含む経路に対する操作の使用をより多く制約す
ることを要求するかも知れない。何れの方法において
も、経路指定の意味を適用業務内に導入する、または適
用業務の意味をオブジェクト経路指定内へ導入すること
はできるが、両アプローチ共望ましいものではない。オ
ブジェクト経路指定システムを拡張する一方法は、能力
またはアクセス制御リストと動作経路と、を、または各
ストップとでさえ結合し、公認されていない変更から保
護するために確認（オーセンチケーション）サービスを
使用することである。これらのリストは適用業務に特定
の意味を有するが保護メカニズムは適用業務に無関係と
することができる。このような拡張は経路指定システム
の複雑さを増大させよう。以上に、メールメッセージ、
構造化データ型、またはファイルのような各種のオブジ
ェクトを経路指定するために使用できる総合的なオブジ
ェクト経路指定システムを説明した。このオブジェクト
経路指定システムは、人間の利用者の便宜のための幾つ
かの機能（例えば本文記述の使用、思い出させ、及び選
択的通知）を含み、実施例に示したように経路指定の目
標上司を自動化ツールとすることもできる。本オブジェ
クト経路指定システムと従来システムとの差異は、前述
した有用なメカニズムの使用、若干の独特機能によるア
ップグレード、適用業務には無関係の汎用分散型システ
ムサービスの提供にある。経路の評価及び変更に若干の
制約が課せられてはいるが、経路指定されたオブジェク
トの進行を制御し監視する、及び若干の事象が上司の注
意を必要とする場合には上司に通知の方法を選択させる
強力且つ柔軟なツールが提供される。オブジェクト支持
サービスより上位のサービス層としての経路指定システ
ムの構成が、このシステムを使用が簡単で、均一で、強
力なシステムとしている。要約すれば、このシステムの
“オブジェクト指向度”がもたらしたシステムの主な便
益は以下のようである。 （１）保護。動作経路をオブジェクト内にカプセル封じ
したことによって、情報の隠蔽と経路の状態の保護が与
えられる。反対に、もしメールシステムにおいて経路が
メールメッセージの一体部分であれば、その内部状態は
隠蔽されることもないし、利用者から保護されることも
ない。 （２）呼出しの均一性。経路に対する操作は、経路指定
されたオブジェクトに対する操作及び目標上司に対する
操作と同じ方法で呼出される。 （３）インタフェースの均一性。経路指定の目標はオブ
ジェクトであるから、それらが人間であるのか自動化ツ
ールであるのかは経路指定システムの目から区別するこ
とはできず、システムはそれらと通信するのに同一の方
法を使用する。これは通知及び思い出させを簡単にす
る。 （４）通信及び追跡性。下位の位置に無関係のオブジェ
クト間通信メカニズムはオブジェクト経路指定システム
の設計を簡単にする。上司は、彼等が何処にいるかには
関係なく通知されることができる。経路は、それらの現
在位置には関係なく上司によって検査することができ
る。この機能は、動作経路に沿うオブジェクトの進行を
制御する能力を与える重要な便益を提供する。一方、メ
ッセージ経路指定システムでは、このような追跡性はメ
ッセージをオブジェクトとして見、本発明のサービスと
類似のサービスを使用するか、またはメッセージデータ
ベースを使用することによって達成することができる。
中央に集められたデータベースを使用するとシステムの
拡張性が制限され、一方分散したデータベースを使用す
ると一貫性を維持するための通信コストが高くなる。 （５）共用及び並行化。経路共用及び並行経路指定はオ
ブジェクト向きシステムにおいては容易である。これは
対してメッセージベース型システムにおいては複数のメ
ッセージによる同一経路の共用（その更新を含む）は殆
ど不能であり、同様に複数の上司が単一のメッセージ
（そのコピーではない）に同時にアクセスすることも殆
ど許されない。 （６）効率的な対話。オブジェクト移送は、経路指定さ
れたオブジェクトと次の上司とを動作経路上で同位置に
配置することを許容する。一方データベース内に記憶さ
れている経路指定論理構成要素は、それらを対話ノード
へ“移送”するか、または全ノードに常駐するローカル
区切りでデータベースを区切らない限り、この便益は受
けられない。 （７）アドレス指定の簡易化。メッセージベース型、ま
たはメールベース型の経路指定では、システムは名前を
回路網に広がる、従って変化することがあるアドレスに
変換しなければならず、従って誤りが導入され易い。オ
ブジェクトスーパバイザが（使い古された回路網アドレ
スを扱う）目標オブジェクトを捜さなければならない
が、これは経路指定システムから隠蔽され、従ってその
設計を容易ならしめる。勿論、移動するオブジェクトを
追跡し、オブジェクトハンドルをオブジェクト位置へ写
像するためにスーパバイザは複雑になる。しかし、何れ
にしても後者は分散型オブジェクト向き適用業務を支持
するためにこの問題に対処しなければならないから、経
路指定システムはこの簡易性を殆ど“無料で”入手す
る。 以上の説明は、特定プロセスにではなく、経路指定を支
持するメカニズムに焦点を絞った。動作経路を指定する
プログラミングツールは、選択されたシステム及びプロ
グラミング言語に依存して種々の型であってよい。ある
経路は適用業務内の“ハードワイヤード”でよく、ある
経路はテンプレート経路のライブラリから作成でき、ま
たある経路は特別な経路としてグラフィックまたは本文
向き利用者インタフェースによって作成してもよい。言
語ベース型ツールも経路を指定でき、それらを生成する
コンパイラを有し、前述のメッセージ管理システムにや
や似ている。以上に本発明の特定の実施例について説明
したが、この説明は本発明を限定するものではない。説
明した実施例に種々の変更が考えられるがこれらの変更
も本発明の範囲内に含まれることを理解されたい。
【表１】
【表２】
【図１】分散型コンピュータシステムのブロック線図で
あって、本発明によるオブジェクト経路指定システムを
使用できる若干の物理ノード１０−１３を含む。
あって、本発明によるオブジェクト経路指定システムを
使用できる若干の物理ノード１０−１３を含む。
【図２】図１のような分散型コンピュータシステムにお
ける各論理ノードのサービス層の論理表現である。
ける各論理ノードのサービス層の論理表現である。
【図３】本発明によるオブジェクト経路指定システムに
使用される順次動作経路の論理表現である。
使用される順次動作経路の論理表現である。
【図４】図３に似ているが並行動作経路オブジェクトの
ための論理表現である。
ための論理表現である。
【図５】上司Ｐが１回以上操作しなければならない場合
の図３による順次動作経路の論理表現である。
の図３による順次動作経路の論理表現である。
【図６】図３または図５の動作経路オブジェクトに使用
され操作の論理表現である。
され操作の論理表現である。
【図７】１つの動作ストップから別の動作ストップへ経
路指定する本発明の方法の論理流れ図である。
路指定する本発明の方法の論理流れ図である。
【図８】図７の方法のディスパッチメカニズムのより詳
細な論理流れ図である。
細な論理流れ図である。
【図９】図８の方法のディスパッチの思い出させ段階の
より詳細な論理流れ図である。
より詳細な論理流れ図である。
【図１０】図８の方法の動作経路後書きを遂行する段階
のより詳細な論理流れ図である。
のより詳細な論理流れ図である。
【図１１】図８の方法の通知及び引き渡しを遂行する段
階のより詳細な論理流れ図であり
階のより詳細な論理流れ図であり
【図１２】図７の方法の機能翻訳段階のより詳細な論理
流れ図である。
流れ図である。
【図１３】図７の方法の通知段階のより詳細な論理流れ
図である。
図である。
【図１４】図７の方法の引き渡し段階のより詳細な論理
流れ図である。
流れ図である。
【図１５】警告要求を処理する方法の詳細な論理流れ図
である。
である。
【図１６】ディスパッチバック要求を処理する方法の詳
細な論理流れ図である。
細な論理流れ図である。
１０−１３ ノード １４ ＣＰＵ １５ メモリ １６ ハードディスク記憶装置 １７ コンソール １８ システムバス １９ 通信アダプタ ２０ リンク ２１ 経路指定システム ２２ 基本サービス ２５ 順次動作経路オブジェクト ２６ 見出し ２７ 本体 ２８ 動作ストップ ２９ 後書き ３０ 並行動作経路オブジェクト ３１ 接合点 ３２ カーソル
Claims (26)
- 【請求項１】 分散型計算システムにおいてオブジェク
トを経路指定する方法であって、 （ａ） 経路指定されるオブジェクトを作成し、この経
路指定されるオブジェクトに添付される動作経路オブジ
ェクトを作成し、この動作経路オブジェクトが経路指定
されるオブジェクトのための動作ストップの順序を定義
し、 （ｂ） 経路指定されたオブジェクトを次の動作ストッ
プ内で名指しされた次の上司へディスパッチし、もし必
要ならば、この動作ストップ内で名指しされたまたは機
能的に記述された上司の識別を翻訳する段階と、次で上
司のオブジェクトハンドルを見出す段階とを含み、 （ｃ） この動作ストップ内の記述された上司オブジェ
クトを上記ハンドルを使用して通知し、 （ｄ） 経路指定されたオブジェクトを上記上司によっ
て好まれたノードへ論理的にまたは物理的に引き渡し、 （ｅ） 経路指定されたオブジェクトとこの経路指定さ
れたオブジェクトに添付された動作経路オブジェクトと
をシステムのあるノードにおいて受け、この動作経路オ
ブジェクトが経路指定されたオブジェクトのための動作
ストップの順序を定義し、 （ｆ） 経路指定されたオブジェクトに対して上記ノー
ドにおいてある上司にある操作を遂行させ、終了した時
に経路指定されたオブジェクトを次の上司へディスパッ
チすることを要求することによってそのことを示し、 （ｇ） 経路指定されたオブジェクトを上記順序の次の
動作ストップ内で名指しされたまたは記述された上司へ
ディスパッチし、もし必要ならば、この次の動作ストッ
プ内で名指しされたまたは機能的に記述された上司の識
別をその上司のオブジェクトハンドルに翻訳する段階を
含み、 （ｈ） 経路指定されたオブジェクトに対して上記ノー
ドにおいてある上司にある操作を遂行させ、終了した時
に経路指定されたオブジェクトを次の上司へディスパッ
チすることを要求することによってそのことを示し、 （ｉ） 動作経路の最後の動作ストップが完了するまで
段階（ｂ）乃至（ｈ）を繰り返し、そして （ｊ） 最後の動作ストップの後に遂行すべき動作経路
が作成されると要求された一連の操作を遂行する諸段階
を具備することを特徴とする方法。 - 【請求項２】 分散型計算システムが複数のノードを有
し、動作ストップがこれらのノードの特定のノードに対
応付けられた上司の名前または機能記述を記述する請求
項１に記載の方法。 - 【請求項３】 引き渡し段階が、動作経路オブジェクト
内の移送情報に基づいて、経路指定されたオブジェクト
をノードへ物理的に移送するか否かを決定する段階を含
む請求項２に記載の方法。 - 【請求項４】 動作経路オブジェクトが、現在の１また
はそれ以上の動作ストップを指し標識を含む請求項１に
記載の方法。 - 【請求項５】 もし標識が前記順序の最後の動作ストッ
プを越えて指していれば、繰り返し段階は遂行されない
請求項４に記載の方法。 - 【請求項６】 動作ストップの順序は並列に動作ストッ
プを含み得るが、経路指定されたオブジェクトは並列動
作ストップに対して複製されることはなく、それによっ
てこのオブジェクトの変更の効率的な同期を可能にした
請求項１に記載の方法。 - 【請求項７】 上司が、それによって通知されることを
欲するか、またはそれによって経路指定されたオブジェ
クトを他の誰かに向かわせる彼等の特定の方法を、オブ
ジェクト経路指定システムが上司に記述させるメカニズ
ムを通知段階が含む請求項１に記載の方法。 - 【請求項８】 分散型計算システムにおいてオブジェク
トを経路指定する方法であって、 （ａ） 経路指定されたオブジェクトとこの経路指定さ
れたオブジェクトに添付される動作経路オブジェクトと
をシステムのあるノードにおいて受け、この動作経路オ
ブジェクトが経路指定されたオブジェクトのための動作
ストップの順序を定義し、上記ノードが動作ストップの
１つに対応付けられ、 （ｂ） 経路指定されたオブジェクトに対して上記ノー
ドにおいてある上司にある操作を遂行させ、終了した時
に経路指定されたオブジェクトを次の上司へディスパッ
チすることを要求することによってそのことを示し、 （ｃ） 経路指定されたオブジェクトを上記順序の次の
動作ストップ内で名指しされたまたは機能的に記述され
た次の上司へディスパッチし、もし必要ならば、この次
の動作ストップ内で名指しされたまたは機能的に記述さ
れた上司の識別をそのオブジェクトハンドルに翻訳する
段階を含み、 （ｄ） 経路指定されたオブジェクトを次の動作ストッ
プへ論理的にまたは物理的に引き渡す諸段階を具備する
ことを特徴とする方法。 - 【請求項９】 分散型計算システムが複数のノードを有
し、動作ストップがこれらのノードの特定のノードに対
応付けられた上司オブジェクトのハンドルとして識別さ
れる請求項８に記載の方法。 - 【請求項１０】 上司がそれによって通知されることを
欲するか、またはそれによって経路指定されたオブジェ
クトを他の誰かに向かわせる彼等の特定の方法を、オブ
ジェクト経路指定システムが上司に記述させるメカニズ
ムを通知段階が含む請求項８に記載の方法。 - 【請求項１１】 動作経路オブジェクトが、現在の１ま
たはそれ以上の動作ストップを指す標識を含む請求項８
に記載の方法。 - 【請求項１２】 標識が前記順序の最後の動作ストップ
を越えて指しているか否かを調べる段階を含む請求項１
１に記載の方法。 - 【請求項１３】 動作ストップの順序は並列に動作スト
ップを含み得るが、経路指定されたオブジェクトは並列
動作ストップに対して複製されることはない請求項８に
記載の方法。 - 【請求項１４】 経路指定されたオブジェクトをホルダ
ーオブジェクトに添付し、付加的なオブジェクトをこの
ホルダーオブジェクトに添付し、前の（または新しい）
動作経路オブジェクトをそのホルダーに添付し、それに
よってこれらのオブジェクトを一緒に経路指定し移送さ
せる請求項８に記載の方法。 - 【請求項１５】 引き渡し段階が、動作経路オブジェク
ト内の移送情報に基づいて、経路指定されたオブジェク
トを次の動作ストップへ物理的に移送するか否かを決定
する段階を含む請求項８に記載の方法。 - 【請求項１６】 分散型計算回路網においてオブジェク
トを経路指定する装置であって、 （ａ） 経路指定されたオブジェクトとこの経路指定さ
れたオブジェクトに添付された動作経路オブジェクトと
を回路網のあるノードで受ける手段（この動作経路オブ
ジェクトが経路指定されたオブジェクトのための動作ス
トップの順序を定義し、上記ノードが動作ストップの１
つに対応付けられている）と、 （ｂ） 経路指定されたオブジェクトに対して上記ノー
ドにおいてある上司にある操作を遂行させ、終了した時
に経路指定されたオブジェクトを次の上司へディスパッ
チすることを要求することによってそのことを示す手段
と、 （ｃ） 経路指定されたオブジェクトを上記順序の次の
動作ストップ内で名指しされたまたは機能的に記述され
た次の上司へディスパッチし、もし必要ならば、次の動
作ストップ内で名指しされたまたは機能的に記述された
上司の識別をその上司のオブジェクトハンドルに翻訳す
る手段と、 （ｄ） 上記次の動作ストップにおいて記録された上司
オブジェクトを上記ハンドルを使用して通知する手段
と、 （ｅ） 経路指定されたオブジェクトを上記上司によっ
て好まれたノードへ論理的にまたは物理的に引渡す手段
を具備することを特徴とする装置。 - 【請求項１７】 分散型計算回路網が複数のノードを有
し、動作ストップがこれらノードの特定のノードに対応
付けられた上司オブジェクトの名前または機能記述を記
述する請求項１６に記載の装置。 - 【請求項１８】 動作経路オブジェクトが、現在の動作
ストップの１つを指す標識を含む請求項１６に記載の装
置。 - 【請求項１９】 標識が前記順序の最後の動作ストップ
を越えて指しているか否かを調べる手段を含む請求項１
８記載の装置。 - 【請求項２０】 オブジェクトが、メッセージ、ファイ
ル、スクリプト、書式及びそれらの組合せからなる群か
ら選択される請求項１６に記載の装置。 - 【請求項２１】 上司が、人間利用者、人間利用者の
群、または自動化ツールの何れかである請求項１６に記
載の装置。 - 【請求項２２】 要求された操作が選択された期間内に
遂行されなければ操作が要求されている上司を思い出さ
せる手段を含む請求項１６に記載の装置。 - 【請求項２３】 上司が操作を完了せずそのことが経路
指定されたオブジェクトによって示されると他の上司へ
報告するか、または上記上司が経路指定されたオブジェ
クトをディスパッチした時に他の上司へ報告する手段を
含む請求項１６に記載の装置。 - 【請求項２４】 経路指定されたオブジェクトに対して
次に操作しなければならない１または複数の上司を見出
すために、前記標識を使用して上司を変更する手段を含
む請求項１８に記載の装置。 - 【請求項２５】 上司が操作を完了せず経路指定された
オブジェクトのディスパッチによってそのことが示され
ると他の上司へ報告するか、または上記上司が経路指定
されたオブジェクトをディスパッチした時に他の上司へ
報告する手段と、経路指定されたオブジェクトの進行を
監視しその状態をトレースする手段をも含む請求項２２
に記載の装置。 - 【請求項２６】 経路指定されたオブジェクト及びその
経路の両者の状態を回復することを許容する手段を含む
請求項１６に記載の装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US52597090A | 1990-05-18 | 1990-05-18 | |
| US525970 | 1990-05-18 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH0683784A true JPH0683784A (ja) | 1994-03-25 |
Family
ID=24095376
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP3228231A Pending JPH0683784A (ja) | 1990-05-18 | 1991-05-17 | 分散型計算システムにおいて動作経路上にオブジェクトを経路指定する方法及び装置 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5701484A (ja) |
| EP (1) | EP0457684A2 (ja) |
| JP (1) | JPH0683784A (ja) |
| CA (1) | CA2041992A1 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08249290A (ja) * | 1995-03-10 | 1996-09-27 | Hitachi Ltd | 分散システム |
Families Citing this family (116)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6345288B1 (en) * | 1989-08-31 | 2002-02-05 | Onename Corporation | Computer-based communication system and method using metadata defining a control-structure |
| CA2093094C (en) * | 1992-04-06 | 2000-07-11 | Addison M. Fischer | Method and apparatus for creating, supporting, and using travelling programs |
| CA2098415A1 (en) * | 1992-10-07 | 1994-04-08 | David L. Campbell | Computerized general purpose process control system and method employing generic process building blocks |
| US6633861B2 (en) | 1993-03-19 | 2003-10-14 | Ricoh Company Limited | Automatic invocation of computational resources without user intervention across a network |
| US6049792A (en) * | 1993-03-19 | 2000-04-11 | Ricoh Company Limited | Automatic invocation of computational resources without user intervention across a network |
| US7924783B1 (en) * | 1994-05-06 | 2011-04-12 | Broadcom Corporation | Hierarchical communications system |
| AU722119B2 (en) * | 1993-08-10 | 2000-07-20 | Addison M. Fischer | A method for operating computers and for processing information among computers |
| AU683038B2 (en) * | 1993-08-10 | 1997-10-30 | Addison M. Fischer | A method for operating computers and for processing information among computers |
| JP3649345B2 (ja) * | 1994-05-26 | 2005-05-18 | 富士ゼロックス株式会社 | 情報処理システム |
| JP3502471B2 (ja) * | 1995-03-27 | 2004-03-02 | 富士通株式会社 | 自律分散指示書制御装置 |
| US6035399A (en) * | 1995-04-07 | 2000-03-07 | Hewlett-Packard Company | Checkpoint object |
| JP3751664B2 (ja) * | 1995-10-05 | 2006-03-01 | 富士通株式会社 | ソフトウェア登録システムおよび方法 |
| US5754857A (en) * | 1995-12-08 | 1998-05-19 | Sun Microsystems, Inc. | Distributed asynchronous workflow on the net |
| US6345311B1 (en) * | 1995-12-27 | 2002-02-05 | International Business Machines Corporation | Method and system of dynamically moving objects between heterogeneous execution environments |
| US6886167B1 (en) | 1995-12-27 | 2005-04-26 | International Business Machines Corporation | Method and system for migrating an object between a split status and a merged status |
| US5933597A (en) * | 1996-04-04 | 1999-08-03 | Vtel Corporation | Method and system for sharing objects between local and remote terminals |
| US6424991B1 (en) * | 1996-07-01 | 2002-07-23 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server communication framework |
| EP0825506B1 (en) | 1996-08-20 | 2013-03-06 | Invensys Systems, Inc. | Methods and apparatus for remote process control |
| US6336148B1 (en) * | 1996-09-25 | 2002-01-01 | Sun Microsystems, Inc. | Automatic checking of public contracts and private constraints on distributed objects |
| US6108689A (en) * | 1996-10-11 | 2000-08-22 | International Business Machines Corporation | Method and system for processing messages in a distributed computing environment |
| US5895472A (en) * | 1996-11-12 | 1999-04-20 | International Business Machines Corporation | Change and accounting log for object-oriented systems |
| WO1998021671A1 (en) * | 1996-11-14 | 1998-05-22 | Triteal Corporation | Distributed document processing through an object request broker and a receptionist object |
| US6065039A (en) * | 1996-11-14 | 2000-05-16 | Mitsubishi Electric Information Technology Center America, Inc. (Ita) | Dynamic synchronous collaboration framework for mobile agents |
| US6233601B1 (en) * | 1996-11-14 | 2001-05-15 | Mitsubishi Electric Research Laboratories, Inc. | Itinerary based agent mobility including mobility of executable code |
| GB2319863B (en) * | 1996-11-30 | 2001-05-16 | Int Computers Ltd | Groupware |
| US6201814B1 (en) * | 1996-12-12 | 2001-03-13 | At&T Corp. | Telecommunications round-robin message delivery |
| US6151623A (en) * | 1996-12-13 | 2000-11-21 | International Business Machines Corporation | Agent activity report via object embedding |
| US5995999A (en) * | 1997-03-12 | 1999-11-30 | Fujitsu Limited | Naming system for hierarchically named computer accessible objects |
| JPH10320367A (ja) * | 1997-05-19 | 1998-12-04 | Fujitsu Ltd | ネットワーク移動可能なオブジェクト間の通信方法及び通信システム |
| US6338074B1 (en) | 1997-07-23 | 2002-01-08 | Filenet Corporation | System for enterprise-wide work flow automation |
| US7546346B2 (en) | 1997-07-28 | 2009-06-09 | Juniper Networks, Inc. | Workflow systems and methods for project management and information management |
| US5978836A (en) * | 1997-07-28 | 1999-11-02 | Solectron Corporation | Workflow systems and methods |
| US6832202B1 (en) * | 1997-08-29 | 2004-12-14 | Electronic Data Systems Corporation | Method and system of routing requests for authorized approval |
| US6208984B1 (en) | 1997-08-29 | 2001-03-27 | Electronic Data Systems Corporation | Method and system of determining access to records of members of a community |
| US6038548A (en) * | 1997-11-26 | 2000-03-14 | International Business Machines Corporation | System and method for conducting electronic commerce in a computer network using a cashier desk payment framework |
| US6018805A (en) * | 1997-12-15 | 2000-01-25 | Recipio | Transparent recovery of distributed-objects using intelligent proxies |
| CA2226062A1 (en) * | 1997-12-31 | 1999-06-30 | Ibm Canada Limited-Ibm Canada Limitee | Workflow mechanism for a stateless environment |
| GB9800430D0 (en) | 1998-01-10 | 1998-03-04 | Ncr Int Inc | Method and system for routing agent programs through a communications network |
| US6862732B1 (en) * | 1998-02-25 | 2005-03-01 | Metaserver, Inc. | Method and apparatus for event-driven processing of data |
| JP3782229B2 (ja) * | 1998-03-13 | 2006-06-07 | 富士通株式会社 | パス情報構築方法 |
| US6148336A (en) * | 1998-03-13 | 2000-11-14 | Deterministic Networks, Inc. | Ordering of multiple plugin applications using extensible layered service provider with network traffic filtering |
| US6141686A (en) * | 1998-03-13 | 2000-10-31 | Deterministic Networks, Inc. | Client-side application-classifier gathering network-traffic statistics and application and user names using extensible-service provider plugin for policy-based network control |
| JPH11282683A (ja) * | 1998-03-26 | 1999-10-15 | Omron Corp | エージェントシステム |
| US6901426B1 (en) * | 1998-05-08 | 2005-05-31 | E-Talk Corporation | System and method for providing access privileges for users in a performance evaluation system |
| AU2003204806B2 (en) * | 1998-05-29 | 2005-09-01 | Blackberry Limited | System and Method for Pushing Information from a Host System to a Mobile Data Communication Device |
| US6611954B1 (en) * | 1998-06-03 | 2003-08-26 | Intel Corporation | Binary compatible software objects |
| US6728947B1 (en) | 1998-06-05 | 2004-04-27 | R. R. Donnelley & Sons Company | Workflow distributing apparatus and method |
| US6236999B1 (en) * | 1998-11-05 | 2001-05-22 | Bea Systems, Inc. | Duplicated naming service in a distributed processing system |
| US6571274B1 (en) * | 1998-11-05 | 2003-05-27 | Beas Systems, Inc. | Clustered enterprise Java™ in a secure distributed processing system |
| US6385643B1 (en) | 1998-11-05 | 2002-05-07 | Bea Systems, Inc. | Clustered enterprise Java™ having a message passing kernel in a distributed processing system |
| US6581088B1 (en) * | 1998-11-05 | 2003-06-17 | Beas Systems, Inc. | Smart stub or enterprise javaTM bean in a distributed processing system |
| US7039673B1 (en) * | 1998-12-24 | 2006-05-02 | Computer Associates Think, Inc. | Method and apparatus for dynamic command extensibility in an intelligent agent |
| US6928469B1 (en) | 1998-12-29 | 2005-08-09 | Citrix Systems, Inc. | Apparatus and method for determining a program neighborhood for a client node in a client-server network using markup language techniques |
| US6691166B1 (en) * | 1999-01-07 | 2004-02-10 | Sun Microsystems, Inc. | System and method for transferring partitioned data sets over multiple threads |
| AU3218500A (en) * | 1999-02-16 | 2000-09-04 | Cyberstar, L.P. | Content tagging in a data distribution system |
| WO2000070417A1 (en) | 1999-05-17 | 2000-11-23 | The Foxboro Company | Process control configuration system with parameterized objects |
| US7089530B1 (en) | 1999-05-17 | 2006-08-08 | Invensys Systems, Inc. | Process control configuration system with connection validation and configuration |
| US6788980B1 (en) | 1999-06-11 | 2004-09-07 | Invensys Systems, Inc. | Methods and apparatus for control using control devices that provide a virtual machine environment and that communicate via an IP network |
| US6768790B1 (en) | 1999-07-09 | 2004-07-27 | Pitney Bowes Inc. | Message automated information system and importance navigator |
| EP1069737A1 (en) * | 1999-07-13 | 2001-01-17 | International Business Machines Corporation | Method and system for optimizing the network path of mobile programs |
| US6654753B1 (en) | 1999-09-29 | 2003-11-25 | International Business Machines Corporation | Combination associative and directed graph representation of command structures |
| US6772220B1 (en) | 1999-09-29 | 2004-08-03 | International Business Machines Corporation | Next hop command level addressing and routing |
| US6631363B1 (en) * | 1999-10-11 | 2003-10-07 | I2 Technologies Us, Inc. | Rules-based notification system |
| US6662310B2 (en) | 1999-11-10 | 2003-12-09 | Symantec Corporation | Methods for automatically locating url-containing or other data-containing windows in frozen browser or other application program, saving contents, and relaunching application program with link to saved data |
| US6631480B2 (en) | 1999-11-10 | 2003-10-07 | Symantec Corporation | Methods and systems for protecting data from potential corruption by a crashed computer program |
| US6630946B2 (en) * | 1999-11-10 | 2003-10-07 | Symantec Corporation | Methods for automatically locating data-containing windows in frozen applications program and saving contents |
| US6912586B1 (en) * | 1999-11-12 | 2005-06-28 | International Business Machines Corporation | Apparatus for journaling during software deployment and method therefor |
| US6516325B1 (en) * | 1999-11-16 | 2003-02-04 | Novell, Inc. | Virtual partition vector for a computer directory system |
| US6615274B1 (en) * | 1999-12-09 | 2003-09-02 | International Business Machines Corporation | Computer network control systems and methods |
| US6532455B1 (en) | 1999-12-22 | 2003-03-11 | Sequoia Software Corporation | Method and system for content-based document security, routing, and action execution |
| US6591277B2 (en) * | 1999-12-27 | 2003-07-08 | International Business Machines Corporation | Dynamic object persistence |
| US20020052979A1 (en) * | 2000-03-31 | 2002-05-02 | Jochen Kappel | Object to object communication system and method |
| US20020087341A1 (en) * | 2000-03-31 | 2002-07-04 | Jochen Kappel | Customer care and billing system |
| US20030040987A1 (en) * | 2000-05-19 | 2003-02-27 | Hudson K. Dean | Global travel reporting system and method |
| EP1174806A1 (en) * | 2000-07-21 | 2002-01-23 | Investigacion, Informatica Y Communicationes, S.L. | Professional teleconsulting method and system |
| US20020032793A1 (en) * | 2000-09-08 | 2002-03-14 | The Regents Of The University Of Michigan | Method and system for reconstructing a path taken by undesirable network traffic through a computer network from a source of the traffic |
| US20020032871A1 (en) * | 2000-09-08 | 2002-03-14 | The Regents Of The University Of Michigan | Method and system for detecting, tracking and blocking denial of service attacks over a computer network |
| US6785736B1 (en) | 2000-09-12 | 2004-08-31 | International Business Machines Corporation | Method and system for optimizing the network path of mobile programs |
| GB0027280D0 (en) * | 2000-11-08 | 2000-12-27 | Malcolm Peter | An information management system |
| WO2002044835A2 (en) * | 2000-11-28 | 2002-06-06 | Gingerich Gregory L | A method and system for software and hardware multiplicity |
| JP4476476B2 (ja) * | 2000-12-13 | 2010-06-09 | コニカミノルタホールディングス株式会社 | ワークフローシステム及びワークフローシステムにおけるクライアント |
| JP3740982B2 (ja) * | 2001-01-15 | 2006-02-01 | 日本電気株式会社 | ネットワークに接続されたホストコンピュータの死活監視方法 |
| US20020133624A1 (en) * | 2001-01-16 | 2002-09-19 | Tony Hashem | System and process for routing information in a data processing system |
| US6792544B2 (en) | 2001-04-03 | 2004-09-14 | Ge Financial Assurance Holdings, Inc. | Method and system for secure transmission of information |
| US7289966B2 (en) * | 2001-08-14 | 2007-10-30 | Norman Ken Ouchi | Method and system for adapting the execution of a workflow route |
| US20030046422A1 (en) * | 2001-09-04 | 2003-03-06 | Ravi Narayanan | Object-oriented routing |
| US20030182377A1 (en) * | 2002-02-12 | 2003-09-25 | Tabet Paul M. | Flexible routing engine |
| US8135843B2 (en) | 2002-03-22 | 2012-03-13 | Citrix Systems, Inc. | Methods and systems for providing access to an application |
| US7155578B2 (en) * | 2002-04-05 | 2006-12-26 | Genworth Financial, Inc. | Method and system for transferring files using file transfer protocol |
| US20080313282A1 (en) | 2002-09-10 | 2008-12-18 | Warila Bruce W | User interface, operating system and architecture |
| US20040133699A1 (en) * | 2002-12-04 | 2004-07-08 | Tony Hashem | System and method for performing data transfer |
| US7761923B2 (en) | 2004-03-01 | 2010-07-20 | Invensys Systems, Inc. | Process control methods and apparatus for intrusion detection, protection and network hardening |
| US7748032B2 (en) | 2004-09-30 | 2010-06-29 | Citrix Systems, Inc. | Method and apparatus for associating tickets in a ticket hierarchy |
| US7711835B2 (en) | 2004-09-30 | 2010-05-04 | Citrix Systems, Inc. | Method and apparatus for reducing disclosure of proprietary data in a networked environment |
| US8171479B2 (en) | 2004-09-30 | 2012-05-01 | Citrix Systems, Inc. | Method and apparatus for providing an aggregate view of enumerated system resources from various isolation layers |
| US8613048B2 (en) | 2004-09-30 | 2013-12-17 | Citrix Systems, Inc. | Method and apparatus for providing authorized remote access to application sessions |
| US8095940B2 (en) | 2005-09-19 | 2012-01-10 | Citrix Systems, Inc. | Method and system for locating and accessing resources |
| US7680758B2 (en) | 2004-09-30 | 2010-03-16 | Citrix Systems, Inc. | Method and apparatus for isolating execution of software applications |
| US8024568B2 (en) | 2005-01-28 | 2011-09-20 | Citrix Systems, Inc. | Method and system for verification of an endpoint security scan |
| US7565395B2 (en) * | 2005-02-01 | 2009-07-21 | Microsoft Corporation | Mechanism for preserving session state when using an access-limited buffer |
| US20070067393A1 (en) * | 2005-08-29 | 2007-03-22 | Sap Ag | System to automate provision of contributions to an electronic communication |
| US8131825B2 (en) | 2005-10-07 | 2012-03-06 | Citrix Systems, Inc. | Method and a system for responding locally to requests for file metadata associated with files stored remotely |
| US7779034B2 (en) | 2005-10-07 | 2010-08-17 | Citrix Systems, Inc. | Method and system for accessing a remote file in a directory structure associated with an application program executing locally |
| US20070174429A1 (en) | 2006-01-24 | 2007-07-26 | Citrix Systems, Inc. | Methods and servers for establishing a connection between a client system and a virtual machine hosting a requested computing environment |
| WO2007123753A2 (en) | 2006-03-30 | 2007-11-01 | Invensys Systems, Inc. | Digital data processing apparatus and methods for improving plant performance |
| US8533846B2 (en) | 2006-11-08 | 2013-09-10 | Citrix Systems, Inc. | Method and system for dynamically associating access rights with a resource |
| US8171483B2 (en) | 2007-10-20 | 2012-05-01 | Citrix Systems, Inc. | Method and system for communicating between isolation environments |
| US20110191494A1 (en) * | 2008-05-27 | 2011-08-04 | Turanyi Zoltan Richard | System and method for backwards compatible multi-access with proxy mobile internet protocol |
| CN104407518B (zh) | 2008-06-20 | 2017-05-31 | 因文西斯系统公司 | 对用于过程控制的实际和仿真设施进行交互的系统和方法 |
| US20090326999A1 (en) * | 2008-06-30 | 2009-12-31 | Wachovia Corporation | Innovation development tracking and management |
| US8090797B2 (en) | 2009-05-02 | 2012-01-03 | Citrix Systems, Inc. | Methods and systems for launching applications into existing isolation environments |
| US8463964B2 (en) | 2009-05-29 | 2013-06-11 | Invensys Systems, Inc. | Methods and apparatus for control configuration with enhanced change-tracking |
| US8127060B2 (en) | 2009-05-29 | 2012-02-28 | Invensys Systems, Inc | Methods and apparatus for control configuration with control objects that are fieldbus protocol-aware |
| TW201137772A (en) * | 2010-04-23 | 2011-11-01 | Askey Computer Corp | Signature-verification operation processing method and system and computer readable record medium and program storing signature-verification operation programs |
| US11153400B1 (en) | 2019-06-04 | 2021-10-19 | Thomas Layne Bascom | Federation broker system and method for coordinating discovery, interoperability, connections and correspondence among networked resources |
| US11741541B2 (en) * | 2020-12-07 | 2023-08-29 | TallyX, Inc. | Computer network in which digital tokens are created and routed to a destination node according to rules configured in each node of the computer network |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4503499A (en) * | 1982-09-14 | 1985-03-05 | Eaton Corporation | Controlled work flow system |
| US4648061A (en) * | 1982-11-09 | 1987-03-03 | Machines Corporation, A Corporation Of New York | Electronic document distribution network with dynamic document interchange protocol generation |
| JPH063934B2 (ja) * | 1986-11-25 | 1994-01-12 | 株式会社日立製作所 | 自動催促方式 |
| US4932026A (en) * | 1986-12-19 | 1990-06-05 | Wang Laboratories, Inc. | Apparatus for distributing data processing across a plurality of loci of control |
| US4820167A (en) * | 1987-01-14 | 1989-04-11 | Nobles Anthony A | Electronic school teaching system |
| DE3889173T2 (de) * | 1987-09-08 | 1994-11-10 | Wang Laboratories | Verfahren und Vorrichtung zur Zirkulation von elektronischer Post. |
| US4885684A (en) * | 1987-12-07 | 1989-12-05 | International Business Machines Corporation | Method for compiling a master task definition data set for defining the logical data flow of a distributed processing network |
| US5051891A (en) * | 1987-12-23 | 1991-09-24 | International Business Machines Corporation | Method to manage transfer of ownership of electronic documents stored in an interactive information handling system |
| JPH01195568A (ja) * | 1988-01-29 | 1989-08-07 | Hitachi Ltd | 電子化文書編集制御方式 |
| US4962532A (en) * | 1988-12-22 | 1990-10-09 | Ibm Corporation | Method for providing notification of classified electronic message delivery restriction |
-
1991
- 1991-05-07 CA CA002041992A patent/CA2041992A1/en not_active Abandoned
- 1991-05-16 EP EP91401268A patent/EP0457684A2/en not_active Withdrawn
- 1991-05-17 JP JP3228231A patent/JPH0683784A/ja active Pending
-
1993
- 1993-03-04 US US08/026,624 patent/US5701484A/en not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08249290A (ja) * | 1995-03-10 | 1996-09-27 | Hitachi Ltd | 分散システム |
Also Published As
| Publication number | Publication date |
|---|---|
| EP0457684A3 (ja) | 1994-02-09 |
| EP0457684A2 (en) | 1991-11-21 |
| CA2041992A1 (en) | 1991-11-19 |
| US5701484A (en) | 1997-12-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH0683784A (ja) | 分散型計算システムにおいて動作経路上にオブジェクトを経路指定する方法及び装置 | |
| EP0788631B1 (en) | Distributed work flow management | |
| US6065009A (en) | Events as activities in process models of workflow management systems | |
| AU2001249273B2 (en) | Method and system for top-down business process definition and execution | |
| JP2721672B2 (ja) | データ処理を複数の制御位置にわたって分散させるための装置 | |
| US6014673A (en) | Simultaneous use of database and durable store in work flow and process flow systems | |
| US6122633A (en) | Subscription within workflow management systems | |
| US6820118B1 (en) | Method and system for providing a linkage between systems management systems and applications | |
| US9513874B2 (en) | Enterprise computing platform with support for editing documents via logical views | |
| US20030195789A1 (en) | Method for incorporating human-based activities in business process models | |
| JP2011175683A (ja) | コンピュータが実行可能なワークフロー制御システム | |
| AU2001249273A1 (en) | Method and system for top-down business process definition and execution | |
| US9311144B1 (en) | Processing virtual transactions of a workflow in atomic manner in a workflow management computer system | |
| KR20130116165A (ko) | 통합된 워크플로우와 데이터베이스 트랜잭션 | |
| CA2253345C (en) | Relational database compiled/stored on a memory structure | |
| EP0438020B1 (en) | Method and system for automatically controlling the distribution of data objects | |
| EP1385110A2 (en) | Method and system for managing long running transactions | |
| Eder et al. | A workflow system based on active databases | |
| CN101278309A (zh) | 自动管理异构环境中的it资源的系统与方法 | |
| Altmann et al. | An environment for cooperative software development realization and implications | |
| Eder et al. | Workflow Management and Databases | |
| Meszaros et al. | A pattern language for workflow systems | |
| JP4006167B2 (ja) | ワークフロー管理システム | |
| Cichocki | Migrating workflows and their transactional properties | |
| Fitzmaurice | Form-centered workflow automation using an agent framework |