架構設計師與SOA)

　SOA(Service-Oriented Architecture)，即面向服務的架構，這是最近一兩年出現在各種技術期刊上最多的詞彙了。現在有很多架構設計師和設計開發人員簡單的把SOA和Web Services技術等同起來，認為SOA就是Web Service的一種實現。本質上來說，SOA體現的是一種新的系統架構，SOA的出現，將為整個企業級軟體架構設計帶來巨大的影響。本系列兩部分文章將根據作者自己的理解來協助大家分析和瞭解什麼是SOA架構，SOA將怎樣對企業系統架構設計帶來積極的影響，什麼是SOA架構設計師的角色，以及SOA架構師在設計SOA系統架構時有哪些應該特別注意的地方。

　　1. 什麼是架構?什麼是基於SOA的架構?

　　1.1 什麼是架構

　　從架構設計師的角度來看，架構就是一套構建系統的準則。通過這套準則，我們可以把一個複雜的系統劃分為一套更簡單的子系統的集合，這些子系統之間應該保持相互獨立，並與整個系統保持一致。而且每一個子系統還可以繼續細分下去，從而構成一個複雜的企業級架構。

　　當一名架構設計師在構建某個企業級的軟體系統時，除了要考慮這個系統的架構以及其應具有的功能行為以外，還要關注整個架構的可用性，效能問題，容錯能力，可重用性，安全性，擴充性，可管理維護性，可靠性等各個相關方面。有的時候一名好的架構設計師甚至還需要考慮所構建的系統架構是否合乎美學要求。由此我們可以看到，我們衡量一個好的架構設計並不能只從功能角度出發，還要考慮很多其他的因素，對任何一個方面的欠缺考慮都有可能為整個系統的構建埋下隱患。

　　1.2 什麼是基於SOA的架構

　　SOA本身就是一種面向企業級服務的系統架構，簡單來說，SOA就是一種進行系統開發的新的體系架構，在基於SOA架構的系統中，具體應用程式的功能是由一些松耦合并且具有統一介面定義方式的組件(也就是service)組合構建起來的。因此，基於SOA的架構也一定是從企業的具體需求開始構建的。但是，SOA和其它企業架構的不同之處就在於SOA提供的業務靈活性。業務靈活性是指企業能對業務變更快速和有效地進行響應、並且利用業務變更來得到競爭優勢的能力。對企業級架構設計師來說，建立一個業務靈活的架構意味著建立一個可以滿足當前還未知的業務需求的IT架構。

　　利用基於SOA的系統構建方法，1中所示的一樣，一個基於SOA架構的系統中的所有的程式功能都被封裝在一些功能模組中，我們就是利用這些已經封裝好的功能模組組裝構建我們所需要的程式或者系統，而這些功能模組就是SOA架構中的不同的服務(services)。

　　

圖1

　　因此，SOA架構本質上來說體現了一種複合的概念:它不僅為一個企業中商業流程的組織和實現提供了一種指導模式，同時也為具體的底層service開發提供了指導。

　　2. SOA架構設計師的角色

　　2.1 SOA架構設計師應該具備什麼?

　　談到SOA架構設計師的角色，我們首先要瞭解架構設計師應具有的能力。總體上來說，一個好的架構設計師不僅應該是一個成熟的，具有實際經驗的並具有快速學習能力的人，而且他還應該具有良好的管理能力和溝通能力。只有具備了必需的能力，架構設計師才能在關鍵的時刻作出困難的決定，這就是一名架構設計師應該承擔的責任。從角色上來看，SOA 架構師不僅會負責端到端的服務要求者和提供者的設計，並且會負責對系統中非功能服務要求的調研和表述。

　　對於任何一名經驗豐富的架構設計師來說，不論他是採用基於傳統的架構設計方法(基於J2EE架構或者.NET架構)還是採用基於SOA的架構設計方法來構建一個企業級的系統架構，具有相關商業領域的知識對於架構設計師來說都是必不可少的，架構設計師往往可以通過實際的工作經驗積累以及接受相關的專項培訓來獲得這些商業領域的知識。除了具有相關商業領域的知識以外，一名合格的架構設計師必須具有較廣泛的技術背景，這可能包括軟硬體，通訊，安全等各個方面的知識。但這並不是意味著要成為一名架構設計師就必須熟悉每一門具體技術的細節，架構設計師必須至少能對各種技術有一個整體上的瞭解，能夠熟知每種技術的特點以及優缺點，只有這樣架構設計師才能在特定的應用情境下正確地選擇各種技術來設計企業整體架構。

