JP2005539324A - ウェブサービスとしてのプロセスフロー及びコレオグラフィーコントローラの提示 - Google Patents

Abstract

本発明は、ドキュメント交換コレオグラフィーをサポートするコンピュータベースの装置及び方法に係る。より詳細には、本発明の態様は、コレオグラフィーバージョン、サービスバージョン、及びドキュメントバージョンの種々の組合せによりシステムの進化を容易にする装置及び方法に係る。又、本発明は、コレオグラフィーエージェントを使用してコレオグラフィー管理を行なうと共に、非コレオグラフィーイネーブルアプリケーションへのコレオグラフィーイネーブルインターフェイスを与える。本発明の更に別の態様は、多数のコンテクスト設定フランチャイズ型サービスとしてのホストサービスのグラフィックデザインツール及び透過的エイリアシングを包含する。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記述する。

Description

本発明は、ドキュメント交換コレオグラフィー(choreography)をサポートするコンピュータベースの装置及び方法に係る。より詳細には、本発明の態様は、コレオグラフィーバージョン、サービスバージョン、及びドキュメントバージョンの種々の組合せによりシステムの展開を容易にする装置及び方法に係る。又、本発明は、コレオグラフィーエージェントを使用してコレオグラフィー管理を行なうと共に、非コレオグラフィーイネーブルアプリケーションへのコレオグラフィーイネーブルインターフェイスを与える。本発明の更に別の態様は、多数のコンテクスト設定フランチャイズ型サービスとして、ホストサービスのグラフィックデザインツール及び透過的（トランスペアレント）エイリアシング（aliasing）を包含する。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記述する。

（著作権の通告）：
本特許文書の開示の一部分は、著作権保護を条件とする画面イメージを含んでいる。本著作権者は、特許商標庁の特許ファイル又は記録に現われる場合に任意の者が特許文書又は特許開示を複写再現することに異議を唱えるものではないが、その他の場合には全ての著作権を留保するものとする。

ビジネス対ビジネス（Ｂ２Ｂ）及びアプリケーション対アプリケーション（Ａ２Ａ）電子商取引は、電子データ交換（ＥＤＩ）のための以前のプロトコルに置き換わりつつある。企業がＢ２Ｂ及びＡ２Ａシステムでそれらの効率を改善するように努力するにつれて、多数の互換性のないプラットホームや計算規格が出現した。互換性のある規格の中には、埋めるべきギャップが残っている。例えば、業界は、簡単なウェブサービスとは何かを定義した。簡単なウェブサービスに関連した規格は、ＵＤＤＩ、ＷＳＤＬ、ＸＳＤＬ及びＳＯＡＰを含む。しかしながら、これらの規格は、実際のＢ２Ｂ及びＡ２Ａ電子商取引のためのセキュリティ、信頼性、管理性及びコレオグラフィー(choreography)要求を完全に満足するものではない。この点において、サービス間のメッセージ交換のコレオグラフィーは、コレオグラフィー型交換に対するパターンを設定し、そして交換の一部分であるメッセージを会話ＩＤのような識別子で追跡することを含む。特に、コレオグラフィーは、多数のオプション及びコンフィギュレーション問題を伴う競合するプラットホームを提起する。コラボレーティブ(collaborative)ウェブサービス及びそれらのコレオグラフィーは、非ウェブビジネスと同様に展開することが予想される。展開から生じる問題を動的に解決する包括的又は一体的な装置や方法は存在しない。

Ｂ２Ｂ及びＡ２Ａ電子商取引を実施する１つの方法は、ウェブサービスの利用である。ウェブサービスは、基本的に、ウェブ上の機能をモジュラー(modular)形態で提示させる新規な方法である。ウェブサービスの現在の展開段階では、ドキュメント交換及びＲＰＣウェブサービスが著しく注目されている。ＲＰＣウェブサービスは、呼び出し者が、イン／アウトパラメータで手順呼び出し（プロシジャーコール）に良く似た何かを呼び出すことで、ウェブサービスを呼び出すようなＲＰＣプログラミングパラダイムをサポートする。

ウェブサービスの現在の実施は、通常、３つの規格に適合する。ＵＤＤＩは、サーチ基準に基づいてウェブサービスを発見しそしてそのインターフェイスをダウンロードするためのレジストリー規格である。ＷＳＤＬは、ウェブサービスのメッセージインターフェイスを定義するインターフェイス規格である。ＳＯＡＰは、有線上のペイロードを伝送するのに使用されるＨＴＴＰ（Ｓ）トランスポートへのバインディングが定義されたエンベロープ(envelope)プロトコル規格である。ウェブサービスは、通常、ＸＳＤＬ、Ｘｌｉｎｋ、Ｘｂａｓｅ及びＸｐｏｉｎｔｅｒのようなＸＭＬ規格、並びにＨＴＴＰ（Ｓ）及びＵＲＩのような汎用ウェブ規格に依存する。

今日のほとんどのウェブサービスは、単純なウェブサービスである。単純なウェブサービスとは、信頼性のない同期式のＨＴＴＰ（Ｓ）トランスポートを使用し、そしてトランスポートレベルのセキュリティ以外のセキュリティをサポートせず、又、通信当事者によりプライベートに理解されるペイロード内のセキュリティ情報に合意するだけである。単純ウェブサービスは、操作（オペレーション）を含む。ウェブサービスを呼び出すことは、ウェブサービスの操作を呼び出すことを意味する。操作は、一方向メッセージを受け容れるか、或いは呼び出し者が応答を阻止しそして呼び出されたサービスが直ちに応答するような要求／応答パラダイムをサポートするように設計されてもよい。単純ウェブサービスは、ＲＰＣプログラミングパラダイム、又はドキュメントベースのプログラミングパラダイムを使用してもよい。

規格に適合するウェブサービスで発生する課題は、企業のビジネス業績を改善するために高性能ウェブサービスを定義することである。このようなウェブサービスは、ＳＭＴＰ、ＪＭＳ、プライバシー（暗号化）、完全性（署名）、認証及び許可、並びにルーティングのような信頼性の高い（厳密に１回）、非同期トランスポートでの呼び出しをサポートする。

発生する別の課題は、コラボレーティブウェブサービスを定義することである。これらのウェブサービスは、他のウェブサービスとの長時間の相互作用を保持し、そしてコレオグラフィー型会話（入力と応答のやり取り）の内容をもたない非コラボレーティブウェブサービスを呼び出すことがある。このようなコラボレーティブウェブサービスは、会話における関連メッセージを相関するためのサポートと、返送アドレスのサポートとを必要とする。

Ｂ２Ｂ及びＡ２Ａ電子商取引に適用可能な規格を拡張するための業界のイニシアティブは多数ある。コレオグラフィーの作業ＯＡＳＩＳからのｅｂＸＭＬ／ＢＰＳＳ、ＩＢＭからのＷＳＦＬ、及びマイクロソフトからのＸＬＡＮＧを含む。会話（入力と応答のやり取り）の作業は、ＯＡＳＩＳからのｅｂＸＭＬ／ＴＲＰ、及びマイクロソフトのＷＳルーティングを含む。付加的な作業は、ＩＢＭ、マイクロソフト及びＢＥＡシステムズからのＢＰＥＬ４ＷＳ（ウェブサービスのためのビジネスプロセス実行言語）と、サンマイクロシステムズからのウェブサービスコレオグラフィーインターフェイスと、ＷＳＣＬ（ウェブサービス会話言語）及びＢＰＭＬ（ビジネスプロセスモデリング言語）とを含む。

非常に多数のコレオグラフィー活動が進行中であって、幾つかの業界リーダーは、２００２年の９月、Ｗ３Ｃ規格団体の「ウェブサービスアーキテクチャーワーキンググループ」に、非互換性を解決する規格を制定するよう求めた。信頼性については、マイクロソフトからの提案、ＯＡＳＩＳからのｅｂＸＭＬ／ＴＲＰ、及びＩＢＭからのＨＴＴＰＲが存在する。Ｗ３Ｃは、これら全ての領域における規格化を検討している。重要な業界の活動家は、ＷＳＩと称されるライバルのコンソーシアムを形成した。しかしながら、それらは、サービス展開及びコレオグラフィー問題に向けられたものではない。

従って、ドキュメント交換コレオグラフィーの展開をサポートする方法及び装置を開発することが必要である。

本発明は、ドキュメント交換コレオグラフィーをサポートするコンピュータベースの装置及び方法に係る。より詳細には、本発明の態様は、コレオグラフィーバージョン、サービスバージョン、及びドキュメントバージョンの種々の組合せによりシステムの展開を容易にする装置及び方法に係る。又、本発明は、コレオグラフィーエージェントを使用してコレオグラフィー管理を行なうと共に、非コレオグラフィーイネーブルアプリケーションへのコレオグラフィーイネーブルインターフェイスを与える。本発明の更に別の態様は、多数のコンテクスト設定フランチャイズ型サービスとして、ホストサービスのグラフィックデザインツール及び透過的（トランスペアレント）エイリアシング（aliasing）を包含する。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記述する。

以下、添付図面を参照して詳細に説明する。本発明を例示するために好ましい実施形態を説明するが、これは、特許請求の範囲により規定された本発明の範囲を限定するものではない。当業者であれば、以下の説明に基づいて種々の同等の変更がなされ得ることが理解されよう。

コミュニティ及びコミュニティのネットワークは、ドキュメント交換コレオグラフィーを実施するコンピュータ支援型装置及び方法が有用となる１つの環境である。これらのコミュニティの中で、あるコミュニティは、そのコミュニティの一部分であるユーザ、会社、サービス及びコネクタのような情報を含むローカルレジストリーを維持する。コミュニティは、市場、企業、又は事業部でよい。コミュニティは、１つ以上のコミュニティネットワークに所属することができる。通常、コミュニティ及びネットワークは、ある共通のビジネス利益を有する。１つ以上のコミュニティネットワーク内のメンバーコミュニティ間で相互操作がなされる。コミュニティのネットワークは、コミュニティのグローバルレジストリーを利用できるようにする。このグローバルレジストリーは、コミュニティをルックアップし、そしてそのコミュニティ又は外部コネクタへの１つ以上のルートを決定するのを許し、上記外部コネクタは、それを経てコミュニティへ向う電子商取引ドキュメントをルーティングできるものである。

