JP2006216035A - 通信バインディングオブジェクトを構築し、使用するシステムおよび方法 - Google Patents

Abstract

【課題】バインディングオブジェクトを構築し、使用する、自動化された、使いやすいやり方を提供する。
【解決手段】開発者は、最終的に、クライアントとサービスエンドポイントの間でメッセージをトランスポートするための実行時通信チャネルを作成するのに使用されるバインディング要素を提示され、それを選択する。ユーザ入力を受け取った後、メタデータ、チャネルファクトリおよびリスナーファクトリが作成される。メタデータはバインディング要素を記述し、実行時に通信態様を実施するプロトコルスタックの抽象表現を提供する。チャネルファクトリは、実行時にメタデータのコレクションを使って実行時通信チャネルを生成するように構成される。さらに、リスナーファクトリは、サービスエンドポイントでメッセージを処理するために、実行時通信チャネルを受け入れて通信態様を多重分離するように構成される。
【選択図】図１

Description

本発明は、一般に、分散システムにおける通信態様へのメッセージのバインディングに関する。より詳細には、本発明は、エンドポイント間でメッセージを転送するときにメッセージに通信態様を適用するための実行時通信チャネルを作成するのに使用することができるバインディングオブジェクトを構築する、自動化された、使いやすいやり方を開発者に提供する。

コンピュータシステムおよび関連する技術は社会の多くの側面に影響を及ぼす。実際、コンピュータシステムが情報を処理する能力は、我々の生活の仕方、働き方を変容させている。コンピュータシステムは、今や普通に、コンピュータシステムの到来以前には手作業で行われていた多くの仕事（例えば、文書処理、スケジュール管理、データベース管理など）を行っている。より最近では、コンピュータシステムは、相互に結合されて、コンピュータシステムがそれを介してデータを共有するために電子的に通信を行うことのできるコンピュータネットワークを形成している。サービス指向のシステム（Ｗｅｂサービスなど）は、そのようなコンピュータシステム間の通信を前進させる原動力となっており、我々がソフトウェアを構築し、使用するやり方を完全に転換させつつある。

サービス指向のアーキテクチャは、アプリケーションにデータを共有させ、より強力には、他のアプリケーションから、それらのアプリケーションがどのようにして構築されたか、それらがどんなオペレーティングシステムまたはプラットフォーム上で実行されるか、それらにアクセスするのにどんな装置が使用されるかを問わずに、諸機能を呼び出す。通常、これらのシステムは、ＳＯＡＰ（シンプルオブジェクトアクセスプロトコル）、ＸＭＬ（拡張可能なマークアップ言語）、ＵＤＤＩ（ユニバーサル・ディスクリプション・ディスカバリ・アンド・インテグレーション）、ＷＳＤＬ（Ｗｅｂサービス記述言語）などを含む産業標準プロトコルによってインターネットを介して呼び出される。これらのサービスは、相互に独立のままであるが、緩やかにリンクし合って特定のタスクを実行する協働グループを形成することができる。

しばしば、サービス指向ネットワークにおける電子通信は、サーバコンピュータシステム（以後「サービス」と呼ぶ）における（１つまたは複数の）ネットワークサービス（Ｗｅｂサービスなど）へのアクセスを要求するクライアントコンピュータシステム（以後「クライアント」と呼ぶ）を含む。したがって、クライアントはサービスに、そのシステムリソースへの特定のアクセスを求める要求を送り、クライアントが許可され、検証された場合、サービスは、例えば、所望の情報を提供する応答メッセージなどで応答する。当然ながら、クライアントとサービスの間の他のメッセージ交換パターンも利用可能であり、それらには、単純なシングルトンメッセージ、ならびに、例えば、通知、送信請求−応答、パブリッシュ−サブスクライブパターン、ポーリング、キック−プッシュ、待ち行列化（ｑｕｅｕｉｎｇ）などのような、より洗練されたマルチメッセージ交換が含まれる。

サービスを記述するサービス指向の概念（アドレス、バインディング、メッセージ対話パターンなど）は、プログラミングモデルに含まれ得る。その場合、プログラミングモデルは、記述されるサービスと通信を行おうとするサービス消費者によってアクセスされ得る。一般に、サービス指向の概念（プログラミングモデルなど）は、例えば、分散コンポーネントオブジェクトモデル（「ＤＣＯＭ」）、共通オブジェクト要求ブローカアーキテクチャ（「ＣＯＲＢＡ」）、Ｗｅｂサービスなど、何らかのサービス指向標準に従って記述される。Ｗｅｂサービスは、さらに、例えば、Ｗｅｂサービス記述言語（「ＷＳＤＬ」）、Ｗｅｂサービスポリシフレームワーク（「ＷＳ−Ｐｏｌｉｃｙ」）など、様々なＷｅｂサービス仕様に従って定義することができる。

ＷＳＤＬのようなサービス指向標準は、共通または標準の言語で契約（ＷＳ契約など）を記述するための全体的ラッパまたは仕様を提供する。そのような仕様は、開発者および開発用ツールが契約を作成し、解釈するのを容易にする。そのようなネットワークプロトコル記述言語（以後「ＮＰＤＬ」と呼ぶ）は、広範囲にわたるツール群を備えており、このことがそれらの普及の大きな理由であるが、現在、そのような標準にはいくつかの短所および破綻がある。

例えば、分散アプリケーションは、通常、そのプログラミングモデルにおいて厳格であり、そのサービスランタイムに緊密に結合されたただ１つのプログラミングモデルだけを許容する。したがって、互換性のために、（例えば、サービス消費者などにおける）クライアントランタイムは、通常、サーバランタイムと同じプログラミングモデルに従って開発されたクライアントプログラムまたはモジュールを利用することが必要とされる。例えば、サービスが要求と応答メッセージとに別々のインターフェースを使って、あるいは特定のセキュリティ機構を使って開発された場合、そのサービス消費者もそれらを実施しなければならない。同じプログラミングモデルに従って開発されたクライアントプログラムまたはモジュールを使用しないと、クライアントランタイムは、サービスランタイムと通信を行うのを妨げられることがある。

さらに、現在のＮＰＤＬは、メッセージ交換パターン（一方向、要求−応答、パブリッシュ−サブスクライブ、全二重など）、メッセージ符号化または形式（ＳＯＡＰエンベロープなど）、およびサービスとメッセージを交換するためのトランスポートの種類（ＨＴＴＰ（ハイパーテキスト転送プロトコル）、ＦＴＰ（ファイル転送プロトコル）、ＳＭＴＰ（簡易メール転送プロトコル）、ＴＣＰ（伝送制御プロトコル）、ＵＤＰ（ユーザデータグラムプロトコル）、ＳＭＳ（ショートメッセージサービス）、ＳＮＡ（システムネットワークアーキテクチャ）、ＧＰＲＳ（汎用パケット無線サービス）など）を含む、限られた通信態様のセットに契約をバインドする。その他の通信態様（セキュリティ、信頼性、コンテキストフロー、トランザクションフロー、ロギングオプション、接続スロットリングオプションなど）は、他の文書（ＷＳ−Ｐｏｌｉｃｙなど）で指定され、または、クライアント側とサービス側の両方で、帯域外で構成されなければならない。

システム全体に散在する通信態様の広範囲に及ぶ分散に起因して、人為的ミスにより、サービス記述文書または構成が、対応するサービスの完全で正確な記述ではない多少の可能性がある。しかしながら、プログラミングモデルとサービスランタイムの間の厳格な結合の結果、サービスによって定義される１つの通信態様または構成オプションが欠けているだけでも、互換性のないクライアント実行時を生じ得る。

また、ＮＰＤＬでは、すべての通信態様が提供されるとは限らないため、通信態様を利用し、維持するために、クライアントとサービスの両方が、各アプリケーション内に相当量のコードを持たなければならない。例えば、セキュリティコンテキストの場合、クライアントは、（１）サービスアプリケーションとの通信がセキュリティコンテキストトークンを使用しなければならないことを認識し、（２）トークン発行者にそのようなトークンを要求し、（３）要求内で適切な情報を提供し、（４）その後の通信のためにセキュリティコンテキストトークンを保存し、（５）そのセキュリティコンテキストトークンを使用するサービスからの通信を受け取るときに、適切なベーストークンおよび共有される秘密を参照するコードを持つ必要がある。同様に、サービスアプリケーションも、セキュリティテキストトークンに基づいてクライアントから保護されたメッセージを受け取るときに、サービスアプリケーションが、（１）ベーストークンを識別し、（２）メッセージを解読するためにベーストークンに関連付けられた適切なセッションキーを決定し、（３）セキュリティコンテキストトークンを保存し、（４）セキュリティコンテキストトークンを再利用して、メッセージを暗号化し、メッセージをクライアントに安全に配信するためにメッセージに署名することができなければならないようにコード化されなければならない。