　　2.2 什麼是SOA架構設計師的職責?

　　那什麼是企業級SOA架構設計師的具體角色呢?什麼是SOA架構設計師與設計和開發人員之間的差別呢?相信這些都是使大家最容易產生迷惑的問題。舉個實際的例子來說，當構建一個基於SOA架構的系統的時候，針對一個具體的 service，系統設計人員主要應該關注的是這個service能夠為外部使用者提供什麼樣的服務，也就是說系統設計人員關注的是這個service所提供的功能。而對於SOA架構設計師來說，他們更關心的可能是當有一千個使用者同時調用這個 service的時候，什麼會發生?也就是說架構設計師關注的應該是一些商業需求和服務等級(service-level)需求。所有的架構設計師的角色都包含了在構建一個系統的一開始就應該盡量減少可能存在的技術風險。而技術風險一般指的是一切未知的、未經證明的或未經測試所帶來的風險。這些風險通常與服務等級(service-level)需求相關，偶爾也會與企業具體的業務需求相關。無論是哪種類型的風險，在項目初期設計整體系統架構的過程中更易於發掘這些風險，如果等到架構實施時再發覺這些風險，那麼很可能會致使大量的開發人員等在那裡，直到這些風險被妥善解決。如果進一步的細化，我們可以看到SOA架構設計師的主要任務包括對整個系統解決方案輪廓的構建，需求分析，對體繫結構的整體決策，相關組件建模，相關操作建模，系統組件的邏輯和物理布局設計。

　　作為SOA架構設計師必須要能夠領導整個Team Dev，這樣才能保證設計和開發人員是按照構建好的系統架構來開發整個系統的，這一點十分的重要。這就要求一名架構設計師不僅要有很好的技術洞察力，同時還要具有一定的專案管理和項目實施的能力。在系統開發的過程中，架構設計師必須要有良好的溝通和表達能力，這就體現在由架構設計師構建的系統模型是否具有很好的可讀性和易理解性。如果由架構設計師構造出的系統模型不是很清晰的話，就可能會影響設計和開發人員對於整個系統架構的理解。為了避免這種情況的出現，定期由架構設計師主持的Team Dev內部討論是十分重要的。

　　3. 構建SOA架構時應該注意的問題

　　3.1 原有系統架構中的整合需求

　　當架構師基於SOA來構建一個企業級的系統架構的時候，一定要注意對原有系統架構中的整合需求進行細緻的分析和整理。我們都知道，服務導向架構是當前及未來應用程式系統開發的重點，服務導向架構本質上來說是一種具有特殊性質的體繫結構，它由具有互通性和位置透明的組件整合構建並互連而成。基於SOA的企業系統架構通常都是在現有系統架構投資的基礎上發展起來的，我們並不需要徹底重新開發全部的子系統;SOA可以通過利用當前系統已有的資源(開發人員、軟體語言、硬體平台、資料庫和應用程式)來重複利用系統中現有的系統和資源。SOA是一種可適應的、靈活的體繫結構類型，基於SOA構建的系統架構可以在系統的開發和維護中縮短產品上市時間，因而可以降低企業系統開發的成本和風險。因此，當SOA架構師遇到一個十分複雜的企業系統時，首先考慮的應該是如何重用已有的投資而不是替換遺留系統，因為如果考慮到有限的預算，整體系統替換的成本是十分高昂的。

　　當SOA架構師分析原有系統中的整合需求的時候，不應該只限定為基於組件構建的已有應用程式的整合，真正的整合比這要寬泛得多。在分析和評估一個已有系統體繫結構的整合需求時，我們必須考慮一些更加具體的整合的類型，這主要包括以下幾個方面:應用程式整合的需求，終端使用者介面整合的需求，流程整合的需求以及已有系統資訊整合的需求。當SOA架構師分析和評估現有系統中所有可能的整合需求的時候，我們可以發現實際上所有整合方式在任何種類的企業中都有一定程度的體現。針對不同的企業類型，這些整合方式可能是簡化的，或者沒有明確地進行定義的。因而，SOA架構師在著手設計新的體繫結構架構時，必須要全面的考慮所有可能的整合需求。例如，在一些類型的企業系統內容中可能只有很少的資料來源類型，因此，系統中對訊息整合的需求就可能會很簡單，但在一些特定的系統中，例如航運系統中的EDI(Electronic Data Interchange 電子資料交換)系統，會有大量的電子資料交換處理的需求，因此也就會存在很多不同的資料來源類型，在這種情況下整個系統對於訊息資料的整合需求就會比較複雜。因此，如果SOA架構師希望所構建的系統架構能夠隨著企業的成長和變化成功地繼續得以保持，則整個系統構架中的整合功能就應該由服務提供，而不是由特定的應用程式來完成。

