JP3090435U - 企業間プロセスを作成し、実行し、保守するためのシステム - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】異なるシステム間でビジネスプロセスを実行す
るシステムを提供する。 【解決手段】複数のサイト１０１〜１０３はインターネ
ット１０４によって結合され事業用システム１００を構
成している。システム１００において、各サイト１０１
〜１０３の内部プロセスは連係した情報交換シーケンス
によってそれぞれの内部プロセスに結合される。これに
より、サイト１０１〜１０３は供給チェーンの３つの要
素である顧客、製造者、依託倉庫とすることができる。

Description

【考案の詳細な説明】

【０００１】

【産業上の利用分野】

本考案は、一般的に情報システムに関連し、特に、分散情報システム間の作業 の連係（調和した動作）を可能にするシステムに関連する。

【０００２】

【従来の技術】

独立した単一の企業（事業）体から複数の相互依存型の企業体への、最近の企 業組織の構造の変化は、単一のメインフレームから、パーソナルコンピュータ及 びワークステーションからなる分散型ネットワークへのコンピュータシステムに おける類似の発展を反映している。コンピュータネットワークは、分散したサイ ト間で情報をやり取りしたり、作業を実行するのに極めて効率が良いので、現代 のネットワークは、まぎれもなくこの技術革新の有益な産物である。例えば、買 い物を注文したり、それを確認するというような日常的な作業を、共有コンピュ ータネットワークによって、既存のシステム間で自動的に実行することができる 。しかしながら、この技術には多くの欠点が存在するために、企業内用途用の従 来のネットワーク技術の十分な開発が妨げられてきた。

【０００３】 ビジネスパートナーとの間で共有ネットワークを使用することによって現れる 最も切迫した問題は、（１）相手（パートナー）のコンピュータシステムが統一 されていないこと、（２）相手のシステムが使用するデータが統一されていない こと、（３）システム間の通信セキュリティ及び信頼性、及び（４）パートナー 間の法律的、組織的、及び文化的な境界、である。

【０００４】 システムの不統一に関しては、企業（組織体）は、互いに互換性のないオペレ ーティングシステム、ミドルウエアシステム、及びソフトウエアアプリケーショ ンをしばしば組み合わせて使用している。広く普及したミドルウエアは、現在も 配備されつつあるが、先導的な陣営間の相互運用は、依然として、十分に規定さ れなければならないものである。特に、解決が困難なのはアプリケーションレベ ルでの違いであり、それは、基本的なものであって、長期にわたって解決される べき課題として存在し続けるであろう。

【０００５】 データの不統一という第２の問題に関しては、異なるアプリケーション、及び それらのアプリケーションのユーザは、しばしば、同じタスクを実行するのに、 異なる方法で情報を表現し、または、異なる種類の情報を使用する。これらの違 いは、アプリケーション及びそれらのユーザが異なる企業間に分散している場合 に、特に重大なものとなりうる。情報における関連する構文上及び意味上の相違 を埋めるためには、変換能力並びに中間オブジェクトを組み合わせたものが必要 となる。

【０００６】 通信セキュリティ及び信頼性という第３の問題については、ビジネスネットワ ークのシステム間のどの対話にも、信頼性があり、かつ安全な通信経路が参加者 間に存在することが必要である。安全性に関する問題は、インターネットが通信 経路内のリンクとして使用される場合に、特に重大である。なぜなら、このメデ ィアは、盗聴や他の形態のセキュリティ攻撃を受けやすいからである。

【０００７】 第４の問題に関しては、複数のパートナー間のビジネス（業務）プロセスを自 動化する努力を行うことよって、複数の組織に分散したプロジェクトの管理に関 連する技術的でない多くの障害を克服しなければならない。これらの課題には、 プロジェクトの優先順位とリソースの割り当てにおけるミスマッチ、言葉の違い による障壁、時間帯の違い、及び会社と政府の両方による規制が含まれる。これ らの課題によって、達成可能な協働レベルが制限される。従って、技術的な解決 策は、この解決策を実施するために必要となる、相互の約束事の範囲及び複雑さ を最小限にすることに焦点を合わせたものでなければならない。

【０００８】 現在のところ、相互依存プロセスを１つのコンピュータシステムを超えて、従 来のコンピュータネットワークリソースによって接続された他のシステムに拡張 するための方法として、少なくとも５つの方法が知られている。第１は、複数の コンピュータシステムのユーザが、電話、ファックス、または他のメディアを介 して互いに情報をやり取りする手動的なアプローチである。やり取りされた情報 は、次に、人手によって、それぞれのコンピュータシステムに入力される。この 手動的なアプローチは、自動化における差異を埋めるために使用することができ るものであるが、これは明らかに、信頼性があり、かつ効率の良い方法でパート ナー間のプロセスを堅固に結合する能力を制限する。

【０００９】 第２のアプローチ（これは、自家製のメインフレームアプリケーションの時代 に生まれたものであるが）は、電子データ交換（ＥＤＩ）として知られている。 ＥＤＩは、広い意味で定義された用語であるが、最も頻繁には、特定の組の標準 、技術（付加価値通信網、ダイレクトダイアルアップ、ソフトウエアマッピング （mapping software））、及び会社間の電子データ交換用に使用される実務慣行 を指している。ＥＤＩにおいては、ビジネス情報（例えば、買い物の注文）を収 集したものを、１つのアプリケーションシステムから読み出して、中間フォーマ ットにマッピングし、ＶＡＮ（付加価値通信網）を介してパートナーに送信し、 パートナーがパートナーのアプリケーションに適したフォーマットにマッピング して、パートナーのアプリケーションに読み込むことができる。代替的には、ダ イレクトダイアリング（direct dialing）をＶＡＮの代わりに使用することがで きる。しかしながら、ＥＤＩは、一般的にバッチ指向であり、広範にわたるフォ ーマットのカスタマイズが必要であり、プロセスを支援するものではない。

【００１０】 ビジネス要件がＥＤＩモデルに適さないときに使用される第３のアプローチは 、ユーザの仕様に合わせて設計され、実装されたカスタムシステムを使用するこ とである。このアプローチは、コストが高く、ネットワークプログラミング及び システムインテグレーション作業の組み合わせを必要とし、特定のユーザのため だけの特定の目的を遂行するものである。さらに、これは、柔軟性がなく、変更 することが困難である。

【００１１】 最近、技術における２つのトレンドが、アプリケーションシステムが相互に関 わり合うことができる方法を根本的に変えた。その結果、ＥＤＩの適用だけでな く、第４及び第５のアプローチを上記の３つに加えなければならない。第１のト レンドは、ネットワークインフラストラクチャの急速な拡大である。このインフ ラストラクチャの最も明白な部分は、インターネットによって提供されるいたる ところに見られる接続性である。ほとんどすべての組織が、インターネットに接 続されている（あるいは、まもなく接続されるであろう）。この接続性には、分 散アプリケーションの取扱いをより簡単にし、ソフトウエアコンポーネントの非 常に高い相互運用性を約束する分散オブジェクトフレームワーク及びメッセージ 指向ミドルウエアのような、ミドルウエア技術の拡張セットとサービスが結合さ れる。

