詳細分析SOA的十大設計原則

一、明確的邊界

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

二、服務(wù)共享和約和架構，不是類(lèi)

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

三、策略驅動(dòng)

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

四、自治

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

五、采用可傳輸的協(xié)議格式，而不是API

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

六、面向文檔

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

七、松偶合

服務(wù)之間要求最小的依賴(lài)性，只要求它們之間能夠相互知曉。

八、符合標準

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

九、獨立軟件供應商

向SOA的轉變正在深刻改變了經(jīng)濟現實(shí)?？蛻?hù)們會(huì )期待更合理的費用以及不必重新進(jìn)行投資就能改進(jìn)業(yè)務(wù)的能力。因此，獨立軟件供應商沒(méi)有選擇，只能使自己的業(yè)務(wù)更加靈活，以期讓自己的客戶(hù)也變得同樣靈活。于是，面向服務(wù)不僅是簡(jiǎn)單的在現有的、緊耦合的、復雜的、不靈活的以及非組件化的業(yè)務(wù)功能上添加基于標準的接口。更重要的是，為了兌現SOA的承諾，獨立軟件供應商必須改變他們構建、打包、銷(xiāo)售、交付、管理和支持自身產(chǎn)品的方式。

十、元數據驅動(dòng)

開(kāi)發(fā)元數據本身并不是元數據驅動(dòng)應用程序的本意。使用元數據來(lái)驅動(dòng)服務(wù)在系統邊界的傳播是一個(gè)更為正確的方法。