SOA 核心技術及應用，第 1 章

1.1 公司 IT 部門面臨的困境

SOA 來了，可是其究竟為 IT 世界帶來了什麼，或者說，解決了企業的什麼問題？讓我們先看一下當前企業 IT 構架所面臨的困境。

從企業的 IT 戰略角度而言，經過多年的發展，各個企業都已經在不同業務支撐領域架構了一系列的 IT 系統，甚至是一個完整的企業架構（Enterprise Architecture），或者是已經完成了部門級的垂直整合。可是，在日新月異的商業環境下，產品的生命週期變得越來越短，客戶的需求也在隨時變化，新的業務模式持續地醞釀生成。

新的業務模式需要新的業務流程來支撐，要求更有效率的合作，這不僅僅發生在同一個垂直的部門內部，對跨部門的業務合作和整合的需求被也提到議事日程上。有效的部門間合作，或者企業間的合作，能夠滿足客戶需求並響應外界變化的靈活業務流程，是現代企業競爭力的根本。這不僅僅是一個企業管理和文化能解決的問題，也對企業的 IT 系統提出了進一步的需求。這些需求為企業 IT 架構和策略帶來巨大的壓力——如何能達到真正的隨需應變？如何提高 IT 系統的投資回報（Return On Investment，ROI）？如何重用已有的技術和業務資源以滿足新的需求？

另外一個不容忽視的商業趨勢是：隨著行業發展越來越專精，越來越多的專業服務被提供出來。比如說，自古以來飯店總是要僱傭一些洗碗工清潔堆積如山的碗筷。可是現在出現了一種專業服務，回收用過的碗筷，清洗、消毒，然後包裝好派送回各個飯店。於是，飯店便無需僱傭專門的洗碗工，也無需使用一次性筷子，還可以向消費者收取碗筷清潔消毒的費用——相當於原來的一次性筷子的費用，所以消費者也不會抱怨。這是一個標準的三贏場景：

飯店省去了僱傭洗碗工的成本；

消費者避免使用浪費資源並可能有衛生問題的一次性筷子；

洗碗服務的提供者獲得了利潤。

其中的理念是，飯館要正常經營，清潔碗具是每個餐館不得不做的事。但大家都知道，洗碗並不是餐館最擅長的事，餐館最擅長的事是烹製美食，而專業的洗碗店最擅長洗碗。為什麼不只做自己最擅長的事，把自己不太擅長的事外包給最擅長做這些事的公司，強強聯手，給消費者提供更好的服務呢？

反觀 IT 業界，同樣的場景也會發生。企業可以使用第三方提供的更好服務來支援自身業務流程實現的需要，而不用事必躬親，這樣可以大大節省 IT 開發和維護的成本。在圖 1-1 中就是這樣一個典型場景，其中企業內部資源包括部門（Division）資源和共享服務（Shared Service）資源兩部分。在客戶（Customer）使用這一業務流程時，企業業務流程不僅僅是使用自己的既有服務，還整合了供應商（Supplier）的服務，進而供應商又整合了一些外包商（Outsourced）的服務。在這樣一個場景中，供應商和外包商提供了流程中的一些專業服務使得業務流程更加敏捷有效，猶如上面例子中的洗碗店一樣。實際上，這就是 Web 服務技術產生的一個業務背景。在這樣一個商業趨勢下，如何整合企業外部資源變成了一個很重要的並亟待解決的問題。

圖 1-1 服務整合