【００１２】 第２のトレンドは、会社によって使用される企業向けアプリケーションシステ ムにおける進歩に関係する。これらのシステムにおける重要な進歩は、オブジェ クトインターフェースの進展、及びワークフロー／プロセスのモデリング能力の 進展を含む。オブジェクトインターフェースは、アプリケーションに対して情報 をやり取りする方法において、ＳＱＬ（Structured Query Language）、または ファイルベースのインターフェースのような従来の方法よりも、より柔軟で、か つ負担の少ない方法を提供する。現在、いくつかのアプリケーションベンダーが 、異なるアプリケーションモジュール間においてワークフローを設計し実装する 能力を提供している。この能力によって、会社は、自身のビジネスプロセスによ り容易に注力することができ、また、ビジネスパートナーのプロセスに接続する 必要性がより明確になる。

【００１３】 これらのトレンド、及びビジネスの相互依存を拡張するための第４のアプロー チの最も明らかな効果は、ビジネス対ビジネスの対話のためにワールドワイドウ ェブ（ＷＷＷ）を使用することである。このモデルでは、ある業務（ビジネス） の従業員が、標準的なウェブブラウザを使用することによって、カタログまたは 出荷情報のような他の会社の業務アプリケーションに属する情報にアクセスする 。しかしながら、このアプローチは、異なる組織のアプリケーションシステム間 で依存した対話を必要とする、多くの拡張された事業プロセスには適さない。

【００１４】 第５のアプローチは、論理的に統合されたハイパフォーマンスの分散アプリケ ーションを作成することを可能にする新しいミドルウエア技術を活用する。同じ 技術を、異なるベンダーからのアプリケーションの組の間、及び、異なるビジネ スにおけるシステム間での相互運用を提供するために使用することができるが、 重大な問題によって実現性が制限される。第１に、ミドルウエア技術を使用する ことは、かなりのプログラミングスキルと、セキュリティ、同期化、及び他のネ ットワークに関する問題に対する専門の知識とが要求されるプログラミングタス クである。そのような努力にかけるコストは、分散アプリケーションに関わるベ ンダーに対しては正当化することができようが、特定の拡張された事業プロセス に関与することを望む会社が、一から分散システムを構築するために必要な資本 を投入する可能性は低い。

【００１５】 最後に、インターネットＥＤＩと呼ばれるＥＤＩの適用には、上述した従来の ＥＤＩによるアプローチをインターネット伝送媒体に移行することを試みる多く の方法が実際にある。これらの方法は、付加価値通信網（ＶＡＮ）に関連する高 い通信コストを低減したいという要望によって動機付けをされている。実質的に は、これらの方法は、従来のＥＤＩとほとんど違いがない。メッセージフォーマ ット、マッピングソフトウエア、さらに構造の包み（enveloping construct）さ えも同じものを利用する。しかしながら、オープンネットワークを使用すること は、以前は、ＶＡＮサービスの一部分であった、特別なセキュリティ、信頼性、 及び検査能力を必要とする。さらに、オープンネットワーク構成におけるこれら の追加サービスの使用は、情報交換の終端においてソフトウエアによってサポー トされなければならない。従って、インターネットＥＤＩは、プロセスサポート の欠如、扱いにくい表現形式、及び新しい実践方式にかみ合わない統合モデルの ような、重大な制限を受ける。

【００１６】

【考案が解決しようとする課題】 上記アプローチでは、本質的に異なるシステム間に、安全でかつ保守可能であ る複雑な自動化プロセスを実装したいという高まる要求に応えることはできない 。従って、拡張されたビジネスの相互依存性を設計して制御するためのシステム が必要とされている。すなわち、（１）既存のビジネスアプリケーションシステ ム間におけるピアツーピアの通信（対話）に特に焦点をおき、（２）安全で信頼 性のある通信をサポートし、（３）カスタムソフトウエアの開発を最小限にし、 （４）統一されていないデータ表現形式を取り扱う機能を有し、（５）企業向け （事業用）アプリケーションの内外に及ぶ複雑なプロセスをサポートする能力を 有するシステムである。

【００１７】

【課題を解決するための手段】

本考案は、企業間プロセスを生成し、実行し、及び保守するためのシステムで ある。企業間プロセスは、組織の境界を横断して、また、統一されていない情報 システム間において、これらのプロセスを自動化するための特別の用意を備えた 分散情報システム間の、共有（共用）化され自動化されたビジネスプロセスまた はワークフローである。

【００１８】 このシステムは、共通の能力を備えたサイトと呼ばれる複数の独立した通信サ ブシステムから構成される。各サイトは、共用プロセス定義を表現し、実行する ための共通の手段を有するサーバーを備えている。これらのサイトは、システム 間の共用プロセスを実行している間、協力して動作する。プロセスの実行には、 各サイトに限定された一連の制御されたアクションに結合される、サイト間の連 係したメッセージ交換が含まれる。さらに、各サイトは、システム間プロセス、 及び内部プロセスをサーバー上で実行するために、たくさんのアプリケーション プログラム及びオペレーティングシステムの中の任意の１つを備えることができ る。

【００１９】 本考案のシステムにおいては、自動化されたシステム間プロセスは、２レベル のプロセスモデルで表される。トップレベル、すなわち共用（パブリック）プロ セス定義／モジュールは、独立したサイト（典型的には、それぞれが、組織また は事業単位を表す）間の相互作用（interaction、対話）を捕捉する。相互作用 は、ノードによって共用プロセス定義内で指定される１つのサイトが、他のサイ トに既知のタイプのメッセージを送信する通信イベントを備える。この場合には 、共用プロセス定義は、１組のサイト間の相互依存通信イベントの論理的なグル ープ分け、または有向グラフである。各定義は、参加サイト間における一連の有 効な通信イベントの組を規定する。

【００２０】 任意の共用プロセス定義に関連して、１組のより低レベルの、または、専用（ プライベート）のプロセス定義もしくはモジュールがある。個別の専用プロセス 定義は、共用プロセスの各ノードに結合される。この専用プロセス定義は、特定 の共用プロセスノードが実行されるときに、サイトで実行可能な、１組の可能性 のあるローカルなアクションを規定する。好ましい実施態様では、専用プロセス 定義は、ノードまたはサイトに固有の動作パラメータ、及びソフトウエアアプリ ケーションの相互作用のような構成に関して定義される。

【００２１】

【実施例】

