JP2006501493A - ウェブサービスのための動的な相互操作性契約 - Google Patents

Abstract

本発明は、相互操作性をサポートするためのマシン読み取り可能なデータ構造体及びデータ構造体の動的計算に係る。より詳細には、本発明は、相互操作性を向上するデータ構造体及びデータ構造体の動的発生の態様に係る。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記載する。

Description

本発明は、相互操作性をサポートするためのマシン読み取り可能なデータ構造体及びデータ構造体の動的計算に係る。より詳細には、本発明は、相互操作性を向上させるデータ構造体及びデータ構造体の動的発生の態様に係る。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記載する。

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

リストで添付したコンピュータプログラムの参照：
本明細書には、コンピュータプログラムリストを添付する。このコンピュータプログラムリストは、次のプログラムの抜粋を含む。
InteroperabilityContract.xsd （全体的な契約のためのスキーマ）、
GeneralContract.XSD （一般的情報のためのスキーマ）、
RoutingContract.XSD （メッセージをルーティングするためのスキーマ）、
TransformationContract.XSD （ドキュメント変換のためのスキーマ）、
SecurityContractKeyInfo.XSD （セキュリティに使用するキーのスキーマ）、
SecurityContract.XSD （ネゴシエーションから出力されるセキュリティ契約のためのスキーマ）、
InteroperabilityContract.XML （相互操作性契約の例）、
ComputeSecurityContract.XML （計算型セキュリティ契約の例）。

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

Ｂ２Ｂ及びＡ２Ａ電子商取引に適用可能な規格を拡張するための業界のイニシアティブは多数ある。コレオグラフィー上の成果は、ＯＡＳＩＳからのｅｂＸＭＬ／ＢＰＳＳ、ＩＢＭからのＷＳＦＬ、及びマイクロソフトからのＸＬＡＮＧを含む。会話上の成果は、ＯＡＳＩＳからのｅｂＸＭＬ／ＴＲＰ、及びマイクロソフトのＷＳルーティングを含む。ｅｂＸＭＬイニシアティブに関する更に別の情報は、ｈｔｔｐ：／／ｗｗｗ．ｅｂｘｍｌ．ｏｒｇ／ｓｐｅｃｓ／ｉｎｄｅｘ．ｈｔｍ＃；ｗｈｉｔｅｐａｐｅｒｓにおいて入手することができ、ここには、ｅｂＸＭＬトレーディング・パートナー・チームによる論文「Collaboration-Protocol Profile and Agreement Specification Version 1.0」（２００１年５月１０日）が見られる。又、対話及びサービス契約実施者に関するロジックの明確なルールについては、米国特許第６，１４８，２９０号にもある程度の情報が見られる。主要なセキュリティ成果は、ＩＢＭ及びマイクロソフトからのＷＳセキュリティであり、又、ＯＡＳＩＳにもＳＡＭＬと称される相補的なセキュリティ成果が存在する。信頼性については、マイクロソフトからの提案、ＯＡＳＩＳからのｅｂＸＭＬ／ＴＲＰ、及びＩＢＭからのＨＴＴＰＲがある。Ｗ３Ｃは、これら全ての領域における規格化に向けられている。重要な業界の活動家は、ＷＳＩと称されるライバルのコンソーシアムを形成した。しかしながら、それらは、動的セキュリティ・ネゴシエーション問題に向けられたものではない。

ｅｂＸＭＬ ＣＰＰ及びＣＰＡでは、相互に操作する当事者が、単一のレジストリーにおけるそれらのサービスの相互的な操作ルールとしてＣＰＰと称するプロフィールを定義する。２つのプロフィールを交差させて、ＣＰＡと称するデフォルトの相互的な操作合意を推論することができる。或いは又、両当事者は、ＣＰＡと称する特定の１組の相互的操作ルールに基づいて合意する。ｅｂＸＭＬ ＣＰＰ及びＣＰＡに伴う問題は、送信側及び受信側の当事者が同じレジストリーにあると仮定することを含む。相互的操作ルールは、相互操作の多くの態様をカバーするには不充分である。つまり、使用時では、ＣＰＡの署名コピー（両当事者により署名された）がレジストリーに保持されると仮定している。これは、維持及び変更を厄介なものにする。これは、直接的には相互的な操作性合意を動的に計算することと矛盾している。従って、あるサービスが別のサービスを呼び出すときの実行時にキャッシングを伴う動的な計算に向けられるのではなく、事前のダウンローディング及びローカルインストールについて協議することになるが、これはＣＰＡへの変化の管理を困難で且つ非自動的なものにしている。

従って、取引のパートナーに対する相互的な操作性合意を動的に決定する方法及び装置を開発する必要性が生じる。

本発明は、相互的な操作性をサポートするためのマシン読み取り可能なデータ構造体及びデータ構造体の動的な計算に係る。より詳細には、本発明は、相互的な操作性を向上するデータ構造体及びデータ構造体の動的発生の態様に係る。本発明の特定の態様を、特許請求の範囲、明細書本文及び添付図面に記述する。

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

図１は、マシン読み取り可能で動的にネゴシエーションされる相互的な操作性契約が有用となる１つの環境のコミュニティ及びコミュニティネットワークを示す。これらコミュニティの中で、あるコミュニティは、そのコミュニティの一部分であるユーザ、会社、サービス及びコネクタのような情報を含むローカルレジストリーを維持する。コミュニティは、市場、企業、又は事業部でよい。コミュニティは、１つ以上のコミュニティネットワークに属することができる。通常、コミュニティ及びネットワークは、ある共通のビジネス利益を有する。１以上のコミュニティネットワーク内のメンバーコミュニティ間で相互操作がなされる。ネットワークは、金市場ネットワーク１と、貴金属市場ネットワーク２と、プライベートネットワーク３と、グローバル取引ウェブネットワーク４とを備えている。この図では、金市場ネットワーク１及び貴金属市場ネットワーク２は、グローバル取引ウェブネットワーク４内に収容される。

貴金属市場ネットワーク２は、金及び銀市場１４、１３を含む。金市場の顧客は、銀市場１３において銀を取引することができ、そして銀市場の顧客は、金市場１４において取引を行うことができる。１つのコミュニティであるＰＱＲ企業１７は、金市場ネットワーク１、プライベートネットワーク３、及びグローバル取引ウェブネットワーク４に所属し、別のコミュニティであるＡＢＣ大規模供給者１８は、プライベートネットワーク３に所属する。この図では、ＸＹＺ金１４は、金を取引するための市場又はコミュニティである。企業はこのコミュニティに所属する。それら自体でコミュニティを形成しているＰＱＲ企業１７のような企業は、金市場ネットワーク１に所属する。これらのコミュニティは、金市場ネットワーク１及びグローバル取引ウェブネットワーク４の一部分である。小規模供給者１５は、金市場コミュニティの一部分である。他の企業１６は、金市場コミュニティネットワーク１の一部分であるコミュニティである。

ＸＹＺ金１４と他の金市場エンティティ１５−１７との間の接続は、金市場が、例えば、勘定及びビジネスインテリジェンス情報を収集するために、金の取引を取り扱う企業（コミュニティ又はその他）間の全てのトラフィックを、ＸＹＺ金１４を通るルートにするよう要求することを示している。ＰＱＲ企業１７は、金市場の一部分であると共に、供給者１８とのローカルプライベートネットワークの一部分でもあるコミュニティである。
小規模供給者１５は、それ自体でコミュニティを形成することを希望せず、むしろ、ユーザ、組織、サービス及び変換等のメタデータを金市場のレジストリーに登録する個々の小規模供給者でよい。

一方、ＡＢＣ大規模供給者１８は、例えば、そのメタデータ、内部バックオフィスシステム及び変換を、それらが著しいコストで開発されたことから、一般的な公衆アクセスから隠れた状態に保持したいために、それ自身のプライベートネットワークを形成している。ＰＲＱ１７は、ＡＢＣ１８の顧客であるので、プライベートネットワーク３に参加する。フィナンシャルサービスプロバイダーＤＥＦフィナンシャル１２は、グローバル取引ウェブネットワーク４の誰かに、それ自身のコミュニティを形成したりグローバル取引ウェブ根１１に登録したりするフィナンシャルサービスを提供することを希望する。コミュニティのネットワークは、コミュニティのグローバルレジストリーを利用できるようにする。このグローバルレジストリーは、コミュニティを検索し且つそのコミュニティ又は外部コネクタへの１つ以上のルートを決定出来るようにし、上記外部コネクタは、それを経てコミュニティへ向う電子商取引ドキュメントをルーティングできるものである。

１つのコミュニティから別のコミュニティへルーティングされるドキュメントは、２つのコミュニティについては外部コネクタ間で直接ルーティングされてもよく、或いは１つ以上の中間コミュニティを経て間接的にルーティングされてもよい。又、コミュニティを伴うトランザクションに対するビジネス及びセキュリティルールも定義して、コミュニティレジスタに維持すことができる。一般に言えば、図１は、電子商取引プラットホーム間の相互操作性の刺激を生じさせるエンティティ及びコミュニティの混合忠誠さを示す。

コネクタとは、他のアプリケーションと通信するアプリケーションに対する汎用的な用語である。コネクタは、ハブ、ゲートウェイ、外部ポート、中央コネクタ等として機能する他のコネクタを通してピア対ピア（Ｐ２Ｐ）ベース又は指令ベースで通信することができる。Ｐ２Ｐで通信するコネクタは、同じトランスポート／エンベローププロトコルを使用する他のコネクタと通信することができる。Ｐ２Ｐで通信するコネクタは、任意であるが、同じトランスポート／エンベローププロトコルを使用しないコネクタと通信を試みるときに、変換サービスを実行する他のハブコネクタの協力を得てもよい。指令ベースで通信するコネクタは、ルーティングルールに基づいてハブコネクタを経て通信する。

