HTML 5+ CSS 3 會殺了Flash 跟Silverlight ? -2

會拿Silverlight跟Flash比較的人，基本上，不懂Silverlight.....

從Silverlight 2開始，我在所有的文章與研討會中就明白的揭示了，"Silverlight是網際網路應用程式開發技術" 的觀念。在VS 2010中，不需要使用Microsoft Blend，就可以直接開發Silverlight的表單操作介面，同時Silverlight Application也可以直接支援Windows、Forms以及SharePoint的驗證，再加上WCF RIA Services的支援，基本上只要會C#的開發人員，不懂HTML、JavaScript，也可以快速的開發出豐富的網際網路應用程式。再加上容易除錯與VS 2010提供了方便的開發環境以及跨平台的支援(Mac、Windows、Linux、WM7)，只要微軟好好發展下去可望成為.NET網際網路應用程式開發的另一個主流。

記得當年HTML剛出來，大家有跑馬燈(<marquee/>)可以用，覺得超新奇超炫的，一時之間每個網站幾乎都有跑馬燈的橫條在上面跑的情況。時至今日，有多少人還在用? 所謂的標準，真的就是符合大家使用的準則，抑或是限制技術成長的濫觴? HTML 5 跟CSS 3的出現，目前獲益最大的應該是這兩家公司：

1. Apple：原本不想支援Flash，但是使用者又想看Flash做出來的效果。

2. Adobe：想不到吧! HTML 5+CSS 5讓Adobe不需要追著瀏覽器去提供新的擴充套件，還可以出新版的CS賺錢。

前一篇也已經說明過了，要叫瀏覽器做更多的事，就必須要有更複雜的瀏覽器的道理。現在所有的個人電腦瀏覽器都有Flash套件可以支援，因此瀏覽器有沒有支援HTML 5 我不相信目前會有多少人care；但是行動裝置則未必。HTML 5 既然是標準，行動裝置製造商就可以直接從作業系統中去支援這一個標準，提供原生的網際網路多媒體存取環境，避開瀏覽器的效能問題；而這一塊也不是目前Flash主攻的市場，因此HTML 5要從此切入，才會有比較大的發展空間。

WCF Service的介面設計

WCF Service 透過Service Contract提供服務的介面給Client端的應用程式使用。常常會有人問我，如果WCF Service的服務介面需要修改，應該要怎麼辦的問題。如果從元件的角度出發來看的話，介面修改相對的所有使用該元件的應用程式也都必須要跟著被修改，這對於可能會需要隨著企業邏輯做調整的WCF服務來說，會造成不小的影響

在繼續這個話題之前，先請大家思考一下，如果你家的電器插頭，每一種電器插頭的規格都不一樣的話，會是怎樣的世界?

從這樣的角度去思考的話，服務的介面規格當然是設計的越簡單越好。微軟所提供的Design Guideline中提到：

• Avoid tight coupling across layers.
• Design coarse-gained operations.

對於90%以上的服務來說，我們需要兩個基本的功能：

1. 執行指令並回傳運算結果或是錯誤資訊。

2. 確定目前服務是正常的。

根據這樣的出發點，我們可以設計出一個通用的WCF Service介面：

[ServiceContrract]

public interface ICommonService{

[OperationContract]

object Execute (string command, Dictionary<string,object> parameters, out string errorMessage);

[OperationContract]

bool Diagnostics ();

}

在這樣的介面設計之下，你的服務不管要增加多少功能，或是要減少功能，都不會需要更動到服務的介面規格，只需要支援新的command指令即可。但是需要注意的是，因為在這個服務介面規格中是使用object型別傳遞資料，因此你必須要另外再使用Data Contract宣告可序列化物件，然後透過ServiceKnownType將該物件定義加入WCF服務規格中。

HTML 5+ CSS 3 會殺了Flash 跟Silverlight ?

前兩天SAM問了我Silverlight會不會沒有前途的問題。

