第12章面向服務應用的體系結構12.1引言

12.2應用的體系結構

12.3面向服務應用的體系結構的例子

12.4討論本章主要敘述SOAA(面向服務應用的體系結構)。SOAA類似于傳統的軟件體系結構,但由于它是面向服務的,所以具有自身的特性。特別地,SOAA可以是動態的,也就是說,在運行時使用已存在的服務可以組合和再組合應用。本章首先介紹SOAA的基本構成,并給出幾種大家熟知的基于SOA的應用的體系結構。

和傳統軟件相比較,SOA軟件具有以下特征：

①基于標準的互操作性；

②通過發現服務進行靜態和動態組合；

③動態管理和編排。12.1引言對運行的服務必須進行控制并提供一些可用機制。一個是基于策略計算的策略管理服務,更具體地說,在開發期和運行期可以指定、檢查和執行策略。另一個是編排,一個中心控制器協調過程的執行并負責服務的運行調度,服務是分布式的,跨越互連的網略,例如ESB(企業服務總線)。

正如第1章所說,有一些SOA的變種。例如,SOA允許工作流、數據、協作模板、用戶接口、測試腳本等的發布和發現,如圖12.1和圖12.2所示。

圖12.1SOAA關注SOA的應用部分圖12.2使用體系結構模版的基于本體的動態組合SOA有以下變種：

(1)發布工作流和協作模板：典型的例子是CCSOA(以客戶為中心的SOA),它的體系結構如圖12.3。除了在SOA中發布服務規范,CCSOA還發布工作流和應用協作規范,并且可以發現、匹配和訂閱。

(2)發布數據：典型的例子是DCSOA(以數據為中心的SOA),它的體系結構如圖12.4所示。在DCSOA中,允許數據提供者在數據中介發布他們的數據。用RESTful服務可以很好地實現DCSOA。圖12.3CCSOA的體系結構

圖12.4DCSOA的體系結構

程序或計算系統的體系結構就是系統的結構。通常,它包含組件及組件間的關系。最通用的體系結構是層次體系結構,這種結構是處于外層的進程和服務調用內層的進程和服務。其他常用的體系結構包括以數據為中心的體系結構,虛擬機體系結構以及調用返回體系結構。12.2應用的體系結構

SOA應用有自己的體系結構和體系結構風格。IBM為WebSphere應用提出了一個五層體系結構模板,如圖12.5所示：表示層、業務流程共同設計層、服務層、企業構件層和運行系統層。這個體系結構也包括兩個支持機制,集成化體系結構以及服務質量、安全、管理和監控。這兩個機制應用到每一層。這種體系結構風格實際上類似于傳統的企業體系結構,它們經常是層次化的體系結構。

圖12.5IBMWebsphere的層次化的SOAA

其他大家熟知的體系結構包括微軟的WF項目、SAP的NetWeaver和不同企業的SOA應用,如企業SOA和面向服務的企業。表12.1概括了這些工作。表12.1SOAA的例子在傳統的軟件設計中,軟件部署后體系結構就不能改變。在SOA中,基本的構建塊是服務。服務被連接到類似總線的通信中樞,例如ESB。服務間的通信通過控制中心控制,它也被連接到通信中樞,如圖12.6所示。這種體系結構用于描述IBMWebSphere的體系結構以及其他SOAA樣式。

圖12.6通用的面向服務應用的體系結構控制中心通常有一個組合管理員,它通過工作流規范指定和控制應用配置。應用配置/工作流規范定義了服務如何被連接在一起去實現指定的應用以及消息在服務間如何傳輸。對于這種體系結構,用戶可以用不同的體系結構甚至不同的體系結構風格組合應用。

這種新方法允許新的服務加入到系統中,此外,通過簡單地改變工作流規范而不改變基本的SOA框架,就可以用已存在的服務組合新的應用。

由于SOA的動態性,基于SOA應用的體系結構具有不同于傳統軟件體系結構的以下特征：動態體系結構、動態再組合、嵌入在運行的基礎設施體系結構中的生命周期管理。12.2.1動態體系結構和動態組合

傳統的軟件體系結構是固定的。換句話說,一旦通過組件和組件間的連接,部署了體系結構,就不能改變。圖12.7通過一個簡單的例子說明了這一點。

