JP2006164280A - ウェブサービスを作成し、対話するためのインターフェースインフラストラクチャ - Google Patents

Abstract

【課題】Ｗｅｂ Ｓｅｒｖｉｃｅを作成し、対話するインターフェースインフラストラクチャを提供する。
【解決手段】ウェブサービス名前空間は、様々なアプリケーションの作成を可能にするためのインフラストラクチャに関する。このインフラストラクチャは、様々なスケールおよび複雑さのメッセージベースアプリケーションを構築するための基礎を提供する。このインフラストラクチャまたはフレームワークは、基本的なメッセージング、セキュアメッセージング、信頼性のあるメッセージング、およびトランザクション式メッセージングのためのＡＰＩを提供する。いくつかの実施形態で、関連付けられたＡＰＩが、ユーティリティ、ユーザビリティ、拡張性、およびバージョン性をバランスする仕方で名前空間の階層にファクタ化される。
【選択図】図２

Description

本発明は、ソフトウェア開発に関する。より詳細には、本発明は、アプリケーションプログラムおよびコンピュータハードウェアによるソフトウェアプラットフォームの使用を容易にして、分散コンピューティングアクティビティを作成し、対話するアプリケーションプログラムインターフェース（ＡＰＩ）に関する。

コンピューティング技術は、我々の働き方、遊び方を変容した。コンピューティングシステムは今や、デスクトップコンピュータ、ラップトップコンピュータ、タブレットＰＣ、携帯情報端末（ＰＤＡ）、家庭用デバイスなどを含む様々な形態をとっている。その最も基本的な形態において、コンピューティングシステムは、システムメモリおよび１つまたは複数のプロセッサを含む。システムメモリ中のソフトウェアは、プロセッサによって実行されて、コンピューティングシステムの他のハードウェアに所望のファンクションを実行するように指示することができる。

ソフトウェアは、一般に、「オペレーティングシステム」ソフトウェアと「アプリケーション」ソフトウェアに分けられる。コンピューティングシステムがオペレーティングシステムを有することは絶対的に必要なものではないが、オペレーティングシステムは、汎用コンピューティングシステムにおいて役立つ。というのは、オペレーティングシステムは、コンピューティングハードウェアを管理および制御し、ファイル管理、スレッドスケジューリング、マルチタスキングなどの一般化されたシステムタスクを行うからである。アプリケーションソフトウェアは、より専門化されたタスクを行うことができ、必要なときに、オペレーティングシステムによって提供されるシステムレベルファンクションをコールすることができる。オペレーティングシステムの存在は、アプリケーション開発をはるかに能率的なものにする。というのは、基本的な機能を、アプリケーションごとに再開発する必要がなくなるからである。

オペレーティングシステムは、アプリケーションソフトウェアに対して多くのコアファンクションを利用可能にする。アプリケーションデベロッパは、アプリケーションプログラミングインターフェース（ＡＰＩ）に準拠するソースコードを起草することによって、アプリケーションソフトウェアに、オペレーティングシステムによって公開されたファンクションをコールさせることができる。ランタイム中には、アプリケーションプログラムは、そのソースコードからコンパイルされたプロセッサレベルの命令を実行するときに、オペレーティングシステムをコールする。したがって、アプリケーションソフトウェアは、個々のＡＰＩファンクションをコールすることによってリソースを要求する。ＡＰＩファンクションは、オペレーティングシステムがアプリケーションソフトウェアに任意の関連する情報を提供できる手段としても働く。用語ＡＰＩは、オペレーティングシステムへの単一のファンクションコールならびにオペレーティングシステムへの可能なファンクションコールの集合を指すのに使用される。さらに、用語ＡＰＩは、ファンクションコールのソースコード表現ならびにファンクションコールのインメモリ表現の両方に適用される。

過去数年にわたって、インターネットの全地球的な採用およびネットワーキング技術全般が、コンピュータソフトウェアデベロッパのランドスケープを変化させてきた。伝統的に、ソフトウェアデベロッパは、スタンドアローンのデスクトップコンピュータ用またはローカルエリアネットワーク（ＬＡＮ）を介して限られた数の他のコンピュータに接続されたＬＡＮベースのコンピュータ用の単一サイトのソフトウェアアプリケーションにフォーカスしてきた。これらのアプリケーションは、明確に定義されたＡＰＩを利用して、コンピュータの基礎となるオペレーティングシステムにアクセスした。

インターネットが進歩し、広く受け入れられるようになるにつれて、産業界は、ワールドワイドウェブ（または単に「Ｗｅｂ」）上の様々なサイトでアプリケーションをホスティングすることの威力を認識し始めた。ネットワーク化された世界では、あらゆる所からのクライアントが、様々なロケーションでホストされるサーバベースのアプリケーションに要求をサブミットし、数分の１秒で応答を受け取ることができる。しかし、これらのＷｅｂアプリケーションは、通常は、スタンドアローンコンピューティングマシンまたはローカルにネットワーク化されたコンピュータのために元々開発された同じオペレーティングシステムプラットフォームを使用して開発されたものであった。残念ながら、いくつかの場合には、これらのアプリケーションは、分散コンピューティング体制（ｄｉｓｔｒｉｂｕｔｅｄ ｃｏｍｐｕｔｉｎｇ ｒｅｇｉｍｅ）に十分に移行しない。基礎になるプラットフォームは、単に、限られた数の相互接続されたコンピュータをサポートするという発想で構成されていなかった。

インターネットによって先導される分散コンピューティングン環境へのシフトに対処するために、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ社は、「．ＮＥＴ」Ｆｒａｍｅｗｏｒｋ（「ドットネット」と読む）またはＭｉｃｒｏｓｏｆｔ（登録商標）．ＮＥＴとして知られているソフトウェアプラットフォームを開発した。Ｍｉｃｒｏｓｏｆｔ（登録商標）．ＮＥＴは、人々、情報、システム、およびデバイスを接続するためのソフトウェアである。このプラットフォームは、デベロッパが、インターネットを介して実行することになるＷｅｂサービスを作成できるようにする。このダイナミックなシフトには、．ＮＥＴ ＦｒａｍｅｗｏｒｋのＡＰＩファンクションのセットが伴っていた。

．ＮＥＴ Ｆｒａｍｅｗｏｒｋの使用が、ますます一般的になるにつれて、このプラットフォームの効率および／またはパフォーマンスを高める方法が識別されてきた。本発明者は、ＡＰＩファンクションのユニークなセットを開発して、そのような高められた効率および／またはパフォーマンスを可能にした。

本発明の原理は、ウェブサービス名前空間を用いて．ＮＥＴフレームワークとインターフェースするときに高められた効率およびパフォーマンスを可能にするＡＰＩファンクションのユニークなセットを対象とする。ウェブサービス名前空間は、様々なアプリケーションの作成を可能にするインフラストラクチャに関し、用語「ウェブ」は、ウェブサービス名前空間を用いるアプリケーションをインターネットアプリケーションに使用されるものに限定するか、いかなる形でも制限することを意図したものではない。このインフラストラクチャは、様々なスケールおよび複雑さのメッセージベースのアプリケーションを構築するための基礎を提供する。このインフラストラクチャまたはフレームワークは、基本的なメッセージング、セキュアなメッセージング、信頼性のあるメッセージング、およびトランザクション式メッセージング（ｔｒａｎｓａｃｔｅｄ ｍｅｓｓａｇｉｎｇ）のためのＡＰＩを提供する。いくつかの実施形態では、関連付けられたＡＰＩが、ユーティリティ、ユーザビリティ、拡張性、およびバージョン性（ｖｅｒｓｉｏｎａｂｉｌｉｔｙ）をバランスする仕方で名前空間の階層にファクタ化される。

本発明の追加の特徴および利点は、次の説明に示され、部分的にこの説明から明白になり、あるいは本発明の実践によって習得することができる。本発明の特徴および利点は、添付の特許請求の範囲で特に指摘される手段および組合せによって実現し、得ることができる。本発明のこれらおよび他の特徴は、次の説明および添付の特許請求の範囲から完全に明白になり、あるいは、後に示す本発明の実践によって習得することができる。

本発明の上記および他の利点および特徴を得ることができる形を説明するために、上記で手短に説明した本発明のより詳しい説明を、添付図面に示された具体的な実施形態を参照して提示するが、添付図面では、同様の符号が同様の要素を指す。これらの図面が、本発明の典型的な実施形態を示すのみであり、それゆえその範囲を制限するものと考えてはならないことを理解しつつ、本発明について、添付図面の使用を通じてさらに具体性と詳細と共に記述し、説明することにする。

本発明の原理は、ウェブサービス名前空間を用いて．ＮＥＴフレームワークとインターフェースするときに高められた効率およびパフォーマンスを可能にするアプリケーションプログラミングインターフェース（ＡＰＩ）ファンクションのユニークなセットに関する。ウェブサービス名前空間は、様々なアプリケーションの作成を可能にするためのインフラストラクチャに関する。このインフラストラクチャは、様々なスケールおよび複雑さのメッセージベースのアプリケーションを構築するための基礎を提供する。インフラストラクチャまたはフレームワークは、基本的なメッセージング、セキュアなメッセージング、信頼性のあるメッセージング、およびトランザクション式メッセージングのためのＡＰＩを提供する。いくつかの実施形態では、関連付けられたＡＰＩが、ユーティリティ、ユーザビリティ、拡張性、およびバージョン性をバランスする仕方で名前空間の階層にファクタ化される。

記載の実装形態では、ネットワークプラットフォームが、データを記述するためのオープンな標準規格であるＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を利用する。ＸＭＬは、Ｗ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）によって管理されている。ＸＭＬは、Ｗｅｂページ上およびビジネス−ビジネス（企業間取引）文書上のデータ要素を定義するのに使用される。ＸＭＬは、ＨＴＭＬに似たタグ構造を使用しているが、ＨＴＭＬは要素がどのように表示されるかを定義するのに対して、ＸＭＬはこれらの要素が何を含むかを定義する。ＨＴＭＬは、事前定義されたタグを使用するが、ＸＭＬは、タグが文書のデベロッパによって定義されることを可能にする。このように、事実上いかなるデータアイテムも識別することができ、ＸＭＬ文書がデータベースレコードのように機能できるようにする。ＸＭＬ、およびＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）などの他のオープンなプロトコルの使用を通じて、このプラットフォームは、ユーザのニーズに合わせて調整できる広範囲のサービスの統合を可能にする。本明細書で説明する実施形態は、ＸＭＬおよび他のオープンな標準規格に関連して説明されるが、これは、特許請求される発明の動作には必須ではない。他の同等に実行可能な技術が、本明細書に記載された発明を実施するのに十分であろう。

本明細書で使用されるように語句アプリケーションプログラムインターフェースまたはＡＰＩには、メソッドまたはファンクションコールを用いる伝統的なインターフェースならびにリモートコール（例えば、プロキシ、スタブ関係）およびＳＯＡＰ／ＸＭＬ呼び出しが含まれる。

（例示的なネットワーク環境）
図１に、．ＮＥＴ Ｆｒａｍｅｗｏｒｋなどのネットワークプラットフォームを実施できるネットワーク環境１００を示す。ネットワーク環境１００は、代表となるＷｅｂサービス１０２（１）、．．．、１０２（Ｎ）を含み、これらは、ネットワーク１０４（例えば、インターネット）を介してまたはプロセス間通信を用いてアクセスできるサービスを提供する。Ｗｅｂサービスは、符号１０２として包括的に参照されるが、再利用可能であり、通常は、ＸＭＬ、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）、ＷＡＰ（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、およびＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などの産業標準Ｗｅｂプロトコルを介してネットワーク１０４を介してプログラム的に対話するプログラム可能なアプリケーションコンポーネントであるが、リモートプロシージャコール（ＲＰＣ）またはオブジェクトブローカタイプの技術など、ネットワークを介してＷｅｂサービスと対話する他の手段を使用することもできる。Ｗｅｂサービスは、自己記述的とすることができ、しばしば、メッセージのフォーマットおよび順序付けに関して定義される。

Ｗｅｂサービス１０２は、他のサービスによって直接に（通信リンク１０６によって表されるように）または、Ｗｅｂアプリケーション１１０などのソフトウェアアプリケーションによって（通信リンク１１２および１１４によって表されるように）アクセス可能である。各Ｗｅｂサービス１０２は、特定のサービスに対する要求を処理するためにソフトウェアを実行する１つまたは複数のサーバを含むものとして図示されている。Ｗｅｂサービスは、様々な異なるサービスのうちの任意の１つを実行するように構成することができる。Ｗｅｂサービスの例には、ログイン検証、通知、データベースストレージ、株価情報（ｓｔｏｃｋ ｑｕｏｔｉｎｇ）提供、ロケーションディレクトリ、マッピング、音楽、電子ウォレット、カレンダ／スケジューラ、電話表、ニュースおよび情報、ゲーム、チケット購入などが含まれる。Ｗｅｂサービスは、互いにそして他のアプリケーションと組み合わせて、可変の複雑なシステムおよびインテリジェントなインタラクティブ体験を構築することができる。