從另一個方面，從技術趨勢和 IT 架構角度而言，從傳統的 C/S（客戶端 / 伺服器，Client/Server）架構，到 90 年代興起的 B/S（瀏覽器 / 伺服器，Browser/Server）架構，到現在大家關注的基於服務的架構，IT 技術經過了不同的時代，在不斷更新進步。可以說，電子製造業的摩爾定律同樣適用於軟體行業。相應地，具體的程式設計技術也在進化和演變，從機器語言到彙編，到以 C 為代表的程式導向程式設計，到以 C++/Java 為代表的物件導向程式設計，進而到 J2EE 的模組化分散式企業級程式設計，可以發現程式設計的粒度逐漸變大。計算機的計算能力越來越強，計算時間的成本不斷降低，程式設計師時間的成本不斷提高。總而言之，隨著軟體程式的規模越來越大，底層架構和技術能夠處理的功能愈發廣泛，層次性的封裝越發普遍，使得程式設計師可以更加貼近業務邏輯進行開發；大大節約了程式設計師的寶貴時間；這是一個趨勢。

業務模式的變遷和技術趨勢的發展，使得企業的 IT 部門需要認真思考，選擇一個符合公司規劃發展的 IT 戰略，保護現有投資，低風險、高回報，並落實到一個能夠和業務真正對齊的技術策略和模型。這也是需要探討和解答的問題。

.2 決策者的決策——部署 SOA

1.2.1 什麼是 SOA

上節中提到了對 IT 戰略架構的各種需求，其核心是業務快速變化和隨需應變。那麼，怎麼做才能滿足這些需求？如何才能真正解決這些問題？我們的答案是實施 SOA（面向服務的架構，Service Oriented Architecture）。

什麼是 SOA？“Service Oriented Architecture，”顧名思義，面向服務的架構，或者說，以服務為基礎搭建的企業 IT 架構。SOA 是一個完整的軟體系統建構體系，包括執行環境、程式設計模型、架構風格和相關的方法論等。其核心是服務，並涵蓋服務的整個生命週期，建模 - 開發 - 裝配 - 執行 - 管理。SOA 的核心理念是業務驅動，採用鬆耦合的、靈活的體系架構來滿足隨需應變的業務需求。

服務是 SOA 的核心詞。從技術概念而言，服務與模組或者功能的概念類似，是用於封裝特定功能的一個實體。但是，值得注意的是，服務的核心理念是業務，服務定義了一個與業務功能或者業務資料相關的介面，以及約束這個介面的契約，是粗粒度的。服務是中立的，不依賴於特定的技術和平臺。服務的註冊、獲取可以通過服務註冊庫管理。多個服務可以被組裝成一個業務流程，完成一個特定的業務功能。由此可見，服務是可重用的，一個定義良好的服務可以被用於組裝多個業務流程。這也是 SOA 和服務被比喻成樂高積木的原因。進而言之，如果系統架構師和業務人員聯手，是可以用這些“樂高積木”（服務）搭建出一艘航空母艦——已組裝好的服務是可以被髮布為一個新的服務，這就是服務巢狀封裝的特性。

下圖表明瞭 SOA 的概念架構模型。可見 SOA 架構是一個分層的結構，從最底層的功能性服務，到原子服務和服務構件，到頂層的業務流程服務，目的是最大限度地封裝不同的服務，從而達到複用的目的。無論哪一個層次，其核心都是服務——簡單的和複雜的。一個複雜的服務元件是由不同的原子服務組成，用於提供業務流程所需的功能。

圖 1-2 SOA 的概念架構模式

另一個不得不提的 SOA 概念是企業服務匯流排（Enterprise Service Bus, ESB）。將服務組裝成業務流程是目標，但是應該如何實現？點到點的連線是一個方式，可是這種方式增加了系統的複雜度，並降低了服務的可重用性。為了實現真正的 SOA，我們需要一箇中間層，來完成服務互動、組裝、管理的功能。這就是 ESB 產生的緣由。ESB 採用的是匯流排的概念，支援服務的即插即用，以訊息流轉為溝通方式，以標準為基礎，可以跨平臺、跨技術（如圖 1-3 所示）。形象地來講，ESB 像一條流動的河流，承載著不同的船隻（資料）到達相應的碼頭。

圖 1-3 SOA 計算環境的組成部分

