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