とあるコンサルタントのつぶやき : WCF

Part 4. IIS ホストの使い方

nakama — Thu, 09 Oct 2008 04:40:05 GMT

さて、前回の Part 3. のエントリまでで基本的な WCF サービスの開発方法を説明しましたが、ここまでのサンプルでは、すべてコンソールアプリケーションを使ってサーバを開発してきました。しかし実際の運用を想定すると、アプリケーションリスタートやプロセスリサイクリング、あるいはモニタリングといった、運用監視関係の機能を充実させる必要があり、このコンソールアプリケーションを強化してそれらの機能を持たせるのは非現実的です。このため、実運用では IIS をホストとして WCF サービスを動作させ、IIS が持つ各種の運用管理機能を活用するのが便利です。

本エントリでは、IIS ホストの使い方として、以下の項目について解説します。

.svc ファイルによる WCF サービスの開発方法
2 つの ASP.NET ランタイムとの統合方式
構成設定ファイルを使わない .svc ファイルの作り方
WPAS （Windows Process Activation Service）の使い方

［Step.15 .svc ファイルによる WCF サービスの開発方法］

では、実際に Web サーバ上で動作する WCF サービスを開発してみます。まず、新規に Web サイトプロジェクトを作成します。（※ WCF サービスプロジェクトはここでは利用しません。通常の ASP.NET Web サイトプロジェクトを利用してください。）

作成されたサイトの Default.aspx ファイルは利用しませんので、削除しておきます。ここに、WCF サービスを開発していきます。

ASP.NET ランタイム上で動作する WCF サービスを開発するためには、.svc ファイルを作成します。

プロジェクトに対して新しい項目を追加します。
画面上に、「WCF サービス」という項目が見えますが、これは使いません。
かわりに、テキストファイルを選択し、ファイル名を「WcfService.svc」ファイルに変更してからプロジェクトに追加します。

※ 「WCF サービス」という項目や、WCF サービスプロジェクトを利用しないのは、これらがファイル分離型開発モデルに基づいたファイル配置を取るためです。今回は、.svc ファイルを通信インタフェース（SI）としてのみ利用するような設計モデルを取るため、.svc ファイルの中にすべてのコードを記述する方法でサンプルを示します。

このようにすると、ファイルの中身が空の .svc ファイルが作成されます。ここに、以下のようなコードを記述します。

        1: <%@ ServiceHost Language="C#" Debug="true" Service="WcfService" %>

       2:  

       3: using System;

       4: using System.Runtime.Serialization;

       5: using System.ServiceModel;

       6: using System.Text;

       7:  

       8: [ServiceContract]

       9: public class WcfService

      10: {

      11:     [OperationContract]

      12:     public string GetMessage(string name)

      13:     {

      14:         return "Hello World, " + name;

      15:     }

      16: }

      17:

※ .svc ファイルを編集する際に、Visual Studio 2008 上で、IntelliSense が効かないことがあります。この場合は、ディレクティブ（先頭行の <%@ %> 記号）を入力したあと、いったんファイルを閉じて再度開いてみてください。

※ なお、今回は話をわかりやすくするために、.svc ファイルのファイル名とクラス名を一致させていますが、これらの名前はずれていても構いません。.svc ファイルは Address (URL) の決定に利用されますが、これは WCF サービスのクラス名と一致していなくても構わないためです。

次に、SvcConfigEditor を利用して、web.config ファイル上に構成設定を行います。

サービスを新規に追加し、実装クラス名として "WcfService" を指定します。（※ .svc ファイル中で WCF サービスクラスを定義する際に namespace 指定を行った場合には、名前空間をつけて実装クラス名を指定してください。）
エンドポイントを作成し、A = 空欄、B = basicHttpBinding、C = WcfService を設定します。（※ Address(URL) は、.svc ファイルにより暗黙的に決定されることになるため、指定しません。）
サービス動作（サービスビヘイビア）を作成し、serviceDebug, serviceMetadata の 2 つを追加します。
serviceMetadata のプロパティとして、HttpGetEnabled を True に変更します。
最後に、作成したサービスビヘイビアを、"WcfService" に割り当てます。

作成し終わった構成設定ファイルと、SvcConfigEditor の画面を以下に示します。

       1: <?xml version="1.0" encoding="utf-8"?>

       2: <configuration>

       3:  

       4:     ... (中略) ...

       5:  

       6:     <system.serviceModel>

       7:         <behaviors>

       8:             <serviceBehaviors>

       9:                 <behavior name="NewBehavior">

      10:                     <serviceDebug />

      11:                     <serviceMetadata httpGetEnabled="true" />

      12:                 </behavior>

      13:             </serviceBehaviors>

      14:         </behaviors>

      15:         <services>

      16:             <service behaviorConfiguration="NewBehavior" name="WcfService">

      17:                 <endpoint binding="basicHttpBinding" contract="WcfService" />

      18:             </service>

      19:         </services>

      20:     </system.serviceModel>

      21: </configuration>

以上の作業が終わったら、Web サイトプロジェクトを実行して、WcfService.svc ファイルを呼び出してみてください。serviceDebug モジュールにより、ヘルプページが作成され、以下のような画面がブラウザ上に表示されます。（WSDL ファイルも表示できることを確認してください。）

WCF サーバの開発が終了したら、今度は WCF クライアントの開発に移ります。

ソリューションに新規にコンソールアプリケーションを追加します（ConsoleApplication1）。
サービス参照を追加し、WCF プロキシクラスを作成します。（※ 同一ソリューション内の WCF サービスを探す場合には、「探索」ボタンを使うと便利です。）
アプリケーションコードを記述し、WCF サービスを呼び出すコードを記述します。

       1: using System;

       2: using System.Collections.Generic;

       3: using System.Linq;

       4: using System.Text;

       5:  

       6: namespace ConsoleApplication1

       7: {

       8:     class Program

       9:     {

      10:         static void Main(string[] args)

      11:         {

      12:             ServiceReference1.WcfServiceClient proxy = new ConsoleApplication1.ServiceReference1.WcfServiceClient();

      13:             string message = proxy.GetMessage("Nobuyuki");

      14:             proxy.Close();

      15:  

      16:             Console.WriteLine(message);

      17:         }

      18:     }

      19: }

以上の作業で完成になります。コンソールアプリケーションを実行してみると、ASP.NET ランタイム上にホストされた .svc ファイル（WCF サービス）が呼び出され、WCF サービスが実行されます。

※ なお今回は解説しませんが、.svc ファイルを使う場合には basicHttpBinding 以外にも、wsHttpBinding や、HTTP トランスポートを利用する customBinding も利用することができます。このため、httpTransport チャネルと binaryMessageEncoding チャネルを組み合わせた customBinding を使うと、バイナリエンコード方式を利用した WCF サービスを ASP.NET ランタイム上でホストすることができます。余力がある方は、ぜひトライしてみてください。

※ ここまで完成したら、いったんソリューションファイルをコピーするなりバックアップするなりしておいてください。（Step.18 で再利用します。）

［Step.16 2 つの ASP.NET ランタイムとの統合方式］

さて、.svc ファイルを利用した場合の WCF サービスの内部動作がどのようになっているのかを次に考えてみます。この .svc ファイル方式は、簡単にいえば、ASP.NET ランタイムを HTTP プロトコルのリスナとして使おうという方式で、その動作イメージは下図のようになります。

つまり、.svc ファイルが WCF ランタイムにおけるリスナの役割を果たすことになり、これにより WCF サービスが HTTP プロトコルによる通信要求を受け付けられる、という形になります。（正確には、.svc ファイルに記述したディレクティブ（先頭行）の命令により ServiceHost インスタンスの生成、WCF パイプラインの構築が行われ、我々が記述した WcfService クラスが動作する、という形になります。）

ところが、ここで問題になるのが、WCF パイプライン（バインディング）と、ASP.NET パイプラインの関係（役割分担・位置づけ）です。ASP.NET ランタイムにもパイプラインがあり、WCF ランタイムにもパイプライン処理がある、という形になっているのですが、これらの関係は、下図のように表わすことができます。（※ Part. 1 の解説も参考になるので、そちらもご参照ください。）

もともと、ASP.NET ランタイムは HTTP 通信に限定して開発されたものであるため、ASP.NET パイプライン（上図で HTTP パイプラインと書かれているところ）は、OSI 7 階層モデルの最上位には位置しますが、WCF 3 階層モデルの観点からすると、あくまで A 層のものでしかありません。よって、ASP.NET ランタイムと WCF ランタイムそれぞれで個別にパイプライン処理が走り、この .svc ファイル内に記述した WCF サービスが動作していることになります。

さて .svc ファイルを使う場合、基本的に、ASP.NET ランタイムは WCF サービスのリスナとしてしか使わない、ということになります。しかし上図のように、.svc ファイルに対する処理を、通常の HTTP ハンドラによる拡張子振り分けにより実施しようとすると、ASP.NET パイプライン上のモジュールを片っ端から動作させることになり、性能上不利益をこうむることになります。このため、WCF ランタイムには ASP.NET ランタイムとの統合モードとして、以下の 2 つが用意されています。

ASP.NET 非互換モード（既定のモード）
HTTP モジュールを使って、PostAuthenticateRequest イベントのタイミングで .svc ファイルをフックする方式。この方式の場合、ASP.NET ランタイムの大半のモジュールはショートカットされて動作せず、より高い性能で WCF サービスを動作させることができる。
ASP.NET 互換モード
HTTP ハンドラを使って、通常通り .svc ファイルを処理する方式。この方式の場合には、ASP.NET ランタイムのモジュールが片っ端から動作することになる。（※ このモードを使うための具体的な設定方法は MSDN ライブラリなどを参照してください。）

※ この 2 つのモードで WCF サービスを動作させるため、.NET Framework 3.0 をインストールすると、ルート web.config ファイルに修正が加わります。一見すると、HTTP ハンドラにより .svc ファイルが動作しているように見えますが、既定のモードでは下側の ServiceModel HTTP モジュールの方が .svc ファイルをフックしています。

       1: <httpHandlers>

       2:   ...

       3:   <add path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/>

       4:   ...

       5: </httpHandlers>

       6:  

       7: <httpModules>

       8:   ...

       9:   <add name="ServiceModel" type="System.ServiceModel.Activation.HttpModule, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>

      10: </httpModules>

WCF ランタイムに 2 つの ASP.NET ランタイム統合モードが用意されているのは、正直なところ混乱の元のような気がしなくもない（＝WCF の原則に従って、非互換モードだけで十分のような気もする）のですが、

ASP.NET XML Web サービス（.asmx ファイル）とのアプリケーション共存
高度なアプリケーションサービスの利用

の 2 点を考えると、確かに互換モードが用意されていてもいいのかな、という気もします。後者については少しわかりにくいと思うので補足しますが、そもそも、WCF パイプラインと ASP.NET パイプラインは、目的としているところが全くといっていいほど違います。

