Web (WCF) Service的設計考量 (1) - 基本觀念

繼續談談 SOA Service Layer方面的設計考量。

前一篇網誌文章中提到，通常有跨平台整合、或是需要透過網路提供遠端存取的共用元件，通常才會考慮建立成為Web Service。除此之外，在設計Web Service的時候，也有些需要注意的基本概念。

Web Service雖然是透過服務介面(interface)與用戶端程式繫結，然而就跟一般應用程式一樣，每個Web Service所提供的功能是獨立的，而且與一般應用程式一樣，採用層級的架構設計。Web Service基本的層級架構如下圖：

 

在設計時，必須盡可能的將 Data Layer 與 Business Layer分別封裝在不同的元件中，並且各層級之間再透過抽象的介面結合。一般來說，後端的元件可以製作成Shared Component，再提供給內部的其他系統整合時使用。

而開發Service Layer時，必須要把Service Contract、Service Implementation、Data Contract 等等，分別定義到不同的組件中。換句話說，你並不應該使用Visual Studio 開發工具新增一個預設的Web Service或是WCF Service專案之後，就只用這一個專案完成所有Service Contract、Service Implementation、Data Contract 的開發；正確的做法應該是另外再建立不同的ClassLibrary專案來開發與維護不同用途的服務元件。這樣的做法可以讓你將來需要調整服務的內容時，可以擁有比較高的彈性；同時也可以比較容易進行單元測試，確保Web Service的穩定性。

同時，也必須要注意到，每個 Web Service 同時也會是一個獨立的應用程式，用戶端程式必須要透過 Service Layer所定義的介面(服務合約)，才可以使用其功能。而 Web Service 之間若是需要整合的話，可以透過下面幾種方式：

1. 若是後端資源(如：資料來源)方面的整合，可以透過 Data Layer所提供的Shared Assembly：

而通常這種方式，因為跳過了 Business Layer，所以僅能做比較邏輯較單純的資料異動。

2. 若是要進行功能面的整合，則必須要透過 ESB(Enterprise Service Bus)，或是再建立一個更上層的 Web Service 來完成；而不是在 Web Service 之間直接建立交互參照：

舉例來說，假設 Service A 是庫存系統的服務，提供產品庫存查詢與異動的介面；而 Service B 是訂單管理系統的服務，提供新增訂單與訂單異動的介面。而若是需要整合客戶系統提供即時下單功能時，就應該另外建立一個新的Service C，並且把處理訂單的流程( Business Workflow)封裝到新服務的功能當中。這樣的架構會比你在Service A 和 B之間建立交互參照來得有彈性，而且也較容易維護多變且複雜的商業流程。

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設計上還需要注意的其他地方。