図１に、拡張された事業用システム１００の好ましい実施態様を示す。本考案 の好ましい実施態様による拡張された事業用システム１００は、好ましくは、通 信ネットワーク１０４によって結合された個別の組織に設置された、複数のサイ ト１０１、１０２、及び１０３から構成される。これらのサイト１０１〜１０３ は拡張された事業用システム１００を形成し、このシステム１００において、各 サイト１０１〜１０３の内部プロセスは、連係した情報交換シーケンスによって 、他のサイト１０１〜１０３の内部プロセスに結合される。例えば、サイト１０ １〜１０３は、供給チェーンの３つの要素、すなわち、供給者、製造者及び顧客 を含む企業とすることができる。しかしながら、当業者には、サイト１０１〜１ ０３を、任意の数のサイトが存在可能な任意のタイプのビジネス単位または機能 に対するものとすることができ、３つのサイト１０１〜１０３は、一例として提 供されただけのものであるということが理解されよう。

【００２２】 これらのサイト１０１〜１０３の各々は、制御区域を表しており、情報を記憶 し、その情報を検索して、変更するためのロジックを備えた１組のアプリケーシ ョンシステムによって構成される。例示のアプリケーションは、ＥＲＰ（事業リ ソースプランニング、Enterprise Resource Planning）アプリケーションの組、 製品データ管理（ＰＤＭ）システム、物流アプリケーション、及び先進のプラン ニングシステム（ＡＰＳ）を備える。

【００２３】 本考案の動作は、各サイト１０１〜１０３内の連係した一連のアクションを含 んでおり、これらのサイトは、異なるサイト１０１〜１０３間の連係した一連の 情報交換に関連付けられている。各サイト１０１〜１０３内で実行されるアクシ ョンには、主として、サイト１０１〜１０３に関連するアプリケーションに対す る情報のやり取りが含まれる。サイト１０１〜１０３間の各情報交換の前に、送 信サイト内で一連のアクションが起こり、該情報交換の後に、受信サイト内で別 の一連のアクションが起こる。従って、これらのサイト固有の一連のアクション は、１組の情報交換を、単一の連係した一連の相互作用（対話）に結合するコネ クション（結合子）として機能する。

【００２４】 可能性のある一連のローカルアクション、及びサイト間交換は、プロセス定義 言語によって規定される。この言語は、複雑な分岐及びループ論理を可能にし、 ローカルアクションのシーケンスとサイト間交換との間の関係を制御（支配）す る制約を取り込むことができる。さらに明確に言うと、好ましい実施態様のプロ セス定義言語は、ノードと、（図２に示すような、そして、以下で説明する）有 向グラフを作成するための特定の命令及びロジックに結合されたアーク要素（ア ークエレメント）とを備える。単一の発信元ノード２０５〜２２５及び単一の送 信先ノード２０５〜２２５が、各アーク要素を定義する。各ノード２０５〜２２ ５は、１組の入力アーク、及びそれを先行するノード２０５〜２２５に結合する 関連ロジック、さらに、１組の出力アーク、及びそれを後のノード２０５〜２２ ５に結合する関連ロジックとを備える。所定のノード２０５〜２２５に対する入 力アーク間の関係は、論理文によって定義されるが、この論理文は、場合によっ ては、入れ子になった結合及び分離を行う命題結合記号（propositional connec tive)を含み、各アークは、個別の命題シンボルによって表される。所定のノー ドに対する出力アークは、等価な形式の個別の論理文によって関連付けられる。 ノード２０１は、入力アークをもたず、イニシエータ（開始）ノードと呼ばれる 。ノード２９９は、出力アークをもたず、ターミナル（終端）ノードと呼ばれる 。

【００２５】 好ましい実施態様では、サイト間の情報交換の収集と、サイト固有のアクショ ンシーケンスを表すために、２レベルのプロセスモデルが使用される。共用プロ セス定義またはモジュール１１６ａが、すべてのサイト間の情報交換の間の関係 を規定する。共用プロセス定義１１６ａ内の特定のノードに対する、単一のサイ ト１０１、１０２、１０３内の可能性のあるアクションシーケンスは、専用プロ セス定義またはモジュール１１８ａ、１１８ｂ、１１８ｃによって規定される。 共用プロセス定義及び専用プロセス定義１１６ａ、１１８ａ、１１８ｂ、１１８ ｃは、いずれも、ノード２０５〜２２５及びアーク要素に対して特定の解釈を有 するプロセス定義言語の最上部で構築される。共用プロセス定義１１６ａにおい て、各ノード要素は、特定のサイト１０１、１０２、１０３を表し、各アーク要 素は、アークの送信先ノードによって表されるサイトに対するアークの発信元ノ ードによって表されるサイト１０１、１０２、１０３から送信される特定の情報 内容を有するメッセージを表す。共用プロセスに対するグラフは、開始ノードを １つだけ含むことができる。この場合、共用プロセス定義１１６ａは、特定の目 的のために、１組のサイト１０１〜１０３の間で、「誰が、いつ、何をするか」 を規定するものである。各共用プロセス定義１１６ａは、参加サイト１０１、１ ０２、１０３の間で、１組の有効な通信イベントのシーケンスを規定する。より 詳しくは、同じ共用プロセス定義１１６ａが、この共用プロセス定義１１６ａ内 のアクションを有する各サイト１０１、１０２、１０３に与えられる。図１に示 すように、各サイト１０１、１０２、１０３は、各サイト間プロセスに対して１ つずつ、１つまたは複数の共用プロセス定義１１６ａを有することができる。専 用プロセス定義１１８ａ、１１８ｂ、１１８ｃにおいて、ノード要素は、特定の プログラムに基づいたアクションを表し、アーク要素は、これらのアクションが 実行される順序を規定する。専用プロセス定義１１８ａ、１１８ｂ、１１８ｃは 、サイト１０１〜１０３がどのようにして受信メッセージを処理して、出力メッ セージを構築するかを規定する。さらに、専用プロセス定義１１８ａ、１１８ｂ 、１１８ｃは、共用プロセス定義１１６ａのノード内で起こることを規定する。 従って、専用プロセス定義１１８ａ、１１８ｂ、１１８ｃは、この専用プロセス 定義１１８ａ、１１８ｂ、１１８ｃが割り当てられ、または、動作する特定のサ イト１０１、１０２、１０３に適合したルーチン及びプロセスを備える。さらに 詳しくは、専用プロセス定義１１８ａ、１１８ｂ、１１８ｃは、それが割り当て られるサイトのオペレーティングシステム、アプリケーション、及びリソースを 使用して相互作用をするために設計される。従って、図１に示すように、各専用 プロセス定義１１８ａ、１１８ｂ、１１８ｃは、各サイト１０１、１０２、１０ ３に対するものとは異なる。それにも関わらず、サイト１０１、１０２、１０３ が類似して構成される（例えば、同じオペレーティングシステム、アプリケーシ ョン、及びリソースを有するように構成される）場合には、この専用プロセス定 義１１８ａ、１１８ｂ、１１８ｃを使用または共用することができる。各サイト １０１、１０２、１０３は、また、図１に示すように、複数の専用プロセス定義 １１８ａ、１１８ｂ、１１８ｃを備えることができるということが、当業者には 理解されよう。この複数の専用プロセス定義１１８ａ、１１８ｂ、１１８ｃは、 ある共用プロセス定義１１６ａに対するものとすることも、また、それとは異な る共用プロセス定義１１６ａに対するものとすることも可能である。

