JP5063899B2 - サービスおよびクライアント・ランタイムを生成、交換、構成するための抽象的な記述の利用 - Google Patents

Description

本発明は、分散アプリケーション・プログラミング・モデルに関し、さらに詳細には、抽象的な記述を利用して、サービスおよびクライント・ランタイムを生成、交換、構成することに関する。

コンピュータ・システムおよび関連技術は、社会の多くの面に影響を及ぼしている。実際に、コンピュータ・システムの情報処理能力は、我々の生活の仕方と働き方とを変化させた。コンピュータ・システムの登場前には手動で行っていた多くのタスク（例えば、ワード・プロセッシングや、スケジュール管理、データベース管理）は、今では普通、コンピュータ・システムによって行われる。さらに最近では、コンピュータ・システムを別のコンピュータ・システムおよび他の電子デバイスに結合して、有線および無線のコンピュータ・ネットワークを形成し、これを介してコンピュータ・システムおよび他の電子デバイスが電子データを転送することができる。結果として、１つのコンピュータ・システムで行われる多くのタスク（例えば、音声コミュニケーションや、電子メールへのアクセス、家庭用電化製品の制御、ウェブ・ブラウズ、文書の印刷）には、有線および／または無線のコンピュータ・ネットワークを介した多数のコンピュータ・システム間および／または多数の電子デバイス間での電子メッセージを交換することが含まれる。

実際、ネットワークの数が増えたので、ネットワーク可能な簡単なコンピューティング・システムが、「インターネット」と呼ばれることの多いネットワークの集合上で、世界中に広がる無数の他のコンピューティング・システムのいずれとも通信できる。このようなコンピューティング・システムは、デスクトップ型、ラップトップ型、タブレット型のコンピュータ、パーソナル・デジタル・アシスタント（「ＰＤＡ」）、電話、またはネットワーク上で通信できる他の任意のコンピュータもしくはデバイスを、含むことができる。

例えばサービス指向アーキテクチャなどのいくつかの環境において、接続エンド・ポイント（「サービス」と呼ばれることが多く、以下そのように呼ぶ）が互いに通信しあって、所望の機能性を実装する。所望の機能性は、２つのサービスがデータを交換するのと同程度に単純である。例えば、あるサービス・コンシューマが、サービス・プロバイダにサービス要求メッセージを送信し、サービス・プロバイダは、そのサービス要求メッセージを受信、処理し、対応するサービス応答メッセージをサービス・コンシューマに戻すことができる。一方、所望の機能性は、さらに複雑にすることもできる。例えば、メッセージを交換する多くのサービスを関係させることで、アクティビティのいくつかを調整することもできる。サービスは通常、対応する提供された接続をサポートするある種のコンピュータ・システム（ハードウェアとソフトウェアの両方）を有する。

交換されるメッセージ（例えば、サービス要求メッセージおよびサービス応答メッセージ）は、所望の機能性を実装することに関わる各サービス（例えば、１つまたは複数のサービス・コンシューマ、および１つまたは複数のサービス・プロバイダ）が理解できるように、方法で、定義することができる。一般に、メッセージは、例えば分散コンポーネント・オブジェクト・モデル（「ＤＣＯＭ」）または、共通オブジェクト・リクエスト・ブローカー・アーキテクチャ（「ＣＯＲＢＡ」）、ウェブ・サービスなどの何らかの標準規格に従って定義することができる。さらに、ウェブ・サービスは、例えばウェブ・サービス記述言語（「ＷＳＤＬ」）、ウェブ・サービス・ポリシー・フレームワーク（「ＷＳ−Ｐｏｌｉｃｙ」）などの各種のウェブ・サービスの仕様に従って定義することができる。

例えば、ＷＳＤＬを使用して、あるサービス・プロバイダは、自身のサービスを記述することができる。サービス・プロバイダは、その記述を、例えばユニバーサル・ディスクリプション・ディスカバリ・アンド・インテグレーション（ＵＤＤＩ）を使用するディレクトリ・サービスにサービスの公開することができる。サービス・コンシューマは、このディレクトリに対し、クエリを発行してサービスの位置を見出し、そのサービスとの通信方法を決定することができる。サービス・プロバイダによって提供されたＷＳＤＬの一部は、クエリへの応答内でサービス・コンシューマに渡される。サービス・コンシューマは、ＷＳＤＬのこの部分を使用してサービス・プロバイダに要求を送信する。そしてサービス・プロバイダは、サービス・コンシューマに適切な応答を提供する。

いくつかの環境では、サービスを生成するために、開発者は特定のプログラミング・モデルに従ってソース・コード（例えばＣ＃あるいは、Ｃ＋＋、Ｖｉｓｕａｌ Ｂａｓｉｃ）を書く。このソース・コードはサービス型（service type）にコンパイルされ、このサービス型は、サービス・コンシューマにサービスを提供するサービス・ランタイムで実行されることができる。しかしながら、サービス・ランタイムは異なる方法で作成することもでき、かつ異なるプログラミング・モデルは異なる方法で分散メッセージング機能を実装できる。例えば、１つのプログラミング・モデルが、要求メッセージを１つ目のインターフェースを使用して実装し、対応応答メッセージを２つ目の異なるインターフェースを使用して実装することができる。一方で、別のプログラミング・モデルでは、要求メッセージおよび対応する応答メッセージの両方を、別個のメソッドを有する単一インターフェースを用いて実装することができる。その単一のインターフェースは、要求メッセージ用に１つ目のメソッドを有し、対応応答メッセージ用に２つ目のメソッドを有することができる。

異なるプログラミング・モデルは、例えば、セキュリティ・オプションや、高信頼性メッセージング・オプション、メッセージ・ロギング・オプション、接続制限オプションなどの異なる構成オプションに従って、構成することもできる。このように、同じ機能性（例えば、数学的操作を行うこと）を実装するように設計された２つのサービスは、その機能性を異なる方法で実装することができる。

さらに、分散アプリケーションは、通常、そのプログラミング・モデルに固定的であり、サービス・ランタイムに密結合した１つのプログラミング・モデルしか許容しない。その結果、互換性のために、（例えば、サービス・コンシューマで）クライアント・ランタイムは、サーバ・ランタイムと同じプログラミング・モデルに従って開発されたクライアント・プログラムまたはクライアント・モジュールを利用することが必要となる。例えば、要求メッセージと応答メッセージに対して別個のインターフェースを使用するか、または特別なセキュリティ・メカニズムを使用してサービスが開発された場合、サービス・コンシューマもそれらを同じように実装しなくてはならない。同じプログラミング・モデルに従って開発されたクライアント・プログラムまたはクライアント・モジュールを使用することをしない場合、クライアント・ランタイムがサービス・ランタイムと通信できない可能性がある。

多くの環境において、サービス記述（またはプログラミング・モデル）および対応するランタイムは固定的に結合している。つまり、サーバが自身のコードを定義し、記述を生成する。そのサービス・ランタイムを利用するために、クライアントはそのサービス記述をダウンロードし、プロキシを生成する。しかし、ダウンロード後にサーバでコードが変化すると、たとえそれが非常に小さな変化であっても、クライアントとサーバの互換性がなくなってしまう。つまり、サービス記述とサービス・ランタイムとが固定的に結合しているために、記述文書の中の構成オプションの１つまたは、定義されるメッセージング・パターン１つを変更するだけで、クライアント・ランタイムが互換性を失う。

あるサービス・ランタイムのプログラミング・モデルを変更すると、既存のクライアント・ランタイムとの互換性がなくなる可能性もある。さらに、その新規のプログラミング・モデルに関連した情報を広めることが難しくなる可能性がある。例えば、あるクライアント・ランタイムの開発者は、その新規のクライアント・ランタイムの開発を始める前に、新規のサービス記述文書が公開されるのを待たなければならない可能性がある。サービス記述文書を生成することは、そのサービスが完成するまで無いことになり、そのためサービス記述文書の生成は、新規プログラミング・モデルに基づく新規サービス・ランタイムの開発に対し遅れる可能性がある。

残念なことに、サービス記述文書を入手不能か、サービス記述文書がどこかで不完全な場合、非互換性の諸問題を識別し、補正することはクライアント・ランタイムの開発者にとって困難である可能性がある。さらに、クライアント・ランタイムの開発者が、サービス・ランタイムの開発者によって書かれたサービス型のソース・コードにアクセスできない可能性がある。そのため、クライアント・ランタイムの開発者は、新規のプログラミング・モデルに関連付けられた新規のメッセージ・パターンあるいは他の新規の構成オプションを決定できない。その結果、クライアント・ランタイムの開発者は、試行錯誤することでしか非互換性の諸問題を識別し、補正することができない。

従って、抽象的な記述を利用してサービスおよびクライアント・ランタイムを生成、交換、構成するシステムと、方法と、コンピュータ・プログラム製品とがあれば有利である。

当分野の従来技術に関する前述の問題は、本発明の原理によって克服される。本発明の原理は、抽象的な記述を利用してサービスおよびクライアント・ランタイムを生成し、交換し、構成する方法、システム、およびコンピュータ・プログラム製品とに向けられる。いくつかの実施形態では、ネットワーク・ベースのサービスを記述する抽象的なサービスの記述をコンピュータ・システムが生成する。このコンピュータ・システムは、特定のプログラミング・モデルに従ってサービスを実装するために、サービス型（例えばコンパイルされたコードを含む）および対応するサービス構成にアクセスする。そしてこのコンピュータ・システムは、サービス型および対応するサービス構成を構文解析して記述情報を識別する。この記述情報は、特定のプログラミング・モデルに基づくそのサービスを記述する。このコンピュータ・システムは識別した記述情報に基づくサービスのサービス記述ツリーを作成する。サービス記述ツリーの形式は、どのプログラミング・モデルからも独立し、かつ１つまたは複数の他の変換モジュールがこのサービス記述ツリーを消費してそのサービスの追加的な表現を他形式で作成することができるようにすることができる。