コネクタ間のルーティングルールは、１以上のトランスポート／エンベローププロトコルに対して１以上のハブ及びスポークトポロジーをサポートするように、指令グラフにマップすることができる。ハブ及びスポークのトポロジーは、１以上の結合子(tier)においてスポークに沿ってハブへの通信を指令する。これは、勘定、ビジネスインテリジェンス収集、追跡、監査、会計、その他の集中サービスを容易にする。図２に示唆されるように、異なるトランスポート／エンベローププロトコル及びテクノロジーをサポートするために、多数のハブ及びスポーク組織が同じコネクタをオーバーレイしてもよい。例えば、ＨＴＴＰ又はＨＴＴＰＳを使用するのではなく、ソニック(Sonic)をトランスポートテクノロジーとして使用するために、より強いハブ及びスポーク組織が必要とされてもよい。
任意であるが、通信ルートは、ソース及び行先が同じコミュニティの一部分であるかどうかによって左右されてもよい。準コミュニティ（全コミュニティを含んでもよい）内で、集中機能が不要とされ、そして他の準コミュニティ内の行先と通信するときに親コネクタと通信するよう指令されたコネクタ間でＰ２Ｐ通信が許可されてもよい。

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

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

本発明の態様は、相互的な操作性契約のデータ構造体、相互的な操作性契約の動的ネゴシエーションの要素である連合レジストリーに向けられる。レジストリーの範囲はコミュニティである。コミュニティは、企業、市場、又は大規模に分布した企業の事業部である。相互的な操作の当事者は、異なるコミュニティに存在してもよい。例えば、一方が、供給者のコミュニティにあり、そして他方がバイヤーのコミュニティにあってもよい。それ故、プロフィール及び合意を記憶するための組合せ構成を使用しなければならない。相互的な操作については、本発明は、電子商取引の相互操作に対するｅｂＸＭＬ及び他の従来の解決策を越えるものである。

相互操作性契約は、次の組合せを包含するように拡張される。サービスとサービスとの間にメッセージを搬送する際にたどるべきルートは、定義されたルーティングルールに合致する。例えば、ルールは、ウェブサービスへの及びウェブサービスからの全てのメッセージの前に特定のルーターを置くべきであることを規定してもよい。ルーターは、例えば、ＳＯＡＰ及びＥＤＩエンベローププロトコル間で、エンベロープ変換のためのゲートウェイを通る自動的ルーティングを含む。メッセージに多数の部分があるときには、メッセージ部分ごとのベースで署名、認証及び暗号化ポリシーが特定される。ここで、ポリシーは、アルゴリズム、テクノロジー（例えば、ＸＭＬ暗号、ＳＭＩＭＥ、ＰＫＣＳ＃７）、及びエレメント（例えば、ＸＭＬドキュメントにおけるＸＭＬエレメント）を含む。

メッセージ部分に含まれたドキュメントに対して、部分ごとのベースで、変換ルールが特定される。例えば、バージョンの相互操作に対する変換が許される場合には、オリジナルを添付しなければならない。特定の変換ロジックを識別することもできる。使用すべきメッセージ交換コレオグラフィーのバージョンが識別される。例えば、あるサービスは、コレオグラフィーの多数のバージョンをサポートしてもよく、従って、送信者及び受信者がサポートする正しいバージョンを知ることからサービスの利益が得られる。

メッセージを公的に保管すべきか、信頼性のある配送を使用すべきか、そして確認のための非拒絶受信を要求すべきかといった幾つかのメッセージ搬送ポリシーがセットされる。ブリッジ（bridge）する必要のある送信及び受信メッセージの相違は、エンベロープ調整又はエンベロープ変換により対処される。例えば、異なるエンベロープ拡張の使用、メッセージ部分の順序の相違、異なるエンベローププロトコルである。コネクタの能力と一貫して、種々の相互的な操作機能にサービスするルート内の接続は、レジストリーに登録される。当業者であれば、本発明の以上の態様及び以下の態様を、多数の有用なサブセットにおいて結合することができ、即ち本発明は、本発明の全ての態様を含む相互的な操作性契約に限定されるものでないことが理解されよう。

相互的な操作性契約は、通常、送信者及び受信者のサービスのポリシー及びインターフェイスに交差することにより導出される。しかしながら、送信者と受信者との間の競争を解決するのに使用すべき判断ルールを指示するオーバーライドが考えられる。例えば、判断ルールは、送信者の勝ち、受信者の勝ち、最も厳格なポリシーの勝ち等を決定してもよい。これは、相互的な操作契約が計算されて、信用のあるコミュニティの大もとの当事者のような信用のあるサービスにより署名されるときに、サービスの変更をサポートするのに有用である。相互的な操作性契約は、あるサービスが呼び出されたときに動的に計算されてもよく、そしてメッセージ送信サイトでローカルキャッシュされてもよい。

呼び出しているサービスが１つのコミュニティにありそして呼び出されたサービスが別のコミュニティにあるときには、両サービスに対してローカルにありそしてそれに交差するコミュニティレジストリーから、送信側情報及び受信側情報を得る分散型ロジックにより契約計算が実行されてもよい。オーバーライドは、受信側で定義されて、送信側に通知され、そして以前の承認がない場合には相補的な承認側へコピーされる。契約作成時に、分散ベースで計算されて得られる相互的な操作性契約は、クロスコミュニティ・オンラインネゴシエーションプロセスを使用してオーバーライドに対処できるので、同一なものとして終了する。サービスライター（service writer）から多くの複雑さが隠され、そして相互的な操作契約は、レジストリーから自動的に推論される。これは、サービスの開発を著しく簡単化する。

相互的な操作性契約は、契約をローカルマシンにインストールすることで主要な同期問題を回避するために動的に計算されねばならない。これは、キャッシュが動的な計算を補充できるので、各メッセージに対して必ずしも再計算を必要としない。キャッシュは、レジストリーの変化又は失効したポリシーに関する無効化通知によりコヒレント状態に保持することができる。キャッシュキーパーは、いかなる必要な通知に申し込むこともできる。相互的な操作性契約は、送信側サービスコネクタ（又はそれをいかに取り扱うか知っているそのプロキシー）からウェブサービスを開始する際に、動的に計算することができる。契約は計算の後にメッセージに添付することができ、従って、通信しているサービスとサービスとの間の中間コネクタは、メッセージ交換におけるそれらの役割を理解する。例えば、契約は、どのコネクタがバージョン変換、署名、暗号化等を実行すべきか特定することができる。

本発明の態様は、相互的な操作性の多数の次元にわたり拡張する。真の端−端メッセージ相互操作の場合に、対処すべき相互操作性の多数の次元が存在する。相互的な操作性のいかなる１つの次元に対処することも、ウェブベースのサービスを利用する電子商取引を進歩させる。相互操作性の問題の組合せに対処することは、著しい進歩をもたらすことができる。以下の説明では、本発明の範囲内の多次元の相互操作性及び解決策について述べる。

１．トランスポートプロトコルの相互操作：
一次元の相互操作は、トランスポートレベルの相互操作である。関連出願に詳細に述べられた本発明の態様によれば、許容され且つサポートされたトランスポートは、使用するエンベローププロトコルに結合される。これに対して、ｅｂＸＭＬでは、許容されたトランスポートがＨＴＴＰ（Ｓ）である。ＭＭＬの場合には、許容されたトランスポートがソニックである。Ｂｉｚｔａｌｋでは、許容されたトランスポートがＨＴＴＰ（Ｓ）である。本発明の一実施形態では、許容されたトランスポートがＨＴＴＰ（Ｓ）及びソニックである。

ソニックでは、信頼性がトランスポートレベルへプッシュダウンされる。ソニック信頼性プロトコルは、非常に良好なアルゴリズムである。長語ＨＴＴＰ（Ｓ）Ｒは、標準化された場合には、ＨＴＴＰ（Ｓ）レベルそれ自体において信頼性を与えることができる。ｅｂＸＭＬ及びＢｉｚｔａｌｋにより現在使用されている解決策は、ＨＴＴＰ（Ｓ）に勝るエンベローププロトコル依存解決策によって信頼性がある。ＳＯＡＰは、拡張しないと、エンベロープレベルの信頼性に対して何のサポートも与えない。

本発明は、サポートされるプロトコルの中で、トランスポートプロトコルのネゴシエーションに対するサポートを含む。一実施形態では、これは、ＨＴＴＰ（Ｓ）とソニックとの間の選択を含む。電子商取引に対して付加的なトランスポートが採用されるときには、本発明はこれら付加的なオプションをネゴシエーションに含むことができる。

２．エンベローププロトコルの相互操作：
本発明の一実施形態において、サポートされるエンベローププロトコルは、ＭＭＬ、Ｃ１ ＳＯＡＰ、ｅメール、及び外部ＳＯＡＰであり、これは、Ｃ１アドレス、会話及びメッセージ情報、マニフェスト、ＳＡＭＬ、及びＳＯＡＰのような任意の拡張をアタッチメントと組み合わせることができるようにする。純粋なＳＯＡＰ、ＳＯＡＰ ＷＡ、標準的ＷＳＤＬで露出されそしてＵＤＤＩで発見できるサービスは、この業界では、単純ウェブサービスと称される。しかしながら、Ｃ１ ＳＯＡＰは、単純ウェブサービスであるエンドポイント（第三者の開発環境及び第三者の実行環境で開発された）と相互操作されるが、信頼性、セキュリティ、及び両方向コレオグラフィーへの関与を伴うネイティブウェブサービスもサポートする。Ｊ２ＥＥ ＣＡ又はＥＪＢで露出されるバックオフィスシステムは、第三者により単純ウェブサービスとしてまとめることができる。この実施形態は、それらと相互操作することができると共に、ｅメールプロトコル及び外部ＳＯＡＰをサポートすることができる。