１つのコミュニティから別のコミュニティへルーティングされるドキュメントは、２つのコミュニティについては外部コネクタ間で直接ルーティングされてもよく、或いは１つ以上の中間コミュニティを経て間接的にルーティングされてもよい。又、コミュニティを伴うトランザクションに対するビジネス及びセキュリティルールも定義して、コミュニティレジスタに維持すことができる。

コネクタとは、他のアプリケーションと通信するアプリケーションに対する一般的用語である。コネクタは、ハブ、ゲートウェイ、外部ポート、中央コネクタ等として機能する他のコネクタを通してピア対ピア（Ｐ２Ｐ）ベース又は指令ベースで通信することができる。Ｐ２Ｐで通信するコネクタは、同じトランスポート／エンベローププロトコルを使用する他のコネクタと通信することができる。Ｐ２Ｐで通信するコネクタは、任意であるが、同じトランスポート／エンベローププロトコルを使用しないコネクタと通信を試みるときに、変換サービスを実行する他のハブコネクタの協力を得てもよい。指令ベースで通信するコネクタは、ルーティングルールに基づいてハブコネクタを経て通信する。コネクタ間のルーティングルールは、１つ以上のトランスポート／エンベローププロトコルに対して１つ以上のハブ及びスポークトポロジーをサポートするように、指令グラフにマップすることができる。ハブ及びスポークトポロジーは、１つ以上の結合子(tier)においてスポークに沿ってハブへの通信を指令する。これは、勘定、ビジネスインテリジェンス収集、追跡、監査、会計、その他の集中サービスを容易にする。

異なるトランスポート／エンベローププロトコル及びテクノロジーをサポートするために、多数のハブ及びスポーク組織が同じコネクタをオーバーレイしてもよい。例えば、ＨＴＴＰ又はＨＴＴＰＳを使用するのではなく、ソニック(Sonic)をトランスポートテクノロジーとして使用するために、より強いハブ及びスポーク組織が必要とされてもよい。任意であるが、通信ルートは、発信元及び宛先が同じコミュニティの一部分であるかどうかに依存してもよい。準コミュニティ（全コミュニティを含んでもよい）内で、集中機能が不要とされ、そして他の準コミュニティ内の宛先と通信するときに親コネクタと通信するよう指令されたコネクタ間でＰ２Ｐ通信が許可されてもよい。

コネクタは、単純コネクタ（時々単にコネクタと称される）、ハブ（時々ゲートウェイ又はルーターと称される）又は中央コネクタにラベル付けされることができる。或いは又、それらは、機能的に記述されてもよい。単純コネクタは、同じ準コミュニティ内のコネクタ間でＰ２Ｐ通信することが許されるとき以外は、ハブコネクタを経て通信するよう指令される。いわゆるハブは、それらに明確に向けられ又はリンクされるコネクタにより使用される。ハブは、２つ以上の機能を果たすことができ、従って、送信元から宛先へのルートにおいて２回以上現われることがある。

ハブは、電子商取引のドキュメント又はメッセージを転送する。又、ハブは、共通のエンベローププロトコルをサポートするトランスポートプロトコル間で変換を行ってもよい。例えば、ハブは、エンベローププロトコルを変換し、そして受信時ではなく送信時に異なるトランスポートプロトコルを実施してもよい。中央コネクタは、ハブの特殊なケースであり、それらに明確に向けられもリンクもされないコネクタにより使用することができる。中央コネクタは、例えば、ルーティングルールに基づいて送信元からコネクタを横断することが、宛先によって使用されるトランスポート／エンベローププロトコルをサポートするハブに至らないときに、変換機能を実行するのに有用である。

規格という点で、ＷＳＤＬは、いわゆるサービス定義（ＷＳＤＬがポート形式（porttype）と称する）、サービスインスタンス（サービス）、及びコネクタ（ポート）を定義するのに使用される規格ベースの言語である。サービス定義は、クラス定義と同様である。ＷＳＤＬは、サービス形式を命名し、本質的にサービスのメソッドであるサービス定義のための１組の操作を定義し、そして操作の入力／出力メッセージを定義する。ＷＳＤＬにより指定される操作の形式は、通知（１つの外方に向うメッセージ）と、一方向（１つの内方に向うメッセージ）と、勧誘／応答（同期、１つの外方のメッセージの後に１つの内方のメッセージが続く）と、要求／応答（同期、１つの内方のメッセージの後に１つの外方のメッセージが続く）とを含む。ＷＳＤＬは、サービス間の相互作用のコレオグラフィーを取り扱わない。

本発明の態様は、ＷＳＤＬを大きく越えて、サービスにおけるコレオグラフィー処理操作に向けられる。コラボレーティブ操作は、コラボレーティブ相互作用により呼び出され、ここで、１つのサービスインスタンスにおける操作が別のサービスインスタンスにおける操作を呼び出す。２つのサービスインスタンス間のコラボレーティブ相互作用は、単一の会話の一部分であり、ここで、会話は、メッセージの双方向フローであると共に、コレオグラフィーインスタンスである。会話におけるメッセージは、通常、会話ＩＤと、適用コレオグラフィーと、サービス／操作の開始の識別又はそこへの復帰アドレスとを含む。

図１は、本発明の多数の態様を組み合わせて、会話としてコレオグラフィー処理される特定のメッセージ交換に対して、ドキュメントバージョン及び変換１０１、サービスバージョン１０２及びコレオグラフィーバージョン１０３を動的に決定するための能力を示す。これらの動的な決定は、幾つかの関連出願に述べられていると共に、以下に説明する。

ＷＳＤＬにおけるメッセージは、名前と、１組の部分とを有する。各部分は、名前と、ＭＩＭＥコンテンツ形式と、ＸＭＬの場合に部分に対するスキーマ定義とを有する。

本発明は、ＸＭＬ部分に対する明確なスキーム（構成）定義ではなく、ドキュメントバージョンの動的な決定をサポートするドキュメントファミリーの概念を追加する。ドキュメントファミリーとは、そのスキーム（構成）がドキュメント構造を定義するような１組のドキュメントバージョンである。これは、２つの相互作用するサービスが、ドキュメントの異なるバージョンをサポートできるようにする。必要なターゲットドキュメントスキーマに対して送信元ドキュメントへ変換するためのバージョン変換ロジックが設けられる。これは、そのドキュメントを使用して互いに相互作用するネットワーク内の全てのサービスをアップグレードせずにドキュメントバージョンを展開できるようにする。これは、いわゆるドキュメントバージョン相互作用であり、上述した特許出願「Registry Driven Interoperability and Exchange of Documents」に詳細に説明されている。

本発明は、動的に決定できるサービス定義バージョンの概念を導入する。新たなバージョンは、既存のイン／アウトパラメータ又はドキュメントに新たな任意の部分を追加したり又は既存の任意の部分を削除したりできると共に、サービスの初期バージョンに新たな操作を追加することができる。バージョン番号がメッセージアドレスにおけるサービス定義名の一部分ではないので、初期バージョンを使用するサービスインスタンスは、サービスインスタンスのアップグレードされた新たなバージョンで正しくアドレスすることができる。（アドレスは、通常、当事者／サービス定義名／操作）を含む。）

一般に、サービス定義は、定義に従うサービスインスタンス（時々、単にサービスと称される）に対するテンプレートである。サービステンプレートを定義することは、形式を定義することと同様であるが、サービスインスタンスを定義することは、その形式の変数を定義することと同様である。サービス定義は、名前及びバージョンを有し、そしてサービスにおけるアクティビティのリストを、１つ以上のアクティビティインターフェイスと共に定義する。インターフェイスは、サポートされるドキュメントを明確に識別せず、少なくとも、サポートされるドキュメントファミリーを識別する。ドキュメントファミリーは、同じビジネスファンクションをもつ１組のドキュメントである。例えば、「ｐｕｒｃｈａｓｅ ｏｒｄｅｒ（購入注文）」は、ドキュメントファミリーであり、そしてｘＣＢＬ３．５ ｐｕｒｃｈａｓｅ ｏｒｄｅｒ及びＲｏｓｅｔｔａｎｅｔ１．０ ｐｕｒｃｈａｓｅ ｏｒｄｅｒは、そのファミリーのメンバーである。

サービス定義は、コミュニティのアドミニストレータにより確立されてもよいし、Ｃｏｍｍｅｒｃｅ Ｏｎｅのような売主から採用されてもよいし、或いは将来、規格団体により定義されてもよい。サービスインスタンスは、使用するドキュメントの実際のバージョンを指定することによりインターフェイス定義を完了する。又、インスタンスは、サービスのポリシー、及びサービスをオファーするＣＰも指定する。又、それがホストされるコネクタも指定する。サービスインスタンスによりメッセージを送信及び受信する。サービスインスタンスにおけるアクティビティは、単一コネクタにおいてホストされるのが好ましい。

コレオグラフィー定義言語は、一般に、役割間のメッセージのフローを定義する。ＷＳＤＬは、役割のサービスインタフェースを定義する。しかし、コレオグラフィー定義言語は、ＷＳＤＬと合体しない。欠落は、コレオグラフィーとサービスとの間の明確なバインディングである。本発明の１つの態様は、コレオグラフィーの役割をサービスインスタンスへマッピングすると共に、コレオグラフィーメッセージをサービス操作のイン／アウトパラメータへマッピングすることを含む。これは、上述した特許出願「Dynamic Interface between BPSS Conversation Management and Local Business Management」に詳細に説明されている。

