iweroulsdjf

由April進行SOA技術(shù)文章的篩選和轉(zhuǎn)載。
篩選了50篇關(guān)于SOA技術(shù)方面的文章，有助于加強團隊初期對SOA技術(shù)的熟悉。以最快的速度了解SOA，在此基礎(chǔ)上發(fā)揮想象力，創(chuàng)造出一個合理可行的解決方案。

團隊的初期分工：
????? 組長:Merlin.
??????組員:April,Tory
??????
Merlin和Tory大量閱讀技術(shù)文檔，研究提出解決方案。April負責blog的建設(shè)。

面向服務(wù)的體系結(jié)構(gòu)（Service Oriented Architecture），更多的時候被稱作 SOA，最近有很多關(guān)于它的報道。但是它到底是什么，又能夠為您做些什么呢？在該采訪中，IBM development 的三名成員將就 SOA 以及 IBM 和 Lotus 產(chǎn)品如何與 SOA 概念相結(jié)合進行探討。

面向服務(wù)的體系結(jié)構(gòu)（SOA） 為對業(yè)務(wù)應(yīng)用程序進行智能且有效的設(shè)計、開發(fā)、部署和管理提供了一個廣闊的基礎(chǔ)設(shè)施。為了幫助更好地理解 SOA 是如何影響 Lotus 和 IBM Workplace 產(chǎn)品和技術(shù)的，我們訪問了 Lotus 和 IBM Workplace 開發(fā)團隊的幾名成員，并探討了 SOA 為您現(xiàn)實的工作帶來了什么。

請簡單談一下你們在 IBM 的職責。
Fernando Salazar：我是 IBM Workplace 團隊的高級技術(shù)人員。負責 Workplace Server 組件的整體體系結(jié)構(gòu)和內(nèi)容。

Robert Duffner：我是 WebSphere Portal 和 Workplace 產(chǎn)品的產(chǎn)品經(jīng)理。還負責在 Workplace、Portal 和 Collaboration (WPLC) 產(chǎn)品部門中圍繞 SOA 策略提供幫助信息。

Doug Wilson：我是 WPLC 部門的主要技術(shù)負責人，還是體系結(jié)構(gòu)指導(dǎo)委員會和顧問組的成員。我的工作是確?？?WPLC 產(chǎn)品的產(chǎn)品空間體系結(jié)構(gòu)的一致性，并保證它們適合于整體 Software Group 體系結(jié)構(gòu)策略。

概括地說，什么是 SOA？
Robert：SOA（面向服務(wù)的體系結(jié)構(gòu)）并非新的思想。SOA 一直主要是關(guān)于如何正確地進行構(gòu)建，如何創(chuàng)建一種體系結(jié)構(gòu)藍圖，該體系結(jié)構(gòu)藍圖允許進行可重用的構(gòu)建，允許以更加松散耦合的方式工作，例如您構(gòu)建了這樣一個體系結(jié)構(gòu)并要進行修改，那么無需打破原有設(shè)計。還有，如何在流模式下集成異構(gòu)的 IT 系統(tǒng)。SOA 是真正支持使用可重用的組件或服務(wù)裝配業(yè)務(wù)流程的體系結(jié)構(gòu)，這些組件或服務(wù)獨立于應(yīng)用程序和它們運行的平臺。

這里的關(guān)鍵點是服務(wù)為真正可重用的構(gòu)建塊。這些概念確實不是新的了。我認為現(xiàn)在很多供應(yīng)商創(chuàng)建的產(chǎn)品開始支持 SOA 標準，比如 Web 服務(wù)這樣的產(chǎn)品，使 SOA 在很多 CIO 的心中占據(jù)了優(yōu)先和中心地位。大型跨平臺供應(yīng)商，如 IBM、Microsoft、Oracle 以及 SAP 都開始以能吸引客戶的方式支持這些標準 —— 因為支持更多的標準能幫助客戶降低風險，很多標準都是這樣產(chǎn)生的。在這種形勢下構(gòu)建 SOA 的能力開始變得很有前景，這可能是今天的 SOA 最激動人心的地方。在這一過程中標準起到了很重要的作用。

Doug：我還要強調(diào) SOA 包括面向服務(wù)的體系結(jié)構(gòu)、對業(yè)務(wù)結(jié)構(gòu)以及支持業(yè)務(wù)的 IT 系統(tǒng)進行推理的方法。事實上，SOA 是從頂層開始的，通過分析業(yè)務(wù)是如何運行的，以及如何把支持業(yè)務(wù)的業(yè)務(wù)流程分割為基本步驟 —— 人為執(zhí)行的或者是通過多個自動片斷執(zhí)行的任務(wù)。SOA 的強大之處在于它給出了一種一致的方法，用于推理業(yè)務(wù)的結(jié)構(gòu)，以及推理支持該業(yè)務(wù)的 IT 基礎(chǔ)設(shè)施和組織。

Fernando：幫助推動 SOA 的新事物是企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）這個概念。我們能夠通過標準定義所有的服務(wù)，這樣非常棒。但是，ESB 允許我們安排這些服務(wù)，并以滿足應(yīng)用程序需要的方式同步或異步地調(diào)用它們。接口和松散耦合是兩個由來已久的軟件工程概念，但是我認為企業(yè)服務(wù)總線是使這個概念成為可能的關(guān)鍵因素。企業(yè)服務(wù)總線是促使 SOA 產(chǎn)生的因素之一。

你們提到 SOA 不是一個新事物，但是看起來直到最近人們才開始關(guān)注它。關(guān)注背后的主要原因是什么呢？
Doug：我認為在該行業(yè)中有兩個關(guān)鍵的變化，為考慮如何構(gòu)造 SOA 重新注入了力量。Web 服務(wù)的描述功能與使用無處不在的互聯(lián)網(wǎng)的 IT 系統(tǒng)相組合，可能是過去兩年中許多 SOA 的思想重新熱起來的驅(qū)動因素。什么都比不上公眾的說服力，以及無處不在的技術(shù)解決方案，推動著前進的步伐。在過去，一些系統(tǒng)間互連的其他方式要通過專有的或是難于使用的協(xié)議，像 CORBA 和 IIOP，結(jié)果就我們需要取得一個單一的、通用的中間件基礎(chǔ)設(shè)施 —— 具體內(nèi)容要與規(guī)則保持高度的一致。Web 服務(wù)規(guī)范使人們只需很少的 IT 投資就能夠解決這個問題。

哪類行業(yè)和公司是 SOA 的主要受益者？
Doug：這是一個很難回答的問題。推動 SOA 實施的一個因素是通過很低的投資，就能夠為小型企業(yè)提供技術(shù)。我認為這在很大程度上能夠促使人們接受它，因為您不會被限制在某個范圍，就是說不是大型企業(yè)或小型企業(yè)的問題。問題是 —— 也是機會 —— 任何規(guī)模的企業(yè)都可以使用 SOA 策略。其中的一個驅(qū)動因素是在大多數(shù)情況下，小型企業(yè)都是較大型企業(yè)的服務(wù)提供者。例如，如果我想外包運輸業(yè)務(wù)，或者是外包客戶滿意度跟蹤，或者是一個較大業(yè)務(wù)流程中的幾個小型業(yè)務(wù)，那么我需要一個 IT 結(jié)構(gòu)允許我將行為或服務(wù)委托給小型企業(yè)?？赡茉趯嵤┑某跫夒A段，大型企業(yè)將是服務(wù)的中心，但是許多小型企業(yè)將作為較大型企業(yè)的服務(wù)提供者形式出現(xiàn)。

Robert：這一點十分好。顯然，能夠從 SOA 得到最大受益的組織，很可能是那些具有處于較高穩(wěn)定狀態(tài)的 IT 基礎(chǔ)設(shè)施的組織。其中所有遺留下來的程序都不能進行及時修改，它們無法支持業(yè)務(wù)需求的變化。通常，您能夠看到許多這樣的組織可能支付這樣的開銷。一些即將成為行業(yè)先鋒的公司正是那些具有投資和 IT 的公司，并且在這些公司中 IT 的使用比在其他公司中占有更大的比重。但是 SOA，在這一方面，能夠從根本上轉(zhuǎn)變 IT 基礎(chǔ)設(shè)施，使其從業(yè)務(wù)的阻礙轉(zhuǎn)變?yōu)闃I(yè)務(wù)變化的推動力。所以，如果您看一下像金融服務(wù)和銀行之類的組織，它們通常都具有非常尖端的組織。

我還注意到，如果您稍微關(guān)注一下，就能夠發(fā)現(xiàn)一些組織還建立了體系結(jié)構(gòu)控制部門，或者是跨學(xué)科和跨區(qū)域的群組，他們實際上是整體地研究整個組織的 IT 基礎(chǔ)設(shè)施和體系結(jié)構(gòu)。這預(yù)示著在未來 SOA 將取得成功。

除了 IT 方面外，SOA 會以哪些其他方式影響公司經(jīng)營業(yè)務(wù)的方式？
Doug：我認為事實上恰恰相反。業(yè)務(wù)方式的自我演化正迫使 IT 部門作出響應(yīng)，SOA 就是由此而產(chǎn)生的強大支持模型。業(yè)務(wù)在不斷地合并、放棄和重構(gòu)，以及自我重組，并對 IT 部門跟上其發(fā)展提出了實質(zhì)性的挑戰(zhàn)。如果 IT 和企業(yè)能夠為業(yè)務(wù)結(jié)構(gòu)的推理形成統(tǒng)一的模型，并因此得到相應(yīng)的 IT 結(jié)構(gòu)，那么這將成為 IT 部門滿足它們業(yè)務(wù)需要的強有力的推動力。

Robert：看一下很多關(guān)于 IBM 幫助開始隨需應(yīng)變業(yè)務(wù)的討論，當我們考慮一個隨需應(yīng)變的業(yè)務(wù)時，我們認為企業(yè)需要跨他們的組織以及他們所需的全部合作伙伴、供應(yīng)商和客戶，對業(yè)務(wù)過程進行集成。但是更重要的是，他們能夠做出非常靈活的響應(yīng)，并且能夠隨客戶的需求、市場機會或其他可能出現(xiàn)的任何類型的機會和威脅做出響應(yīng)。從這一觀點出發(fā)，只是一味地花費、花費、花費和不進行調(diào)整的日子結(jié)束了。IT 和業(yè)務(wù)線正在以過去未曾有的方式結(jié)合到了一起。你不再為所有這些 IT 系統(tǒng)持續(xù)地花費資金，并且還得不到最初進行這些投資時所預(yù)期的回報。有了 IT 和業(yè)務(wù)線的密切合作，將幫助推動使用 SOA，幫助實現(xiàn)隨需應(yīng)變的業(yè)務(wù)這一目標。

Fernando：我們描述的過程部分不僅采用了技術(shù)、標準和基礎(chǔ)設(shè)施；并且還從工程的角度進行了分析，以確定什么是您所依靠的（我們將其稱作 “原始的”）業(yè)務(wù)功能。原始的業(yè)務(wù)功能可能是像運輸產(chǎn)品、重新進貨報表或支付帳單這樣的功能。當將它們作為服務(wù)進行嵌入時，就能夠分離調(diào)用這些服務(wù)的邏輯，并且可以放到一個不同的位置。這是您真正獲得適應(yīng)性的地方 —— 如果這樣做了，現(xiàn)在就可以用新的算法管理庫存或運送包裹。邏輯是從原始的服務(wù)中分離出來的。當這樣做時，就能夠開始從適應(yīng)性中獲益。

SOA 將會成為新的 IBM 特性和產(chǎn)品嗎？
Doug：當然。最近，我們宣布了整個產(chǎn)品系列，目的非常明確，是要在我們的客戶中推動 SOA 實施。關(guān)于我們在世界范圍內(nèi)推動 SOA 這一事件，各種論壇上都有具體和詳細的報導(dǎo)。

Robert：SOA 確實觸及到了我們所有的軟件生產(chǎn)線。請您看一下我們是如何定義 SOA 參考體系結(jié)構(gòu)的，其中涉及建模、部署、變更和管理，我們有幫助實施 SOA 整個周期的產(chǎn)品。SOA 最大的優(yōu)點是，公司不必一次性地完全加以實施；這里有很多的入口點，他們能夠從這些入口點開始。這要依據(jù)組織正在做什么。一些組織可能非常依賴集成解決方案，例如消息傳遞。這些客戶會問 “如何將系統(tǒng)集成到一起？如何確保可靠性和保證消息的傳遞？”。通常，當考慮高速消息傳遞和消息傳遞框架時，您將想到企業(yè)服務(wù)總線。我們有一個整套的產(chǎn)品線，主要為 WebSphere 品牌，我們還有已經(jīng)宣布的帶有業(yè)務(wù)集成的新產(chǎn)品，這些新產(chǎn)品還具有一些其他功能以支持 SOA 的核心。我們的其他產(chǎn)品，如 WebSphere Portal 和 IBM Workplace 產(chǎn)品，能夠作為 SOA 的最好的組成部分。

某些組織可能會選擇從一些有機會的項目開始。這可能比較簡單，“我需要構(gòu)建門戶中的一部分。我該如何開始組織、構(gòu)建并將其放在具有面向服務(wù)體系結(jié)構(gòu)特征的系統(tǒng)中？換句話說，在可以較高程度的重用的地方該如何做？”。您可以從定義服務(wù)開始。一個服務(wù)可以簡單到只有一個業(yè)務(wù)流程，或是客戶必須進行的一個操作，例如檢查某個產(chǎn)品訂單的狀態(tài)。這個服務(wù)可以在客戶將要登錄的門戶中自我顯示。這個門戶和服務(wù)將顯示為一個 portlet，占用屏幕的一小部分。我將登錄到系統(tǒng)中 —— 我能夠快速地查看訂單狀態(tài)。這就是客戶將會看到的?？蛻暨€會問 “我們?nèi)绾芜M行構(gòu)建？我們?nèi)绾芜M行軟件生命周期管理？我們?nèi)绾伍_發(fā)和部署這些產(chǎn)品？”。所以我們在支持 SOA 的 Rational 品牌中還有另外一組完整的產(chǎn)品線。這里還有 Tivoli 產(chǎn)品集，使您能夠進行安全性管理，并保證這些系統(tǒng)能夠正常運行。我們的另外一個產(chǎn)品線用于信息管理；例如 DB2 產(chǎn)品線。它們帶來了一整套的產(chǎn)品用于 SOA 策略的所有方面。

最終情況依賴于我們的客戶的需要。我們可以把更多的精力放在某些組織的整個能力的廣度上，他們試圖進行部署、考慮部署或者是想要部署面向服務(wù)的體系結(jié)構(gòu)。在他們想從投資中獲得回報時，就是他們開始的時機，這要根據(jù)業(yè)務(wù)的需求而定。

我們可以詳細闡述一下在 SOA 中 WebSphere Portal 技術(shù)所扮演的角色嗎？
Robert：按照 Gene Phifer 的說法，他是 Gartner Research 的一個門戶權(quán)威，WebSphere Portal 是 SOA 出名之前的一種 SOA。回到互聯(lián)網(wǎng)剛產(chǎn)生的時候，當我們過去使用門戶時，我們中的很多人都理解門戶和 portlet 的概念，這些門戶如今在 Yahoo、AOL 和諸如此類的站點中變得十分流行。但是猜一猜怎么樣？企業(yè)和大型組織想做同樣的事情，但是在這種情況下內(nèi)容不是必需的，卻是有 “如何將所有的系統(tǒng)進行集成并提供單點訪問？” 這一問題。因此，創(chuàng)建一個平臺供重復(fù)使用這一想法實際上已經(jīng)非常接近面向?qū)ο蟮捏w系結(jié)構(gòu)。對許多組織而言，門戶代表進入 SOA 的邏輯上的過渡，因為它允許組織做我們正在談?wù)摰氖虑?。您可以在一個基礎(chǔ)設(shè)施上進行標準化，這樣如果您開發(fā)了一個雇員門戶，然后必須進行另外一個項目，那么您能夠重用許多資產(chǎn)和基礎(chǔ)設(shè)施，并開始從 SOA 中獲益。對一些組織而言，門戶是一個邏輯上、戰(zhàn)略上的 SOA 入口點，這并不意味著您必須從這里開始，但是它為您提供了一個平滑的入口點。

Doug：大多數(shù)的業(yè)務(wù)流程在處理過程中需要用戶的參與。門戶為構(gòu)造人與面向服務(wù)的體系結(jié)構(gòu)之間的用戶交互提供了一種較好的方法。將服務(wù)的用戶界面映射到屏幕上特定的小矩形中，例如 portlet，是一種非常常見的操作。portlet 還對用戶能夠訪問的服務(wù)類型進行管理，并安排這些服務(wù)呈現(xiàn)在用戶前的方式。這些功能，諸如 WebSphere Portal 的處理功能，允許用戶安排一組服務(wù)和一組用戶界面間的用戶活動流。我們將門戶的這些非常常見的部分作為體系結(jié)構(gòu)中 Web 服務(wù)的基本表現(xiàn)工具。想像一下門戶作為 SOA 的前端。正是在這里 SOA 觸及到了用戶。