ネットワーク環境１００は、Ｗｅｂサービス１０２（通信リンク１２２によって表される）および／またはＷｅｂアプリケーション１１０（通信リンク１２４、１２６、および１２８によって表される）を利用する、代表となるクライアントデバイス１２０（１）、１２０（２）、１２０（３）、１２０（４）、．．．、１２０（Ｍ）も含んでいる。クライアントは、クライアント１２０（３）と１２０（４）の間の例示的なＸＭＬリンク１３０によって表されているように、標準的なプロトコルを用いて互いに通信することもできる。

クライアントデバイスは、符合１２０によって包括的に参照されるが、多くの異なる方法で実装することができる。可能なクライアント実装の例には、限定なしに、ポータブルコンピュータ、ステーショナリコンピュータ、タブレットＰＣ、テレビジョン／セットトップボックス、ワイヤレス通信デバイス、携帯情報端末、ゲーム機、プリンタ、写真複写機、および他のスマートデバイスが含まれる。

Ｗｅｂ Ｓｅｒｖｉｃｅアプリケーション１１０は、ネットワークプラットフォーム上で稼働するように設計されたアプリケーションであり、クライアント１２０からの要求を処理し、サービスするときにＷｅｂ Ｓｅｒｖｉｃｅサービス１０２を利用することができる。Ｗｅｂ Ｓｅｒｖｉｃｅアプリケーション１１０は、プログラミングフレームワーク１３２の上で稼働する１つまたは複数のソフトウェアアプリケーション１３０から構成され、プログラミングフレームワーク１３２は、１つまたは複数のサーバ１３４上または他のコンピュータシステム上で実行されている。Ｗｅｂ Ｓｅｒｖｉｃｅアプリケーション１１０の一部が、実際に１つまたは複数のコンピュータ１２０に常駐できることに留意されたい。あるいは、Ｗｅｂ Ｓｅｒｖｉｃｅアプリケーション１１０が、クライアント１２０上または他のコンピュータ上の他のソフトウェアと協調して、そのタスクを達成することができる。

プログラミングフレームワーク１３２は、アプリケーションデベロッパによって開発されたアプリケーションおよびサービスをサポートする構造である。これは、複数のプログラミング言語をサポートすることによって、マルチランゲージ開発およびシームレスな統合を可能にする。これは、ＳＯＡＰなどのオープンなプロトコルをサポートし、基礎となるオペレーティングシステムおよびオブジェクトモデルサービスをカプセル化する。このフレームワークは、複数のプログラミング言語の堅牢でセキュアな実行環境を提供し、セキュアで統合されたクラスライブラリを提供する。

フレームワーク１３２は、ＡＰＩレイヤ１４２、ＣＬＲ（ｃｏｍｍｏｎ ｌａｎｇｕａｇｅ ｒｕｎｔｉｍｅ）レイヤ１４４、およびオペレーティングシステム／サービスレイヤ１４６を含む多層状のアーキテクチャである。この層化されたアーキテクチャは、このフレームワークの他の部分に影響することなく、様々なレイヤに対するアップデートおよび変更を可能にする。共通言語仕様（ＣＬＳ）１４０は、様々な言語のデザイナが、基礎となるライブラリ機能にアクセスできるコードを書けるようにする。この仕様１４０は、言語の相互運用性を促進するのに使用できる、言語デザイナとライブラリデザイナの間の契約として機能する。ＣＬＳに固執することによって、ある言語で書かれたライブラリが他の言語で書かれたコードモジュールに直接にアクセス可能にして、ある言語で書かれたコードモジュールと別の言語で書かれたコードモジュールの間のシームレスな統合を達成することができる。ＣＬＳの１つの例示的な詳細な実装形態が、ＥＣＭＡ ＴＣ３９／ＴＧ３の参加者によって作成されたＥＣＭＡ標準に記載されている。

ＡＰＩレイヤ１４２は、アプリケーション１３０が、レイヤ１４６によって提供されるリソースおよびサービスにアクセスするためにコールすることができるファンクションのグループを提示する。ネットワークプラットフォームのためのＡＰＩファンクションを公開することによって、アプリケーションデベロッパは、ローカルおよびネットワークリソースと他のＷｅｂ Ｓｅｒｖｉｃｅサービスとを完全に利用させる分散コンピューティングシステムのためのＷｅｂ Ｓｅｒｖｉｃｅアプリケーションを、これらのネットワークリソースが実際にどのように動作するかまたはどのように利用可能にされるかの複雑な相互作用を理解する必要なく、作成することができる。さらに、Ｗｅｂ Ｓｅｒｖｉｃｅアプリケーションは、任意の数のプログラミング言語で書くことができ、共通言語ランタイム１４４によってサポートされる中間言語に変換でき、共通言語仕様１４０の一部として含めることができる。このようなにして、ＡＰＩレイヤ１４２は、広範で多様なアプリケーションのためのメソッドを提供することができる。

さらに、フレームワーク１３２は、このフレームワークをホストするサーバ１３４からリモートに実行されるリモートアプリケーションによって行われたＡＰＩコールをサポートするように構成することができる。クライアント１２０（３）および１２０（Ｍ）にそれぞれ存在する代表としてのアプリケーション１４８（１）および１４８（２）は、ネットワーク１０４を介してＡＰＩレイヤ１４２に直接にまたは間接にコールを行うことによって、ＡＰＩファンクションを使用することができる。

このフレームワークは、クライアントで実装することもできる。クライアント１２０（３）は、フレームワーク１５０がクライアントで実装される状況を表している。このフレームワークは、サーバベースのフレームワーク１３２と同一であっても、クライアントのために変更されてもよい。あるいは、クライアントが、セルラー電話、携帯情報端末、ハンドヘルドコンピュータ、または他の通信／コンピューティングデバイスなど、機能を限定され、または専用化された機能のデバイスである場合に、クライアントベースのフレームワークは要約することができる。

（デベロッパのプログラミングフレームワーク）
図２に、プログラミングフレームワーク１３２をさらに詳細に示す。共通言語仕様（ＣＬＳ）レイヤ１４０は、様々な言語１３０（１）、１３０（２）、１３０（３）、１３０（４）、．．．、１３０（Ｋ）で書かれたアプリケーションをサポートする。このようなアプリケーション言語には、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｃ＋＋、Ｃ＃、ＣＯＢＯＬ、Ｊｓｃｒｉｐｔ、Ｐｅｒｌ、Ｅｉｆｆｅｌ、Ｐｙｔｈｏｎなどが含まれる。共通言語仕様１４０は、それに従う場合に様々な言語が通信できるようにする機能のサブセットまたは機能に関するルールのサブセットを指定する。例えば、一部の言語は、そうでなければ共通言語ランタイム１４４によってサポートされ得るある所与の型（例えば、「ｉｎｔ＊」型）をサポートしない。この場合に、共通言語仕様１４０は、その型を含まない。他方、すべてまたはほとんどの言語によってサポートされる型（例えば、「ｉｎｔ［］」型）は、共通言語仕様１４０に含まれ、そのため、ライブラリデベロッパはそれを自由に使用することができ、それらの言語が処理できることが確実となる。

この通信する能力は、ある言語で書かれたコードモジュールと別の言語で書かれたコードモジュールの間のシームレスな統合をもたらす。異なる言語は、特定のタスクに特によく適するので、言語間のシームレスな統合によって、デベロッパは、異なる言語で書かれたモジュールと共に特定のコードモジュールを使用する能力と共に、そのコードモジュールのために特定の言語を選択できるようになる。共通言語ランタイム１４４は、言語間継承と共に、シームレスなマルチ言語開発を可能にし、複数プログラミング言語に対する堅牢でセキュアな実行環境を提供する。共通言語仕様１４０および共通言語ランタイム１４４に関するさらなる情報について、読者には、参照によって組み込まれる同時係属中の「Method and System for Compiling Multiple Languages」と題され、２０００年６月２１日に出願された特許出願（米国特許出願番号第０９／５９８，１０５号）および「Unified Data Type System and Method」と題され、２０００年７月１０日に出願された特許出願（米国特許出願番号第０９／６１３，２８９号）を示す。

フレームワーク１３２は、オペレーティングシステム１４６（１）（例えば、Ｗｉｎｄｏｗｓ（登録商標）ブランドのオペレーティングシステム）およびオブジェクトモデルサービス１４６（２）（例えば、ＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）または分散ＣＯＭ）をカプセル化する。オペレーティングシステム１４６（１）は、ファイル管理、通知、イベント処理、ユーザインターフェース（例えば、ウィンドウイング、メニュー、ダイアログなど）、セキュリティ、認証、検証、プロセスおよびスレッド、メモリ管理などの通常の機能を提供する。オブジェクトモデルサービス１４６（２）は、他のオブジェクトとのインターフェーシングを提供して、様々なタスクを行う。ＡＰＩレイヤ１４２に対して行われるコールは、オペレーティングシステム１４６（１）および／またはオブジェクトモデルサービス１４６（２）によるローカル実行のための共通言語ランタイムレイヤ１４４に渡される。

ＡＰＩ１４２は、ＡＰＩファンクションを複数の名前空間にグループ化する。名前空間は、基本的に、クラス、インターフェース、委譲、列挙、および構造体のコレクションを定義し、これらは、集合的に「型」と呼ばれ、これは、関連する機能の特定のセットを提供する。クラスは、参照割り当てセマンティクスを有する、管理されたヒープを割り振られたデータを表す。委譲は、オブジェクト指向のタイプセーフなファンクションポインタである。列挙は、名前付き定数によって表されるいくつかの事前定義された値の１つをとることができる、特別な種類の値型である。構造体は、値割り当てセマンティクスを有する静的に割り振られたデータを表す。インターフェースは、他の型が実装できる契約を定義する。

名前空間を使用することによって、デザイナは、型のセットを階層的な名前空間に編成することができる。デザイナは、型のセットから複数のグループを作成することができ、各グループは、論理的に関連する機能を公開する、少なくとも１つの型を含む。例示的実装では、ＡＰＩ１４２は、３つのルート名前空間を含むように編成される。図２に３つのルート名前空間だけが示されているが、追加のルート名前空間をＡＰＩ１４２に含めることもできることに留意されたい。ＡＰＩ１４２に示された３つのルート名前空間は、プレゼンテーションサブシステムのための第１名前空間２００（ユーザインターフェースシェル用の名前空間２０２を含む）、ウェブサービスのための第２名前空間２０４、およびファイルシステムのための第３名前空間２０６である。それで各グループに名前を割り当てることができる。例えば、プレゼンテーションサブシステム名前空間２００中の型に、名前「Ｗｉｎｄｏｗｓ」を割り当てることができ、ファイルシステム名前空間２０６中の型に、名前「Ｓｔｏｒａｇｅ」を割り当てることができる。名前を付けられたグループは、全体的なＳｙｓｔｅｍ名前空間など、システムレベルＡＰＩのための単一の「グローバルルート」名前空間の下で編成することができる。

トップレベル識別子を選択し、プレフィックスすることによって、各グループ中の型を、その型を含むグループの名前にプレフィックスされたその選択されたトップレベル識別子を含む階層名によって簡単に参照することができる。例えば、ファイルシステム名前空間２０６の型は、階層名「Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ」を用いて参照することができる。このようにして、個々の名前空間２００、２０４、および２０６が、Ｓｙｓｔｅｍ名前空間からの主要な枝になり、個々の名前空間が、「Ｓｙｓｔｅｍ．」プレフィックスなど、指定子によってプレフィックスされている指定を担うことができる。

プレゼンテーションサブシステム名前空間２００は、プログラミングおよびコンテンツ開発に関係する。これは、アプリケーション、文書、メディアプレゼンテーション、および他のコンテンツの生成を可能にする型を供給する。例えば、プレゼンテーションサブシステム名前空間２００は、デベロッパがオペレーティングシステム１４６（１）および／またはオブジェクトモデルサービス１４６（２）からサービスを得られるようにするプログラミングモデルを提供する。シェル名前空間２０２は、ユーザインターフェース機能に関係する。これは、デベロッパがそのアプリケーションにユーザインターフェース機能を組み込めるようにし、さらに、デベロッパがユーザインターフェース機能を拡張できるようにする。