圖12.7傳統體系結構的例子在這個例子中,使用了四個組件,其中構件1可以和構件2,3,4通信。同樣,構件2可以和構件1,構件4通信。體系結構的拓撲結構在設計的時候就確定了,應用部署后,體系結構很難改變。例如,應用部署后,如果用戶發現星型結構能更好地滿足用戶的需求,為了交付新的應用,應用構件者就需要返回到設計階段,重新設計、實現、部署。

如圖12.6所示,在SOA中,控制中心通常有一個組合管理員,它通過工作流規范指定和控制應用配置。應用配置/工作流規范定義了服務如何連接在一起構成用戶希望的應用以及消息如何在服務間傳輸。使用這種體系結構,用戶可以用不同的體系結構甚至不同的體系結構風格組合應用。對于有四個服務的簡單系統,可組合成的體系結構如圖12.8所示。

這種方法允許在不改變應用的前提下為應用添加新的服務。此外,通過簡單地改變工作流規范而不改變基本的SOA框架,可用已有的服務組合新的應用。

圖12.8不同應用體系結構配置12.2.2動態再組合

SOAA的另一個獨一無二的特征是它能夠動態再組合一個應用。不同于動態組合,動態再組合指的是運行時SOA應用能改變他自己的體系結構,包括替換服務或者改變互聯服務的體系結構的拓撲結構。動態組合指的是SOA應用使用一組相同的服務組合成具有不同拓撲結構的應用的體系結構。動態組合發生在系統建模和組裝階段,而動態再組合發生在目標應用部署后。動態組合與動態再組合的不同之處在于動態再組合的建模和組裝實際上是當已有的應用正在運行時進行重新建模和重新組裝。傳統的容錯計算在應用中使用冗余模塊,實際上就是用復制模塊代替已失敗的模塊。它類似于動態再組合。然而,傳統的容錯機制在一個固定的體系結構中。換句話說,如果系統體系結構不是很好時,它可以替換一個失效的模塊,但不能動態改變應用的體系結構以消除可靠性問題的根源。然而,通過SOA應用的動態再組合,兩者都成為可能。為了進行改變,僅僅只需改變應用配置或工作流規范,則目標應用立即被組裝、部署和管理。

雖然動態組合是SOA的一個關鍵特征,但因為動態再組合在運行時對已存在的應用快速更改,并且對再配置管理的影響很小,所以給SOA帶來了更高的靈活性。12.2.3嵌入在運行基礎設施中的生命周期管理

SOAA還有一個特征是為了促進動態軟件組合,而嵌入在運行基礎設施中的生命周期管理。在這種方式下,SOA應用的開發基礎設施和運行基礎設施被集成為一個統一的SOA基礎設施。

(1)開發基礎設施一般包括建模、分析、設計、體系結構、代碼生成、驗證和確認,例如測試和模型檢查。

(2)運行基礎設施一般包括代碼部署、代碼執行、策略實施、監控、通信和系統重新配置。

SOA環境將包含上面兩個基礎設施的特征。IBMSOA基礎體系結構由以下幾個階段組成：建模、組裝、部署和管理。此外,為了引導和監督目標SOA應用,將執行運行監控活動。四個階段的活動按照循環方式執行。

(1)建模：收集需求并建立應用模型,用一組服務表示系統。

(2)組裝：根據建立的模型,設計者或者創建需要的服務或者從服務中介查找現有的服務以開發應用。

(3)部署：配置運行環境滿足應用的需求,同時部署應用到環境中并運行。

(4)管理：應用部署后,提供應用使用的服務并進行監控,收集必要的信息,以幫助預防、隔離、診斷、修復運行時可能發生的任何問題。

(5)監管和過程：整個過程需要使用國際標準,組織中的任何人都要遵守過程。

IBMSOA的基礎生命周期把開發活動(建模和組裝)和運行活動(部署和管理)集成為一個單一的過程,如圖12.9所示。

圖12.9IBMSOA基礎生命周期基礎生命周期也是一個模型驅動的應用開發過程。這個具有監管和過程的環形過程和目標SOA應用一起交付給用戶。當需要改變應用體系結構時,用戶只需重新制定系統模型,應用將被重新組裝,重新部署和重新監控。