SOA 會影響其他 IBM 產(chǎn)品嗎，例如 Notes/Domino 和 IBM Workplace？
Doug：Domino 作為一項集成技術(shù)，通過在 Domino 基礎(chǔ)設(shè)施中添加定義 Web 服務(wù)并執(zhí)行這些 Web 服務(wù)的功能，在支持 SOA 的過程中邁出了重大的一步。這是一個重要的新功能。許多 SOA 工作的初始階段包括調(diào)整現(xiàn)有的系統(tǒng)，使之適應(yīng)面向服務(wù)的體系結(jié)構(gòu)。通常，這意味著在 Web 服務(wù)中封裝這些系統(tǒng)的一些業(yè)務(wù)功能，并且在環(huán)境中顯示 Web 服務(wù)。Domino 是這個領(lǐng)域中新的參與者。而 IBM Workplace 一開始就被設(shè)計為基于面向服務(wù)體系結(jié)構(gòu)的應(yīng)用程序系列。

Fernando：確實是這樣。IBM Workplace 是一組協(xié)作功能，會在門戶中用到這些功能，但是其本質(zhì)結(jié)構(gòu)都是面向服務(wù)的體系結(jié)構(gòu)。主要協(xié)作功能有一些服務(wù)接口，例如創(chuàng)建文檔、發(fā)送電子郵件消息、創(chuàng)建 Web 會議等等。這些接口可以被調(diào)用、組合并與想開發(fā)的任何其他應(yīng)用程序中的其他服務(wù)集成。例如，使用 Workplace，完全有可能調(diào)整組織中新員工的注冊以及他們在想?yún)⒓拥恼n程中的注冊，這些課程是由 Workplace Learning 提供的。所有這些都可以通過 Workplace 提供的 Web 服務(wù) API 來實現(xiàn)。我們從一開始就將這作為我們的功能的整體意圖，并且我們一直在努力提高這些 API 的功能以與其他流程集成，并提高整個系統(tǒng)的功能以支持這些用戶交互。

需要些什么才能夠使 IT 部門對 SOA 的理解同對業(yè)務(wù)線的理解相匹配？
Robert：顯然，要對 IT 部門進行創(chuàng)新。同時也要讓業(yè)務(wù)線以不同于以前的方式加入進來。在我所工作過的某些組織中，技術(shù)從來不是阻礙成功的因素；而阻礙成功的因素通常與組織問題、部門問題、政治、組織間合作方式、設(shè)置管理方式等問題有關(guān)。用戶不想定義業(yè)務(wù)線試圖去做什么，而是將那些需求收集工作都交給 IT 人員，然后希望在 9 到 12 個月內(nèi)就能取得巨大成果。

組織正在重新思考他們當前的組織方式?，F(xiàn)在可以看到 IT 和業(yè)務(wù)線的跨學(xué)科、跨功能角色的信息都聚集到一起，以更好地理解什么是業(yè)務(wù)需求，從而更好地理解技術(shù)如何幫助他們從一種組織方式轉(zhuǎn)換到另一種組織方式。這就是 IBM 的業(yè)務(wù)咨詢服務(wù)的重要作用，他們能幫助公司了解他們?nèi)绾沃匦绿幚砘蛑匦滤伎甲鳛橐粋€組織應(yīng)該如何運作，以及如何以不同于以前的方式來利用 IT，因此 IT 能成為組織的極具競爭性的優(yōu)勢。

我希望 SOA 在組織中能像它在技術(shù)領(lǐng)域中那樣流行，但通常并非如此。它實際上是讓業(yè)務(wù)線和 IT 人員以更好地理解什么是需求的方式工作，從而確保項目取得成功，并理解每個需求在取得整個成功過程中都有其作用。而不是用戶將項目交給 IT 人員，IT 人員又將其交給業(yè)務(wù)線這樣一種運作方式。

Doug：從入門角度來說，有多種可能的方法。一種是自頂向下的方法，從業(yè)務(wù)開始，然后是業(yè)務(wù)分析、為組織建模，最后是對業(yè)務(wù)流程進行建模。這種方法受 Rational Software Architect 套件的工具支持。更常見的是 “雙向逼近” 戰(zhàn)略，IT 人員從認識 Web 服務(wù)和 SOA 的封裝和集成戰(zhàn)略開始，并構(gòu)建一定數(shù)量的體系結(jié)構(gòu)，然后加入到業(yè)務(wù)中以便在可能的情況下利用這些體系結(jié)構(gòu)。正如 Robert 所說的，SOA 實際上是關(guān)于將業(yè)務(wù)和 IT 組織合并到一起，在粒度級和業(yè)務(wù)行為方面達成一致，從而由服務(wù)對其進行建模。

IT 組織如何能夠使 SOA 被業(yè)務(wù)線獲得和使用？
Robert：這又回到了我們剛才談?wù)摰脑掝}，就是關(guān)于如何使用 WebSphere Portal 技術(shù)來實現(xiàn) SOA，并將 Workplace 作為 Portal 技術(shù)的一種超集。通過將服務(wù)目錄映射到 portlet 目錄（即為所提供的服務(wù)創(chuàng)建用戶界面），并且通過使用 WebSphere Portal 來驅(qū)動服務(wù)和用戶之間的用戶交互，這是一個很好的過渡，適合于很多客戶已經(jīng)進行的 IT 工作。因此我們認為 WebSphere Portal 是業(yè)務(wù)線用戶能夠訪問 SOA 的關(guān)鍵。

Fernando：要詳細描述這一點，也可以這么說，IT 領(lǐng)域和業(yè)務(wù)線領(lǐng)域之間的常見分工是，開發(fā)人員在 IT 方構(gòu)建標準的組件。這些界面可以作為 portlet，這些 portlet 訪問企業(yè)服務(wù)，然后 IT 組織會將 portlet 組織到模板中。模板是服務(wù)的可重用組合，不同業(yè)務(wù)線的終端用戶都可以訪問這些服務(wù)，并根據(jù)他們的自身需要對這些服務(wù)進行定制（這是一個關(guān)鍵部分）。同時使用 WebSphere Portal 和 Workplace，用戶的系統(tǒng)可以變得更靈活，由此可以為銷售群組或研發(fā)部門定制能訪問這些企業(yè)服務(wù)的標準模板，以包括特定類型的表單，從而收集自己的信息或涵蓋您所感興趣的項的特定文檔集，或上面標記了對您的團隊來說非常重要的事件和里程碑的特定日歷。這是一種本地定制，這些本地格式化的企業(yè)工作空間使這些組織內(nèi)的各個群組可以利用 SOA 的價值。

Robert：的確如此，他說出了我們工作的意義和 WPLC 組織是什么。隨著組織開始使他們的基礎(chǔ)設(shè)施變得合理，并試圖提高工作效率，您將看到這些流程驅(qū)動的門戶、企業(yè)工作空間、企業(yè)桌面 —— 這些是您所聽到的用于描述這些事情的術(shù)語 —— 作為公司跨企業(yè)優(yōu)化他們的協(xié)作業(yè)務(wù)流程的首選方法而出現(xiàn)。WebSphere Portal 和 Workplace 能扮演如此重要角色是因為它們是商業(yè)人士實際所用的工具。用戶無需接觸很多集成技術(shù)，因為這些都是底層技術(shù)。但是他們的確接觸到了這些桌面 —— 這些企業(yè)工作空間。

你們?nèi)绾慰创?SOA 將塑造軟件工業(yè)的未來（或是這方面的其他工業(yè)）？
Doug：我將更清晰地預(yù)測一下未來，我們已經(jīng)說過 SOA 是業(yè)務(wù)和 IT 組織很好的交匯場所。我認為這將導(dǎo)致根本上的變化。我們還略微提到了一些 Web 服務(wù)，尤其是互聯(lián)網(wǎng)上的 Web 服務(wù)，允許小型業(yè)務(wù)和大型業(yè)務(wù)集合到一起，使 IT 基礎(chǔ)設(shè)施的花費同時適用于它們。并且其通過互聯(lián)網(wǎng)創(chuàng)建大型的、面向服務(wù)的系統(tǒng)的能力，我認為前景非常廣闊。隨著互聯(lián)網(wǎng)支持大量其他新出現(xiàn)的業(yè)務(wù)模型，我認為在服務(wù)提供者和服務(wù)消費者的領(lǐng)域，將會有一整套新的業(yè)務(wù)模型。

Robert：我認為服務(wù)的重點是繼續(xù)強調(diào)虛擬化和適應(yīng)的作用，這就像軟件產(chǎn)品的交付。如今，我們經(jīng)常需要深入了解軟件系統(tǒng)的參數(shù)和選項才能進行安裝，然后再來調(diào)整這些參數(shù)和選項。軟件在某種程度上來說本身就是一種服務(wù)，用戶將其添加到網(wǎng)絡(luò)基礎(chǔ)設(shè)施中并讓其工作，現(xiàn)在該軟件即是可以作為端點來訪問的服務(wù)。可以對該服務(wù)進行管理，將其連接到其他服務(wù)，但是不需要深入了解這些服務(wù)的內(nèi)部工作原理。用戶更多的是注意它所帶來的價值。作為軟件開發(fā)人員，這對我們來說并不容易，實際上，我認為這是一件很難的事情。但是讓我們所有的產(chǎn)品以相同的方式互相通信是我們的預(yù)期目標。

有什么需要補充嗎？
Doug：我要再強調(diào)一下，我們將 WebSphere Portal 和 IBM Workplace 技術(shù)作為該行業(yè)的關(guān)鍵技術(shù)。隨著人們在互聯(lián)網(wǎng)上提供服務(wù)的改進和增加、組織內(nèi)部對服務(wù)可用性的改進、業(yè)務(wù)線幫助他們自身和創(chuàng)建新的最適合其業(yè)務(wù)需要的服務(wù)組合的機會，這些都將越來越多地需要 IT 基礎(chǔ)設(shè)施。IBM Workplace 是一種旨在允許業(yè)務(wù)線用戶創(chuàng)建和構(gòu)建他們自己的結(jié)構(gòu)、能力以及應(yīng)用程序的產(chǎn)品，以可用的協(xié)作服務(wù)和由 IT 組織或應(yīng)用程序供應(yīng)商帶入到應(yīng)用環(huán)境中的其他服務(wù)為基礎(chǔ)。因此我們認為自我服務(wù)和用戶驅(qū)動這兩者相結(jié)合非常重要。

Robert：我將借用一下別人的展望和預(yù)測 —— 如果您看一下 IDC 上系統(tǒng)專家的分析，那么就會看到他們的確相信一個新的用戶工作環(huán)境將在今后的五年中出現(xiàn)，一種新的、統(tǒng)一的、模塊化的企業(yè)軟件組合將為該環(huán)境提供支持，該環(huán)境構(gòu)建在面向服務(wù)的體系結(jié)構(gòu)之上。他們稱其為企業(yè)工作空間，它將極大地改進應(yīng)用程序和工作人員之間的交互，以及工作人員之間的協(xié)作。您將看到前所未有的效率水平。

檢驗 IBM WebSphere Integration Developer 組裝的SCA 組件的上下文中的引用和連線。

摘自 IBM WebSphere 開發(fā)者技術(shù)期刊。

引言

在這一系列文章的第 1 部分，我們引入了服務(wù)組件體系結(jié)構(gòu)（Service Component Architecture，SCA）作為編程模型來構(gòu)建和組裝集成解決方案，包括簡要介紹什么是 SCA，以及一些相關(guān)術(shù)語的定義。我們還提供了一個通過 IBM WebSphere Integration Developer 使用 Java? 構(gòu)建 SCA 組件的示例，測試了該 SCA 組件，并使用 SCA 客戶端編程模型構(gòu)建了一個調(diào)用該 SCA 組件的示例 JSP 文件。在第 2 部分中，我們將繼續(xù)描述引用和連線，并介紹如何使用它們來組裝 SCA 組件。

概述

在第 1 部分介紹的示例中，我們使用了一個簡單的 JSP 客戶端來調(diào)用 SCA 組件。該示例只用于演示；當構(gòu)建您自己的實際自定義應(yīng)用程序時，您可能會使用標準 J2EE? 組件模型來實現(xiàn)應(yīng)用程序邏輯。J2EE Web 應(yīng)用程序?qū)⒗^續(xù)調(diào)用 Enterprise JavaBean 來訪問特定于應(yīng)用程序的功能。實際上，SCA 編程模型是用于業(yè)務(wù)集成、應(yīng)用程序組合和解決方案組裝的，而不是用于 J2EE 應(yīng)用程序開發(fā)的。SCA 客戶端（它可以是 J2EE）通常在進程管理器外，例如它可以使用 BPEL 流程來編排工作流。與 BPEL 流程聯(lián)合部署的 Web 應(yīng)用程序也可以使用 SCA 編程模型來調(diào)用特定于應(yīng)用程序的功能。圖 1 顯示了 SCA 生態(tài)系統(tǒng)的一個示例。

SCA 位于集成層。SCA 組件可以通過導(dǎo)入來調(diào)用 SCA 運行時外的應(yīng)用程序。非 SCA 客戶端可以通過導(dǎo)出調(diào)用 SCA 組件。在集成層內(nèi)，可以通過定義引用和使用連線來組合 SCA 組件，這將在本文中重點介紹。有了連線和引用，您就可以在開發(fā)時定義運行時調(diào)用的特性；例如，使調(diào)用同步或異步，標記調(diào)用的轉(zhuǎn)換邊界，等等。這些特性是在部署時讀取的，它們可以啟用所需的運行時行為。圖 2 闡釋了這些高級概念。

再次說明，我們關(guān)注的是集成層，而不是應(yīng)用層。另外，我們介紹的是較高級的集成，例如工作流編排或與 EIS 系統(tǒng)的高級集成。然而，出于演示目的，我們使用簡單的 Java 示例來顯示如何將組件連接到集成層中，強調(diào)的是連線和引用的功能而不是組件本身的實現(xiàn)。（在后續(xù)文章中，我們將介紹如何將 SCA 組件實現(xiàn)為 BPEL 流程和狀態(tài)機，以及如何應(yīng)用連線技術(shù)。）因此我們使用一個按比例縮減的模型來闡釋引用和連線，如圖 3 所示；然而，我們要記住圖 2 中合適的 SCA 使用遠景。

引用

正如第 1 部分所討論的，SCA 組件被打包成一個 SCA 模塊。一個模塊中的 SCA 組件通過對調(diào)用的 SCA 組件定義引用來彼此交互，并且將這些引用連線到相同模塊中的其他 SCA 組件。圖 4 闡釋了這一概念。

對調(diào)用組件的引用是用 SCDL 表示的，如下所示：

												
																		
<scdl:component xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:java="http://www.ibm.com/xmlns/prod/websphere/scdl/java/6.0.0"
xmlns:ns1="http://CreditApproval/CreditRequest"
xmlns:scdl="http://www.ibm.com/xmlns/prod/websphere/scdl/6.0.0"
xmlns:wsdl="http://www.ibm.com/xmlns/prod/websphere/scdl/wsdl/6.0.0"
displayName="CreditApproval" name="CreditApproval">
  <interfaces>
    <interface xsi:type="wsdl:WSDLPortType" portType="ns1:CreditRequest">
      <method name="calulateCreditScore"/>
    </interface>
  </interfaces>
  <references>
    <reference name="CreditHistoryPartner">
      <interface xsi:type="java:JavaInterface" 
      interface="approval.credit.credit.history.CreditHistory">
        <method name="getCreditLimit"/>
      </interface>
      <wire target="CreditHistory"/>
    </reference>
    <reference name="CreditAgencyPartner">
      <interface xsi:type="java:JavaInterface" 
      interface="approval.credit.credit.agency.CreditAgency">
        <method name="getCreditScore"/>
      </interface>
      <wire target="CreditAgency"/>
    </reference>
  </references>
  <implementation xsi:type="java:JavaImplementation" 
  class="sca.component.java.impl.CreditApprovalImpl"/>
</scdl:component>
												
										

引用的好處之一是能夠定義調(diào)用期間的服務(wù)質(zhì)量。當在 Assembly Editor 中連線組件時，可以指定服務(wù)質(zhì)量 (QoS) 限定符。這些限定符定義了調(diào)用期間在 SCA 運行時管理組件的必要條件。

限定符

使用 SCA，您無需編程或更改服務(wù)實現(xiàn)代碼就可以對組件應(yīng)用 QoS 限定符（例如事務(wù)、安全性和可靠的異步調(diào)用）。在連線組件時，您可以指定限定符來為組件以及訪問服務(wù)的客戶端提供擴展的服務(wù)質(zhì)量。在 IBM WebSphere Process Server 中，您可以在三個地方定義 SCA 限定符：

