![]() | ![]() |
![]() |
級別: 初級 Min Luo, Mark Endrei, Philippe Comte,Pal Krogdahl, Jenny Ang, Tony Newling, International Technical Support Organization, Raleigh Center 2004 年 6 月 01 日 在這一節中,我們簡(jiǎn)要地描述了面向服務(wù)的體系結構的發(fā)展。然后,我們探究了面向組件的開(kāi)發(fā)與面向服務(wù)的體系結構之間的關(guān)系,并且說(shuō)明了如何將組件作為實(shí)現服務(wù)的基礎設施。 雖然 IT 經(jīng)理一直面臨著(zhù)削減成本和最大限度地利用現有技術(shù)的難題,但是與此同時(shí),他們還必須不斷地努力,以期更好地服務(wù)客戶(hù),更快地響應企業(yè)戰略重點(diǎn),從而贏(yíng)得更大的競爭力。 在所有這些壓力之下,有兩個(gè)基本的主題:異構和改變?,F在,大多數企業(yè)都有各種各樣的系統、應用程序以及不同時(shí)期和技術(shù)的體系結構。集成來(lái)自多個(gè)廠(chǎng)商跨不同平臺的產(chǎn)品簡(jiǎn)直就像一場(chǎng)噩夢(mèng)。但是我們也不能單單使用一家廠(chǎng)商的產(chǎn)品,因為改變應用程序套件和支持基礎設施是如此之難。 在當今 IT 經(jīng)理面臨的問(wèn)題之中,改變是第二個(gè)主題。全球化和電子商務(wù)加快了改變的步伐。全球化帶來(lái)了激烈的競爭,產(chǎn)品周期縮短了,每個(gè)公司都想贏(yíng)得超過(guò)競爭對手的優(yōu)勢。在競爭產(chǎn)品和可以從 Internet 上獲得的大量產(chǎn)品信息的推動(dòng)下,客戶(hù)要求更快速地進(jìn)行改變。因而,在改進(jìn)產(chǎn)品和服務(wù)方面展開(kāi)的競爭進(jìn)一步加劇了。 為了滿(mǎn)足客戶(hù)提出的越來(lái)越多的新要求,技術(shù)方面的改進(jìn)也在不斷地加快。企業(yè)必須快速地適應這種改變,否則就難以生存,更別提在這個(gè)動(dòng)蕩不安競爭激烈的環(huán)境中取得成功了,而 IT 基礎設施必須支持企業(yè)提高適應能力。 因此,企業(yè)組織正在從上世紀八十年代或更早的時(shí)期的相互隔離的垂直業(yè)務(wù)部門(mén),到上世紀八十年代和九十年代關(guān)注業(yè)務(wù)流程的水平結構,向新的生態(tài)系統業(yè)務(wù)范例發(fā)展。重點(diǎn)是擴展供應鏈,支持客戶(hù)和合作伙伴訪(fǎng)問(wèn)業(yè)務(wù)服務(wù)。第 19 頁(yè)的圖 2-1 展示了企業(yè)的這種發(fā)展。 圖 2-1 企業(yè)的發(fā)展 ![]() 我如何使我的 IT 環(huán)境更靈活且更快地響應不斷改變的業(yè)務(wù)需求呢? 我們如何使這些異構系統和應用程序盡可能無(wú)縫地進(jìn)行通信呢?我們如何達到企業(yè)目標而不使企業(yè)走向破產(chǎn)的深淵呢? IT 響應者/支持者是隨著(zhù)企業(yè)的這種發(fā)展而并行發(fā)展的,如圖 2-2 所示?,F在,許多 IT 經(jīng)理和專(zhuān)業(yè)人員都同樣相信,我們真的快找到了一種滿(mǎn)意的答案——面向服務(wù)的體系結構。 圖 2-2 體系結構的發(fā)展 圖 2-2 體系結構的發(fā)展 ![]() 為了減少異構性、互操作性和不斷改變的要求的問(wèn)題,這樣的體系結構應該提供平臺來(lái)構建具有下列特征的應用程序服務(wù):
基于這樣的面向服務(wù)的體系結構,服務(wù)使用者甚至不必關(guān)心與之通信的特定服務(wù),因為底層基礎設施或服務(wù)“總線(xiàn)”將代表使用者做出適當的選擇?;A設施對請求者隱藏了盡可能多的技術(shù)。特別地,來(lái)自不同實(shí)現技術(shù)(如 J2EE 或 .NET)的技術(shù)規范不應該影響 SOA 用戶(hù)。如果已經(jīng)存在一個(gè)服務(wù)實(shí)現,我們就還應該重新考慮用一個(gè)“更好”的服務(wù)實(shí)現來(lái)代替,新的服務(wù)實(shí)現必須具有更好的服務(wù)質(zhì)量。
自從“軟件危機”促進(jìn)軟件工程的開(kāi)創(chuàng )以來(lái),IT 界一直在努力尋求解決上述問(wèn)題的方案。在過(guò)去幾年里,下面簡(jiǎn)要概述的核心技術(shù)進(jìn)展使我們走到了今天。我們將簡(jiǎn)要討論這些核心技術(shù),而我們重點(diǎn)關(guān)注的將是這些技術(shù)如何幫助解決 IT 問(wèn)題。 在“Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design”中,Larman 將面向對象的分析和設計的本質(zhì)描述為“從對象(物體、概念或實(shí)體)的角度考慮問(wèn)題域和邏輯解決方案”。在“Object-Oriented SoftwareEngineering: A Use Case Driven Approach”中,Jacobson 等將這些對象定義為“特點(diǎn)在于具有許多操作和狀態(tài)(記憶這些操作的影響)的物體”。 在面向對象的分析中,這樣的對象是用問(wèn)題域來(lái)標識和描述的,而在面向對象的設計中,它們轉變成邏輯軟件對象,這些對象最終將用面向對象的編程語(yǔ)言進(jìn)行實(shí)現。 通過(guò)面向對象的分析和設計,可以封裝對象(或對象組)的某些方面,以簡(jiǎn)化復雜業(yè)務(wù)場(chǎng)景的分析。為了降低復雜性,也可以抽象對象的某些特征,這樣就可以只捕獲重要或本質(zhì)的方面。 基于組件的設計并不是一種新技術(shù)。它是從對象范例中自然發(fā)展而來(lái)的。在面向對象的分析和設計的早期,細粒度的對象被標榜為提供“重用”的機制,但是這樣的對象的粒度級別太低了,沒(méi)有適當的標準可以用來(lái)使重用廣泛應用于實(shí)踐之中。在應用程序開(kāi)發(fā)和系統集成中,粗粒度組件越來(lái)越成為重用的目標。這些粗粒度對象通過(guò)內聚一些更細粒度的對象來(lái)提供定義良好的功能。通過(guò)這種方式,還可以將打包的解決方案套件封裝成這樣的“組件”。 一旦組織在更高層次上實(shí)現了基于完全獨立的功能組件的完備體系結構,就可以將支持企業(yè)的應用程序劃分成一組粒度越來(lái)越大的組件??梢詫⒔M件看作是打包、管理和公開(kāi)服務(wù)的機制。它們可以共同使用一組技術(shù):實(shí)現企業(yè)級用況的大粒度企業(yè)組件可以通過(guò)更新的面向對象的軟件開(kāi)發(fā)與遺留系統相結合來(lái)實(shí)現 在“Component-Based Development for Enterprise Systems”中,Allen 涉及了服務(wù)的概念,“它是將組件描述成提供相關(guān)服務(wù)的物理黑盒封裝的可執行代碼單元。它的服務(wù)只能通過(guò)一致的已發(fā)布接口(它包括交互標準)進(jìn)行訪(fǎng)問(wèn)。組件必須能夠連接到其他組件(通過(guò)通信接口)以構成一個(gè)更大的組”。服務(wù)通常實(shí)現為粗粒度的可發(fā)現軟件實(shí)體,它作為單個(gè)實(shí)例存在,并且通過(guò)松散耦合的基于消息通信模型來(lái)與應用程序和其他服務(wù)交互。第 22 頁(yè)的圖 2-3 展示了重要的面向服務(wù)術(shù)語(yǔ):
圖 2-3 面向服務(wù)的術(shù)語(yǔ) ![]() 在組件和服務(wù)開(kāi)發(fā)中,都需要進(jìn)行接口設計,這樣軟件實(shí)體就可以實(shí)現和公開(kāi)其定義的關(guān)鍵部分。因此,在基于組件和面向服務(wù)的系統中,“接口”的概念對于成功的設計非常關(guān)鍵。下面是一些與接口有關(guān)的重要定義:
第 23 頁(yè)的圖 2-4 定義了客戶(hù)關(guān)系管理 (CRM) 服務(wù)的 UML 定義,它表示為一個(gè) UML 組件,實(shí)現接口 AccountManagement、ContactManagement 和 SystemsManagement。在這些接口中只有頭兩個(gè)接口是已發(fā)布接口,不過(guò),后者是公共接口。注意,SystemsManagement 接口和 ManagementService 接口構成了雙接口。CRMservice 可以實(shí)現許多這樣的接口,但是它以多種方式行為的能力取決于客戶(hù)端在行為的實(shí)現方面是否允許有大的靈活性。甚至有可能給特定類(lèi)型的客戶(hù)端提供不同或附加的服務(wù)。在一些運行時(shí)環(huán)境中,這樣的功能也用于在單個(gè)組件或服務(wù)上支持相同接口的不同版本。 圖 2-4 已實(shí)現的服務(wù) ![]() 如前所述,面向對象的技術(shù)和語(yǔ)言是實(shí)現組件的極好方式。雖然組件是實(shí)現服務(wù)的最好方法,但是您必須理解的一點(diǎn)是,好的基于組件的應用程序未必就構成好的面向服務(wù)的應用程序。一旦理解了服務(wù)在應用程序體系結構中所起的作用,組件開(kāi)發(fā)人員就很有可能會(huì )利用現有的組件。進(jìn)行這種轉變的關(guān)鍵是認識到面向服務(wù)的方法意味著(zhù)附加的應用程序體系結構層。第 24 頁(yè)中的圖 2-5 演示了如何將技術(shù)層應用于程序體系結構以提供粒度更粗的實(shí)現(它更靠近應用程序的使用者)。為稱(chēng)呼系統的這一部分而創(chuàng )造的術(shù)語(yǔ)是“應用程序邊界”,它反映了服務(wù)是公開(kāi)系統的外部視圖的極好方法的事實(shí)(通過(guò)內部重用并結合使用傳統組件設計)。 圖 2-5 應用程序實(shí)現層:服務(wù)、組件、對象 ![]()
面向服務(wù)的體系結構提供了一種方法,通過(guò)這種方法,可以構建分布式系統來(lái)將應用程序功能作為服務(wù)提供給終端用戶(hù)應用程序或其他服務(wù)。其組成元素可以分成功能元素和服務(wù)質(zhì)量元素。第 25 頁(yè)的圖 2-6 展示了體系結構堆棧以及在一個(gè)面向服務(wù)的體系結構可能觀(guān)察到的元素。 注意:面向服務(wù)的體系結構堆??赡苁且粋€(gè)容易引起爭議的問(wèn)題,因為各方面的支持者已經(jīng)提出了幾種不同的堆棧。我們的堆棧不是作為服務(wù)堆棧提出的。我們之所以在此提出它,是因為我們想要搭建一個(gè)有用的框架,在本書(shū)的剩余章節中,我們將通過(guò)這個(gè)框架來(lái)組織對 SOA 的討論。 圖 2-6 面向服務(wù)的體系結構的元素 ![]() 體系結構堆棧分成兩半,左邊的一半集中于體系結構的功能性方面,而右邊的一半集中于體系結構的服務(wù)質(zhì)量方面。這些元素詳細描述如下: 功能性方面包括:
服務(wù)質(zhì)量方面包括:
圖 2-7 展示了面向服務(wù)的體系結構中的協(xié)作。這些協(xié)作遵循“查找、綁定和調用”范例,其中,服務(wù)使用者執行動(dòng)態(tài)服務(wù)定位,方法是查詢(xún)服務(wù)注冊中心來(lái)查找與其標準匹配的服務(wù)。如果服務(wù)存在,注冊中心就給使用者提供接口契約和服務(wù)的端點(diǎn)地址。下圖展示了面向服務(wù)的體系結構中協(xié)作支持“查找、綁定和調用”范例的實(shí)體。 圖 2-7 面向服務(wù)的體系結構中的協(xié)作 ![]() 面向服務(wù)的體系結構中的角色包括:
面向服務(wù)的體系結構中的每個(gè)實(shí)體都扮演著(zhù)服務(wù)提供者、使用者和注冊中心這三種角色中的某一種(或多種)。面向服務(wù)的體系結構中的操作包括:
面向服務(wù)的體系結構中的構件包括:
除了動(dòng)態(tài)服務(wù)發(fā)現和服務(wù)接口契約的定義之外,面向服務(wù)的體系結構還具有以下特征:
這些特征也是滿(mǎn)足電子商務(wù)按需操作環(huán)境的要求的主要特征,如第 301 頁(yè)“e-business on demand and Service-oriented architecture”所定義的。 最后,我們需要說(shuō)明的是,面向服務(wù)的體系結構并不是一個(gè)新的概念。如圖 2-8 所示,面向服務(wù)的體系結構所涉及的技術(shù)至少包括 CORBA、DCOM 和 J2EE。面向服務(wù)的體系結構的早期采用者還曾成功地基于消息傳遞系統(如 IBM WebSphere MQ)創(chuàng )建過(guò)他們自己的面向服務(wù)企業(yè)體系結構。最近,SOA 的活動(dòng)舞臺已經(jīng)擴展到包括 World Wide Web (WWW) 和 Web 服務(wù)。 圖 2-8 面向服務(wù)的體系結構的不同實(shí)現 ![]() 在面向服務(wù)的體系結構中,映射到業(yè)務(wù)功能的服務(wù)是在業(yè)務(wù)流程分析的過(guò)程中確定的。服務(wù)可以是細粒度的,也可以是粗粒度的,這取決于業(yè)務(wù)流程。每個(gè)服務(wù)都有定義良好的接口,通過(guò)該接口就可以發(fā)現、發(fā)布和調用服務(wù)。 企業(yè)可以選擇將自己的服務(wù)向外發(fā)布到業(yè)務(wù)合作伙伴,也可以選擇在組織內部發(fā)布服務(wù)。服務(wù)還可以由其他服務(wù)組合而成。 服務(wù)是粗粒度的處理單元,它使用和產(chǎn)生由值傳送的對象集。它與編程語(yǔ)言術(shù)語(yǔ)中的對象不同。相反,它可能更接近于業(yè)務(wù)事務(wù)(如 CICS 或 IMS 事務(wù))的概念而不是遠程 CORBA 對象的概念。 服務(wù)是由一些組件組成的,這些組件一起工作,共同提供服務(wù)所請求的業(yè)務(wù)功能。因此,相比之下,組件比服務(wù)的粒度更細。另外,雖然服務(wù)映射到業(yè)務(wù)功能,但是組件通常映射到業(yè)務(wù)實(shí)體和操作它們的業(yè)務(wù)規則。作為一個(gè)示例,讓我們看一看 WS-I 供應鏈管理(WS-I Supply Chain Management)樣本的定購單(PurchaseOrder)組件模型,如圖 2-9 所示。 圖 2-9 定購單組件模型 ![]() 在基于組件的設計中,可以創(chuàng )建組件來(lái)嚴格匹配業(yè)務(wù)實(shí)體(如顧客(Customer)、定購單(Purchase Order)、定購項(Order Item)),并且封裝匹配這些實(shí)體所期望的行為的行為。 例如,定購單(Purchase Order)組件提供獲取關(guān)于已定購的產(chǎn)品列表和定購的總額的信息的功能;定購項(Order Item)組件提供獲取關(guān)于已定購的產(chǎn)品的數量和價(jià)格的信息的功能。每個(gè)組件的實(shí)現都封裝在接口的后面。因此,定購單(Purchase Order)組件的用戶(hù)不知道定購單(Purchase Order)表的模式、計算稅金的算法、以及定單總額中的回扣和/或折扣。 在面向服務(wù)的設計中,不能基于業(yè)務(wù)實(shí)體設計服務(wù)。相反,每個(gè)服務(wù)都是管理一組業(yè)務(wù)實(shí)體中的操作的完整單元。例如,顧客服務(wù)將響應來(lái)自任何其他系統或需要訪(fǎng)問(wèn)顧客信息的服務(wù)的請求。顧客服務(wù)可以處理更新顧客信息的請求;添加、更新、刪除投資組合;以及查詢(xún)顧客的定單歷史。顧客服務(wù)擁有所有與它管理的顧客有關(guān)的數據,并且能夠代表調用方進(jìn)行其他服務(wù)查詢(xún),以提供統一的顧客服務(wù)視圖。這意味著(zhù)服務(wù)是一個(gè)管理器對象,它創(chuàng )建和管理它的一組組件。
如前所述,企業(yè)正在處理兩個(gè)問(wèn)題:迅速地改變的能力和降低成本的要求。為了保持競爭力,企業(yè)必須快速地適應內部因素(如兼并和重組)或外部因素(如競爭能力和顧客要求)。需要經(jīng)濟而靈活的 IT 基礎設施來(lái)支持企業(yè)。 我們可以認識到,采用面向服務(wù)的體系結構將給我們帶來(lái)幾方面的好處,有助于我們在今天這個(gè)動(dòng)蕩的商業(yè)環(huán)境中取得成功: SOA 提供了一個(gè)抽象層,通過(guò)這個(gè)抽象層,企業(yè)可以繼續利用它在 IT 方面的投資,方法是將這些現有的資產(chǎn)包裝成提供企業(yè)功能的服務(wù)。組織可以繼續從現有的資源中獲取價(jià)值,而不必重新從頭開(kāi)始構建。 在面向服務(wù)的體系結構中,集成點(diǎn)是規范而不是實(shí)現。這提供了實(shí)現透明性,并將基礎設施和實(shí)現發(fā)生的改變所帶來(lái)的影響降到最低限度。通過(guò)提供針對基于完全不同的系統構建的現有資源和資產(chǎn)的服務(wù)規范,集成變得更加易于管理,因為復雜性是隔離的。當更多的企業(yè)一起協(xié)作提供價(jià)值鏈時(shí),這會(huì )變得更加重要。 從現有的服務(wù)中組合新的服務(wù)的能力為需要靈活地響應苛刻的商業(yè)要求的組織提供了獨特的優(yōu)勢。通過(guò)利用現有的組件和服務(wù),可以減少完成軟件開(kāi)發(fā)生命周期(包括收集需求、進(jìn)行設計、開(kāi)發(fā)和測試)所需的時(shí)間。這使得可以快速地開(kāi)發(fā)新的業(yè)務(wù)服務(wù),并允許組織迅速地對改變做出響應和減少上市準備時(shí)間。 通過(guò)以松散耦合的方式公開(kāi)的業(yè)務(wù)服務(wù),企業(yè)可以根據業(yè)務(wù)要求更輕松地使用和組合服務(wù)。這意味資源副本的減少、以及重用和降低成本的可能性的增加。 通過(guò) SOA,企業(yè)可以未雨綢繆,為未來(lái)做好充分的準備。SOA 業(yè)務(wù)流程是由一系列業(yè)務(wù)服務(wù)組成的,可以更輕松地創(chuàng )建、修改和管理它來(lái)滿(mǎn)足不同時(shí)期的需要。 SOA 提供了靈活性和響應能力,這對于企業(yè)的生存和發(fā)展來(lái)說(shuō)是至關(guān)重要的。但是面向服務(wù)的體系結構決不是靈丹妙藥,而遷移到 SOA 也并非一件可以輕而易舉就完成的事情。請別指望一個(gè)晚上就將整個(gè)企業(yè)系統遷移到面向服務(wù)的體系結構,我們推薦的方法是,在業(yè)務(wù)要求出現或露出苗頭時(shí)遷移企業(yè)功能的適當部分。 |
聯(lián)系客服