微軟在它的WF項目中也采用了這種方法,WF也具有建模、體系結構、代碼生成、代碼部署和代碼執行的能力。在WF中,SOA設計者從服務池中選擇服務并指定體系結構說明服務間如何通信。體系結構框圖完成后,不需要知道模塊服務的細節,設計者就可以執行它,查看應用是否按照預想進行工作。稍后,通過改變模型或者體系結構,就可以容易地改變應用。另一個采用這種方法的應用是PESOI(處理嵌入式的面向服務的基礎設施),它把開發和運行基礎設施集成到被開發的應用中。這種方法有廣泛的SOSE支持。在開發和運行時,有自動化工具支持SOSE活動,這些工具快速檢查正確性和應用中的服務的質量。當開發應用時,相關的SOA應用開發基礎設施被嵌入到目標應用并交付給用戶。一個可能的PESOI體系結構如圖12.10所示。

圖12.10PESOI參考體系結構圖12.11說明了用PESOI參考體系結構開發的應用體系結構模板。用來組合預想應用的服務被連接到通信中樞以及中心控制器的服務上。為服務建模能幫助用戶建立目標應用的體系結構模型、過程模型和策略模型。通過V&V服務,驗證和確認這些模型。動態組合管理器根據模型從服務庫中挑選合適的服務組合預想應用。

圖12.11PESOI應用體系結構系統組裝和部署完成后,數據收集服務將一直監控應用服務。分析服務分析收集到的運行數據。如果故障處理條件被觸發,就調用動態工作流規范服務修改系統組合規范以適應改變了的環境。如果在運行時無法解決問題,通過模型化服務檢查或更改系統模型的方式讓用戶參與進來。

本節給出幾個大的計算機企業或社區提出的或實施的面向服務應用的體系結構的例子。12.3面向服務應用的體系結構的例子12.3.1IBMWebSphere的體系結構

WebSphere集成化參考體系結構旨在提供一組服務幫助在企業環境里進行業務集成。關鍵的集成功能如圖12.12所示。

圖12.12WebSphere參考體系結構此體系結構的核心在于連接服務,它提供了支持和實例化ESB的基礎設施。連接服務提供了三個主要的服務：傳輸服務、事件服務和仲裁服務。

(1)傳輸服務為消息傳遞提供了位于有線和無線網絡之上的連接層,確保消息傳遞獨立于通信協議。

(2)事件服務為企業系統提供了事件驅動的能力,因此系統能夠對作為業務過程一部分的事件做出響應。

(3)仲裁服務協調服務間的通信,進行消息傳輸、消息路由和服務綁定。

連接到連接服務上的兩類服務如圖12.13所示。

圖12.13ESB體系結構

(1)業務邏輯服務：伙伴服務、業務應用服務、應用和信息資源。

(2)控制服務：交互服務、過程服務和信息服務。

在三種類型的業務邏輯服務中,伙伴服務支持外部環境,例如外部伙伴、銷售商和供應商,到傳統系統的集成,它也進行不同協議和技術間的數據轉換。業務應用服務支持把J2EE運行環境集成到業務組件中。應用和信息資源支持與第三方應用,例如ERP、CRM、異質數據源例如XML和RDBMS的交互。控制服務把人員、業務過程和信息集成在一起。為了開發和運行業務流程,控制服務恰當的控制企業的業務數據和交互流。交互服務以恰當的格式向用戶交付需要的數據和功能。過程服務管理流和服務的交互。應用和信息服務提供了聯合、復制、查詢、分析和轉換數據源的功能。

圖的左邊是開發服務,它提供了一個支持全部軟件生命周期的開發平臺,這個生命周期包括需求分析、建模、模塊開發、測試以及代碼維護。

業務創新和優化服務提供了業務流程持續改進的基礎設施。

IT服務管理提供了安全、目錄、系統管理和資源虛擬化。例如,安全和目錄服務包括跨越企業的身份鑒定和授權。

最后,基礎設施服務封裝了計算平臺和資源相關性。通過這些服務,用戶不必優化服務質量,例如吞吐率、可用性和性能等。

應用服務在WEbSphere參考體系結構的右邊,它們可以利用參考體系結構提供的服務。12.3.2企業服務總線

在SOA環境中,ESB(企業服務總線)定義了一組支持模塊(服務)集成和通信的標準。本質上,ESB提供了支持不同SOAA的能力,它是SOA應用集成的基本模塊。

圖12.13是一個典型的例子——Sonic軟件的SonicESB實現。ESB在建立企業SOA應用中非常流行,它為應用和服務提供了通信中樞和工作流控制。事實上,通過業務容器和適配器,各種應用和服務都可插入ESB。

服務托管在服務容器中,一個服務容器托管一組服務并把它們與外部資源綁定。