セキュリティその他のセマンティクスでのそのような通信態様が、クライアントとサービス両方のアプリケーションでコード化されなければならないため、システムを拡張する際の柔軟性も容易さも、たとえあるとしても、わずかしかない。例えば、サービス指向のシステムを、異なる種類のセキュリティコンテキストトークンを使用し、または異なる信頼性オプションを持つことを可能にするように拡張することが望ましいと思われる場合、しかしながら、そうするには、既存のコードを書き換えるのみならず、サービスアプリケーションに別の大量のコードも必要になるはずである。また、当然ながら、セキュリティコンテキストは、ＨＴＴＰＳなどを使ってトランスポートレベルでも設定され得る。しかしながら、セマンティクスが仕様によって事前定義されるため、この解決法も、やはり、システムを拡張する際に柔軟性や容易さをもたらさない。さらに、アプリケーション開発者は、通常、特定の通信態様の専門家ではないため、性能、ストレス、その他の耐性のみならず、セキュリティの懸念、信頼性の懸念もある。さらに、これらの通信態様すべての置換および組み合わせが多数であるため、様々な組み合わせのメリットを十分に理解するのが厄介で、困難になる。

したがって、開発者に、メッセージを豊富な通信態様にバインドする、自動化された、使いやすいやり方をもたらすユーザインターフェースが求められている。このユーザインターフェースは、整合性のためにクライアントとサービスの両方によって使用され得る標準化ツールを生成することができなければならない。さらに、バインディングプロトコルの可能な置換の数を制限するために、よく使用される、互換性のある通信態様のリストを記述することも求められている。また、様々な通信態様、ならびによく使用される組み合わせは、十分に柔軟性があり、拡張可能で、プラグ可能（ｐｌｕｇｇａｂｌｅ）でなければならない。

前述の現在のバインディング機構の欠陥および弱点は、本発明の例示的実施形態によって克服される。例えば、本発明は、開発者に、エンドポイント間でメッセージを転送するときにメッセージに通信態様を適用するための実行時通信チャネルを作成する際に使用するバインディングオブジェクトを構築する、自動化された、使いやすいやり方をもたらすユーザインターフェースを提供する。別の例示的実施形態は、開発者に、バインディング要素の可能な置換の数を縮小するための、よく使用される、互換性のあるバインディングオブジェクトのリストの提示をもたらす。また、本発明は、作成されたバインディングオブジェクトを使い、プロトコルの通信態様に従ってエンドポイント間でメッセージをやりとりする実行時通信チャネルを生成することのできるシステムも提供する。

例示的実施形態によれば、本発明は、選択のための、ユーザへの複数のバインディング要素の提示をもたらす。バインディング要素は、最終的に、クライアントとサービスエンドポイントの間でメッセージをトランスポートするための実行時通信チャネルを作成するのに使用される通信態様を表す。複数のバインディング要素の提示後、複数のバインディング要素から１つまたは複数のバインディング要素を選択するユーザ入力が受け取られる。選択に基づいて、メタデータ、チャネルファクトリおよびリスナーファクトリが作成される。バインディングオブジェクトを記述するメタデータは、１つまたは複数のバインディング要素のコレクションであり、実行時に通信態様を実施するプロトコルの抽象表現を提供する。チャネルファクトリは、実行時にメタデータを使って実行時通信チャネルを生成するように構成される。一方リスナーファクトリは、サービスエンドポイントでメッセージを処理するために、実行時通信チャネルを受け入れ、通信態様を多重分離（ｄｅ−ｍｕｌｔｉｐｌｅｘ）するように構成される。

別の例示的実施形態は、選択のためのユーザへの複数のバインディングオブジェクトの提示をもたらす。複数のバインディングオブジェクトは、それぞれ、互換性、および複数のバインディング要素を組み合わせる産業上の蓋然性（ｐｒｏｂａｂｉｌｉｔｙ）に基づいて組み合わされる、複数のバインディング要素を含む。さらに、複数のバインディング要素のそれぞれは、最終的に、クライアントとサービスエンドポイントの間でメッセージをトランスポートするための実行時通信チャネルを作成するのに使用される複数の通信態様を表す。その後、複数のバインディングオブジェクトから１つのバインディングオブジェクトを選択するユーザ入力が受け取られる。その後、実行時に通信態様を実施する実行時通信チャネルの抽象表現を提供する、選択されたバインディングオブジェクトを記述するメタデータが自動的に作成される。

さらに別の例示的実施形態は、最終的に、クライアントとサービスエンドポイントの間でメッセージをトランスポートするための実行時通信チャネルを作成するのに使用される１つまたは複数の通信態様を表す、１つまたは複数のユーザ選択のバインディング要素を含むバインディングオブジェクトを記述するメタデータへのアクセスを提供する。メタデータに基づき、１つまたは複数のユーザ選択のバインディング要素に対応する１つまたは複数の通信態様を実施するように構成された１つまたは複数のチャネルコンポーネントを含む実行時通信チャネルが開始される。その後、実行時通信チャネルを使い、１つまたは複数の通信態様に従って、サービスに関連付けられたエンドポイントにメッセージが転送される。

本発明のさらなる特徴および利点を以下の説明に示す。その一部は以下の説明から明白になり、あるいは本発明の実施によって知ることもできる。本発明の特徴および利点は、添付の特許請求の範囲で詳細に指摘される手段および組み合わせによって実現され、獲得され得る。本発明の上記その他の特徴は、以下の説明および添付の特許請求の範囲からより詳細に明らかになり、あるいは以下に示す本発明の実施によって知ることもできる。

本発明の上記その他の利点および特徴が獲得され得る仕方を説明するために、簡単に前述した本発明のより詳細な説明を、以下で、添付の図面に示す本発明の具体的な実施形態を参照して提供する。これらの図面は、本発明の典型的な実施形態を示すにすぎず、したがって、本発明の範囲を限定するものとみなされるべきではないことを理解した上で、本発明を、添付の図面を使って、さらに具体的かつ詳細に記述し、説明する。

本発明は、例示的実施形態によれば、開発者が、実行時通信チャネルを生成するのに使用され得るバインディングオブジェクトを作成するのを補助する方法、システムおよびコンピュータプログラム製品にまで及ぶ。本発明の実施形態は、以下でより詳細に論じるように、様々なコンピュータハードウェアを含む専用または汎用コンピュータを備え得る。

本発明の例示的実施形態を詳細に論じる前に、本願の残りの部分を通して使用されるいくつかの用語を定義することが役立つであろう。「通信態様」は、分散システムにおいてエンドポイント間でメッセージを搬送するための具体的な公式規則のセットに対応する。通信態様の例には、それだけに限らないが、（１）Ｗｅｂサービス（ＷＳ）ファミリの実際の仕様（ＷＳ−Ｓｅｃｕｒｉｔｙ、ＷＳ−Ｒｅｌｉａｂｌｅ Ｍｅｓｓａｇｉｎｇ、ＷＳ−Ａｔｏｍｉｃ Ｔｒａｎｓａｃｔｉｏｎなど）、（２）特定の電信伝送機構（ＨＴＴＰ、ＴＣＰ、ＵＤＰなど）、（３）メッセージの特定の電信符号化（テキスト、バイナリなど）、および（４）他の種々雑多な転送プロトコルが含まれる。これらの通信態様は、相互に結びついて、以下で説明する実行時通信チャネルの使用によって実施され得る「プロトコルスタック」を作り出すためのものである。各プロトコルスタックは、通常、少なくとも１つのトランスポート態様および１つの符号化態様（ＴＣＰを介したＳＯＡＰメッセージなど）を含む。しかしながら、各通信態様自体が１つのプロトコルであることに留意されたい。したがって、本明細書で使用する場合の「プロトコルスタック」は、１つまたは複数の通信態様を含むものであると幅広く解釈されるべきである。

