Windows Communication Foundation とは

  • [アーティクル]

アプリケーション間通信の標準プロトコルを含め、Web サービスがグローバルに受け入れられるようになったことで、ソフトウェア開発に変化がもたらされました。たとえば、Web サービスで、セキュリティ、分散トランザクションの調整、信頼性の高い通信などの機能が提供されるようになりました。Web サービスの変化によるメリットを、開発者が使用するツールやテクノロジに反映する必要があります。Windows Communication Foundation (WCF) は、分散コンピューティング、広範な相互運用性、およびサービス指向の直接サポートを実現する管理しやすい方法を提供することを目的としています。

WCF では、新しいサービス指向のプログラミング モデルによって、オンライン アプリケーションの開発が簡略化されます。WCF は、複数層アーキテクチャを提供することにより、分散アプリケーション開発のさまざまなスタイルをサポートしています。WCF チャネル アーキテクチャは、その基礎において、型指定のないメッセージ非同期受け渡しの基本機能を提供しています。セキュリティで保護された信頼性の高いトランザクション データ交換のためのプロトコル機能と、トランスポートおよびエンコード オプションの幅広い選択肢は、この基礎の上に構築されています。

"サービス モデル" と呼ばれる型指定のプログラミング モデルは、分散アプリケーションの開発を容易にすると共に、ASP.NET Web サービス、.NET Framework リモート処理、およびエンタープライズ サービスの専門知識があり、WCF をこれから使用する開発者が、これまでと同様に開発作業を行うことができるように設計されています**。サービス モデルの特徴は、Visual C# や Visual Basic などの言語でのサービス実装へのメッセージの柔軟性と拡張性のあるマッピングなど、Web サービスの概念を .NET Framework 共通言語ランタイム (CLR: Common Language Runtime) の概念に簡単にマップできることです。サービス モデルは、疎結合とバージョン管理を可能にするシリアル化機能を備えています。また、このモデルにより、既存の .NET Framework 分散システム テクノロジ (メッセージ キュー (MSMQ)、COM+、ASP.NET Web サービス、Web サービス拡張 (WSE: Web Services Enhancements)、および他の多数の機能) との統合および相互運用が実現します。

問題の例

WCF が対処する問題の一部を次の例に示します。あるレンタカー会社が車両予約用の新しいアプリケーションを作成することにしました。このレンタカー予約アプリケーションの作成者は、アプリケーションが実装するビジネス ロジックに、社内と社外の両方で実行されている他のソフトウェアがアクセスできる必要があることを認識しています。したがって、定義済みの一連のサービスを介して他のソフトウェアにアプリケーションのロジックを公開するサービス指向のスタイルで、アプリケーションを構築することにしました。これらのサービスを実装し、他のソフトウェアと通信するために、新しいアプリケーションでは WCF を使用します。

レンタカー シナリオ

レンタカー予約アプリケーションには、その有効期間を通じて、他のさまざまなアプリケーションがアクセスすると考えられます。ただし、上記の図に示すように、レンタカー予約アプリケーションの設計時点で、このアプリケーションのビジネス ロジックには、次の 3 種類のアプリケーションがアクセスすることになるということを設計者は把握しています。

  • 組織のコール センターの従業員が使用する Windows デスクトップ上で実行されるコール センター クライアント アプリケーション。新しい予約システム用に特別に作成されるこのアプリケーションも、Microsoft .NET Framework と WCF を使用して構築される予定です。このアプリケーションは、新しいシステムのクライアントとして機能することだけを目的としているため、新しいレンタカー予約アプリケーションとまったく異なるわけではありません。サービス指向の観点から見ると、このアプリケーションは、予約システムのビジネス ロジックを要求する 1 つのクライアントにすぎません。
  • Windows 以外のシステム上で実行される J2EE サーバーを基盤に構築された既存の予約アプリケーション。最近、別のレンタカー会社と合併したため、合併先の顧客に統一感のある操作性を提供するために、この既存のシステムは新しいアプリケーションのロジックにアクセスできる必要があります。
  • さまざまなプラットフォーム上で実行されるパートナー アプリケーション。各アプリケーションは、このレンタカー会社と業務提携している企業内にあります。パートナーには、旅行代理店、航空会社、およびレンタカーを予約するというビジネス要件を持つその他の企業が含まれます。