WCF パイプライン＝通信プロトコルの抽象化
ASP.NET パイプライン＝高度なアプリケーションサービスの提供

もう少し具体的な例を挙げると、たとえば ASP.NET パイプラインの中には、SessionState モジュールや OutputCache モジュールなどなど、アプリケーション開発に役立つような機能群がたくさん用意されています。ところが、WCF パイプラインの方には、こうしたアプリケーション開発に活用できるサービスや機能がほとんどといっていいほど存在せず、通信暗号化や通信抽象化、トランザクションフローなどの通信制御系の低水準機能を提供することにフォーカスしています。（これはある意味当たり前で、WCF パイプラインは OSI 7 階層モデルにおける下層のようなものなので、ASP.NET パイプラインのような高度なアプリケーション開発サービスを提供する場合には、WCF パイプライン（Binding）の上位に、こうしたサービスを構築しなければならないと考えられます...が、まだそれはない、ということなんですよね。）

こうした状況下で WCF アプリケーションを作ろうと思った場合、ASP.NET 上で *.asmx を作る場合に比べると、利用できるアプリケーションサービスが限定的であるため、開発が厄介になることがあります（特にデータキャッシュ機能がないのはかなり不便でしょう）。このような場合には、ASP.NET 互換モードを利用して、ASP.NET ランタイムのアプリケーションサービスを使うというのも（現時点では）一つの有効な選択肢になると思います。（ただ、ASP.NET ランタイム上でしかその WCF サービスが動作しなくなってしまう、という問題は当然存在するのですが。）

［Step.17 構成設定ファイルを使わない .svc ファイルの作り方］

さて、ここまでの解説では、Web サイト内に WCF サービス（.svc ファイル）をひとつだけ作成しましたが、実際の業務アプリケーションでは、WCF サービス（.svc ファイル）が複数個作られることになるはずです。ところが現状の作り方では、WCF サービスが増えると、構成設定ファイル（web.config ファイル）上にそれらの構成設定を追加していかなければならなくなるため、構成設定ファイルの維持・管理が極端に面倒になります。（下図の例を参照）

※ この点は結構大きな問題で、例えば X, Y, Z の 3 つの WCF サービス（.svc ファイル）を作成する際に、それらの構成設定データを同一の web.config ファイルに記述しなければならなくなると、チーム開発が非常にやりづらくなります。（例えば X さんが web.config ファイルをいじったときに、間違って Y さんの構成設定を壊してしまう、など） ASP.NET XML Web サービス（*.asmx）開発のよいところは、複数人がそれぞれの XML Web サービスを開発する際に、バラバラのファイルを触ればよいようになっている（同じファイルをみんなで触らなくて済むようになっている）、という点です。

この問題を避けるためには、.svc ファイルのディレクティブとして、Service 属性のかわりに Factory 属性を利用し、さらに ServiceHost インスタンス（WCF ランタイム）を手動で起動して A/B/C を手作業で構築するコードを記述します。このようにすると、web.config ファイル上に構成設定を記述しなくても済むようになります。（※ web.config ファイル上でも構成設定を行うと、衝突を起こして例外が発生します。）

       1: <%@ ServiceHost Language="C#" Debug="true" Factory="WcfServiceHostFactory" %>

       2:  

       3: using System;

       4: using System.ServiceModel;

       5: using System.ServiceModel.Activation;

       6: using System.ServiceModel.Description;

       7:  

       8: public class WcfServiceHostFactory : ServiceHostFactory

       9: {

    public override ServiceHostBase CreateServiceHost(string service, Uri[] baseAddresses)

    {

        ServiceHost host = new ServiceHost(typeof(WcfService), baseAddresses);

        host.AddServiceEndpoint(typeof(WcfService), new BasicHttpBinding(), "");

        ServiceMetadataBehavior svb1 = new ServiceMetadataBehavior();

        svb1.HttpGetEnabled = true;

        host.Description.Behaviors.Add(svb1);

        return host;

    }

}

  

[ServiceContract]

public class WcfService

{

    [OperationContract]

    public string GetMessage(string name)

    {

        return "Hello World, " + name;

    }

}



上記のコードではベタ書きしていますが、少し工夫すればユーティリティクラス化することができますので、この方法を利用すると、みんなが一つの構成設定ファイルをいじらなければならない、という状況を回避することができます。

［Step.18 WPAS （Windows Process Activation Service）の使い方］

最後に、IIS 7 で利用できるようになった、WPAS （Windows Process Activation Service（WAS と書くこともあります））についても解説しておきます。

WPAS とは、簡単に言うと、IIS 上にホストした WCF サービスを、TCP/IP 通信や名前付きパイプ通信により呼び出せるようにするための仕組みです。従来、TCP/IP 通信を受け付けるサーバアプリケーションを記述するためには、.NET Remoting などを使って、自力でサーバランタイムを記述しなければならなかったのですが、IIS 7 を使うとこの作業が大幅に簡素化される、ということになります。（なお、この仕組みは IIS 7 上、つまり Windows Vista 及び Windows Server 2008 でしか使うことができませんので注意してください。）

以下では Windows Vista の場合を例にとって、WPAS の使い方を解説してみることにします。（基本的なやり方は Windows Server 2008 でも同じです。）

まず、Windows Vista のコントロールパネルから、IIS 7 及び WCF 拡張サービスをインストールします。細かいオプションをひとつずつ設定するのは大変なため、以下の 4 項目にのみチェックを入れてください。（関連するものは自動的にチェックが入ります。）

Internet Information Services → World Wide Web サービス → アプリケーション開発機能 → ASP.NET
Internet Information Services → Web 管理ツール → IIS 管理コンソール
Microsoft .NET Framework 3.0 → Windows Communication Foundation HTTP Activation
Microsoft .NET Framework 3.0 → Windows Communication Foundation Non-HTTP Activation

※ WPAS の実体はこの画面のずーっと下のほうにある「Windows プロセス起動サービス」というものです。上記の項目を選択すると、これらの項目も自動的にインストール対象となります。

次に、Step.15 で完成させたソリューションファイルを（まずは HTTP ベースで） IIS 7 上で動作させるように構成します。

コントロールパネル → 管理ツール → IIS Manager を開きます。
Default Web Site に「仮想ディレクトリの追加」を行い、Step.15 で作った Web サイトへのフォルダマッピングを作成します。（エイリアス = "WebSite1"、物理パス = "C:\Users\nakama\Documents\Visual Studio 2008\WebSites\WebSite1"）
作成された WebSite1 フォルダに対して、「アプリケーションへの変換」を行い、当該フォルダを Web アプリケーション化します。
物理フォルダに対して ACL （ファイルアクセス権）の設定を行い、Everyone に対して読み取り権限を与えます。
以上の作業が終わったら、WcfService.svc ファイルを呼び出してみてください。（ポート 80 番上で公開されているので、http://localhost/WebSite1/WcfService.svc をブラウザから呼び出してみてください。）

［仮想ディレクトリの作成］

［Web アプリケーション化］

［ACL の設定］

［動作確認］

次に、ポート 80 番の IIS 7 上で動作しているこのアプリケーションを呼び出すクライアントアプリケーションを用意します。すでに作成してあるアプリケーションの構成設定ファイルを書きかえれば呼び出せるようになるはずなので、以下のように作業してみることにします。

Step.15 で作成したコンソールアプリケーション（WCF サービスを呼び出すクライアント側のアプリケーション）を、まるごとデスクトップなどにコピーします。（C:\Users\nakama\Documents\Visual Studio 2008\Projects\WebSite1\ConsoleApplication1\bin\Debug フォルダの下にあるファイル群。Debug フォルダごとデスクトップなどにコピーしてしまうとよいでしょう。）
コピーした "ConsoleApplication1.exe.config" ファイルを、SvcConfigEditor ツールで開きます。
クライアントエンドポイントの "Address" を、適切なアドレスに書き換えます。（例： http://localhost:1208/WebSite1/WcfService.svc → http://localhost/WebSite1/WcfService.svc）
書き替えたら、コマンドラインプロンプトなどから ConsoleApplication1.exe を呼び出して実行します。

以上の作業により、IIS 7 上に配置したアプリケーションを、HTTP プロトコルで呼び出すことができるようになります。

次に、この WCF サービスの通信プロトコルを、TCP/IP に切り替えてみます。サーバ側の通信プロトコルの切り替えに必要なのは、① IIS 7 の構成設定を変更して TCP/IP 通信を受け付けられるようにすることと、② web.config ファイルを修正してバインディングを netTcpBinding に切り替えること、です。

① IIS 7 の構成設定を変更して TCP/IP 通信を受け付けられるようにする

この作業は、IIS サービスマネージャから行います。

まず、"Default Web Site" を選択し、画面右側の「操作」→「サイトの編集」→「バインド...」を選択し、サイトバインドを確認します。http だけでなく、net.tcp という項目が追加されていれば、IIS で TCP/IP 通信による WCF サービス呼び出しを受け付けられる状態になっています。
次に、"WeiSite1" を選択し、画面右側の「操作」→「アプリケーションの管理」→「詳細設定...」を選択します。詳細設定一覧の中の「動作」→「有効なプロトコル」を、"http" から "http,net.tcp" に変更します。（カンマ区切り、空白なしで）これにより、この Web アプリケーションが TCP/IP 通信を受け付けられるようになります。

② web.config ファイルを修正してバインディングを netTcpBinding に切り替える

次に、web.config ファイルを修正します。ここではせっかくですので、netTcpBinding への切り替えではなく、このバインディングを追加してみたいと思います。

まず、"C:\Users\nakama\Documents\Visual Studio 2008\WebSites\WebSite1" フォルダ下にある web.config ファイルを、SvcConfigEditor.exe ツールで開きます。
WcfService に対して、新規にサービスエンドポイントを追加し、Binding = "netTcpBinding", Contract = "WcfService" を指定します。（Address は空欄）
暗号化通信を行わない設定とするため、バインディング構成設定を追加します。「バインド」セクションに「新しいバインド構成」を追加し、netTcpBinding のバインド構成を新規作成します。セキュリティタブの Mode を "None" に変更したら、再びエンドポイントの設定に戻り、このバインド構成（"NewBinding0"）を割り当ててください。

       1: <?xml version="1.0" encoding="utf-8"?>

       2: <configuration>

       3:  

       4:     ... (中略) ...

       5:  

       6:     <system.serviceModel>

       7:         <bindings>

       8:             <netTcpBinding>

       9:                 <binding name="NewBinding0">

                    <security mode="None" />

                </binding>

            </netTcpBinding>

        </bindings>

        <behaviors>

            <serviceBehaviors>

                <behavior name="NewBehavior">

                    <serviceDebug />

                    <serviceMetadata httpGetEnabled="true" />

                </behavior>

            </serviceBehaviors>

        </behaviors>

        <services>

            <service behaviorConfiguration="NewBehavior" name="WcfService">

                <endpoint binding="basicHttpBinding" contract="WcfService" />

                <endpoint binding="netTcpBinding" bindingConfiguration="NewBinding0"

                    contract="WcfService" />

            </service>

        </services>

    </system.serviceModel>

