軟件體系架構閱讀筆記十五

面向服務架構，它能夠根據需求經過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用。服務層是SOA的基礎，能夠直接被應用調用，從而有效控制系統中與軟件代理交互的人爲依賴性。

SOA是一種粗粒度、鬆耦合服務架構，服務之間經過簡單、精肯定義接口進行通信，不涉及底層編程接口和通信模型。SOA能夠看做是B/S模型、XML語言的子集）/Web Service技術以後的天然延伸。

SOA將可以幫助軟件工程師們站在一個新的高度理解企業級架構中的各類組件的開發、部署形式，它將幫助企業系統架構者以更迅速、更可靠、更具重用性架構整個業務系統。較之以往，以SOA架構的系統可以更加從容地面對業務的急劇變化。

Soa系統是一種企業通用性架構。

這種具備中立的接口定義（沒有強制綁定到特定的實現上）的特徵稱爲服務之間的鬆耦合。鬆耦合系統的好處有兩點，一點是它的靈活性，另外一點是，當組成整個應用程序的每一個服務的內部結構和實現逐漸地發生改變時，它可以繼續存在。與之相反，緊耦合意味着應用程序的不一樣組件之間的接口與其功能和結構是緊密相連的，於是當須要對部分或整個應用程序進行某種形式的更改時，它們就顯得很是脆弱。

對鬆耦合的系統的須要來源於業務應用程序須要根據業務的須要變得更加靈活，以適應不斷變化的環境，好比常常改變的政策、業務級別、業務重點、合做夥伴關係、行業地位以及其餘與業務有關的因素，這些因素甚至會影響業務的性質。咱們稱可以靈活地適應環境變化的業務爲按需（On demand）業務，在按需業務中，一旦須要，就能夠對完成或執行任務的方式進行必要的更改。

雖然面向服務的體系結構不是一個新鮮事物，但它倒是更傳統的面向對象的模型的替代模型，面向對象的模型是緊耦合的，已經存在二十多年了。雖然基於 SOA 的系統並不排除使用面向對象的設計來構建單個服務，可是其總體設計倒是面向服務的。因爲它考慮到了系統內的對象，因此雖然 SOA 是基於對象的，可是做爲一個總體，它卻不是面向對象的。不一樣之處在於接口自己。SOA 系統原型的一個典型例子是通用對象請求體系結構（Common Object Request Broker Architecture，CORBA），它已經出現很長時間了，其定義的概念與 SOA 類似。

然而， SOA 已經有所不一樣了，由於它依賴於一些更新的進展，這些進展是以可擴展標記語言（eXtensible Markup Language，XML）爲基礎的。經過使用基於XML 的語言（稱爲 Web 服務描述語言（Web Services Definition Language，WSDL））來描述接口，服務已經轉到更動態且更靈活的接口系統中，非之前 CORBA 中的接口描述語言（Interface Definition Language，IDL）可比了。

Web 服務並非實現 SOA 的唯一方式。前面剛講的 CORBA 是另外一種方式，這樣就有了面向消息的中間件（Message-Oriented Middleware）系統，好比 IBM 的 MQseries。可是爲了創建體系結構模型，您所須要的並不僅是服務描述。您須要定義整個應用程序如何在服務之間執行其工做流。您尤爲須要找到業務的操做和業務中所使用的軟件的操做之間的轉換點。所以，SOA 應該可以將業務的商業流程與它們的技術流程聯繫起來，而且映射這二者之間的關係。例如，給供應商付款的操做是商業流程，而更新您的零件數據庫，以包括進新供應的貨物倒是技術流程。於是，工做流還能夠在 SOA 的設計中扮演重要的角色。

此外，動態業務的工做流不只能夠包括部門之間的操做，甚至還能夠包括與不爲您控制的外部合做夥伴進行的操做。所以，爲了提升效率，您須要定義應該如何得知服務之間的關係的策略，這種策略經常採用服務級協定和操做策略的形式。

最後，全部這些都必須處於一個信任和可靠的環境之中，以同預期的同樣根據約定的條款來執行流程。所以，安全、信任和可靠的消息傳遞應該在任何 SOA 中都起着重要的做用。