淺析面向構件的SOA架構設計

概述

目前，關于SOA（面向服務的架構）的研究和討論已經成為IT業界的新熱點。盡管各方研究者和專家對SOA架構的認識和理解不盡相同，各IT廠商提供的SOA解決方案也不一而足，SOA相關標準仍在不斷發展和完善之中，但大家卻都有一個共同的認識，那就是SOA代表著今后一段時期軟件技術的發展方向，并已經開始從研究階段進入實施和推廣階段。本文試圖從面向構件的角度，介紹一些SOA架構設計的基本思想和方法論。首先簡單介紹一些構件設計和實現的基礎知識，然后重點介紹面向服務設計的基本原則和方法。

構件的組成要素



構件是軟件開發、復用和軟件組裝的實體單元，包括以下要素：構件類型（componenttype）、構件實現（componentimplement）、提供接口（provides-interfaces）和依賴接口（requires-interface）。

構件類型（componenttype）：構件類型表明構件是處理什么問題和提供哪些接口功能，它包含了構件類型的名稱。

構件實現（componentimplement）：對構件類型的具體實現稱為構件實現，一個構件類型可能有多個構件實現。

提供接口（provides-interfaces）：提供接口指構件提供給外部程序使用的接口。

依賴接口（requires-interface）：依賴接口指構件運行時所必須依賴的外部程序接口。

構件的基本特征

復用：復用是構件最基本的性質，構件的設計必須滿足未來能在新的應用、項目中使用。

封裝：構件封裝對外界隱藏構件的設計和實現細節，僅通過接口與外界交互。這可以保證構件功能復用的完整性和構件開發及交付的獨立性。

組裝：構件可以通過組裝形成新的構件或系統，組裝是構件復用的手段，同時具備可插拔，便于替換，系統可以由不同的開發商開發的構件組裝而成。

粒度：構件是有大小的，越是跟領域相關的構件粒度越大，小粒度的構件可以方便的組裝成較大粒度的構件。

層次：構件可以按層次進行劃分，企業級應系統的復雜邏輯可以通過層次來解決，不同的層次需要不同層次的構件。按照MVC的體系架構，可以把構件劃分為：展現層、控制層、業務層、運算層及數據層等。

構件的實現

目前軟件市面上有三個代表性的構件技術標準分別是：COM/DCOM、CORBA和EJB。

COM/DCOM：COM（Conponent Object Model）是由Microsoft公司推出的構件接口標準，DCOM是指可以分布式布的COM。

CORBA：CORBA（Common Object Request Broker Architecture）是由對象管理組織（OMG）提出的構件技術標準。

EJB：EJB是由SUN公司提出的構件技術標準。

以上三種構件標準實現的構件互相依賴的方式仍然是基于對象接口式的，當系統復雜度到一定規模時，整個系統會因依賴關系混亂而陷入失控。

比較理想的構件模型是構件之間是數據耦合的，每個構件只單獨與數據總線發生聯系。當需求發生變化時，可以對各個單獨的構件進行添加、減少或者修改而不影響整體的架構和性能?；跀祿詈系臉嫾?，據有很高的獨立性，對需求變化有較強的適應能力。

構件技術與構件化

構件技術與構件化的區別在于，構件化的關注點不在于構件本身的技術實現，而在于如何把應用系統分解成穩定、靈活、可重用的構件，在于如何利用已有的構件庫組裝出隨需應變的應用軟件，從一個面向構件的環境中去分析應用，如何做出靈活、重用的構件來思考。但是，構件技術是構件化的基礎，它為構件的工廠化生產提供技術保障。傳統的軟件方法學是從面向機器、面向數據、面向過程、面向功能、面向數據流等反映問題的本質；而構件技術關注的是在構件已經可用的情況下，在更高層次上的組裝和復用。面向構件的軟件設計方法把裝配和制造分離，構件運行時負責提供標準接口和框架，負責軟件裝配，而構件負責軟件的制造，使軟件開發變成構件的組裝。

接下來，我們將開始介紹面向服務（SOA）的設計。