新しいレンタカー予約アプリケーションのさまざまな通信要件は、単純なものではありません。たとえば、コール センター クライアント アプリケーションとのやり取りでは、パフォーマンスが重要となりますが、2 つのアプリケーションは共に .NET Framework を基盤に構築されるため、相互運用は簡単です。しかし、J2EE ベースの既存の予約アプリケーション、およびさまざまなパートナー アプリケーションとの通信については、相互運用性が最も重要な目標となります。また、Windows ベースのローカル アプリケーション、別のオペレーティング システム上で実行される J2EE ベースのアプリケーション、およびインターネット経由でアクセスしてくるさまざまなパートナー アプリケーションでは、セキュリティ要件がまったく異なります。トランザクション要求の作成が許可されているのは内部アプリケーションだけであるため、トランザクション要件もさまざまです。新しいアプリケーションの作成者が、こういった複雑さの管理で苦労せずに、これらの多様なビジネス要件や技術要件を満たすにはどうすればよいでしょうか。

WCF は、この多様で現実的なシナリオに対応できるように設計されており、サービスを公開し、サービスにアクセスする Windows アプリケーションの既定のテクノロジとなっています。ここでは、WCF の概要を説明します。WCF が提供する内容について考察し、使用方法も解説します。この概要全体を通じて、先ほどのシナリオを例として使用します。このトピックの目的は、WCF とは何かを明確にし、WCF によって解決される問題とその解決方法を示すことにあります。

問題への対処

Windows ベースの新しいアプリケーションの基盤となるのは .NET Framework です。したがって、WCF は、.NET Framework CLR の上に一連のクラスとしてまず実装されます。WCF は、開発者が使い慣れた環境を拡張するため、現在 .NET Framework を使用してオブジェクト指向アプリケーションを作成している開発者は、熟知している方法でサービス指向アプリケーションも構築できます。

WCF クライアントとサービス間の通信

この図は、WCF クライアントとサービスを示しています。両者は WCF のネイティブ メッセージ表現である SOAP を使用してやり取りします。したがって、この図では双方が WCF を基盤に構築されていることを示していますが、これは必須ではありません。WCF は、.NET Framework 2.0 を基盤としています。

前述のシナリオで示したように、WCF は、アプリケーションの通信に関するさまざまな課題に対処します。ただし、WCF の最も重要な側面として、特に次の 3 点が挙げられます。

  • 既存の .NET Framework 通信テクノロジの統合
  • 信頼性、セキュリティ、およびトランザクションを含めた、ベンダ間の相互運用性のサポート
  • 明確なサービス指向

マイクロソフト分散コンピューティング テクノロジの統合

WCF がない場合、レンタカー アプリケーションを実装する開発チームは、.NET Framework で提供される複数の選択肢の中から、適切な分散テクノロジを選択する必要があります。しかし、このアプリケーションの多様な要件を考えると、単一のテクノロジで要件を満たすことはできません。代わりに、アプリケーションでは、次のような複数の既存の .NET Framework テクノロジを使用することになると考えられます。

  • ASP.NET Web サービス (ASMX)。J2EE ベースの既存の予約アプリケーション、およびインターネットを経由するパートナー アプリケーションと通信する場合の選択肢です。現在、ほとんどのプラットフォーム上で基本 Web サービスがサポートされていることを考えると、WCF がリリースされる前は、これがベンダ間の相互運用性を実現する最も早い方法でした。
  • .NET Framework リモート処理。コール センター アプリケーションと通信する場合の選択肢です。このアプリケーションとレンタカー アプリケーションは、共に .NET Framework を基盤に構築されるからです。リモート処理は密接に結び付けられた .NET 間通信用に特別に設計されているため、リモート処理を使用すると、ローカル ネットワーク内のアプリケーションをシームレスかつ簡単に開発できます。
  • エンタープライズ サービス。オブジェクトの有効期間を管理し、分散トランザクションを定義するために、レンタカー予約アプリケーションによって使用されます。これらの機能は、このシナリオの他のアプリケーションとの通信や統合には役立ちますが、エンタープライズ サービスがサポートする通信オプションは限られています。
  • WSE。J2EE ベースの予約アプリケーションおよびパートナー アプリケーションと通信するために、ASMX と共に使用できます。WSE は、WS-* 仕様と総称される、最近定義されたばかりの Web サービス契約を実装しているため、関与するすべてのアプリケーションがこれらの新しい仕様の互換バージョンをサポートしている場合は、WSE によって Web サービス セキュリティの柔軟性を高めることができます。
  • Microsoft Message Queuing (MSMQ)。データ配信を保証し、負荷とアプリケーションの有効期間を切り離す必要のある Windows ベースのパートナー アプリケーションとの通信に使用します。一般に、Message Queuing が提供する永続的なメッセージングは、断続的に接続されるアプリケーションに最適なソリューションです。

