JP4667748B2 - マルチノード・プロセスを制御する方法および装置 - Google Patents

Description

本発明は、マルチノード・プロセスを制御する方法および装置に関する。具体的には、本発明は、複数のクライアント・システムの間でのプロセスを制御するブローカ・システムに関する。

Ｗｅｂサービスは、アプリケーションがインターネットを介して互いに通信できるようにするプロトコルおよび技術の組を指す。Ｗｅｂサービスは、e-businessフレームワークのうちで、従来のサービスに期待されるものと同一のサービス品質で、商業サービスをインターネットの世界に持ち込むことに関連する部分である。

単純なＷｅｂサービスには、２つの当事者すなわち、インターネットを介して接続されたクライアントおよびサーバが含まれる。クライアントは、インターネットを介してサーバに要求を送信し、サーバは、要求を処理し、インターネットを介してクライアントに応答を送信し、クライアントが、その情報を受信する。この情報は、天気予報とすることができる。

より複雑なＷｅｂサービスには、図１の従来技術に示されているように、複数のノードが含まれる。クライアント１２（売り手）は、クライアント１４（買い手）からの支払を受け取るために、クライアント１４との間でメッセージを送受信する。支払いサービス１８は、クライアント１４の代わりに支払を行い、支払いサービス１６は、クライアント１２の代わりに支払を受け取る。この例では、クライアント１２が、クライアント１４に支払を要求し、クライアント１４が、その要求を支払いサービス１８に渡し、支払いサービス１８が、支払注文を準備し、これが、クライアント１４およびクライアント１２を介して支払いサービス１６に転送され、支払注文が除外される場合には、支払いサービス１６が、クライアント１２にメッセージを送信する。

上のサービスでは、固定されたステップのプロセスが、各ノードで定義され、各ノードは、プロセスの次のステップを調整する。プロセス・ステップの知識が、各ノードで保持される。各ノードは、それ自体でまたは別のノードと共に、プロセスのあるステップを実行する方法だけを知っている。プロセスの各ステップは、プロセスの次のステップにつながり、これによって、プロセスが、集中して定義されるのではなく、ノードのグループにまたがって定義される。ノードは、プロセスにおけるそれ自体のステップを終了したならば、次のステップを開始するために次のノードをトリガする。この例では、ノードは、なんらかの制御を有するが、プロセスの個々の制御は有しない。

そのような分散プロセスは、当該プロセスおよびそれらのノードに固定される。必要なものは、クライアントがプロセスを選択でき、そのプロセスに含まれるノードを選択できる解決策である。

本発明の第１の態様によれば、請求項１で定義される、複数のノードの間のプロセスを制御するシステムが提供される。

そのようなシステムを、好ましい実施形態ではプロセス・ブローカと呼ぶ。ノード（好ましい実施形態ではクライアントと呼ぶ）が、プロセス・ブローカと排他的に対話し、他のノードと対話しないように構成され、その結果、ブローカの対話なしでその排他的ノードに対するプロセスを実行できるノードがなくなることが好ましい。そのようなブローカが、信頼される当事者になることが好ましい。そのようなブローカ・システムを使用して、全体的なプロセスの一部を形成する複数のサブプロセスに、単一の焦点が与えられることが最も好ましい。

そのようなシステムによって、実際に事前定義サービスと対話する方法の知識なしで、クライアントがサービスと対話できるようにする、アプリケーション開発者用の単純なコマンド試行インターフェースが提供されることが好ましい。そのような知識は、システム内に保管される。

ノードは、複数のコンピュータ・システム・タイプの１つとすることができるのが好ましい。第１ノードは、製品またはサービスを買うプロセスを呼び出すクライアントとすることができる。第２ノードは、処理される商品またはサービスを有するクライアントとすることができる。もう１つのノードは、第１ノードおよび第２ノードの支払いサービスとすることができる。もう１つのノードは、たとえば支払いサービスなどのノードの接続詳細を突き止めるためのサービス・レジストリとすることができる。