通信態様の抽象表現は「バインディング要素」と呼ばれ、通信態様（ゆえにプロトコルスタック）を実施する実行時通信チャネルを作成するのに使用され得る。本明細書では、バインディング要素のコレクションを「バインディングオブジェクト」と呼び、これで特定のプロトコルスタックまたは通信態様の組み合わせの抽象表現を表す。

本発明は、一般に、エンドポイント間でメッセージを転送するためにバインディングオブジェクトを作成し、使用するシステム、方法およびコンピュータプログラム製品を提供する。図１に、例示的実施形態による、クライアントからサービスにメッセージを転送するためのバインディングオブジェクトを作成し、使用するのに使用され得る様々なコンポーネントを備える分散システム１００を示す。図示のように、サービス開発者には、バインディング要素１１５を選択するために開発側アプリケーション１１０においてユーザインターフェース１１２が提示され得る。これらのバインディング要素１１５は、容易に理解され得るやり方で提示され、ユーザの選択を補助するための様々な記述を提供し得る。例えば、ユーザインターフェースは、ユーザに、「セキュリティを必要としますか？」、「信頼性を必要としますか？」などのように、情報の入力を促すことができる。ユーザ入力に基づき、他のオプションまたは質問を続けることができる。さらに、以下でより詳細に説明するように、これらのバインディング要素は、この提示プロセスの間にグループに結合され、または標準バインディングオブジェクトに構成され得る。その場合、開発者は、ユーザインターフェース１１２を使って提供される様々なオプションの中から選択を行うことができる。

また、本発明は、デフォルトのバインディング要素および／またはバインディングオブジェクトを定義することもサポートすることに留意されたい。したがって、開発者がバインディング要素を選択せずに進行する場合、バインディング要素１１５の１つまたは複数を含むデフォルトのバインディングオブジェクトが、ユーザのために自動的に選択され得る。そのため、本明細書で使用する「ユーザ選択の」という用語または他の類似の語句は、デフォルトのバインディング要素またはオブジェクトを含むものであると幅広く解釈されるべきである。そのような場合、デフォルトのバインディング要素１１５を選択するために受け取られるユーザ入力が、バインディング要素（または以下で説明する他のバインディングオブジェクト）を選択することなく入力されて進行し得る。

開発者が自分の選択をし終えると、組み合わされた選択のバインディング要素からバインディングオブジェクトが作成される。バインディングオブジェクトを使って、バインディングビルダ（図示せず）によっていくつかの異なる例示的実施形態を作成するのに使用されるバインディング記述１２０が構築される。第１に、バインディング記述１２０は、ストア１０５に格納され得るバインディングオブジェクトの記述であるメタデータ１２５のコレクションを作成するのに使用され得る。このメタデータはサービス１４０に存在し得るが、これは、例えば、ユニバーサルな記述、発見および統合（「ＵＤＤＩ」）を使用するサービスのディレクトリに格納されるＮＰＤＬ文書（ＷＳＤＬ文書など）にも存在し得る。

第２に、バインディング記述１２０は、メタデータ１２５を使って実行時通信チャネル１６５を作成するチャネルファクトリ１３５を作成するのにも使用され得る。チャネル（実行時通信チャネル１６５など）は、クライアント１３０とサービス１４０の間でメッセージを交換するためのコア抽象化を表す。特に、チャネル（実行時通信チャネル１６５など）は、入力／出力（Ｉ／Ｏ）抽象化を表し、（１）アプリケーションデータまたはメッセージ１７０（ＳＯＡＰメッセージなど）を受け入れ、（２）様々な通信態様（信頼性、セキュリティ、符号化など）を実施し、（３）通信態様に従って送信のためにメッセージ１７０をフォーマットし、（４）「電信」によってメッセージ１７０を送信する役割を果たす。また、実行時通信チャネル１６５は、通信態様においてプルベースの機構を使ったスロットリングおよびフロー制御もサポートし、維持し得ることに留意されたい。

また、バインディング記述１２０は、サービス１４０のリスナーファクトリ１４５を作成するのにも使用される。サービス側１４０で、リスナーファクトリ１４５は、特定のネットワークアドレス上でメッセージ１７０などの新しいメッセージをリッスンし、サービス１４０の特定のエンドポイント１６０と通信を行うリスナー１５０を作成する機構を提供する。その場合、リスナーファクトリ１４５は、メッセージ１７０の一部を多重分離し、メッセージ１７０を適切なリスナー１５０に送ることができる。

サービス１４０からメタデータ１２５（ＷＳＤＬ文書など）を獲得することができ、次いで、実行時通信チャネル１６５を生成することは、本発明で提供される「使いやすさ」の重要な部分であることに留意されたい。例えば、ある開発者がサービス１４０のためにバインディング要素１１５を選択することができ、次いで、別の開発者が、リモートで、サービス１４０にそのメタデータ１２５を問い合わせることができる。このメタデータ１２５から、アプリケーションは、実行時通信チャネル１６５を生成し、それを使い、サービスの開発者のバインディング要素１１５の選択に従って、サービス１４０にメッセージを転送することができる。

さらに、上記オブジェクト１２５、１３５、１４５は、特定の順序で論じたバインディング記述を使って作成されているが、本発明は、これらのオブジェクトを生成する順序にもタイミングにも限定されないことに留意されたい。例えば、メタデータ１２５、チャネルファクトリ１３５、およびリスナーファクトリ１４５は、同時に作成されても、任意の順序で別個に作成されても、またはその組み合わせとしてもよい。

通信オブジェクト１２５、１３５、１４５がいつ作成されるかを問わず、サービス１４０にアクセスするために、クライアント１３０は、その特定のサービス１４０のチャネルファクトリ１３５にチャネルを能動的に要求する（１８０）。次いで、チャネルファクトリ１３５は、ストア１０５のメタデータ１２５にアクセスし、このバインディングオブジェクトの記述を使って実行時通信チャネル１６５を開始することができる。実行時通信チャネル１６５の具体的詳細は、この例示的実施形態に密接には関係しないが、実行時通信チャネル１６５が、通常、（組み合わされて実施されるとプロトコルスタックを構成する）様々な通信態様に対応する通信コンポーネントから構成されることは注目に値する。例えば、実行時通信チャネル１６５は、セキュリティコンポーネント、信頼性コンポーネント、トランスポートコンポーネントおよび符号化コンポーネントを含み得る。その場合、これらのコンポーネントが結びついて、そのプロトコルを実施する全体の実行時通信チャネル１６５を作り出す。

要求１８０を受け取ると、チャネルファクトリ１３５は、クライアント１３０が、実行時通信チャネル１６５を適切に参照し、それを使って、指定された通信態様に従ってサービス１４０にメッセージ１７０を渡すことができるように、クライアント１３０に（実行時通信チャネル１６５またはその識別子とすることのできる）ハンドル１７５を返す。本発明は、これらの通信態様を開発者から選択されたバインディング要素から導出したが、現在の実施形態はそのような選択プロセスだけに限定されないことに留意されたい。例えば、メタデータ１２５は、デフォルトのバインディングオブジェクトまたはサービス側のシステム管理者による構成セマンティクスによって指定されるバインディングオブジェクトを表すこともできる。したがって、この実施形態で重要なのは、実行時通信チャネル１６５を作成するためのメタデータ１２５の使用である。しかしながら、前述のように、実行時通信チャネル１６５は、通常、少なくとも１つのトランスポート態様および１つの符号化態様を含むべきであることに留意されたい。

実行時通信チャネル１６５がどのようにして開始されるかを問わず、サービス側１４０で、リスナーファクトリ１４５は、実行時通信チャネル１６５をリッスンし、適当なリスナー１５０を作成する。リスナー１５０は、サービス側１４０で新しい実行時通信チャネル１６５をリッスンし、それを受け入れる抽象化を表す。リスナー１５０によって新しいチャネル（実行時通信チャネル１６５など）が検出されると、エンドポイント１６０は、実行時通信チャネル１６５によって実施される通信態様に従ってリスナーにメッセージ１７０を多重分離させる、「チャネル受け入れ」を呼び出すことができる。代替として、エンドポイント１６０は、未処理の受け入れ開始を「保留」にすることもでき、これは、後で、他のメッセージが処理されてから完了され得る。いずれにしても、その後、エンドポイント１６０は、しかるべくメッセージを処理し、必要に応じて適当な応答を送ることができる。