這樣一個以服務為核心的體系架構可以提供鬆耦合、異構的企業級計算環境。這是企業 IT 架構的設計思想的一個革新——以業務為導向的設計，而並非傳統的技術架構導向。這一 SOA 架構直接的好處是：企業級整合變得更加得心應手，無論是在一個垂直系統內部，還是跨部門的整合，甚至是跨企業的行業整合。進而，可以重用定義好的服務，無論是包裝已有系統功能，還是新開發的業務功能，甚至是採用合作伙伴所提供的服務。這是一件很好的事情，不僅節約了企業內部的投資，還可以創收——向外部的客戶和合作夥伴提供服務！理念的變革是，由自給自足變為開放，成為服務的提供者和整合者。

不僅如此，SOA 和服務的理念使企業的成長不再受到 IT 架構的制約——業務流程可標準化、可整合。

眾所周知，中華餐飲的歷史源遠流長，美食無數。可是中式快餐很難形成如肯德基或麥當勞那樣的大型連鎖店，為什麼呢？先看一下中餐的烹飪過程：選材備料，主廚掌勺。可是，每一個大師傅烹飪的過程都有所不同，火候、配料是關鍵，所以菜品的口味也不一樣。即使同一道菜，同一品牌，不同的分店，味道也會有所不同。反觀西式快餐，材料統一配送，烹飪工具統一，流程規範，做出來的東西自然一樣。當有菜品有更新時，只要把原料配送好，操作流程培訓好，就可以在全國甚至是全世界的分店裡同時推出這道菜品，迅捷有效。

現今，我們的軟體行業同中餐類似，關鍵看主廚的功力，架構師是否能設計出優雅的架構，程式設計師能否寫出健壯的程式，是一個應用成功的關鍵。可是這又是多麼的可遇而不可求。由此可見，建構一個靈活的可擴充套件的大型解決方案，降低維護成本，標準化是成功之道，服務化則是必由之路。

1.2.2 SOA 實施的主要困難

前面描繪了一幅美麗的圖畫：一切皆服務，服務可組合。可是，有人會問，事情真的有那麼美好嗎？這條路到底行不行得通，好不好走？

大家可以回想一下，在 SOA 的概念被旗幟鮮明地提出後，花了幾年時間討論到底什麼是 SOA，什麼是一個好的 SOA 架構，並試圖找出一個可行的技術路線。如今大家的關注點是 SOA 如何著陸，如何真正部署一個 SOA 架構。在先行者的實踐中，大家看到了一些設計和實施的關鍵點和困難點，其中包括：

SOA 不僅僅是 IT 技術思想，也是企業管理思想的革新：一切以業務流程為基礎，而不是部門職能。SOA 需要全域性性的思考，垂直部門不再是一個封閉的組織，企業也不再封閉，需要採用服務的方式進行開放整合。這一觀念需要在企業管理層達成共識，否則可能成為 SOA 成功實施的阻礙。

如何梳理出業務流程，並進行相應的服務劃分？這是一個成功的 SOA 實施的關鍵，需要縱觀企業業務的全域性思考和分析，並且需要業務和技術人員的共同參與。

對大多數企業而言，SOA 可能並非一場革命，而是一種轉變，現有的系統也要參與其中，使現有資產合理重用是一個重要的考慮。

技術架構的選擇。會在下面詳細地闡述。

可見，SOA 並非一蹴可就的，需要全域性的思考和準備。但是 SOA 的實施是可以漸進式的，既有系統可以逐步改造，新的服務可以按需新增，這也是以服務為基礎的架構的優點。從小處入手，從長遠考慮，這些投資的回報是十分客觀的。

圖 1-4 IT 與業務並行發展
 

1.3 SOA 的技術抉擇

在前面的章節裡，已經講解了什麼是 SOA 和為什麼要部署 SOA（當然，本書的論述是比較提綱挈領，讀者可以在《SOA 原理穃 u26041? 法穃 u23454? 踐》中得到更為詳盡的論述）。在本書中試圖講解的是如何部署和實施 SOA，以及實施 SOA 所需要的技術。