【００２６】 この好ましい実施態様は、構造及び動作が制限されたオブジェクトとして、サ イト１０１、１０２及び１０３間を送信されるメッセージに含まれる情報をモデ ル化する。これらのオブジェクトはデータの入れ物であって、その可能性のある 内容が、オブジェクト定義１２０ａ、１２０ｂ、１２０ｃによって規定される。 好ましい実施態様では、オブジェクト定義１２０ａ、１２０ｂ、１２０ｃは、Ｘ ＭＬ（拡張マークアップ言語）ＤＴＤ（文書型定義）の形態を取る。この定義は 、そのタイプのすべてのオブジェクトの語義的及び文法的型式を規定する。オブ ジェクト定義１２０ａ、１２０ｂ、１２０ｃは、共用プロセス定義、及び専用プ ロセス定義の両方によって参照される。

【００２７】 図２に、典型的な共用プロセス定義２００を示す。この共用プロセス定義２０ ０は、流れ図として図で示されている。図２は、サイト１０１〜１０３間で起こ りうる１組の相互作用を規定する共用プロセス定義２００を示している。プロセ ス定義２００は、２０５から２２５までの１組のノード、及び、２３０から２５ ０までの１組の通信イベントを含む。各ノードは、特定のサイト１０１〜１０３ に対応し、共用プロセス定義２００の各ノード２０５〜２２５に関連して、専用 プロセス定義１１８ａ、１１８ｂ、１１８ｃがある。図３に、ノード２１０に関 連する典型的な専用プロセス定義３００を示す。

【００２８】 共用プロセス定義２００において、あるノードを他のノードに接続する各通信 イベント２３０〜２５０は、既知のオブジェクトタイプのメッセージの交換を表 す。例えば、既知のオブジェクトは、購入発注オブジェクト、確認メッセージオ ブジェクト等のような従来のタイプのビジネスオブジェクトのうちの任意の１つ とすることができる。そのようなオブジェクト１２０ａ、１２０ｂ、１２０ｃは 、オブジェクト定義１２０ａ、１２０ｂ、１２０ｃにおいて定義され、それによ って、各サイト１０１、１０２、１０３が、共用レベルまたは専用レベルのいず れかのレベルでオブジェクトを処理する必要に応じて、オブジェクト定義１２０ ａ、１２０ｂ、１２０ｃを使用することができる。すなわち、共用プロセス定義 ２００は、図１に示すように、サイト１０１〜１０３間の相互依存通信イベント ２３０〜２５０の論理的なグループ分け、または有向グラフである。このグルー プ分けは、参加サイト１０１、１０２、１０３の間の１組の有効な通信イベント のシーケンスを規定する。具体的には、共用プロセス定義２００は、通信イベン ト２３０において、サイト１０１からサイト１０２に送られる購入発注を記述す る。この購入発注は、ノード２０５に関連するサイト１０１の専用プロセスによ って生成される。ノード２１０は、分岐ノードであり、２つの通信イベント２３ ５及び２４０が、そのノードで生成される。指定された分岐条件に依存して、そ れらのイベントのうちの１つのイベント、または両方のイベントが発生する。こ れらの２つのイベントがトリガされる条件は、共用プロセス定義２００によって は指示されない。なぜなら、それらを知っているのはサイト１０２のみだからで ある。これらの条件は、ノード２１０、従って、サイト１０２に関連する専用プ ロセス定義１１８ｂに含まれている。専用プロセス定義１１８ｂは、共用プロセ ス定義１１６ａのインスタンスに相当する１組の専用プロセス定義とすることが できるということが、当業者には、また、理解されよう。

【００２９】 イベント２３５及び／又は２４０の発生により、直後に続くノード（１つまた は２つのノード）が実行され、図の下方に向かって実行が進行する。ノード２２ ５は、それに接続した組の１つまたは全てのイベントを待つことができる分岐結 合ノードである。ノード２２５の実行に続いて、共用プロセスは終端（ターミナ ル）２９９で終了する。

【００３０】 共用プロセス定義２００の２０５から２２５の各ノードに関連して、専用プロ セス定義１１８ａ、１１８ｂ、１１８ｃがある。例えば、図３に、ノード２１０ に関連する専用プロセス定義３００を示す。共用プロセス定義２００とは異なり 、専用プロセス定義３００の内容は、対応するサイト（この場合、サイト１０２ ）によってのみ、決定され、かつ認識される。専用プロセス定義３００は、所定 のロジックに従って制御される多くのアクション（３０５から３３０）を含む。 起こりうるアクションには、外部のビジネスアプリケーション通信、スクリプト 実行、ユーザ通知と承認、時間遅れ、出力オブジェクト仕様、及びサブプロセス 実行が含まれる。専用プロセス定義３００のすべてのインスタンスは、通信イベ ント２３０に含まれるオブジェクトタイプ「購入発注」にアクセスすることがで きる。専用プロセス定義３００のどのアクションも、このオブジェクトを参照す ることができる。専用プロセス定義３００は、通信イベント２３５及び２４０に それぞれ対応して、「確認応答（Acknowledgement）」または、「購入発注」の タイプのいずれかのオブジェクトを生成しなければならない。

【００３１】 図３には、専用プロセス定義３００の典型的な１実施態様が示されている。専 用プロセス定義３００は、通信イベント２３０が完了した後に実行するイニシエ ータアクション３０１で始まる。このプロセスは、オブジェクトが、サイト１０ １、１０２、１０３に転送または受信されると、通信イベントに続くノードに対 応する専用定義が自動的に開始するような、種々の他の専用プロセス定義に対す るものと類似しているということが、当業者には理解されよう。専用プロセス３ ００は、アクション３０５を続行する。アクション３０５の実行は、受信した購 入発注に相当する情報ブロックを、ビジネスアプリケーション１１３に送ること を伴う。アクション３０５の実行が完了すると、アクション３１０に移る。アク ション３１０は、ビジネスアプリケーション１１４に照会して、通信イベント２ ３０の購入発注に関連する品物の在庫があるか、あるいは外部に委託されている かを決定することを伴う。この照会の結果は、専用プロセス３００に関連する１ 組の変数のうちの「OUTSOURCED」という名前の変数に入れられる。アクション３ １５が、アクション３１０に続いて実行される。アクション３１５には、スクリ プトアクション内での、OUTSOURCEDの値についてのIF-THEN-ELSEの条件テストが 含まれる。この条件テストの結果によって、アクション３１５の完了に続いて、 経路Ａまたは経路Ｂのどちらをとるかが決定される。経路Ａをとると、アクショ ン３２０に進む。アクション３２０は、「確認応答」のタイプのオブジェクトを 構築し、専用プロセスの出力として指定することを伴う。経路Ｂをとると、アク ション３２５に進む。アクション３２５は、「購入発注」のタイプのオブジェク トを構築し、専用プロセスの出力として指定することを伴う。経路ＡとＢはアク ション３３０で終了する。アクション３３０は、稼働中のプロセスに関連する所 定のステータス情報を、電子メールによって指定されたユーザに通知することを 伴う。この情報は、購入発注の特徴（指標）の識別と、ビジネスアプリケーショ ン照会の結果を含むものである。専用プロセスは、アクション３３０の実行に続 いて終了し、制御は、共用プロセスレベルに戻る。このような専用定義を使用す ることは、特に有利である。なぜなら、これによってサイト間プロセスの一様な 制御及び調整が提供されるとともに、特定のサイトのコントローラが、特定のサ イトのパラメータ、リソース、及び他の制約に従う任意の方法で、専用定義を実 施することを可能にする、専用定義の使用による最大限の柔軟性が許容されるか らである。

