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之間建立交互參照來得有彈性，而且也較容易維護多變且複雜的商業流程。