基本上，從我目前所得到的資訊來看，HTML 5正在走當年Silverlight 1.0、1.1所走的路。Markup Language、CSS基本上都是需要透過parser解析過才會有樣式；而Tag與CSS所能做的事情越多，parser的等級就需要用高。換句話說，瀏覽器就越複雜，網頁的模型也就越複雜。Silverlight 1.x當年就是希望透過XAML+JavaScript建立高互動性的網頁，但是因為XAML的Tag太多太複雜，再加上JavaScript不容易維護與除錯，最後還是發展成編譯式的架構。

未來的趨勢，上網的裝置會走向輕量化的嵌入式系統或是行動裝置為主，在省電與節省成本的考量下，這些裝置所提供的瀏覽器大多無法像一般瀏覽器完整支援JavaScript或是樣式，因此若是你所開發的網際網路應用程式，需要在這些環境下執行，勢必就要另外開發特定的版本來滿足需求。而HTML 5和CSS 3有多少功能會被這些瀏覽器完整支援?

Flash雖然目前在網頁中被廣泛使用，但是因為Adobe自己沒有作業系統，也沒做瀏覽器，被賈伯斯幹譙也只能摸摸鼻子吃悶虧。反觀是微軟，在Silverlight 4與VS2010推出之後，就搶先推出WM 7的Silverlight 4在WM 7的模擬環境，所以在WM 7中會支援Silverlight已經是可以確定的事。HTML 5+ CSS 3目前看來，應該可以視為瀏覽器製造商不甘心瀏覽器成為Flash、Silverlight等RIA技術的附庸的反撲；但以目前設計人員已經習慣使用Flash方便的設計工具來設計網頁中的動畫、微軟自己又有完整的Silverlight發展環境規劃看來，短期大概只有Open Source的community會很感興趣。

但HTML 5也不是沒前途，等到行動嵌入式系統個普及之後，作業系統的廠商就會跟微軟一樣，由作業系統層直接去支援解析這些標籤的能力。屆時桌面即是瀏覽器，才會是真的戰場...

Web Service? WCF Service?

最近有位朋友在網路以及MSN上面問我，Web Service和WCF Service的差別到底在哪裡呢?

Web Service，從字面上可以直譯為"網路服務"，可以從廣義或是狹義方面來解釋。廣義的來說，只要是服務提供者透過網際網路所提供的服務，都可以稱為網路服務。例如微軟所提供的SkyDrive，Google 所提供的Gmail、Google Earth，都可以視為廣義的網路服務。而狹義的網路服務，指的則是在網際網路上，可以透過網路服務的標準，SOAP或是WS-I所存取的應用程式服務介面。如果是這樣來看的話，Web Service 就可以視為在網際網路上的元件；因為網際網路本身具有跨平台的特性，因此無論你是透過.NET或是Java等程式語言所建立的Web Service，就可以在不同平台被使用，因此可以用來建立分散式架構中跨平台使用的元件。

除了Web Service 之外，微軟在分散式架構中，也有許多開發分散式元件的技術，像是Remoting、MSMQ等。因為每種技術都有特定的溝通模式，也各有各的優缺點。像是Web Service雖然可以跨平台，但是速度上就比Remoting支援的TCP Channel幔上許多；但是開發及設定Remoting元件的efforts，又比Web Service複雜。更重要的是，你必須要懂每種不同的技術，才可以作出符合需求的企業級元件，這對於開發人員來講，是相當沉重的負荷。

為了解決這樣的問題，因此微軟從.NET 3.0開始推出了WCF的技術。WCF整合了Web Service、Remoting、MSMQ等微軟分散式元件開發技術，只需要開發一個WCF Service，就可以透過設定的方式，發佈支援不同通訊協定的服務端點。因此現在若是你要開發新的網路服務的話，在.NET Framework中就統一透過WCF技術框架開發。

有興趣可以再回顧之前我所寫的幾篇：

• 微軟新一代分散式架構與網際網路開發技術剖析(1)
• 微軟新一代分散式架構與網際網路開發技術剖析(2)
• 微軟新一代分散式架構與網際網路開發技術剖析(3)