　　3.2 服務粒度的控制以及無狀態服務的設計

　　當SOA架構師構建一個企業級的SOA系統架構的時候，關於系統中最重要的元素，也就是SOA系統中的服務的構建有兩點需要特別注意的地方:首先是對於服務粒度的控制，另外就是對於無狀態服務的設計。

　　服務粒度的控制

　　SOA系統中的服務粒度的控制是一項十分重要的設計任務。通常來說，對於將暴露在整個系統外部的服務推薦使用粗粒度的介面，而相對較細粒度的服務介面通常用於企業系統架構的內部。從技術上講，粗粒度的服務介面可能是一個特定服務的完整執行，而細粒度的服務介面可能是實現這個粗粒度服務介面的具體的內部操作。 舉個例子來說，對於一個基於SOA架構的網上商店來說，粗粒度的服務可能就是暴露給外部使用者使用的提交購買表單的操作，而系統內部的細粒度的服務可能就是實現這個提交購買表單服務的一系列的內部服務，比如說建立購買記錄，設定客戶地址，更新資料庫等一系列的操作。雖然細粒度的介面能為服務要求者提供了更加細化和更多的靈活性，但同時也意味著引入較難控制的互動模式易變性,也就是說服務的互動模式可能隨著不同的服務要求者而不同。如果我們暴露這些易於變化的服務介面給系統的外部使用者，就可能造成外部服務要求者難於支援不斷變化的服務提供者所暴露的細粒度服務介面。而粗粒度服務介面保證了服務要求者將以一致的方式使用系統中所暴露出的服務。雖然服務導向架構(SOA)並不強制要求一定要使用粗粒度的服務介面，但是建議使用它們作為外部整合的介面。通常架構設計師可以使用BPEL來建立由細粒度操作組成的商務程序的粗粒度的服務介面。

　　無狀態服務的設計

　　SOA系統架構中的具體服務應該都是獨立的、自包含的請求，在實現這些服務的時候不需要前一個請求的狀態，也就是說服務不應該依賴於其他服務的上下文和狀態，即SOA架構中的服務應該是無狀態的服務。當某一個服務需要依賴時，我們最好把它定義成具體的商務程序(BPEL)。在服務的具體實現機制上，我們可以通過使用 EJB 組件來實現粗粒度的服務。我們通常會利用無狀態的Session Bean來實現具體的服務，如果基於Web Service技術，我們就可以將無狀態的Session Bean暴露為外部使用者可以調用的到的Web服務，也就是把傳統的Session Facade模型轉化為了 EJB 的Web服務端點，這樣，我們就可以向 Web 服務客戶提供粗粒度的服務。

　　如果我們要在 J2EE的環境下(基於WebSphere)構建Web服務，Web 服務客戶可以通過兩種方式訪問 J2EE 應用程式。客戶可以訪問用 JAX-RPC API 建立的 Web 服務(使用 Servlet 來實現);Web 服務客戶也可以通過 EJB的服務端點介面訪問無狀態的Session Bean，但Web 服務客戶不能訪問其他類型的企業Bean，如有狀態的Session Bean，實體Bean和訊息驅動Bean。後一種選擇(公開無狀態 EJB 組件作為 Web 服務)有很多優勢，基於已有的EJB組件，我們可以利用現有的商務邏輯和流程。在許多企業中，現有的商務邏輯可能已經使用 EJB 組件編寫，通過 Web 服務公開它可能是實現從外界訪問這些服務的最佳選擇。EJB 端點是一種很好的選擇，因為它使商務邏輯和端點位於同一層上。另外EJB容器會自動提供對並發的支援，作為無狀態Session Bean實現的 EJB 服務端點不必擔心多線程訪問，因為 EJB 容器必須序列化對無狀態會話 bean 任何特定執行個體的請求。 由於EJB容器都會提供對於Security和Transaction的支援，因此Bean的開發人員可以不需要編寫安全的程式碼以及交易處理代碼。 效能問題對於Web服務來說一直都是一個問題，由於幾乎所有 EJB 容器都提供了對無狀態會話 Bean 群集的支援以及對無狀態Session Bean 池與資源管理的支援，因此當負載增加時，可以向群集中增加機器，Web 服務請求可以定向到這些不同的伺服器，同時由於無狀態Session Bean 池改進了資源利用和記憶體管理，使 Web 服務能夠有效地響應多個客戶請求。由此我們可以看到，通過把 Web 服務模型化為 EJB 端點，可以使服務具有更強的延展性，並增強了系統整體的可靠性。