• 引用
• 接口
• 實現(xiàn)

在運行時，這些規(guī)范確定了客戶端如何與目標組件進行交互。運行時環(huán)境可以提供所需的任何額外處理，這取決于所指定的限定符。

用于引用的限定符

引用限定符可以指定異步調(diào)用的可靠性，以及是否應(yīng)該聯(lián)合目標組件的方法，使之成為任何客戶端事務(wù)的一部分。

引用限定符包括：

• Asynchronous reliability - 允許發(fā)生異步調(diào)用。這些限定符還允許您指定消息的可靠性、請求和響應(yīng)超時。同時也能配置 Service Integration Bus——它在 IBM WebSphere Application Server 運行時中提供消息傳遞平臺，因此對 WebSphere Process Server 可用。（有關(guān) Service Integration Bus 的信息，請參閱參考資料。）

• Suspend transaction - 對于同步調(diào)用，當使用同步編輯模型進行調(diào)用時，客戶端全局事務(wù)上下文始終會被傳播到目標組件。（此限定符只影響客戶端全局事務(wù)，因為本地事務(wù)從不傳播到目標組件。）對于客戶端不想讓目標組件與客戶端事務(wù)聯(lián)合的用例，需要使用掛起事務(wù)限定符設(shè)置來進一步限定引用：

  • True 會在通過服務(wù)引用調(diào)用組件之前掛起當前全局事務(wù)。
  • False（缺省值）指示運行時在通過服務(wù)引用調(diào)用組件之前不要掛起全局事務(wù)。

• Asynchronous invocation - 確定是否應(yīng)該進行異步調(diào)用（作為任何客戶端事務(wù)的一部分）。值：

  • Call（缺省值）指示運行時在進行服務(wù)調(diào)用的同時將消息提交給異步調(diào)用的目的地。
  • Commit 指示運行時將消息提交給異步調(diào)用的目的地的工作交給當前工作范圍單元處理。

• Suspend activity session - 活動會話能夠?qū)赡懿恢С址植际绞聞?wù)的資源進行更高級的協(xié)調(diào)。集成解決方案中更可能出現(xiàn)此類情況；客戶端不想讓目標組件與客戶端的活動會話相聯(lián)合，所以需要使用掛起活動會話限定符設(shè)置來進一步地限定引用：

  • True 會在通過服務(wù)引用調(diào)用組件之前掛起當前活動會話（如果存在）。
  • False（缺省值）指示運行時在通過服務(wù)引用調(diào)用組件之前不要掛起任何處于活動狀態(tài)的活動會話。

您可以指定引用限定符，以便它們應(yīng)用于服務(wù)組件的所有引用或者只應(yīng)用于獨立引用。如果需要，您還可以為每個引用指定這些限定符，在這種情況下它們將重寫任何頂級限定符設(shè)置。在 Properties 視圖中以灰色表示繼承的限定符，以黑色表示已賦值的限定符。繼承的限定符不能更改，除非您選擇定義它們的所在元素。

用于接口的限定符

接口限定符說明了被目標服務(wù)支持的QoS，因此代表了一個與該服務(wù)客戶端的約定。

接口限定符包括：

• Join activity session - 確定目標服務(wù)是否愿意加入傳播的活動會話范圍。值：

  • True 指示運行時不要在接口邊界掛起活動會話（如果存在）。
  • False（缺省值）指示運行時在接口邊界掛起活動會話（如果存在）。

• Join transaction - 確定目標服務(wù)是否愿意加入傳播的全局事務(wù)。值：

  • True 指示運行時不要在接口邊界掛起全局事務(wù)（如果存在）。
  • False（缺省值）指示運行時在接口邊界掛起全局事務(wù)（如果存在）。

• Security permission - 使您能夠在 SCA 組件上定義 J2EE 角色。只有與聲明的角色相關(guān)聯(lián)的客戶端才能調(diào)用該組件。

所有接口限定符都可以應(yīng)用于組件的三個級別：

• 用于其所有接口
• 用于單個接口
• 用于某個接口的單個操作。

操作的限定符覆蓋接口的限定符；接口的限定符覆蓋組件的所有接口的限定符。

用于實現(xiàn)的限定符

實現(xiàn)限定符提供確定服務(wù)權(quán)限和/或表示其對事務(wù)環(huán)境的需求的功能。

接口限定符包括：

• Activity session - 確定組件的處理是否在一個活動會話中執(zhí)行，除了全局事務(wù)上下文所提供的，它還提供一個備選的工作范圍單元。值：

  • True：組件將在活動會話的上下文中執(zhí)行。如果活動會話是在調(diào)用時出現(xiàn)的，則會添加該組件。
  • False（缺省值）：組件將在現(xiàn)有的全局事務(wù)（如果存在）或本地事務(wù)的上下文中執(zhí)行。實現(xiàn)限定符為 activitySession=false 的組件必須使用接口限定符 joinActivitySession=false。
  • Any：如果存在活動會話，則組件會加入當前活動會話。如果不存在活動會話，則組件會在現(xiàn)有的工作范圍單元或本地事務(wù)的上下文中執(zhí)行。

• Transaction - 確定組件處理執(zhí)行的邏輯工作單元。對于邏輯工作單元，事務(wù)期間所做的全部數(shù)據(jù)修改都是作為一個單元一起提交或作為一個單元回滾的：

  • Global：組件將在全局事務(wù)的上下文中執(zhí)行。如果在調(diào)用時存在一個全局事務(wù)，則該組件會被添加到該全局事務(wù)范圍。如果不存在全局事務(wù)，則會建立新的事務(wù)范圍。
  • Local（缺省值）：組件將在本地事務(wù)的上下文中執(zhí)行。
  • Any：如果存在一個全局事務(wù)，則組件將加入當前全局事務(wù)范圍。如果不存在全局事務(wù)，則組件將在本地事務(wù)的上下文中執(zhí)行。

• Security identity - 使您能夠指定組件擔當?shù)纳矸?，與部署描述符上的 J2EE Run-As 約束類似。

限定符是在 SCDL 文件中定義的：接口限定符是在接口部分定義的，實現(xiàn)限定符是在實現(xiàn)部分定義的，引用限定符是在引用部分定義的。（有關(guān)詳細信息，請查閱 WebSphere Process Server Information Center。）

連線組件

在對引用有了新的理解之后，我們現(xiàn)在可以將一些組件通過連線連接起來。我們將使用的示例十分簡單，但在這個過程中我們也會檢查各種可用的服務(wù)質(zhì)量。我們將繼續(xù)介紹在第 1 部分使用的信貸審批示例。

在我們的示例中：

• Credit Approval 組件必須調(diào)用 Credit History 組件以及 Credit Agency 組件。
• Credit Approval 組件將作為這兩個服務(wù)的一個 Facade。
• Credit Approval 組件需要連線到其他組件。

這一練習所需要的文件可以從本文所附帶的下載文件中獲得。

設(shè)置工作區(qū)

1. 啟動 WebSphere Integration Developer 并創(chuàng)建一個新的工作區(qū)（圖 5）。

   
   圖 5. 在 WebSphere Integration Developer 中創(chuàng)建工作區(qū)
   
   

2. 關(guān)閉歡迎屏幕（圖 6）。

   
   圖 6. WebSphere Integration Developer 歡迎屏幕
   
   

3. 要從下載的文件導(dǎo)入項目交換文件，請右鍵單擊 Business Integration 視圖并選擇 Import（圖 7）。

   
   圖 7. 導(dǎo)入下載文件
   
   

4. 選擇 Project Interchange，然后單擊 Next（圖 8）。

   
   圖 8. 導(dǎo)入項目
   
   

5. 假設(shè)您已經(jīng)將下載的文件解壓縮到 C: 驅(qū)動器，則選擇 CreditApprovalPart2.zip 文件，然后單擊 Select All 和 Finish（圖 9）。

   
   圖 9. 導(dǎo)入項目
   
   

檢查組件

在我們的示例中，我們將使用自底向上的開發(fā)風格：我們有一個現(xiàn)有的 SCA 組件集并準備對它們進行集成。從 Business Integration 視圖中，您可以檢查該 SCA 模塊：

6. 展開 CreditApproval 模塊（圖 10）。

   
   圖 10. 展開的 Credit Approval 模塊
   
   

7. 請注意，它有三個接口和三個 Java 實現(xiàn)。打開 CreditApprovalImpl Java 實現(xiàn)并轉(zhuǎn)到 calculateCreditScore() 方法。請注意，calculateCreditScore 同時與 CreditAgency 組件和 CreditHistory 組件進行交互來完成其服務(wù)。您很容易想到將 CreditApproval Service 實現(xiàn)為 BPEL 流程或其他組件類型，但在本例中，我們用一個簡單的 Java 組件來作為 Facade。

   
   清單 2
   

   public DataObject calulateCreditScore(DataObject creditApp) { ServiceManager serviceManager = new ServiceManager(); BOFactory bof = (BOFactory)serviceManager.locateService("com/ibm/websphere/bo/BOFactory"); DataObject creditRating = bof.create("http://CreditApproval", "CreditRating"); creditRating.setString("customerId", creditApp.getString("customerId")); CreditAgency creditAgency = (CreditAgency) serviceManager.locateService("CreditAgencyPartner"); Integer creditScore = creditAgency.getCreditScore(creditApp); CreditHistory creditHistory = (CreditHistory) serviceManager.locateService("CreditHistoryPartner"); Double creditLimit = creditHistory.getCreditLimit(creditApp); creditRating.setInt("creditScore", creditScore.intValue()); creditRating.setDouble("creditLimit", creditLimit.doubleValue()); return creditRating; }

   
   

8. 要打開 Assembly Editor，請雙擊 CreditApproval 集合（圖 11）。當 Assembly Editor 打開時，會顯示三個組件（圖 12）。

   
   圖 11. 打開 Assembly Editor
   
   
   圖 12. Assembly Editor 中的組件
   
   

連線組件

CreditApproval 組件通過使用簡單的 SCA 客戶端 API 來與 CreditAgency 和 CreditHistory 進行交互。然而，要讓運行時正確地調(diào)用這些服務(wù)，需要將組件“連線”起來，使用 WebSphere Integration Developer 來進行這一操作非常簡單。在我們的示例中，我們將接受缺省值。

9. 選擇 CreditAproval 組件并將其連線到 CreditAgency 組件（圖 13）。

   
   圖 13. 連線組件
   
   

10. 將顯示一個對話框（圖 14），表明將在 CreditApproval 組件上創(chuàng)建一個引用。選擇 OK。

    
    圖 14. 匹配引用對話框
    
    

11. 由于 CreditApproval 組件是一個 Java 組件，所以我們需要用 WebSphere Integration Developer 生成 Java 接口以便能夠調(diào)用該組件。因此，在下一個對話框（圖 15）中選擇 Yes。如果 CreditApproval 已經(jīng)是一個完整的 BPEL 流程，則選擇 No。（請記住，在大多數(shù)情況下將使用 WSDL 作為集成層中的接口選擇。如果 User Interface 是與集成解決方案聯(lián)合部署的，則可以使用 Java 接口。）

    
    圖 15. 生成 Java 接口對話框
    
    

12. 重復(fù)步驟 9 到 11，將 CreditApproval 組件連線到 CreditHistory 組件。結(jié)果應(yīng)該與圖 16 類似。

    
    圖 16. 組件連線完成
    
    

單元測試組件

因為我們使用 Java 作為我們的實現(xiàn)，所以可以在 Java SE 環(huán)境中對組件進行單元測試。正如在第 1 部分所做的，我們很容易在 WebSphere Integration Developer 中調(diào)出單元測試工具：

13. 右鍵單擊 CreditApproval 組件并選擇 Test Component（圖 17）。

    
    圖 17. 測試組件
    
    

14. 將顯示單元測試工具。該單元測試功能的一個很好的優(yōu)點是它允許獨立測試組件，并且可以檢測引用和創(chuàng)建模擬器。在我們的例子中，我們自己測試集成，所以需要刪除模擬器。

15. 切換到 Configurations 選項卡。

16. 展開 Module CreditApproval 模塊，突出顯示 CreditAgency 和 CreditHistory，并將它們從 Emulators 列表中刪除（圖 18）?，F(xiàn)在，測試 CreditApproval 組件將導(dǎo)致調(diào)用 CreditHistory 和 CreditAgency 組件，而不會模擬交互。

    
    圖 18. 刪除模擬器
    
    

17. 切換回 Events 選項卡并突出顯示 Invoke 項（圖 19）。

    
    圖 19. Events 選項卡
    
    

18. 填充輸入，如圖 20 所示。

    
    圖 20. 數(shù)據(jù)參數(shù)
    
    

19. 單擊 Continue。

20. 選擇 Eclipse 1.4 JVM 選項（圖 21）。

    
    圖 21. 選擇部署位置
    
    

21. 檢查每個步驟的流程。您可以實際看到流經(jīng)組件的數(shù)據(jù)（圖 22）。

    
    圖 22. 事件流
    
    

22. 最終結(jié)果應(yīng)該與圖 23 類似。

    
    圖 23. 測試結(jié)果
    
    

23. 關(guān)閉測試編輯器，不進行保存。

檢查服務(wù)質(zhì)量

引用和連線是集成解決方案的關(guān)鍵，因為它們抽象出調(diào)用的方式和場合。當在 WebSphere Process Server 中運行時，您可以定義想為調(diào)用設(shè)定的服務(wù)質(zhì)量。例如，您可以使調(diào)用異步化、可以更改事務(wù)上下文，或者使異步調(diào)用更加可靠。這里我們將通過檢查引用屬性來查看各種 QoS 選項。

24. 選擇 CreditApproval 組件上的 CreditAgency 引用，如圖 24 所示。

    
    圖 24. 組件引用
    
    

25. 轉(zhuǎn)到 Properties 視圖。您將注意到該引用被選中。

    
    圖 25. 選中的引用
    
    

26. 在 Details 選項卡上（圖 26），將顯示被調(diào)用的接口和多樣性，以及作為目標的連線。您可以更改調(diào)用的多樣性；對于異步調(diào)用，這樣可以以一種發(fā)布/訂閱方式調(diào)用幾個組件。

    
    圖 26. 引用詳細信息
    
    

27. 切換至 Qualifiers 選項卡（圖 27）以設(shè)置特定服務(wù)質(zhì)量。

    
    圖 27. Qualifiers 選項卡
    
    

28. 單擊 Add 按鈕來查看幾個可用的服務(wù)質(zhì)量（圖 28）。

    
    圖 28. 服務(wù)質(zhì)量限定符
    
    

29. 作為自我練習，您可以試驗這些限定符，請記住，這些質(zhì)量需要在 WebSphere Process Server 運行時中測試。這些限定符包括事務(wù)質(zhì)量和異步質(zhì)量；要測試事務(wù)工作，您需要與資源交互的組件。特定服務(wù)質(zhì)量是在接口中定義的。這使得該組件能夠控制其他組件調(diào)用它的方式。

30. 突出顯示 Assembly Editor 中的 CreditApproval 接口（圖 29），或者導(dǎo)航至 Properties 編輯器。

    
    圖 29. Assembly Editor 中選定的 CreditApproval
    
    

31. 檢查服務(wù)質(zhì)量限定符（圖 30）和實現(xiàn)限定符。請注意，這些限定符是在被調(diào)用的服務(wù)（而不是調(diào)用它的服務(wù)）上定義的。

    
    圖 30. 檢查限定符
    
    

在 WebSphere Process Server 測試環(huán)境中測試

要測試服務(wù)質(zhì)量，您通常需要在 WebSphere Process Server 中運行，或者在 WebSphere Integration Developer 中為測試提供的 WebSphere Process Server 運行時運行。

32. 在 Servers 視圖中，右鍵單擊該服務(wù)器并選擇 Start（圖 31）。

    
    圖 31. 啟動測試環(huán)境中的服務(wù)器
    
    
    圖 32. 服務(wù)器已啟動
    
    

33. 當服務(wù)器啟動后，您可以按照管理控制臺中的指示（圖 32），以一種類似于添加 J2EE 應(yīng)用程序的方式將該 SCA 模塊添加到服務(wù)器中，因為 SCA 模塊被包裝成 EAR 文件（如第 1 部分所提到的）。再次右鍵單擊服務(wù)器并選擇 Add and remove rojects...（圖 33）。

    
    圖 33. 添加和刪除項目
    
    

34. 選擇 CreditApprovalApp 并將它添加到已配置的項目一側(cè)（圖 34）。

    
    圖 34. 將項目添加到服務(wù)器
    
    

35. 檢查管理控制臺，確保 SCA 模塊已啟動（圖 35）。

    
    圖 35. 表明 SCA 模塊已啟動的控制臺消息
    
    

