【正文】 攻擊，也可以保證其他模塊相對安全。這是因為安全性不僅要求確保系統(tǒng)的保密和完整性，而且還要防止影響可用性的服務(wù)拒絕(DenialofService)攻擊。 8) 安全性 安全性是指確保系統(tǒng)安全不會被危及的能力。因此，分析并選擇不同的產(chǎn)品或底層框架來實現(xiàn)企業(yè)系統(tǒng)架構(gòu)也是架構(gòu)設(shè)計師的主要職責(zé)之一。對于 SOA 架構(gòu)設(shè)計師來說，可以選擇的底層系統(tǒng)框架有很多，可以選用基于 MQ, MessageBorker， WebSphere Application Server 等產(chǎn)品來構(gòu)建企業(yè)服務(wù)總線（ Enterprise Service Bus）以支持企業(yè)的 SOA 系統(tǒng)架構(gòu)，也可以選用較新的基于 WebSphere Application Server 6 中內(nèi)嵌的 Sibus 來構(gòu)建企業(yè)的 ESB 以支持 SOA 系統(tǒng)架構(gòu)。一個好的系統(tǒng)架構(gòu)必須能夠監(jiān)控整個系統(tǒng)的運(yùn)行情況并具備動態(tài)系統(tǒng)配置管理的功能。 7) 可管理性 可管理性是指管理系統(tǒng)以確保整個系統(tǒng)的可升級性、可靠性、可用性、性能和安全性的能力。關(guān)于系統(tǒng)文檔紀(jì)錄，除了底層子系統(tǒng)的相關(guān)文檔外，基于 SOA 的系統(tǒng)還會引用到許多系統(tǒng)外部的由第三方提供的服務(wù)，因此如果人力資源準(zhǔn)許的話，應(yīng)該增加專職的文檔管理員來專門負(fù)責(zé) 有關(guān)整個企業(yè)系統(tǒng)所涉及的所有外部服務(wù)相關(guān)文檔的收集、歸類和整理，這些相關(guān)的文檔可能涉及到第三方服務(wù)的接口（可以是 WSDL）、服務(wù)的質(zhì)量和級別、具體性能測試結(jié)果等各種相關(guān)文檔。當(dāng)創(chuàng)建和設(shè)計系統(tǒng)架構(gòu)時，要想提高系統(tǒng)的可維護(hù)性，你必須考慮下面幾個要素：低耦合、模塊性以及系統(tǒng)文檔記錄。 6) 可維護(hù)性 可維護(hù)性是指在不影響系統(tǒng)其他部分的情況下修改現(xiàn) 有系統(tǒng)功能中問題或缺陷的能力。這是因為 SOA 架構(gòu)中的不同服務(wù)之間本身就保持了一種無依賴的低耦合關(guān)系；服務(wù)本身是通過統(tǒng)一的接口定義（可以是 WSDL）語言來描述具體的服務(wù)內(nèi)容，并且很好地封裝了底層的具體實現(xiàn)。任何一個架構(gòu)設(shè)計師在構(gòu)建系統(tǒng)架構(gòu)時， 為了確保架構(gòu)設(shè)計的可擴(kuò)展性，都應(yīng)該考慮下面幾個要素：低耦合，界面 (interfaces)以及封裝。 5) 可擴(kuò)展性 可擴(kuò)展性是指在不影響現(xiàn)有系統(tǒng)功能的基礎(chǔ)上，為系統(tǒng)添加新的功能或修改現(xiàn)有功能的能力。在基于 SOA 來構(gòu)建系統(tǒng)架構(gòu)的時候，對于關(guān)鍵性的服務(wù)需要更多地考慮其可用性需求，這可以由兩個層次的技術(shù)實現(xiàn)來支持，第一種是利用不同服務(wù)的具體內(nèi)部實現(xiàn)內(nèi)部所基于的框架的容錯或 者冗余機(jī)制來實現(xiàn)對服務(wù)可用性的支持；第二種是通過 UDDI 等動態(tài)查找匹配方式來支持系統(tǒng)整體的高可用性?？煽啃钥梢栽黾酉到y(tǒng)的整體可用性，但即使系統(tǒng)部件出錯，有時卻并不一定會影響系統(tǒng)的可用性。只有確保每一個 SOA 系統(tǒng)中的服務(wù)都具有較高的可靠性，我們才能保證系 統(tǒng)整體的可靠性能夠得以保障。要在基于 SOA 架構(gòu)的系統(tǒng)中保證一定的系統(tǒng)可靠性，就必須要首先保證分布在系統(tǒng)中的不同服務(wù)的可靠性。因此，一個真正可升級的系統(tǒng)必須是可靠的系統(tǒng)?？煽啃钥赡軙谝欢ǔ潭壬舷拗葡到y(tǒng)的可升級性。 3) 可靠性 可靠性是指確保各應(yīng)用及其相關(guān)的所有交易的完整性和一致性的能力。作為一個系統(tǒng)架構(gòu)設(shè)計師所設(shè)計出來的架構(gòu)必須能夠處理對硬件的垂直或者水平升級。垂直升級包括為現(xiàn)在的機(jī)器增加處理器、內(nèi)存或硬盤。要想升級已達(dá)到最大負(fù)載能力的系統(tǒng)，你必須增加新的硬件。要想理解可升級性，我 們必須首先了解系統(tǒng)容量或系統(tǒng)的承受能力，也就是一個系統(tǒng)在保證正常運(yùn)行質(zhì)量的同時，所能夠處理的最大進(jìn)程數(shù)量或所能支持的最大用戶數(shù)量。 2) 可升級性 可升級性是指當(dāng)系統(tǒng)負(fù)荷加大時，仍能夠確保所需的服務(wù)質(zhì)量，而不需要更改整個系統(tǒng)的架構(gòu)。因此在基于 SOA 的系統(tǒng)中，推薦采用大數(shù)據(jù)量低頻率訪問模式，也就是以大數(shù)據(jù)量的方式一次性進(jìn)行信息交換。在較傳統(tǒng)的基于 EJB 或者 XMLRPC 的分布式計算模型中，它們的服務(wù)提供都是通過函數(shù)調(diào)用的方式進(jìn)行的，一個功能的完成往往需要通過客戶端和服務(wù)器來回很多次的遠(yuǎn)程函數(shù)調(diào)用才能完成。 1) 性能 我們通?？梢愿鶕?jù)每個用戶訪問的系統(tǒng)響應(yīng)時間來衡量系統(tǒng)的整體性能；另外，我們也可以通過系統(tǒng)能夠處理的交易量（每秒）來衡量系統(tǒng)的性能。一個企業(yè)級系統(tǒng)中的服務(wù)級別需求往往是十分錯綜復(fù)雜的， SOA 架構(gòu)設(shè)計師需要憑借豐富的專業(yè)經(jīng)驗和扎實的理論知識來分離和抽象系統(tǒng)中不同的服務(wù)級別需求，圖 3 展示了這種分析的過程。 架構(gòu)設(shè)計師的職責(zé)之一就是要盡可能地為提高系統(tǒng)設(shè)計人員和系統(tǒng)開發(fā)人員的工作效率考慮。例如，如果服務(wù)級別需求中最重要的是系統(tǒng)性 能，架構(gòu)設(shè)計師很有可能不得不在一定程度上犧牲系統(tǒng)的可維護(hù)性及可擴(kuò)展性，以確保滿足系統(tǒng)性能上的要求。構(gòu)建出的系統(tǒng)架構(gòu)必須要能滿足以下幾方面的服務(wù)水準(zhǔn)要求：性能、可升級性、可靠性、可用性、可擴(kuò)展性、可維護(hù)性、易管理性以及安全性。 2． SOA 架構(gòu)中的非功能性服務(wù)級別（ servicelevel）需求 除了系統(tǒng)的業(yè)務(wù)需求，架構(gòu)設(shè)計師還必須要保證構(gòu)建出來的系統(tǒng)架構(gòu)能夠滿足系統(tǒng)中的非功能性服務(wù)級別（ servicelevel）需求以及服務(wù)質(zhì)量（ QoS）方面的需求。以上這 5層都需要有一個集成的環(huán)境來支持它們的運(yùn)行，第 6 層中的企業(yè)服務(wù)總線（ ESB）提供了這個功能。在服務(wù)層之上的第 4 層就是商業(yè)流程層，在這一層中我們利用已 經(jīng)封裝好的各種服務(wù)來構(gòu)建商業(yè)系統(tǒng)中的商業(yè)流程。 (2)商業(yè)功能服務(wù)（ business function service）， 這類服務(wù)會完成一些具體的商業(yè)操作，也會被更上層的商業(yè)服務(wù)調(diào)用，不過大多數(shù)情況下這類服務(wù)不會暴露給外部用戶直接調(diào)用，比如說檢索用戶帳戶信息，存儲用戶信息等。這一類的服務(wù)是一個企業(yè)可以暴 露給外部用戶或者合作伙伴使用的服務(wù)。第 3 層就是 SOA 系統(tǒng)中最重要的服務(wù)層，在這層中我們要用底層功能組件來構(gòu)建我們所需要的不同功能的服務(wù)。 在 SOA 系統(tǒng)中不同的功能模塊可以被分為 7 層：第一層就是系統(tǒng)已經(jīng)存在的程序資源，例如 ERP或者 CRM 系統(tǒng)等。通過這些 SOA 架構(gòu)所具有的特性我們可以看到， SOA 架構(gòu)的出現(xiàn)為企業(yè)系統(tǒng)架構(gòu)提供了更加靈活的構(gòu)建方式，如果企業(yè)架構(gòu)設(shè)計師基于 SOA 來構(gòu)建系統(tǒng)架構(gòu)，就可以從底層架構(gòu)的級別來保證整個系統(tǒng)的松耦合性以及靈活性，這都為未來企業(yè)業(yè)務(wù)邏輯的擴(kuò)展打好了基礎(chǔ)。 SOA 架構(gòu)具有一些典型特性，主要包括松耦合性，位置透明性以及協(xié)議無關(guān)性。 SOA 最主要的應(yīng)用場合在于解決在 Inter 環(huán)境下的不同商業(yè)應(yīng)用之間的業(yè)務(wù)集成問題。本文將延續(xù)第一部分的內(nèi)容，向您介紹了 SOA 為企業(yè)級架構(gòu)設(shè)計帶來的影響，以及在構(gòu)建基于 SOA 架構(gòu)的企業(yè)系統(tǒng)時應(yīng)該怎樣保證所構(gòu)建的系統(tǒng)架構(gòu)能夠滿足系統(tǒng)中不同的服務(wù)級別需求。 關(guān)于作者 王 強(qiáng) ,IBM 軟件工程師，工作在 IBM 中國軟件開發(fā)實驗室 SOA Design Center，從事 Incubator及 SOA， Grid 項目的工作，對 J2EE 架構(gòu)、 SOA 架構(gòu)、 MDA/MDD 以及網(wǎng)格計算等技術(shù)有較深入的研究。 5. 面向服務(wù)的分析與設(shè)計原理 一文研究了 OOAD、 EA 和 BPM 中的適當(dāng)原理。 2. DeveloperWorks 的 SOA 和 Web 服務(wù)專區(qū) 有大量專題文章以及關(guān)于開發(fā) Web 服務(wù)應(yīng)用程序的入門級、中級和高級教程。本文的內(nèi)容只是涉及到了有關(guān)于架構(gòu)方面的一部分內(nèi)容，希望能對廣大的 SOA 系統(tǒng)開發(fā)設(shè)計人員起到一定的幫助作用。從架構(gòu)設(shè)計師的 角度， SOA 是一種新的設(shè)計模式，方法學(xué)。 4. 結(jié)束語 本文簡要介紹了有關(guān)架構(gòu)設(shè)計師以及 SOA 架構(gòu)的知識，分析了 SOA 架構(gòu)師在設(shè)計 SOA 系統(tǒng)架構(gòu)時有哪些應(yīng)該特別注意的地方。 性能問題對于 Web 服務(wù)來說一直都是一個問題，由于幾乎所有 EJB 容器都提供了對無狀態(tài)會話 Bean 群集的支持以及對無狀態(tài) Session Bean 池與資源管理的支持，因此當(dāng)負(fù)載增加時，可以向群集中增加機(jī)器， Web 服務(wù)請求可以定向到這些不同的服務(wù)器，同時由于無狀態(tài) Session Bean 池改進(jìn)了資源利用和內(nèi)存管理，使 Web 服務(wù)能夠有效地響應(yīng)多個客戶請求。另外 EJB 容器會自動提供對并發(fā)的支持，作為無狀態(tài) Session Bean實現(xiàn)的 EJB 服務(wù)端點不必?fù)?dān)心多線程訪問，因為 EJB 容器必須串行化對無狀態(tài)會話 bean 任何特定實例的請求。在許多企業(yè)中，現(xiàn)有的業(yè)務(wù)邏輯可能已經(jīng)使用 EJB 組件編寫，通過 Web 服務(wù)公開它可能是實現(xiàn)從外界訪問這些服務(wù)的最佳選擇。客戶可以訪問用 JAXRPC API 創(chuàng)建的 Web 服務(wù)（使用 Servlet 來實現(xiàn)）；Web 服務(wù)客戶也可以通過 EJB 的服務(wù)端點接口訪問無狀態(tài)的 Session Bean，但 Web 服務(wù)客戶不能訪問其他類型的企業(yè) Bean，如有狀態(tài)的 Session Bean，實體 Bean 和消息驅(qū)動 Bean。我們通常會利用無狀態(tài)的 Session Bean 來實現(xiàn)具體的服務(wù)，如果基于 Web Service 技術(shù)，我們就可以將無狀態(tài)的Session Bean 暴露為外部用戶可以調(diào)用的到的 Web 服務(wù)，也就是把傳統(tǒng)的 Session Facade 模型轉(zhuǎn)化為了 EJB 的 Web 服務(wù)端點，這樣，我們就可以向 Web 服務(wù)客戶提供粗粒度的服務(wù)。當(dāng)某一個服務(wù)需要依賴時，我們最好把它定義成具體的業(yè)務(wù)流程（ BPEL）。通常架構(gòu)設(shè)計師可以使用 BPEL 來創(chuàng)建由細(xì)粒度操作組成的業(yè)務(wù)流程的粗粒度的服務(wù)接口。而粗粒度服務(wù)接口保證了服務(wù)請求者將以一致的方式使用系統(tǒng)中所暴露出的服務(wù)。雖然細(xì)粒度的接口能為服務(wù)請求者提供了更加細(xì)化和更多的靈活性，但同時也意味著引入較難控制的交互模式易變性 ,也就是說服務(wù)的交互模式可能隨著不同的服務(wù)請求者而不同。從技術(shù)上講，粗粒度的服務(wù)接口可能是一個特定服務(wù)的完整執(zhí)行，而細(xì)粒度的服務(wù)接口可能是實現(xiàn)這個粗粒度服務(wù)接口的具體的內(nèi)部操作。 服務(wù)粒度的控制 SOA 系統(tǒng)中的服務(wù)粒度的控制是一項十分重要的設(shè)計任務(wù)。因此，如果SOA 架構(gòu)師希望所構(gòu)建的系統(tǒng)架構(gòu)能夠隨著企業(yè)的成長和變化成功地繼續(xù)得以保持，則整個系統(tǒng)構(gòu)架中的集成功能就應(yīng)該由服務(wù)提供，而不是由特定的應(yīng)用程序來完成。因而， SOA 架構(gòu)師在著手設(shè)計新的體系結(jié)構(gòu)框架時，必須要全面的考慮所有可能的集成需求。當(dāng) SO