深入淺出 .NET Framework 3.0

 
您 WinFX 了嘛 ?
If you are a developer, and you don’t like change, you should get out of this business as early as possible.
By David Chappell, Boston, Tech.Ed, 2006
不論您過去是否聽過 WinFX，您的未來，將不再聽見到這個名詞。2006年美國 Boston Tech.Ed 週，一個風光明寐的下午，管那台灣天天吹著政治風，微軟總部正式宣告了進入 .NET 3.0 的里程碑，並且開開心心的將 WinFX 重新命名為 .NET Framework 3.0。
Yes, 是真的, MS did it again !
只是除了 change, 我們不禁要問.. Why change? What to be change. ?
本文的目的，再和您分享一份 .NET 3.0 的新消息. 也希望能讓您了解到 .NET 3.0 的領域本質
.NET Framework 3.0 = WinFX
WinFX 是微軟在 .NET平台的基礎元件服務中，在.NET Basic Class Library (BCL) 下，堆疊出的新技術元件，這些元件架構，在過去沸沸騰騰的炫燿了一段時間，分別為：

圖表 1
§ Window Presentation Framework (WPF)
§ Windows Communication Framework (WCF)
§ Windows Workflow Foundation (WF)
§ Windows CardSpace (WCS)
論壇上有許多關心 MS 平台技術的鄉親父老，目前熱烈的把砲口對準了 這個全新的架構，一個基本的問題，MS 又稿了一個新的版本? 我們好不容易才 upgrade 到.NET 2.0, 好不容易才花錢買了 VS2005 開發，好不容易習慣 2.0 的架構，怎麼3.0 又來了，那天殺的相容性 ?
事實上，親愛的鄉親父老們，請先別擔心，如同前面描述，WinFX/.NET 3.0 技術，是採用了.NET現有平台，也就是 CLR 2.0 的平台，進行加值的運用元件技術，換句話說，您的 VS2005 開發工具，是可以用來開發 年底就將上場的 .NET 3.0 新元件，您已經習慣的軟體環境與平台，一切依舊的。
只是在我清楚的描述以後，相信另一票論壇上的叔叔伯伯又不開心了，因為這聽起來是 MS 是提供了新的軟體元件，底層還是在 CLR 2.0 上，那既然這樣 WinFX 元件聽起來多屌，搞成這樣多讓人容易搞不清楚狀況啊…。 難不成以後 .NET 4.0 會是 BCL 3.5 加上 CLR 3.0 ??? 粉亂的勒!
Well 您說的是，但您曉得的，替您的小孩取名子一值都是一件困擾的事情， 林大X 老師 與 廟口鐵口大師，剛好給了我兩個不同的名子， 我的寶貝未來實在難以決定呢… 我們能做的事情，是盡可能的讓您保持雪亮的眼睛，清楚的判斷名詞背後的 .NET 的本質
NET Framework 3.0 … 原來如此

圖表 2
口號有口號的空間，品牌有品牌的說法，但回到 Developer 與 Designer 的觀點，.NET Framework 的領域，在討論的領域其實可以由上圖表2來解釋。圖表2 描述了一個標準的軟體系統互動空間，事實上，這正是我們過去受到完整訓練的軟體結構之一，偉大的 MVC 設計樣式。不意外的，這也是現在軟體內觀的本質結構之一，也是 .NET Framework 3.0 (WinFX) 的技術領域空間。Windows Presentation Framework (WPF)
軟體技術上，UI的呈現一項是個好的問題，但更大的問題，其實在 製作的方法，效率，溝通，品質上；一個美美的 UI，通常是經由一群軟體工程師，一群構思靈敏的美工設計團隊，一組以客戶至上為天職的 Product Manager所構成的。一個最終的 UI 往往是經過團隊不斷反覆的討論設計，改code, 改 Layout, 重寫 code…… 一堆可樂衛生紙的故事。 得來不易…
然而，自 XML 相關技術問世以來，事情有了新的突破，我們現在有一個好的方法，將 XML 透過 XSL 等轉譯技巧，來做到 UI 的描述與定義。

圖表 3
同樣的資料，轉化為 WAP 以後，您可以在手機上享受豐富的圖文資訊，轉化為 HTML 以後，您可以在瀏覽器上看到另您臉紅心跳的圖文，轉換為 RSS 之後，您可以在 RSS 新聞讀取工具中，訂閱豐富的網路文章日誌。
相同的到理，在本質上 WPF 也是這樣的設計理念，微軟透過了 XML 與轉換的運用，讓資料與呈現多了最新的運用。

圖表 4
這個運用的結果第一步呈現在，軟體設計的團隊與方式的變化，

