消息交換是WCF進行通信的唯一手段，通過方法調用（Method Call）形式體現的服務訪問需要轉化成具體的消息，並通過相應的編碼（Encodin

在上篇中大體上圍繞著Message的兩個話題進行講述：消息版本（Message Version）和采用五種不同的方式創建Message。本篇文章將

《WCF技術剖析（卷1）》自出版近20天以來，得到了園子裡的朋友和廣大WCF愛好者的一致好評，並被卓越網計算機書店作為首頁推薦，在這裡對大家的支持

在本篇文章中，我們將討論WCF四大契約（服務契約、數據契約、消息契約和錯誤契約）之一的消息契約（Message Contract）。服務契約關注於

消息作為WCF進行通信的唯一媒介，最終需要通過寫入傳輸層進行傳遞。而對消息進行傳輸的一個前提或者是一項必不可少的工作是對消息進行相應的編碼。WCF

通過上篇的介紹，我們知道了WCF所有與編碼與解碼相關的功能都實現在相應的System.Xml.XmlDictionaryWriter和System

任何一個程序都需要運行於一個確定的進程中，進程是一個容器，其中包含程序實例運行所需的資源。同理，一個WCF服務的監聽與執行同樣需要通過一個進程來承

由於WCF采用.NET托管語言（C#和NET）作為其主要的編程語言，注定以了基於WCF的編程方式不可能很復雜。同時，WCF設計的一個目的就是提供基

通過WCF基本的異常處理模式[上篇]， 我們知道了：在默認的情況下，服務端在執行某個服務操作時拋出的異常（在這裡指非FaultException異

從FaultContractAttribute的定義我們可以看出，該特性可以在同一個目標對象上面多次應用（AllowMultiple = true

對於上一篇文章 （WCF基本異常處理模式：[上篇]、[中篇]、[下篇]）,主要是站在最終開發者的角度對WCF關於異常處理編程模式進行了介紹,接下來

在[上篇]中，我們分別站在消息交換和編程的角度介紹了SOAP Fault和FaultException異常。在服務執行過程中，我們手工拋出Faul

WCF客戶端和服務端的框架體系相互協作，使得開發人員可以按照我們熟悉的方式進行異常的處理：在服務操作執行過程中拋出異常（FaultExceptio

服務調用的目的體現在對某項服務功能的消費上，而功能的實現又定義在相應的服務類型中。不論WCF服務端框架處理服務調用請求的流程有多麼復雜，最終都落實

在[第1篇]中，我們介紹了WCF關於實例管理一些基本的知識點，包括InstanceContext、InstanceContextMode、已經如何

在[第2篇]中，我們深入剖析了單調（PerCall）模式下WCF對服務實例生命周期的控制，現在我們來討輪另一種極端的服務實例上下文模式：單例（Si

服務端只有拋出FaultException異常才能被正常地序列化成Fault消息，並實現向客戶端傳播。對於一般的異常（比如執行Divide操作拋出

元數據實際上是服務終結點的描述，終結點由地址（Address）、綁定（Binding）和契約（Contract）經典的ABC三要素組成。認真閱讀過

在[WS標准篇]中我花了很大的篇幅介紹了WS-MEX以及與它相關的WS規范：WS-Policy、WS-Transfer和WSDL，因為WCF元數據

元數據的導出就是實現從ServiceEndpoint對象向MetadataSet對象轉換的過程，在WCF元數據框架體系中，元數據的導出工作由Met