本発明の好ましい実施形態を、例としてのみ添付図面を参照してこれから説明する。

ノードのシステム全体の構成要素を、図２を参照して説明する。１つまたは複数のネットワークを介してプロセス・ブローカ１０に接続されたクライアント４０およびクライアント４２が示されている。やはりブローカ１０に接続されているのが、支払いサービス４４、支払いサービス４６、およびサービス・レジストリ４８である。

クライアント４０は、関連データをセキュア・ストアに保管するが、この場合に、関連データは、支払いサービス４４の名前および支払いサービス４４によって保持されるアカウント詳細である。クライアント４０および４２は、プロセス・ブローカ１０との間でデータを送受信することができる。この実施形態では、クライアント４０は、ＷＡＰトランスポート・プロトコルを使用してプロセス・ブローカ１０と通信するＷＡＰ対応モバイル電話機である。クライアント４２は、ＨＴＴＰである共通ネットワーク・プロトコルを介してプロセス・ブローカ１０と通信する。

サービス・レジストリ４８は、支払いサービス４４および４６の接続詳細を含む。そのような接続詳細は、プロセス・ブローカ１０によって、クライアントによって供給されるノード名を使用して獲得される。

ネットワークは、サービスを使用する、クライアント、ブローカ、およびサービス・レジストリを含むすべてのノードが接続する。プロセス・ブローカ１０は、複数ネットワーク・トランスポート機能を有し、ネットワーク上で、共通ＨＴＴＰプロトコルを使用して、Ｗｅｂサービスを調整する

プロセス・ブローカ１０は、サービスを実行することができ、図３に詳細に示されている。この実施形態では、プロセス・ブローカは、IBM（登録商標）WebSphere（登録商標）Business ProcessBeansを使用して構築され、IBM Websphere Ｗｅｂアプリケーション・サーバ上で動作する。しかし、サービスの走行、実行、処理、および呼び出しが可能であるならば、どのような言語またはプラットフォームでも使用することができる。プロセス・ブローカ１０の機能は、プロセス・テンプレートを保管し、それらのプロセス・テンプレートを実行し、実行の状態を維持し、実行ステップの間でデータを処理することである。プロセス・テンプレートの例を説明する。

プロセス・ブローカ１０は、プロセス・エンジン３０およびプロセス・テンプレート・リポジトリ３２を含む。プロセス・エンジン３０は、構成要素の本体、メッセージ・リスナ３４、メッセージ・センダ３５、プロセス・インタープリタ３６、プロセス実行３７、セキュリティ３８、およびプロトコル・コンバータ３９を含む。プロセス・テンプレート・リポジトリ３２は、プロセス・テンプレート１（支払いプロセス・テンプレート）、プロセス・テンプレート２（暗号込みの支払いプロセス・テンプレート）、および支払いプロセス・テンプレート３（支払いのためのディジタル商品の交換）を含む。

メッセージ・リスナ３４は、ノードからのメッセージが受信する。この構成要素は、どのようなトランスポート・プロトコルが使用されても、そのプロトコルを介してメッセージ（当事者からの要求または応答）を受信することができる。そのプロトコルが、共通プロトコルではなく、異なるプロトコルである場合には、プロトコル・コンバータ３９が、異なるプロトコル・メッセージを変換するために呼び出される。異なるプロトコルが保管され、その結果、後続メッセージを、変換された異なるプロトコルにすることができる。メッセージ・リスナ３４は、セッションｉｄを識別するかメッセージにそれが含まれないことを識別することによって、現在のプロセスの一部であるメッセージと、新しいプロセスの実行を要求するメッセージを区別する。セッションｉｄがない場合には、そのメッセージは、プロセス・インタープリタ３６に渡される。セッションｉｄがある場合には、そのメッセージは、プロセス実行３７に渡される。