面向服務設計



服務代表一段完整的業務單元，并且可以根據特定用戶的需求組織成為更大和新的服務。服務可以由一個或多個構件組合而成。服務開發者必須考慮構件的粒度，以及構件的流程和組裝，這樣他們在改變服務的實現時，可以盡可能少的影響其它構件、應用和服務。而服務的設計者則更關心選擇合適的服務，并將它們以可管理的方式組織，并最終將它們組裝為完整的業務流程。

“面向服務”表示一種分離系統關注面的方法，其實質是將一個比較大的問題分解成一系列較小的、互相關聯的子問題，從而降低問題的復雜度，使得我們能夠較從容地分析、解決和管理它。傳統的面向對象的設計方法其實也是一種分離系統關注面的方法，只不過它是在對象層面來分離關注面，相對業務邏輯較遠，而面向服務則是在服務層面來分離關注面，直接關注的是業務邏輯，從而使面向服務能夠(至少在理論上)更好地滿足業務需求。

其實，就現實世界而言，到處都是面向服務的業務。一座城市向居住或來到這個城市的人提供各種各樣的服務。這些服務分別由不同的服務提供者提供，這些服務提供者包括政府部門、企業、社會團體和自由職業者等。人們早已習慣為享受某種服務而參與某種業務，商業機構也早已習慣為發展某項業務而向公眾或其他團體提供某種服務?？梢哉f，服務和業務是有著某種天然聯系的，具有很強的業務親和力和包容度。面向服務的架構就是要通過將信息技術直接作用于服務的實現，從而實現信息技術與實際業務的優質對接。

面向服務設計原則

封裝原則 為了保持自治（Autonomy）和抽象（Abstraction），服務封裝了其內部的邏輯，同時對外部進行隱藏（服務契約規定的除外）。服務從來都不是孤立的，它必定有其適用的上下文環境。上下文環境可以是一個業務規則、一個業務實體或者一些業務邏輯的組合。業務可大可小，因此服務所關注的問題可大可小，服務所表示的業務邏輯的規模和范圍也各不相同。此外，服務還可包含其他服務提供的業務邏輯，在這種情況下，一個大的服務由多個子服務組合而成。例如，一個業務自動化處理解決方案通常是一套業務流程的實現。按照業務規則和運行時條件，一個業務流程被分解成預先定義好順序的一系列步驟。在基于服務來構建該業務流程的自動化解決方案的時候，每一個步驟可以被封裝為一個服務，或者可以先將多個步驟組合成的一個子流程，然后再將該子流程封裝為一個服務，甚至可以將整個流程封裝為一個服務。

關聯原則 服務可以被其它服務調用，因此服務與服務之間必須建立某種特殊的聯系，我們稱為關聯。關聯過多會造成服務之間的緊耦合，最終導致整個架構的脆弱。為避免這種情況，服務設計者需要謹慎地選擇服務，使它們之間建立“松耦合”（Loose coupling）的關系，使得服務之間的耦合降到業務需要的最低，從而使服務之間僅維持相互了解所必須的最少的依賴關系。

服務之間的相互了解是通過服務描述(Service description)來實現的。服務描述至少要包含服務的名稱、它所實現的具體功能、以及服務的使用方式和調用的返回值等。為了保證服務描述能夠被其它服務容易地理解，需要遵守共同的描述方式和語法——服務契約。通過標準的服務契約，服務可以相互理解，無須或很少人工干預。

復用原則 服務應該是可復用（Reusability)的。它不僅可以被其它服務或使用者調用，而且可以與其它服務一起組合成新的服務。

