企業需求

一般大型企業的資訊系統，往往相當龐大且複雜。若缺乏開發前的系統分析與設計，往往會造成同樣功能的程式在系統A開發過一次，系統Ｂ又開發一次。或是因為系統與系統間並不互通，導致相同的元件到處散置。這種模式下往往會造成：

• 東起一個元件、西起一個元件，無法好好管理，增加主機負擔。


• 資料邏輯改變時，系統維護人員必須檢查整個龐大的資訊系統中，到底有多少系統裡面包含需要進行修改的元件，導致簡單的維護變成一個複雜的大工程。


• 同樣的元件透過不同的人、不同的時間重複開發，可能無法確保元件品質。

以筆者實務經驗-某證券商為例，該證商的MIS系統非常龐大，包含數以百計的功能，每項功能都是獨立開發的不同網站應用程式，使用者透過同一個入口進行連結，再進入不同的網站應用程式。這種模式下會發生的問題在於：

進入不同的網站應用程式代表的意思是，伺服器主機必須在用戶端每次進入一項功能就產生一個新的session物件，因此只要用戶端點了10個不同的功能，針對一個用戶就會產生10個不同的session以保存用戶端的狀態，造成系統資源的浪費。

該證商針對用戶端是採用AD方式進行認證，每一個應用程式都會有三行一模一樣的程式用來進行認證，這就是先前所說重複開發的問題。當未來要從AD的模式改成其他種類的目錄服務 (Directory Service) 方式，要進行修改可就是一項大工程。

所有MIS的系統都與資料庫脫離不了關係。比方說，幾乎所有交易相關功能都免不了從資料庫中讀取營業員基本資料。假設交易相關系統有10個，就會變成每個系統各自維護資料庫連線，造成系統之間各自去搶奪資料庫資源，幾乎等於沒有管理。

會造成這樣的情形，有一部分原因是該證商的資訊部沒有統一的資訊系統開發準則。其他部門一提出新需求，資訊部沒有進行分析與設計階段就直接著手開發，只要功能出來，可以正常運作就上線，幾乎不考慮開發這套系統對整個資訊系統可能會造成的衝擊。

這是企業一般可能會遇到的問題，因此，他們需要的是一個新的應用程式架構，目標是達成以下幾點特性：

• 應用程式可以透過位於遠端與本機端的元件來完成作業


• 可以與已開發的舊系統完全相容或只需要修改部分程式


• 保有可靠性、安全性與效率


• 可監視元件狀態的介面


• 可輕易的開發元件與掛載


• 方便除錯


• 完善的元件管理機制

這也是為什麼現在服務導向架構(Service-Oriented Architecture, SOA)這麼熱門的原因。接下來我們將簡單介紹SOA架構。

SOA架構

XML技術出現後，應用程式之間的溝通變得容易，基於XML技術，W3C訂出Simple Object Access Protocol(SOAP)、Web Services Description Language(WSDL)、Universal Discovery Description and Integration(UDDI)三個Web Service標準，將企業對外的服務變成標準化的Web Service，實現了異質性系統的基本互通性。SOA的發展也因此開始具體實現。

SOA是一種有彈性的設計規則，系統設計及整合時使用。SOA架構下的佈署環境中，元件與元件之間可以是彼此獨立的，不需要使用相同的程式語言，因此適用於異質性系統。

依據微軟「真實世界SOA」白皮書所述：



SOA實作技術的比較

目前最為人所知的SOA實作技術有.NET陣營的Window Communication Foundation (WCF)與JAVA陣營的JAX-WS， 我們在下方以列舉方式比較兩者的異同：



從上方的比較表，我們可以知道WCF與JAX-WS均可以滿足大部分企業的需求；但以開發人員來說，在學習過程與開發成本的考量上，WCF似乎是較佳的選擇。

WCF簡介

WCF是微軟實作SOA架構的一個Application Framework，於.NET Framework 3.0版開始納入，主要用於提供跨平台的訊息交換服務，簡化程式設計師實作SOA架構的複雜度，目前隨.NET Framework 4.0版本問世，WCF也進行了改版。簡單來說，WCF包含ABC三個部分：

　A：Address，服務所在的位置
　B：Binding，定義了服務的方式為同步、非同步、廣播等
　C：Contract，定義提供服務的種類為Service Contract、Data Contract、Fault Contract或Message Contract

