次の方法で共有

Windows Communication Foundation の新機能

  • [アーティクル]

このトピックでは、Windows Communication Foundation (WCF) の新しい機能について説明します。

構成ベースのアクティブ化

インターネット インフォメーション サービス (IIS: Internet Information Services) または Windows プロセス アクティブ化サービス (WAS) で Windows Communication Foundation (WCF) サービスをホストする場合は、.svc ファイルを用意する必要があります。.svc ファイルには、サービスの名前と、オプションのカスタム サービス ホスト ファクトリが含まれています。この追加ファイルによって、管理のオーバーヘッドが増加します。構成ベースのアクティブ化機能により、.svc ファイルを用意する必要がなくなり、関連するオーバーヘッドも発生しません。詳細については、次のトピックを参照してください。 IIS と WAS における構成ベースのアクティブ化, 構成ベースのアクティブ化.

System.Web.Routing 統合

Windows Communication Foundation (WCF) サービスを IIS でホストするときには、.svc ファイルを仮想ディレクトリに配置します。この .svc ファイルは、使用するサービス ホスト ファクトリと、サービスを実装するクラスを指定します。サービスを要求するときには、URI で .svc ファイルを指定します。たとえば、https://contoso.com/EmployeeServce.svc と指定します。REST サービスを記述するプログラマにとっては、この種類の URI は最適とは言えません。REST サービス用の URI は、特定のリソースを指定しており、拡張子がないのが普通です。System.Web.Routing 統合機能では、拡張子のない URI に応答する WCF サービスをホストできます。詳細については、次のトピックを参照してください。 System.Web.Routing 統合, SystemWebRouting 統合サンプル.

複数の IIS サイト バインディングのサポート

インターネット インフォメーション サービス (IIS: Internet Information Services) 7.0 で Windows Communication Foundation (WCF) サービスをホストする場合は、同じサイトで同じプロトコルを使用する、複数のベース アドレスを提供できます。これにより、同じサービスで多数の異なる URI に応答できます。https://www.contoso.com および https://contoso.com でリッスンするサービスをホストするときには、これが役立ちます。また、内部ユーザー用に 1 つのベース アドレスを持ち、外部ユーザー用に別のベース アドレスを持つサービスを作成するのにも役立ちます。詳細については、次のトピックを参照してください。 複数の IIS サイト バインディングのサポート,

ルーティング サービス

ルーティング サービスは、メッセージ ルーターとして機能する、汎用の SOAP 中継局です。ルーティング サービスの主要な機能は、メッセージのコンテンツに基づいてメッセージをルーティングする機能です。これにより、メッセージのヘッダーまたはメッセージ本文内に含まれる値に基づいて、メッセージをクライアント エンドポイントに転送できます。詳細については、次のトピックを参照してください。 ルーティング, ルーティング サービス .

WS-Discovery のサポート

サービス探索機能では、クライアント アプリケーションが WS-Discovery を使用して、相互運用可能な方法で実行時にサービス アドレスを動的に探索できます。WS-Discovery 仕様は、マルチキャスト (アドホック) およびユニキャスト (ネットワーク リソースを利用) の両方による、サービスの軽量探索の実行に必要なメッセージ交換パターン (MEP) の概要を示しています。詳細については、次のトピックを参照してください。 WCF Discovery, 探索 (サンプル).

標準エンドポイント

標準エンドポイントは、1 つ以上のプロパティ (アドレス、バインディング、コントラクト) が固定されている、あらかじめ定義されたエンドポイントです。たとえば、すべてのメタデータ交換エンドポイントは IMetadataExchange をコントラクトとして指定するため、開発者がコントラクトを指定する必要はありません。このため、標準の MEX エンドポイントには、固定の IMetadataExchange コントラクトがあります。詳細については、次のトピックを参照してください。 標準エンドポイント, .

ワークフロー サービス

メッセージング アクティビティのセットが導入されたため、データを送受信するワークフローの実装が以前よりも容易になりました。これらのメッセージング アクティビティを使用すると、従来の送信/受信または RPC スタイルのメソッド呼び出しの枠を超える、複雑なメッセージ交換パターンをモデル化できます。詳細については、次のトピックを参照してください。 ワークフロー サービス, Services, Services.

ターゲット フレームワーク属性

ターゲット フレームワーク属性は、IIS または WAS でホストされるアプリケーションが対象とする .NET Framework のバージョンを指定するのに使用されます。この属性を使用すると、.NET Framework のバージョン 2.0、3.5、または 4 を対象とするアプリケーションを Visual Studio で構築できます。これは、次の例で示すように、アプリケーションの Web.config ファイルで <compilation> タグ内に設定される属性です。

<compilation debug="false"
        targetFramework="4.0">

        <assemblies>
          <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
          <add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
          <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
          <add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
        </assemblies>

      </compilation>

IIS または WAS でホストされているアプリケーションが、インストールされていないバージョンの .NET Framework を対象としている場合は、この問題を示す例外がスローされます。対象となるフレームワーク モニカーがアプリケーションの Web.config ファイルで指定されていない場合は、IIS で構成されているアプリケーション プール バージョンから値が推論されます。

この新しい機能が導入されたため、.NET Framework 3.5 で作成された WCF サービスを .NET Framework 4 を実行しているコンピューター上でホストしようとすると、次のテキストが指定された ProtocolException を受け取ることがあります。