SOA通過服務、服務契約和消息通訊提供了一個支撐復用性的基本架構。其中，服務的精細度是決定服務復用程度的最重要因素。一般而言，服務的精細度越高，服務越細致，其復用性也就越強。但是隨之而來的系統的復雜度也會越來越大，服務多，意味著系統必須同時維護大量不同的服務及其組合，反過來會降低復用的意義。此外，同等條件下，服務的開發成本相比傳統的基于模塊或類的開發方法要高。原因是，服務不僅要完整實現其業務功能和保證其自身的性能（這一點和傳統開發方法一樣），而且還要符合SOA所要求的各項規定，以保證SOA架構的統一。因此，服務不是越多越好，服務的設計者必須準確把握服務的精細度，在保障總實現成本最低的同時，還要遵循SOA架構的標準和規范，從而真正發揮SOA架構的優勢。

質量原則 在SOA架構中，服務是最小設計單元。如果把SOA比喻為一座大廈，那么服務就是構建整座大廈的磚石。顯然，服務必須滿足一定的質量要求，才能真正被SOA所用。這里的質量要求，不僅包括業務功能的要求，還應包括其它非功能性要求，如可用性、性能、伸縮性、安全性以及隱私策略等。在不同的上下文中，對服務質量的要求也不盡相同。因此，服務還應具備靈活適應各種不同服務宿主環境的能力，滿足各種環境下對服務質量的要求，甚至可以根據不同的環境自動提供與之相適應的質量屬性供其選擇。

在服務上下文中，服務質量(QoS)可以看作為一種基于一組定量特性提供保證的機制。這些特性基于重要的功能性和非功能性服務質量屬性來進行定義，其中包括實現和部署相關的問題以及其他的重要服務特性，例如：服務測量和計費、性能衡量（如響應時間）、安全需求、（事務）完整性、可靠性、伸縮性和可用性等。對于理解服務的整體行為使得其他應用程序可以與其進行綁定并使其作為商業過程的一部分而執行，這些特性是很必要的。

在Web服務環境中，支持服務質量(QoS)的關鍵元素包括可用性（服務持續對外提供的能力）、完整性（功能實現的程度）、性能（吞吐量和延遲）、可靠性（用每月或每年的事務失敗數表示）、伸縮性和安全性（認證、授權、消息完整性和機密性）。

Web服務采用服務水平協議(SLA)作為服務提供者和使用者的正式協議，即用一種服務提供者和使用者共同理解和同意的形式描述Web服務的詳細信息。為達到服務的設計目標，服務提供者和使用者都必須遵守SLA，因此SLA在維持服務供應關系中是一種重要并且應用廣泛的工具。

SLA中的衡量標準必須和提供的服務的整體目標關聯起來。針對這個問題，Web服務標準組建立了一個標準的策略框架，如Web服務策略框架（WS-Policy），使得開發人員能夠表達服務的策略，Web服務能夠理解這些策略并在運行時實施它們。

在面向服務的基礎上，我們還需要對業務流程進行梳理和整合，從而使得我們能夠迅速地采用面向構件的SOA架構來實現它。因此，我們需要對流程進行重新設計。需要特別指出的是，這里的重新設計是指采用構件技術，用面向服務的思想對業務流程進行梳理、分解和整合，并不是一味地要求業務實際改變原有的流程來適應技術上的要求。雖然我們鼓勵業務和技術相結合，但這并不是SOA要解決的問題。

流程設計一方面要將冗繁的、復雜的業務實際分解為若干個流程或子流程，另一方面需要考慮選擇什么服務或開發什么服務，然后通過服務的組合來實現具體的業務流程。就前者而言，將業務實際分為若干服務領域是一種常用的分析方法。服務領域是一個業務域，由一系列彼此相關又相互協作的具體業務流程組成，例如貸款、保險、銀行、商業、制造和人力資源等。從這個角度上說，一個應用可以分解為若干不同服務領域(業務領域)，每個服務領域可以由一組專門針對該領域開發的服務和一些通用的基礎服務組合而成。

總結

面向構件的SOA架構是一項令人鼓舞的技術，人們期待它解決長期困擾軟件工程領域的軟件復用和軟件靈活性問題。需要特別指出的是，面向構件并不是實現SOA架構的唯一手段，我們應該根據項目的實際情況選擇適當的技術來實現SOA。

(責任編輯：銘銘 mingming_ky#126.com TEL：（010）－68476636)