本発明は、サービスがサポートする一組のコレオグラフィー（例えば、名前で識別される）と、動的に決定できるそのコレオグラフィーにおける役割とを、サービス定義が定義できるようにする。サービスインスタンスは、それがサポートするコレオグラフィーのサブセットを指示し、そしてサポートされたコレオグラフィーの中で好みの順序を指示することもできる。実行時に、参加するサービスインスタンスの中でそれらサポートされたコレオグラフィーの交差が計算され、そしてコレオグラフィーの特定のバージョンが、メッセージ交換で使用するために選択される。１つ以上のサービスの好みを要因に分けて、どのコレオグラフィーバージョンを使用すべきかの判断を行うことができる。要因に分けるのに、開始者の勝ち、応答者の勝ち、最新バージョンの勝ち、最初のバージョンの勝ち、又は好みの重み付けなどのルールが使用されてもよい。或いは又、使用すべきコレオグラフィーバージョンを指定する２つのサービス間の合意を予め定義することもできる。全てのコレオグラフィー参加者は、コレオグラフィー処理の会話において全ての後続メッセージに対して同じコレオグラフィーを使用する。これは、全ネットワークにおける全てのサービスを必要とせずに、展開すべきコレオグラフィーがアップグレードできるようにする。これは、いわゆるコレオグラフィーバージョン相互操作である。この相互操作は、コレオグラフィーを記述するのに使用される言語とは独立して達成されるが、コレオグラフィーの意味をその名前から理解すると、サービスに依存する。

コレオグラフィーバージョンを選択するか又はサービスバージョンを発見する２つの方法を、図２及び３に示す。図２では、第１サービス２０１と第２サービス２０２との間でバージョンに関する情報を交換するためにメッセージが使用される。この解決策は、第１メッセージが他の全てのサービスに送信されるか、又は付加的な第１メッセージが第２又はそれ以降のサービスから他のサービスへ送信されるようにして、３つ以上のサービスへと拡張することができる。コレオグラフィーにおいて、例えば、コレオグラフィーの異なるバリエーション及びバージョンにおける第１メッセージ２１１は、実質的に同じである。ドキュメントバージョンを考慮して、メッセージが若干異なってもよい。第１メッセージにおける他の小さなバリエーションは許されるが、第１メッセージは、全てのコレオグラフィーバージョンとの適合が保たれる。使用するコレオグラフィーが第１メッセージにおいて選択された後、サービスとサービスとの間のいずれかの方向における全ての後続メッセージも、このコレオグラフィーの一部分である。

コレオグラフィーバージョンが選択された後に、その後続メッセージ２１２−２２４は、選択されたコレオグラフィーに合致する。図３において、１つ以上のレジストリーへの参照を使用して、第１サービス及び第２サービスによりサポートされるバージョンに関する情報を発見する。発見プロセスに対してローカルなサービスは、メソッド３２１にアクセス可能な第１レジストリー３３１にバージョン情報を記憶することができる。リモートサービスは、メソッド３２３にアクセス可能な第２レジストリー３３２にバージョン情報を記憶する。ある場合には、リモートサービスの情報は、第１レジストリー３３１にあり、メソッド３２２にアクセス可能である。例えば、第１及び第２サービスが同じコミュニティにあって、同じレジストリーに依存する場合である。或いは、第１及び第２サービスが最近コンタクトしていて、第１サービスが第２サービスの情報を第１レジストリーにキャッシュしている場合である。両サービスによりサポートされるバージョンに関する情報は、バージョン選択ロジック３１１により考慮される。

従って、本発明の態様は、ドキュメントバージョン、サービスバージョン、及びコレオグラフィーバージョンの幾つか又は全部を動的に決定するように多数のやり方で結合することができる。本発明により実施されるように、ウェブサービスは、実質的に更新できると共に、同様に更新されなかった他のサービスとの相互操作性を保持することができる。

本発明の更に別の態様は、複雑なコレオグラフィー及びビジネスプロセスを、インターネット又は別のネットワークにわたり分布されたコラボレーティブなウェブサービス間で、いわゆるピア対ピア相互作用又はコラボレーティブ相互作用において、定義して実行することができる。又、レガシーウェブサービス実施において一般的である標準クライアント／サーバー相互作用（又はコラボレーティブな相互作用）もサポートする。ピア対ピア相互作用では、コレオグラフィーサポートは、サービス間で交換される関連メッセージを相関させ、そして会話メッセージに復帰アドレスを含ませる。

コラボレーティブサービスは、非コラボレーティブウェブサービス又は他のアプリケーションインターフェイスとの仮想会話を有してもよい。基本的に、２つのサービスは、互いにクライアント／サーバー相互作用を使用し、そして帯域から戻りアドレスを知る。これらサービスは、メッセージペイロードを検査するアプリケーションロジックを使用してメッセージを相関させる。

コラボレーティブサービスは、ゼロ又はより関連付けられたコンテクストを有する。１つ以上のトリガー操作により新たなコンテクストが生成される。或いは又、コンテクストが自発的に（メッセージングの観点から）開始されてもよい。その後の非トリガー操作の開始は、このコンテクストに結合される。プロセスフローインスタンスは、参照されるコンテクストである。１つの操作がプロセスインスタンスをキックオフし、そして全ての後続メッセージがこのインスタンスに関連する。このコンテクストは、開始者との双方向会話と、コンテクストにより駆動される他のサービスとの双方向会話とを有する上で助けとなる。非コラボレーティブサービスについては、各操作がそれ自体で完全であり、開始者は、いずれかのプログラムでよく、サービスである必要はなく、そしてサービスにおいて他のすべての操作を呼び出すこととは無関係である。

より一般的には、当事者間に２つの形式のメッセージ相互作用がある。ピア対ピアメッセージは、通常、コレオグラフィーに関連している。ピア対ピア相互作用では、若干の付加的な情報断片が与えられる。通常、送信ＣＰ、サービス定義、及びアクティビティ定義を識別する復帰アドレスが与えられる。会話ＩＤ及びコレオグラフィーＩＤ並びにリファーズ・ツー・ＩＤ(refers to ID)のようなメッセージ相関データが与えられる。復帰アドレスは、呼び出されたサービスが応答すべき場所を識別する。このサービスを更に助けるために、この相互作用に使用される適用可能なコレオグラフィーは、会話の各メッセージにおいて両サービスへ戻すことができる。会話ＩＤは、２つのサービス間の会話における各メッセージに対して同じ値を有する。これは、サービスが関連メッセージを容易に相関させられるようにする。コレオグラフィーＩＤは、第１メッセージにおいて選択され、そして会話に対して同じに保たれる。リファーズ・ツー・ＩＤは、応答であるところのメッセージのメッセージＩＤを指す。単一のメッセージが多数の応答を有してもよい。

第２形式のメッセージ相互作用は、クライアント／サーバー相互作用（非コラボレーティブ相互作用とも称される）である。クライアント／サーバー相互作用では、通常、送信サービス／アクティビティが存在しない。要求及び任意の単一応答は、通常、交換を完了し、そしてその後のクライアント／サーバー相互作用は、これに関連しない。

クライアント／サーバーの１つの特別な態様は、要求／応答呼び出しにおける応答に対する変換サポートである。ピア対ピア相互作用では、送信サービスは、そのインターフェイスにおいて、どんなドキュメントが応答で予想（期待）されるかについて言及する。しかしながら、クライアント／サーバーでは、このようにならず、要求者は、要求において、応答で期待されるドキュメントについて言及しなければならない。要求者が、ある部分に対して予想されるドキュメントを指定しない場合には、応答者により発生されるドキュメントが、変換されずに送信される。

サービスは、複数のドキュメント交換アクティビティインターフェイスを含んでもよい。ドキュメント交換アクティビティインターフェイスは、サービスインスタンスが登録されるときにサービス定義の一部分として定義され（及びカスタマイズされ）てもよい。アクティビティは、そのインターフェイス及びそのポリシーにより記述される。例えば、ＵＩサービスは、それらのアクティビティを特権決定(privilege determination)のためにレジストリーに登録し、そしてシングルサインオンウェブエージェントやリソース経路のような他のアクセス制御情報を登録してもよい。

アクティビティは、図４に示す４つの形式のものがある。要求／応答４１１：このアクティビティは、要求及び応答を受け取る。勧誘／応答４１２：これは、要求／応答の逆インターフェイスである。勧誘応答アクティビティは、別のサービスインスタンスにおいて要求／応答アクティビティを呼び出してもよい。一方向４１４：これは、非同期メッセージを受信するアクティビティである。通知４１３：これは、一方向の逆インターフェイスである。通知アクティビティは、別のサービスインスタンスにおける一方向アクティビティを呼び出す。これらの定義は、ＷＳＤＬと一貫したものである。

アクティビティへの入力又は出力をメッセージと称する。メッセージは、多数の部分で構成される。これらの部分は、次のように説明される。部分の名前は、その部分のアクティビティからの／アクティビティへの各メッセージに対して再使用されるその部分固有の名前である。部分の形式は、ＸＭＬ部分でもよいし、或いはＭＩＭＥ形式により説明される部分でもよい。部分が、定義されたＭＩＭＥ形式をもたない場合には、その部分に対するＭＩＭＥ形式を、実行時に、呼び出し者により供給することができる。

部分の位置は、その部分が本体内であるか又はアタッチメントであるか指定する。或いは又、それがメッセージヘッダにあってもよいし、或いはそれがメッセージの外部にあって、メッセージがそれだけを指してもよい。部分は、必要とされてもよいし、任意であってもよい。ルート(root)のインジケータ：メッセージには１つのルート部分がなければならない。これは、通常、メッセージのメインテーマであり、通常、ＸＭＬ部分である。ルート部分は、他の部分を見つけるための横断のスタート点を意味する。これは、他の部分への参照を含んでもよいが、必ずしも、それらの全部をルート部分からの横断により発見できなくてもよい。又、メッセージは、ドキュメントＩＤリストを含んでもよい。いかなる部分（ＸＭＬ又は非ＸＭＬ）も、ドキュメントファミリーに属することができる。ドキュメントファミリーのメンバー（ドキュメントＩｄと称される）に関連付けられるのは、記述子情報、任意であるがスキーマ、及び任意であるがこのメンバーからの／このメンバーへの種々の形式の変換マップである。ドキュメントファミリーのメタデータは、サービスとは独立して（無関係に）登録される。