</configuration>

以上のことを行ったら、ファイルをセーブし、ヘルプページ（http://localhost/WebSite1/WcfService.svc）と WSDL 情報（http://localhost/WebSite1/WcfService.svc?wsdl）を開いてみてください。正しく構成できていれば、WSDL 情報に、basicHttpBinding によるエンドポイントの情報と、netTcpBidning によるエンドポイントの情報とが掲載されます。

この WSDL ファイルを利用してサービス参照を行い、TCP/IP プロトコルでの呼び出しを行ってもよいのですが、ここではクライアント側アプリケーションの構成設定を手動で変更してみることにします。デスクトップにコピーしたコンソールアプリケーションの構成設定ファイル（ConsoleApplication1.exe.config）を、SvcConfigEditor.exe で開きます。

現在は、basicHttpBinding を利用するようにエンドポイントが構成されているので、これを netTcpBinding を使うように変更してみます。

バインドセクションに、netTcpBinding の新しいバインド構成を追加し、セキュリティの Mode を "None" に変更します。
エンドポイント設定に戻り、エンドポイントのバインディングを変更します。
Address = "net.tcp://localhost:808/WebSite1/WcfService.svc"
Binding = "netTcpBinding"
BindingConfiguration = "NewBinding0"
Contract = "ServiceReference1.WcfService" （変更なし）

※ （参考） IIS 7 上で TCP/IP プロトコルを利用する場合、既定ではポート番号は 808 が利用されます（上記の Address 設定では ":808" を取り除いても動作します）。また、エンドポイントの名前はここでは変更していません（BasicHttpBinding_WcfService のままになっています）が、"NetTcpBinding_WcfService" などに変更していただいても構いません。

以上の作業を終えてから、コマンドプロンプトよりこのアプリケーションを動作させると、TCP/IP プロトコルにて IIS 7 上にホストした WCF サービスが呼び出されるようになります。

［まとめ］

非常に長いエントリになりましたが、本エントリの要点をまとめると以下のようになります。

Web サーバ上に WCF サービスをホストしたい場合には、.svc ファイルを利用する。
.svc ファイルは、WCF ランタイムにおいてリスナの役割を果たすようになる。
WCF ランタイムと ASP.NET ランタイムの統合モードは 2 種類ある。通常は、ASP.NET ランタイムをリスナとしてのみ利用するモードを利用する。
.svc ファイルのディレクティブにて Factory 属性を利用して、手作業で WCF パイプラインを組み立てると、構成設定ファイルを使わない WCF サービスを開発できる。
IIS 7 に搭載された WPAS （Windows Process Activation Service）を利用すると、IIS 7 上にホストした WCF サービスを TCP/IP や名前付きパイプのプロトコルで呼び出すことができるようになる。

＃ここまで読んでいただきましたら、もう一度 Part.1 の解説を読み返してみていただけると、その内容がより深く理解できるのではないかと思います。

さて、全 4 回にわたって WCF （Windows Communication Foundation）の基本的な利用方法について解説してきましたが、「業務アプリケーション開発の用途だったら ASP.NET XML Web サービス（*.asmx）で十分じゃないの？」という感想を持たれる方もいらっしゃると思います。実際、素の SOAP over HTTP プロトコルのみで十分な場合には WCF を利用する必要性は薄く、ASP.NET XML Web サービスのお手軽開発の方が便利、ということも多いでしょう。しかし、WCF ランタイムにはマルチプロトコル対応などのメリットの他、今回のエントリでは紹介しきれていない I/F 型共有機能や WSDL ファイルを参照しない開発など様々な機能が提供されています。また、今後、マイクロソフトから提供される様々なテクノロジが、低水準では WCF ランタイムを利用するようになってくるため、今回の一連のエントリで解説した程度の内容は理解しておくことが望ましいと思います。

WCF に関しては概念的に高度なランタイムであるため、非常にとっつきにくいものになっていますが、本エントリを元にして WCF に触れてみていただければ幸いです。

＃ ...にしてもホントに長いエントリになってしまいました。WPAS の説明などが異様に長いですね。無理もないのですが。

Part 3. Hello World WCF クライアントの開発

nakama — Wed, 01 Oct 2008 18:32:50 GMT

さて、前回のエントリでは Hello World メッセージを返す WCF サーバを作成し、SOAP over HTTP でリクエストを受け付けるエンドポイントを作成しました。引き続き本エントリでは、このサーバアプリケーションを呼び出すクライアントアプリケーションを作成していくことにします。

クライアントアプリケーション作成時には、Part 2. で作成した WCF サーバを起動しておき、WSDL ファイルを入手できる状態にしておく必要があります。このため、以降の作業は Part.2 で作成した WCF サーバアプリケーションを起動した状態で作業を進めてください。

※ Part 2. で完成させたソリューションは以下になります。

本エントリでは、以下の作業を行います。

WCF プロキシクラスの作成と利用
サービスログとトランスポートログ
TCP/IP 通信への通信プロトコルの切り替え

では具体的な作業手順を以下に説明したいと思います。

［Step. 10］ WCF プロキシクラスの作成と利用

まず、Visual Studio 2008 をもう一つ起動し、新規にコンソールアプリケーションをひとつ作成します（名前は "Sample01.Client" にしておきます）。

※ （参考） WCF サーバ／クライアントアプリケーションを開発する際に、サーバとクライアントのソリューションを分けるということに違和感を覚える方も多いと思います。……が、その違和感は極めてごもっともだと思います；。本来、ソリューションは「ビルドの単位」なわけで、I/F 整合性を保ってビルドされる複数のプロジェクトは同一ソリューションに含まれるべきです。SOAP over HTTP は疎結合と言われますが、スマートクライアントなどの開発においてはサーバ／クライアントは実態として密結合であることがほとんど。このため、XML Web サービスなどを使ってスマクラを作る場合には、サーバとクライアントは同一ソリューションに含める形で作るべきだと私は考えています。ところが WCF での開発の場合、サーバ側のアプリケーションがちゃんとビルド＋実行できないと、MEX エンドポイントが公開できず、クライアント側でプロキシクラスを手軽に作ることができないという問題があり、サーバ／クライアントのソリューションを分けて作業しないと、恐ろしく開発作業が面倒になります（実際に一度やってみるとよいかも．．．．かなり苦労します）。このため、（論理的には不適切だと思うのであまりお薦めしたくはないのですが開発の利便性を優先させて）、サーバ／クライアントをソリューションとして分けて開発する、という方法で説明しています。

作成したら、ここに WCF サービスを呼び出すためのプロキシクラスを作成します。

ソリューションエクスプローラのコンソールアプリケーションプロジェクトを右クリックし、「サービス参照の追加」を選択します。
アドレス欄に、MEX エンドポイントの URL を打ち込み、移動ボタンを押します。
（手順通りに作業している場合は、http://localhost:8000/Sample01.Server/WcfService/mex という名前にしているはずです。）
正しく WSDL ファイルが入手できると、下図のように WCF サービスの内容が表示されます。
さらに必要に応じて詳細設定を行いますが、ここでは特になにもせずに OK ボタンを押下します。（※ 例えば、既定では WCF のプロキシクラスが作成されますが、ASP.NET XML Web サービスのプロキシクラスを作成する場合には詳細設定からオプションを指定します。）

以上の作業により、プロキシクラスが作成されます。

作成されたプロキシクラスは、以下のようなコードでインスタンス化して利用することができます。

        1: using System;

       2: using System.Collections.Generic;

       3: using System.Linq;

       4: using System.Text;

       5:  

       6: namespace Sample01.Client

       7: {

       8:     class Program

       9:     {

      10:         static void Main(string[] args)

      11:         {

      12:             ServiceReference1.WcfServiceClient proxy = new ServiceReference1.WcfServiceClient();

      13:             string ret = proxy.GetMessage("Nobuyuki");

      14:             proxy.Close();

      15:  

      16:             Console.WriteLine(ret);

      17:         }

      18:     }

      19: }

※ なお、コード中でプロキシクラスを作成・利用した後に ".Close()" メソッドを呼び出してプロキシを閉じていますが、WCF を使う場合には、この .Close() 処理のコードを記述するクセをつけてください。単純な SOAP over HTTP 呼び出しなどでは、「単発のメソッド呼び出し」で処理が終了するため、.Close() 処理は不要ですが、例えば WS-ReliableMessaging や WS-Security などを利用している場合には、サーバとクライアント間で論理セッションが張られていることがあります。このため、.Close() 処理によりこうした論理セッションを解放してやらないと、サーバ／クライアントそれぞれでリソースリークとなることがあります。

実行すると、WCF サーバが呼び出され、以下のように Hello World メッセージが表示されます。

ここで、クライアント側のソリューション（Sample01.Client）内にある app.config ファイルを、テキストエディタや SvcConfigEditor で開いてみてください。

       1: <?xml version="1.0" encoding="utf-8" ?>

       2: <configuration>

       3:     <system.serviceModel>

       4:         <bindings>

       5:             <basicHttpBinding>

       6:                 <binding name="BasicHttpBinding_WcfService" closeTimeout="00:01:00"

       7:                     openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"

       8:                     allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"

       9:                     maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"

      10:                     messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"

      11:                     useDefaultWebProxy="true">

      12:                     <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"

      13:                         maxBytesPerRead="4096" maxNameTableCharCount="16384" />

      14:                     <security mode="None">

      15:                         <transport clientCredentialType="None" proxyCredentialType="None"

      16:                             realm="" />

      17:                         <message clientCredentialType="UserName" algorithmSuite="Default" />

      18:                     </security>

      19:                 </binding>

      20:             </basicHttpBinding>

      21:         </bindings>

      22:         <client>

      23:             <endpoint address="http://localhost:8000/Sample01.Server/WcfService"

      24:                 binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_WcfService"

      25:                 contract="ServiceReference1.WcfService" name="BasicHttpBinding_WcfService" />

      26:         </client>

      27:     </system.serviceModel>

      28: </configuration>

この設定ファイルに書き出された内容の詳細は理解する必要はありませんが、以下の点に注目してください。

サーバに比べるとかなり複雑な構成設定が記述されています。これはクライアント側の app.config ファイルには WCF ランタイムの既定の設定値による構成設定値も書き出されるためです。
SvcConfigEditor でみると、「サービス」のセクションではなく、「クライアント」のセクションにエンドポイントの構成設定（A/B/C 情報）が書き出される形になっています。（大枠として A/B/C について設定しなければならない点は同一ですが、詳細な設定項目はサーバ側とクライアント側でかなり異なっています。）