メッセージ・センダ３５は、メッセージをノードに送信する。この構成要素は、ＨＴＴＰトランスポート機構を介してメッセージ（当事者からの要求または応答）を送信することができる。通常、各メッセージに、セッションｉｄが含まれ、このセッションｉｄを応答に含めて、メッセージが進行中のプロセスの一部であることを示すことができる。受信ノードが、異なるプロトコルをサポートするが、共通プロトコルをサポートしないことが既知である場合には、メッセージを送信する前に、プロトコル・コンバータ３９を呼び出して、その異なるプロトコルに変換する。

プロセス・インタープリタ３６は、セッションｉｄがないメッセージを解析して、そのメッセージによってプロセス実行３７とのセッションが開始されるかどうかを識別する。次に、メッセージ（ノードを含む）から、プロセス実行３７による後続の実行のためのプロセス・テンプレートおよびパラメータを識別し、プロセス・テンプレートの処理のためのセッションｉｄを割り当てる。

プロセス実行３７は、選択されたプロセス・テンプレートのステップを解析し、さまざまなメソッドを呼び出す。ノードからの応答にセッションｉｄが含まれる場合に、プロセス実行３７は、その応答も解析する。プロセス実行３７は、テンプレート内のステップをカウントし、各ステップを順次に実行する。４つの主要なメソッドすなわち、内部メソッド、ノード呼び出しメソッド、ノード・アドレス・メソッド、および役割管理メソッドを、本明細書で説明する。内部メソッドは、たとえば数値演算、論理演算、文字列操作、ローカル・メソッド呼び出しなどの多数の内部メソッドのいずれかとすることができる。ノード呼び出しメソッドは、メッセージ・センダ３５を使用して、ノードと通信し、実行されるサービスを要求する。このメソッドは、ノード・アドレスを必要とする。ノード呼び出しメソッドから戻る際に、応答が保管され、さらなるステップの処理に使用される。ノード・アドレス・メソッドは、ノード名をサービス・ディレクトリに送信することによって、ノード・アドレスを獲得する。このメソッドは、開始クライアントまたは後続クライアントによってノード名だけが与えられる時に呼び出される。役割管理メソッドは、ノード名を役割に割り振るためのものであり、ノード名がプロセス・テンプレートで直接に参照されない時に使用される。プロセス・テンプレートは、ソース・ノード、ターゲット・ノード、ターゲット・ノードの支払いサービスなどの役割によってプロセスを定義する。役割管理メソッドは、ノードからの最初のメッセージおよび後続メッセージで供給されるパラメータから、役割を特定のノードに割り振る。

セキュリティ構成要素３８は、セキュア・プロセスに関する要求を識別する。プロセス・ブローカ１０自体は、関連ノードに暗号化されたデータを渡す時を除いて、暗号化されたデータを使用せず、使用することを必要としない。

セキュリティ構成要素は、セキュア・プロセス・テンプレートに関する要求の識別およびそのようなセキュア・プロセス・テンプレートの選択、ならびにプロセス・テンプレート内のセキュア・プロセスの識別のためのメソッドを含む。

プロセス・テンプレートは、本明細書で、１つまたは複数のノードの間での汎用の対話を記述するのに使用される用語である。そのような記述は、システムによって、ノードの間のウェブ・プロセスを調整するのに使用される。プロセス・テンプレートは、システムによる実行に適切な言語で記述され、支払いプロセスまたは商品の交換プロセスなどの複数のノードの間での特定の目標を達成する特定のプロセスを定義する。プロセス・テンプレートは、収集され交換される必要がある情報、プロセス内で当事者の所与の組によって演じられなければならない役割、および全体的な目標を達成するために行われる必要があるステップを定義する。「支払い」を記述するためにテンプレート内で定義することができる役割の例は、「買い手」、「売り手」、および「銀行家」である。Ｗｅｂサービス用語では、プロセス・テンプレートは、それぞれがＷｅｂサービス対話を記述する、１つまたは複数のサブプロセスを含む。

プロセス・テンプレートが、プロセス・ブローカによって解釈され、実行される時に、そのプロセス・テンプレートは、それによって記述されるプロセスの実行中インスタンスになり、その中で定義された役割は、実際に参加する当事者（プロセス・ブローカのクライアントであれ、プロセス・ブローカが使用するサービスであれ、クライアントによって使用するように指定されたサービスであれ）にバインドされなければならない。

