《WCF技術內幕》翻譯5：第1部分_第1章_藍月亮:WCF介紹和本章小結

WCF介紹
   在上世紀90年代微軟和其他公司看到了互聯的普遍需求和麵向服務的普遍概念。那時，還沒有被普遍接受的訊息標準，結果，就沒有平臺、應用程式程式設計介面API、或者能夠讓開發者輕易建立面向服務的應用系統的執行時環境。技術上說，是可以建立面向服務的應用，但是開發工具和執行時環境的功能使得這一切看來相當困難。幸運的是，微軟和其他廠商開始定義一個可以產生統一訊息結構的基礎架構。最終努力的結果就是WS-*規範。於此同時，微軟也在制定可以給開發者提供他們開發支援WS-*規範的面向服務應用的開發工具和執行時環境的技術計劃。在這個指導性計劃中包含Microsoft .NET Framework、ASP.NET Web Services (ASMX)、Web Services Enhancements (WSE)、Windows Vista、當然也有WCF. 
不僅僅是另一個API
    隨著時間的推移，開發社群可以看到很多新的APIs,每個都許諾各種新的完美的功能。常常是這些新的API用來包裝這些新的功能。結果，你也許本能上認為WCF只是另外一個API。地址這些誘惑。Jackie Gleason在電影《熊和強盜》中說的很好（我一直最喜歡的電影之一）：“夥計，…不要這麼幹，再考慮一下，但是你不要做。”WCF不僅僅是包裝了現有的功能或者另外一個很棒的API。WCF是在分散式開發領域裡技術轉移的一個證據。微軟花費巨資在這個上面就是因為它可以建立真正的SOA應用，並且提供在微軟平臺上建立應用的更好方式。IBM, BEA, SAP和其它廠商已經做了相似的努力，各個被連線不同平臺上應用系統的動力所鼓舞。
WCF總覽

    WCF是建立在Microsoft .NET Framework上型別的集合，並且存在於微軟Windows作業系統上，在面向服務的世界和麵向物件的世界裡起著橋樑的作用。通常來說，與物件協作比在物件導向的世界裡執行會更高效而且較低的錯誤，即便當這些物件傳送、接受和處理物件導向的訊息的時候。WCF給了我們可以在不同世界裡工作的能力，但是它目標的是讓我們可以在面向服務的世界裡使用大家熟悉的東西程式設計。
WCF下層：Windows
    分散式應用需要頻繁的跨程式辯解通訊。分散式應用同樣需要託管，結果，他們需要依賴像Windows啟用服務（WAS），Internet資訊服務（ IIS），Windows NT服務。像XP帶有Service Pack 2，Windows Server 2003 還有Vista都是允許應用系統互連的作業系統的一部分典型例子。

這些內建支援服務的作業系統，機器本身，都是重要的分散式計算的一部分。

    最低層次上，WCF應用程式通過作業系統的I/O機制(sockets, named pipes, 等等)傳送和接受訊息。但是抽象的公共層使得WCF開發者已經遠離了底層複雜的實現細節。
有用的產品：Windows 伺服器系統

    Microsoft has many products that automate and simplify the tasks associated with distributed computing:

微軟有很多產品可以自動完成和簡化分散式計算的任務。

      1.BizTalk Server

      2.Commerce Server

      3.Application Center

　　4.Internet Security and Acceleration Server

　　5.SQL Server

　　6.Exchange Server

　　7.Host Integration Server

     隨著時間的前移，我希望看到這些產品在某些方面能夠使用WCF通訊（備註：Biztalk已經提供了不同Binding的WCF Adapter）。

將來，希望可以看到WCF應用可以直接與這些服務通訊。例如，能夠支援從WCF應用到SQL Server 2005的事務Broker的協調。
開發平臺：Microsoft .NET Framework

自2002年，Microsoft .NET Framework已經是Windows開發的一個選擇。它由4個重要機制：自動記憶體管理，JIT編譯，後設資料和程式碼訪問安全。這些重要機制可以提供快速的元件開發，型別安全的執行環境，多語言的選擇，簡化開發場景和元件安全。（我可以繼續）WCF是建立在.NET Framework之上，完全由C#編寫的。

.NET Framework通過System.Net.Sockets.Socket和System.Messaging.MessageQueue型別 (這裡提到一些)抽象了作業系統的IO機制。這些型別會被WCF的基礎框架用來傳送和接受訊息。正如你將會再本書的後面看到內容，這些都可以通過WCF的擴充套件點與這些型別直接互動。
分散式平臺：WCF