【００３２】 好ましい実施態様の各サイトは、共用プロセス及び専用プロセスの設計、実装 、及び保守をサポートするコンポーネントと、これらのプロセスの実行をサポー トするランタイムコンポーネントの組み合わせを備える。図４に、例としてのサ イト１０２の好ましい構成を示す。

【００３３】 標準的なサイト１０２は、単一のサーバ４８０と、ネットワーク４０９を介し てサーバと通信する１つまたは複数のクライアント４６０、４７０から構成され る。クライアント４６０及び４７０、サーバ４８０は、別々のホストコンピュー タ上で動作する。クライアント４６０及び４７０は、グラフィックユーザインタ ーフェース（ＧＵＩ）４６５及び４７５をそれぞれ備えている。さらに、サーバ ４８０は、データベース４１０、アプリケーション４２０及び４３０を備えてい るか、または、それらにアクセスすることができる。好ましい実施態様では、デ ータベース４１０は、サーバ４８０が置かれているホストコンピュータとは別の ホストコンピュータに置かれる。クライアント４６０及び４７０、サーバ４８０ は、指定された従来の通信プロトコルに従って、ネットワーク４０９を介して対 話することによって、関連する情報の共通の表現を共有する。そのような共有さ れた情報の表現は、共用プロセス定義及び専用プロセス定義、オブジェクト定義 、プロセス実行履歴、並びに、サイトが対話する他のサイトに関する情報を含む 。ユーザ４４０及び４５０は、クライアントのＧＵＩ４６５及び４７５を介して サイト１０２と対話して、上記のように範囲を定められた共有された情報の表現 を目視し、生成し、編集し、及び管理する。例えば、ユーザ４４０及び４５０は 、共用プロセス２００と専用プロセス３００のグラフィック表現をＧＵＩ４６５ 及び４７５上で見て、編集することができる。図８及び図９に、図２及び図３に それぞれ関連して説明した共用プロセス定義及び専用プロセス定義に相当するＧ ＵＩの１画面を示す。

【００３４】 好ましい実施態様のサーバ４８０は、中間層マネージャセット４８２、実行エ ンジン４８４、伝送マネージャ（トランスポータ）４８６、及びアダプター４８ ８、４８９から構成される。中間層マネージャセット４８２は、ネットワーク４ ０９、エンジン４８４、及びデータベース４１０間の情報のアクセスとその流れ を制御する。さらに、それは、関連するアプリケーションロジックを実施し、こ れらの構成要素の間の情報の一貫性を保証する。ネットワーク４０９に関しては 、マネージャセット４８２は、同時に動作しているクライアントとサーバ４８０ の他の構成要素からの情報に対するアクセスを仲介する。

【００３５】 以下に詳細に説明するように、共用プロセス２００と専用プロセス３００のイ ンストールには、ユーザ４４０または４５０の事前の承認が必要である。この承 認が受け入れられた場合には、それは、適正なユーザによって、それぞれのＧＵ Ｉを介してクライアント４６０または４７０に入力される。次に、ローカルなイ ンストール信号が、ネットワーク４０９を介してサーバ４８０に中継される。受 信信号に従って動作するマネージャセット４８２は、エンジン４８４へのプロセ ス定義のインストールを開始する。インストールの間、実行エンジン４８４は、 それが受信するプロセス定義を、データベース４１０に保存されている実行可能 な状態マシンに転送する。この転送は、目的のサイトを含むアークに接続された すべてのノードを共用プロセス定義から抜き取る。結果とし生じた状態マシンは 、単一のサイトが、元の共用プロセスの実行に参加するのに必要なすべての情報 を含んでいる。インストールが完了すると、マネージャセット４８２が、データ ベース４１０に記憶された、または、クライアント４６０及び４７０から受け取 ったプロセスを実行するために必要な追加の情報をエンジン４８４に与える。共 有データの持続性が、データベース４１０との通信によって維持される。

【００３６】 共用プロセス定義２００及び専用プロセス定義３００のインストールが完了す ると、エンジン４８４がそれらの実行を制御する。実行中、実行エンジン４８４ は、２つの重要な作業、すなわち、伝送マネージャ４８６を介する他のサイトと の入出力通信と、アダプター４８８及び４８９を介するアプリケーション４２０ 及び４３０との対話を管理する。エンジン４８４は、また、マネージャセット４ ８２を介して、ユーザ４４０及び４５０に対するメッセージの送受信、及びデー タベース４１０へのログ情報の格納を含むいくつかの補助的な作業を管理する。

【００３７】 定義２００のような共用プロセス定義の実行中、伝送マネージャ４８６が、イ ンターネット１０４に対する通信を管理する。例えば、共用プロセス定義２００ は、サイト１０２による購入発注２３０及び確認応答２４５の受信、並びに確認 応答２３５及び購入発注２４０の送信を予期する。この機能においては、マネー ジャ４８６は、（それが使用するサービスの属性に基づいて）再試行と確認応答 のロジックを処理するのが好ましい。メッセージは、任意の特定の伝送サービス の外側で生成され、通信セキュリティは、メッセージベースである。出所と配送 の両方に対する拒否されない受信がサポートされる。