本発明の好ましい実施形態のプロセス・テンプレートは、システム内の他のプロセス・テンプレートと共にデータベースに保管され、実行中に変更されないという意味で、静的である。

プロセスによっては、機密詳細が必要であり、関係する一部の当事者の機密詳細へのアクセスの制限が望まれる。

プロトコル・コンバータ３９は、クライアントからメッセージを受信する時に、それが共通プロトコルと異なる場合にメッセージ・トランスポート・プロトコルを共通プロトコルに変換するメソッドと、クライアントにメッセージを送信する時に、クライアントが異なるトランスポート・メッセージを使用する場合にメッセージ・トランスポート・プロトコルをクライアントのトランスポート・プロトコルに変換するメソッドを含む。

暗号化技法は、複数ノード・システムで遭遇する機密詳細の問題を扱うことができる。信頼のドメインが、同様なノードおよび関連するノードの間に存在し、たとえば、この実施形態では、信頼のドメインは、クライアント間、クライアントとその支払いサービスの間、および支払いサービス間に存在する。１つの状況は、各クライアントが、同一レベルの信頼を有し、各ノードのすべてのデータを見る時である。もう１つの状況は、クライアントとそのそれぞれの支払いサービスの間の通信が、クライアントとそのノードだけが知り、他のノードが知らない鍵を用いて暗号化される時である。もう１つの状況は、２つの支払いシステムが、お互いを知り、独立にまたはブローカを介して公開暗号鍵を交換する時であり、その場合、ブローカを介して送られる暗号化されたデータは、ブローカに知られることはない。この第３の場合では、ブローカは、機密データを渡すことを許可されるが、それが何であるかを知らないので、部分的に信頼される第三者のプロセス・コーディネータにすぎない。

この最後の場合に、機密データだけが暗号化され、メッセージは暗号化されないので、メッセージは部分的に暗号化される。そのような解決策は、ＩＢＭ ＭＱｅ製品によって対処され、この場合に、文書の部分的暗号化およびメッセージ・レベル暗号化が可能であり、その結果、メッセージを、中間ノードに見られる危険性なしで、ノードを介してルーティングすることができるようになる。しかし、この製品は、純粋にメッセージング・プラットフォームであり、この実施形態などのプロセスを構築する基礎である。ＩＢＭ ＭＱｅは、各ノード（この場合にはクライアント、支払いサービス、および呼び出されるすべてのサービス）にＭＱｅが存在する同種環境で動作する。

異種システムは、共通ネットワーク・トランスポート・プロトコルを有する。プロセス・ブローカは、実質的に共通のネットワーク・トランスポート・プロトコルを有して、プロセスを調整するが、あるノードが共通プロトコルをサポートしない場合に、プロトコルと共通プロトコルの間の変換を実行する手段も含む。プロセス・ブローカは、プロセスの中心にあるので、そのような機能を実行するのに理想的な位置であり、ノードをシンに保ち、ネイティブ・トランスポート・プロトコルを使用した通信を可能にする。

２つのプロセス・テンプレートの例を、この実施形態で説明する。これらのプロセス・テンプレートは、プロセス・テンプレート・リポジトリ３２に保管される。プロセス・テンプレートは、標準インターフェース定義を使用してサービスを定義する。このプロセス・テンプレートのデータベースは、タイプによって参照でき、プロセス・エンジン３０による解釈および実行のために検索することができる。

図４の支払いプロセス・テンプレートは、クライアント４２の支払いサービスからクライアント４０の支払いサービスに電子支払い注文を直接転送する。たとえば、一対のクライアントが商売を行っており、１ドルの支払いを、それらの間で行う必要がある。クライアント４０（売り手）は、クライアント４２（買い手）に支払いを求める。