ウェブサービス名前空間２０４は、例えばイントラネット上の２つのピアの間で動作するチャットアプリケーションのように単純なアプリケーションそして／または数百万のユーザのためのスケーラブルなＷｅｂサービスのように複雑なアプリケーションなど、様々なアプリケーションの作成を可能にするインフラストラクチャに関係する。記載のインフラストラクチャは、ある特定のソリューションの複雑さに相応しい部分だけを使用する必要があるという点で、有利なことに非常に可変である。このインフラストラクチャは、様々なスケールおよび複雑さのメッセージベースのアプリケーションを構築するための基礎を提供する。このインフラストラクチャまたはフレームワークは、基本的なメッセージング、セキュアなメッセージング、信頼性のあるメッセージング、およびトランザクション式メッセージングのためのＡＰＩを提供する。下記で説明する実施形態では、関連付けられたＡＰＩが、ユーティリティ、ユーザビリティ、拡張性、およびバージョン性をバランスするように入念にクラフトされた形で名前空間の階層にファクタ化されている。

ファイルシステム名前空間２０６は、ストレージに関係する。これは、情報のストレージおよび取り出しを可能にする型を供給する。

フレームワーク１３２の他に、プログラミングツール２１０を提供して、デベロッパがＷｅｂ Ｓｅｒｖｉｃｅおよび／またはアプリケーションを構築するのを助ける。プログラミングツール２１０の１つの例が、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ社によって提供されるプログラミングツールのマルチ言語スイートであるＶｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）である。

（ルート名前空間）
図３に、ＡＰＩ１４２と、そのルート名前空間の１つすなわちウェブサービス２０４を詳細に示す。一実施形態において、名前空間は、名前のストリングがピリオドで連結される階層命名規約（ｈｉｅｒａｃｈｉｃａｌ ｎａｍｉｎｇ ｃｏｎｖｅｎｔｉｏｎ）に従って識別される。この命名規約を念頭において、以下では、ＡＰＩ１４２の選択された名前空間の全般的な概要を提供するが、他の命名規約を、同等の効果と共に使用することができよう。

ウェブサービス名前空間２０４は、ルート名「Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ」によって識別される。「Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ」名前空間内には、次のサブ名前空間がある。

・ チャネル（すなわち「Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｃｈａｎｎｅｌｓ」）、
・ コンフィギュレーション（すなわち「Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｃｏｎｆｉｇｕｒａｔｉｏｎ」）、
・ 設計（すなわち「Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｄｅｓｉｇｎ」）、
・ 診断（すなわち「Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｄｉａｇｎｏｓｔｉｃｓ」）、および
・ セキュリティ（すなわち「Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｓｅｃｕｒｉｔｙ」）
さらに、「Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｓｅｃｕｒｉｔｙ」名前空間内には、次のサブ名前空間がある。

・ プロトコル（すなわち「Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｓｅｃｕｒｉｔｙ．Ｐｒｏｔｏｃｏｌｓ」）
さらに、メッセージングの外のユーティリティを有し、それ以外の機能をサポートする追加の名前空間がある。これには、「Ｓｙｓｔｅｍ．Ｓｅｃｕｒｉｔｙ．Ａｕｔｈｏｒｉｚａｔｉｏｎ」、「Ｓｙｓｔｅｍ．Ｒｕｎｔｉｍｅ．Ｓｅｒｉａｌｉｚａｔｉｏｎ」、「Ｓｙｓｔｅｍ．Ｔｒａｎｓａｃｔｉｏｎｓ」、「Ｓｙｓｔｅｍ．ＩＯ．Ｌｏｇ」、「Ｓｙｓｔｅｍ．Ｔｅｘｔ」、および「Ｓｙｓｔｅｍ．ＸＭＬ」が含まれる。

これらの示された名前空間のそれぞれおよびそれらに対応するコアクラスを、これからさらに詳細に説明することにする。

（Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ）
Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌは、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌのすべてをカプセル化するルート名前空間である。具体的には、この名前空間は、Ｗｅｂ Ｓｅｒｖｉｃｅメッセージを使用する分散されたメッセージ受け渡しアプリケーションを書くのに利用されるＡＰＩを表す。ＡＰＩのこのセットが一緒にグループ化されているのは、これが、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌの論理的なコアレイヤを表し、他のＳｅｒｖｉｃｅ Ｍｏｄｅｌ名前空間を使用せずにこれらのＡＰＩだけを使用してアプリケーションを書くことが可能であるからである。この名前空間のコアクラスには、次のものが含まれる。

・ ＢａｓｉｃＰｒｏｆｉｌｅＨｔｔｐＢｉｎｄｉｎｇ − 組み込みＷＳ−Ｉ ＢＰ １．１バインディング。

・ ＢａｓｉｃＰｒｏｆｉｌｅＨｔｔｐｓＢｉｎｄｉｎｇ − ＨＴＴＰＳを介した組み込みＷＳ−Ｉ ＢＰ １．１バインディング。

・ ＣｈａｎｎｅｌＦａｃｔｏｒｙ＜Ｔ＞ − クライアントサイドのランタイムを作成するのに使用される。

・ ＣｏｎｔｒａｃｔＤｅｓｃｒｉｐｔｉｏｎ − サービス契約を記述する。それぞれにＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｉｏｎｓのコレクションが入ったＯｐｅｒａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎｓのコレクションを含む。

・ ＥｎｄｐｏｉｎｔＡｄｄｒｅｓｓ − ＥｎｄｐｏｉｎｔＡｄｄｒｅｓｓ（およびそれに含まれるクラスＡｄｄｒｅｓｓＰｒｏｐｅｒｔｉｅｓ）は、Ｗｅｂ Ｓｅｒｖｉｃｅのアドレスの定義を表す。これには、サービスのＳＯＡＰアドレス（ＡｃｔｉｎｇＡｓ）、そのトランスポートアドレス（Ａｄｄｒｅｓｓ）、メタデータ寄与ヘッダ（ＥｎｄｐｏｉｎｔＨｅａｄｅｒｓ）、メタデータ不可知論ヘッダ（ＩｎｓｔａｎｃｅＨｅａｄｅｒｓ）、セキュリティアイデンティティ（Ｉｄｅｎｔｉｔｙ）、ならびにそのエンドポイントで実装されるバインディングおよび契約に関する情報を含む、サービスのアドレスに関するいくつかの態様が含まれる。

・ ＩＣｈａｎｎｅｌＦａｃｔｏｒｙ − ＩＣｈａｎｎｅｌＦａｃｔｏｒｙインターフェースは、チャネルをアクティブに作成するための基本インターフェースを表す。これは、その上に２セットのメソッド、すなわち特定の型のＩＣｈａｎｎｅｌがサポートされているかどうかをユーザが問い合わせられるＣａｎＣｒｅａｔｅＣｈａｎｎｅｌ＜Ｔ＞（）およびユーザが指定エンドポイントへの特定の型のＩＣｈａｎｎｅｌを作成できるようにするＣｒｅａｔｅＣｈａｎｎｅｌ＜Ｔ＞（．．．）を有する。

・ ＩＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ − ＩＬｉｓｔｅｎｅｒＦａｃｔｏｒｙインターフェースは、ネットワークアドレスで聴取し、ＩＬｉｓｔｅｎｅｒｓを作成するための基本インターフェースを表す。これは、機能の型、すなわちネットワークアドレスを構成する仕方（ＬｉｓｔｅｎＵｒｉ、ＳｅｔＬｉｓｔｅｎＵｒｉ、ＳｅｔＵｎｉｑｕｅＬｉｓｔｅｎＵｒｉ）およびＩＬｉｓｔｅｎｅｒｓを作成する仕方（ＣｒｅａｔｅＬｉｓｔｅｎｅｒ＜Ｔ＞（．．．）、ＣａｎＣｒｅａｔｅＬｉｓｔｅｎｅｒ＜Ｔ＞（））を公開する。

ＩＬｉｓｔｅｎｅｒｓは、一般に、Ｍｅｓｓａｇｅフィルタ中に渡すことによってＩＬｉｓｔｅｎｅｒＦａｃｔｏｒｉｅｓ上で作成される。Ｌｉｓｔｅｎｅｒ Ｆａｃｔｏｒｙで受け取られるメッセージおよびＬｉｓｔｅｎｅｒのフィルタにマッチするメッセージは、そのＬｉｓｔｅｎｅｒに配送される。これを、ＴＣＰ／ＩＰが働く仕方、すなわちコンピュータ（Ｌｉｓｔｅｎｅｒ Ｆａｃｔｏｒｙ）が特定のＩＰアドレスを聴取することに類推することができる。ソケットは、特定のＴＣＰポート（Ｆｉｌｔｅｒ）にバインドする。特定のＩＰアドレスに到着したパケットは、特定のＬｉｓｔｅｎｅｒ Ｆａｃｔｏｒｙに到着したＭｅｓｓａｇｅがＦｉｌｔｅｒに基づいてＬｉｓｔｅｎｅｒにデマルチプレックスされる仕方と同様に、ポート番号に基づいてソケットにデマルチプレックスされる。

ＩＬｉｓｔｅｎｅｒＦａｃｔｏｒｉｅｓは、一般に、通信パターンのアクセプタによって使用される。チャネルがどのようにアクティブに作成されるかの詳細については、ＩＣｈａｎｎｅｌＦａｃｔｏｒｙを参照されたい。

・ ＩｎｔｅｒｍｅｄｉａｒｙＨｔｔｐＢｉｎｄｉｎｇ − 中間ＨＴＴＰバインディング。

・ ＩｎｔｅｒｍｅｄｉａｒｙＴｃｐＢｉｎｄｉｎｇ − 中間ＴＣＰバインディング。

・ Ｍｅｓｓａｇｅ − Ｍｅｓｓａｇｅは、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌ中のアプリケーション間の通信の基礎単位である。これは、Ｗｅｂ Ｓｅｒｖｉｃｅｓ間のすべてのデータ交換がカプセル化されるコンテナである。これは、ＩＰパケットのＳｅｒｖｉｃｅ Ｍｏｄｅｌ等価物である。メッセージの構造は、ＳＯＡＰエンベロープのそれとゆるやかに対応する。メッセージは、メッセージヘッダのセットと本体の両方を含み、これらは、それぞれＳＯＡＰ ＨｅａｄｅｒブロックおよびＳＯＡＰ Ｂｏｄｙに対応する。メッセージに含めることのできるヘッダのセットは、拡張可能である。いくつかのデフォルトヘッダ型、具体的にはメッセージアドレッシングおよびメッセージ満了に関係するものが定義され、指定される。その他は、他のＳｅｒｖｉｃｅ Ｍｏｄｅｌコンポーネントによってそして／またはサードパーティデベロッパによって定義される。

・ ＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｉｏｎ − サービスメッセージを記述する。

・ ＭｓｍｑｓＢｉｎｄｉｎｇ − ＭＳＭＱ統合バインディング。

・ ＮｅｔＭｓｍｑＢｉｎｄｉｎｇ − ＭＳＭＱバインディング。

・ ＮｅｔＭｓｍｑｓＢｉｎｄｉｎｇ − セキュアＭＳＭＱバインディング。

・ ＮｅｔＮａｍｅｄＰｉｐｅＢｉｎｄｉｎｇ − 名前付きパイプバインディング。

・ ＮｅｔＴｃｐＢｉｎｄｉｎｇ − 非インターオペラブルＴＣＰバインディング。

・ ＮｅｔＴｃｐｓＢｉｎｄｉｎｇ − 非インターオペラブルＴＣＰＳバインディング。

・ ＯｐｅｒａｔｉｏｎＡｔｔｒｉｂｕｔｅ − ．ＮＥＴ Ｆｒａｍｅｗｏｒｋ Ａｔｔｒｉｂｕｔｅモデルに従って使用されるときに、この属性は、サービス契約の一部としてメソッドをマークし、デベロッパがオペレーションの態様を構成できるようにする。

・ ＯｐｅｒａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ − サービスオペレーションを記述する。ＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｉｏｎｓのコレクションを含む。

・ ＳｅｃｕｒｉｔｙＢｉｎｄｉｎｇＥｌｅｍｅｎｔ − このクラスおよびその関連するクラス（ＳＯＡＰＡｕｔｈｅｎｔｉｃａｔｉｏｎＭｏｄｅ、ＳｅｃｕｒｉｔｙＣｏｎｔｅｘｔＭｏｄｅ、ＣｈａｎｎｅｌＳｅｃｕｒｉｔｙＣｒｅｄｅｎｔｉａｌｓ、ＳｅｒｖｉｃｅＳｅｃｕｒｉｔｙＣｒｅｄｅｎｔｉａｌｓ、ＣｈａｎｎｅｌＳｅｃｕｒｉｔｙＢｅｈａｖｉｏｒｓ、ＳｅｒｖｉｃｅＳｅｃｕｒｉｔｙＢｅｈａｖｉｏｒｓ）は、チャネルスタック中のＳＯＡＰセキュリティを構成するためのフレームワークを提供する。つまり、これらは、メッセージに適用されるセキュリティのタイプを判定する。

・ ＳｅｒｖｉｃｅＣｏｎｔｒａｃｔＡｔｔｒｉｂｕｔｅ − ．ＮＥＴ Ｆｒａｍｅｗｏｒｋ Ａｔｔｒｉｂｕｔｅモデルに従って使用されるときに、この属性は、サービス契約としてインターフェースをマークし、デベロッパがその契約の態様を構成させる。

・ ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎ − 適したランタイム環境の作成、メタデータの生成、およびコードまたはコンフィギュレーション情報を含む様々な目的に使用することのできる、サービスのランタイム要件のインメモリ表現。

・ ＳｅｒｖｉｃｅＥｎｄｐｏｉｎｔ − 世界と通信するためのポータルを表し、エンドポイントアドレス、契約、およびバインディングを含む。

・ ＳｅｒｖｉｃｅＨｏｓｔ＜Ｔ＞ − 通信能力を有する特定のサービスタイプを提供するランタイムのためのコンテナ。

・ ＷｓＨｔｔｐＢｉｎｄｉｎｇ − ＨＴＴＰを介したインターオペラブルＷＳ（非ＢＰ）バインディング。

・ ＷｓＨｔｔｐｓＢｉｎｄｉｎｇ − ＨＴＴＰＳを介したインターオペラブルＷＳ（非ＢＰ）バインディング。

（Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｃｈａｎｎｅｌｓ）
Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｃｈａｎｎｅｌｓは、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌトランスポート、信頼性、ならびにＣｈａｎｎｅｌ ＦａｃｔｏｒｉｅｓおよびＬｉｓｔｅｎｅｒ Ｆａｃｔｏｒｉｅｓのキューイングのためのメイン名前空間である。これらのクラスは、Ｗｅｂ Ｓｅｒｖｉｃｅｓ通信サブシステムの具体的な実装を表す。ＡＰＩのこのセットは、ＳＯＡＰメッセージに作用する通信ＡＰＩの論理的で総合的なレイヤを表すので一緒にグループ化される。この名前空間のコアクラスには、次のものが含まれる。

・ ＢｉｎａｒｙＭｅｓｓａｇｅＥｎｃｏｄｅｒ − ＢｉｎａｒｙＭｅｓｓａｇｅＥｎｃｏｄｅｒは、ＭｅｓｓａｇｅオブジェクトをＭｅｓｓａｇｅの．ＮＥＴ−ＢｉｎａｒｙＦｏｒｍａｔエンコーディングを使用して一連のオクテットに変換またはその逆を行うための抽象化を表す。これは、ＳｔｒｅａｍまたはＡｒｒａｙＳｅｇｍｅｎｔ＜ｂｙｔｅ＞をとり、Ｍｅｓｓａｇｅオブジェクトのインスタンスを返すためのメソッド、およびＭｅｓｓａｇｅを取り、そのＭｅｓｓａｇｅをＳｔｒｅａｍまたはＡｒｒａｙＳｅｇｍｅｎｔ＜ｂｙｔｅ＞に書くためのメソッドを定義する。

・ ＨｔｔｐＣｈａｎｎｅｌＦａｃｔｏｒｙ − ＨｔｔｐＣｈａｎｎｅｌＦａｃｔｏｒｙクラスは、ＨＴＴＰチャネルをアクティブに作成するための基本クラスを表す。ＨＴＴＰチャネルは、ＳＯＡＰ−ｏｖｅｒ−ＨＴＴＰプロトコルを使用してサービスにメッセージを送り、おそらくはそのサービスからの応答を受け取るのに使用される。

・ ＨｔｔｐＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ − ＨｔｔｐＬｉｓｔｅｎｅｒＦａｃｔｏｒｙクラスは、ＳＯＡＰメッセージのＨＴＴＰアドレスで聴取し、そのアドレスに対して開始されたチャネルを受け入れるための基本クラスを表す。ＳＯＡＰ−ｏｖｅｒ−ＨＴＴＰプロトコル経由で通信されるメッセージは、ＨｔｔｐＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ（およびそのヘルパＩＬｉｓｔｅｎｅｒ）から受け入れられたチャネル上で受け入れることができる。

・ ＮａｍｅｄＰｉｐｅＣｈａｎｎｅｌＦａｃｔｏｒｙ − ＮａｍｅｄＰｉｐｅＣｈａｎｎｅｌＦａｃｔｏｒｙクラスは、Ｎａｍｅｄ Ｐｉｐｅチャネルをアクティブに作成するための基本クラスを表す。Ｎａｍｅｄ Ｐｉｐｅチャネルは、Ｗｉｎｄｏｗｓ Ｎａｍｅｄ Ｐｉｐｅを介して．ＮＥＴ−ＭｅｓｓａｇｅＦｒａｍｉｎｇプロトコルを使用してサービスにメッセージを送り、おそらくはそのサービスから応答を受け取るのに使用される。

・ ＮａｍｅｄＰｉｐｅＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ − ＮａｍｅｄＰｉｐｅＬｉｓｔｅｎｅｒＦａｃｔｏｒｙクラスは、ＳＯＡＰメッセージのＮａｍｅｄ Ｐｉｐｅアドレスで聴取し、そのアドレスに対して開始されたチャネルを受け入れるための基本クラスを表す。Ｗｉｎｄｏｗｓ Ｎａｍｅｄ Ｐｉｐｅを介して．ＮＥＴ−ＭｅｓｓａｇｅＦｒａｍｉｎｇ経由で通信されるメッセージは、ＮａｍｅｄＰｉｐｅＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ（およびそのヘルパＩＬｉｓｔｅｎｅｒ）から受け入れられたチャネル上で受け入れることができる。

・ ＲｅｌｉａｂｌｅＣｈａｎｎｅｌＦａｃｔｏｒｙ − ＲｅｌｉａｂｌｅＣｈａｎｎｅｌＦａｃｔｏｒｙクラスは、Ｒｅｌｉａｂｌｅチャネルをアクティブに作成するための基本クラスを表す。Ｒｅｌｉａｂｌｅチャネルは、サポートされるトランスポートを介してＷＳ−ＲｅｌｉａｂｌｅＭｅｓｓａｇｉｎｇプロトコルを使用してサービスにメッセージを送り、おそらくはそのサービスから応答を受け取るのに使用される。

・ ＲｅｌｉａｂｌｅＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ − ＲｅｌｉａｂｌｅＬｉｓｔｅｎｅｒＦａｃｔｏｒｙクラスは、新しいＲｅｌｉａｂｌｅチャネルについて聴取するための基本クラスを表す。ＷＳ−ＲｅｌｉａｂｌｅＭｅｓｓａｇｉｎｇプロトコルを使用して通信されるメッセージは、ＲｅｌｉａｂｌｅＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ（およびそのヘルパＩＬｉｓｔｅｎｅｒ）から受け入れられたチャネル上で受け入れることができる。

・ ＴｃｐＣｈａｎｎｅｌＦａｃｔｏｒｙ − ＴｃｐＣｈａｎｎｅｌＦａｃｔｏｒｙクラスは、ＴＣＰチャネルをアクティブに作成するための基本クラスを表す。ＴＣＰチャネルは、ＴＣＰストリームを介して．ＮＥＴ−ＭｅｓｓａｇｅＦｒａｍｉｎｇプロトコルを使用してサービスにメッセージを送り、おそらくはそのサービスから応答を受け取るのに使用される。

・ ＴｃｐＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ − ＴｃｐＬｉｓｔｅｎｅｒＦａｃｔｏｒｙクラスは、ＳＯＡＰメッセージのＴＣＰアドレスで聴取し、そのアドレスに対して開始されたチャネルを受け入れるための基本クラスを表す。ＴＣＰストリームを介して．ＮＥＴ−ＭｅｓｓａｇｅＦｒａｍｉｎｇプロトコル経由で通信されるメッセージは、ＴｃｐＬｉｓｔｅｎｅｒＦａｃｔｏｒｙ（およびそのヘルパＩＬｉｓｔｅｎｅｒ）から受け入れられたチャネル上で受け入れることができる。

・ ＴｅｘｔＭｅｓｓａｇｅＥｎｃｏｄｅｒ − ＴｅｘｔＭｅｓｓａｇｅＥｎｃｏｄｅｒは、ＭｅｓｓａｇｅオブジェクトをＭｅｓｓａｇｅの標準ＸＭＬエンコーディングを使用して一連のオクテットに変換およびその逆を行うための抽象化を表す。これは、ＳｔｒｅａｍまたはＡｒｒａｙＳｅｇｍｅｎｔ＜ｂｙｔｅ＞をとり、インスタンス化されたＭｅｓｓａｇｅを返すためのメソッドと、Ｍｅｓｓａｇｅをとり、そのＭｅｓｓａｇｅをＳｔｒｅａｍまたはＡｒｒａｙＳｅｇｍｅｎｔ＜ｂｙｔｅ＞に書くためのメソッドを定義する。

（Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｃｏｎｆｉｇｕｒａｔｉｏｎ）
Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｃｏｎｆｉｇｕｒａｔｉｏｎ名前空間は、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌアプリケーションの永続設定を格納するクラスを含む。これらのＡＰＩは、主にアプリケーションの開発の後にアクセスされるので、一緒にグループ化される。これらのクラスは、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌアプリケーションを書くときにデベロッパによって使用されるのではなく、アプリケーションが書かれた後に使用される。別個の名前空間が、この区別を明瞭にする。この名前空間のコアクラスには、次のものが含まれる。

・ ＳｅｒｖｉｃｅＢｉｎｄｉｎｇｓＳｅｃｔｉｏｎ − ＳｅｒｖｉｃｅＢｉｎｄｉｎｇｓＳｅｃｔｉｏｎは、特定のＳｅｒｖｉｃｅ Ｍｏｄｅｌバインディングに対するすべてのコンフィギュレーションを含む。これらのコンフィギュレーション設定の機能は、プログラミングモデル中の同等のクラスの機能を密接にミラー化する。

・ ＳｅｒｖｉｃｅＭｏｄｅｌＳｅｃｔｉｏｎＧｒｏｕｐ − ＳｅｒｖｉｃｅＭｏｄｅｌＳｅｃｔｉｏｎＧｒｏｕｐは、すべてのＳｅｒｖｉｃｅ Ｍｏｄｅｌコンフィギュレーションに対するコンテナクラスである。これは、すべての他のＳｅｒｖｉｃｅ Ｍｏｄｅｌコンフィギュレーションをプログラム的に読み、書くときに使用されるアクセッサクラスでもある。

・ ＳｅｒｖｉｃｅｓＳｅｃｔｉｏｎ − ＳｅｒｖｉｃｅｓＳｅｃｔｉｏｎは、．ＮＥＴ Ｆｒａｍｅｗｏｒｋ ＡｐｐＤｏｍａｉｎ中に実装されたサービスのためのすべてのコンフィギュレーション設定を含む。

（Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｄｅｓｉｇｎ）
Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｄｅｓｉｇｎ名前空間は、記述の変換を扱う型（ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎおよびＣｈａｎｎｅｌＤｅｓｃｒｉｐｔｉｏｎ）を含む。これらには、コードおよびコンフィグから記述を作成するＳｅｒｖｉｃｅＬｏａｄｅｒおよびＣｈａｎｎｅｌＬｏａｄｅｒと、メタデータジェネレータおよびコードジェネレータをインポートし、エクスポートするＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎＩｍｐｏｒｔｅｒおよびＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎＥｘｐｏｒｔｅｒが含まれる。これは、ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎおよびＣｈａｎｎｅｌＤｅｓｃｒｉｐｔｉｏｎからランタイム環境を構築する型も含む。これらの型は、これらすべてが何らかの形でＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎおよびＣｈａｎｎｅｌＤｅｓｃｒｉｐｔｉｏｎを変換するので、１つの名前空間の下にグループ化される。この名前空間は、Ｄｅｓｉｇｎで終わる。というのは、これがサポートするシナリオの多くが厳密に、いずれのメッセージ交換にも先立つデザインタイムシナリオまたはランタイムシナリオであるからである（これらを、「アプリケーションがそれ自体をセットアップする」シナリオと考えることができる）。この名前空間のコアクラスには、次のものが含まれる。

・ ＣｈａｎｎｅｌＢｕｉｌｄｅｒ − ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎおよびＣｈａｎｎｅｌＤｅｓｃｒｉｐｔｉｏｎに基づいてリスナおよびチャネルスタックを構築する。

・ ＣｈａｎｎｅｌＬｏａｄｅｒ − 型付きチャネルおよび関連するバインディングに基づいてＣｈａｎｎｅｌＤｅｓｃｒｉｐｔｉｏｎを構築する。

・ ＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎＩｍｐｏｒｔｅｒ／Ｅｘｐｏｒｔｅｒ − メタデータからＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎを生成し、その逆を行う。

・ ＳｅｒｖｉｃｅＬｏａｄｅｒ − サービス型ならびに関連する契約およびバインディングからＳｅｒｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎを作成する。

（Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｄｉａｇｎｏｓｔｉｃｓ）
Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｄｉａｇｎｏｓｔｉｃｓ名前空間は、ランタイム状態の直接の検査および制御を通して、またトレースの永続ストリームを通してＳｅｒｖｉｃｅ Ｍｏｄｅｌアプリケーションをモニタし診断するのに使用される型を公開する。これらのクラスが使用されるシナリオは、アプリケーションを作成するのではなく、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌアプリケーションの振る舞いを観察し、制御することに関係する。これらのＡＰＩは、機能的区別を明瞭にするためにこの名前空間にグループ化される。この名前空間のコアクラスには、次のものが含まれる。

・ ＩＷＳＴｒａｎｓｆｅｒＣｏｎｔｒａｃｔ − ＩＷＳＴｒａｎｓｆｅｒＣｏｎｔｒａｃｔは、ＷＳ−Ｔｒａｎｓｆｅｒプロトコルを実装するインターフェースである。ＷＳ−Ｔｒａｎｓｆｅｒは、プロトコルのＷＳ−Ｍａｎａｇｅｍｅｎｔスイートの一部であり、Ｗｅｂ Ｓｅｒｖｉｃｅアプリケーションの稼働中のインスタンスを検査するのに使用される。

・ ＭｅｓｓａｇｅＷｒｉｔｅｒＴｒａｃｅＬｉｓｔｅｎｅｒ − ＭｅｓｓａｇｅＷｒｉｔｅｒＴｒａｃｅＬｉｓｔｅｎｅｒは、Ｗｅｂ Ｓｅｒｖｉｃｅの着信および発信メッセージのロギングに使用される、Ｓｙｓｔｅｍｓ．Ｄｉａｇｎｏｓｔｉｃｓ．ＴｒａｃｅＬｉｓｔｅｎｅｒクラスの実装である。

（Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｓｅｃｕｒｉｔｙ）
Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｓｅｃｕｒｉｔｙ名前空間は、メッセージセキュリティに関する型を含む。これは、ＳＯＡＰ Ｍｅｓｓａｇｅセキュリティプロトコル、ＷＳ−Ｔｒｕｓｔプロトコル、ＷＳ−ＳｅｃｕｒｅＣｏｎｖｅｒｓａｔｉｏｎｓプロトコル、および他のＷＳ−＊ Ｓｅｃｕｒｉｔｙプロトコルの実装を含む。これは、セキュリティトークンを得るためのクラス、セキュリティトークンのシリアライゼーションのためのクラス、Ｓｙｓｔｅｍ．Ｓｅｃｕｒｉｔｙ．Ａｕｔｈｏｒｉｚａｔｉｏｎ名前空間中の型の中にコールすることによってセキュリティトークンを検証するためのクラス、およびＳｙｓｔｅｍ．Ｓｅｃｕｒｉｔｙ．Ａｕｔｈｏｒｉｚａｔｉｏｎ名前空間中の型をコールすることによって認証チェックを行うためのクラスを含む。これは、セキュリティバインディング抽象化を含む（セキュリティバインディングは、メッセージセキュリティパターンである）。この名前空間中のコアクラスには、次のものが含まれる。

・ ＳｅｃｕｒｉｔｙＢｉｎｄｉｎｇＦａｃｔｏｒｙ − ＳｅｃｕｒｉｔｙＢｉｎｄｉｎｇＦａｃｔｏｒｙは、セキュリティテンプレート（バインディング）を管理するためのフレームワークである。セキュリティテンプレート（バインディング）は、ＳＯＡＰメッセージセキュリティプロトコルに準拠するセキュアメッセージの特定の定式化である。これは、テンプレート通りに、発信メッセージを保護し、着信メッセージを検証する。このクラスは、すべてのセキュリティバインディングがそれから派生する抽象基本クラスＳｅｃｕｒｉｔｙＢｉｎｄｉｎｇのインスタンスを作成する。ＳｅｃｕｒｉｔｙＢｉｎｄｉｎｇクラスは、ＳｅｃｕｒｅＯｕｔｇｏｉｎｇＭｅｓｓａｇｅ機能およびＶａｌｉｄａｔｅＩｎｃｏｍｉｎｇＭｅｓｓａｇｅ機能を提供する。

・ ＳｅｃｕｒｉｔｙＢｉｎｄｉｎｇＦａｃｔｏｒｙは、ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｓｅｃｕｒｉｔｙ．Ｐｒｏｔｏｃｏｌｓ名前空間内に特定の実装を有する。その一部を、下にリストする。

○ − AnonymousOverAsymmetricSecurityBindingFactory
○ − BasicOverAsymmetricSecurityBindingFactory
○ − BasicOverSymmetricSecurityBindingFactory
○ − BasicOverTransportSecurityBindingFactory
○ − CryptoOverAsymmetricSecurityBindingFactory
○ − CryptoOverTransportSecurityBindingFactory
○ − SessionSecurityBindingFactory
○ − SoapSecurityBindingFactory
○ − SymmetricSecurityBindingFactory
○ − TransportSecurityBindingFactory

・ ＳｅｃｕｒｉｔｙＴｏｋｅｎＡｕｔｈｅｎｔｉｃａｔｏｒ − トークンオーセンティケータは、トークン検証に使用されるべき認証設定を格納し、型固有部分を所与としてトークンをインスタンス化する。

・ ＳｅｃｕｒｉｔｙＴｏｋｅｎＰｒｏｖｉｄｅｒ − ＳｅｃｕｒｉｔｙＴｏｋｅｎＰｒｏｖｉｄｅｒは、リモートエンドポイントでプリンシパルを認証する際に使用されるセキュリティトークンを得るための機能を提供する。

・ ＳｅｃｕｒｉｔｙＴｏｋｅｎＲｅｓｏｌｖｅｒ − ＳｅｃｕｒｉｔｙＴｏｋｅｎＲｅｓｏｌｖｅｒは、トークンへの参照を作成し、マッチする（そして、予め必要なトークンについて発見する）パブリックフレームワークである。

・ ＳｅｃｕｒｉｔｙＴｏｋｅｎＳｅｒｉａｌｉｚｅｒ − ＳｅｃｕｒｉｔｙＴｏｋｅｎＳｅｒｉａｌｉｚｅｒは、ＳｅｃｕｒｉｔｙＴｏｋｅｎｓをＸＭＬにシリアライズし、トークンＸＭＬを型固有フォーマット中立部分にデシリアライズし、ＴｏｋｅｎＡｕｔｈｅｎｔｉｃａｔｏｒを呼び出してｓｅｃｕｒｉｔｙＴｏｋｅｎを作成する。これは、内部および外部トークン参照をどのようにシリアライズし、デシリアライズするかも知っている。

（Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｓｅｃｕｒｉｔｙ．Ｐｒｏｔｏｃｏｌｓ）
この名前空間は、ある特定の明確に定義され分析されたセキュリティパターン（セキュリティバインディングと呼ばれる）とマッチするＳＯＡＰメッセージセキュリティの特定の実装を含む。これは、Ｓｙｓｔｅｍ．ＳｅｒｖｉｃｅＭｏｄｅｌ．Ｓｅｃｕｒｉｔｙで定義されたフレームワークの具体的な実装を含む。

（Ｓｙｓｔｅｍ．Ｓｅｃｕｒｉｔｙ．Ａｕｔｈｏｒｉｚａｔｉｏｎ）
Ｓｙｓｔｅｍ．Ｓｅｃｕｒｉｔｙ．Ａｕｔｈｏｒｉｚａｔｉｏｎ名前空間は、セキュリティトークン、クレーム、および認証を伴うコアセキュリティ機能に責任を負うすべてのクラスを含む。この機能は、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌ名前空間とは別個の名前空間で提示されて、他のメッセージングフレームワークが、これが提示するセキュリティ機能を利用できるようにする。この名前空間には、次のコアクラスが含まれる。

・ ＩＣｌａｉｍ − セキュリティモデルの基礎は、クレーム、すなわち発行する当事者によって行われたステートメントである。クレームは、ＩＣｌａｉｍインターフェースを最小限に実装したオブジェクトによって表される。ＩＣｌａｉｍインターフェースはそれで、ＩＭａｔｃｈＰｏｌｉｃｙインターフェースを実装する。このインターフェースは、Ｍａｔｃｈメソッドを公開する。これは、指定されたクレームが、Ｍａｔｃｈメソッドを実装するオブジェクトと「マッチ」するかどうかを判定するために使用される。新しいインターフェースをＩＣｌａｉｍから導出して、クラスの分類法（ｔａｘｏｎｏｍｙ）を作成することができる。究極的に、オブジェクトは、これらのインターフェースを実装し、これら自体が、他のインターフェースに導出することができる。この名前空間は、クレームの４つのトップレベルの型、すなわちアイデンティティ、属性、発行、およびアクセス決定を定義する。アイデンティティクレームは、当事者をどのように識別するかに関するステートメントを作る。これは、プリンシパルまたはキーホルダとすることができる。属性クレームは、電話番号または誕生日など、アイデンティティに関するステートメントである。発行クレームは、指定されたアイデンティティが特定の型のクレームを発行することを許可されていることを示す。アクセス決定クレームは、示されたアイデンティティに許可されたか与えられた権利または能力である。

・ ＩＣｌａｉｍＳｅｔ − このモデルでは、クレームは単に単一のステートメントである。その結果、次の論理コンポーネントは、クレームのセットである。これらは、ＩＣｌａｉｍＳｅｔインターフェースを実装するオブジェクトによって提供される。クレームのセットは、単一のキーを担うクレームだけを有することができることを除いて、クレームの任意のセットを有することができる。

・ ＩＣｒｙｐｔｏ − ＩＣｒｙｐｔｏインターフェースは、キーホルダが実行できる暗号オペレーションを表す。暗号オペレーションは、対称または非対称のいずれかとすることができよう。

・ ＩＳｅｃｕｒｉｔｙＴｏｋｅｎ − セキュリティトークンは、ＩＣｌａｉｍｓＰｒｏｖｉｄｅｒインターフェースおよびＩＣｒｙｐｔｏＰｒｏｖｉｄｅｒインターフェースをサポートするオブジェクトであり、これは、クレームセットのコンテナであり、暗号オペレーションの暗号プロバイダを公開することを意味する。Ｖａｌｉｄａｔｅメソッドは、トークンをチェックし、検証するためにコールされる。検証は、すべての発行しているオーソリティシグネチャが確認されることを確実にし、発行委譲チェーンを認証の一部として検証できるように、これらのオーソリティのクレームセットをそれ自体のものと事実上マージする。

（Ｓｙｓｔｅｍ．Ｒｕｎｔｉｍｅ．Ｓｅｒｉａｌｉｚａｔｉｏｎ）
Ｓｙｓｔｅｍ．Ｒｕｎｔｉｍｅ．Ｓｅｒｉａｌｉｚａｔｉｏｎ名前空間は、ＸＭＬ Ｆｏｒｍａｔｔｅｒクラス（Ｓｅｒｖｉｃｅ Ｍｏｄｅｌのメインシリアライゼーションエンジン）、関連クラス、ならびにシリアライズ可能クラスをマークするのに使用されるカスタム属性およびインターフェースを含み、これらの属性およびインターフェースは、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌのシリアライゼーションプログラミングモデルを形成する。この名前空間には、次のコアクラスが含まれる。

・ ＤａｔａＣｏｎｔｒａｃｔＡｔｔｒｉｂｕｔｅ − このカスタム属性は、型がシリアライズ可能であり、新しいＳｅｒｖｉｃｅ Ｍｏｄｅｌシリアライゼーションプログラミングモデルに従って注釈を付けられていることを宣言し、その型のある特定のシリアライゼーションプロパティを設定するのに使用される。

・ ＤａｔａＭｅｍｂｅｒＡｔｔｒｉｂｕｔｅ − 新しいＳｅｒｖｉｃｅ Ｍｏｄｅｌシリアライゼーションプログラミングモデルでは、このカスタム属性は、ある所与のフィールドまたはプロパティをシリアライズすべきことを宣言するために使用される。これは、フィールドまたはプロパティのある特定のシリアライゼーション設定を制御するためにも使用することができる。

・ ＫｎｏｗｎＴｙｐｅＡｔｔｒｉｂｕｔｅ − このカスタム属性は、型を「既知の型のコレクション」に追加するために使用され、これは、シリアライゼーションエンジンがオブジェクトをどの型にデシリアライズすべきかを知らない場合にシリアライゼーションエンジンが試みる型のセットである。

・ ＵｎｋｎｏｗｎＳｅｒｉａｌｉｚａｔｉｏｎＤａｔａ − このクラスは、同じオブジェクトの異なるバージョンの間のラウンドトリッピング情報に使用され、オブジェクトの新しいバージョンのインスタンスを古いバージョンにデシリアライズするときに、古いバージョンによって理解されないどの情報もＵｎｋｎｏｗｎＳｅｒｉａｌｉｚａｔｉｏｎＤａｔａに格納される。古いオブジェクトがシリアライズされるときに、ＵｎｋｎｏｗｎＳｅｒｉａｌｉｚａｔｉｏｎＤａｔａに格納されたデータも同様にシリアライズされ、シリアライズされたデータが新しいバージョンにデシリアライズされなければならない場合にデータが失われないことを確実にする。