WCF基本架構如下：

• Endpoint: Server端提供給外部存取的介面


• Service: Server端所提供的服務


• Proxy: Client可透過Proxy呼叫Server端所提供的服務


• Transport Channel: WCF提供了：
  ‧Basic binding: Client可以透過ASP.NET呼叫WCF服務
  ‧TCP binding: 可在內網中透過TCP通訊協定以WCF對WCF的方式呼叫服務
  ‧Peer network binding: 透過P2P的方式使用WCF服務
  ‧IPC binding: 在同一台機器上使用named pipes的方式呼叫WCF服務
  ‧Web Service binding: 使用Web Service的方式，透過Http、Https使用WCF提供的服務
  ‧Federated WS binding: Web Service binding方式的延伸，提供federated security的安全性架構
  ‧Deplex WS binding: Web Service binding方式的延伸，提供雙向的溝通方式
  ‧MSMQ binding: 使用MSMQ的方式使用WCF的服務
  ‧MSMQ integration binding: 將WCF訊息轉換成MSMQ的格式再傳送，用來與舊的MSMQ系統溝通

接著我們介紹WCF其他層面的議題：

• 掛載：WCF可掛載於Console Application、Windows Application、IIS、Windows Service以及Windows Activation Services中執行。


• 物件管理：Service instance的生命週期有per-call service、sessionful及singleton services三種。pre-call service是只要客戶端每傳一個request到server，server就會產生一個新的service instance、sessionful是每個session只會有一個instance，session結束即釋放，singleton則是只要Server啟動，所有的client就共享同一個instance。


• 服務管理：目前微軟所提供的工具Application Server AppFabric可以針對WCF進行的管理作業有監控、控制最大同時呼叫數、控制最大同時執行個體數與設定憑證等。


• 異常處理：WCF Service發生錯誤時，系統會拋出Exception物件，此時如果在Server端沒有利用try…catch進行異常處理時，client端的連線就會中斷，要再次使用服務時就得重新連線。如果有利用try…catch機制將異常截取下來，再轉拋出FaultException，client端的連線就不會中斷。


• 安全性：WCF中的安全性以安全性模式、用戶端認證類型與認證值三個步驟為基礎。首先選擇Binding類型，不同的Binding類型允許不同的安全性模式，基本上為Transport、Message、TransportWithMessageCredential三種。用戶端認證類型也可分為Windows、Certificate、Digest、Basic、UserName、NTLM以及IssuedToken七種。最後由ServeiceCredentials類別設定服務端的認證值、ClientCredentials類別設定用戶端的認證值。

實務分析

當一個完全沒有WCF架構的企業，在所有應用程式都獨立開發，幾乎沒有共用元件的情況下，要導入WCF或許必須考量下列幾點：

1.進行開發時，必須分析現有系統、設計服務架構、考量定義服務的規則
2.界定服務的安全性層級，在內外網中該如何定義統一而嚴謹的認證模式
3.服務是否依據叫用頻率與占用系統資源的大小來進行負載平衡
4.現有硬體設備是否足以乘載WCF所帶來的額外的硬體負擔
5.考慮到服務不再是原先可能只是呼叫函式庫，而是透過其他的溝通管道來叫用服務時，則必須考慮連線層的錯誤、代理和通道層的錯誤以及應用層的錯誤等該怎麼處理
6.必須建立未來服務的開發、管理與維護機制，否則所有項目都變成WCF後，Service會變得很亂，很龐大，除了讓拖慢系統速度、維護變得困難之外，不會帶來任何實質的效益
7.資訊人員改變開發模式，要投入教育訓練所需耗費的時間與成本

結語

以程式設計師的角度來看，WCF是目前在SOA領域中是可以減輕程式設計師最多負擔的SOA框架。服務異常監看相當完善，可以看見詳細的訊息，包含訊息交換過程與詳細的異常訊息，並且在新一代的Silverlight前端應用程式中，也提供可以存取資料庫的WCF RIA Service，讓前端應用程式可以更方便存取資料庫，大大減輕程式設計師的負擔。雖然WCF在服務監控與管理上似乎並有些缺憾，無法只單獨啟動或停止某一項服務，也無法監控目前哪個Service所占用的資源最多，User數最多。以目前各家SOA的實作品來看，WCF是現階段程式設計師最好的選擇。