1.3.1 相關技術概覽

在深入理解了 SOA 的理念和架構基礎上，可以看到 SOA 的技術必然建立在標準之上——只有做到了“書同文，車同軌”，才能夠進行真正意義上的業務整合。在此基礎上，有服務執行環境、企業服務匯流排（ESB）、服務註冊和管理工具、流程引擎等 SOA 計算環境所需要的主要元件。同時，還會有業務活動監控（Business Activity Monitoring，BAM）和業務績效管理（Business Performance Management，BPM）等方面。

SOA 的設計理念在於將企業的 IT 架構建立在一系列執行業務功能的服務基礎上，IT 資產通過服務的形式得到重用。業務模式和流程也可以通過服務的重新組合變得更加靈活。可見，要搭建一個靈活多變的架構，其中的幾個關鍵的技術抉擇在於：

服務

搭建大廈的磚石，建造航空母艦的“樂高積木”，需要謹慎的選擇。服務需要是標準化的，是可以自描述的，是可以組裝的，並能夠隔離業務功能和具體實現。

資料 / 訊息模型

大廈電路中的電流和水管中流動的水流，有了這些資源，一個現代化的大廈才能夠真正“活”起來。資料就是客戶的“錢”，是服務的目的——準確、迅捷地傳送資料。因此，一個好的資料模型可以事半功倍。

服務編排和流程引擎

大廈的設計圖紙，用來將已有的服務組裝起來定義真正的業務流程。敏捷是對服務編排的一個重要要求。服務編排同時要提供相應的事務管理、流程狀態管理、出錯處理等支援功能。

以上的三個方面被稱為 SOA 程式設計模式的“鐵三角”。

圖 1-5 SOA 程式設計模式的鐵三角

1.3.2 服務

作為構建 SOA 的一個基礎元件，服務具有下面一些特徵：

服務是可以獨立操作的。每一個服務都能夠提供相應的操作，能夠很容易地被獨立呼叫，其執行並不依賴於架構中的其他元件和服務。操作是通過標準方式封裝和釋出的。

服務是自描述的。其使用標準的描述格式定義了服務提供的操作和訊息格式，無論呼叫者和被呼叫者都無需關心其他資訊，如地址、實現技術等。

服務是鬆耦合和異構的。服務的使用者和提供者可以是分佈部署的，可以位於不同的系統平臺上，可以使用不同的技術實現。

服務是可組合的。使用相應的服務組裝技術，例如流程編排技術，可以將多個簡單的服務組裝成一個更加複雜的服務。這一過程是可遞迴的。這一特性極大地提高了服務的靈活度和計算能力。

服務是動態的。已釋出的服務是可以被動態發現和繫結。

服務是標準和開放的。只有在標準的基礎上，企業中不同部門或者不同供應商的服務才能夠動態地組織到一起提供業務流程。供應商的獨立性和互通性是服務的目標。這樣才能真正實現理想的“天下大同”。

服務可以包裝已有的應用或元件。這一特性使得服務的領域變得更加廣泛，並且可以使現有資產可被重用，保護已有 IT 投資。

服務是有質量保障（QoS）的。

一個描述服務的概念模型是：

圖 1-6 服務的概念模型

可見，服務是可以自描述並獨立註冊釋出的。在一個服務請求者需要使用某個特定業務功能的服務時，可以先在服務管理者，即服務註冊中心中發現符合要求的服務——可能得到一個服務列表，因為不同的供應商會提供同一服務（這也是一種競爭）。服務請求者可以根據需要決定使用哪一個服務，也就是服務繫結，然後就理所應當地使用選定的服務了。