　　4. 總結

　　本文簡要介紹了有關架構設計師以及SOA架構的知識，分析了SOA架構師在設計SOA系統架構時有哪些應該特別注意的地方。

　　本文的下部分將向您介紹在構建基於SOA架構的企業系統時應該怎樣保證所構建的系統架構能夠滿足系統中不同的服務等級需求。從架構設計師的角度，SOA是一種新的設計模式，方法學。因此，SOA本身涵蓋了很多的內容，也觸及到了系統整體架構設計、實現、維護等各個方面。本文的內容只是涉及到了有關於架構方面的一部分內容，希望能對廣大的SOA系統開發設計人員起到一定的協助作用。

 　本系列的上部分介紹了有關架構設計師以及 SOA 架構的知識，分析了 SOA 架構師在設計 SOA 系統架構時有哪些應該特別注意的地方。本文將延續第一部分的內容，向您介紹了 SOA 為企業級架構設計帶來的影響，以及在構建基於 SOA 架構的企業系統時應該怎樣保證所構建的系統架構能夠滿足系統中不同的服務等級需求。

　　1. SOA 為企業級架構設計帶來的影響

　　1.1 SOA 的特點及其使用範圍

　　SOA 既不是一種語言，也不是一種具體的技術，它是一種新的軟體系統架構模型。 SOA 最主要的應用場合在於解決在Internet環境下的不同商業應用之間的業務整合問題。Internet環境區別於Intranet環境的幾個特點主要是:

　　(a)大量異構系統並存，不同電腦硬體工作方式不同，作業系統不同、程式設計語言也不同;

　　(b)大量、頻繁的資料轉送的速度仍然相對較緩慢並且不穩定;

　　(c)無法完成服務(service)的版本升級，甚至根本就無法知道互連網上有哪些機器直接或者間接的使用某個服務。

　　SOA 架構具有一些典型特性，主要包括松耦合性，位置透明性以及協議無關性。松耦合性要求 SOA 架構中的不同服務之間應該保持一種松耦合的關係，也就是應該保持一種相對獨立無依賴的關係;位置透明性要求 SOA 系統中的所有服務對於他們的調用者來說都是位置透明的，也就是說每個服務的調用者只需要知道他們調用的是哪一個服務，但並不需要知道所調用服務的物理位置在哪裡;而協議無關性要求每一個服務都可以通過不同的協議來調用。通過這些 SOA 架構所具有的特性我們可以看到，SOA 架構的出現為企業系統架構提供了更加靈活的構建方式，如果企業架構設計師基於 SOA 來構建系統架構，就可以從底層架構的層級來保證整個系統的松耦合性以及靈活性，這都為未來企業商務邏輯的擴充打好了基礎。

　　1.2 SOA 架構的分層模型

　　接下來簡要介紹一下 SOA 系統中的分層模型，整個 SOA 架構的分層模型2所示。