WCF是微軟建立獨立於版本的，安全的，可靠的，支援事務的面向服務的API。它完全包含面向服務的概念，並且可以建立符合WS-*規範的訊息，但它同樣可以使用在表屬性狀態傳輸（Rest）架構裡和其它的使用樸素的舊的（POX）XML訊息的分散式應用系統中。本質上，WCF是開發者通往面向服務世界的橋樑。在WCF之前，也可以使用像WSE和ASMX這樣的技術來編寫面向服務的應用，但是WCF比微軟其它的面向服務的技術提供了更好的安全性，可靠性，靈活性，並且效能選擇。換句話說，WCF滿足了互聯的普遍需求，因此，世界因此而不同（月亮是藍色的）。
整合到一起

圖1-3 說明了Windows，.NET Framework, WCF, 和 WCF應用程式如何在概念上組織在一起的

圖1-3 上下文裡的WCF

    在概念上和邏輯上，WCF是能使得開發者可以快速開發面向服務應用的程式集的集合。使用WCF的應用系統可以通過訊息schema和WS-*裡定義的編排、REST 架構、POX訊息來通訊。WCF使得開發者遠離許多原始通訊和 WS-*規範的細微差別。根本上，WCF是暴露一個型別集的程式集的集合。這些型別由一些面向開發的API和一些面向底層的型別集組成。正如你可能想象的一樣，面向開發的API是非WCF開發團隊的人使用，面向內部的型別為了傳送、接受和其它處理訊息與.NET Framework和作業系統互動。WCF建立在自己的擴充套件架構上，所以開發者可以改變這些即裝即用的WCF功能以適合特別應用的需求。
WCF 特性
　　設計、構建、維護和版本控制分散式應用時一個複雜的任務。安全性、可靠性、事務性和伸縮性的因素和任務變得更加複雜。因為問題的複雜性，所以WCF被設計來解決這些問題，WCF是相當複雜的技術。為了能看清WCF的特性，我把主要的功能分為10個類別：獨立版本控制、非同步只進訊息、平臺統一、安全性、可靠性、事務支援、互操作性、效能、擴充套件性和配置性。

Independent Versioning
獨立版本控制

應用系統版本控制已經成為一個頭疼的問題。如我之前提到的，面向元件的設計不能在分散式應用中很好地解決這些問題。任何技術如果在分散式世界裡獲得認可，必須允許分散式應用的不同部分能夠獨立的版本控制。遵照WS-*規範，關注WS-*關於訊息定義的內容，允許被呼叫的服務可以再不同速率開發。這些特性不像建立WCF應用的底層原理那麼重要，但是我認為這是使用WCF最重要的副產品。
非同步單向訊息

我們的許多應用是使用請求-響應模式呼叫功能的。典型的是，我們呼叫一個功能，然後等待結果返回，然後根據返回結果執行。這種方式在Internet上尤為多見。每次我們請求一個頁面，我們必須等待網頁的響應。侷限我們的條件，大部分分散式應用使用的都是請求-響應方式。儘管開始看起來不自然，對於穿越IO邊界的任務分散式應用，非同步只進訊息方式是更加高效的方式。我認為這是使用WCF的又一個好處。非同步只進訊息方式允許使用高效的處理資源，更加方便地使用分散式應用的高階的功能、可靠性和相應能力。
平臺統一
　　過去微軟已經發布的很多分散式技術;有些成為WCF誕生的重要的導向技術。並且許多技術依然在使用。例如，在WCF釋出以前，微軟支援5種主要的分散式技術： RPC, WSE, ASMX, Remoting, COM+, 和MSMQ。過去，最好的分散式技術取決於應用系統的需求。例如，假如分散式應用都是基於.NET Framework，那麼會選擇.NET Remoting，因為它是.NET Remoting應用程式之間一種高效的通訊方式。如果一個應用需要擔保訊息傳輸和持久化，那麼MSMQ是最好的選擇。兩個技術有不同的API、程式設計方式、操作要求和配置需求。結果，應用程式程式碼緊密地繫結到這些技術上，這些技術也繫結到特定的功能上。一些新的技術允許我們組合特性，比如事務性和佇列性的COM+。只要需求不改變或者不使用其它的不支援的方式，這種模式是可以工作的。