コレオグラフィック処理されたサービス内で、プロセスフローを使用して、インターフェイスの両側でアクティビティを整合することができる。プロセスエンジンにおいてデザインツール及び定義実行を使用して定義されるプロセスフローの概念が、他のコンテクストにおいて使用されている。例えば、Ｃｏｍｍｅｒｃｅ Ｏｎｅは、ＣＰＭと称するプロセスフロー解決策を有する。プロセスは、潜在的な分岐ポイント及び並列な実行スレッドを伴うフローを定義する。プロセスインスタンスには、コンテクストが関連付けられ、そしてある事象により開始されて長時間継続する。このコンテクストは、他の事象によりトリガーされる一連の状態遷移を通過し、そしてプロセス自体は、フローの一部分として事象を開始することができる。これら事象は、ＵＩ相互作用、ドキュメント交換事象（ドキュメントペイロードを伴う送信又は受信メッセージ）、コンテクスト状態又は関連データベース状態の変化、或いはビジネスロジックの呼び出しを含んでもよい。

図５は、アクティビティと内部プロセスとの間の相互作用を示す。アクティビティ４１１から４１４は、プロセスフロー５２１から５２５とメッセージを交換する。プロセスフローステップは、それら自体の間にメッセージを渡す。別のインスタンスでは、プロセスフローは、プロセスの分岐及び並列実行を含むことができる。

又、プロセスエンジンにおいて実行される内部プロセスフローは、図６に示すように、コレオグラフィーを集中的に管理するコレオグラフィーエージェントを構成するのに使用できる。コレオグラフィーは、全てのメッセージフローをコレオグラフィーエージェント６１０に通過させることにより集中的に管理することができ、このコレオグラフィーエージェント６１０自体は、コラボレーティブウェブサービスとして現われ、そして内部プロセスフロー６１２を使用する。コレオグラフィーエージェントに適応されて、サービス６３０からサービス６４０へのメッセージは、サービス６３０から中間サービス６１０へのメッセージに切り換えられ、この中間サービスがそのメッセージをサービス６４０へ転送する。サービス６４０からサービス６３０へ戻る非同期応答は、サービス６４０から中間サービス６１０へのメッセージに切り換えられ、この中間サービスがそのメッセージをサービス６３０へ転送する。コレオグラフィーエージェント６０１は、メッセージが渡されるインターフェイス６１１、６１３、６１４を含む。

内部プロセスフロー６１２を使用して、１つ以上のコレオグラフィーの状態を追跡することができる。内部プロセスフローステップの幾つか又は全部が、コレオグラフィー処理されたメッセージの交換が完了せずに終了する場合に使用されるべき情報を、トランザクションロールバックログに記憶することができる。コレオグラフィーエージェントを通過して整合される１つ以上のコレオグラフィーインスタンスの状態の問い合せをサポートするために、インターフェイスを追加することができる。同様に、アクティビティの統計学的情報をコレオグラフィー整合中にコンパイルして、インターフェイスを通過して報告することができる。この集中化は、コレオグラフィーの状態を追跡のために容易に問い合せできるようにする。エラー処理及びエラー補償アクションを更に容易に実施することができる。中間サービスがプロセスフローとして実施されるときには、内部プロセスフローがプロセス定義に適合するので、コレオグラフィーは、おそらく全体的に正しいものとなる。コレオグラフィーが正しいかどうかの全体的なチェックは容易にされる。

プロセスエンジンにおいて実行されるプロセスフローは、事象をトリガーするメッセージを得て、それらのメッセージを、事象を処理する一部分として送信する。これらのメッセージは、ＷＳＤＬのような標準的ウェブサービス定義言語を使用して記述することができる。これらの記述は、ＵＤＤＩのような標準レジストリーで容易に発見することができる。それ故、これらのメッセージは、ウェブサービスへと一緒にグループ編成することができる。メッセージングシステムは、このサービスのアクティビティに対するメッセージを、フローを実行するコネクタへルーティングすることができる。ある操作は、新たなプロセスインスタンスに着手するセマンティック（意味）をもつことができる。これらの操作に対するメッセージは、新たなプロセスインスタンスを生じる。他の到来するメッセージに対して、コネクタのディスパッチャーは、ペイロードコンテンツに基づくインスタンス、プロセスインスタンスの状態（特定のメッセージが特定の操作に対して待機するようなステップにある場合に）、或いはメッセージエンベロープにおけるメッセージ相関データ（到来するメッセージが以前の出て行くメッセージに対する非同期応答であるときに有用な）を推論することにより、既存のプロセスインスタンスへメッセージをリンクすることができる。

多数のプロセスエンジン６１０、６２０、６３０、６４０において分散形態で実行されてそれら自体の間にそれらの内部状態を渡すプロセスフローは、互いに相互作用する一組のコラボレーティブサービスとして処理することができる。

本発明の更に別の態様は、呼び出される前にサービスへの申し込み(subscription)を任意に要求することである。サービス申し込みの間に、コラボレーティブサービスに対して、考えられるコレオグラフィーの１つを選択し、そして消費者及びプロバイダーの両方が使用するように合意することができる。又、アクセス制御のようなサービスの他の態様は、申し込み時に合意することもできる。

サービス指向のアクセス制御は、サービスへのアクセス及びサービスにおけるアクティビティ／操作の管理及び実施を容易にするために一緒に作用する３つの重要な概念、即ちサービス視認性、サービス申し込み、及びサービス特権又は許可、を有する。サービス視認性は、サービスプロバイダーが、誰がサービスを発見できるか指定できるようにすると共に、発見メカニズムが視認性に基づいて発見を制限できるようにする。サービス視認性ルールは、誰かを視認できる、アドミニストレータ／オペレータを視認できる、コミュニティにおける特定の当事者を視認できる、コミュニティにおける特定の役割を視認できる、ネットワークにおける何らかのコミュニティを視認できる、或いはネットワークにおける特定のコミュニティを視認できることを含む。

また、視認性は、コラボレーション当事者（時々、取引当事者又はパートナーと称される）にも適用される。ある当事者がコミュニティに登録されるときには、その当事者はデフォルト値としてコミュニティにおいて視認できる。更に、当事者は、ネットワークにおける何らかのコミュニティ、又はネットワークにおける特定のコミュニティを視認できるようにされる。又、サービス及び当事者情報は、指定の視認性ルールに基づいてパブリックＵＤＤＩレジストリーに押し込むこともできる。

また、各サービスアクティビティについては、申し込み時に（又はデフォルトによって）１組の特権(privilege)を確立することができる。各サービスに対し、アプリケーションは、実際には特権グループであるサービス役割を指定することもできる。特権については、「特権が、特定組織単位の範囲をサポートするかどうか」、「特権がサービス役割の一部分として使用できるだけであるかどうか」、等々の付加的な詳細を指定することができる。又、サービスは、誰かがそれを利用する前にある種の申し込みを要求するかどうか指定することもできる。例えば、供給者は、オーダー管理サービスにおいて、買手が申し込みの後にのみこのサービスにオーダーを送信できることを指定してもよい。

申し込みプロセスは、サービスプロバイダーが、申し込み者に関する情報と、申し込みサービスの能力とを、必要に応じて受け取ることができるようにする。この情報に基づいて、サービスプロバイダーは、申し込みを承認するか又は拒絶するか選択することができる。ある当事者のアドミニストレータがあるサービスに申し込みすると、申し込まれたサービス内でサービス役割及び／又は特権をグループ編成しそしてこれらのユーザ役割をユーザ口座に指定することにより、それら自身の組織内でユーザの役割を生成することができる。

コレオグラフィー型相互作用をサポートするための別の主要課題は、バックオフィスシステムである。サービスコンポジションエージェントの使用で、バックオフィスシステムの一体化に関連した問題に対処することができる。バックオフィスシステムは、通常、コレオグラフィー型会話をサポートするＳＯＡＰ拡張を理解しないし、そのＳＯＡＰ拡張は、メッセージ相関及び復帰アドレス指定をサポートするための拡張を含んでいる。それ故、図７に示すように、バックオフィスシステムの単純なウェブサービスインターフェイスへと双方向にマップされるコラボレーティブウェブサービスインターフェイスをコンポジションエージェントが露出させることが有用である。コンポジションエージェントは、ペイロードに対してルールを実行することにより関連メッセージを相関させ、そしてアプリケーションからのピア対ピア呼び出しメッセージからアプリケーションの復帰アドレスを推論する。バックオフィスシステムは、それらの機能を異なる仕方で提示し、従って、通常、各バックオフィスシステムに対してサービス定義の異なるセットが存在する。コンポジションエージェントは、多数の進化するバックオフィスシステムを単一のインターフェイスに与えることによりそれらの追跡を簡単化する。コンポジションエージェントは、正しいバックオフィスサービス及びアクションを選択する。バックオフィスシステムは、種々のＸＭＬドキュメント定義がＥＡＩインターフェイスで増強されたときにそれらの定義をサポートする。それらは、例えば、ｘＣＢＬ、ＩＤＯＣ、ＯＡＧＩ、等を含む。本発明の態様は、この種々の定義言語を使用して定義されたドキュメントを、単一ドキュメントファミリーのメンバーとして処理できるようにする。変換ロジックを呼び出して、ドキュメントファミリーメンバー間でメッセージを前後に変換することができる。

バックオフィスシステムへのＥＡＩインターフェイスは、通常、厳格なセキュリティや信頼性のあるメッセージング等をサポートしない。コンポジションエージェントは、それ自身と問合せサービスとの間でセキュリティ、信頼性等をサポートすることができる。コンポジションエージェントは、頑丈さ及びセキュリティがあまりない解決策を、バックオフィスシステムと最後のネイティブコネクタとの間の最後のホップに使用することもできるし、或いは特殊なセキュリティ及び信頼性手段を採用することもできる。