他の実施形態では、コンピュータ・システムが、ネットワーク・ベースのサービスを記述する抽象的なサービスの記述を、そのサービスを表現するコードに変換する。このコンピュータ・システムは、あるサービス用のサービス記述ツリーにアクセスする。このサービス記述ツリーの形式は、どのプログラミング・モデルからも独立しており、対応するサービス型およびサービス構成から構文解析した記述情報から生成されたものである。このコンピュータ・システムは、このサービス記述ツリーを異なる表現形式にコンバートし、これによりこの記述情報は、この異なる表現形式に従って定義されるサービス記述情報を処理するモジュールに対し、互換性を保って転送されることができる。このコンピュータ・システムは、この異なる表現形式でこの記述情報を出力する。

追加の実施形態では、コンピュータ・システムが、ネットワーク・ベースのサービスを記述する抽象的なサービスの記述からのサービス・ランタイムを初期化する。このコンピュータ・システムは、あるサービスのためのサービス記述ツリーにアクセスする。このサービス記述ツリー形式は、どのプログラミング・モデルからも独立しており、対応するサービス型およびサービス構成から構文解析した記述情報から生成されたものである。このコンピュータ・システムは、そのサービス記述ツリーに関連付けられたサービス・ホストの初期化メソッドを呼び出し、その対応するサービス型およびサービス構成から構文解析したその記述情報に従って、そのサービス用のサービス・ランタイムを初期化する。

さらに別の実施形態では、コンピュータ・システムがチャネル用のソース・コードを生成する。このコンピュータ・システムは、サービスを記述するメタデータにアクセスし、そのメタデータをチャネル用のチャネル記述ツリーにインポートする。このチャネル記述ツリーの形式は、いずれのプログラミング・モデルからも独立している。コンピュータ・システムは、そのチャネル記述ツリーからコード文書オブジェクト・モデルおよび対応するサービス構成を生成する。生成されたコード文書オブジェクト・モデルおよび対応するサービス構成は、特定のプログラミング・モデルに従ってチャネルを実装するためのものである。このコンピュータ・システムは、生成したコード文書オブジェクト・モデルをソース・コードとして出力し、対応するサービス構成を出力する。これにより、コード文書オブジェクト・モデルおよび対応するサービス構成を使用して特定のプログラミング・モデルによりチャネルを開始する（initiate）ことができるようにする。

本発明の目的および特徴は、下記の説明および請求の範囲からいっそう明らかになるであろう。あるいは本発明の目的および特徴は、以下に記載した本発明の実施によって理解することができる。

本発明の上述した利点や、他の利点、特性をさらに明らかにするために、添付図面に示した本発明の特定実施形態を参照することで、本発明をさらに詳しく説明する。添付図面は、本発明の代表的な実施形態を図示したものに過ぎず、そのため本発明を制限するものとして捉えるべきでないことが理解されよう。本発明は、付属図面を使用して、さらに具体的かつ詳細に説明される。

当分野の従来技術に関する前述の問題は、本発明の原理によって克服される。本発明の原理は、抽象的な記述を利用してサービスおよびクライアント・ランタイムを生成し、交換し、構成する方法、システム、およびコンピュータ・プログラム製品とに向けられる。いくつかの実施形態では、ネットワーク・ベースのサービスを記述する抽象的なサービスの記述をコンピュータ・システムが生成する。このコンピュータ・システムは、特定のプログラミング・モデルに従ってサービスを実装するために、サービス型（例えばコンパイルされたコードを含む）および対応するサービス構成にアクセスする。そしてこのコンピュータ・システムは、サービス型および対応するサービス構成を構文解析して記述情報を識別する。この記述情報は、特定のプログラミング・モデルに基づくサービスを記述する。このコンピュータ・システムは識別した記述情報に基づくサービスのサービス記述ツリーを作成する。サービス記述ツリーの形式は、どのプログラミング・モデルからも独立し、かつ１つまたは複数の他の変換モジュールがこのサービス記述ツリーを消費してそのサービスの追加的な表現を他形式で作成することができるようにすることができる。

他の実施形態では、コンピュータ・システムが、ネットワーク・ベースのサービスを記述する抽象的なサービスの記述を、そのサービスを表現するコードに変換する。このコンピュータ・システムは、あるサービス用のサービス記述ツリーにアクセスする。このサービス記述ツリーの形式は、どのプログラミング・モデルからも独立しており、対応するサービス型およびサービス構成から構文解析した記述情報から生成されたものである。このコンピュータ・システムは、このサービス記述ツリーを異なる表現形式にコンバートし、これによりこの記述情報は、この異なる表現形式に従って定義されるサービス記述情報を処理するモジュールに対し、互換性を保って転送されることができる。このコンピュータ・システムは、この異なる表現形式でこの記述情報を出力する。

追加の実施形態では、コンピュータ・システムが、ネットワーク・ベースのサービスを記述する抽象的なサービスの記述からサービス・ランタイムを初期化する。このコンピュータ・システムは、あるサービスのためのサービス記述ツリーにアクセスする。このサービス記述ツリー形式は、どのプログラミング・モデルからも独立しており、対応するサービス型およびサービス構成から構文解析した記述情報から生成されたものである。このコンピュータ・システムは、そのサービス記述ツリーに関連付けられたサービス・ホストの初期化メソッドを呼び出し、その対応するサービス型およびサービス構成から構文解析したその記述情報に従って、そのサービス用のサービス・ランタイムを初期化する。

さらに別の実施形態では、コンピュータ・システムがチャネル用のソース・コードを生成する。このコンピュータ・システムは、サービスを記述するメタデータにアクセスし、そのメタデータをチャネル用のチャネル記述ツリーにインポートする。このチャネル記述ツリーの形式は、いずれのプログラミング・モデルからも独立している。コンピュータ・システムは、そのチャネル記述ツリーからコード文書オブジェクト・モデルおよび対応するサービス構成を生成する。生成されたコード文書オブジェクト・モデルおよび対応するサービス構成は、特定のプログラミング・モデルに従ってチャネルを実装するためのものである。このコンピュータ・システムは、生成したコード文書オブジェクト・モデルをソース・コードとして出力し、対応するサービス構成を出力する。これにより、コード文書オブジェクト・モデルおよび対応するサービス構成を使用して特定のプログラミング・モデルによりチャネルを開始する（initiate）ことができるようにする。

本発明の範囲内の実施形態には、コンピュータ可読媒体が含まれ、当媒体は、その上に格納されたコンピュータ実行可能命令またはデータ構造を搭載あるいは有する。このようなコンピュータ可読媒体は、汎用コンピュータ・システムまたは特殊目的用コンピュータ・システムが、アクセスすることができて利用可能な媒体であれば何でもよい。制限ではなく例として、このようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク・ストレージ、磁気ディスク・ストレージまたは他の磁気ストレージ・デバイスまたは、次の条件を満たす任意の媒体のような、物理ストレージ・メディアを備えることができる。前記条件とは、コンピュータ実行可能命令またはコンピュータ可読命令またはデータ構造の形で所望のプログラム・コード手段を搭載または格納するように使用されること、および汎用コンピュータ・システムまたは特殊目的用コンピュータ・システムによりアクセスできることである。

本説明と請求の範囲において、「ネットワーク」とは、コンピュータ・システムおよび／またはモジュールの間で電子データの転送を可能にする１つまたは複数のデータリンクであると定義される。ネットワークまたは別の通信接続（ハードワイヤード、無線、それらの組合せのいずれか）上で情報がコンピュータ・システムに転送または提供される場合、その接続は、コンピュータ可読媒体とみるのが妥当である。従って、このような接続すべては妥当的にコンピュータ可読媒体と呼ばれる。上述の組合せもコンピュータ可読媒体の範囲に含まれるべきである。例えば、コンピュータ実行可能命令には、汎用コンピュータ・システムまたは特殊目的用コンピュータ・システムにある機能または機能群を行わせる命令およびデータが含まれる。コンピュータ実行可能命令は、例えば、バイナリや、アセンブリ言語またはソース・コードのような中間言語形式の命令であってもよい。

本説明とそれに続く請求の範囲において、「コンピュータ・システム」とは、１つまたは複数のソフトウェア・モジュール、１つまたは複数のハードウェア・モジュール、あるいはこの２つの組合せであると定義され、これらは協働して電子データに対して操作（operation）を実行する。例えば、コンピュータ・システムの定義には、パーソナル・コンピュータのハードウェア・コンポーネントに加え、そのパーソナル・コンピュータのオペレーティング・システムなどのソフトウェア・モジュールが含まれる。モジュールの物理的なレイアウトは、重要ではない。コンピュータ・システムには、ネットワークを介して結合された１つまたは複数のコンピュータが含まれてもよい。同様に、コンピュータ・システムには、（メモリおよびプロセッサなどの）内部モジュールが協働して電子データに対して操作を実行する（携帯電話またはパーソナル・デジタル・アシスタント「ＰＤＡ」などの）単一の物理デバイスが含まれてもよい。

