IBM介紹遷移到面向服務的體系結構的方法.doc

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