ちなみに、クライアント側の設定の中の重要な部分だけ抜粋すると、以下のようになります。記述するセクションは異なりますが、サーバ側の構成設定とクライアントの構成設定とが対称的な設定になっていることに着目してください。

■ クライアント側の構成設定（の要点）

       1: <?xml version="1.0" encoding="utf-8" ?>

       2: <configuration>

       3:     <system.serviceModel>

       4:         <client>

       5:           <endpoint address="http://localhost:8000/Sample01.Server/WcfService"

       6:               binding="basicHttpBinding" contract="ServiceReference1.WcfService" />

       7:         </client>

       8:     </system.serviceModel>

       9: </configuration>

■ サーバ側の構成設定（の要点）

       1: <?xml version="1.0" encoding="utf-8" ?>

       2: <configuration>

       3:     <system.serviceModel>

       4:         <services>

       5:             <service name="Sample01.Server.WcfService">

       6:                 <endpoint address="http://localhost:8000/Sample01.Server/WcfService"

       7:                     binding="basicHttpBinding" contract="Sample01.Server.WcfService" />

       8:             </service>

       9:         </services>

      10:     </system.serviceModel>

      11: </configuration>

［Step. 11］サービスログとトランスポートログ

さて、このままだと実際にサーバが呼び出されたか否かがわかりませんので、構成設定ファイルを書き替えて、ログファイルを取得してみることにします。

まず、いったん WCF のサーバ側アプリケーションを停止し、サーバ側（Sample01.Server）のソリューション内にある app.config ファイルを SvcConfigEditor で開きます。次に、この中の「診断」（Diagnostics）セクションを開き、以下の設定作業を行います。

構成ウィンドウ内の「診断」セクションの「メッセージログ」を有効化する。
メッセージログの設定項目として現れる「ログ記録レベルとして、「間違った形式のメッセージ」「サービスメッセージ」「トランスポートメッセージ」の 3 つを有効化する。
構成ウィンドウ内のさらに「診断」セクションの下の「メッセージログ」の項目を開き、"LogEntireMessage" プロパティを "True" に変更する。

通常は以上の作業でおしまいですが（これにより C:\Users\nakama\Documents\Visual Studio 2008\Projects\Sample01.Server\Sample01.Server\App_messages.svclog などにログファイルが出力されるようになる）、ここではコンソール画面上にもログデータが出力されるようにしてみます。追加で以下の作業を行ってみてください。

リスナセクションに、新しいリスナをひとつ追加する。
"TypeName" プロパティを、System.Diagnostics.Console.TraceListener に変更する。（"..." ボタンから選択すると簡単。選択すると、"System.Diagnostics.ConsoleTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" が設定される。）
ソースとして "System.ServiceModel.MessageLogging" を追加する。

以上の作業を行ったら、実際に WCF サービスを起動し、ログファイルを取得してみます。

まず、既存のログファイルが残っている場合はこれを削除します。（Visual Studio のソリューションエクスプローラ上で、「すべてのファイルを表示」オプションを入れ、そこに現れる "App_messages.svclog" を削除するとラク。）
WCF サーバアプリケーション（Sample01.Server）を起動します。
WCF クライアントアプリケーション（Sample01.Client）を実行します。（サーバ側のコンソール上にログが出力されることを確認してください。）
呼び出しが終了したら、サーバアプリケーション上でリターンキーなどを押下し、穏やかに終了させてください。（＝Ctrl+C などで強制終了させないでください。（host.Close() 処理により、ログファイルがクローズされるため。））

以上の作業により、App_messages.svclog ログファイルが出力されます。このファイルの中身は XML 形式で出力されたデータファイルであるため、このままではとても読み取れません。このため、サービストレースビューアというツールで読み取ります。（プログラムメニュー内の Microsoft Windows SDK 6.0A 下にあります）

※ このツールについても、SvcConfigEditor ツールなどと同様に、Visual Studio に登録しておくと便利です。

実際に出力されたログファイルの内容を確認すると、1 回のリクエストしか行っていないにもかかわらず、4 つのログが出力されています。これは、以下のような理由によります。

先に、サービスレベルとトランスポートレベルのログを出力するように設定しましたが、これは下図のように、WCF パイプラインの入口と出口のところそれぞれについてロギングを行う、という設定になります。
メッセージが入ってくる流れと、レスポンスが出ていく流れそれぞれでロギングが行われるので、都合 4 つのログが出力されます。

なお、今回のサンプルでは、サービスレベルとトランスポートレベルのログがほとんど同じになっています。しかし、WS-Security などを使う場合には、2 つの場所で記録される内容がかなり変わります。（トランスポートレベルのメッセージは暗号化されており、サービスレベルのメッセージは暗号化されていない） WS-Security などを使う場合には、実際にログを取って確認してみるとよいでしょう。

［Step. 12］ TCP/IP 通信への通信プロトコルの切り替え（サーバ側）

では最後に、WCF ランタイムの大きな特徴の一つである、マルチプロトコル対応（同一通信特性を持つ通信プロトコルへの切り替え）を示してみたいと思います。ここでは、SOAP over HTTP 通信を、TCP/IP 通信に取り替えてみたいと思います。作業は以下の流れで行います。

サーバ側のバインディングの取り換え（basicHttpBinding から netTcpBinding への取り換え）
クライアント側でのプロキシクラスの作り直し

ではまず、サーバ側のバインディングの取り換えを行います。サーバ側アプリケーションを停止させた上で、app.config ファイルを SvcConfigEditor で開き、以下の作業を行います。

サービスのエンドポイントを開き、Binding を netTcpBinding に取り替えます。
さらに、Address を net.tcp://localhost:8001/Sample01.Server/WcfService に切り替えます。（※ ポート番号は 8001 番などにずらしてください。これは、ポート 8000 では HTTP による MEX エンドポイントの公開を行っており、同一のポート番号に異なるプロトコルを割り当てることができないためです。）

なお、netTcpBinding では、既定でトランスポートレベル暗号化と呼ばれる暗号化処理が行われるようになっていますが、これは Windows 統合認証ベースで動作するため、ネットワーク環境によってはうまく動かないことがあります。そこで、今回は簡単のために暗号化を off にすることにします。以下の作業を行ってください。

「バインド」セクションから「新しいバインド構成」を選択し、netTcpBinding の新しい構成設定を追加する。
"Name" プロパティを、"NewBinding0" から適当な名前（例えば "WcfService_NetTcpBinding" などのわかりやすい名前）に変更しておく。

セキュリティタブを開き、セキュリティモードを "Transport" から "None" に変更する。

最後に、「サービス」セクションのエンドポイント構成設定に戻り、今、作成したバインド構成を BindingConfiguration として割り当てる。（この作業も忘れがちなので注意してください。）

以上の作業が済んだら、サーバアプリケーションを起動してください。（※ Windows Firewall にひっかかると思いますので、適宜許可を与えてください。）

見た目は特に変わっていませんが、このサーバは以下の 3 つのプロトコルを受け付けるようになっています。

ポート 8001 番上で、TCP/IP 通信による WCF サービス呼び出しを受け付ける。
（URL は net.tcp://localhost:8001/Sample01.Server/WcfService）
ポート 8000 番上で、HTTP 通信による WSDL ファイルの取り出し要求を受け付ける。（MEX エンドポイント）
（URL は http://localhost:8000/Sample01.Server/WcfService/mex）
ポート 8000 番上で、HTTP 通信によるヘルプファイルの取り出し要求を受け付ける。
（URL は http://localhost:8000/Sample01.Server/WcfService/help）

なお、ポート 8000 番上の MEX エンドポイントは、HTTP 通信による WSDL ファイル取り出し要求を受け付けますが、そこで公開されている情報は TCP/IP 通信を受け付けるエンドポイントの情報であることに注意してください。（実際に WSDL ファイルを見てみるとわかります。）

ご参考までに、ここまでの作業で作成された app.config（サーバ側）を示します。

       1: <?xml version="1.0" encoding="utf-8" ?>

       2: <configuration>

       3:     <system.diagnostics>

       4:         <sources>

       5:             <source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">

       6:                 <listeners>

       7:                     <add type="System.Diagnostics.DefaultTraceListener" name="Default">

       8:                         <filter type="" />

       9:                     </add>

                    <add name="ServiceModelMessageLoggingListener">

                        <filter type="" />

                    </add>

                    <add name="NewListener">

                        <filter type="" />

                    </add>

                </listeners>

            </source>

        </sources>

        <sharedListeners>

            <add initializeData="C:\Users\nakama\Documents\Visual Studio 2008\Projects\Sample01.Server\Sample01.Server\App_messages.svclog"

                type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

                name="ServiceModelMessageLoggingListener" traceOutputOptions="Timestamp">

                <filter type="" />

            </add>

            <add type="System.Diagnostics.ConsoleTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

                name="NewListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack">

                <filter type="" />

            </add>

        </sharedListeners>

    </system.diagnostics>

    <system.serviceModel>

        <bindings>

            <netTcpBinding>

                <binding name="WcfService_NetTcpBinding">

                    <security mode="None" />

                </binding>

            </netTcpBinding>

        </bindings>

        <diagnostics>

            <messageLogging logEntireMessage="true" logMalformedMessages="true"

                logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" />

        </diagnostics>

        <behaviors>

            <serviceBehaviors>

                <behavior name="WcfService_ServiceBehavior">

                    <serviceDebug httpHelpPageUrl="http://localhost:8000/Sample01.Server/WcfService/help"

                        includeExceptionDetailInFaults="false" />

                    <serviceMetadata httpGetEnabled="true" httpGetUrl="http://localhost:8000/Sample01.Server/WcfService/mex" />

                </behavior>

            </serviceBehaviors>

        </behaviors>

        <services>

            <service behaviorConfiguration="WcfService_ServiceBehavior" name="Sample01.Server.WcfService">

                <endpoint address="net.tcp://localhost:8001/Sample01.Server/WcfService"

                    binding="netTcpBinding" bindingConfiguration="WcfService_NetTcpBinding"

                    contract="Sample01.Server.WcfService" />

            </service>

        </services>

    </system.serviceModel>

</configuration>

［Step. 13］ TCP/IP 通信への通信プロトコルの切り替え（クライアント側）

次に、今度はクライアント側を TCP/IP 通信に切り替えます。この作業は簡単で、サーバ側アプリケーションを起動した状態（＝WSDL ファイルを取得可能な状態）にしたままで、Visual Studio のサービス参照を更新するだけです。これにより、サーバ側から最新の WSDL ファイルが入手され、プロキシクラスがリフレッシュされ、TCP/IP 通信による WCF サービス呼び出しを行うことができるようになります。

※ 見た目は何も変わっていませんが、TCP/IP 通信によるサーバ呼び出しが行われています。

なお TCP/IP 通信の場合には、サーバ呼び出しはバイナリエンコード方式（SOAP メッセージが、XML 形式ではなくバイナリ形式にエンコードされる）が利用されています。これについての詳細は Part.1 で解説していますので、そちらを読み返してみてください。