ESB中的服務不局限于Web服務,還包括建立在J2EE、.Net及遺產組件上的服務,這些服務直接部署在ESB中。

通信中樞提供了安全可靠的通信。通過通信中樞,可以訪問其他網絡上的服務,這些服務提供了統一的名字空間和聯合的安全環境。

為了實現上面的目標,ESB需要具備以下特征：

(1)統一路由、消息和獨立于協議和平臺的數據交換機制；

(2)企業服務的管理和監控能力,通過這種能力允許組織管理和監控服務；

(3)處理業務服務和工作流；

(4)圖形化的快速的SOAA開發和集成能力,即通過易用的圖形化環境創建、編輯和服務集成,開發SOA企業應用。

(5)快速自動的應用生成和數據集成技術,一旦指定了模型和計算邏輯信息,SOA應用將被集成并被部署到相關領域。12.3.3SAP的NetWeaver

SAPNetWeaver提供了和傳統應用的集成,例如SAPR/3、mySAP和微軟的.Net平臺和IBM的WebSphere平臺上的SOA應用的集成。

NetWeaver提出了“ESA(企業服務體系結構)”概念,它為過程模型和服務應用提供了體系結構框架。基本上,NetWeaver/ESA可以被視為：

(1)當前應用或新的SAP應用的運行和集成平臺；

(2)互操作和集成平臺,關注和IBM的WebSphere以及微軟的.Net技術的互操作性。

NetWeaver的體系結構如圖12.14。圖12.14SAPNetWeaverNetWeaver通過W3C、WSI(Web服務互操作)組織、JCP(Java社區過程)和OASIS建立的標準,提供了與其他應用的互操作和集成。

交換基礎設施是NetWeaver的互操作性特征和業務流程管理的核心。交換基礎設施提供了許多用于互操作性的適配器,包括和WebSphere業務集成互操作的JMS適配器(MQSeries)和微軟的消息隊列(MSMQ)以及BizTalk互操作的伙伴適配器。如圖12.15所示,交換基礎設施由集成目錄和集成倉庫組成。集成服務管理由不同服務組成的應用組件間的基于XML/SOAP的通信。集成目錄包含了運行時所需的信息,例如集成腳本和業務過程。

SAPNetweaver的一個關鍵模塊是業務流程管理(BMP),它由以下組件組成：

(1)集成構造器;

(2)集成倉庫;

(3)集成目錄;

(4)業務過程引擎。

集成構造器是SAP的過程建模工具,它支持BPEL,允許導入和導出過程定義,能夠集成業務場景和業務過程。就如前面所說,場景和過程存儲在集成倉庫中。業務過程引擎是集成服務的一部分,它根據集成目錄中定義的流控制過程步驟。圖12.15NetWeaver交換基礎設施——業務過程管理(BPM)12.3.4用戶為中心的面向服務的體系結構

UCSOA(用戶為中心的SOA)［chang2006］由Intel和亞利桑那州立大學聯合開發,它是一個支持在CCSOA(客戶為中心的SOA)之上的客戶的新框架,UCSOA對SOA規范做了改進,提出了新的服務規范階段,也就是,用戶為中心的規范。以前,應用構建者是具備編程知識和技能的工程師。另一方面,用戶可能不具備編程技能,但他們知道軟件應具有的功能以及應如何使用軟件。在用戶為中心的規范方法中,需要一些技術支持不具有編程知識的最終用戶說明他們想要的應用和服務。UCSOA的頂層架構是一個四層的體系結構,如圖12.16所示。

(1)傳統的SOA層：這一層提供了傳統的SOA服務,如發布、發現、服務中介。

(2)CCSOA層：CCSOA不僅發布服務規范,而且發布應用模板和協作模式。在CCSOA中,為用戶和服務提供者提供了各種解決方案。

(3)COI(興趣社區)層：在這一層,分類存儲和特定領域相關的通用解決方案。

(4)客戶相關層：每一個客戶有其特定的喜好和行為,因此會產生不同的應用。

圖12.16UCSOA體系結構

本章首先介紹了SOAA存在的問題,接著回顧了幾個已存在的SOAA。一個爭論點是大多數的SOAA類似于傳統的軟件體系結構,如層次化體系結構,但實際上SOAA有自己獨一無二的特性。SOAA經常使用ESB,應用體系結構在模型中說明,在控制器中控制。這樣,在需要的時候SOAA可被改變和更新。SOAA