クライアント１３０とサービス１４０の間のメッセージ交換パターンに応じて、実行時通信チャネル１６５は、サービス１４０からクライアント１３０に生成され得ることに留意されたい。例えば、クライアント１３０とサービス１４０の間の全二重メッセージ交換パターンでは、そのような通信のために、サービス１４０からクライアント１３０への逆方向チャネルが生成される必要が生じうる。したがって、前述の通信プロセスは、サービス１４０がクライアント１３０として働き、逆もまた同様に働くように切り換えられる必要が生じ得る。さらに、前述の例示的実施形態を実施する他のやり方もあり得る。例えば、メタデータ１２５、チャネルファクトリ１３５、およびリスナーファクトリ１４５は、バインディング記述なしで自動的に生成され得る。したがって、実行時通信チャネル１６５を生成し、そのような通信チャネルを使ってメッセージを転送する具体的実装形態は、例示のために使用しているにすぎず、明示的に特許請求されない限り、本発明の範囲を限定し、または別の点で狭めるためのものではない。

図２Ａに、様々なバインディング要素がそれらに共通の特性に従ってグループ化されている一般的なユーザインターフェース１０１を示す。例えば、１つのグループ１８２は、（信頼性バインディングＡおよび信頼性バインディングＢ１９６として示す）いくつかのバインディング要素１８４を備え得る信頼性１８６グループを含む。そのような信頼性バインディング要素１９６は、特定のトランスポート（ＨＴＴＰなど）にバインドされた、ＷＳファミリからのものとすることもでき、独自の信頼性バインディング要素１９６とすることもできる。このバインディング要素１８４のグループ１８２への編成は、バインディング要素１８４の定義を容易にし、その特定のグループ１８２の最もよく要求される機能を表す。

図示のように、他のグループには、様々なセキュリティバインディング要素１９８（ＷＳ−Ｓｅｃｕｒｉｔｙ、ＨＴＴＰＳ、プロプライエタリなど）を持つセキュリティグループ１８８、トランスポートバインディング要素１８１（ＨＴＴＰ、ＨＴＴＰＳ、ＨＴＴＰＲ、名前つきパイプ、ＴＣＰ、ＵＤＰ、待ち行列化メッセージング（ｑｕｅｕｅｄ ｍｅｓｓａｇｉｎｇ）、待ち行列化統合メッセージング（ｑｕｅｕｅｄ ｉｎｔｅｇｒａｔｉｏｎ ｍｅｓｓａｇｉｎｇ）など）を持つトランスポートグループ１９０、符号化バインディング要素１８３（テキスト、バイナリ、ＳＯＡＰ、メッセージ伝送最適化機構（ＭＴＯＭ）など）を持つ符号化グループ１９２、およびその他グループ１９４が含まれ得る。当然ながら、他の共通の通信態様を表す他のグループ１８２（「ＷＳファミリ」グループなど）もあり得る。実際、以下でより詳細に述べるように、グループは、十分にプラグ可能で、拡張可能であり、独自のグループ化および他のグループ化も可能である。そのため、前述のグループおよび各グループ内のバインディング要素のリストは、例示のために使用しているにすぎず、明示的に特許請求されない限り、本発明の範囲を限定し、または別の点で狭めるためのものではない。

この最後のその他グループ１９４は、どんな特定のグループ１８２にもうまく当てはまらないその他のバインディング要素１８５を含み得る。例えば、その他のバインディング要素１８５は、（１）異なる通信チャネルが１つの全二重チャネルに組み合わされ得る、複合全二重バインディング要素、（２）メッセージがＲＰＣ／リテラル、ＲＰＣ／符号化、文書／リテラル、文書／符号化であるかどうか決定するメッセージ形式バインディング要素、（３）コンテキストの実行のためのコンテキストフローバインディング要素、および（４）トランザクションの流れのためのトランザクションフローバインディング要素の１つまたは複数とすることができる。当然ながら、他の共通グループ１８２に当てはまらない他の多くのバインディング要素１８５もあり得る。したがって、前述のその他のバインディング要素１８５のリストは、例示のために使用しているにすぎず、本発明の範囲を限定し、または別の点で狭めるためのものではない。

実際、前述のように、例示的実施形態は、グループ１８２およびバインディング要素１８４が十分にプラグ可能であり、拡張可能であると規定する。すなわち、グループ１８２、および各グループ１８２中のバインディング要素１８４さえも、バインディングオブジェクトを作成するためのアプリケーションを書き換えることなく、必要に応じて、除去され、挿入され、または拡張され得る。グループ１８２および各グループ内のバインディング要素１８４のそれぞれがプラグ可能であり、拡張可能であるため、前述のグループ１８２およびバインディング要素１８４のリストは、包括的であることが意図されていないことに留意されたい。したがって、前述のリストおよび以下のその他のリストは、例示のために使用しているにすぎず、明示的に特許請求されない限り、本発明の範囲を限定し、または別の点で狭めるためのものではない。

また、図２Ａに示すユーザインターフェースは、ラジオボタンを使って選択され得るバインディング要素１８４の単純な表示であることに留意されたい。しかしながら、本発明には他のユーザインターフェースも利用可能である。例えば、バインディング要素および／またはグループ１８２は、個々に、または一括して表示され得る。さらに、選択の型は、単純なラジオボタンではなく、例えば、チェックボックス、反転表示などとすることもできる。さらに、バインディング要素（または場合によってはオブジェクト）は、次の利用可能なオプションが前に行われる選択によって決まるウィザードとしても提供され得る。また、アプリケーション開発者がクラスを書いているときに、ユーザに、オプションのオートコンプリートをスクロールさせるポップアップボックスも表示され得る。実際、前述の機能を達成するための、異なる美的側面を持つ多数のユーザインターフェース設計が存在する。そのため、本明細書で説明し、または図示するどんな特定のユーザインターフェースも、例示のために使用しているにすぎず、明示的に特許請求されない限り、本発明の範囲を限定し、または別の点で狭めるためのものではない。

上記のバインディング要素１８４のグループ１８２は、１組の共通の通信機能からカスタム通信バインディングオブジェクトを定義する柔軟な機構を提供するが、そのような柔軟性は、多数のバインディングオブジェクト（すなわち、バインディング要素およびその可能な組み合わせの数）を持つという厄介な問題を生み出す。実際、その計算を開始すると、可能なバインディングオブジェクトの数は、何万にも及ぶ。そのため、個々のバインディング要素に精通していない開発者は、どんな組み合わせが開発者の個々の必要に最も適するか知らないことがある。

したがって、別の例示的実施形態は、産業上最も一般的な種類の通信バインディングオブジェクトのコレクションまたは構成である、標準化されたバインディングを提供する。言い換えると、例示的実施形態は、最も一般的な種類であることがわかっている様々なバインディング要素を組み合わせることによって事前構築されたバインディングオブジェクトを提供する。図２Ｂに、開発者に、ユーザがそこから選択することのできる様々な標準バインディング１０４を提示する例示的ユーザインターフェース１０２を示す。また、ユーザには、１０６に示すような個々のバインディング要素を選択するオプションも提示され得る。

以下は、現在産業標準として使用されている、最も一般的な種類の通信バインディングオブジェクトのいくつかのリストである。このリストは、そのようなバインディングオブジェクトを作成するための特定のバインディング要素の概要を示しているが、産業が成長し、変化するにつれて、これらのバインディング要素も変化し得る。したがって、以下のリストは、包括的であることを意図されておらず、単に、現在、一般に組み合わされる蓋然性が高いと考えられているバインディング要素の例示的組み合わせを示すものにすぎない。

現在の事前構築のバインディングオブジェクトの１つの種類は、Ｗｅｂサービス相互運用性：基本プロファイル（ＷＳＩ−ＢＰ）と整合するＷｅｂサービスとの通信に適した、基本プロファイルバインディングオブジェクトとすることができる。このバインディングオブジェクトは、ＨＴＴＰまたはＨＴＴＰＳを介したテキスト符号化を使用し、一方向および要求−応答ＭＥＰ（メッセージ交換パターン）をサポートする。しかしながら、このバインディングオブジェクトは、全二重ＭＥＰ、トランスポートセッション、および信頼性の高いセッションをサポートしない。