讀到這裡，讀者必然會想到 Web 服務（Web Services）。Web 服務是一個既有的成熟服務技術標準，甚至很多人在提到 SOA 時就會將其自然等同於 Web 服務及其相應的架構。的確，從歷史而言，SOA 設計理念的確是在 Web 服務技術產生和發展之後才逐漸形成的，也確實借鑑了 Web 服務技術的概念和開發模式，但是 SOA 的範疇要更加寬泛，解決更加深入的問題，並非僅僅是技術領域（見上文）。由此可見，Web 服務理所當然是 SOA 服務實現技術的一個選擇，但並非是唯一的選擇。

當前，在業界逐漸得到廣泛認可的一個服務封裝技術是服務元件架構（Service Component Architecture，SCA）。SCA 是一個跟實現語言無關的服務元件程式設計模型，可以很好地處理服務網路的建構，因此提供了基於 SOA 簡化開發的解決方案。SCA 規範的開發和釋出由 Open SOA（Open Service Oriented Architecture，http://www.osoa.org）組織負責。OSOA 組織在世界範圍內有廣泛的支持者，其中不乏 IBM、BEA、Oracle、SAP、Siebel、Sybase 和 Xcalia 等著名廠商。

最初的 SCA 規範在 2004 由 IBM 和 BEA 共同釋出。在 2007 年，SCA 規範終於結束了其孵化期，由 18 家處於 SOA 技術領先地位的廠商正式提交給 OASIS（Organization for the Advancement of Structured Information Standards）組織進入標準化過程，將和其姊妹規範 SDO 一同架構 SOA 的標準程式設計模型。

SCA 的主要特點如下：

SCA 是用於建構服務的，是鬆耦合的。

SCA 是一個跟實現語言無關的元件程式設計模型。SCA 提供了統一的呼叫方式，可以把不同的服務型別，比如 POJO、EJB、BPEL、JMS、Web 服務等都通過統一的介面來封裝呼叫。這使得整合已有的異構系統成為可能。

SCA 還支援不同的通訊協議，如 Webservices、JMS、Rest、JSON/RPC 等。

SCA 隔離了業務邏輯和具體技術實現。這使得開發者能更集中於業務邏輯而非技術細節，也極大地提高了業務邏輯的靈活度——可以採用不同的服務實現而無需改變業務邏輯。

SCA 提供了許多面向企業計算的 QoS 能力。

圖 1-7 SCA 結構和組裝

SCA 的這些特性使得企業應用具有良好的分層架構，能夠很好地分離業務邏輯和技術邏輯，使應用易於構建、易於部署、易於變更。這些特性，恰恰是 SOA 中服務所需要的。

鑑於讀者對 Web 服務的概念和技術已經耳熟能詳，本書中就不再針對這一技術進行論述，而試圖為讀者提供另外一種服務實現的技術選擇：SCA。在本書下面的第二部分（第 2 章—第 7 章），會詳盡地介紹 SCA 的起源，技術思想，具體規範，以及實際用例。

1.3.3 資料和訊息模型

在 SOA 的世界裡，訊息意味著企業的效益，因為其包含的業務資料代表實際發生的交易，資料的丟失等同於是現金的流失。從這個角度而言，一個完備的、豐富的訊息資料模型是必需的。

同 SOA 服務建構技術相輔相成，不同的服務有不同的訊息定義方式。比如說，Web 服務採用 SOAP 訊息作為其資料表現。相應地，和 SCA 伴生的技術是服務資料物件（Service Data Object,SDO）。SDO 以物件為中心的，層次樹型資料模型，是一種最貼近業務表現的方式。

SDO 基於離線資料圖的設計理念如圖 1-8 所示。資料圖是一組樹型結構或者圖型結構的資料物件。離線的訪問方式是指客戶端從資料來源提取並構建資料圖，然後在應用中運算元據圖，並在變更摘要（Change Summary）中記錄相應的資料操作，在動作結束後由資料訪問服務（Data Access Service）批量地將相應的改變反映回資料來源，其中資料來源可以是異構的，並不僅僅限於關聯式資料庫。

圖 1-8 SDO 基本結構

