雖然面向服務的體系結構不是一個新鮮事物,但它卻是更傳統的面向對象的模型的替代模型,面向對象的模型是緊耦合的,已經存在二十多年了。雖然基於 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 的設計中扮演重要的角色。
另一種形式是內部改變,在這種改變中,零售組織決定它還將把連鎖零售商店內的一些地方出租給專賣流行衣服的小商店,這可以看作是採用店中店(store-in-store)的業務模型。這裡,雖然公司的大多數業務操作都保持不變,但是它們需要新的內部軟體來處理這樣的出租安排。儘管在內部軟體系統可以承受全面的檢修,但是它們需要在這樣做的同時不會對與現有的供應商系統的互動產生大的影響。在這種情況下,SOA 模型保持原封不動,而內部實現卻發生了變化。雖然可以將新的方面添加到 SOA 模型中來加入新的出租安排的職責,但是正常的零售管理系統繼續如往常一樣。
為了延續內部改變的觀念,IT 經理可能會發現,軟體的新配置還可以以另外的一種方式加以使用,比如出租貼上海報的地方以供廣告之用。這裡,新的業務提議是通過在新的設計中重用靈活的 SOA 模型得出的。這是來自 SOA 模型的新成果,並且還是一個新的機會,而這樣的新機會在以前可能是不會有的。
垂直改變也是可能的,在這種改變中,零售商從銷售他們自己的服裝完全轉變到專門通過店中店模型出租地方。如果垂直改變完全從最底層開始的話,就會帶來 SOA 模型結構的顯著改變,與之一起改變的還可能有新的系統、軟體、流程以及關係。在這種情況下,SOA 模型的好處是它從業務操作和流程的角度考慮問題而不是從應用程式和程式的角度考慮問題,這使得業務管理可以根據業務的操作清楚地確定什麼需要添加、修改或刪除。然後可以將軟體系統構造為適合業務處理的方式,而不是在許多現有的軟體平台上常常看到的其他方式。
正如您可以看到的,在這裡,改變和 SOA 系統適應改變的能力是最重要的部分。對於開發人員來說,這樣的改變無論是在他們工作的範圍之內還是在他們工作的範圍之外都有可能發生,這取決於是否有改變需要知道接口是如何定義的以及它們相互之間如何進行互動。與開發人員不同的是,架構師的作用就是引起對 SOA 模型大的改變。這種分工,就是讓開發人員集中精力於創建作為服務定義的功能單元,而讓架構師和建模人員集中精力於如何將這些單元適當地組織在一起,它已經有十多年的歷史了,通常用統一建模語言(Unified Modeling Language,UML),並且描述成模型驅動的體系結構(Model-Driven Architecture,MDA)。
儘管J2EE和.NET平台是開發SOA應用程式常用的平台,但SOA不僅限於此。像J2EE這類平台,不僅為開發者自然而然地參與到SOA中來提供了一個平台,還通過他們內在的特性,將可擴展性,可靠性,可用性以及性能引入了SOA世界。新的規範,例如 JAXB(Java API for XML Binding),用於將XML文檔定位到Java類;JAXR(Java API for XML Registry)用來規範對UDDI註冊表(registry)的操作;XML-RPC(Java API for XML-based Remote Procedure Call)在J2EE1.4中用來調用遠程服務,這使得開發和部署可移植於標準J2EE容器的Web服務變得容易,與此同時,實現了跨平台(如.NET)的服務互用。
服務品質
在企業中,關鍵任務系統(mission-critical system,譯註:關鍵任務系統是指如果一個系統的可靠性對於一個組織是至關重要的,那么該系統就是該企業的關鍵任務系統。比如,電話系統對於一個電話促銷企業來說就是關鍵任務系統,而文字處理系統就不那么關鍵了。)用來解決高級需求,例如安全性,可靠性,事物。當一個企業開始採用服務架構作為工具來進行開發和部署套用的時候,基本的Web服務規範,像WSDL,SOAP,以及UDDI就不能滿足這些高級需求。正如前面所提到的,這些需求也稱作服務品質(QoS,quality of services)。與QoS相關的眾多規範已經由一些標準化組織(standards bodies)提出,像W3C(World Wide Web Consortium)和OASIS(the Organization for the Advancement of Structured Information Standards)。下面的部分將會討論一些QoS服務和相關標準。
當企業著手於服務架構時,服務可以用來整合數據倉庫(silos of data),應用程式,以及組件。整合套用意味著例如異步通信,並行處理,數據轉換,以及校正等進程請求必須被標準化。在SOA中,進程是使用一組離散的服務創建的。BPEL4WS 或者 WSBPEL(Web Service Business Process Execution Language)是用來控制這些服務的語言。WSBPEL也由OASIS負責。
管理能力
隨著企業服務的增長,所使用的服務和業務進程的數量也隨之增加,一個用來讓系統管理員管理所有運行在多相環境下的服務的管理系統就顯得尤為重要。WSDM(Web Services for Distributed Management)規定了任何根據WSDM實現的服務都可以由一個WSDM適應(WSDM-compliant)的管理方案來管理。
在理解SOA和Web服務的關係上,經常發生混淆。根據2003年4月的Gartner報導,Yefim V. Natis就這個問題是這樣解釋的:“Web服務是技術規範,而SOA是設計原則。特別是Web服務中的WSDL,是一個SOA配套的接口定義標準:這是Web服務和SOA的根本聯繫。”從本質上來說,SOA是一種架構模式,而Web服務是利用一組標準實現的服務。Web服務是實現SOA的方式之一。用Web服務來實現SOA的好處是你可以實現一個中立平台,來獲得服務,而且隨著越來越多的軟體商支持越來越多的Web服務規範,你會取得更好的通用性。