サポートされるプロトコルは、許容されるトランスポート、信頼性及びセキュリティプロトコルを定義する。また、それらは、そのプロトコルにおいてサービス及び当事者をアドレスする仕方、及び関連メッセージを結合するためのデータリンケージも定義する。メッセージのルーティング及びディスパッチは、定義されたアドレスに基づく。

エンベローププロトコルの決定及び変換は、相互的な操作性契約によりサポートすることができる。これは、相互的な操作性契約が典型的なｅｂＸＭＬ ＣＰＡ契約を越えて遥かに進む先の一方法である。この場合も、相互的な操作性契約は、たどるべきルート、行うべき変換、どこでそれらを行うべきか、署名又は暗号化されるべきもの、どこでそれを行いそしてどんなアルゴリズムを使用すべきか、コレオグラフィーの名前及びバージョン、並びに送信／受信ＴＰ／サービス／サービスバージョン／操作に関する情報を含んでもよい。相互的な操作性契約は、サービスとサービスとの間のルートに沿った中間コネクタを導出するのに使用することができる。関与するサービスとサービスとの間のルートのセグメントは、いわゆる「インテリジェントに相互操作することが可能なネットワーク」で、本発明の譲受人により開発されたソフトウェアを使用せずにエンドポイントが厳密に規格に従う場合でも価値を付加するものである。

エンベローププロトコル間の相互操作は、ゲートウェイを通るものである。同じプロトコルの異なるバージョンは、異なるプロトコルとして処理されてもよい。ルーターは、相互操作のための適当な１組のゲートウェイを通してメッセージを透過的にルーティングすることを知っている。宛先コネクタにおけるディスパッチャーは、入って来るメッセージを適当なコンポーネントへ手渡す。このディスパッチングも、ターゲットアドレス及び他のエンベロープフィールドにより駆動されるルールに基づいている。

エンベローププロトコル相互操作の１つのバリエーションは、ベースライン及び使用可能な多数のオプションをもつプロトコルを有することである。その一例は、外部ＳＯＡＰで、アタッチメント、ルーティング、セキュリティ、ＳＡＭＬ等をもつＳＯＡＰはオプションである。送信者が１組のオプションを特定しそして受信者が別の組を特定する場合には、ネットワークへの入口ポイントが、相互操作が可能であるか、そしていかに可能であるかを計算する。これは、ルールに基づいてオプションのブロックを自動的に追加すると共に、ネットワークからの出口ポイントにおいて望ましからぬブロックを取り除いている。

ＸＭＬデータをＳＯＡＰ本体からＭＩＭＥ部分のドキュメントへ、或いはそれとは逆に転送するときに、これをエンベロープ相互操作の一形式であると考えることができる。このような変換は、ＢｉｚｔａｌｋとｅｂＸＭＬとの間、又はＳＯＡＰとｅｂＸＭＬとの間で変換するときに生じる。またこれは、送信者が添付（アタッチメント）にペイロードを入れそして受信者がそれを本体において予想する（又はそれとは逆の）ＳＯＡＰ対ＳＯＡＰ相互操作についても生じる。

３．セキュリティプロトコルの相互操作：
エンベローププロトコル相互操作に伴う１つの問題は、サポートされるセキュリティプロトコルがエンベローププロトコルによって定義され、そしてセキュリティプロトコル間の変換がほぼ不可能なことである。例えば、エンベローププロトコルＡによりサポートされるＸＭＬ署名からエンベローププロトコルＢによりサポートされるＰＫＣＳ＃７へのスイッチングを行うことができない。受信側サービスがオリジナル署名又は相互操作のための暗号化を要求する場合には、ゲートウェイがセキュリティプロトコルを変換するための信用がない限り、ゲートウェイはエラーを送信者へ返送しなければならない。セキュリティプロトコルの非適合性を克服するための１つの解決策は、ゲートウェイを信用して、メッセージの署名を照合し、そしてメッセージを暗号解読し（暗号装置がゲートウェイキーを使用する）、且つ再署名及び再暗号化することである。信用できる構成が設けられ、従って受信者はゲートウェイの署名を信用することができる。

この業界で提案されるＳＯＡＰ拡張は、ＷＳセキュリティ（ＧＸＡの一部分）を含む。本発明の実施形態は、Ｃ１ ＳＯＡＰに対するＷＳセキュリティを含むＷＳセキュリティをサポートすることができる。このとき、このようなセキュリティ拡張はオプションであり、外国のウェブサービスがＷＳセキュリティを採用しなかった場合には、相互操作性ネットワークへの入口ポイントに、それに代わってメッセージに署名しそしてそれを暗合するための権限を委任することができる（入口ポイントはユーザキーにアクセスすることができる）。これは、ネットワークへの入口ポイントが、外国ウェブサービスを伴う企業内に位置する場合に機能する。

最初に認証されずに（呼び出されたサービスが明白に処置をしない限り）、相互操作ネットワークにメッセージが受け容れられてはならない。

セキュリティプロトコル相互操作の１つの態様は、送信者と受信者が異なるセキュリティポリシー及び能力を特定するときである。相互操作フレームワークは、相互操作が可能であるか、そしていかに可能であるかを計算しなければならない。

４．異なる形式のサービス間の相互操作：
通常、サービスは、特に指示のない限り、コラボレーティブレジストリーに登録される。この説明では、あるコラボレーティブウェブサービスは、別のコラボレーティブウェブサービスとの少なくとも１つのインターフェイスにおいて相互作用することが予想される。

いわゆる単純な高性能のコラボレーティブウェブサービスがある。又、ネイティブ(native)及び外国(foreign)ウェブサービスもある。最後に、登録されたサービス及び未登録のサービスもある。単純ウェブサービスは、署名、暗号化、信頼性のあるメッセージを使用せず、そして中央の信用のある当事者からの認証を必要としない。又、両方向コレオグラフィーもサポートしない。換言すれば、単純ウェブサービスの各呼び出しは、単純ウェブサービスの以前の全ての呼び出しとは独立しており、単純ウェブサービスにはコレオグラフィー内容が保持されず、そしてその内容には、後で応答できるようにする復帰アドレスの知識もない。高性能のウェブサービスは、良好な信頼性及びセキュリティを含むことができる。コラボレーティブウェブサービスは、単純であるか又は高性能であり、更に、両方向のコレオグラフィーをサポートすることができる。通常、本出願の譲受人により準備されたもの以外のウェブサービス（外国ウェブサービス）は、単純ウェブサービスである。

本出願及び関連出願を通して説明するように、本発明の態様は、電子商取引のメカニズムを多くの方法で拡張することができる。革新的なウェブサービスは、高性能のウェブサービス及びコラボレーティブウェブサービスとしてコラボレーティブレジストリーに登録することができる。エレメントを１つずつ追加できるような、ネイティブな単純且つ高性能のウェブサービス間の継続性に対してサポートを与えることができる。高性能のウェブサービスは、それがどんなエレメントをサポートするかレジストリーにおいて宣言することができる。革新的なネイティブな単純ウェブサービスのＷＳＤＬ定義を（ＵＤＤＩから又は取引者自身のコラボレーティブレジストリーから）ダウンロードすることができ、これは、ネットワークへの入口ポイントのＵＲＬであるサービスポートを識別する。入口ポートを通して搬送されるメッセージは、そこから、それらの論理的宛先へ自動的にルーティングされる。本発明によりルーティングされるメッセージは、各ホップにおいて何が生じるか支配する相互的な操作性契約を含むか、又はそれにより支配される。ネイティブなウェブサービスは、ネイティブ又は外国の単純ウェブサービスを呼び出すことができる。

外国の単純ウェブサービスは、革新的ネットワークによりサポートすることができる。外国ウェブサービスが、革新的アドレッシング及びメッセージ認識並びに相関ＳＯＡＰ拡張を知っている場合には、両方向コレオグラフィーにコラボレーティブウェブサービスとして参加することができる。外国ウェブサービスは、革新的ＳＯＡＰ拡張の組合せを使用してもよい。それらは、コミュニティレジストリーにアクセスしたり又は相互的な操作性契約を理解したりする必要はない。本発明は、外国ウェブサービスを構築するためのソフトウェアを提供するように拡張することができ、そして第三者のソフトウェアを使用することができる。

外国ウェブサービスは、ネイティブウェブサービス又は他の外国ウェブサービスにより本発明のネットワークを経て呼び出すことができる。外国ウェブサービスは、外部ＳＯＡＰ又はｅメールを使用することができる。ｅメールの場合には、ｅメールブラウザを使用する人間のユーザがウェブサービスを「実施」し、そして単純な及びコラボレーティブなネイティブ又は外国ウェブサービスの両方と相互操作することができる。外国ウェブサービスのＷＳＤＬ定義は、コラボレーティブレジストリー又はＵＤＤＩからダウンロードすることができる。外国ウェブサービスは、革新的ネットワークへの入口ポイントでＵＲＬを呼び出すことにより、そのネットワークにおいてウェブサービスを呼び出す。コラボレーティブな外国ウェブサービスは、ネイティブなコラボレーティブウェブサービスによる呼び出しの一部分として、ＳＯＡＰ拡張において本発明のネットワークへの入口ポイントのＵＲＬが与えられ、従って、ＳＯＡＰ拡張を理解した場合に後で動的に応答することができる。

