面向服務架構(SOA)的原則

- 中國WEB開發者網絡 (http://www.webasp.net)
-- 技術教程 (http://www.webasp.net/article/)
--- 面向服務架構(SOA)的原則 (http://www.webasp.net/article/23/22115.htm)
-- 作者:未知
-- 發佈日期: 2005-04-30

分佈式計算將網絡上分佈的軟件資源看作是各種服務。面向服務架構是一種不錯的解決方案。但這種架構不是什麼新思想;CORBA和DCOM就很類似,但是,這些過去的面向服務架構都受到一些難題的困擾:首先,它們是緊密耦合的,這就意味著如分佈計算連接的兩端都必須遵循同樣API的約束。打比方說,如果一個COM對象的代碼有了更改,那麼訪問該對象的代碼也必須作出相應更改。其二,這些面向服務架構受到廠商的約束。Microsoft控制DCOM自不必說,CORBA也只是一個偽裝的標準化努力,事實上,實現一個CORBA架構,經常都是在某個廠商對規範的實現上進行工作。

Web services是在改進DCOM和CORBA缺點上的努力。今天應用Web services的面向服務架構與過去不同的特點就在於它們是基於標準以及鬆散耦合的。廣泛接受的標準(如XML和SOAP)提供了在各不同廠商解決方案之間的交互性。而鬆散耦合將分佈計算中的參與者隔離開來,交互兩邊某一方的改動並不會影響到另一方。這兩者的結合意味著公司可以實現某些Web services而不用對使用這些Web services的客戶端的知識有任何瞭解。我們將這種基於標準的、鬆散耦合的面向服務的架構簡稱為SOA。

SOA的強大和靈活性將給企業帶來巨大的好處。如果某組織將其IT架構抽像出來,將其功能以粗粒度的服務形式表示出來,每種服務都清晰地表示其業務價值,那麼,這些服務的顧客(可能在公司內部,也可能是公司的某個業務夥伴)就可以得到這些服務,而不必考慮其後台實現的具體技術。更進一步,如果顧客能夠發現並綁定可用的服務,那麼在這些服務背後的IT系統能夠提供更大的靈活性。但是,要得到種強大和靈活性,需要有一種實現架構的新方法,這是一項艱巨的任務。企業架構設計師必須要變成“面向服務的架構設計師”,不僅要理解SOA,還要理解SOA的實踐。在架構實踐和最後得到的架構結果之間的區別非常微妙,也非常關鍵。本文將討論SOA的實踐,即:面向架構的設計師在構建SOA時必須要做的事情。

SOA的原則

要滿足這種業務敏捷性,SOA的實踐必須遵循以下原則:

* 業務驅動服務,服務驅動技術

從本質上說,在抽像層次上,服務位於業務和技術中間。面向服務的架構設計師一方面必須理解在業務需求和可以提供的服務之間的動態關係,另一方面,同樣要理解服務與提供這些服務的底層技術之間的關係。

* 業務敏捷是基本的業務需求

SOA考慮的是下一個抽像層次:提供響應變化需求的能力是新的“元需求”,而不是處理一些業務上的固定不變的需求。從硬件系統而上的整個架構都必須滿足業務敏捷的需求,因為,在SOA中任何的瓶頸都會影響到整個IT環境的靈活性。

* 一個成功的SOA總在變化之中

SOA工作的場景,更像是一個活的生物體,而不是象傳統所說的“蓋一棟房子”。IT環境唯一不變的就是變化,因此面向服務架構設計師的工作永遠不會結束。對於習慣於蓋房子的設計師來說,要轉向設計一個活的生物體要求嶄新的思維方式。如下文所寫的,SOA的基礎還是一些類似的架構準則。

SOA基礎

在IT行業有兩個越來越普遍的發展方向,一個是架構方面的,一個是方法學方面的,面向服務的架構設計師可以從中有所收穫。第一個就是MDA(模型驅動架構),由提出CORBA的OMG模型提出。MDA認為架構設計師首先要對待創建的系統有一個形式化的UML(也是由OMG提出)的模型。MDA首先給出一個平台無關的模型來表示系統的功能需求和use cases,根據系統搭建的平台,架構設計師可以由這個平台無關的模型得到平台相關的模型,這些平台相關模型足夠詳細,以至於可以用來直接生成需要的代碼。

MDA的核心就在於在設計階段系統就已經完全描述,這樣,在創建系統的時候,幾乎就沒有錯誤解釋的可能,模型也就可以直接生成代碼。但MDA有一些局限性:首先,MDA假設在創建模型之前,業務需求已經全部描述,而這一點,在當前典型的動態業務環境中幾乎是不可能的。第二,MDA沒有一個反饋機制。如果開發人員對模型有需要改動的地方,並沒有提供給他們這麼一個途徑。

SOA的另一個基礎是敏捷方法(AM),其中非常有名的方法是極限編程(XP)。像XP這樣的AM提供了在需求未知或者多變的環境中創建軟件系統的過程。XP要求在開發團隊中要有一個用戶代表,他幫助書寫測試來指導開發人員的日常工作。開發團隊中的所有成員都參與到設計之中,並且設計要盡量小並且非形式化。AM的目標是僅僅創建用戶想要的,而不是在一些形式化模型上耗費工作量。AM的核心思想就在於其敏捷性-處理需求變更的敏捷性。AM的主要弱點是其規模上的限制,例如,XP在一個小團隊和中型項目中效果不錯,但是當項目規模增大時,如果沒有一個一致的清晰的計劃,項目成員很難把握項目中的方方面面。

從表面看來,MDA和AM似乎是相對立的-MDA假定需求是固定的,而AM恰恰相反。MDA的中心是形式化的模型,而AM恰恰要避開它們。但是,我們還是決定冒險把這些不同方法中的一些元素提取出來,放入到一個一致的架構實踐中。

在SOA中有三個抽像層次,按照SOA的第一條準則:業務驅動服務、服務驅動技術。AM將業務模型直接和實踐連接起來,表現在平台相關的模型之中。MDA並沒有把業務模型和平台無關模型分開來,而是把平台無關模型做為起點。SOA必須連接這些模型,或者說抽像層次,得到單一的架構方法。我們將從五個視圖的架構實現方法來實現這個連接。

SOA的五視圖實現方法


企業架構設計師發現他們的職業非常有競爭力並且值得驕傲,因為他們要從很多方面來通盤考慮IT系統。Kruchten(RUP的開發負責人)將這些方面提取出來,在應用到SOA時,我們稱為五視圖實現方法(five-view approach)。

四個方框表示對一個架構的不同審視方法,分別代表不同的涉眾(stakeholder)。弟五個視圖,use-case視圖涵蓋了其它視圖,在架構中扮演的是一個特殊的角色。部署視圖將軟件映射到底層平台和相關硬件上,是系統部署人員對架構的視圖;實現視圖描述了軟件代碼的組織,是從開發人員角度出發的視圖;業務分析人員則利用過程視圖進行工作,它描述的是軟件系統的運行時特性。最後,邏輯視圖表示的是用戶的功能需求。在SOA中,面向服務的架構必須能夠以use-case視圖中的用例將用戶連接到服務,將服務連接到底層的技術。

為了表示面向對象的架構是如何工作在這些視圖之上,讓我們將他們置於SOA元模型的上下文之中。SOA中兩個領域存在重疊:由業務模型和服務模型表示的業務領域和由服務模型及平台相關模型表示的技術領域(兩個領域共享服務模型)。業務用戶通過邏輯視圖和過程視圖處理粗粒度的業務服務,根據變化的業務需求,按照需要將它們安排在過程之中。另一方面,技術專家的工作是創建並維護服務和地層技術之間的抽像層。表示這些服務的中間模型,起到的是軸心的作用,業務以它為中心進行。

SOA元模型從MDA中繼承平台無關模型和平台相關模型,但是添加了AM和用戶交互以及敏捷的反饋這兩部分,後者通過橢圓之間的雙向箭頭來表現。類似地,元模型通過引入由中心的服務模型提供的中間層抽像解決了AM在伸縮性方面的問題。這樣,服務模型中的任何需求的變化,都會反映到用戶每天的業務處理中。同樣,由於底層技術是模型驅動的,技術專家也可以根據這些變化的需求迅速而有效地作出應變。

SOA實踐和過去解決企業架構傳統方式的不同之處就在於其對敏捷性的支持。如前所說,SOA的第三條原則就在於它總在變化之中。這種恆在的變化性環境是SOA實踐的基石。如圖所示,涉眾(stakeholders,譯者註:RUP中也有這個詞,表示軟件開發中涉及到的各種角色如:用戶、設計人員、開發人員乃至測試人員等等。)在一個必需的基礎上影響到整個架構的變化。在當技術專家在每天的日常工作中不斷對變化的業務需求作出響應的這種情況下,設計階段和運行階段之間的界限變得模糊起來,很難清晰地分離這兩個階段。

剩下的部分

我們已經為面向服務的架構提供了一個高層次的框架,其中MDA和AM的元素幫助工具的使用者來創建和維護SOA。但是,SOA中還缺少一些內容-那就是軟件開發商和專業的服務組織必需提供的。理想情況下,開發商必需提供面向服務的業務流程、工作流以及服務的協調工具和服務;另外,能夠以一種敏捷的、平台無關的方式充分反映業務服務的建模工具也是必須的;技術專家必須配備可以從模型中自動生成代碼,並在代碼變化時更新模型的工具,最後,開發商必須提供支持SOA的軟件,幫助面向服務的架構設計師以一種可信並且可伸縮的方式創建位於服務和底層技術之間的抽像層次。幸運的是,這方面的產品即將上市。

另外,最重要的就是貫穿本文的自頂而下的SOA實現方法了。今天關於Web services的大部分思考都是自底而上的:“這是如何創建Web services的方法,現在,我們來使用它們集成吧”,對Web services技術的這種方法是偉大的第一步,因為它可以驚人地降低集成的開銷,這是現在的技術管理人員最樂意見到的了。但當經濟進一步發展,IT走出低谷,企業會尋求IT的幫助來提高組織戰略意義上的核心價值。使用面向服務的架構,IT可以提供給企業實現業務敏捷性的這樣一個框架。

 

 


webasp.net