別の一般的なバインディングは、ＨＴＴＰまたはＨＴＴＰＳトランスポートを介してＷＳスイートまたはファミリを使用するＷｅｂサービスとの保護された、信頼性の高い通信に適した、ＷＳプロファイルバインディングとすることができる。このバインディングオブジェクトは、テキストまたはＭＴＯＭで符号化することができ、ＨＴＴＰまたはＨＴＴＰトランスポートプロトコルをサポートする。また、このトランスポートは、信頼性の高いセッション、ならびに一方向、要求−応答および全二重ＭＥＰも提供する。別の類似のバインディングは、ＷＳファミリと併せて双方向ＨＴＴＰ通信を使用するＷｅｂサービスとの保護された、信頼性の高い通信に適した、ＷＳプロファイル全二重ＨＴＴＰバインディングである。

セキュリティに使用されるＴＬＳ／ＳＳＬありまたはなしの、ＴＣＰトランスポートを介したバイナリによる．ＮＥＴファミリのプロトコルを実施するサービス間の、保護された、信頼性の高い通信に適した、．ＮＥＴプロファイルＴＣＰバインディングオブジェクトが利用可能である。別の類似の事前構築のバインディングオブジェクトは、同じマシン上のプロセス間の、保護された、信頼性の高い通信に適した、．ＮＥＴプロファイル名前付きパイプバインディングオブジェクトとすることができる。また、２つの一方向ＴＣＰ接続を介して．ＮＥＴファミリのプロトコルを実施するサービス間の、保護された、信頼性の高い通信に適した、．ＮＥＴプロファイル全二重ＴＣＰバインディングも利用可能と考えられる。さらに、様々な待ち行列化トランスポートセキュリティを使用することのできるサービス間の、保護された、待ち行列化通信に適した、．ＮＥＴ待ち行列化メッセージングおよび保護された待ち行列化メッセージングバインディングも利用可能である。また、既存の待ち行列化アプリケーションと相互運用するアプリケーションをバインドするのに適した、待ち行列化統合バインディングも利用可能である。

他の一般的な種類の通信バインディングオブジェクトには、仲介ＨＴＴＰ、ＴＣＰ、名前付きパイプバインディングなどの仲介バインディングが含まれ得る。これらの各バインディングは、それぞれ、ＨＴＴＰ、ＴＣＰ、または名前付きパイプ上でリッスンするＳＯＡＰ仲介をバインドするのに適する。

前述のように、バインディング要素を定義する例示的実施形態が与えられたとすると、可能なバインディングオブジェクトの数は何千にも及ぶ。したがって、有意なシナリオ分析および選別の後、上記の標準バインディングのリストは、よく使用される事例の圧倒的多数をカバーする簡潔で一意のバインディングオブジェクトのセットを定義する。しかしながら、やはり前述のように、このリストは、産業標準が変化するにつれて、必要に応じて、拡張可能であり、プラグ可能である。さらに、各バインディングオブジェクトごとに、子バインディング要素の構成ノブすべての厳密な和集合を取ることによって構成ノブを定義するのではなく、例示的実施形態は、最も必要とされる可能性の高い構成ノブを「再公開する」。

図３Ａ〜Ｅに、前述の様々なグループおよび標準バインディングがどのようにしてウィザード型ユーザインターフェース（ＵＩ）で提示され得るかを示す。例えば、図３Ａには、セキュリティバインディング３０５がある場合にその選択を可能にするバインディングウィザードユーザインターフェース３００が示されている。同様に、図３Ｂには、様々なセキュリティバインディング要素３１０の選択を可能にするバインディングウィザードＵＩ３００が示されている。図３Ｃにおいて、バインディングウィザードＵＩ３００は、ユーザが複数のトランスポート３１５および符号化３２０から選択することを可能にする。前述のように、図３Ｄには、その他のバインディング３３０を用いて選択され得る任意選択のバインディング要素を含むその他グループ３２５を有するバインディングウィザード３００が設けられている。最後に、図３Ｅには、前述の標準バインディング３２５のリストを有するバインディングウィザードＵＩ３００が提示されている。当然ながら、このＵＩ３００は、独自のバインディング３４０を作成するオプションを含み得る。

ある状況では、バインディング要素の１つまたは複数が必要とされ、または選択から制限され得ることに留意されたい。例えば、トランスポートと符号化両方のバインディングを選択する要件が必要とされ得る。しかしながら、選択されたトランスポートが特定の種類の符号化をサポートしないこともある。したがって、開発者は、サポートされる符号化の選択だけに制限され得る。また、特定のトランスポートその他のバインディング要素にデフォルトがあることもあり、その場合、開発者には、前に行われた選択に基づいて符号化その他のバインディング要素を選択するオプションが与えられない。したがって、本発明は、サービス開発者が利用可能な選択に関する様々な規則を実施するように構成される。しかしながら、定義され、実施され得る多数の要件または制限があることに留意されたい。したがって、上記の要件および制限の例は例示のために使用するものであり、本発明は、実施のための多くの規則を構成すること（または規則を構成しないこと）ができる。

また、本発明は、機能ステップおよび／または非機能動作を含む方法の観点からも説明され得る。以下は、本発明を実施するに際して実行され得るステップおよび／または動作の説明である。普通、機能ステップは、達成される結果の発明を記述するのに対し、非機能動作は、特定の結果を実現する、より具体的なアクションを記述する。機能ステップおよび／または非機能動作は、特定の順序で記述され、特許請求され得るが、本発明は、必ずしも、ステップおよび／または動作の特定の順序または組み合わせに限定されるとは限らない。さらに、特許請求の範囲の記述、および以下の図４〜６の流れ図の説明におけるステップおよび／または動作の使用は、そのような項目の所望の具体的使用を示すために使用される。

図４〜６に、本発明の様々な例示的実施形態の流れ図を示す。以下の図４〜６の説明は、時折、図１、２Ａ〜Ｂおよび３Ａ〜Ｅからの対応する要素に言及し、これらの図からの特定の要素への参照が行われ得るが、そのような要素は、例示のために使用するにすぎず、明示的に特許請求されない限り、本発明の範囲を限定し、または別の点で狭めるためのものではない。

図４に、開発者に、エンドポイント間でメッセージを転送するのに使用される実行時通信チャネルを作成する際に使用するバインディングオブジェクトを構築する、自動化された、使いやすいやり方を提供する方法４００の例示的流れ図を示す。方法４００は、選択のためにユーザに複数のバインディング要素を提示する動作４０５を含む。例えば、サービス開発用アプリケーション１１０は、ＵＩ１１２を使って、選択のためにユーザに複数のバインディング要素１１５を提示することができる。バインディング要素１１５は、クライアント１３０とサービス１４０またはサービスエンドポイント１６０の間でメッセージをトランスポートするための実行時通信チャネル１６５の通信態様を表す。

これらの通信態様には、少なくとも１つのトランスポート態様（ＵＤＰ、ＨＴＴＰ、ＨＴＴＰＳ、ＨＴＴＰＲ、ＴＣＰ、ＳＭＴＰ、メッセージングミドルウェア、メッセージングミドルウェア統合など）および１つの符号化態様（テキスト、バイナリ、ＳＯＡＰ、ＭＴＯＭなど）が含まれるはずである。さらに、通信態様には、信頼性、セキュリティ、複合全二重、メッセージ形式、コンテキストフロー、トランザクションフローなども含まれ得る。また、バインディング要素は、前述のように、ユーザに複数のバインディング要素を提示するアプリケーション、またはメタデータ、チャネルファクトリおよびリスナーファクトリを構築する基礎をなすビルダを書き換る必要なく、バインディング要素が付加され、変更され、または除去され得るという点で、十分に拡張可能であり、カスタマイズ可能である。さらに、これらのバインディング要素は、例えば、信頼性グループ、セキュリティグループ、トランスポートグループ、符号化グループ、その他グループなどのグループとしてもユーザに提示され得る。個々のバインディング要素と同様に、グループも、各グループごとにバインディング要素が、付加され、除去され、または変更され、システムを中断させずにグループ自体が付加され、除去され、または変更され得るという点で、十分に拡張可能であり、プラグ可能である。