［Step. 14（おまけ）］ HTTP/Binary 通信を利用する方法

最後におまけで、CustomBinding を利用して、バイナリエンコード方式と HTTP 通信を組み合わせる方法についても紹介しておきます。

ASP.NET XML Web サービスや .NET Remoting に関してよく聞く要望の一つに、「HTTP 通信上で、バイナリエンコードされたメッセージ形式が利用できないか？」というものがありました。ASP.NET XML Web サービスは、SOAP over HTTP に最適化されて実装されている、つまりメッセージ形式は XML シリアル化された SOAP メッセージに限定されていたため、この要望にこたえることができませんでしたが、WCF の場合、CustomBinding を利用することで、バイナリエンコードされたメッセージを HTTP プロトコルでやり取りすることができるようになっています。

具体的には、以下のような作業を行います。

新しいバインド構成として、CustomBinding ベースのバインド構成を作成する。
名前を "HttpBinaryBinding" などに変更する。

この画面の下側に現れる「バインド要素の拡張の位置」というのは、これは簡単にいえば WCF パイプラインの内部に含まれるモジュール（これを BindingElement と呼びます）の一覧になります。通常、basicHttpBinding や netTcpBinding などを使う場合には、このモジュールセットは自動的に用意されるのですが、CustomBinding を使うと、この内部構成を自分で決定できるため、バイナリエンコード方式と HTTP プロトコルを組み合わせる、といったことも可能になります。

textMessageEncoding を削除し、binaryMessageEncoding に変更する。
サービスエンドポイントの設定を変更し、Address を http://localhost:8000/Sample01.Server/WcfService に、Binding を CustomBinding に、BindingConfiguration を HttpBinaryBinding （さきほど作成したバインド構成）に変更する。

以上の作業により、サーバ側で HTTP 通信＋バイナリエンコード方式を使った WCF サービスを作成することができたので、あとはクライアント側のサービス参照を更新して使ってみてください。（見た目には変わったことがわかりませんが） HTTP/Binary ベースで通信する WCF サービスが作成できます。（余力のある方はパケットキャプチャなどでみてみるとよいと思います。）

※ 最終的に完成したソリューションは以下になります。

［このエントリのまとめ］

というわけでいろいろ解説してきましたが、WCF を利用すると、以下のようなことが簡単にできるようになります。

サービス参照を作成することで、WCF サービス呼び出しのためのプロキシクラスを簡単に作ることができる。
構成設定ファイルを書きかえることで、比較的簡単にログファイルを出力できる。
サーバ側の構成設定を変更することで、同一通信特性を持つバインディングへの変更が容易にできる。

従来は非常に難しかった、TCP/IP 通信や名前付きパイプ通信を行うサーバアプリケーションも、比較的簡単に開発できることをご理解いただければ幸いです。そして、次回の Part.4 の WCF 最終回では、IIS 上でこの WCF を利用する方法について解説をしたいと思います。

……ふう、というわけで Part 3 書き終わりです。書き終わってから思いましたが、ロギングの話はちょっと余分だったかもしれませんね；。

Part 2. Hello World WCF サーバの開発

nakama — Thu, 25 Sep 2008 08:49:11 GMT

では、前回のエントリに引き続いて、今回は Hello World メッセージを返す WCF サーバの開発を行ってみたいと思います。WCF のランタイムはポータブル（いろんな場所に持っていける）に設計されているのが面白いところで、IIS 上はもちろんのこと、コンソールアプリケーションや Windows サービスなどにも簡単にホストすることができるように設計されています。が、いきなりそれらの話をするも大変なので、まずはコンソールアプリケーションを使って、SOAP over HTTP のリクエストを受け付ける Hello World WCF サーバを開発する、という作業を行ってみたいと思います。

・WCF サービスの作成
・WCF ホストプロセスの作成
・構成設定ファイルの作成
・サービスビヘイビアによる MEX (Metadata Exchange) の作成
・WCF テストツールによる WCF サーバの動作確認

なお、本サンプルでは Visual Studio 2008 に用意されている WCF ライブラリのプロジェクトテンプレートなどは一切使いません。これは以下の理由によります。

テンプレートやウィザードを使ってしまうと何をやってるのかわからくなる。
Application Architecture for .NET などの考え方に基づいて、通信インタフェース（SI）を分離するという設計モデルを取る場合、SI 内部でさらにインタフェースを分離することにはあまり意味がない。

簡単にいえば、WCF ライブラリのプロジェクトテンプレートは、従来の考え方（ビジネスロジックが直接通信機能を持つ）に近い設計モデルに基づいて作られているものだと思います（と自分は解釈している）。なので、ここではあえてプロジェクトテンプレートは利用せずに、WCF サーバを作ってみたいと思います。

※ 以下の作業を Windows Vista や Windows 2008 で行う場合には、Visual Studio 2008 を管理者特権で動作させるようにしてください。VS2008 を管理者特権で動作させるためには、以下の 2 つのファイルのプロパティとして、管理者で動作させる設定を付与してください。

C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe
C:\Program Files (x86)\Common Files\microsoft shared\MSEnv\VSLauncher.exe

［Step. 4］ WCF サービスの作成

まず、Visual Studio 2008 のコンソールアプリケーションプロジェクトを使って、WCF サーバとなるアプリケーションを作成します。ここでは、名前を "Sample01.Server" としておきましょう。

作成されたプロジェクトに対して、以下の作業を行います。

System.ServiceModel.dll ファイルに参照設定をかける。
WcfService.cs クラスファイルを追加し、WCF サービスのコードを記述する。（System.ServiceModel 名前空間に対する using 設定も忘れずに。）

        1: using System;

       2: using System.Collections.Generic;

       3: using System.Linq;

       4: using System.Text;

       5: using System.ServiceModel;

       6:  

       7: namespace Sample01.Server

       8: {

       9:     [ServiceContract]

      10:     public class WcfService

      11:     {

      12:         [OperationContract]

      13:         public string GetMessage(string name)

      14:         {

      15:             return "Hello World, " + name;

      16:         }

      17:     }

      18: }

［Step. 5］ WCF ホストプロセスの作成

以上で WCF サービスの作成（実際に処理を行うクラス）は終わりですが、このサービスを動作させるためには、サービスをホストするためのプロセス（ホストプロセス）が必要になります。このため、コンソールアプリケーションの Program.cs ファイルの Main() 関数に、WCF ランタイム起動のためのコードを記述します。

       1: using System;

       2: using System.Collections.Generic;

       3: using System.Linq;

       4: using System.Text;

       5: using System.ServiceModel;

       6:  

       7: namespace Sample01.Server

       8: {

       9:     class Program

      10:     {

      11:         static void Main(string[] args)

      12:         {

      13:             using (ServiceHost host = new ServiceHost(typeof(WcfService)))

      14:             {

      15:                 host.Open();

      16:                 Console.WriteLine("WCF サーバを起動しました。");

      17:                 Console.ReadLine();

      18:                 host.Close();

      19:             }

      20:         }

      21:     }

      22: }

1 つのサービスホストで起動できる WCF サービス（の実装クラス）は 1 つだけです。ですので、もし WCF サービスの実装クラスが複数ある場合には、以下のように記述します。（ここではコードを見やすくするために try-finally を省略してます）

       1: ServiceHost host1 = new ServiceHost(typeof(WcfService1));

       2: ServiceHost host2 = new ServiceHost(typeof(WcfService2));

       3: host1.Open();

       4: host2.Open();

       5: Console.WriteLine("WCF サーバを起動しました。");

       6: Console.ReadLine();

       7: host1.Close();

       8: host2.Close();

以上で WCF サービスとホストプロセスの作成はおしまいです。ですが、実際に Ctrl + F5 キーでこれを起動してみると、例外が発生して動作しません。これは、サービスホストが WCF パイプライン（エンドポイント、サービス要求を受け付ける受け口）を作成するために必要な構成設定が準備されていないことによるものです。

［Step. 6］構成設定ファイルの作成

プロジェクトに app.config ファイルを追加し、ここに WCF エンドポイントに関する構成設定を記述します。構成設定ファイルは手で書くこともできますが、かなり大変なのでツールを使うことをお勧めします。以下の手順で作業を行ってください。

プロジェクトに app.config ファイルを追加する。
スタートメニュー内の Microsoft Windows SDK v6.0a → Tools 内にある、「サービス構成エディタ」を起動する。
ファイル → 開く → 構成ファイルを選択し、先ほど追加した app.config ファイル（C:\Users\nakama\Documents\Visual Studio 2008\Projects\Sample01.Server\Sample01.Server\app.config）を開く。

これにより、エンドポイントの構成設定ファイルを、ツールを使って書くことができるようになります。

なお、サービス構成エディタツールを毎回、スタートメニューから開くのは大変です。なので、VS2008 上にツールとして登録してしまうと便利です。具体的には以下のようにします。

app.config ファイルを右クリックし、「ファイルを開くアプリケーションの選択」を選ぶ。
ここに SvcConfigEditor.exe をプログラムとして追加して使う。

※ サービス構成エディタは OS や Visual Studio のバージョンによって、インストール先が異なる場合がありますので注意してください。VS2008 の場合には C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\SvcConfigEditor.exe にあります。

ここに、エンドポイントの構成設定情報を書いていきます。一応、ウィザードもあるのですが、ここでは敢えてまず手で指定していってみます。

左側の「構成」ペイン内の「サービス」フォルダを右クリックし、新しいサービスを追加。
サービスの名前として、"Sample01.Server.WcfService" （WCF サービス実装クラスのフルネーム）を指定。

その下側にある「エンドポイント」フォルダから、「新しいサービスエンドポイント」を指定して、エンドポイントを追加する。
このエンドポイントに、Adress, Binding, Contract の 3 つを指定する。（後述）

エンドポイントに指定しなければならない要素は、A/B/C の 3 つです。指定に関しては、以下の点に気をつけてください。

A (Address) について

サーバ側のリスナアドレスを指定します。SOAP over HTTP を使う場合には、http:// ～を指定することになります。
URL のアドレス部分は、一意であれば自由に設定できます。たとえば以下のようなアドレスを指定することができます。
http://localhost:8000/Sample01.Server/WcfService (今回はこれを使いました)
http://localhost:8235/hogehoge (ポート番号ずらしたり、ぜんぜん関係ない名前を使っても OK)
http://localhost:8000/WcfService.wcf (拡張子っぽいものをつけても OK)
http://localhost:8023/Sample01/Server/WcfService (スラッシュなどで区切ってもよい)
http://localhost:9732/WcfService.Server.Sample01 (ピリオドでつないでもよい)
要するに、他の WCF のエンドポイントとアドレスがぶつからなければ何を指定しても OK、ということです。（が、エキセントリックな名前をつけてもあんまり意味がないので今回は一番上にしてきおきました。）
なお、TCP/IP の場合には net.tcp:// ～、名前付きパイプの場合には net.pipe:// ～という名前で URL を指定することになります。

