Part 4. IIS ホストの使い方

[アーティクル]
10/08/2008

さて、前回の 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: {

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

   11:     {

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

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

   14:         ServiceMetadataBehavior svb1 = new ServiceMetadataBehavior();

   15:         svb1.HttpGetEnabled = true;

   16:         host.Description.Behaviors.Add(svb1);

   17:         return host;

   18:     }

   19: }

20:

   21: [ServiceContract]

   22: public class WcfService

   23: {

   24:     [OperationContract]

   25:     public string GetMessage(string name)

   26:     {

   27:         return "Hello World, " + name;

   28:     }

   29: }

30:

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

［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 番上で公開されているので、https://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" を、適切なアドレスに書き換えます。（例： https://localhost:1208/WebSite1/WcfService.svc → https://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">

   10:                     <security mode="None" />

   11:                 </binding>

   12:             </netTcpBinding>

   13:         </bindings>

   14:         <behaviors>

   15:             <serviceBehaviors>

   16:                 <behavior name="NewBehavior">

   17:                     <serviceDebug />

   18:                     <serviceMetadata httpGetEnabled="true" />

   19:                 </behavior>

   20:             </serviceBehaviors>

   21:         </behaviors>

   22:         <services>

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

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

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

   26:                     contract="WcfService" />

   27:             </service>

   28:         </services>

   29:     </system.serviceModel>

   30: </configuration>

以上のことを行ったら、ファイルをセーブし、ヘルプページ（https://localhost/WebSite1/WcfService.svc）と WSDL 情報（https://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 の説明などが異様に長いですね。無理もないのですが。

Comments

Anonymous
October 14, 2008
MSDNマガジンの10月号にWCFに承認機能を実装する話が載っています。 WCF ベースのサービスでの承認ちょっと視点を変えて、ASP.NETのForm認証に基づいてWCFの承認を行う場合は以下の記事を参考にしたほうが実装が簡単そうです。...
Anonymous
January 17, 2009
さて、前回までの解説で、.NETアプリケーションにおける一般的な例外の取り扱い型の基本を学習してきました。キーポイントをまとめると、以下の通りです。例外は、アプリケーションエラーやシステムエラーの場合に限り、利用する。

次の方法で共有

Part 4. IIS ホストの使い方

Comments

その他のリソース