面向服務架構（SOA）的原則

2019-11-18 12:30:24

字體：大中小

來源：轉載

供稿：網友

　　Web service已經不再是新婚的娘子。眾多企業都已經創建各種實驗性Web Services 項目，事實證實，這項新興的分布式計算技術確實能夠降低集成和開發的成本。另外，一些要害的Web Services標準紛紛制定，強安全（robust security）和治理方面的產品也陸續問世。對于志向遠大的企業來說，他們已經在考慮下一步了。
　　
　　對大多數公司來說，下一步要考慮的不再是點對點的應用，而是Web services在企業間以及業務伙伴間更為寬廣的應用。這種技術的變遷需要更松散耦合、面向基于標準的服務的架構。這樣一個架構要求對IT在組織中的角色有新的觀點和熟悉，而不僅僅是一種實現方法。通過對業務的靈敏反應，企業可以得到實實在在的回報，而要達到這一點，面向服務架構設計師的角色非常要害。除此之外，潛在的回報更是不可勝數－分布計算技術能夠保證對業務需求足夠靈活的反應，而這種業務上的靈敏正是各公司夢寐以求而目前還遙不可及的。
　　
　　分布式計算將網絡上分布的軟件資源看作是各種服務。面向服務架構是一種不錯的解決方案。但這種架構不是什么新思想；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考慮的是下一個抽象層次：提供響應變化需求的能力是新的“元需求”，而不是處理一些業務上的固定不變的需求。從硬件系統而上的整個架構都必須滿足業務靈敏的需求，因為，在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中還缺少一些內容－那就是軟件開發商和專業的服務組織必需提供的。理想情況下，開發商必需提供面向服務的業務流程、工作流以及服務的協調工具和服務；另外，能夠以一種靈敏的、平臺無關的方式充分反映業務服務的建模工具也是必

上一篇：J2EE體系結構

下一篇：對J2EE幾點的理解