５．ネットワーク及び位置独立の相互操作：
宛先サービスコンポーネントの位置が問題となってはならず、又、サービスが登録される市場又は企業コミュニティが問題となってはならない。ルーティングアルゴリズムは、位置の透過性、及び市場又は企業コミュニティの透過性を透過的（トランスペアレント）に取り扱わねばならない。トランスポート及びセキュリティメカニズムを伴うルーティングは、セキュリティを妥協することなく、適当な企業及び市場のファイアウオールを貫通する自動トンネリングをサポートしなければならない。

６．プラットホーム独立の相互操作：
プラットホームは、ソフトウェアが実行されるハードウェア／オペレーティングシステムと、ビジネスサービスが実行されるサーバーの開発及び実行環境とを含むことができる。また、ソフトウェアが実行されるサーバーテクノロジー（Ｊ２ＥＥアプリケーションサーバー、ウェブサーバー、サーブレットランナー）を含んでもよい。ハードウェア部分の独立性は、１００％純粋なＪａｖａ(登録商標)を使用することで達成できる。開発／実行環境からの独立性は、海外コネクタ及びサーバーとの厳密な規格に基づくワイヤレベルの相互操作をサポートすることにより達成できる。サーバーテクノロジーの独立性は、コンポーネントを埋め込み可能とし、且つＪ２ＥＥ規格に適合させることにより達成できる。

売主が供給するコンポーネントのプラットホームが独立であるときには、顧客は、それらの好ましい気に入った売主から、それらの気に入ったクライアント側ツールでアクセスした好ましい開発／実行環境を使用して、サービスを開発することができる。このようなサービスは、インテリジェントネットワークにより相互的な操作価値が付加される状態で、売主が開発したサービスと依然として相互操作することができ、そして全てのサービスは、プロセスフローエンジンを使用した構築能力で、より複雑なサービスへと構築することができる。

主としてメッセージ相互操作コンポーネントに基づいて、軽量の商取引ウェブサービスサーバーを配備することができる。軽量のサーバーは、供給者の接続性、ゲートウェイライター及びＩＳＶ市場にとってターゲットとなろう。コラボレーティブなウェブサービスサーバーのより完全な実施形態は、軽量版の特別な集合である。軽量版は、ドキュメント関連開発のための基本的開発ツールを含むが、主として、サービス開発のための第三者ツールを強化するものである。ＵＩ及びドキュメントベースプロセスを中心とする自己組み込み型又は構築型サービスのための精巧で完全な開発環境は、コラボレーティブウェブサービスサーバーの実施形態と共に含まれてもよい。

７．バックオフィスシステムの相互操作：
海外コネクタとの相互操作の１つの態様は、非営業(事務)部門（バックオフィス）システムとの相互操作である。本発明の態様はバックオフィスシステムを開放して、まさにメッセージレベル及び発見レベルからの複数のサービスのように見せることにある。ツールキットは、バックオフィスシステムのオペレータが、それらのインターフェイスを単純なウェブサービスとして開放させるか、又はそれらのカスタムアダプターをウェブサービスとしてまとめることができるようにする。カスタム統合の仲介人は、確立されたＥＡＩテクノロジーを革新的メッセージングシステムと統合するか、又はウェブサービスインターフェイスを直接構成することができる。バックオフィスシステムとの統合に関する別の実施形態は、ｅメールサポートである。ｅメールサーバーを使用して、バックオフィスシステムを革新的ネットワークと一体化することができる。

バックオフィスシステムをウェブサービスとして開放すると、ＸＭＬを基本としない特殊な変換機構を含ませることができる。その一例は、ＤＢとＸＭＬとの間又はＸＭＬとフラットファイルとの間の変換、或いはＪ２ＥＥ ＣＡ１．０記録構造とＸＭＬとの間の変換である。これは、全て、下流のウェブサーバーから隠され、そして下流のウェブサービスデベローパーに対して透過的（トランスペアレント）である。

８．サービス発見及びクロスコミュニティの相互操作：
将来、取引パートナー間の相互操作が更に動的になることが考えられる。発見メカニズムは、ビジネス関係を設定する前にビジネスを一緒に行う取引パートナーを見つけるのに有用である。サービス及びそれらを申し込む取引パートナーの発見は、ＵＤＤＩ規格により行われる。ＵＤＤＩがサポートする更に強力なツールは、革新的レジストリーウェブサーバーを呼び出すことである。本発明に関連した発明は、１つのコミュニティ又は１組のコミュニティに対して職業別加入者（イエローページ）として作用するパブリックＵＤＤＩレジストリー又はプライベートＵＤＤＩレジストリーへ、データをアップロードするためのサポートを与える。コミュニティのネットワーク全般への発見が可能である。

コミュニティにわたる発見の場合に、各コミュニティは、それに関連したグローバルなホワイトページ（個人別加入者）コミュニティ又はグローバルなイエローページレジストリーのリストを有することができる。グローバルなホワイトページコミュニティは、１組の広告されたコミュニティへ要求をルーティングするためのトランスポートアドレスを含む。グローバルなイエローページレジストリーは、取引パートナーと、１組の広告されたコミュニティのサービスとを、エイリアス及びカテゴリーと共に含む。サーチは、カテゴリーで行われる。相互操作は両方向性であるので、２つのコミュニティが、共通のグローバルなホワイトページコミュニティに申し込むことができ、或いはそれらのコミュニティレジストリー内で情報を互いに直接的にルーティングすることができる。２つのコミュニティは、それらが共通のイエローページレジストリーに申し込む場合には、互いにオブジェクトを発見することができる。通常、イエローページレジストリーは、ホワイトページコミュニティ内にホスティングされる。

プログラミングレジストリーアクセスインターフェイスは、発見に対してサポートされるだけでなく、役割及び特典を含む取引パートナー情報や、ユーザ及び組織並びにそれらの関係についてもサポートされる。又、ＷＳＤＬファイル、サービスインターフェイス、変換コード、及びスキーマファイルを含む相互操作のための技術的情報を得るためのサポートもある。

９．レジストリーバージョンの相互操作：
レジストリーサービスは、他のウェブサービスとして構成されて、全サービスの相互操作性サポートから利益を得ることができる。

１０．ドキュメントセマンティックの相互操作：
インフラストラクチャーは、ペイロードの意味（セマンティック）に関心を持たない。しかしながら、ドキュメントセマンティックの相互操作は、異なるドキュメントを使用してエンド対エンドの相互操作を楽しむサービスができるようにする。送信者及び受信者は、ドキュメントファミリーメンバー及びメンバー間での変換のようなドキュメントセマンティックに対して合意して、相互操作を容易にしなければならない。バックオフィスシステムとの相互操作については、ドキュメント規格は、Ｉｄｏｃｓ及びＯＡＧＩを含んでもよい。

１１．ドキュメントバージョンの相互操作：
サービスにおける受信操作のインターフェイスは、ドキュメントの１つ以上のバージョンに対するサポートを定義することができる。革新的バージョン相互操作システムは、送信ドキュメントと、受信することが予想されるドキュメントとの間で変換を行い、そして最良に受信されたバージョンを取り上げることによりロスを減少するよう試みる。送信側でメッセージに署名して暗号化する前に、変換が行なわれる。

レジストリーは、ドキュメントファミリー内の大きな及び小さなバージョンをサポートする。大きなバージョンは、異なるスキーマ言語に適合してもよい。小さなバージョンは、任意の部分を基本バージョンに追加することが予想される。

１２．スキーマ言語の相互操作：
ペイロードＸＭＬドキュメントに対するスキーマ言語は、エンベローププロトコルで定義される。スキーマ言語の例は、ＳＯＸ及びＸＳＤＬである。これらは、ＸＭＬドキュメントのスキーマを記述するための言語である。１つの言語におけるスキーマのＸＭＬインスタンスは、別の言語における同等のスキーマのＸＭＬインスタンスとは異なる。それ故、スキーマ言語のインスタンス変換は、ゲートウェイにおける変換によりサポートされなければならない。

ゲートウェイは、いわゆる構文変換を実行することができ、ここでは、ペイロード（エレメントの関係）及び意味的な構造は不変であるが、構文及びパッケージング（packaging）が変化する。適合し得る構造が厳密に同等のＸＭＬマークアップに変換され、且つその逆も行なわれる。

１３．相互操作ステップの位置及び順序に対する依存性：
ここでの説明から、当業者であれば、相互的な操作性契約は、相互操作ステップを合意された位置において合意された順序で実行するよう確保する１つの方法であることが明らかであろう。送信者から受信者へのメッセージは、一連のコネクタを経て移動し、異なるコネクタが相互操作のための種々のステップを実行する。スキーマ言語インスタンス変換、バージョン変換、エンベロープ変換、署名、及び暗号化の位置と順序との間には相互作用がある。インフラストラクチャーは、変換を適切に順序付けする。

１４．サービスバージョンの相互操作：
ウェブサービスは、それらがレジストリー記述に関して外部にいかに現われるか及びそれらにいつメッセージをアドレスするかにより定義される。サービスをアップグレードしそしてサービスバージョンを時間と共に変更するのは当然である。サービスの新たなバージョンは、操作を追加したり、或いは既存のメッセージに任意の部分を追加又は削除したりしてもよい。又、サポートされる１組のコレオグラフィー、及びメッセージの一部分の位置を変更してもよい。ここに述べるコレオグラフィーの相互操作を使用して、送信者が新たな操作を呼び出さねばならないかどうか知ることができる。更に、サービスのバージョン番号が送信者及び受信者に分かるようにされ、これにより適切に応答することができる。