また、方法４００は、複数のバインディング要素から１つまたは複数のバインディング要素を選択するユーザ入力を受け取る動作４１０も含む。したがって、サービス開発用アプリケーション１１０は、トランスポート態様および／または符号化態様に対応するバインディング要素１１５を選択するユーザ入力を受け取ることができる。また、方法４００は、選択に基づいてメタデータ、チャネルファクトリおよびリスナーファクトリを作成する動作４１５も含む。より具体的には、サービスアプリケーション１１０（または前述のバインディングビルダ）は、バインディング要素１１５の選択を受け取ると、それらのバインディング要素を含むバインディングオブジェクトを記述するメタデータ１２５のコレクションを生成することができる。メタデータ１２５のコレクションは、実行時に通信態様を実施するプロトコルの抽象表現を提供する。このメタデータ１２５は、ＷＳＤＬ文書の一部とすることも、他の何らかの形とすることもできる。また、サービス開発用アプリケーションは、実行時にメタデータ１２５のコレクションを使って実行時通信チャネル１６５を生成するように構成され得る、チャネルファクトリ１３５を作成することもできる。さらに、サービス開発用アプリケーション１１０は、サービスエンドポイントでメッセージを処理するために実行時通信チャネルを受け入れるように構成されるリスナーファクトリ１４５を生成し、または作成するのにも使用され得る。複合全二重バインディング要素が選択されると、２つのトランスポートバインディング要素および／または２つの符号化バインディング要素が選択され得る。当然ながら、両方向に、１つのトランスポートおよび／または１つの符号化バインディング要素が選択され、前提とされ得る。

図５に、開発者に、実行時通信チャネルを作成するのに使用され得る、よく使用される、互換性のあるバインディングオブジェクトのリストを開発者に提示することによってバインディングオブジェクトを自動的に構築する簡潔なやり方を提供する方法５００を示す。方法５００は、ユーザに複数のバインディングオブジェクトを提示する動作５０５を含む。すなわち、図２Ｂに示すように、ユーザに、選択のための複数のバインディングオブジェクト１０４を含むＵＩ１０２が提示され得る。複数のバインディングオブジェクト１０４は、それぞれ、互換性、および複数のバインディング要素を組み合わせる産業上の蓋然性に基づいて組み合わされる複数のバインディング要素１１５を含む。さらに、複数のバインディング要素１１５のそれぞれは、最終的に、クライアント１３０とサービスエンドポイント１６０の間でメッセージ１７０をトランスポートするための実行時通信チャネル１６５を作成するのに使用される複数の通信態様を表す。通信態様には、前述の、符号化の種類、トランスポートの種類、信頼性、セキュリティ、複合全二重などの通信態様が含まれ得る。

また、方法５００は、複数のバインディングオブジェクトから１つのバインディングオブジェクトを選択するユーザ入力を受け取る動作５１０も含む。すなわち、ＵＩ１０２は、複数のバインディングオブジェクト１０４から１つのバインディングオブジェクトを選択するユーザ入力を受け取ることができる。また、方法５００は、選択されたバインディングオブジェクトを記述するメタデータを自動的に作成する動作５１５も含む。すなわち、メタデータ１２５は、複数の標準バインディング１０４からの１つの標準バインディング１０４の選択に基づいて生成され得る。メタデータ内で記述されるバインディングオブジェクトは、実行時に通信態様を実施するプロトコルスタックの抽象表現を提供する。

また、実行時にメタデータ１２５を使って実行時通信チャネル１６５を生成するように構成されるチャネルファクトリ１３５も作成され得る。さらに、サービスエンドポイント１６０でメッセージを処理するために、実行時通信チャネル１６５を受け入れ、通信態様を多重分離するようにリスナーファクトリも構成され得る。バインディングオブジェクトは、基本プロファイルバインディング、ＷＳプロファイルバインディング、ＷＳプロファイル全二重バインディング、．ＮＥＴプロファイルＴＣＰバインディング、．ＮＥＴプロファイル全二重ＴＣＰバインディング、．ＮＥＴプロファイル名前付きパイプバインディング、．ＮＥＴプロファイル待ち行列化バインディング、待ち行列化統合バインディング、仲介バインディングなどの内の１つまたは複数とすることができる。

図６に、バインディングオブジェクトを使って、エンドポイント間でメッセージをやりとりするのに使用されるプロトコルを実施する実行時通信チャネルを作成する方法６００を示す。方法６００は、バインディングオブジェクトを記述するメタデータにアクセスする動作６０５を含む。より具体的には、チャネルファクトリ１３５は、分散システム１００においてエンドポイント間でメッセージがどのようにしてトランスポートされるかを表す複数のユーザ選択のバインディング要素を有するバインディングオブジェクトを含むメタデータ１２５にアクセスすることができる。また、方法６００は、バインディングオブジェクトに基づいて、実行時通信チャネルを開始する動作６１０も含む。より具体的には、チャネルファクトリ１３５は、メタデータ１２５内のバインディングオブジェクトに基づいて、ユーザ選択のバインディング要素に対応する通信態様を含む実行時通信チャネル１６５を開始することができる。通信態様は、前述のように、少なくとも１つのトランスポート態様および１つの符号化態様を含むプロトコルにまとめられる。さらに、方法６００は、実行時通信チャネルを使い、通信態様に従ってメッセージを転送する動作６１５も含む。より具体的には、クライアント１３０は、チャネルファクトリ１３５にチャネル１８０を要求した後、実行時通信チャネル１６５を参照するのに使用されるハンドル１７５を受け取ることができる。その後、メッセージ１７０が、通信態様またはプロトコルスタックに従って、サービス１４０に関連付けられたエンドポイント１６０に送られ、または転送され得る。

別の例示的実施形態は、メッセージ１７０をサービスエンドポイント１６０に送る前に、サービスエンドポイント１６０に対応するリスナー１５０が、実行時通信チャネル１６５を受け入れ、サービスエンドポイント１６０でメッセージを消費するためにメッセージから通信態様を多重分離するサービス通信チャネルを作成すると規定する。この特定の方法６００には前述の別の態様も利用可能である。

また、本発明の範囲内の実施形態には、コンピュータ実行可能命令またはデータ構造を搬送し、または含むコンピュータ可読媒体も含まれる。そのようなコンピュータ可読媒体は、汎用または専用コンピュータによってアクセスされ得る任意の利用可能な媒体とすることができる。例をあげると、それだけに限らないが、そのようなコンピュータ可読媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたはその他の光ディスク記憶、磁気ディスク記憶またはその他の磁気記憶装置、あるいはコンピュータ実行可能命令またはデータ構造の形で所望のプログラムコード手段を搬送し、または格納するのに使用され、汎用または専用コンピュータによってアクセスされ得る他の任意の媒体が含まれ得る。情報がネットワークまたは別の通信接続（有線、無線、または有線と無線の組み合わせ）を介してコンピュータに転送され、または供給されると、コンピュータは、その接続を、正しくコンピュータ可読媒体とみなす。ゆえに、そのような任意の接続は正しくコンピュータ可読媒体と呼ばれる。また、上記の組み合わせもコンピュータ可読媒体の範囲内に含めるべきである。コンピュータ実行可能命令には、例えば、汎用コンピュータ、専用コンピュータ、または専用処理装置に、ある機能または機能群を実行させる命令およびデータが含まれる。

図７および以下の考察は、本発明が実施され得る適当なコンピューティング環境の簡単で、一般的な説明を提供するためのものである。必須ではないが、本発明を、ネットワーク環境でコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的コンテキストで説明する。一般に、プログラムモジュールには、個々のタスクを実行し、または個々の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造体などが含まれる。コンピュータ実行可能命令、関連するデータ構造体、およびプログラムモジュールは、本明細書で開示される方法ステップを実行するプログラムコード手段の例を表す。そのような実行可能命令または関連するデータ構造体の個々のシーケンスは、そのようなステップで示す機能を実施する対応する動作の例を表す。

本発明が、パーソナルコンピュータ、ハンドヘルド機器、マルチプロセッサシステム、マイクロプロセッサベースの、またはプログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む、多様なコンピュータシステム構成を用いたネットワークコンピューティング環境で実施され得ることを、当分野の技術者は理解するであろう。また、本発明は、タスクが、通信ネットワークを介して（有線リンク、無線リンク、あるいは有線リンクまたは無線リンクの組み合わせによって）リンクされたローカルおよびリモートの処理装置によって実行される、分散コンピューティング環境でも実施され得る。分散コンピューティング環境では、プログラムモジュールは、ローカルとリモート両方のメモリ記憶装置に位置し得る。