　　在 SOA 系統中不同的功能模組可以被分為7層:第一層就是系統已經存在的程式資源，例如ERP或者CRM系統等。第2層就是組件層，在這一層中我們用不同的組件把底層系統的功能封裝起來。第3層就是 SOA 系統中最重要的服務層，在這層中我們要用底層功能組件來構建我們所需要的不同功能的服務。總的來說，SOA 中的服務可以被映射成具體系統中的任何功能模組，但是從功能性方面可以大致劃分為以下三種類型:(1)商務服務(business service) 或者是商業過程(business process)。這一類的服務是一個企業可以暴露給外部使用者或者夥伴使用的服務。比如說提交貸款申請，使用者信用檢查，貸款信用查詢。(2)商業功能服務(business function service)， 這類服務會完成一些具體的商業操作，也會被更上層的商務服務調用，不過大多數情況下這類服務不會暴露給外部使用者直接調用，比如說檢索使用者帳戶資訊，儲存使用者資訊等。(3)技術功能服務(technical function service)，這類服務主要完成一些底層的技術功能，比如說Log Service以及安全服務等。在服務層之上的第4層就是商業流程層，在這一層中我們利用已經封裝好的各種服務來構建商業系統中的商業流程。在商業流程層之上的就是第5層展示層了，我們利用展示層來向使用者提供使用者介面服務，這一層可以用基於portal的系統來構建。以上這5層都需要有一個整合的環境來支援它們的運行，第6層中的企業服務匯流排(ESB)提供了這個功能。第7層主要為整個 SOA 系統提供一些輔助的功能，例如服務品質管理，安全管理這一類的協助工具功能。

　　2. SOA 架構中的非功能性服務等級(service-level)需求

　　除了系統的業務需求，架構設計師還必須要保證構建出來的系統架構能夠滿足系統中的非功能性服務等級(service-level)需求以及服務品質(QoS)方面的需求。在項目初始及細化階段，架構設計師應該與系統所有涉及方(Stakeholders)一起，為每一個服務等級需求定義其相關的衡量標準。構建出的系統架構必須要能滿足以下幾方面的服務水準要求:效能、可升級性、可靠性、可用性、可擴充性、可維護性、易管理性以及安全性。架構設計師在設計架構過程中需要平衡所有的這些服務等級需求。例如，如果服務等級需求中最重要的是系統效能，架構設計師很有可能不得不在一定程度上犧牲系統的可維護性及可擴充性，以確保滿足系統效能上的要求。隨著互連網的發展，新構建的系統對於服務等級需求也變得日益重要，現在基於互連網的企業系統的使用者已經不僅僅局限於是本企業的僱員，企業的外部客戶也會成為企業系統的主要使用者。

　　架構設計師的職責之一就是要儘可能地為提高系統設計人員和系統開發人員的工作效率考慮。在構建整個企業系統架構的過程中，需要充分重視各種服務等級需求，從而避免在系統開發和啟動並執行時候出現重大問題。一個企業級系統中的服務等級需求往往是十分錯綜複雜的， SOA 架構設計師需要憑藉豐富的專業經驗和紮實的理論知識來分離和抽象系統中不同的服務等級需求，圖3展示了這種分析的過程。

　　圖3

　　經過 SOA 架構設計師分析和抽象的服務等級需求主要分為以下幾類:

　　﹡　效能是指系統提供的服務要滿足一定的效能衡量標準，這些標準可能包括系統反應時間以及處理交易量的能力等;

　　﹡　可升級性是指當系統負荷加大時，能夠確保所需的服務品質，而不需要更改整個系統的架構;

　　﹡　可靠性是指確保各應用及其相關的所有交易的完整性和一致性的能力;

　　﹡　可用性是指一個系統應確保一項服務或者資源永遠都可以被訪問到;

　　﹡　可擴充性是指在不影響現有系統功能的基礎上，為系統填加新的功能或修改現有功能的能力;

　　﹡　可維護性是指在不影響系統其他部分的情況下修正現有功能中問題或缺陷，並對整個系統進行維護的能力;

　　﹡　可管理性是指管理系統以確保系統的可升級性、可靠性、可用性、效能和安全性的能力;

　　﹡　安全性是指確保系統安全不會被危及的能力。

　　1) 效能

　　我們通常可以根據每個使用者訪問的系統回應時間來衡量系統的整體效能;另外，我們也可以通過系統能夠處理的交易量(每秒)來衡量系統的效能。對於架構設計師來說，無論採取哪種衡量系統效能的方法來構建系統架構，這些對於效能的考慮對系統設計開發人員來說都應該是透明的，也就是說對於系統整體架構效能的考慮應該是架構設計師的工作，而不是系統設計開發人員應該關注的事情。在較傳統的基於EJB或者XML-RPC的分散式運算模型中，它們的服務提供都是通過函數調用的方式進行的，一個功能的完成往往需要通過用戶端和伺服器來回很多次的遠程函數調用才能完成。在Intranet的環境下，這些調用給系統的響應速度和穩定性帶來的影響都可以忽略不計，但如果我們在基於 SOA 的架構中使用了很多Web Service來作為服務提供點的話，我們就需要考慮效能的影響，尤其是在Internet環境下，這些往往是決定整個系統是否能正常工作的一個關鍵決定因素。因此在基於 SOA 的系統中，推薦採用大資料量低頻率訪問模式，也就是以大資料量的方式一次性進行資訊交換。這樣做可以在一定程度上提高系統的整體效能。