.NET Framework を基盤とするレンタカー予約アプリケーションでは、要件を満たすために、上記の複数の通信テクノロジを使用する必要があります。これは技術的には可能ですが、作成されたアプリケーションは、実装が複雑で保守も困難になります。

WCF を使用すると、このソリューションの実装が非常に容易になります。図に示すように、前述のすべての状況で WCF を使用できます。したがって、レンタカー予約アプリケーションでは、この単独のテクノロジを使用して、すべてのアプリケーション間通信に対応できます。WCF が各要件にどのように対処するかを以下に示します。

  • WCF では、Web サービスを使用して通信できるため、J2EE ベースの主要アプリケーション サーバーなど、SOAP をサポートする他のプラットフォームと簡単に相互運用できます。
  • WCF は、SOAP に基づいていないメッセージ (RSS のような単純な XML 形式など) を使用して Web サービスと通信するように構成および拡張することもできます。
  • ほとんどの企業にとって、パフォーマンスは最大の関心事といえます。WCF は、Microsoft が開発した最高速分散アプリケーション プラットフォームの 1 つとなることを目標として設計されました。WCF と他の Microsoft .NET 分散通信テクノロジの概略的なパフォーマンス比較については、https://go.microsoft.com/fwlink/?LinkId=94274 を参照してください。
  • 通信を行う双方が WCF を基盤に構築されている場合、最適なパフォーマンスを実現するために、ネットワーク エンコードとして XML Information Set の最適化されたバイナリ バージョンが使用されます。メッセージは SOAP メッセージのデータ構造に準拠していますが、エンコードでは、XML 1.0 テキスト エンコーディングの標準的な山かっこ + テキストの形式ではなく、このデータ構造のバイナリ表現が使用されます。このオプションの使用は、コール センター クライアント アプリケーションとの通信に適しています。これは、このアプリケーションも WCF を基盤としており、パフォーマンスが重視されるためです。
  • オブジェクトの有効期間の管理、分散トランザクションの定義、およびエンタープライズ サービスのその他の側面は、WCF によって既に提供されています。これらは、WCF ベースのどのアプリケーションでも使用できます。つまり、レンタカー予約アプリケーションは、通信先の他のすべてのアプリケーションと共にこれらを使用できるということです。
  • WCF は、さまざまな WS-* 仕様をサポートしているため、これらの仕様をサポートするプラットフォームと通信する場合には、信頼性、セキュリティ、およびトランザクションが提供されます。
  • WCF には、メッセージ キューを基盤とする、キューに置かれたメッセージングのためのオプションが用意されています。このオプションにより、アプリケーションはアプリケーション プログラミング インターフェイスの別のセットを使用せずに、永続キューを使用できます。

この統合の結果、機能が強化されると共に、複雑さも大幅に軽減されます。

他のテクノロジを基盤に構築されたアプリケーションとの相互運用性

WCF では、分散アプリケーションの新しい開発環境が導入されているだけでなく、WCF アプリケーション以外のアプリケーションと適切に相互運用できるように設計されています。WCF の相互運用性には、他のプラットフォームとの相互運用性と、WCF 以前のマイクロソフト テクノロジとの相互運用性という 2 つの重要な側面があります。以下のセクションでは、この両方について説明します。

他の Web サービス プラットフォームとの相互運用性

今日の企業は、一般にさまざまな業者から購入したシステムやアプリケーションを保有しています。たとえば、レンタカー アプリケーションでは、さまざまな言語で作成され、各種オペレーティング システムで実行される、他のさまざまソフトウェア アプリケーションとの通信が必要とされています。