図７を参照すると、本発明を実施する例示的システムは、処理装置７２１、システムメモリ７２２、およびシステムメモリ７２２を含む様々なシステムコンポーネントを処理装置７２１に結合するシステムバス７２３を含む従来のコンピュータ７２０の形で、汎用コンピューティングデバイスを含む。システムバス７２３は、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む数種類のバス構造のいずれでもよい。システムメモリは、読出し専用メモリ（ＲＯＭ）７２４およびランダムアクセスメモリ（ＲＡＭ）７２５を含む。基本入出力システム（ＢＩＯＳ）７２６は、始動時などにコンピュータ７２０の要素間での情報転送を支援する基本ルーチンを含み、ＲＯＭ７２４に格納され得る。

また、コンピュータ７２０は、磁気ハードディスク７３９との間で読取りおよび書込みを行う磁気ハードディスクドライブ７２７、取り外し可能磁気ディスク７２９との間で読取りまたは書込みを行う磁気ディスクドライブ７２８、およびＣＤ−ＲＯＭや他の光メディアなどの取り外し可能光ディスク７３１との間で読取りまたは書込みを行う光ディスクドライブ７３０を含み得る。磁気ハードディスクドライブ７２７、磁気ディスクドライブ７２８、および光ディスクドライブ７３０は、それぞれ、ハードディスクドライブインターフェース７３２、磁気ディスクドライブインターフェース７３３、および光ドライブインターフェース７３４によってシステムバス７２３に接続される。これらのドライブおよびそれに関連付けられたコンピュータ可読媒体は、コンピュータ７２０に、コンピュータ実行可能命令、データ構造、プログラムモジュールおよびその他のデータの不揮発性の記憶を提供する。本明細書で説明する例示的実施形態は磁気ハードディスク７３９、取り外し可能磁気ディスク７２９および取り外し可能光ディスク７３１を用いるが、磁気カセット、フラッシュメモリカード、ディジタル多用途ディスク、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなどを含めて、データを格納するための他の種類のコンピュータ可読媒体も使用され得る。

オペレーティングシステム７３５、１つまたは複数のアプリケーションプログラム７３６、その他のプログラムモジュール７３７、およびプログラムデータ７３８を含む、１つまたは複数のプログラムモジュールを含むプログラムコード手段は、ハードディスク７３９、磁気ディスク７２９、光ディスク７３１、ＲＯＭ７２４またはＲＡＭ７２５に格納され得る。ユーザは、キーボード７４０、ポインティングデバイス７４２、または、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなど他の入力装置（図示せず）を介してコンピュータ７２０にコマンドおよび情報を入力することができる。上記その他の入力装置は、しばしば、システムバス７２３に結合されたシリアルポートインターフェース７４６を介して処理装置７２１に接続される。代替として、入力装置は、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェースによっても接続され得る。また、モニタまたは別の表示装置も、ビデオアダプタ７４８などのインターフェースを介してシステムバス７２３に接続される。モニタ以外に、パーソナルコンピュータは、通常、スピーカやプリンタなど、他の周辺出力装置（図示せず）も含む。

コンピュータ７２０は、リモートコンピュータ７４９ａ、７４９ｂなど、１つまたは複数のリモートコンピュータへの論理接続を使用するネットワークで接続された環境で動作し得る。リモートコンピュータ７４９ａ、７４９ｂは、それぞれ、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたはその他一般のネットワークノードとすることができ、通常、コンピュータ７２０に関連して前述した要素の多くまたはすべてを含むが、図７には、メモリ記憶装置７５０ａ、７５０ｂおよびそれらに関連付けられたアプリケーションプログラム７３６ａ、７３６ｂだけが示されている。図７に示す論理接続には、本明細書で例として提示するにすぎない、ローカルエリアネットワーク（ＬＡＮ）７５１および広域ネットワーク（ＷＡＮ）７５２が含まれる。そのようなネットワーク環境は、オフィス規模または企業規模のコンピュータネットワーク、イントラネットおよびインターネットではごく一般的である。

ＬＡＮネットワーク環境で使用されるとき、コンピュータ７２０はネットワークインターフェースまたはアダプタ７５３を介してローカルネットワーク７５１に接続される。ＷＡＮネットワーク環境で使用されるとき、コンピュータ７２０は、モデム７５４、無線リンク、またはインターネットなど、広域ネットワーク７５２を介して通信を確立する他の手段を含み得る。モデム７５４は、内蔵でも外付けでもよく、シリアルポートインターフェース７４６を介してシステムバス７２３に接続される。ネットワークで接続された環境では、コンピュータ７２０に関連して示すプログラムモジュール、またはその一部は、リモートメモリ記憶装置にも格納され得る。図示のネットワーク接続は例であり、広域ネットワーク７５２を介して通信を確立する他の手段も使用され得ることが理解されるであろう。

本発明は、その精神および本質的特性を逸脱することなく、他の特定の形でも実施され得る。前述の実施形態は、あらゆる点において、例示にすぎず、限定的ではないとみなされるべきである。したがって、本発明の範囲は、前述の説明によってではなく、添付の特許請求の範囲によって示される。特許請求の範囲と等価の意味および範囲内に含まれるすべての変更は、その範囲内に包含されるべきものである。

例示的実施形態による、メタデータを利用してサービスにメッセージを転送するための実行時通信チャネルを構築する分散システムを示す図である。 例示的実施形態による、グループ化されるバインディング要素の一例を示す図である。 標準バインディングを選択するためのユーザインターフェースの一例を示す図である。 本発明の例示的実施形態による、使用され得る様々なウィザード型ユーザインターフェースを示す図である。 本発明の例示的実施形態による、使用され得る様々なウィザード型ユーザインターフェースを示す図である。 本発明の例示的実施形態による、使用され得る様々なウィザード型ユーザインターフェースを示す図である。 本発明の例示的実施形態による、使用され得る様々なウィザード型ユーザインターフェースを示す図である。 本発明の例示的実施形態による、使用され得る様々なウィザード型ユーザインターフェースを示す図である。 本発明の例示的実施形態による、開発者に、バインディングオブジェクトを構築する、自動化された、使いやすいやり方を提供する方法を示す流れ図である。 本発明の例示的実施形態による、開発者に、よく使用される、互換性のあるバインディングオブジェクトのリストを提供する方法を示す流れ図である。 例示的実施形態による、バインディングオブジェクトを使って実行時通信チャネルを作成する方法を示す流れ図である。 本発明の適当な動作環境を提供する例示的システムを示す図である。

符号の説明

１０５ ストア
１１０ サービス開発側
１１５ バインディング要素
１２０ バインディング記述
１２５ メタデータ
１３０ クライアント
１３５ チャネルファクトリ
１４０ サービス
１４５ リスナーファクトリ
１５０ リスナー
１６０ エンドポイント
１６５ 実行時通信チャネル
１７０ メッセージ
１７５ ハンドル
１８０ 要求
７２１ 処理装置
７２２ システムメモリ
７２３ システムバス
７３２ ハードディスクドライブインターフェース
７３３ 磁気ディスクドライブインターフェース
７３４ 光ドライブインターフェース
７３５ オペレーティングシステム
７３６ａ，ｂ アプリケーションプログラム
７３７ その他のプログラムモジュール
７３８ プログラムデータ
７４０ キーボード
７４６ シリアルポートインターフェース
７４７ モニタ
７４８ ビデオアダプタ
７４９ａ、ｂ リモートコンピュータ
７５１ ローカルエリアネットワーク
７５２ 広域ネットワーク
７５３ ネットワークインターフェース
７５４ モデム

Claims (20)