パーソナル・コンピュータや、ラップトップ・コンピュータ、ハンドヘルド・デバイス、マルチ・プロセッサ・システム、ミニ・プロセッサ・ベースまたはプログラム可能な家庭用電化製品、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータ、携帯電話、ＰＤＡや、ポケットベル等を含む多種のコンピュータ・システム構成を有するネットワーク・コンピューティング環境において、本発明を実施可能であることが当業者には理解できるであろう。本発明は、ネットワークを通して（ハードワイヤード・データリンク、無線データリンク、またはそれらの組合せのいずれかによって）リンクされたローカル・コンピュータ・システムおよびリモート・コンピュータ・システム両方がタスクを行うような分散環境で、実施されてもよい。分散システム環境においてプログラム・モジュールが、ローカル・メモリ・ストレージ・デバイスおよびリモート・メモリ・ストレージ・デバイスの両方に存在することができる。

図１を参照する。図１は、抽象的な記述を利用してサービスおよびクライアント・ランタイムを生成し、交換し、構成することを容易にするコンピュータ・アーキテクチャの例１００を示す。コンピュータ・アーキテクチャ１００に示されているように、コンピュータ・システム１０１および１２１がネットワーク１４１に接続されている。ネットワーク１４１は、ローカル・エリア・ネットワーク（「ＬＡＮ」）あるいは、広域エリア・ネットワーク（「ＷＡＮ」）であることができ、さらにインターネットであることさえできる。ネットワーク１４１に接続されたコンピュータ・システムは、ネットワーク１４１に接続された他のコンピュータ・システムに対してデータを送受信できる。従って、コンピュータ・システム１０１および１２１は、接続された他のコンピュータシステム（図示せず）と同様に、ネットワーク１４１上で、メッセージ関連データ（例えば、インターネット・プロトコル（「ＩＰ」）データグラムおよび転送制御プロトコル（「ＴＣＰ」）、ハイパーテキスト転送プロトコル（「ＨＴＴＰ」）、簡易メール転送プロトコル（「ＳＭＴＰ」）、簡易オブジェクト・アクセス・プロトコル（「ＳＯＡＰ」）などのＩＰデータグラムを利用する他の高層プロトコル・メッセージ）を生成し、交換することができる。

コンピュータ・システム１０１は、サービス・ローダ１０４と、メタデータ・エクスポータ１０７と、メタデータ・インポータ１０８と、コントラクト・ジェネレータ１１３とを含む。一般に、サービス・ローダ１０４は、サービス型（例えば、共通言語ランタイム（「ＣＬＲ」）型）あるいは、ネットワーク・ベースのサービスを表現する他のオブジェクト指向プログラミング・モデル・オブジェクトを受信するように構成される。また、サービス・ローダ１０４は、対応するオプション的なサービス構成情報を受信するように構成することもできる。サービス・ローダ１０４は、サービス型（あるいは他のオブジェクト）および対応するサービス構成情報（ロードされていれば）を抽象的なサービスの記述にコンバートすることができる。

いくつかの実施形態では、ネットワーク・ベースのサービスが、特定のプログラミング・モデルに従って表現される。特定のプログラミング・モデルは、１つまたは複数のインターフェースを実装する型（type）であることができる。各インターフェースは、さらに１つまたは複数のメソッドを実装することができる。型（type）に含まれるインターフェースおよびメソッドに対して、それらの処理方法および公開方法と、それらを用いて特定のランタイム処理を行う方法と、を示す属性で注釈付けすることが可能である。代わりに、この注釈属性と組合せて、サービス構成情報は、インターフェースおよびメソッドの処理方法および公開方法と、そのインターフェースおよびメソッドを用いてランタイム処理を行う方法とを示すこともできる。

従って、サービス・ローダ１０４は、サービス型および対応するサービス構成情報をロードすることができる。サービス・ローダ１０４は、プログラミング・モデルおよび対応するサービス構成情報を表現するコンパイルされたコードを構文解析して、表現されているネットワーク・ベースのサービスの機能性を識別することができる。例えば、サービス・ローダ１０４は、サービス型および対応する構成情報から、エンド・ポイントと、チャネル・スタックと、バインディングとを識別することができる。サービス・ローダ１０４は、他のランタイム・オプション、例えば、セキュリティ・オプションおよび、高信頼性メッセージング・オプション、メッセージ・ロギング・オプション、接続制限オプションなどを識別することもできる。サービス・ローダ１０４は識別した機能性から、その機能性を記述する抽象的なサービスの記述を作成することができる。

いくつかの実施形態では、抽象的なサービスの記述は、ネットワーク・ベースのサービスを記述する記述情報のツリーとして整理（arrange）される。例えば、図２を参照する。図２は、抽象的なサービスの記述の例２０１を示す。サービス記述２０１は、サービス記述２０１によって記述されたネットワーク・ベースのサービスの型（例えばＣＬＲ型）を示す、サービス型２０２を含む。示されたサービス型は、記述されたネットワーク・ベースのサービスを提供するためのインターフェースおよびメソッドを実装する型（type）であることができる。サービス型２０２は、サービス型および対応するサービス構成情報を構文解析して識別された型（type）であることができる。

サービス記述２０１は、ＩＳｅｒｖｉｃｅＢｅｈａｖｉｏｒ２０３Ａおよび２０３Ｂも含む。しかし、１つまたは複数の追加のＩＳｅｒｖｉｃｅＢｅｈａｖｉｏｒを含むこともできる。ＩＳｅｒｖｉｃｅＢｅｈａｖｉｏｒ２０３Ａおよび２０３Ｂは、例えばサービス制限（即ち、記述されたサービスへの同時要求数を制限すること）のような、サービス記述２０１によって記述されたネットワーク・ベースのサービスがランタイムに実施する挙動を、表現する。ＩＳｅｒｖｉｃｅＢｅｈａｖｉｏｒ２０３Ａおよび２０３Ｂは、あるサービス型および対応するサービス構成情報を構文解析して識別された挙動であることができる。

サービス記述２０１は、サービス・エンド・ポイント２０４Ａおよび２０４Ｂも含む。しかし、１つまたは複数の追加サービス・エンド・ポイントを含むこともできる。サービス・エンド・ポイント２０４Ａおよび２０４Ｂは、エンド・ポイント・アドレスと、バインディングと、１つまたは複数のコントラクト記述を含む（エンド・ポイント・クラスの）エンド・ポイントを表現する。サービス・エンド・ポイント２０４Ａおよび２０４Ｂは、あるサービス型および対応するサービス構成情報を構文解析して識別されたサービス・エンド・ポイントであることができる。

エンド・ポイント・アドレスとは、記述されたサービスと通信する（例えば、その記述されたサービスの位置を示す）ための電子アドレス（例えば、ユニフォーム・リソース・ロケータ（「ＵＲＬ」））である。例えば、エンド・ポイント・アドレス２１４は、サービス記述２０１によって記述されたネットワーク・ベースのサービスと通信するための電子アドレスであることができる。エンド・ポイント・アドレス２１４は、サービス型および対応するサービス構成情報を構文解析して識別されたエンド・ポイント・アドレスであることができる。

バインディングは、記述されたサービスと通信する時のデータの転送方法を示す。バインディングは、異なる転送特性（transfer characteristics）に適用できるような、複数の異なるバインディング要素を含むことができる。その要素には、例えば、転送バインディング要素（例えば、ハイパーテキスト転送プロトコル（“ＨＴＴＰ”）または転送制御プロトコル（“ＴＣＰ”）を使用）、エンコーダ・バインディング要素（例えば、ＵＴＦ−８またはＵＴＦ−１６を使用）、セキュリティ・バインディング要素（例えば、特定の型（type）の暗号化を使用）がある。例えば、バインディング２１６は、サービス記述２０１によって記述されたネットワーク・ベースのサービスへの、データの転送方法を示すことができる。バインディング２１６は、サービス型および対応するサービス構成情報を構文解析して識別されたバインディングであることができる。

コントラクト記述は、記述されたサービスと通信する時にどのデータ（例えば、メッセージの対話（interaction）パターン）が転送されるべきかを示す。コントラクト記述には、１つまたは複数の操作（operation）を含めることができる。例えば、ネットワーク・ベースの数学サービス用のコントラクト記述は、加算、減算、乗算、除算用の操作を含めることができる。各操作は、１つまたは複数のメッセージを含むことができる。例えば、加算操作には、２つの整数を含む要求メッセージと、その２つの整数の和を含む応答メッセージとを含むことができる。

このように、コントラクト記述２１７Ａは、サービス記述２０１によって記述されたネットワーク・ベースのサービスと通信するための複数のメッセージ対話パターンを示すことができる。操作（例えば、操作２１８）には、例えば、１つの入力メッセージまたは１つの出力メッセージなどの単一メッセージ（例えば、メッセージ２２８）を含むものもある。他の操作（例えば、操作２１９）には、例えば、１つの要求メッセージおよび１つの応答メッセージなどの２つのメッセージが含まれるものもある。

明示していないが、コントラクト記述２１７Ｂは、サービス記述２０１によって記述されたネットワーク・ベースのサービスと通信するための複数のメッセージ対話パターンも示す。このように、コントラクト記述２１７Ｂは、１つまたは複数の操作を含むことができ、各操作は１つまたは複数のメッセージを含むことができる。