ハンドルされていない例外: System.ServiceModel.ProtocolException: 応答メッセージのコンテンツの種類 text/html; charset=utf-8 が、バインド (application/soap+xml; charset=utf-8) のコンテンツの種類と一致しません。カスタム エンコーダーを使用している場合は、IsContentTypeSupported メソッドが正しく実装されていることを確認してください。応答の先頭の 1024 バイトは '<html>    <head>        <title>' でした。アプリケーション ドメインまたはアプリケーション プールは、現在、バージョン 4 以降の .NET Framework を実行しています。この Web アプリケーションの IIS 設定が 4.0 以降に設定されている場合、または ASP.NET Web 開発サーバーのバージョン 4.0 以降を使用している場合に、この状況が発生することがあります。この Web アプリケーションの Web.config ファイル内の &lt;compilation&gt; 要素に、このバージョンの .NET Framework に必要な targetFrameworkMoniker 属性が含まれていません (&lt;compilation targetFrameworkMoniker=&quot;.NETFramework,Version=v4.0&quot;&gt, など)。この属性を使用して Web.config ファイルを更新するか、別のバージョンの .NET Framework を使用するように Web アプリケーションを構成します。</title>...

このエラーは、IIS 内で実行されているアプリケーション ドメインが .NET Framework 4 を実行しており、WCF サービスが .NET Framework 3.5 で実行されるように構成されている場合に発生します。この問題の解決方法詳細情報、「.NET Framework 4 で実行されている IIS 内の .NET Framework 3.5 で作成された WCF サービスをホストする方法」を参照してください。

WCF REST

キャッシュ

.NET Framework 4 では、ASP.NET で既に導入されている宣言によるキャッシュ機構を、WCF REST サービスで活用できます。このため、WCF REST サービス操作からの応答をキャッシュできます。キャッシュ用に構成されているサービスに対してユーザーが HTTP GET を送信すると、ASP.NET はキャッシュされた応答を送り返し、サービス メソッドは呼び出されません。キャッシュの有効期限が切れると、次にユーザーが HTTP GET を送信したときに、サービス メソッドが呼び出され、応答が再度キャッシュされます。

.NET Framework 4 では、条件付き HTTP GET キャッシュを実装することもできます。REST シナリオでは、条件付き HTTP GET がサービスで使用されて、HTTP の仕様で説明されているように、インテリジェントな HTTP キャッシュが実装されることがよくあります。詳細については、次のトピックを参照してください。 WCF WEB HTTP サービスのキャッシュ サポート, Caching and Automatic Help Page.

形式のサポート

WCF Web HTTP プログラミング モデルでは、サービス操作で返す応答の最適な形式を動的に決定できます。応答は、Accept ヘッダーに基づいて、自動的に XML および JSON に設定できます。操作の形式をプログラムで設定するために、ヘルパー API が追加されています。詳細については、次のトピックを参照してください。 WCF Web HTTP 形式, 形式の自動選択, 高度な形式選択.

HTTP REST エラー処理

WCF Web HTTP エラー処理では、WCF REST サービスからエラーを返すことができます。このサービスは、HTTP 状態コードを指定し、操作と同じ形式 (XML、JSON など) を使用してエラーの詳細を返します。詳細については、次のトピックを参照してください。 WCF Web HTTP エラー処理, .

配置機能

サービスの実行に必要な構成が簡略化され、新しい標準エンドポイントが導入されて、サービス構成がさらに容易になりました。簡略化された新しい構成詳細情報、「簡略化された構成」を参照してください。標準エンドポイント詳細情報、「標準エンドポイント」を参照してください。

Windows Communication Foundation (WCF) サービスを IIS でホストするときには、.svc ファイルを仮想ディレクトリに配置します。この .svc ファイルは、使用するサービス ホスト ファクトリと、サービスを実装するクラスを指定します。サービスを要求するときは、https://contoso.com/EmployeeServce.svc などの URI で .svc ファイルを指定します。REST サービスを記述するプログラマにとっては、この種類の URI は最適とは言えません。REST サービス用の URI は、特定のリソースを指定しており、拡張子がないのが普通です。System.Web.Routing 統合機能では、拡張子のない URI に応答する WCF REST サービスをホストできます。詳細については、次のトピックを参照してください。 System.Web.Routing 統合.

ドメイン間 JavaScript

JSONP (JSON with Padding) は、Web ブラウザーでクロスサイト スクリプティングのサポートを有効にする機構です。JSONP は、現在読み込まれているドキュメントの取得元サイトとは異なるサイトからスクリプトを読み込むための、Web ブラウザーの機能を軸に設計されています。この機構は、JSON ペイロードにユーザー定義のコールバック関数の名前を埋め込むことで機能します。たとえば、次のように指定します。

callback({ “a” = \“b\” });

上の例では、JSON ペイロード {“a” = \”b\”} が、関数呼び出し callback にラップされています。コールバック関数は、現在の Web ページで既に定義されている必要があります。JSONP 応答のコンテンツの種類は application/javascript です。詳細については、次のトピックを参照してください。 JSONP.

WCF REST サービス ヘルプ ページ

.NET Framework Version 4 には、WCF REST サービスの自動的なヘルプ ページが用意されています。このヘルプ ページには、各操作の説明、要求と応答の形式、およびスキーマが一覧表示されます。詳細については、次のトピックを参照してください。 WCF Web HTTP サービスのヘルプ ページ, Caching and Automatic Help Page.