什麼是你的應用系統與其他的 .NET Framework應用、非 .NET Framework應用和支援事務的處理通訊所需要的？在WCF之前，沒有好的選擇，本質上講，這些需求使得開發者要麼放棄一個需求要麼編寫自己的通訊技術。與舊的技術相比，WCF能夠整合舊的技術特性並且統一為一個程式設計模型，如表1-1所示。

表1-1 WCF特性對比

Feature	WSE	ASMX	Remoting	COM+	MSMQ	WCF
WS-* support	X			X		X
Basic Web service interoperability		X		X		X
.NET -to-.NET communication			X			X
Distributed transactions				X	X	X
Queued messaging					X	X

客觀地說，WCF沒有提供給我們無約束連線的特性，但是確實提供給了我們比以更多的連線特性。
安全性

沒人想建立一個全是安全隱患的應用系統。恰恰相反，我們會盡量確保我們的系統是安全的。如果我們現在這樣做，將來一定會做。過去，它取決於我們、開發者】架構師或者測試人員知道如何用安全的方式配置我們的系統。我們可以看到無數為我們的系統提供安全的技術，而確定那種技術或者技術的整個對我們的應用安全是正確的選擇是非常困難的。

創新的是，WCF支援多種安全模型，並且可以方便地實現廣泛接受的安全措施。自從WCF有的擴充套件架構，擴充套件WCF安全滿足特殊應用的需求相對變的容易許多。預設的安全選項從像WS-Security和相關規範裡描述的傳統的傳輸安全到現代的訊息安全。
可靠性

    分散式應用經常需要支援可靠訊息。在分散式計算，可靠訊息在保證裡經常提到。一個保證就像擔保。下面是4種保證使用在分散式計算場景裡;

1.最多一次   一個訊息保證最多傳送到目的地一次。如果一個訊息到達目的地多次，可以被忽略或者當做錯誤。

2.最少一次   一個訊息保證最少到達目的地一次，如果沒有到達，則視為錯誤。

3.僅僅一次   最多一次和最少一次的結合，它擔保訊息只到達目的地一次。

4.有序        一個資訊的邏輯集合可以分佈在多個訊息體了，這些訊息可以在特定的順序傳送，有序保證就是確保訊息可以按照傳送的順序處理。

經驗告訴我們，網路和產生網路通訊的應用程式師部可靠的。整體來說，如果一個應用經過網路傳送訊息到另外一個應用，保證訊息到達目的地的機制傳統上來自於傳輸。肯定可能一個或者兩個訊息在傳輸的過程中丟失。接受和傳送的訊息也可能不同，儘管訊息到達的次數多於傳送次數。粗多因素導致了不可靠性，包括網路過載，網路連線丟失，程式bug和環境變化這些因素。


一個不可靠的網路是氣人的，當你正在檢查郵件或者網上衝浪的時候，尤其是在分散式計算情況下會帶來更多麻煩。比如，如果一個順序處理程式當它在各個計算節點上傳輸訊息的時候丟失了訊息，這些問題可以類比到延遲送貨和憤怒的客戶。如果，當失敗發生的時候一個應用可以學習，那麼它可以採取補救措施。

     過去，一個應用的可靠需求指明瞭應用裡要使用的技術。例如，MSMQ提供不同應用間的可靠傳輸。如果一個應用需要卡考訊息傳輸，MSMQ是邏輯上的技術選擇。實現MSMQ，相當坦率地說，需要MSMQ規範知識和MSMQ規範程式碼。編寫這些程式碼和設定正確的執行環境需要知道MSMQ一些

不能與其他技術互用的MSMQ規範。本質上，在過去，從一個應用到另外一個應用傳送訊息可靠的決心已經影響到了應用程式的程式碼和需要編寫程式的知識。

WCF包括最多一次、最少一次、僅僅一次和有序傳遞的機制。WCF給應用系統提供了活多或少的修訂。甚至更好的是，傳輸保證機制是傳輸的弱耦合的，因此即使通過傳統的非安全傳輸也是可以保證訊息傳遞。

 備註：不要混淆可靠訊息和持久化訊息。從高層次看，持久化訊息被處理的時候會被儲存到非易失性介質中。如果應用程式粗意外終止和易失性記憶體被清空，訊息依然在持久化介質中。

事務支援

在互聯的世界裡，處理收到訊息的工作涉及後續的傳送給其他應用系統的訊息。優勢這些工作需要執行在事務的範圍內。簡單地說，事務是一個可以確保所有或沒有任何工作可以被執行完成。WCF支援跨越多個系統的事務範圍。
互操作性