インフラストラクチャーは、１組の任意の部分が異なるとき又は本体部分が添付となるとき、或いはそれとは逆のときに相互操作に関心を持つ。

１５．コレオグラフィーの相互操作：
コレオグラフィーをサポートする少なくとも２つの実施形態がある。一方の実施形態は、プロセスフローを定義し、そして全ての参加者がこのプロセスを通してメッセージを流すようにする。プロセスフローは、サービスにおいてプロセスフローエンジンに流れる。他方の実施形態は、エンドポイントサービスそれ自体において、コレオグラフィーの詳細が分かるようにしてエンドポイントサービス間で直接的なメッセージングをサポートする。プロセスフローエンジンプロセスは、他のサービスとでメッセージを送信及び受信し、それ故、サービスそれ自体のように見える。この抽象化は非常に有用である。

プロセスフローエンジンプロセスは、サービスとしてあらわれなければならない。このプロセスとの対話を希望するアプリケーションは、このサービスへメッセージを送信し且つそこからメッセージを受信する。この抽象化のために、プロセスフローエンジンプロセスを使用して、１組のサービスをフローへと一緒に結合するプロセス定義を使用することにより大きなサービスを構成し、そしてその大きなサービスを露出することもできる。更に、プロセスフローエンジンプロセスのエンジンは、各革新的サービスにおいて利用できるようになり、それ故、多数のプロセスエンジンに及ぶような分散型プロセスを構築することができる。これが可能となるのは、分散型プロセスにおける各サブプロセスがサービスのようにみえ、そして別のサブプロセスを呼び出すサブプロセスが、別のサービスを呼び出すサービスのように処理されるからである。種々のサブプロセスは、メッセージで対話し、そしてメッセージは、各サブプロセスで得られるプロセスフロー内容を搬送して、サブプロセスをより緊密に一体化することができる。

サービスとサービスとの間の両方向コレオグラフィーにおいて考慮すべきは、送信側ＴＰ／サービス／操作を知るための能力であり、特にサービスの１つがコレオグラフィー又は会話ＩＤ拡張を直接サポートしないときに関係する。関連メッセージを会話ＩＤと相関させる方法が有用である。単純ウェブサービスとの仮想会話は可能であり、それは会話を形成する関連メッセージを相関させるためにペイロードデータを使用することによるコレオグラフィーをサポートするものではない。プロセスフローエンジンは、相関を実行するためのロジック及びリソースを含む。アドレス拡張を伴わない海外コネクタからのメッセージに対し（通常、バックオフィスシステムで言えることである）、ペイロード、レジストリー又はローカルデータベースで見られる固定のサービスへメッセージを送信して、メッセージ転送の前に宛先アドレスを推論することができる。この能力は、論理的ルーティングと称され、プロセスフローエンジンは、会話ＩＤを推論できるところの検査すべきペイロードのフィールドの構成仕様に基づいて、これを容易にする。

１６．コレオグラフィーバリエーションの相互操作：
コレオグラフィーは、参加者により申し込まれる１組のサービス形式を一緒に結合する。コレオグラフィーの全てのバリエーションは、第１メッセージが実質的に同じであるファミリーを形成する。相互操作する２つのサービス間にサポートされるファミリーは１つだけでなければならず、そのファミリーにおけるコレオグラフィーは、好みの順とすることができる。しかしながら、あるサービスは、サービスの異なる組合せを含むコレオグラフィーの多数のファミリーをサポートしてもよい。コレオグラフィーは、多極性であってもよい。

コレオグラフィーネゴシエーションの一実施形態では、コレオグラフィーの第１メッセージが送信されるときに、送信者及び受信者は、システムにより取り上げられたコレオグラフィーバリエーションについて話しをする。それらの間のコレオグラフィーは、変化し得ない。それらは、次いで、それらの処理を適宜に調整する。新たなサービスが会話に追加される場合には、送信側サービスは、多極性コレオグラフィーにおいて異なるサービスによりサポートされるコレオグラフィーバリエーション間のブリッジとして働くか、又は選択されたコレオグラフィーを強制的に使用するかを選択することができる。コレオグラフィーネゴシエーションは、ここに取り上げる共通に所有された特許出願の１つに更に説明されている。

１７．相互操作の複雑さを隠す：
本発明の態様に基づいて相互作用するサービスは、複雑な問題をカバーしながら処理できるので、相互操作についてほとんど又は全く知る必要がない。相互操作を実施する新たなモデルを構成することができる。これらモデルは、レジストリーメタデータにより駆動される相互操作に関連した複雑な問題を処理する。エンベロープ構造を完全に隠すと共に、エンベロープ特有のフィールドの意味及び構文をできるだけ隠すために、ＡＰＩ抽象化を行うことができる。全てのセキュリティポリシーは、相互的な操作性契約に含ませて、アプリケーションを実施するためのサービスデベローパーの努力を簡略化することができる。

１８．相互操作を制限するためのメカニズム：
真の相互操作に対する１つの障壁は、セキュリティである。そのモデルは、インフラストラクチャーが送信者を認証し、そしてサービスが、おそらく、レジストリーにより捕獲されたメタデータに基づいてそれを許可するというものである。この障壁は、ビジネスルール、申し込み、及び隠れたサービスを含む。ビジネスルールは、時々、コミュニティにわたる又はコミュニティ内の相互操作を制限しなければならない。申し込みは、プロバイダーのサービスポリシーにより指示されるように、相互操作の前に要求されてもよい。また、コミュニティの外側から見えないか又は特定の当事者にしか見えないサービスを隠すのが有用である。

図２は、製作者サービスと消費者サービスとの間の動的にネゴシエーションされる相互的な操作性契約の有用性を示す。この図の主たる特徴は、レジストリー２０１と、相互操作性契約を動的に決定するためのロジックを含むウェブサービスエンジン２０２と、コレオグラフィーされたインターフェイスを内部プロセスフロー２０４に開放する製作者サービス２０３と、消費者サービス２０５とを備えている。この図のテキストは、この例が、オーダー受け取りシステムを含んでいて、オーダーの受け容れを生じることを示している。製作者及び消費者サービスは、コレオグラフィー、サービスバージョン、ドキュメント、セキュリティ認証、セキュリティ暗号化、セキュリティ署名、エンベローププロトコル、及びトランスポート２１３、２１５に対するそれら自身の能力及びポリシーを有する。

動的にネゴシエーションされる相互的な操作性契約は、サービスのウェブを設定又は維持するのに必要な対方式の構成の程度を減少させる。これは、参加者により設定されるポリシー間の相違を解決するための明確なルールを与える。参加するサービスが進化するにつれて、動的にネゴシエーションされる相互的な操作性契約も進化する。

相互的な操作性契約の動的なネゴシエーションは、法的契約ネゴシエーションをより密接に近似する従来の解決策からの顕著なずれをもたらす。動的なネゴシエーションは、製作者サービスの利用性、能力及びポリシーについての記述で始まる。消費者サービスは、ＵＤＤＩのような発見プロトコルを使用して製作者サービスを容易に発見することができる。製作者及び消費者は、その能力及びポリシーについてマシン読み取り可能な仕様を有する。製作者及び消費者により確認される１以上のスキーマは、各当事者の能力及びポリシーをいかに解釈しそして交点をいかに見出すかを明確に定義する。異なる相互操作性の事項を解決するためのネゴシエーションを勧めるのではなく、このシステムは、２つの形式の対立、即ち別々のオプションに対する好みの対立、及び動的にネゴシエーションされる相互的な操作性契約に基づいて交換されるメッセージの特定部分に署名及び暗号化のようなセキュリティ手段を適用すべきかどうかに関する対立を、いかに解決するかに関する判断ルールを与える。

好みに関する判断ルールは、受信者の勝ち、送信者の勝ち、厳格さが最も高い要求の勝ち、厳格さが最も低い要求の勝ち、又は両当事者の好みの重み付けされた事項が適用される等の標準的なルールでよい。例えば、セキュリティ手段を適用すべきかどうかについての判断ルールも同様である。オーバーライドを含むこれらの判断ルールは、参考としてここに援用する、本出願と同日に出願された別の特許出願「Dynamic Negotiation Of Security Arrangements Between Web Servers」に更に説明されている。

ある場合には、製作者は、消費者が製作者と対話できる前に申し込みを必要とすることがある。これは、クレジット及び認証テック等を容易にすることができる。交差及び判断ルールのフレームワークは、特に申し込みが製作者によって受け容れられた場合に、信用のあるソフトウェアエージェントが相互的な操作性合意を動的にネゴシエーションできるようにする。相互的な操作性契約を動的にネゴシエーションすることが許された信用のあるソフトウェアエージェントをこのように使用することは、効果を得ることができる前に製作者及び消費者の両方により暗号で署名された、更に従来のＣＰＡスタイルの相互操作性合意とは著しく異なる。（この説明は、読者の理解を助けるため製作者及び消費者のサービスに関して述べるが、それらの役割が製作者であるか、消費者であるか、仲介人、その他であるかに関わらず、２以上のサービスに等しく適用される。）

１組のスキーマ及び例示的な相互操作性の契約は、本発明の態様に関する付加的な詳細を与える。