コンポジションエージェントのサービスは、バックオフィスシステムにより開始される会話を含むバックオフィスシステムとの会話に対して論理的ルーティング（ペイロード検査及び／又はレジストリールックアップによりターゲットアドレス選択）をサポートすることができる。メッセージの相関が図７に示されている。バックエンドシステムのような非コレオグラフィーイネーブルシステム７１０は、イネーブルプロセス又はコンポジションエージェント７２０と通信する。これらの通信は、コンポジションエージェントが受信するメッセージ７２１、７２２、７２３内にフィールドを指定することにより、その一部が構成される。

メッセージ相関ロジック７２４は、メッセージを新たな又は進行中のコレオグラフィー７２５と相関させるのに使用できる。このコレオグラフィーは、上述したように、内部プロセスとしてモデリングすることができる。相関ロジック７２４は、バックエンドシステムからの各メッセージをそれが受信したときに処理するために、メッセージフローに配置することができる。或いは、プロセスフロー７２５におけるプロセスステップに利用可能なリソースがあってもよい。相関ロジック７２４の配置は、そのアクション、即ちバックオフィスアプリケーションインターフェイスにより発生されたメッセージを検査し、そしてフィールドの指定を使用して、バックオフィスメッセージをコレオグラフィーインスタンスと相関させることよりも重要性が低い。

相関ロジックは、バックオフィスシステムにより開始される会話へと拡張することができる。相関ロジックが、メッセージの送信元が常に会話を開始すると決定するか、或いはメッセージの指定フィールドと相関する既存の会話がないと決定すると、相関ロジックは、新たな会話インスタンスを生成する必要があることを信号できる。相関ロジックは、更に、指定のフィールドを使用して、どんなコレオグラフィーを呼び出さねばならないか決定することができる。例えば、バックオフィスシステムは、供給者オーダーを開始してもよい。供給者名フィールドを使用して、適切なＣＰと、このＣＰが新たなオーダーを受信するために利用するサービスとを識別することができる。そのサービスに関連したコレオグラフィーを呼び出すことができる。コンポジションエージェント７２０は、標準インターフェイス７２６、７２７を経てコレオグラフィーイネーブルサービス７３０に提示される。１つ又は多数のサービスがそのサービスインターフェイスを経てコンポジションエージェントと相互作用することができる。コンポジションエージェント及び相関ロジックは、コレオグラフィー型会話の状態を追跡し、そしてバックオフィスシステム７１０と交換されるメッセージを、他のサービス７３０と交換されるメッセージに使用される適当な会話ＩＤに相関させる。

本発明の別の態様は、単一ホスト型サービスを、ホストによりフランチャイズ処理される複数のエイリアシング(aliasing)を経てサービスフランチャイズへ提示することである。ブリック・アンド・モルタル(brick and mortar)ビジネスにおけるフランチャイズとは異なり、これらのフランチャイズは、ホストの認識を広告することは期待されない。ある意味では、これらのサービスフランチャイズは、ＯＥＭ商品のプライベートラベラー(private labeler)に良く似ている。フランチャイズ型サービスは、他のサービスと相互作用するように登録することもできるし、或いはホストがサポートするように設計された１つ以上のバックオフィスシステムへルーティングすることもできる。

図８及び図９は、通常の非フランチャイズ型サービスと、フランチャイズ型サービスとの間を区別するのに役立つ。図８において、サービス８１０のレジストリーには２つのサービス８１１、８１２が現われている。非フランチャイズ型の構成では、これらのレジストリーエントリーは、同じサービスロジックの２つの異なるインスタンス８３１及び８３２に対応する論理的アドレスを与える。サービスロジックのこれらインスタンスは、２つの異なるウェブサーバーで実行されるサーバーインフラストラクチャーソフトウェアの２つのライセンス付きコピーに類似している。図９において、サービス９１０のレジストリーには３つのフランチャイズ型サービス９１１、９１２、９１３が現われている。これらのフランチャイズ型サービスは、異なる論理的アドレスを有する。それらは、全て、ホストサービス９２１に論理的に接続され、該ホストサービスは、フランチャイズ型サービスと同様にレジストリーを通して提示されない。異なる論理的アドレスに送信されるメッセージは、３つのフランチャイズ型サービスのフランチャイジーに対応する異なるコンテクストにある。フランチャイズ型サービス９１１、９１２、９１３とホスト９２１との間の論理的関係により設定されたコンテクストでは、ホスト９２１をフランチャイズさせたフランチャイザーが、各登録されたサービスに対してロジック８３１、８３２の実行中インスタンスではなく、ホストロジック９３１の１つのインスタンスを使用することができる。

市場オペレータがオーダー管理アプリケーション（サービスの集合）をホストとなるように使用するケースを考える。１組の供給者が、次いで、このホストサービスパッケージをフランチャイズし、それらに対する全てのオーダーを管理する。このケースでは、フランチャイズへのメッセージは、＜franchisee CP＞、＜service definition＞、＜activity definition＞へアドレスされる。ＵＩ及びドキュメント交換サービスの両方がフランチャイズされる。実際の観点では、フランチャイズ型サービスを実施する１つの実施形態は、次のステップを含む。

１． サービスのホストインスタンスを生成する。
２． １組のホストサービスを一緒に収集することによりホストパッケージを生成する。ホストエンティティは、パッケージの所有者である。又、パッケージは、実際の実施が行われるコネクタに結合される。
３． フランチャイジーにより申し込まれた１組のサービスであって、フランチャイジーが受け取ったドキュメントを処理できるようにする１組のサービスをホストパッケージに関連付ける。これは、１つ以上のフランチャイジーがホストパッケージをフランチャイズできるようにしている。ステップ１及び２は、ある環境においては、コミュニティのアドミニストレータにより行なう必要があり、一方、ステップ３は、サービスプロバイダーにより行うことができる。

フランチャイズコラボレーティブサービスは、ホストサービスＣＰへのレジストリーにおいて認証を任意に委譲(delegate)することができる。その１つの理由は、フランチャイジーがそれ自身を完全に識別することを望まないために、フランチャイジーがフランチャイジーの信用証明の使用を望まないことである。このケースでは、フランチャイジーは、このフランチャイジーに代わってこのサービスからの全てのメッセージに対してホストＣＰへの認証を委譲(delegate)することになろう。

フランチャイズ型サービスは、コンテクストをセットすると共に全ての情報がホストサービスへと単に流れてホストサービスにより処理できる「パススルー(pass-through)」サービスに類似している。フランチャイズサービスは、ホストサービスへの参照を有し、そして一般に、ビジネスの必要性に基づいて幾つかのオーバーライドを許しながら、ホストから実施能力及びポリシーを継承する。フランチャイズサービスに直結された実施がないのが好ましい。カスタマイゼーションが要求される場合には、多数のホストサービスバリエーションを申し込むのが好ましい。或いは又、多数のコレオグラフィーがホストサービスによりサポートされてもよく、そしてコレオグラフィーのサブセットが特定のフランチャイズ型サービスに対してサポートされてもよい。フランチャイジーへのメッセージは、あたかもフランチャイジーがスタンドアローンサービスを操作するかのように、＜franchisee CP＞、＜service definition＞、＜activity definition＞へアドレスされる。サービス消費者は、通常の即ちフランチャイズサービスに、交換可能に申し込んで利用することができる。フランチャイジーと相互作用するサービス消費者は、フランチャイズ型サービスと非フランチャイズ型サービスに何ら差を見ることがない。

ホストサービスパッケージは、ホストアプリケーションにより一般に実施される全てのサービスより成るパッケージである。単一のホストアプリケーションは、多数のホストパッケージを公表することができる。ほとんどの場合に、ホストアプリケーションは、単一ホストパッケージを公表する。ホストサービスパッケージで束ねられるサービスは、２つの形式にグループ分けすることができる。ホストサービスの１つの形式は、フランチャイジーに代わってフランチャイズ型サービスとして「再オファー（再申し出）」される。別の形式は、フランチャイズ型サービスにより受け取られた情報を処理するためにフランチャイジーにより使用されるポータル（又はＵＩ）サービスを含むが、これは、フランチャイジーを越えて再オファーも提示もされない。例えば、オーダー管理パッケージは、規格ベースの「受け取りオーダー」サービスを有してもよく、又、他のＵＩサービス、例えば、「ビューオーダー」、「オーダーレポート」、「承認オーダー」、等を有してもよい。フランチャイジーは、オーダー管理パッケージをフランチャイズするために署名するとき、規格ベースのドキュメント交換サービスを経てオーダーを受け取るだけでなく、それらを見て承認する等々を行なうことができねばならない。ホストパッケージは、メッセージを送信又は受信するためにパッケージ内の各サービスに対してデフォルトコネクタとなるパッケージコネクタを有する。

フランチャイジーとホストプロバイダーとの間のビジネスプロセスは、フランチャイジーが、必要に応じて、オンライン承認プロセスにより、ホストパッケージをオンラインでフランチャイズできるようにされる。サービスプロバイダーがホストパッケージをフランチャイズするときには、フランチャイズ型サービスが自動的に生成されて、パッケージ内の各ホストサービスへパススルーとして登録される。更に、フランチャイジーは、フランチャイズが登録されるときに、パッケージ内の他の申し込みサービスに自動的に申し込む（ひいては、それを使用することが許可される）。

フランチャイズサービスは、上述したように、ホストサービスへの認証を任意に委譲(delegate)することができる。一実施形態では、ホスト側で認証を委譲するのに伴う実際のステップは、次のものを含む。
１．サービス（通常、ドキュメント交換サービスのみ）のホストインスタンスを生成し、２．パッケージの一部分としてフランチャイジーにより使用される通常のサービスを生成し、３．ホストパッケージを生成すると共に、フランチャイジーにより与えられたときにイネーブルされるホストサービスの集合を指定し、４．ホストサービスに対してメッセージを送信／受信するホストパッケージ用のコネクタを関連付け、５．フランチャイジーにより申し込まれたサービスのセットであって、フランチャイジーが受信したドキュメントを処理するのを許すサービスのセットを関連付け、６．フランチャイズが要求されたときに承認が必要とされるかどうかホストプロバイダーがパッケージにおいて指定でき、そして、７．デレゲートされた認証がこのパッケージにおいて許されるかどうかホストプロバイダーが指定できる。