ステップ４０１で、クライアント４０は、要求およびデータをプロセス・ブローカ１０に送信する。要求データ（Ｃ４０データ）は、クライアント４０の支払いサービス詳細（それへの支払いを行うことができる支払いサービス４４）の名前、支払われる額（１ドル）、プロセス・ブローカ１０が理解するクライアント４０への参照（たとえば、クライアント４０のノード名またはアドレス）を含む。セッションｉｄは、このメッセージに含まれない。

ステップ４０２で、プロセス・ブローカ１０は、メッセージ・リスナ３４を介してこのメッセージを受信する。メッセージ・リスナ３４は、セッションｉｄがないことを識別し、このメッセージをプロセス・インタープリタ３６に渡す。プロセス・インタープリタ３６は、要求による指示に従って、支払いプロセス・テンプレートを解析し、選択する。プロセス・インタープリタ３６は、プロセス・テンプレート・リポジトリ３２から支払いプロセスのプロセス・テンプレートを検索し、そのプロセス・テンプレートをプロセス実行３７に渡す。プロセス実行３７は、プロセスへの入力として送信された要求データを使用して、そのプロセス・テンプレートを実行する。プロセス実行３７は、このプロセス・テンプレートにおける開始役割を売り手として識別し、役割管理メソッドを使用して、クライアント４０をその役割にバインドする。プロセス実行３７は、プロセスの３つの他の役割もバインドする、すなわち、買い手をクライアント４２に、買い手銀行サービスを支払いサービス４６に、売り手銀行サービスを支払いサービス４４にそれぞれバインドする。売り手銀行サービスは、要求データ（Ｃ４０）で指定され、このステップ４０２でプロセス・インタープリタ３６によって支払いサービス４４にバインドされるが、買い手銀行サービスは、ステップ４０４の後でバインドされる。

ステップ４０３は、プロセス実行３７によって実行されるプロセス・テンプレートの最初のステップであり、このステップは、クライアント４２からの関連データを要求する。最初のプロセス・ステップは、買い手役割からの銀行サービス詳細に関する要求文書により定義される。入力データがクライアント４２を指定しているので、買い手役割は、前に、クライアント４２として解決されている。

クライアント４２は、要求文書を受信し、売り手データ（額＝１ドル）に基づいて、支払いサービス４６が買い手銀行サービスであることを指定することによって応答する。クライアント４２は、クライアント４０のデータに基づいて、要求文書にそれ自体のデータ（Ｃ４２データ）を追加し、それをプロセス・ブローカ１０に送り返す。

ステップ４０４で、プロセス実行は、クライアント４２からの要求文書を受信する。このステップでは、プロセス実行は、役割管理メソッドを呼び出し、プロセス・インタープリタ３６によるクライアント４２データの受信の後に、支払いサービス４６を、買い手銀行サービス役割にバインドする。

ステップ４０５で、プロセス実行は、支払いサービス４４および４６のノード・アドレスを獲得する必要がある場合に、サービス・レジストリ４８を呼び出す。このプロセス・ステップは、サービス・レジストリ４８からの支払いサービス４４および４６の接続詳細を要求する。というのは、これらが、それぞれ売り手銀行サービスおよび買い手銀行サービスの役割にバインドされるからである。

ステップ４０６で、プロセス実行３７は、振り出される、クライアント４０に支払い可能な支払い注文について、要求文書（買い手詳細、売り手詳細、額）をクライアント４２の支払いサービス４６に送信する。

ステップ４０７で、プロセス実行３７は、すべての詳細が適切である場合に、サービス・レジストリ４８から支払い注文を受け取る。

ステップ４０８で、プロセス・テンプレートにおける次のフロー・ステップが、支払い注文をクライアント４０の支払いサービス４４に供託する。

ステップ４０９で、支払いサービス４４は、成功または失敗を示し、プロセス・テンプレートにおける最後のフロー・ステップであるステップ４１０で、状況がクライアント４０に返される。

プロセス・テンプレートの第２の例は、支払いに関するディジタル商品の交換を伴う、より複雑な処理フローである。これは、図２にディジタル権利管理（ＤＲＭ）ノードを追加したものと同一なので、このプロセスに関して図は示さない。