36. 要使用同一 WebSphere Integration Developer 單元測試功能來測試該組件，請按照前面所執(zhí)行的操作，再次右鍵單擊該組件，然后選擇 Test Component（圖 36）。

    
    圖 36. 測試 SCA 組件
    
    

37. 再次說明，請刪除模擬器，以使測試能夠流經(jīng) SCA 組件（圖 37）。

    
    圖 37. 刪除模擬器
    
    

38. 鍵入輸入?yún)?shù)，如圖 38 所示。

    
    圖 38. 數(shù)據(jù)參數(shù)
    
    

39. 選擇 WebSphere Process Server V6.0 作為部署位置（圖 39）。

    
    圖 39. 選擇部署位置
    
    

40. 檢查測試結(jié)果。

作為自我練習，請更改組件以進行數(shù)據(jù)庫更新，然后試驗事務(wù)屬性。您也可以在管理控制臺中使調(diào)用異步化以及檢查基礎(chǔ) Service Integration Bus 配置。

結(jié)束語

本文介紹了使用 WebSphere Integration Developer 組裝服務(wù)組件體系結(jié)構(gòu)組件的上下文中的引用和連線。這一系列的下一篇文章將討論導(dǎo)入和導(dǎo)出，以便您能夠集成 SCA 模塊。該系列以后的文章還將介紹更復(fù)雜的組件以及與非 SCA 組件相集成。

致謝

作者真誠感謝 Eric Herness、Keys Botzum 和 Paul Ilechko 對本文的審閱。

下載

名字	大小	下載方法
CreditApprovalPart2.zip	23 KB	?FTP|HTTP

保護面向服務(wù)的體系結(jié)構(gòu)（service-oriented architecture，SOA）中的應(yīng)用程序具有挑戰(zhàn)性，因為 SOA 的松耦合特性可能暴露現(xiàn)有安全實現(xiàn)的弱點。以下解決方案包括定義明確的信任模型（基于可接受的驗證形式），并糅合了策略、Web 服務(wù)安全性和安全工程最佳實踐。

引言

對于任何應(yīng)用程序來說，保護信息訪問的安全都是最基本的要求。由于按 SOA 原則構(gòu)造的實現(xiàn)的服務(wù)、應(yīng)用程序以及跨組織操作的松耦合，因此安全對其甚至更為重要。這種環(huán)境往往會暴露現(xiàn)有安全實現(xiàn)的弱點或局限性。

即使不考慮通過由模型驅(qū)動的開發(fā)和基于 SOA 的服務(wù)管理所提高的效率，業(yè)務(wù)應(yīng)用程序仍須保護信息。只保護周邊設(shè)施（如防火墻和路由器）是不夠的，因為隨需應(yīng)變的企業(yè)必須能夠隨著其合作伙伴、客戶和雇員之間的關(guān)系發(fā)展而建立和斷絕動態(tài)信任關(guān)系。因此，安全的隨需應(yīng)變企業(yè)需要靈活的、可自定義的基礎(chǔ)設(shè)施，以適應(yīng)新要求和規(guī)章制度。要提供這種靈活性，不應(yīng)將策略生搬硬套到基礎(chǔ)設(shè)施中；應(yīng)該通過由策略驅(qū)動的基礎(chǔ)設(shè)施滿足安全模型的要求，這任務(wù)可不簡單。

本文將闡釋業(yè)務(wù)應(yīng)用程序利用隨需應(yīng)變安全基礎(chǔ)設(shè)施的安全功能的方式，以及建立用于保護面向服務(wù)的應(yīng)用程序的編程模型的設(shè)計原則。

業(yè)務(wù)應(yīng)用程序和安全基礎(chǔ)設(shè)施

安全集成以及對業(yè)務(wù)應(yīng)用程序和信息的訪問通常是通過身份驗證、授權(quán)和責任實現(xiàn)的。企業(yè)探討管理身份驗證、授權(quán)和責任的方式在很大程度上取決于其對客戶、雇員和合作伙伴之間的信任關(guān)系的看法；這些關(guān)系對業(yè)務(wù)應(yīng)用程序安全的影響；以及這些應(yīng)用程序的相對重要性和安全性。

在業(yè)務(wù)合作伙伴之間交換敏感信息時，敏感信息必須受到保護?？赡苓€需要用安全的方式保存敏感信息。必須保證消息源的完整性（如通過公證服務(wù)）才能在必要時啟用驗證、審核和認可。可能需要對敏感信息進行加密以實現(xiàn)機密性，或?qū)ζ溥M行數(shù)字簽名以實現(xiàn)完整性。（數(shù)字簽名也可用于認可。）完整的 SOA 設(shè)計必須不但涵蓋消息級和傳輸級安全性，而且還要滿足保護保存的內(nèi)容以遵守政府規(guī)章制度和業(yè)界最佳實踐的需要。

安全策略的制定和執(zhí)行以及所執(zhí)行的安全級別，基本上都取決于企業(yè)及其雇員、客戶和合作伙伴之間的信任關(guān)系。證書和密鑰之類的相關(guān)技術(shù)可用于反映和管理這些信任關(guān)系。工具可用于建立業(yè)務(wù)合作伙伴、客戶和企業(yè)等之間的信任關(guān)系模型并指定信任關(guān)系，還可以將信任定義轉(zhuǎn)換成適用于 IT 環(huán)境的技術(shù)。

SOA 安全模型

SOA 安全模型基于 Web 服務(wù)可能需要其中的傳入消息以驗證一系列聲明的過程。名稱、密鑰、權(quán)限和功能都是聲明的例子。根據(jù)所提供的證據(jù)，會在請求者、服務(wù)端點和一系列可能的中介之間應(yīng)用適當?shù)男湃文Ｐ汀?/p>

消息可能會通過請求者和目標服務(wù)之間的若干中介。端到端安全性必須考慮到請求者、中介和最終端點服務(wù)（提供者）之間的信任模型，如圖 1 所示。

對于消息處理，網(wǎng)絡(luò)和傳輸中介（如防火墻、路由器和代理服務(wù)器）一般不受信任。應(yīng)該防止傳輸中的所有消息受到不可靠中介的篡改。

OASIS Web 服務(wù)安全性（Web Services Security，WSS）規(guī)范提供對傳輸中的簡單對象訪問協(xié)議（Simple Object Access Protocol，SOAP）消息的保護?？捎?WSS 防止消息的真實性、完整性和機密性受到不可靠網(wǎng)絡(luò)和傳輸中介的攻擊。

并不是所有中介都不可靠。Web 服務(wù)網(wǎng)關(guān)和企業(yè)服務(wù)總線中介服務(wù)都是消息轉(zhuǎn)換中介的例子，其在 SOA 內(nèi)的功能包括檢查，在某些情況下還包括對消息有效負載的修改 [請參閱此系列中的第 4 部分，“IBM 企業(yè)服務(wù)總線簡介”（developerworks，2005 年）]。在設(shè)計 SOA 安全基礎(chǔ)設(shè)施時，請考慮允許某些受信任的中介。

處理請求者和應(yīng)用程序服務(wù)主機之間的信任關(guān)系的消息代理可能是另一個受信任的中介。在這種設(shè)計中，安全責任由代理和服務(wù)端點來分擔。如圖 2 所示，消息中介將負責消息級安全、請求者和提供者環(huán)境之間的身份聯(lián)合，以及管理請求者和服務(wù)提供者之間的信任關(guān)系。服務(wù)只有為了滿足特定于服務(wù)的安全要求（如建立（通過中介映射和聯(lián)合）訪問特定于消息有效負載中應(yīng)用程序數(shù)據(jù)的服務(wù)、完整性和機密性數(shù)據(jù)的身份）才會繼續(xù)起安全作用。通過分解業(yè)務(wù)應(yīng)用程序中脆弱或復(fù)雜的基礎(chǔ)設(shè)施代碼并將其委派給容器，基于 SOA 的安全方法可以提高靈活性并降低發(fā)生不測事件的可能性。

消息安全性

WSS 規(guī)范還提供一系列有助于 Web 服務(wù)開發(fā)人員保護 SOAP 交換的基本消息級完整性、機密性和身份驗證機制?？捎酶鞣N方式組合這些機制，以便用各種加密技術(shù)建立各種安全模型。

WSS 還提供可擴展的機制，以便將安全令牌與含有各種身份驗證及授權(quán)格式和機制的消息相關(guān)聯(lián)。例如，客戶機可能會提供身份證據(jù)及其具有特定業(yè)務(wù)證書的已簽名聲明。然后收到這種消息的 Web 服務(wù)就可以確定是否要信任其聲明和信任的程度。

安全令牌聲明可由授權(quán)機構(gòu)核準或不核準。一組已核準的聲明通常表示為安全令牌（經(jīng)過數(shù)字簽名或受到授權(quán)機構(gòu)加密保護）。X.509 證書就是一個熟悉的已簽名安全令牌例子；它斷言某人的身份和公鑰之間的綁定關(guān)系。安全令牌可以“推送到”消息中或者在消息中攜帶安全令牌，也可以通過引用表示安全令牌，以便接收方從授權(quán)機構(gòu)“拉取”該聲明。

因為安全令牌是在信任域內(nèi)起作用的，所以需要有鏈接信任域作用范圍的方式?？赏ㄟ^協(xié)議或通過實現(xiàn)一系列規(guī)則強制執(zhí)行信任策略來手動鏈接。這樣，如果發(fā)送方和接收方之間有已確立的信任關(guān)系，則可信任未經(jīng)核準的聲明。例如，如果發(fā)送方和接收方使用的是其通過帶外信任關(guān)系建立的可靠連接，則發(fā)送方為 Bob 的未核準聲明足以讓某些接收方認為發(fā)送方實際上就是 Bob。在本例中，此可靠連接的存在可作為確鑿的證據(jù)。

防止消息內(nèi)容受到非法訪問（機密性）或非法修改（完整性）是主要的安全事務(wù)。WSS 規(guī)范提供通過對主體、標題、附件或其任意組合（或部分）進行加密和/或數(shù)字簽名保護消息的方法。

身份驗證請求基于可選網(wǎng)絡(luò)、由傳輸支持的安全性和消息中已批準的信息（聲明）的組合，這種技術(shù)稱為消息源身份驗證可能更好一些。通過網(wǎng)絡(luò)和由傳輸提供的安全性、消息中已批準的聲明，以及用收件人已知的密鑰對請求進行加密，請求者可以對收件人進行身份驗證。

信任模型

演示安全令牌已授權(quán)應(yīng)用的一種方式是，添加采用相關(guān)聯(lián)密鑰（來自于占有證據(jù)令牌）的數(shù)字簽名。這會使請求者可通過將安全令牌（如 X.509 公鑰基礎(chǔ)設(shè)施（Public Key Infrastructure for X.509，PKIX）證書或 X.509 證書）與消息相關(guān)聯(lián)來證明所請求的聲明組。

如果請求者沒有向服務(wù)證明請求的聲明所必要的令牌，則可與相應(yīng)的授權(quán)機構(gòu)（我們稱為安全令牌服務(wù)）聯(lián)系，并用正當?shù)穆暶髡埱笏璧牧钆啤０踩钆仆ㄟ^發(fā)布一系列安全令牌（可用于在不同的信任域之間代理信任關(guān)系）來形成信任的基礎(chǔ)。

一種機制是應(yīng)用 WS-Trust（對于有關(guān) WS-Trust 規(guī)范的更多信息，請參閱參考資料）中所定義的質(zhì)詢回應(yīng)協(xié)議。這種機制由 Web 服務(wù)用來對請求者進行更多質(zhì)詢，以確保消息不過時，以及驗證安全令牌的使用是否已經(jīng)授權(quán)。圖 3 所示的就是此模型，可以看出任何請求者也都可以是服務(wù)，請求者和目標服務(wù)都具有受信任的第三方安全令牌服務(wù)，這種服務(wù)有助于驗證每個目標服務(wù)策略所需的安全令牌。

此 SOA 安全模型（聲明、策略和安全令牌）還含有并支持若干特定模型，如基于身份的授權(quán)、訪問控制列表和基于功能的授權(quán)。通過該模型可使用現(xiàn)有的技術(shù)，如 X.509 公鑰證書、基于 XML 的令牌、Kerberos 共享秘密票證，甚至口令摘要。SOA 模型結(jié)合 Web 服務(wù)安全對話語言（Web Services Secure Conversation Language，WSSC）和 Web 服務(wù)策略框架基本要素，這足以構(gòu)造高級密鑰交換、身份驗證、基于策略的訪問控制、審核和復(fù)雜的信任關(guān)系。

將對 Web 服務(wù)應(yīng)用策略，Web 服務(wù)會從請求者收到可能包括安全令牌的消息，還可能會對其通過 WSSC 機制應(yīng)用某些保護措施。下面是由 Web 服務(wù)的信任引擎執(zhí)行的主要步驟：

• 驗證令牌中的聲明是否足以遵從策略，以及消息是否與策略一致。
• 驗證申請人的特征是否可由簽名來證明。在代理式信任模型中，簽名不可以證明申請人的身份；簽名可以證明中介（只是可斷言申請人的身份）的身份。聲明經(jīng)過批準或不是基于策略。
• 驗證安全令牌（包括所有相關(guān)和即將頒發(fā)的安全令牌）的頒發(fā)者是否可信，可以頒發(fā)其所作的聲明。信任引擎可能需要外部驗證或代理令牌（也就是向安全令牌提供服務(wù)發(fā)送令牌，以便用其交換其他可直接用在其評估中的安全令牌）。

如果滿足了這些條件，而且請求者有權(quán)執(zhí)行操作，則服務(wù)可以處理服務(wù)請求。

可將 IP 安全（IP Security，IPSec）或傳輸層安全/安全套接字層（Transport Layer Security/Secure Sockets Layer，TLS/SSL）之類的網(wǎng)絡(luò)和傳輸保護機制與此 SOA 安全模型結(jié)合使用，以支持不同的安全要求和方案。如果可用，作為附加安全技術(shù)，請求者應(yīng)該考慮采用網(wǎng)絡(luò)或傳輸安全機制，以便在頒發(fā)、驗證或更新安全令牌時對收件人預(yù)先進行身份驗證。

編程模型設(shè)計原則

從安全的角度來看，編程模型包括對于誰負責實現(xiàn)安全策略（如基礎(chǔ)設(shè)施或應(yīng)用程序）所作的決策，以及需要讓請求者得到此信息的哪一部分。除了操作方面，某些設(shè)計期間的策略（如在 J2EE 描述符中捕獲的）也有助于管理應(yīng)用程序。是通過使基礎(chǔ)設(shè)施能夠?qū)崿F(xiàn)安全模型，還是通過將安全的實現(xiàn)轉(zhuǎn)換成每個應(yīng)用程序中的代碼來最大程度地滿足業(yè)務(wù)需求，這是關(guān)鍵實現(xiàn)決策之一。要考慮的另一方面是調(diào)用服務(wù)的變數(shù)。服務(wù)的消費者是否通過可在訂閱期間定制的選擇得到了靈活性？最后，在實現(xiàn)安全解決方案時，應(yīng)該考慮安全工程——用于構(gòu)建安全應(yīng)用程序的工程方法。

由基礎(chǔ)設(shè)施管理的安全與由應(yīng)用程序管理的安全

每個組織通常都會讓某些人負責確定和實現(xiàn)其安全策略。在許多情況下此過程都是手動的，從而導(dǎo)致組織投入大量資源在不同的實體和應(yīng)用程序之間協(xié)調(diào)訪問。

我們建議復(fù)雜的組織在基礎(chǔ)設(shè)施中集中實現(xiàn)與解決方案相關(guān)的安全策略——也就是驗證用戶質(zhì)詢（如用戶 ID/密碼）、控制對應(yīng)用程序的訪問（如對 travelService 執(zhí)行 reserve() 方法），以及委派身份（如運行方式 travelAgency id），以確保方法一致。可在某些部署構(gòu)件（如 J2EE 應(yīng)用程序的部署描述符）中定義初始應(yīng)用程序安全策略。部署完畢后，熟悉大部分應(yīng)用程序邏輯時就可以向部署環(huán)境提供策略信息了?？蓪⒉呗月暶鞲爬ǔ筛呒壊呗砸?，以備將來細化成實現(xiàn)約束條件，這被認為是部署階段的工作。

應(yīng)用程序設(shè)計中引入了有關(guān)由基礎(chǔ)設(shè)施管理的安全與由應(yīng)用程序管理的安全的決策。安全約束和條件是附加到實現(xiàn)構(gòu)件的。決定是讓基礎(chǔ)設(shè)施處理安全，還是將安全轉(zhuǎn)換成應(yīng)用程序中的代碼的時機在實現(xiàn)階段，此時通?？梢缘玫接嘘P(guān)應(yīng)用程序平臺（如 Java? Platform Enterprise Edition (J2EE) 和 Microsoft? .NET）的信息。

