Private Component、Shared Component and Web Service

SOA (Service Oriented Architecture) 與雲端運算是目前相當熱門的話題，最近看了一些 design，有些感想。

先請問各位，private component、shared component與 web service，有甚麼相同之處 ?

原則上，這三種都是用來封裝可以重複使用的程式邏輯的技術：

• Private component 的組件必須要放到應用程式的目錄中執行，一次僅可以分享給一個應用程式使用。
• Shared component 則是必須要註冊到執行環境的GAC(Global Assembly Cache)中，可以提供給整台電腦的應用程式共用。應用程式在存取shared component時，必須指定所呼叫的組件版本。
• Web Service 則是發布到網路上特定位置的公開介面(interface)，以單一應用程式的方式執行，提供用戶端程式可以透過網路存取程式邏輯。Web Service 是以訊息為導向(message-oriented)的溝通模式，因此用戶端應用程式在存取Web Service 時，必須要先取得Web Service的WSDL文件，並且根據WSDL文件建立服務要求，再取得服務的回應。

而很多人認為，所謂的 SOA，就是要把之前所有的共用元件，都做成Web Service或是WCF Service。於是乎東一個Service、西一個Service，最後不但效能不好，出問題也很難除錯 -- SOA的好處沒享受到，反而增加了很多維護的成本。當然，在目前這一個開發Web Service就像喝水一樣簡單的時代當中，很多人都會有這樣的誤解，因此選擇了錯誤的技術去解決問題，反而製造出更多的問題。

我們以Data Access Componets來舉例，因為很多人導入SOA的第一個步驟，就是先從DAL著手。一般應用程式對於 Data Access Component 都會有幾個基本的需求：新增、修改、刪除、與查詢資料；當然，也包括了要做交易(transaction)的處理。若是你將 DAL實作成Web Service，你馬上就會面臨幾個問題：

1. 無法進行交易。雖然微軟的MS-DTC 可以搭配WS-Transaction提供交易的支援，但若是要執行跨平台的交易處理，不是一般的開發人員可以容易實作與維護的。

2. 存取資料效能變差。因為Web Service本身也是獨立的應用程式，因此會有自己的驗證/授權、建立執行環境等等邏輯需要執行，都會影響資料的存取速度。

3. 維護成本增加。建立Web Service需要規劃新的部署與維護計畫，更重要的是，若是將來前端程式出錯，要除錯會是一個很大的災難。

4. 透過Shared Component，用戶端應用程式執行環境是否安裝必要的元件，只需要從檔案總管就可以看出來；若是要更新介面，只需要安裝新版本的組件到production server上，很容易就可以讓新舊版本共存。然而對於Web Service來說，就不是那麼件容易的事。

因此，對於大部分.NET的系統而言，Data Access Componet 其實只需要建立成Shared Components，將來部署到執行環境的機器中就夠了。會需要開發Web Service，一般有兩種情況：

1. 跨平台整合元件的需求。

2. 透過網際網路直接存取元件的需求。

若是沒有這兩個前題，一般共用元件其實並不需要每個都做成Web Service。參考微軟針對Service Application中 Service的特性的描述如下：

"Services support a heterogeneous environment by focusing interoperability at the message/interface definition."

下次，再跟大家繼續分享其他Web Service設計上還需要注意的其他地方。