一対のクライアントが、商売をしている。クライアント４０（売り手）が、クライアント４２（買い手）に５ドルの支払いを求める。これと交換に、クライアント４０は、ディジタル資産、たとえば、ＭＰ３フォーマットでエンコードされ、音楽ファイルを作成した音楽出版会社（ＤＲＭサービスＡ）のディジタル権利管理（ＤＲＭ）システムを用いて保護された音楽ファイルの所有権を移転する。

ステップ１ クライアント４０が、その支払いサービスの詳細（支払いサービス４４）、そのＤＲＭサービス名（ＤＲＭサービスＡ）、ＤＲＭサービスに既知の音楽ファイル名への参照（ＭＰ３−Ａ）、およびクライアント４２のセッションｉｄを指定して、ブローカに「支払いのための商品の交換」要求を送信する。

ステップ２ プロセス・ブローカ１０が、「支払いのための商品の交換」プロセス・テンプレートを検索し、供給されたデータを適当な役割すなわち買い手、売り手、売り手支払いサービス、およびＤＲＭサービスにバインドする。

ステップ３ 最初のプロセス・ステップが、買い手役割から銀行サービス詳細を要求する。プロセス・ブローカ１０は、この情報の要求をクライアント４２に送信する。

ステップ４ クライアント４２が要求を受信し、支払いサービス４６がその銀行サービスであることを指定することによって応答する。支払いサービス４６は、買い手銀行サービス（プロセス・テンプレートにおける最後の役割）にバインドされる。

ステップ５ 次のプロセス・ステップで、プロセス・ブローカ１０が、それぞれ売り手銀行サービスおよび買い手銀行サービスの役割にバインドされる、支払いサービス４４および４６の接続詳細と、ＤＲＭサービス役割にバインドされるＤＲＭサービスＡの接続詳細を、サービス・レジストリ４８に要求する。

ステップ６ 次のプロセス・ステップで、プロセス・ブローカ１０が、振り出される、売り手に支払い可能な支払い注文の合成要求（買い手詳細、売り手詳細、額）を、支払いサービス４６に送信する。

ステップ７ すべての詳細が適切である場合に、支払いサービス４６が、プロセス・ブローカ１０に有効な支払い注文を返す。

ステップ８ 次のステップで、支払い注文が有効であり、受入可能であることを検証するために、プロセス・ブローカ１０が、支払い注文を支払いサービス４４に送信する。

ステップ９ 次のステップで、支払いサービス４４が、支払い注文が有効であることの表示をブローカ１０に返す。

ステップ１０ 仮想資産（ＭＰ３−Ａ）の所有権を、クライアント４０からクライアント４２に変更するための要求を、プロセス・ブローカ１０が、ＤＲＭサービスＡに送信する。

ステップ１１ ＤＲＭサービスＡが、所有権の変更が訴えられたが、完了には委託が必要であることを確認することによって、プロセス・ブローカ１０に応答する。

ステップ１２ 次のプロセス・テンプレート・ステップが、満たされるべき委託として、支払いサービス４４に支払い注文を送信する。

ステップ１３ 支払いサービス４４が、成功または失敗を示す。

ステップ１４ 結果が失敗である場合には、プロセス・ブローカ１０が、所有権変更を取り消す要求をＤＲＭサービスＡに送信し、失敗応答をクライアント４０に送り返す。しかし、結果が成功である場合には、プロセス・ブローカ１０は、成功状況をクライアント４０に返す（支払いが成功裡に行われ、資産所有権が移転された）。

プロセス・ブローカ１０を、Business Beansに関して説明したが、プロセス・ブローカ１０は、有限状態機械、有向グラフ・インタープリタなど、プロセス・モデルを実行するのに適切な多数の形で実施することができる。たとえば、BusinessProcess Beansは、適応ビジネス・サービス・モデルを使用することができ、IBM MQSeriesWork Flow（ＭＱＷＦ）などの有向グラフ・フロー・エンジンは、Flow Definition ModellingLanguage（ＦＤＭＬ）を使用することができる。