圖表 5
借用Java的口號『Write Once, run everywhere』，而我們相信，這一次UI系統的設計讓軟體的架構與產值又向前突破了一個新的里程碑。
既然有了 XAML，接下來的MS 需要做的事情是，將 CLR 與 IE 7 做好解析 XAML 的功能，您所撰寫的 .NET 應用程式，編程為 XAML，然後最終可以無嫌隙的直接執行在 瀏覽器端，或是您的單機作業系統上 (win form)。
美妙的願景Windows Communication Framework (WCF)
由 Client 端存取『遠端不同處理程序的元件』，過去已經有了許多的軟體技術在其中，在 .NET 問世以來，微軟教育我們，在不同的需求下，我們可以採用不同的軟體技術架構達到目的。
比方說，如果您的後端服務系統平台，完全沒有不同平台的考量，那麼 .NET Remoting 是您最佳的伴侶；如果您後端系統中有了跨平台服務的需求，那麼您需要的是 .NET Web Service 的軟體架構；如果您需要考量嚴謹非凡的整合架構，您可以採用 WS-* 介面也就是 Web Service Enhancement軟體架構；當您有需要做到 Queue 的存取服務，您千萬記得使用 MSMQ的軟體元件服務…..
當我在台北時請打 02, 在台灣需加 886, 打新竹要加 03….. 找我在房間，請打 27221234, 找我在客廳，請電 27225678….. 拜託給我一隻手機吧
微軟真的做了，給軟體人員一隻新的手機，這隻手機的目的，在讓您不用在關心對方是0204還是0954…，因為這一類的組態資訊，往往是一開始就寫死在軟體架構中的，想想看，萬一天殺的系統由 WS介面，升級為 WS-* 協定，或是改為 Remoting 接口，您已經佈署在外的 上萬個子系統應用程式，要怎樣回收改版呢?
Wow… 這似乎是不合理的，對於提倡 COM 設計概念的 微軟而言，一值以來在追求的是 IUnknown 的設計精神，應該有一種設計架構，軟體機制，能夠完全隱藏掉軟體夠通的細節，然而也許這是一個新的 Vision，但今天，微軟告訴我們，在未來微軟平台中，您需要的只有一種技術，Windows Communication Framework.

圖表 6Windows Workflow Foundation (WF)
在繼續之前，筆者斗膽先請問您，『說到 workflow 您想到的是什麼 ?』
微軟在 2006 年拋出來了一個新的軟體架構，叫做 WF, 說實在的嚇壞了許多人，特別是環繞在微軟平台提供服務的協力廠商，原因很簡單，因為 workflow 有太多太多的偉人，給他太多太多的描述。
罄竹難書
我無意在這裡搞政治，只是一個簡單的笑話，讓各位了解，一個單字一但被太多人過分解釋，造成的影響，相當可觀的。因此在談 WF 的情況下，我們只有採用最基本的 八股教學法，給您一個新的定義，一個來自微軟官方最貼切的說法。
微軟在這裡談起了Workflow，其實有很多理由，其中一個理由在微軟內部的不一致性；事實上，微軟內部有許多不同的軟體產品，這些產品都會有著Workflow的功能需求，在過去，因為微軟的工程師每一個都是身上有好幾把刀的，所以面對 Workflow的需求，大夥都是傢伙抄起，就快速的幹了下去；這個結果下，微軟很快的也發現到，這樣的重複 Function，而且完全不一致，造成了微軟內部軟體的無法有效整合，資源無法共用的困境。(業帳不是不到，只是時候未到呢)。同時微軟也發現，原來不是只有他有這樣的問題….
微軟的 WF 其實是一種元件的架構，一個核心的執行引擎，一系列的 API Library.讓您去定義 Activity 流程、State 轉移順序；

圖表 7
自WF計畫開始以來，微軟便開始規劃未來在Window平台上的任何MS產品，都要陸續採用 WF 作為核心元件，讓軟體系統能夠達到一致，更提供更大的相互整合空間。
同時，當WF提出以後，市場上即刻就多了一些新的市場商機 (當然也間接的影響到了某些 ISV)。未來您可以期望在市場上，買到 “符合標準ABC的管理流程”，買到“標準XYZ的訂單處理流程”，買到 “遠端MMS/3G 傳呼流程”… 。您也可以期望 您所採用的軟體流程，不是只有某廠商的平台才能正常運作執行，只要是符合 WF 規格，您的流程式可以安全轉移平台的。
而說到平台，我們就不得不在談 WF 的執行平台。

