.Net Framework 3.0介紹


轉自MSDN:http://www.microsoft.com/china/MSDN/library/netFramework/netframework/intronetfx30.mspx?mfr=true

描述 .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 和上述四個新組件的功能。

.

圖 1

.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 引擎執行的活動。一個活動就是一個類,它可以包含工作流創建者認為有必要的任何工作。活動可以在不同的工作流中重復使用,因此,在針對新問題創建自動化的解決方案時,過程將會更加容易。

.

圖 2

提供通用工作流技術面臨另一個困難是,面向人員工作流和面向系統工作流的傳統分歧。通常來說,工作人員使用的工作流應用程序需要有較高的靈活性,能夠進行實時更改。而一般由系統,也就是由軟件使用的工作流應用程序則相對更加靜態,但要求盡可能高效。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 所示。您可以選擇一張卡片,這就相當於選擇了登錄該網站的數字標識。不必再去費心記住數不清的用戶名和密碼,用戶只要記住他們要使用的那張信息卡就可以了。不同的信息卡還包含其他信息,用戶可以通過它控制登錄網站時提交的信息。

.

圖 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 的部分功能。過去,開發人員需要懂得各種技術才能進行工作;而現在通過這種更為一致的方法,開發人員可以輕松制作出類似示例中的用戶界面。

.

圖 4