フランチャイジーの側では、１．フランチャイジーがホストパッケージのフランチャイズを要求し、これが、ホストプロバイダーにより、必要に応じて、承認プロセスをトリガーし、２．ホストプロバイダーが、要求を承認するための通知を受け取り、そして要求を承認又は拒絶し、そして３．ホストプロバイダーが要求を承認する場合に、システムがフランチャイズパッケージを生成し、パッケージ内の申し込みサービスへ申し込み、そしてパッケージ内のフランチャイズ可能なサービスに対してサービスをフランチャイズする。

フランチャイズ型サービスの理解を容易にするために、オーダー管理システムに直面する供給者について考える。この説明において、このシステムは、ＳＯＭＳ（供給者オーダー管理システム）と称される。ＳＯＭＳは、買手からオーダーを受け取るために供給者により使用できるオーダー管理システムである。一実施形態では、ＳＯＭＳを設計しそして設定するのに次のステップが含まれる。設計者は、発表されるべきサービスを、フランチャイジーによりフランチャイズされるべきサービス（例えば、受け取りオーダー、チェックオーダー状態、等）、フランチャイジーにより使用（又は消費）されるべきサービス（例えば、ビューオーダー、承認／拒絶オーダー、オーダー統計学的情報／レポート、等）、及び他のアプリケーション又はバックオフィスシステムとの一体化（例えば、ユーザ管理システム、パブリックレジストリー、カタログシステム等との一体化）のようなＡ２Ａ（アプリケーション対アプリケーション）一体化に対してアプリケーションが提供するサービス、を含むグループへと分割する。

設計者は、全てのフランチャイジーが同じサービスセットを有するかどうか、又は異なるサブセットを潜在的に必要とするかどうか決定する。この必要性に基づいて、１つのホストサービスパッケージ、又は多数のホストサービスパッケージ、或いは又同じサービスの多数のコレオグラフィーを識別する。ホストサービスパッケージは、「フランチャイズされるべき(to-be-franchised)」サービス、及び「フランチャイジーにより使用するための(for-use-by-franchisee)」サービスを含まねばならない。一体化に使用される他のサービスは、通常、提供側ＣＰをアプリケーション又はホストプロバイダーとしてもつ通常のサービスとして登録される。

コミュニティ環境では、ホストプロバイダーは、通常、コミュニティオペレータであるが、コミュニティ内のコラボレーション当事者のいずれであってもよい。設計中には、「フランチャイズされるべき」サービスは、実際に、多数のサービスプロバイダーに代わってメッセージを受信及び送信することに留意されたい。従って、アプリケーションビジネスロジックは、メッセージを処理するためのコンテクストとしてメッセージ内のアドレスを使用する必要がある。ホストサービス実施は、到来するメッセージを見て、受信者ＣＰを算定すると共に、適当なビジネスプロセスへトリガー／マップしなければならない。ＵＩトリガーされるビジネスプロセスについては、ホストサービスが、フランチャイジーＣＰをプロセスコンテクストへの入力とみなし、そしてこれをプロセス内のデレゲーションポリシーに使用しなければならない。

少なくとも幾つかの実施形態では、設計及びコード化の後に、サンプルＳＯＭＳサービスを登録することが必要となる。フランチャイズされるべきサービス、フランチャイジーにより使用されるべきサービス、及びホストサービスパッケージそれ自体の登録は、図中、多数の設定スクリーンで示されている。登録の一部分は、フランチャイズされるべきホストサービスを登録することである。一実施形態では、レジストリーマネージャーＵＩを使用して、サービスに対する新たなサービス定義を生成する（それがまだ存在しない場合に）。

次いで、アプリケーションに対してコネクタを使用できることを確認する。これは、フランチャイザーに使用可能なデフォールトコネクタでもよいし、又はフランチャイザーのアプリケーションに対して登録される個別のコネクタでもよい。又、必要なドキュメント識別子がレジストリーにロードされたことも確認する。次いで、ホストサービスを次のように生成する。図１０は、ホストパッケージ管理スクリーンである。「Ｒｅｇｉｓｔｅｒ Ｎｅｗ（新規登録）」１００１をクリックする。図１１は、新規ホストサービスを登録する部分を示す。サービス定義１１０１を選択する。オペレータ当事者を「Ｐｒｏｖｉｄｉｎｇ Ｐａｒｔｙ（提供者）」１１０２として取り上げるか、又は異なる当事者を適宜に使用する。サービス情報１１０３を指定し、「Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｓｔａｎｃｅ Ｎａｍｅ（アプリケーションインスタンス名）」及び「Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｉｄｅｎｔｉｆｉｅｒ（アプリケーションサービス識別子）」をブランクのまま残す。

任意であるが、このサービスに関連付けねばならないサービス分類１１０４を指定する。このサービスによりサポートされるコレオグラフィー１１０５及び好みの順序を選択する。ｖｉｓｉｂｉｌｉｔｙ（視認性）１１０６を、「Ｖｉｓｉｂｌｅ ｔｏ Ａｌｌ Ｐａｒｔｉｅｓ ｉｎ Ｃｏｍｍｕｎｉｔｙ（コミュニティ内の全当事者を視認する）」であるデフォルト設定にセットする。サポートされるドキュメント交換アクティビティ１１０７を選択し、そして図１２のようなスクリーンを使用してアクティビティを編集する。ｐｒｉｖｉｌｅｇｅ（特権）１２０１を生成する。アプリケーションが特殊な配送受領取り扱いを必要としない限り、「Ｍｅｓｓａｇｅｉｎｇ Ｐｏｌｉｃｉｅｓ（メッセージングポリシー）」１２０２をそのままにする。入力１２１０及び／又は出力１２２０のメッセージについては、書名及び暗号化ポリシー１２１３、１２２３を「ｒｅｑｕｉｒｅｄ（必要）」にセットする。必要な部分１２１４、１２２４を編集し、そしてサポートされたドキュメント識別子のオーダーリストを指定する。レジストリーにおいて発表することのできる任意のメッセージ部分を追加する。

図１３のようなスクリーンを使用して、ポリシーを次のように確認又は変更する。非同期配送受領１３０１を「Ｙｅｓ」にセットする。「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍｏｄｅ（認証モード）」１３０２を「Ｄｏｃｕｍｅｎｔ Ｓｉｎｇｌｅ Ｓｉｇｎ−ｏｎ（ドキュメントシングルサインオン）」にセットする。「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍｅｃｈａｎｉｓｍ（認証メカニズム）」１３０３を「Ｕｓｅｒｎａｍｅ／ｐａｓｓｗｏｒｄ（ユーザ名／パスワード）」にセットする。次いで、任意であるが、サービス役割１３０４を指定する。「Ｓｕｂｍｉｔ／Ｓａｖｅ（提出／セーブ）」１３０５をクリックして、サービスを登録する。

登録の別の部分は、フランチャイジーにより使用されるべき通常のサービスを登録することである（ホストサービスとは対照的に）。これは、ウェブサービスの開発にとって通常のやり方で行なわれる。

図１４のようなスクリーンを使用して、ホストサービスパッケージも登録される。「Ｒｅｇｉｓｔｅｒ ａ Ｎｅｗ Ｈｏｓｔ Ｐａｃｋａｇｅ（新規ホストパッケージの登録）」スクリーンにおいて、パッケージ名１４０１及び記述１４０２を指定する。アプリケーション名１４０３を指定する。オペレータ当事者を「Ｈｏｓｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ（ホストサービスプロバイダー）」１４０４として取り上げるか、又は異なる当事者を適宜に使用する。サービス情報を指定する（「Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｓｔａｎｃｅ Ｎａｍｅ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｉｄｅｎｔｉｆｉｅｒ（アプリケーションインスタンス及びアプリケーションサービス識別子）」をブランク状態に保つ）。このパッケージをフランチャイズするのに承認が必要かどうか指定する（１４０５）。もし「Ｙｅｓ」であれば、ＣＰがこのパッケージをフランチャイズするときに承認プロセスがトリガーされる。アプリケーションコネクタを指定する（１４０６）。

フランチャイジーがホストサービスプロバイダーへの認証を委譲することが許されるかどうか指定する（１４０７）。フランチャイジーによりフランチャイズされるべきサービスを、ホストサービスプロバイダーによりオファーされるホストサービスのリストから選択する（１４０８）。フランチャイジーにより申し込まれるべきサービスのリストを、ホストサービスプロバイダーによりオファーされる通常サービスのリストから選択する（１４０９）。「Ｓａｖｅ（セーブ）」１４１０をクリックして、ホストサービスパッケージを登録する。

又、フランチャイジーは、図１５のようなスクリーンから、フランチャイズすべき新たなパッケージを選択して登録する。無線ボタン１５０１を選択しそして「Ｓｅｌｅｃｔ（選択）」１５０２をクリックすることにより１つ以上のホストパッケージが選択される。図１６のようなスクリーンにアクセスできるようになる。フランチャイジーのオプションは制限され、従って、設定が単純化される。別の実施形態では、特に、フランチャイジーがサービスを再オファーする環境において、フランチャイジーが、オファーすべきサービス及び／又は申し込むべきサービスに関するオプションを有することになる。認証がフランチャイジーの信用証明を使用するか、又はホストに対してデレゲートされるか判断する（１６０１）。オファーされるべき１つ以上のサービスを編集し（１６０２）、編集に対して指示された要求を満足する（１６０３）。「Ｓｕｂｍｉｔ（提出）」１６０４を選択して、フランチャイズを処理のために提出する。