我們建議將應(yīng)用程序的重點放在業(yè)務(wù)邏輯、延遲服務(wù)訪問的保護和送往基礎(chǔ)設(shè)施的消息（承載應(yīng)用程序的運行時容器）上。在這種由基礎(chǔ)設(shè)施管理的方法中，附加到設(shè)計構(gòu)件的安全策略將被轉(zhuǎn)換成特定于平臺的策略 [例如，通過統(tǒng)一建模語言（Unified Modeling Language，UML）模型表示的要求將轉(zhuǎn)換成 J2EE 部署描述符]。

在由應(yīng)用程序管理的方法中，安全實現(xiàn)是在應(yīng)用程序中實現(xiàn)的，必須實現(xiàn)相應(yīng)的安全調(diào)用。即使是由應(yīng)用程序管理的安全也必須通過 Java 身份驗證和授權(quán)服務(wù)（Java Authentication and Authorization Service，JAAS）將其安全調(diào)用（如 authenticate()）轉(zhuǎn)換成相應(yīng)的特定于平臺的功能[如 loginContext.login()]。

授權(quán)和訪問控制的粒度粗細不等。細粒度訪問（對于解決方案本身）與粗粒度訪問（對于其操作之一）的選擇通常取決于業(yè)務(wù)和技術(shù)考慮。粒度也會受各種因素的影響，包括信息實體的實例（如特定游客的信用帳戶概要信息）、上下文信息，如用戶特征（如旅行社）、時間約束（如從早上九點到下午五點）、訪問目的（如進行旅游預(yù)訂的目的）、訪問路徑（例如，內(nèi)部網(wǎng)請求與外部請求），以及許多其他因素。

可通過定義應(yīng)用程序角色概括與授權(quán)相關(guān)的策略，其中的角色是指一組通過其可對特定應(yīng)用程序資源執(zhí)行某些操作的權(quán)限。例如，旅行應(yīng)用程序可聲明對 ReservationBean 執(zhí)行的 view() 或 change() 預(yù)訂方法可由 TravelAgent 角色訪問。換句話說，TravelAgent 是由實現(xiàn)方案定義的角色，可以確定可由“旅行社”執(zhí)行的操作；根據(jù)一組用于對各自企業(yè) JavaBean（Enterprise JavaBean，EJB）調(diào)用特定方法的權(quán)限。在實現(xiàn)階段不大可能定義的是誰擁有 TravelAgent 特權(quán)。用戶到角色的指派通常是在部署時開始的，然后會在應(yīng)用程序的整個生命周期內(nèi)對其進行管理。清單 1 所示的是用于定義某些基于角色的方法權(quán)限的示例代碼。

												
														<method-permission>
<role-name>TravelAgent</role-name>
<method>
   <ejb-name>ReservationBean</ejb-name>
<method-permission>
<role-name>TravelAgent</role-name>
<method>
   <ejb-name>ReservationBean</ejb-name>
   <method-name> view</method-name>
   <method-name> change</method-name>
</method>
</method-permission>
			
												
										

在執(zhí)行某些業(yè)務(wù)邏輯之前要求提供通過身份驗證的身份信息的應(yīng)用程序必須從基礎(chǔ)設(shè)施中得到該信息。例如，在 J2EE 環(huán)境中，運行時會在身份驗證后確定用戶的身份；應(yīng)用程序可通過 API（如 getCallerPrincipal()）檢索此信息。

選擇的靈活性

客戶機運行時有時需要某些對訪問服務(wù)本身的要求或約束（包括身份驗證、完整性和機密性要求）。而支持各種客戶機運行時（如瀏覽器客戶機、非瀏覽器客戶機和 PDA 瘦客戶機）可能是令人滿意的。要支持各種客戶機運行時，請發(fā)布斷言客戶機運行時必須確保消息機密性，并必須提供用戶身份的證據(jù)（用戶 ID/密碼或證書）的策略。身份驗證的策略概括可列出替代選項，如可接受的憑據(jù)類型，或所信任的憑據(jù)頒發(fā)機構(gòu)。

例如，TravelService Web 服務(wù)可聲明其要求某些安全令牌類型的意圖和機密性要求。實現(xiàn)方案可通過描述符支持意圖聲明。工具則可進而生成必要的機器級詳細信息（如 WS-SecurityPolicy 表達式），如清單 2 所示。

												
														<wsp:Policy>
  <sp:SymmetricBinding>
    <wsp:Policy>
      <sp:ProtectionToken>
        <wsp:Policy>
          <sp:KerberosV5APREQToken
              sp:IncludeToken=".../IncludeToken/Once" />
        </wsp:Policy>
      </sp:ProtectionToken>
      <sp:SignBeforeEncrypting />
      <sp:EncryptSignature />
    </wsp:Policy>
  </sp:SymmetricBinding>
  <sp:SignedParts>
    <sp:Body/>
    <sp:Header
       Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
    />
  </sp:SignedParts>
  <sp:EncryptedParts>
    <sp:Body/>
  </sp:EncryptedParts>
</wsp:Policy>
			
												
										

安全工程

在開發(fā)安全解決方案的過程中，安全工程是最佳實踐之一——請遵循定義明確的模式，以使您的應(yīng)用程序、服務(wù)或組件可以完全實現(xiàn)其設(shè)計者和用戶的期望。您應(yīng)該估計每個實現(xiàn)方案構(gòu)件中固有的風險，對其進行設(shè)計和實現(xiàn)以防其暴露在弱點下（例如，高效的內(nèi)存管理并避免出現(xiàn)隱蔽的通道）。工具支持和代碼評審也有助于將對從中部署解決方案的環(huán)境的損害降到最低（或徹底避免）。

總結(jié)

SOA 編程模型必須確保每個服務(wù)調(diào)用都符合對請求者和服務(wù)端點均有效的安全策略。安全基礎(chǔ)設(shè)施（包括對請求者進行身份驗證和對其授予服務(wù)訪問權(quán)的能力、基于基本信任模型跨 Web 服務(wù)請求傳播安全上下文、審核重要事件，以及有效地保護數(shù)據(jù)和內(nèi)容）形成了有助于保護組件和服務(wù)的 SOA 環(huán)境的結(jié)構(gòu)。所有 SOA 安全的核心都是基于策略的基礎(chǔ)設(shè)施和策略的管理。在理想的情況下，SOA 應(yīng)用程序的重點在于業(yè)務(wù)邏輯、委派安全策略的實現(xiàn)，以及處理基礎(chǔ)設(shè)施的信任關(guān)系?；?Web 服務(wù)安全規(guī)范的 Web 服務(wù)安全模型和方法有助于解決保護面向服務(wù)的應(yīng)用程序的難題。

與語言無關(guān)、基于組件的面向服務(wù)的體系結(jié)構(gòu) (SOA) 編程模型簡化了實現(xiàn) Web 服務(wù)以及將其組裝到解決方案中的過程。使用編程模型，非編程人員可以在沒有掌握復(fù)雜的技術(shù)的情況下使用現(xiàn)有的 IT 資產(chǎn)。它滿足了解決方案設(shè)計人員和業(yè)務(wù)分析人員的需要，提供了更高級別的抽象來隱藏實現(xiàn)技術(shù)之間的差異，同時還提高了業(yè)務(wù)可靠性。

為什么需要基于組件的編程模型？

推動 IBM 的 SOA 編程模型的遠景依賴于兩個重要的觀察結(jié)果，請看以下兩段引言中的精辟描述：

“根據(jù)時髦詞語設(shè)計 (Design-by-buzzword) 是一種常見的情況。至少在軟件行業(yè)，這種行為或多或少與缺乏對一組給定的有用體系結(jié)構(gòu)約束的理解有關(guān)。換句話說，在選擇要重用的軟件體系結(jié)構(gòu)時，設(shè)計人員并沒有真正弄清楚這些體系結(jié)構(gòu)之所以好的原因?！?br />——Roy Thomas Fielding，“Architectural Styles and the Design of Network-based Software Architectures”（請參閱參考資料以獲得指向此研究報告的鏈接）。

這個問題可以通過將詳細了解體系結(jié)構(gòu)約束的原因的人的經(jīng)驗融入一組模式、編程構(gòu)件和工具來解決。

第二個重要的觀察結(jié)果同人以及人與技術(shù)的交互有關(guān)：

“創(chuàng)建面向服務(wù)的體系結(jié)構(gòu) (SOA) 意味著重新考慮當前用于構(gòu)建系統(tǒng)的實踐、組織的技能，以及團隊成員協(xié)作的方式。面向服務(wù)的作用在于通過組裝不同的應(yīng)用程序來開發(fā)解決方案，SOA 是體系結(jié)構(gòu)樣式，強調(diào)獨立服務(wù)提供者的松散耦合?！?br />——A.W. Brown 等，“Realizing service-oriented solutions with the IBM software development platform”（請參閱參考資料以獲得指向這篇文章的鏈接）。

基于 XML 的 Web 服務(wù)標準使人想到了基于組件的編程模型的某些方面。諸如 Web 服務(wù)互操作性 (WS-I)、Web 服務(wù)描述語言 (WSDL) 和 Web 服務(wù)策略 (WS-Policy) 之類的標準嘗試創(chuàng)建與平臺無關(guān)的抽象和統(tǒng)一的框架來進行業(yè)務(wù)軟件集成。而 Web 服務(wù)的價值來源于在 SOA 中使用它們。

大多數(shù)關(guān)于 Web 服務(wù)的資料都集中于互操作性協(xié)議和服務(wù)接口及其使用。而本文把重點放在用于實現(xiàn)服務(wù)并將服務(wù)組裝成解決方案的編程模型上。組件模型簡化了構(gòu)建和組裝服務(wù)的過程。

良好定義的組件應(yīng)該支持生態(tài)系統(tǒng)中的各種用戶角色——例如業(yè)務(wù)分析人員、集成開發(fā)人員、適配器開發(fā)人員和解決方案管理員——通過實例化、使用、組裝和自定義符合用戶目標、技能和概念性框架的不同組件類型，來創(chuàng)建面向服務(wù)的應(yīng)用程序。（注意：編程人員作為專業(yè)人員和重要的軟件開發(fā)角色仍然存在，但并非每個人都必須成為專業(yè)編程人員才能高效地使用 SOA 構(gòu)件。）

Web 服務(wù)標準中的組件模型明確地定義了組件和組件類型，以及定義和構(gòu)造組件的方式，以便由適合角色的工具重用和操作，這與我們對技術(shù)使用中人的方面的觀察結(jié)果是一致的。

基于組件的編程模型有許多好處，最顯著的好處是可以減少復(fù)雜性。沒有哪個角色需要了解實現(xiàn)功能的所有方式或所有的系統(tǒng)接口。公開給每個角色的復(fù)雜性是有限的，而公開給開發(fā)人員角色的復(fù)雜性有助于他們使用適合于其任務(wù)的工具以定義良好的方式開發(fā)解決方案。

組件模型必須是抽象的，并且與語言無關(guān)，因為它的作用在于隱藏技術(shù)細節(jié)和差異。

組件模型還必須簡化非編程人員組裝和定制“解決方案部分”的過程。因此，與組裝和調(diào)整有關(guān)的組件（或組件集合）的所有方面必須以與語言無關(guān)的方式顯式地聲明，這樣無需編程人員修改源代碼就可以通過工具操作它們。我們使用 XML 來表示這些聲明。

SOA 的確切特征還有待探討，不過一些關(guān)鍵的方面已經(jīng)得到廣泛承認：

1. SOA 是一種分布式組件 體系結(jié)構(gòu)。不管在企業(yè)內(nèi)部還是企業(yè)外部，SOA 組件都是透明的，并且可以通過一系列統(tǒng)一支持的、可互操作遠程過程調(diào)用和消息傳遞協(xié)議來統(tǒng)一訪問。接口定義標準支持開發(fā)人員工具之間的互操作性。網(wǎng)絡(luò)上 (on the wire) 協(xié)議互操作性——相對于代碼可移植性——是 SOA 組件的中心部分，支持統(tǒng)一訪問和平臺獨立。調(diào)用方不知道組件的基礎(chǔ)實現(xiàn)技術(shù)，例如 Java? 2 Platform、Enterprise Edition (J2EE)、Microsoft? .Net 和 PHP。
2. SOA 組件封裝功能，并支持通過業(yè)務(wù)分析人員和業(yè)務(wù)模型建模的抽象級別的重用。這使 IT 功能和它所支持的業(yè)務(wù)功能之間的映射更加直接，從而提高了可靠性。
3. 聲明性的、計算機可處理的約定允許第三方訪問 SOA 組件提供的服務(wù)。這些約定顯式地聲明功能性特征以及非功能性（服務(wù)質(zhì)量或 QoS）特征和需求。SOA 組件使用 WSDL 記錄它們的操作。還可以使用用于 Web 服務(wù)的業(yè)務(wù)流程執(zhí)行語言 (BPEL4WS) 來定義組件的有效操作序列。
4. 可以動態(tài)地發(fā)現(xiàn)、選擇、綁定（通過其聲明性屬性）和集成（使用組合機制，例如本系列第 3 部分“Process choreography and business state machines”（developerWorks，2005 年 7 月）中描述的組合機制）SOA 組件。

組件實現(xiàn)和專用組件類型

開發(fā)人員可以選擇使用 J2EE、PHP 或其他工具實現(xiàn)基本組件。作為一種編程模型，從根本上講，SOA 更多地關(guān)系到與組件的交互以及如何將這些交互集成到復(fù)合組件、應(yīng)用程序和解決方案。

我們的編程模型還引入了一些定義良好的組件類型，可以建模開發(fā)人員生產(chǎn)和部署到解決方案中的常見構(gòu)件。其中包括 Plain Old Java Objects (POJOs)、Business Processes (BPEL4WS)、Structured Query Language (SQL) 服務(wù)、Adaptive Business Objects、通過 J2EE Connector (J2C) 體系結(jié)構(gòu)資源適配器訪問的 Customer Information Control System (CICS) 程序、使用 SAP 的業(yè)務(wù)應(yīng)用程序編程接口的應(yīng)用程序、J2EE 無狀態(tài)會話 Bean 和 IBM MQSeries? 應(yīng)用程序。

因為在性質(zhì)上 SOA 組件模型是虛擬的，所以許多 SOA 組件自然支持多種實現(xiàn)技術(shù)。另一方面，不同的實現(xiàn)技術(shù)更好地適合于不同的任務(wù)。為了提高透明度，我們引入了服務(wù)組件類型的概念，每種類型都適合于具有特定技能、執(zhí)行特定任務(wù)和使用特定工具的開發(fā)人員。對于查詢，編程人員實現(xiàn)了一個 SQL 文件和一個包含一組 XQuery 語句的文件；對于文檔轉(zhuǎn)換，使用為此任務(wù)優(yōu)化的工具實現(xiàn) XSLT 樣式表等等。不需要知道 Web 服務(wù)、Enterprise JavaBean (EJB) 或其他組件是在部署時生成的，這是因為總體結(jié)果是作為通用 SOA 組件公開和使用的。

編程人員構(gòu)建一種適合于該任務(wù)的特定組件類型，集中于要解決的問題和要使用的工具，而不是結(jié)果構(gòu)件。SOA 開發(fā)工具應(yīng)該集中于開發(fā)人員的技能和他或她理解的概念。后續(xù)文章將簡要介紹一些組件類型，通過三個完全不同的示例——Java 對象、信息管理系統(tǒng) (IMS) 事務(wù)和 SQL 語句——演示如何將任何實現(xiàn)技術(shù)映射到公共 SOA 組件模型，同時滿足特定開發(fā)人員的需要。

組合

雖然可以使用特定于平臺的技術(shù)實現(xiàn) SOA 組合，但是新的以 SOA 為中心的組合類型可以自己實現(xiàn)，而無需轉(zhuǎn)換為另一種編程模型。

使用組合模型，可以發(fā)現(xiàn)具有所需的接口和所需的基礎(chǔ)設(shè)施 (QoS) 策略的服務(wù)，并且將這些服務(wù)聚合到新的服務(wù)、模塊和解決方案中。可以組合這些新的服務(wù)。

我們的方法統(tǒng)一了創(chuàng)建和訪問業(yè)務(wù)邏輯的范型。我們的 SOA 編程模型比現(xiàn)有的編程構(gòu)造復(fù)雜，隱藏了實現(xiàn)技術(shù)之間的不同。在這種模型中，組件組裝到模塊中，而模塊又可以組合到解決方案中。組件公開了可以通過可尋址接口調(diào)用的接口。接口是使用 WSDL、Java 或其他語言描述的。實現(xiàn)可能有無法解析的對所需服務(wù)的引用，這些服務(wù)是執(zhí)行之前由連接在一起的組件提供的。可以由解決方案集成人員或解決方案組裝人員使用適合于角色的工具進行連網(wǎng)操作，他們可以運用可能不為最初開發(fā)這些組件的人所知的企業(yè)策略和企業(yè)服務(wù)總線 (ESB) 部署拓撲知識來進行工作。

