這是一系列文章第一部分，這一系列文章旨在幫助您更好的理解面向服務的體系結構（SOA）的價值，制訂出一個實際的計劃來評估您現在的基礎架構，并把它轉變成一個真正的面向服務的體系結構。其目的在于，當您讀完本文時，您將理解為什么聲稱 SOA 是把現有資產帶到未來的最好的平臺，同時也使得迅速而正確地開發未來的程序成為可能。另外，您將對在計劃這樣一次遷移的過程中主要考慮的事項有更好的理解。
開發面向服務的體系結構的情況
在過去的40年里，軟件體系結構試圖處理日益增長的軟件復雜性。但是，復雜性仍在繼續增加，傳統的體系結構好像已經達到了它們處理此類問題的極限。同時，IT 組織的傳統需要仍然繼續存在；比如，需要對新的業務需求進行快速的反應，需要不斷地減少業務中 IT 的成本，以及吸收、集成新的業務伙伴和新的客戶群。作為一個產業，我們經歷了能夠提供完全的分布式處理的多種計算體系結構和能夠運行在任何平臺上的編程語言，從而大大縮短了實現的時間表，我們還經歷了無數的連接性產品，這些產品能夠更快更好地集成應用程序。然而，我們還是沒有找到完全的解決方案。現在，業界提出面向服務的體系結構（SOA）作為軟件體系結構中下一個發展的階段來幫助 IT 組織滿足他們面臨的越來越多的復雜性的挑戰。可是，這種體系結構現實嗎？即使它可以被概括和描述出來，它也能真的被實現嗎？本文的論點就是斷定 SOA 是現實的；在所有天花亂墜的宣傳塵埃落定之后，所有夸大的期望又回到了現實之中，您將發現至少現在 SOA 是 IT 組織可以將其現有的資產帶到未來同時又構建新的應用程序系統最好的基礎。這是一系列文章的第一部分，它旨在幫助您更好地理解面向服務的體系結構（SOA）的價值，并且制訂出一個切實可行的計劃來評估您現有的基礎架構，然后將其遷移到一個真正的面向服務的體系結構。
曾幾何時，現有的 Web 服務技術刺激了關于面向服務的體系結構（SOA）的討論。這個討論并不新鮮；從 CORBA 擴展到在完全不同的異類平臺上應用程序一直到現在，這個概念已經發展10多年了。集成這樣的應用程序的問題不斷出現，通常是因為有那么多不同的（非 CORBA 兼容的）對象模型流行起來；因而，很多架構師和工程師都陷入了解決此類問題的泥淖中，開發一種更健壯的體系結構來實現簡單、快速和安全的系統和應用程序集成的承諾并沒有兌現。然而，問題卻在繼續增加，并且日益復雜?；镜臉I務需求，諸如降低成本、減少開發周期、跨企業集成、企業到企業（B2B）和企業到顧客（B2C）集成、更大的投資回報率（ROI）、創建自適應的和自響應的業務模型等等，使我們不停地尋找更好的解決方案；但是，我們越來越覺得“點解決方案（point solutions）”不能解決這樣的基本問題。在很多情況下，問題在于缺乏一個一致的體系結構框架，在這種體系結構中，可以快速地開發、集成和重用應用程序。更重要的是，我們需要一個這樣的體系結構框架，它能夠裝配組件和服務，以便快速甚至動態地交付應用程序。為什么像 Web 服務這樣的某種技術是好的，但是我們真正需要的是一種不受技術約束的體系結構，有很多文章對此進行了討論。讓我們首先考慮一些基本的問題，這些問題是我們尋求更好的基礎的依據，如何解決這些問題將決定我們工作的成敗。
首要問題 - 復雜性
一些事情總是相同的，特別是 IT 組織所面對的業務問題。公司管理層總是努力爭取更好地利用 IT、獲取更大的投資回報率（ROI）、集成歷史上分離的系統和更快地實現新系統；但是時至今日，事情發生了些許變化?，F在，您遇到的是更復雜的環境。必須重用而不是替換遺留系統，因為考慮到更有限的預算，替換的成本是高昂的。您將發現費用低廉、無處不在的 Internet 訪問使得建立一個全新的業務模型成為可能。公司至少需要評估這個模型，因為競爭使然。合并和收購的增長已經成為家常便飯，因此必須將整個 IT 組織、應用程序和基礎架構集成和融合在一起。在這樣復雜的環境，點解決方案只會使問題進一步惡化，而決不會引導我們走出重林。必須在一個以異構為基礎的環境中開發系統，因為它們必須容納種類繁多的硬件、操作系統、中間件、語言和數據存儲。長達數十年的發展和演化積累起來的影響導致了嚴重的復雜性。面對所有這些對 IT 業務的挑戰，很多 CIO 將應用程序集成作為首要任務也就不是令人驚訝的事情了，如 圖1所示。
考慮一個銀行有一些分離的“地窖”——在銀行內不為其他系統所知的自包含應用程序系統。這些應用程序系統中的第一個可能是優秀的設計，同樣，第二個、第三個等等可能都是。但是每一個都是針對銀行中不同業務的，是單獨投資的孤立項目。因而，例如 獲取賬戶余額的功能在 ATM 系統、分行出納員交付系統、信用卡計分系統都是重復的，即便它們存取相同數據庫中的相同會計數據數據。現在，假設該銀行必須為客戶開發 Internet 服務、在線銀行或在線貸款發放系統以保持競爭力，結果會怎么樣。新系統只會給已經存在的冗余編程問題雪上加霜，除非通過某種方式使得現有的代碼可以重用。
真正的集成難題 - 接口多樣性
同樣考慮 n（n-1）集成問題。任何組織都會碰到某些類型的集成問題；或許是因為一次公司的合并、一個新的商業聯盟或者僅僅是需要互連現有的系統。如果 n 個應用程序系統必須直接互連，那么將會產生 n(n-1) 個連接或接口。在 圖2中，每個箭頭表示一個接口。
因此，如果另一個應用程序系統 A（第 n+1 個）必須集成進來，將需要產生、文檔化、測試和維護 2n 個新的接口。雖然在上圖中，5個應用程序組成的集合需要20個直接接口，但是添加第6個應用程序將需要10個新接口！而更糟的是，必須修改每個已有的應用程序中的代碼以包括進新的接口，因而將發生大量的測試費用。您可以立即為 n 個應用程序找到產生最小接口數目（n）的最優解決方案，只為每個附加的系統添加一個新的接口，但是，通過直接連接是做不到的。
將來會怎樣呢？
在過去的40多年來，軟件開發的實踐經歷了幾個不同的編程模型。而進行的每一次轉變在某種程度上都是為了處理更高級別的軟件復雜性，并且使得可以通過部件、組件或服務來裝配應用程序。近來，Java 技術促成了平臺中立的編程，而 XML 促成了自描述，因而也促成了平臺中立的數據?，F在，Web 服務通過允許應用程序以對象模型中立的方式實現互連，從而克服了另一個障礙。使用簡單的基于 XML 的消息傳遞 Scheme，Java 應用程序能夠調用基于 DCOM、遵循 CORBA 甚至是 COBOL 的應用程序。在新加坡的一臺大型機上的 CICS 或 IMS 事務能夠被一臺在慕尼黑的 Domino 服務器上運行的 Lotus 腳本驅動的基于 COM 的應用程序調用。最好的情況是，調用程序很有可能根本不知道該事務在哪里運行、它是由哪種語言編寫的以及消息的傳輸路徑。只需提出服務請求，然后就會得到答案。
與其任何一個前身相比，Web 服務更有可能成為提供提供有效的、可靠的和可擴展的機器到機器交互的標準，這是幾個技術和文化上必須具備的先決條件適時結合的產物。這些先決條件包括：
- 無處不在的、開放標準的、低成本的網絡基礎架構和技術。它有助于一個分布式環境的形成，這個環境更有利于采用 Web 服務，而不是 CORBA 和 DCE
- 在一個以網絡為中心的領域內達到的接受程度和技術成熟水平。它要求互操作性以實現關鍵的業務目標（比如，分布式協作）
- 一致同意基于 Internet 的開放標準和相關技術是實現低成本互操作性的最好方法。
- 基于網絡的技術（比如 TCP/IP）、工具集（IDE、UML等等）、平臺（比如 J2EE 平臺）和相關的方法（比如 OO、服務等等）的成熟水平。它們提供了簡化松散耦合的、可互操作的、機器到機器的交互（一種比 CORBA 用戶體驗到的高級得多的狀態）所需的基礎架構。
面向服務的體系結構允許設計這樣的軟件系統，它通過發布的可發現的接口為其他的應用程序提供服務，而其中的服務可以通過網絡進行調用。當您用 Web 服務技術來實現面向服務的體系結構時，您是在一個更強大、更靈活的編程模型中創建一種新的構建應用程序的方式，從而降低開發成本、持有成本以及實現風險。SOA 既是體系結構模型，又是編程模型，是一種考慮構建軟件的方式。
然而，還有更重要的機會剛剛出現。其中第一個就是網格計算，網格計算不僅是使用擁有大量 MIPS 的應用程序來進行計算的解決方案，而且還將提供一個框架，通過此框架可以動態地定位、重定位、平衡和管理大量的服務，這樣，無論系統上的負載如何，總可以保證安全地獲取所需的應用程序。而這又明顯地需要按需計算的概念（on-demand computing），按需計算可能是在任何配置下實現的，從簡單的服務器集群到有1024個節點的 SP2 網絡。用戶需要解決問題和適當的用于解決問題的計算資源——不多也不少——并且為實際使用的資源付費。
這些新功能的有效使用將需要重新構造許多現有的應用程序。現有的單一應用程序能夠在這些環境中運行，但沒有以最優的方式來使用可用的資源。這個問題和先前討論過的問題一起可以產生如下結論：必須作出根本的改變——遷移到面向服務的體系結構。
面向服務的體系結構的需求
根據上面討論的問題，可以很明顯地看出，應該開發一種體系結構來滿足所有的需求，這些需求包括：
- 首要的一點就是利用現有的資產?，F有系統很少可以拋棄，它們通常都包含對于企業很有價值的東西。從戰略上講，目標是構造一個新的體系結構來創造所有想要的價值，但是，從戰術上講，必須集成現有系統，以便隨著時間的推移，可以在可管理、漸進式項目中分化或取代它們。
- 支持所有必需的集成類型或“樣式”。這包括：
- 用戶交互——能夠提供單一的、交互式的用戶體驗
- 應用程序連接性——通信層構成了所有體系結構的基礎
- 流程集成——編排應用程序和服務
- 信息集成——聯合和移動企業數據
- 依集成需求而構建——構建和部署新的應用程序和服務。
- 允許漸進式實現和資產遷移——這將支持開發這種體系結構的一個最關鍵的方面：獲得更大的投資回報率（ROI）的能力。數不清的集成項目由于它們的復雜性、成本和不切實際的實現進度安排而失敗。
- 包括一個以標準的組件框架為基礎構建的開發環境，促進更好地重用模塊和系統，允許將遺留資產轉移到這個框架中，并且考慮到新技術的及時實現。
- 允許實現新的計算模型；特別是，新的基于 Portal 的客戶端模型、網格計算和按需計算（on-demand computing）。
面向服務的體系結構——不只是 Web 服務
Web 服務的出現產生了根本的改變，因為很多 Web 服務項目的成功顯示這種技術事實上確實存在，借此您可以實現真正的面向服務的體系結構。它使您又往回走了一步，不僅分析您的應用程序的體系結構，而且還要分析您正設法解決的基本業務問題。從業務的角度來看，它不再是一個技術問題，而是要開發一種應用程序體系結構和框架，可以在其中定義業務問題，還可以以一致的可重復的方式來實現解決方案。
不過，首先必須理解 Web 服務并不等同于 面向服務的體系結構。Web 服務是包括 XML，SOAP，WSDL 和 UDDI 在內的技術的集合，它使您能夠針對特定的消息傳遞和應用程序集成問題構建編程解決方案。隨著時間的推移，您有理由相信這些技術將逐漸成熟并最終為更好、更有效、更健壯的技術所取代，但是，就目前的情況而言，它們可以發揮作用。至少，它們是 SOAs 能夠最終實現這種觀念的證明。那么，面向服務的體系結構實際上是由什么組成的呢？
SOA 只不過是一種體系結構。它不是任何諸如 Web 服務這樣的特定技術的集合；而是超越它們的，在理想的情況下，是完全獨立于它們的。在業務環境中，SOA 的純粹的體系結構定義可能會是這樣的“一種應用程序體系結構，在這種體系結構中，所有功能都定義為獨立的服務，這些服務帶有定義明確的可調用接口，可以以定義好的順序調用這些服務來形成業務流程”。請注意這里的表述：
- 所有功能都定義為服務。這僅僅包括業務功能、由底層功能組成的業務事務和系統服務功能。這將會產生粒度問題，后面我們將對此進行討論。
- 所有的服務都是獨立的。它們就像“黑匣子”一樣運行：外部組件既不知道也不關心它們如何執行它們的功能，而僅僅關心它們是否返回期望的結果。
- 在其最一般的意義上來說，接口是可調用的；也就是說，在體系結構的層面上，它們究竟是本地的（在本系統內）還是遠程的（在直接系統外）、是用什么互連 Scheme 或協議來調用或需要什么樣的基礎架構組件來連接，都是無關緊要的。服務可能是在相同的應用程序中，也可能是在公司內部網內完全不同的系統上的不對稱多處理器的不同地址空間中，還有可能是在用于 B2B 配置的合作伙伴的系統上的應用程序中。
在所有這些表述中，接口是最關鍵的，同時也是調用應用程序關注的焦點。它定義了必需的參數和結果的類型；因而，它定義了服務的類型，而不是實現服務的技術。系統的責任是實現和管理服務的調用，而不是調用應用程序。這使得可以認識到兩個關鍵的特征：其一，服務是真正獨立的；其二，它們是可以管理的。管理包括許多功能，其中有：
- 安全性——請求的授權、加密和解密（在需要時）、確認等等
- 部署——出于性能、可用性冗余或其他方面的原因，允許服務在網絡內重新部署（移動）
- 日志——用于審核、測量等等
- 動態重新路由——用于故障排除（fail over）或負載平衡
- 維護——管理服務的新版本
總結
在第一部分中，您已經簡要地分析了一些導致需要考慮 SOA 的問題，這些需求寄希望于新的體系結構。而在第二部分中，我們將研究服務的類型，構造一個基于服務的組件的應用程序框架和一些將來的計算環境，這些環境將使得 SOA 的開發更加勢在必行。