(57)【要約】【課題】  Ｗｅｂサービス・アプリケーション・モデルをの一般的なメッセージ操作に基づいて定義するＳＯＡＰベースのプロトコルを含むＷｅｂサービス・アプリケーション・プロトコルを提供すること。【解決手段】  ＷＳＡＰは、Ｗｅｂサービスをそれが互いにどうやり取りするかの点で定義する基礎を提供する。ＷＳＡＰは、サービスの振る舞いにそれぞれ個別のポート（ＵＲＩ）を提供し、サービスの振る舞いと直接のやり取りができる。ＷＳＡＰは、メッセージとは何か、メッセージの処理とは何か、それが受信側の状態／振る舞いにどう関わるかを識別する操作に関する共有意味論を定義する。メッセージの順序付けは、何が起きているかのコンテクストも提供する。操作、順序付けの既知の特徴の結果、仲介者は、交換メッセージを処理して通信に付加価値を付加可能である。ＳＯＡＰ処理モデルは、複数のＷｅｂサービスを並列又は逐次的に動作させる合成を定義する。【選択図】  図３
2005339555.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティング環境において、
サービスの分岐する振る舞いを決定すること、
分岐する振る舞いのそれぞれに対して、その振る舞いに対応するサービスの状態へのアクセスを可能にする識別子を割り当てること、および
割り当てられた識別子を、クライアントの要求に応答して返して、前記クライアントが、サービスの状態へのアクセスを、前記識別子を割り当てた前記振る舞いによって行えるようにすること
を備えることを特徴とする方法。
【請求項２】
前記サービスが取り扱う能力のある操作を定義する規約を、前記クライアントに返すことをさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
規約を前記クライアントに返すことは、文書の識別子を前記クライアントに提供することを備えることを特徴とする請求項２に記載の方法。
【請求項４】
バインディング・リストを前記クライアントに提供することをさらに備えることを特徴とする請求項２に記載の方法
【請求項５】
前記規約は、ＬＯＯＫＵＰ、ＣＲＥＡＴＥ、ＱＵＥＲＹ、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ、ＧＥＴ、ＮＯＴＩＦＹ、ＲＥＰＬＩＣＡＴＥ、ＣＡＮＣＥＬＲＥＰＬＩＣＡＴＥ、ＳＵＢＳＣＲＩＢＥ、ＵＮＳＵＢＳＣＲＩＢＥ、およびＤＲＯＰの操作を備える集合からの少なくとも１つの操作を定義することを特徴とする請求項２に記載の方法。
【請求項６】
サービスは、前記集合の操作のうちの少なくとも２つを、定義された順序で実装することを特徴とする請求項５に記載の方法。
【請求項７】
識別子を分岐する振る舞いのそれぞれに割り当てることは、ＵＲＩを分岐する振る舞いのそれぞれに割り当てることを備えることを特徴とする請求項１に記載の方法。
【請求項８】
クライアントから、割り当てた識別子に基づいてエンティティに送られたメッセージを受け取ることをさらに備えることを特徴とする請求項１に記載の方法。
【請求項９】
前記エンティティは、仲介者を含み、前記仲介者で前記メッセージを処理することをさらに備えることを特徴とする請求項８に記載の方法。
【請求項１０】
前記識別子の１つは、前記サービスに対するどの購読も別個の状態を持つような購読リストに対応することを特徴とする請求項１に記載の方法。
【請求項１１】
前記購読リスト上のサブスクライバに通知することをさらに備えることを特徴とする請求項１０に記載の方法。
【請求項１２】
別のサービスの同期を、前記購読リスト上のサブスクライバー・サービスに対してデータを複製することによって行うことをさらに備えることを特徴とする請求項１０に記載の方法。
【請求項１３】
購読リストの状態の変更を、ＲＥＰＬＩＣＡＴＥ、ＣＡＮＣＥＬＲＥＰＬＩＣＡＴＥ、ＳＵＢＳＣＲＩＢＥ、およびＵＮＳＵＢＳＣＲＩＢＥの操作を備える集合からの少なくとも１つの操作に応答して行うことをさらに備えることを特徴とする請求項１０に記載の方法。
【請求項１４】
前記購読リストの維持を、ヘルパ・サービスと通信することによって行うことをさらに備えることを特徴とする請求項１０に記載の方法。
【請求項１５】
バインディング・リストを前記クライアントに提供することをさらに含み、前記ヘルパ・サービスは、前記バインディング・リスト内で識別されることを特徴とする請求項１４に記載の方法。
【請求項１６】
実行すると請求項１に記載の方法を実行する、コンピュータ実行可能命令を有する少なくとも１つのコンピュータ可読媒体。
【請求項１７】
コンピューティング環境において、
サービスで、規約に対する要求を受け取ること、および
規約の文書の識別子およびバインディング・リストの文書の識別子を、前記要求に応答して提供することを含み、前記規約の文書は、メッセージ順序づけを備える規約情報および前記サービスの振る舞いに対応する１組の対話ポイントを含み、前記バインディング・リストの文書は、サービスの関係の情報を備える
ことを特徴とする方法。
【請求項１８】
前記バインディング・リストの文書は、前記サービスに対する少なくとも１つの購読リストを維持する少なくとも１つのヘルパ・サービスの識別子を備えることを特徴とする請求項１７に記載の方法。
【請求項１９】
ＣＲＥＡＴＥ要求を対話ポイントで受け取ることをさらに備えることを特徴とする請求項１７に記載の方法。
【請求項２０】
ＱＵＥＲＹ要求を対話ポイントで受け取ることをさらに備えることを特徴とする請求項１７に記載の方法。
【請求項２１】
ＧＥＴ要求を対話ポイントで受け取ることをさらに備えることを特徴とする請求項１７に記載の方法。
【請求項２２】
ＩＮＳＥＲＴ要求を対話ポイントで受け取ることをさらに備えることを特徴とする請求項１７に記載の方法。
【請求項２３】
ＵＰＤＡＴＥ要求を対話ポイントで受け取ることをさらに備えることを特徴とする請求項１７に記載の方法。
【請求項２４】
ＤＥＬＥＴＥ要求を対話ポイントで受け取ることをさらに備えることを特徴とする請求項１７に記載の方法。
【請求項２５】
ＤＲＯＰ要求を対話ポイントで受け取ることをさらに備えることを特徴とする請求項１７に記載の方法。
【請求項２６】
通知を対話ポイントで受け取ることをさらに備えることを特徴とする請求項１７に記載の方法。
【請求項２７】
購読リストの修正を対象とする要求を対話ポイントで受け取ることをさらに備えることを特徴とする請求項１７に記載の方法。
【請求項２８】
前記購読リストの状態の変更を、ＲＥＰＬＩＣＡＴＥ、ＣＡＮＣＥＬＲＥＰＬＩＣＡＴＥ、ＳＵＢＳＣＲＩＢＥ、およびＵＮＳＵＢＳＣＲＩＢＥの操作を備える集合からの少なくとも１つの操作に応答して行うことをさらに備えることを特徴とする請求項２７に記載の方法。
【請求項２９】
前記購読リストの状態を変更することは、ヘルパ・サービスと通信することを備えることを特徴とする請求項２８に記載の方法。
【請求項３０】
実行すると請求項１７に記載の方法を実行する、コンピュータ実行可能命令を有する少なくとも１つのコンピュータ可読媒体。
【請求項３１】
コンピューティング環境において、
第１の識別子を持つ第１のサービスの状態を把握すること、
前記状態を、第２の識別子を持つ第２のサービスで再作成すること、および
前記状態へのアクセスを、前記第２の識別子によって提供すること
を備えることを特徴とする方法。
【請求項３２】
前記状態へのアクセスを、前記第２の識別子によって提供することは、少なくとも１つのサブスクライバに前記第２のサービスの存在を通知することを備えることを特徴とする請求項３１に記載の方法。
【請求項３３】
第１のサービスの状態を把握することは、前記状態およびサービス依存性データを前記第１のサービスから得ることを備えることを特徴とする請求項３１に記載の方法。
【請求項３４】
前記第１のサービスとの通信をドロップすることをさらに備えることを特徴とする請求項３３に記載の方法。
【請求項３５】
前記状態を第２のサービスで再作成することは、前記第２のサービスを作成すること、および、前記第２のサービスのデータを、前記第１のサービスから得られた前記状態およびサービス依存性データで置き換えることを備えることを特徴とする請求項３３に記載の方法。
【請求項３６】
実行すると請求項３１に記載の方法を実行する、コンピュータ実行可能命令を有する少なくとも１つのコンピュータ可読媒体。
【請求項３７】
分散コンピューティング環境において、
第２のサービスが、第１のサービスから第２のサービスに対して複製されたクライアント要求データを有することを要求する購読要求を提供するサブスクライバー・サービスと、
前記第１のサービスに関する購読データを維持するヘルパ・サービスとを含み、
前記第１のサービスは、クライアント要求データを前記第２のサービスへと複製することを、前記第１のサービスからの複製を前記第２のサービスで購読停止する要求を受け取るまで行う
ことを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、コンピュータ・システムおよびネットワークに関し、より詳細には、Ｗｅｂサービスに関する。
【背景技術】
【０００２】
コンピュータのユーザおよびアプリケーションが、管理する必要のある、あるいはアクセスする必要のあるコンピューティング・サービス、リソース、およびデータには多くのタイプが存在する。そのようなリソースおよびデータは、ローカルに維持されるサービスおよびデータ、ならびに、イントラネットおよびインターネットを含めて、企業ネットワーク上、および他のリモートにアクセス可能なサイト上で維持されるデータを含む。
【０００３】
Ｗｅｂサービスの概念は、一般に、コンピューティング・サービスのクライアントへの提供を、その性質上クロス・プラットフォームであるプロトコルおよび標準によって行うことを対象とする。一般に、Ｗｅｂサービスにより、分散アプリケーションのノードを繋ぎ合わせるための基本的なツールが、要求側クライアントが動作するプラットフォームのタイプに関わらず、提供される。数多くの異なるコンピューティング・プラットホームがあるために、Ｗｅｂサービスでは、ネットワーク情報の交換を容易にする、プラットフォーム独立な様々な機構およびプロトコルが、珍しくなくなってきており、これには、ＨＴＴＰ（HyperText Transfer Protocol）、ＸＭＬ（eXtensible Markup Language）、ＸＭＬ  Ｓｃｈｅｍａ、およびＳＯＡＰ（Simple Object Access Protocol）ＸＭＬが含まれる。ユーザおよびアプリケーションにサービスを提供する会社、組織、および他のプロバイダにおける従来のＷｅｂサービスは、現在、こうした標準に基づくものである。さらに、本発明の譲受人に譲渡された米国特許出願第１０／３２８７１４号明細書に記載されるように、Ｗｅｂサービスは、ハードウェア装置やデータベースなど、他のタイプのリソースを代表することができる。
【０００４】
現在、Ｗｅｂサービスがデータをクライアントと交換するためのプロトコルは、クライアントが、そのサービスに対応するサーバ・ポート（たとえば、ＵＲＩ）へのメッセージを送信すること、および逆にそのクライアント側でメッセージを受信することを、Ｗｅｂサービスによって提供される規約（contract）に従って合意した方法で行えるようになっている。しかし、潜在的な１つの問題は、クライアントが、そのメッセージの送信をそのサービスのＵＲＩを通して行うことが、そのサービスそれ自体は個々のエンティティから構築できる場合でも、必要であることであり、このため、そのサービスのＵＲＩを通しての通信が、潜在的なボトルネックとなっていた。
【０００５】
既存のプロトコルに関する別の問題は、所与のどのようなメッセージも、基本的にそのメッセージが存在すると判ることを除き、そのメッセージのフォーマットに精通していなければ、観察可能でない、ということである。その結果、インターミディアリー（intermediary：仲介者）（たとえば、別の信頼されたサービス）はメッセージの基本的な特徴および／または目的について確信が持てないため、インターミディアリーがメッセージ交換に付加価値（value）を提供する方法が全くない。
【０００６】
クライアントおよびＷｅｂサービスが、サービスを構築するエンティティを含めて、Ｗｅｂサービスと安全で効率的に通信することを可能にし、インターミディアリーが通信に付加価値を付け加えることを可能にする機構が必要とされている。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
簡潔には、本発明は、ＷＳＡＰ（web services application protocol）、とりわけ、ポート（たとえば、ＵＲＩ）を介するサービスの状態および振る舞いを形式的に表現し、それによりサービスにおけるエンティティが対話のため直接連絡を取り合うことができる、ＷＡＳＰを含む方法、システム、および機構を提供する。言い換えると、他のプロトコルとは異なり、ＷＳＡＰは、Ｗｅｂサービスの振る舞いを形式的な形で、たとえば、サービスの各振る舞いがそれ自体のポートを持つものとして、記述する。また、ＷＳＡＰプロトコルは、メッセージは何か、メッセージの処理は何か、それがどのように受け取り側の状態／振る舞いに影響するか、を識別する、動詞（verbs）に関する共有セマンティクスを定義することによって、インターミディアリーの使用を容易にする。さらに、メッセージおよび操作のその順序付けは、何が起きているかに対するコンテクストを提供する。
【課題を解決するための手段】
【０００８】
一般に、サービスの論理エンティティの振る舞い（または状態）が分岐すると常に、ＷＳＡＰは、サービスが各振る舞い／状態にそれ自体のポート（たとえば、ＵＲＩなどの識別）を与えることを可能にする。このようにして、クライアントは、その振る舞い／状態を制御するサービス内部の論理エンティティと直接に通信することができる。例として、ハードディスク・ドライブなどのストレージ装置にアクセスを提供するＷｅｂサービスを考える。従来の場合、クライアントは、ファイルを、ファイル・システムを介してオープンしファイル・ハンドルを受け取った後、オープンしたファイルに対してデータの読み取りおよび書き込みを行うために、ファイル・ハンドルをファイル・システムへと送ることになる。ＷＳＡＰの場合では、ファイル・ハンドルを返す代わりに、アービタ・サービスが、適当な状態（データ）に対する振る舞い（実行する操作）へのアクセスを提供する、Ｗｅｂサービスの別の論理エンティティ（別のサービス）にＵＲＩを戻す。この例では、ＷＳＡＰの場合、クライアントは、ストレージ媒体自体上の許可された場所へ書き込むためのポートと、そのストレージ媒体から読み取るための別のポートとを、再びアービタを経由せずに受け取ることになる。読み取り操作はストレージ媒体の１つの振る舞いに対応し、したがって、別の振る舞いに対応する、書き込み操作とは異なるＵＲＩを有することができることに注意されたい。理解できるように、データ・アクセスのこのモデルは、操作ごとにファイル・システム・コントローラを経由するのに比べると、特にこのファイル・システムが他の方法ではボトルネックとなる場合には、より効率的である。
【０００９】
しかも、状態および振る舞いを露出させるポートの形をした、ＷＳＡＰの明確な対話ポイントに加えて、ＷＳＡＰのメッセージでは、その対話ポイント上でなされることを記述する共有セマンティクスを使用する。このセマンティクスは、（場合によっては独自仕様の）メッセージの詳細から切り離された共有メッセージ動詞（shared message verbs）を含み、それは、そのメッセージ内容を安全な状態に置きながら、任意のインターミディアリーが、何が起きているかを知られる範囲で観察することを可能にする。
【００１０】
また、メッセージ順序付けは、観察者にコンテクストを提供するのに役立たせることができる。たとえば、各サービスは、どのＷＳＡＰ操作を、どの順序で受理するかを定義することができる。さらに、各ポートとの通信は、要求されている振る舞いを、それぞれの振る舞いがそれ自体のポートに割り当てられることができるので、通常、識別する。実際にはポートのリストとして維持することのできる、サービスポート間のこうした対話パターンは、どのようなＷＳＡＰ操作が起きたか、どの順序でそれが起きたかの直ちに観察可能なディレクトリを提供する。
【００１１】
その結果、インターミディアリーは、交換されるメッセージを処理して、通信に付加価値を付け加えることができる。たとえば、要求された操作タイプおよび／または知られているＵＲＩから、あるメッセージがあるリソースの状態を変更しないことが判るときには、キャッシュ・サービスなどのインターミディアリーは、キャッシュを無効化しそのメッセージを（別のサービスへと）渡して他のストレージ媒体にアクセスするのではなく、それ自体のキャッシュから安全にデータを読み取ってその要求を満たすことができる。この中間的（intermediate）キャッシュ・サービスは、読み取り専用サービスに対するものであると判っている場合、そのメッセージの内部の内容を知る必要はなく、プロトコルのセマンティクスから操作タイプまたはＵＲＩを知りさえすればよく、そのメッセージの内部の内容は安全に保つことができる（実際、これは、別のインターミディアリー・サービスによって暗号化されている可能性がある）ことに留意されたい。状態の変更を伴わないＷＳＡＰにおける、そのような読み取り的な操作の例としては、ＱＵＥＲＹまたはＧＥＴの共有セマンティクスを用いて参照される操作がある。そのような操作はどれも、操作の要求を満たすには読み取りアクセスで十分であることを本質的に意味する、安全であるという特徴を有し、同じ操作を無期限に（indefinitely）、状態を変更せずに繰り返せることを本質的に意味する、べき等（idempotent）であるという特徴を有する。キャッシュは、そのようなインターミディアリーの１つの例に過ぎず、インターミディアリーは、適当な他の任意のサービス、たとえば、ロード・バランサ、データ圧縮器、複製サービス、暗号化／復号機構などとすることができることに注意されたい。
【００１２】
しかも、振る舞いがそれ自体のポートを有することから、複数のＷｅｂサービスを、並行してまたは逐次的に動作させるためにどのように合成するかを定義する、ＳＯＡＰ処理モデルが提供される。このモデルは、ＳＯＡＰ対応のシリアライザ（serializer）など、いくつかのサービスの実装形態が、所与のＳＯＡＰメッセージのヘッダと本体をコンカレントにシリアライズまたは逆シリアライズすることを可能にする。これにより、ＳＯＡＰエンベロープの一部に依存するサービスは、サービスが関心を持つヘッダが利用可能であるときはいつでもアンブロックできるようになる。通信を行う双方が、同一場所に配置されている（co-located）場合、たとえば、同じ装置上にある場合、転送およびトランスポートのサービスは、ＳＯＡＰエンベロープのシリアライズを、パフォーマンスの理由から行わないことに注意されたい。
【００１３】
他の利点は、以下の詳細な説明から、これを図面と併せ解釈するとき明らかとなろう。
【発明を実施するための最良の形態】
【００１４】
例示的な動作環境
図１に、本発明を実施できる適切なコンピューティング・システム環境１００の例を示している。コンピューティング・システム環境１００は、適切なコンピューティング環境の例であるに過ぎず、本発明の使用の範囲または機能に関する制限を何ら示唆するものではない。また、コンピューティング環境１００は、例示的な動作環境１００に示すコンポーネントのどの１つまたは組み合わせに関する何らの依存性または要件を有するものと解釈すべきでもない。
【００１５】
本発明は、他の数多くの汎用または特殊目的のコンピューティング・システムの環境また構成とともに動作可能である。本発明とともに使用するのに適する可能性のあるよく知られているコンピューティングのシステム、環境、および／または構成の例としては、パーソナル・コンピュータ、サーバ・コンピュータ、ハンドヘルド装置またはラップトップ装置、タブレット装置、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータ、これらのシステムまたは装置の任意のものを含む分散コンピューティング環境などがあるが、これに限定されるものではない。
【００１６】
本発明は、コンピュータによって実行される、プログラム・モジュールなどのコンピュータ実行可能命令の一般的なコンテクストで説明することができる。一般に、プログラム・モジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含み、これらは、特定のタスクを実行し、または特定の抽象データタイプを実装する。また、本発明は、分散コンピューティング環境において実施することもでき、そこでは、タスクが、通信ネットワークを通してリンクされるリモートの処理装置によって実行される。分散コンピューティング環境では、プログラム・モジュールは、メモリ・ストレージ装置を含むローカルおよび／またはリモートのコンピュータ・ストレージ媒体に置くことができる。
【００１７】
図１を参照すると、本発明を実装するための例示的なシステムは、コンピュータ１１０の形の汎用コンピューティング装置を含む。コンピュータ１１０のコンポーネントは、処理ユニット１２０、システム・メモリ１３０、および、システム・メモリを含む様々なシステム・コンポーネントを処理ユニット１２０へと結合するシステム・バス１２１を含むが、これに限定されるものではない。システム・バス１２１は、様々なバス・アーキテクチャのいずれかを用いた、メモリ・バスまたはメモリ・コントローラ、周辺バス、およびローカル・バスを含むいくつかのタイプのバス構造のうちのどのようなものともすることができる。限定ではなく例として、そのようなアーキテクチャとしては、ＩＳＡ（Industry Standard Architecture、業界標準アーキテクチャ）バス、ＭＣＡ（Micro Channel Architecture、マイクロ・チャネル・アーキテクチャ）バス、ＥＩＳＡ（Enhanced ISA、拡張ＩＳＡ）バス、ＶＥＳＡ（Video Electronics Standards Association、ビデオ電子標準協会）ローカル・バス、および、Ｍｅｚｚａｎｉｎｅバスとしても知られるＰＣＩ（Peripheral Component Interconnect、周辺機器相互接続）バスがある。
【００１８】
コンピュータ１１０は、通常、様々なコンピュータ可読媒体を有する。コンピュータ可読媒体は、コンピュータ１１０のアクセスできるどのような利用可能な媒体とすることもでき、揮発性と不揮発性の媒体、リムーバブルと非リムーバブルの媒体をいずれも含む。限定ではなく例として、コンピュータ可読媒体は、コンピュータ・ストレージ媒体および通信媒体を含む。コンピュータ・ストレージ媒体は、コンピュータ可読命令、データ構造、プログラム・モジュールまたは他のデータなどの情報の格納のための任意の方法または技術でも実装される揮発性および不揮発性で、リムーバブルおよび非リムーバブルの媒体を含む。コンピュータ・ストレージ媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（digital versatile disk、デジタル多用途ディスク）または他の光ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたは他の磁気ストレージ装置、または所望の情報を格納するのに使用でき、コンピュータ１１０のアクセスできる他のどのような媒体も含むが、それに限定されるものではない。通信媒体は、通常、コンピュータ可読命令、データ構造、プログラム・モジュールまたは他のデータを、搬送波などの変調されたデータ信号（modulated data signal）または他の通信機構（transport mechanism）の形で具現化し、任意の情報配信媒体（information delivery media）も含む。「変調されたデータ信号」という用語は、情報をその信号の中にエンコードする形でその特徴の１つまたは複数が設定または変更される信号を意味する。限定ではなく例として、通信媒体は、有線ネットワークや直接配線接続などの有線媒体、ならびに音響、高周波、赤外線などの無線媒体および他の無線媒体を含む。また、上記のどのようなものの組み合わせも、コンピュータ可読媒体の範囲内に含められる。
【００１９】
システム・メモリ１３０は、コンピュータ・ストレージ媒体を、ＲＯＭ（read only memory、読み取り専用メモリ）１３１やＲＡＭ（random access memory、ランダム・アクセス・メモリ）１３２などの揮発性および／または不揮発性のメモリの形で含む。起動（start-up）時などにコンピュータ１１０内部の要素間で情報を転送するのに役立つ基本ルーチンを含む、ＢＩＯＳ（基本入出力システム）１３３は、通常、ＲＯＭ１３１に格納されている。ＲＡＭ１３２は、通常、処理ユニット１２０の直ちにアクセス可能なおよび／または目下操作中のデータおよび／またはプログラム・モジュールを含む。限定ではなく例として、図１に、オペレーティング・システム１３４、アプリケーション・プログラム１３５、他のプログラム・モジュール１３６、およびプログラム・データ１３７を示している。
【００２０】
また、コンピュータ１１０は、他のリムーバブル／非リムーバブルで揮発性／不揮発性のコンピュータ・ストレージ媒体を含むこともできる。単なる例として、図１に、非リムーバブルで不揮発性の磁気媒体からの読み取りまたはそれへの書き込みを行うハードディスク・ドライブ１４１、リムーバブルで不揮発性の磁気ディスク１５２からの読み取りまたはそれへの書き込みを行う磁気ディスク・ドライブ１５１、および、ＣＤ−ＲＯＭや他の光学メディアなどのリムーバブルで不揮発性の光ディスク１５６からの読み取りまたはそれへの書き込みを行う光ディスク・ドライブ１５５を示している。例示的な動作環境で使用できる他のリムーバブル／非リムーバブルで揮発性／不揮発性のコンピュータ・ストレージ媒体としては、磁気テープカセット、フラッシュ・メモリ・カード、ＤＶＤ（デジタル多用途ディスク）、デジタル・ビデオ・テープ、ソリッド・ステートＲＡＭ、ソリッド・ステートＲＯＭなどがあるが、これに限定されるものではない。ハードディスク・ドライブ１４１は、通常、システム・バス１２１にインターフェース１４０などの非リムーバブル・メモリ・インターフェースを通して接続され、磁気ディスク・ドライブ１５１および光ディスク・ドライブ１５５は、通常、システム・バス１２１にインターフェース１５０などのリムーバブル・メモリ・インターフェースを通して接続される。
【００２１】
上で論じ、図１に示したドライブおよびその関連するコンピュータ・ストレージ媒体により、コンピュータ１１０用のコンピュータ可読命令、データ構造、プログラム・モジュールおよび他のデータのストレージが提供される。図１で、たとえば、ハードディスク・ドライブ１４１は、オペレーティング・システム１４４、アプリケーション・プログラム１４５、他のプログラム・モジュール１４６、およびプログラム・データ１４７を格納するものとして示している。こうした構成要素は、オペレーティング・システム１３４、アプリケーション・プログラム１３５、他のプログラム・モジュール１３６、およびプログラム・データ１３７と同じでも異なっていてもよいことに注意されたい。オペレーティング・システム１４４、アプリケーション・プログラム１４５、他のプログラム・モジュール１４６、およびプログラム・データ１４７には、本明細書では異なる符号を与えて、最小限、これらが異なるコピーであることを示している。ユーザは、コマンドおよび情報のコンピュータ１１０への入力を、タブレットもしくは電子デジタイザ１６４、マイクロフォン１６３、キーボード１６２、普通マウス、トラックボール、またはタッチパッドと呼ばれるポインティング装置１６１などの入力装置によって行うことができる。図１に図示していない他の入力装置としては、ジョイスティック、ゲームパッド、衛星放送受信アンテナ（satellite dish）、スキャナなどがあり得る。こうしたおよび他の入力装置の処理ユニット１２０への接続は、しばしば、システム・バスに結合されるユーザ入力インターフェース１６０を通して行われるが、パラレル・ポート、ゲーム・ポート、またはＵＳＢ（universal serial bus、ユニバーサル・シリアル・バス）など、他のインターフェースおよびバス構造によって行うことも可能である。また、モニタ１９１または他のタイプのディスプレイ装置のシステム・バス１２１への接続も、ビデオ・インターフェース１９０などのインターフェースを介して行うことができる。また、モニタ１９１は、タッチ・スクリーン・パネルなどと一体化させることができる。モニタおよび／またはタッチ・スクリーン・パネルは、タブレット型のパーソナル・コンピュータの場合のように、コンピューティング装置１１０が組み込まれているハウジングに物理的に結合させることができる。さらに、コンピューティング装置１１０などのコンピュータは、スピーカ１９５やプリンタ１９６など他の周辺出力装置を含むことができ、その接続は出力周辺インターフェース１９４などを通して行うことができる。
【００２２】
コンピュータ１１０は、リモート・コンピュータ１８０など、１つまたは複数のリモート・コンピュータへの論理接続を用いてネットワーク化環境で操作することができる。リモート・コンピュータ１８０は、パーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置（peer device）または他の一般的なネットワーク・ノードとすることができ、通常、コンピュータ１１０に関して上で説明した要素の多くまたはすべてを含むが、図１にはメモリ・ストレージ装置１８１だけを示していた。図１に示す論理接続は、ＬＡＮ（local area network、構内通信網）１７１およびＷＡＮ（wide area network、広域通信網）１７３を含むが、また他のネットワークを含んでもよい。そのようなネットワーキング環境は、オフィス、全社規模のコンピュータ・ネットワーク、イントラネット、およびインターネットでは普通のものである。たとえば、本発明では、コンピュータ・システム１１０は、データを移行（migrate）中の移行元（source）マシンを含むことができ、リモート・コンピュータ１８０は、移行先（destination）マシンを含むことができる。しかし、移行元および移行先のマシンは、ネットワークまたは他のどのような手段によっても接続されている必要はないが、その代わり、データの移行を、移行元のプラットフォームによる書き込み、移行先のプラットフォームまたはプラットフォーム群による読み取りに堪えるどのような媒体によっても行うことができることに注意されたい。
【００２３】
コンピュータ１１０は、ＬＡＮネットワーキング環境で使用するときには、ＬＡＮ１７１にネットワーク・インターフェースまたはアダプタ１７０を通して接続する。コンピュータ１１０は、ＷＡＮネットワーキング環境で使用するときには、通常、モデム１７２、または、インターネットなどのＷＡＮ１７３を介して通信を確立するための他の手段を含む。モデム１７２は、内蔵でも外付けでもよいが、システム・バス１２１にユーザ入力インターフェース１６０、または他の適当な機構を介して接続する。ネットワーク化環境では、コンピュータ１１０に関して示したプログラム・モジュールまたはその部分は、リモートのメモリ・ストレージ装置に格納することができる。限定ではなく例として、図１には、リモートのアプリケーション・プログラム１８５を、メモリ装置１８１上にある（ｒｅｓｉｄｅ）ものとして示している。ここに示すネットワーク接続は例示的であり、コンピュータ間に通信リンクを確立する他の手段を使用してもよいことが理解されよう。
【００２４】
Ｗｅｂサービス・アプリケーション・プロトコルおよびＳＯＡＰ処理モデル  
分散プログラミング・モデルでは、基本的なプログラミングのプリミティブは軽量ポートであり、これは、状態を保存し通信を行うのに使用できる順序付けのないメッセージの集合（collection）を含む。項目は参照によって保存され、ポートにより、（少なくとも）２つのプリミティブな操作、すなわちＰｏｓｔ（）およびＧｅｔ（）がサポートされる。クラスのインスタンスなどの項目をポストする際には、参照をバッファに入れて直ちに戻る。供給されたキーに基づいて項目を取り出す際には、そのキーを伴う項目がリモートサービスによってポストされていない場合、ブロックすることができる。ポートは、サービスから直接に使用できるが、通常は、特定のメッセージ・タイプが集合の中の各ポートに関連付けられるポート集合のコンテクストの内部で使用される。ポート集合の作成は、サポートされているメッセージ・タイプの固定されたまたは動的な組によって、必要な柔軟性に依存して行われるが、プログラマの視点からは、ポート集合は、単に型付きポートでしかない。
【００２５】
本発明の説明に戻ると、サービス・コードにより、厳密にポート通信を用いて、クリティカル・セクションおよび複雑なＩ／Ｏプロトコルが実装され、非常にコンカレントな処理モデルが作られる。このために、本発明は、部分的には、Ｗｅｂサービスと通信するためのプロトコル（Ｗｅｂサービス・アプリケーション・プロトコル、またはＷＳＡＰ）を対象としており、そこでは、クライアントの消費者は、サーバ・プロバイダに、クライアントのために何らかのサービスを行い、クライアントに適切な応答を提供するように、要求する。しかし、理解されることであるが、一般的なＷｅｂサービス・モデルは、ソフトウェアをクライアントのために動作させるサーバに限定されず、クライアントがアクセスしたいと思うどのようなリソースにも適用され、たとえば、ＷＳＡＰのサポートする統一サービス・モデル（uniform service model）を、ファイル、装置、サービス、および人物をモデル化するために使用することができる。たとえば、ハードウェアは、ある程度コンポーネント化することができ、多くの面で事実上、ソフトウェア指向のＷｅｂサービスとの区別は、ユーザが１組のハードウェア・コンポーネントを選択しそれらを相互接続してコンピューティング・タスクを実行する点で、事実上見分けがつかないことになる。各装置が通信プロトコルに従う限り（適切な量の帯域が利用可能である限り）、事実上どのような認可された装置も、別の装置とそのリソースを使用するために通信できることになる。
【００２６】
図２に、ＳＯＡＰ（simple object access protocol）エンベロープ内部で通信されるＷＳＡＰメッセージを介して、Ｗｅｂサービス２０４と通信するＷｅｂクライアント・コード２０２（たとえば、これは図１のコンピュータ・システム１１０とすることができる）を含む、アーキテクチャ２００を示している。サービスの識別は、名前付きポート（named port）（たとえば、ＵＲＩ）によって記述され、サービスの状態は、通常、ＸＭＬスキーマによって記述される。サービスは、ローカル（クライアント・コードと同じマシンの内部にある）とすることもでき、または、サーバまたはハードウェア装置など、リモートのリソースとすることもできることに注意されたい。一般に、また下で説明するように、ＷＳＡＰでは、セマンティクスの点で（semantically）、あるＷｅｂサービスが何をするのかが定義されるのに対し、ＳＯＡＰ処理モデルでは、複数のＷｅｂサービスをどのように合成して、並行してまたは逐次的に動作させるかが定義され、これを本発明に従って使用すると、コンピューティング装置への内部的なサービスを、外部のＷｅｂサービスと実質的に同じ形で、たとえば、メモリ内のＸＭＬでないシリアライズされたデータによって、組み立てることができる。
【００２７】
他のＷｅｂサービスと同様に、ＷＳＡＰ対応可能なサービスは、Ｗｅｂサービス規約の要求（web service contract request）２０６および規約の提供（contract offering）２０８によって図２に示すように、規約を、規約の要求に応答して提供すること（offering）により操作する。ＷＳＡＰでは、規約を得るために、ポートのクライアントへの露出が、下で説明するように、ＬＯＯＫＵＰ操作に対応して行われることに注意されたい。これも下で説明するが、バインディング・リスト情報が、応答２０８とともに、たとえば、下で説明するように、その規約を「インスタンス化」するキー／値の対の配列に対応する識別子／ポートとして提供される。サービスは、ＬＯＯＫＵＰ操作以外にはＷＳＡＰ操作を実装する必要はないが、対話のセマンティクスがＷＳＡＰ操作と互換性があるときには、ＷＳＡＰサービスは、ＷＳＡＰ操作を実装すべきである。サービスの提供において、サービスの作成者（author）は、どのような対話またはサービス機能のマッピングも、ＷＳＡＰの動詞および表現を用いて行うことができる。ＷＳＡＰの動詞をある特定のサービスのためにすべて使用しなくてもよく、想定状況次第で、逆にサブセットを使用することもできる。
【００２８】
本発明の一態様によれば、ＷＳＡＰは、分散コンピューティング環境で有用なＳＯＡＰベースのプロトコルであり、それは、識別、状態、およびサービスの振る舞いに従って使用できる１組の操作によって、Ｗｅｂサービスを定義する。これは、サービスおよびその状態が、一貫性があり観察可能な形で、効率的に操作されることを可能にする。ＷＳＡＰでは、振る舞い型（behavioral）Ｗｅｂサービスは、識別および振る舞いを有するプロセスの抽象的な概念である。この概念が抽象的であるのは、異なる多くのアプリケーション・モデルおよび名前空間へと適用可能であるという意味においてである。ＷＳＡＰにより、概してインターネットに合わせて調整するように設計されている、１つのこのようなアプリケーション・モデルが定義されるが、他の多くのアプリケーション・モデルに合わせて調整することも可能である。
【００２９】
ＷＳＡＰでの識別（identity）の概念は、従来のＷｅｂモデルで、ＵＲＩで識別されるリソースのそれに似ている。すなわち、識別を有する何か（anything）である。識別の目的は、あるサービスが、同じ名前空間の内部に存在する可能性のある他のサービスから、それ自体を区別できるようにすることである。本明細書で説明するＷＳＡＰ  Ｗｅｂサービスの範囲は、インターネットとすることができ、これは、ＤＮＳまたはＩＰが、ＵＲＩの「ａｕｔｈｏｒｉｔｙ」構成要素（authority component）に対する命名機関（naming authority）であることを意味する、しかし、ある装置または限られたネットワークの内部など、より限定された範囲では、別の命名機関が実現可能である。
【００３０】
ＷＳＡＰ  Ｗｅｂサービスはそれぞれ、図３に例示しているＵＲＩなどの一意の識別を有する。（Ｗｅｂ上などの）他のどのようなＵＲＩと同様に、単にＵＲＩだけに基づいては意味的知識は得られず、同様に、２つのＷＳＡＰ  Ｗｅｂサービスの間の関係（たとえば、包含関係）は、そのＵＲＩからは推論できない。ＷＳＡＰでは、ＵＲＩは、相対的または絶対的とすることができる。ＵＲＩが相対的である場合、その基底は、ＸＭＬ  Ｂａｓｅによって決定される。ＷＳＡＰでは、ＵＲＩの長さに何ら制限を課しておらず、したがって、ＷＳＡＰの受け取り側はどれも、ＷＳＡＰが公開するどのＵＲＩの長さも取り扱える必要がある。ＷＳＡＰの実装では、長さが少なくとも２キロ・バイトのＵＲＩを扱えるべきである。
【００３１】
サービス間のやり取り（これは１つのプロトコルと考えることができる）は、あるサービスの振る舞いであり、振る舞いタイプを用いたサービスの記述である規約を備える、振る舞いのタイプとして、形式的に記述することができる。サービスの実装は、そのサービスが実装していると主張する規約にサービスが適合する限り、どのような数のやり方でも可能である。ＷＳＡＰでは、規約は、本質的に他のあらゆるものと同様に、サービスであり、このことから、規約は、ポート（たとえば、ＵＲＩ）によって識別され、他の任意のサービスのように、その規約に従って操作することができる。
【００３２】
振る舞いの概念は、サービスがその環境と行うやり取りが、その生成し受理するメッセージのタイプのシーケンスの点で、どのように行われるかに基づいている。振る舞いは、同じ名前空間の内部に存在する可能性のある他のサービスの振る舞いから、その特定の振る舞いをサービスが区別することを可能にし、振る舞いは、そのサービスが定義されるある特定の名前空間に関して定義される可能な振る舞いの組に相対的なものである。言い換えると、振る舞いは、そのサービスによって公開される分散状態マシンである。したがって、そうしたリソースまたはサービスの他のサービスとのやり取りを含めることにより、振る舞いは、現在のＷｅｂモデルを、リソースの識別のために拡張する。２つのサービスは、通信するためには互換性のある振る舞いを有している必要がある。すなわち、それらは噛み合わなければならない。あるサービスの振る舞いが別のサービスには知られていない場合、このことはその２つのサービスがやり取りできないことを意味し、このことは、対話するための機構がそのＵＲＩを保持する側に知られていないために、ＵＲＩを区別することが可能でない場合の、リソースからなるＷｅｂモデルに似ている。
【００３３】
ＷＳＡＰサービスから見ると、どのようなデータも、それがメタデータでもデータでも、サービスとして表現することができる。すなわち、（ファイルなどの）データの同じ集合を読み取りまたは実行が可能な単一エンティティとして露出させるのではなく、ファイルは、個別の規約を持つ個々のサービスとして公開される。このことは、図３に示しているが、そこでは、識別および振る舞いにおける一意性の概念を、異なる振る舞いを有し、それぞれがそれ自体のＵＲＩを有する、１組のサービスとして公開される、従来型のファイルのデータ３０２によって示している。また、図３に示すように、あるファイルの振る舞いに対応するサービスは、読み取りサービス３０４、実行サービス３０６、メタデータ操作サービス３０８、および、このファイルの他のサービスに対する関係のディレクトリを読み取るためのサービス３１０、を含む。また、本質的に、あるファイルに関する他のどのような振る舞い（たとえば、書き込み）も、サービスとなることが可能であり、図３にはそれを暗黙に示してある。
【００３４】
ファイルを１組のサービスとして、それぞれがそれ自体のＵＲＩを有するものとして公開させることは、ファイルが、ファイル・システムを経由して、オープンした後に返されたそのハンドルによってアクセスされる、従来のモデルにまさる顕著な利益を提供する。たとえば、本発明の場合、メディア・サービスへのＵＲＩが知られると、そのファイルへの操作は、適切なサービスを介して行われ、そのファイルデータに何かを行うのにファイル・システムを経由し続ける必要性が省かれる。このことは、分散コンピューティング環境で、たとえば、ファイル・システムが、ある遠いサーバ上に存在する可能性があり、および／または、ファイル・システムが、本発明によって回避できるボトルネックとなっている可能性がある状況下で、特に有益である。
【００３５】
ＷＳＡＰの第１の目的は、ＷＳＡＰ  Ｗｅｂサービスは何であり、どのように識別されるか、ＷＳＡＰ  Ｗｅｂサービスの振る舞いは何であり、どのように他のＷＳＡＰ  Ｗｅｂサービスと通信を行うか、および、ＷＳＡＰ  Ｗｅｂサービスは、どのように他のＷＳＡＰサービスと、そして他のリソース一般と関係するか、を解決するアプリケーション・レベルのプロトコルの枠組みを提供することである。ＷＳＡＰによって、１組のメッセージの操作および交換パターンによって、提供されるこの枠組みは、識別および振る舞いの点で、振る舞い型Ｗｅｂサービスの概念を意図的に制約する、しかし、構造または複雑さの点で、制約することはない。ＷＳＡＰ  Ｗｅｂサービスは、様々なアプリケーション・コンテクストで使用することができる。たとえば、図３の例で示したサービスとしてのファイルの概念のほかに、たとえば、ある装置の分岐するそれぞれの振る舞いに対して、または簡単なチャット・サービスのそれぞれの振る舞いに対して、複数のポートの割り当てることなど、識別および振る舞いにおける一意性を有する単純な他の例が、実現可能である。簡単化のために、本明細書における例では、比較的低レベルのエンティティおよびサービスを使用していることに注意されたい。しかし、このモデルが、ビジネスのエンティティおよびそれらの関係など、より複雑なエンティティにも同等に良く当てはまることを理解されたい。
【００３６】
サービスの識別およびサービスの振る舞いのほかに、振る舞い型Ｗｅｂサービスには、時に「サービス値（service value）」と呼ばれる、サービスの状態の概念がある。より詳細には、ＷＳＡＰメッセージ操作は、サービスの部分または下位部分（ただし、ＷＳＡＰサービス自体ではない）を表すシリアライズされた状態の交換を含むことができる。サービスのシリアライズされた状態を、サービスタイプを表す振る舞いと対照させて、サービス値と呼ぶ。サービスは、そのサービスの振る舞いの許すどのような値も持つことができ、その値は時間とともに変化してもよい。ＷＳＡＰが操作を行うのはサービスであり、使用するのは、サービスのシリアライズされた状態を表すサービス表現であることに注意されたい。１つのサービスは、０個以上の可能な表現を持つことができる。すなわち、サービスは表現をまったく持たないことも可能である。ＷＳＡＰ操作が含むことができるのは、サービス表現の交換であり、サービスそのものの交換ではない。サービス表現は、時間とともに変化してもよく、その表現を生成させた条件の関数として変わることができる。アプリケーションがやり取りを行うのは表現の交換を通してであり、サービスの交換を通してではない。
【００３７】
図４に、サービス値４０３を示しているが、そこでは、このサービス値は、データベースのデータ、英数字データ、家の画像、花の画像など、どのようなデータ（たとえば、ファイルの状態データ）とすることもできる。サービスから見ると、同じサービス値を、異なるやり取りのやり方を伴う異なるサービスとして表現することができる。上で説明したように、異なる振る舞いが別々のサービスとしてモデル化されるため、アクセス権や通信の特性（properties）など、振る舞いに影響を及ぼす特性は、異なるサービスを生じさせる可能性がある。
【００３８】
図４では、同じサービス値に対する異なるアクセス・モデルが、読み取り専用アクセス、読み取り書き込みアクセス、暗号化アクセスおよびトランザクションによるアクセス（transacted access）をそれぞれ含む、異なるサービス４１１〜４１４としてモデル化してある。従属するサービス間の同期は、下で説明するＷＳＡＰ複製モデルを用いて行えることに注意されたい。
【００３９】
図３および４を考慮すると、ファイル・システムは、データ、すなわち（ファイル名、長さ、所有者、およびアクセス許可などの）メタデータおよび（ファイル内容などの）データを含むファイル、の複数の「ビュー」を含むエンティティの１つの例であることが判る。さらに、あるファイルのビューは、そのファイルをオープンするエンティティのアクセス許可に依存するものであり、実際、読み取り専用ファイルの振る舞いは、読み取り書き込みファイルの振る舞いとは異なっている。したがって、ファイル・システムは、１組の振る舞い型サービスとして、容易にモデル化される。
【００４０】
サービスは、互換性のある規約によって接続が済むと、互いとのやり取りを、特定のタイプのメッセージのシーケンスの生成および受理によって行うことができる。このために、ＷＳＡＰは、１組のメッセージ操作を関連するセマンティクスによって定義する。メッセージ操作のそれぞれは、通信を行う２者間で交換される１組の特定のタイプのメッセージを備える。
【００４１】
本発明の別の態様によれば、ＷＳＡＰは、振る舞い型Ｗｅｂサービスの定義の上に構築され、振る舞い型Ｗｅｂサービスの定義では、識別および振る舞いを決定するための枠組みが、共有される１組のメッセージ操作およびメッセージ交換パターンによって定義される。ＷＳＡＰメッセージ操作の定義は、クライアント・コード２０２（図２）、すなわち、通常はアプリケーション・プログラムによって行われ、そこでは、ある操作は、特定のタイプのメッセージの交換を、ＷＳＡＰの定義するメッセージ交換パターンの１つを用いて行うこと、を含み、これは、以下で、図５および６を参照して説明する。これも以下で説明することであるが、ポートにより、通信を通して同期化が提供され、ＳＯＡＰにより、サービス間で交換されるメッセージに関する処理モデルが提供される。
【００４２】
ＷＳＡＰの一目的は、Ｗｅｂサービスおよびそのやり取りを定義するための共通のアプリケーション層の基盤（foundation）を提供することである。ＳＯＡＰは、複数のアプリケーション・モデルをサポートするように設計されており、アプリケーションは、ＳＯＡＰ拡張性モデルの範囲全体を自由に使用できることに注意されたい。しかし、ＷＳＡＰの１つの意図は、非常に様々な非集中化されたアプリケーションにとって一般に有用なアプリケーション・モデルを定義することである。ＷＳＡＰの別のゴールは、高度の相互運用性を可能にし、システム全体の有用性の潜在的な向上をもたらすことである。
【００４３】
こうした目的および他の目的を達成するために、ＷＳＡＰでは、Ｗｅｂサービス・アプリケーション・モデルを、１組の共通のメッセージ操作に基づいて定義している。Ｗｅｂサービスに適用される共通の語彙という概念が、これまで知られていなかったことに注意されたい。ＷＳＡＰでは、操作の構造およびセマンティクス全体を、ＬＯＯＫＵＰ、ＱＵＥＲＹ、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ、ＧＥＴ、ＤＲＯＰなどのなじみ深い名前で定義しており、このため、個々のサービスは、これらの操作からの継承を、動的束縛（late binding）に対するサポートを保存しながら行うことができる。一般に、本明細書ではＷＳＡＰ操作に対して、多くの場合に大文字を使用して、ＷＳＡＰ操作を従来の動詞から差異化するが、操作に大文字を使用する必要性はなく、さらに、他のまたは異なる名前のＷＳＡＰ操作の組も実現可能であり、サービスでは、それ自体の追加の操作を望む通りに定義することができる。
【００４４】
操作により、アプリケーションは他のサービスと通信できるようになる。たとえば、ＬＯＯＫＵＰでは、あるサービスについての情報が、規約の形で提供されるのに対し、ＧＥＴおよびＱＵＥＲＹを使用すると、そのサービスの現在の状態を取り出すことができる。ＣＲＥＡＴＥおよびＤＲＯＰ操作では、サービス、その他を、下で説明するように、作成および削除することができる。操作のほとんどは、メッセージの具体的な形態を越えて多態的（polymorphic）であり、これにより、個々のサービスはメッセージの構造をサービスの形態に合わせることができるようになっている。たとえば、ディレクトリ・サービスの定義するＩＮＳＥＲＴ要求メッセージのＳＯＡＰ本体要素は、ローダサービスの定義するＩＮＳＥＲＴ要求メッセージとは異なるが、そのどちらも同じ基本的なセマンティクスに従っている。
【００４５】
ＷＳＡＰメッセージ操作は、合成してより複雑な規約にすることができるミニ規約（mini-contracts）と考えることができる。このことにより、アプリケーションは、メッセージ操作を組み合わせてその特定の必要性に適するシーケンスにし、それにより、より複雑なサービスを構築できるようになる。言い換えると、ＷＳＡＰ操作そのものの合成および／または順序付けを行って、あるサービスのためのより複雑な振る舞いを定義することができる。たとえば、あるサービスを、ＱＵＥＲＹ操作と、それに続くＵＰＤＡＴＥ操作を受理するものとして定義することができる。（ＱＵＥＲＹおよびＵＰＤＡＴＥ操作は以下で説明する。）したがって、ＵＲＩは、ＷＳＡＰ操作のシーケンスを表現することができ、このことは、ＵＲＩそのものが、単純な振る舞いまたは複雑な振る舞いを表すことができることを意味するものであることに注意されたい。ＷＳＡＰによって要求されるわけではないが、規約を使用すると、非常に有利に所望の構成可能性（composability）を達成することができる。
【００４６】
ネットワークの周辺における潜在的な価値が増すことのほかに、可能なところでは共有セマンティクスを使用することにより、システム全体の高度の透過性が可能になる。その結果、キャッシングおよび他の中間的処理サービスなどのパフォーマンス最適化を、システムのすみずみまで展開して、インターネット規模のシステムに必要なスケーラビリティを達成することができる。
【００４７】
より詳細には、ＷＳＡＰ操作は、キャッシュ・サービス、ロード・バランサ・サービス、データ圧縮サービス、複製サービス、暗号化／復号サービスなどのインターミディアリーがメッセージを処理できるようにする特性（properties）を有する。ＷＳＡＰ操作を修飾する（qualify）そのような２つの特性として、操作が「安全（safe）」であるかどうか、および／または「べき等（idempotent.）」かどうか、がある。操作がべき等であるのは、成功した実行の結果が、操作の実行の回数から独立であるときである。操作が安全であるのは、操作のセマンティクスが、その操作の適用されるリソースへの読み取り専用アクセスに制限される場合である。定義により、安全な操作はべき等であるが、その逆は真ではなく、したがって、読み取り専用操作は、安全でも、べき等でもあることに注意されたい。さらに、こうした修飾子（qualifiers）が適用されるのは、操作に対してであり、その操作の特定の実装に対してではないことに注意されたい。
【００４８】
こうした修飾子により、操作を開始する側とターゲットとなるサービスの間のサービスレベルの可能性（expectation）が提供される。安全またはべき等な操作の特定の実装には、操作の実行に関連する２次的な（second-order）副作用がある可能性があるということに注意されたい。そのような副作用の典型例としては、ロギング、動的なコンテンツの場合における読み取り専用データの生成に関連する処理、状態管理の更新などがある。そのような２次的な副作用は、安全なおよびべき等な操作の概念に影響を与えない。
【００４９】
結果として、インターミディアリー・サービスは、交換されたメッセージを処理して、通信に付加価値を付け加えることができる。例として、キャッシュなどのインターミディアリーを考える。この例では、クライアントは、データへのアクセスを提供するサービスに接続し、その応答として、クライアントはキャッシュに対するＵＲＩを受け取る。キャッシュは、ＧＥＴおよび／またはＱＵＥＲＹ要求に応答してデータを返すために、データの内容、すなわち、たとえば、内部でどのようにフォーマットされているか、暗号化されているかどうか、などについては何も知る必要がない、しかし、要求された操作タイプから、キャッシュの背後に存在するリソースの状態が、そのメッセージの処理によって変更されることはないことを知っている。結果として、キャッシュ・サービスは、それ自体のキャッシュストレージから安全にデータを読み取って、どのＧＥＴおよび／またはＱＵＥＲＹ要求も満たすことができる。状態を変更することになる要求、すなわち、たとえば、ＷＳＡＰのＩＮＳＥＲＴ、ＤＥＬＥＴＥ、またはＵＰＤＡＴＥ操作を受け取った場合には、キャッシュ・サービスは、メッセージを適切なＵＲＩへと渡すことができ、または代替方法として、クライアントが異なるＵＲＩを使用して状態を変更することができ、この場合には、キャッシュ・サービスは、その何らかの部分が無効であるとの通知を受けることになる。
【００５０】
本発明の別の一態様によれば、ＷＳＡＰ操作は、２つのメッセージ交換パターン、すなわちｏｎｅ−ｗａｙ（片方向；処理結果を返さない）と、最終応答の到着前の中間的応答（intermediate responses）に対するサポートを伴うｒｅｑｕｅｓｔ−ｒｅｓｐｏｎｓｅ（要求／応答；処理結果を返す）に基づいている。ＷＳＡＰメッセージは、潜在的に、マルチキャスト対応インフラストラクチャ（multicast-enabled infrastructure）を介して運ばれることが可能であるけれども、ＷＳＡＰメッセージ操作のセマンティクスは、ポイントツーポイント通信のメッセージである。ＷＳＡＰでは、Ｗｅｂサービスの振る舞いが形式化された形で記述され、このことは、ＷＳＡＰと他のプロトコルの大きな違いである。
【００５１】
図５および６に、片方向、および要求／応答のメッセージ交換パターンを用いたＷＳＡＰ操作を、それぞれ示している。どちらの状況でも、送り手と受け手のどちらもが、（たとえば、ＵＲＬによる）名前付きのＷＳＡＰサービスである。このことは、その要求のターゲット・リソースだけが名前付きである、ＨＴＴＰなどのクライアント／サーバ・プロトコルとは異なることに注意されたい。
【００５２】
片方向のメッセージ交換パターンを図５に示しているが、これは、最初の送り手から最終的な受け取り手へと、０個以上のインターミディアリーを通して送られるメッセージを含んでいる。片方向メッセージから、（下で説明する）ＳＯＡＰ  ｆａｕｌｔの生成が起きた場合、ＳＯＡＰ  Ｆａｕｌｔメッセージは最初の送り手に返されないことに注意されたい。
【００５３】
要求／応答メッセージ交換パターンを図６に示しているが、これは、最初の送り手から最終的な受け取り手へと、０個以上のインターミディアリーを通して送られる要求メッセージと、それに続く、最終的な受け取り手からその要求の最初の送り手からへと、やはり０個以上のインターミディアリーを通して送られる暫定的な応答を含んでいる。このメッセージ交換パターンに課される時間的な制約は存在せず、このメッセージ交換パターンをサポートする操作は、同期および非同期の通信モデルで使用できることに注意されたい。さらに、要求メッセージから下で説明するＳＯＡＰ  ｆａｕｌｔの生成が起きた場合は、ＳＯＡＰ  Ｆａｕｌｔメッセージが最初の送り手へと返されるが、応答メッセージからＳＯＡＰ  ｆａｕｌｔの生成が起きた場合は、ＳＯＡＰ  ｆａｕｌｔは生成されるが、ＳＯＡＰ  Ｆａｕｌｔメッセージは応答側（responder）へは返されないことに注意されたい。
【００５４】
本発明の一態様によれば、ＷＳＡＰ操作は、ＳＯＡＰ  Ｂｏｄｙのコンテンツとして運ばれる１組のメッセージ・タイプ、これらのメッセージ・タイプの振る舞い、および、操作を呼び出すことが意味するセマンティクスを含む。ＳＯＡＰメッセージに関しては、ＷＳＡＰメッセージ・タイプを、通常ＳＯＡＰヘッダ・ブロックとして表現される、数の無制限（ｏｐｅｎ−ｅｎｄｅｄ）なＳＯＡＰ機能（ｆｅａｔｕｒｅｓ）を使用して組み立てることができる。そのような機能の例としては、セキュリティ、ルーティング、信頼性があるが、これに限定されるものではない。
【００５５】
次のＣ＃言語のクラス（Ｃ＃  ｃｌａｓｓ）（ＩＲＰデータ構造など一部の場合に使用される）は、ある実装形態におけるＳＯＡＰエンベロープを表している。
【００５６】
【表１】
2005339555.tif 000003
【００５７】
ＳＯＡＰエンベロープの取り扱いは、メッセージ生成、メッセージ交換、およびメッセージ解析を含んでいる。ｐｏｒｔＨｅａｄｅｒポートは、ＳＯＡＰ処理グループ内のインターミディアリーが、シリアライズ可能なまたは厳密に内的なヘッダ構造を交換するのに使用する。第２のポート、ｐｏｒｔＢｏｄｙは、メッセージの本体（body）を格納する。このコンテナ内部でポートを使用することにより、ＳＯＡＰエンベロープのコンカレントでスレッド・セーフな操作（concurrent and thread-safe manipulation）が可能になる。厳密なパイプライン・モデルまたはスタック・ベースのモデルは（ＳＯＡＰヘッダ・ブロックおよび／またはＳＯＡＰ本体の間のやり取りを取り扱う際に問題となるが）、必要とされない。
【００５８】
ＳＯＡＰ処理モデルのＷＳＡＰベースの実装の一利点は、これが、ＳＯＡＰメッセージのコンカレントな処理のためのＳＯＡＰの中にある本来のサポートと調和することである。この実装では、振る舞いに対応しているポートを介するため、いくつかのサービスによるメッセージのコンカレントな処理が容易になる。たとえば、ＳＯＡＰ対応のシリアライザは、所与のＳＯＡＰメッセージのヘッダと本体のシリアライズまたは非シリアライズを、他のサービス操作とコンカレントに、行うことができる。これにより、そのＳＯＡＰエンベロープの部分に依存するサービスは、そのサービスが関心を持つヘッダが利用可能になると、いつでもアンブロックできるようになる。ＳＯＡＰの非シリアライゼーションそのものは、このコンカレントな構文解析の設計に起因して、アトミックではない。パフォーマンスの向上のため、転送およびトランスポートのサービスは、通信を行う双方が共存している（co-locate）場合、ＳＯＡＰエンベロープを、決してシリアライズすることはない。
【００５９】
ＳＯＡＰを使用している以上、要求／応答メッセージ交換パターンを使用する任意のＷＳＡＰ操作実行中における障害（failure）は、ＳＯＡＰ  ｆａｕｌｔ構造を用いて報告され、ＷＳＡＰアプリケーションの生成するＳＯＡＰ  ｆａｕｌｔは、ＳＯＡＰ  Ａｃｔｉｏｎ要素情報項目を含んでいる必要があり、この項目の値は、S:Envelope/S:Body/S:Fault/S:Code/S:Valueの値を持つＳＯＡＰ  ｆａｕｌｔを反映する。一般に、ｆａｕｌｔごとに個々のアクションが存在する。
【００６０】
本発明の一態様によれば、ＷＳＡＰメッセージ・タイプの識別が可能である。ＳＯＡＰ  Ｂｏｄｙの特定のタイプに関心のない、またはＳＯＡＰ  Ｂｏｄｙの内容を見ることができない（たとえば、暗号化されている場合）インターミディアリーまたは他のＳＯＡＰノードは、たとえば、ＷＳアドレッシングの運ぶＳＯＡＰ  Ａｃｔｉｏｎ要素情報項目を使用することができる。ＷＳＡＰ操作では、一意のＡｃｔｉｏｎ値を定義している。
【００６１】
特定のタイプのＳＯＡＰ  Ｂｏｄｙに実際に関心のあるＳＯＡＰノードは、ＳＯＡＰ  Ｂｏｄｙの最も外側の要素情報項目のＸＭＬ拡張名（XML Expanded Name）を使用することができる。ＷＳＡＰでは、アプリケーションの定義するメッセージ・タイプで置き換えることの必要な１組の抽象的な要素情報項目を定義している。
【００６２】
ＳＯＡＰ  ｆａｕｌｔに関しては、モデルは似ているが、ＳＯＡＰ  ｆａｕｌｔの詳細に関心のないインターミディアリーまたは他のＳＯＡＰノードがＳＯＡＰ  ｆａｕｌｔコードを検査できる点で、ＳＯＡＰ  ｆａｕｌｔコードの使用は、検査可能性について追加されたレベルを提供する。
【００６３】
上で説明した操作のほかに、状態の露出により、キャッシュや複製などのそれほど古くない（less traditional）操作、ならびに、すべてのサービスに一貫して適用できる、一様なパブリッシュ／サブスクライブ型モデル（publication/subscription (pub/sub) model）が可能になる。これは、サービスの検査、監査、および管理を分散オペレーティング・システム・ノードの内部および複数のノードを横断して行う総称的なアプリケーションの構築に使用されてきている。
【００６４】
ＷＳＡＰでは、セッションもサービスとしてモデル化され、ここでは、セッション管理とは、値の状態（value states）を呼び出し側に従って差異化することを指す。セッション管理の１つの例としては、しばしば、ＨＴＴＰクッキーを使用して、Ｗｅｂページを、ユーザに応じて、独立したＨＴＴＰ操作に渡って、個人化することが行われている。しかし、クッキーに関する問題は、サービスの状態および場合によっては振る舞いが、クッキーの値に依存することであり、これは、振る舞い型Ｗｅｂサービス・モデルとは一貫性を持たない。しかし、ＷＳＡＰでは、セッションを別のサービスとしてモデル化しており、セッション識別子またはセッションの識別のためのクッキーを使用しないので、そのセッションは、作成され、操作され、そして終了させられる他の任意のサービスと同じように、状態および振る舞いを持つ１つのサービスとなる。
【００６５】
上で説明したサービスのやり取りの他に、複数のサービスは、ＷＳＡＰメッセージの実際の交換を含まない形で、互いに関係し合うことができる。そのような関係の例としては、１組のサービスを同じセキュリティ・グループに属するものとして記述するセキュリティポリシ、および１組のサービスを特定の当事者がどのように運用するかを記述する管理ステートメントがある（が、これに限定されるものではない）。そのような場合の例では、これらの記述（descriptions)は、１組のサービスを指すが、記述は、関係するサービスの間の実際の通信を何ら含むものではない。しかし、その関係を捉えることは、明示的なＷＳＡＰメッセージが交換されない場合でも、やはり重要である。
【００６６】
こうした関係を、振る舞いのタイプとしてモデル化し、規約の部分として記述することが可能である。このような規約を、「グラフ規約」（graph contracts）と呼んで、こうした関係の規約（relationship contract）をＷＳＡＰメッセージの規約と差異化する。グラフ規約は、他の規約と同じ記述言語を用いて記述される。
【００６７】
共有セマンティクスの説明に移るが、一般に、サービスは、他のサービスによって作成される。より詳細には、サービスは、ＣＲＥＡＴＥ操作を用いて作成することができ、これは、新しいサービスの作成を、既存のサービスをコピーすることによって行う。このために、新しく作成されるサービスは、作成側のサービス、すなわち、ＣＲＥＡＴＥ操作が新しく作成されるサービスの値に対するテンプレートとして働くことを受理するサービスの、サービスの振る舞いおよびサービス値を持つ。ＣＲＥＡＴＥ要求は、新しく作成されるサービスの初期化に使用する追加の状態を含むことができる。これにより、サービスを、その他の方法で不変の状態で初期化することができる。ＣＲＥＡＴＥ要求は、新しく作成されたサービスのコピーされた状態を、そのサービスの形態に従って修正する状態を含むことができる。提案されるエンド・ポイントに、ＣＲＥＡＴＥ要求の部分として名前を付けること、または作成側のサービスにその名前を提供させること、は実行可能である。レガシーのサービスは、直接にＷｅｂサービスとして作成されていなくても、Ｗｅｂサービスとして露出させることができることに注意されたい。
【００６８】
ＷＳＡＰでは、ＣＲＥＡＴＥ操作をサポートするサービスは、特定の振る舞いからなるサービスを作成することができる。どのようなサービスも、ＣＲＥＡＴＥ操作をサポートでき、したがって、望むだけの数の振る舞いの作成をサポートすることができる。ＷＳＡＰ操作は、明示的なサービスと関連付けられているため、ＣＲＥＡＴＥ操作は、ターゲットとなるサービスが新しいサービスを作成することの要求となる。ＣＲＥＡＴＥ操作では、ターゲットとなるサービスそのものの作成は行わない。
【００６９】
図７に、ＣＲＥＡＴＥ操作により、１つまたは複数の従属するサービスの作成がどのように引き起こされるかを示している。単純なサービスの作成の場合、ＣＲＥＡＴＥ操作は、単一のサービスを、作成シーケンスと、それに続く明示的な初期化を介して作成する。図７で、クライアント７０２は、ＣＲＥＡＴＥ操作を、そのような操作を取り扱うサービス７１０に伝える。Ｗｅｂサービス一般と同様に、ＣＲＥＡＴＥ要求は、作成すべきサービスのタイプに関する規約を含んでいる。サービスを作成することは、そのサービスにＵＲＩを割り当てること、および、そのサービスを所与の振る舞いに関連付けることを含んでいる。あるサービスの作成が済んだ後、追加のメッセージ操作として、サービス値をそのサービスの構造に従って変更すること、および／または、その新しいサービスの他のサービスとの関連付けを、関係、アクセス制御、または他の機構を通して行うことを含むことができる。
【００７０】
応答は、新しく作成されたサービス７２０のＵＲＩを含む、インスタンス化された規約を含んでいる。そのサービスの作成が済んだ後、そのサービスは、その振る舞いおよび他のサービスとの関係に従って、適切に操作することができる。たとえば、そのサービスのセキュリティポリシへの関連付けを、そのようなポリシを取り扱うサービスを操作することによって行うことができる。
【００７１】
次の表に、ＷＳＡＰのＣＲＥＡＴＥ操作のプロパティを示している。
【００７２】
【表２】
2005339555.tif 000004
【００７３】
次のデータ構造は、サンプルのＣＲＥＡＴＥ操作のＳＯＡＰ  Ｂｏｄｙのコンテンツを含んでいる。要求はサービスによって定義され、応答では、空の応答のために定義されているコンビニエンス型が使用されている。
【００７４】
【表３】
2005339555.tif 000005
【００７５】
より複雑なサービスの作成では、ＣＲＥＡＴＥ操作により、１組の関連するサービスが作成される。たとえば、複雑なサービスの作成は、１組のサービスが、いつも一緒に存在する形で関係すると、その作成サービスが知っている場合に、発生する。図８は、２つのサービスの作成を例示するシーケンス図である。図８では、単純なサービスの作成の場合のように、クライアント８０２は、ＣＲＥＡＴＥ操作を、そのような操作を取り扱うサービス８１０（作成サービスＡ）に伝える。操作の要求（operation request）は、作成すべきサービスのタイプに関する規約を含んでいる。作成サービスＡというサービス８１０は、別のＣＲＥＡＴＥ操作を、作成サービスＢ（図８でのラベルは８１２である）に伝え、もう１つの新しいサービス８２４、すなわちサービスＢを作成する。
【００７６】
サービスＡおよびＢ（８２２および８２４）の作成が済んだ後、作成サービスＢのサービス８１２は、作成の応答を、作成サービスＡのサービス８１０へと送り、今度はサービス８１０が作成の応答をクライアント８０２へと送る。作成サービスＡのサービス８１０の送った作成の応答は、２つの新しく作成されたサービス８２２および８２４のＵＲＩ（複数）を含むインスタンス化された規約を含む。複雑なサービスの作成では、ＷＳＡＰからは、サービスがトランザクションのコンテクストの範囲内で作成されることの本来的な（inherent）保証が提供されないことに注意されたい。そのような保証の提供は、そのサービスの振る舞いを、トランザクションのサポートによって拡張することによって行うことができる。
【００７７】
上で説明したように、ＷＳＡＰサービスの振る舞いは、規約として記述される。通常、規約は、ＸＭＬ文書としてシリアライズされるが、これは必須ではない。規約そのものもサービスであり、したがって、規約は、ＵＲＩによって識別され、その規約に従って、他のどのようなサービスとも同様に、操作することができる。
【００７８】
サービスは、サービスの規約ではなく、その２つのサービスが通信するのに必要な他のサービスのＵＲＩを持つことができる。規約を得るために、ＷＳＡＰプロトコルは、あらゆるサービスがＬＯＯＫＵＰ操作をサポートすることを要求する。ＬＯＯＫＵＰ操作は、あるサービスが、別のサービスにその規約を要求し、それにより、サービスの振る舞いを決定する、ことを可能にする。
【００７９】
【表４】
2005339555.tif 000006
【００８０】
次に、サンプルのＬＯＯＫＵＰ操作のＳＯＡＰ  Ｂｏｄｙのコンテンツを示す。要求と応答のどちらもが、ＷＳＡＰによって定義されている。
【００８１】
【表５】
2005339555.tif 000007
【００８２】
図９に、クライアント９０２とサービス９２０の間のＬＯＯＫＵＰ操作を示すサンプルのシーケンスを示している。ルックアップの応答は、規約のＵＲＩを含み、この規約は、規約そのものを返すことも実現可能であるけれども、上で触れたようにサービスでもある。
【００８３】
したがって、ある実装形態では、ＬＯＯＫＵＰは、規約／プロトコルのシリアライゼーションを含む文書へのＵＲＩを返す。規約は、メッセージの順序を定義されるだけでなく、ＵＲＩを有するポートによって示され、その上でメッセージが交換される、対話ポイント（interaction points）を定義する。さらに、その文書と、キー／値の対の配列である、ＢｉｎｄｉｎｇＬｉｓｔ（バインディング・リスト）を併せたものが、規の文書をインスタンス化させるために使用される。これにより、総称的な名前を、ランタイム時に真の値で置き換えられるようになり、サービスのインスタンス間の関係を、ランタイム時に決定して、サービスのインスタンス間の反射的機能を提供することができるようになる。規約／バインディング・リストは、分散されたセッティングでの依存関係の管理を可能とし、それと同時に、起動時の必要なサービスを指定する。
【００８４】
サービスの状態の取り出しに関して、ＷＳＡＰプロトコルでは、ＧＥＴとＱＵＥＲＹという名前の２つの操作が定義されている。どちらの操作も安全であり、べき等（idempotent）であるが、ＧＥＴとＱＵＥＲＹの操作の間の違いは、下で説明するように、ＱＵＥＲＹ要求が構造化されたクエリー（問い合わせ）を含むのに対し、ＧＥＴ要求は、サービスの現在の状態のスナップショットに対するアプリケーション独立な要求である。その結果、ＱＵＥＲＹ要求では、クエリーを受けているサービスについての特定のスキーマ知識が必要となるが、ＧＥＴ要求では必要にならない。この違いの結果として、ＱＵＥＲＹ要求が、サービスの名前の部分でないパラメータを含むのに対し、ＧＥＴ要求では、サービスを、そのサービスの名前の部分として識別するパラメータが提供されることになる。
【００８５】
ＱＵＥＲＹとＧＥＴをどちらもサポートすることにより、ＷＳＡＰでは、構造化された識別子も不透明な（opaque）識別子もサポートし、そのような解決策の間のマッピングが可能になっている。これは、その使用のコンテクストに応じて、どちらにも利点があるためである。より詳細には、サービスを名付ける際に、クエリーなどの構造化された名前と、ＵＲＩなどの意味的に不透明な名前との使用の間には、競合（tension）がある。たとえば、「http://example.com/people」として識別され、人物の名前の構造化された表現を提供できるサービスの例を考える。特定の人物の参照を、少なくとも３つの異なるやり方で、すなわち、構造化されたクエリーとして、ＵＲＩクエリーコンポーネント内にエンコードされた非構造化クエリーとして、またはＵＲＩパス・コンポーネントの部分である不透明な識別子として、行うことができる。サービスに対して発行される構造化クエリーは、特定の任意の人物を参照するために、「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｐｅｏｐｌｅ」というサービスの例に対して発行される、次の構造化クエリーの例に示すように、サービスの構造についての知識を必要とする。
【００８６】
【表６】
2005339555.tif 000008
【００８７】
これとは対照的に、ＵＲＩクエリーコンポーネントの不透明でない部分としてエンコードされた非構造化クエリーでは、通常、ＵＲＩ  ＨＴＭＬ形式エンコーディングを使用することになる。このモデルでは、名前／値の対の組についての知識が必要であるが、特定のサービスについての構造化された知識は、こうした名前／値の対をエンコードするＵＲＩを組み立てる（compose）ためには、必要ではない。次の例に、ＵＲＩクエリーコンポーネント内に名前／値の対としてエンコードされた、そのような非構造化クエリーを示している。
【００８８】
【表７】
2005339555.tif 000009
【００８９】
ＵＲＩパス・コンポーネントの部分である不透明な識別子では、実際の解決がクエリーに関係する可能性があることを明らかにしない。クライアントが知る必要があるのは、識別子を、この場合はＨＴＴＰを使用することによって、どのように解決するか、ということだけである。次の例に、そのような不透明な識別子を示している。これは、クエリーの部分を何ら表現していない。
【００９０】
【表８】
2005339555.tif 000010
【００９１】
クエリーの解決策の１つの利点は、クエリー・パラメータを強く型付け（strongly typed）することが可能なことである。しかし、その結果として、構造化クエリーはその人物に対する識別子の部分になることになる。これは、その人物を参照させたいと思っているどのようなエンティティも、その特定の構造化された名前を使用し、しかも理解する必要があることを意味する。他の事柄を識別する構造化された名前は、異なる形態を取り、使用するためには、また特別な知識を必要とすることになる。一部の場合、特にユーザがデータに操作を行うと期待されているときには、これはうまく働く。しかし、特別な知識が必要となることから、名前の特定の形態について詳しい知識をもっているグループの外部で、その名前の概念を使いこなすのが難しいために、スケーラビリティが直ちに問題となる。
【００９２】
識別子の間のもう１つの重要な違いは、存在するデータ隠匿（data-hiding）のレベルである。より詳細には、クエリーの解決策では、クエリーの構造についての知識が必要であるのに対し、非構造化エンコードのクエリーおよび不透明な解決策では、この順に（gradually）提供される情報は少なくなる。非構造化エンコードのクエリーを使用できるのは、公開できる特定のキーワードが存在する場合、特に、それがマッピングしなければならないＵＲＩの数を減らす役に立つ場合である。そのような適用の典型例は、Ｇｏｏｇｌｅ（商標）（「http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=msft」）などの公開サーチ・エンジン、および典型的な株式速報サービス（「http://moneycentral.msn.com/scripts/webquote.dll?iPage=qd&Symbol=msft」）である。
【００９３】
非構造化エンコードのクエリーの解決策が、Ｗｅｂ上で今日、最も普通に使用されているタイプの識別子であるが、構造化データをＵＲＩの中にエンコードするのは非常に困難である。しかも、ＵＲＩの部分としてエンコードされたデータは、本来的に、インフラストラクチャに対して公開され、このため、識別子の部分であるどのようなデータに対しても、セキュリティ関連の問題を扱うことは、より難しくなる。不透明な識別子の解決策では、クエリー・インターフェースのサポートは、クエリーをその識別子にマッピングするためのモデルが存在しない限り、行われない。クエリーの構造が、サービスの潜在的なユーザの一部にしか知られていない（たとえば、プライバシまたは他の理由で）場合には、これは、非構造化エンコードのクエリーの解決または不透明な識別子の解決によって、構造化されたデータの露出を、まったく行わないか、または制限された部分だけで行うことによって達成することができる。
【００９４】
したがって、ＧＥＴ操作は、サービスのシリアライズされた値の状態を取り出すために使用することができ、次のプロパティをもっている。
【００９５】
【表９】
2005339555.tif 000011
【００９６】
次の表は、サンプルのＧＥＴ操作のＳＯＡＰ  Ｂｏｄｙのコンテンツを含んでいる。要求の定義はＷＳＡＰが、応答の定義はサービスが行っている。
【００９７】
【表１０】
2005339555.tif 000012
【００９８】
ＱＵＥＲＹ要求は、一部の場合にＧＥＴ操作へとマッピングすることができ、たとえば、そのようなマッピングは、特定のクエリーに対する識別子を効率よく提供する。たとえば、これにより利益が提供されるのは、同じクエリーが数多くの異なるコンテクストで生じるとき、または、ＵＲＩ参照がキャッシュ動作を導入するために必要となるときである。図１０に、ＱＵＥＲＹからＧＥＴへのマッピングを例示するサンプルのシーケンスを示している。このＱＵＥＲＹ応答は、Ａに対するＱＵＥＲＹと同じ結果を提供できるサービスＢのＵＲＩを含んでいる。このマッピングは、どのようなサービスによっても行うことができ、ＱＵＥＲＹのターゲットとするサービスに関係していなくてもよいことに注意されたい。
【００９９】
したがって、ＱＵＥＲＹ操作は、サービスのシリアライズされた値の状態に関してクエリーを行うのにも使用することができ、次のプロパティをもっている。
【０１００】
【表１１】
2005339555.tif 000013
【０１０１】
次の表は、サンプルのＱＵＥＲＹ操作のＳＯＡＰ  Ｂｏｄｙのコンテンツを含んでいる。要求も応答も、定義はサービスが行っている。
【０１０２】
【表１２】
2005339555.tif 000014
【０１０３】
ＧＥＴおよびＱＵＥＲＹの操作は安全で「べき等」であり、そうであることが共有セマンティクスの観察可能な性質によって知られるため、様々なインターミディアリーが、メッセージ交換に対して付加価値を提供できることに注意されたい。たとえば、キャッシュ・サービスには、ＱＵＥＲＹまたはＧＥＴの要求が状態の変更を行わないことが判っている。この結果、キャッシュからは、そのような要求に応答して、状態データの提供が、状態の変更を行う操作の検出が行われない限りまた行われるまで、続けられる。
【０１０４】
状態の取り出しのほかに、ＷＳＡＰは、サービスの状態が、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥ操作を用いて更新されることを可能にする。こうした操作は、サービスの値に対してだけ適用され、サービスの作成または終了を行うことはない。
【０１０５】
ＷＳＡＰサービスのデータ構造は、そのサービスが、その振る舞いの関数として定義する。その結果、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥ操作では、ＱＵＥＲＹと同様にこのサービスの値に影響を及ぼすためには、要求側（requestor）が、この構造についての知識を持っていることが要求される。したがって、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥ操作は、個々のサービスへと合わせることができるように、そのアブストラクト内で定義される。
【０１０６】
サービスの値を、ＩＮＳＥＲＴ操作を用いて変更すると、ＩＮＳＥＲＴ要求に含まれているその値は、サービスの値に付け加えられる。サービスの観察が、孤立した形で行われると仮定すると、ＩＮＳＥＲＴ操作の結果の検出を、ＩＮＳＥＲＴ操作の前に発行されたＧＥＴ操作とＩＮＳＥＲＴ操作の後で発行されたＧＥＴ操作の違いを見ることによって行うことができ、これは、図１１のメッセージ・シーケンス図に一般的に示している通りである。図１１で、クライアント１１０２は、状態データのサービス１１２０からの受け取りを、挿入の操作の前に行い、この挿入の操作に続く次の要求の後で、更新された状態データを受け取る。
【０１０７】
ＩＮＳＥＲＴ操作を使用すると、サービスにシリアライズされた値の状態を付け加えることができ、これは次のプロパティによって記述される通りである。
【０１０８】
【表１３】
2005339555.tif 000015
【０１０９】
次の表は、サンプルのＩＮＳＥＲＴ操作のＳＯＡＰ  Ｂｏｄｙのコンテンツを含んでいる。要求の定義はＷＳＡＰが、応答の定義はサービスが行っている。この例では、どこでデータを挿入すべきかの順序付けを何ら示していないが、アプリケーションは、そのアプリケーションのスキーマを定義して、順序づけの制約に適応するようにすることができる。
【０１１０】
【表１４】
2005339555.tif 000016
【０１１１】
サービスの構造の定義は、そのサービスが行い、ＷＳＡＰでは、その値の挿入を何らかの特定のやり方で行うことは要求しない。サービスは、その構造の部分として、ＩＮＳＥＴ、ＵＰＤＡＴＥ、およびＤＥＬＥＴＥ操作が、その操作を行うべき特定の場所を、たとえば、ＸＰａｔｈ表現を用いて識別する、ことを可能にする。
【０１１２】
ＩＮＳＥＲＴと同様に、あるサービスの値を、ＤＥＬＥＴＥ操作、そこでは、ＤＥＬＥＴＥ要求の中で識別されるサービスの値の部分が削除される（deleted）、を用いて変更する際、同じ一般的な観察の特徴が適用される。サービスの観察が、孤立した形で行われると仮定すると、ＤＥＬＥＴＥ操作の結果の検出を、ＤＥＬＥＴＥ操作の前に発行されたＧＥＴ操作とＤＥＬＥＴＥ操作の後で発行されたＧＥＴ操作の違いを見ることによって行うことができ、これは、図１２に一般的に示している通りである。
【０１１３】
次の表に、ＤＥＬＥＴＥ操作のプロパティを示している。
【０１１４】
【表１５】
2005339555.tif 000017
【０１１５】
ＤＥＬＥＴＥ要求の定義は、サービスが行い、応答では、空の応答のために定義されているコンビニエンス型が使用される。
【０１１６】
【表１６】
2005339555.tif 000018
【０１１７】
サービスの値を、ＵＰＤＡＴＥ操作を用いて変更すると、サービスの値のＵＰＤＡＴＥ要求の中で識別される部分が、ＵＰＤＡＴＥ要求に含まれている値で置き換えられる。ＵＰＤＡＴＥ操作は、トランザクションのコンテクストの範囲内で見ると、ＤＥＬＥＴＥと、それに続くＩＮＳＥＲＴに似ている。すなわち、ＵＰＤＡＴＥが成功するのは、ＵＰＤＡＴＥ操作によって記述されるように、既存のサービスの値が、成功裡に変更される場合に限られる。ＩＮＳＥＲＴおよびＤＥＬＥＴＥと同様に、ＵＰＤＡＴＥ操作の結果の検出は、孤立した形で、ＵＰＤＡＴＥ操作の前に発行されたＧＥＴ操作とＵＰＤＡＴＥ操作の後で発行されたＧＥＴ操作の違いを見ることによって行うことができ、これは、図１３に一般的に示している通りである。
【０１１８】
ＵＰＤＡＴＥ操作は、既存の値の状態を更新（update）するのに使用し、次のプロパティをもっている。
【０１１９】
【表１７】
2005339555.tif 000019
【０１２０】
次の表は、サンプルのＵＰＤＡＴＥ操作のＳＯＡＰ  Ｂｏｄｙのコンテンツを含んでいる。要求と応答の動詞（verb）のどちらの定義も、ＷＳＡＰが行っており、要求と同様に、ＳＯＡＰエンベロープの本体は、サービスにより定義された（service-defined）応答の要素を含む。
【０１２１】
【表１８】
2005339555.tif 000020
【０１２２】
ＷＳＡＰによって容易になる別の操作は、複製を含み、これは、状態を分散サービスに渡って同期した状態に保つ、クリーンで、透過性のあるやり方を提供する。この目的のために、ＷＳＡＰは、あるサービスが別のサービスと同期化されることを可能にする複製モデルを提供する。２つのサービスの状態を同期した状態に保つために、複製された側のサービスにより、複製する側のサービス上では、複製された側のサービス上で行われたのと同じ操作または操作群が行われる。
【０１２３】
一般に、ＲＥＰＬＩＣＡＴＥ、ＳＵＢＳＣＲＩＢＥ、ＣＡＮＣＥＬＲＥＰＬＩＣＡＴＥ、およびＵＮＳＵＢＳＣＲＩＢＥは、購読者リスト（subscriber list）の状態を操作する（manipulate）。ＷＳＡＰでは状態が露出されるので、購読者リストは、別のＷＳＡＰサービス（たとえば、ｓｕｂｓｃｒｉｂｅＨｅｌｐｅｒ）内で保管される可能性がある。メインのＷＳＡＰサービスは、Ｉｎｓｅｒｔ／Ｄｅｌｅｔｅ要求を、ＳＵＢＳＣＲＩＢＥ、ＲＥＰＬＩＣＡＴＥ、ＣＡＮＣＥＬＲＥＰＬＩＣＡＴＥ、およびＵＮＳＵＢＳＣＲＩＢＥの要求の受け取り後、適切に送信する。メインのサービス上でのＬＯＯＫＵＰの応答の中で、バインディング内に、ヘルパが識別され、これにより、第３者は、そのサービスの状態全体を獲得できるようになる。これ、すなわち状態全体は、購読リストを含めて、ＵＲＩで表現された場合に、閲覧可能となる（visible）。第３者は、購読記録（subscriptions）をそれ自体の状態上へと分離することによって、サブスクライバに対して、あるサービスが消滅し異なるＵＲＩで復活したことを通知できることに注意されたい。
【０１２４】
図１４で一般的に示しているように、ＩＮＳＥＲＴ操作の実行が、複製された側のサービス１４３０上で、サブスクライバ（subscriber）１４５０からの事前のＲＥＰＬＩＣＡＴＥ要求に基づいて行われた場合、複製された側のサービス１４３０は、ＩＮＳＥＲＴ操作の実行を、複製する側のサービス１４４０上で行うことになる。ＷＳＡＰ複製モデルのセマンティクスは、（下で説明する）ＷＳＡＰ通知モデルとは異なっており、これは、サービスがＮＯＴＩＦＹメッセージの受け取り後、何らのアクションの実行も要求しないことに注意されたい。
【０１２５】
ＲＥＰＬＩＣＡＴＥ操作を使用すると、サービスまたはサービスの部分を複製することができる。複製の振る舞いは、要求の中に含まれている規約によって記述される。次の表に、ＲＥＰＬＩＣＡＴＥ操作のプロパティを示している。
【０１２６】
【表１９】
2005339555.tif 000021
【０１２７】
次の表は、サンプルのＲＥＰＬＩＣＡＴＥ操作のＳＯＡＰ  Ｂｏｄｙのコンテンツを含んでいる。要求の定義はＷＳＡＰが行い、応答の定義はサービスが行っている。この例では、応答は、空の応答のために定義されているコンビニエンス型である。
【０１２８】
【表２０】
2005339555.tif 000022
【０１２９】
複製の開始は、ＲＥＰＬＩＣＡＴＥ操作を発行することによって行われ、これは、使用すべき複製モデルを記述する規約を含んでいる。たとえば、複製された側のサービスは、ＩＮＳＥＲＴ操作を通した状態の追加を複製するだけの複製モデルをサポートすることができる。この例のように、複製する側のサービスは、ＩＮＳＥＲＴ操作に興味を持つだけである場合、その指示を、ＲＥＰＬＩＣＡＴＥ操作内のその複製の規約への指示によって、そのことを指示する。このＲＥＰＬＩＣＡＴＥ要求が受理された場合、複製サービスは、その現在の状態を、複製する側のサービスに対する１組のＩＮＳＥＲＴ操作として転送する。
【０１３０】
図１４のように、購読を行うサービス（subscribing service）１４５０は、複製する側のサービス１４４０とは異なっていてもよいことに注意されたい。さらに、複製する側のサービスは、すでに存在し、特定の状態をもっていてもよい。複製の規約に応じて、この状態は、複製の開始時にオーバーライドされてもされなくてもよい。複製の規約がＩＮＳＥＲＴ操作のみを可能とする上の例では、複製された状態は、複製する側のサービスの既存の状態に付け加えた状態になることになる。
【０１３１】
複製の規約は、一部の場合には、それ自体で終了してもよく、複製は、有効期限の時間（expiration time）で制限することもでき、または状態を無期限に（indefinitely）複製し続けることもできる。ある実装形態では、有効期限を規約の部分として決めることができるが、代替方法として、値のパラメータとして提供することも可能である。
【０１３２】
また、複製の終了を、ＣＡＮＣＥＬＲＥＰＬＩＣＡＴＥ操作を用いて明示的に行うこともできる。ＣＡＮＣＥＬＲＥＰＬＩＣＡＴＥ操作に関するサンプルのシーケンス図を、図１５に示している。これから判るように、クライアント１５０２からの最初の挿入の要求を、複製された側のサービス１５３０で受け取り、複製する側のサービス１５４０に対して複製している。アンサブスクライバー・サービス（unsubscriber service）１５５２からＣＡＮＣＥＬＲＥＰＬＩＣＡＴＥ操作が要求された場合、確立されている複製は、明示的に終了させられる。図１５の例では、クライアント１５０２からの更なる挿入の要求は、複製された側のサービス１５３０によって、複製する側のサービス１５４０に複製されることはない。
【０１３３】
【表２１】
2005339555.tif 000023
【０１３４】
次の表は、サンプルのＣＡＮＣＥＬＲＥＰＬＩＣＡＴＥ操作のＳＯＡＰ  Ｂｏｄｙのコンテンツを含んでいる。応答では、空の応答のために定義されているコンビニエンス型が使用されている。
【０１３５】
【表２２】
2005339555.tif 000024
【０１３６】
複製モデルのほかに、ＷＳＡＰでは、単純イベント通知モデルをＮＯＴＩＦＹ操作に基づいて定義しており、これは、状態の変更が起きたことは報告するが、その状態の変更が起きた状況は明かさない。イベント通知モデルのセマンティクスは、複製モデルとは異なり、そこでは、複製する側のサービスは、状態を、複製された側のサービスから送ったメッセージの結果として、変更することに注意されたい。通知モデルでは、サブスクライバは、ＮＯＴＩＦＹメッセージの受け取り後、何らのアクションの実行も要求されない。その結果、サブスクライバの取るどのアクションも、もっぱらそれ自体のセマンティクスに基づくのであり、イベント通知ソース（source）のそれに基づくのではないことになる。ＮＯＴＩＦＹ操作は、購読の対象となり、したがって期限切れになることがあり、これは、規約の部分とすることもでき、または値のパラメータとして設定することもできることに注意されたい。
【０１３７】
ＮＯＴＩＦＹ操作は、ＷＳＡＰ通知モデルの部分であり、イベント通知を発行するのに使用することができ、次のプロパティをもっている。
【０１３８】
【表２３】
2005339555.tif 000025
【０１３９】
次の表は、サンプルのＮＯＴＩＦＹ操作のＳＯＡＰ  Ｂｏｄｙのコンテンツを含んでいる。
【０１４０】
【表２４】
2005339555.tif 000026
【０１４１】
図１６に、ＮＯＴＩＦＹに関するＳＵＢＳＣＲＩＢＥ操作を示しており、図において、サブスクライバ１６５０は、イベントソース（event source）１６７０に要求する。この要求は、サブスクライバが状態の変更を見ることに興味のあるイベント通知ソースの部分を識別するクエリーを含んでいる。ＳＵＢＳＣＲＩＢＥ操作が受理されると、イベント通知ソース１６７０は、ソースの現在の状態を示すＮＯＴＩＦＹ操作を開始する。この最初のＮＯＴＩＦＹ操作の後、イベント通知ソースは、新しいＮＯＴＩＦＹ操作の発行を、イベント通知ソースの状態が適切に変更される（changes）と、必ず行う。イベント通知ソースの振る舞いを記述する規約は、アプリケーションのセマンティクスとは独立であるため、その定義はすべてＷＳＡＰが行う。
【０１４２】
ＳＵＢＳＣＲＩＢＥ操作は、このように、サービスの状態の変更を購読するのに使用され、次のプロパティをもっている。
【０１４３】
【表２５】
2005339555.tif 000027
【０１４４】
次の表は、サンプルのＳＵＢＳＣＲＩＢＥ操作のＳＯＡＰ  Ｂｏｄｙのコンテンツを含んでいる。要求の定義はＷＳＡＰが行い、応答の定義はサービスが行っている。この例では、応答は、空の応答のために定義されているコンビニエンス型である。
【０１４５】
【表２６】
2005339555.tif 000028
【０１４６】
購読は、複製モデルに似た、有効期限の時間で制限することができる。同様に、購読の終了はいつでも、ＵＮＳＵＢＳＣＲＩＢＥ操作を用いて行うことができるが、これは図１７に示す通りであり、そこでは、アンサブスクライバ（unsubscriber）１７５２から、ＵＮＳＵＢＳＣＲＩＢＥ操作がイベント通知ソースへと送られて、それ以降の通知が取り消される。
【０１４７】
購読を取り消すＵＮＳＵＢＳＣＲＩＢＥ操作は、次のプロパティをもっている。
【０１４８】
【表２７】
2005339555.tif 000029
【０１４９】
次の表は、サンプルのＵＮＳＵＢＳＣＲＩＢＥ操作のＳＯＡＰ  Ｂｏｄｙのコンテンツを含んでいる。要求の定義はＷＳＡＰが行い、応答の定義はサービスが行っている。この例では、応答は、空の応答のために定義されているコンビニエンス型である。
【０１５０】
【表２８】
2005339555.tif 000030
【０１５１】
ＷＳＡＰのイベント通知モデルは、イベント通知がソース（source）からシンク（sink）へとプッシュされる、伝統的なプッシュ・モデルであることに注意されたい。しかし、メッセージ・パス内でバッファリングするインターミディアリーを使用することにより、プッシュ・モデルを、イベント通知シンクに対するオフラインのサポートを提供する、プル・モデルに変換することが可能である。
【０１５２】
サービス終了の記述に戻ると、ＷＳＡＰサービスは、終了させられると、どのようなタイプのメッセージの送信または受信も、もはや行うことができない。サービスの終了は、そのサービスの振る舞いに、そのサービスの送信または受信できる有限個のメッセージの組を記述させることによって行うことができる。そのサービスは、規約の履行を済ませると、終了し、それが消費していたリソースは何であれ、復元することができる。
【０１５３】
これに加えて、サービスの振る舞いでは、そのサービスの終了を強制する明示的なやり取りを定義することができる。この目的のために、ＷＳＡＰでは、ＤＲＯＰ操作を定義しており、これにより、ＤＲＯＰをその規約の部分として受理するサービスは、明示的に終了させることができる。図１８に示すように、ＤＲＯＰ操作をクライアント１８０２などのサービスから受理すると、ターゲットとなるサービス１８２０は、将来のどのようなメッセージの送信または受信も単に停止する。ＣＲＥＡＴＥ操作と同様に、ＤＲＯＰは、図１８のように単純とすることも、または下で図２０に関して説明するように、複雑とすることもできる。
【０１５４】
ＤＲＯＰ操作は、次のプロパティをもっている。
【０１５５】
【表２９】
2005339555.tif 000031
【０１５６】
次の表は、サンプルのＤＲＯＰ操作のＳＯＡＰ  Ｂｏｄｙのコンテンツを含んでいる。要求の定義はＷＳＡＰが行い、応答では、空の応答のために定義されているコンビニエンス型を使用している。
【０１５７】
【表３０】
2005339555.tif 000032
【０１５８】
サービスの振る舞いに、無制限な量のメッセージを送信または受信できるようにし、サービスを停止させられる明示的な操作ができないようにすることは、実行可能であるが、その場合、そのサービスの終了を適切な（graceful）方法で行うことはできないことに注意されたい。さらに、記述されているＷＳＡＰ操作の数と、経過したクロック時間に関するサービスの寿命の間には、固有の関係がないことに注意されたい。サービス識別子をサービスの終了後リサイクルせず、旧いサービスの使わなくなった（obsolete）参照が、同じ名前の新しいサービスに適用されるのを避けるようにすることが推奨される（が、これは必須ではない）。
【０１５９】
場合によっては、ターゲットとなるサービスは、ディレクトリ・サービスでの登録取り消しや終わりのイベント通知の送出など、何らかの追加のクリーンアップを行うことができる。そのようなクリーンアップは、ＤＲＯＰ操作が完了する前に行われるが、これは、図１９のＤＥＬＥＴＥ操作およびＮＯＴＩＦＹ操作で示している通りである。
【０１６０】
図２０に示している、複雑なサービスの終了では、複数の関連するサービスが、セットで終了させられる。これが起きる可能性があるのは、サービス間の関係が、サービスが独立しては存在できないようなものである場合である。複雑なサービスの終了の場合、ＷＳＡＰからは、すべてのサービスがトランザクションのコンテクストの範囲内で終了させられることの本来的な保証が提供されない。そのような保証の提供は、そのサービスの振る舞いを、トランザクションのサポートによって拡張することによって行うことができる。
【０１６１】
上のコマンド群から判るように、ＷＳＡＰにより、異なるサイトでの状態の把握および再作成を行えるようになっているで、ＷＳＡＰは、サービスが再起動可能で、動的にロードバランスすることを可能にすると、見なすことが可能である。これは、トランザクションの実施、ロードバランスおよび／または動作可能時間を最大に保つためにバージョン更新を存続させることに使用することができる。例として、タイプがＴで、ＵＲＩがＡであるサービスを考える。ＷＳＡＰのコマンド群により、別のサービスは、データをＡから（たとえば、ＧＥＴ要求によって）得て、Ａのルックアップを（たとえば、ＬＯＯＫＵＰ要求によって）行ってその依存関係を取得し、Ａをドロップすることができる。次いで、タイプがＴで、ＵＲＩがＢであるサービスを作成し、Ｂ上置き換え（たとえば、ＤＥＬＥＴＥおよびＩＮＳＥＲＴ）を行うことにより、その結果は、厳密に同じ状態の振る舞いが、Ａがドロップされたところから複製されたものとなる。
【０１６２】
以上の詳細な説明から判るように、クライアント（サービス）および他のＷｅｂサービスが、サービスを構築するエンティティを含めて、Ｗｅｂサービスとの通信を、効率的で安全であるが、観察可能で再使用可能な形で行い、これにより、インターミディアリーが通信に付加価値を付け加えられるようにするための方法、システム、および機構が提供されている。したがって、この方法およびシステムにより、現在のコンピューティングに必要な顕著な利点および利益が提供される。
【０１６３】
本発明には、様々な修正および代替構成（constructions）の余地があるが、その例示的な特定の実施形態を、図面には示してあり、上で詳細に説明を行っている。しかし、本発明を、開示した特定の形式に限定する意図はなく、逆に、本発明の趣旨および範囲の内部に入る修正、代替構成、および均等物をすべて蔽うことを意図としていることを理解されたい。
【図面の簡単な説明】
【０１６４】
【図１】本発明を組み込むことのできるコンピュータ・システムを一般的に示す構成図である。
【図２】本発明の一態様による、ＷＳＡＰ（web service application protocol）を介して互いに通信するサービスを一般的に示す構成図である。
【図３】本発明の一態様による、ＷＳＡＰメッセージ通信時の一方向メッセージ交換パターンの概念を一般的に示す構成図である。
【図４】本発明の一態様による、ＷＳＡＰメッセージのための要求／応答メッセージ交換パターンの例を一般的に示す構成図である。
【図５】本発明の一態様による、異なる振る舞いを伴うサービスのセットとして露出されるファイルを一般的に示す構成図である。
【図６】本発明の一態様による、同じサービス値を含むかどうかに関わらず異なるサービスとしてモデル化される異なるアクセス・モデルを一般的に示す構成図である。
【図７】本発明の一態様による、ＣＲＥＡＴＥ操作におけるメッセージのシーケンスの例およびそれに続く明示的な初期化を一般的に示す図である。
【図８】本発明の一態様による、複合サービス作成のためのメッセージのシーケンスの例を一般的に示す図である。
【図９】本発明の一態様による、ＬＯＯＫＵＰ操作におけるメッセージのシーケンスの例を一般的に示す図である。
【図１０】本発明の一態様による、ＱＵＥＲＹ操作からＧＥＴ操作へのマッピングのためのシーケンスを一般的に示す図である。
【図１１】本発明の一態様による、ＩＮＳＥＲＴ操作の前後で実行されるＧＥＴ操作の違いを示してそのＩＮＳＥＲＴ操作の結果を例示するシーケンス図である。
【図１２】本発明の一態様による、ＤＥＬＥＴＥ操作の前後で実行されるＧＥＴ操作の違いを示してそのＤＥＬＥＴＥ操作の結果を例示するシーケンス図である。
【図１３】本発明の一態様による、ＵＰＤＡＴＥ操作の前後で実行されるＧＥＴ操作の違いを示してそのＵＰＤＡＴＥ操作の結果を例示するシーケンス図である。
【図１４】本発明の一態様による、ＲＥＰＬＩＣＡＴＩＯＮシーケンスの例を一般的に示す構成図である。
【図１５】本発明の一態様による、複製をキャンセルするためのＣＡＮＣＥＬＲＥＰＬＩＣＡＴＩＯＮシーケンスの例を一般的に示す構成図である。
【図１６】本発明の一態様による、イベント通知を得るためのＳＵＢＳＣＲＩＢＥシーケンスの例を一般的に示す構成図である。
【図１７】本発明の一態様による、ＵＮＳＵＢＳＣＲＩＢＥシーケンスの例を一般的に示す構成図である。
【図１８】本発明の一態様による、単純サービス終了の例を一般的に示す構成図である。
【図１９】本発明の一態様による、追加のクリーンアップを伴う単純サービス終了の例を一般的に示す構成図である。
【図２０】本発明の一態様による、複合サービス終了の例を一般的に示す構成図である。
【符号の説明】
【０１６５】
１１０    コンピュータ
１２０    処理ユニット
１２１    システム・バス
１３０    システム・メモリ
１３１    （ＲＯＭ）
１３２    （ＲＡＭ）
１３３    ＢＩＯＳ
１３４    オペレーティング・システム
１３５    アプリケーション・プログラム
１３６    他のプログラム・モジュール
１３７    プログラム・データ
１４０    非リムーバブル不揮発性メモリ・インターフェース
１４１    ハードディスク・ドライブ
１４４    オペレーティング・システム
１４５    アプリケーション・プログラム
１４６    他のプログラム・モジュール
１４７    プログラム・データ
１５０    リムーバブル不揮発性メモリ・インターフェース
１５１    磁気ディスク・ドライブ
１５２    磁気ディスク
１５５    光ディスク・ドライブ
１５６    光ディスク
１６０    ユーザ入力インターフェース
１６１    マウス
１６２    キーボード
１６３    マイクロフォン
１６４    タブレット
１７０    ネットワーク・インターフェース
１７１    ＬＡＮ（構内通信網）
１７２    モデム
１７３    ＷＡＮ（広域通信網）
１８０    リモート・コンピュータ
１８１    メモリ・ストレージ装置
１８５    リモートのアプリケーション・プログラム
１９０    ビデオ・インターフェース
１９１    モニタ
１９４    出力周辺インターフェース
１９５    スピーカ
１９６    プリンタ
２００    アーキテクチャ
２０２  Ｗｅｂクライアント・コード
２０４  ＷＳＡＰ  Ｗｅｂサービス
２０６  Ｗｅｂサービスの規約の要求
２０８  Ｗｅｂサービスの規約の提供、バインディング・リスト情報
３０２  従来のファイル
３０４  ファイルとして読み込む
３０６  プログラムとして実行する
３０８  従来のファイルのメタデータを操作する
３１０  他のサービスとの関係についてのディレクトリを読み込む
４０３  サービスの値
４１１  読み取り専用アクセス
４１２  読み取り書き込みアクセス
４１３  暗号化アクセス
４１４  トランザクションによるアクセス
５６０  最初の送り手
５６２  最終的な受け取り手
６６０  最初の送り手
６６２  最終的な受け取り手
７０２  クライアント
７１０  作成サービス
７２０  新しいサービス
８０２  クライアント
８１０  作成サービスＡ
８２２  新しいサービスＡ
８１２  作成サービスＢ
８２４  新しいサービスＢ
９０２  クライアント
９２０  サービス
１００２  クライアント
１０２２  サービスＡ
１０２４  サービスＢ
１１０２  クライアント
１１２０  サービス
１２０２  クライアント
１２２０  サービス
１３０２  クライアント
１３２０  サービス
１４０２  クライアント
１４３０  複製された側のサービス
１４４０  複製する側のサービス
１４５０  購読者（サブスクライバ）
１５０２  クライアント
１５３０  複製された側のサービス
１５４０  複製する側のサービス
１５５２  購読停止者（アンサブスクライバ）
１６０２  クライアント
１６５０  購読者
１６７０  イベントソース
１６８０  イベントシンク
１７０２  クライアント
１７５２  購読停止者
１７８０  イベントソース
１７７０  イベントシンク
１８０２  クライアント
１８２０  サービス
１９０２  クライアント
１９２２  サービスＡ
１９２４  サービスＢ
１９２６  サービスＣ
２００２  クライアント
２０２２  サービスＡ
２０２４  サービスＢ
２０２６  サービスＣ
【図１】
2005339555.tif 000033
【図２】
2005339555.tif 000034
【図３】
2005339555.tif 000035
【図４】
2005339555.tif 000036
【図５】
2005339555.tif 000037
【図６】
2005339555.tif 000038
【図７】
2005339555.tif 000039
【図８】
2005339555.tif 000040
【図９】
2005339555.tif 000041
【図１０】
2005339555.tif 000042
【図１１】
2005339555.tif 000043
【図１２】
2005339555.tif 000044
【図１３】
2005339555.tif 000045
【図１４】
2005339555.tif 000046
【図１５】
2005339555.tif 000047
【図１６】
2005339555.tif 000048
【図１７】
2005339555.tif 000049
【図１８】
2005339555.tif 000050
【図１９】
2005339555.tif 000051
【図２０】
2005339555.tif 000052
【外国語明細書】
2005339555000001.pdf