WCF の基本的な通信機構は、SOAP ベースの Web サービスであるため、WCF ベースのアプリケーションは、さまざまなコンテキストで実行される他のソフトウェアと通信できます。WCF を基盤に構築されたアプリケーションの場合、以下のすべてのアプリケーションとやり取りできます。

  • 同じ Windows コンピュータ上の別のプロセスで実行されている WCF ベースのアプリケーション。
  • 別の Windows コンピュータ上で実行されている WCF ベースのアプリケーション。
  • 標準 Web サービスをサポートし、他のテクノロジを基盤に構築されたアプリケーション (J2EE アプリケーション サーバーなど)。これらのアプリケーションは、Windows コンピュータ上で実行されていても、他のオペレーティング システムを実行しているコンピュータ上で実行されていてもかまいません。

基本的な通信以外も可能にするために、WCF は、WS-* 仕様によって定義された Web サービス テクノロジを実装しています。これらの仕様はすべて、もともと、マイクロソフト、IBM、および連携するその他のベンダによって定義されたものです。仕様が安定してくるにつれて、所有権が W3C (World Wide Web Consortium) や OASIS (Organization for the Advancement of Structured Information Standards) などの規格団体に渡されることが多くなっています。これらの仕様は、基本的なメッセージング、セキュリティ、信頼性、トランザクション、およびサービスのメタデータの使用など、複数の領域に対応しています。詳細については、「相互運用性と統合」を参照してください。高度な Web サービス仕様詳細については、 、https://go.microsoft.com/fwlink/?LinkId=86603 を参照してください。

これらの仕様は、次のように機能別にグループ化されます。

  • メッセージング : SOAP は Web サービスの基盤であり、ヘッダーと本文の各セクションを含む基本的なエンベロープが定義されています。WS-Addressing では、SOAP メッセージのアドレス指定のために、SOAP ヘッダーに追加する情報が定義されています。これにより、SOAP は基になるトランスポート プロトコル (HTTP など) に依存することなく、アドレス指定情報を伝達できます。MTOM (Message Transmission Optimization Mechanism) では、XOP (XML-binary Optimized Packaging) 仕様に基づいて、サイズの大きいバイナリ データ コンテンツを含む SOAP メッセージの最適化された送信形式が定義されています。
  • メタデータ : WSDL (Web サービス記述言語) では、サービスおよびその使用方法のさまざまな側面を指定するための標準言語が定義されています。WS-Policy により、WSDL で表現できないサービスの動作の動的側面 (優先セキュリティ オプションなど) を指定できます。WS-MetadataExchange を使用すると、クライアントは SOAP を使用してサービスに関する説明情報 (WSDL やポリシーなど) を直接要求できます。
  • セキュリティ : WS-Security、WS-SecureConversation、WS-Trust、および WS-Federation では、認証、データ整合性、データ プライバシー、およびその他のセキュリティ機能を提供するために、SOAP メッセージに追加する情報が定義されています。
  • 信頼性 : WS-Reliable Messaging では、1 つ以上の中間 Web サービスを経由する必要がある場合でも、信頼性の高いエンドツーエンド通信を可能にするために、SOAP ヘッダーに追加する情報が定義されています。
  • トランザクション : WS-Coordination を基盤とする WS-AtomicTransaction では、Web サービスのメッセージ交換のコンテキストにおいて、2 フェーズ コミット トランザクションの調整が可能になります。

レンタカー予約アプリケーションでは、これらのより高度なテクノロジが複数使用されると考えられます。たとえば、WS-Addressing は、HTTP 以外のトランスポート機構で SOAP を使用する場合に不可欠です (ここでは、.NET Framework ベースのコール センター クライアント アプリケーションと通信する場合)。WCF は、通信先のシステムも WCF を使用しているかどうかを検出する場合などに、WS-Policy と WS-Metadata Exchange に依存します。通信の信頼性は、ほとんどの状況で不可欠です。したがって、このシナリオでは、他の多くのアプリケーションとやり取りするために、WS-Reliable Messaging を使用する可能性が高いといえます。同様に、1 つ以上のアプリケーションとの通信をセキュリティで保護するために、WS-Security や関連する各仕様も使用することになると考えられます。これは、許可されていないアクセスや、メッセージの変更および途中受信に対する何らかの保護が必要となるためです。レンタカー予約システムとトランザクションを統合する必要のあるアプリケーションでは、WS-AtomicTransaction が不可欠となります。最後に、バイナリ データの最適化されたネットワーク形式が必要であり (車両見本の画像など)、通信の両方の側がこのオプションをサポートしている場合は、MTOM を使用できます。