図１を再度参照すると、メタデータ・エクスポータ１０７は、例えばサービス記述２０１などの抽象的なサービスの記述を、例えばウェブ・サービス記述言語（「ＷＳＤＬ」）文書などの対応するメタデータにエクスポートすることができる。一般に、メタデータ・エクスポータ１０７は、抽象的なサービスの記述を調べて、その抽象的なサービスの記述を、対応するメタデータ、例えばＷＳＤＬ文書などに変換するように構成される。

メタデータ・エクスポータ１０７は、拡張可能マークアップ言語（「ＸＭＬ」）にシリアライズ可能なオブジェクト・モデルをターゲットにすることができる。そのため、メタデータ・エクスポータ１０７は、抽象的なサービスの記述を、メタデータを表現するオブジェクトにエクスポートすることも可能である。その後、そのメタデータを表現しているオブジェクトを生のメタデータへとシリアライズ化することができる。例えば、メタデータ・エクスポータ１０７は、抽象的なサービスの記述を、ＷＳＤＬ文書を表現するオブジェクトにエクスポートすることができる。その後、このオブジェクトをＷＳＤＬ文書へとシリアライズ化することができる。代わりに、メタデータ・エクスポータ１０７は、生のＷＳＤＬ文書（または他のメタデータ）をエクスポートすることができる。

ある抽象的なサービスの記述をメタデータにエクスポートすることは、その抽象的なサービスの記述の構成体（constructs）をメタデータ形式の適切な構成体とマッチさせることを含むことができる。例えば、メタデータ・エクスポータ１０７は、抽象的なサービスの記述のバインディング要素（例えばバインディング２１６のバインディング要素）を適切なＷＳＤＬバインディング要素とマッチさせることができる。

メタデータ・インポータ１０８は、例えばＷＳＤＬ文書などのメタデータを例えばサービス記述２０１などの対応する抽象的なサービスの記述にインポートすることができる。一般に、メタデータ・インポータ１０８は、メタデータを調べて、そのメタデータを対応する抽象的なサービスの記述へと変換するように構成される。

メタデータ・インポータ１０８は、拡張マークアップ言語（「ＸＭＬ」）にシリアライズ可能なオブジェクトを受信することができる。例えば、メタデータ・インポータ１０８は、ＷＳＤＬオブジェクトを表現するオブジェクトを受信することができる。メタデータ・インポータ１０８はそのオブジェクトを調べて、表現されたネットワーク・ベースのサービスの機能性を識別することができる。メタデータ・インポータ１０８は、サービス型および対応する構成情報から、例えば、エンド・ポイントと、チャネル・スタックと、バインディングとを識別することができる。また、メタデータ・インポータ１０８は、例えば、セキュリティ・オプション、高信頼性メッセージング・オプション、メッセージ・ロギング・オプション、接続制限オプションなどの他のランタイム・オプションを識別することもできる。メタデータ・インポータ１０８は、識別された機能性から、その機能性を記述する抽象的なサービスの記述を作成することができる。代わりに、メタデータ・インポータ１０８は、生のＷＳＤＬ（または他のメタデータ）を受信し、同様の操作を行って、抽象的なサービスの記述を作成することができる。

メタデータを抽象的なサービスの記述にインポートすることには、そのメタデータ形式の構成体を抽象的なサービスの記述の適切な構成体とマッチさせることを含むことができる。例えば、メタデータ・インポータ１０８は、あるメタデータ形式のバインディング要素を抽象的なサービスの記述の適切なバインディングとマッチさせることができる。

メタデータ・エクスポータ１０７およびメタデータ・インポータ１０８は共に、抽象的なサービスの記述からメタデータへのコンバートおよびその逆を行う場合に、拡張性を促進するサード・パーティのプラグインをサポートするように構成することができる。サード・パーティのプラグインは、抽象的なサービスの記述とメタデータ間のカスタマイズされた変換を実装できる。例えば、プラグインは、ＷＳ−Ｐｏｌｉｃｙ、ＷＳ−ＲＭ（高信頼性メッセージング）などのウェブ・サービス仕様に従って定義されるポリシー・ステートメントの変換を容易にすることができる。ＷＳ−Ｐｏｌｉｃｙを使用して、例えば、ある方法で暗号化を行うために、鍵の情報を提供するなどの任意のポリシーを仮想的に表現するＸＭＬ要素を定義することができる。ＷＳ−ＲＭを使用して、例えばタイムアウト値などの高信頼性メッセージングの特性を定義することができる。

この結果、拡張可能なポリシー・ステートメントを、ＷＳＤＬ文書にエクスポートすること、およびＷＳＤＬ文書からインポートすることができる。例えば、メタデータ・エクスポータ１０７へのエクスポータ・プラグインは、ポリシー要素の抽象的なサービスの記述を調べ、適切なポリシー・アサーションをＷＳＤＬ文書内に挿入することができる。このように、抽象的なサービスの記述の中のバインディングが、定義されたＲＭバインディング要素を含む場合、エクスポータ・プラグインは、そのＲＭバインディング要素を見つけ、適切なＲＭポリシー・アサーションをエクスポートされるメタデータに加えることができる。一方、メタデータ・インポータ１０８へのインポータ・プラグインは、ＷＳＤＬ文書を調べてポリシー・アサーションを探し、適切なポリシー要素を抽象的なサービスの記述内に挿入することができる。このように、メタデータがバインディング要素に対するＲＭポリシー・アサーションを含む場合、インポータ・プラグインは、そのＲＭポリシー・アサーションを見つけ、適切な定義されたＲＭバインディング要素を、インポートされた抽象的なサービスの記述に加えることができる。

プラグインは、抽象的なサービスの記述の一部分を、ＷＳＤＬ文書中の任意のＸＭＬ要素および属性へエクスポートすること、およびＷＳＤＬ文書中の任意のＸＭＬ要素および属性を抽象的なサービスの記述の適切な部分にインポートすることを、容易にすることもできる。

なお図１を参照すると、コントラクト・ジェネレータ１１３は、抽象的なサービスの記述をコード文書オブジェクト・モデルおよび対応するサービス構成情報にコンバートすることができる。一般に、コントラクト・ジェネレータ１１３は、抽象的なサービスの記述を調べ、その抽象的なサービスの記述を対応するコード文書オブジェクト・モデルおよびサービス構成情報に変換するように構成される。

サービス・コントラクト・ジェネレータ１１３は、例えばコード文書オブジェクト・モデル（「ＣｏｄｅＤＯＭ」）などのパブリック・オブジェクト・モードをターゲットにすることができる。言語プロバイダがＣｏｄｅＤＯＭを使用して、そのＣｏｄｅＤＯＭに基づくコード（例えば、Ｃ＃または、Ｃ＋＋、Ｖｉｓｕａｌ Ｂａｓｉｃ）を生成することができる。このように、抽象的なサービスの記述を、コントラクト記述を表現するインターフェースと、操作を表現するメソッドと、メッセージを表現するパラメータおよび戻り値と、にコンバートすることができる。結果的に、言語に中立な形式の中のソース・コードが、ワイヤ上にＸＭＬがどう現れるべきかを示すこと、および何らかのセキュリティ情報を含むことができる。

サービス・コントラクト・ジェネレータ１１３は、対応するサービス構成情報、例えば、サービス・エンド・ポイント、エンド・ポイント・アドレス、バインディング、チャネルの挙動などをサービス構成ファイルに格納することもできる。ソース・コードから生成されたサービス型（コンパイルされたコード）が、抽象的なサービスの記述とやりとりするために構文解析される際に、この構成ファイルがサービス・ローダに提供されることができる。いくつかの実施形態において、コード文書オブジェクト・モデルおよび構成ファイルは、クライアントで使用されて、記述されたサービスと通信するためのチャネルを構築することができる。

コンピュータ・システム１２１は、チャネル・ローダ１２４と、メタデータ・インポータ１２８と、コントラクト・ジェネレータ１３３と、コード・コンバータ１３８と、コンパイラ１４３とを含む。

チャネル・ローダ１２４は、サービス・ローダ１０４と同様に機能する。チャネル・ローダ１２４は、チャネル型および対応するチャネル構成情報をロードすることができる。チャネル・ローダ１２４は、プログラミング・モデルおよび対応するチャネル構成情報を表現するコンパイルされたコードを構文解析して、ネットワーク・ベースのサービスと通信するための機能性を識別することができる。例えば、チャネル・ローダ１０４は、エンド・ポイントと、チャネル・スタックと、バインディングとを、チャネル型および対応する構成情報から識別することができる。チャネル・ローダ１２４は、例えば、セキュリティ・オプション、高信頼性メッセージング・オプション、メッセージ・ロギング・オプション、接続制限オプションなどの、他のランタイム・オプションを識別することもできる。識別した機能性から、チャネル・ローダ１２４は、その機能性を記述する抽象的なチャネルの記述を作成することができる。

いくつかの実施形態では、抽象的なチャネルの記述は、ネットワーク・ベースのサービスとの通信方法を記述する記述情報ツリーとして整理される。例えば、図３を参照する。図３は、抽象的なチャネルの記述の例３０１を示す。チャネル記述３０１は、チャネル記述３０１によって記述されたネットワーク・ベースのチャネルの型（例えばＣＬＲ型）を示すチャネル型３０２を含む。示されたチャネル型は、対応するネットワーク・ベースのサービスと通信するためのインターフェースおよびメソッドを実装する型であることができる。チャネル型３０２は、サービス型および対応するサービス構成情報を構文解析して識別された型であることができる。

