このセクションでは、Windows Communication Foundation (WCF) コントラクトを定義して実装する方法について説明します。 サービス コントラクトは、エンドポイントが外部と通信する内容を指定します。 より具体的なレベルでは、要求/応答、一方向、双方向などの基本的なメッセージ交換パターン (MEP) に編成された特定のメッセージのセットに関するステートメントです。 サービス コントラクトが論理的に関連するメッセージ交換のセットである場合、サービス操作は単一のメッセージ交換です。 たとえば、 Hello 操作では、明らかに 1 つのメッセージを受け入れる必要があります (呼び出し元があいさつを読み上げることができるようにします)。また、(操作の提供に応じて) メッセージを返す場合と返さない場合があります。
コントラクトとその他の主要な 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 型システムへの必要な変換を自動的に実行します。
コントラクトの設計の詳細については、「 サービス コントラクトの設計」を参照してください。 コントラクトの実装の詳細については、「 サービス コントラクトの実装」を参照してください。
さらに、WCF には、メッセージ レベルでサービス コントラクトを完全に開発する機能も用意されています。 メッセージ レベルでのサービス コントラクトの開発の詳細については、「 メッセージ コントラクトの使用」を参照してください。 SOAP XML 以外のサービスの開発の詳細については、「 POX アプリケーションとの相互運用性」を参照してください。
要件の階層について
サービス コントラクトは、操作をグループ化します。は、メッセージが伝達する MEP、メッセージ型、およびデータ型を指定します。は、実装がコントラクトをサポートするために必要な実行時動作のカテゴリを示します (たとえば、メッセージの暗号化と署名が必要な場合があります)。 ただし、サービス コントラクト自体では、これらの要件が満たされる方法を正確に指定するわけではありません。指定する必要があるのはその要件だけです。 暗号化の種類、またはメッセージの署名方法は、準拠しているサービスの実装と構成に対応しています。
コントラクトで動作を追加するために、サービス コントラクトの実装と実行時の構成の特定のものが必要な方法に注意してください。 使用するサービスを公開するために満たす必要がある要件のセットは、上記の一連の要件に基づいています。 コントラクトが実装の要件を満たす場合、実装では、サービスの実行を可能にする構成とバインディングをさらに多く必要とする可能性があります。 最後に、ホスト アプリケーションは、サービスの構成とバインドによって追加されるすべての要件もサポートする必要があります。
この追加要件プロセスは、Windows Communication Foundation (WCF) サービス アプリケーションの設計、実装、構成、ホストを行う際に留意することが重要です。 たとえば、コントラクトはセッションをサポートする必要があることを指定できます。 その場合は、その契約要件をサポートするようにバインディングを構成する必要があります。そうしないと、サービスの実装は機能しません。 または、サービスに統合 Windows 認証が必要で、インターネット インフォメーション サービス (IIS) でホストされている場合は、サービスが存在する Web アプリケーションで統合 Windows 認証を有効にし、匿名サポートを無効にする必要があります。 さまざまなサービス ホスト アプリケーションの種類の機能と影響の詳細については、「 ホスティング」を参照してください。