B (Binding) について

いろんな種類の Binding が利用できますが、今回は単純な SOAP over HTTP を使うので、basicHttpBinding を使ってください。
その他の Binding については、Part.1 に簡単に紹介してありますのでそちらをご参照を。Part. 3 でも多少紹介します。

C (Contract) について

[ServiceContract] を付与した I/F を、フルネームで指定します。
今回のサンプルのように、サービス実装クラスに直接 [ServiceContract] 属性を付与している場合には、サービス実装クラスの名前を指定してください。インタフェースを分離して定義している場合には、そちらを指定します。
なお、Contract を指定しなければならないのは、WCF サービス実装クラスが複数の I/F を持っているケースを想定しています。（通常、ひとつの WCF サービス実装クラスが持つ外部公開 I/F は 1 つですが、インタフェースを分離して定義した場合には、ひとつの WCF サービス実装クラスが複数の [ServiceContract] 属性つきインタフェースを継承している場合があります。）

以上が終了したら、ファイルをセーブし、Visual Studio に戻ります。ツールから app.config ファイルが書き出され、今、記述した構成設定が画面上に現われます。

       1: <?xml version="1.0" encoding="utf-8" ?>

       2: <configuration>

       3:     <system.serviceModel>

       4:         <services>

       5:             <service name="Sample01.Server.WcfService">

       6:                 <endpoint address="http://localhost:8000/Sample01.Server/WcfService"

       7:                     binding="basicHttpBinding" contract="Sample01.Server.WcfService" />

       8:             </service>

       9:         </services>

      10:     </system.serviceModel>

      11: </configuration>

この状況でコンソールアプリケーションを実行すると、今度は問題なく WCF サーバが起動します。

この WCF サーバは、http://localhost:8000/Sample01.Server/WcfService というアドレスに対して HTTP で送信した SOAP メッセージを処理できるようになっています。しかし、ASP.NET XML Web サービス（*.asmx）とは異なり、ブラウザなどでこのアドレスを呼び出すことはできません。呼び出してみると、以下のように HTTP 400 エラー（要求形式がおかしい）が発生します。

※ ASP.NET XML Web サービスにおいて、*.asmx ファイルをブラウザから呼び出すことができたのは、これは *.asmx が、SOAP 形式ではないリクエスト（具体的には HTTP-GET や HTTP-POST と呼ばれる方式のリクエスト）を処理できるように作られていたからです。WCF ではこの挙動が厳格になっており、ここまでの設定だけでは、SOAP 形式以外のリクエストを一切処理することができません。

［Step. 7］サービスビヘイビアによる MEX （MetadataExchange）の作成

また、現在のままではもう一つ困るポイントがあります。それは、クライアント側にプロキシクラスを作成することができない、という点です。クライアント側にプロキシクラスを作成するには、

サーバ側で WSDL ファイル（サービスの情報を記載した XML ファイル）を公開しておく。
これをクライアント側に取り込ませて、プロキシクラスを作成する。

という方法がもっとも簡単なのですが、現状のままでは WSDL ファイルが公開されていません。このため、サービスビヘイビアと呼ばれるものを利用して、WSDL ファイルを公開するようにします。

サービスビヘイビアとは、簡単にいえばサーバ（サービスホスト）に追加するプラグイン型のパワーアップモジュールで、このモジュールを追加することで、以下のようなことができるようになります。

WSDL ファイルの自動作成と公開（serviceMetadata サービスビヘイビア）
デバッグ用の情報公開（serviceDebug サービスビヘイビア）
サーバの証明書やユーザのパスワード情報の管理機能（serviceCredentials サービスビヘイビア）

ここでは、serviceMetadata と serviceDebug をサーバに追加して、WCF サーバをパワーアップすることにします。

具体的には以下の作業を行います。

もし WCF サーバアプリケーション（さっきのコンソールアプリケーション）を動作させているのであればこれを停止する。
app.config ファイルを SvcConfigEditor.exe で開く。（すでに開いていればそのまま編集）
「構成」ペイン → 「詳細設定」 → 「サービス動作」 → 「新しいサービス動作の構成」を選択して、サービスビヘイビア定義を作成。
まずサービス動作の名前を変更。（NewBehavior → お好きな名前に。ここでは "WcfService_ServiceBehavior" にしました。）
次に、「動的要素の拡張の位置」のところから「追加」を選択し、serviceDebug と serviceMetadata を追加する。（訳語がもはや意味不明ですが、要するにサービスビヘイビアについて、拡張モジュールを追加して、それを入れる順番を指定してください、という意味です。正直、こういうものは無理に訳さない方がいい気がする．．．．）

次に、各サービスビヘイビアモジュールのプロパティを設定します。

serviceDebug モジュールについては、HttpHelpPageUrl に、ヘルプ情報を出力する URL を指定します。（http://localhost:8000/Sample01.Server/WcfService/help など。）
servceMetadata モジュールについては、HttpGetEnabled を True に変更するとともに、HttpGetUrl に WSDL 情報を入手するための URL を指定します。（http://localhost:8000/Sample01.Server/WcfService/mex など。）

そして、最後に以下の作業を行います。（この作業を忘れがちなので注意してください。）

サービスセクションに戻り、BehaviorConfiguration として、先ほど作成したサービスビヘイビア構成設定を割り当てる。

以上で設定作業はおしまいです。ファイルをセーブしてから WCF サーバを立ち上げなおしてみてください。

見た目は何も変わっていませんが、Web ブラウザを起動し、以下の 2 つの URL を呼び出してみてください。

http://localhost:8000/Sample01.Server/WcfService/help
serviceDebug サービスビヘイビアにより、この URL を呼び出すと、WCF サービスに関するヘルプページが動的に生成されるようになります。
http://localhost:8000/Sample01.Server/WcfService/mex
serviceMetadata サービスビヘイビアにより、この URL を呼び出すと、WCF サービスに関する I/F 仕様情報（WSDL 情報）が動的に生成され、公開されるようになります。

［ヘルプページ］

［WSDL 情報］

［Step. 8］ WCF テストツールによる WCF サーバの動作確認

さて、この状態で WCF サーバの動作確認を行いたいところですが、ASP.NET XML Web サービス（*.asmx）の場合と異なり、WCF では簡単にサーバを呼び出すことができません。これは、WCF がマルチプロトコル対応であるために、サーバを呼び出す方法が一定しないことが大きな要因だろうと思います。

（どうせなら、SOAP over HTTP の場合に限っては、*.asmx と同様にヘルプページからテストも行えるようにしてほしいところなのですが、とつぶやいてみる．．．．まあ贅沢を言っちゃいけないのかもですが。）

この問題に対処するため、Visual Studio 2008 では、WSDL 情報を元にして WCF サーバを呼び出す汎用テストクライアントツール WcfTestClient.exe が用意されました。

具体的には以下のようにして利用します。

まず、WCF サーバを起動しておきます。（※ WCF サーバが起動していないと、WSDL ファイルが入手できないため。）
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\WcfTestClient.exe を起動します。
ファイル → サービスの追加を選択し、エンドポイントアドレスの入力欄に、WSDL ファイルが公開されている URL （ここでは http://localhost:8000/Sample01.Server/WcfService/mex ）を指定します。
※ WcfTestClient.exe の起動時のコマンドライン引数として、WSDL ファイルのアドレスを与えても OK です。

以上の作業により、WCF サービスを呼び出す準備ができるので、あとはメソッドを選択し、パラメータ引数を入力して起動ボタンを押下してください。これにより WCF サービスを呼び出すことができます。

なお、このツールは TCP/IP 通信や名前つきパイプ通信でも利用できます。WSDL ファイルさえ入手できれば、あとはそれを元に動的にテストクライアントを組み上げてくれるツールになっているので、適宜活用するとよいでしょう。（…といっても、実際のアプリケーション開発の場合には、さくっとクライアントアプリを作ってしまった方が手っ取り早いのですが。）

［Step. 9］（おまけ）構成設定ファイルを使わない方法

以上で説明はおしまいですが、最後におまけとして、構成設定ファイルを使わないで WCF サーバを起動する方法について説明しておきます。

実際に自分のアプリケーションで WCF を使おうと思った場合にネックになる大きなポイントの一つに、構成設定データの維持がえらく大変、という点があります。今回のサンプルの場合には、WCF サービスが一つだったので構成設定データを作成するのもラクでしたが、実際の業務アプリケーションでは WCF サービスがたくさん作成されることになるため、構成設定ファイルを作成・メンテするのがとかく面倒になります。こうした場合には、アプリケーションコードでエンドポイントを構成する手段を検討してみてください。

例えば、以下のようなコードを書くと、app.config なしで WCF サービスを起動することができます。

       1: using (ServiceHost host = new ServiceHost(typeof(WcfService)))

       2: {

       3:     // ① エンドポイントの手動構成設定 (C/B/A を指定)

       4:     //   バインディングの構成設定を行いたい場合には、Binding インスタンスのプロパティを設定する

       5:     host.AddServiceEndpoint(typeof(WcfService), new BasicHttpBinding(), 

       6:         "http://localhost:8000/Sample08.Server/WcfService");

       7:     // ② ビヘイビアの手動構成設定

       8:     //   すでにいくつかのビヘイビアは既定で追加されているため、取り払ってから再設定する

       9:     host.Description.Behaviors.Remove(typeof(ServiceDebugBehavior));

      10:     host.Description.Behaviors.Remove(typeof(ServiceMetadataBehavior));

      11:     host.Description.Behaviors.Add(new ServiceDebugBehavior { IncludeExceptionDetailInFaults = true });

      12:     host.Description.Behaviors.Add(new ServiceMetadataBehavior { HttpGetEnabled = true, 

      13:     HttpGetUrl = new Uri("http://localhost:8000/Sample08.Server/WcfService/mex") });

      14:  

      15:     // ホストのオープン

      16:     host.Open();

      17:     Console.WriteLine("WCF サービスを起動しました。");

      18:     Console.ReadLine();

      19:     host.Close();

      20: }

このコードについては詳細には説明しませんが、このようにコードによって構成設定を行う方法もある、というのを知っておくと何かと便利ですので、覚えておいてください。

［ここまでのまとめ］

今回のエントリのキーポイントをまとめると、以下のようになります。

[ServiceContract], [OperationContract] 属性を使って、WCF サービスを作成する。
WCF サービスを動作させるためには、サービスホスト（ServiceHost）の初期化とオープンが必要。
サービスホストを動作させるためには、構成設定ファイルを使ってエンドポイントの構成を指定しておく必要がある。（アプリケーションコードを使ってエンドポイントの構成を行うことも可能）
さらに、サービスビヘイビアを追加することで、ヘルプページや WSDL 情報を作成・公開したりすることができる。