チャネル記述３０１は、ＩＣｈａｎｎｅｌＢｅｈａｖｉｏｒ３０３Ａおよび３０３Ｂも含む。しかし、１つまたは複数のＩＣｈａｎｎｅｌＢｅｈａｖｉｏｒを含むこともできる。ＩＣｈａｎｎｅｌＢｅｈａｖｉｏｒ３０３Ａおよび３０３Ｂは、例えば高信頼性メッセージングおよび権限付与のような、チャネル記述３０１によって記述されたネットワーク・ベースのチャネルがランタイムに実施する挙動を、表現する。ＩＣｈａｎｎｅｌＢｅｈａｖｉｏｒ３０３Ａおよび３０３Ｂは、チャネル型および対応するサービス構成情報を構文解析して識別された挙動であることができる。

チャネル記述３０１は、サービス・エンド・ポイント３０４も含む。サービス・エンド・ポイント３０４は、１つのエンド・ポイント・アドレスと、１つのバインディングと、１つまたは複数のコントラクト記述とを含む（エンド・ポイント・クラスの）エンド・ポイントを表現する。サービス・エンド・ポイント３０４は、チャネル型および対応するサービス構成情報を構文解析して識別されたサービス・エンド・ポイントであることができる。

エンド・ポイント・アドレス３１４は、チャネル記述３０１によって記述されたネットワーク・ベースのチャネルと通信するための電子アドレスであることができる。エンド・ポイント・アドレス３１４は、チャネル型および対応するサービス構成情報を構文解析して識別されたエンド・ポイント・アドレスであることができる。バインディング３１６は、チャネル記述３０１によって記述されたネットワーク・ベースのチャネルへの、データの転送方法を示すことができる。バインディング３１６は、サービス型および対応するサービス構成情報を構文解析して識別されたバインディングであることができる。コントラクト記述３１７は、サービス記述３０１によって記述されたネットワーク・ベースのチャネルと通信するための複数のメッセージ対話（interaction）パターンを示すことができる。操作の中には（例えば操作３１８）、例えば、入力または出力メッセージのような単一メッセージ（例えばメッセージ３２８）を含むものがある。他の操作（例えば操作３１９）には、例えば、１つの要求メッセージと１つの応答メッセージのように、２つのメッセージ（例えば、メッセージ３２９および３３９）を含むことができるものがある。

メタデータ・インポータ１２８は、メタデータ・インポータ１０８と同様に機能する。そのため、メタデータ・インポータ１２８は、例えば、ＷＳＤＬ文書などのメタデータを、例えばチャネル記述２０１などの対応する抽象的なチャネルの記述にインポートすることができる。一般に、メタデータ１２８は、メタデータを調べて、そのメタデータを対応する抽象的なチャネルの記述に変換するように構成される。メタデータ・インポータ１２８は前述のように、シリアライズ可能なオブジェクトまたは生のメタデータをインポートすることができ、拡張可能なサード・パーティのプラグインを含むことができる。メタデータ・インポータ１２８は、メタデータ形式の構成体を、抽象的なサービスの記述の適切な構成体にマッチさせることもできる。例えば、メタデータ・インポータ１２８は、あるメタデータ形式のバインディング要素を適切な抽象的なチャネルの記述バインディングにマッチさせることができる。

コントラクト・ジェネレータ１３３は、コントラクト・ジェネレータ１１３と同様に機能する。そのため、コントラクト・ジェネレータ１３３は、抽象的なチャネルの記述をコード文書オブジェクト・モデルおよび対応するサービス構成情報にコンバートすることができる。一般に、コントラクト・ジェネレータ１３３は、抽象的なチャネルの記述を調べて、その抽象的なチャネルの記述を対応するコード文書オブジェクト・モデルおよびサービス構成情報に変換するように構成される。コントラクト・ジェネレータ１３３は、ソース・コードを言語に中立な形式で表現するパブリック・オブジェクトをターゲットにすることができ、続いてサポートされたプログラミング言語にそのコードをコンバートすることができる。このように、抽象的なチャネルの記述を、コントラクト記述を表現するインターフェースと、操作を表現するメソッドと、メッセージを表現するパラメータおよび戻り値と、にコンバートすることができる。結果的に、言語に中立な形式のソース・コードが、ワイヤ上でＸＭＬがどう現れるべきかを示すことができ、いくつかのセキュリティ情報を含むことができる。

コントラクト・ジェネレータ１３３は、例えば、サービス・エンド・ポイント、エンド・ポイント・アドレス、バインディング、チャネルの挙動などの対応するサービス構成情報をサービス構成ファイルに格納することができる。ソース・コードから生成されたチャネル型（コンパイルされたコード）が、抽象的なチャネルの記述とやりとりするために構文解析される際に、この構成ファイルがチャネル・ローダに提供されることができる。いくつかの実施形態において、コード文書オブジェクト・モデルおよび構成ファイルは、クライアントで使用されて、記述されたサービスと通信するためのチャネルを構築することができる。

コード・コンバータ１３８は、コード文書オブジェクト・モデルをプログラミング言語のソース・コードにコンバートするように構成される。コード・コンバータ１３８は、コード文書オブジェクト・モデルの生成に使用される同じオブジェクト・モデルの一部分とすることができる。コンパイラ１４３は、プログラミング言語をチャネル型のコンパイルされたコードにコンパイルするように構成される。コンパイラ１４３は、例えば、Ｃ＃、Ｃ＋＋、またはＶｉｓｕａｌ Ｂａｓｉｃのコンパイラであり、統合開発環境（“ＩＤＥ”）の一部分とすることができる。

図５は、ネットワーク・ベースのサービスを記述する抽象的なサービスの記述を生成するメソッドの例５００のフローチャートを示す。メソッド５００は、コンピュータ・アーキテクチャ１００およびサービス記述２０１に図示された、コンポーネントおよびデータに関連して記述される。

メソッド５００は、特定のプログラミング・モデルに従ってサービスを実装するために、サービス型および対応するサービス構成にアクセスする動作（act）（動作５０１）を含む。例えば、サービス・ローダ１０４は、サービス型１０２および構成１０３にアクセスすることができる。サービス型１０２は、何らかのプログラミング言語（Ｃ＃、Ｃ＋＋、Ｖｉｓｕａｌ Ｂａｓｉｃなど）のソース・コードからコンパイルされたコンパイル済コードを表現することができる。サービス型１０２に含まれるインターフェースおよびメソッドに対して、サービスを記述する属性で注釈付けすることができる。構成１０３は、このサービスを記述する追加のサービス構成情報を含むことができる。

メソッド５００は、アクセスしたサービス型および対応するサービス構成を構文解析して記述情報を識別する動作（act）（動作５０２）を含む。例えば、サービス・ローダ１０４は、サービス型１０２および構成１０３を構文解析して、サービス型１０２によって表現されたサービスに対応する記述情報を識別することができる。識別された記述情報は、例えば、サービス型や、サービスの挙動（例えば、セキュリティ・オプション、高信頼性メッセージング・オプション、メッセージ・ロギング・オプション、接続制限オプション）、サービス・エンド・ポイント（例えば、操作およびメッセージを含むエンド・ポイント・アドレスや、バインディング、コントラクト記述）などの様々な接続および／または通信プロトコル・オプションを含むことができる。

メソッド５００は、識別した記述情報に基づくサービス用のサービス記述ツリーを、生成する動作（act）（動作５０３）を含む。例えば、サービス・ローダ１０４は、サービス型１０２および構成１０３から識別された記述情報に基づき、サービス記述１０６を生成することができる。サービス記述１０６は、サービス記述２０１と同様のサービス記述ツリーであることができる。識別されたサービス型と、識別されたサービスの挙動と、識別されたサービス・エンド・ポイントとは、対応するツリー構造中の適切な位置で生成されることができる。

図６は、ネットワーク・ベースのサービスを記述する抽象的なサービスの記述をそのサービスを表現するコードに変換するメソッドの例６００のフローチャートを示す。コンピュータ・アーキテクチャ１００内に図示されたコンポーネントおよびデータとの関連で、メソッド６００を説明する。

メソッド６００は、サービス用のサービス記述ツリーにアクセスする動作（act）（動作６０１）を含む。例えば、メタデータ・エクスポータ１０７は、サービス記述１０６にアクセスすることができる。代わりに、コントラクト・ジェネレータ１１３が、サービス記述１０６にアクセスすることもできる。

メソッド６００は、このサービス記述ツリーを異なる表現形式にコンバートする動作（act）を含み、そうすることでこの記述情報を、この異なる表現形式に従って定義されるサービス記述情報を処理するモジュールに対し、互換性を保って転送されることができるようにする動作（act）（動作６０２）を含む。例えば、メタデータ・エクスポータ１０７は、メタデータ・インポータ（例えば、メタデータ・インポータ１２８）が引き続いてメタデータ１０９（またはメタデータ１０９を表現するオブジェクト）をサービス（またはチャネル）記述にインポートし直せるように、サービス記述１０６をメタデータ１０９（またはメタデータ１０９を表現するオブジェクト）にエクスポートできる。