サービスの詳細が編集されると、図１７のようなスクリーンにアクセスできるようになる。ある実施形態では、与えられる詳細のほとんどが、ホストでなければ編集できず、フランチャイジーでは編集できない。これは、図１７を図１１及び１３と比較することにより明らかである。与えられた詳細の幾つかは、ホストがそれらをフランチャイジーに適用するのと同様に、サービスが再オファーされる下流のユーザに適用される。図１１の記載が一般に適用される。更に、特権をグループ分けするサービス役割は、上述したように確立することができる。

フランチャイジーが申し込みできる幾つかのサービスは、ポータルサービスである。ポータルサービス（又はＵＩサービス）は、ポータルを経てアクセスされるサービスである。これらは、単に、ユーザがアプリケーションと相互作用できるようにアプリケーションにより提示されるサービスである。これは、ユーザが、アプリケーションのサービス指向のビューをもつことができるようにする。特定のユーザは、異なるアプリケーションからのサービスと相互作用してもよく、そして１つのアプリケーションからの全てのサービスと相互作用してもよいし／しなくてもよい。これらのケースのいずれにおいても、アドミニストレーション、アクセス制御／特権、シングルサインオン、ナビゲーション等に関するアプリケーションにわたる経験は、同一であると共に、サービスパラダインに基づくものである。

ポータルサービスは、サービス定義をもたなくてもよい。（まだ規格は存在しない。ここに示す実施形態では、ポータルサービスのためのサービス定義を要求しないが、将来は、ポータルサービスのためのサービス定義が存在すると想像される。）ポータルサービスは、全てポータルを経てアクセスできる登録されたアクティビティのリスト（必要に応じて、ＵＲＬと共に）を有する。アクティビティについては、アクティビティにアクセスできるようにする特権のリストも指定される。更に、ウェブエージェント及び保護されたリソース経路のようなシングルサインオン（ＳＳＯ）情報も、サービス又は各アクティビティについて指定される。又、レポートグループ／フォルダーをアクティビティとして登録することにより、レポートへのアクセスもポータルサービスを経てイネーブルされる。

アプリケーションに対して登録されるべきＵＩサービスを識別するときには多数の要因を考慮するのが有用である。ターゲットユーザ又は当事者を考慮する。アプリケーションインターフェイスは、異なるターゲットユーザにより使用するように設計される。例えば、あるＵＩは、アドミニストレータを意味し、あるＵＩは、買手を意味し、あるＵＩは、供給者を意味し、等々である。役割で区別されるこれらのＵＩは、別々のサービスでなければならない。あるインターフェイスが、あるクラスの供給者又は買手のみをターゲットするかどうか考える。例えば、進歩型供給者のみに対して付加的な機能をイネーブルすることを希望する。これらを別々のサービスに保持する。

１つのターゲットグループ（例えば供給者）をターゲットとする多数のサービスを有する場合には、サービス申し込みパッケージを生成して、それらをユーザが便利なようにグループ分けすることを考える。コラボレーション当事者がサービスを申し込み、当事者の中のユーザに、サービス内の特定の特権が許可される。これは、当事者にわたる特権及びアクティビティを混合してはならないことを意味する。例えば、買手がＲＦＰを提出することと、売手がＲＦＰ特権に応答することは、２つの異なるサービスにおいて行われねばならない。

ポータルサービスについては、特定の表示カテゴリーに関連付けることができる。表示カテゴリーは、サービスに対しポータルに関するタブを予約する。多数のポータルサービスを１つの表示カテゴリーに入れることができる。表示カテゴリーには、アプリケーションにより指定されたサービスルームＵＲＬが関連付けられる。このサービスルームＵＲＬを登録することにより、アプリケーションは、タブ内のポータルにおいてサービスをいかにレンダリングするかについて完全な制御を保持する。多数の表示カテゴリーとしてアプリケーションをレンダリングすることを望む場合には、それに関連する表示カテゴリーに基づいてサービスを識別する。

サービス、アクティビティ、特権、及びウェブエージェントの間で次の関係が遵守されるのが好ましい。１．サービスは、１つ以上のアクティビティを有することができる。２．アクティビティは、ゼロ以上の特権に関連付けることができる。３．特権は、サービスに所属しそしてサービス内で独特である。４．特権は、同じサービス内の１つ以上のアクティビティに関連付けることができる。５．サービスは、サービスを通してアクセスできるウェブリソース経路のリストと共にシングルサインオン（ＳＳＯ）を取り扱うデフォールトウェブエージェントに関連付けることができる。６．サービスの各アクティビティは、サービスウェブエージェントに関連付けできるか、又は異なるウェブエージェントでオーバーライドすることができる。アクティビティ特有のリソース経路へのアクセスも指定することができる。

ＵＩサービスにおいてアクティビティ及び特権を識別する際に多数の要因を考慮するのが有用である。１．サービスにおけるアクティビティ及び特権は、コラボレーション当事者内でターゲットとならねばならない。これは、当事者にわたる特権及びアクティビティが同じサービスの一部分であってはならないことを意味する。この場合も、買手がＲＦＰを提出することと、売手がＲＦＰ特権に応答することが、同じサービスで行われてはならない。２．アプリケーションにおける各リンクをＵＩサービスにおけるアクティビティとして登録することは好ましくない。アクセス制御が必要とされる場合には、これらを特権として登録することができる。３．簡単なケースでは、ポータルサービスは、１つのアクティビティと、１束の特権しか登録できない。例えば、特定のビッド機能を許す１組の特権と共に１つのアクティビティ「ビッド」を有する「アクションビッド」サービスが存在し得る。ユーザに指定された特権に基づいて、アプリケーションは、完全に異なるページをレンダリングするか、或いは異なるオプションがイネーブルされた同じページをレンダリングするように選択できる。これらのアクティビティへのリンクが他のアプリケーション／サービスからイネーブルされる場合には、ユーザは、粒度の大きなアクティビティをＵＲＬと共に登録して、レジストリーを経てこれらを発見できるようにすることを希望する。例えば、「カタログマネージメント」は、「サーチカタログ」アクティビティを「マネージカタログ」アクティビティと共に登録することを希望してもよい。「サーチカタログ」アクティビティは、調達スクリーン、送信元スクリーン、契約管理スクリーン、及び管理カタログスクリーンにおけるリンクとして表示されてもよい。５．サービス内のあるリンクが、異なるアプリケーションサーバー又はウェブサーバーにおいてホストされ、そしてそれらを保護するために個別のウェブエージェントを必要とする場合には、これらを別々のサービスへとグループ分けすることもできるし、又は同じサービスにおける別々のアクティビティとして登録することもできる。（例えば、残りのカタログサービスアクティビティからの異なるウェブサーバーにおいて実行できる製品構成アクティビティ。）

以上、好ましい実施形態及び実施例を参照して本発明を説明したが、これらは、本発明を例示するものであって、限定するものではないことを理解されたい。以上の説明から、当業者であれば、種々様々なシステム及び方法を本発明により構成できることが明らかであろう。前記実施形態では、コンピュータ支援処理が示唆される。従って、本発明は、コンピュータ支援の処理方法、この方法を実施するためのロジックを含むシステム、この方法を実施するためのロジックが銘記された媒体、この方法を実施するためのロジックが銘記されたデータストリーム、或いはコンピュータアクセス可能な処理サービスにおいて実施することができる。又、当業者であれば、本発明の精神及び範囲内で種々の変更や組合せがなされ得ることが理解されよう。

ドキュメントバージョン及び変換、サービスバージョン、及びコレオグラフィーバージョンを動的に決定する能力を示す図である。 サービスバージョンに関するメッセージ交換をいかに行なうか示す図である。 ネゴシエーションのための情報を発見するのに使用される１つ以上のレジストリーへの参照を示す図である。 ４つの形式のアクティビティを示す図である。 アクティビティと内部プロセスとの間の相互作用を示す図である。 コレオグラフィーエージェントを構成するのに使用されるプロセスエンジンにおいて実行される内部プロセスフローを示す図である。 メッセージ相関を示す図である。 通常の非フランチャイズ型サービスと、フランチャイズ型サービスとの間を区別する上で助けとなる図である。 通常の非フランチャイズ型サービスと、フランチャイズ型サービスとの間を区別する上で助けとなる図である。 本発明の一実施形態のスクリーンショットで、管理ホストパッケージスクリーンを示す図である。 本発明の一実施形態のスクリーンショットで、新たなホストサービスを登録する部分を示す図である。 本発明の一実施形態のスクリーンショットで、ドキュメント交換アクティビティを編集するのに使用されるスクリーンを示す図である。 本発明の一実施形態のスクリーンショットで、署名及び暗号化ポリシーを照合又は変更するのに使用されるスクリーンを示す図である。 本発明の一実施形態のスクリーンショットで、ホストサービスパッケージを登録するのに使用されるスクリーンを示す図である。 本発明の一実施形態のスクリーンショットで、フランチャイズすべき新たなパッケージを選択するのに使用されるスクリーンを示す図である。 本発明の一実施形態のスクリーンショットで、フランチャイズオプションを選択するのに使用されるスクリーンを示す図である。 本発明の一実施形態のスクリーンショットで、サービス詳細を編集するのに使用されるスクリーンを示す図である。

Claims (23)

1. 複数のサービスエンティティの中でウェブサービス相互操作性をサポートする方法において、実行時に、
   前記エンティティの中でメッセージを交換するのに使用されるべきメッセージコレオグラフィーの特定バージョンであって、実質的に同じ第１メッセージを使用するようなメッセージコレオグラフィーのバージョンと、
   前記サービスエンティティの中で１つ以上のサービスプロバイダーにより使用されるサービスバージョンと、
   ドキュメントバージョンの中で必要に応じてメッセージ交換及び変換において前記サービスエンティティにより使用されるべきドキュメントバージョンと、
   を決定するステップを備えた方法。