SDO 的資料表現形式基於資料物件（Data Object）和資料圖（Data Graph）的概念，其封裝形式和 Java 類和 XML 有水到渠成的對映關係。同時，SDO 提供了豐富的資料操作介面——動態介面和靜態介面，還可以用 XPath 來直接訪問相應的資料物件屬性。

SDO 所解決的另外一個問題是異構資料的相容性，提出了一個簡單並統一的模式供服務處理其相關的資料。開發人員可以用 SDO 統一其資料訪問和處理模式，即使這些資料來源於異構資料來源——關聯式資料庫、XML 資料、Web 服務或者是企業資訊系統。

SDO 是 SCA 的姊妹標準，同樣由 Open SOA（Open Service Oriented Architecture，www.osoa.org）組織負責。SDO 規範 2.0 版本於 2006 年底釋出，現已提交 OASIS 標準化組織。在本書的第三部分（第 8 章—第 13 章）中，會針對這一技術進行詳盡的介紹，包括技術起源和思想，具體規範和詳盡例項。

1.3.4 服務編排和流程整合

SOA 程式設計模型的第三個方面是服務編排。誠然，SCA 規範中已經包含了服務元件和組裝的概念，但是其並非一個嚴格意義上的服務編排。在考慮業務流程的編排時，希望流程是視覺化的、可定製的、靈活的，並且是可管理的。服務猶如一個個音符，而精心編排的樂譜將其串成優美樂曲。

遠在 SOA 概念提出之前，就已經有 Web 服務技術，與之關聯的服務編排技術是 Business Process Execution Language for Web Services（BPEL4WS）。2002 年 7 月，IBM、微軟、BEA 聯手提交了這一規範，奠定了以 Web 服務和 XML 為基礎的業務流程規範。此後，BPEL 規範被提交給 OASIS 組織，並更名為 WS-BPEL（在下文中簡稱為 BPEL）。如今，BPEL 已經得到業界的廣泛認可。

一個服務編排模型需要滿足 SOA 鬆耦合和異構的要求，並且需要是敏捷的。反觀 BPEL，具有下面的一些特點：

基於服務。BPEL 在對多個服務進行排程與協調，本身只定義業務流程相關的邏輯，而具體的功能則由其所呼叫的服務來實現，與 BPEL 無關。BPEL 從規範的定義上就自然而然地支援 Web 服務，但並不僅僅限於 Web 服務，也可以支援 SCA 所定義的服務。

巢狀性。相應地，由服務編排而成的 BPEL 業務流程可以被封裝為一個新的服務，提供更加複雜的業務功能（回顧圖 1-2 中的業務流程服務）。這一點充分體現了服務的可巢狀性。

鬆耦合性。BPEL 定義本身只需指定相應的介面即可，不需要指定實現該介面的服務。BPEL 致力於業務邏輯的表現，而相應的實現服務完全可以在部署甚至執行時確定。同時，流程與所呼叫的服務之間以非同步的 XML 文件形式傳遞訊息，不直接與服務的實現打交道。因此 BPEL 流程和所呼叫的服務之間是鬆耦合的，他們可以獨立地進行替換或修改，而不對另一方產生影響。

服務質量、交易和生命週期的管理。BPEL 並不僅僅是簡單的服務裝配，還支援長時間的流程定義，以及有狀態的互動，並且提供了相應的失敗處理和補償機制。不僅如此，還有相應的服務質量（QoS，Quality of Service）和事務處理機制等。

高度的敏捷性。正是由於 BPEL 具有高度的鬆耦合性和可重用性，才具有敏捷性的特點。

圖 1-9 SOA 的標準協議棧

在 SOA 計算環境的協議棧中，業務流程位於協議的頂端，BPEL 是它的具體表現形式。

BPEL 是服務編排的核心技術，也是具體業務流程的表現。在本書的第三部分（第 14 章—第 17 章）中，會對這一技術進行詳盡的介紹。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-594431/，如需轉載，請註明出處，否則將追究法律責任。