代わりに、コントラクト・ジェネレータ１１３が、サービス記述１０６をコード文書オブジェクト・モデル１１４と構成１１６とにコンバートすることができる。続いて、コード文書オブジェクト・モデル１１４を使用して、プログラミング言語のソース・コードを生成することができる。そのコードを開発者が適宜修正して、適切な機能性を保障するか、あるいは追加の機能性を加えることができる。そして、このプログラミング言語のソース・コードをコンパイルすることができる。構成１１６は、構成１０３からの構成情報のサブセットを少なくとも１つ含む。例えば、構成１１６は、サービス型１０２に基づくサービス・ランタイムと通信するチャネルを構築するための適切な構成設定を含むことができる。

メソッド６００は、記述情報を異なる表現形式で出力する動作（act）（動作６０３）を含む。例えば、メタデータ・エクスポータ１０７は、メタデータ１０９をメタデータ・インポータ１２８に送信することができる。代わりに、コントラクト・ジェネレータ１１３が、コード文書オブジェクト・モデル１１４と構成１１６とをコンピュータ・システム１２１に送信できる。引き続いてコンピュータ・システム１２１において、メタデータ１０９と、コード文書オブジェクト・モデル１１４および構成１１６のいずれもチャネルへとコンバートし、修正し、および／またはコンパイルすることができる。

図７は、ネットワーク・ベースのサービスを記述する抽象的なサービスの記述からのランタイムを初期化するメソッドの例７００のフローチャートを示す。コンピュータ・アーキテクチャ１００内に図示されたコンポーネントおよびデータとの関連でメソッド７００を説明する。

メソッド７００は、サービス用のサービス記述ツリーにアクセスする動作（act）（動作７０１）を含む。このサービス記述ツリーは、対応するサービス型および対応するサービス構成から構文解析された記述情報から生成されたものである。例えば、コンピュータ・システム１０１は、サービス型１０２および構成１０３から構文解析した記述情報から生成されたサービス記述１０６にアクセスすることができる。

メソッド７００は、サービス記述ツリーに関連付けられた初期化サービス・ホスト・メソッドを呼び出す動作（act）を含む（動作７０２）。例えば、コンピュータ・システム１０１は、サービス記述１０６に関連付けられたサービス・イニシャライザ１１１を呼び出すことができる。いくつかの実施形態では、この初期化（イニシャライズ）サービス・ホストは、サービス記述１０６に含まれる実行可能なコードである。そのため、サービス記述１０６が、サービス・イニシャライザ１１１を呼び出してもよい。

メソッド７００は、対応するサービス型および対応するサービス構成から構文解析された記述情報に従ってサービス用のサービス・ランタイムを初期化する動作（act）（動作７０３）を含む。例えば、サービス・ランタイム１１２を、サービス型１０２および構成１０３から構文解析した記述情報に従って初期化することができる。

図８は、チャネル用のソース・コードを生成するためのメソッドの例８００のフローチャートを示す。コンピュータ・アーキテクチャ１００内に図示したコンポーネントおよびデータとの関連でメソッド８００を説明する。

メソッド８００は、サービスを記述するメタデータにアクセスする動作（act）（動作８０１）を含む。例えば、メタデータ・インポータ１２８は、メタデータ１０９にアクセスすることができる。メソッド８００は、このメタデータをチャネル用のチャネル記述ツリーにインポートする動作（act）（動作８０２）を含む。

メソッド８００は、このチャネル記述ツリーから、コード文書オブジェクト・モデルおよび対応するサービス構成を生成する動作（act）（動作８０３）を含む。例えば、コントラクト・ジェネレータ１３３は、コード文書オブジェクト・モデル１３４および構成１３６をチャネル記述１２６から生成することができる。

メソッド８０４は動作（act）（動作８０４）を含む。この動作（act）は、生成されたコード文書オブジェクト・モデルおよび対応するサービス構成が特定のプログラミング・モデルによるチャネル初期化に使用されるように、それらを出力する。例えば、コード・コンバータ１３８は、コード文書オブジェクト・モデル１３４を使用して、ソース・コード１３９を生成することができる。コンパイラ１４３は、ソース・コード１３９をチャネル型１３２にコンパイルすることができる。

チャネル・ローダ１２４は次いで、チャネル型１３２および構成１３６を構文解析して、リファインされたチャネル記述１２６を生成することができる。続いて、チャネル記述１２６は、チャネル・イニシャライザ１３１を呼び出して、チャネル型１３２および構成１３６から構文解析した記述情報に従って、チャネル１３２を初期化することができる。その後、チャネル１３２およびサービス・ランタイム１１２は通信し、サービス型１０２によって表現されたサービスを利用することができる。

本発明の実施形態は、サービス記述情報の柔軟な交換を容易にする。例えば、サービス・ランタイムと互換性のある通信を行うためのチャネル構成方法を示すメタデータおよび／またはソース・コードを、サーバがクライアントに提供することができる。さらに、サード・パーティのプラグインは、サーバとクライアントとの間で、ポリシー・アサーションおよび任意のＸＭＬをインポートおよびエクスポートすることを容易にする。従って、本発明は、サービス・ランタイムと、対応するチャネルとの間の相互操作性（interoperability）を向上させる。

図４は、本発明の原理に適合したオペレーティング環境を示す。図４および下記の記述は、本発明を実装することができる好適なコンピューティング環境の簡単で一般的な説明を提供するよう意図したものである。必須要件ではないが、本発明は、プログラム・モジュールなどのコンピュータ・システムによって実行されるコンピュータ実行可能命令の一般的なコンテキストで説明される。一般に、プログラム・モジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれ、これらは、特定のタスクを行うか、あるいは特定の抽象データ型を実装する。コンピュータ実行可能命令と、関連するデータ構造と、プログラム・モジュールとが、本明細書に開示したメソッドの動作（act）を実行するプログラム・コード手段の例を表現する。

図４を参照すると、本発明を実装するシステム例には、コンピュータ・システム４２０の形で汎用コンピューティング・デバイスが含まれ、コンピュータ・システム４２０は、処理ユニット４２１、システム・メモリ４２２と、システム・メモリ４２２を含む各種のシステム・コンポーネントを処理ユニット４２１に結合するシステム・バス４２３とを含む。処理ユニット４２１は、コンピュータ・システム４２０の特徴を実装するよう設計されたコンピュータ実行可能命令を実行することができる。コンピュータ・システム４２０の特徴は、本発明の特徴を含む。システム・バス４２３は、メモリ・バスまたはメモリ・コントローラ、周辺バス、様々なバス・アーキテクチャのいずれかを使用するローカル・バスを含む数種類のバス構造のいずれかであればよい。システム・メモリは、リード・オンリ・メモリ（「ＲＯＭ」）４２４およびランダム・アクセス・メモリ（「ＲＡＭ」）４２５を含む。起動時などに、コンピュータ・システム４２０内の要素間で情報を転送するのを助ける基本ルーチンを含む基本入力／出力システム（「ＢＩＯＳ」）４２６をＲＯＭ４２４に格納してもよい。

コンピュータ・システム４２０は、磁気ハードディスク４３９から読み取りかつそこへ書き込む磁気ハードディスク・ドライブ４２７と、取り外し可能な磁気ディスク４２９から読み取りかつそこへ書き込む磁気ディスク・ドライブ４２８、取り外し可能な光ディスク４３１、例えばＣＤ−ＲＯＭまたは他の光媒体などから読み取りかつそこへ書き込む光ディスク・ドライブ４２８とを含んでもよい。磁気ハードディスク・ドライブ４２７、磁気ディスク・ドライブ４２８、光ディスク・ドライブ４３０は、それぞれハードディスク・ドライブ・インターフェース４３２、磁気ドライブ・インターフェース４３３、光ドライブ・インターフェース４３４によってシステム・バス４２３に接続されている。このドライブとそれぞれに関連付けられたコンピュータ可読媒体は、コンピュータ実行可能命令、データ構造、プログラム・モジュール、他のデータの不揮発性のストレージをコンピュータ・システム４２０に提供する。ここで説明する環境例は、磁気ハードディスク４３９および、取り外し可能な磁気ディスク４２９、取り外し可能な光ディスク４３１を採用するが、データを格納する他種のコンピュータ可読媒体を使用することもできる。他種のコンピュータ可読媒体は、磁気カセットやフラッシュ・メモリ・カード、デジタル多用途ディスク、Bernoulli cartridges、ＲＡＭ、ＲＯＭなどを含む。

ハードディスク４３９、磁気ディスク４２９、光ディスク４３１、ＲＯＭ４２４、ＲＡＭ４２５のいずれかに、１つまたは複数のプログラム・モジュールを備えるプログラム・コード手段を格納してもよい。１つまたは複数のプログラム・モジュールは、オペレーティング・システム４３５と、１つまたは複数のアプリケーション・プログラム４３６と、他のプログラム・モジュール４３７と、プログラム・データ４３８とを含む。キーボード４４０、ポインティング・デバイス４４２または、例えばマイクもしくは、ジョイスティック、ゲームパッド、スキャナなどの他の入力デバイス（図示せず）を介して、ユーザはコマンドおよび情報をコンピュータ・システム４２０に入力することができる。システム・バス４２３に結合された入力／出力インターフェース４４６を介して、これら入力デバイスと他の入力デバイスを処理ユニット４２１に接続することができる。入力／出力インターフェース４４６は、任意の多種多様な異なるインターフェース、例えば、シリアル・ポート・インターフェース、ＰＳ／２インターフェース、パラレル・ポート・インターフェース、ユニバーサル・シリアル・バス（「ＵＳＢ」）インターフェースまたはＩＥＥＥ（米国電気電子学会）１３９４インターフェース（すなわちファイヤー・ワイヤ・インターフェース）などを論理的に表現し、場合によっては、異なるインターフェースの組合せを論理的に表現してもよい。

