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

通過了 OCUP Intermediate 認證考試 ...

把OMG的認證考試用書 (UML 2 Certification Guide: Fundamental & Intermediate Exams (The OMG Press))裡面Intermediate考試的範圍整理過之後，上星期也順利的通過了OCUP Intermediate 的考試。

基本上，OCUP 這兩級考試的範圍，都沒有超過認證用書的內容，也跟網站中所標示的一致。但是因為UML本身有很多抽象的定義，若是沒有一些UML 經驗，或是沒有接觸過UML 的人，直接看書或是UML Superstructure 的規格應該會是一頭霧水，更不用說是考試了。而考試本身其實並不會太難，主要的出題方向是在理解與應用的方面，因此不用硬去記metamodel，反而要花一些時間去理解metamodel對應到實際的UML notation 時，所表示的意義與特性。

過一陣子整理完Advanced考試的範圍資料之後，再去挑戰最後一級的認證考試。

近況更新

最近陸續接到一些讀者詢問有關於Silverlight 3的書是不是已經出的問題，特別在這裡說明一下。

首先，很感謝悅知出版社的邀稿，讓我有機會把Silverlight到目前為止的研究心得有可以集結成冊的機會。但是幾經考慮之後，Silverlight 3的出書計畫還是在最後關頭停住了。主要有幾個原因：

1. 微軟這次在Silverlight 3 SDK與Blend 3 中文版中所提供了相當多的資訊，這些資訊對於Silverlight 3的入門使用者來說，已經是相當足夠了。

2. 這本書定位是在實戰的等級，但是剛好前陣子公司有重要的案子進行，沒有很多時間可以refine 書裡面的內容；為了維持品質，所以在取得編輯大人的諒解之後將這本書的出書計畫暫停了。

當然，在這裡也要向等待的讀者致歉。不過出書計畫只是暫停，並沒有停止。目前新的計畫是：

1. 關於Silverlight 3，我還是會持續透過"線上講堂" 與各位交流。

2. 未來的bandwidth放在整理 .NET Framework 4.0 的範例與資料。未出版的Silverlight 3 的內容會與 .NET Framework 4.0 所提供的雲端運算服務整合成另外一本書，等級也是會定位在實戰的等級，以VS 2010為開發工具，做為學習完C#程式語言之後，可以延伸學習的進階書籍。

而從我上一篇分享的網誌中，大家應該也可以嗅到了未來微軟的開發平台將會與UML有更緊密的結合(請參考 "Microsoft Focuses on Bringing Modeling Mainstream, Improves IT Delivery of Business Strategies")。因此最近正透過參加OCUP認證考試，複習與整理UML的相關知識，希望可以繼續提供大家更多充實的內容。也因為準備考試的關係，所以最近網誌內容更新的比較慢一點，敬請見諒；當然，如果各位有問題或是想要我分享的內容，都歡迎繼續留言與我聯絡，謝謝。 

通過了OMG Certified UML Professional (OCUP) Fundamental 認證

OCUP(OMG Certified UML Professional)，是目前主導UML(Unified Modeling Language) 規格發展的國際組織 OMG (是 "Object Management Group"，不是"Oh, My God !") 所推廣的UML認證。比起Microsoft或是Sun Java等大廠的認證來說，在台灣算是比較冷門的認證。然而以UML本身來說，卻是你在任何專案的文件當中，都一定會看到、用到的東西；因此就算沒有了解全部的UML文件規格，也至少會在文件中看過Class Diagram、Use case Diagram 等基本的UML圖。

目前系統開發的分工越來越細，拜SOA發展所賜，系統的執行環境與架構也越來越複雜，一般公司的系統外包給協力廠商開發或是透過雲端系統執行，已漸漸變成了趨勢。而要將系統外包給協力廠商開發，就必須要在系統進入開發測試階段之前，透過UML建立起完整的系統模型。此時，你就不能只是 "會用" UML的階段，還必須要 "了解" UML，專案才有辦法在發包之前確定規格以及找出問題。

理論上，UML 是以圖形化方式描述系統的架構，應該是相當容易了解；但是往往大家在應用的時候，就會出現一些盲點。例如有多少人可以正確的告訴我，下面這兩張圖所代表的意義跟差異?

另外一個常看到的問題是， 當 SA/SD 使用UML完成設計之後，因為開發人員或是協力廠商對於 UML的規格不熟悉，誤解了系統文件中設計的內容，而做出了錯誤的東西。因此若是要導入 UML，除了SA/SD 人員一定要熟悉 UML的規格之外，開發人員也必須要對 UML 有一定程度的了解，才能夠成功。

Microsoft 近幾年來，也慢慢的開始與這些軟體工程的公開標準整合。像是BizTalk Server 2006就支援了BPEL(Business Process Execution Language)；在WF中 透過設計工具就可以以建立類似 UML 的Active Diagram、State Diagram的方式，建立程式的流程。在 "Microsoft Focuses on Bringing Modeling Mainstream, Improves IT Delivery of Business Strategies" 中，微軟也正式的宣布加入OMG組織；並且在VS 2010中，加入了 "Modeling Projects" 的專案範本 -- 換句話說，你可以直接使用 VSTS 2010 建立專案的 UML 文件，並且透過 TFS 加入專案中管理。關於這部分，以後會再慢慢跟大家分享。

而 OCUP，就是用來證明你對 UML 規格了解程度的認證。OCUP 認證分成三級，你可以根據在專案中所扮演角色的角色，決定你要考到哪一個等級。每個等級的詳細說明在網站(http://www.omg.org/uml-certification/index.htm) 上介紹的很清楚，各位如有興趣可以自行參考；一般開發人員應該考過初級(Fundamental)就可以了。

準備 OCUP 的考試，其實也不太難，因為UML的規格其實在規格書當中定義的相當清楚 -- 但也就是因為太清楚了，所以看起來會有點辛苦。OMG 自己有出版一本認證教材，整理的很詳細，解釋的也很清楚：

 

UML 2 Certification Guide: Fundamental & Intermediate Exams (The OMG Press)
      by Tim Weilkiens and Bernd Oestereich

這本書很有系統的介紹了 UML 的規格，以及整理了 OCUP 考試所需要了解的重點。就算你沒有要考 OCUP 認證，這本書中的經典範例也可以幫助你深入學習 UML，我個人認為這是每一個導入UML 的專案團隊所必備的一本工具書。