解析企業(yè)SOA的十大設計原則

一、明確的邊界

通過跨越定義明確的邊界進行顯式消息傳遞，服務得以彼此交互。有時候，跨越服務邊界可能要耗費很大的成本，這要視地理、信任或執(zhí)行因素而定。邊界是指服務的公共接口與其內(nèi)部專用實現(xiàn)之間的界線。服務的邊界通過WSDL發(fā)布，可能包括說明特定服務之期望的聲明。

二、服務共享和約和架構，不是類

服務交互應當只以服務的策略、架構和基于合約的行為為基礎。服務的合約通常使用WSDL定義，而服務聚合的合約則可以使用BPEL定義(進而，對聚合的每個服務使用 WSDL)。服務使用者將依靠服務的合約來調(diào)用服務及與服務交互。鑒于這種依賴性，服務合約必須長期保持穩(wěn)定。在利用XML架構 (xsd:any) 和SOAP處理模型(可選標頭)的可擴展性的同時，合約的設計應盡可能明確。

三、策略驅(qū)動

盡管它往往被認為是最不為人所了解的原則，但對于實現(xiàn)靈活的Web服務，它或許是最有力的。單純依靠WSDL無法交流某些業(yè)務交互要求�？梢允褂貌呗员磉_式將結構兼容性(交流的內(nèi)容)與語義兼容性(如何交流消息或者將消息交流給誰)分隔開來。

四、自治

服務是獨立進行部署、版本控制和管理的實體。開發(fā)人員應避免對服務邊界之間的空間進行假設，因為此空間比邊界本身更容易改變。

五、采用可傳輸?shù)膮f(xié)議格式，而不是API

通常，服務提供商基于某種傳輸協(xié)議(例如HTTP)提供服務，而服務消費者只能通過另一種不同的協(xié)議(比如MQ)通信。因此，也許需要在服務提供商與消費者之間建立一座異步起動同步運行的連接橋梁，超越HTTP和Java Messaging Service消息服務(JMS)等協(xié)議。從技術角度講，Java Messaging Service消息服務(JMS)并不是一種傳輸協(xié)議，而是一組供應商中立(vendor-neutral)的通信APIs。

六、面向文檔

消息被構造為“純文本的”XML文檔(換句話說，數(shù)據(jù)的格式只對XML有意義)。 消息通常用于傳輸業(yè)務文檔，比如購買訂單、發(fā)票和提單。這種交互類型與同步消息排隊系統(tǒng)的兼容性很好，比如MQ Series、MSMQ、JMS、TIBCO、IMS等等。

七、松偶合

服務之間要求最小的依賴性，只要求它們之間能夠相互知曉。

八、符合標準

當通過Web的服務實現(xiàn)時，最原始的(基本的)面向服務的架構(SOA)的模型僅僅提供了很低程度上的關于可靠性、安全性以及事務管理的標準化機制。第二代的技術條件和框架，如WS-ReliableMessaging規(guī)范、WS-Security規(guī)范和WS-Coordination規(guī)范 (與WS-AtomicTransaction規(guī)范和WS-BusinessActivity規(guī)范相聯(lián)系)，它們試圖以工業(yè)標準的方式定位存在的缺陷。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質(zhì)保障！--億恩科技[ENKJ.COM]