モニタ４４７と他の表示デバイスもまた、ビデオ・インターフェース４４８経由でシステム・バス４２３に接続されている。コンピュータ・システム４２０には、例えば、スピーカおよびプリンタなどの他の周辺出力デバイス（図示せず）を接続することもできる。

コンピュータ・システム４２０は、例えば、事業所規模か企業規模のコンピュータ・ネットワークや、ホームネットワーク、イントラネットおよび／またはインターネットなどのネットワークに接続することが可能である。コンピュータ・システム４２０は、例えば、このようなネットワーク上で、リモート・コンピュータ・システムや、リモート・アプリケーションおよび／またはリモート・データベースなどの外部ソースとデータを交換することができる。

コンピュータ・システム４２０は、ネットワーク・インターフェース４５３を含み、ネットワーク・インターフェース４５３を介して、コンピュータ・システム４２０は、外部ソースからデータを受信し、および／または外部ソースにデータを送信する。図４に図示したように、ネットワーク・インターフェース４５３によって、リンク４５１経由でリモート・コンピュータ・システム４８３とデータ交換することが容易になる。ネットワーク・インターフェース４５３は、例えば、ネットワーク・インターフェース・カードおよび対応するネットワーク・ドライバ・インターフェース仕様（「ＮＤＩＳ」）スタックなどの１つまたは複数のソフトウェア・モジュールおよび／またはハードウェア・モジュールを論理的に表示することができる。リンク４５１は、ネットワーク（例えば、イーサネット（登録商標）のセグメント）の一部を表現し、リモート・コンピュータ・システム４８３は、そのネットワークのノードを表現する。

同様に、コンピュータ・システム４２０は、入力／出力インターフェース４４６を含み、入力／出力インターフェース４４６によって、コンピュータ・システム４２０は、外部ソースからデータを受信し、および／または外部ソースにデータを送信する。入力／出力インターフェース４４６は、リンク４５９経由でモデム４５４（例えば、スタンダード・モデムまたは、ケーブル・モデム、デジタル加入者回線（「ＤＳＬ」）モデム）に結合され、この結合によって、コンピュータ・システム４２０は、外部ソースからデータを受信し、および／または外部ソースにデータを送信する。図４に図示したように、入力／出力インターフェース４４６およびモデム４５４によって、リンク４５２経由でリモート・コンピュータ・システム４９３とデータを交換することが容易になる。リンク４５２は、ネットワークの一部を表現し、リモート・コンピュータ・システム４９３は、そのネットワークのノードを表現する。

図４は、本発明に適したオペレーティング環境を表現するが、本発明の原理を、必要であれば適宜修正して本発明の原理を実装することができるいずれのシステムにも採用してもよい。図４に示した環境は、例示に過ぎず、本発明を実装することができる多様な環境のほんの一部のみを表現するものではない。

本発明に従って、サービス型、構成、コード文書オブジェクト・モデル、メタデータ、サービス記述、チャネル記述を含む関連データに加えて、サービス・ローダ、コントラクト・ジェネレータ、メタデータ・インポータ、メタデータ・エクスポータ、サービス・イニシャライザ、サービス・ランタイム、チャネルを含むモジュールも、コンピュータ・システム４２０に関連付けられたコンピュータ可読媒体のいずれにも格納され、そこからアクセスされてもよい。例えば、このようなモジュールの一部と関連プログラム・データの一部は、システム・メモリ４２２内のストレージのために、オペレーティング・システム４３５、アプリケーション・プログラム４３６、プログラム・モジュール４３７、および／またはプログラム・データ４３８内に含めることができる。

例えば、磁気ハードディスク４３９などの大容量ストレージ・デバイスがコンピュータ・システム４２０に結合した場合、このようなモジュールおよび関連プログラム・データを大容量ストレージ・デバイスに格納してもよい。ネットワーク環境において、コンピュータ・システム４２０に関して図示されたプログラム・モジュールあるいはこのプログラム・モジュールの一部を、リモート・コンピュータ・システム４８３および／またはリモート・コンピュータ・システム４９３に関連付けられたシステム・メモリおよび／または大容量ストレージ・デバイスなどのリモート・メモリ・ストレージ・デバイスに格納することができる。前述した分散環境で、このようなモジュールの実行を行ってもよい。

本発明の精神または本質的な特徴から逸脱せずに、他の特定の形で本発明を具体化してもよい。説明した実施形態は、どの観点においても、制限ではなく例示に過ぎないものとみなされたい。従って、本発明の範囲は、前述の説明よりむしろ請求の範囲によって示される。請求の範囲の意味の範囲内にあり、請求の範囲と同等の範囲内にある変更は、請求項の範囲内に包含される。

抽象的な記述を利用して、サービスおよびクライアント・ランタイムを生成、交換、構成することを容易にするコンピュータ・アーキテクチャの一例を示す図である。 抽象的なサービスの記述の例を示す図である。 抽象的なチャネルの記述の例を示す図である。 本発明の原理に適合する動作環境を示す図である。 ネットワーク・ベースのサービスを記述する抽象的なサービスの記述を生成するためのメソッドの例を示すフローチャートである。 ネットワーク・ベースのサービスを記述する抽象的なサービスの記述を、そのネットワーク・ベースのサービスを表現するコードに変換するメソッドの例を示すフローチャートである。 ネットワーク・ベースのサービスを記述する抽象的なサービスの記述からサービス・ランタイムを初期化するメソッドの例を示すフローチャートである。 チャネル用のソース・コードを生成するメソッドの例を示すフローチャートである。

符号の説明

１０１ コンピュータ・システム
１０２ サービス型
１０３ 構成
１０４ サービス・ローダ
１０６ サービス記述
１０７ メタデータ・エクスポータ
１０８ メタデータ・インポータ
１０９ メタデータ
１１１ サービス・イニシャライザ
１１２ サービス・ランタイム
１１３ コントラクト・ジェネレータ
１１４ コード文書オブジェクト・モデル
１１６ 構成
１２１ コンピュータ・システム
１２４ チャネル・ローダ
１２６ チャネル記述
１２８ メタデータ・インポータ
１３１ チャネル・イニシャライザ
１３２ チャネル
１３３ コントラクト・ジェネレータ
１３４ コード文書オブジェクト・モデル
１３６ 構成
１３８ コード・コンバータ
１３９ ソース・コード
１４３ コンパイラ
２０１ サービス記述
２０２ サービス型
２０３Ａ、Ｂ ＩＳｅｒｖｉｃｅＢｅｈａｖｉｏｒ
２０４Ａ、Ｂ サービス・エンド・ポイント
２１４ エンド・ポイント・アドレス
２１６ バインディング
２１７Ａ、Ｂ コントラクト記述
２１８ 操作
２２８ メッセージ
２１９ 操作
２２９ メッセージ
２３９ メッセージ
３０１ チャネル記述
３０２ チャネル型
３０３Ａ、Ｂ ＩＣｈａｎｎｅｌＢｅｈａvｉｏｒ
３０４ サービス・エンド・ポイント
３１４ エンド・ポイント・アドレス
３１６ バインディング
３１７ コントラクト記述
３１８ 操作
３２８ メッセージ
３１９ 操作
３２９ メッセージ
３３９ メッセージ
４２２ システム・メモリ
４３５ オペレーティング・システム
４３６ アプリケーション・プログラム
４３７ 他のプログラム・モジュール
４３８ プログラム・データ
４２１ 処理ユニット
４２３ システム・バス
４３２ ハードディスク・ドライブ・インターフェース
４３３ 磁気ディスク・ドライブ・インターフェース
４３４ 光ドライブ・インターフェース
４４０ キーボード
４４６ シリアル・ポート・インターフェース
４５３ ネットワーク・インターフェース
４５４ モデム
４３５ オペレーティング・システム
４３６ アプリケーション・プログラム
４３７ 他のプログラム・モジュール
４３８ プログラム・データ
４４７ モニタ
４８３ リモート・コンピュータ
４９３ リモート・コンピュータ

Claims (20)

1. コンピュータ・システムによって実行される、ネットワーク・ベースのサービスを記述する抽象的なサービスの記述を生成する方法であって、前記コンピュータ・システムは少なくとも１つのプロセッサおよびシステムメモリを含み、前記方法は、
   前記プロセッサが、第１のプログラミング言語に従ってネットワーク・ベースのサービスを実装するための、前記第１のプログラミング言語によって記述されたソース・コードから実行形式にコンパイルされた実行コードを含むサービス型および対応するサービス構成にアクセスする動作であって、前記コンパイルされた実行コードは、前記コンパイルされた実行コードによって実装される少なくとも１つのインターフェースの処理方法および公開方法と前記少なくとも１つのインターフェースを用いてランタイム処理を行う方法とを記述する少なくとも１つの注釈を含む、アクセスする動作、
   前記プロセッサが、前記サービス型および前記対応するサービス構成を構文解析して、前記第１のプログラミング言語に基づくネットワーク・ベースのサービスを使用するための情報を記述する記述情報を識別する動作であって、前記識別する動作は前記少なくとも１つの注釈を含む前記サービス型の前記コンパイルされた実行コードを構文解析して前記記述情報を識別することを含む、識別する動作、および
   前記プロセッサが、前記サービス型の前記コンパイルされた実行コードを構文解析することによって識別された記述情報に基づく前記ネットワーク・ベースのサービスについてのサービス記述ツリーを作成する動作であって、
   前記サービス記述ツリーの形式は、ネットワーク・ベースのサービスについてのいずれのプログラミング言語からも独立しており、
   １つまたは複数のほかの変換モジュールが前記サービス記述ツリーを消費して、前記ネットワーク・ベースのサービスの追加的な表現を他形式で作成することができるように、前記サービス記述ツリーは消費可能であり、
   前記１つまたは複数のほかの変換モジュールは、前記サービス記述ツリーを消費して、第２のプログラミング言語に従って前記ネットワーク・ベースのサービスを実装するために前記第２のプログラミング言語によって記述されたソース・コードと、前記第２のプログラミング言語に従って実装される前記ネットワーク・ベースのサービスを記述するＷＳＤＬ文書とを作成し、前記ソース・コードは実行形式にコンパイルされるよう構成された前記第２のプログラミング言語によって記述される、サービス記述ツリーを作成する動作
   を備えることを特徴とする方法。