・ ＸｍｌＦｏｒｍａｔｔｅｒ − このクラスは、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌのメインシリアライゼーションエンジンであり、このクラス上のメソッドをコールすることによって、シリアライゼーションまたはデシリアライゼーションオペレーションを開始することができる。

（Ｓｙｓｔｅｍ．Ｔｒａｎｓａｃｔｉｏｎｓ）
Ｓｙｓｔｅｍ．Ｔｒａｎｓａｃｔｉｏｎｓ名前空間は、２つの子名前空間、Ｓｙｓｔｅｍ．Ｔｒａｎｓａｃｔｉｏｎｓ．ＩｓｏｌａｔｉｏｎおよびＳｙｓｔｅｍ．Ｔｒａｎｓａｃｔｉｏｎｓ．Ｒｅｃｏｖｅｒｙを含む。

（Ｓｙｓｔｅｍ．Ｔｒａｎｓａｃｔｉｏｎｓ．Ｉｓｏｌａｔｉｏｎ）
Ｓｙｓｔｅｍ．Ｔｒａｎｓａｃｔｉｏｎｓ．Ｉｓｏｌａｔｉｏｎ名前空間は、アプリケーションに、強調しているクライアントの間でリソースを分離させる能力を与える。その中の型は、揮発性リソースおよび持続可能でロック可能なリソースの分離と、可変粒度リソースサポート（ｖａｒｉａｂｌｅ−ｇｒａｎｕｌａｒｉｔｙ ｒｅｓｏｕｒｃｅｓ ｓｕｐｐｏｒｔ）をサポートする。この名前空間には、次のコアクラスが含まれる。

・ ＬｏｃｋＣｏｎｔｅｘｔ − クライアントのためにリソースがロックされているクライアントコンテキストを表す。

・ ＬｏｃｋＭａｎａｇｅｒ − ロックのコレクションを表し、ロックのライフタイム管理を提供する。

・ ＬｏｃｋＳｃｏｐｅ − リソースに関するオペレーションの境界を表す。

・ ＲｅｓｏｕｒｃｅＬｏｃｋ − ロックを表す。

（Ｓｙｓｔｅｍ．Ｔｒａｎｓａｃｔｉｏｎｓ．Ｒｅｃｏｖｅｒｙ）
Ｓｙｓｔｅｍ．Ｔｒａｎｓａｃｔｉｏｎｓ．Ｒｅｃｏｖｅｒｙ名前空間は、リソースマネージャのデベロッパを助けるロギングオブジェクトモデルを提供する。Ｌｏｇクラスは、異なる作業の単位、補正レコード、およびチェックポイントをサポートする。この名前空間には、次のコアクラスが含まれる。

・ Ｌｏｇ − リソースマネージャの回復ログを表す。

・ ＬｏｇＲｅｃｏｒｄ − 回復ログに書き込まれた単一レコードを表す。

・ ＳａｖｅＰｏｉｎｔ − 作業の単位中のセーブポイントを表し、ログを切り捨て、マージし、およびロールバックするためのメソッドを提供する。

・ ＵｎｉｔＯｆＷｏｒｋ − リソースマネージャのログにおける作業の論理単位を表し、作業の単位を準備し、コミットし、およびロールバックするためのメソッドを提供する。

（Ｓｙｓｔｅｍ．ＩＯ．Ｌｏｇ）
Ｓｙｓｔｅｍ．ＩＯ．Ｌｏｇ名前空間は、レコード指向のシーケンシャルＩ／Ｏシステムへの単純なインターフェースを提供するクラスを含む。これは、ＷＩＮＤＯＷＳ（登録商標）ＣＬＦＳ（Ｃｏｍｍｏｎ Ｌｏｇ Ｆｉｌｅ Ｓｙｓｔｅｍ）への管理されたインターフェースを含む。この名前空間には、次のコアクラスが含まれる。

・ ＩＲｅｃｏｒｄＳｅｑｕｅｎｃｅ − レコードシーケンス抽象化を提供するインターフェース。

（Ｓｙｓｔｅｍ．Ｔｅｘｔ）
Ｓｙｓｔｅｍ．Ｔｅｘｔ名前空間は、様々な形態のバイナリ／テキストエンコーディングおよびデコーディング（Ｂａｓｅ６４およびＢｉｎＨｅｘ）を行うためにＳｅｒｖｉｃｅ Ｍｏｄｅｌ ＸＭＬ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅコンポーネント（Ｘｍｌ ＲｅａｄｅｒｓおよびＷｒｉｔｅｒｓ）によって使用されるヘルパクラスを収容する。この名前空間には、次のコアクラスが含まれる。

・ Ｂａｓｅ６４Ｅｎｃｏｄｉｎｇ − Ｂａｓｅ６４フォーマットのバイナリデータのエンコーディングおよびデコーディングを取り扱う。

・ ＢｉｎＨｅｘＥｎｃｏｄｉｎｇ − ＢｉｎＨｅｘフォーマットのバイナリデータのエンコーディングおよびデコーディングを取り扱う。

（Ｓｙｓｔｅｍ．ＸＭＬ）
Ｓｙｓｔｅｍ．Ｘｍｌは、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌの「ＸＭＬ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ」、すなわちＳｅｒｖｉｃｅ Ｍｏｄｅｌシリアライゼーションによって使用されるが、独立に有用でもある最適化されたＸＭＬ ＲｅａｄｅｒｓおよびＷｒｉｔｅｒｓを含む。現在サポートされているリーダーおよびライタの２つのセットは、ＵＴＦ８テキストＸＭＬのためのパフォーマンス最適化されたリーダーおよびライタならびにＳｅｒｖｉｃｅ Ｍｏｄｅｌ独自のバイナリフォーマットのためのリーダー／ライタである。この名前空間には、次のコアクラスが含まれる。

・ ＩＸｍｌＤｉｃｔｉｏｎａｒｙ − ＩＸｍｌＤｉｃｔｉｏｎａｒｙを実装するクラスは、ＸｍｌＤｉｃｔｉｏｎａｒｙＳｔｒｉｎｇオブジェクトのリポジトリとして働くことができる。

・ ＸｍｌＢｉｎａｒｙＲｅａｄｅｒ、ＸｍｌＢｉｎａｒｙＷｒｉｔｅｒ − これらのクラスは、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌの独自のバイナリフォーマットのＸＭＬを読み取り、書き込む。

・ ＸｍｌＤｉｃｔｉｏｎａｒｙＲｅａｄｅｒ、ＸｍｌＤｉｃｔｉｏｎａｒｙＷｒｉｔｅｒ − これらの抽象クラスは、この名前空間のすべての他のリーダーおよびライタの基礎を形成し、標準ＸＭＬリーダーおよびライタＡＰＩに、ストリングディクショナリの使用を可能にする新しいメソッドを導入する（ＸｍｌＤｉｃｔｉｏｎａｒｙＳｔｒｉｎｇクラスを参照されたい）。すなわち、通常のストリングの代わりにＸｍｌＤｉｃｔｉｏｎａｒｙＳｔｒｉｎｇを用いてＷｒｉｔｅＳｔｒｉｎｇをコールすることができ、ライタは、サポートされる場合に、ストリングのディクショナリＩＤだけを書き込むことができ（ストリング全体ではなく）、これによって、サイズ節約を達成する。

・ ＸｍｌＤｉｃｔｉｏｎａｒｙＳｔｒｉｎｇ − このクラスは、基本的に、ストリングをユニークなＩＤ番号と組み合わせるように働き、例えばストリングが複数回書き出される（この機能をサポートするＸＭＬライタを使用して）場合に、サイズ節約を達成するために、そのストリングを、１回だけ書き出し、その後、後続のすべての使用でそのユニークＩＤによって置換することができる。

・ ＸｍｌＵＴＦ８ＴｅｘｔＲｅａｄｅｒ、ＸｍｌＵＴＦ８ＴｅｘｔＷｒｉｔｅｒ − これらのクラスは、ＵＴＦ８エンコーディングを用いて、テキストフォーマットでＸＭＬを読み取り、書き込む。これらは、標準テキストＸＭＬリーダーおよびライタに似ているが、パフォーマンスについて最適化されており、ＸｍｌＤｉｃｔｉｏｎａｒｙＲｅａｄｅｒ／Ｗｒｉｔｅｒから派生し、これによって、Ｓｅｒｖｉｃｅ Ｍｏｄｅｌシリアライゼーションエンジンの最適化されたコードパスで使用可能になされている。

（例示的なコンピューティングシステムおよび環境）
図４に、プログラミングフレームワーク１３２を実施できる（完全または部分的のいずれかで）適切なコンピューティング環境４００の一例を示す。コンピューティング環境４００は、本明細書に記載のコンピュータおよびネットワークアーキテクチャで利用することができる。

例示的なコンピューティング環境４００は、コンピューティング環境の一例にすぎず、コンピュータおよびネットワークアーキテクチャの使用または機能の範囲に関していかなる限定を示唆することが意図されたものではない。コンピューティング環境４００を、例示的なコンピューティング環境４００に図示されたコンポーネントのいずれかまたはその組合せに関する依存性または要件を有するものと解釈するべきではない。

フレームワーク１３２は、多くの他の汎用または専用のコンピューティングシステム環境または構成で実装することができる。使用に適する可能性がある周知のコンピューティングシステム、環境、および／または構成には、パーソナルコンピュータ、サーバコンピュータ、マルチプロセッサシステム、マイクロプロセッサベースのシステム、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれるが、これらに限定されない。このフレームワークのコンパクトバージョンまたはサブセットバージョンがセルラー電話、携帯情報端末、ハンドヘルドコンピュータ、または他の通信／コンピューティングデバイスなどの限られたリソースのクライアントに実装することもできる。

フレームワーク１３２を、プログラムモジュールなど、１つまたは複数のコンピュータまたは他のデバイスによって実行されるコンピュータ実行可能命令の一般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。フレームワーク１３２を、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが行われる分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリストレージデバイスを含む、ローカルおよびリモートの両方のコンピュータ記憶媒体に置くことができる。

コンピューティング環境４００は、コンピュータ４０２の形態の汎用コンピューティングデバイスを含む。コンピュータ４０２のコンポーネントは、１つまたは複数のプロセッサまたは処理ユニット４０４、システムメモリ４０６、およびプロセッサ４０４を含む様々なシステムコンポーネントをシステムメモリ４０６に結合するシステムバス４０８を含むことができる。

システムバス４０８は、メモリバスまたはメモリコントローラ、周辺バス、アクセラレイテッドグラフィックスポート、および様々なバスアーキテクチャのいずれかを使用するプロセッサバスまたはローカルバスを含む複数の可能なタイプのバス構造の１つまたは複数を表す。例として、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも称するＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスを含むことができる。

コンピュータ４０２は、通常、様々なコンピュータ可読媒体を含む。そのような媒体は、コンピュータ４０２によってアクセス可能で、揮発性および不揮発性の媒体、リムーバブルおよびノンリムーバブルの媒体の両方を含む任意の利用可能な媒体とすることができる。

システムメモリ４０６には、ランダムアクセスメモリ（ＲＡＭ）４１０などの揮発性メモリ、および／または読取専用メモリ（ＲＯＭ）４１２などの不揮発性メモリの形態のコンピュータ可読媒体が含まれる。起動中などにコンピュータ４０２内の要素の間で情報を転送するのを助ける基本ルーチンが入った基本入出力システム（ＢＩＯＳ）４１４は、ＲＯＭ ４１２に格納される。ＲＡＭ４１０は、通常、処理ユニット４０４によって即座にアクセス可能および／または現在操作されているデータおよび／またはプログラムモジュールを収容している。

コンピュータ４０２は、他のリムーバブル／ノンリムーバブル、揮発性／不揮発性のコンピュータ記憶媒体を含むこともできる。例として、図４に、非リムーバブル不揮発性磁気媒体（図示せず）から読み取り、これに書き込むハードディスクドライブ４１６、リムーバブル不揮発性磁気ディスク４２０（例えば、「フロッピディスク」）から読み取り、これに書き込む磁気ディスクドライブ４１８、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光媒体などのリムーバブル不揮発性光ディスク４２４から読み取り、そして／またはこれに書き込む光ディスクドライブ４２２が示されている。ハードディスクドライブ４１６、磁気ディスクドライブ４１８、および光ディスクドライブ４２２は、それぞれ、１つまたは複数のデータ媒体インターフェース４２６によってシステムバス４０８に接続されている。あるいは、ハードディスクドライブ４１６、磁気ディスクドライブ４１８、および光ディスクドライブ４２２を、１つまたは複数のインターフェース（図示せず）によってシステムバス４０８に接続することができる。