引き続き次回の Part.3 では、この WCF サーバに対するクライアントアプリケーションの作成と、通信プロトコルの差し替えなどを行ってみることにしたいと思います。

Part 1. WCF に導入されている新たな設計概念

nakama — Thu, 18 Sep 2008 15:41:56 GMT

では順番に、WCF について説明していってみようと思います。……が、WCF を理解する上で重要なのは、実装方法というよりも、むしろ WCF がなぜ作られたのかとか、どういう考えやモデルに基づいて作られているか、という点だと思います。そこで、Part 1. では、まず WCF が持っているいくつかのきわめて重要な設計概念についてまとめて説明してみたいと思います。

・WCF の狙い
・エンドポイント（ABC モデル）
・WCF パイプライン（ABC モデル）と OSI 7 階層モデルの関係
・Message オブジェクトとエンコード方式

なお、以下の説明では、ある程度リモート通信に関する基礎知識がある（例えば ASP.NET XML Web サービスを使ったことがある）方を対象として記述しています。もしリモート通信技術を全く触ったことがないという場合には、まず ASP.NET XML Web サービス（*.asmx）などを軽く学習してから本エントリをお読みいただくことをお勧めします。

※ Part 1 は概念的に難しいので、よくわからない．．．という方は、Part 2 以降を読んでから、最後に戻ってきてもう一回読むとよいかと思います。

[Step. 1] WCF の狙い

WCF は、様々な通信プロトコルを、同一のプログラミングモデルの中で取り扱えるようにするための仕組みです。

もともと世の中に多種多様な通信プロトコルが存在するのは、通信プロトコルに求められる要件が、アプリケーションやシステムの特性によって大きく変化するため、ひとつの通信プロトコルでは多種多様な通信に対応できないからです。

信頼性を重視しなければならない場合（一般的な業務システムとか）
付加機能を充実しなければならない場合（トランザクション引き継ぎが必要な業務システムとか）
とにかく性能を重視する必要のある場合（取引システムとかオンラインゲームとか）

このような理由から、世の中には様々な通信プロトコルが存在します（Windows 系に限ってみても、SOAP over HTTP, DCOM, TCP/IP, MSMQ, Service Broker, 名前付きパイプ, etc...）。しかし、一方で次のような問題も存在します。

通信プロトコルごとに、プログラミング方式（API）がまるで違う。
同一の通信特性を持つ通信であっても、簡単に置き換えることができない。

また、最近では WS-* （WS-Security や WS-ReliableMessaging, WS-AtomicTransaction など）といった高付加価値プロトコルも開発されていますが、こうしたプロトコルは従来の通信ミドルウェアの設計ではなかなかスマートに対応させることができません。こうした問題を解決するために設計されたのが WCF です。WCF を利用すると、以下のようなメリットが得られます。

様々な通信プロトコルを扱う際のプログラミングモデルが統合されます。
このため、新しい通信プロトコルを利用したアプリケーションに開発する際の学習コストが低減されます。
WS-* プロトコルへの対応が非常にスマートにできます。
（※ この点は極めて重要です。詳細は後述します。）
同一の通信特性を持つ通信プロトコルであれば、簡単にリプレースできます。
例えば、SOAP over HTTP ベースで開発された WCF のアプリケーションの通信方式を、TCP/IP ベースの通信に簡単に切り替えられます。

例えば一例を挙げると、"Hello World" メッセージを返すサーバアプリケーションを作成する場合、WCF を利用すれば、SOAP over HTTP だろうと TCP/IP だろうと、サーバのサービス実装は全く同じになります。構成設定ファイルを書きかえることにより、通信プロトコルを変更することができます。（※ ここでは単純化して解説しています。具体的な通信プロトコルの置換方法については Part 3. で扱います。）

［WCF サービス実装］

        1: [ServiceContract]

       2: public class WcfService

       3: {

       4:     [OperationContract]

       5:     public string GetMessage(string name)

       6:     {

       7:         return String.Format("Hello World, {0}", name);

       8:     }

       9: }

［SOAP over HTTP の場合の構成設定ファイルの書き方］

       1: <configuration>

       2:     <system.serviceModel>

       3:         <services>

       4:             <service name="Server.WcfService">

       5:                 <endpoint address="http://localhost:8000/Server/WcfService"

       6:                           binding="basicHttpBinding" contract="Server.WcfService" />

       7:             </service>

       8:         </services>

       9:     </system.serviceModel>

      10: </configuration>

［TCP/IP の場合の構成設定ファイルの書き方］

       1: <configuration>

       2:     <system.serviceModel>

       3:         <services>

       4:             <service name="Server.WcfService">

       5:                 <endpoint address="net.tcp://localhost:7000/Server/WcfService"

       6:                           binding="netTcpBinding" contract="Server.WcfService" />

       7:             </service>

       8:         </services>

       9:     </system.serviceModel>

      10: </configuration>

※ 2 つ目のポイントについては結構勘違いしやすいので注意してください。当たり前のことですが、WCF は、通信プロトコルを任意に切り替えられるようにするものではありません。WCF を利用しても通信特性の異なるプロトコルへの切り替えはできません。たとえば、上記の「リクエスト／レスポンス」型のアプリケーションの通信プロトコルを、「一方向」型の通信プロトコルである MSMQ などに切り替えることはできません。

※ なお、WCF サービスを実装する場合、通常は上記のサンプルのように、サーバ側のコードに [ServiceContract], [OperationContract] 属性をつけたコードを記述しますが、昔ながらのリモート通信プログラミングモデルのように、インタフェース定義を分離することもできるようになっています。（下記参照）ただし、業務アプリケーションではこのようにインタフェース定義を分離する必要は通常ないので、本資料ではインタフェース分離しない形でサンプルコードを示していきます。（理由は SI 上にビジネスロジックを実装することはないためなのですが、これはまた別の機会に。）

       1: [ServiceContract]

       2: interface IWcfService {

       3:  

       4:     [OperationContract]

       5:     string GetMessage(string name);

       6:  

       7:     [OperationContract]

       8:     PubsDataSet GetAuthorsDataByState(string state);

       9: }

      10:  

      11: public class WcfServiceImpl : IWcfService {

      12:     public string GetMessage(string name) {

      13:         return "Hello World, " + name;

      14:     }

      15:     public PubsDataSet GetAuthorsDataByState(string state) {

      16:         authorsTableAdapter ta = new authorsTableAdapter();

      17:         PubsDataSet pds = new PubsDataSet();

      18:         ta.FillByState(pds.authors, state);

      19:         return pds;

      20:     }

      21: }

さて WCF では、

サーバ側のサービスを、[ServiceContract] や [OperationContract] の属性をつけた形で記述する。
構成設定ファイルで通信プロトコルを指定する。

という形で実装していくのですが、このような通信プロトコル切り替えを実現する源泉となっているのが、エンドポイントと呼ばれる概念です。

［Step. 2］エンドポイント（ABC モデル）

エンドポイントとは、サーバとクライアントの両側にできる「通信の出入り口」のことで、以下の 3 つの要素から構成されています。

A (Address) : URL （例えば http://server:8000/WcfService など。）
B (Binding) : 通信制御に利用するパイプラインの種類
C (Contract) : SOAP メッセージの仕様（すなわち I/F 仕様）

この A/B/C に関する構成をサーバとクライアントの両方で合致させることにより、適切な通信ができるようになる...と WCF の本には書かれているのですが、最初にこれを読んだときにはぶっちゃけ何のことだかさっっっぱりわかりませんでした；。たぶん、開発者の方々の場合には、以下のようなエンドポイント内部の構造を具体的に示した方がわかりやすいでしょう。

WCF によるクライアントからサーバへの通信は、以下の流れで進みます。

平文 SOAP メッセージの組み立て
プロキシクラスのメソッドを呼び出すと、プロキシクラスは平文の SOAP メッセージを組み立てます。
クライアント側エンドポイントによるパイプライン処理
クライアント側エンドポイントによって、平文の SOAP メッセージに対する適切な加工処理（認証情報付与やデータ暗号化など）が行われます。
サーバ側リスナへのデータ送信
例えば WS-Security を使っている場合には、クライアント側のエンドポイントパイプラインにより加工された（すなわち暗号化された）SOAP メッセージが、通信チャネル経由で送信されることになります。
サーバ側エンドポイントによるパイプライン処理
2. の逆の処理（解読・復元処理）が行われます。
サービス実装クラスへのディスパッチ
平文となった SOAP メッセージを元に、実際のサービスが呼び出されて処理されます。

そしてサーバ側で処理された結果については、逆の流れをたどってクライアントに届けられます。このように、WCF サービスを正しく動作させるためには、構成設定ファイル（前掲）でこの A/B/C を正しく設定しなければならないのですが、上図から、A/B/C が具体的に何に紐づいているのかがわかると思います。

A (Address) : リスナまたはトランスポートの種類およびその URL
B (Binding) : SOAP メッセージに対する前加工・後加工処理を施すためのパイプラインの種類
C (Contract) : SOAP メッセージの仕様

そして、WCF のマルチプロトコル対応は、この Binding （及びその下側にある A）の取り換えによって実現されています。例えば、Step 1. で示した SOAP over HTTP 及び TCP/IP 通信の切り換えの例の場合は、Binding を basicHttpBinding から netTcpBinding に切り替えていますが、これは下図のように、WCF パイプラインを入れ替えることに相当します。

つまり、端的にいえば、

Binding の変更 = WCF パイプラインの交換 = 通信ランタイムの全とっかえ

を意味します。（このためバインディングを変更すると、通信特性や利用可能な機能がまるごと変わる）これが、同一のプログラミングモデルで異なる通信プロトコルを取り扱うことができる仕組みの源泉になっています。

※ 繰り返しになりますが、通信特性の異なる Binding へ取り替えても、アプリケーションは動作しない（するはずがない）ので注意が必要です。

なお、WCF には様々な Binding が用意されていますが、まず真っ先に覚えるべき Binding は以下の 4 つです。（覚えてしまうことを推奨）

［Step. 3］ WCF パイプライン（ABC モデル）と OSI 7 階層モデルの関係

さて、上で「Binding の変更は、通信ランタイムの全とっかえに相当する」と書いたのですが、そもそもそんなことが許されていいのか？！ ……という人も多いと思います（私もそう思います；）。ですが、この ABC モデルこそが WCF の設計上の一番の肝であり、さらにこれが実は OSI 7 階層モデルの上に WCF 3 階層モデルとでも呼ぶべき新しい階層をもたらすものである、ということに気づくと、WCF の設計の見事さがわかってくると思います。

※ WCF 3 階層モデルというのは nakama が勝手に呼んでるものなので、正しいかどうかはわかりませんが、私はこういうふうに理解しました。

この WCF 3 階層モデル（nakama 命名）を説明する前に、まず SOAP と WS-* の仕様の関係を改めて復習してみたいと思います。