　　2) 可升級性

　　可升級性是指當系統負荷加大時，仍能夠確保所需的服務品質，而不需要更改整個系統的架構。當基於 SOA 的系統中負荷增大時，如果系統的回應時間仍能夠在可接受的限度內，那麼我們就可以認為這個系統是具有可升級性的。要想理解可升級性，我們必須首先瞭解系統容量或系統的承受能力，也就是一個系統在保證正常運行品質的同時，所能夠處理的最大進程數量或所能支援的最大使用者數量。如果系統運轉時已經不能在可接受時間範圍內反應，那麼這個系統已經到達了它的最大可升級狀態。要想升級已達到最大負載能力的系統，你必須增加新的硬體。新添加的硬體可以以垂直或水平的方式加入。垂直升級包括為現在的機器增加處理器、記憶體或硬碟。水平升級包括在環境中添置新的機器，從而增加系統的整體處理能力。作為一個系統架構設計師所設計出來的架構必須能夠處理對硬體的垂直或者水平升級。基於 SOA 的系統架構可以很好地保證整體系統的可升級性，這主要是因為系統中的功能模組已經被抽象成不同的服務，所有的硬體以及底層平台的資訊都被屏蔽在服務之下，因此不管是對已有系統的水平升級還是垂直升級，都不會影響到系統整體的架構。

　3) 可靠性

　　可靠性是指確保各應用及其相關的所有交易的完整性和一致性的能力。當系統負荷增加時，你的系統必須能夠持續處理需求訪問，並確保系統能夠象負荷未增加以前一樣正確地處理各個進程。可靠性可能會在一定程度上限制系統的可升級性。如果系統負荷增加時，不能維持它的可靠性，那麼實際上這個系統也並不具備可升級性。因此，一個真正可升級的系統必須是可靠的系統。在基於 SOA 來構建系統架構的時候，可靠性也是必須要著重考慮的問題。要在基於 SOA 架構的系統中保證一定的系統可靠性，就必須要首先保證分布在系統中的不同服務的可靠性。而不同服務的可靠性一般可以由其部署的應用伺服器或Web伺服器來保證。只有確保每一個 SOA 系統中的服務都具有較高的可靠性，我們才能保證系統整體的可靠效能夠得以保障。

　　4) 可用性

　　可用性是指一個系統應確保一項服務或者資源應該總是可被訪問到的。可靠性可以增加系統的整體可用性，但即使系統組件出錯，有時卻並不一定會影響系統的可用性。通過在環境中設定冗餘組件和錯誤恢複機制，雖然一個單獨的組件的錯誤會對系統的可靠性產生不良的影響，但由於系統冗餘的存在，使得整個系統服務仍然可用。在基於 SOA 來構建系統架構的時候，對於關鍵性的服務需要更多地考慮其可用性需求，這可以由兩個層次的技術實現來支援，第一種是利用不同服務的具體內部實現內部所基於的架構的容錯或者冗餘機制來實現對服務可用性的支援;第二種是通過UDDI等動態尋找匹配方式來支援系統整體的高可用性。在 SOA 架構設計師構建企業系統架構的時候，應該綜合考慮這兩個方面的內容，盡量保證所構建的 SOA 系統架構中的關鍵性業務能具有較高的可用性。

　　5) 可擴充性

　　可擴充性是指在不影響現有系統功能的基礎上，為系統添加新的功能或修改現有功能的能力。當系統剛配置好的時候，你很難衡量它的可擴充性，直到第一次你必須去擴充系統已有功能的時候，你才能真正去衡量和檢測整個系統的可擴充性。任何一個架構設計師在構建系統架構時，為了確保架構設計的可擴充性，都應該考慮下面幾個要素:低耦合，介面(interfaces)以及封裝。當架構設計師基於 SOA 來構建企業系統架構時，就已經隱含地解決了這幾個可擴充性方面的要素。這是因為 SOA 架構中的不同服務之間本身就保持了一種無依賴的低耦合關係;服務本身是通過統一的介面定義(可以是WSDL)語言來描述具體的服務內容，並且很好地封裝了底層的具體實現。在這裡我們也可以從一個方面看到基於 SOA 來構架企業系統能為我們帶來的好處。

