簡介
.NET Framework 3.0，應用程式開發的目標始終如一，就是在最短時間內製作出最好的軟體。然而，隨著開發平台的性能越來越高，製作軟體的壁壘也相應提高了。以 Windows 為例，原來的 Win32 接口已經融入到功能更強的 .NET Framework 中。2002 年發布的 Framework 1.0 和 2005 年發布的 Framework 2.0 為設計和編寫 Windows 軟體的開發人員提供了更好的工作環境，效率也更高。
.NET Framework 3.0（以前稱為 WinFX）就是我們前進路上的下一個目標。建立在這一新版 Framework 上的應用程式可通過 Visual Studio 2005 創建，對大多數 Windows 開發人員來說，這樣的應用程式將會更加熟悉。.NET Framework 3.0 是從 2.0 版本演化而來，並在原來的基礎上添加了許多新的功能。.NET Framework 3.0 計畫於 2006 年底發布，適用於 Windows Vista、Windows Server 2003 和 Windows XP。
本文對 .NET Framework 3.0 及其組件進行了整體描述，目的是讓大家對這一新版本有一個清晰的了解，同時分析了採用的技術，並給出簡要說明。
創建現代應用程式：主要挑戰
今天，開發一款優秀的應用程式可不簡單 - 您需要考慮眾多的要求。傳統的考慮因素，如訪問數據、通過 Web 瀏覽器上網等固然重要，但這些已經顯然不夠了。下面列出了現代應用程式面臨的一系列新挑戰：
組織越來越傾向於從面向流程的角度看待他們的工作。由於大多數應用程式已經對業務流程實現了部分自動化，因此，在代碼中明確流程中的這幾個步驟就非常重要了。而要實現這一目標，最有效途徑是使用工作流技術，這是一種需要支持基於工作流的應用程式的方法。
通常來講，應用程式要與組織內外的其他應用程式進行通信。現代應用程式還必須適用於面向服務的架構 (SOA)，同時還要實現一些功能，作為其他軟體可以訪問的互動服務。要實現這些目標，就需要支持面向服務的應用程式。
對於使用應用程式的人員來說，通常還需要有傳遞識別信息的方法。目前定義和使用數字標識的技術各不相同，這也是造成網頁仿冒等問題泛濫的原因。有鑒於此，現代應用程式及其使用者將會從一致的數字標識用戶控制項中受益。
對於現代用戶界面，人們的要求也有了很大幅度的提高。要提供真正的業務價值往往需要處理不同類型的文檔，使用二維或三維圖形，播放視頻等等，還要保證本地 Windows 客戶端和 Web 瀏覽器能夠兼容這些功能。要滿足這些要求，需要不同的用戶界面採用統一的方法。
一般說來，現在的應用程式需要應對以上部分或全部的挑戰，因此，這些應用程式的開發平台應該採用一致、可行的方法來解決所有的相關問題。.NET Framework 3.0 就是專為解決這些 Windows 應用程式難題而設計。
應對挑戰：.NET Framework 3.0 功能介紹
如圖 1 所示，.NET Framework 3.0 版是在以前版本的基礎上完善而成。事實上，3.0版本保留了 .NET Framework 2.0 的全部功能，因此，在以前版本基礎上開發的應用程式仍然可以正常使用。.NET Framework 3.0 添加了四個新組件：Windows Workflow Foundation、Windows Communication Foundation、Windows CardSpace 和 Windows Presentation Foundation。本節將會概要介紹 .NET Framework 2.0 和上述四個新組件的功能。
.NET Framework 2.0：Windows 應用程式通用基礎
儘管仍然可以通過 Win32 界面直接編寫軟體，而事實上卻是，.NET Framework 已經成為編寫新 Windows 應用程式的主流環境。如下所示為.NET Framework 最重要的組成部分：
• ASP.NET，支持可 Web 訪問的應用程式的開發。
• ADO.NET，允許應用程式訪問相關的其他類型數據。
• Windows Forms，支持建立 Windows 應用程式的圖形用戶界面 (GUI)。
• System.XML，使應用程式能夠使用 XML 定義的數據，包括 XSLT 和 XPath。
Framework 的 2.0 版本在以前版本的基礎上添加了幾項實用功能，包括對開發 ASP.NET Web 應用程式的技術改進，支持在 64 位 Windows 上運行的 64 位應用程式，還增加了處理事務的新方法。雖然 .NET Framework 2.0 中的部分組件為 3.0 版本中新增組件所取代，但是 2.0 版本的技術仍然是新發布的 3.0 版本的基礎，請見隨後的詳細介紹。
Windows Workflow Foundation：支持基於工作流的應用程式
工作流是一個簡單思路：按照特定順序執行的一系列步驟。您甚至可以認為每個應用程式都在執行工作流，因為每個應用程式都執行某些過程。但是，在使用 C#、Visual Basic 或其他程式語言等傳統方法開發的應用程式中，這些過程都隱含在代碼中。這樣做沒問題，但是這些過程被深深地嵌入程式邏輯中，使得其執行或更改愈加困難。
使用工作流技術執行過程邏輯可以有效地解決這一問題。採用工作流技術後，邏輯與普通代碼就不會糾纏在一起，過程中的每一步驟都會明確定義，然後由工作流引擎執行。這樣做的結果就是，過程執行清楚明確。
工作流引擎不是什麼新概念，有些已經在 Windows 和其他系統中得到套用。Microsoft 已經在部分產品中嵌入了工作流引擎。但是，隨著工作流日漸成為開發應用程式的主流方法，提供適用於 Windows 的單一工作流技術已經勢在必行。這也正是 Windows Workflow Foundation（正式縮寫是 WF ）的設計初衷。由於其提供了適用於 Windows 的通用工作流技術，WF 已成為所有基於工作流應用程式的統一創建基礎。Microsoft 的 microsoft office 2007 系統、Windows SharePoint Services 等軟體，以及許多其他公司的應用程式也會使用 WF。
但是，提供通用的工作流技術之路卻是困難重重。舉例來說，如何使用一種方法來滿足不同工作流應用程式的各種要求？WF 給出的答案是，從全局視角來看待工作流。如圖 2 所示，WF 工作流只是一組由 WF 引擎執行的活動。一個活動就是一個類，它可以包含工作流創建者認為有必要的任何工作。活動可以在不同的工作流中重複使用，因此，在針對新問題創建自動化的解決方案時，過程將會更加容易。
提供通用工作流技術面臨另一個困難是，面向人員工作流和面向系統工作流的傳統分歧。通常來說，工作人員使用的工作流應用程式需要有較高的靈活性，能夠進行實時更改。而一般由系統，也就是由軟體使用的工作流應用程式則相對更加靜態，但要求儘可能高效。WF 綜合考慮了這兩種不同的使用情況，不僅包括面向人員的功能（如更改運行中工作流的功能），同時還支持更多面向系統的操作。
通過 WF 的 Windows 通用工作流技術，.NET Framework 3.0 為廣大開發人員提供了一種非常有用的軟體開發模式。隨著面向流程的軟體繼續風行，工作流技術也會隨之推廣。
Windows Communication Foundation：支持面向服務的應用程式
無論是通過工作流還是其他方式開發，絕大多數應用程式都需要與其他應用程式進行通信。近幾年來，應用程式間的通信技術發展迅速。在長達數十年的不統一之後，主要供應商之間最終達成了一致的應用程式通信協定。根據 SOAP 這一全球 Web 服務協定，基於 J2EE、.NET Framework 等不同技術平台開發的應用程式間的互操作性相比以前大為簡化。它還會使面向服務的架構這一思想為更多的組織接受。
當然，現在的通信方式已經不少了。以 .NET Framework 2.0 為例，您可以選擇以下幾種通信方式：
• ASP.NET Web 服務，提供基於 SOAP 的互動通信。
• .NET Remoting，主要用於 .NET 應用程式之間的通信。
• Enterprise Services，支持可擴展的事務性應用程式。
• System.Messaging，通過 Microsoft Message Queuing (MSMQ) 支持佇列訊息。
• Web Services Enhancements (WSE)，它是 ASP.NET Web 服務的擴展，支持 WS-Security 等新規範。
這些技術都有其自身的價值，在實際套用中也有著各自的地位。可是，既然問題是一樣的，為什麼要採用好幾種不同的解決方案呢？為什麼不根據互動服務來建立一個單一的應用程式通信基礎？
這正是 Windows Communication Foundation (WCF) 的設計初衷。有了 WCF，開發人員不必再像從前一樣，處理每一類通信都要使用到不同的應用程式編程接口技術 － WCF （最初的代號為“Indigo”）以通用的 API 提供通用的方法。在 .NET Framework 3.0 環境下，大多數使用上述技術之一的應用程式將會代而使用 WCF。
WCF 通過 SOAP 提供強大的互動通信支持，這是現代計算機設備的基本要素。它還支持多項 WS-* 規範，如 WS-Security、WS-ReliableMessaging 和 WS-AtomicTransaction。WCF 不需要 SOAP，但是可能會使用其他方法，包括最佳化二進制協定、MSMQ 佇列訊息 和基於 REST 的簡單通信。WCF 同樣採取明確的面向服務方法來進行通信。WCF 不會在對象間進行透明通信，而是為通信各方提供略微不同的抽象服務。其結果之一就是放開了分散式對象系統間某些緊密的耦合關係，使得互動出錯減少，並且更容易修改。
無論是在組織內部還是組織之間，應用程式通信都是現代軟體的基本功能。.NET Framework 3.0 以其 WCF 面向服務方法解決了這一難題。
Windows CardSpace：一致的數字標識用戶控制項
請您想一下，人們在 Internet上是如何表示各自身份的。多數情況下是將個人的數字標識作為一個簡單的用戶名。再加上密碼之後，就可以使用這個標識訪問電子郵件帳戶、網上商店、網上銀行和其他一些金融機構了。儘管這種方法很簡單，現在也在普遍套用，但是用戶名和密碼方式有著無法迴避的缺點。最重要的兩項是：
要記住登錄眾多網站的不同用戶名和密碼，的確讓人不勝其煩。為了減少這些麻煩，許多人在不同網站使用相同的用戶名和密碼，可這樣又增加了安全風險。
用戶名、密碼和其他個人信息可能會被網頁仿冒者竊取。網頁仿冒者會傳送欺騙性電子郵件，誘使受害者去登錄一個假冒網站，比如一個與受害者銀行極其相似的仿冒網站。而這個網站實際上是網頁仿冒者控制的。一旦受害者輸入自己的用戶名和密碼，網頁仿冒者就會利用這些信息，在真網站冒充該用戶，牟取不當利益。
要減少這些問題的危害性，我們需要採用新的方法來管理數字標識。Windows CardSpace（最初代號為“infocard”）是這種新方法中的重要組成部分。為幫助人們追蹤自己的數字標識，CardSpace 用不同的信息卡來表示每個數字標識。如果網站接受 CardSpace 登錄，那么用戶在嘗試登錄這一網站時會看到 CardSpace 選擇螢幕，如圖 3 所示。您可以選擇一張卡片，這就相當於選擇了登錄該網站的數字標識。不必再去費心記住數不清的用戶名和密碼，用戶只要記住他們要使用的那張信息卡就可以了。不同的信息卡還包含其他信息，用戶可以通過它控制登錄網站時提交的信息。
信息卡表示的這些標識是由一個或多個標識提供者創建而成的。組織可以有自己的標識提供者，而不必依賴於簡單的用戶名和密碼。每個標識提供者都會採用更加強大的加密機制，讓用戶來驗證他們的標識。CardSpace 本身也包含一個自發行的標識提供者，可以在客戶端計算機上運行。使用這一提供程式，用戶可以創建自己的標識，且標識也不必依賴密碼進行身份驗證。網站接受這些自發行 CardSpace 標識，這樣就不必再依賴常見的密碼方法，自然會減少因密碼而帶來的諸多問題。
不用密碼登錄網站，網頁仿冒者也就無密碼可偷了！但是，如果網頁仿冒者成功誘使受害者訪問假冒網站的話，他們還是會竊取用戶的其他信息，如敏感的醫療信息等。要杜絕這種情況，就要求用戶自己能夠區別假冒網站和真網站。為幫助用戶識別網站，擁有網站的組織應獲取“高度確認認證”。與現在的 SSL 簡單認證不同，新的認證方式涉及到更多、更嚴格的流程，其中包括採用更嚴格的方式來證明申請該項認證的組織的身份。高度確認認證上還可以帶有公司徽標和其他信息，幫助用戶準確識別使用證書的網站是否合法。用戶訪問新網站時，CardSpace 會始終以標準螢幕顯示該網站的證書信息。根據認證的接受程度，螢幕上會自動顯示出對網站標識的確認程度。其目的是，強制用戶明確界定網站是否可信，然後幫助他們作出正確選擇。
Windows CardSpace實際上是更大的標識元系統的一部分。標識元系統完全基於開放的公共協定，它定義了一種全新的方式，能夠使不同的數字標識技術在各個不同的平台（包括 Windows 以外的作業系統）和應用程式（包括 Internet Explorer 以外的 Web 瀏覽器）上使用。CardSpace 採取通用的方法來選擇標識和其他 Windows 信息，因而在元系統中扮演著重要角色。並且，由於解決了基本的標識問題，CardSpace 也已經成為 .NET Framework 3.0 的重要組成部分。
Windows Presentation Foundation：適用於不同用戶界面的統一方法
對幾乎所有的應用程式來說，用戶界面都是重要的組成部分。現在，用戶對這些界面的要求越來越高了。當然，我們仍然需要傳統的選單驅動式 GUI。但是除此之外，許多應用程式還需要能夠播放視頻、運行動畫、採用二維或三維圖形，以及調用不同的文檔。無論是通過安裝的桌面客戶端還是通過 Web 瀏覽器來訪問應用程式，上述功能都必須可以正常使用。
一直以來，Windows 上的這些用戶界面功能都是以不同方式提供的。例如，開發人員可以使用 .NET Framework 中的 Windows Forms 來創建 Windows GUI，使用 HTML、Java 小程式或 JavaScript 代碼創建 Web 瀏覽器界面，或是使用 Windows Media Player、Adobe 的 Flash Player 等軟體播放視頻，文檔格式則以 Microsoft Word、Adobe PDF 或其他軟體進行定義。很明顯，開發人員面臨著巨大的挑戰：如何使用不同的技術，為不同的客戶端創建一致的用戶界面。這相當困難。
Windows Presentation Foundation (WPF)，最初代號為“Avalon”，就是為解決這一難題而設計。WPF 為所有的這些用戶界面提供一致的技術基礎，從而大幅簡化了開發人員的工作。WPF 採用更為現代的方法，支持視頻、動畫、二維或三維圖形以及各種類型的文檔，從而可以讓用戶以全新的方式處理信息。此外，WPF 還為桌面客戶端和瀏覽器客戶端提供了通用基礎，大大簡化了二者的應用程式開發工作。
讓我們以圖 4 中的界面（其中包含了圖像、現場圖、三維視圖等等）為例說明 WPF 的部分功能。過去，開發人員需要懂得各種技術才能進行工作；而現在通過這種更為一致的方法，開發人員可以輕鬆製作出類似示例中的用戶界面。
另外一個長期困擾用戶界面開發人員的問題是，如何創建高效界面需要的不同角色。軟體開發人員需要編寫相應的界面邏輯，但是，他們並不是定義界面感觀的最佳人選。一般來說，人機互動領域的設計人員和專家更適合這一工作。但是在以前的技術（如 Windows Forms）背景下，這些問題完全由開發人員決定。開發人員和設計人員之間沒有實現真正有效的協作。WPF 藉助於可擴展應用程式標記語言 (XAML) 解決這一問題。XAML 是一種基於 XML 的語言，允許以聲明方式指定用戶界面 －而非代碼。這就，開發工具就能夠根據設計人員創建的可視化顯示，更加容易地生成和使用界面規範。實際上，Microsoft 的一款新產品 Expression Interactive Designer 就是為此而設計。使用這一工具（其他的由第三方提供），設計人員可以創建界面外觀，然後生成他們所創建界面的 XAML 定義。開發人員將這些定義導入 Visual Studio 之後，就可以著手構建界面所要求的邏輯了。
開發人員創建了直接在 Windows 上運行的安裝版 WPF 應用程式後，就可以使用 WPF 提供的全部功能了。但是，若要創建在 Web 瀏覽器內部運行的客戶端程式，開發人員應創建一個 XAML 瀏覽器應用程式，我們通常稱之為 XBAP。與安裝版 WPF 應用程式的基本原理相同，XBAP 允許在可下載的瀏覽器應用程式中表示與用戶界面相同的樣式。兩種應用程式可以使用相同的代碼，這也就意味著開發人員不再需要針對桌面和瀏覽器客戶端的不同技術集。特別是按照此類豐富 Internet 應用程式的現狀，在安全沙箱內運行從 Internet 下載的 XBAP，將會限制應用程式的功能。但是，安裝版 WPF 應用程式中提供的大量用戶界面功能子集也可用於 XBAP。
WPF 安裝版應用程式和 XBAP 都可以利用 WPF 的現代圖形支持，其中包括使用硬體加速、支持矢量圖形以及其他更多功能。通過提供更強大的圖形支持功能，WPF 使得一系列數據可視化選項成為可能，而這依靠 Windows Forms 或其他的早期技術是不可能實現的。WPF 還提供了 XML Paper Specification (XPS) 的基礎，可定義查看、分發和列印固定格式文檔的標準格式。
用戶界面是現代應用程式中複雜而重要的組成部分。通過 WPF，.NET Framework 3.0 提供了一種比較完整和一致的解決方案，用於應對用戶界面方面的難題。其目標是使構建用戶界面的相關人員（包括開發人員和設計人員）能夠更有效的進行工作。
套用 .NET Framework 3.0：構想
理解一組技術如何協同工作的最好方式，就是查看其使用方式的示例。現在假設，一款應用程式要求客戶和代理提交保單。如果使用 .NET Framework 3.0 執行，則會有圖 5 所示的工作流程。圖表左上角所顯示的應用程式業務邏輯，是使用 WF 工作流得以實現的。處理保單是一項多步驟流程，包括根據組織的保險規則來評估此保單，或許要檢查投保人的信用，甚至還要獲得其上司的批准。工作流依靠所需要的其他軟體，以活動方式實現流程中的每一個步驟。如果要訪問存儲數據，工作流中的活動可以使用 ADO.NET。
保險公司可以提供一個呼叫中心，使客戶可以通過電話進行投保。呼叫中心員工使用的客戶端軟體顯示在圖表的右上角，是由安裝版 WPF 應用程式實現的。客戶端使用 WCF 與應用程式業務邏輯進行通信，採用的是經過 WCF-WCF 通信最佳化的二進制協定。如圖所示，呼叫中心工作人員依靠 Windows CardSpace 來選擇他們在登錄該應用程式時將要使用的標識。客戶還可以通過網路進行投保，而保險代理商也可以通過網路提交保單。為便於網路操作，該應用程式使用 ASP.NET 與 Web 瀏覽器進行通信。如圖表的左下角所示，客戶通過 Internet Explorer 來訪問該應用程式，他們可以使用普通的 HTML 界面，也可以使用 CardSpace 來選擇自主設定的標識。第三方也可以為其他客戶端作業系統和瀏覽器實現標識選擇機制，使得標識元系統能夠擴展至非 Windows 客戶端和 Web 瀏覽器。保險代理商通過 Internet 訪問該應用程式時可能需要具有更多功能的界面。因此，他們應該使用 XBAP 而非簡單的 HTML 界面。如圖表底部中間位置所示，這些客戶可以共享呼叫中心所用 WPF 桌面應用程式提供的大部分用戶界面功能。由於兩者構建在同一基礎之上，因此應用程式開發人員可以在兩種類型的客戶端中重複使用相同的代碼。對於其他類型的客戶端來說，代理商可以使用 CardSpace 選擇他們針對該應用程式所設定的標識。
最後，此應用程式有可能需要與其他應用程式之間進行互訪。如果批准客戶時要求信用審核，則最有可能通過調用外部服務實現。或者此應用程式會直接收到外部軟體請求，提供這些外部應用程式可以調用的服務。在這些情況下，如圖表右下角所示，該應用程式依靠 WCF 使用標準 Web 服務進行通信。無論這些應用程式構建於何種技術之上，WCF 對 SOAP 的支持都使得這些應用程式之間的互動變得輕而易舉。該方案說明了如何使用 .NET Framework 3.0 中最重要的組件來構建出色的應用程式。而此處所舉的簡單示例省略了相當多的選項，因此不能將其視為該系列技術所有功能的完整說明。相反，該示例只是提供一種思路，用於講解如何使用 .NET Framework 3.0 的不同部分來解決實際的業務問題。
了解 .NET Framework 3.0：技術
更深入地研究 .NET Framework 3.0 的各項構成技術，對於真正了解 .NET Framework 3.0 的功能會很有幫助。本節分別為 .NET Framework 3.0 的五個部分提供了一個簡明教程。有關各部分的更詳細介紹，請參閱本文末尾的“更多參考資料”。
. NET Framework 2.0 是目前 Windows 開發的基礎，同時也是 .NET Framework 3.0 的基礎。圖 6 介紹了 Framework 的兩個組成部分：公共語言運行庫 (CLR) 和 .NET Framework 類庫。.NET Framework 3.0 的一些組件，包括 WF、WCF 和 WPF，基本上都作為 .NET Framework 類庫的擴展而執行。如前文所述，類庫的許多部分仍然是開發人員所使用的重要部分，而其他部分則被包含到 .NET Framework 3.0 提供的新技術中。例如，ASP.NET 仍然是創建瀏覽器可訪問的應用程式的基礎，ADO.NET 仍然用來與存儲數據配合使用。.NET Framework 3.0 開發人員使用 WPF 而非 Windows Forms 來創建本機 Windows GUI，但與 ASP.NET Web Services、.NET Remoting 或 Enterprise Services 相比，他們通常更喜歡 WCF。儘管存在這些變化，但也應該了解即使在 .NET Framework 3.0 世界中，早期版本的 Framework 仍然是開發人員所使用的核心部分，這一點非常重要。
Windows Workflow Foundation
由工作流驅動的、面向流程的設計，是 Windows 軟體重要部分的正確開發方式。WF 的目的是讓開發人員創建並執行這些基於工作流的應用程式。圖 7 顯示 WF 提供的用於進行該項工作的組件。如前文所述，每個工作流都通過一定數量的活動創建。工作流和活動都屬於類，所以兩者均可由代碼直接創建。WF 也提供了工作流設計器，這是一個用於構建工作流的 Visual Studio 託管圖形工具。但是創建工作流後，其活動就可以從 WF 附帶的基本活動程式庫 (BAL) 或其他任何來源得到。
一旦定義了一個工作流，最終就會由 WF 運行時引擎來執行。該引擎所依賴的是一組運行時服務，用於保持工作流狀態、跟蹤工作流執行等。運行時服務、運行時引擎和工作流本身，所有這些都包含在某個主機進程中。該進程可以是任何 Windows 進程，從正在桌面上運行的簡單的控制台或 WPF 應用程式，到可擴展的伺服器進程。
要了解 WF，需要至少具有一點其組件的知識。以下部分將對各組件進行簡述。
工作流
從本質上說，工作流就是一組活動。WF 對兩種樣式的工作流提供內置支持：
可以按定義的順序執行活動的順序工作流。類似於傳統的流程圖，順序工作流中包含分支、循環和其他控制結構。但默認情況下，活動會按順序依次執行。可以實現傳統有限狀態機的狀態機工作流。類似於任何的狀態機，特定時間所執行的活動由當前狀態和已收到的事件共同決定。 順序選項可用於定義明確的工作流，例如完全基於軟體的進程中的工作流。創建並理解這些工作流相對簡單，而且一開始就讓大多數開發人員覺得非常容易。當執行路徑不太容易預測時，可以選擇狀態機工作流。一個典型的例子就是涉及與人進行互動的工作流，任何人在任何地方都可以取消該工作流。通過順序工作流可應對該狀況，但每個步驟都會成為一個分支：若工作流未取消，則應該執行；若已取消，則應該執行其他活動。使用狀態機對這種行為建模會簡單許多，因為取消工作流的請求恰恰是另一個可以在任何時間接收並處理的事件。對狀態機工作流的支持，是 WF 如何嘗試為人和系統工作流提供支持的一個例子。另一個相關的例子是，WF 對更改正在運行的工作流的支持。人的要求千變萬化，某個工作流的相關人員，在進程運行當中添加步驟、刪除步驟或進行其他更改的行為並不罕見。為了以受控方式適應這種狀況，WF 允許創建工作流的開發人員在執行工作流時指明是否要修改以及如何修改。
基本活動程式庫
開發人員可以隨意創建自定義活動。事實上，Microsoft 的目標是促進滿含可重用活動的 WF 生態系統的開發。而且，從一個普通的基本活動集著手會讓每個人都覺得更加容易。基本活動程式庫 (BAL) 的作用就是提供這個普通集。
無論使用 BAL 中的哪些活動，工作流都不是必需的。而且，許多開發人員會發現 BAL 使他們的工作變得更簡單，尤其是在開始的時候。BAL 中包含的活動如下：
• IfElse：根據是否滿足某個條件，執行兩個或更多可能路徑中包含的活動。
• While：只要某個條件為真，就反覆執行一個或多個活動。
• Sequence：以定義的順序，一次執行一組活動。
• Parallel：並行執行兩組或多組活動。
• Code：執行定義的代碼塊。
• Listen：等待一個特定事件，收到後再執行一個或多個活動。
• InvokeWebService：調用一個 Web 服務。
• state：表示工作流狀態機中的一個狀態。
• EventDriven：定義包含一個或多個活動的轉換，該轉換需處於特殊狀態，並在收到特定事件後執行。
• Policy：允許使用 WF 提供的規則引擎定義並執行業務規則。
WF 採用了較一般的方式來使用活動，而並非為指定的工作流定義特定語言。BAL 提供了一種“語言”，但任何人都可以使用 WF 隨意定義自己的語言。
Windows Workflow Foundation 工具：工作流設計器
使用工作流創建應用程式的一個優勢是可以圖形化地定義工作流。WF 的工作流設計器允許使用該功能，如圖 8 所示。默認情況下，開發人員可將工具框中出現的 BAL 活動拖放到該工具的設計界面上，以創建工作流。
一些開發人員不喜歡圖形設計器，他們更願意編寫代碼。WF 也允許使用這種方法（並且有時需要該方法：一般是直接從代碼構建的活動）。也可以將這兩種方法結合使用，如同時使用工作流設計器和直接編碼的方法創建工作流。其目的是讓開發人員使用最有效率的方法。並且為實現更廣泛的工具支持，也可以通過 XAML 語言表達工作流，這也是 WPF 所使用的語言。事實上，使用工作流設計器創建的工作流默認為是 XAML 定義的。
運行時引擎和運行時服務
如前文所述，WF 運行時引擎具有執行工作流中的活動的職責。作為執行該職責的一個部分，它依賴於一組運行時服務。WF 包含這些服務的標準實現，但是有能力的開發人員可以根據需要更換。這些服務支持幾種不同的功能，其中有兩種最值得注意：
• 持久性：因等待某個事件受到阻塞的工作流，可以使用該服務將其記憶體狀態自動保存到磁碟。當事件發生時，該服務會自動重新載入工作流的狀態並重新開始執行。這對於涉及到人員的工作流尤其有用，因為等待一個回響可能需要幾個小時、幾天或更長時間。
• 跟蹤：工作流中的活動清楚地區分了其實現進程的執行。WF 的跟蹤服務允許開發人員將工作流的執行信息自動寫入資料庫中。例如，開發人員希望跟蹤工作流的起始時間、它的每個活動的起始時間和其他信息。
Windows Workflow Foundation 和其他 Microsoft 技術
引入新方法肯定會影響現有方法。.NET Framework 3.0 中的新技術也不例外，每項技術都會對 Microsoft 的其他技術產生影響。當使用 WF 時，對 Windows SharePoint Services、Microsoft Office 2007 系統和 BizTalk Server 的初始影響最大。
為了使開發人員更容易地創建文檔合作和其他種類信息共享的工作流應用程式，3 版 的 Windows SharePoint Services 託管了 WF 運行時。Office SharePoint Server 2007 是 Office 2007 系統的組成部分，基於 WF 支持，構建於 Windows SharePoint Services 中。此外，添加該伺服器後，就可以直接在 Office 2007 客戶端應用程式中顯示 infopath 窗體，而且可以在一些普通方案（如批准一個文檔）中使用一組預定義的工作流。
任何熟悉 BizTalk Server 的人現在一定已經注意到了該產品的編排功能和 WF 提供功能之間的相似性。事實上，BizTalk Server 2006 發布後，將通過 WF 替換該產品現有的編排功能，並提供可幫助將現有編排服務遷移到 WF 工作流的工具。但有一點很重要，即應了解 WF 和 BizTalk Server 2006 解決的問題是截然不同的：
• WF 提供了一個通用框架，用於創建基於工作流的 Windows 應用程式。它可以被託管在任何進程中，使用任何種類的活動，並解決任何種類的業務問題，其中包括人員和系統工作流。
• BizTalk Server 是面向企業應用程式集成、企業對企業集成和管理業務流程的許可產品。它提供了大量用於連線不同系統和軟體的適配器、用於實現諸如 RosettaNet 和 SWIFT 等標準的加速器以及對企業活動監控的支持。BizTalk Server 還提供了管理基礎結構和工具，以及對增長的可擴展性的支持。
因為它是 Windows 標準的工作流技術，因此 WF 以後很可能會出現在其他 Microsoft 產品和技術中。無論 Microsoft 做出什麼樣的選擇，在客戶創建的大量應用程式中都肯定會出現 WF 的身影。
Windows Communication Foundation
面向服務的通信的變化，標誌著在應用程式互動方式上的進步。WCF 專為支持面向服務的應用程式而設計，正好體現了這種進步。本節將介紹 WCF 最重要的方面，包括服務和客戶端、通信選項以及對安全性、可靠通信和事務的支持。
服務和客戶端
如圖 9 所示，WCF 的基本思路很簡單：服務提供了客戶端可訪問的接口。該接口可通過 Web 服務描述語言 (WSDL) 來定義，然後轉成代碼，也可以通過 C# 或 Visual Basic 等語言直接定義。對於一個提供保險應用程式服務的簡單接口而言，若使用後一種方法，則代碼如下所示：
【ServiceContract】
interface IInsuranceApplication
{
【OperationContract】
int Submit(int policyType, string ApplicantName);
【OperationContract】
bool CheckStatus(int applicationNumber);
【OperationContract】
bool Cancel(int applicationNumber);
}
C# 接口的定義用 ServiceContract 屬性來標記。該屬性表示 WCF 可在該接口中提供進行遠程調用操作的方法。所提供的接口方法都標有 OperationContract 屬性。在上述簡單示例中，每個方法都標有該屬性，因此都可以提供給遠程調用者。但這並不是必需的，僅為接口的某些方法套用 OperationContract 是合法的。無論進行哪種選擇，應用程式中必須有一個類實現該接口，從而為接口定義的方法提供實際代碼。一旦完成，WCF 會自動將方法標記為 OperationContract，表示該服務的客戶端可對其進行訪問。
關於服務如何被實際提供給其客戶端，圖 10 給出了比較詳細的介紹。客戶端不直接訪問接口，而是連線到特定的端點。服務可以提供多個端點，從而允許不同的客戶端以不同方式進行訪問。
如圖所示，每個端點都具有以下三個屬性：
• 契約，說明使用該端點可以調用的操作。該契約只需使用定義這些操作的接口名即可識別，此處是 IInsuranceApplication。
• 綁定，定義如何調用端點的操作。每個綁定都可定義數個方面，包括使用什麼協定來調用操作、使用哪類安全性等。WCF 中包含許多預定義綁定，如此處顯示的 BasicHttpBinding，這是最常見的例子，用戶也可以定義自定義綁定。單個服務可以提供多個端點，所以可通過不同協定、使用不同安全性選項，同時訪問不同種類的客戶端。
• 地址，表示端點的位置。如圖所示，位置是以 URL 表示的。
WCF 的基礎很簡單。與大多數通信技術一樣，細節可以很複雜，因為具有許多選項，但是創建一般的 WCF 應用程式並不難。
通信選項
由不同類型的開發人員構建的不同種類的應用程式，需要以不同的方式進行通信。對大多數開發人員而言，最簡單的方式是遠程過程調用 (RPC)，它可以使客戶端可以像調用本地操作那樣調用遠程操作。例如，假設是上文所示的接口，客戶端可通過一般同步的方式調用任何操作，並耐心等待返迴響應。該選項對開發人員而言很容易，在某些情況下是正確的選擇。
但是，WCF 還提供了其他幾個選項。如下所示：
• 調用沒有回響的操作。該類通信標有屬性 oneway，對於傳送事件或其他單向互動很有用。
• 基於訊息的異步通信，直接傳送和接收 XML 訊息。
• 顯式處理 SOAP 訊息，包括直接在 SOAP 標頭中插入元素。
WCF 還允許開發人員控制服務進行的各種本地形式。例如，使用 ServiceBehavior 屬性，可用來設定服務是單執行緒還是多執行緒的、是否為每次調用創建新的服務實例以及其他選項。
安全性、可靠性和事務
基本通信，即系統間的數據移動功能，它非常有用，但卻遠遠不夠。大多數應用程式還需要其他功能。例如，大多數分散式應用程式需要某種安全性。從今天使用的不同方法和技術多樣性看來，安全性的提供可能非常複雜。為了使開發人員在不必了解所有細節的情況下創建安全的分散式應用程式，WCF 主要依賴於安全性綁定。例如，上文所示的 BasicHttpBinding 可以配置為使用 HTTPS 而不是普通的 HTTP，其他綁定則提供了更多的安全性選項。例如，WsHttpBinding 支持 WS-Security，允許基於 SOAP 的互動驗證、數據完整性和數據機密性。開發人員還可以創建自定義綁定，以提供其應用程式所需的相同的安全性服務。
對於許多應用程式而言，確保通信的可靠性也非常重要。傳統的 Web 服務方法，即通過 HTTP 傳送 SOAP，在某些情況下完全可以勝任，當使用 BasicHttpBinding 時會用到該方法。但在大多數情況下，這種廣泛使用的方法顯得力不從心。例如，經由一個或多個 SOAP 中間方傳輸的訊息不能靠這種簡單的方法實現端對端的可靠性。這些情況下，WCF 將執行 WS-ReliableMessaging。開發人員可以選擇一個支持該選項的綁定，如 WsHttpBinding，從而傳輸互動可靠的訊息。
在某些應用程式中，分散式事務也很重要。WCF 構建於 System.Transactions 之上，是 .NET Framework 2.0 的組成部分，允許創建事務性軟體。方法可以使用 OperationBehavior 屬性指示其所需事務並定義該事務的進行方式。WCF 依賴於 WS-AtomicTransaction 規範，允許分散式事務跨供應商邊界進行互動。使用該多供應商協定定義的技術，WCF 應用程式可以參與涉及多項技術（包括 J2EE 及其他）的事務。
Windows Communication Foundation 和其他 Microsoft 技術
如前文所述，WCF 取代了一些用於創建分散式應用程式的早期 Microsoft 技術。大多數使用 ASP.NET Web Services、.NET Remoting、Enterprise Services、System.Messaging 或 WSE 構建的應用程式，將轉而通過 WCF 進行構建。WCF 應用程式可以與 ASP.NET Web Services 應用程式互動，兩者都支持標準 SOAP，也可與其他構建在 Enterprise Services、MSMQ 和 3.0 版的 WSE 上的應用程式互動。BizTalk Server 2006 也可以使用 WCF，而且未來版本的 BizTalk Server 會更直接地構建在 WCF 提供的架構上。
有一點非常重要，即使新的 .NET Framework 3.0 應用程式不常使用 WCF，但其取代的所有技術仍是該版 Framework 的組成部分，而且仍被照常支持。使用這些技術的早期版本構建的應用程式，還會繼續正常運行；安裝和使用 .NET Framework 3.0 不會破壞現有代碼。
Windows CardSpace
無論是通過 Web 瀏覽器還是其他種類的客戶端，用戶通常會跨網路訪問應用程式。這些應用程式通常需要用戶以某種方式標識自己，因此結果肯定是人們必須定期獲取並提供遠程軟體的標識信息。通過瀏覽器訪問 Internet 應用程式，就是一個很常見的示例，內聯網上的用戶通常也會面臨該問題。
如前文所述，現在多數人經常依賴用戶名和密碼進行數字識別，由此產生了諸多問題。Windows CardSpace 作為較大的標識元系統的組成部分，提供了解決這些問題的可選方法。若要更深入地了解 CardSpace 是如何實現的，應從了解標識元系統的基本概念入手。
Windows CardSpace 和標識元系統
當用戶訪問應用程式時，無論所使用的是 Web 瀏覽器還是應用程式特定的客戶端，或者其他形式，一般都會提供某種數字標識。數字標識各種各樣，但實際上都可由網路上的一個安全令牌表示。簡單的安全令牌可能只是一個用戶名，複雜的令牌則可能包含一個 X.509 證書或一個 XML 文檔。無論通過何種方式，安全令牌都是目前網路上表示數字標識的典型機制。
我們可以美好地憧憬，總有一天所有人都會採用相同的安全令牌格式，但實際上各種方式仍將繼續使用。現在我們會在錢包中攜帶各種標識卡，如駕駛執照、信用卡、航空公司常飛旅客積分卡等，與此類似，我們會始終使用由各種安全令牌表示的數字標識。沒有單個標識系統可以提供通用的方案，所以多個安全令牌將始終是必需的。
然而，用戶仍需要某種方式來一致地處理不同的數字標識。即使沒有單個標識系統可以勝任，也可以創建一個標識系統的子系統，即標識元系統，從而以一致的方式使用各種數字標識。Microsoft 與其他公司通力協作，引領著定義該元系統的進程。該元系統基於開放的 Web 服務技術，如 WS-Security 和 WS-Trust 等，可定義數字標識的獲取與使用方式，而無需考慮其所依賴的安全令牌類型。
發行、獲取和使用數字標識的過程可以視作是獲取三個不同角色的過程。這些角色如下：
• 用戶：有時稱為主體，用戶是具有數字標識的實體。
• 標識提供者：標識提供者可以為用戶提供數字標識。例如，對僱主分配給您的數字標識而言，標識提供者一般是諸如 Active Directory 的系統。對於您使用的 Amazon 數字標識而言，標識提供者將只對您有效，因為您可以定義自己的用戶名和密碼。不同標識提供者所創建的數字標識可以包含不同的信息，並提供不同的用戶真實身份保證級別。
• 依賴方：依賴方是一個應用程式，以某種方式依賴於數字標識。依賴方將頻繁使用標識（即該標識安全令牌中包含的信息）來驗證用戶，然後作出授權決定，如批准該用戶訪問某信息等。依賴方也會使用該標識獲得信用卡號，來驗證不同時間或出於不同目的而進行訪問的同一用戶。依賴方的典型示例包括 Internet 網站，如銀行、網上商店和拍賣站點，以及其他通過 Web 服務接受請求的所有應用程式。
這三種實體在標識元系統中進行互動。圖 11 說明了這種互動作用，以及 CardSpace 的適當位置。
用戶通過 CardSpace 識別應用程式訪問依賴方時，這一過程就會開始。要了解此依賴方將請求哪種類型的安全令牌，應用程式必須取得依賴方的策略（步驟 1）。以用於訪問網站的瀏覽器為例（這可能是最常見的情況），站點策略的表達方式為 HTML，並作為網頁的一部分傳送回來。但是，對於通過 Web 服務訪問的應用程式來說，應用程式將改為使用由 WS-MetadataExchange 定義的行業標準協定來向依賴方請求獲取其策略。在這種情況下，該策略使用另一種行業標準 WS-SecurityPolicy 來表示。無論以何種方式獲得策略信息，都會始終指明該依賴方將會接受的安全令牌類型，以及這些令牌中所必須包含的信息。
一旦 CardSpace 了解到依賴方需要的安全令牌類型後，會顯示之前所示的標識螢幕。對該用戶可用的每個數字標識在此螢幕上表示為一個信息卡。由外部依賴方發行的卡稱之為受管卡，而由 CardSpace 自發行提供程式發行的卡稱之為自發行卡。兩種卡都在此螢幕上顯示，用戶可以任選其一。為了更加方便做出選擇，螢幕會將所有不符合要求的信息卡顯示為灰色，從而指示出能夠滿足依賴方要求的標識。然後，用戶就可以從中任意選擇一個作為要使用的數字標識（步驟 2）。
但是，卡中並不包含實際的安全令牌。相反，它含有的是用於查找特定標識提供者以及為該用戶請求安全令牌所必需的信息。（實際上，所有信息卡最初都是由某些標識提供者創建的。）CardSpace 以用戶所選信息卡中包含的內容向發行此卡的標識提供者請求安全令牌（步驟 3）。該請求是使用另一種行業標準協定 WS-Trust 發出的，並且用戶使用 Kerberos（X.509 證書和數字簽名）或另外一種機制來向標識提供者進行自我身份驗證。令牌以加密形式返回，其中還包含了一個時間戳，以防止令牌被盜並於日後重新使用。
請求的安全令牌返回後會傳送到依賴方（步驟 4）。依賴方使用令牌信息的方式有所不同。例如，如果令牌中包含一個 X.509 證書，並附帶數字簽名，則依賴方將有可能使用令牌來驗證用戶。但是，使用令牌驗證或進行其他任何安全相關目的操作時沒有任何要求。（實際上，術語“安全令牌”本身就是用詞不當。）令牌中可以含有如用戶年齡證明、購物網站享受優惠資格以及其他信息。身份驗證是安全令牌一種重要但非唯一的使用目的。
需要十分注意的是，作為整體來講，無論是 CardSpace 還是標識元系統都不了解用於安全令牌的格式或技術。元系統的目標是提供一致的方法來使用基於任何類型安全令牌的所有數字標識，而不僅僅是嘗試為數字標識創建新的單一源或為安全令牌創建標準格式。通過提供元系統關鍵部分的 Windows 實現，CardSpace 在實現數字標識的常規方法過程中扮演著一個很重要的角色。
防止網頁仿冒
標識提供者通常與用戶不同，例如在標識由僱主分配時。但是在很多情況下，標識提供者即為用戶自身。例如，如果沒有使用 CardSpace，則訪問許多網站都需要提供用戶名和密碼，而這兩者都是由用戶定義的。一旦用戶創建標識之後，他們就可以將其用於提供用名和密碼，然後可以查詢銀行餘額、購買書籍或進行站點允許的其他任何操作。
但是如上所述，由於他們仍然依賴密碼，所以這種自發行標識容易成為攻擊者的目標，。為幫助減少此類攻擊，CardSpace 提供了另外一種創建自發行標識的方法。該自發行標識提供者在用戶的 Windows 系統上本地運行。自發行標識提供者創建的安全令牌不是依賴於用戶名和密碼，而是使用安全聲明標記語言（SAML，一種 OASIS 定義的標準）進行定義。這些令牌依靠公鑰技術而不是依靠密碼來驗證用戶標識。如果依賴方接受他們，則他們就可以起到與傳統用戶名和密碼相同的作用。好處是將不再存在網頁仿冒者可以盜取的密碼。減少密碼的使用，再有如上所述高度保險認證提供更嚴格的網站標識證明，能夠大幅降低網頁仿冒所造成的危害。
Windows CardSpace 和其他 Microsoft 技術
CardSpace 涉及到數項其他 Microsoft 技術，其中包括：
• WCF：由於依賴 Web 服務標準，例如 WS-Security 和 WS-Trust，因此 CardSpace 使用 WCF 進行通信。實際上，WCF 應用程式的創建者只需指定一個特別綁定，就可以讓該應用程式使用 CardSpace。
• Active Directory：雖然現在還無法實現，但 Active Directory 終將成為元系統中的一個標識提供者。
• Windows Live ID（以前稱為 Passport）：正如 Active Directory 一樣，Microsoft 業已宣布會將 Live ID 驗證系統修改為一款標識提供者。請注意，不能使用 CardSpace 來代替 Live ID，因為這兩者用於解決完全不同的問題。相反，正如其他任何標識提供者一樣，Live ID 將成為標識元系統的一部分。
Microsoft 還提供其他標識相關技術，用以解決與 CardSpace 不同的問題。例如，Active Directory Federation Services (ADFS) 主要關注於組織之間的聯合標識。這是一項重大的挑戰，許多需要與其他組織合作的公司都面臨著這一挑戰。但是，此問題與 CardSpace 和標識元系統所解決的更廣泛的問題完全不同。
Windows Presentation Foundation
基於工作流的邏輯、面向服務的通信和標識都是現代應用程式中的重要組成部分。但是，用戶通常最關注的是他們所看到的：用戶界面。WPF 的目的是為了解決現代應用程式中創建用戶界面所遇到的挑戰。WPF 提供了一系列相應功能來滿足這些需求，如下所述。
Windows Presentation Foundation 功能
開發人員完全可以使用 C#、Visual Basic 或一些其他基於 CLR 的語言來自由構建 WPF 應用程式界面。但是，如前文所述，WPF 也允許使用基於 XML 的 XAML 來指定界面。XAML 中的元素和屬性可直接映射到 WPF 提供的類和屬性。例如，在下面的簡單示例即使用 XAML 來定義按鈕：
<Button Background="Red">
No
</Button>
該示例創建了一個包含文本“No”的紅色按鈕。使用如下代碼也可以達到完全相同的效果：
Button BTN = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";
無論如何定義，實際上所有 WPF 應用程式都遵循相同的基本模型。應用程式可繼承 WPF 的標準應用程式對象，以提供基本方法、事件和屬性。WPF 應用程式既可以擁有傳統的對話框驅動界面，也可以擁有導航式界面，其功能更類似於一個瀏覽器應用程式。以後者樣式構建的應用程式通常作為一組頁面實現，每個頁面中包含以 XAML 定義的用戶界面和以代碼定義的某些邏輯關係。為了將這些頁面連結在一起，XAML 還提供了一個與 HTML 十分類似的超連結元素。應用程式每次顯示一個頁面，可使用戶在這些頁面之間前進或後退、維護歷史記錄列表以及其他功能等。儘管不需要，導航應用程式還是可以作為 XBAP 在 Web 瀏覽器內運行；開發人員也可以在安裝版 WPF 應用程式中自由使用該界面樣式。其目的是構建出融合瀏覽器界面與本地 Windows 界面最佳特點的軟體。
無論其界面使用哪種樣式，WPF 應用程式都可以通過面板進行基本布局。每個面板通常包含多個控制項，這些由 WPF 提供的控制項包括按鈕、文本框、組合框、選單以及其他對象。這些控制項如何放置取決於所選擇的面板類型。例如，Grid 允許將控制項放在指定的格線上，而 Canvas 則允許開發人員將控制項放在其界限範圍內的任何位置。在 GUI 中，通常用戶生成的事件由應用程式中的不同控制項和其他類進行捕獲和處理。還可以將樣式和模板套用到控制項組，這樣就可以非常容易使應用程式具有一致的外觀。
WPF 的支持範圍遠遠超出了上述的基本用戶界面功能，還包括：
• 文檔：WPF 應用程式可以使用 XAML 的 FixedDocument 標記來顯示 XPS 文檔。也可以使用 FlowDocument 標記來顯示流文檔。流文檔與傳統的螢幕文檔類似，能夠讓用戶滾動瀏覽其內容。另外，開發人員通過設定此標記的不同屬性，可以使文檔更適應其環境。例如，文檔可以每次顯示一頁，這樣讀者就不必上下滾動頁面了。WPF 還能夠根據顯示文檔的視窗大小來自動確定應該把文檔拆分成多少列。其目的是儘量提高螢幕上文檔的可讀性。
• 圖形：WPF 還支持創建二維和三維矢量圖形。對於二維作業，WPF 可提供標準抽象，例如形狀、畫筆和繪圖筆，同時還允許三維圖形定義模型，以用於指定光線和攝像機位置信息。與早期技術（例如 Windows Forms 需要依賴於 GDI+ 才能繪製圖形）不同的是，WPF 圖形並不是使用開發人員所必須了解的單獨一組概念來進行分區的。相反，用於圖形的 XAML 元素能夠與那些用戶界面其他方面的元素自然組合。按鈕可帶有圖形內容，文本和圖形可以組合，以及其他更多功能。
• 圖像：使用 XAML 的圖像標記，WPF 應用程式可以顯示不同格式的圖形，包括 JPEG、GIF 以及其他格式。WPF 依靠 Windows Imaging Component (WIC) 為編解碼器以及顯示和存儲圖像的軟體提供標準框架。在 WPF 中，通常圖像元素可以與其他元素組合，能夠讓按鈕顯示圖像而不是簡單的文本標籤。
• 媒體：WPF 應用程式可以使用 MediaElement 標記來顯示不同格式的視頻和音頻，包括 WMV、AVI 和 MPEG。同樣，此元素也可與其他 XAML 元素相組合，例如使三維立方體的所有側面上都顯示視頻。
• 動畫：WPF 提供動態顯示絕大部分用戶界面的內置支持。例如，放大和縮小圓圈、順利地更改按鈕大小。應用程式還可以定義包含時間線的情節提要，允許調整動畫的發生順序。
• 數據綁定：由於許多 WPF 應用程式都需要顯示數據，因此提供將數據映射到用戶界面元素的自動支持功能是很有幫助的。WPF 可為包含在對象和其他源中的信息提供此類數據綁定。WPF 數據綁定還允許在顯示數據前對其進行排序和篩選。
