構造化データプロトコルをバイトストリームを供するプロトコルにバインドするための機構
【課題】対応するバイトストリームを使用して、構造化データを送信するための機構を提供すること。
【解決手段】簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）エンベロープなどの構造化データ２１１にアクセスすると、バイトストリーム２１３が生成される。バイトストリーム２１３は、構造化データを表すバイト、並びに、例えば、通信モードなどの、バイトストリーム２１３についてのプロパティを表すバイトの集合を含む。バイトストリーム２１３は、次に、バイトストリームの送受信を行うことができる通信モジュール（例えば、ＴＣＰモジュールまたは名前付きパイプモジュール）２１４に送られる。
【解決手段】簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）エンベロープなどの構造化データ２１１にアクセスすると、バイトストリーム２１３が生成される。バイトストリーム２１３は、構造化データを表すバイト、並びに、例えば、通信モードなどの、バイトストリーム２１３についてのプロパティを表すバイトの集合を含む。バイトストリーム２１３は、次に、バイトストリームの送受信を行うことができる通信モジュール（例えば、ＴＣＰモジュールまたは名前付きパイプモジュール）２１４に送られる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワーク技術に関し、より具体的には、構造化データトランスポートを、データストリームを供する（offer up）プロトコルにバインドして、１つの方向で通信されるメッセージが、逆の方向で通信されるメッセージと互いに関係付けられることを要求することなしに、双方向通信を使用して、構造化されたデータが通信されることを可能にするようにするための機構に関する。
【背景技術】
【０００２】
コンピュータ技術は、私達が仕事をし、遊ぶ仕方を一変させた。コンピューティングシステムは、現在、デスクトップコンピュータ、ラップトップコンピュータ、タブレットＰＣ、パーソナルデジタルアシスタント（ＰＤＡ）、家庭用デバイスなどを含む、多種多様な形態をとる。最も基本的な形態では、コンピューティングシステムは、システムメモリ、および１つまたは複数のプロセッサを含む。システムメモリ内のソフトウェアが、プロセッサによって実行されて、コンピューティングシステムの他のハードウェアが、所望の種々機能を実行するように導くことが可能である。
【０００３】
ネットワーキング技術は、コンピューティングシステムが、広大な距離にわたってさえ通信することを可能にして、コンピュータ機能を拡張する。例えば、ネットワーキング技術は、電子メール、Ｗｅｂブラウズ、ファイル転送、インスタントメッセージング、電子ホワイトボード（whiteboarding）、ネットワーク共同作業などのアプリケーションを可能にする。したがって、コンピュータネットワークは、広範な通信および情報アクセスを可能にする。
【０００４】
コンピューティングシステム間で通信されるデータは、しばしば、データの意味が、少なくともある程度、構造内のデータの位置によって暗示される、構造化された形態になっている。ソフトウェアコンポーネントが、構造化データプロトコルによって規定された規則に従うことにより、データ構造の少なくともいくつかの部分を生成する、または解釈することができる。この説明、および特許請求の範囲では、「構造化データプロトコル（structured data ptotocol）」は、データ構造がどのように形成されるべきかを定義する１つまたは複数の規則のセットであると広く定義される。可能性として、複数の構造化データプロトコルが、データ構造の異なる部分を支配する可能性がある。
【０００５】
構造化データプロトコルの一例には、拡張マークアップ言語（ＸＭＬ）の様々なバージョンが含まれる。ＸＭＬは、データが、階層化されたノードツリーとして構造化されることを可能にする。ルートノードが、ツリーにおいて最も遡った祖先の（most ancestral）ノードを形成する。ルートは、０以上の子ノードを有することが可能であり、各子ノードは、０以上の子ノードを有するといった具合である。各ノードは、属性および／またはその他のテキストコンテキストを有する。ＸＭＬ自体は、ノードの身元を指定せず、また、階層ツリーの形態を指定することもしない。したがって、ＸＭＬは、多くのタイプのデータを構造的に表すのに十分なだけの柔軟性がある。
【０００６】
一部の構造化データプロトコルは、基本的なＸＭＬに追加の構造規則を課す。そのような構造化データプロトコルには、例えば、簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）の様々なバージョンが含まれる。ＳＯＡＰは、トランスポートにバインドされることが可能なメッセージを表すＳＯＡＰエンベロープの形態で、ＸＭＬ要素を定義する。ＳＯＡＰエンベロープには、ヘッダ要素を含む子ＸＭＬ要素、および本文要素が含まれる。ヘッダ要素には、バージョン設定、ルーティング、アドレス情報、メッセージ識別子などを定義する、いくつかの必須の子ＸＭＬ要素およびオプションの子ＸＭＬ要素が含まれることが可能である。本文要素には、１つまたは複数の他の構造化データプロトコルに準拠することが可能な、他のＸＭＬ構造が含まれる。
【０００７】
ＳＯＡＰは、比較的トランスポートアグノスティック（agnostic）であるように設計される。しかし、ＳＯＡＰは、トランスポート機構として、ハイパーテキスト転送プロトコル（ＨＴＴＰ）への既定のバインド（しばしば、「ＳＯＡＰ−ｏｖｅｒ−ＨＴＴＰ」と呼ばれる）を定義する。ＳＯＡＰ−ｏｖｅｒ−ＨＴＴＰは広く実施されている。ＳＯＡＰ−ｏｖｅｒ−ＨＴＴＰバインド（および基礎にあるＨＴＴＰプロトコル）は、クライアントシナリオおよび企業シナリオにおける有用性を減じる、いくつかの限界を有する。
【０００８】
第１に、ＨＴＴＰは、サポートされるメッセージ交換パターンの点で限られている。というのは、ＨＴＴＰは、本質的に要求−応答プロトコルだからである。具体的には、ＨＴＴＰ対話の開始者は、サービスに単一の要求を送信し、次に、基礎にある伝送制御プロトコル接続上で応答を待つ。応答は、無視して、要求によって表される単方向通信をシミュレートすることもできる。しかし、このシミュレーションは、貴重なネットワーク帯域幅を浪費する。というのは、応答は、未使用の情報を含むからである。したがって、ＨＴＴＰは、基本的な単一要求−単一応答メッセージ交換パターンだけを効果的にサポートする。これにより、いくつかの限界がもたらされる。例えば、サーバは、求められていない応答をクライアントに送信する（すなわち、単方向メッセージ）手段を有さない。また、クライアントが、所与のＴＣＰ接続に関して、一度にせいぜい１つの保留中の要求しか有することができない。第２の要求は、第１の応答が受信されるまで、開始することができない。さらに、サーバは、所与の要求に１回だけしか応答しない可能性がある。最後に、サーバは、要求を処理している間、ネットワーク接続を開かれたままに保っているため、サーバが、メッセージを処理すべき時間は、通常、限られ、長期継続の対話が妨げられる。
【０００９】
第２に、展開されたＨＴＴＰインフラストラクチャは、一般に、ストリーミングＨＴＴＰ要求メッセージをサポートしない。要求メッセージのそのようなストリーミングは、「チャンキング（chunking）」と呼ばれる。これにより、要求メッセージの中で、複数のメガバイトビジネスドキュメントのような、大きいメッセージをストリーミングすることが困難になる。大きいメッセージをバッファリングすることは、一般に、コンピュータリソースの点で法外な費用がかかる。
【００１０】
第３に、ＨＴＴＰでセキュリティをアクティブにするのに、対話が、ＨＴＴＰからＨＴＴＰ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）プロトコルへのネゴシエーションを行わなければならない。ＨＴＴＰＳは、異なるプロトコル（異なるＴＣＰポート、および異なるＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）スキームを使用する）であるため、通信インフラストラクチャは、一般に、ＨＴＴＰからＨＴＴＰへのネゴシエーションを特別ケース化（special-case）する必要がある。例えば、ルーティングテーブルの中に重複エントリ、つまり、ＨＴＴＰをサポートするためのエントリと、ＨＴＴＰＳをサポートするためのエントリが存在することが可能である。これもまた、計算リソースの点で非効率である。
【００１１】
したがって、有利なのは、データストリーミングを許し、セキュリティの好都合なアクティブ化を容易にする、柔軟性のあるメッセージ交換パターンを可能にする形で、ＸＭＬおよび／またはＳＯＡＰなどの構造化データプロトコルを、基礎にあるトランスポートにバインドするための機構である。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
先行技術が抱える以上の諸問題は、構造化されたデータを第２のコンピューティングシステムに、対応するバイトストリームを使用して送信するための機構に向けられた、本発明の種々原理によって克服される。構造化されたデータは、通信のためのバイトストリームに変換されるため、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に限定されるのではなく、バイトストリームを通信することができる任意の通信モジュールまたは通信プロトコルを、通信のために使用することができる。
【課題を解決するための手段】
【００１３】
簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）エンベロープなどの構造化されたデータにアクセスすると、バイトストリームが生成される。バイトストリームは、構造化されたデータを表すバイト、並びにバイトストリームについてのプロパティを表すバイトの集合を含む。バイトストリームは、次に、バイトストリームの送受信を行うことができる通信モジュール（例えば、ＴＣＰモジュールまたは名前付きパイプモジュール）に送られることが可能である。それらのプロパティは、以下の詳細な説明から明白となるとおり、多種多様であることが可能である。
【００１４】
本発明のさらなる特徴および利点は、以下の説明において提示し、ある程度、この説明から明らかとなるか、または本発明の実施によって知ることができる。本発明の特徴および利点は、添付の特許請求の範囲で特に指摘する手段（instruments）および組合せを使用して、実現し、獲得することができる。本発明のそれら、およびその他の特徴は、以下の説明、および添付の特許請求の範囲から、より完全に明白となるか、または以下に提示する本発明の実施によって知ることができる。
【００１５】
本発明の前述した利点および特徴、並びにその他の利点および特徴を得ることができる方法を説明するため、添付の図面に示す、本発明の具体的な種々実施形態を参照して、以上に簡単に説明した本発明のより詳細な説明を行う。それらの図面は、本発明の典型的な種々実施形態を示すに過ぎず、したがって、本発明の範囲を限定するものと見なされるべきではないものと理解して、本発明を、添付の図面の使用を介して、さらに具体的に、さらに詳細に示し、説明する。
【発明を実施するための最良の形態】
【００１６】
本発明の種々原理は、構造化されたデータを、対応するバイトストリームを使用して送信するための機構に関する。簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）エンベロープなどの、構造化されたデータにアクセスすると、バイトストリームが生成される。バイトストリームは、構造化されたデータを表すバイト、並びに、例えば、通信モードなどの、バイトストリームについてのプロパティを表すバイトの集合を含む。バイトストリームは、次に、バイトストリームを送受信することができる通信モジュール（例えば、ＴＣＰモジュール、または名前付きパイプモジュール）に送られることが可能である。構造化されたデータは、受信側で、逆の形で回復されることが可能である。構造化されたデータは、バイトストリームに変換されるので、ＨＴＴＰに依拠するのではなく、任意の通信モジュール（ＴＣＰ、または名前付きパイププロトコルなどの）を使用して、構造化されたデータを伝送することができる。
【００１７】
同様の符号が同様の要素を指す図面を参照すると、本発明の種々原理が、適切なコンピューティング環境において実施されているのが示されている。以下の説明は、本発明の図示する種々実施形態に基づき、本明細書で明示的に説明しない代替の種々実施形態に関して、本発明を限定するものと解釈されるべきではない。
【００１８】
以下の説明では、本発明の種々実施形態を、特に明記しない限り、１つまたは複数のコンピュータによって実行される動作の作用および記号表現を参照して説明する。このため、ときとして、コンピュータによって実行されるものとして述べられる、そのような作用および動作には、構造化された形態のデータを表す電気信号の、コンピュータの処理装置による操作が含まれるものと理解されたい。この操作は、データを変換するか、またはコンピュータのメモリシステム内のロケーションでデータを保持し、これにより、当業者によってよく理解されている形で、コンピュータの動作が再構成されるか、または別の形で変更される。データが保持されるデータ構造は、データのフォーマットによって定義された特定のプロパティを有する、メモリの物理的ロケーションである。しかし、本発明の種々原理を、以上の文脈で説明するが、以下に説明する作用および動作のいくつかは、ハードウェアで実施することもできることが当業者には理解されるとおり、限定的であることは意図していない。
【００１９】
図１は、以上のデバイス群のために使用可能な典型的なコンピュータアーキテクチャの概略図を示す。説明の目的で、描かれたアーキテクチャは、適切な環境の一例に過ぎず、本発明の用法または機能の範囲について何ら限定を示唆するものではない。また、コンピューティングシステムが、図１に示したコンポーネントのいずれの１つ、または組合せに関連する依存関係または要件も、有するものと解釈してはならない。
【００２０】
本発明の種々原理は、他の多数の汎用または専用のコンピューティングまたは通信の環境または構成で機能する。本発明で使用するのに適した周知のコンピューティングシステム、コンピューティング環境、およびコンピューティング構成の例には、移動電話、ポケットコンピュータ、パーソナルコンピュータ、サーバ、マルチプロセッサシステム、マイクロプロセッサベースのシステム、ミニコンピュータ、メインフレームコンピュータ、並びに以上のシステムまたはデバイスのいずれかを含む分散コンピューティング環境が含まれるが、以上には限定されない。
【００２１】
最も基本的な構成では、コンピューティングシステム１００は、通常、少なくとも１つの処理装置１０２、およびメモリ１０４を含む。メモリ１０４は、揮発性（ＲＡＭのように）、不揮発性（ＲＯＭ、フラッシュメモリなどのように）、またはその２つの何らかの組合せであることが可能である。この最も基本的な構成を、破線１０６で図１に示す。
【００２２】
記憶媒体デバイス群は、さらなる特徴および機能を有することが可能である。例えば、記憶媒体デバイス群には、ＰＣＭＣＩＡカード、磁気ディスクおよび光ディスク、並びに磁気テープを含むが、以上には限定されない追加のストレージ（リムーバブルなストレージ、およびリムーバブルでないストレージ）が含まれることが可能である。そのような追加のストレージを、図１にリムーバブルなストレージ１０８、およびリムーバブルでないストレージ１１０で示す。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報の格納のために任意の方法または技術で実装された、揮発性媒体および不揮発性媒体、リムーバブルな媒体、およびリムーバブルでない媒体が含まれる。メモリ１０４、リムーバブルなストレージ１０８、およびリムーバブルでないストレージ１１０はすべて、コンピュータ記憶媒体の例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、その他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク、その他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、その他の磁気記憶装置、並びに所望の情報を格納するのに使用することができ、コンピューティングシステムがアクセスすることができる他のあらゆる媒体が含まれるが、以上には限定されない。
【００２３】
本明細書で使用する、「モジュール（module）」または「コンポーネント（component）」という用語は、コンピューティングシステム上で実行されるソフトウェアオブジェクトまたはルーチンを指すことが可能である。本明細書で説明する、異なるコンポーネント、モジュール、エンジン、およびサービスは、コンピューティングシステム上で実行される（例えば、別々のスレッドとして）オブジェクトまたはプロセスとして実施されることが可能である。本明細書で説明するシステムおよび方法は、好ましくは、ソフトウェアで実施されるが、ソフトウェアとハードウェアでの実施、またはハードウェアでの実施も可能であり、企図されている。
【００２４】
コンピューティングシステム１００は、ホストが、例えば、ネットワーク１２０を介して、他のシステムおよびデバイスと通信することを可能にする通信チャネル１１２も含むことが可能である。ネットワーク１２０は、任意のネットワークタイプ（現在、存在しているか、または将来に開発されるかにかかわらず）を含むことが可能であるが、例には、トークンリング、イーサネット（登録商標）、Ｂｌｕｅｔｏｏｔｈ、８０２．１１、ＵＳＢ１３９４、ＳＭＳ、ＳＯＡＰ ｏｖｅｒ ＩＰなどが含まれる。通信チャネル１１２は、通信媒体の例である。通信媒体は、通常、搬送波などの変調されたデータ信号、または他のトランスポート機構でコンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを実現し、あらゆる情報配信媒体が含まれる。例として、限定としてではなく、通信媒体には、有線ネットワークおよび直接有線接続などの有線媒体、並びに音響媒体、無線媒体、赤外線媒体、およびその他の無線媒体などの無線媒体が含まれる。本明細書で使用するコンピュータ可読媒体という用語には、記憶媒体と通信媒体がともに含まれる。
【００２５】
また、コンピューティングシステム１００は、キーボード、マウス、ペン、音声入力コンポーネント、タッチ入力デバイスなどの、入力コンポーネント１１４も有することが可能である。出力コンポーネント１１６には、スクリーンディスプレイ、スピーカ、プリンタなど、並びにこれらを駆動するためのレンダリングモジュール群（しばしば、「アダプタ（adapters）」と呼ばれる）が含まれる。コンピューティングシステム１００は、電源１１８を有する。以上すべてのコンポーネントは、当技術分野で周知であり、ここで詳細に説明する必要はない。
【００２６】
図２は、本発明の種々原理を使用することができるネットワーク環境２００を示す。ネットワーク環境２００は、任意の数のコンピューティングシステムを含むことが可能である。しかし、明瞭にするため、第１のコンピューティングシステム２１０および第２のコンピューティングシステム２２０を示す。第１のコンピューティングシステム２１０および第２のコンピューティングシステムは、互いに通信するように結合可能である。この説明、および特許請求の範囲において、２つのコンピューティングシステムは、互いに通信するように結合される能力を有する場合、「通信するように結合可能（communicatively couplable）」である。この説明、および特許請求の範囲では、２つのコンピューティングシステムは、互いに通信する場合、「通信するように結合（communicatively coupled）」されている。２つのコンピューティングシステム２１０および２２０は、同一のコンピューティングシステムまたはコンピューティングデバイスの内部に組み込まれることも可能であるが、それでも、本発明の種々原理を使用して通信する。例えば、一方のコンピューティングシステムが、ストレージ機構を表す一方で、他方のコンピューティングシステムが、本発明の種々原理を使用して、そのストレージ機構から情報を送受信することも可能である。
【００２７】
本発明の種々原理によれば、バインドモジュール２１２が、構造化されたデータ２１１にアクセスし、構造化されたデータ２１１の構造を支配する構造化データプロトコルを、バイトストリームを供するバイトストリームプロトコルにバインドする役割をする。バイトストリーム通信モジュール２１４は、この通信モジュールが、バイトストリームプロトコルに従って他のコンピューティングシステムと通信するためにバイトストリームを供することを強調するように、「バイトストリーム（byte stream）」という用語で修飾されている。この説明、および特許請求の範囲では、「バイトストリーム」は、フィールドのシーケンスとして定義される。一部のケースでは、バイトストリームの長さは、先験的には（a priori）分からない。他のケースでは、長さは、既知であり、かつ／または固定サイズであることが可能である。以上のケースのすべてが、本明細書で使用される「バイトストリーム」の定義に含まれる。
【００２８】
一実施形態では、構造化されたデータ２１１は、例えば、拡張マークアップ言語（ＸＭＬ）ドキュメントなどの階層構造のドキュメントであることが可能である。１つの特定の実施形態では、ＸＭＬドキュメントは、簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）ドキュメントであることが可能である。適切なバイトストリームプロトコルの例には、例えば、伝送制御プロトコルおよび名前付きパイプが含まれる。バインドモジュール２１２は、構造化されたデータ２１１をバイトストリーム２１３に変換することによってバイトストリームプロトコルとのバインドを完了し、次に、バイトストリーム２１３をバイトストリーム通信モジュール２１４に提供する。次に、バイトストリーム通信モジュール２１４が、そのデータを、矢印２１５で表されるとおり、第２のコンピューティングシステム２２０に送信する。第２のコンピューティングシステム２２４における類似したバイトストリーム通信モジュール２１４が、そのデータを受信し、そのデータをバイトストリーム２２３として、バインドモジュール２２２に供する。バインドモジュールは、構造化されたデータ２２１を回復する。
【００２９】
本発明の種々原理を大まかに説明したので、特定の実施形態のより詳細な動作を、図３および図４を参照して説明する。図３は、構造化されたデータを、構造化されたデータの表現を含むとともに、その構造化されたデータに関するプロパティ情報を表すバイトストリームにまず変換することにより、構造化されたデータを送信するための方法３００の流れ図を示す。方法３００は、バインドモジュール２１２によって、構造化されたデータ２１１を第２のコンピューティングシステム２２０に送信する際に実行されることが可能である。
【００３０】
バインドモジュール２１２は、第２のコンピューティングシステムに伝送するために、構造化されたデータにアクセスする（動作３０１）。バインドモジュール２１２は、例えば、他のコンポーネント、または他のコンピューティングシステムから構造化されたデータの一部、または全部を受信すること、および／または構造化されたデータの一部、または全部を生成することにより、構造化されたデータにアクセスすることができる。前述したとおり、構造化されたドキュメントの例には、ＸＭＬドキュメントおよびＳＯＡＰエンベロープが含まれる。以下は、第２のコンピューティングシステム２２０に伝送されることが所望される可能性があるＳＯＡＰエンベロープ（ＳＯＡＰバージョン１．２を使用して表現されるが、本発明の種々原理は、このバージョンに限定されない）の一例を表す。
【００３１】
【表１】
【００３２】
この３行のＳＯＡＰエンベロープは、単なる例であり、本発明の実施形態の動作をさらに明瞭にする目的で、この説明全体で一例として使用される。
【００３３】
構造化されたデータ２１１にアクセスした後（動作３０１）、バインドモジュール２１２は、構造化されたデータ２１１を、バイトストリームの１つまたは複数のプロパティを共同で表す第１の複数のバイトと、構造化されたデータを共同で表す第２の複数のバイトとを含むバイトストリーム２１３に変換する（動作３０２）。図５は、バイトストリーム２１３の一例を表す典型的なバイトストリーム５００を概略で示す。
【００３４】
図５を参照すると、バイトストリーム５００は、左右の省略記号で表される、可能性のある他の構造化データコンポーネント５２０Ｂの中でとりわけ、構造化データコンポーネント５２０Ａを含む。初期情報は、図５におけるバイトストリーム５００内の右端のフィールドとして指定されており、次に続く情報が、左方向に連なっている。各構造化データコンポーネント５２０Ａおよび５２０Ｂは、対応する構造化されたデータを含む。例えば、構造化データコンポーネント５２０Ａは、対応する構造化されたデータ５２２Ａのバイトストリーム表現を含む。前述したとおり、構造化されたデータ５２２Ａは、例えば、ＳＯＡＰエンベロープであることが可能である。また、各構造化データコンポーネント５２０Ａおよび５２０Ｂは、オプションとして、構造化されたデータのバイトストリーム表現の長さを明らかにする長さコンポーネントも含むことが可能である。例えば、長さコンポーネント５２１Ａは、構造化されたデータ５２２Ａのバイトストリーム表現の長さを明らかにする。バイトストリームの長さが既知である（例えば、長さが、受信側に知られている固定サイズである）場合、長さフィールドは、オプションにされてもよい。また、長さは、他の何らかの機構を使用して、ネゴシエートされることも可能である。さらに、各構造化データコンポーネント５２０Ａおよび５２０Ｂは、オプションとして、他の情報も含むことが可能である。例えば、構造化データコンポーネント５２０Ａは、他のフィールド５２３Ａを含む。
【００３５】
バイトストリームの中に長さフィールド５１２Ａを有することにより、いくつかの利点が可能になる。第１に、形式に誤りがある（malformed）構造化データコンポーネントを、接続を閉じるのではなく、単に飛ばして進むことができる。接続を閉じることは、高くつく。というのは、接続を再開することは、時間、処理リソース、およびメモリリソースを要するからである。さらに、接続が閉じられていた時間中に受信されたであろうメッセージの一部が、失われる可能性がある。第２に、メッセージを処理するアプリケーションコードを呼び出す前に、構造化されたデータ全体をメモリの中に読み込むことができる。これにより、アプリケーションが、メッセージの残りの部分が利用可能になるのを待つ必要なしに、メッセージに完全にアクセスし、処理を完了することが可能になる。
【００３６】
また、バイトストリーム５００は、バイトストリーム５００全体についてのプロパティを定義するストリームプロパティ５１０も含む。それらのプロパティは、バイトストリーム５００のプロパティレコードと考えることもできる。そのようなプロパティレコードの例を示す。図示していないが、構造化されたデータは、ストリームプロパティをリセットするように各プロパティフィールドの間にインタリーブすることができる。
【００３７】
最初に、バイトストリーム５００のフレーミングバージョンを定義するバージョンレコード５１１が図示されている。受信側コンピューティングシステムが、そのバージョンを、後続のプロパティレコードをどのように解釈すべきか、かつ／または構造化されたデータをどのように回復すべきかを支配する一組の規則と互いに関係付けることができる。例えば、バージョン情報は、許容できるプロパティレコードのリスト、およびそれらのレコードの対応する意味と互いに関係付けられることが可能である。
【００３８】
次に、通信のモードを定義する通信モードレコード５１２が図示されている。通信モードに関してさらに、図６Ａないし図６Ｃに関連して以下に説明する。簡単に述べると、通信モードは、メッセージ交換のパターンおよび信頼性を指定する際の柔軟性を可能にする。モードレコード５１２を有することは、単一のネットワークアドレス（例えば、単一のＴＣＰポート番号）が異なるモードでメッセージを受信することを可能にする。ＴＣＰポート番号は、所与のマシン用の限られたリソースであるという点で、幾分、高くつく。
【００３９】
ｖｉａレコード５１３が、データストリーム５００に関する目標宛先を定義する。バインドモジュールは、通信プロトコルスタックの中に存在することが可能であり、プロトコルスタックにおける上位レイヤが、構造化されたデータ２１１（または構造化されたデータ２１１内で表される情報）を別の宛先に送信する。そうすることで、その情報に関する最終的な宛先は、ｖｉａレコード５１３によって表されるコンピューティングシステムよりも、通信パスにおいてさらに先であることが可能である。それでも、ｖｉａレコード５１３は、次のバインドモジュールレベル宛先のアドレスを表す。ｖｉａレコード５１３は、バイトストリーム５００を完全に解析し、構造化されたデータ５２２Ａにアクセスするのに必要とされる処理リソースを消費する必要なしに、受信側システムによる何らかのレベルのディスパッチを可能にする。ｖｉａレコード５１３の値は、既定で、以前のｖｉａ値になり、バイトストリームのサイズが縮小されることも可能である。
【００４０】
符号化フィールド５１４は、含まれる構造化データコンポーネント５２２に関する符号化フォーマットを定義することができる。これにより、システムが、接続上で複数の符号化をサポートすることが可能になり、それにより、必要とされる接続の数が削減されることが可能である。また、これにより、単一のアドレス（例えば、単一のＴＣＰポート番号）が、異なる符号化のために使用されることも可能になる。前述したとおり、ＴＣＰポート番号は、高くつく可能性がある。コンテンツタイプに関して周知の値と拡張可能な値の両方をサポートすることにより、共通の値のためにワイヤサイズ（wire size）を犠牲にすることなしに、拡張性が可能になる。例えば、周知のコンテンツタイプを単一のバイトで符号化することができるが、ＭＩＭＥ媒体タイプに対応する文字列の値を示すことにより、さらなるコンテンツタイプが可能である（ただし、より冗長（verbose）である）。
【００４１】
アップグレードフィールド５１５により、セキュリティアップグレードが要求されるか否か、またはセキュリティアップグレードに応答が行われるか否かが示される。２つのコンピューティングシステムが、セキュリティアップグレード要求を完了し、その後に、戻された肯定応答が行われると、その２つのコンピューティングシステムは、セキュリティコンポーネント（例えば、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）を使用して、セキュリティのネゴシエーションをさらに行うことができる。アップグレードフィールド５１５は、さらなるネゴシエーションのために使用される必要はないが、セキュリティアップグレードを要求し、そのセキュリティアップグレードが可能であることを確認するのに少なくとも使用して、その後のネゴシエーションが、セキュリティアップグレードを完成させることができるようにすることができる。アップグレードフィールド５１５を使用する場合、構造化データコンポーネント５２０が、まったく存在していなくてもよい。このアップグレード機構は、セキュリティで保護された形で通信するのに別個の接続が要求されないため、有用である。さらに、アップグレードフィールド５１５は、例えば、圧縮および／または暗号化をネゴシエートするなどの、完全なストリームの他の変換のために使用することもできる。
【００４２】
障害フィールド５１６は、例えば、前のデータストリームが、正しい形式（well formed）ではなかった、またはそれ以外で応答を受けることができない場合などに、障害情報の通信を可能にする。このケースでも、障害フィールド５１６を使用する場合に、構造化データコンポーネント５２０が、まったく存在していなくてもよい。
【００４３】
その他フィールド５１７は、可能なプロパティレコードのリストが、拡張可能であることを表す。例えば、その他フィールド５１７は、例えば、圧縮レベルまたは暗号化レベルなどの、ストリームについてネゴシエーションが行われるべき他の情報を含むことが可能である。
【００４４】
以下は、対応するバイトストリームに変換される典型的な３行のＳＯＡＰエンベロープの具体的な一例を示す。この具体的な例では、読者が、各行で提示されるバイトストリームの対応するコンポーネントを理解するのを助ける追加のテキストが、各行に追加されている。各行の左端は、括弧内の２桁の番号であり、その２桁は、行番号を表す。この例では、行番号は、０１から２４までの範囲である。行番号の閉じ括弧の直後に来るのが、バイトをそれぞれが表す２つの１６進数字の１つまたは複数のクラスタである。各行を閉じるのが、２重スラッシュ（double foward slash）「／／」で始まる、人間が読むことができる注釈（remarks）ステートメントである。バイトストリームは、もちろん、バイトのストリームであり、行に編成されてはいない。以下の例は、論理的な境界に沿って人工的に行に編成されて、読者を助けている。
【００４５】
【表２】
【００４６】
第１の行（すなわち、行０１）は、バイト００を含む。各レコードは、複数のバイトを含むことが可能である。この例では、各レコード内の最初のバイトは、レコードタイプを明らかにする。このケースで００は、レコードがバージョンレコードであることを示す。第２の行および第３の行はそれぞれ、１バイトを含み、第２のリストは、メジャーバージョンを明らかにし、第３の行は、マイナーバージョンを明らかにする。行０１ないし行０３は一緒になって、図５のバージョンレコード５１１の一例を表す。
【００４７】
行０４は、次のレコードに関するレコードタイプ識別子を表す１バイトを含む。ここで、バイト０１は、通信モードレコードを表す。行０５は、動作モードが単信であることを表す値３を有するバイトを含む。他の典型的な通信モードには、多重、２重、およびシングルトン（ｓｉｎｇｌｅｔｏｎ）が含まれる。これらの通信モードのそれぞれの意味を、図６Ａないし図６Ｃに関連して以下にさらに説明する。通信モードの数は、さらなるフレーミングバージョンを追加すること、およびバージョンレコードの中でバージョンを適切に明らかにすることにより、拡張することができる。行０４と行０５は一緒になって、図５のモードレコード５１２の一例を表す。
【００４８】
行０６は、ｖｉａレコードの先頭を示す、レコードタイプ識別子バイト０２を含む。行０７は、このケースでは２３バイトである、ｖｉａレコードの長さを明らかにする。行０８ないし行１０は、宛先アドレスを「http://example.org/dest」として定義した２３個のＵＴＦ−８文字を表す２３バイトを含む。行０６ないし行１０は一緒になって、ｖｉａレコード５１３の例を表す。
【００４９】
行１１は、符号化レコードの先頭を示す、レコードタイプ識別子バイト０３を含む。行１２は、この例では、ＵＴＦ−８およびＳＯＡＰバージョン１．２に相当する、３という値を有するバイトを含む。行１１および行１２は一緒になって、図５の符号化レコード５１４の一例を表す。
【００５０】
行１３は、サイズド（sized）エンベロープレコードの先頭を示す、レコードタイプ識別子バイト０６を含む。サイズドエンベロープレコードは、ＳＯＡＰエンベロープのサイズのＩＤと、ＳＯＡＰエンベロープ自体をともに含む。具体的には、行１４は、ＳＯＡＰエンベロープの長さが、７５バイトである（または、ＵＴＦ−８において各文字を表すのに１バイトが使用されるので、７５文字でもある）と明らかにする。行１５ないし行２４は、この例において最初に提示した３行のＳＯＡＰエンベロープに関するＵＴＦ−８を表す。したがって、行１５ないし行２４は共同で、図５の構造化されたデータ５２２Ａのバイトストリーム表現を表す。行１４は、図５の長さフィールド５２１Ａを表す。このため、行１３ないし行２４は共同で、図５の構造化データコンポーネント５２０Ａを表す。
【００５１】
他のプロパティレコードを使用して、セキュリティアップグレードの要求または応答を表す、障害を表す、またはその他の情報を表すこともできる。
【００５２】
バイトストリーム５００は、現時点で、バイトストリームであるため、ユーザデータグラムプロトコル（ＵＤＰ）、Ｍｉｃｒｏｓｏｆｔメッセージキュー（ＭＳＭＱ）、ＴＣＰ、または名前付きパイプなどのバイトストリームを供する任意の通信モジュールに与えられることが可能である。したがって、図３を参照すると、バイトストリームを生成した後、バインドモジュールは、次に、そのバイトストリーム２１３を、他のコンピューティングシステムと通信するためにバイトストリームを受け入れるバイトストリーム通信モジュール２１４に送る（動作２０３）。
【００５３】
他のプロパティレコードを使用して、セキュリティアップグレードの要求または応答を表現する、障害を表現する、またはその他の情報を表現することもできる。
【００５４】
図４は、構造化されたデータと、バイトストリームのプロパティの両方を表すバイトストリームをまず受信することにより、構造化されたデータを受信するための方法４００の流れ図を示す。方法４００は、第２のコンピューティングシステム２２０におけるバインドモジュール２２２によって実行されることが可能であり、あるいはさらに、メッセージを受信する際に、第１のコンピューティングシステム２１０におけるバインドモジュール２１２によって実行されることが可能である。いずれの場合も、メッセージを受信すると、バイトストリーム通信モジュール２２４（または２１４）は、バイトストリームを対応するバインドモジュール２２２（または２１２）に与える。
【００５５】
すると、バインドモジュールは、バイトストリームを受け取る（動作４０１）。バインドモジュールは、プロパティレコード群を使用して、バージョン情報、通信モードなどを識別することができる。受信側バインドモジュールは、送信側バインドモジュールが、バイトストリームを構築するのに使用したのと同一のフレーミング規則を使用して、バイトストリームを解釈する。したがって、受信側バインドモジュールは、次に、バイトストリームから構造化されたデータを回復することができる（動作４０２）。送受信するプロセスは、頻繁に繰り返されることが可能である。
【００５６】
したがって、本発明の種々原理は、バイトストリーム（ＴＣＰなどの）を供する通信モジュールを使用して、構造情報（ＳＯＡＰエンベロープなどの）を通信するための柔軟性のある機構を説明する。そのような通信モジュールとインターフェースをとる能力は、そのような通信モジュールの柔軟性を利用して、メッセージ交換のパターンおよび信頼性に関するより広い範囲の選択を可能にすることができることを意味する。ＴＣＰは、単一要求−単一応答メッセージパターンに限定されない。さらに多くのメッセージパターンを使用して、例えば、ＳＯＡＰ−ｏｖｅｒ−ＨＴＴＰの、最も本質的な弱点の１つを克服することができる。さらに、この機構は、フレーミングプロトコルに組み込まれた、好都合なセキュリティアップグレードを可能にする。
【００５７】
また、通信モードも変更することができる。一実施形態では、これは、図５のようなバイトストリーム５００のストリームプロパティ５１０のモードフィールド５１２の中に通信モード情報を含めることによって実行される。図６Ａないし図６Ｃは、通信モードレコードによって設定されることが可能な様々な通信モードのいくつかの例を示す。各図では、コンポーネント６１０が、第１のコンピューティングシステム上の単一の接続（例えば、ＴＣＰ接続または名前付きパイプ）を表し、他方、コンポーネント６２０が、第２のコンピューティングシステム上の単一の接続（例えば、ＴＣＰ接続または名前付きパイプ接続）を表す。
【００５８】
図６Ａは、多重モードを示す。このモードでは、単一の接続６１０Ａが、単一の接続６２０Ａにデータを送信する。バインドモジュールに対応するバインドレイヤで、様々なメッセージを受信するのに単一の接続が使用されていても、それらのメッセージは異なるエンドポイントにルーティングされるべきである。例として、１つのＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）−ＴＣＰポート（例えば、接続６１０Ａに関連する）に関連するユーザが、別のＵＲＩ−ＴＣＰポート（例えば、接続６２０Ａに関連する）によって表されるオンライン書店とインターフェースをとることを所望するものと想定されたい。その単一のＴＣＰポートは、いくつかの異なるサービスを提供することができる。例えば、おそらく、１つのサービスが書店在庫目録情報を提供する一方で、別のサービスは書籍購入を提供する。各要求のために異なる接続を使用する必要がない。代わりに、適切な要求６１１Ａが、在庫目録サービスに対する適切なルーティング６１２Ａないし６１４Ａのために、接続６２０Ａに送信され、同一の接続が、書籍購入のために後に使用される。図５の実施形態では、このルーティングは、ｖｉａレコード５１３内の情報を使用して達せられることが可能である。
【００５９】
図６Ｂは、第１のコンピューティングシステムに関して単一の接続６１０Ｂを使用して、第２のコンピューティングシステムにおける単一の接続６２０Ｂにメッセージ６１１Ｂを信頼できる形で送信することができる単信モードを示す。この単信モードも同様に、図５の実施形態におけるモードレコード５１２内で明らかにされることが可能である。信頼性を確実にするため、矢印６１２Ｂで表される、リターン受信確認メッセージまたはリターン受信確認パケットが存在することが可能である。接続６２０Ｂは、バイトストリーム６１３をプロトコルスタックの他のレイヤに提供する。このモードでは、ＴＣＰおよび名前付きパイプのケースにおける接続間で、中間のバインドレベルモジュールは、まったく存在しない。しかし、信頼性は、さらに保証される。この信頼性をもたらす受信確認メッセージは、構造データ自体（例えば、図５の構造化されたデータ５２２Ａ）の中に入っていること、または他の何らかの機構によることが可能である。
【００６０】
図６Ｃは、第１のコンピューティングシステムに関して単一の接続６１０Ｃを使用して、第２のコンピューティングシステムにおける単一の接続６２０Ｃにメッセージ６１１Ｃを信頼できる形で送信する２重モードを示す。この２重モードは、図５の実施形態におけるモードレコード５１２内で明らかにされることが可能である。信頼性を向上させるように、関連する受信確認メッセージ６１２Ｃが存在することが可能であり、接続６２０Ｃは、プロトコルスタックにおける他のレイヤに、対応するバイトストリーム６１３Ｃを供する。同様に、反対方向で、第２のコンピューティングシステムに関して単一の接続６２０Ｃが使用されて、第１のコンピューティングシステムにおける同一の接続６１０Ｃにメッセージ６２１Ｃが、信頼できる形で送信される。信頼性を向上させるように、関連する受信確認メッセージ６２２Ｃが存在することが可能であり、接続６１０Ｃは、プロトコルスタックにおける他のレイヤに、対応するバイトストリーム６２３Ｃを供する。
【００６１】
図示していないが、「シングルトン（singleton）」モードも、図５の実施形態におけるモードフィールド５１２を使用して選択されることが可能である。単一の接続を使用するこのシングルトンは、サイズが制限されていないバイトストリームを第２のコンピューティングシステムに送信するのに使用される。
【００６２】
本発明は、本発明の趣旨または基本的な特徴から逸脱することなく、他の特定の形態で実施することもできる。説明した種々実施形態は、すべての点で、単に例示的であり、限定的ではないものと見なされるべきである。したがって、本発明の範囲は、以上の説明によってではなく、添付の特許請求の範囲によって示される。特許請求の範囲の均等の趣旨および範囲に含まれるすべての変更が、特許請求の範囲に包含されるものとする。
【図面の簡単な説明】
【００６３】
【図１】本発明の種々特徴を実施することができる適切なコンピューティングシステムを示す図である。
【図２】本発明の種々原理を使用できるネットワーク環境を示す図である。
【図３】構造化されたデータを、構造化されたデータの表現を含むとともに、その構造化されたデータに関するプロパティ情報を表すバイトストリームにまず変換することにより、構造化されたデータを送信するための方法を示す図である。
【図４】構造化されたデータと、バイトストリームのプロパティをともに表すバイトストリームをまず受信することにより、構造化されたデータを受信するための方法を示す図である。
【図５】構造化されたデータと、バイトストリームのプロパティをともに表すバイトストリームのデータ構造を示す図である。
【図６Ａ】複数のアウトバウンド通信を、単一の受信者コンピューティングシステム上で実行される異なるプロセスに通信するのに、単一の接続が使用される通信モードを示す図である。
【図６Ｂ】信頼できる形で単方向通信を行うのに単一の接続が使用される通信モードを示す図である。
【図６Ｃ】信頼できる形で双方向通信を行うのに単一の接続が使用される通信モードを示す図である。
【符号の説明】
【００６４】
１０２ 処理装置
１０８ リムーバブルなストレージ
１１０ リムーバブルでないストレージ
１１２ 通信チャネル
１１４ 入力コンポーネント
１１６ 出力コンポーネント
１１８ 電源
１２０ ネットワーク
２００ ネットワーク環境
２１０ 第１のコンピューティングシステム
２１１，２２１ 構造化データ
２１２，２２２ バインドモジュール
２１３，２２３，５００ バイトストリーム
２１４，２２４ バイトストリーム通信モジュール
２２０ 第２のコンピューティングシステム
５１０ ストリームプロパティ
５２０Ａ 構造化データコンポーネント
５２２Ａ 構造化データ
【技術分野】
【０００１】
本発明はネットワーク技術に関し、より具体的には、構造化データトランスポートを、データストリームを供する（offer up）プロトコルにバインドして、１つの方向で通信されるメッセージが、逆の方向で通信されるメッセージと互いに関係付けられることを要求することなしに、双方向通信を使用して、構造化されたデータが通信されることを可能にするようにするための機構に関する。
【背景技術】
【０００２】
コンピュータ技術は、私達が仕事をし、遊ぶ仕方を一変させた。コンピューティングシステムは、現在、デスクトップコンピュータ、ラップトップコンピュータ、タブレットＰＣ、パーソナルデジタルアシスタント（ＰＤＡ）、家庭用デバイスなどを含む、多種多様な形態をとる。最も基本的な形態では、コンピューティングシステムは、システムメモリ、および１つまたは複数のプロセッサを含む。システムメモリ内のソフトウェアが、プロセッサによって実行されて、コンピューティングシステムの他のハードウェアが、所望の種々機能を実行するように導くことが可能である。
【０００３】
ネットワーキング技術は、コンピューティングシステムが、広大な距離にわたってさえ通信することを可能にして、コンピュータ機能を拡張する。例えば、ネットワーキング技術は、電子メール、Ｗｅｂブラウズ、ファイル転送、インスタントメッセージング、電子ホワイトボード（whiteboarding）、ネットワーク共同作業などのアプリケーションを可能にする。したがって、コンピュータネットワークは、広範な通信および情報アクセスを可能にする。
【０００４】
コンピューティングシステム間で通信されるデータは、しばしば、データの意味が、少なくともある程度、構造内のデータの位置によって暗示される、構造化された形態になっている。ソフトウェアコンポーネントが、構造化データプロトコルによって規定された規則に従うことにより、データ構造の少なくともいくつかの部分を生成する、または解釈することができる。この説明、および特許請求の範囲では、「構造化データプロトコル（structured data ptotocol）」は、データ構造がどのように形成されるべきかを定義する１つまたは複数の規則のセットであると広く定義される。可能性として、複数の構造化データプロトコルが、データ構造の異なる部分を支配する可能性がある。
【０００５】
構造化データプロトコルの一例には、拡張マークアップ言語（ＸＭＬ）の様々なバージョンが含まれる。ＸＭＬは、データが、階層化されたノードツリーとして構造化されることを可能にする。ルートノードが、ツリーにおいて最も遡った祖先の（most ancestral）ノードを形成する。ルートは、０以上の子ノードを有することが可能であり、各子ノードは、０以上の子ノードを有するといった具合である。各ノードは、属性および／またはその他のテキストコンテキストを有する。ＸＭＬ自体は、ノードの身元を指定せず、また、階層ツリーの形態を指定することもしない。したがって、ＸＭＬは、多くのタイプのデータを構造的に表すのに十分なだけの柔軟性がある。
【０００６】
一部の構造化データプロトコルは、基本的なＸＭＬに追加の構造規則を課す。そのような構造化データプロトコルには、例えば、簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）の様々なバージョンが含まれる。ＳＯＡＰは、トランスポートにバインドされることが可能なメッセージを表すＳＯＡＰエンベロープの形態で、ＸＭＬ要素を定義する。ＳＯＡＰエンベロープには、ヘッダ要素を含む子ＸＭＬ要素、および本文要素が含まれる。ヘッダ要素には、バージョン設定、ルーティング、アドレス情報、メッセージ識別子などを定義する、いくつかの必須の子ＸＭＬ要素およびオプションの子ＸＭＬ要素が含まれることが可能である。本文要素には、１つまたは複数の他の構造化データプロトコルに準拠することが可能な、他のＸＭＬ構造が含まれる。
【０００７】
ＳＯＡＰは、比較的トランスポートアグノスティック（agnostic）であるように設計される。しかし、ＳＯＡＰは、トランスポート機構として、ハイパーテキスト転送プロトコル（ＨＴＴＰ）への既定のバインド（しばしば、「ＳＯＡＰ−ｏｖｅｒ−ＨＴＴＰ」と呼ばれる）を定義する。ＳＯＡＰ−ｏｖｅｒ−ＨＴＴＰは広く実施されている。ＳＯＡＰ−ｏｖｅｒ−ＨＴＴＰバインド（および基礎にあるＨＴＴＰプロトコル）は、クライアントシナリオおよび企業シナリオにおける有用性を減じる、いくつかの限界を有する。
【０００８】
第１に、ＨＴＴＰは、サポートされるメッセージ交換パターンの点で限られている。というのは、ＨＴＴＰは、本質的に要求−応答プロトコルだからである。具体的には、ＨＴＴＰ対話の開始者は、サービスに単一の要求を送信し、次に、基礎にある伝送制御プロトコル接続上で応答を待つ。応答は、無視して、要求によって表される単方向通信をシミュレートすることもできる。しかし、このシミュレーションは、貴重なネットワーク帯域幅を浪費する。というのは、応答は、未使用の情報を含むからである。したがって、ＨＴＴＰは、基本的な単一要求−単一応答メッセージ交換パターンだけを効果的にサポートする。これにより、いくつかの限界がもたらされる。例えば、サーバは、求められていない応答をクライアントに送信する（すなわち、単方向メッセージ）手段を有さない。また、クライアントが、所与のＴＣＰ接続に関して、一度にせいぜい１つの保留中の要求しか有することができない。第２の要求は、第１の応答が受信されるまで、開始することができない。さらに、サーバは、所与の要求に１回だけしか応答しない可能性がある。最後に、サーバは、要求を処理している間、ネットワーク接続を開かれたままに保っているため、サーバが、メッセージを処理すべき時間は、通常、限られ、長期継続の対話が妨げられる。
【０００９】
第２に、展開されたＨＴＴＰインフラストラクチャは、一般に、ストリーミングＨＴＴＰ要求メッセージをサポートしない。要求メッセージのそのようなストリーミングは、「チャンキング（chunking）」と呼ばれる。これにより、要求メッセージの中で、複数のメガバイトビジネスドキュメントのような、大きいメッセージをストリーミングすることが困難になる。大きいメッセージをバッファリングすることは、一般に、コンピュータリソースの点で法外な費用がかかる。
【００１０】
第３に、ＨＴＴＰでセキュリティをアクティブにするのに、対話が、ＨＴＴＰからＨＴＴＰ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）プロトコルへのネゴシエーションを行わなければならない。ＨＴＴＰＳは、異なるプロトコル（異なるＴＣＰポート、および異なるＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）スキームを使用する）であるため、通信インフラストラクチャは、一般に、ＨＴＴＰからＨＴＴＰへのネゴシエーションを特別ケース化（special-case）する必要がある。例えば、ルーティングテーブルの中に重複エントリ、つまり、ＨＴＴＰをサポートするためのエントリと、ＨＴＴＰＳをサポートするためのエントリが存在することが可能である。これもまた、計算リソースの点で非効率である。
【００１１】
したがって、有利なのは、データストリーミングを許し、セキュリティの好都合なアクティブ化を容易にする、柔軟性のあるメッセージ交換パターンを可能にする形で、ＸＭＬおよび／またはＳＯＡＰなどの構造化データプロトコルを、基礎にあるトランスポートにバインドするための機構である。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
先行技術が抱える以上の諸問題は、構造化されたデータを第２のコンピューティングシステムに、対応するバイトストリームを使用して送信するための機構に向けられた、本発明の種々原理によって克服される。構造化されたデータは、通信のためのバイトストリームに変換されるため、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に限定されるのではなく、バイトストリームを通信することができる任意の通信モジュールまたは通信プロトコルを、通信のために使用することができる。
【課題を解決するための手段】
【００１３】
簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）エンベロープなどの構造化されたデータにアクセスすると、バイトストリームが生成される。バイトストリームは、構造化されたデータを表すバイト、並びにバイトストリームについてのプロパティを表すバイトの集合を含む。バイトストリームは、次に、バイトストリームの送受信を行うことができる通信モジュール（例えば、ＴＣＰモジュールまたは名前付きパイプモジュール）に送られることが可能である。それらのプロパティは、以下の詳細な説明から明白となるとおり、多種多様であることが可能である。
【００１４】
本発明のさらなる特徴および利点は、以下の説明において提示し、ある程度、この説明から明らかとなるか、または本発明の実施によって知ることができる。本発明の特徴および利点は、添付の特許請求の範囲で特に指摘する手段（instruments）および組合せを使用して、実現し、獲得することができる。本発明のそれら、およびその他の特徴は、以下の説明、および添付の特許請求の範囲から、より完全に明白となるか、または以下に提示する本発明の実施によって知ることができる。
【００１５】
本発明の前述した利点および特徴、並びにその他の利点および特徴を得ることができる方法を説明するため、添付の図面に示す、本発明の具体的な種々実施形態を参照して、以上に簡単に説明した本発明のより詳細な説明を行う。それらの図面は、本発明の典型的な種々実施形態を示すに過ぎず、したがって、本発明の範囲を限定するものと見なされるべきではないものと理解して、本発明を、添付の図面の使用を介して、さらに具体的に、さらに詳細に示し、説明する。
【発明を実施するための最良の形態】
【００１６】
本発明の種々原理は、構造化されたデータを、対応するバイトストリームを使用して送信するための機構に関する。簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）エンベロープなどの、構造化されたデータにアクセスすると、バイトストリームが生成される。バイトストリームは、構造化されたデータを表すバイト、並びに、例えば、通信モードなどの、バイトストリームについてのプロパティを表すバイトの集合を含む。バイトストリームは、次に、バイトストリームを送受信することができる通信モジュール（例えば、ＴＣＰモジュール、または名前付きパイプモジュール）に送られることが可能である。構造化されたデータは、受信側で、逆の形で回復されることが可能である。構造化されたデータは、バイトストリームに変換されるので、ＨＴＴＰに依拠するのではなく、任意の通信モジュール（ＴＣＰ、または名前付きパイププロトコルなどの）を使用して、構造化されたデータを伝送することができる。
【００１７】
同様の符号が同様の要素を指す図面を参照すると、本発明の種々原理が、適切なコンピューティング環境において実施されているのが示されている。以下の説明は、本発明の図示する種々実施形態に基づき、本明細書で明示的に説明しない代替の種々実施形態に関して、本発明を限定するものと解釈されるべきではない。
【００１８】
以下の説明では、本発明の種々実施形態を、特に明記しない限り、１つまたは複数のコンピュータによって実行される動作の作用および記号表現を参照して説明する。このため、ときとして、コンピュータによって実行されるものとして述べられる、そのような作用および動作には、構造化された形態のデータを表す電気信号の、コンピュータの処理装置による操作が含まれるものと理解されたい。この操作は、データを変換するか、またはコンピュータのメモリシステム内のロケーションでデータを保持し、これにより、当業者によってよく理解されている形で、コンピュータの動作が再構成されるか、または別の形で変更される。データが保持されるデータ構造は、データのフォーマットによって定義された特定のプロパティを有する、メモリの物理的ロケーションである。しかし、本発明の種々原理を、以上の文脈で説明するが、以下に説明する作用および動作のいくつかは、ハードウェアで実施することもできることが当業者には理解されるとおり、限定的であることは意図していない。
【００１９】
図１は、以上のデバイス群のために使用可能な典型的なコンピュータアーキテクチャの概略図を示す。説明の目的で、描かれたアーキテクチャは、適切な環境の一例に過ぎず、本発明の用法または機能の範囲について何ら限定を示唆するものではない。また、コンピューティングシステムが、図１に示したコンポーネントのいずれの１つ、または組合せに関連する依存関係または要件も、有するものと解釈してはならない。
【００２０】
本発明の種々原理は、他の多数の汎用または専用のコンピューティングまたは通信の環境または構成で機能する。本発明で使用するのに適した周知のコンピューティングシステム、コンピューティング環境、およびコンピューティング構成の例には、移動電話、ポケットコンピュータ、パーソナルコンピュータ、サーバ、マルチプロセッサシステム、マイクロプロセッサベースのシステム、ミニコンピュータ、メインフレームコンピュータ、並びに以上のシステムまたはデバイスのいずれかを含む分散コンピューティング環境が含まれるが、以上には限定されない。
【００２１】
最も基本的な構成では、コンピューティングシステム１００は、通常、少なくとも１つの処理装置１０２、およびメモリ１０４を含む。メモリ１０４は、揮発性（ＲＡＭのように）、不揮発性（ＲＯＭ、フラッシュメモリなどのように）、またはその２つの何らかの組合せであることが可能である。この最も基本的な構成を、破線１０６で図１に示す。
【００２２】
記憶媒体デバイス群は、さらなる特徴および機能を有することが可能である。例えば、記憶媒体デバイス群には、ＰＣＭＣＩＡカード、磁気ディスクおよび光ディスク、並びに磁気テープを含むが、以上には限定されない追加のストレージ（リムーバブルなストレージ、およびリムーバブルでないストレージ）が含まれることが可能である。そのような追加のストレージを、図１にリムーバブルなストレージ１０８、およびリムーバブルでないストレージ１１０で示す。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報の格納のために任意の方法または技術で実装された、揮発性媒体および不揮発性媒体、リムーバブルな媒体、およびリムーバブルでない媒体が含まれる。メモリ１０４、リムーバブルなストレージ１０８、およびリムーバブルでないストレージ１１０はすべて、コンピュータ記憶媒体の例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、その他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク、その他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、その他の磁気記憶装置、並びに所望の情報を格納するのに使用することができ、コンピューティングシステムがアクセスすることができる他のあらゆる媒体が含まれるが、以上には限定されない。
【００２３】
本明細書で使用する、「モジュール（module）」または「コンポーネント（component）」という用語は、コンピューティングシステム上で実行されるソフトウェアオブジェクトまたはルーチンを指すことが可能である。本明細書で説明する、異なるコンポーネント、モジュール、エンジン、およびサービスは、コンピューティングシステム上で実行される（例えば、別々のスレッドとして）オブジェクトまたはプロセスとして実施されることが可能である。本明細書で説明するシステムおよび方法は、好ましくは、ソフトウェアで実施されるが、ソフトウェアとハードウェアでの実施、またはハードウェアでの実施も可能であり、企図されている。
【００２４】
コンピューティングシステム１００は、ホストが、例えば、ネットワーク１２０を介して、他のシステムおよびデバイスと通信することを可能にする通信チャネル１１２も含むことが可能である。ネットワーク１２０は、任意のネットワークタイプ（現在、存在しているか、または将来に開発されるかにかかわらず）を含むことが可能であるが、例には、トークンリング、イーサネット（登録商標）、Ｂｌｕｅｔｏｏｔｈ、８０２．１１、ＵＳＢ１３９４、ＳＭＳ、ＳＯＡＰ ｏｖｅｒ ＩＰなどが含まれる。通信チャネル１１２は、通信媒体の例である。通信媒体は、通常、搬送波などの変調されたデータ信号、または他のトランスポート機構でコンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを実現し、あらゆる情報配信媒体が含まれる。例として、限定としてではなく、通信媒体には、有線ネットワークおよび直接有線接続などの有線媒体、並びに音響媒体、無線媒体、赤外線媒体、およびその他の無線媒体などの無線媒体が含まれる。本明細書で使用するコンピュータ可読媒体という用語には、記憶媒体と通信媒体がともに含まれる。
【００２５】
また、コンピューティングシステム１００は、キーボード、マウス、ペン、音声入力コンポーネント、タッチ入力デバイスなどの、入力コンポーネント１１４も有することが可能である。出力コンポーネント１１６には、スクリーンディスプレイ、スピーカ、プリンタなど、並びにこれらを駆動するためのレンダリングモジュール群（しばしば、「アダプタ（adapters）」と呼ばれる）が含まれる。コンピューティングシステム１００は、電源１１８を有する。以上すべてのコンポーネントは、当技術分野で周知であり、ここで詳細に説明する必要はない。
【００２６】
図２は、本発明の種々原理を使用することができるネットワーク環境２００を示す。ネットワーク環境２００は、任意の数のコンピューティングシステムを含むことが可能である。しかし、明瞭にするため、第１のコンピューティングシステム２１０および第２のコンピューティングシステム２２０を示す。第１のコンピューティングシステム２１０および第２のコンピューティングシステムは、互いに通信するように結合可能である。この説明、および特許請求の範囲において、２つのコンピューティングシステムは、互いに通信するように結合される能力を有する場合、「通信するように結合可能（communicatively couplable）」である。この説明、および特許請求の範囲では、２つのコンピューティングシステムは、互いに通信する場合、「通信するように結合（communicatively coupled）」されている。２つのコンピューティングシステム２１０および２２０は、同一のコンピューティングシステムまたはコンピューティングデバイスの内部に組み込まれることも可能であるが、それでも、本発明の種々原理を使用して通信する。例えば、一方のコンピューティングシステムが、ストレージ機構を表す一方で、他方のコンピューティングシステムが、本発明の種々原理を使用して、そのストレージ機構から情報を送受信することも可能である。
【００２７】
本発明の種々原理によれば、バインドモジュール２１２が、構造化されたデータ２１１にアクセスし、構造化されたデータ２１１の構造を支配する構造化データプロトコルを、バイトストリームを供するバイトストリームプロトコルにバインドする役割をする。バイトストリーム通信モジュール２１４は、この通信モジュールが、バイトストリームプロトコルに従って他のコンピューティングシステムと通信するためにバイトストリームを供することを強調するように、「バイトストリーム（byte stream）」という用語で修飾されている。この説明、および特許請求の範囲では、「バイトストリーム」は、フィールドのシーケンスとして定義される。一部のケースでは、バイトストリームの長さは、先験的には（a priori）分からない。他のケースでは、長さは、既知であり、かつ／または固定サイズであることが可能である。以上のケースのすべてが、本明細書で使用される「バイトストリーム」の定義に含まれる。
【００２８】
一実施形態では、構造化されたデータ２１１は、例えば、拡張マークアップ言語（ＸＭＬ）ドキュメントなどの階層構造のドキュメントであることが可能である。１つの特定の実施形態では、ＸＭＬドキュメントは、簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）ドキュメントであることが可能である。適切なバイトストリームプロトコルの例には、例えば、伝送制御プロトコルおよび名前付きパイプが含まれる。バインドモジュール２１２は、構造化されたデータ２１１をバイトストリーム２１３に変換することによってバイトストリームプロトコルとのバインドを完了し、次に、バイトストリーム２１３をバイトストリーム通信モジュール２１４に提供する。次に、バイトストリーム通信モジュール２１４が、そのデータを、矢印２１５で表されるとおり、第２のコンピューティングシステム２２０に送信する。第２のコンピューティングシステム２２４における類似したバイトストリーム通信モジュール２１４が、そのデータを受信し、そのデータをバイトストリーム２２３として、バインドモジュール２２２に供する。バインドモジュールは、構造化されたデータ２２１を回復する。
【００２９】
本発明の種々原理を大まかに説明したので、特定の実施形態のより詳細な動作を、図３および図４を参照して説明する。図３は、構造化されたデータを、構造化されたデータの表現を含むとともに、その構造化されたデータに関するプロパティ情報を表すバイトストリームにまず変換することにより、構造化されたデータを送信するための方法３００の流れ図を示す。方法３００は、バインドモジュール２１２によって、構造化されたデータ２１１を第２のコンピューティングシステム２２０に送信する際に実行されることが可能である。
【００３０】
バインドモジュール２１２は、第２のコンピューティングシステムに伝送するために、構造化されたデータにアクセスする（動作３０１）。バインドモジュール２１２は、例えば、他のコンポーネント、または他のコンピューティングシステムから構造化されたデータの一部、または全部を受信すること、および／または構造化されたデータの一部、または全部を生成することにより、構造化されたデータにアクセスすることができる。前述したとおり、構造化されたドキュメントの例には、ＸＭＬドキュメントおよびＳＯＡＰエンベロープが含まれる。以下は、第２のコンピューティングシステム２２０に伝送されることが所望される可能性があるＳＯＡＰエンベロープ（ＳＯＡＰバージョン１．２を使用して表現されるが、本発明の種々原理は、このバージョンに限定されない）の一例を表す。
【００３１】
【表１】
【００３２】
この３行のＳＯＡＰエンベロープは、単なる例であり、本発明の実施形態の動作をさらに明瞭にする目的で、この説明全体で一例として使用される。
【００３３】
構造化されたデータ２１１にアクセスした後（動作３０１）、バインドモジュール２１２は、構造化されたデータ２１１を、バイトストリームの１つまたは複数のプロパティを共同で表す第１の複数のバイトと、構造化されたデータを共同で表す第２の複数のバイトとを含むバイトストリーム２１３に変換する（動作３０２）。図５は、バイトストリーム２１３の一例を表す典型的なバイトストリーム５００を概略で示す。
【００３４】
図５を参照すると、バイトストリーム５００は、左右の省略記号で表される、可能性のある他の構造化データコンポーネント５２０Ｂの中でとりわけ、構造化データコンポーネント５２０Ａを含む。初期情報は、図５におけるバイトストリーム５００内の右端のフィールドとして指定されており、次に続く情報が、左方向に連なっている。各構造化データコンポーネント５２０Ａおよび５２０Ｂは、対応する構造化されたデータを含む。例えば、構造化データコンポーネント５２０Ａは、対応する構造化されたデータ５２２Ａのバイトストリーム表現を含む。前述したとおり、構造化されたデータ５２２Ａは、例えば、ＳＯＡＰエンベロープであることが可能である。また、各構造化データコンポーネント５２０Ａおよび５２０Ｂは、オプションとして、構造化されたデータのバイトストリーム表現の長さを明らかにする長さコンポーネントも含むことが可能である。例えば、長さコンポーネント５２１Ａは、構造化されたデータ５２２Ａのバイトストリーム表現の長さを明らかにする。バイトストリームの長さが既知である（例えば、長さが、受信側に知られている固定サイズである）場合、長さフィールドは、オプションにされてもよい。また、長さは、他の何らかの機構を使用して、ネゴシエートされることも可能である。さらに、各構造化データコンポーネント５２０Ａおよび５２０Ｂは、オプションとして、他の情報も含むことが可能である。例えば、構造化データコンポーネント５２０Ａは、他のフィールド５２３Ａを含む。
【００３５】
バイトストリームの中に長さフィールド５１２Ａを有することにより、いくつかの利点が可能になる。第１に、形式に誤りがある（malformed）構造化データコンポーネントを、接続を閉じるのではなく、単に飛ばして進むことができる。接続を閉じることは、高くつく。というのは、接続を再開することは、時間、処理リソース、およびメモリリソースを要するからである。さらに、接続が閉じられていた時間中に受信されたであろうメッセージの一部が、失われる可能性がある。第２に、メッセージを処理するアプリケーションコードを呼び出す前に、構造化されたデータ全体をメモリの中に読み込むことができる。これにより、アプリケーションが、メッセージの残りの部分が利用可能になるのを待つ必要なしに、メッセージに完全にアクセスし、処理を完了することが可能になる。
【００３６】
また、バイトストリーム５００は、バイトストリーム５００全体についてのプロパティを定義するストリームプロパティ５１０も含む。それらのプロパティは、バイトストリーム５００のプロパティレコードと考えることもできる。そのようなプロパティレコードの例を示す。図示していないが、構造化されたデータは、ストリームプロパティをリセットするように各プロパティフィールドの間にインタリーブすることができる。
【００３７】
最初に、バイトストリーム５００のフレーミングバージョンを定義するバージョンレコード５１１が図示されている。受信側コンピューティングシステムが、そのバージョンを、後続のプロパティレコードをどのように解釈すべきか、かつ／または構造化されたデータをどのように回復すべきかを支配する一組の規則と互いに関係付けることができる。例えば、バージョン情報は、許容できるプロパティレコードのリスト、およびそれらのレコードの対応する意味と互いに関係付けられることが可能である。
【００３８】
次に、通信のモードを定義する通信モードレコード５１２が図示されている。通信モードに関してさらに、図６Ａないし図６Ｃに関連して以下に説明する。簡単に述べると、通信モードは、メッセージ交換のパターンおよび信頼性を指定する際の柔軟性を可能にする。モードレコード５１２を有することは、単一のネットワークアドレス（例えば、単一のＴＣＰポート番号）が異なるモードでメッセージを受信することを可能にする。ＴＣＰポート番号は、所与のマシン用の限られたリソースであるという点で、幾分、高くつく。
【００３９】
ｖｉａレコード５１３が、データストリーム５００に関する目標宛先を定義する。バインドモジュールは、通信プロトコルスタックの中に存在することが可能であり、プロトコルスタックにおける上位レイヤが、構造化されたデータ２１１（または構造化されたデータ２１１内で表される情報）を別の宛先に送信する。そうすることで、その情報に関する最終的な宛先は、ｖｉａレコード５１３によって表されるコンピューティングシステムよりも、通信パスにおいてさらに先であることが可能である。それでも、ｖｉａレコード５１３は、次のバインドモジュールレベル宛先のアドレスを表す。ｖｉａレコード５１３は、バイトストリーム５００を完全に解析し、構造化されたデータ５２２Ａにアクセスするのに必要とされる処理リソースを消費する必要なしに、受信側システムによる何らかのレベルのディスパッチを可能にする。ｖｉａレコード５１３の値は、既定で、以前のｖｉａ値になり、バイトストリームのサイズが縮小されることも可能である。
【００４０】
符号化フィールド５１４は、含まれる構造化データコンポーネント５２２に関する符号化フォーマットを定義することができる。これにより、システムが、接続上で複数の符号化をサポートすることが可能になり、それにより、必要とされる接続の数が削減されることが可能である。また、これにより、単一のアドレス（例えば、単一のＴＣＰポート番号）が、異なる符号化のために使用されることも可能になる。前述したとおり、ＴＣＰポート番号は、高くつく可能性がある。コンテンツタイプに関して周知の値と拡張可能な値の両方をサポートすることにより、共通の値のためにワイヤサイズ（wire size）を犠牲にすることなしに、拡張性が可能になる。例えば、周知のコンテンツタイプを単一のバイトで符号化することができるが、ＭＩＭＥ媒体タイプに対応する文字列の値を示すことにより、さらなるコンテンツタイプが可能である（ただし、より冗長（verbose）である）。
【００４１】
アップグレードフィールド５１５により、セキュリティアップグレードが要求されるか否か、またはセキュリティアップグレードに応答が行われるか否かが示される。２つのコンピューティングシステムが、セキュリティアップグレード要求を完了し、その後に、戻された肯定応答が行われると、その２つのコンピューティングシステムは、セキュリティコンポーネント（例えば、Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）を使用して、セキュリティのネゴシエーションをさらに行うことができる。アップグレードフィールド５１５は、さらなるネゴシエーションのために使用される必要はないが、セキュリティアップグレードを要求し、そのセキュリティアップグレードが可能であることを確認するのに少なくとも使用して、その後のネゴシエーションが、セキュリティアップグレードを完成させることができるようにすることができる。アップグレードフィールド５１５を使用する場合、構造化データコンポーネント５２０が、まったく存在していなくてもよい。このアップグレード機構は、セキュリティで保護された形で通信するのに別個の接続が要求されないため、有用である。さらに、アップグレードフィールド５１５は、例えば、圧縮および／または暗号化をネゴシエートするなどの、完全なストリームの他の変換のために使用することもできる。
【００４２】
障害フィールド５１６は、例えば、前のデータストリームが、正しい形式（well formed）ではなかった、またはそれ以外で応答を受けることができない場合などに、障害情報の通信を可能にする。このケースでも、障害フィールド５１６を使用する場合に、構造化データコンポーネント５２０が、まったく存在していなくてもよい。
【００４３】
その他フィールド５１７は、可能なプロパティレコードのリストが、拡張可能であることを表す。例えば、その他フィールド５１７は、例えば、圧縮レベルまたは暗号化レベルなどの、ストリームについてネゴシエーションが行われるべき他の情報を含むことが可能である。
【００４４】
以下は、対応するバイトストリームに変換される典型的な３行のＳＯＡＰエンベロープの具体的な一例を示す。この具体的な例では、読者が、各行で提示されるバイトストリームの対応するコンポーネントを理解するのを助ける追加のテキストが、各行に追加されている。各行の左端は、括弧内の２桁の番号であり、その２桁は、行番号を表す。この例では、行番号は、０１から２４までの範囲である。行番号の閉じ括弧の直後に来るのが、バイトをそれぞれが表す２つの１６進数字の１つまたは複数のクラスタである。各行を閉じるのが、２重スラッシュ（double foward slash）「／／」で始まる、人間が読むことができる注釈（remarks）ステートメントである。バイトストリームは、もちろん、バイトのストリームであり、行に編成されてはいない。以下の例は、論理的な境界に沿って人工的に行に編成されて、読者を助けている。
【００４５】
【表２】
【００４６】
第１の行（すなわち、行０１）は、バイト００を含む。各レコードは、複数のバイトを含むことが可能である。この例では、各レコード内の最初のバイトは、レコードタイプを明らかにする。このケースで００は、レコードがバージョンレコードであることを示す。第２の行および第３の行はそれぞれ、１バイトを含み、第２のリストは、メジャーバージョンを明らかにし、第３の行は、マイナーバージョンを明らかにする。行０１ないし行０３は一緒になって、図５のバージョンレコード５１１の一例を表す。
【００４７】
行０４は、次のレコードに関するレコードタイプ識別子を表す１バイトを含む。ここで、バイト０１は、通信モードレコードを表す。行０５は、動作モードが単信であることを表す値３を有するバイトを含む。他の典型的な通信モードには、多重、２重、およびシングルトン（ｓｉｎｇｌｅｔｏｎ）が含まれる。これらの通信モードのそれぞれの意味を、図６Ａないし図６Ｃに関連して以下にさらに説明する。通信モードの数は、さらなるフレーミングバージョンを追加すること、およびバージョンレコードの中でバージョンを適切に明らかにすることにより、拡張することができる。行０４と行０５は一緒になって、図５のモードレコード５１２の一例を表す。
【００４８】
行０６は、ｖｉａレコードの先頭を示す、レコードタイプ識別子バイト０２を含む。行０７は、このケースでは２３バイトである、ｖｉａレコードの長さを明らかにする。行０８ないし行１０は、宛先アドレスを「http://example.org/dest」として定義した２３個のＵＴＦ−８文字を表す２３バイトを含む。行０６ないし行１０は一緒になって、ｖｉａレコード５１３の例を表す。
【００４９】
行１１は、符号化レコードの先頭を示す、レコードタイプ識別子バイト０３を含む。行１２は、この例では、ＵＴＦ−８およびＳＯＡＰバージョン１．２に相当する、３という値を有するバイトを含む。行１１および行１２は一緒になって、図５の符号化レコード５１４の一例を表す。
【００５０】
行１３は、サイズド（sized）エンベロープレコードの先頭を示す、レコードタイプ識別子バイト０６を含む。サイズドエンベロープレコードは、ＳＯＡＰエンベロープのサイズのＩＤと、ＳＯＡＰエンベロープ自体をともに含む。具体的には、行１４は、ＳＯＡＰエンベロープの長さが、７５バイトである（または、ＵＴＦ−８において各文字を表すのに１バイトが使用されるので、７５文字でもある）と明らかにする。行１５ないし行２４は、この例において最初に提示した３行のＳＯＡＰエンベロープに関するＵＴＦ−８を表す。したがって、行１５ないし行２４は共同で、図５の構造化されたデータ５２２Ａのバイトストリーム表現を表す。行１４は、図５の長さフィールド５２１Ａを表す。このため、行１３ないし行２４は共同で、図５の構造化データコンポーネント５２０Ａを表す。
【００５１】
他のプロパティレコードを使用して、セキュリティアップグレードの要求または応答を表す、障害を表す、またはその他の情報を表すこともできる。
【００５２】
バイトストリーム５００は、現時点で、バイトストリームであるため、ユーザデータグラムプロトコル（ＵＤＰ）、Ｍｉｃｒｏｓｏｆｔメッセージキュー（ＭＳＭＱ）、ＴＣＰ、または名前付きパイプなどのバイトストリームを供する任意の通信モジュールに与えられることが可能である。したがって、図３を参照すると、バイトストリームを生成した後、バインドモジュールは、次に、そのバイトストリーム２１３を、他のコンピューティングシステムと通信するためにバイトストリームを受け入れるバイトストリーム通信モジュール２１４に送る（動作２０３）。
【００５３】
他のプロパティレコードを使用して、セキュリティアップグレードの要求または応答を表現する、障害を表現する、またはその他の情報を表現することもできる。
【００５４】
図４は、構造化されたデータと、バイトストリームのプロパティの両方を表すバイトストリームをまず受信することにより、構造化されたデータを受信するための方法４００の流れ図を示す。方法４００は、第２のコンピューティングシステム２２０におけるバインドモジュール２２２によって実行されることが可能であり、あるいはさらに、メッセージを受信する際に、第１のコンピューティングシステム２１０におけるバインドモジュール２１２によって実行されることが可能である。いずれの場合も、メッセージを受信すると、バイトストリーム通信モジュール２２４（または２１４）は、バイトストリームを対応するバインドモジュール２２２（または２１２）に与える。
【００５５】
すると、バインドモジュールは、バイトストリームを受け取る（動作４０１）。バインドモジュールは、プロパティレコード群を使用して、バージョン情報、通信モードなどを識別することができる。受信側バインドモジュールは、送信側バインドモジュールが、バイトストリームを構築するのに使用したのと同一のフレーミング規則を使用して、バイトストリームを解釈する。したがって、受信側バインドモジュールは、次に、バイトストリームから構造化されたデータを回復することができる（動作４０２）。送受信するプロセスは、頻繁に繰り返されることが可能である。
【００５６】
したがって、本発明の種々原理は、バイトストリーム（ＴＣＰなどの）を供する通信モジュールを使用して、構造情報（ＳＯＡＰエンベロープなどの）を通信するための柔軟性のある機構を説明する。そのような通信モジュールとインターフェースをとる能力は、そのような通信モジュールの柔軟性を利用して、メッセージ交換のパターンおよび信頼性に関するより広い範囲の選択を可能にすることができることを意味する。ＴＣＰは、単一要求−単一応答メッセージパターンに限定されない。さらに多くのメッセージパターンを使用して、例えば、ＳＯＡＰ−ｏｖｅｒ−ＨＴＴＰの、最も本質的な弱点の１つを克服することができる。さらに、この機構は、フレーミングプロトコルに組み込まれた、好都合なセキュリティアップグレードを可能にする。
【００５７】
また、通信モードも変更することができる。一実施形態では、これは、図５のようなバイトストリーム５００のストリームプロパティ５１０のモードフィールド５１２の中に通信モード情報を含めることによって実行される。図６Ａないし図６Ｃは、通信モードレコードによって設定されることが可能な様々な通信モードのいくつかの例を示す。各図では、コンポーネント６１０が、第１のコンピューティングシステム上の単一の接続（例えば、ＴＣＰ接続または名前付きパイプ）を表し、他方、コンポーネント６２０が、第２のコンピューティングシステム上の単一の接続（例えば、ＴＣＰ接続または名前付きパイプ接続）を表す。
【００５８】
図６Ａは、多重モードを示す。このモードでは、単一の接続６１０Ａが、単一の接続６２０Ａにデータを送信する。バインドモジュールに対応するバインドレイヤで、様々なメッセージを受信するのに単一の接続が使用されていても、それらのメッセージは異なるエンドポイントにルーティングされるべきである。例として、１つのＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）−ＴＣＰポート（例えば、接続６１０Ａに関連する）に関連するユーザが、別のＵＲＩ−ＴＣＰポート（例えば、接続６２０Ａに関連する）によって表されるオンライン書店とインターフェースをとることを所望するものと想定されたい。その単一のＴＣＰポートは、いくつかの異なるサービスを提供することができる。例えば、おそらく、１つのサービスが書店在庫目録情報を提供する一方で、別のサービスは書籍購入を提供する。各要求のために異なる接続を使用する必要がない。代わりに、適切な要求６１１Ａが、在庫目録サービスに対する適切なルーティング６１２Ａないし６１４Ａのために、接続６２０Ａに送信され、同一の接続が、書籍購入のために後に使用される。図５の実施形態では、このルーティングは、ｖｉａレコード５１３内の情報を使用して達せられることが可能である。
【００５９】
図６Ｂは、第１のコンピューティングシステムに関して単一の接続６１０Ｂを使用して、第２のコンピューティングシステムにおける単一の接続６２０Ｂにメッセージ６１１Ｂを信頼できる形で送信することができる単信モードを示す。この単信モードも同様に、図５の実施形態におけるモードレコード５１２内で明らかにされることが可能である。信頼性を確実にするため、矢印６１２Ｂで表される、リターン受信確認メッセージまたはリターン受信確認パケットが存在することが可能である。接続６２０Ｂは、バイトストリーム６１３をプロトコルスタックの他のレイヤに提供する。このモードでは、ＴＣＰおよび名前付きパイプのケースにおける接続間で、中間のバインドレベルモジュールは、まったく存在しない。しかし、信頼性は、さらに保証される。この信頼性をもたらす受信確認メッセージは、構造データ自体（例えば、図５の構造化されたデータ５２２Ａ）の中に入っていること、または他の何らかの機構によることが可能である。
【００６０】
図６Ｃは、第１のコンピューティングシステムに関して単一の接続６１０Ｃを使用して、第２のコンピューティングシステムにおける単一の接続６２０Ｃにメッセージ６１１Ｃを信頼できる形で送信する２重モードを示す。この２重モードは、図５の実施形態におけるモードレコード５１２内で明らかにされることが可能である。信頼性を向上させるように、関連する受信確認メッセージ６１２Ｃが存在することが可能であり、接続６２０Ｃは、プロトコルスタックにおける他のレイヤに、対応するバイトストリーム６１３Ｃを供する。同様に、反対方向で、第２のコンピューティングシステムに関して単一の接続６２０Ｃが使用されて、第１のコンピューティングシステムにおける同一の接続６１０Ｃにメッセージ６２１Ｃが、信頼できる形で送信される。信頼性を向上させるように、関連する受信確認メッセージ６２２Ｃが存在することが可能であり、接続６１０Ｃは、プロトコルスタックにおける他のレイヤに、対応するバイトストリーム６２３Ｃを供する。
【００６１】
図示していないが、「シングルトン（singleton）」モードも、図５の実施形態におけるモードフィールド５１２を使用して選択されることが可能である。単一の接続を使用するこのシングルトンは、サイズが制限されていないバイトストリームを第２のコンピューティングシステムに送信するのに使用される。
【００６２】
本発明は、本発明の趣旨または基本的な特徴から逸脱することなく、他の特定の形態で実施することもできる。説明した種々実施形態は、すべての点で、単に例示的であり、限定的ではないものと見なされるべきである。したがって、本発明の範囲は、以上の説明によってではなく、添付の特許請求の範囲によって示される。特許請求の範囲の均等の趣旨および範囲に含まれるすべての変更が、特許請求の範囲に包含されるものとする。
【図面の簡単な説明】
【００６３】
【図１】本発明の種々特徴を実施することができる適切なコンピューティングシステムを示す図である。
【図２】本発明の種々原理を使用できるネットワーク環境を示す図である。
【図３】構造化されたデータを、構造化されたデータの表現を含むとともに、その構造化されたデータに関するプロパティ情報を表すバイトストリームにまず変換することにより、構造化されたデータを送信するための方法を示す図である。
【図４】構造化されたデータと、バイトストリームのプロパティをともに表すバイトストリームをまず受信することにより、構造化されたデータを受信するための方法を示す図である。
【図５】構造化されたデータと、バイトストリームのプロパティをともに表すバイトストリームのデータ構造を示す図である。
【図６Ａ】複数のアウトバウンド通信を、単一の受信者コンピューティングシステム上で実行される異なるプロセスに通信するのに、単一の接続が使用される通信モードを示す図である。
【図６Ｂ】信頼できる形で単方向通信を行うのに単一の接続が使用される通信モードを示す図である。
【図６Ｃ】信頼できる形で双方向通信を行うのに単一の接続が使用される通信モードを示す図である。
【符号の説明】
【００６４】
１０２ 処理装置
１０８ リムーバブルなストレージ
１１０ リムーバブルでないストレージ
１１２ 通信チャネル
１１４ 入力コンポーネント
１１６ 出力コンポーネント
１１８ 電源
１２０ ネットワーク
２００ ネットワーク環境
２１０ 第１のコンピューティングシステム
２１１，２２１ 構造化データ
２１２，２２２ バインドモジュール
２１３，２２３，５００ バイトストリーム
２１４，２２４ バイトストリーム通信モジュール
２２０ 第２のコンピューティングシステム
５１０ ストリームプロパティ
５２０Ａ 構造化データコンポーネント
５２２Ａ 構造化データ
【特許請求の範囲】
【請求項１】
第１のコンピューティングシステムを含むネットワーク環境であって該コンピューティングシステムが第２のコンピューティングシステムに通信するように結合可能なネットワーク環境において、前記第１のコンピューティングシステムが、前記第２のコンピューティングシステムに構造化データを、対応するバイトストリームを使用して送信する方法であって、
前記第２のコンピューティングシステムに伝送するために、構造化データにアクセスする動作と、
バイトストリームを生成する動作であって、該バイトストリームが、該バイトストリームの１つまたは複数のプロパティを共同で表す第１の複数のバイトと、前記構造化データを共同で表す第２の複数のバイトとを含む動作と、
該バイトストリームを、他のコンピューティングシステムと通信するためにバイトストリームを受け入れるバイトストリーム通信モジュールに渡す動作と
を含むことを特徴とする方法。
【請求項２】
前記アクセスする動作は、前記第１のコンピューティングシステム自体が前記構造化データを生成する動作を含むことを特徴とする請求項１の方法。
【請求項３】
前記アクセスする動作は、前記第１のコンピューティングシステムが前記構造化データを別のコンピューティングシステムから受け取る動作を含むことを特徴とする請求項１の方法。
【請求項４】
前記構造化データはＸＭＬを含むことを特徴とする請求項１の方法。
【請求項５】
前記構造化データはＳＯＡＰエンベロープであることを特徴とする請求項１の方法。
【請求項６】
前記バイトストリーム通信モジュールは名前付きパイプ通信モジュールであることを特徴とする請求項５の方法。
【請求項７】
前記バイトストリーム通信モジュールは伝送制御プロトコル（ＴＣＰ）通信モジュールであることを特徴とする請求項５の方法。
【請求項８】
前記バイトストリーム通信モジュールはユーザデータグラムプロトコル（ＵＤＰ）通信モジュールであることを特徴とする請求項５の方法。
【請求項９】
前記バイトストリーム通信モジュールは名前付きパイプ通信モジュールであることを特徴とする請求項１の方法。
【請求項１０】
前記バイトストリーム通信モジュールは伝送制御プロトコル（ＴＣＰ）通信モジュールであることを特徴とする請求項１の方法。
【請求項１１】
前記バイトストリーム通信モジュールはユーザデータグラムプロトコル（ＵＤＰ）通信モジュールであることを特徴とする請求項１の方法。
【請求項１２】
前記バイトストリーム通信モジュールはＭｉｃｒｏｓｏｆｔメッセージキュー（ＭＳＭＱ）通信モジュールであることを特徴とする請求項１の方法。
【請求項１３】
前記１つまたは複数のプロパティは、前記第２の複数のバイトの中に含められることが可能なプロパティの許容できる集合を定義する、前記バイトストリームのバージョンを含むことを特徴とする請求項１の方法。
【請求項１４】
前記１つまたは複数のプロパティは前記バイトストリームの通信モードを含むことを特徴とする請求項１の方法。
【請求項１５】
前記通信モードは、前記第１のコンピューティングシステムに関して単一の接続を使用して、前記第２のコンピューティングシステム上の異なるプロセスに複数のバイトストリームを送信することができるモードを含むことを特徴とする請求項１４の方法。
【請求項１６】
前記通信モードは、前記第１のコンピューティングシステムに関して単一の接続を使用して、前記第２のコンピューティングシステムにバイトストリームを信頼できる形で送信することができるモードを含むことを特徴とする請求項１４の方法。
【請求項１７】
前記通信モードはまた、前記第１のコンピューティングシステムに関して前記単一の接続を使用して、前記第２のコンピューティングシステムからバイトストリームを信頼できる形で受信することができるモードを含むことを特徴とする請求項１６の方法。
【請求項１８】
前記バイトストリームの前記通信モードは、単一の接続を使用して、サイズが制限されていないバイトストリームが前記第２のコンピューティングシステムに送信されるモードを含むことを特徴とする請求項１４の方法。
【請求項１９】
前記１つまたは複数のプロパティは前記第１の複数のバイトに関する符号化フォーマットを含むことを特徴とする請求項１の方法。
【請求項２０】
前記１つまたは複数のプロパティは目標宛先Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を含むことを特徴とする請求項１の方法。
【請求項２１】
前記バイトストリームが第１のバイトストリームであり、前記構造化データが第１の構造化データであって、さらに、
第２のバイトストリームの１つまたは複数のプロパティを共同で表す第３の複数のバイトと、第２の構造化データを共同で表す第４の複数のバイトとを含む前記第２のバイトストリームを前記バイトストリーム通信モジュールから受信する動作、および、前記第２の構造化データを前記第２のバイトストリームから回復する動作を含むことを特徴とする請求項１の方法。
【請求項２２】
第１のコンピューティングシステムを含むネットワーク環境であって該コンピューティングシステムが第２のコンピューティングシステムに通信するように結合可能なネットワーク環境において使用するための、前記第１のコンピューティングシステムが、前記第２のコンピューティングシステムに構造化データを、対応するバイトストリームを使用して送信する方法を実施するためのコンピュータプログラムであって、該プログラムはコンピュータ実行可能命令を含んだコンピュータ可読媒体に含まれ、該命令が前記第１のコンピューティングシステムの１つまたは複数のプロセッサで実行されると該システムに該方法を実行させ、該方法が、
前記第１のコンピューティングシステムの１つまたは複数のプロセッサによって実行されて、前記第２のコンピューティングシステムに伝送するために、構造化データにアクセスする動作と、
バイトストリームを生成する動作であって、該バイトストリームが、該バイトストリームの１つまたは複数のプロパティを共同で表す第１の複数のバイトと、前記構造化データを共同で表す第２の複数のバイトとを含む動作と、
該バイトストリームを、他のコンピューティングシステムと通信するためにバイトストリームを受け入れるバイトストリーム通信モジュールに渡す動作と
を含むことを特徴とするコンピュータプログラム。
【請求項２３】
前記構造化データにアクセスする前記動作は、前記第１のコンピューティングシステム自体が前記構造化データを生成する動作を含むことを特徴とする請求項２２のコンピュータプログラム。
【請求項２４】
前記構造化データはＸＭＬを含むことを特徴とする請求項２２のコンピュータプログラム。
【請求項２５】
前記構造化データはＳＯＡＰエンベロープであることを特徴とする請求項２２のコンピュータプログラム。
【請求項２６】
前記バイトストリーム通信モジュールは名前付きパイプ通信モジュールであることを特徴とする請求項２５のコンピュータプログラム。
【請求項２７】
前記バイトストリーム通信モジュールは伝送制御プロトコル（ＴＣＰ）通信モジュールであることを特徴とする請求項２５のコンピュータプログラム。
【請求項２８】
前記バイトストリーム通信モジュールはユーザデータグラムプロトコル（ＵＤＰ）通信モジュールであることを特徴とする請求項２５のコンピュータプログラム。
【請求項２９】
前記バイトストリーム通信モジュールは名前付きパイプ通信モジュールであることを特徴とする請求項２２のコンピュータプログラム。
【請求項３０】
前記バイトストリーム通信モジュールは伝送制御プロトコル（ＴＣＰ）通信モジュールであることを特徴とする請求項２２のコンピュータプログラム。
【請求項３１】
前記バイトストリーム通信モジュールはユーザデータグラムプロトコル（ＵＤＰ）通信モジュールであることを特徴とする請求項２２のコンピュータプログラム。
【請求項３２】
前記バイトストリーム通信モジュールはＭｉｃｒｏｓｏｆｔメッセージキュー（ＭＳＭＱ）通信モジュールであることを特徴とする請求項２２のコンピュータプログラム。
【請求項３３】
前記バイトストリームの前記１つまたは複数のプロパティは、
前記第２の複数のバイトの中に含められることが可能なプロパティの許容できる集合を定義する、前記バイトストリームのバージョン、
前記バイトストリームの通信モード、
前記第１の複数のバイトに関する符号化フォーマット、および、
目標宛先Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）の１つまたは複数の表現
を含むことを特徴とする請求項２２のコンピュータプログラム。
【請求項３４】
前記バイトストリームが第１のバイトストリームであり、前記構造化データが第１の構造化データであり、前記方法は、
第２のバイトストリームの１つまたは複数のプロパティを共同で表す第３の複数のバイトと、第２の構造化データを共同で表す第４の複数のバイトとを含む前記第２のバイトストリームを前記バイトストリーム通信モジュールから受信する動作と、
前記第２の構造化データを前記第２のバイトストリームから回復する動作をさらに含むことを特徴とする請求項２２のコンピュータプログラム。
【請求項３５】
前記１つまたは複数のコンピュータ可読媒体は物理的メモリ媒体であることを特徴とする請求項２２のコンピュータプログラム。
【請求項３６】
前記物理的メモリ媒体は不揮発性メモリを含むことを特徴とする請求項３５のコンピュータプログラム。
【請求項３７】
前記物理的メモリ媒体はシステムメモリを含むことを特徴とする請求項３５のコンピュータプログラム。
【請求項３８】
構造化データを共同で表す第１の複数のバイトと、
前記バイトストリームのバージョン、前記バイトストリームの通信モード、前記第１の複数のバイトに関する符号化フォーマット、および目標宛先ＵＲＩを含む、前記バイトストリームの１つまたは複数のプロパティを共同で表す第２の複数のバイトと
を含むバイトストリームデータ構造を有することを特徴とする１つまたは複数のコンピュータ可読媒体。
【請求項３９】
前記構造化データはＳＯＡＰエンベロープであることを特徴とする請求項３８のコンピュータ可読媒体。
【請求項４０】
物理的メモリ媒体であることを特徴とする請求項３８のコンピュータ可読媒体。
【請求項４１】
前記物理的メモリ媒体は不揮発性メモリを含むことを特徴とする請求項４０のコンピュータ可読媒体。
【請求項１】
第１のコンピューティングシステムを含むネットワーク環境であって該コンピューティングシステムが第２のコンピューティングシステムに通信するように結合可能なネットワーク環境において、前記第１のコンピューティングシステムが、前記第２のコンピューティングシステムに構造化データを、対応するバイトストリームを使用して送信する方法であって、
前記第２のコンピューティングシステムに伝送するために、構造化データにアクセスする動作と、
バイトストリームを生成する動作であって、該バイトストリームが、該バイトストリームの１つまたは複数のプロパティを共同で表す第１の複数のバイトと、前記構造化データを共同で表す第２の複数のバイトとを含む動作と、
該バイトストリームを、他のコンピューティングシステムと通信するためにバイトストリームを受け入れるバイトストリーム通信モジュールに渡す動作と
を含むことを特徴とする方法。
【請求項２】
前記アクセスする動作は、前記第１のコンピューティングシステム自体が前記構造化データを生成する動作を含むことを特徴とする請求項１の方法。
【請求項３】
前記アクセスする動作は、前記第１のコンピューティングシステムが前記構造化データを別のコンピューティングシステムから受け取る動作を含むことを特徴とする請求項１の方法。
【請求項４】
前記構造化データはＸＭＬを含むことを特徴とする請求項１の方法。
【請求項５】
前記構造化データはＳＯＡＰエンベロープであることを特徴とする請求項１の方法。
【請求項６】
前記バイトストリーム通信モジュールは名前付きパイプ通信モジュールであることを特徴とする請求項５の方法。
【請求項７】
前記バイトストリーム通信モジュールは伝送制御プロトコル（ＴＣＰ）通信モジュールであることを特徴とする請求項５の方法。
【請求項８】
前記バイトストリーム通信モジュールはユーザデータグラムプロトコル（ＵＤＰ）通信モジュールであることを特徴とする請求項５の方法。
【請求項９】
前記バイトストリーム通信モジュールは名前付きパイプ通信モジュールであることを特徴とする請求項１の方法。
【請求項１０】
前記バイトストリーム通信モジュールは伝送制御プロトコル（ＴＣＰ）通信モジュールであることを特徴とする請求項１の方法。
【請求項１１】
前記バイトストリーム通信モジュールはユーザデータグラムプロトコル（ＵＤＰ）通信モジュールであることを特徴とする請求項１の方法。
【請求項１２】
前記バイトストリーム通信モジュールはＭｉｃｒｏｓｏｆｔメッセージキュー（ＭＳＭＱ）通信モジュールであることを特徴とする請求項１の方法。
【請求項１３】
前記１つまたは複数のプロパティは、前記第２の複数のバイトの中に含められることが可能なプロパティの許容できる集合を定義する、前記バイトストリームのバージョンを含むことを特徴とする請求項１の方法。
【請求項１４】
前記１つまたは複数のプロパティは前記バイトストリームの通信モードを含むことを特徴とする請求項１の方法。
【請求項１５】
前記通信モードは、前記第１のコンピューティングシステムに関して単一の接続を使用して、前記第２のコンピューティングシステム上の異なるプロセスに複数のバイトストリームを送信することができるモードを含むことを特徴とする請求項１４の方法。
【請求項１６】
前記通信モードは、前記第１のコンピューティングシステムに関して単一の接続を使用して、前記第２のコンピューティングシステムにバイトストリームを信頼できる形で送信することができるモードを含むことを特徴とする請求項１４の方法。
【請求項１７】
前記通信モードはまた、前記第１のコンピューティングシステムに関して前記単一の接続を使用して、前記第２のコンピューティングシステムからバイトストリームを信頼できる形で受信することができるモードを含むことを特徴とする請求項１６の方法。
【請求項１８】
前記バイトストリームの前記通信モードは、単一の接続を使用して、サイズが制限されていないバイトストリームが前記第２のコンピューティングシステムに送信されるモードを含むことを特徴とする請求項１４の方法。
【請求項１９】
前記１つまたは複数のプロパティは前記第１の複数のバイトに関する符号化フォーマットを含むことを特徴とする請求項１の方法。
【請求項２０】
前記１つまたは複数のプロパティは目標宛先Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を含むことを特徴とする請求項１の方法。
【請求項２１】
前記バイトストリームが第１のバイトストリームであり、前記構造化データが第１の構造化データであって、さらに、
第２のバイトストリームの１つまたは複数のプロパティを共同で表す第３の複数のバイトと、第２の構造化データを共同で表す第４の複数のバイトとを含む前記第２のバイトストリームを前記バイトストリーム通信モジュールから受信する動作、および、前記第２の構造化データを前記第２のバイトストリームから回復する動作を含むことを特徴とする請求項１の方法。
【請求項２２】
第１のコンピューティングシステムを含むネットワーク環境であって該コンピューティングシステムが第２のコンピューティングシステムに通信するように結合可能なネットワーク環境において使用するための、前記第１のコンピューティングシステムが、前記第２のコンピューティングシステムに構造化データを、対応するバイトストリームを使用して送信する方法を実施するためのコンピュータプログラムであって、該プログラムはコンピュータ実行可能命令を含んだコンピュータ可読媒体に含まれ、該命令が前記第１のコンピューティングシステムの１つまたは複数のプロセッサで実行されると該システムに該方法を実行させ、該方法が、
前記第１のコンピューティングシステムの１つまたは複数のプロセッサによって実行されて、前記第２のコンピューティングシステムに伝送するために、構造化データにアクセスする動作と、
バイトストリームを生成する動作であって、該バイトストリームが、該バイトストリームの１つまたは複数のプロパティを共同で表す第１の複数のバイトと、前記構造化データを共同で表す第２の複数のバイトとを含む動作と、
該バイトストリームを、他のコンピューティングシステムと通信するためにバイトストリームを受け入れるバイトストリーム通信モジュールに渡す動作と
を含むことを特徴とするコンピュータプログラム。
【請求項２３】
前記構造化データにアクセスする前記動作は、前記第１のコンピューティングシステム自体が前記構造化データを生成する動作を含むことを特徴とする請求項２２のコンピュータプログラム。
【請求項２４】
前記構造化データはＸＭＬを含むことを特徴とする請求項２２のコンピュータプログラム。
【請求項２５】
前記構造化データはＳＯＡＰエンベロープであることを特徴とする請求項２２のコンピュータプログラム。
【請求項２６】
前記バイトストリーム通信モジュールは名前付きパイプ通信モジュールであることを特徴とする請求項２５のコンピュータプログラム。
【請求項２７】
前記バイトストリーム通信モジュールは伝送制御プロトコル（ＴＣＰ）通信モジュールであることを特徴とする請求項２５のコンピュータプログラム。
【請求項２８】
前記バイトストリーム通信モジュールはユーザデータグラムプロトコル（ＵＤＰ）通信モジュールであることを特徴とする請求項２５のコンピュータプログラム。
【請求項２９】
前記バイトストリーム通信モジュールは名前付きパイプ通信モジュールであることを特徴とする請求項２２のコンピュータプログラム。
【請求項３０】
前記バイトストリーム通信モジュールは伝送制御プロトコル（ＴＣＰ）通信モジュールであることを特徴とする請求項２２のコンピュータプログラム。
【請求項３１】
前記バイトストリーム通信モジュールはユーザデータグラムプロトコル（ＵＤＰ）通信モジュールであることを特徴とする請求項２２のコンピュータプログラム。
【請求項３２】
前記バイトストリーム通信モジュールはＭｉｃｒｏｓｏｆｔメッセージキュー（ＭＳＭＱ）通信モジュールであることを特徴とする請求項２２のコンピュータプログラム。
【請求項３３】
前記バイトストリームの前記１つまたは複数のプロパティは、
前記第２の複数のバイトの中に含められることが可能なプロパティの許容できる集合を定義する、前記バイトストリームのバージョン、
前記バイトストリームの通信モード、
前記第１の複数のバイトに関する符号化フォーマット、および、
目標宛先Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）の１つまたは複数の表現
を含むことを特徴とする請求項２２のコンピュータプログラム。
【請求項３４】
前記バイトストリームが第１のバイトストリームであり、前記構造化データが第１の構造化データであり、前記方法は、
第２のバイトストリームの１つまたは複数のプロパティを共同で表す第３の複数のバイトと、第２の構造化データを共同で表す第４の複数のバイトとを含む前記第２のバイトストリームを前記バイトストリーム通信モジュールから受信する動作と、
前記第２の構造化データを前記第２のバイトストリームから回復する動作をさらに含むことを特徴とする請求項２２のコンピュータプログラム。
【請求項３５】
前記１つまたは複数のコンピュータ可読媒体は物理的メモリ媒体であることを特徴とする請求項２２のコンピュータプログラム。
【請求項３６】
前記物理的メモリ媒体は不揮発性メモリを含むことを特徴とする請求項３５のコンピュータプログラム。
【請求項３７】
前記物理的メモリ媒体はシステムメモリを含むことを特徴とする請求項３５のコンピュータプログラム。
【請求項３８】
構造化データを共同で表す第１の複数のバイトと、
前記バイトストリームのバージョン、前記バイトストリームの通信モード、前記第１の複数のバイトに関する符号化フォーマット、および目標宛先ＵＲＩを含む、前記バイトストリームの１つまたは複数のプロパティを共同で表す第２の複数のバイトと
を含むバイトストリームデータ構造を有することを特徴とする１つまたは複数のコンピュータ可読媒体。
【請求項３９】
前記構造化データはＳＯＡＰエンベロープであることを特徴とする請求項３８のコンピュータ可読媒体。
【請求項４０】
物理的メモリ媒体であることを特徴とする請求項３８のコンピュータ可読媒体。
【請求項４１】
前記物理的メモリ媒体は不揮発性メモリを含むことを特徴とする請求項４０のコンピュータ可読媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【公開番号】特開２００６−１９０２６３（Ｐ２００６−１９０２６３Ａ）
【公開日】平成１８年７月２０日（２００６．７．２０）
【国際特許分類】
【出願番号】特願２００５−３５１２７７（Ｐ２００５−３５１２７７）
【出願日】平成１７年１２月５日（２００５．１２．５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成１８年７月２０日（２００６．７．２０）
【国際特許分類】
【出願日】平成１７年１２月５日（２００５．１２．５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]