2. 前記方法は、複数のコレオグラフィー定義言語に適応されることを特徴とする請求項１に記載の方法。
3. 前記方法は、複数のサービスエンティティインターフェイス定義言語に適応されることを特徴とする請求項１に記載の方法。
4. ウェブサービスをコレオグラフィー処理し、コレオグラフィーは、複数のサービスエンティティの規格適合インターフェイスへマップされた複数のメッセージを含むものであり、更に、前記メッセージに会話識別子を指定し、そして前記コレオグラフィーに基づいて前記サービスエンティティの中でメッセージ交換を実行する方法であって、
   コレオグラフィーエージェントを経て前記メッセージ交換をルーティングするステップを備え、前記コレオグラフィーエージェントは、
   (a)前記メッセージを検査し、
   (b)前記メッセージの検査に基づいて前記会話識別子に対応するコレオグラフィーインスタンスの状態を更新し、そして
   (c)前記メッセージをそれらの宛先へ転送する、
   というように構成された方法。
5. 前記方法は、複数のコレオグラフィー定義言語に適応されることを特徴とする請求項４に記載の方法。
6. 前記方法は、複数のサービスエンティティインターフェイス定義言語に適応されることを特徴とする請求項４に記載の方法。
7. 前記コレオグラフィーエージェントは、更に、コレオグラフィーの状態に関する問合せに応答することを特徴とする請求項４に記載の方法。
8. 前記コレオグラフィーエージェントは、更に、トランザクションロールバックログを更新することを特徴とする請求項４に記載の方法。
9. 前記メッセージはドキュメントを含み、そして更に、
   前記ドキュメントのドキュメントバージョンと、それらバージョン間で変換するための変換ロジックとを維持するステップと、
   特定のドキュメントバージョンの中で必要に応じてサービスエンティティ及び変換により使用されるべき特定のドキュメントバージョンを決定するステップと、
   を備えた請求項４に記載の方法。
10. ウェブサービスをコレオグラフィー処理し、コレオグラフィーは、複数のサービスエンティティの規格適合インターフェイスへマップされた複数のメッセージを含むものであり、更に、前記メッセージに会話識別子を指定し、そして前記コレオグラフィーに基づいて前記サービスエンティティの中でメッセージ交換を実行する方法であって、
    コレオグラフィーのコレオグラフィーバージョンであって、実質的に同様の第１メッセージを使用するコレオグラフィーバージョンを維持するステップと、
    第１メッセージに応答して、前記サービスエンティティによりサポートされる特定メッセージコレオグラフィーバージョンを決定し、そして前記第１メッセージの後に前記特定コレオグラフィーバージョンを使用するステップと、
    を備えた方法。
11. メッセージコレオグラフィーバージョンを決定する前記ステップは、前記サービスエンティティによりサポートされるコレオグラフィーバージョンを識別するレジストリーにアクセスする段階を含む請求項１０に記載の方法。
12. 前記レジストリーは、更に、前記サポートされたコレオグラフィーバージョンの中で前記サービスエンティティの好みを識別し、そして前記決定するステップは、更に、少なくとも１つのサービスエンティティの好みを利用する段階を含む請求項１１に記載の方法。
13. 前記メッセージはドキュメントを含み、そして更に、
    前記ドキュメントのドキュメントバージョンと、それらバージョン間で変換するための変換ロジックとを維持するステップと、
    特定のドキュメントバージョンの中で必要に応じてサービスエンティティ及び変換により使用されるべき特定のドキュメントバージョンを決定するステップと、
    を備えた請求項１０に記載の方法。
14. ウェブサービスをコレオグラフィー処理し、コレオグラフィーは、複数のサービスエンティティの規格適合インターフェイスへマップされた複数のメッセージを含むものであり、更に、前記メッセージに会話識別子を指定し、そして前記コレオグラフィーに基づいて前記サービスエンティティの中でメッセージ交換を実行する方法であって、
    コレオグラフィーのコレオグラフィーバージョンであって、実質的に同様の第１メッセージを使用するコレオグラフィーバージョンを維持するステップと、
    前記サービスエンティティによりサポートされるコレオグラフィーバージョンを識別するデータをレジストリーに維持するステップと、
    前記レジストリーにアクセスし、そして前記サービスエンティティによりサポートされる特定メッセージコレオグラフィーバージョンを決定するステップと、
    前記特定コレオグラフィーバージョンをメッセージ交換に使用するステップと、
    を備えた方法。
15. 前記レジストリーは、更に、前記サポートされたコレオグラフィーバージョンの中で前記サービスエンティティの好みを識別し、そして前記決定するステップは、更に、少なくとも１つのサービスエンティティの好みを利用する段階を含む請求項１４に記載の方法。
16. 前記メッセージはドキュメントを含み、そして更に、
    前記ドキュメントに適用できるドキュメントバージョンと、それらバージョン間で変換するための変換ロジックとを維持するステップと、
    特定のドキュメントバージョンの中で必要に応じてサービスエンティティ及び変換により使用されるべき特定のドキュメントバージョンを決定するステップと、
    を備えた請求項１４に記載の方法。
17. １つ以上の規格適合インターフェイスを有するサービスエンティティをバージョン改訂する方法であって、
    サービスのサービスバージョンであって、基本サービスに任意の操作を追加するようなサービスバージョンを維持するステップと、
    前記サービスエンティティによりサポートされるサービスバージョンを識別するデータをレジストリーに維持するステップと、
    前記レジストリーにアクセスし、そして前記サービスエンティティによりサポートされるサービスバージョンを決定するステップと、
    前記サポートされるサービスバージョンを利用して前記サービスエンティティとのメッセージ交換を実行するステップと、
    を備えた方法。
18. １つ以上の規格適合インターフェイスを有するサービスエンティティをバージョン改訂する方法であって、
    サービスのサービスバージョンであって、基本サービスに任意の操作を追加するようなサービスバージョンを維持するステップと、
    前記サービスエンティティによりサポートされるサービスバージョンに依存しない第１メッセージを前記サービスエンティティに送信するステップと、
    前記サービスエンティティから、それがサポートするサービスバージョンを識別する応答を受信するステップと、
    前記サポートされるサービスバージョンを利用して前記サービスエンティティとのメッセージ交換を進めるステップと、
    を備えた方法。
19. 複数の非コレオグラフィーイネーブル型インターフェイスにより発生されたメッセージを、コレオグラフィーのインスタンスに対応する会話識別子と相関させるためのメカニズムであって、
    コレオグラフィー会話識別子のないメッセージを発生する複数のアプリケーションインターフェイスへとマップされた内部プロセスフローと、
    メッセージをコレオグラフィーインスタンスに相関させるのに使用すべく前記アプリケーションインターフェイスにより発生されるメッセージにおけるフィールドの指定と、
    前記アプリケーションインターフェイスからの内部プロセスフローで受け取られたメッセージを検査し、前記フィールドの指定を適用し、そしてメッセージを前記コレオグラフィーインスタンスに対応する特定の会話識別子に相関させるロジック及びリソースと、
    を備えたメカニズム。
20. 複数の非コレオグラフィーイネーブル型インターフェイスにより発生されたメッセージを、コレオグラフィーのインスタンスに対応する会話識別子と相関させるためのメカニズムであって、
    １つ以上のコレオグラフィーイネーブル型インターフェイスと、コレオグラフィー会話識別子のないメッセージを発生する複数のアプリケーションインターフェイスとの間のマッピングと、
    メッセージをコレオグラフィーインスタンスに相関させるのに使用すべく前記アプリケーションインターフェイスにより発生されるメッセージにおけるフィールドの指定と、
    前記アプリケーションインターフェイスから受け取られたメッセージを検査し、前記フィールドの指定を適用し、メッセージを前記コレオグラフィーインスタンスに対応する特定の会話識別子に相関させ、そして前記コレオグラフィーイネーブル型インターフェイスにそれらを与えるロジック及びリソースと、
    を備えたメカニズム。
21. 会話識別子のない非コレオグラフィー処理メッセージから、会話識別子を含むコレオグラフィー処理メッセージをコンポーズする方法であって、前記コレオグラフィー処理メッセージは、第１インターフェイスに与えられ、そして前記非コレオグラフィー処理メッセージは、複数の第３インターフェイスから第２インターフェイスに受け取られるような方法であって、
    前記第３インターフェイスにより発生される非コレオグラフィー処理メッセージをコレオグラフィーインスタンスに相関させるのに使用すべく前記第３インターフェイスにより発生されるメッセージにおいてフィールドを指定するステップと、
    前記第２インターフェイスと第３インターフェイスとの間でメッセージを交換するときに、特定のコレオグラフィーインスタンスに対する状態情報を維持するステップと、
    前記フィールドの指定及び状態情報を使用して、前記第２インターフェイスで受け取られた特定の非コレオグラフィー処理メッセージを、特定のコレオグラフィーインスタンスに対応する会話識別子に相関させるステップと、
    前記非コレオグラフィー処理メッセージ及び前記会話識別子の少なくとも一部分を前記第１インターフェイスに与えるステップと、
    を備えた方法。
22. ブローカーエージェント及び要求発生エンティティに対して使用すべきメッセージコレオグラフィーのバージョンと、
    ブローカーエージェントにより使用されるサービスバージョンと、
    メッセージの交換と、ドキュメントバージョン間の変換とにおいて、ブローカーエージェント及び要求発生エンティティにより使用されるべきドキュメントバージョンと、
    を実行時に決定するステップを更に備えた請求項１９に記載の方法。
23. ホスト型サービスを複数のフランチャイズ型サービスとしてエイリアシングする方法であって、
    １つ以上のフランチャイズ型サービスを、個別の論理アドレスを有するウェブサービスとして登録するステップと、
    前記フランチャイズ型サービスを経て受け取られたメッセージを検査してメッセージのコンテクストを決定するためのロジックを含むホスト型ウェブサービスを提供するステップと、
    受け取ったメッセージをホスト型ウェブサービスへ渡すように前記フランチャイズ型サービスを構成するステップと、
    を備えた方法。

Images