IBM介紹遷移到面向服務(wù)的體系結(jié)構(gòu)的方法.doc

遷移到面向服務(wù)的體系結(jié)構(gòu)，第 1 部分英文原文內(nèi)容：開發(fā)面向服務(wù)的體系結(jié)構(gòu)的情況面向服務(wù)的體系結(jié)構(gòu)的需求總結(jié)參考資料關(guān)于作者相關(guān)內(nèi)容：Web 服務(wù)體系結(jié)構(gòu)與最佳實(shí)踐在 Web 服務(wù)專區(qū)還有：教學(xué)工具與產(chǎn)品所有的文章簡介和概述 級(jí)別：中級(jí)Kishore Channabasavaiah，執(zhí)行架構(gòu)師，IBM Global ServicesKerrie Holley，杰出工程師，電子商務(wù)集成解決方案首席架構(gòu)師，IBM Global ServicesEdward M. Tuggle, Jr.，高級(jí)軟件工程師，IBM Software Group2004 年 1 月這是一系列文章第一部分，這一系列文章旨在幫助您更好的理解面向服務(wù)的體系結(jié)構(gòu)（SOA）的價(jià)值，制訂出一個(gè)實(shí)際的計(jì)劃來評(píng)估您現(xiàn)在的基礎(chǔ)架構(gòu)，并把它轉(zhuǎn)變成一個(gè)真正的面向服務(wù)的體系結(jié)構(gòu)。其目的在于，當(dāng)您讀完本文時(shí)，您將理解為什么聲稱 SOA 是把現(xiàn)有資產(chǎn)帶到未來的最好的平臺(tái)，同時(shí)也使得迅速而正確地開發(fā)未來的程序成為可能。另外，您將對(duì)在計(jì)劃這樣一次遷移的過程中主要考慮的事項(xiàng)有更好的理解。開發(fā)面向服務(wù)的體系結(jié)構(gòu)的情況在過去的40年里，軟件體系結(jié)構(gòu)試圖處理日益增長的軟件復(fù)雜性。但是，復(fù)雜性仍在繼續(xù)增加，傳統(tǒng)的體系結(jié)構(gòu)好像已經(jīng)達(dá)到了它們處理此類問題的極限。同時(shí)，IT 組織的傳統(tǒng)需要仍然繼續(xù)存在；比如，需要對(duì)新的業(yè)務(wù)需求進(jìn)行快速的反應(yīng)，需要不斷地減少業(yè)務(wù)中 IT 的成本，以及吸收、集成新的業(yè)務(wù)伙伴和新的客戶群。作為一個(gè)產(chǎn)業(yè)，我們經(jīng)歷了能夠提供完全的分布式處理的多種計(jì)算體系結(jié)構(gòu)和能夠運(yùn)行在任何平臺(tái)上的編程語言，從而大大縮短了實(shí)現(xiàn)的時(shí)間表，我們還經(jīng)歷了無數(shù)的連接性產(chǎn)品，這些產(chǎn)品能夠更快更好地集成應(yīng)用程序。然而，我們還是沒有找到完全的解決方案?，F(xiàn)在，業(yè)界提出面向服務(wù)的體系結(jié)構(gòu)（SOA）作為軟件體系結(jié)構(gòu)中下一個(gè)發(fā)展的階段來幫助 IT 組織滿足他們面臨的越來越多的復(fù)雜性的挑戰(zhàn)?？墒?，這種體系結(jié)構(gòu)現(xiàn)實(shí)嗎？即使它可以被概括和描述出來，它也能真的被實(shí)現(xiàn)嗎？本文的論點(diǎn)就是斷定 SOA 是現(xiàn)實(shí)的；在所有天花亂墜的宣傳塵埃落定之后，所有夸大的期望又回到了現(xiàn)實(shí)之中，您將發(fā)現(xiàn)至少現(xiàn)在 SOA 是 IT 組織可以將其現(xiàn)有的資產(chǎn)帶到未來同時(shí)又構(gòu)建新的應(yīng)用程序系統(tǒng)最好的基礎(chǔ)。這是一系列文章的第一部分，它旨在幫助您更好地理解面向服務(wù)的體系結(jié)構(gòu)（SOA）的價(jià)值，并且制訂出一個(gè)切實(shí)可行的計(jì)劃來評(píng)估您現(xiàn)有的基礎(chǔ)架構(gòu)，然后將其遷移到一個(gè)真正的面向服務(wù)的體系結(jié)構(gòu)。 曾幾何時(shí)，現(xiàn)有的 Web 服務(wù)技術(shù)刺激了關(guān)于面向服務(wù)的體系結(jié)構(gòu)（SOA）的討論。這個(gè)討論并不新鮮；從 CORBA 擴(kuò)展到在完全不同的異類平臺(tái)上應(yīng)用程序一直到現(xiàn)在，這個(gè)概念已經(jīng)發(fā)展10多年了。集成這樣的應(yīng)用程序的問題不斷出現(xiàn)，通常是因?yàn)橛心敲炊嗖煌模ǚ?CORBA 兼容的）對(duì)象模型流行起來；因而，很多架構(gòu)師和工程師都陷入了解決此類問題的泥淖中，開發(fā)一種更健壯的體系結(jié)構(gòu)來實(shí)現(xiàn)簡單、快速和安全的系統(tǒng)和應(yīng)用程序集成的承諾并沒有兌現(xiàn)。然而，問題卻在繼續(xù)增加，并且日益復(fù)雜?；镜臉I(yè)務(wù)需求，諸如降低成本、減少開發(fā)周期、跨企業(yè)集成、企業(yè)到企業(yè)（B2B）和企業(yè)到顧客（B2C）集成、更大的投資回報(bào)率（ROI）、創(chuàng)建自適應(yīng)的和自響應(yīng)的業(yè)務(wù)模型等等，使我們不停地尋找更好的解決方案；但是，我們?cè)絹碓接X得“點(diǎn)解決方案（point solutions）”不能解決這樣的基本問題。在很多情況下，問題在于缺乏一個(gè)一致的體系結(jié)構(gòu)框架，在這種體系結(jié)構(gòu)中，可以快速地開發(fā)、集成和重用應(yīng)用程序。更重要的是，我們需要一個(gè)這樣的體系結(jié)構(gòu)框架，它能夠裝配組件和服務(wù)，以便快速甚至動(dòng)態(tài)地交付應(yīng)用程序。為什么像 Web 服務(wù)這樣的某種技術(shù)是好的，但是我們真正需要的是一種不受技術(shù)約束的體系結(jié)構(gòu)，有很多文章對(duì)此進(jìn)行了討論。讓我們首先考慮一些基本的問題，這些問題是我們尋求更好的基礎(chǔ)的依據(jù)，如何解決這些問題將決定我們工作的成敗。 首要問題 - 復(fù)雜性一些事情總是相同的，特別是 IT 組織所面對(duì)的業(yè)務(wù)問題。公司管理層總是努力爭取更好地利用 IT、獲取更大的投資回報(bào)率（ROI）、集成歷史上分離的系統(tǒng)和更快地實(shí)現(xiàn)新系統(tǒng)；但是時(shí)至今日，事情發(fā)生了些許變化?，F(xiàn)在，您遇到的是更復(fù)雜的環(huán)境。必須重用而不是替換遺留系統(tǒng)，因?yàn)榭紤]到更有限的預(yù)算，替換的成本是高昂的。您將發(fā)現(xiàn)費(fèi)用低廉、無處不在的 Internet 訪問使得建立一個(gè)全新的業(yè)務(wù)模型成為可能。公司至少需要評(píng)估這個(gè)模型，因?yàn)楦偁幨谷?。合并和收購的增長已經(jīng)成為家常便飯，因此必須將整個(gè) IT 組織、應(yīng)用程序和基礎(chǔ)架構(gòu)集成和融合在一起。在這樣復(fù)雜的環(huán)境，點(diǎn)解決方案只會(huì)使問題進(jìn)一步惡化，而決不會(huì)引導(dǎo)我們走出重林。必須在一個(gè)以異構(gòu)為基礎(chǔ)的環(huán)境中開發(fā)系統(tǒng)，因?yàn)樗鼈儽仨毴菁{種類繁多的硬件、操作系統(tǒng)、中間件、語言和數(shù)據(jù)存儲(chǔ)。長達(dá)數(shù)十年的發(fā)展和演化積累起來的影響導(dǎo)致了嚴(yán)重的復(fù)雜性。面對(duì)所有這些對(duì) IT 業(yè)務(wù)的挑戰(zhàn)，很多 CIO 將應(yīng)用程序集成作為首要任務(wù)也就不是令人驚訝的事情了，如圖1所示。 圖1. CIO 優(yōu)先考慮的事情另一問題 - 冗余和不可重用編程考慮一個(gè)銀行有一些分離的“地窖”在銀行內(nèi)不為其他系統(tǒng)所知的自包含應(yīng)用程序系統(tǒng)。這些應(yīng)用程序系統(tǒng)中的第一個(gè)可能是優(yōu)秀的設(shè)計(jì)，同樣，第二個(gè)、第三個(gè)等等可能都是。但是每一個(gè)都是針對(duì)銀行中不同業(yè)務(wù)的，是單獨(dú)投資的孤立項(xiàng)目。因而，例如獲取賬戶余額的功能在 ATM 系統(tǒng)、分行出納員交付系統(tǒng)、信用卡計(jì)分系統(tǒng)都是重復(fù)的，即便它們存取相同數(shù)據(jù)庫中的相同會(huì)計(jì)數(shù)據(jù)數(shù)據(jù)。現(xiàn)在，假設(shè)該銀行必須為客戶開發(fā) Internet 服務(wù)、在線銀行或在線貸款發(fā)放系統(tǒng)以保持競爭力，結(jié)果會(huì)怎么樣。新系統(tǒng)只會(huì)給已經(jīng)存在的冗余編程問題雪上加霜，除非通過某種方式使得現(xiàn)有的代碼可以重用。 真正的集成難題 - 接口多樣性同樣考慮 n（n-1）集成問題。任何組織都會(huì)碰到某些類型的集成問題；或許是因?yàn)橐淮喂镜暮喜ⅰ⒁粋€(gè)新的商業(yè)聯(lián)盟或者僅僅是需要互連現(xiàn)有的系統(tǒng)。如果 n 個(gè)應(yīng)用程序系統(tǒng)必須直接互連，那么將會(huì)產(chǎn)生 n(n-1) 個(gè)連接或接口。在圖2中，每個(gè)箭頭表示一個(gè)接口。 圖2. n 個(gè)應(yīng)用程序的直接集成因此，如果另一個(gè)應(yīng)用程序系統(tǒng) A（第 n+1 個(gè)）必須集成進(jìn)來，將需要產(chǎn)生、文檔化、測(cè)試和維護(hù) 2n 個(gè)新的接口。雖然在上圖中，5個(gè)應(yīng)用程序組成的集合需要20個(gè)直接接口，但是添加第6個(gè)應(yīng)用程序?qū)⑿枰?0個(gè)新接口！而更糟的是，必須修改每個(gè)已有的應(yīng)用程序中的代碼以包括進(jìn)新的接口，因而將發(fā)生大量的測(cè)試費(fèi)用。您可以立即為 n 個(gè)應(yīng)用程序找到產(chǎn)生最小接口數(shù)目（n）的最優(yōu)解決方案，只為每個(gè)附加的系統(tǒng)添加一個(gè)新的接口，但是，通過直接連接是做不到的。 將來會(huì)怎樣呢？在過去的40多年來，軟件開發(fā)的實(shí)踐經(jīng)歷了幾個(gè)不同的編程模型。而進(jìn)行的每一次轉(zhuǎn)變?cè)谀撤N程度上都是為了處理更高級(jí)別的軟件復(fù)雜性，并且使得可以通過部件、組件或服務(wù)來裝配應(yīng)用程序。近來，Java 技術(shù)促成了平臺(tái)中立的編程，而 XML 促成了自描述，因而也促成了平臺(tái)中立的數(shù)據(jù)?，F(xiàn)在，Web 服務(wù)通過允許應(yīng)用程序以對(duì)象模型中立的方式實(shí)現(xiàn)互連，從而克服了另一個(gè)障礙。使用簡單的基于 XML 的消息傳遞 Scheme，Java 應(yīng)用程序能夠調(diào)用基于 DCOM、遵循 CORBA 甚至是 COBOL 的應(yīng)用程序。在新加坡的一臺(tái)大型機(jī)上的 CICS 或 IMS 事務(wù)能夠被一臺(tái)在慕尼黑的 Domino 服務(wù)器上運(yùn)行的 Lotus 腳本驅(qū)動(dòng)的基于 COM 的應(yīng)用程序調(diào)用。最好的情況是，調(diào)用程序很有可能根本不知道該事務(wù)在哪里運(yùn)行、它是由哪種語言編寫的以及消息的傳輸路徑。只需提出服務(wù)請(qǐng)求，然后就會(huì)得到答案。 與其任何一個(gè)前身相比，Web 服務(wù)更有可能成為提供提供有效的、可靠的和可擴(kuò)展的機(jī)器到機(jī)器交互的標(biāo)準(zhǔn)，這是幾個(gè)技術(shù)和文化上必須具備的先決條件適時(shí)結(jié)合的產(chǎn)物。這些先決條件包括： 無處不在的、開放標(biāo)準(zhǔn)的、低成本的網(wǎng)絡(luò)基礎(chǔ)架構(gòu)和技術(shù)。它有助于一個(gè)分布式環(huán)境的形成，這個(gè)環(huán)境更有利于采用 Web 服務(wù)，而不是 CORBA 和 DCE 在一個(gè)以網(wǎng)絡(luò)為中心的領(lǐng)域內(nèi)達(dá)到的接受程度和技術(shù)成熟水平。它要求互操作性以實(shí)現(xiàn)關(guān)鍵的業(yè)務(wù)目標(biāo)（比如，分布式協(xié)作） 一致同意基于 Internet 的開放標(biāo)準(zhǔn)和相關(guān)技術(shù)是實(shí)現(xiàn)低成本互操作性的最好方法。 基于網(wǎng)絡(luò)的技術(shù)（比如 TCP/IP）、工具集（IDE、UML等等）、平臺(tái)（比如 J2EE 平臺(tái)）和相關(guān)的方法（比如 OO、服務(wù)等等）的成熟水平。它們提供了簡化松散耦合的、可互操作的、機(jī)器到機(jī)器的交互（一種比 CORBA 用戶體驗(yàn)到的高級(jí)得多的狀態(tài)）所需的基礎(chǔ)架構(gòu)。面向服務(wù)的體系結(jié)構(gòu)允許設(shè)計(jì)這樣的軟件系統(tǒng)，它通過發(fā)布的可發(fā)現(xiàn)的接口為其他的應(yīng)用程序提供服務(wù)，而其中的服務(wù)可以通過網(wǎng)絡(luò)進(jìn)行調(diào)用。當(dāng)您用 Web 服務(wù)技術(shù)來實(shí)現(xiàn)面向服務(wù)的體系結(jié)構(gòu)時(shí)，您是在一個(gè)更強(qiáng)大、更靈活的編程模型中創(chuàng)建一種新的構(gòu)建應(yīng)用程序的方式，從而降低開發(fā)成本、持有成本以及實(shí)現(xiàn)風(fēng)險(xiǎn)。SOA 既是體系結(jié)構(gòu)模型，又是編程模型，是一種考慮構(gòu)建軟件的方式。 然而，還有更重要的機(jī)會(huì)剛剛出現(xiàn)。其中第一個(gè)就是網(wǎng)格計(jì)算，網(wǎng)格計(jì)算不僅是使用擁有大量 MIPS 的應(yīng)用程序來進(jìn)行計(jì)算的解決方案，而且還將提供一個(gè)框架，通過此框架可以動(dòng)態(tài)地定位、重定位、平衡和管理大量的服務(wù)，這樣，無論系統(tǒng)上的負(fù)載如何，總可以保證安全地獲取所需的應(yīng)用程序。而這又明顯地需要按需計(jì)算的概念（on-demand computing），按需計(jì)算可能是在任何配置下實(shí)現(xiàn)的，從簡單的服務(wù)器集群到有1024個(gè)節(jié)點(diǎn)的 SP2 網(wǎng)絡(luò)。用戶需要解決問題和適當(dāng)?shù)挠糜诮鉀Q問題的計(jì)算資源不多也不少并且為實(shí)際使用的資源付費(fèi)。 這些新功能的有效使用將需要重新構(gòu)造許多現(xiàn)有的應(yīng)用程序?，F(xiàn)有的單一應(yīng)用程序能夠在這些環(huán)境中運(yùn)行，但沒有以最優(yōu)的方式來使用可用的資源。這個(gè)問題和先前討論過的問題一起可以產(chǎn)生如下結(jié)論：必須作出根本的改變遷移到面向服務(wù)的體系結(jié)構(gòu)。 面向服務(wù)的體系結(jié)構(gòu)的需求根據(jù)上面討論的問題，可以很明顯地看出，應(yīng)該開發(fā)一種體系結(jié)構(gòu)來滿足所有的需求，這些需求包括： 1. 首要的一點(diǎn)就是利用現(xiàn)有的資產(chǎn)?，F(xiàn)有系統(tǒng)很少可以拋棄，它們通常都包含對(duì)于企業(yè)很有價(jià)值的東西。從戰(zhàn)略上講，目標(biāo)是構(gòu)造一個(gè)新的體系結(jié)構(gòu)來創(chuàng)造所有想要的價(jià)值，但是，從戰(zhàn)術(shù)上講，必須集成現(xiàn)有系統(tǒng)，以便隨著時(shí)間的推移，可以在可管理、漸進(jìn)式項(xiàng)目中分化或取代它們。 2. 支持所有必需的集成類型或“樣式”。這包括： o 用戶交互能夠提供單一的、交互式的用戶體驗(yàn) o 應(yīng)用程序連接性通信層構(gòu)成了所有體系結(jié)構(gòu)的基礎(chǔ) o 流程集成編排應(yīng)用程序和服務(wù) o 信息集成聯(lián)合和移動(dòng)企業(yè)數(shù)據(jù) o 依集成需求而構(gòu)建構(gòu)建和部署新的應(yīng)用程序和服務(wù)。 3. 允許漸進(jìn)式實(shí)現(xiàn)和資產(chǎn)遷移這將支持開發(fā)這種體系結(jié)構(gòu)的一個(gè)最關(guān)鍵的方面：獲得更大的投資回報(bào)率（ROI）的能力。數(shù)不清的集成項(xiàng)目由于它們的復(fù)雜性、成本和不切實(shí)際的實(shí)現(xiàn)進(jìn)度安排而失敗。 4. 包括一個(gè)以標(biāo)準(zhǔn)的組件框架為基礎(chǔ)構(gòu)建的開發(fā)環(huán)境，促進(jìn)更好地重用模塊和系統(tǒng)，允許將遺留資產(chǎn)轉(zhuǎn)移到這個(gè)框架中，并且考慮到新技術(shù)的及時(shí)實(shí)現(xiàn)。 5. 允許實(shí)現(xiàn)新的計(jì)算模型；特別是，新的基于 Portal 的客戶端模型、網(wǎng)格計(jì)算和按需計(jì)算（on-demand computing）。 面向服務(wù)的體系結(jié)構(gòu)不只是 Web 服務(wù)Web 服務(wù)的出現(xiàn)產(chǎn)生了根本的改變，因?yàn)楹芏?Web 服務(wù)項(xiàng)目的成功顯示這種技術(shù)事實(shí)上確實(shí)存在，借此您可以實(shí)現(xiàn)真正的面向服務(wù)的體系結(jié)構(gòu)。它使您又往回走了一步，不僅分析您的應(yīng)用程序的體系結(jié)構(gòu)，而且還要分析您正設(shè)法解決的基本業(yè)務(wù)問題。從業(yè)務(wù)的角度來看，它不再是一個(gè)技術(shù)問題，而是要開發(fā)一種應(yīng)用程序體系結(jié)構(gòu)和框架，可以在其中定義業(yè)務(wù)問題，還可以以一致的可重復(fù)的方式來實(shí)現(xiàn)解決方案。 不過，首先必須理解Web 服務(wù)并不等同于面向服務(wù)的體系結(jié)構(gòu)。Web 服務(wù)是包括 XML，SOAP，WSDL 和 UDDI 在內(nèi)的技術(shù)的集合，它使您能夠針對(duì)特定的消息傳遞和應(yīng)用程序集成問題構(gòu)建編程解決方案。隨著時(shí)間的推移，您有理由相信這些技術(shù)將逐漸成熟并最終為更好、更有效、更健壯的技術(shù)所取代，但是，就目前的情況而言，它們可以發(fā)揮作用。至少，它們是 SOAs 能夠最終實(shí)現(xiàn)這種觀念的證明。那么，面向服務(wù)的體系結(jié)構(gòu)實(shí)際上是由什么組成的呢？ SOA 只不過是一種體系結(jié)構(gòu)。它不是任何諸如 Web 服務(wù)這樣的特定技術(shù)的集合；而是超越它們的，在理想的情況下，是完全獨(dú)立于它們的。在業(yè)務(wù)環(huán)境中，SOA 的純粹的體系結(jié)構(gòu)定義可能會(huì)是這樣的“一種應(yīng)用程序體系結(jié)構(gòu)，在這種體系結(jié)構(gòu)中，所有功能都定義為獨(dú)立的服務(wù)，這些服務(wù)帶有定義明確的可調(diào)用接口，可以以定義好的順序調(diào)用這些服務(wù)來形成業(yè)務(wù)流程”。請(qǐng)注意這里的表述： 1. 所有功能都定義為服務(wù)。這僅僅包括業(yè)務(wù)功能、由底層功能組成的業(yè)務(wù)事務(wù)和系統(tǒng)服務(wù)功能。這將會(huì)產(chǎn)生粒度問題，后面我們將對(duì)此進(jìn)行討論。 2. 所有的服務(wù)都是獨(dú)立的。它們就像“黑匣子”一樣運(yùn)行：外部組件既不知道也不關(guān)心它們?nèi)绾螆?zhí)行它們的功能，而僅僅關(guān)心它們是否返回期望的結(jié)果。 3. 在其最一般的意義上來說，接口是可調(diào)用的；也就是說，在體系結(jié)構(gòu)的層面上，它們究竟是本地的（在本系統(tǒng)內(nèi)）還是遠(yuǎn)程的（在直接系統(tǒng)外）、是用什么互連 Scheme 或協(xié)議來調(diào)用或需要什么樣的基礎(chǔ)架構(gòu)組件來連接，都是無關(guān)緊要的。服務(wù)可能是在相同的應(yīng)用程序中，也可能是在公司內(nèi)部網(wǎng)內(nèi)完全不同的系統(tǒng)上的不對(duì)稱多處理器的不同地址空間中，還有可能是在用于 B2B 配置的合作伙伴的系統(tǒng)上的應(yīng)用程序中。 在所有這些表述中，接口是最關(guān)鍵的，同時(shí)也是調(diào)用應(yīng)用程序關(guān)注的焦點(diǎn)。它定義了必需的參數(shù)和結(jié)果的類型；因而，它定義了服務(wù)的類型，而不是實(shí)現(xiàn)服務(wù)的技術(shù)。系統(tǒng)的責(zé)任是實(shí)現(xiàn)和管理服務(wù)的調(diào)用，而不是調(diào)用應(yīng)用程序。這使得可以認(rèn)識(shí)到兩個(gè)關(guān)鍵的特征：其一，服務(wù)是真正獨(dú)立的；其二，它們是可以管理的。管理包括許多功能，其中有： 1. 安全性請(qǐng)求的授權(quán)、加密和解密（在需要時(shí)）、確認(rèn)等等 2. 部署出于性能、可用性冗余或其他方面的原因，允許服務(wù)在網(wǎng)絡(luò)內(nèi)重新部署（移動(dòng)） 3. 日志用于審核、測(cè)量等等 4. 動(dòng)態(tài)重新路由用于故障排除（fail over）或負(fù)載平衡 5. 維護(hù)管理服務(wù)的新版本總結(jié)在第一部分中，您已經(jīng)簡要地分析了一些導(dǎo)致需要考慮 SOA 的問題，這些需求寄希望于新的體系結(jié)構(gòu)。而在第二部分中，我們將研究服務(wù)的類型，構(gòu)造一個(gè)基于服務(wù)的組件的應(yīng)用程序框架和一些將來的計(jì)算環(huán)境，這些環(huán)境將使得 SOA 的開發(fā)更加勢(shì)在必行。參考資料 查閱 IBM developerWorks Web services 專區(qū) 來獲得 Web 服務(wù)白皮書和工具。 要查找 Web 服務(wù)和面向服務(wù)的體系結(jié)構(gòu)方面的客戶項(xiàng)目案例，請(qǐng)參閱 IBM jStart Web 站點(diǎn)。 閱讀文章 Best practices for determining the proper level of granularity of services within a SOA（developerWorks，2003年10月）。 閱讀 Accessing CICS transactions as services within a SOA（IBM）。 Zackman Framework for Enterprise Architecture 將是這一系列關(guān)于 SOA 的文章中另一篇的主題。在 Zachman 框架以外，還開發(fā)了幾個(gè)主要的體系結(jié)構(gòu)框架，其中包括： o 聯(lián)邦企業(yè)體系結(jié)構(gòu)框架（FEAF） o 用于命令、控制、通信、計(jì)算機(jī)、智能、監(jiān)視和偵查（C4ISR）體系結(jié)構(gòu) o 開放組織體系結(jié)構(gòu)框架（TOGAF）關(guān)于作者 Kishore Channabasavaiah 獲得了印度 Bangalore 大學(xué)機(jī)械工程學(xué)士學(xué)位。他現(xiàn)在是 IBM 全球服務(wù)芝加哥創(chuàng)新中心（Chicago Innovation Center of IBM Global Services）的執(zhí)行架構(gòu)師。他專門從事 Web 服務(wù)和端到端解決方案的研究，為電子商務(wù)的集成解決方案提供思想指導(dǎo)。目前，他側(cè)重于 Web 應(yīng)用程序的解決方案、技術(shù)解決方案評(píng)論、Web 服務(wù)、面向服務(wù)的體系結(jié)構(gòu)和普及計(jì)算（Pervasive Computing）。您可以通過 與 Kishorec 聯(lián)系。Kerrie Holley 獲得了 DePaul 大學(xué)數(shù)學(xué)文學(xué)學(xué)士學(xué)位和法學(xué)博士學(xué)位。他現(xiàn)在是 IBM Global Services 的杰出工程師和電子商務(wù)集成解決方案首席架構(gòu)師。在電子商務(wù)集成解決方案方面，他提供 Web 服務(wù)實(shí)踐的思想領(lǐng)導(dǎo)。他目前主要從事軟件工程最佳實(shí)踐、端到端高級(jí) Web 開發(fā)、自適應(yīng)的企業(yè)體系結(jié)構(gòu)、體系結(jié)構(gòu)評(píng)論、Web 服務(wù)和面向服務(wù)的體系結(jié)構(gòu)。您可以通過 與 Kerrie 聯(lián)系。Edward M. Tuggle, Jr. 獲得了俄克拉何馬州大學(xué)數(shù)學(xué)理學(xué)士學(xué)位，目前是 IBM Software Group jStart Emerging Technology Solutions team 的高級(jí)軟件工程師。他在 IBM 從事操作系統(tǒng)設(shè)計(jì)、開發(fā)和維護(hù)工作有23年，在過去的6年里研究的是 Java 技術(shù)和其他新興技術(shù)?，F(xiàn)在，Edward 專攻 Web 服務(wù)和面向服務(wù)的體系結(jié)構(gòu)。您可以通過 與 Edward 聯(lián)系。遷移到面向服務(wù)的體系結(jié)構(gòu)，第 2 部分英文原文內(nèi)容：服務(wù)的性質(zhì)解決前面的問題體系結(jié)構(gòu)中的集成需求部署面向服務(wù)的體系結(jié)構(gòu)的好處未來 新模型，新需求總結(jié)參考資料關(guān)于作者相關(guān)內(nèi)容：Web Services 體系結(jié)構(gòu)和最佳實(shí)踐遷移到面向服務(wù)的體系結(jié)構(gòu)，第 1 部分在 Web 服務(wù)專區(qū)還有：教學(xué)工具與產(chǎn)品所有的文章簡介和概述（繼續(xù)） 級(jí)別：中級(jí)Kishore Channabasavaiah，執(zhí)行架構(gòu)師，IBM Global ServicesKerrie Holley，杰出工程師，電子商務(wù)集成解決方案首席架構(gòu)師，IBM Global ServicesEdward M. Tuggle, Jr.，高級(jí)軟件工程師，IBM Software Group2004 年 1 月這是一系列文章的第二部分。這一系列文章旨在幫助您更好地理解面向服務(wù)的體系結(jié)構(gòu)（SOA）的價(jià)值，制訂出一個(gè)實(shí)際的計(jì)劃來評(píng)估您現(xiàn)在的基礎(chǔ)架構(gòu)，并把它轉(zhuǎn)變成一個(gè)真正的面向服務(wù)的體系結(jié)構(gòu)。其目的在于，當(dāng)您讀完本文時(shí)，您將理解為什么聲稱 SOA 是把現(xiàn)有資產(chǎn)帶到未來的最好的平臺(tái)，同時(shí)也使得迅速而正確地開發(fā)未來的程序成為可能。另外，您將對(duì)在計(jì)劃這樣一次遷移的過程中主要考慮的事項(xiàng)有更好的理解。這一系列文章的第一部分描述了推動(dòng)考慮 SOA 的動(dòng)力和這樣的一個(gè)體系結(jié)構(gòu)的需求?，F(xiàn)在，第二部分將繼續(xù)討論服務(wù)和接口。服務(wù)的性質(zhì)什么是服務(wù)？如前所述，在一個(gè)典型的業(yè)務(wù)環(huán)境里，服務(wù)意味著業(yè)務(wù)函數(shù)、業(yè)務(wù)事務(wù)和系統(tǒng)服務(wù)。業(yè)務(wù)函數(shù)可能是 getStockQuote、getCustomerAddress 或 checkCreditRating。業(yè)務(wù)事務(wù)可能是 commitInventory、sellCoveredOption 或 scheduleDelivery。系統(tǒng)服務(wù)可能是 logMessageIn、getTimeStamp 或 openFile。請(qǐng)注意各種類型服務(wù)之間的區(qū)別。從應(yīng)用程序的角度來看，業(yè)務(wù)函數(shù)實(shí)際上是原子的非系統(tǒng)函數(shù)。業(yè)務(wù)事務(wù)很像是調(diào)用應(yīng)用程序的簡單函數(shù)，但是它們可能是作為自己的事務(wù)的上下文所包含的復(fù)合函數(shù)來實(shí)現(xiàn)的。它們可能包括多個(gè)底層函數(shù)，這些底層函數(shù)對(duì)調(diào)用者來說是透明的。系統(tǒng)函數(shù)是能夠從諸如 Windows 或者 Linux 這樣的特定平臺(tái)中抽象出來的廣義函數(shù)。應(yīng)用程序框架可能提供像 openFile 這樣的廣義函數(shù)來有效地虛擬化數(shù)據(jù)源，從而可以在不考慮真實(shí)數(shù)據(jù)源的類型和位置的情況下使用這類函數(shù)。 這看起來像人為地規(guī)定服務(wù)之間的區(qū)別；您可以從應(yīng)用程序的角度斷言，所有的服務(wù)都是原子的，而與它是業(yè)務(wù)服務(wù)還是系統(tǒng)服務(wù)無關(guān)。做出這樣的區(qū)別僅僅是為了引入粒度這個(gè)重要的概念。將業(yè)務(wù)程序分解成服務(wù)不僅僅是一個(gè)抽象的過程；它具有非常真實(shí)的現(xiàn)實(shí)含義。根據(jù)定義，服務(wù)可能是低級(jí)（細(xì)粒度的）函數(shù)，也可能是復(fù)雜的高級(jí)（粗粒度的）函數(shù)，并且在性能、靈活性、可維護(hù)性和可重用性方面都有很現(xiàn)實(shí)的折衷選擇。定義服務(wù)的過程通常是在更大的作用域（應(yīng)用程序框架的作用域）內(nèi)完成的。這才是必須做的實(shí)際工作：也就是開發(fā)基于組件的應(yīng)用程序框架，其中，服務(wù)定義為一組可重用的組件，而這些組件又可以用來構(gòu)建新的應(yīng)用程序或集成現(xiàn)有的軟件資產(chǎn)。 現(xiàn)在，可以獲得很多這樣的框架；在 IBM，一些像 EWA、JADE 和 Struts （來自 Jakarta）的這樣的框架正用在客戶集成場景中。以 EWA （讀作“Eva”） 為例（它來自 IBM Software Group Advanced Technology Solutions 組），在一個(gè)較高的層次上，框架看起來如 圖 1 所示。在這個(gè)框架中，配置定義了一個(gè)應(yīng)用程序，描述了該應(yīng)用程序的組件以及它們調(diào)用的順序和方法。以源中立的方式接收輸入并將其傳送到應(yīng)用程序。因此，舉例來說，用現(xiàn)有的 ATM 訪問將因特網(wǎng)連接添加到一個(gè)銀行應(yīng)用程序，對(duì)應(yīng)用程序邏輯來說是透明的。前端設(shè)備和協(xié)議處理程序使其成為可能。核心提供系統(tǒng)級(jí)服務(wù)，而特定用途的使得能夠連接后端企業(yè)應(yīng)用程序，這樣它們就可以保持原來的狀態(tài)，或者在一段時(shí)間以后進(jìn)行遷移。雖然 EWA 是完全遵循 J2EE，但是它可以連接到外部基于 DCOM 或 CORBA 組件的系統(tǒng)。 圖 1. EWA 框圖現(xiàn)在，EWA 包括超過 1500 個(gè)的常規(guī)和特定用途的組件，從而大大地減少了編寫新的應(yīng)用程序所需的代碼數(shù)量。本系列的另一篇文章將詳細(xì)地研究應(yīng)用程序框架以及用戶在開發(fā)這樣一個(gè)應(yīng)用程序框架的過程中需要什么。 解決前面的問題現(xiàn)在，讓我們回到討論第一個(gè)集成場景，尋找一個(gè)將所需的接口數(shù)量減到最少的 Scheme，如圖 2 所示。 圖 2. 將接口減到最少這張圖看起來可能過于簡化，但是現(xiàn)在可以很清楚地看出，在像 EWA 這樣的框架中，這張圖是一個(gè)起點(diǎn)?，F(xiàn)在，添加屬于體系結(jié)構(gòu)概念范圍的服務(wù)總線（Service Bus）（在圖 3 中用深色的中線表示）和服務(wù)或流管理器來連接服務(wù)和提供服務(wù)請(qǐng)求的路徑。流管理器處理定義好的執(zhí)行序列或服務(wù)流，它們將按照適當(dāng)?shù)捻樞蛘{(diào)用所需的服務(wù)來產(chǎn)生最后的結(jié)果。業(yè)務(wù)流程執(zhí)行語言（Business Process Execution Language，BPEL）就是這種將流程定義為一組服務(wù)調(diào)用的技術(shù)的例子。 圖 3. 添加總線和執(zhí)行管理在這里，您需要確定如何調(diào)用服務(wù)，因而您將添加應(yīng)用程序配置。接著，虛擬化輸入和輸出。最后，提供到后端流程的連接，以便使它們可以按“僅此狀態(tài)”運(yùn)行，并且還可以在將來進(jìn)行遷移。現(xiàn)在，這個(gè)高層次的圖至少在結(jié)構(gòu)上是完整的了，如圖 4 所示。 圖 4. 完整的基本結(jié)構(gòu)這張圖與 EWA 框圖有一些類同之處是毫不奇怪的；在最高的層次上，任何健壯的應(yīng)用程序框架都必須提供這些功能。然而，從現(xiàn)在起，真正的工作開始了構(gòu)建 1500 個(gè)組件來豐富這個(gè)骨架。這就是為什么很多 IT 架構(gòu)師選擇在一個(gè)現(xiàn)有的框架中進(jìn)行實(shí)現(xiàn)的原因；把現(xiàn)有的應(yīng)用程序分解成用于框架的組件就夠了，而不必重新開發(fā)所有其他已知將要用到的通用用途組件和系統(tǒng)組件。無論您如何使用它，您都可以使用現(xiàn)有的技術(shù)和框架來實(shí)現(xiàn)該體系結(jié)構(gòu)，所以您繞了一整圈，現(xiàn)在又回到了開始的地方，在這里，流程首先分析必須解決的業(yè)務(wù)問題。如果您敢肯定您的體系結(jié)構(gòu)事實(shí)上是可實(shí)現(xiàn)的，您現(xiàn)在就可以這樣做。體系結(jié)構(gòu)中的集成需求討論至此，集成已限定為通過基于組件的服務(wù)進(jìn)行的應(yīng)用程序的集成，但是集成這個(gè)主題比這要寬泛得多。在估計(jì)一個(gè)體系結(jié)構(gòu)的需求時(shí)，必須考慮一些集成的類型或“方式”。您必須考慮如下幾方面： 應(yīng)用程序集成 終端用戶界面集成 應(yīng)用程序連接 流程集成 信息集成 構(gòu)建集成開發(fā)模型。終端用戶界面集成涉及如何集成特定用戶訪問的全部應(yīng)用程序和服務(wù)來提供可用、高效、一致的界面。它是一個(gè)正在發(fā)展的主題，而新的發(fā)展在近期將主要取決于 Portal 服務(wù)器使用方面的進(jìn)展。雖然 Portlet 已經(jīng)可以通過 Web 服務(wù)調(diào)用本地服務(wù)組件，但是新技術(shù)（比如用戶遠(yuǎn)程 Portlet 的 Web 服務(wù)）將使內(nèi)容和應(yīng)用程序提供者能夠創(chuàng)建交互式服務(wù)，這些服務(wù)在因特網(wǎng)上可以通過 Portal 即插即用，從而為很多新的集成提供了可能。應(yīng)用程序連接是一種集成方式，它涉及體系結(jié)構(gòu)必須支持的所有類型的連接。在一個(gè)層次上，這意味著數(shù)據(jù)的同步和異步通信、路由、轉(zhuǎn)換和高速分布、以及網(wǎng)關(guān)和協(xié)議轉(zhuǎn)換器等等。而在另一個(gè)層次上，它還與輸入和輸出或源（sources）和匯（sinks）的虛擬化有關(guān)，正如您在 EWA 的通道（Channel）和協(xié)議轉(zhuǎn)換程序（Protocol Handlers）中所看到的。這里的問題在于數(shù)據(jù)移入、移出以及在實(shí)現(xiàn)體系結(jié)構(gòu)的框架中移動(dòng)的方式。流程集成涉及開發(fā)映射到業(yè)務(wù)流程和為業(yè)務(wù)流程提供解決方案的計(jì)算流程、將應(yīng)用程序集成到流程以及集成一些流程與其他一些流程。雖然第一項(xiàng)需求可能看起來似乎無關(guān)緊要，不過就是體系結(jié)構(gòu)提供一個(gè)模擬基本業(yè)務(wù)問題的環(huán)境，但是，如果在這一層中不進(jìn)行充分的分析，體系結(jié)構(gòu)的任何實(shí)現(xiàn)注定都將失敗，不管它采用的技術(shù)是多么的巧妙。將應(yīng)用程序集成到流程可能包括企業(yè)中的應(yīng)用程序，也可能涉及調(diào)用遠(yuǎn)程系統(tǒng)中的應(yīng)用程序或服務(wù)，而這些遠(yuǎn)程系統(tǒng)多半屬于業(yè)務(wù)合作伙伴。同樣地，流程層集成可能涉及整個(gè)流程的集成而不僅僅是來自外部源的單個(gè)服務(wù)，比如供應(yīng)鏈管理或金融服務(wù)這樣橫跨多個(gè)機(jī)構(gòu)的流程。為了滿足這樣的應(yīng)用程序和流程的集成需求，可以使用像 BPEL4WS 這樣的技術(shù)，而應(yīng)用程序框架也可以使用程序配置 Scheme（比如在 EWA 中看到的）。實(shí)際上，可以在底層使用 BPEL4WS 來構(gòu)造一個(gè)高層配置 Scheme，然后通過一個(gè)引擎來驅(qū)動(dòng)，這個(gè)引擎不僅提供流管理，而且還提供其他功能。然而，在構(gòu)建這一切之前，您應(yīng)該首先了解體系結(jié)構(gòu)方面的需求，然后，再構(gòu)建合適的基礎(chǔ)架構(gòu)。信息集成是一個(gè)流程，其作用在于為所有需要它的應(yīng)用程序提供對(duì)企業(yè)中全部數(shù)據(jù)的一致訪問，而不管這些應(yīng)用程序是以什么形式需要它，也不受數(shù)據(jù)的格式、來源或位置的限制。在實(shí)現(xiàn)時(shí)，這項(xiàng)需求可能包括適配器和轉(zhuǎn)換引擎，不過它通常要比這復(fù)雜。而關(guān)鍵的概念往往是數(shù)據(jù)的虛擬化，這可能包括數(shù)據(jù)總線（Data Bus）的開發(fā)，企業(yè)中的所有應(yīng)用程序都通過標(biāo)準(zhǔn)服務(wù)或接口從數(shù)據(jù)總線中請(qǐng)求數(shù)據(jù)。因此，不管數(shù)據(jù)是來自電子數(shù)據(jù)表、本地文件、SQL 或 DL/I 數(shù)據(jù)庫，還是來自內(nèi)存中的數(shù)據(jù)存儲(chǔ)，都可以將數(shù)據(jù)提供給應(yīng)用程序。永久存儲(chǔ)中的數(shù)據(jù)格式可能還不為應(yīng)用程序所知。應(yīng)用程序更不知道管理數(shù)據(jù)的操作系統(tǒng)，因而訪問 AIX 或 Linux 系統(tǒng)中的本地文件的方式與這些文件放在 Windows、OS/2、ZOS 或其他系統(tǒng)中時(shí)訪問它們的方式相同。同樣地，數(shù)據(jù)的位置也是透明的；由于它是由共同的服務(wù)提供的，所以是由訪問服務(wù)而不是由應(yīng)用程序來負(fù)責(zé)查詢數(shù)據(jù)（無論是本地的還是遠(yuǎn)程的），然后按照請(qǐng)求的格式提供數(shù)據(jù)。應(yīng)用程序開發(fā)環(huán)境的最后一項(xiàng)需求是，必須考慮可能在企業(yè)中實(shí)現(xiàn)的集成的所有方式和層次，并且為它們的開發(fā)和部署做好準(zhǔn)備。要想真正做到健壯，開發(fā)環(huán)境必須包括（和執(zhí)行）一種方法來明確地規(guī)定如何設(shè)計(jì)和構(gòu)建服務(wù)和組件，以便促進(jìn)重用、消除冗余和簡化測(cè)試、部署和維護(hù)。上面列出的所有集成方式在任何企業(yè)中都有一定程度的體現(xiàn)，盡管在某些情況下它們可能是簡化的，或者沒有明確地進(jìn)行定義；因而，在著手設(shè)計(jì)新的體系結(jié)構(gòu)框架時(shí)，您必須全面的考慮它們。特定的 IT 環(huán)境可能只有很少的數(shù)據(jù)源類型，因此，消息集成可能會(huì)很簡單。同樣地，應(yīng)用程序連接的作用域可能也很有限。雖然如此，如果希望框架能夠隨著企業(yè)的成長和變化成功地繼續(xù)得以保持，則框架中的集成功能仍然必須由服務(wù)提供，而不是由特定的應(yīng)用程序來完成。部署面向服務(wù)的體系結(jié)構(gòu)的好處面向服務(wù)的體系結(jié)構(gòu)可以基于現(xiàn)有的系統(tǒng)投資來發(fā)展，而不需要徹底重新創(chuàng)建系統(tǒng)。如果組織將開發(fā)力量集中在創(chuàng)建服務(wù)、利用現(xiàn)有的技術(shù)、結(jié)合基于組件的方法來開發(fā)軟件上，將獲得如下幾方面好處： 利用現(xiàn)有資產(chǎn) 這是首要的需求。通過使用適當(dāng)?shù)?SOA 框架并使其可用于整個(gè)企業(yè)，可以將業(yè)務(wù)服務(wù)構(gòu)造成現(xiàn)有組件的集合。使用這種新的服務(wù)只需要知道它的接口和名稱。服務(wù)的內(nèi)部細(xì)節(jié)以及在組成服務(wù)的 組件之間傳送的數(shù)據(jù)的復(fù)雜性都對(duì)外界隱藏了。這種組件的匿名性使組織能夠利用現(xiàn)有的投資，從而可以通過合并構(gòu)建在不同的機(jī)器上、運(yùn)行在不同的操作系統(tǒng)中、用不同的編程語言開發(fā)的組件來創(chuàng)建服務(wù)。遺留系統(tǒng)可以通過 Web 服務(wù)接口來封裝和訪問。 商品化基礎(chǔ)架構(gòu) 在所有不同的企業(yè)應(yīng)用程序之間，基礎(chǔ)架構(gòu)的開發(fā)和部署將變得更加一致?，F(xiàn)有的組件、新開發(fā)的組件和從廠商購買的組件可以合并在一個(gè)定義良好的 SOA 框架內(nèi)。這樣的組件集合將被作為服務(wù)部署在現(xiàn)有的基礎(chǔ)構(gòu)架中，從而使得可以更多地將基礎(chǔ)架構(gòu)作為一種商品化元素來加以考慮 更快的產(chǎn)品上市速度 組織的 Web 服務(wù)庫將成為采用 SOA 框架的組織的核心資產(chǎn)。使用這些 Web 服務(wù)庫來構(gòu)建和部署服務(wù)將顯著地加快產(chǎn)品的上市速度，因?yàn)閷?duì)現(xiàn)有服務(wù)和組件的新的創(chuàng)造性重用縮短了設(shè)計(jì)、開發(fā)、測(cè)試和部署產(chǎn)品的時(shí)間。 減少成本 隨著業(yè)務(wù)需求的發(fā)展和新的需求的引入，通過采用 SOA 框架和服務(wù)庫，為現(xiàn)有的和新的應(yīng)用程序增強(qiáng)和創(chuàng)建新的服務(wù)的成本大大地減少了。同樣，開發(fā)團(tuán)隊(duì)的學(xué)習(xí)難讀也降低了，因?yàn)樗麄兛赡芤呀?jīng)熟悉了現(xiàn)有的組件。 降低風(fēng)險(xiǎn) 重用現(xiàn)有的組件降低了在增強(qiáng)或創(chuàng)建新的業(yè)務(wù)服務(wù)的過程中帶來的風(fēng)險(xiǎn)。如前所述，這也減少了維護(hù)和管理支持服務(wù)的基礎(chǔ)架構(gòu)的風(fēng)險(xiǎn)。 持續(xù)改進(jìn)業(yè)務(wù)過程 SOA 允許清晰地表示流程流，這些流程流通過在特定業(yè)務(wù)服務(wù)中使用的組件的順序來標(biāo)識(shí)。這給商業(yè)用戶提供了監(jiān)視業(yè)務(wù)操作的理想環(huán)境。業(yè)務(wù)建模反映在業(yè)務(wù)服務(wù)中。流程操縱是以一定的模式重組部件（構(gòu)成業(yè)務(wù)服務(wù)的組件）來實(shí)現(xiàn)的。這將進(jìn)一步允許更改流程流，而同時(shí)監(jiān)視產(chǎn)生的結(jié)果，因此促進(jìn)了持續(xù)改進(jìn)。 以流程為中心的體系結(jié)構(gòu) 現(xiàn)有的體系結(jié)構(gòu)模型和實(shí)踐往往是以程序?yàn)橹行牡?。?yīng)用程序是為了程序員的便利而開發(fā)的。通常，流程信息在組件之間傳播。應(yīng)用程序很像一個(gè)黑匣子，沒有粒度可用于外部。重用需要復(fù)制代碼、合并共享庫或繼承對(duì)象。在以流程為中心的體系結(jié)構(gòu)中，應(yīng)用程序是為過程開發(fā)的。流程可以分解成一系列的步驟，每一個(gè)步驟表示一個(gè)業(yè)務(wù)服務(wù)。實(shí)際上，每個(gè)過程服務(wù)或組件功能都相當(dāng)于一個(gè)子應(yīng)用程序。將這些子應(yīng)用程序鏈接在一起可以創(chuàng)建能夠滿足業(yè)務(wù)需求的流程流。這種粒度允許利用和重用整個(gè)組織中的子應(yīng)用程序。未來 新模型，新需求到目前為止，討論集中在滿足現(xiàn)有業(yè)務(wù)的需求、更好地利用和重用資源以及集成現(xiàn)有的和新的應(yīng)用程序的相關(guān)概念上。但是，一個(gè)全新的應(yīng)用程序模型究竟是什么樣的呢？面向服務(wù)的體系結(jié)構(gòu)的觀念是否仍然有意義或者是必不可少的呢？實(shí)際上，兩種新的概念已經(jīng)開始實(shí)現(xiàn)了：網(wǎng)格計(jì)算（Grid Computing）和按需計(jì)算（On-demand Computing）。雖然這兩個(gè)模型是截然不同的，并且是獨(dú)立開發(fā)的，但是它們之間的關(guān)系又是非常的緊密，而每個(gè)模型都使 SOA 的發(fā)展更加勢(shì)在必行。網(wǎng)格計(jì)算深入討論網(wǎng)格計(jì)算超出了本文的范圍，但是有幾個(gè)要點(diǎn)值得提及的。其一，網(wǎng)格計(jì)算不僅是使用擁有大量 MIPS 的應(yīng)用程序來進(jìn)行計(jì)算的解決方案，它還涉及包括硬件、應(yīng)用程序和數(shù)據(jù)在內(nèi)的所有系統(tǒng)資源的虛擬化，因此，在網(wǎng)格中，無論在什么地方，用什么方法，只要需要就可以利用這些資源。其二，前面的章節(jié)已經(jīng)討論了虛擬化數(shù)據(jù)源和將應(yīng)用程序分解成基于組件的服務(wù)的重要性，所以很容易理解在網(wǎng)格環(huán)境中，一個(gè)真正的 SOA 應(yīng)該更好地獲得最多的資源。按需計(jì)算On-demand 也不在我們討論的范圍