昨天在台灣微軟的會議廳跟許多朋友分享了有關ASP.NET 4以及Visual Studio 2010 在升級方面的一些實務，各位朋友可以透過下面的連結下載簡報：
昨天的場次中也為各位介紹了.NET Framework 4.0所提供的新功能，以及可以為您的應用程式所帶來的好處。當然，這些都必須要搭配Visaul Studio 2010開發在.NET Framework 4.0當中執行的應用程式，才可以使用這些新功能(如：平行運算)所帶來的好處。當然，搭配Visual Studio 2010對於"多目標.NET Framework"的支援，既有的ASP.NET應用程式也可以直接透過Visual Studio 2010 維護，不一定需要立即升級目前的ASP.NET應用程式。如果有需要升級既有的ASP.NET應用程式的話，Visual Studio 2010也提供了升級精靈，讓你可以快速地將ASP.NET應用程式升級到新的環境中，使用.NET Framework所提供的新功能!!!
.NET Framework 4.0 當中，其中一項很重要的特色，就是加入了對於平行運算的支援，讓你的應用程式可以發揮多核處理器的運算能力，甚至於搭配Windows HPC Server 2008 R2進行分散式運算。使用.NET Framework 4.0當中的Task Parallel Library，C#與VB.NET所建立的程式很容易就寫出在多核的環境中執行平行運算的程式。
然而，在平行運算的的程式使用集合一向是個問題，因為在.NET Framework 4.0以前所提供的集合物件，都不是執行緒安全(thread-safe)的物件；換句話說，在平行運算的程式中使用，必須要透過特別的同步鎖定(synchronization)寫法，才可以正常的使用集合中的資料。
這一個問題，.NET Framework 4.0 提供了解決的方式。在.NET Framework 4.0當中，加入了 System.Collections.Concurrent 命名空間，提供了許多可以使用在平行運算程式當中的執行緒安全(thread-safe)集合類別，包括了：
在支援平行運算的程式碼當中，只需要將原本使用的集合換成新的集合就可以了。例如原本的程式碼：
pulblic class MyData{
public List<byte[]> Data {get; set;}
}
因為 List集合物件不支援執行緒安全，因此當你將MyData物件直接在平行運算的程式中使用，並且沒有特別同步鎖定的話，可能會出現下面的錯誤：
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at System.Collections.Generic.List`1.Enumerator.MoveNext()
而在.NET Framework 4.0 的程式當中，你可以將 List集合換成 BlockingCollection集合物件：
pulblic class MyData{
public BlockingCollection<byte[]> Data {get; set;}
}
因為 BlockingCollection物件本身就支援執行緒安全，因此直接將BlockingCollection物件使用在平行運算的程式碼當中，就不會有前述的錯誤發生!!!
在IIS 7.5當中，可以使用" Windows Platform Installer” 工具，安裝支援PHP的延伸模組之後，就可以在IIS上執行PHP應用程式了。當然，此時你就可以使用IIS或是ASP.NET的Membership，建立PHP應用程式所需要的使用者驗證功能。在這裡我先介紹最簡單的WIndows驗證的作法。
Windows驗證在ASP或是ASP.NET的應用程式中，是驗證企業內部網域使用者最簡單的方法；同時使用者在支援Windows驗證的不同Web應用程式間切換時，也不需要再重新登入，對使用者來說也是相當的方便。若是要在裝載在IIS 7.x上執行的PHP應用程式當中使用Windows驗證，首先你必須要開啟PHP應用程式目錄的Windows驗證功能：
1. 用滑鼠雙擊應用程式目錄的Authentication(驗證)設定。
2. 取消匿名驗證(標示 1)，並且啟用Windows驗證(標示 2)：
完成之後，將來所有來自用戶端的HTTP要求，IIS就會使用網域帳號驗證使用者；驗證成功之後，使用者的Window網域帳號就會被自動寫入 "LOGON_USER" 的Server變數當中。而在PHP應用程式中，只需要透過下面的程式碼，就可以取出驗證過的使用者帳號：
除此之外，也可以結合ASP.NET的Forms驗證檢查使用者身分，或是透過URL方式進行授權。
當透過AppFabric設定工具，要將目前機器加入已經存在的快取叢集時，若是出現下面的錯誤訊息：
錯誤發生的原因，就是在 "C:\Windows\System32\AppFabric\DistributedCacheService.exe.config" 檔案中，<clusterConfig>標籤中沒有正確的資料。解決的方式，可以從任一台叢集中的機器中，開啟這一個檔案之後，再將資料複製到config檔案之後，再重新執行AppFabric設定工具就可以了。
雖然最近相當忙，但是發現技術的東西用過之後如果沒有記錄一下，很快就會忘記了。
雲端運算是最近相當熱門的題材，為了讓無法自行建置雲端平台的新興網路產業，以及希望降低公有雲TOC的企業，微軟提供了Windows Azure，讓需要企業可以隨時調配所需要的公有雲架構。然而，在企業當中，還是有需要可以將一些內部的企業級應用程式，建置在企業內私有雲端執行的需求。
Windows High Performance Computing (HPC) Server 2008 R2 是微軟叢集運算的核心，搭配.NET Framework 4.0 所提供的TPL(Task Parallel Library)，你就可以將C#或是VB.NET所建立的WCF服務，進行分散式的運算；而像是ETL、Data Mining等需要大量運算資源的Job，也可以透過HPC Cluster的Head Node進行分散式運算，並且還可以監控每台機器的執行狀況，產生報表。再加上Windows Server AppFabric Caching 的分散式快取，其實要建立企業內私有雲平台並不難。下面是Windows HPC Server 2008 R2的叢集運算基本架構：
Windows HPC Server 不是新的作業系統，而是架構在Windows Server 2008 R2 64 位元作業系統上面的叢集運算服務，由下面幾個基本的角色構成：
1. Head Node：負責集中管理與分派工作(Job)的節點，透過SQL Server資料庫紀錄工作與執行狀態。
2. WCF Broker Node：負責裝載WCF服務，並且將用戶端要求傳送到叢集中運算，回傳結果。
3. Compute Node：負責運算的節點，可以是Windows Server或是Windows 7的工作站。
設定Job的時候可以指定需要使用多少運算的資源：
但需要注意的是，若是要發揮叢集運算的最佳效果，程式在撰寫的時候，就必須要把平行運算的設計考量，加入到程式碼當中。關於.NET Framework 4.0的平行運算是一個很大的課題，有時間再慢慢分享。
今年TechDays 之後，有很多朋友詢問我有關於是不是需要等 HTML 5標準的問題。我先跟大家分享一個身邊的故事：
我有一位好朋友，幾年以來，一直想在台北市買間房子。他跟我說，希望可以找一間室內有35坪以上，總價兩千萬以下的房子。其實這條件並不會太難找，但是找到的都是中古屋，要不然就是交通比較不方便的區域，所以他就不考慮了；再加上常常會有房價泡沫化的新聞，於是乎迄今，屬於他的房子還不知道在哪裡 -- 即便是他有兩千萬的預算…
HTML 5 從2007年開始制定到現在，一直被視為下一代網際網路的一個重要標準；然而到現在為止，也還在 "Working Draft"的階段，"最快" 應該也是明年六月以後才有機會變成 "Recommandation" 的標準(很樂觀的看法)。而備受爭議的CSS 3，則可能會需要再拖一陣子。在現在這標準還是曖昧不明的階段，Chrome、Safari等不同的瀏覽器廠商，為了搶瀏覽器的市場，也舉辦許多的研討會，每家都試圖證明自己是HTML 5的領導廠商。更甚者，希望讓IT人員相信，只有HTML 5才是下一代Rich Internet Application的唯一標準。
我在五月份的文章中，已經把HTML 5發展的可能做了一些分析；在 IE 9 Beta1釋出之後，情勢又更加的明顯。微軟從2007年，也就是大約是 HTML 5標準開始發想的時間，就推出了Silverlight 1.0版。在Silverlight 1.x中，微軟就已經試著使用 XAML標籤，來描述網頁中動畫、影片、聲音等等，與使用者互動的技術，再透過JavaScript控制這些網頁中的物件，建立RIA應用程式。但是也就是為了要讓 XAML標籤所設計的使用者操作介面可以在不同的環境中(特別是未來的行動裝置)，不受瀏覽器與JavaScript引擎的影響，而可以有一致的效果，因此從Silverlight 2.0開始，Silverlight就轉變為現今的架構。而從2007年迄今，Silverlight也已經根據實際應用的需求，進化了四個版本；如果從這樣的經驗來看， HTML 5 的標準就算在制定完成之後，也還有一段長路要走…
另外，若是要讓 RIA應用程式可以在不同的瀏覽器中可以有一致的效果，瀏覽器本身除了需要有很好的JavaScript執行引擎之外，更需要與作業系統有更緊密的結合，才能善用圖形加速的功能(GPU、DirectX…)去呈現網頁。在我TechDays 2010的demo當中(http://ie.microsoft.com/testdrive/Performance/PsychedelicBrowsing/Default.html)，其實就可以看出有支援GPU加速的 IE 9 Beta 1，在執行HTML 5的網頁時，效果就比Chrome(7.0.517.44)好上很多。當然，現在離HTML 5的標準制定完成至少還有半年以上的時間(很樂觀的看法)，瀏覽器廠商都還有進步的時間與空間。但在這些問題都還沒有解決或是最佳化之前，使用HTML 5開發出來的網頁對於使用者來說，不會有太多的感覺。當然，對於瀏覽器廠商來說，若是 IE 9在執行大部分的HTML 5網頁時的速度與效果都比Chrome或是Safari好的話，自然市占率就會增加 -- 然而在 HTML 5標準確定之前，目前所有 "號稱"支援HTML 5 的瀏覽器，也都沒有支援全部的功能(http://www.w3.org/QA/2010/09/how_do_we_test_a_web_browser_o.html)，自然對於使用者來說，也沒辦法帶來好處。
(差很大的使用者操作經驗…)
HTML 5 會一統江湖嗎? 從幾個地方來看：
1. 大部分的HTML 5的規格，都是參考自2007年迄今，RIA應用程式技術(Flash、Silverlight)現有的功能所制定的。然而應用程式的發展日新月異，參考現在的需求所制訂出來的規格，通常是無法滿足未來的需求。換句話說，在環境變化多樣性的網際網路平台中，HTML 5 應該是繼續扮演目前的角色，做為Web基礎的框架；而各種 RIA的技術，包括Silverlight以及未來的其他裝置，勢必會繼續發展滿足未來使用者需求的功能；而HTML 5標準所無法支援的環境，則應該依然是可以透過plug-in的方式，執行在瀏覽器中。
2. 根據這幾年來Silverlight的發展經驗來看，未來HTML 5應該會發展成為設計工具間，轉換使用者操作介面的一種標準。每一種不同的UI 技術都會有各自的profile，如同MDA(Model Driven Architectur)當中 PIM(Platform Independent Model)到PSM (Platform Specific Model)的過程一樣，設計人員可以先使用工具設計好一個通用的模型之後，再套上不同執行環境所需要的profile，就可以轉換成所需要的使用者操作介面。
會需要這樣做的原因是，未來可以上網的裝置越來越多，需求也會不同，要讓RIA應用程式在這些裝置中都有良好的操作經驗，就不可能都靠瀏覽器去執行這些程式。換句話說，除非裝置本身的作業系統就是最佳化過的瀏覽器(Chrom OS ?)，否則會有越來越多的RIA應用程式需要支援於瀏覽器外執行。此時不同的裝置，設計工具就可以透過不同的profile，轉換成各自支援的UI標準 (類似MDA當中的PIM->PSM)，開發人員再透過 MVVM 等開發模式，就可以快速的將使用者操作介面與程式結合，轉換成在不同裝置中執行的應用程式。
我們需要等 HTML 5嗎? 不需要! 就像買房子一樣，有現在就已經成熟的技術可以解決問題，為什麼要等以後不確定能做到多少的標準? 在未來，Silverlight技術將會繼續演進，支援更多裝置與平台；而同時，HTML 5無法滿足的部分，也繼續會有新的技術會出現，請問你還可以等多久???
參考資料：
 
|