在沒有進行編程的情況下自定義

不可能始終在沒有進行配置、自定義或調(diào)整的情況下按原樣重用服務(wù)。在需要更改時，當前的技術(shù)發(fā)展水平是修改源代碼。然而，是否能夠交付可以大量重用的組件在很大程度上取決于組件適應(yīng)其使用環(huán)境的功能。SOA 編程模型應(yīng)該支持構(gòu)建“編程人員”可以在沒有修改源代碼的情況下進行自定義的服務(wù)和模塊。當使用組件的編程人員與構(gòu)建組件的編程人員不在一個單位時，這一點尤為重要。

基于組件的 SOA 編程模型提供了幾種在沒有進行編程的情況下自定義組件的機制。

旨在重用的組件可以打包成具有可變點 (points of variability) 的模板，在將模板放入解決方案時可以對其做一些調(diào)整。這種適應(yīng)性是我們的編程模型最重要的部分，此外，編程模型還包括規(guī)則語言和相關(guān)工具，用于給新的用戶提供自定義功能。

中介主要用于處理動態(tài)消息。通?？梢栽跊]有進行編程的情況下組合中介。作為一個多協(xié)議構(gòu)造，企業(yè)服務(wù)總線發(fā)揮了重要的作用，可以將服務(wù)組件組合在一起進行無縫交互，另外，還允許在消息的路徑中插入稱為中介 的組件，以在不改變現(xiàn)有端點的情況下代理服務(wù)之間的交互，從而在主要方面解決整個企業(yè)范圍內(nèi)的問題，例如審核、記錄、路由、不匹配接口的適應(yīng)性、等效組件的增量替換和安全性。

SOA 編程模型的另一個好處（來源于前面提到的特性）是能夠在軟件生命周期的不同階段用一個組件替換另一個組件。通過將聲明的接口延遲綁定到支持這些接口的實現(xiàn)可以做到這一點。企業(yè)為什么需要替換功能單元，有許多方面的原因。其中最重要的原因可能是減少在大型企業(yè)中管理更改的困難。以增量的方式引入更改并且通過遵循定義的接口限制其影響可以提高靈活性。這種做法也適合于松散耦合，而松散耦合常常是大型組織的特征。此外，使用服務(wù)組件，有不同的技能、需求和時間安排的組可以以人力資源和系統(tǒng)資源兩方面的效率都最高的方式在 IT 基礎(chǔ)設(shè)施中協(xié)同工作，這樣企業(yè)就可以快速地響應(yīng)業(yè)務(wù)級的更改，從而使企業(yè)大大獲益。

組件定義

我們的 SOA 是由以下規(guī)范定義的：

1. 服務(wù)規(guī)范 以組件提供和使用的一組服務(wù)的形式提供了組件的視圖。它由以下三組規(guī)范定義：
   • 接口，通常是 WSDL portTypes。
   • 策略，記錄 QoS 屬性，例如事務(wù)行為和安全性。
   • 行為描述，例如 BPEL4WS 抽象流程。另一個例子可能是統(tǒng)一建模語言 V2 (UML2) 狀態(tài)模型，該模型指定了哪些操作對不同的狀態(tài)和操作所引發(fā)的狀態(tài)事務(wù)是有效的。調(diào)用方可以通過狀態(tài)模型計算有效的操作序列。
2. 服務(wù)組件實現(xiàn) 是由以下四組規(guī)范定義的：
   • 提供的服務(wù)規(guī)范。
   • 需要的服務(wù)規(guī)范。
   • 可以在組件上設(shè)置以調(diào)整或自定義的屬性。
   • 為此提供基本支持的屬性；更復(fù)雜的方案使用可變點和對自定義組件的外部調(diào)用。
   • 對所有實現(xiàn)實例都保持不變的容器指示（策略）。
   • 定義組件實現(xiàn)的實現(xiàn)構(gòu)件（例如 Java 類、BPEL 文檔或 XSLT 規(guī)則集）。
3. 服務(wù)組件（實例）由以下規(guī)范定義：
   • 名稱。
   • 服務(wù)組件實現(xiàn)。
   • 實現(xiàn)的任何屬性的值，設(shè)置用于調(diào)整實例。
   • 任何服務(wù)的規(guī)范，解析實現(xiàn)需要的服務(wù)規(guī)范。它們可以是連接組件實例的“網(wǎng)絡(luò)”，也可以是在運行時執(zhí)行以查找組件的“查詢”，所查找的組件實現(xiàn)相關(guān)接口，具有相關(guān)的 QoS 策略，并且匹配指定的行為（例如抽象流程或狀態(tài)模型）。

有兩種定義 SOA 組件的基本方法。這些定義可以通過開發(fā)工具生成，也可以由開發(fā)人員手動創(chuàng)建。

第一種方法是控制文件，顧名思義，控制文件即關(guān)聯(lián)或聯(lián)接組件的所有部分的文檔。例如，控制文件可以引用 WSDL 定義（提供的接口）、實現(xiàn)組件的 Java 類（實現(xiàn)構(gòu)件）或相關(guān)的策略文檔（策略斷言）。 它們可以是對文件系統(tǒng)、類路徑、源代碼管理系統(tǒng)或 Web URL 的引用?？刂莆募椒▽⒍鄠€單獨開發(fā)的構(gòu)件聚合在一起組成組件。應(yīng)用程序開發(fā)工具可以幫助定義控制文件。

第二種方法是使用 pragmas，指定相同信息的語言元素，但是包含在單個源文件的主體中。Java 方面的支持正在不斷增加（例如，JSR 175 中的 XDoclet 標記），以用 Java 語言編寫這些批注部分。但是這種方法尚不支持其他等同的有效 SOA 組件實現(xiàn)技術(shù)（如 SQL 或 XQuery 語句集）。每種組件類型都有用于其實現(xiàn)構(gòu)件的相關(guān)源文件格式，例如 Java 文件、狀態(tài)機或 SQL 文件。IBM WebSphere? Rapid Deployment 中的批注支持可以生成所有組成包含 pragmas 的源文件中的組件的單個元素。例如，Java 源文件中的結(jié)構(gòu)化注釋指示哪些 Java 方法將成為所生成的定義組件的服務(wù)接口中的 Web 服務(wù)操作。

總結(jié)

基于組件的編程模型——由面向任務(wù)的工具和運行時基礎(chǔ)設(shè)施支持——是快速采用 SOA 的關(guān)鍵。借助于期望的優(yōu)勢（如新的軟件重用方法），專業(yè)人員（不必是編程人員）可以在新的業(yè)務(wù)需求出現(xiàn)時使用 SOA 組件創(chuàng)建新的業(yè)務(wù)解決方案和改寫現(xiàn)有的業(yè)務(wù)解決方案。

您是否希望了解如何使用 XML 二進制優(yōu)化打包 (XOP) 規(guī)范來優(yōu)化 Web 服務(wù)應(yīng)用程序？Judith M. Myerson 將向您展示在處理 Web 服務(wù)時，XOP 包比 XML 解析器更有效的原因。她將討論在多 SOA 中 Web 服務(wù)變得過于龐大的兩個場景。為了解決此問題，她討論了 XOP 包可以如何比 XML 解析器更為有效地處理二進制（而非文本）格式的大型文件。她給出了 XOP 處理前后的代碼示例，以幫助開發(fā)人員了解需要更改哪些元素。

引言

在本系列的第 2 部分中，我討論了可以如何實現(xiàn)原始應(yīng)用程序 Web 服務(wù)的業(yè)務(wù)流程并確定系統(tǒng)可以承載的可互操作 SOA 的最大個數(shù)，以避免 SOA 過載。在本系列的第 5 部分中，我強調(diào)了將業(yè)務(wù)流程規(guī)則作為優(yōu)化 Web 服務(wù)的首要事項的重要性，并給出了一些示例，以說明可以如何減少 Web 請求的數(shù)量和執(zhí)行時間。

在這一部分中，我將討論基于 XML 的 Web 服務(wù)應(yīng)用程序是如何變得過于龐大的。當大量使用 Web 服務(wù)時，這些 Web 服務(wù)將阻塞網(wǎng)絡(luò)通信，從而導(dǎo)致系統(tǒng)過載。為了解決此問題，我將討論可以如何應(yīng)用 XML 二進制優(yōu)化打包 (XOP) 規(guī)范（請參閱參考資料）來加速 Web 服務(wù)。

此標準草案旨在比當前 XML 解析器更有效地處理 Web 服務(wù)。解析器的行為更像解釋器，而不是編譯器。當解析器讀寫大型文件（特別是文本格式的大型文件）時，并不能達到其讀取較小的文件或計算簡單函數(shù)時的性能。甚至加密也可能使 Web 服務(wù)陷于停頓，因為必須執(zhí)行復(fù)雜的計算才能獲得希望的結(jié)果。

兩個場景

我在第 2 部分中提到，從企業(yè)應(yīng)用程序提取組件，然后將其重新構(gòu)造為外部 Web 服務(wù)，這種做法更為恰當。如果這樣，您就可以更改 Web 服務(wù)中的代碼，而不用重新設(shè)計并編譯長時間運行的大型復(fù)雜應(yīng)用程序。

第一個 SOA 中經(jīng)過重新設(shè)計而顯得更加緊湊的應(yīng)用程序（請參見圖 1）可以通過發(fā)送 Web 請求來與第二個 SOA 中的外部企業(yè) MRP（托管資源原型）Web 服務(wù)進行動態(tài)鏈接。而 MRP Web 服務(wù)又指向第三個 SOA 中的外部企業(yè) CRM Web 服務(wù)。客戶關(guān)系管理 (CRM) Web 服務(wù)隨后將請求和信息發(fā)送到該應(yīng)用程序以進行進一步處理。

讓我們假定在任何給定時間都可能出現(xiàn)對多個基于 XML 的 Web 服務(wù)的多個 Web 請求。鏈接到其他遺留系統(tǒng)或大型企業(yè)系統(tǒng)的企業(yè)應(yīng)用程序未在上圖中顯示，而這些系統(tǒng)又與接收多個 Web 請求的多個 Web 服務(wù)鏈接。當大量使用時，Web 服務(wù)會變得過于龐大，從而阻塞網(wǎng)絡(luò)通信。

一個解決方案就是向基于 XML 的 MRP 和 CRM Web 服務(wù)應(yīng)用 XOP 包（請參見圖 2），從而以二進制格式進行處理。

在第二個場景中，可以首先開發(fā)業(yè)務(wù)流程規(guī)則，然后開發(fā)根據(jù)現(xiàn)有 Web 服務(wù)構(gòu)建新的 Web 服務(wù)所需的基于 XML 的 Web 請求。如果新的 Web 服務(wù)（業(yè)務(wù)邏輯 Web 服務(wù)或以數(shù)據(jù)為中心的 Web 服務(wù)）可以提供更好的或額外的服務(wù)和功能，則必須減少或完全消除冗余的 Web 請求、執(zhí)行時間、訪問時間和帶寬。

問題在于，當創(chuàng)建新的 Web 服務(wù)并大量使用時，它們將會變得過于龐大。與第一個場景類似，您需要將 XOP 包應(yīng)用于 Web 服務(wù)。對于這兩個場景，您都需要與系統(tǒng)管理員協(xié)作，以確定在不引起系統(tǒng)過載的情況下可以使用 XOP 包的 Web 服務(wù)的最大數(shù)目。

XOP 處理前的 Infoset

為了理解 XOP 的工作方式，我將首先討論一個與 SOAP 消息相似的 XML Infoset，其中描述了包含一張圖片和一個簽名的 XML 文檔。在清單 1 中，我使用粗體來突出顯示原始 XML Infoset，以說明哪些原始元素在 XOP 處理之前。

												
																		

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope' 
    xmlns:xop='http://www.w3.org/2003/12/xop/include' 
    xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
    
      
														
																
																		
																				<m:photo xmlmime:content-type='image/png'>
        /aWKKapGGyQ=
      </m:photo>
      <m:sig xmlmime:content-type='application/pkcs7-signature'>
        Faa7vROi2VQ=
      </m:sig>
																		`
      
    </m:data>
  </soap:Body>
</soap:Envelope>
  

														
												
										

正如您所看到的，其中有兩個元素：m:photo 和 m:sig。m:photo 元素采用 base64 編碼的內(nèi)容為 /aWKKapGGyQ=，而 m:sig 元素采用 base64 編碼的內(nèi)容為 Faa7vROi2VQ=。這些元素也稱為元素信息項。內(nèi)容是元素的子項。請將該元素當作此子項的父項。子項是字符信息項，即包含字母數(shù)字字符的項。例如，m: photo 是子項 /aWKKapGGyQ= 的父項。該子項的名稱不便閱讀且難于發(fā)音，很容易出現(xiàn)鍵入錯誤。

當通過 XOP 處理放置 XML Infoset 時，可以解決此問題。XOP 的工作方式是：從原始 Infoset 提取優(yōu)化內(nèi)容，然后創(chuàng)建 XOP Infoset。優(yōu)化內(nèi)容是我剛剛談到的經(jīng)過縮減的內(nèi)容。在清單 2 中，我突出顯示了要刪除的內(nèi)容。

												
																		

<m:photo xmlmime:content-type='image/png'>
        /aWKKapGGyQ=
      </m:photo>
      <m:sig xmlmime:content-type='application/pkcs7-signature'>`
        Faa7vROi2VQ=
      </m:sig>


												
										

XOP 處理后的 Infoset

XOP 處理涉及到三個步驟。第一步，使用 Infoset 中的二進制元素替換文本元素。第二步，在包含已替換元素的 Infoset 前添加 MIME 包。第三步，在該 Infoset 后添加另一個包。

第 1 步：替換元素

XOP 包使用名為 xop:Include 的新元素信息項來替換刪除的內(nèi)容。xop: Include 元素包含一個屬性信息項，帶有指向 XOP 包部分的鏈接，XOP 包承載從原始元素中刪除的數(shù)據(jù)的二進制表示。在清單 3 中，我突出顯示了替換原始 Infoset 中的圖片和簽名元素的內(nèi)容的 xop: Include。

												
																		
 <m:photo xmlmime:content-type='image/png'>
        <xop:Include href='cid:http://example.org/me.png'/>
      </m:photo>
      <m:sig xmlmime:content-type='application/pkcs7-signature'>
        <xop:Include href='cid:http://example.org/my.hsh'/>
      </m:sig>
       
 
												
										

正如您所看到的， href='cid:http://example.org/me.png'/ 是圖片元素的屬性信息項，而 href='cid:http://example.org/my.hsh' 是簽名元素的屬性信息項。

更新 Infoset 部分（請參見清單 4）。而行數(shù)保持不變。

												
																		
<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xop='http://www.w3.org/2003/12/xop/include'
    xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo xmlmime:content-type='image/png'>
        <xop:Include href='cid:http://example.org/me.png'/>
      </m:photo>
      <m:sig xmlmime:content-type='application/pkcs7-signature'>
        <xop:Include href='cid:http://example.org/my.hsh'/>
      </m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

												
										

第 2 步：在 Infoset 前添加 MIME 包

為了完成更新，需要使用 MIME Multipart/Related 包中的 XOP 對原始 Infoset 進行序列化。XOP 是一種更有效的方法，用于序列化包含特定類型的 Xquery 和 Xpath 2.0 元素內(nèi)容的 XML Infoset。

在更新后的 Infoset 前后各添加一個 MIME 包，以分別描述包含文本格式和二進制格式的圖片和簽名的 XML 文檔。在清單 5 中，我突出顯示了 XOP 包識別 8 位文本格式的 XML Infoset 的代碼。

												
																		
 MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
	      type=text/xml;start="<mymessage.xml@example.org>"
Content-Description: An XML document with my picture and signature in it

--MIME_boundary

														
																
																		
																				Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
																		
Content-ID: mymessage.xml@example.org

 
														
												
										

第 3 步：在 Infoset 后添加 MIME 包。

清單 6 顯示了 XOP 包如何識別已被刪除的數(shù)據(jù)的二進制表示。

												
																		
  --MIME_boundary

														
																
																		
																				Content-Type: image/png
Content-Transfer-Encoding: binary
																		
Content-ID: <http://example.org/me.png>

// binary octets for png

--MIME_boundary

														
														
																
																		
																				Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
																		
Content-ID: <http://example.org/my.hsh>

// binary octets for signature

--MIME_boundary--
      
  
														
												
										

正如您所看到的，Infoset 后的 Content-ID 的二進制內(nèi)容，xop: Include element 中提到的鏈接代替了 Infoset 前的消息的文本內(nèi)容。

最終結(jié)果

在清單 7 給出了序列化為 XOP 包的整個 XML Infoset。盡管其中還有其他行，但是此包比原始 Infoset 的 XML 解析器的效率高得多。

												
																		

MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
	      type=text/xml;start="<mymessage.xml@example.org>"
Content-Description: An XML document with my picture and signature in it

--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xop='http://www.w3.org/2003/12/xop/include'
    xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo xmlmime:content-type='image/png'>
        <xop:Include href='cid:http://example.org/me.png'/>
      </m:photo>
      <m:sig xmlmime:content-type='application/pkcs7-signature'>
        <xop:Include href='cid:http://example.org/my.hsh'/>
      </m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>

// binary octets for png

--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>

// binary octets for signature

--MIME_boundary--
        

												
										

結(jié)束語

為了運行具有 XOP 包的 Web 服務(wù)，需要事先進行計劃，以確定應(yīng)該如何設(shè)計應(yīng)用程序，從而避免高峰時過載。應(yīng)該就優(yōu)化 Web 服務(wù)時應(yīng)采用何種編碼技術(shù)與系統(tǒng)管理員團隊進行溝通。

您會發(fā)現(xiàn)解決這些問題后，您的 Web 服務(wù)應(yīng)用程序優(yōu)化工作變得容易得多。您可以使用 IBM Relational Web Developer for WebSphere? Software 來開發(fā)基于業(yè)務(wù)流程的 Web 服務(wù)，然后在 SOA 內(nèi)部及各個 SOA 之間將其與 XOP 包一起使用。管理員會發(fā)現(xiàn)，解決了這些問題也使得他們的網(wǎng)絡(luò)管理工作變得更加輕松。他們能確定在不引起系統(tǒng)過載的前提下，可以將多少應(yīng)用程序與 XOP 包一起使用。

您希望了解 SOA 內(nèi)服務(wù)器間 Web 服務(wù)應(yīng)用程序的負載平衡么？在本文中，Judith M. Myerson 與我們一起探討了用戶在高峰流量期間所需求的快速響應(yīng)的重要性，并且列舉了一些負載平衡技術(shù)的示例。此外，她還與我們一起探討了負載平衡工具——WebSphere? Application Server 和 WebSphere Edge Server，開發(fā)人員、系統(tǒng)管理員和網(wǎng)絡(luò)管理員可以使用這些工具在服務(wù)器間平衡 Web 服務(wù)應(yīng)用程序的負載，從而確保網(wǎng)絡(luò)在高峰流量期間保持高性能、高可靠性和高可用性。

引言

在本系列第 4 部分“使用 Rational 開發(fā)工具構(gòu)建 SOA 中間件應(yīng)用程序”（請參閱參考資料）一文中，我講解了如何使用 Web 開發(fā)工具創(chuàng)建 SOA 中間件應(yīng)用程序。在本系列第 5 部分“使用 WebSphere Business Integration 工具優(yōu)化 Web 服務(wù)應(yīng)用程序”（請參閱參考資料）一文中，我講解了如何使用業(yè)務(wù)流程工具集成和優(yōu)化 Web 服務(wù)應(yīng)用程序。在第 5 部分，我還講解了減少 Web 請求數(shù)量、執(zhí)行時間、訪問時間和帶寬量的方法，這些方法都可以用來優(yōu)化 Web 服務(wù)應(yīng)用程序。

在本文中，我介紹了負載應(yīng)用程序的某些問題如何影響了 Web 服務(wù)應(yīng)用程序間的互操作方式。文中包含了一個流量瓶頸的實例，導(dǎo)致該瓶頸的原因是：在特定期間有太多的訪問者基于業(yè)務(wù)流程發(fā)送了太多的請求到一個 Web 服務(wù)應(yīng)用程序。接著又講了如何從負載平衡技術(shù)中獲益。

請記住，Web 請求與訪問者的請求是不同的。Web 請求的數(shù)量不僅依賴于訪問者的請求數(shù)量，也依賴于由訪問者請求生成的、已優(yōu)化的 Web 請求的類型和內(nèi)容。

響應(yīng)遲緩

為了更好地認清這種差異，請看接下來的這個實例。如果某個訪問者在將請求通過 Web 服務(wù)發(fā)送到一臺服務(wù)器后等了很久才得到回復(fù)，那么該訪問者很可能為了獲得更快的響應(yīng)時間而轉(zhuǎn)向使用另一種 Web 服務(wù)或網(wǎng)站。該始發(fā)端 Web 服務(wù)將處理傳入的訪問者請求，以生成并優(yōu)化傳輸?shù)侥繕?Web 服務(wù)的 Web 請求。

始發(fā)端 Web 服務(wù)響應(yīng)遲緩，可能表明目標服務(wù)器繁忙，或是沒有足夠的系統(tǒng)空間來處理多個訪問者請求（多線程處理）。處理這種負載問題的方法之一是平衡服務(wù)器間的負載，這樣訪問者就不會為得到答復(fù)而等待太久。這種技術(shù)稱為負載平衡。

加快響應(yīng)

平衡服務(wù)器間負載要優(yōu)于外包 Web 服務(wù)，負載平衡技術(shù)不僅全面考慮到增加的服務(wù)器容量、改善的站點設(shè)計和使用獨立磁盤冗余陣列（Redundant Array of Independent Disk，RAID）的能力，而且也提供了處理預(yù)期高峰流量所需的帶寬。在服務(wù)器的長期運行中，它們會消耗更多的服務(wù)器資源。通過使用負載平衡技術(shù)，我們有更好的機會來提高服務(wù)器的性能和可靠性，并同時減少帶寬量、執(zhí)行時間和訪問時間（假定服務(wù)器中包含故障轉(zhuǎn)移機制 ）。

由于上述原因，負載平衡技術(shù)成為了大多數(shù)公司在處理大流量時（尤其在高峰流量期間經(jīng)受服務(wù)器停滯時）的首選技術(shù)。這些公司希望更快地響應(yīng)用戶需求，從而在較短的時間內(nèi)完成更多的工作任務(wù)。

您可以將負載路由到域名系統(tǒng)中不同的服務(wù)器主機地址，或者將一臺服務(wù)器要處理的工作總量分攤到兩臺或多臺服務(wù)器上。您不僅需要使用另外一臺服務(wù)器智能化地選擇出將工作分配給哪臺服務(wù)器，還需要使用故障轉(zhuǎn)移和備份服務(wù)將這些服務(wù)器聯(lián)合到一起，以防某臺服務(wù)器出現(xiàn)故障（尤其當服務(wù)器集散于不同地理位置時）。

類比購物車

作為一個類比，請把負載平衡服務(wù)器看為超市的 4 個付款臺。讓我們瞧瞧超市是如何在 4 個付款臺間實現(xiàn)“負載平衡”的。

假設(shè)您排在 1 號付款臺前的長隊中，您可以粗略地估算出大概需要多久時間才能排到自己付款。如果您發(fā)現(xiàn)這條隊伍移動緩慢，而且此時看到一名收銀員走向 4 號付款臺打開機器準備工作，那您一定會推著購物車快速地跑到 4 號付款臺（請參見圖 1）。

接著又有一名收銀員打開了 3 號付款臺，并揮手示意第一隊排在您前面的購物者到 3 號付款臺排隊。這些購物者當然會移到 3 號付款臺。2 號付款臺此時仍然保持關(guān)閉狀態(tài)。

減少服務(wù)時間

讓我們看看另一種負載平衡方式。如果您推著一輛滿滿的購物車，里面裝著您一家十口一個月的雜貨，您可能希望將貨物分給多個付款臺結(jié)帳。在沒有家人陪同的情況下，這種想法尤為強烈。您可以將購物車中的物品分為幾份，然后分從幾個清閑可用的付款臺結(jié)帳，這樣就減少了付款時間。

雖然這在實際生活中是不可能的，但您可以使用負載平衡器實現(xiàn)類似的目的，它能把在線購物車（Web 服務(wù)應(yīng)用程序）的請求從繁忙的服務(wù)器上轉(zhuǎn)移到其他清閑可用的服務(wù)器上（請參見圖 2）。如果其他服務(wù)器通過優(yōu)化可以滿足服務(wù)需求，就沒必要再啟用新服務(wù)器。

問題

您該怎樣解決該問題？更快地跑到付款臺前（增加帶寬）？增加付款臺數(shù)量（增加服務(wù)器容量）？找其他人幫您買（外包）？這些方法都不適用。

請您回答以下這些問題：

• 您將要平衡哪種應(yīng)用程序的負載？
• 在整個分布式網(wǎng)絡(luò)中，該應(yīng)用程序是否為長期運行？
• 一臺服務(wù)器或一個服務(wù)器集群超時接收了多少請求？
• 在高峰流量期間，需要多少流量和帶寬量？
• 怎樣利用服務(wù)器平衡應(yīng)用程序負載？
• 在不同時段，預(yù)計有多少訪問者？
• 訪問者最多能夠發(fā)送多少請求？

在您答完這些問題后，請與一名網(wǎng)絡(luò)管理員或系統(tǒng)管理員檢查和整理這些答案，以促進相互了解。然后使用某種算法、技術(shù)或工具開發(fā)一個負載平衡程序，實現(xiàn)將繁忙的服務(wù)器上的訪問者和 Web 請求重定向到清閑可用的服務(wù)器上。

負載平衡技術(shù)

負載平衡技術(shù)包括以下幾種：

• 簡單路由
• DNS Round Robin
• 復(fù)雜算法
• 智能路由

由于實際工作中的流量需要按優(yōu)先級處理，所以在開發(fā) Web 服務(wù)應(yīng)用程序時，請考慮上述技術(shù)中的最后兩種技術(shù)。因為包含要求更快響應(yīng)的服務(wù)器和訪問者的分布式網(wǎng)絡(luò)正在不斷地擴張。由于前兩種技術(shù)不需要按流量的優(yōu)先級進行處理，所以我們將不在有關(guān)流量瓶頸的問題中討論它們。

當您使用復(fù)雜算法時，分發(fā)請求是基于服務(wù)器性能、服務(wù)器使用的硬件種類和處理客戶優(yōu)先級的方法等等。這表明，最快的服務(wù)器將獲得更多具有最高客戶優(yōu)先級的請求。智能路由基于請求的內(nèi)容和（在始發(fā)端服務(wù)器發(fā)生故障時）流量重定向到另一臺服務(wù)器的方式。

基于服務(wù)器的軟件

雖然您可以使用軟件、硬件或兩者來達到負載平衡，但您最好還是在應(yīng)用程序服務(wù)器集群上使用基于服務(wù)器的軟件?；诜?wù)器的軟件的價格要遠低于基于硬件的專用服務(wù)器。硬件升級的價格要遠高于相應(yīng)軟件升級的價格。

在將基于服務(wù)器的軟件添加到網(wǎng)絡(luò)中之前，請檢查網(wǎng)絡(luò)是否配置正確，負載平衡器是否“靈活”。“靈活”在這里的解釋是：雖然負載平衡器可能已為目前的 Web 服務(wù)應(yīng)用程序做好了充分的配置，但它還必須能夠通過擴展?jié)M足未來應(yīng)用程序的需求。

IBM WebSphere Application Server 就是一款基于服務(wù)器的軟件，它在負載平衡和故障轉(zhuǎn)移中同時使用了復(fù)雜算法和智能路由。它的負載平衡器有能力根據(jù) Web 服務(wù)應(yīng)用程序的未來需求進行擴展。您需要為負載平衡建立一個服務(wù)器集群，并測試其故障轉(zhuǎn)移機制（請參閱參考資料）。

面向多平臺的 WebSphere Edge Server V2.0 是另一款基于服務(wù)器的軟件。它專門設(shè)計用于改善服務(wù)器選擇、負載優(yōu)化和容錯。它還附帶了網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation，NAT）和用于 Cisco CSS 交換機的 WebSphere Edge Server Consultant，并且支持內(nèi)核級的基于內(nèi)容路由（Content Based Routing，CSR）。（請參閱參考資料）

結(jié)束語

Web 服務(wù)應(yīng)用程序的負載平衡需要提早計劃，以確定在高峰流量期間如何在服務(wù)器間平衡負載。在設(shè)計 Web 服務(wù)的過程中，請多與系統(tǒng)管理員交流負載平衡技術(shù)相關(guān)的問題。

解決這些問題能使您更容易地創(chuàng)建負載平衡的 Web 服務(wù)應(yīng)用程序。您可以在 SOA 內(nèi)部（或跨 SOA）基于業(yè)務(wù)流程開發(fā) Web 服務(wù)和平衡 Web 服務(wù)負載。解決這些問題還能使管理員更容易地平衡 Web 服務(wù)應(yīng)用程序的負載，并確定在 SOA 中使用哪種負載平衡方法，以及能夠平衡多少應(yīng)用程序的負載。

SOA(Service-Oriented Architecture)，即面向服務(wù)的架構(gòu)，這是最近一兩年出現(xiàn)在各種技術(shù)期刊上最多的詞匯了?，F(xiàn)在有很多架構(gòu)設(shè)計師和設(shè)計開發(fā)人員簡單的把SOA和Web Services技術(shù)等同起來，認為SOA就是Web Service的一種實現(xiàn)。本質(zhì)上來說，SOA體現(xiàn)的是一種新的系統(tǒng)架構(gòu)，SOA的出現(xiàn)，將為整個企業(yè)級軟件架構(gòu)設(shè)計帶來巨大的影響。本系列兩部分文章將根據(jù)作者自己的理解來幫助大家分析和了解什么是SOA架構(gòu)，SOA將怎樣對企業(yè)系統(tǒng)架構(gòu)設(shè)計帶來積極的影響，什么是SOA架構(gòu)設(shè)計師的角色，以及SOA架構(gòu)師在設(shè)計SOA系統(tǒng)架構(gòu)時有哪些應(yīng)該特別注意的地方。

1. 什么是架構(gòu)？什么是基于SOA的架構(gòu)？

1．1 什么是架構(gòu)

從架構(gòu)設(shè)計師的角度來看，架構(gòu)就是一套構(gòu)建系統(tǒng)的準則。通過這套準則，我們可以把一個復(fù)雜的系統(tǒng)劃分為一套更簡單的子系統(tǒng)的集合，這些子系統(tǒng)之間應(yīng)該保持相互獨立，并與整個系統(tǒng)保持一致。而且每一個子系統(tǒng)還可以繼續(xù)細分下去，從而構(gòu)成一個復(fù)雜的企業(yè)級架構(gòu)。

當一名架構(gòu)設(shè)計師在構(gòu)建某個企業(yè)級的軟件系統(tǒng)時，除了要考慮這個系統(tǒng)的架構(gòu)以及其應(yīng)具有的功能行為以外，還要關(guān)注整個架構(gòu)的可用性，性能問題，容錯能力，可重用性，安全性，擴展性，可管理維護性，可靠性等各個相關(guān)方面。有的時候一名好的架構(gòu)設(shè)計師甚至還需要考慮所構(gòu)建的系統(tǒng)架構(gòu)是否合乎美學(xué)要求。由此我們可以看到，我們衡量一個好的架構(gòu)設(shè)計并不能只從功能角度出發(fā)，還要考慮很多其他的因素，對任何一個方面的欠缺考慮都有可能為整個系統(tǒng)的構(gòu)建埋下隱患。

1．2 什么是基于SOA的架構(gòu)

SOA本身就是一種面向企業(yè)級服務(wù)的系統(tǒng)架構(gòu)，簡單來說，SOA就是一種進行系統(tǒng)開發(fā)的新的體系架構(gòu)，在基于SOA架構(gòu)的系統(tǒng)中，具體應(yīng)用程序的功能是由一些松耦合并且具有統(tǒng)一接口定義方式的組件（也就是service）組合構(gòu)建起來的。因此，基于SOA的架構(gòu)也一定是從企業(yè)的具體需求開始構(gòu)建的。但是，SOA和其它企業(yè)架構(gòu)的不同之處就在于SOA提供的業(yè)務(wù)靈活性。業(yè)務(wù)靈活性是指企業(yè)能對業(yè)務(wù)變更快速和有效地進行響應(yīng)、并且利用業(yè)務(wù)變更來得到競爭優(yōu)勢的能力。對企業(yè)級架構(gòu)設(shè)計師來說，創(chuàng)建一個業(yè)務(wù)靈活的架構(gòu)意味著創(chuàng)建一個可以滿足當前還未知的業(yè)務(wù)需求的IT架構(gòu)。

利用基于SOA的系統(tǒng)構(gòu)建方法，如圖1中所示的一樣，一個基于SOA架構(gòu)的系統(tǒng)中的所有的程序功能都被封裝在一些功能模塊中，我們就是利用這些已經(jīng)封裝好的功能模塊組裝構(gòu)建我們所需要的程序或者系統(tǒng)，而這些功能模塊就是SOA架構(gòu)中的不同的服務(wù)（services）。

因此，SOA架構(gòu)本質(zhì)上來說體現(xiàn)了一種復(fù)合的概念：它不僅為一個企業(yè)中商業(yè)流程的組織和實現(xiàn)提供了一種指導(dǎo)模式，同時也為具體的底層service開發(fā)提供了指導(dǎo)。