ご存じのとおり、SOAP (Simple Object Access Protocol) は、XML 形式にエンコードされた、リモートメソッド呼び出し要求のためのメッセージです。

SOAP メッセージは通信プロトコルとは独立して設計されているのが大きな特徴でした（つまり、この SOAP メッセージは HTTP 通信、TCP/IP 通信、極端なことを言えばメールの添付ファイルとしてサーバに送りつけることも可能）。従来の様々な RPC （リモートメソッド呼び出し）技術は、通信プロトコルと一体化して設計されてきたわけですが、SOAP はこの前提を覆し、メッセージと通信プロトコルを分離し、「通信プロトコルにはお好きなものを使ってね」というスタンスを取った、というのが大きな特徴でした。

でもって、SOAP メッセージを HTTP 通信で運んだり（SOAP over HTTP）、TCP/IP 通信で運んだり（SOAP over TCP/IP）している分にはたいして問題がなかったのですが、しばらくすると、この SOAP メッセージに WS-* と呼ばれる様々な拡張機能が登場します。代表格が WS-Security で、これは SOAP メッセージを暗号化するための仕様でした。（雰囲気つかむために SOAP メッセージが暗号化された様子を下に示します。詳細は理解しなくてよいです。）

ところがここで「？？？」となってしまう疑問が生じます。それは、レイヤの逆転現象です。例えば、HTTPS という通信プロトコルを OSI 7 階層モデルに基づいて考えた場合、レイヤの重なり方は

アプリケーション層（HTTP）
暗号化処理を行う層（SSL）
通信制御を行う層（TCP/IP）

となっているのですが、WS-Security を使った SOAP メッセージを HTTP で搬送する場合、

WS-Security による暗号化処理
SOAP メッセージ
HTTP 通信
SSL
TCP/IP

という形のスタックになっている、つまり HTTP 通信というアプリケーション層の上に、改めて暗号処理を行うレイヤを積み上げている形になってしまっています。設計上の是非はともかく、WS-Security をはじめとした WS-* の仕様を見たときに、

「これって SOAP 上にもう一度プロトコルを全部作り直してるってこと？？」

という疑問を抱いたのは（きっと）私だけではないと思います（というか思いたい...）が、通信プロトコル中立性を保ちながら、その上でメッセージを暗号化したりするためには、確かにこうした仕様は必要になります。

ところがここで新たに問題になるのは、では通信インフラを WS-Security などに対応させようと思った場合に、どのような形で対応させればよいのか？（誰がどこで WS-Security の暗号化や復号処理を行うのが設計上スマートなのか？）という点です。例えば、ASP.NET XML Web サービスは、ASP.NET ランタイムが持つ HTTP パイプライン上で動作していますが、その動作モデルは下図のように描くことができます。

ASP.NET ランタイムの HTTP パイプラインは、文字通り HTTP 通信に紐づいた形で設計され、HTTP プロトコルを意識しながら動作するものです。もちろんこのパイプラインの中で SOAP メッセージの暗号化や復号処理を行うようなモジュールを作ることもできるでしょうが、それでは SOAP 及び WS-* が持つ基本設計概念である、通信プロトコル独立性に反します。

そこで現れたのが、WCF の ABC 3 階層モデル（nakama 命名（しつこい；））です。

このように描くとわかりやすいのですが、要するに A/B/C とは、OSI 7 階層モデルの上に、SOAP 及び WS-* 仕様に基づく制御レイヤを導入しようというものです。このレイヤが導入されることにより、クライアントコードや WCF サービスのコードは、以下のようなメリットを享受することができるようになります。

WS-* 関連の制御から解放される。（WS-* の制御を抽象化できる）
通信プロトコルから独立したメッセージのやり取りが可能になる。

このうち前者は極めて重要な点で、WS-* を利用する際には、Binding レイヤで複数回のパケット（SOAP メッセージ）の交換が自動的に行われることがあります。もうちょっと突っ込んで説明するため、例えば、HTTPS （HTTP over SSL）と、WS-Security の 2 つを比較してみます。まず、HTTPS を考えてみてください。

一般的に、HTTPS によるサーバとの通信は、アプリケーションレベルからみると「単発のリクエスト／レスポンス」に見えます。
しかし実は TCP/IP レベルでは、SSL セッション鍵の交換のために、サーバ／クライアント間で複数回のパケット交換（ネゴシエーション処理）が行われています。

つまり HTTPS では、SSL セッションを張るために複数回のパケット交換が行われているものの、アプリケーションレベルではこのパケット交換を意識しなくて済むようになっている、ということになります。

実は WS-Security でも、Binding レイヤにより同様のことが行われます。つまり、

クライアントコードから Binding （WCF パイプライン）に SOAP の平文メッセージを投入します。
WCF パイプラインでは WS-Security の暗号化に必要なセッション鍵を入手するため、サーバ側の WCF パイプラインとの間で、SOAP メッセージを何度か交換します。（WS-SecureConversation プロトコルによるメッセージ交換が行われる）
セッション鍵が交換されると、実際の SOAP メッセージが暗号化されてサーバに送信されます。

という挙動が行われます。見掛け上、クライアントコードからプロキシクラスの呼び出しが一度であっても、実は HTTP 通信レベルでみると、複数回の SOAP メッセージのやり取りが行われていることがある、ということになります。しかし、WCF の Binding レイヤがこれを抽象化してくれているため、アプリケーションレベルではこのネゴシエーションのためのパケット（SOAP メッセージ）交換を意識しなくて済むようになっている、ということになります。

以上を踏まえれば、WCF のエンドポイントの ABC モデルとは、OSI 7 階層モデルの上に、SOAP 及び WS-* による 3 階層の抽象化レイヤを作るものである、と説明できるのではないかと思います。（← という説明がたぶん最も的確じゃないかと思うんですが、こういう説明がなされている資料を見たことがない．．．．）

[Step. 4] Message オブジェクトとエンコード方式

さて、上記において、WCF パイプラインが SOAP 及び WS-* の制御を抽象化してくれるものである、という説明をしたのですが、この動作は、HTTP 通信だけでなく、すべての通信プロトコルにおいて共通の挙動になります。つまり、

WCF では、TCP/IP 通信だろうと名前付きパイプ通信だろうと、必ずSOAP が使われる。
ただし、通信チャネル（トランスポート）によっては、SOAP メッセージが XML 形式以外にエンコードされることがある。

という挙動をします。このことを、HTTP 通信を使う場合と、TCP/IP 通信を使う場合とで比較しながら説明します。

上図では、HTTP 通信を使うために basicHttpBinding パイプラインを、TCP/IP 通信を使うために netTcpBinding パイプラインを使っていますが、どちらの場合であっても、

パイプラインを通過するデータは、SOAP メッセージ。（正確には、SOAP メッセージのオブジェクト形式である System.ServiceModel.Channels.Message オブジェクト）
データを暗号化する場合には、どちらの場合でも WS-Security 仕様に基づく暗号化処理が行われる。

となります。しかし、トランスポートレイヤでは、

basicHttpBinding を使った場合には、SOAP メッセージ（のオブジェクト形式である Message オブジェクト）が、XML 形式にエンコードされて転送される。
netTcpBinding を使った場合には、SOAP メッセージ（のオブジェクト形式である Message オブジェクト）が、バイナリ形式にエンコードされて転送される。

となり、TCP/IP 通信を使う場合にはバイナリフォーマットでのデータ転送が行われることになります。ちなみにご参考までに、Message オブジェクトが XML 形式にエンコードされた場合と、バイナリ形式にエンコードされた場合を以下に示します。バイナリ形式のデータをよく見ると、タグではなく "." 区切りでデータがエンコードされていることがわかります。

［XML 形式にエンコードされた Message オブジェクト］

［バイナリ形式にエンコードされた Message オブジェクト］

つまり、TCP/IP 通信（netTcpBinding）を使った場合には、バイナリエンコード＋TCP/IP 通信によるデータ転送が行われるのですが、そこで運ばれているデータは SOAP データそのものです。

※ WCF の開発チームによると、RPC におけるリモート呼び出しデータを持つときに最も優れたフォーマットを追及したら、結局 SOAP と同じデータ項目になったため、WCF パイプラインを通す「RPC 呼び出しデータ」の構造として、SOAP XML データのオブジェクト表現を使うことにしたそうです。

そして、WCF ランタイムでは、リモートのサービス呼び出しの際のメッセージデータ構造として SOAP データを使っているが故に、WS-* 仕様を、すべての通信プロトコルに対して使うことができるようになっています。例えば、

SOAP over HTTP 通信において、通信データを暗号化したい場合には、WS-Security を使うことができます。
ですが、TCP/IP 通信においても、通信データを暗号化したい場合には、WS-Security を使うことができます。
（※ ワイヤを流れるデータはちゃんとバイナリエンコードされることに注意。WS-Security により暗号化された Message オブジェクトが、バイナリエンコードされてワイヤに流れる形になります。）

もちろん、実質的に WS-* 仕様を使う必要・意味がないケースもあります。例えば、名前付きパイプ通信はもともと信頼性のある通信であるため、WS-ReliableMessaging 仕様を適用しても意味がないがありません（このため、netNamedPipeBinding では WS-ReliableMessaging 仕様は使えないようになっています）。ですが、考え方としては、Binding パイプラインが基本的に通信プロトコルに対して中立である、というのが非常に興味深い設計であるといえるでしょう。

※ なお、上記のように、WS-* と通信プロトコルの間には組み合わせ上の適否があるため、組み込みの Binding では利用できる WS-* やエンコード方式に制限が加わっていることがほとんどです。ですが、CustomBinding を使って自分でパイプラインを組み立てると、ある程度はこの組み合わせを自由にすることができます。（例えば、HTTP 通信でバイナリエンコードをしたい場合には、CustomBinding を利用し、httpTransportChannel と binaryEncodingChannel を組み合わせる、など。）

［ここまでのまとめ］

というわけで、とんでもなく説明が長くなりましたが、ここまでの解説をまとめると以下のようになります。

WCF を使うと、様々な通信プロトコルに対して、似たようなプログラミングモデルでの開発を行うことができるようになる。
WCF を使うと、同一の通信特性を持つ別の通信プロトコルへの切り替えが簡単にできるようになる。
WCF では、OSI 7 階層モデルの上に、WS-* などの処理を行うための 3 階層モデルを構築している。これにより、通信プロトコルや WS-* などの付加処理が高度に抽象化されている。
WCF では、すべての通信手法において、リモート呼び出しのデータが SOAP メッセージ（のオブジェクト表現である Message オブジェクト）として管理される。

次回の Part 2. では、実際に WCF のサーバアプリケーションを開発してみていくことにしたいと思います。

……と、概念ばっかり説明してるとわかりにくいですよね；。これだけだとわからない方も多いと思いますが、Part 2 以降で徐々にわかっていただけると思いますので、しばらくお付き合いいただけると幸いです。