このセクションでは、WCF コントラクトを定義して実装する方法について説明します。 サービス コントラクトは、エンドポイントが外部と通信する内容を指定します。 より具体的なレベルでは、要求/応答、一方向、双方向などの基本的なメッセージ交換パターン (MEP) に編成された特定のメッセージのセットに関するステートメントです。 サービス コントラクトが論理的に関連するメッセージ交換のセットである場合、サービス操作は単一のメッセージ交換です。 たとえば、 Hello 操作では、明らかに 1 つのメッセージを受け入れる必要があります (呼び出し元があいさつを読み上げることができるようにします)。また、(操作の提供に応じて) メッセージを返す場合と返さない場合があります。
コントラクトとその他の主要な Windows Communication Foundation (WCF) の概念の詳細については、「 基本的な Windows Communication Foundation の概念」を参照してください。 このトピックでは、サービス コントラクトについて説明します。 サービス コントラクトを使用してサービスに接続するクライアントを構築する方法の詳細については、「 WCF クライアントの概要」を参照してください。
概要
このトピックでは、WCF サービスの設計と実装に関する概念的な概要について説明します。 サブトピックでは、設計と実装の詳細に関する詳細情報が提供されます。 WCF アプリケーションを設計して実装する前に、次の作業を行うことをお勧めします。
サービス コントラクトとは何か、そのしくみ、作成方法を理解します。
コントラクトには、ランタイム構成またはホスティング環境でサポートされない可能性がある最小要件が記載されていることを理解します。
サービス コントラクト
サービス コントラクトでは、次を指定します。
コントラクトが公開する操作
交換されるメッセージに関する操作の署名。
これらのメッセージのデータ型。
操作の場所。
サービスとの正常な通信をサポートするために使用される特定のプロトコルとシリアル化形式。
たとえば、発注書コントラクトには、注文情報の種類の入力を受け入れ、注文識別子を含む成功または失敗の情報を返す CreateOrder 操作がある場合があります。 また、注文 ID を受け取り、注文の状態情報を返す GetOrderStatus 操作が含まれる場合もあります。 この種類のサービス コントラクトでは、次の指定が行われます。
発注書契約が
CreateOrder操作とGetOrderStatus操作で構成されていること。操作で入力メッセージと出力メッセージが指定されていること。
これらのメッセージが伝達できるデータ。
メッセージを正常に処理するために必要な通信インフラストラクチャに関するカテゴリ ステートメント。 たとえば、これらの詳細には、通信を成功させるために必要かどうか、そしてどのようなセキュリティ対策が求められるかが含まれます。
このような情報を多くのプラットフォーム (Microsoft 以外のプラットフォームを含む) 上の他のアプリケーションに伝えるために、XML サービス コントラクトは、 Web サービス記述言語 (WSDL) や XML スキーマ (XSD) などの標準 XML 形式でパブリックに表現されます。 多くのプラットフォームの開発者は、このパブリック コントラクト情報を使用してサービスと通信できるアプリケーションを作成できます。これは、仕様の言語を理解していることと、それらの言語が、サービスがサポートするパブリック フォーム、形式、プロトコルを記述することによって相互運用を可能にするように設計されているためです。 WCF でこの種の情報を処理する方法の詳細については、「 メタデータ」を参照してください。
コントラクトは多くの方法で表現できます。WSDL と XSD は、アクセス可能な方法でサービスを記述するのに優れた言語ですが、直接使用するのは困難な言語であり、サービス コントラクトの実装ではなく、サービスの説明にすぎません。 そのため、WCF アプリケーションでは、マネージド属性、インターフェイス、およびクラスの両方を使用して、サービスの構造を定義し、それを実装します。
マネージド型で定義された結果のコントラクトは、クライアントまたは他のサービス実装者が必要に応じてメタデータ (WSDL および XSD) として エクスポート できます。 その結果、任意のクライアント アプリケーションに対して (パブリック メタデータを使用して) 記述できる簡単なプログラミング モデルが得られます。 基になる SOAP メッセージの詳細、トランスポートおよびセキュリティ関連の情報など、WCF に任せることができます。WCF は、サービス コントラクト型システムから XML 型システムへの必要な変換を自動的に実行します。
コントラクトの設計の詳細については、「 サービス コントラクトの設計」を参照してください。 コントラクトの実装の詳細については、「 サービス コントラクトの実装」を参照してください。
メッセージを前面と中央に配置する
リモート プロシージャ コール (RPC) スタイルのメソッド シグネチャを使用する場合、マネージド インターフェイス、クラス、メソッドを使用してサービス操作をモデル化するのは簡単です。このシグネチャでは、パラメーターをメソッドに渡し、戻り値を受け取るのが、オブジェクトまたはその他の種類のコードから機能を要求する通常の形式です。 たとえば、Visual Basic や C++ COM などのマネージド言語を使用するプログラマは、RPC スタイルの分散オブジェクト システムに固有の問題を経験することなく、(オブジェクトまたはインターフェイスを使用するかどうかに関係なく) RPC スタイルのアプローチに関する知識を WCF サービス コントラクトの作成に適用できます。 サービス指向では、RPC プログラミングの容易さと知識を保持しながら、疎結合のメッセージ指向プログラミングの利点を得ることができます。
多くのプログラマは、Microsoft MSMQ などのメッセージ キュー、.NET Framework の System.Messaging 名前空間、HTTP 要求での非構造化 XML の送信など、メッセージ指向のアプリケーション プログラミング インターフェイスに慣れている人が多くいます。 メッセージ レベルでのプログラミングの詳細については、「 メッセージ コントラクトの使用、 サービス Channel-Level プログラミング、 および POX アプリケーションとの相互運用性」を参照してください。
要件の階層について
サービス コントラクトは、操作をグループ化します。は、メッセージ交換パターン、メッセージ型、およびそれらのメッセージが伝達するデータ型を指定します。は、実装がコントラクトをサポートするために必要な実行時動作のカテゴリを示します (たとえば、メッセージの暗号化と署名が必要な場合があります)。 サービス コントラクト自体は、これらの要件が満たされる方法を正確に指定せず、必要な要件のみを指定します。 暗号化の種類またはメッセージの署名方法は、準拠しているサービスの実装と構成に応じられます。
コントラクトで動作を追加するために、サービス コントラクトの実装と実行時の構成の特定のものが必要な方法に注意してください。 使用するサービスを公開するために満たす必要がある要件のセットは、上記の一連の要件に基づいています。 コントラクトが実装の要件を満たす場合、実装では、サービスの実行を可能にする構成とバインディングをさらに多く必要とする可能性があります。 最後に、ホスト アプリケーションは、サービスの構成とバインドによって追加されるすべての要件もサポートする必要があります。
この追加要件プロセスは、Windows Communication Foundation (WCF) サービス アプリケーションの設計、実装、構成、ホストを行う際に留意することが重要です。 たとえば、コントラクトはセッションをサポートする必要があることを指定できます。 その場合は、その契約要件をサポートするようにバインディングを構成する必要があります。そうしないと、サービスの実装は機能しません。 または、サービスに Windows 統合認証が必要で、インターネット インフォメーション サービス (IIS) でホストされている場合は、サービスが存在する Web アプリケーションで Windows 統合認証を有効にし、匿名サポートを無効にする必要があります。 さまざまなサービス ホスト アプリケーションの種類の機能と影響の詳細については、「 ホスティング サービス」を参照してください。