2. サービスを実装するために、サービス型および対応するサービス構成にアクセスする前記動作は、共通言語ランタイム型にアクセスする動作を備えることを特徴とする請求項１に記載の方法。
3. サービスを実装するために、サービス型および対応するサービス構成にアクセスする前記動作は、ランタイムでの前記サービス型に含まれるインターフェースおよびメソッドの実装方法を示す属性で注釈付けされたサービス型にアクセスする動作を備えることを特徴とする請求項１に記載の方法。
4. サービス型を実装するために、サービス型および対応するサービス構成にアクセスする前記動作は、セキュリティ・オプション、高信頼性のメッセージング・オプション、メッセージ・ロギング・オプション、および接続制限オプションのうちから選択されるサービス構成情報にアクセスする動作を備えることを特徴とする請求項１に記載の方法。
5. 前記サービス型および対応するサービス構成を構文解析して、記述情報を識別する前記動作は、前記サービス型を構文解析して、エンド・ポイント・アドレス、バインディング、およびコントラクト記述のうちから選択される記述情報を識別する動作を備えることを特徴とする請求項１に記載の方法。
6. 前記サービス型および対応するサービス構成情報を構文解析して、記述情報を識別する前記動作は、前記サービス構成を構文解析して、セキュリティ・オプション、高信頼性のメッセージング・オプション、メッセージ・ロギング・オプション、および接続制限オプションのうちから選択される記述情報を識別することを備えることを特徴とする請求項１に記載の方法。
7. 前記識別した記述情報に基づいて前記サービス用のサービス記述ツリーを作成する前記動作は、対応する操作および対応するメッセージを含むコントラクト記述の表現を作成する動作を備えることを特徴とする請求項１に記載の方法。
8. 前記識別した記述情報に基づいて前記サービス用のサービス記述ツリーを作成する前記動作は、サービスの挙動の表現を作成する動作を備えることを特徴とする請求項１に記載の方法。
9. コンピュータ・システムによって実行される、ネットワーク・ベースのサービスを記述する抽象的なサービスの記述を、前記ネットワーク・ベースのサービスを表現するソース・コードに変換する方法であって、前記コンピュータ・システムは少なくとも１つのプロセッサおよびシステムメモリを含み、前記方法は、
   前記プロセッサが、ネットワーク・ベースのサービス用のサービス記述ツリーにアクセスする動作であって、前記サービス記述ツリーの形式は、ネットワーク・ベースのサービスについてのいずれのプログラミング言語からも独立しており、前記サービス記述ツリーは、前記ネットワーク・ベースのサービスを実装するための対応するサービス型およびサービス構成から構文解析した前記ネットワーク・ベースのサービスを使用するための情報を記述する記述情報から生成され、前記記述情報の少なくとも一部は、前記サービス型の前記コンパイルされた実行コードから構文解析され、前記コンパイルされた実行コードは、第１のプログラミング言語によって記述されたソース・コードから実行形式にコンパイルされ、前記コンパイルされた実行コードは、前記コンパイルされた実行コードによって実装される少なくとも１つのインターフェースの処理方法および公開方法と前記少なくとも１つのインターフェースを用いてランタイム処理を行う方法とを記述する少なくとも１つの注釈を含む、アクセスする動作、
   前記プロセッサが、前記サービス記述ツリーを異なる表現形式にコンバートする動作であって、前記記述情報は、前記異なる表現形式に従って定義されるサービス記述情報を処理するモジュールに対し、互換性を保って転送され、前記コンバートする動作は前記サービス記述ツリーをＷＳＤＬ以外の形式からＷＳＤＬの形式へエキスポートすることを含む、コンバートする動作、および
   前記プロセッサが、前記異なる表現形式で前記記述情報を出力する動作
   を備えることを特徴とする方法。
10. サービス用のサービス記述ツリーにアクセスする前記動作は、前記サービス用の挙動にアクセスする動作を備えることを特徴とする請求項９に記載の方法。
11. サービス用のサービス記述ツリーにアクセスする前記動作は、対応する操作および対応するメッセージを含む前記サービス用のコントラクト記述にアクセスする動作を備えることを特徴とする請求項９に記載の方法。
12. 前記サービス記述ツリーを異なる表現形式にコンバートする前記動作は、前記サービス記述ツリーをメタデータにエクスポートする動作を備えることを特徴とする請求項９に記載の方法。
13. 前記サービス記述ツリーをメタデータにエクスポートする前記動作は、前記サービスツリーをＷＳＤＬ文書にエクスポートする動作を備えることを特徴とする請求項１２に記載の方法。
14. 前記サービス記述ツリーをメタデータにエクスポートする前記動作は、サード・パーティのプラグインが、ポリシー・アサーションを前記メタデータに挿入する動作を備えることを特徴とする請求項１２に記載の方法。
15. 前記サービス記述ツリーをメタデータにエクスポートする前記動作は、サード・パーティのプラグインが、任意のＸＭＬを前記メタデータに挿入する動作を備えることを特徴とする請求項１２に記載の方法。
16. 前記サービス記述ツリーを異なる表現形式にコンバートする前記動作は、前記サービス記述ツリーをコード文書オブジェクト・モデルおよび対応するサービス構成にコンバートする動作を備えることを特徴とする請求項９に記載の方法。
17. 前記サービス記述ツリーをコード文書オブジェクト・モデルおよび対応するサービス構成にコンバートする前記動作は、前記サービス記述ツリーをソース・コードにコンバートする動作を備えることを特徴とする請求項１６に記載の方法。
18. 前記サービス記述ツリーをコード文書オブジェクト・モデルおよび対応するサービス構成にコンバートする前記動作は、サービス・エンド・ポイントを表現する言語に中立なソースに前記サービス記述ツリーをコンバートする動作を備えることを特徴とする請求項１６に記載の方法。
19. 前記サービス記述ツリーをコード文書オブジェクト・モデルおよび対応するサービス構成にコンバートする前記動作は、セキュリティ・オプション、信頼性の高いメッセージング・オプション、メッセージ・ロギング・オプション、および接続制限オプションの中から選択されるサービスの挙動を表現するサービス構成に、前記サービス記述ツリーをコンバートする動作を備えることを特徴とする請求項１６に記載の方法。
20. コンピュータ・システムに、ネットワーク・ベースのサービスを記述する抽象的なサービスの記述を生成する方法を実行させるためのコンピュータ・プログラムであって、前記方法は、
    第１のプログラミング言語に従ってネットワーク・ベースのサービスを実装するための、前記第１のプログラミング言語によって記述されたソース・コードから実行形式にコンパイルされた実行コードを含むサービス型および対応するサービス構成にアクセスすることであって、前記コンパイルされた実行コードは、前記コンパイルされた実行コードによって実装される少なくとも１つのインターフェースの処理方法および公開方法と前記少なくとも１つのインターフェースを用いてランタイム処理を行う方法とを記述する少なくとも１つの注釈を含む、アクセスすること、
    前記サービス型および前記対応するサービス構成を構文解析して、前記第１のプログラミング言語に基づくネットワーク・ベースのサービスを使用するための情報を記述する記述情報を識別することであって、前記記述情報の少なくとも一部は、少なくとも１つの注釈を含む前記サービス型の前記コンパイルされた実行コードから構文解析される、識別すること、および
    前記サービス型の前記コンパイルされた実行コードを構文解析することによって識別された記述情報に基づく前記ネットワーク・ベースのサービスについてのサービス記述ツリーを作成することであって、
    前記サービス記述ツリーの形式は、ネットワーク・ベースのサービスについてのいずれのプログラミング言語からも独立しており、
    １つまたは複数のほかの変換モジュールが前記サービス記述ツリーを消費して、前記ネットワーク・ベースのサービスの追加的な表現を他形式で、作成させることができるように前記サービス記述ツリーは消費可能であり、
    前記１つまたは複数のほかの変換モジュールは前記サービス記述ツリーを消費して、第２のプログラミング言語に従って前記ネットワーク・ベースのサービスを実装するために前記第２のプログラミング言語によって記述されたソース・コード、および前記第２のプログラミング言語に従って実装される前記ネットワーク・ベースのサービスを記述するＷＳＤＬ文書を作成し、前記ソース・コードは実行形式にコンパイルされるよう構成された前記第２のプログラミング言語によって記述される、サービス記述ツリーを作成すること
    を含むコンピュータ・プログラム。

Images