従来技術のマルチノード支払いプロセスの概略を示す図である。 本発明のマルチノード支払いプロセスの概略を示す図である。 本発明の実施形態のプロセス・ブローカの主構成要素を示す概略図である。 支払いプロセス・テンプレートのマルチノード・プロセス・フローを示す図である。

Claims (7)

1. 複数のクライアントおよび少なくとも１つのサーバの間でのプロセスを制御するシステムであって、
   それぞれが複数のクライアントおよび少なくとも１つのサーバの間でのプロセスであって、複数のクライアントの間で特定の目標を達成するプロセスを定義する複数のプロセス・テンプレートを保管するプロセス・テンプレート・リポジトリ手段と、
   クライアントおよび少なくとも１つのサーバの間でメッセージを送受信する手段であって、進行中のプロセスであることを示すセッションｉｄが含まれないメッセージを受信した場合には前記メッセージをプロセス・インタープリタ手段に渡し、セッションｉｄが含まれるメッセージを受信した場合には前記メッセージをプロセス実行手段に渡す手段と、
   セッションｉｄがないメッセージを解析し、当該メッセージによりセッションが開始されるかどうかを識別し、第１クライアントから受信される前記メッセージに応答してプロセス・テンプレート、サーバ、および第２クライアントを選択し、前記メッセージにセッションｉｄを割り当てるプロセス・インタープリタ手段と、
   前記セッションｉｄを含むメッセージを受領し、前記プロセス・テンプレート内のステップをカウントして順次に実行することにより、選択された第２クライアントにメッセージを送信し、それに応答する第２クライアントからのメッセージを受信することと、選択されたサーバにメッセージを送信し、選択されたサーバから応答を受信することと、第２クライアントおよびサーバからの応答の結果として、第１クライアントに応答を送信することとを含む、選択されたプロセス・テンプレートを実行するプロセス実行手段とを含み、
   前記プロセス実行手段は、サーバと通信し、実行されるサービスを要求するサーバ呼び出し手段を含み、
   前記サーバ呼び出し手段は、サーバ名をサービス・ディレクトリに送信することによってサーバ・アドレスを獲得し、
   前記プロセス・テンプレートは、支払いプロセスまたは商品交換プロセスを定義し、
   前記支払いプロセスは、前記クライアントそれぞれの支払いサービスノードに電子支払いを実行させ、
   前記商品交換プロセスは、前記クライアントそれぞれの支払いサービスノードに電子支払いを実行させ、前記クライアントであるＤＲＭノードにデジタル商品の所有権を移転させる、システム。
2. 前記プロセス・テンプレートが、収集され交換される必要がある情報、当事者の所与の組によってプロセス内で演じられなければならない役割、および指定された目標を達成するために行われる必要があるステップを定義する、請求項１に記載のシステム。
3. 前記第１クライアントが、製品またはサービスを買うプロセスを呼び出すことを可能にされる、請求項１または２に記載のシステム。
4. 前記第２クライアントが、処理される商品またはサービスを有する、請求項１ないし３のいずれかに記載のシステム。
5. 各前記プロセス・テンプレートが、１つまたは複数のステップを含み、少なくとも１つのステップが、クライアントまたはサーバとの対話である、請求項１ないし４のいずれかに記載のシステム。
6. 前記プロセス・テンプレートを実行する前記プロセス実行手段が、解釈済み言語でコード化される、請求項１ないし５のいずれかに記載のシステム。
7. クライアントまたはサーバからメッセージを受信する時に、メッセージ・トランスポート・プロトコルが共通プロトコルと異なる場合に、メッセージ・トランスポート・プロトコルを共通プロトコルに変換し、クライアントまたはサーバにメッセージを送信する時に、前記クライアントまたはサーバが異なるメッセージ・トランスポート・プロトコルを使用する場合に、メッセージ・トランスポート・プロトコルをクライアントまたはサーバのトランスポート・プロトコルに変換するためのプロトコル・コンバータをブローカが含む、請求項１ないし６のいずれかに記載のシステム。

Images