WCF設計出來完全是為了與其他系統的互動。這包括可以執行在其他作業系統和平臺上的應用。因為WCF專注在訊息本性使得這個成為可能。

創新的是，建立在WCF之上的應用可以通過TCP, HTTP, Named Pipes, 和MSMQ與其他支援WS-*、Basic Profile (BP)、XML訊息的應用。開發者可以自由編寫擴充套件WCF功能的元件，這包括編寫定製擴充套件功能，允許WCF與那些需要使用二進位制訊息編碼的系統通訊（像大型機應用系統）。

傳統上，與其他平臺（像java）的互動需求已經很大程度上規定了我們的應用系統設計。過去，如果我們想與另外的平臺通訊，我們要麼使用ASMX要麼編寫自己的互動層。WCF就不同。從互動的角度來看，WCF是個單一的技術，它能夠可以與早期的幾種不同的技術互動。WCF通過相容WS-*、支援Rest架構和POX訊息風格兌現了真正的互操作的承諾。
效能

分散式應用一般都會有效能成本；這個成本一般會由這個技術的特性來低效。比如，對於2個.NET Framework應用來說，.NET Remoting是個相對高效的通訊方式。但是他不能與非.NET Framework應用互動。ASMX，換句話說，沒有Remoting那麼高效，但它可以與非.NET Framework的應用互動。從端對端的角度來說，MSMQ效率不高，但是佇列的特性可以彌補傳送訊息的應用的效率問題。換個方式，產生、傳送、傳輸和接受一個MSMQ訊息總時間成本是可以忽略不計的，但是MSMQ的永續性和可靠性讓傳送訊息的應用可以保證程式不需要產生和傳送訊息，並且等待訊息或者接受訊息。在傳送訊息的應用裡，網路影響是總體在吞吐量上總體增加。這個技術的缺點就是它不能與其它的訊息佇列系統互動。（有一個方式連線MSMQ和IBM的MQSeries）。總體來看，分散式系統使用的分散式技術已經影響到系統的效能。

相反地，WCF應用可以提供不同層次的互操作習慣和效能。例如，與基於Java的Web服務通訊相比，WCF應用與其他WCF應用通訊的時候可以更高效。
擴充套件性

公共語言執行時（CLR）深藏奧妙。例如，JIT編譯器，驗證子系統和垃圾收集器幾乎是不可複製的。微軟已經發布了部分關於這些子系統工作的資訊。但是子系統不可以被第三方系統取代。例如，所有的.NET Framework程式都受到垃圾收集器的管理。我們可以而且應該知道如何編寫程式碼才能高效地利用垃圾收集器的特性。然而，沒有微軟之外的人可以寫出使用帶自己編寫的垃圾收集器的CLR的.NET Framework應用程式。

相反地，WCF沒有什麼神奇的。不要讓這個歪曲了你對這個平臺能力的認識。與之相反，在大的標準衡量它的可擴充套件的設計，WCF都是異常強大和符合預期的。WCF被設計來與自定義的傳輸、通道、繫結、編碼和架構模式一起工作。第4章，“WCF 101”描述許多WCF的擴充套件點。
配置性

一個值得炫耀的WCF特性就是它可支援XML檔案的完善的配置功能。使用這個特性，可以在XML檔案裡配置傳輸、地址、行為和繫結。如果配置檔案更新，可以不需要修改任何程式碼就可以改變WCF應用的行為。從管理的角度來看非常有吸引力，因為這可以讓非開發人員來移植、維護和修改應用的行為而不需要捲入到開發工作中。合理的使用，會大大減少開發團隊的壓力和工作負荷。如果濫用，會帶來無法預期的後果。

　　WCF為分散式應用開發提供了突破性的功能。WCF讓我們比以前更加快速地設計、構建、除錯和維護分散式系統，並且比以前具有更多的特性。它完全支援SOAP和WS-*規範，但是它同樣可以傳送POX訊息，並且適應Rest架構。它整合了不同的分散式技術：RPC, COM+, Remoting, ASMX, WSE, 和 MSMQ。WCF也是高可擴充套件的。這個擴充套件性為了2個目的：第一個就是，提供給WCF團隊可以容易地改變WCF的能力。其次就是，它提供給公司更多的可以根據自身需求採用WCF的靈活性，WCF API相當複雜但是非常強大。因為描述WCF所有不同的使用方式實際是不可能的，這本書關注在WCF的內部實現上。我的觀點，這個方法可以幫助應用系統開發者和framework 的開發者使用WCF解決他們的分散式計算任務。