圖表 8
在微軟 WF 架構下，未來的WF基礎開發的流程系統，將是需要一個“Host Process”，這個” Host Process” 可以是您自行開發的 Windows Service、Windows Form、ASP.NET 應用程式；又或者是某協力廠商提供的 Workflow 應用平台。同時微軟自己在 即將上市的 Office 2007中，也提供了一個基礎的 “Host Process” 環境，讓Office 2007 的使用者，透過 Office 2007 來執行標準的 WF 流程系統。
事實上，這玩意就是 Windows SharePoint V3. 您可以在這個平台上定義工作流程，文件流程，與MS Office文件整合
同時，我們也注意到了，在WF架構下，Default Developer是要透過 Visual Studio 來開發 WF 流程系統，微軟在 WF 元件函式庫中，提供了一系列標準的 BAL (Basic Activity Library)。
最後一個細節也是必須和各位報告的，一個 Workflow 整合的解決方案，決對不是只有一系列的流程、Host Process、就搞定的，一但Workflow簽扯到 交易，管理，追蹤..等，那就需要一系列的 Runtime Services 提供服務。比如，您的 Workflow 需要您的老闆簽呈，但您得老闆出差三天，您需要等他回國才能回應，您的 Workflow 就必須安靜的躺在某個空間中，但絕對不是 Host Process，除非您的系統不考慮效能與穩定。您的Workflow簽扯到不同系統的繞送交易，您必須要讓 Workflow 能夠做到 Two phase 補償交易，同時還要能追蹤管理；諸如此類的Workflow的細節，您會需要這些 Runtime Services。
WF 針對這一類的 Runtime Services 服務，是有提供了一系列 Core API 讓軟體人員自由興建，但代價是，您要花時間 Coding.
怎麼我怎麼聽都像是BizTalk
如果您還有這個困擾，那麼請您試著聯想一下， WF 核心技術所提供的就像是一顆強力的引擎，以及一系列的輪子。但 BizTalk 給您的就是一個完整的 VW 跑車，舒適安全，有外殼，有皮椅，還有冬暖夏涼的恆溫裝置。
如果說困擾您的是目前 BizTalk 2006 的引擎還不是 WF 技術做的，請別擔心，微軟承諾在下個版本，更新整個 Orchestration 引擎，100% WF Inside，同時也會提供轉換引擎的工具
所以結論是，如果您在乎的是商業本質，重視結果，那麼 BizTalk 是您在微軟平台上最佳的方案；但如果您的腳色是和我一樣黑不溜丟的黑手，那麼深入 WF 元件技巧，就是您責無旁貸的任務。Windows CardSpace (WCS)
InfoCard，是微軟 CardSpace 的前身，說真的，這兩個版本的名稱，都環繞在 “Card” 的本身，而這也是 WCS 的設計核心抽象理念：『每個人都有好多張卡』。這些卡是用來代表 某一個情節下，我個人的身分地位。微軟抽用了這個概念，在軟體系統中，在廣大的網海中，不同的應用程式，不同的網站，您都應該有張卡，來代表您的尊貴身分。
我的 Cosco 卡代表了我曾經付了 1200 元年費，我可以自由進出消費 Cosco。
我的 花旗白金卡代表了我一狗票的負債，卡奴找我不是別人。
我還有一堆的卡，用來表示我的身分，當然是在不同的情境之中。
在微軟設計 CardSpace的理念，除了抽象的用意之外，另一個最大的目的就是對附廣大的網路釣客，那些專門誘拐您到不同網站，騙取您的帳號密碼，那些想盡辦法攔截您的訊息，抽取您的帳號密碼。
事實上，如果網路釣客是一群邪惡的混蛋，微軟深深的認為，對於經驗不豐富的使用者來說，他們的帳號和密碼就像是午夜穿著超短熱酷的辣妹，引誘著人犯罪。
在新的 CardSpace 架構中，使用者不在需要針對應用系統或網站，提供您的帳號密碼，相對的，提供一組經由您私鑰簽章的卡片，只要真的是您所要去拜訪的系統與網站，他們能用您公佈的公鑰做訊息交換；而這個時候網路釣客，即使他們竊取到您的卡片，但在沒有把你的整台機器偷走，A到您的私鑰之前，他是決對無法冒充您的身分的。
這裡馬上就有了一個直接的問題，『既然卡片這樣重要，究竟是誰能夠製作與提供這樣的卡呢？』
WCF 軟體技術 Default 提供了兩種不同的卡片種類，一種是使用者自行製作的卡片，一種是由第三方組織所提供的卡片。事實上這也是針對了兩種真實的使用情節。
讓我們舉個兩個簡單的例子：組織內部開發了新的應用軟體，軟體系統的架構仍是建構在帳號密碼之下，這些帳號密碼使用者可以先行以卡片技術包裝後，存放在自己的電腦中。
當應用系統需要使用這登入認證時，使用者透過 CardSpace 介面選擇對應的卡片，提供給網站系統，這時候使用者一點也不需要擔心被釣客拐走了密碼，因為帳號密碼被卡片保護住了。

圖表 9
另一個腳本一樣豐富，您登入了一個購物網站，需要提供您的信用卡資料，這時候您的卡片很有可能不能由您自行提供，是由您的銀行提供。透過 CardSpace技術，您和您的銀行要求授權，將授權卡片轉交給購物網站，購物網站取得您的卡片後再自行和銀行授權取款。

圖表 10結尾：
If you are a Developer, you should always reset yourself, reset what you learn and do thing before, fundamentally.
By David Chappell, Boston, Tech.Ed, 2006
改變嗎？ 放開心點，這些改變是在於問題的源頭，有個更好的解決方式。年底在 Vista 的盛會上，您 .NET 3.0 了嘛 ？
提筆情怯，望文心虛…
2006年 李學麟 Polo Lee
Published Monday, September 04, 2006 12:42 AM bypolo
Filed Under:.NET 3.0