另外一個長期困擾用戶界面開發人員的問題是,如何創建高效界面需要的不同角色。軟件開發人員需要編寫相應的界面邏輯,但是,他們並不是定義界面感觀的最佳人選。一般來說,人機交互領域的設計人員和專家更適合這一工作。但是在以前的技術(如 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 所示的工作流程。

.

圖 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

.

圖 6

.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 提供的用於進行該項工作的組件。

.

圖 7

如前文所述,每個工作流都通過一定數量的活動創建。工作流和活動都屬於類,所以兩者均可由代碼直接創建。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 活動拖放到該工具的設計界面上,以創建工作流。

.

圖 8

一些開發人員不喜歡圖形設計器,他們更願意編寫代碼。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

如圖 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 給出了比較詳細的介紹。客戶端不直接訪問接口,而是連接到特定的端點。服務可以提供多個端點,從而允許不同的客戶端以不同方式進行訪問。

.

圖 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 的適當位置。

.

圖 11

用戶通過 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 數據綁定還允許在顯示數據前對其進行排序和篩選。

Windows Presentation Foundation 的應用

WPF 提供大量的用戶界面功能,使開發人員和設計人員可以創建出非常吸引人的用戶界面。但是無論客戶端應用程序看起來有多漂亮,如果存在部署問題的話,可能會使某些組織拒絕使用。如果推出的新版本客戶端涉及到安裝此應用程序的每台桌面電腦,則會導致高額的升級成本。現在,避免此問題的一個常用方法是創建基於瀏覽器的客戶端,而不是本地 Windows 客戶端。然而與瀏覽器相比,本地 Windows 客戶端通常擁有更好、響應更及時的用戶界面。為解決部署這些客戶端時所面臨的難題,就需要使用 ClickOnce 技術准備好安裝版 WPF 應用程序。ClickOnce 技術第一次應用於 .NET Framework 2.0,可使 Internet Explorer 用戶通過 Web 選擇應用程序,然后將其自動安裝在本地計算機上。安裝之后,應用程序還能夠在出現可用的新版本時進行自動更新。目的是將 Web 客戶端的簡單性和低成本部署與安裝版 WPF 應用程序強大功能結合起來。

尤其是在使用 ClickOnce 進行部署時,安裝版 WPF 應用程序在許多情況下都是很好的客戶端選擇。但即使其用戶可以從 WPF 界面中獲益,也存在不適用此類應用程序的情況。例如,回想一下上述的遠程保險代理商,或者希望提供三維圖形、視頻以及其他 WPF 現代功能的網上商店。奢望此類應用程序用戶通過安裝本地 WPF 應用程序來訪問網站通常是不切合實際的。更佳的解決方案是在用戶的 Web 瀏覽器內提供 WPF 樣式的界面。

XAML 瀏覽器應用程序 XBAP 即是針對這一問題而專門設計的。Internet Explorer 用戶可以將 XBAP 直接下載到瀏覽器,而不必部署安裝版 WPF 應用程序。此應用程序在 Internet Explorer 內運行,可以提供基於 WPF 的用戶界面。但是從 Internet 網站下載和運行代碼是一項危險的操作。為保護用戶免遭惡意開發者的攻擊,所有從 Internet 下載的 XBAP 都在部分信任沙箱中運行。基於 .NET Framework 提供的代碼訪問安全性,該沙箱會限制 XBAP 的操作。例如,從 Internet 下載的 XBAP 不能創建獨立窗口或啟動新窗口,不能顯示由 XBAP 本身啟動的保存對話框或訪問隔離存儲區以外的文件系統。盡管沙箱規定了種種限制,XBAP 仍然可以使用大部分的 WPF 功能,包括二維和三維圖形、動畫、屏幕文檔、圖像、視頻等。

如前文所述,WPF 可使用 XAML 的 FlowDocument 元素讓應用程序顯示適合的文檔。顯然,基於顯示方式而更改文檔外觀並不總是最好的解決方案。有時,固定格式文檔(在屏幕上和打印出來的效果始終相同)會是更好的選擇。WPF 的 XPS 文檔可解決這一問題。使用 XAML 子集予以定義之后,可以在安裝了 XPS 閱讀器的任何系統上閱讀 XPS 文檔。此外還提供了一種新的 Windows 打印格式,能夠以更高的保真度來打印復雜圖形。為了更加一致地與不同類型的文檔配合使用,XPS 文檔和 Office 2007 文檔都使用了 Microsoft 的“開放打包約定”,其中定義了存儲文檔內容、數字簽名文檔以及其他操作的常用方法。

Windows Presentation Foundation 工具

使用基本的文本編輯器就可以直接以代碼和/或 WPF 來創建任何的 WPF 用戶界面。但大多數人還是傾向於使用更好的工具,因此 Microsoft 提供了 Visual Studio 2005 的擴展,開發人員可以基於此來構建 WPF 應用程序。Visual Studio 的下一個版本(代號為“Orcas”)仍將為 Windows Presentation Foundation 提供更多的可視化設計器功能。使用該工具,開發人員能夠以圖形方式創建他們所希望的用戶界面,然后用工具生成此界面的代碼。

但是一般來講,開發人員不是定義用戶界面的最佳人選。設計人員通常更擅長此類工作,因為他們的工作就是與人交流。問題在於絕大多數設計人員並不編寫代碼,因而 Windows Presentation Foundation 可視化設計器(位於 Visual Studio 內)不是適用於該團隊的有效工具。為了保證設計人員在 WPF 環境下的高效工作,Microsoft 推出了 Expression Interactive Designer。設計人員可以使用該工具來執行定義界面感觀、指定動畫等操作,然后將所創建內容生成 XAML 版本。開發人員將此 XAML 版本導入 Visual Studio 之后,就可以為事件處理等內容添加代碼。由於 Visual Studio 和 Expression Interactive Designer 使用相同的生成系統,因此開發人員和設計人員可以使用其各自熟悉的工具反復處理一個項目。其目的是幫助來自設計與軟件工程這兩個不同學科的人員高效地協同工作。

Windows Presentation Foundation 和其他 Microsoft 技術

與其他 .NET Framework 3.0 組件一樣,WPF 對現有 Microsoft 技術也有所影響。其中受到影響最大的有:

Windows Forms:.NET Framework 最初用於創建 GUI 的方法,現在許多應用程序中都用到 Windows Forms。考慮到這一點,WPF 應用程序中允許托管 Windows Forms 控件,同時允許在 Windows Forms 應用程序中托管 WPF 控件。例如,Windows Forms 應用程序中可以托管能夠提供三維數據可視化的 WPF 控件。雖然有一些限制,但是肯定可以同時使用這兩種技術來構建應用程序。另請注意,現有 Windows Forms 應用程序仍可在 .NET Framework 3.0 環境中正常工作。

Win32 和 Microsoft 基礎類 (MFC):與 Windows Forms 一樣,可以在使用這些現有技術構建的現有 Win32 和 MFC 應用程序中托管 WPF 控件,反之亦然。但是其互操作性與 Windows Forms 相比有些復雜,原因是與 Windows Forms 的不同之處在於,基於 Win32 和基於 MFC 的應用程序並不是構建在 CLR 之上。因此,與 WPF 之間的互操作性還要求基於 CLR 的代碼與本地 Win32 代碼之間建立映射。

Direct3D:是 API DirectX 系列的組成部分,其作用是使應用程序創建和顯示三維圖形。隨着 .NET Framework 3.0 的面世,主流 Windows 應用程序都可以使用 WPF 中的三維功能,而不只局限於 Direct3D 提供的更專業方法。但一些需要較高性能的應用程序(例如三維游戲)仍將繼續使用 Direct3D。實際上在后台,WPF 仍依靠 Direct3D 來完成所有的圖形渲染工作。

Windows Communication Foundation:如上所述,WPF 應用程序可以使用 WCF。但是,XBAP 通常無法使用 WCF,因為 WCF 需要完全信任才可正常運行。從 Internet 下載的每個 XBAP 都在部分信任沙箱中運行,這就禁止了 XBAP 訪問 WCF。但是,XBAP 能夠使用 ASP.NET Web 服務來調用可與 WCF 和其他 Web 服務實現交互的 SOAP。

“WPF/E”:WPF 值得一提的另一個方面,盡管沒有包含在 .NET Framework 3.0 之內。其代號為“WPF/E”,目的是在本身不支持 WPF 的系統中提供 WPF 樣式界面支持。顧名思義,“E”表示該技術可用於任何地方,包括 Macintosh、小型設備以及其他系統。WPF/E 計划於推出 WPF 之后的某個時間發布,將提供全部 WPF 功能的一個子集,其中包括二維圖形、動畫和視頻。

獲取 .NET Framework 3.0:不同選項

對於要使用 .NET Framework 3.0 的應用程序,必須將此版本的 Framework 安裝在運行該應用程序的計算機上。這對於 Windows Vista 來說是非常簡單的:會在默認情況下安裝 .NET Framework 3.0。也就是說,安裝了 Windows Vista 的新計算機或升級到 Vista 的現有計算機都會自動安裝 .NET Framework 3.0 應用程序。另外,.NET Framework 3.0 也可以在 Windows XP 和 Windows Server 2003 上運行。為使這兩個系統的現有用戶能夠用到新的 .NET Framework 3.0 組件,Microsoft 提供該軟件的免費下載版本。

結論

.NET Framework 3.0 是由 Windows 編程模型演變而來。它建立於 .NET Framework 2.0 的基礎之上並加以擴展,目的是支持現代應用程序的構建。為此,該 3.0 版本采用了大量的最新技術,可以解決當今應用程序開發中的種種難題。通過在公共基礎上建立這種多樣性,Microsoft 致力於使軟件的整體效果大於各個部分之和,從而讓開發人員以更加一致的方式使用 .NET Framework 3.0 的不同部分來構建應用程序。

無論組織選擇采用此新版本的哪些方面,其中所蘊含的技術必定會對 Windows 軟件領域產生重大影響。對於該領域的所有人來說(無論是開發人員、設計人員或是決策者),現在是開始了解如何從 .NET Framework 3.0 獲益的時候了。

描述 .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 和上述四個新組件的功能。

.

圖 1

.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 引擎執行的活動。一個活動就是一個類,它可以包含工作流創建者認為有必要的任何工作。活動可以在不同的工作流中重復使用,因此,在針對新問題創建自動化的解決方案時,過程將會更加容易。

.

圖 2

提供通用工作流技術面臨另一個困難是,面向人員工作流和面向系統工作流的傳統分歧。通常來說,工作人員使用的工作流應用程序需要有較高的靈活性,能夠進行實時更改。而一般由系統,也就是由軟件使用的工作流應用程序則相對更加靜態,但要求盡可能高效。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 所示。您可以選擇一張卡片,這就相當於選擇了登錄該網站的數字標識。不必再去費心記住數不清的用戶名和密碼,用戶只要記住他們要使用的那張信息卡就可以了。不同的信息卡還包含其他信息,用戶可以通過它控制登錄網站時提交的信息。

.

圖 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 的部分功能。過去,開發人員需要懂得各種技術才能進行工作;而現在通過這種更為一致的方法,開發人員可以輕松制作出類似示例中的用戶界面。

.

圖 4

另外一個長期困擾用戶界面開發人員的問題是,如何創建高效界面需要的不同角色。軟件開發人員需要編寫相應的界面邏輯,但是,他們並不是定義界面感觀的最佳人選。一般來說,人機交互領域的設計人員和專家更適合這一工作。但是在以前的技術(如 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 所示的工作流程。

.

圖 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

.

圖 6

.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 提供的用於進行該項工作的組件。

.

圖 7

如前文所述,每個工作流都通過一定數量的活動創建。工作流和活動都屬於類,所以兩者均可由代碼直接創建。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 活動拖放到該工具的設計界面上,以創建工作流。

.

圖 8

一些開發人員不喜歡圖形設計器,他們更願意編寫代碼。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

如圖 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 給出了比較詳細的介紹。客戶端不直接訪問接口,而是連接到特定的端點。服務可以提供多個端點,從而允許不同的客戶端以不同方式進行訪問。

.

圖 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 的適當位置。

.

圖 11

用戶通過 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 數據綁定還允許在顯示數據前對其進行排序和篩選。

Windows Presentation Foundation 的應用

WPF 提供大量的用戶界面功能,使開發人員和設計人員可以創建出非常吸引人的用戶界面。但是無論客戶端應用程序看起來有多漂亮,如果存在部署問題的話,可能會使某些組織拒絕使用。如果推出的新版本客戶端涉及到安裝此應用程序的每台桌面電腦,則會導致高額的升級成本。現在,避免此問題的一個常用方法是創建基於瀏覽器的客戶端,而不是本地 Windows 客戶端。然而與瀏覽器相比,本地 Windows 客戶端通常擁有更好、響應更及時的用戶界面。為解決部署這些客戶端時所面臨的難題,就需要使用 ClickOnce 技術准備好安裝版 WPF 應用程序。ClickOnce 技術第一次應用於 .NET Framework 2.0,可使 Internet Explorer 用戶通過 Web 選擇應用程序,然后將其自動安裝在本地計算機上。安裝之后,應用程序還能夠在出現可用的新版本時進行自動更新。目的是將 Web 客戶端的簡單性和低成本部署與安裝版 WPF 應用程序強大功能結合起來。

尤其是在使用 ClickOnce 進行部署時,安裝版 WPF 應用程序在許多情況下都是很好的客戶端選擇。但即使其用戶可以從 WPF 界面中獲益,也存在不適用此類應用程序的情況。例如,回想一下上述的遠程保險代理商,或者希望提供三維圖形、視頻以及其他 WPF 現代功能的網上商店。奢望此類應用程序用戶通過安裝本地 WPF 應用程序來訪問網站通常是不切合實際的。更佳的解決方案是在用戶的 Web 瀏覽器內提供 WPF 樣式的界面。

XAML 瀏覽器應用程序 XBAP 即是針對這一問題而專門設計的。Internet Explorer 用戶可以將 XBAP 直接下載到瀏覽器,而不必部署安裝版 WPF 應用程序。此應用程序在 Internet Explorer 內運行,可以提供基於 WPF 的用戶界面。但是從 Internet 網站下載和運行代碼是一項危險的操作。為保護用戶免遭惡意開發者的攻擊,所有從 Internet 下載的 XBAP 都在部分信任沙箱中運行。基於 .NET Framework 提供的代碼訪問安全性,該沙箱會限制 XBAP 的操作。例如,從 Internet 下載的 XBAP 不能創建獨立窗口或啟動新窗口,不能顯示由 XBAP 本身啟動的保存對話框或訪問隔離存儲區以外的文件系統。盡管沙箱規定了種種限制,XBAP 仍然可以使用大部分的 WPF 功能,包括二維和三維圖形、動畫、屏幕文檔、圖像、視頻等。

如前文所述,WPF 可使用 XAML 的 FlowDocument 元素讓應用程序顯示適合的文檔。顯然,基於顯示方式而更改文檔外觀並不總是最好的解決方案。有時,固定格式文檔(在屏幕上和打印出來的效果始終相同)會是更好的選擇。WPF 的 XPS 文檔可解決這一問題。使用 XAML 子集予以定義之后,可以在安裝了 XPS 閱讀器的任何系統上閱讀 XPS 文檔。此外還提供了一種新的 Windows 打印格式,能夠以更高的保真度來打印復雜圖形。為了更加一致地與不同類型的文檔配合使用,XPS 文檔和 Office 2007 文檔都使用了 Microsoft 的“開放打包約定”,其中定義了存儲文檔內容、數字簽名文檔以及其他操作的常用方法。

Windows Presentation Foundation 工具

使用基本的文本編輯器就可以直接以代碼和/或 WPF 來創建任何的 WPF 用戶界面。但大多數人還是傾向於使用更好的工具,因此 Microsoft 提供了 Visual Studio 2005 的擴展,開發人員可以基於此來構建 WPF 應用程序。Visual Studio 的下一個版本(代號為“Orcas”)仍將為 Windows Presentation Foundation 提供更多的可視化設計器功能。使用該工具,開發人員能夠以圖形方式創建他們所希望的用戶界面,然后用工具生成此界面的代碼。

但是一般來講,開發人員不是定義用戶界面的最佳人選。設計人員通常更擅長此類工作,因為他們的工作就是與人交流。問題在於絕大多數設計人員並不編寫代碼,因而 Windows Presentation Foundation 可視化設計器(位於 Visual Studio 內)不是適用於該團隊的有效工具。為了保證設計人員在 WPF 環境下的高效工作,Microsoft 推出了 Expression Interactive Designer。設計人員可以使用該工具來執行定義界面感觀、指定動畫等操作,然后將所創建內容生成 XAML 版本。開發人員將此 XAML 版本導入 Visual Studio 之后,就可以為事件處理等內容添加代碼。由於 Visual Studio 和 Expression Interactive Designer 使用相同的生成系統,因此開發人員和設計人員可以使用其各自熟悉的工具反復處理一個項目。其目的是幫助來自設計與軟件工程這兩個不同學科的人員高效地協同工作。

Windows Presentation Foundation 和其他 Microsoft 技術

與其他 .NET Framework 3.0 組件一樣,WPF 對現有 Microsoft 技術也有所影響。其中受到影響最大的有:

Windows Forms:.NET Framework 最初用於創建 GUI 的方法,現在許多應用程序中都用到 Windows Forms。考慮到這一點,WPF 應用程序中允許托管 Windows Forms 控件,同時允許在 Windows Forms 應用程序中托管 WPF 控件。例如,Windows Forms 應用程序中可以托管能夠提供三維數據可視化的 WPF 控件。雖然有一些限制,但是肯定可以同時使用這兩種技術來構建應用程序。另請注意,現有 Windows Forms 應用程序仍可在 .NET Framework 3.0 環境中正常工作。

Win32 和 Microsoft 基礎類 (MFC):與 Windows Forms 一樣,可以在使用這些現有技術構建的現有 Win32 和 MFC 應用程序中托管 WPF 控件,反之亦然。但是其互操作性與 Windows Forms 相比有些復雜,原因是與 Windows Forms 的不同之處在於,基於 Win32 和基於 MFC 的應用程序並不是構建在 CLR 之上。因此,與 WPF 之間的互操作性還要求基於 CLR 的代碼與本地 Win32 代碼之間建立映射。

Direct3D:是 API DirectX 系列的組成部分,其作用是使應用程序創建和顯示三維圖形。隨着 .NET Framework 3.0 的面世,主流 Windows 應用程序都可以使用 WPF 中的三維功能,而不只局限於 Direct3D 提供的更專業方法。但一些需要較高性能的應用程序(例如三維游戲)仍將繼續使用 Direct3D。實際上在后台,WPF 仍依靠 Direct3D 來完成所有的圖形渲染工作。

Windows Communication Foundation:如上所述,WPF 應用程序可以使用 WCF。但是,XBAP 通常無法使用 WCF,因為 WCF 需要完全信任才可正常運行。從 Internet 下載的每個 XBAP 都在部分信任沙箱中運行,這就禁止了 XBAP 訪問 WCF。但是,XBAP 能夠使用 ASP.NET Web 服務來調用可與 WCF 和其他 Web 服務實現交互的 SOAP。

“WPF/E”:WPF 值得一提的另一個方面,盡管沒有包含在 .NET Framework 3.0 之內。其代號為“WPF/E”,目的是在本身不支持 WPF 的系統中提供 WPF 樣式界面支持。顧名思義,“E”表示該技術可用於任何地方,包括 Macintosh、小型設備以及其他系統。WPF/E 計划於推出 WPF 之后的某個時間發布,將提供全部 WPF 功能的一個子集,其中包括二維圖形、動畫和視頻。

獲取 .NET Framework 3.0:不同選項

對於要使用 .NET Framework 3.0 的應用程序,必須將此版本的 Framework 安裝在運行該應用程序的計算機上。這對於 Windows Vista 來說是非常簡單的:會在默認情況下安裝 .NET Framework 3.0。也就是說,安裝了 Windows Vista 的新計算機或升級到 Vista 的現有計算機都會自動安裝 .NET Framework 3.0 應用程序。另外,.NET Framework 3.0 也可以在 Windows XP 和 Windows Server 2003 上運行。為使這兩個系統的現有用戶能夠用到新的 .NET Framework 3.0 組件,Microsoft 提供該軟件的免費下載版本。

結論

.NET Framework 3.0 是由 Windows 編程模型演變而來。它建立於 .NET Framework 2.0 的基礎之上並加以擴展,目的是支持現代應用程序的構建。為此,該 3.0 版本采用了大量的最新技術,可以解決當今應用程序開發中的種種難題。通過在公共基礎上建立這種多樣性,Microsoft 致力於使軟件的整體效果大於各個部分之和,從而讓開發人員以更加一致的方式使用 .NET Framework 3.0 的不同部分來構建應用程序。

無論組織選擇采用此新版本的哪些方面,其中所蘊含的技術必定會對 Windows 軟件領域產生重大影響。對於該領域的所有人來說(無論是開發人員、設計人員或是決策者),現在是開始了解如何從 .NET Framework 3.0 獲益的時候了。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com