【００３８】 実行中、アダプター４８８と４８９が、実行エンジン４８４と、外部アプリケ ーション４２０及び４３０との間のデータの流れを仲介する。例えば、専用プロ セス定義３００のステップ３１５を参照すると、エンジン４８４は、アダプター ４８８または４８９を介して、問題の品物が外部委託されているかどうかを判定 するアプリケーション４２０または４３０にリクエストを送信することができる 。次に、アプリケーションは、それぞれのアダプターを介して応答する。４８８ 及び４８９に対するアダプター構成オプションは、関連するサイトに対する専用 プロセスの作成者によって設定される。これらのアダプター４８８及び４８９は 、それらの許容可能な構成オプションを、それらのインストール時に中間層マネ ージャセット４８２に伝える。アダプター４８８及び４８９に対する構成インタ ーフェースによって、専用プロセスは、外部アプリケーションにデータを挿入し たり、外部アプリケーションからデータを検索したり、または、外部アプリケー ションによって生成された特定のイベントに対して問い合わせる（聞く）ことが できる。ここで、データが挿入されたか、検索されたか、または問い合わせられ たかは、オブジェクト定義によって表される。アダプター４８８及び４８９は、 また、状態／一貫性管理の一様な特性を保証し、システムに統合することができ る異なるアプリケーション間の動作を検査する。プロセスの実行中、アダプター ４８８及び４８９は、専用プロセスにおいて指定されたアクションに対する挿入 、検索及び問い合わせを目的のアプリケーション４２０及び４３０との特定の対 話にマッピングする。

【００３９】 好ましい実施態様のサイトの動作は、共用プロセス定義、関連する専用プロセ ス及びオブジェクト定義のライフサイクルを循環する。図５に示すように、この サイクルは、共用プロセス定義と参照するオブジェクト定義の作成から始まり、 次に、共用プロセス定義とオブジェクト定義の配信、必要な専用プロセス定義の 作成、プロセスのインストールに続き、そして、プロセスの実行で終了する。

【００４０】 ステップ５０２で、ユーザが共用プロセス定義を作成する。共用プロセス定義 ２００が作成されるサイトは、オーサリングサイトと呼ばれる。共用プロセス定 義２００の作成には、共用プロセス定義内のサイト間メッセージを表すすべての オブジェクト定義の作成が含まれる。好ましい実施態様では、共用プロセス定義 及びオブジェクト定義の両方とも、クライアントのＧＵＩ４６５及び４７５を介 してマネージャセット４８２と対話するユーザ４４０及び４５０によって作成さ れる。共用プロセス定義２００の作成中、例えば、ユーザ４４０は、すべての参 加サイト１０１、１０２、及び１０３間の対話シーケンスと、これらの対話を結 合するロジックを指定する。この例では、ＧＵＩ４６５は、図２の図と同じ様に 見える流れ指標（インジケータ）によって内部接続された1組のアイコンとして 、定義２００を表示する。購入発注、確認応答、及び拒否オブジェトに対する定 義もまた、それらが事前に存在していなければ、ユーザ４４０によってＧＵＩ４ ６５を介して作成される。

【００４１】 共用プロセス及び必要なオブジェクトを定義した後、ユーザは、プロセスの配 信に進む。ステップ５０４で、オーサリングサイトは、インターネット１０４を 介して、作成した共用プロセス定義と参照されるオブジェクト定義を、共用プロ セスに参加するすべてのサイトに送信する。インターネット１０４は、ローカル エリアネットワーク（ＬＡＮ）上のイントラネット、ワイドエリアネットワーク （ＷＡＮ）上のインターネット、またはいわゆるインターネットとすることがで きるということが、当業者には理解されよう。この場合、サイト１０２は、オー サリングサイトであり、サイト１０１及び１０３は、参加サイトである。サイト １０２が、共用プロセス定義２００と関連するオブジェクト定義をインターネッ トを介して送信するために、これらの定義は、マネージャセット４８２から伝送 マネージャ４８６へ、及びそこから参加サイトの伝送マネージャへと送信される 。共用プロセス定義２００及びオブジェクト定義が参加サイト（この場合には、 サイト１０１と１０３）の伝送マネージャによって受け取られると、それらの定 義は、伝送マネージャから中間層マネージャに、データベースへの永続的な記憶 のために渡される。受信した共用プロセス定義２００及びオブジェクト定義をク ライアントのＧＵＩによって検査した後、参加サイト１０１及び１０３のユーザ は、共用プロセス定義を承認または不承認しなければならない。この承認または 不承認は、パートナーのサイトの伝送マネージャを介してオーサリングサイトに 送られる。共用プロセス定義２００が、参加サイト１０１及び１０３で検査され ている間に、オーサリングサイト１０２は、ステップ５０８で、伝送マネージャ ４８６によって受け取られることになる承認または不承認の結果を待つ。サイト １０１及び１０３による承認または不承認は、技術的な関心事ではなくて、営業 的な関心事を表すものであろう。パートナーのサイトが、定義２００に記述され た商用上の配置（commercial arrangement）が許容可能であることを見いだした 場合は、それは、この場合サイト１０２であるオーサリングサイトに承認信号を 返す。ステップ５０８で、システムは、すべての承認が得られたかどうかについ て検査をし、参加サイト１０１または１０３のいずれかが共用プロセス２００を 承認しない場合には、オーサリングサイト１０２が、中止メッセージを伝送マネ ージャ４８６を介してパートナーのサイト１０１及び１０３に配信し、そして、 ステップ５１０に進む。この場合には、共用プロセス定義２００は破棄され、サ イト１０１、１０２、及び１０３は、新たな共用プロセス定義について交渉を開 始することができる。ステップ５０８で、共用プロセス定義があまねく許可され た場合には、オーサリングサイト１０２は、パートナーサイトのそれぞれにコミ ットメッセージ（commit message）を配信する。

【００４２】 コミットメッセージがオーサリングサイトによって送信されて、参加サイトに よって受信された後、オーサリングサイトと参加サイトの両方のサイトは、各サ イトが所有する共用プロセスノードに関連する専用プロセスの生成に進む。これ は、図５のステップ５１４によって表されている。各サイトのユーザは、ユーザ のサイトに関連する共用プロセス定義の各ノードに対する専用プロセス定義を作 成する。例えば、ユーザ４００は、ノード２１０に対する専用プロセス定義３０ ０と、ノード２２０に対する付随する専用プロセス定義を作成する。というのは 、ノード２１０及び２２０は、それぞれサイト１０２に関連付けられているから である。同様に、サイト１０１のユーザは、ノード２０５及び２２５に対する専 用プロセス定義を作成し、一方、サイト１０３のユーザは、ノード２１５に対す る定義を作成する。

【００４３】 必要な専用プロセス定義を首尾良く実装した後、各参加サイトは、専用プロセ ス定義の実装完了を示すメッセージをオーサリングサイトに送信する。ステップ ５１６で、オーサリングサイトは、すべてのサイトからの専用プロセス完了信号 を収集する。もし、どれかのサイトが１つまたは複数の専用プロセスの実装に失 敗した場合には、そのサイトは、オーサリングサイトに失敗メッセージを送信す る。この場合は、実装プロセスは中止され（ステップ５１８）、プロセス定義２ ００は破棄される。オーサリングサイトが、すべての参加サイトから、専用プロ セスの実装がうまく完了したことを示すメッセージを受け取り、さらに、それ自 身の専用プロセスを首尾良く実装すると、オーサリングサイトは、インストール プロセスを開始することができる（ステップ５２０）。