　　6) 可維護性

　　可維護性是指在不影響系統其他部分的情況下修改現有系統功能中問題或缺陷的能力。同系統的可擴充性相同，當系統剛被部署時，你很難判斷一個系統是否已經具備了很好的可維護性。當建立和設計系統架構時，要想提高系統的可維護性，你必須考慮下面幾個要素:低耦合、模組性以及系統文檔記錄。在企業系統可擴充性中我們已經提到了 SOA 架構能為系統中暴露出來的各個子功能模組也就是服務帶來低耦合性和很好的模組性。關於系統文檔紀錄，除了底層子系統的相關文檔外，基於 SOA 的系統還會引用到許多系統外部的由第三方提供的服務，因此如果人力資源准許的話，應該增加專職的文件管理員來專門負責有關整個企業系統所涉及的所有外部服務相關文檔的收集、歸類和整理，這些相關的文檔可能涉及到第三方服務的介面(可以是WSDL)、服務的品質和層級、具體效能測試結果等各種相關文檔。基於這些文檔，就可以為 SOA 架構設計師構建企業 SOA 架構提供很好的文檔參考和支援。

　　7) 可管理性

　　可管理性是指管理系統以確保整個系統的可升級性、可靠性、可用性、效能和安全性的能力。具有可管理性的系統，應具備對服務品質需求(QoS)的系統監控能力，通過改變系統的配置從而可以動態地改善服務品質，而不用改變整體系統架構。一個好的系統架構必須能夠監控整個系統的運行情況並具備動態系統組態管理的功能。在對複雜系統進行系統架構建模時， SOA 架構設計師應該盡量考慮利用將系統整體架構構建在已有的成熟的底層系統架構(Framework)上。對於 SOA 架構設計師來說，可以選擇的底層系統架構有很多，可以選用基於MQ, MessageBorker，WebSphere Application Server等產品來構建企業服務匯流排(Enterprise Service Bus)以支援企業的 SOA 系統架構，也可以選用較新的基於WebSphere Application Server 6中內嵌的Sibus來構建企業的ESB以支援 SOA 系統架構。具體選擇哪種底層架構來實施 SOA 系統架構要根據每個系統各自的特點來決定，但這些底層的架構都已經提供了較高的系統可管理性。因此，分析並選擇不同的產品或底層架構來實現企業系統架構也是架構設計師的主要職責之一。有關於如何利用已有底層架構來構建 SOA 系統，中國 SOA 設計中心已經發表了一系列相關的文章，大家可以在DeveloperWorks中的 SOA 專欄看到它們。

　　8) 安全性

　　安全性是指確保系統安全不會被危及的能力。目前，安全性應該說是最困難的系統品質控制點。這是因為安全性不僅要求確保系統的保密和完整性，而且還要防止影響可用性的服務拒絕(Denial-of-Service)攻擊。這就要求當 SOA 架構設計師在構建一個架構時，應該把整體系統架構儘可能地分割成各個子功能模組，在將一些子功能模組暴露為外部使用者可見的服務的時候，要圍繞各個子模組構建各自的安全區，這樣更便於保證整體系統架構的安全。如果一個子模組受到了安全攻擊，也可以保證其他模組相對安全。如果企業 SOA 架構中的一些服務是由Web Service實現的，在考慮這些服務安全性的時候也要同時考慮效率的問題，因為WS-Security會為Web Service帶來一定的執行效率損耗。

　　3.結束語

　　本系列兩部分介紹了有關架構設計師以及 SOA 架構的知識，分析了 SOA 架構師在設計 SOA 系統架構時有哪些應該特別注意的地方並在最後簡要介紹了在構建基於 SOA 架構的企業系統時應該怎樣保證所構建的系統架構能夠滿足系統中不同的服務等級需求。從架構設計師的角度， SOA 是一種新的設計模式，方法學。因此， SOA 本身涵蓋了很多的內容，也觸及到了系統整體架構設計、實現、維護等各個方面。本文的內容只是涉及到了有關於架構方面的一部分內容，希望能對廣大的 SOA 系統開發設計人員起到一定的協助作用。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1432229