ソースコード添付資料におけるスキーマ「Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ．ＸＳＤ」は、本発明の多数の態様を含む相互的な操作性契約をモデリングするのに使用できる。この実施形態では、マシン読み取り可能な出力ファイルがＸＭＬドキュメントである。他の実施形態では、他のデータ構造体、例えば、ＸＭＬコードの後にモデリングされたツリー構造を使用して、同じ情報を記憶することができる。スキーマ「Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ．ＸＳＤ」は、ドキュメンテーション発生ビューを含むスキーマの多数の別々のビューを与えるＸＭＬ Ｓｐｙ ＴＭのような一体化開発環境（ＩＤＥ）にファイルをロードすることにより最も良く理解される。

Ｓｐｙスキーマ設計ビューで見ると、「Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ．ＸＳＤ」コンポーネントは、一般的契約セクション、ルーティング契約セクション、変換契約セクション、セキュリティ契約セクション及び契約署名を含む。これら４つのセクションの各々は、以下に述べる別のスキーマを参考として組み込んでいる。契約署名は、従来の相互操作性契約とは異なり、契約をネゴシエーションする信用のあるソフトウェアエージェントにより適用される。契約に対する当事者の個別の署名は必要とされない。契約署名の一部分は、ソースコードに更に文書化されたように、ＳｉｇｎｅｄＩｎｆｏＴｙｐｅ、ＳｉｇｎａｕｒｅＶａｌｕｅ、ＫｅｙＩｎｆｏ及びＯｂｊｅｃｔＴｙｐｅを含む。

また、ソースコード添付資料におけるスキーマ「ＧｅｎａｒａｌＣｏｎｔｒａｃｔ．ＸＳＤ」は、本発明の多数の態様を含む相互操作性契約の一般的セクションをモデリングするのに使用できる。「ＧｅｎａｒａｌＣｏｎｔｒａｃｔ．ＸＳＤ」コンポーネントは、「ｔｏ ａｎｄ ｆｒｏｍ ｉｎｆｏｒｍａｔｉｏｎ」、「ＥｒｒｏｒＨａｎｄｌｉｎｇ」及び「ＤｅｌｉｖｅｒｙＲｅｃｅｉｐｔＨａｎｄｌｉｎｇ」を含む。コンポーネントは、任意であるが、「ＲｅｑｕｉｒｅｄＭｅｓｓａｇｅＰａｒｔｓ」及び「ＯｐｔｉｏｎａｌＭｅｓｓａｇｅＰａｒｔｓ」、並びに送信及び受信コネクタ能力を含む。「ｔｏ ａｎｄ ｆｒｏｍ ｉｎｆｏｒｍａｔｉｏｎ」は、当該当事者／サービス／アクティビティに関連している。「ＥｒｒｏｒＨａｎｄｌｉｎｇ」コンポーネントは、能力について記述し、そして任意であるが、エラーメッセージをどこに送信すべきか識別する。「ＥｒｒｏｒＨａｎｄｌｉｎｇ」と同様に、「ＤｅｌｉｖｅｒｙＲｅｃｅｉｐｔＨａｎｄｌｉｎｇ」は、メッセージのための任意のアドレスをもつ能力パラメータである。

配送受領は、非否認を実施するのに使用される。必要なメッセージ及び任意の部分は、その名前の通りである。サービスバージョン及びドキュメントファミリーバージョンにおける必要な部分及び任意な部分の役割は、関連出願に詳細に説明されている。送信側及び受信側コネクタ能力は、コネクタの属性及び属性の価値（署名又は暗号化の能力等）をリストする。これら能力は、非コラボレーティブ要求又は一方向メッセージに対して現われないことがあるので、任意である。これらのコンポーネントは、ソースコードにおいて更に文書化される。

また、ソースコード添付資料におけるスキーマ「ＲｏｕｔｉｎｇＣｏｎｔｒａｃｔ．ＸＳＤ」は、本発明の多数の態様を含む相互操作性契約のルーティングセクションをモデリングするのに使用できる。Ｓｐｙスキーマ設計ビューで見ると、「ＲｏｕｔｉｎｇＣｏｎｔｒａｃｔ．ＸＳＤ」コンポーネントは、ルートを特定する。ルートは、送信者及び受信者を含むルートにおける２つ以上の「ＲｏｕｔｅＮｏｄｅ」を含む。ノードへの入口及び出口チャンネルは、ノードに到達するために又はノードから退出するときに使用されるトランスポート及びエンベローププロトコルにより定義される。この情報の対称性は、出口及び入口チャンネルが逆のルートに対して役割を逆転できるようにする。このスキーマは、ソースコードにおいて更に文書化される。ルーティングについては、関連出願に詳細に説明されている。

同日に出願された特許出願の１つに対処されているように、セキュリティ構成のネゴシエーションは、送信側及び受信側サービスのセキュリティプロフィールを使用して、相互に合意可能なセキュリティ構成を決定するコンピュータベースプロセスにより実行される。好ましくは、このセキュリティ構成は、ユーザを介在せずに、ネゴシエーションされるか、又は潜在的に規則的に更新される。この構成は、ユーザの要求があったときに、又はユーザを介在せずに、メッセージが交換されるとき、又は他の何らかの周期又は時々、例えば、毎月、毎週、毎日、或いは特定の送信者と受信者との間のメッセージの交換に影響する事象が発生したとき（例えば、ソフトウェアコンポーネントの故障、又はセキュリティ好みの変化というような場合）、既にネゴシエーションされた構成が故障したとき、又は他の何らかの周期的又は時々のベースで、ネゴシエーションされ、更新され、又は有効性についてチェックされる。

ソースコード添付資料におけるスキーマ「ＳｅｃｕｒｉｔｙＣｏｎｔｒａｃｔ．ＸＳＤ」は、マシン読み取り可能なセキュリティ相互操作性の契約ドキュメントを準備するためのモデルとして使用することができる。この実施形態では、マシン読み取り可能なドキュメントは、ＸＭＬドキュメントである。他の実施形態では、他のデータ構造体、例えば、ＸＭＬコードの後にモデリングされたツリー構造を使用して、同じ情報を記憶してもよい。このスキーマは、セキュリティポリシーに対するポリシー及びチャンネルを定義する。セキュリティチャンネルは、署名、暗号化及び認証アルゴリズムのようなセキュリティアルゴリズムを実行するリソース及びリソースへのルートを定義する。またこれは、非否認及び許可リソースを含んでもよい。

１組の計算型セキュリティ構成は、次のように部分的に再現される。

この１組のセキュリティ構成は、セキュリティポリシー及びセキュリティチャンネルに対する２つの主要セクションを有する。この例では、全メッセージに適用できる１つのセキュリティポリシーと、該セキュリティポリシーの部分を実施するための多数のセキュリティチャンネルがある。セキュリティポリシーセクションは、署名ポリシー、暗号化ポリシー及び暗号キー情報を設定する。またこれは、送信又は受信の認証、許可及び非否認に関するポリシーを設定してもよい。この実施形態では、同じ署名及び暗号化ポリシーがドキュメントの全ての部分に適用される。他の実施形態では、異なる部分又は１つの部分内の異なるエレメントに多数のアルゴリズムを適用することができる。

署名、暗号化及び認証のために選択されるアルゴリズムは、オプションセットを含むテンプレートにより抽象化され、アルゴリズムの選択を簡単にする。選択されるアルゴリズムは、ロジック及びリソースに関連付けられ、従って、メッセージの異なる部分に署名し／照合し及びそれを暗号化し／暗号解読するのに、異なるサービス又はプロセスを使用することができる。セキュリティポリシーセクションの暗号キーエレメントにおいてパブリックキー又は証明書を送信することができる。セキュリティチャンネルセクションは、セキュリティポリシーの適用に含まれるサービス又はコネクタを記述する。特定のポリシーについては、チャンネルセクションは、セキュリティポリシーを適用する際にサポートを要求するソースコネクタ（例えば、暗号化を要求する送信側サービス）と、セキュリティポリシーを適用するか、又はセキュリティポリシーを適用するロジック及びリソースに対して仲介者として作用するターゲットコネクタとを識別する。署名、暗号化、認証、許可、又は非否認のような特定のセキュリティポリシーに対して、そのセキュリティポリシーを実行するのに必要な特定の情報がセキュリティチャンネルセクションにおいて与えられる。

図３は、送信者が、セキュリティ、変換及び他の構成の計算に対してローカルであるときに、受信者の情報を得るための別の実施形態を示す。図中、ローカルレジスタ３３１及びリモートレジスタ３３２が示されている。この例では、送信者がローカルであり、そして受信者がリモートである。送信者のデータは、ローカルレジスタ３３１に現存し且つ完全である。送信者の情報は、収集され（３２１）、そしてセキュリティ構成３１１を計算するロジック及びリソースに利用できるようにされる。受信者のデータは、例えば、受信者が送信者と同じコミュニティにいてコミュニティ規模のレジストリーが存在するか、或いは受信者の情報が最近得られてローカルキャッシュされた場合に、現存して且つ完全である。受信者の情報がどこで見つかるか（３３１又は３３２）に基づいて、プロセス３２２又は３２３が呼び出されて、受信者の情報を収集し、そしてセキュリティ構成を計算するロジックに利用できるようにされる。１組のセキュリティ構成３０１が得られる。