【００４４】 プロセスのインストール（ステップ５２０）は、オーサリングサイトがインス トールメッセージをすべての参加サイトに送信することから始まる。このインス トールメッセージを受信すると、各参加サイトは、ローカルに共用プロセスをイ ンストールする。図６は、単一のサイトで、共用プロセス定義に関連する専用プ ロセス定義をインストールするためのプロセスを示す流れ図である。ステップ６ ０２で、共用プロセス定義及び関連する専用プロセス定義が、マネージャセット ４８２から実行エンジン４８４に送られる。ステップ６０４で、共用プロセス定 義は、対象としているサイトに対してのみの状態を含む状態マシンを作成するた めにコンパイルされる。例えば、サイト１０２における共用プロセス定義２００ のコンパイルの処理は、ノード２１０及び２２０に関連した状態を生成すること になる。状態マシンに記憶されるのは、各状態に対するトリガイベントである。 共用プロセス定義２００の例を続行して、サイト１０２は、そのイベント２３０ 、すなわちサイト１０１からの購入発注を記録し、ノード２１０に関連した状態 、及び、サイト１０３からの確認応答であるイベント２４５をトリガし、ノード ２２０に関連する状態をトリガする。ステップ６０６で、状態マシンの各状態は 、「コール（call）」コマンドによって関連する専用プロセス定義に結合される 。例えば、サイト１０２は、専用プロセス定義３００をノード２１０に関連する 状態に結合する。この結合の結果は、ノード２１０に関連する状態が、サイト１ ０１からの購入発注によってトリガされると、専用プロセス定義３００が呼び出 されて実行されるということである。ステップ６０８で、対象とするサイトが共 用プロセスのイニシエータであるかどうかが判定される。サイト１０２の例のよ うに、イニシエータでなければ、実行エンジンは、受信すべきトリガメッセージ を決定して、それを伝送マネージャに登録する。サイト１０２の例では、サイト １０１からの購入発注２３０と、サイト１０３からの確認応答２４５という２つ のトリガメッセージがある。もし、サイトが共用プロセスのイニシエータであれ ば、第１の専用プロセスに対するトリガイベントは、そのサイトの内部にあり、 ステップ６１２で、イベントトリガ、スケジューリングされたスタートアップ、 または、サブプロセスのトリガとして登録される。

【００４５】 共用プロセスを首尾良くインストールすると、各参加サイトは、オーサリング サイトにインストール確認メッセージを返す。ステップ５２２で、オーサリング サイトは、すべての参加サイトからのインストール確認メッセージを収集する。 どれかのサイトが、共用プロセスをインストールすることができなかった場合に は、そのプロセスは上述したようにステップ５２４で中止される。オーサリング サイトにおけるインストールの成功によって、すべての関連するサイトで共用プ ロセスがインストールされたということを示す、すべての参加サイトへのメッセ ージの送信がトリガされる。この時点で、プロセスは、実行の準備が整う（ステ ップ５２６）。

【００４６】 上述したように、共用プロセスの実行は、実際には、パートナーのサイトにお ける関連する専用プロセスの対話的な実行によって行われる。単一のサイトによ るインストールされた共用プロセスの実行のようすを図７に示す。実行は、ステ ップ７０２で、パートナーのサイトからのメッセージの受信、アプリケーション に関連するイベント、スケジューリングされたスタートアップ、またはサブプロ セスのトリガを含むことができる開始イベントにより始まる。例えば、共用プロ セス定義２００のノード２１０は、サイト１０１からの購入発注メッセージの受 信によってトリガされる。ステップ７０４で、そのトリガされたサイトにおける 実行エンジンが、適切な状態マシンにおいてインスタンスを作成して、その状態 マシンを初期状態に設定する。ステップ７０６で、実行エンジンは、関連する共 用プロセスノードに関連した専用プロセスを取り出す。例えば、ノード２１０の トリガ時に専用プロセス定義３００がアクセスされる。ステップ７０８で、実行 エンジンは、イベント２３０の内容を含む適切なデータを専用プロセスに送って 、その実行を開始する。ステップ７１０で、専用プロセスが実行されて、実行エ ンジンにデータ返し、ステップ７１２で、実行エンジンは、その返されたデータ に基づいて動作する。例えば、専用プロセス３００は、サイト１０１に確認応答 を送信するための命令、またはサイト１０３への購入発注のいずれかを実行エン ジン４８４に返す。ステップ７１０における専用プロセスの実行の間、エンジン ４８４は、アプリケーション４２０と４３０を利用することができるということ に注意すべきである。実行エンジン４８４は、それに従って応答する。ステップ ７１４で、共用プロセス定義がローカルに終了した状態となったかどうかについ ての判定が実行エンジンによってなされる。この判定は、ローカルな判定であっ て、共用プロセスにおける参加サイトに限定される。例えば、ノード２２０の完 了は、サイト１０２についてのローカルな終了状態である。なぜなら、それは、 サイト１０２に対応するプロセス２００における最終ノードであるからである。 同様に、付随する専用プロセスの結果に依存して、ノード２１０の完了を、サイ ト１０２に対するローカルな終了状態とすることができる。ローカルな終了が起 こると、ステップ７１６で、そのサイトについての共用プロセスは終了する。ス テップ７１６は、２つのフェーズのコミットプロトコル（commit protocol）が 、サイト１０１、１０２、及び１０３間で実行されて、プロセス２００の実行が 相互に完了したことが保証されるまでは完了しない。

【００４７】 ステップ７１４で、ローカルに終了した状態にならない場合は、伝送マネージ ャは、パートナーのサイトからのトリガメッセージを待つ（ステップ７１８）。 例えば、ノード２１０の結果が、イベント２４０における購入発注の送信である 場合は、伝送マネージャ４８６は、イベント２４５の確認応答を待って、ノード ２２０に関連する専用プロセスをトリガする。ステップ７２０でトリガメッセー ジが受信されると、ステップ７２２において、実行エンジンは、関連するプロセ スの状態について調べる。次に、専用プロセスが、ステップ７０６で実行を開始 し、上述したように実行される。

【図面の簡単な説明】

【図１】本考案に従って、共用（パブリック）プロセス
定義と、専用（プライベート）プロセス定義を有する複
数のサイトを備える、拡張された事業システムのブロッ
ク図である。