2. SOA架構(gòu)設(shè)計師的角色

2．1 SOA架構(gòu)設(shè)計師應(yīng)該具備什么？

談到SOA架構(gòu)設(shè)計師的角色，我們首先要了解架構(gòu)設(shè)計師應(yīng)具有的能力?？傮w上來說，一個好的架構(gòu)設(shè)計師不僅應(yīng)該是一個成熟的，具有實際經(jīng)驗的并具有快速學(xué)習能力的人，而且他還應(yīng)該具有良好的管理能力和溝通能力。只有具備了必需的能力，架構(gòu)設(shè)計師才能在關(guān)鍵的時刻作出困難的決定，這就是一名架構(gòu)設(shè)計師應(yīng)該承擔的責任。從角色上來看，SOA 架構(gòu)師不僅會負責端到端的服務(wù)請求者和提供者的設(shè)計，并且會負責對系統(tǒng)中非功能服務(wù)請求的調(diào)研和表述。

對于任何一名經(jīng)驗豐富的架構(gòu)設(shè)計師來說，不論他是采用基于傳統(tǒng)的架構(gòu)設(shè)計方法（基于J2EE架構(gòu)或者.NET架構(gòu)）還是采用基于SOA的架構(gòu)設(shè)計方法來構(gòu)建一個企業(yè)級的系統(tǒng)架構(gòu)，具有相關(guān)商業(yè)領(lǐng)域的知識對于架構(gòu)設(shè)計師來說都是必不可少的，架構(gòu)設(shè)計師往往可以通過實際的工作經(jīng)驗積累以及接受相關(guān)的專項培訓(xùn)來獲得這些商業(yè)領(lǐng)域的知識。除了具有相關(guān)商業(yè)領(lǐng)域的知識以外，一名合格的架構(gòu)設(shè)計師必須具有較廣泛的技術(shù)背景，這可能包括軟硬件，通信，安全等各個方面的知識。但這并不是意味著要成為一名架構(gòu)設(shè)計師就必須熟悉每一門具體技術(shù)的細節(jié)，架構(gòu)設(shè)計師必須至少能對各種技術(shù)有一個整體上的了解，能夠熟知每種技術(shù)的特點以及優(yōu)缺點，只有這樣架構(gòu)設(shè)計師才能在特定的應(yīng)用場景下正確地選擇各種技術(shù)來設(shè)計企業(yè)整體架構(gòu)。

2．2 什么是SOA架構(gòu)設(shè)計師的職責？

那什么是企業(yè)級SOA架構(gòu)設(shè)計師的具體角色呢？什么是SOA架構(gòu)設(shè)計師與設(shè)計和開發(fā)人員之間的差別呢？相信這些都是使大家最容易產(chǎn)生迷惑的問題。舉個實際的例子來說，當構(gòu)建一個基于SOA架構(gòu)的系統(tǒng)的時候，針對一個具體的 service，系統(tǒng)設(shè)計人員主要應(yīng)該關(guān)注的是這個service能夠為外部用戶提供什么樣的服務(wù)，也就是說系統(tǒng)設(shè)計人員關(guān)注的是這個service所提供的功能。而對于SOA架構(gòu)設(shè)計師來說，他們更關(guān)心的可能是當有一千個用戶同時調(diào)用這個 service的時候，什么會發(fā)生？也就是說架構(gòu)設(shè)計師關(guān)注的應(yīng)該是一些商業(yè)需求和服務(wù)級別（service-level）需求。所有的架構(gòu)設(shè)計師的角色都包含了在構(gòu)建一個系統(tǒng)的一開始就應(yīng)該盡量減少可能存在的技術(shù)風險。而技術(shù)風險一般指的是一切未知的、未經(jīng)證明的或未經(jīng)測試所帶來的風險。這些風險通常與服務(wù)級別（service-level）需求相關(guān)，偶爾也會與企業(yè)具體的業(yè)務(wù)需求相關(guān)。無論是哪種類型的風險，在項目初期設(shè)計整體系統(tǒng)架構(gòu)的過程中更易于發(fā)掘這些風險，如果等到架構(gòu)實施時再發(fā)覺這些風險，那么很可能會致使大量的開發(fā)人員等在那里，直到這些風險被妥善解決。如果進一步的細化，我們可以看到SOA架構(gòu)設(shè)計師的主要任務(wù)包括對整個系統(tǒng)解決方案輪廓的構(gòu)建，需求分析，對體系結(jié)構(gòu)的整體決策，相關(guān)組件建模，相關(guān)操作建模，系統(tǒng)組件的邏輯和物理布局設(shè)計。

作為SOA架構(gòu)設(shè)計師必須要能夠領(lǐng)導(dǎo)整個開發(fā)團隊，這樣才能保證設(shè)計和開發(fā)人員是按照構(gòu)建好的系統(tǒng)架構(gòu)來開發(fā)整個系統(tǒng)的，這一點十分的重要。這就要求一名架構(gòu)設(shè)計師不僅要有很好的技術(shù)洞察力，同時還要具有一定的項目管理和項目實施的能力。在系統(tǒng)開發(fā)的過程中，架構(gòu)設(shè)計師必須要有良好的溝通和表達能力，這就體現(xiàn)在由架構(gòu)設(shè)計師構(gòu)建的系統(tǒng)模型是否具有很好的可讀性和易理解性。如果由架構(gòu)設(shè)計師構(gòu)造出的系統(tǒng)模型不是很清晰的話，就可能會影響設(shè)計和開發(fā)人員對于整個系統(tǒng)架構(gòu)的理解。為了避免這種情況的出現(xiàn)，定期由架構(gòu)設(shè)計師主持的開發(fā)團隊內(nèi)部討論是十分重要的。

3. 構(gòu)建SOA架構(gòu)時應(yīng)該注意的問題

3．1 原有系統(tǒng)架構(gòu)中的集成需求

當架構(gòu)師基于SOA來構(gòu)建一個企業(yè)級的系統(tǒng)架構(gòu)的時候，一定要注意對原有系統(tǒng)架構(gòu)中的集成需求進行細致的分析和整理。我們都知道，面向服務(wù)的體系結(jié)構(gòu)是當前及未來應(yīng)用程序系統(tǒng)開發(fā)的重點，面向服務(wù)的體系結(jié)構(gòu)本質(zhì)上來說是一種具有特殊性質(zhì)的體系結(jié)構(gòu)，它由具有互操作性和位置透明的組件集成構(gòu)建并互連而成?；赟OA的企業(yè)系統(tǒng)架構(gòu)通常都是在現(xiàn)有系統(tǒng)架構(gòu)投資的基礎(chǔ)上發(fā)展起來的，我們并不需要徹底重新開發(fā)全部的子系統(tǒng)；SOA可以通過利用當前系統(tǒng)已有的資源（開發(fā)人員、軟件語言、硬件平臺、數(shù)據(jù)庫和應(yīng)用程序）來重復(fù)利用系統(tǒng)中現(xiàn)有的系統(tǒng)和資源。SOA是一種可適應(yīng)的、靈活的體系結(jié)構(gòu)類型，基于SOA構(gòu)建的系統(tǒng)架構(gòu)可以在系統(tǒng)的開發(fā)和維護中縮短產(chǎn)品上市時間，因而可以降低企業(yè)系統(tǒng)開發(fā)的成本和風險。因此，當SOA架構(gòu)師遇到一個十分復(fù)雜的企業(yè)系統(tǒng)時，首先考慮的應(yīng)該是如何重用已有的投資而不是替換遺留系統(tǒng)，因為如果考慮到有限的預(yù)算，整體系統(tǒng)替換的成本是十分高昂的。

當SOA架構(gòu)師分析原有系統(tǒng)中的集成需求的時候，不應(yīng)該只限定為基于組件構(gòu)建的已有應(yīng)用程序的集成，真正的集成比這要寬泛得多。在分析和評估一個已有系統(tǒng)體系結(jié)構(gòu)的集成需求時，我們必須考慮一些更加具體的集成的類型，這主要包括以下幾個方面：應(yīng)用程序集成的需求，終端用戶界面集成的需求，流程集成的需求以及已有系統(tǒng)信息集成的需求。當SOA架構(gòu)師分析和評估現(xiàn)有系統(tǒng)中所有可能的集成需求的時候，我們可以發(fā)現(xiàn)實際上所有集成方式在任何種類的企業(yè)中都有一定程度的體現(xiàn)。針對不同的企業(yè)類型，這些集成方式可能是簡化的，或者沒有明確地進行定義的。因而，SOA架構(gòu)師在著手設(shè)計新的體系結(jié)構(gòu)框架時，必須要全面的考慮所有可能的集成需求。例如，在一些類型的企業(yè)系統(tǒng)環(huán)境中可能只有很少的數(shù)據(jù)源類型，因此，系統(tǒng)中對消息集成的需求就可能會很簡單，但在一些特定的系統(tǒng)中，例如航運系統(tǒng)中的EDI（Electronic Data Interchange 電子數(shù)據(jù)交換）系統(tǒng)，會有大量的電子數(shù)據(jù)交換處理的需求，因此也就會存在很多不同的數(shù)據(jù)源類型，在這種情況下整個系統(tǒng)對于消息數(shù)據(jù)的集成需求就會比較復(fù)雜。因此，如果SOA架構(gòu)師希望所構(gòu)建的系統(tǒng)架構(gòu)能夠隨著企業(yè)的成長和變化成功地繼續(xù)得以保持，則整個系統(tǒng)構(gòu)架中的集成功能就應(yīng)該由服務(wù)提供，而不是由特定的應(yīng)用程序來完成。

3．2 服務(wù)粒度的控制以及無狀態(tài)服務(wù)的設(shè)計

當SOA架構(gòu)師構(gòu)建一個企業(yè)級的SOA系統(tǒng)架構(gòu)的時候，關(guān)于系統(tǒng)中最重要的元素，也就是SOA系統(tǒng)中的服務(wù)的構(gòu)建有兩點需要特別注意的地方：首先是對于服務(wù)粒度的控制，另外就是對于無狀態(tài)服務(wù)的設(shè)計。

服務(wù)粒度的控制

SOA系統(tǒng)中的服務(wù)粒度的控制是一項十分重要的設(shè)計任務(wù)。通常來說，對于將暴露在整個系統(tǒng)外部的服務(wù)推薦使用粗粒度的接口，而相對較細粒度的服務(wù)接口通常用于企業(yè)系統(tǒng)架構(gòu)的內(nèi)部。從技術(shù)上講，粗粒度的服務(wù)接口可能是一個特定服務(wù)的完整執(zhí)行，而細粒度的服務(wù)接口可能是實現(xiàn)這個粗粒度服務(wù)接口的具體的內(nèi)部操作。 舉個例子來說，對于一個基于SOA架構(gòu)的網(wǎng)上商店來說，粗粒度的服務(wù)可能就是暴露給外部用戶使用的提交購買表單的操作，而系統(tǒng)內(nèi)部的細粒度的服務(wù)可能就是實現(xiàn)這個提交購買表單服務(wù)的一系列的內(nèi)部服務(wù)，比如說創(chuàng)建購買記錄，設(shè)置客戶地址，更新數(shù)據(jù)庫等一系列的操作。雖然細粒度的接口能為服務(wù)請求者提供了更加細化和更多的靈活性，但同時也意味著引入較難控制的交互模式易變性,也就是說服務(wù)的交互模式可能隨著不同的服務(wù)請求者而不同。如果我們暴露這些易于變化的服務(wù)接口給系統(tǒng)的外部用戶，就可能造成外部服務(wù)請求者難于支持不斷變化的服務(wù)提供者所暴露的細粒度服務(wù)接口。而粗粒度服務(wù)接口保證了服務(wù)請求者將以一致的方式使用系統(tǒng)中所暴露出的服務(wù)。雖然面向服務(wù)的體系結(jié)構(gòu)（SOA）并不強制要求一定要使用粗粒度的服務(wù)接口，但是建議使用它們作為外部集成的接口。通常架構(gòu)設(shè)計師可以使用BPEL來創(chuàng)建由細粒度操作組成的業(yè)務(wù)流程的粗粒度的服務(wù)接口。

無狀態(tài)服務(wù)的設(shè)計

SOA系統(tǒng)架構(gòu)中的具體服務(wù)應(yīng)該都是獨立的、自包含的請求，在實現(xiàn)這些服務(wù)的時候不需要前一個請求的狀態(tài)，也就是說服務(wù)不應(yīng)該依賴于其他服務(wù)的上下文和狀態(tài)，即SOA架構(gòu)中的服務(wù)應(yīng)該是無狀態(tài)的服務(wù)。當某一個服務(wù)需要依賴時，我們最好把它定義成具體的業(yè)務(wù)流程（BPEL）。在服務(wù)的具體實現(xiàn)機制上，我們可以通過使用 EJB 組件來實現(xiàn)粗粒度的服務(wù)。我們通常會利用無狀態(tài)的Session Bean來實現(xiàn)具體的服務(wù)，如果基于Web Service技術(shù)，我們就可以將無狀態(tài)的Session Bean暴露為外部用戶可以調(diào)用的到的Web服務(wù)，也就是把傳統(tǒng)的Session Facade模型轉(zhuǎn)化為了 EJB 的Web服務(wù)端點，這樣，我們就可以向 Web 服務(wù)客戶提供粗粒度的服務(wù)。

如果我們要在 J2EE的環(huán)境下（基于WebSphere）構(gòu)建Web服務(wù)，Web 服務(wù)客戶可以通過兩種方式訪問 J2EE 應(yīng)用程序?？蛻艨梢栽L問用 JAX-RPC API 創(chuàng)建的 Web 服務(wù)（使用 Servlet 來實現(xiàn)）；Web 服務(wù)客戶也可以通過 EJB的服務(wù)端點接口訪問無狀態(tài)的Session Bean，但Web 服務(wù)客戶不能訪問其他類型的企業(yè)Bean，如有狀態(tài)的Session Bean，實體Bean和消息驅(qū)動Bean。后一種選擇（公開無狀態(tài) EJB 組件作為 Web 服務(wù)）有很多優(yōu)勢，基于已有的EJB組件，我們可以利用現(xiàn)有的業(yè)務(wù)邏輯和流程。在許多企業(yè)中，現(xiàn)有的業(yè)務(wù)邏輯可能已經(jīng)使用 EJB 組件編寫，通過 Web 服務(wù)公開它可能是實現(xiàn)從外界訪問這些服務(wù)的最佳選擇。EJB 端點是一種很好的選擇，因為它使業(yè)務(wù)邏輯和端點位于同一層上。另外EJB容器會自動提供對并發(fā)的支持，作為無狀態(tài)Session Bean實現(xiàn)的 EJB 服務(wù)端點不必擔心多線程訪問，因為 EJB 容器必須串行化對無狀態(tài)會話 bean 任何特定實例的請求。 由于EJB容器都會提供對于Security和Transaction的支持，因此Bean的開發(fā)人員可以不需要編寫安全代碼以及事務(wù)處理代碼。 性能問題對于Web服務(wù)來說一直都是一個問題，由于幾乎所有 EJB 容器都提供了對無狀態(tài)會話 Bean 群集的支持以及對無狀態(tài)Session Bean 池與資源管理的支持，因此當負載增加時，可以向群集中增加機器，Web 服務(wù)請求可以定向到這些不同的服務(wù)器，同時由于無狀態(tài)Session Bean 池改進了資源利用和內(nèi)存管理，使 Web 服務(wù)能夠有效地響應(yīng)多個客戶請求。由此我們可以看到，通過把 Web 服務(wù)模型化為 EJB 端點，可以使服務(wù)具有更強的可伸縮性，并增強了系統(tǒng)整體的可靠性。

4. 結(jié)束語

本文簡要介紹了有關(guān)架構(gòu)設(shè)計師以及SOA架構(gòu)的知識，分析了SOA架構(gòu)師在設(shè)計SOA系統(tǒng)架構(gòu)時有哪些應(yīng)該特別注意的地方。

本文的第二部分將向您介紹在構(gòu)建基于SOA架構(gòu)的企業(yè)系統(tǒng)時應(yīng)該怎樣保證所構(gòu)建的系統(tǒng)架構(gòu)能夠滿足系統(tǒng)中不同的服務(wù)級別需求。從架構(gòu)設(shè)計師的角度，SOA是一種新的設(shè)計模式，方法學(xué)。因此，SOA本身涵蓋了很多的內(nèi)容，也觸及到了系統(tǒng)整體架構(gòu)設(shè)計、實現(xiàn)、維護等各個方面。本文的內(nèi)容只是涉及到了有關(guān)于架構(gòu)方面的一部分內(nèi)容，希望能對廣大的SOA系統(tǒng)開發(fā)設(shè)計人員起到一定的幫助作用。