２つの形式の好みを調停する必要がある。コミュニティ及びサービス特有の両好みが示される。一方の形式の好みは、アルゴリズムテンプレート間にある。オプションＢとＤとの間を選択するための判断ルールは、メッセージサービスの好みの一方又は両方を考慮してもよい。例えば、署名のための受信側サービスの好み（Ｄ）、又は暗号化のための送信側サービスの好み（Ｂ）は、一致するものの中から選択されてもよい。両方の好みを考慮に入れて、最も厳格なもの（Ｂ）又は最も厳格でないもの（Ｄ）が選択される。別の実施形態では、各サービスは、それらの好みに重み又はスコアをつけ、合成された重み又はスコアを使用して、両方の好みを考慮してもよい。

第２の形式の好みは、メッセージの一部分に署名すべきか又は暗号化すべきかである。判断テーブルを使用して、メッセージの一部分に署名すべきか又は暗号化すべきかに関連した好みの形式の調整を実施してもよい。この場合も、署名すべきでない好みを受け容れたり受信者の好み又は単なる反対を受け容れたりするように判断を偏らせることもできる。考えられる判断ルールを実施するのに使用できる判断テーブルを以下に示す。

セキュリティ判断ルールのためのこれらのフォーマットは、他の好みのネゴシエーションに等しい力関係で適用される。変換のような幾つかの特殊なケースでは、関連出願に説明されたように、情報ロス又は変換精度の基準値（metrics）を適用できる。

また、ソースコード添付資料におけるスキーマ「ＴｒａｎｓｆｏｒｍａｔｉｏｎＣｏｎｔｒａｃｔ．ＸＳＤ」は、本発明の多数の態様を含む相互操作性契約のドキュメント変換セクションをモデリングするのに使用できる。Ｓｐｙスキーマ設計ビューで見ると、「ＴｒａｎｓｆｏｒｍａｔｉｏｎＣｏｎｔｒａｃｔ．ＸＳＤ」コンポーネントは、変換すべき１つ以上のドキュメントを特定し、そして任意であるが、応答ドキュメントを特定する。
ＤｏｃｕｍｅｎｔＴｏＴｒａｎｓｆｏｒｍＴｙｐｅ」は、ソースドキュメントＩＤ及びパート名と、受信者アタッチメント好みフラグとを含む。これは、任意であるが、アタッチメントパートＩＤと、変換をいかに行うかを示す１つ以上の変換マップとを含む。このスキーマ及び特に変換マップは、ソースコードに更に文書化されている。ドキュメント変換は、関連特許出願に詳細に説明されている。

計算された相互操作性契約の部分例が、添付したソースコードの「ＩｎｔｅｒｏｐｅｒａｂｉｌｉｔｙＣｏｎｔｒａｃｔ．ＸＭＬ」に示されている。この例は、一般的なルーティング及び変換契約セクションを含む。セキュリティ契約セクションの例については上記を参照されたい。この例は、特に、利用できる添付のスキーマと共に、当業者にほぼ自明であろう。その幾つかを、以下に示す。

一般的契約セクションは、コラボレーティブな相互作用を支配するので、これを契約として識別する。メッセージは、非否認、エラー取り扱い及び他の使用に対してアーカイブされる。ユーティリティは、集計された（又は構成的には、特定の）ビジネスインテリジェンス情報をコンパイルする際にこの契約により支配されるメッセージを考慮することが許される。「ｂｕｙＰａｒｔｙＣｏｎｓｕｍｅｒＯｒｄｅｒＭａｎａｇｅｍｅｎｔｓｅｎｄＯｒｄｅｒ」アクティビティに対して「フローム・アドレス(from address)」が与えられる。経歴的ＤＤＩＤ番号又はアドレスは、送信側サービスを更に識別する。「ｓｅｌｌＰａｒｔｙｐｒｏｖｉｄｅｒＯｒｄｅｒＭａｎａｇｅｍｅｎｔ」プロセスオーダーアクティビティに対して受信側アドレスが与えられる。送信者は、指定のアドレスに対してＣ１ ＳＯＡＰ１．０エンベローププロトコルを使用して非同期エラーメッセージを受け容れる。送信者は、受信者が非同期で発生できる配送受領を要求する。要求されるメッセージ部分又はドキュメントは、オーダー及びイメージである。任意であるが、あるＸＭＬＰａｒｔを含ませることができる。送信側及び受信側コネクタ能力が、署名、暗号化、アーカイブ、メッセージエンベロープ、マニフェスト形式、及び配送受領形式に対して列挙される。例示的な一般的契約セクションは、添付したソースコードにける例の部分である。

一般的契約セクションに加えて、ルーティング契約セクション及び変換契約セクションがある。例示的なルーティング契約セクションは、次の通りである。

この例は、上述したスキーマの適用を示している。同様に、変換スキーマの適用を示す例示的な変換契約は、次の通りである。

以上の説明から、当業者であれば、本発明の態様及び要素から広範囲なシステム及び方法を構成できることが明らかであろう。一実施形態は、相互操作性データを特定するマシン読み取り可能なデータ構造体である。このマシン読み取り可能なデータ構造体が有用となる環境は、消費側サービスと提供又は製作側サービスとの間の相互操作に対するものである。これらのサービスは、中間コネクタを任意に使用して、ネットワークを経てドキュメントを交換する。

マシン読み取り可能なデータ構造体は、次の有用なデータエレメントの２以上を結合してもよい。即ち、サービス及び中間コネクタの名前により特定されるサービスとサービスとの間のルート；メッセージの交換に使用されるべきコレオグラフィーバージョン；メッセージをアーカイブし、メッセージの信頼性ある配送を確保し、そして受領確認を要求するためのポリシー；特定メッセージの部分の要求と、使用すべき少なくとも１つの署名アルゴリズムとを指定する仕様；特定メッセージの部分の暗号化要求と、使用すべき少なくとも１つの暗号化アルゴリズムとの仕様；使用すべき１つ以上の認証手順の仕様；特定メッセージに含まれたドキュメントに適用すべき１つ以上の変換ロジックの仕様；及びドキュメントの非変換コピーを、ドキュメントの変換コピーと共に含ませるべきかどうかの仕様である。特許請求の範囲に特定された組合せは、これで全部ではない。上記有用なデータエレメントの２つ以上の置き換えが明確に説明される。

本発明の更に別の実施形態は、プロセスにより準備された現在の相互操作性データを特定するマシン読み取り可能なデータ構造体である。このマシン読み取り可能なデータ構造体が有用となる環境は、消費側サービスと提供又は製作側サービスとの間の相互操作である。これらのサービスは、ネットワークを経てドキュメントを交換する。これらのサービスは、中間コネクタを任意に使用してもよい。両当事者により署名される契約のような静的な相互操作契約とは異なり、このマシン読み取り可能なデータ構造体は、サービス間でメッセージ交換を開始する要求に応答してプロセスにより生成される。

このプロセスは、サービスに対する相互操作性データにアクセスし、サービスに対する相互操作性データに交差し、そして２つ以上の相互に受け容れられるオプションを形成する交差相互操作性データに対して、判断ルールを適用して１つのオプションを選択することを含む。このマシン読み取り可能なデータ構造体は、以前の実施形態で述べた有用なデータエレメントの置き換えを含んでもよい。使用する判断ルールは、メッセージを交換するサービスにより申し込まれてもよいし、或いは取引コミュニティへのサービスの申し込みにより採用されてもよい。本明細書全体にわたって説明したいずれの判断ルールも、この実施形態の更なる態様として使用されてもよい。

本発明の別の実施形態は、１つ以上のセキュリティチャンネルを特定するマシン読み取り可能なデータ構造体である。このマシン読み取り可能なデータ構造体が有用となる環境は、消費側サービスと提供又は製作側サービスとの間の相互操作である。これらのサービスは、ネットワークを経てドキュメントを交換する。これらのサービスは、中間コネクタを任意に使用してもよい。セキュリティチャンネルは、指定、暗号化又は認証の１つ以上に適用される。またそれらは、許可、又は非否認、或いはこれらセキュリティ関連タスクの任意の組合せに適用されてもよい。
セキュリティチャンネルそれ自体は、セキュリティ関連要求を発信するコネクタ及びそのセキュリティ関連要求に応答するコネクタの仕様と、セキュリティ関連要求の仕様とを含む。セキュリティ関連要求は、上述したセキュリティ関連タスクの１つ以上を含んでもよい。セキュリティチャンネルを含むこのデータ構造体は、サービス間のメッセージ交換を開始する要求に応答して形成されてもよい。

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

マシン読み取り可能で動的にネゴシエーションされる相互操作性契約が有用となる１つの環境であるコミュニティ及びコミュニティのネットワークを示す図である。 異なるトランスポート／エンベローププロトコル及びテクノロジーをサポートするために同じコネクタをオーバーレイする多数のハブ及びスポーク組織を示す図である。 セキュリティの計算、変換及び他の構成に対して送信者がローカルであるときに受信者の情報を得るための別の実施形態を示す図である。

Claims (29)

1. 消費側サービス及び提供側サービスのための相互操作性データを特定するマシン読み取り可能なデータ構造体であって、前記サービスは、中間コネクタを任意に使用してネットワークを経てドキュメントを交換するものであり、前記データ構造体は、
   前記サービス及び前記中間コネクタの名前により特定されるサービス間のルート、且つ前記名付けられたサービス及びコネクタ間のルートと、
   メッセージの交換に使用されるべきコレオグラフィーバージョンと、
   前記メッセージをアーカイブし、前記メッセージの信頼性ある配送を確保し、そして受領確認を要求して、受領の否認を減少できるようにするためのポリシーと、
   を備えたデータ構造体。