ディスクドライブおよびそれに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの不揮発性ストレージをコンピュータ４０２に提供する。この例には、ハードディスク４１６、リムーバブル磁気ディスク４２０、およびリムーバブル光ディスク４２４が示されているが、磁気カセットまたは他の磁気記憶デバイス、フラッシュメモリカード、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光ストレージ、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、電気的消去可能プログラマブル読取専用メモリ（ＥＥＰＲＯＭ）および類似物などの、コンピュータによってアクセス可能なデータを格納できる他のタイプのコンピュータ可読媒体も、例示のコンピューティグシステムおよび環境を実施するのに利用できることを理解されたい。

例として、オペレーティングシステム４２６、１つまたは複数のアプリケーションプログラム４２８、他のプログラムモジュール４３０、およびプログラムデータ４３２を含む、任意の数のプログラムモジュールを、ハードディスク４１６、磁気ディスク４２０、光ディスク４２４、ＲＯＭ４１２、および／またはＲＡＭ４１０に格納することができる。オペレーティングシステム４２６、１つまたは複数のアプリケーションプログラム４２８、他のプログラムモジュール４３０、およびプログラムデータ４３２のそれぞれ（あるいはこれらの組合せ）は、プログラミングフレームワーク１３２の要素を含むことができる。

ユーザは、キーボード４３４およびポインティングデバイス４３６（例えば、「マウス」）などの入力デバイスを介してコンピュータ４０２にコマンドおよび情報を入力することができる。他の入力デバイス４３８（具体的には図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星アンテナ、シリアルポート、スキャナ、および／または類似物を含むことができる。これらおよび他の入力デバイスは、システムバス４０８に結合された入出力インターフェース４４０を介して処理ユニット４０４に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することができる。

モニタ４４２または他のタイプのディスプレイデバイスも、ビデオアダプタ４４４などのインターフェースを介してシステムバス４０８に接続することができる。モニタ４４２の他に、他の出力周辺デバイスは、入出力インターフェース４４０を介してコンピュータ４０２に接続することができるスピーカ（図示せず）およびプリンタ４４６などのコンポーネントを含むことができる。

コンピュータ４０２は、リモートコンピューティングデバイス４４８などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク化された環境で動作することができる。例えば、リモートコンピューティングデバイス４４８は、パーソナルコンピュータ、ポータブルコンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイスまたは他の一般的なネットワークノード、および類似物とすることができる。リモートコンピューティングデバイス４４８は、コンピュータ４０２に関して本明細書で説明した要素および特徴の多くまたはすべてを含むことができるポータブルコンピュータとして図示されている。

コンピュータ４０２とリモートコンピュータ４４８の間の論理接続は、ローカルエリアネットワーク（ＬＡＮ）４５０および一般的な広域ネットワーク（ＷＡＮ）４５２として図示されている。そのようなネットワーキング環境は、オフィス、会社全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。

ＬＡＮネットワーキング環境で実施されるときに、コンピュータ４０２は、ネットワークインターフェースまたはネットワークアダプタ４５４を介してローカルネットワーク４５０に接続される。ＷＡＮネットワーキング環境で実施されるときに、コンピュータ４０２は、通常、広域ネットワーク４５２を介する通信を確立する、モデム４５６または他の手段を含む。モデム４５６は、コンピュータ４０２に内蔵するか外付けとすることができるが、入出力インターフェース４４０または他の適当な機構を介してシステムバス４０８に接続することができる。図示のネットワーク接続が、例示であり、コンピュータ４０２と４４８の間の通信リンクを確立する他の手段を使用できることを理解されたい。

コンピューティング環境４００と共に例示されたようなネットワーク化された環境では、コンピュータ４０２に関して図示されたプログラムモジュールまたはその一部は、リモートメモリストレージデバイスに格納することができる。例として、リモートアプリケーションプログラム４５８が、リモートコンピュータ４４８のメモリデバイス上に存在する。例示のために、アプリケーションプログラムと、オペレーティングシステムなどの他の実行可能プログラムコンポーネントが、本明細書では別個のブロックとして示されているが、そのようなプログラムおよびコンポーネントが、ときにコンピューティングデバイス４０２の異なるストレージコンポーネントに存在し、コンピュータのデータプロセッサによって実行されることを理解されたい。

フレームワーク１３２の実装、具体的にはＡＰＩ１４２またはＡＰＩ１４２に対して行われるコールを、何らかの形態のコンピュータ可読媒体に格納するか、伝送することができる。コンピュータ可読媒体は、コンピュータによってアクセスできる利用可能な媒体とすることができる。限定ではなく例として、コンピュータ可読媒体には、「コンピュータ記憶媒体」および「通信媒体」を備えることができる。「コンピュータ記憶媒体」には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報のストレージのための方法または技術で実施された、揮発性および不揮発性、リムーバブルおよび非リムーバブルの媒体が含まれる。コンピュータ記憶媒体に、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは、所望の情報を保管するのに使用でき、コンピュータによってアクセスできる他のすべての媒体が含まれるが、これらに限定されない。

「通信媒体」は、通常、搬送波または他のトランスポート機構などの変調されたデータ信号で、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを具現する。通信媒体には、任意の情報配布媒体も含まれる。用語「変調されたデータ信号」は、信号に情報を符号化する形でその特性の１つまたは複数を設定または変更した信号を意味する。限定ではなく例として、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。上記のいずれかの組合せも、コンピュータ可読媒体の範囲に含まれる。

あるいは、このフレームワークの一部を、ハードウェアで、またはハードウェア、ソフトウェア、および／もしくはファームウェアの組合せで実装することができる。例えば、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）またはプログラマブルロジックデバイス（ＰＬＤ）を設計またはプログラムして、このフレームワークの１つまたは複数の部分を実装することができる。

（プログラミングインターフェース）
プログラミングインターフェースは、コードの１つまたは複数のセグメントが、コードの１つまたは複数の他のセグメントと通信するかこれによって提供される機能にアクセスすることを可能にする機構、プロセス、プロトコルと見なすことができる。プログラミングインターフェースの１タイプが、通常はアプリケーションによってコールされるアプリケーションプログラミングインターフェースである。あるいは、プログラミングインターフェースは、他のコンポーネントの１つまたは複数の機構、メソッド、ファンクションコール、モジュールなどに通信可能に結合できるシステムのコンポーネントの１つまたは複数の機構、メソッド、ファンクションコール、モジュール、オブジェクトなどと見なすことができる。前文での用語「コードのセグメント」は、コードの１つまたは複数の命令または行を含むことが意図されており、適用される用語法にかかわらず、コードセグメントが別個にコンパイルされるかどうかにかかわらず、あるいはコードセグメントがソースコード、中間コード、またはオブジェクトコードとして提供されるかにかかわらず、コードセグメントがランタイムシステムまたはプロセスで利用されるかにかかわらず、あるいはコードセグメントが同じマシンまたは異なるマシンに配置されるか、複数のマシンにわたって分散されるかにかかわらず、あるいはコードのセグメントによって表される機能がソフトウェアだけで、ハードウェアだけで、またはハードウェアとソフトウェアの組合せで実装されるかにかかわらずに、例えば、コードモジュール、オブジェクト、サブルーチン、ファンクションなどを含む。

概念上、プログラミングインターフェースは、総称的に、図５または図６に示されているように見ることができる。図５に、第１および第２のコードセグメントが通信するコンジット（ｃｏｎｄｕｉｔ）としてのプログラミングインターフェースＩｎｔｅｒｆａｃｅ１を示す。図６に、インターフェースオブジェクトＩ１およびＩ２（第１および第２のコードセグメントの一部であってもそうでなくてもよい）を備えるものとしてプログラミングインターフェースを示し、これらのインターフェースオブジェクトは、システムの第１および第２のコードセグメントが媒体Ｍを介して通信できるようにする。図６の図面では、プログラミングインターフェースオブジェクトＩ１およびＩ２を、同じシステムの別個のプログラミングインターフェースと考えることができ、オブジェクトＩ１およびＩ２に加えて媒体Ｍがプログラミングインターフェースを備えると考えることもできる。図５および６は、双方向のフローと、フローの両側にインターフェースを示しているが、ある特定の実装が、一方向の情報フローだけを有する（または、下記で示すように情報フローを有しない）こともできるし、片側だけにインターフェースオブジェクトを有することもできる。限定ではなく例として、アプリケーションプログラミングインターフェース（ＡＰＩ）、エントリポイント、メソッド、ファンクション、サブルーチン、リモートプロシージャコール、およびコンポーネントオブジェクトモデル（ＣＯＭ）インターフェースなどの用語は、プログラミングインターフェースの定義内に包含される。

このようなプログラミングインターフェースの態様は、第１コードセグメントが第２コードセグメントに情報を伝送する（ここで「情報」とは、その最も広義の意味で使用され、データ、コマンド、要求などを含む）方法と、第２コードセグメントが情報を受け取る方法と、情報の構造、シーケンス、シンタックス、編成、スキーマ、タイミング、およびコンテンツを含むことができる。これに関して、基礎になるトランスポート媒体自体は、その媒体が有線、無線、またはそれらの組合せであれ、情報がインターフェースによって定義される仕方でトランスポートされる限り、インターフェースの動作は重要でない場合がある。いくつかの状況では、情報が、通常の意味で一方向または両方向で渡されない場合がある。というのは、情報転送が、別の機構を介する（例えば、コードセグメントの間の情報フローと別個に、バッファ、ファイルなどに置かれた情報）か、１つのコードセグメントが第２コードセグメントによって実行される機能に単純にアクセスするときのように存在しない場合があるからである。これらの態様のいずれかまたはすべてが、例えばコードセグメントが疎結合または密結合された構成のシステムの一部であるかに依存して、所与の状況で重要である場合があり、したがって、このリストは、制限的ではなく例示的と考えられるべきである。

プログラミングインターフェースのこの概念は、当業者に既知であり、本発明の前述の詳細な説明から明らかである。しかし、プログラミングインターフェースを実装する他の方法があり、明示的に除外されない限り、これらも、本明細書と共に示された請求項に包含されることが意図されている。そのような他の方法は、図５および６の単純な図より洗練され、または複雑になるように見えるかもしれないが、それでも、これらは、同じ全体的な結果を達成するための類似の機能を行う。これから、プログラミングインターフェースのいくつかの例示的な代替的な実装形態を簡潔に説明する。

（ファクタリング）
あるコードセグメントから別のコードセグメントへの通信は、通信を複数の個別の通信に分解することによって間接的に達成することができる。これを、概略的に図７および８に示す。図に示すように、いくつかのインターフェースを、機能の分割可能なセットに関して記述することができる。このように、数学的に２４を２×２×３×２として提供できるのと同様に、図５および６のインターフェース機能をファクタ化して、同一の結果を達成することができる。したがって、図７に示すように、プログラミングインターフェースＩｎｔｅｒｆａｃｅ１によって提供されるファンクションをサブ分割して、同一の結果を達成しつつ、プログラミングインターフェースの通信を複数のインターフェースＩｎｔｅｒｆａｃｅ １Ａ、Ｉｎｔｅｒｆａｃｅ １Ｂ、Ｉｎｔｅｒｆａｃｅ １Ｃなどに変換することができる。図８に示すように、インターフェースＩ１によって提供されるファンクションを、同一の結果を達成しつつ、複数のプログラミングインターフェースＩ１ａ、Ｉ１ｂ、Ｉ１ｃなどにサブ分割することができる。同様に、第１コードセグメントから情報を受け取る第２コードセグメントのプログラミングインターフェースＩ２を、複数のプログラミングインターフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどにファクタ化することができる。ファクタ化するときに、第１コードセグメントと共に含まれるインターフェースの数が、第２コードセグメントと共に含まれるプログラミングインターフェースの数とマッチする必要はない。図７および８のケースのどちらにおいても、インターフェースＩｎｔｅｒｆａｃｅ１およびＩ１の機能的趣旨は、それぞれ図５および６と同じままである。プログラミングインターフェースのファクタ化は、結合（ａｓｓｏｃｉａｔｉｖｅ）、可換（ｃｏｍｍｕｔａｔｉｖｅ）、および他の数学的プロパティに従うこともあり、ファクタ化が認識し難い場合がある。例えば、オペレーションの順序付けは、重要でない場合があり、その結果、あるプログラミングインターフェースによって履行されるファンクションは、そのインターフェースに達するかなり前に、コードまたはインターフェースの別の断片によって履行されるか、あるいはシステムの別個のコンポーネントによって行うことができる。さらに、プログラミング技術の当業者は、同じ結果を達成する異なるファンクションコールを行う様々な方法があることを理解することができる。

