自從WCF 問世以來， WCF服務的配置一直是廣大開發人員所關心的話題。由於WCF作爲一個通用服務框架，擁有大量的拓展點，您有時會覺得配置文件過於複雜。在WCF 4.0中，根據各方面收集的用戶反饋，WCF團隊對WCF的配置做了大量的簡化工作，以方便您更快更好的配置WCF服務。下面會給大家主要介紹以下幾點：
-
缺省服務配置
-
標準終結點(Standard Endpoint)
-
簡化的IIS/ASP.NET中的部署
1. 缺省服務配置
我們都知道，在WCF3.0或3.5中，對每一個服務我們都必須要詳細地定義地址，綁定(binding)，契約(contract)，行爲(behavior)等一系列的配置，缺一不可。而在WCF4.0中，配置文件中增加了許多缺省選項：從終結點，到綁定，各種行爲，都可以被省略。下面是一個簡單的WCF服務，運行這個服務甚至不需要配置文件：
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
using (ServiceHost host = new ServiceHost(typeof(Service1),
new Uri("http://localhost/Service1")))
{
host.Open();
ServiceEndpoint endpoint = host.Description.Endpoints[0];
Console.WriteLine("Address: {0}\nBinding: {1}", endpoint.Address, endpoint.Binding);
Console.ReadLine();
}
}
}
[ServiceContract]
class Service1
{
[OperationContract]
public void DoWork()
{
}
}
}
運行這個程序結果如下所示：
可以看到，雖然我們在程序中並沒有添加終結點，也沒有指定綁定，但WCF還是智能地爲我們做了這兩項配置，那WCF是通過怎樣的機制來做這項設定的呢？
1.1. 缺省的終結點和綁定
事實上，WCF4.0框架會自動檢測當前將要運行的服務的終結點個數。根據用戶反饋，不少程序員會忘記往當前服務中添加終結點，結果自然是在服務運行的時候跳出錯誤。在4.0中，如果您指定了服務類型和服務的基本地址，WCF會用這個地址爲您自動添加一個終結點。
我們同時可以看到，WCF爲這個服務自動選定了BasicHttpBinding。是的，WCF會根據當前URI地址的前綴（在這裏是http://），自動挑選對應的缺省綁定。下面是幾個常見前綴的默認綁定表：
|
前綴 |
綁定 |
|
Http |
BasicHttpBinding |
|
Net.tcp |
NetTcpBinding |
|
Net.Pipe |
NetNamedPipeBinding |
值得注意的是，如果您爲您的服務添加了���個不同的基本地址，WCF會爲這兩個地址分別添加一個終結點。如果這兩個終結點地址的前綴不同的話，您就會自動擁有了兩個不同綁定的終結點。
如果您希望改動這裏的缺省綁定對應，比如，希望用WsHttpBinding來作爲Http前綴的缺省綁定，您只需要在配置文件中添加如下語句：
<system.serviceModel>
<protocolMapping>
<addscheme="http"binding="wsHttpBinding"/>
</protocolMapping>
</system.serviceModel>
如果您熟悉WCF ABC (Address，Binding，Contract)話一定會還有一個小疑問：那這邊的契約是怎麼定義的呢？相信大家一定能夠想到，如果當前服務實現了多個WCF 服務接口，WCF會爲每一個接口創建一個新的終結點。這邊這些終結點會共用一個服務地址和綁定。由於彼此契約不同，這樣的行爲並不會引起任何衝突。
1.2. 默認的綁定/行爲設定
在WCF3.0或3.5中，您需要爲您的每一個綁定或者行爲取一個名字，然後您的每個終結點需要指定某個定義好的綁定或行爲來進行應用。可以想象，當您有幾十個甚至幾百個服務同時應用相同的綁定或行爲的時候，指定這些名字將成爲單純的體力勞動。爲了避免這樣的情況，WCF4.0 引入了默認綁定/行爲的設定。下面是一個默認綁定的例子：
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding>
<securitymode ="Message">
<messageclientCredentialType="UserName"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
</system.serviceModel>
請注意這邊我們在定義綁定的時候並沒有給這個綁定取名字！在WCF 3.0或3.5版本中是不合法的，但在4.0中，這樣的行爲表示默認設定。也就是說在當前配置文件中其他用到WsHttpBinding的服務，如果沒有指定對應的綁定，那麼就會自動採用這個默認綁定，即擁有采用用戶名密碼認證模式的消息級安全設定。這樣的設定方式無疑能夠大大的簡化程序員的工作量。
WCF的默認行爲設定和默認綁定設定的方式類似。同樣，如果您在定義完您的服務級行爲或者終結點級行爲後不特別取一個名字，那麼這個行爲就能夠直接爲您所有沒指定行爲的服務或終結點所採用。
2. 標準終結點
在WCF 3.0或3.5中，爲了能夠暴露一個元數據端口(metadata endpoint)，您也許常常需要採用如下的方式定義端口：
<endpointaddress="mex"binding="mexHttpBinding"contract="IMetadataExchange"/>
您會發現對於每個服務，元數據端口的設置其實基本上都是一致的，每次重複寫同樣的設定其實是沒有必要的。因此在WCF 4.0中，我們將一些常用的終結點規範化，引入了一個“標準終結點”的概念。下面就是一個元數據端口的標準終結點的用法：
<endpointaddress="mex"kind="mexEndpoint"/>
這裏用新關鍵詞“kind”直接指定了這個標準終結點的類型。可以看到這樣的寫法會爲您省下不少工作，同時也減少了出錯的可能。另外，和普通的終結點一樣，您始終可以在配置文件中對標準終結點的各項設定做出您自己的修改。
下面是WCF4.0 中設定的標準終結點的列表，供您參考：
|
標準終結點的名字 |
描述 |
|
mexEndpoint |
元數據終結點。採用IMetadataExchange 作爲服務接口，mexHttpBinding 作爲默認綁定。地址設定默認爲空。 |
|
dynamicEndpoint |
WCF 4.0中新引入的支持服務地址動態尋找的(WS-Discovery)客戶端標準終結點。這個標準終結點不需要指定服務地址。當這個終結點第一次被調用時，它會自動根據當前指定的綁定和契約尋找符合要求的服務，並自動返回結果。 |
|
discoveryEndpoint |
WCF 4.0中新引入的支持WS-Discovery的服務端標準終結點。使用這個終結點時用戶需要指定綁定和契約。 |
|
udpDiscoveryEndpoint |
WCF 4.0中新引入的支持WS-Discovery的服務端標準終結點。它主要支持基於UDP的服務發現機制。 |
|
announcementEndpoint |
WCF 4.0中爲了實現WS-Discovery標準中服務宣告功能而新引入的服務端標準終結點。 |
|
udpAnnouncementEndpoint |
WCF 4.0中爲了實現WS-Discovery標準中服務宣告功能而新引入的服務端標準終結點。它主要支持基於UDP的服務發現機制。 |
|
workflowControlEndpoint |
爲了工作流進程控制而設計的標準終結點，支持創建，運行，掛起，終結工作流等操作。 |
|
webHttpEndpoint |
爲了REST服務而設計的標準終結點。它默認採用WebHttpBinding和WebHttpBehavior。 |
|
webScriptEndpoint |
爲了Ajax服務而設計的標準終結點。它默認採用WebHttpBinding和WebScriptEnablingBehavior。 |
3. 簡化的IIS/ASP.NET中的部署
WCF 4.0針對用戶在IIS中的部署做了很多簡化工作。如果您曾經在WCF 3.5中爲ASP.NET項目添加一個WCF服務，那麼先想象一下那時候您需要做的所有操作，然後看一下下面的添加一個WCF 4.0服務的例子：
Service1.svc:
<%@ ServiceHost Language="C#" Debug="true" Service="WcfService1.Service1" %>
namespace WcfService1
{
using System.ServiceModel;
[ServiceContract]
public class Service1
{
[OperationContract]
public void DoWork()
{
}
}
}
如果您自己創建了一個ASP.NET項目並且添加了上述服務文件，您會發現：
- 您不再需要單獨創建一個接口作爲服務的契約了。
- 您可以直接把您的服務內容寫在.svc文件裏面，這樣可以直接省下一個.svc.cs(或.vb)文件。
- 您甚至不需要改動Web.Config就能夠使得這個服務自動運行。如果您的Web.Config中添加了支持元數據的默認行爲，您的服務不需要任何額外設置就擁有了元數據服務支持。
如果您不喜歡用.svc文件而傾向於用.cs或者.vb文件來描述您的服務，您可以反其道而行之，在您的Web.Config文件中添加如下描述：
<system.serviceModel>
<serviceHostingEnvironment>
<serviceActivations>
<addrelativeAddress="Service1.svc"service="WcfService1.Service1"/>
</serviceActivations>
</serviceHostingEnvironment>
</system.serviceModel>
您可以在這一段中添加所有您的服務描述，在捨棄您所有冗餘的.svc文件的同時，也使得您的所有服務有了一個統一的描述地點，管理起來更加方便，可謂一舉兩得。
是的，一切就那麼簡單！
4. 小結
以上爲大家簡單介紹了一下WCF 4.0中關於簡化的配置的新特性。希望這些工作能夠爲您節省更多的時間，做出更好的產品。也希望能夠得到您更多關於我們產品的反饋，以便於我們在下一個版本中做出更多的改進和優化。謝謝！
http://blogs.msdn.com/b/wcftoolsteamblogcn/archive/2010/06/04/wcf-4-0.aspx