2. 前記サービス間で交換される特定メッセージの部分に対する署名要求と、使用すべき少なくとも１つの署名アルゴリズムとに関する仕様を更に備えた請求項１に記載のデータ構造体。
3. 前記サービス間で交換される特定メッセージの部分に対する暗号化要求と、使用すべき少なくとも１つの暗号化アルゴリズムとに関する仕様を更に備えた請求項１に記載のデータ構造体。
4. 使用すべき１つ以上の認証手順の仕様を更に備えた請求項１に記載のデータ構造体。
5. 前記サービス間で交換される特定メッセージに含まれたドキュメントに適用すべき１つ以上の変換ロジックの仕様と、
   前記ドキュメントの未変換のコピーを、前記ドキュメントの変換されたコピーと共に含ませるべきかどうかの仕様と、
   を更に備えた請求項１に記載のデータ構造体。
6. 消費側サービス及び提供側サービスのための相互的な操作性データを特定するマシン読み取り可能なデータ構造体であって、前記サービスは、中間コネクタを任意に使用してネットワークを経てドキュメントを含むメッセージを交換するもので、前記データ構造体は、
   前記サービス間で交換される特定メッセージの部分に対する署名要求と、使用すべき少なくとも１つの署名アルゴリズムとに関する仕様と、
   前記サービス間で交換される特定メッセージの部分に対する暗号化要求と、使用すべき少なくとも１つの暗号化アルゴリズムとに関する仕様と、
   使用すべき１つ以上の認証手順の仕様と、
   を備えたデータ構造体。
7. 前記サービス及び中間コネクタの名前により特定されるサービス間のルート、且つ前記名付けられたサービス及びコネクタ間のルートを更に備えた請求項６に記載のデータ構造体。
8. メッセージの交換に使用されるべきコレオグラフィーバージョンを更に備えた請求項６に記載のデータ構造体。
9. 前記メッセージをアーカイブし、前記メッセージの信頼性ある配送を確保し、そして受領確認を要求して、受領の否認を減少できるようにするためのポリシーを更に備えた請求項６に記載のデータ構造体。
10. 前記サービス間で交換される特定メッセージに含まれたドキュメントに適用すべき１つ以上の変換ロジックの仕様と、
    前記ドキュメントの未変換のコピーを、前記ドキュメントの変換されたコピーと共に含ませるべきかどうかの仕様と、
    を更に備えた請求項６に記載のデータ構造体。
11. 消費側サービス及び提供側サービスのための相互操作性データを特定するマシン読み取り可能なデータ構造体であって、前記サービスは、中間コネクタを任意に使用してネットワークを経てドキュメントを含むメッセージを交換するもので、前記データ構造体は、
    前記サービス間で交換される特定メッセージに含まれたドキュメントに適用すべき１つ以上の変換ロジックの仕様と、
    前記ドキュメントの未変換のコピーを、前記ドキュメントの変換されたコピーと共に含ませるべきかどうかの仕様と、
    を備えたデータ構造体。
12. 前記サービス及び中間コネクタの名前により特定されるサービス間のルート、及び前記名付けられたサービス及びコネクタ間のルートを更に備えた請求項１１に記載のデータ構造体。
13. メッセージの交換に使用されるべきコレオグラフィーバージョンを更に備えた請求項１１に記載のデータ構造体。
14. 前記メッセージをアーカイブし、前記メッセージの信頼性ある配送を確保し、そして受領確認を要求して、受領の否認を減少できるようにするためのポリシーを更に備えた請求項１１に記載のデータ構造体。
15. 前記サービス間で交換される特定メッセージの部分に対する署名要求と、使用すべき少なくとも１つの署名アルゴリズムとに関する仕様を更に備えた請求項１１に記載のデータ構造体。
16. 前記サービス間で交換される特定メッセージの部分に対する暗号化要求と、使用すべき少なくとも１つの暗号化アルゴリズムとに関する仕様を更に備えた請求項１１に記載のデータ構造体。
17. 使用すべき１つ以上の認証手順の仕様を更に備えた請求項１１に記載のデータ構造体。
18. 消費側サービス及び提供側サービスのための現在の相互的な操作性データを特定するマシン読み取り可能なデータ構造体であって、前記サービスは、ネットワークを経てドキュメントを含むメッセージを交換するものであり、前記データ構造体は、
    前記サービス間にメッセージの交換を開始するための要求に応答して、前記サービスのための相互操作性データにアクセスし、
    前記サービスのための相互操作性データに交差し、そして
    ２つ以上の相互に受け容れ可能なオプションを形成する前記相互操作性データの交差に対して、判断ルールを適用して１つのオプションを選択する、
    というプロセスにより作成されたデータ構造体。
19. 前記判断ルールは、前記サービスによって申し込まれることを特徴とする請求項１８に記載のデータ構造体。
20. 前記判断ルールは、取引コミュニティへの前記サービスの申し込みにより採用されることを特徴とする請求項１８に記載のデータ構造体。
21. 前記相互的な操作性データは、
    前記サービス及び中間コネクタの名前により特定されるサービス間のルート、及び前記名付けられたサービス及びコネクタ間のルートと、
    メッセージの交換に使用されるべきコレオグラフィーバージョンと、
    前記メッセージをアーカイブし、前記メッセージの信頼性ある配送を確保し、そして受領確認を要求して、受領の否認を減少できるようにするためのポリシーと、
    前記サービス及び中間コネクタの名前により特定されるサービス間のルート、及び前記名付けられたサービス及びコネクタ間のルートと、
    メッセージの交換に使用されるべきコレオグラフィーバージョンと、
    前記メッセージをアーカイブし、前記メッセージの信頼性ある配送を確保し、そして受領確認を要求して、受領の否認を減少できるようにするためのポリシーと、
    前記サービス間で交換される特定メッセージに含まれたドキュメントに適用すべき１つ以上の変換ロジックの仕様と、
    前記ドキュメントの未変換のコピーを、前記ドキュメントの変換されたコピーと共に含ませるべきかどうかの仕様と、
    の１つ以上を含む請求項１８に記載のデータ構造体。
22. 前記相互操作性データは、
    前記サービス及び中間コネクタの名前により特定されるサービス間のルート、及び前記名付けられたサービス及びコネクタ間のルートと、
    メッセージの交換に使用されるべきコレオグラフィーバージョンと、
    前記メッセージをアーカイブし、前記メッセージの信頼性ある配送を確保し、そして受領確認を要求して、受領の否認を減少できるようにするためのポリシーと、
    前記サービス及び中間コネクタの名前により特定されるサービス間のルート、及び前記名付けられたサービス及びコネクタ間のルートと、
    メッセージの交換に使用されるべきコレオグラフィーバージョンと、
    前記メッセージをアーカイブし、前記メッセージの信頼性ある配送を確保し、そして受領確認を要求して、受領の否認を減少できるようにするためのポリシーと、
    前記サービス間で交換される特定メッセージに含まれたドキュメントに適用すべき１つ以上の変換ロジックの仕様と、
    前記ドキュメントの未変換のコピーを、前記ドキュメントの変換されたコピーと共に含ませるべきかどうかの仕様と、
    の１つ以上を含む請求項１９に記載のデータ構造体。
23. 前記相互操作性データは、
    前記サービス及び中間コネクタの名前により特定されるサービス間のルート、及び前記名付けられたサービス及びコネクタ間のルートと、
    メッセージの交換に使用されるべきコレオグラフィーバージョンと、
    前記メッセージをアーカイブし、前記メッセージの信頼性ある配送を確保し、そして受領確認を要求して、受領の否認を減少できるようにするためのポリシーと、
    を備えた請求項１８に記載のデータ構造体。
24. 前記相互操作性データは、
    前記サービス間で交換される特定メッセージの部分に対する署名要求と、使用すべき少なくとも１つの署名アルゴリズムとに関する仕様と、
    前記サービス間で交換される特定メッセージの部分に対する暗号化要求と、使用すべき少なくとも１つの暗号化アルゴリズムとに関する仕様と、
    使用すべき１つ以上の認証手順の仕様と、
    を備えた請求項１８に記載のデータ構造体。
25. 前記相互操作性データは、
    前記サービス間で交換される特定メッセージに含まれたドキュメントに適用すべき１つ以上の変換ロジックの仕様と、
    前記ドキュメントの未変換のコピーを、前記ドキュメントの変換されたコピーと共に含ませるべきかどうかの仕様と、
    を備えた請求項１８に記載のデータ構造体。
26. 消費側サービス及び提供側サービスのための相互的な操作性データを特定するマシン読み取り可能なデータ構造体であって、前記サービスは、中間コネクタを任意に使用してネットワークを経てドキュメントを含むメッセージを交換するもので、前記データ構造体は、
    署名、暗号化、又は認証の１つ以上に適用可能な１つ以上のセキュリティチャンネルを備え、これらセキュリティチャンネルは、
    （ａ）セキュリティ関連要求を発信するコネクタと、
    （ｂ）前記セキュリティ関連要求に応答するコネクタと、
    （ｃ）署名、暗号化、又は認証の１つ以上としての前記セキュリティ関連要求の仕様と、を含むものであるデータ構造体。
27. 前記セキュリティチャンネルは、署名、暗号化、認証又は非否認の１つ以上と、前記セキュリティ関連要求が署名、暗号化、認証又は非否認の１つ以上である場合の仕様とに適用できる請求項２６に記載のデータ構造体。
28. 前記データ構造体は、サービス間にメッセージの交換を開始するための要求に応答して形成される請求項２６に記載のデータ構造体。
29. 前記データ構造体は、サービス間にメッセージの交換を開始するための要求に応答して形成される請求項２７に記載のデータ構造体。

Images