（再定義）
いくつかの場合に、所期の結果を依然として達成しながら、プログラミングインターフェースのある特定の態様（例えば、パラメータ）を無視し、追加し、または再定義することが可能である場合がある。これを、図９および１０に示す。例えば、図５のプログラミングインターフェースＩｎｔｅｒｆａｃｅ１に、３つのパラメータ、ｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎ、およびｏｕｔｐｕｔを含むコールであり、第１コードセグメントから第２コードセグメントに発行されるファンクションコールＳｑｕａｒｅ（ｉｎｐｕｔ，ｐｒｅｃｉｓｉｏｎ，ｏｕｔｐｕｔ）を含むと仮定する。真中のパラメータｐｒｅｃｉｓｉｏｎが、ある所与のシナリオに関係しない場合に、図９に示すように、これを単に無視するか、意味のない（この状況で）パラメータと置き換えることさえできる。関係のない追加パラメータを追加することもできる。どの場合でも、ｉｎｐｕｔが第２コードセグメントによって自乗された後にｏｕｔｐｕｔが返される限り、自乗の機能を達成することができる。ｐｒｅｃｉｓｉｏｎは、下流またはコンピューティングシステムの他の部分にとって意味のあるパラメータである可能性があるが、自乗を計算する狭い目的のためにｐｒｅｃｉｓｉｏｎが必要でないことが認識されると、これを置き換えるか無視することができる。例えば、有効なｐｒｅｃｉｓｉｏｎ値を渡す代わりに、結果に悪影響を及ぼさずに、誕生日などの無意味な値を渡すことができよう。同様に、図１０に示すように、インターフェースＩ１を、このインターフェースへのパラメータを無視するか追加するために再定義されたプログラミングインターフェースＩ１’によって置き換える。プログラミングインターフェースＩ２は、同様に、不要なパラメータまたはどこかで処理され得るパラメータを無視するように再定義されたプログラミングインターフェースＩ２’として再定義することができる。ここでのポイントは、いくつかの場合には、プログラミングインターフェースが、ある目的に必要でない、パラメータなどの態様を含むことがあり、したがって、これらを無視するか再定義し、あるいは他の目的のためにどこかで処理することができることである。

（インラインコーディング）
２つの別個のコードモジュールの間の「インターフェース」が形態を変えるように、この２つのコードモジュールの機能の一部またはすべてをマージすることが実現可能である場合もある。例えば、図５および６の機能を、それぞれ図１１および１２の機能に変換することができる。図１１では、図５の以前の第１および第２のコードセグメントが、それらの両方を含むあるモジュールにマージされる。この場合に、コードセグメントは、まだ互いに通信することができるが、インターフェースは、単一モジュールにより適する形態に適合させることができる。このように、例えば、形式的なＣａｌｌおよびＲｅｔｕｒｎステートメントが、もはや必要でないかもしれないが、プログラミングインターフェースＩｎｔｅｒｆａｃｅ１に従う類似の処理または応答が、まだ有効であるかもしれない。同様に、図１２に示すように、図６からのインターフェースＩ２の一部（またはすべて）を、プログラミングインターフェースＩ１にインラインで書き込んで、プログラミングインターフェースＩ１”を形成することができる。図示したように、プログラミングインターフェースＩ２は、Ｉ２ａおよびＩ２ｂに分割され、インターフェース部分Ｉ２ａは、プログラミングインターフェースＩ１と共にインラインでコード化されて、プログラミングインターフェースＩ１”を形成する。具体的な例として、図６からのプログラミングインターフェースＩ１が、ファンクションコールｓｑｕａｒｅ（ｉｎｐｕｔ，ｏｕｔｐｕｔ）を行い、これは、プログラミングインターフェースＩ２によって受け取られ、これが、第２コードセグメントによってｉｎｐｕｔ（自乗のため）と共に渡された値を処理した後に、ｏｕｔｐｕｔと共に自乗した結果を渡すことを考える。そのような場合に、第２コードセグメントによって行われる処理（ｉｎｐｕｔの自乗）を、プログラミングインターフェースへのコールなしで、第１コードセグメントによって行うことができる。

（分離）
あるコードセグメントから別のコードセグメントへの通信は、通信を複数の別個の通信に分解することによって間接的に達成することができる。これを、概略的に図１３および１４に示す。図１３に示すように、ミドルウェア１つまたは複数の断片（機能および／またはインターフェースファンクションを元のインターフェースから分離（ｄｉｖｏｒｃｅ）させるのでＤｉｖｏｒｃｅ Ｉｎｔｅｒｆａｃｅ）が、第１インターフェースＩｎｔｅｒｆａｃｅ１上での通信を変換して、異なるインターフェース、この例ではプログラミングインターフェースＩｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２Ｂ、およびＩｎｔｅｒｆａｃｅ２Ｃに準拠させるように提供されている。これは、例えば、言わばＩｎｔｅｒｆａｃｅ１プロトコルに従ってオペレーティングシステムと通信するように設計されたアプリケーションのインストールベースがあるが、オペレーティングシステムが、異なるインターフェース、この例ではプログラミングインターフェースＩｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２Ｂ、およびＩｎｔｅｒｆａｃｅ２Ｃを使用するように変更された場合に、行うことができる。ポイントは、第２コードセグメントによって使用される元のインターフェースが変更され、第１コードセグメントによって使用されるインターフェースともはや互換でなくなり、したがって、仲介物が、古いインターフェースと新しいインターフェースを互換にするのに使用されることである。同様に、図１４に示すように、インターフェースＩ１からの通信を受け取る分離インターフェースＤＩ１と、例えばＤＩ２と共に働くように再設計されたが同じ機能的結果を提供するインターフェースＩ２ａおよびＩ２ｂにインターフェース機能を伝送する分離インターフェースＤＩ２と共に第３コードセグメントを導入することができる。同様に、ＤＩ１およびＤＩ２は、共に働いて、図６のインターフェースＩ１およびＩ２の機能を、同じまたは類似の機能的結果を提供しつつ、新しいオペレーティングシステムに変換することができる。

（リライティング）
もう１つの可能な変形は、コードを動的にリライトして、プログラミングインターフェース機能を、別のものであるが同じ全体的な結果を達成するものに置き換えることである。例えば、中間言語（例えば、Ｍｉｃｒｏｓｏｆｔ ＩＬ、Ｊａｖａ（登録商標）ＢｙｔｅＣｏｄｅなど）で提示されたコードセグメントを実行環境（「．ＮＥＴ」Ｆｒａｍｅｗｏｒｋによって提供されるもの、Ｊａｖａ（登録商標）ランタイム環境、または他の類似のランタイムタイプ環境）中のジャストインタイム（ＪＩＴ）コンパイラまたはインタープリタに提供するシステムがある場合がある。ＪＩＴコンパイラは、第１コードセグメントから第２コードセグメントへの通信を動的に変換する、すなわち第２コードセグメント（元のまたは異なる第２コードセグメントのいずれか）によって必要とされる可能性がある異なるインターフェースにこれらを準拠させるようにリライトすることができる。これを、図１５および１６に示す。図１５からわかるように、このアプローチは、上述した分離シナリオに似ている。これは、例えば、アプリケーションのインストールベースが、Ｉｎｔｅｒｆａｃｅ１プロトコルに従ってオペレーティングシステムと通信するように設計されているが、オペレーティングシステムが、異なるインターフェースを使用するように変更された場合に行うことができる。ＪＩＴコンパイラを使用して、通信を、インストールベースアプリケーションからオペレーティングシステムの新しいインターフェースにオンザフライで準拠させることができよう。図１６に示されているように、インターフェースを動的にリライトするというこのアプローチを適用して、インターフェースをダイナミックにファクタ化するか他の点で変更することもできる。

代替実施形態を介してプログラミングインターフェースとして同じまたは類似の結果を達成するための上述したシナリオを、様々な仕方で、シリアルにおよび／またはパラレルに、あるいは他の介在するコードと組み合わせることもできることにも留意されたい。このように、上記で提示した代替実施形態は、相互に排他的ではなく、混合し、マッチさせ、組み合わせて、図５および６に提示された総称的なシナリオと同じまたは均等のシナリオを作ることができる。また、ほとんどのプログラミング構成と同様に、本明細書に記載されていないかもしれないが、それでも本発明の趣旨および範囲によって表される、インターフェースの同じまたは類似の機能を達成する他の方法があることに留意されたい、すなわち、それが、少なくとも部分的に、インターフェースの価値の根底にある、インターフェースによって表される機能であり、インターフェースによって可能にされる有利な結果であることに留意されたい。

（結び）
本発明について、構造的特徴および／または方法論的アクトに固有の言葉で説明したが、添付の特許請求の範囲で定義される発明が、記載の具体的な特徴またはアクトに必ずしも限定されないことを理解されたい。むしろ、具体的な特徴およびアクトは、請求される発明を実施する例示的な形態として開示されたものである。

本発明を、その趣旨または本質的特性から逸脱することなく他の具体的な形態で実施することができる。記載の実施形態は、すべての態様において、制限的ではなく例示的であるものと考えられるべきである。それゆえ、本発明の範囲は、前述の説明によるのではなく、添付の特許請求の範囲によって示される。特許請求の範囲の意味および均等の範囲内に入るすべての変更が、その範囲に包摂さえるべきである。

クライアントが従来のプロトコルを用いてＷｅｂサービスにアクセスするネットワークアーキテクチャを示す図である。 アプリケーションプログラムインターフェース（ＡＰＩ）を含む、ネットワークプラットフォームのためのソフトウェアアーキテクチャを示すブロック図である。 ＡＰＩによってサポートされるユニークな名前空間を示すブロック図であり、各名前空間は共通の特性を有する１つまたは複数のファンクションクラスを表している。 ソフトウェアアーキテクチャのすべてまたは一部を実行することができる例示的なコンピュータを示すブロック図である。 本発明の１つの実施形態によるプログラミングインターフェースの態様を説明するブロック図である。 一実施形態によるプログラミングインターフェースの態様説明するブロック図である。 一実施形態によるプログラミングインターフェースの態様説明するブロック図である。 一実施形態によるプログラミングインターフェースの態様説明するブロック図である。 一実施形態によるプログラミングインターフェースの態様説明するブロック図である。 一実施形態によるプログラミングインターフェースの態様説明するブロック図である。 一実施形態によるプログラミングインターフェースの態様説明するブロック図である。 一実施形態によるプログラミングインターフェースの態様説明するブロック図である。 一実施形態によるプログラミングインターフェースの態様説明するブロック図である。 一実施形態によるプログラミングインターフェースの態様説明するブロック図である。 一実施形態によるプログラミングインターフェースの態様説明するブロック図である。 一実施形態によるプログラミングインターフェースの態様説明するブロック図である。

符号の説明

１００ ネットワーク環境
１０２（１）〜（Ｎ） Ｗｅｂサービス
１０４ ネットワーク
１０６ 通信リンク
１１０ Ｗｅｂアプリケーション
１２０（１）〜（Ｍ） クライアント
１３０ アプリケーション
１３０（１）〜（４） アプリケーション言語
１３２ フレームワーク
１３４ サーバ
１４０ 共通言語仕様（ＣＬＳ）
１４２ アプリケーションプログラムインターフェース（ＡＰＩ）
１４４ 共通言語ランタイム（ＣＬＲ）
１４６ ＯＳ／サービス
１４６（１） オペレーティングシステム（ＯＳ）
１４６（２） オブジェクトモデルサービス
１４８（１）、（２） アプリケーション
１５０ フレームワーク
２００ プレゼンテーションサブシステム
２０２ シェル
２０４ Ｗｅｂサービス
２０６ ファイルシステム
２１０ プログラミングツール
４００ コンピューティング環境
４０２ コンピュータ
４０４ 処理ユニット
４０６ システムメモリ
４０８ システムバス
４１０ ＲＡＭ
４１２ ＲＯＭ
４１４ ＢＩＯＳ
４１６ ハードディスクドライブ
４１８ 磁気ディスクドライブ
４２０ リムーバブル不揮発性磁気ディスク
４２２ 光ディスクドライブ
４２４ リムーバブル不揮発性光ディスク
４２６ データ媒体インターフェース
４２６ オペレーティングシステム
４２８ アプリケーションプログラム
４３０ 他のプログラムモジュール
４３２ プログラムデータ
４３４ キーボード
４３６ マウス
４３８ 入力デバイス
４４０ 入出力インターフェース
４４２ モニタ
４４４ ビデオアダプタ
４４６ プリンタ
４４８ リモートコンピューティングデバイス
４５０ ローカルエリアネットワーク（ＬＡＮ）
４５２ インターネット
４５４ ネットワークアダプタ
４５６ モデム
４５８ リモートアプリケーションプログラム

Claims (28)

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. 前記１つまたは複数のコンピュータ可読媒体は、物理媒体であることを特徴とする請求項１６に記載の１つまたは複数のコンピュータ可読媒体。
    

Images