重要なのは、プラットフォーム間のセキュリティ、信頼性、トランザクション、およびその他のサービスをすべて兼ね備えた相互運用可能な Web サービスを WCF が実装しているという点です。最大のスループットを実現するために、WCF と WCF との間の通信は大幅に最適化できますが、他のすべての通信では、標準の Web サービス プロトコルを使用します。実際には、1 つのアプリケーションが両方の種類のクライアントにサービスを公開できます。

マイクロソフト テクノロジとの相互運用性

Microsoft の多くの顧客は、WCF に含まれる .NET Framework テクノロジに多大な投資をしてきました。これらの投資を保護することが WCF の設計者の基本的な目標でした。WCF を導入しても、既存のテクノロジを使用できなくなることはないため、組織で WCF を使用するために既存のアプリケーションを変更するという要件はありません。明確なアップグレード パスが用意されており、可能な場合は WCF をこういった以前のテクノロジと相互運用できます。

たとえば、WCF と ASMX は共に SOAP を使用するため、WCF ベースのアプリケーションは、ASMX を基盤とするアプリケーションと直接相互運用できます。既存のエンタープライズ サービス アプリケーションも、WCF のインターフェイスでラップできるため、WCF を基盤とするアプリケーションと相互運用できます。さらに、WCF の永続キューは MSMQ に依存しているため、WCF ベースのアプリケーションは、ネイティブ MSMQ インターフェイスを使用して構築された WCF ベース以外のアプリケーションと直接相互運用できます。レンタカー予約アプリケーションの場合、これらの以前のテクノロジを使用して構築されたソフトウェアは、新しいシステムの WCF ベースのサービスに直接接続して使用できます。

ただし、相互運用が常に可能であるわけではありません。たとえば、WSE 1.0 と WSE 2.0 は、WCF と同じ WS-* 仕様を一部実装していますが、これらの以前のテクノロジが実装しているのは、以前のバージョンの仕様です。WSE のバージョン 3.0 は WCF と相互運用できますが、以前のバージョンは相互運用できません。相互運用性の詳細については、「WSE 3.0 Web サービスの WCF への移行」を参照してください。

他の XML プロトコルとの相互運用性

インターネットの将来を予測することは不可能で、現在使用されているテクノロジが進化する可能性もあれば、他のテクノロジが代わりに使用される可能性もあります。今日、("Web 2.0" と呼ばれることの多い) Web 中心のアプリケーションの構築に見られる一般的な傾向は、SOAP ベースではない単純な XML 形式だけを使用し、トランスポートおよびアプリケーション プロトコルとして HTTP だけに依存する通信に基づくアプリケーション モデルです。たとえば、REST (Representational State Transfer) アーキテクチャ スタイルには、データを処理するためのユーザー定義操作の概念はありません。代わりに、アプリケーションの状態は、HTTP URL と HTTP メソッド (PUT、POST、DELETE、GET など) に関連付けられます。この方法は、エンタープライズ環境で、ほとんどの開発者が精通しているユーザー定義のプロシージャや関数の作成とは大きく異なります。ただし、Web 2.0 アプリケーションのバックエンドとしてサービスを機能させる必要のあるシナリオでは、REST は有用な方法です。

REST は、進化し続ける Web 2.0 テクノロジの一例にすぎません。実験的なプログラミング モデルや、標準の再解釈と改良が継続的に行われているこの環境では、予測不可能な変更に対処するための柔軟性が求められます。WCF は、柔軟性を備えています。たとえば、WCF では基底構造として SOAP を使用していますが、ネットワーク通信に SOAP を使用しなければならないというわけではありません。実際に、SOAP エンベロープにラップされていない "書式なし" XML データを処理するように WCF を構成できます。また、WCF を拡張して、ATOM (一般的な RSS 標準) などの特定の XML 形式や、JSON (JavaScript Object Notation) などの XML 以外の形式をサポートすることもできます。この柔軟性により、プロトコルが変更されたり、置き換えられたりした場合でも、現在作成されているコードが今後も有効であることが保証されます。つまり、WCF は現在と将来の両方に対応できるように設計されています。

関連項目

リファレンス

System.ServiceModel

概念

Windows Communication Foundation の基本概念
Windows Communication Foundation のアーキテクチャ
ドキュメントのガイド

その他の技術情報

ガイドラインとベスト プラクティス
チュートリアル入門
基本的な WCF プログラミング
Windows Communication Foundation Samples