1. コンピューティングシステムにおいて、開発者に、エンドポイント間でメッセージを転送するときに前記メッセージに通信態様を適用するための実行時通信チャネルを作成する際に使用するバインディングオブジェクトを構築する、自動化された、使いやすいやり方を提供する方法であって、
   選択のためにユーザに、最終的に、クライアントとサービスエンドポイントの間でメッセージをトランスポートするための実行時通信チャネルを作成するのに使用される通信態様を表す複数のバインディング要素を提示する動作と、
   前記複数のバインディング要素から１つまたは複数のバインディング要素を選択するユーザ入力を受け取る動作と、
   前記選択に基づき、
   前記１つまたは複数のバインディング要素のコレクションであり、実行時に前記通信態様を実施するプロトコルスタックの抽象表現を提供するバインディングオブジェクトを記述するメタデータのコレクションと、
   実行時に前記メタデータのコレクションを使って前記実行時通信チャネルを生成するように構成されるチャネルファクトリと、
   前記サービスエンドポイントで前記メッセージを処理するために、前記実行時通信チャネルを受け入れ、前記通信態様を多重分離するように構成されるリスナーファクトリと
   を自動的に作成する動作と
   を備えることを特徴とする方法。
2. それぞれ、トランスポート態様および符号化態様に対応するトランスポートバインディング要素および符号化バインディング要素が選択され、前記トランスポート態様は、ＵＤＰ、ＨＴＴＰ、ＨＴＴＰＳ、ＨＴＴＰＲ、名前付きパイプ、ＴＣＰ、ＳＭＴＰ、メッセージ待ち行列化、メッセージ待ち行列化統合の内の１つであり、前記符号化態様は、テキスト、バイナリ、ＭＴＯＭの内の１つであることを特徴とする請求項１に記載の方法。
3. 前記メタデータのコレクションはＷＳＤＬ文書の一部であることを特徴とする請求項１に記載の方法。
4. 前記複数のバインディング要素は、トランスポート態様、符号化態様、信頼性態様、セキュリティ態様、複合全二重態様、メッセージ形式態様、コンテキストフロー態様、およびトランザクションフロー態様の内の１つまたは複数に対応することを特徴とする請求項１に記載の方法。
5. 前記バインディング要素は、バインディング要素が、前記ユーザに前記複数のバインディング要素を提示するアプリケーションを書き換る必要なく付加され、変更され、または除去され得るという点で十分に拡張可能であり、カスタマイズ可能であることを特徴とする請求項１に記載の方法。
6. 前記バインディング要素は、信頼性グループ、セキュリティグループ、トランスポートグループ、符号化グループおよびその他のグループというグループとして前記ユーザに提示されることを特徴とする請求項１に記載の方法。
7. 前記グループは、バインディング要素が各グループごとに付加され、除去され、または変更され得ると共に、前記グループも付加され、除去され、または変更され得るという点で十分に拡張可能であり、プラグ可能であることを特徴とする請求項６に記載の方法。
8. 複合全二重バインディング要素が選択され、２つのトランスポートバインディング要素が選択されることを特徴とする請求項１に記載の方法。
9. コンピューティングシステムにおいて、開発者に、実行時通信チャネルを作成する際に使用され得る、よく使用される、互換性のあるバインディングオブジェクトのリストを前記開発者に提示することによってバインディングオブジェクトを自動的に構築する簡潔なやり方を提供する方法であって、
   選択のためにユーザに、互換性、およびバインディング要素を組み合わせる産業上の蓋然性に基づいて組み合わされる複数のバインディング要素をそれぞれが含む複数のバインディングオブジェクトを提示する動作であって、前記複数のバインディングオブジェクトのそれぞれが、最終的に、クライアントとサービスエンドポイントの間でメッセージをトランスポートするための実行時通信チャネルを作成するのに使用される複数の通信態様を表す動作と、
   前記複数のバインディングオブジェクトから１つのバインディングオブジェクトを選択するユーザ入力を受け取る動作と、
   実行時に前記通信態様を実施する前記実行時通信チャネルの抽象表現を提供する、前記選択されたバインディングオブジェクトを記述するメタデータのコレクションを自動的に作成する動作と
   を備えることを特徴とする方法。
10. 前記選択に基づき、
    実行時に前記メタデータのコレクションを使って前記実行時通信チャネルを生成するように構成されるチャネルファクトリと、
    前記サービスエンドポイントで前記メッセージを処理するために、前記実行時通信チャネルを受け入れ、前記通信態様を多重分離するように構成されるリスナーファクトリと
    を自動的に作成する動作
    をさらに備えることを特徴とする請求項９に記載の方法。
11. 前記複数のバインディングオブジェクトの１つまたは複数は、それぞれ、トランスポート態様および符号化態様に対応するトランスポートバインディング要素および符号化バインディング要素を含み、前記トランスポート態様は、ＵＤＰ、ＨＴＴＰ、ＨＴＴＰＳ、ＨＴＴＰＲ、名前付きパイプ、ＴＣＰ、ＳＭＴＰ、メッセージ待ち行列化、メッセージ待ち行列化統合の内の１つであり、前記符号化態様は、テキスト、バイナリ、ＭＴＯＭの内の１つであることを特徴とする請求項１０に記載の方法。
12. 前記メタデータのコレクションはＷＳＤＬ文書の一部であることを特徴とする請求項１０に記載の方法。
13. 前記複数のバインディング要素は、トランスポート態様、符号化態様、信頼性態様、セキュリティ態様、複合全二重態様、メッセージ形式態様、コンテキストフロー態様、およびトランザクションフロー態様の内の１つまたは複数に対応することを特徴とする請求項１０に記載の方法。
14. 前記バインディングオブジェクトは、バインディングオブジェクトが、前記ユーザに前記複数のバインディングオブジェクトを提示するアプリケーションを書き換る必要なく、付加され、変更され、または除去され得るという点で十分に拡張可能であり、カスタマイズ可能であることを特徴とする請求項１０に記載の方法。
15. 前記バインディングオブジェクトは、基本プロファイルバインディング、ＷＳプロファイルバインディング、ＷＳプロファイル全二重バインディング、．ＮＥＴプロファイルＴＣＰバインディング、．ＮＥＴプロファイル全二重ＴＣＰバインディング、．ＮＥＴプロファイル名前付きパイプバインディング、．ＮＥＴプロファイル待ち行列化バインディング、待ち行列化統合バインディング、または仲介バインディングの内の１つまたは複数から選択されることを特徴とする請求項１０に記載の方法。
16. クライアントコンピューティングシステムにおいて、バインディングオブジェクトを使い、プロトコルスタックの通信態様に従ってエンドポイント間でメッセージをやりとりするために前記プロトコルスタックを実施する実行時通信チャネルを作成する方法であって、
    最終的に、クライアントとサービスエンドポイントの間でメッセージをトランスポートするための実行時通信チャネルを作成するのに使用される１つまたは複数の通信態様を表す、１つまたは複数のユーザ選択のバインディング要素を含むバインディングオブジェクトを記述するメタデータにアクセスする動作と、
    前記メタデータに基づき、前記１つまたは複数のユーザ選択のバインディング要素に対応する前記１つまたは複数の通信態様を実施するように構成される１つまたは複数のチャネルコンポーネントを含む前記実行時通信チャネルを開始する動作と、
    前記実行時通信チャネルを使い、前記サービスに関連付けられたエンドポイントに、前記１つまたは複数の通信態様に従って前記メッセージを転送する動作と
    を備えることを特徴とする方法。
17. 前記サービスエンドポイントに前記メッセージを送る前に、前記サービス外部ポートに対応するリスナーが、前記サービスエンドポイントで前記メッセージを消費するために、前記メッセージから前記通信チャネルを受け入れ、前記１つまたは複数の通信態様を多重分離することを特徴とする請求項１６に記載の方法。
18. 前記１つまたは複数のバインディング要素には、それぞれ、トランスポート態様および符号化態様に対応するトランスポートバインディング要素および符号化バインディング要素が含まれ、前記トランスポート態様は、ＵＤＰ、ＨＴＴＰ、ＨＴＴＰＳ、ＨＴＴＰＲ、名前付きパイプ、ＴＣＰ、ＳＭＴＰ、メッセージ待ち行列化、メッセージ待ち行列化統合の内の１つであり、前記符号化態様は、テキスト、バイナリ、ＭＴＯＭの内の１つであることを特徴とする請求項１６に記載の方法。
19. 前記メタデータはＷＳＤＬ文書の一部であることを特徴とする請求項１６に記載の方法。
20. 前記１つまたは複数のバインディング要素は、トランスポート態様、符号化態様、信頼性態様、セキュリティ態様、複合全二重態様、メッセージ形式態様、コンテキストフロー態様、およびトランザクションフロー態様の内の１つまたは複数に対応することを特徴とする請求項１６に記載の方法。
    

Images