【図２】本考案に従って、ノード、アーク(arc）、及び
それらの間の接続を含む共用プロセス定義を表す図であ
る。

【図３】本考案に従って、専用プロセス定義を実行する
ためのプロセスを示す流れ図である。

【図４】本考案に従うシステムのブロック図である。

【図５】本考案に従って、共用プロセス定義を配信する
ための方法を示す流れ図である。

【図６】本考案に従って、共用プロセス定義を実装する
ための方法を示す流れ図である。

【図７】本考案に従って、特定のプロセスタイプのイン
スタンスを実行するための方法を示す流れ図である。

【図８】共用プロセス定義を編集するためのグラフィッ
クユーザインターフェースを表示している表示装置を示
す図である。

【図９】専用プロセス定義を編集するためのグラフィッ
クユーザインターフェースを表示している表示装置を示
す図である。

───────────────────────────────────────────────────── フロントページの続き (72)考案者 フロスト，ヒルドレス，ロバート アメリカ合衆国カリフォルニア州94131, サンフランシスコ，チャーチ・ストリー ト・1513 (72)考案者 シブナブカラス，チェリア アメリカ合衆国カリフォルニア州94002, ベルモント，カールモント・ドライブ・ナ ンバー１・2156 (72)考案者 ニベリンク，ミッチェル，ダブリュー アメリカ合衆国カリフォルニア州94061, レッドウッド・シティ・ウエスト・オーク ウッド・ブルバード・299

Claims (10)

【実用新案登録請求の範囲】
1. 【請求項１】第１のサイトに関連した第１のノード、第
   ２のサイトに関連した第２のノード、及び前記第１及び
   第２のノードに結合されたアークとからなる共用プロセ
   ス定義を使用して前記第１と第２のサイト間のプロセス
   を調和させるためのシステムであって、 前記第１のノードに関する共有情報によって関連付けら
   れた第１の専用プロセス定義を実行することによって前
   記第１のサイトにおいて前記共用プロセス定義の前記第
   １のノードを実行する手段と、 前記アークによって定義されたメッセージの受信時に、
   前記第２のノードに関する共有情報によって関連付けら
   れた第２の専用プロセス定義を実行することによって前
   記第２のサイトにおいて前記共用プロセス定義の前記第
   ２のノードを実行する手段と、 からなるシステム。
2. 【請求項２】前記アークがビジネスオブジェクトであ
   る、請求項１のシステム。
3. 【請求項３】前記第１のサイトにおいて前記共用プロセ
   ス定義を作成する手段と、 前記第２のサイトに前記共用プロセス定義を配信する手
   段と、 前記第１のサイトにおいて、共有情報によって、前記第
   １のノードに、該第１のサイトからのメッセージの送信
   に先行するアクションを含む第１の専用プロセス定義を
   関連付ける手段と、 前記第２のサイトにおいて、共有情報によって、前記第
   ２のノードに、該第２のサイトによるメッセージの受信
   に続くアクションを含む第２の専用プロセスを関連付け
   る手段と、 をさらに含む、請求項２のシステム。
4. 【請求項４】前記配信する手段が、 前記第２のサイトにおいて前記共用プロセス定義を検査
   する手段と、 前記第２のサイトにおいて前記共用プロセス定義が承認
   された場合に、前記第２のサイトから前記第１のサイト
   へ承認信号を送信する手段と、 前記第２のサイトにおいて前記共用プロセス定義が承認
   されない場合に、前記第２のサイトから前記第１のサイ
   トへ不承認信号を送信する手段と、 をさらに含む、請求項３のシステム。
5. 【請求項５】前記配信する手段が、 前記第２のサイトからの承認信号を前記第１のサイトで
   受信した場合に、前記第２のサイトにコミットメッセー
   ジを送信する手段と、 前記第１のサイトにおいて前記共用プロセス定義と前記
   第１の専用プロセス定義をインストールする手段と、 前記第２のサイトにおいて前記第１のサイトからのコミ
   ットメッセージを受信した場合に、前記第２のサイトに
   おいて前記共用プロセス定義と前記第２の専用プロセス
   定義をインストールする手段と、 をさらに含む、請求項４のシステム。
6. 【請求項６】前記配信する手段が、 前記第２のサイトからの不承認信号を前記第１のサイト
   で受信した場合に、前記第２のサイトに中止メッセージ
   を送信する手段をさらに含む、請求項５のシステム。
7. 【請求項７】前記第１のサイトにおいて前記共用プロセ
   ス定義を第１の状態マシンに変換する手段と、 前記第２のサイトにおいて前記共用プロセス定義を第２
   の状態マシンに変換する手段と、 をさらに含む、請求項３のシステム。
8. 【請求項８】前記共用プロセス定義の第１のノードの実
   行を第１のプロセス実行履歴に記録する手段と、 前記共用プロセス定義の第２のノードの実行を第２のプ
   ロセス実行履歴に記録する手段と、 前記第１及び第２のプロセス実行履歴を検査する手段
   と、 をさらに含む、請求項３のシステム。
9. 【請求項９】第１のサイトと第２のサイト間のプロセス
   を調和させるシステムであって、 前記第１のサイトにおいて、該第１のサイトに関連する
   第１のノード、前記第２のサイトに関連する第２のノー
   ド、及び前記第１のノードと前記第２のノード間に介在
   するアークとを含む共用プロセス定義を作成する手段
   と、 前記共用プロセス定義を前記第２のサイトに配信する手
   段と、 前記第１のサイトにおいて前記第１のノードに関する共
   有情報によって関連付けられた第１の専用プロセス定義
   を作成する手段であって、該プロセス定義に前記第１の
   サイトからのメッセージの送信に先行するアクションを
   定義する手段と、 前記第２のサイトにおいて前記第２のノードに関する共
   有情報によって関連付けられた第２の専用プロセス定義
   を作成する手段であって、該プロセス定義に前記第２の
   サイトによるメッセージの受信に続くアクションを定義
   する手段と、 前記第１のサイトにおいて前記第１の専用プロセス定義
   を実行することによって、前記共用プロセス定義の前記
   第１のノードを実行する手段と、 前記メッセージの受信時に、前記第２のサイトにおいて
   前記第２の専用プロセス定義を実行することによって前
   記共用プロセス定義の前記第２のノードを実行する手段
   と、 からなるシステム。
10. 【請求項１０】第１のサイトと第２のサイト間のプロセ
    スを制御するプロセス定義を作成するシステムであっ
    て、 前記第１のサイトにおいて、該第１のサイトに関連する
    第１のノード、前記第２のサイトに関連する第２のノー
    ド、及び前記第１のノードと前記第２のノード間に介在
    するアークとを含む共用プロセス定義を作成する手段
    と、 前記共用プロセス定義を前記第２のサイトに配信する手
    段と、 前記第１のサイトにおいて前記第１のノードに関する共
    有情報によって関連付けられた第１の専用プロセス定義
    を作成する手段であって、該プロセス定義に前記第１の
    サイトからのメッセージの送信に先行するアクションを
    定義する手段と、 前記第２のサイトにおいて前記第２のノードに関する共
    有情報によって関連付けられた第２の専用プロセス定義
    を作成する手段であって、該プロセス定義に前記第２の
    サイトによるメッセージの受信に続くアクションを定義
    する手段と、 からなるシステム。