追尋生活的動力！

什么是SOA?SOA的基本特征?SOA有什么優點？SOA現狀？

什么是SOA?

SOA是一種架構模型，它可以根據需求通過網絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中與軟件代理交互的人為依賴性。

SOA:Service-Oriented Architecture，面向服務架構，SOA是一種架構模型，它可以根據需求通過網絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中與軟件代理互聯網紓的人為依賴性。

SOA的幾個關鍵特性：一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義適配器進行通訊，不涉及底層編程適配器和通訊模型。

SOA的關鍵是“服務”的概念，W3C將服務定義為：“服務提供者完成一組工作，為服務使用者交付所需的最終結果。最終結果通常會使使用者的狀態發生變化，但也可能使提供者的狀態改變，或者雙方都產生變化”。

Service-architecture.com將SOA定義為：“本質上是服務的集合。服務間彼此通信，這種通信可能是簡單的數據傳送，也可能是兩個或更多的服務協調進行某些活動。服務間需要某些方法進行連接。所謂服務就是精確定義、封裝完善、獨立于其他服務所處環境和狀態的函數。”

Looselycoupled.com將SOA定義為：“按需連接資源的系統。在SOA中，資源被作為可通過標準方式訪問的獨立服務，提供給網絡中的其他成員。與傳統的系統結構相比，SOA規定了資源間更為靈活的松散耦合關系。”

Gartner則將SOA描述為：“客戶端/服務器的軟件設計方法，一項應用由軟件服務和軟件服務使用者組成……SOA與大多數通用的客戶端/服務器模型的不同之處，在于它著重強調軟件組件的松散耦合，并使用獨立的標準接口。”

Gartner相信BPM和SOA的結合對所有類型的應用集成都大有助益??“SOA極大的得益于BPM技術和方法論，但是SOA面臨的真正問題是確立正確的企業意識，即：強化戰略化的SOA計劃（針對供應和使用）并鼓勵重用。”

雖然不同廠商或個人對SOA有著不同的理解，但是我們仍然可以從上述的定義中看到SOA的幾個關鍵特性：一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義接口進行通訊，不涉及底層編程接口和通訊模型。

需著重注意的是，SOA并不是新生事物??大型IT組織成功構建和部署SOA應用已有多年的歷史??這要比現有的XML和Web服務長很多。IBM CICS和BEA TUXEDO就是過去被用于構建SOA應用的兩種技術范例。

重點說明的是SOA并不是一種現成的技術，而是一種架構和組織IT基礎結構及業務功能的方法。SOA是一種在計算環境中設計、開發、部署和管理離散邏輯單元（服務）的模型。這一定義闡明了SOA的范圍。

SOA要求開發人員將應用設計為服務的集合。SOA要求開發人員跳出應用本身進行思考，考慮現有服務的重用，或思索他們的服務如何能夠被其他項目重用。“單獨的”、“獨立的”、“封裝完善的”服務所具有的一個關鍵的好處是，可以采用多種不同方法將它們組合成較大型的服務，由此來實現重用。

但是，SOA并不僅僅是一種開發方法??它還具有管理上的優點。例如，現在管理員可直接管理開發人員所構建的相同服務，這遠勝于以往管理單個應用的方式。通過分析服務間的交互，SOA可以幫助企業了解何時以及為什么業務邏輯被切實執行了，這使管理員或分析師能夠有針對性的優化業務流程。

 

SOA的基本特征

SOA的實施具有幾個鮮明的基本特征。實施SOA的關鍵目標是實現企業IT資產的最大化重用。要實現這一目標，就要在實施SOA的過程中牢記以下特征：

1 可從企業外部訪問

通常被稱為業務伙伴的外部用戶也能像企業內部用戶一樣訪問相同的服務。業務伙伴采用先進的B2B協議（ebXML或RosettaNet）相互合作。當業務伙伴基于業務目的交換業務信息時，他們就參與了一次會話。會話是業務伙伴間一系列的一條或多條業務信息的交換。會話類型（會話復雜或簡單、長或短等）取決于業務目的。

除了B2B協議外，外部用戶還可以訪問以Web服務方式提供的企業服務。

 

2 隨時可用

當有服務使用者請求服務時，SOA要求必須有服務提供者能夠響應。大多數SOA都能夠為門戶應用之類的同步應用和B2B之類的異步應用提供服務。同步應用對于其所使用的服務具有很強的依賴性。

許多同步應用通常部署在前臺，其最終用戶很容易受到服務提供者短缺的影響。很多情況下，同步應用利用分布式服務提供者，這樣可以響應更多的用戶請求。但是，隨著提供特定服務功能的服務器數量的增長，出現短缺的可能性也呈指數級上升。

相比之下，異步應用要更為穩健，因為其采用隊列請求設計，因此可以容許出現服務提供者短缺或遲滯的情況。異步應用大多數情況下部署在后臺，用戶通常不會覺察到短暫的短缺。大部分情況下異步應用能夠穩健應對短時間短缺，但是長時間短缺則會引發嚴重問題。在服務短缺解決、隊列引擎將罕見的大量工作推到共享的應用資源中時，可能會出現隊列溢出甚至服務死鎖。

服務使用者要求提供同步服務時，通常是基于其自身理解或使用習慣。在多數情況下，采用異步模型可以達到同樣的效果，但更能夠體現SOA的最佳特性。

當然，并不是所有情況下都應當采用異步設計模式。但大多數情況下，異步消息可以確保系統在不同負荷下的伸縮性，在接口響應時間不是很短時尤其如此。

3 粗粒度服務接口

粗粒度服務提供一項特定的業務功能，而細粒度服務代表了技術組件方法。舉個例說明最為清楚??向計費系統中添加一個客戶是典型的粗粒度服務，而你可以使用幾個細粒度服務實現同一功能，如：將客戶名加入到計費系統中，添加詳細的客戶聯系方式、添加計費信息等等。

采用粗粒度服務接口的優點在于使用者和服務層之間不必再進行多次的往復，一次往復就足夠。Internet環境中有保障的TCP/IP會話已不再占據主導、建立連接的成本也過高，因此在該環境中進行應用開發時粗粒度服務接口的優點更為明顯。

除去基本的往復效率，事務穩定性問題也很重要。在一個單獨事務中包含的多段細粒度請求可能使事務處理時間過長、導致后臺服務超時，從而中止。與此相反，從事務的角度來看，向后臺服務請求大塊數據可能是獲取反饋的唯一途徑。

4 分級

一個關于粗粒度服務的爭論是此類服務比細粒度服務的重用性差，因為粗粒度服務傾向于解決專門的業務問題，因此通用性差、重用性設計困難。解決該爭論的方法之一就是允許采用不同的粗粒度等級來創建服務。這種服務分級包含了粒度較細、重用性較高的服務，也包含粒度較粗、重用性較差的服務。

在服務分級方面，須注意服務層的公開服務通常由后臺系統（BES's）或SOA平臺中現有的本地服務組成。因此允許在服務層創建私有服務是非常重要的。正確的文檔、配置管理和私有服務的重用對于IT部門在SOA服務層快速開發新的公開服務的能力具有重要影響。

 

5 松散耦合

SOA具有“松散耦合”組件服務，這一點區別于大多數其他的組件架構。該方法旨在將服務使用者和服務提供者在服務實現和客戶如何使用服務方面隔離開來。

服務提供者和服務使用者間松散耦合背后的關鍵點是服務接口作為與服務實現分離的實體而存在。這是服務實現能夠在完全不影響服務使用者的情況下進行修改。

大多數松散耦合方法都依靠基于服務接口的消息。基于消息的接口能夠兼容多種傳輸方式（如HTTP、JMS、TCP/IP、MOM等）。基于消息的接口可以采用同步和異步協議實現，Web服務對于SOA服務接口來講是一個重要的標準。
當使用者調用一個Web服務時，被調用的對象可以是CICS事務、DCOM或CORBA對象、J2EE EJB或TUXEDO服務等，但這與服務使用者無關。底層實現并不重要。

消息類Web服務通常是松散耦合和文檔驅動的，這要優于與服務特定接口的連接。當客戶調用消息類Web服務時，客戶通常會發送的是一個完整的文檔（如采購訂單），而非一組離散的參數。Web服務接收整個文檔、進行處理、而后可能或者不會返回結果信息。由于客戶和Web服務間不存在緊密耦合請求響應，消息類 Web服務在客戶和服務器間提供了更為松散的耦合。

 

6 可重用的服務及服務接口設計管理

如果完全按照可重用的原則設計服務，SOA將可以使應用變得更為靈活。可重用服務采用通用格式提供重要的業務功能，為開發人員節約了大量時間。設計可重用服務是與數據庫設計或通用數據建模類似的最有價值的工作。由于服務設計是成功的關鍵因此，因此SOA實施者應當尋找一種適當的方法進行服務設計過程管理。

服務設計管理根本上講是服務設計問題，服務設計需要在兩點間折衷??走捷徑的項目戰術與企業構建可重用通用服務的長期目標。

超越項目短期目標進行服務接口的開發和評估是邁向精確定義服務接口的重要一步，同時還需要為接口文檔、服務實現文檔及所有重要的非功能性特征設立標準。

在大型組織中實現重用的一個先決條件是建立通用（設計階段）服務庫和開發流程，以保證重用的正確性和通用性。此外，對記述服務設計和開發的服務文檔進行評估也是成功利用服務庫的關鍵。

簡言之，不按規則編寫服務將無法保證可提供重用性的SOA的成功實施。在執行規則的過程中會產生財務費用，需要在制定SOA實施計劃時加以考慮。

 

7 標準化的接口

近年來出現的兩個重要標準XML和Web服務增加了全新的重要功能，將SOA推向更高的層面，并大大提升了SOA的價值。盡管以往的SOA產品都是專有的、并且要求IT部門在其特定環境中開發所有應用，但XML和Web服務標準化的開放性使企業能夠在所部署的所有技術和應用中采用SOA。這具有巨大的意義！

Web服務使應用功能得以通過標準化接口（WSDL）提供，并可基于標準化傳輸方式（HTTP和JMS）、采用標準化協議（SOAP）進行調用。例如，開發人員可以采用最適于門戶開發的工具輕松創建一個新的門戶應用，并可以重用ERP系統和定制化J2EE應用中的現有服務，而完全無須了解這些應用的內部工作原理。采用XML，門戶開發人員無須了解特定的數據表示格式，便能夠在這些應用間輕松地交換數據。

你也可以不采用Web服務或XML來創建SOA應用，但是這兩種標準的重要性日益增加、應用日趨普遍。盡管目前只有幾種服務使用者支持該標準，但未來大多數的服務使用者都會將其作為企業的服務訪問方法。

 

8 支持各種消息模式

SOA中可能存在以下消息模式。在一個SOA實現中，常會出現混合采用不同消息模式的服務。

A. 無狀態的消息。使用者向提供者發送的每條消息都必須包含提供者處理該消息所需的全部信息。這一限定使服務提供者無須存儲使用者的狀態信息，從而更易擴展。

B. 有狀態的消息。使用者與提供者共享使用者的特定環境信息，此信息包含在提供者和使用者交換的消息中。這一限定使提供者與使用者間的通信更加靈活，但由于服務提供者必須存儲每個使用者的共享環境信息，因此其整體可擴展性明顯減弱。該限定增強了服務提供者和使用者的耦合關系，提高了交換服務提供者的服務難度。

C. 等冪消息。向軟件代理發送多次重復消息的效果和發送單條消息相同。這一限定使提供者和消費者能夠在出現故障時簡單的復制消息，從而改進服務可靠性。

 

9 精確定義的服務接口

服務是由提供者和使用者間的契約定義的。契約規定了服務使用方法及使用者期望的最終結果。此外，還可以在其中規定服務質量。此處需要注意的關鍵點是，服務契約必須進行精確定義。

META將SOA定義為：“一種以通用為目的、可擴展、具有聯合協作性的架構，所有流程都被定義為服務，服務通過基于類封裝的服務接口委托給服務提供者，服務接口根據可擴展標識符、格式和協議單獨描述。”該定義的最后部分表明在服務接口和其實現之間有明確的分界。

 

SOA的優點

了解了SOA的定義和基本特征，最后我們再來看看SOA潛在的優點：

A.編碼靈活性

可基于模塊化的低層服務、采用不同組合方式創建高層服務，從而實現重用，這些都體現了編碼的靈活性。此外，由于服務使用者不直接訪問服務提供者，這種服務實現方式本身也可以靈活使用。

B.明確開發人員角色

例如，熟悉BES的開發人員可以集中精力在重用訪問層，協調層開發人員則無須特別了解BES的實現，而將精力放在解決高價值的業務問題上。

C.支持多種客戶類型

借助精確定義的服務接口和對XML、Web服務標準的支持，可以支持多種客戶類型，包括PDA、手機等新型訪問渠道。

D.更易維護

服務提供者和服務使用者的松散耦合關系及對開放標準的采用確保了該特性的實現。

E.更好的伸縮性

依靠服務設計、開發和部署所采用的架構模型實現伸縮性。服務提供者可以彼此獨立調整，以滿足服務需求。

F.更高的可用性

該特性在服務提供者和服務使用者的松散耦合關系上得以體現。使用者無須了解提供者的實現細節，這樣服務提供者就可以在WebLogic集群環境中靈活部署，使用者可以被轉接到可用的例程上。

SOA可以看作是B/S模型、XML/Web Service技術之后的自然延伸。SOA將能夠幫助我們站在一個新的高度理解企業級架構中的各種組件的開發、部署形式，它將幫助企業系統架構者以更迅速、更可靠、更具重用性架構整個業務系統。較之以往，以SOA架構的系統能夠更加從容地面對業務的急劇變化。

面向服務架構（SOA）是讓IT更加關注于業務流程而非底層IT基礎結構，從而獲得競爭優勢的更高級別的應用程序開發架構。

IT人士如何滿足那些日益增長的需求以便快速實現IT價值呢？答案是開發和部署面向服務的架構（SOA）。SOA方法能夠更好地讓IT與業務目標看齊，使得IT組織可以高效復用資產、為企業更快地創造價值，進而更輕松地應對不斷變化的業務需求。

SOA對需要使用信息技術解決關鍵業務問題的企業（包括希望減少冗余架構、創建跨客戶和員工系統的公共業務接口的企業；需要基于角色和工作流對用戶提供個性化信息的業務的企業；希望通過Internet實現跨區銷售、升級銷售和經由移動設備的訪問來提升客戶服務的組織）很有價值。

采用服務驅動型方法的企業體驗著以下業務和IT好處：

面向服務架構的業務好處

<!--[if !supportLists]-->l    <!--[endif]-->效率：將業務流程從"煙囪"狀的、重復的流程向維護成本較低的高度利用、共享服務應用轉變。

<!--[if !supportLists]-->l    <!--[endif]-->響應：迅速適應和傳送關鍵業務服務來滿足市場需求，為客戶、雇員和合作伙伴更高水準的服務。

<!--[if !supportLists]-->l    <!--[endif]-->適應性：更高效地轉入轉出讓整個業務變得復雜性和難度更小，達到節約時間和資金的目的。

面向服務架構的IT好處

<!--[if !supportLists]-->l    <!--[endif]-->復雜性降低：基于標準的兼容性，與點到點的集成相比降低了復雜性。

<!--[if !supportLists]-->l    <!--[endif]-->重用增加：通過重用以前開發和部署的共享服務，實現了更有效的應用程序/項目開發和交付。

<!--[if !supportLists]-->l    <!--[endif]-->遺留集成：用作可重用服務的遺留應用程序降低了維護和集成的成本。

如今的服務驅動型企業都在體驗著開發的高效率，服務的高可靠性和服務的高質量，以最大限度獲得業務機會所帶來的這些好處。

 

IBM發布31種SOA產品 加速實現面向服務架構

IBM在它的客戶中加速實現面向服務架構的努力當中，已經發布了IBM的11項新產品和22項基于WebSphere的軟件的更新，IBM還宣布將會對咨詢服務增加人力投入，以使得該項目能夠在接下來的六個月中完成。

IBM Software 集團的高級副總裁和執行總裁Steve Mills認為SOA軟件市場還沒有成熟，但是本周發布的軟件將會幫助客戶開始SOA軟件的開發和應用。

<!--[endif]--> <!--[if !vml]--><!--[endif]-->

圖1：共享服務生命周期的設計和運行時階段

SSLC中的設計時注意事項

現在我們來看看共享服務周期的設計時方面。提到設計時，我主要關注服務投入生產和使用之前的生命周期。本文不涉及設計時建模的許多需求，如開發服務建模方法學，但如有興趣，我將在未來的文章中闡述這一主題。

確定業務流程

SOA的一個核心原則是業務和IT保持一致以及建立競技場(playing field)。通過識別企業通過服務定位提供價值的業務流程，服務工程團隊(通常是業務、分析師和IT人員的組合)可能在討論的出發點方面達成一致。

許多企業發覺很難理解從何處開始SOA以及哪些是最合適的業務流程。一種好的方法是首先在白板上定義需求目錄。將白板劃分為3條泳道，分別代表短期需求(3到6個月——通常本質上更有戰術性)，中期需求(6到18個月)和長期需求(超過18個月——通常為戰略需求，可能隨業務需求的變化而變化)。劃分泳道之后，開始為每個區域添加需求。盡量避免按應用系統(如，電子商務網站)思考;看得越遠，越有可能達到您要求的高度(例如，我需要完善自己的清單系統)。在生命周期的這一階段，主要著眼于可能成為業務組成部分的業務流程，如電子商務站點。

完成初步分析之后，服務工程團隊可能開始尋找依賴性，試圖決定優先級、揭示重用可能性或確定需求之間的依賴性。觀察下面的需求目錄示例，可以看到對于該企業來說，最初集中在用戶注冊流程上是再合理不過了，因為許多其他流程依賴于該流程，而且它可以在整個電子商務功能和企業內部網中重用。

<!--[if !vml]--><!--[endif]-->

圖2：需求目錄示例，它向服務工程團隊提供了實現公司未來狀態的路線圖

根據公司在服務設計和開發方面的成熟度，選擇首先開發哪種服務可能很自然地導致構建沒有很多依賴性的服務，同時積累經驗。盡管這些想法是對的，但是在企業成熟度中，熟悉增強重用的服務建模技術是很重要的，如強大的契約和策略定義。服務工程團隊必須意識到重用概念以前曾在業務中提到過多次，但沒有多大成效。由于相對于傳統應用程序生命周期來說，服務開發周期較短，服務工程團隊有能力從短期目錄創建一系列可以跨計劃快速利用的基礎服務，從而實現早期的成功。

無論如何，對初始服務（特別是依賴服務）的選擇應與服務工程團隊的能力相一致。這是很重要的。新的團隊需要時間才能在SSLC的設計階段具有更多經驗。在服務目錄中確定的依賴服務可能由于具有較高的重用水平，看似是一個好的侯選服務，但是不適合于尚未成熟的團隊。若一個服務已涉及到跨業務線、提供企業級功能或遵守嚴格的服務質量規章的依賴性，則它可能不是一個理想的初始侯選服務。

另一方面，對于一個具有已定義流程和已知端點的服務，如果這些端點是受控的、成熟的并且范圍很小，在必要的情況下，服務本身的離散程度足以構建或重構，那么在很短的時間內，這種服務是初始開發的主要侯選服務。這樣的初始服務應該可以很快地驗證假設、方法學和流程。正確的設計需要經驗和實踐。反復進行試驗并糾正錯誤，尤其在SOA計劃的成型階段，這種方法是判斷在您的企業內哪些SOA實踐可以發揮作用的重要機制。早期選擇沒有依賴性的孤立服務可能會限制服務工程團隊在成型階段獲取更多的學習機會。

服務設計和建模

服務設計和建模階段的目標是，基于需求目錄中確定的業務流程建立一種定義侯選服務的一致方法。真到開始做的時候，服務工程團隊通常用白板描繪業務流程、分解步驟以及討論當前和未來的需求。為此，一致的設計方法學應該使用業務和IT均可理解的常用語言來建立。

服務設計方法學為服務工程團隊提供了一系列用于分解業務流程的步驟或活動，基于面向服務的設計原則確定服務中開發哪些方面是合理的。對于這種設計方法學，許多企業最初有一些爭執，尤其是服務粒度。過細的粒度可能產生不可重用的服務增殖；過粗的粒度，又很難著手。在團隊對建模流程滿意之前，它應該將其活動集中在定義良好的業務流程中，這些業務流程可能并沒有較大企業需求（如高生產量、長期事務）。

盡管從技術上來說不是建模階段的一部分（但可能是建模方法學的一部分），但我的經驗表明：在定義服務分類原則方面投入時間對企業來說是很重要的。這些指導方針應該定義服務的哪些方面決定了服務是業務線（LOB）或應用程序級服務，還是具有特殊需求的企業服務。這些指導方針可能包括生產量、服務質量（QoS）、正常運行時間、服務關鍵程度以及多少客戶將使用該服務。另外，開始定義與建立和管理服務相關的企業治理控制時，這些指導方針至關重要。開發指導方針可能本身是貫穿始終的工作，但開頭很簡單，只定義當前需求所要求的部分就可以。而且，服務分類可能有助于將相似功能分組并確認這些功能的業務所有者。記住，后續出現新的需求時可以重新調整指導方針。

<!--[if !vml]--><!--[endif]-->

圖3：服務分類及其與SOA治理的關系；此分類可能有助于定義SOA資產的企業治理控制。

根據服務目錄示例，企業可能已經建立了企業服務和業務線服務類別。以下進行詳細描述。

企業服務

企業服務具有水平影響，可能包括：

1. 無論在是周邊或核心部門，安全性都需要符合行業規范。
2. 活動審計。記住審計可能是某一特定功能的一個方面，如外匯交易，而不是進行交易的流程。
3. 一般異常處理。
4. 服務要求24x7可靠性，并且必須據此進行治理。
5. 服務要求大容量和（或）低延遲吞吐量。
6. 根據使用環境，服務可能要求更高級別的客戶服務或響應時間。例如，客戶個人信息表明他們是貴賓客戶，則服務契約會要求不同的SLA。
7. 若服務要求跨業務線進行交互，則可能具有必須滿足的企業基礎架構需求。
8. 服務與企業數據進行交互。這方面可能意味著企業擁有通用模型，而具體用戶數據存儲的實現則由業務線控制。經驗和實踐表明，大量的用戶數據存儲存在于企業中。SOA目標的一部分就是為了長期鞏固這些方面，但在定義未來計劃時，不應脫離現實，而是要充分利用現有資源。

業務線服務

這些服務具有垂直影響，可能包括：

1. 特定業務功能，如采購單（PO）或新的租賃處理。
2. 具有特定UI和外觀的表示服務，或者通常用于提供某一特定業務功能的可視化表示的向導。
3. 支持業務線的CRUD（創建、讀取、更新、刪除）活動的信息和訪問服務。
4. 應用服務，如基于特定業務線數據的銷售跟蹤或預測。

此分類并不完整，但應該可以提供企業如何開始分類工作的概念。

通過檢查以上類別，可將以前定義的需求目錄中的某些侯選服務放至治理組中，并識別出以前并不明顯的許多典型結構：

服務生命周期主要是為了解決業務需求問題，而不是過度陷于具體的分類練習。SSLC評估階段是為了支持基于實際應用和環境的再評估。我想到電影《夢幻之地》中凱文·科斯特納聽到的聲音重復說：“你蓋好了，他們就會來”。這與在企業中公開服務沒有什么區別。在某一時間點上以某一使用級別定義的內容實際上可能會以完全不同的方式使用，也就是通常在最初設計時并未考慮到的方式。指導方針在重分類階段應該有所幫助。

在流程的這一階段，我主要談論侯選服務與服務實現的概念。Erl（2004）建議侯選服務是潛在的服務，這些服務可能在最后的設計中實現，也可能不實現。設計流程是為了確定設計和開發的未來階段的輸入。理解企業中哪些服務已存在以及哪些需要開發對服務工程團隊來說特別重要。支持服務發現的工具（如兼容UDDI的注冊庫）是促進服務重用和了解現有可用資源的重要組件。

最后，在建模階段，隨著逐漸理解了團隊正在定義侯選服務，服務工程團隊應通過獨立于技術架構和物理環境約束的已確定方法學繼續進行設計。服務設計和建模階段的目的就是定義期望的未來狀態。SSLC的構建和組合階段將使侯選服務遵守組織約束以定義最后的服務實現。

構建和組合

為更加快速經濟地開發新的功能，服務生命周期的構建和組合重點集中在開發新服務以及利用企業中現有資源所要求的任務上。這一方法可以縮短上市時間，從而實現SOA的一項關鍵財務收益。

在本階段，服務建模和設計階段確定的侯選服務被具體化成服務操作，并將基礎架構和環境實體映射到它們。正如在建模階段提到的，確定SOA計劃的目標是很重要的。由于當前環境的限制，實現這些目標可能比較困難，但是可能會促進某些良性討論以及某種成本利潤分析，從而確定如何實現期望的未來狀態。但是，現在的企業需要繼續發展，所以您的侯選服務在企業環境中必須具有現實意義。

理解了哪些服務操作和實現比較現實之后，就可以著眼于重用的可能性以及在上一階段確定的組合。要充分利用SOA，組合的概念對業務敏捷性來說非常重要。開發環境和服務基礎架構工具必須推動設計時發現服務，并可組合這些服務，完成整個業務流程。

沒有這些工具，SOA計劃的成功可能會受到阻礙。隨著初始服務對業務線團隊和其他工程團隊可用，組合的機會可能得以實現。在這種情況下，在分類的同時已確定了初始依賴性。這些依賴性應描述為構建組合服務的直接可能性，并應提供重用的切實收益。本文中只稍微提到了組合，但這些活動的重要性與SSLC的構建和組合階段直接相關。

考慮需求目錄示例：一個稱為整合清單系統的計劃已在長期目標中確定。在第一次瀏覽時，該任務可能被描述為物理上廢棄舊清單系統，并將存儲庫整合到一個主數據源中。盡管可能真的會是這樣（如果成本利潤分析表明廢棄舊系統更加經濟有效的話），活動也可能表述為一種沒這么具體的形式。服務工程團隊可能產生一系列邏輯數據服務，對客戶隱藏物理端點。構建普適數據訪問層的這一方法將通過組合直接利用在中期需求目錄中開發的現有檢查清單X服務。整合清單系統計劃可能要求根據清單文檔的典型表示來決定哪些端點需要修改。這種分散式CRUD邏輯應在“服務基礎架構工具”中提供，這樣的一個示例是BEA AquaLogic Data Services Platform。

通常，服務起源于業務線級別而不是通過企業計劃，因為一般情況下這是驅動項目建立和需求的地方。結果，“你蓋好了，他們就來了”方案可能導致設計時發現的服務不是良好的重用侯選服務。它們可能不提供足夠的性能或一致模式。盡管它們在企業中可用，但仍為應用程序級服務。最后，企業必須開始創建管理流程以控制服務的企業可見性。在通常情況下，服務注冊提供確保服務質量的管理機制和流程。這些問題必須在服務生命周期的發布和準備階段予以解決。

最后，要進行快速的開發，經驗表明，工具標準化可使企業充分利用現有知識并在整個SOA計劃中重用。這不是說每個人都必須使用相同的IDE或某個特定工具，而是說使用的任何工具必須以類似的模式工作，必須支持標準；若開發人員需要使用不同的工具支持其他項目，則必須降低學習的難度。另外，這些工具必須能夠輕松地度量服務的重用性和控制上市時間。通過服務生命周期獲得度量可以為企業提供價值巨大的信息，幫助SOA計劃獲得成功。

BEA域模型

正如許多方法學所述，需要建立一種底層模式來統一所有其他活動。在BEA和SOA環境中，就是BEA的域模型（需要注冊）。Dev2Dev中有許多文章描述理解SOA各個方面的重要性（詳見David Groves撰寫的Successfully Planning for SOA）。共享服務生命周期使用該模型并按此方式提供切實的控制點。在本文定義的設計時階段中，域模型的影響通過定義項目和應用程序的需求以及架構方法的需求目錄來表述。

該方法通常開始于遠景，最初通過基礎服務或構造塊實現。盡管治理在設計階段沒有在SSLC的運行時那么關鍵，但是治理已開始在流程中產生了一定的影響，特別是在決定初始服務實現時。

本系列文章的第二部分將揭示評估部署服務成本和收益的重要性，并繼續關注在運行時如何對服務進行治理。另外，SSLC的設計時和運行時階段都要求緊密結合業務策略和流程。這就要求確定和設計可能成為侯選服務的業務流程，并將它們組合成可重用服務，以實現業務的靈活性。

結束語

通過進一步理解與共享服務生命周期相關的設計時需求，正在尋求使用SOA促進重用和增加業務靈活性的企業可能認識到及早建立基礎架構（如方法學、分類指導方針以及開發工具）是實現早期及后續成功的重要因素。通過突破傳統應用程序開發范型以及關注作為發展藍圖的業務流程，服務工程團隊可以及時有效地緊密結合業務需求。

本文的第二部分將關注共享服務生命周期的運行時。

SOA （Service Oriented Architecture，面向服務體系架構）是將開發和業務流程所需的各項操作開發成“服務”（Service）的一種IT體系架構。在這種架構支撐下開發和組成的業務流程本身還可以通過流程編排與其它“服務”組合，從而實現松耦合的復雜“服務”。
目前，SOA技術已經從理論走向了現實，越來越多的企業正在或準備享受SOA帶來的回報。與傳統IT項目類似，采用SOA技術同樣是一個循序漸進的過程，從簡單SOA項目到SOA型企業，從技術平臺到技術標準遵循都是漸進過程的一部分。
盡管采用SOA技術同樣是一個漸進的過程，但是與傳統IT項目相比，它仍然具有明顯的獨特性。面向服務的架構思想不僅提供了一條解決問題的思路，也同樣對整個項目的管理過程提出了一個新的挑戰。
影響SOA項目成功的主要因素
在SOA的世界里，“業務模式”和“技術實現”比以往任何時候都結合得更緊密。這是由于通過服務間松耦合編排方式構建的應用具有極大的靈活性，可以更敏捷的適應業務需求的變化。換句話說，SOA型的IT架構為業務開展提供了更新、更有效的技術支撐。
正是因為SOA與業務的密切關系，使得影響SOA項目成功的因素跨越了傳統IT項目管理的范疇。
從下面的SOA項目成功因素三維模型可以看出，除了傳統的“使能工具、平臺和應用”因素之外，“實施方法論”和“企業文化”也是保證SOA項目成功不可或缺的重要因素。其中“實施方法論”要解決的是從何入手、如何建設的問題；“企業文化”要解決的則是如何建立SOA型企業的問題。
從另一方面來看，影響SOA項目成功的關鍵因素又可分為技術因素和管理因素兩大類：技術因素包括技術的采納和相關技術標準的遵循；管理因素包括企業發展策略、組織架構和IT架構、信息和資源共享模型、IT治理、流程等。
 
SOA項目分級模型
從影響SOA項目成功的關鍵因素來看，“實施方法論”是其中的一個重點。在企業準備采納SOA的技術的時候，必須考慮清楚從何入手、如何建設的問題，因為實現SOA型企業需要一個循序漸進的過程。目前全球范圍內，已經有眾多企業成功應用了SOA，根據從這些成功者中提煉的經驗，可以將SOA項目分為5個不同的層級模型。（如圖2）
需要特別指出的是，這一分級模型并不要求從低到高逐級實現，而僅提供一個理論模型，企業可以根據自身的具體情況，以及項目的特點，綜合各方因素，從任意層級開始自己的SOA之旅。
 
第一級：簡單SOA應用
簡單SOA應用模型主要針對構造和使用Web Services，并對使用情況監控管理的需求而提出。這一級別中，技術上需要使用應用服務器平臺和掌握支持 Web Services 的開發工具；要遵循的相關標準包括WSDL、SOAP、XML、WSRP、JSR168；在項目選擇方面，應該選擇能快速實施的項目以求短期能見效益。
具有35年歷史的The Hartford是美國最大的保險公司之一，企業內運行的傳統系統效率極為低下，由于過分依賴代碼，3-4月/30人的維護周期成為家常便飯。2003年，The Hartford采用Web Service方式的服務單元實現了傳統業務功能，并通過松耦合的方式對業務進行編排，一下將系統的維護周期提速到了3-4周/5-8人。SOA模式允許The Hartford 從大型機 “one service at a time”模式遷移到更靈活的模式。例如，在SOA之前，創建.Net與Java的橋接需要花費3-5周時間，采用SOA (WSDL接口)后，時間減少至2小時。The Hartford的SOA項目是典型的“服務”驅動的項目，是從第一級模型開始的典型案例之一 。
第二級：SOA戰術應用
SOA戰術應用模型主要針對傳統的數據集成及相應的安全管理需求而提出。這一級別中，技術平臺要求有BPEL 流程編排 (Orchestration)、企業服務總線（ESB -  Enterprise Service Bus）、服務注冊（Registry）和Web Services 管理和安全（WSM）；要遵循的相關標準包括BPEL、WSIF、JMS、JCA、UDDI、WS-Security；在策略方面要注重信息的共享模式、明確衡量SOA是否成功的主要指標、保證“Web Service”的管理和安全性政策的有效實行。
Deutsche Post World Net是世界上最大的物流公司之一。它的SOA需求是如何利用靈活的基礎架構來幫助公司減少多個業務系統集成的時間和費用。通過在IT集成平臺上采用先進的企業服務總線 (ESB)技術，Deutsche Post World Net使SOA項目很好的滿足了企業IT需求。這是從架構著手，通過服務總線，實現SOA的一個例子，也是由第二級模型啟用SOA的典型案例。
第三級：SOA戰略級應用
SOA戰略級應用的目標是建立SOA型的業務流程處理系統。技術上要求包括業務流程建模( Process Modeling)、業務規則引擎 (Rule Engines)、數據集成中心（Data Hubs）、集成服務環境（ISE - Integrated Services Environment）、元數據管理等；要遵循的相關標準包括BPMN（Business Process Modeling Notation ）、BPEL、Industry XML；此時已經開始實施業務處理流程自動化。
ING LEASE（以下簡稱ING）是世界最大的金融服務公司之一。由于不斷通過收購擴大企業規模，ING內部形成了相當復雜的IT架構，其中包括三個完全不同的后臺系統，具有明顯的處理瓶頸。為了有效的支撐公司業務運營，ING需要將復雜的IT系統集成。在專家的協助下，通過自上而下的設計方式，ING從流程處理影射開始，并經過反復的原型修正，用了不到6個月時間便實現了“報價到合同”處理的自動化。而這個過程僅用了5個有經驗的系統開發人員。這套自動化的系統目前正在歐洲的16個國家部署實施。ING的SOA項目是個典型的業務驅動的范例，重點是塊系統的自動化業務流程實現。同時，這也是由第三級模型開始實施SOA的典型案例。
第四級：企業級SOA的實施
企業級SOA實施的目標是著手建立SOA型企業。技術手段要提高到業務流程模擬、業務活動監測（BAM）、復雜事件處理、元數據管理系統、網格計算技術；要遵循的相關標準需進步到Service Component Architecture (SCA)、WS-Addressing, WS-Eventing、WS-Trust, WS Secure Conversations 等；企業級SOA要求企業全面的信息、資源共享，IT規劃和治理也將上升到新的高度。
第五級：行業SOA的和諧
這一級模型的目標是通過企業SOA的實踐，將SOA應用擴大到業務合作伙伴，實現行業范圍的產能最大化。

IBM® 面向服務體系結構（Service-Oriented Architecture，SOA）編程模型使非程序員可以創建和重用 IT 資產，而不需要掌握 IT 技能。該模型包括組件類型，布線，模板，應用程序適配器，統一數據表示和企業服務總線（Enterprise Service Bus，ESB）。本文是系列文章的第一部分，該系列文章介紹了 IBM SOA 編程模型，選擇、開發、部署工作所需的內容，以及建議的編程模型元素。本文陳述的內容考慮了使用該模型的開發人員可能具備不同的技術水平和工作角色。

SOA 編程模型系列
對于任何獨立程序員來說，有效的掌握和應用飛速增長的軟件技術、實踐、工具和平臺，變得越來越困難，當然更不用說非程序員了。然而，如果業務流程轉換能夠成功進行，很多的非程序員就可以使用現有的 IT 資產來進行他們的工作，而不用去學習繁瑣的底層技術細節。本系列文章描述了一個新的面向服務體系結構（SOA）編程模型，該模型實現了業務關系的分離，因此企業中具備不同技術水平和工作角色的人，即使不是專業的 IT 人員，也可以在軟件開發生命周期每個階段創建和使用 IT 資產。這可以顯著提高隨需應變企業的業務靈活性。

引言
IBM 產品逐漸應用了 SOA 和編程模型。程序員構建服務、使用服務，并且開發聚集服務的解決方案。我們在這里使用"程序員（programmer）"這個泛稱，因為 SOA 編程模型的一個關鍵方面是將"編程"的概念擴展到非傳統開發人員的工作角色和技能，比如業務分析員和腳本語言用戶。

大多數關于 Web 服務的文章主要集中在服務接口和這些接口的使用方面。為了補充接口標準和最佳實踐，IBM 引入了一個編程模型，來實現服務并將它們組合為解決方案。擴展 IBM 軟件平臺的范圍，使之能夠被更多的用戶團體使用 -- 包括非傳統的開發人員 -- 這個模型提供了新的組件類型與用戶的角色、目標、技能和概念框架相匹配。這些組件類型使更直觀的開發工具可以使用。另一個主要的主題是通過編程模型特性和功能的逐步透明化來增強可使用性。

這是關于 SOA 編程模型系列文章中的第一篇，特別針對軟件開發專業人員。在本系列中，我們介紹了實現這些目標的一些新的編程模型元素。我們介紹了如何利用它們來使您選擇、開發、建議或管理的軟件能夠更加容易的開發、重用和消費。將軟件構造為服務對于按需的企業來說更加有價值，因為不具備太多技能的開發人員可以將其"接入"到解決方案中，或者編入一個業務流程編排流中來滿足快速變更的業務需求。不管你是大型企業或者小型業務的開發人員、獨立軟件供應商（ISV），還是應用程序提供者或者中間件供應商，你都可以通過這種方式構造你的軟件，從而從中受益。那么，讓我們立即開始應用 SOA 原理。

SOA 編程模型的亮點
讓我們首先重點介紹 SOA 編程模型的幾個主要特性。

服務數據對象（SDO）是 IBM SOA 中的一個基礎概念。SDO 大大提高了開發人員的生產力，并且將你從如何訪問特定后端數據源、應用程序和服務的技術細節中解脫出來。它們提供了簡化的抽象，使程序員可以更多的集中在業務邏輯上。SDO 還提供了統一的消息表示來與服務交互，淘汰了用于數據表示的復雜技術迷宮，僅僅訪問單個統一模型。

SOA 編程模型同樣需要統一的范型來創建和訪問業務邏輯。為了易于使用，服務應該隱藏實現技術之間的差別，并應該建立在比現有編程結構（比如 Enterprise Java™Bean（EJB））更高級別的抽象上。服務可以通過組裝到模塊（這些模塊可以組成解決方案）中的組件來實現。通過組件公開的服務可以使用可定位的接口來調用。您可以使用 Web 服務描述語言（WSDL）、Java 或其他語言來描述接口。這個實現類型可以有對所需服務的待定引用，在將組件結合在一起執行之前，這些服務是滿足需求的。

這個編程模型還引入了良好定義的組件類型，對程序員開發和部署到解決方案中的常用構件建模。例子包括"無格式舊 Java 對象"、業務流程執行語言（BPEL）流程、結構化查詢語言（SQL）服務、Adaptive Business Objects、通過 Java 連接器體系結構（J2C）資源適配器訪問的 CICS®程序、使用 SAP 業務應用程序編程接口的應用程序、Java 2 Enterprise Edition（J2EE）無狀態會話 bean 和 MQSeries® 應用程序。

企業服務總線是多協議結構的一個關鍵角色，將服務組件編成無縫的交互，通過在消息路徑中加入被稱為中介的特別組件，來代理服務間的交互，而不用更改現有的端點，從而允許在核心級別上處理企業關注的內容 -- 比如審核、日志、路由、不匹配接口的適配、等價組件的增量替換、安全等。

新的流程語言縮小了 IT 概念和業務構件之間的間隙。很重要的一個是 BPEL。雖然流程可以通過業務分析員引入圖形化工具來定義，但它也是一個可執行程序。流程在按需業務轉換中占有重要的地位，例如為擴展價值鏈描述長時間運行的可執行流程。通過擴展價值鏈，我們可以跨越多個供應商和 IT 域來進行業務安排，比如一個零售商和他的多個獨立的供應商，保險公司及其眾多的第三方理賠員，IT 外購狀況等。

業務狀態機（business state machine）是業務分析師可以通過圖形工具創建流程的另一個編程框架，并且在流程設計引擎中執行。狀態機可以表示業務構件 -- 比如采購單、保險索賠等 -- 這些轉換通過一些良好定義的狀態來響應特定的生命周期"事件"。

需要重用的組件可以封裝為具有可變點（points of variability）的模板，可以在放入解決方案中時進行設計。這種適配成為我們的編程模型的第一部分，同時結合規則語言和相關的工具，為新型用戶提供定制的能力。

另一個創新領域是新的解決方案模型，它讓部署者、管理者和其它業務用戶可以將組件組裝成解決方案。在開發的時候，你可以將服務實現與托管服務的拓撲（系統架構師建模的部署拓撲）關聯在一起。模型捕捉的系統需求和環境假設在早期的實現中進行校驗，降低了應用程序生命周期的費用，并且極大的提高了可靠性和可計賬性（accountability）。該模型的特性還包括現有應用程序的后期綁定、數據轉換中介和適配器，可以通過企業服務總線來實現面向服務的交互。

總的來說，SOA 編程模型將開發和部署活動分割為不同的階段，這些階段可以發生在不同的時間，并且可以通過不同的個人使用不同的技能來實現。這就產生了關系的分離，使軟件組件可以被重用。它也將軟件體驗劃分為單獨用戶的業務角色、技能和任務。最終，它使軟件生命周期可以適應按需企業的需要，因為它們通過針對業務靈活性重新設計 IT 流程來尋求更高的有效性。

編程模型的概念
編程模型通常是 IBM SOA 和 IBM 產品的核心。它定義了程序員可以構建和使用的概念和抽象。運行時產品，例如 WebSphere® Application Server，DB2®和 CICS，可以運行或托管編程模型構件。開發工具支持編程模型構件的建模和實現、組裝到應用程序（解決方案），以及部署到運行時環境中。最后，系統管理產品、代理和設備支持對運行時和它們托管的編程模型構件的管理。

編程模型是什么？雖然目前沒有公認的一般定義，但我們喜歡將它定義為：

• 程序員構建的一套部件類型。部件類型包括多種編程模型構件：超文本標記語言（HTML）文件、數據庫存儲過程、Java 類、可擴展標記語言（XML）Schema 定義、定義 MQSeries 消息的 C 結構，等等。
• 一系列角色，將具備相似技能和知識的開發和管理人員分組。用這種方式對開發人員分類有助于生產適應于角色的工具，使非程序員可以實現服務并將服務組裝為解決方案。業務分析人員定義業務流程，銷售專家定義顧客分類的策略并計算產品折扣。每一種角色包含：
  • 角色所具備的技能。例如，用戶界面開發人員開發界面，用來呈現應用程序或者解決方案的功能構件。假設這個角色了解正在開發的應用程序和它的業務目標，充分了解應用程序的用戶及他們的任務，精通一些用戶界面設計方法，能夠通過為每個任務選擇恰當的類型來創建易于使用的用戶接口。
  • 角色交互（消費或者生產）所用的部件類型和應用程序接口。例如，動態頁面設計人員 -- 角色 -- 生產 JavaServer Page（JSP）并消費 EJB -- 部件類型 -- 包裝現有的信息資源和應用程序。
  • 角色使用的工具。例如，Web 開發人員所用的適合于角色的工具是所見即所得的頁面設計工具，用來構建動態頁面，使用與 HTML 和 JSP 標簽庫相關的控件，并將控件連接到 EJB。

使 Web 服務易于實現和使用的關鍵是對現有技術和知識進行增量擴展，從而使 SOA 可以被消費。以 CICS COBOL 事務程序形式存在的服務與用 BPEL 編寫的服務差別很大。從數據庫存儲過程中調用服務與從 JSP 中調用也是不同的；技能和期望值是不同的。通過提供工具的分類來使部件類型適應于各種技能，并適應于開發流程的階段，你可以實現可消費性（consumability）。

本系列的后續文章更加詳細的介紹了 SOA 編程模型的部件類型。

產品架構

圖 1. 產品架構
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

支持 IBM SOA 方案的產品分成兩個主要類別：服務端點和連接它們的消息傳送結構。這個通用的架構 -- 包含了許多產品，這些產品都不是 IBM SOA 的專用傳輸工具 -- 如圖 1 所示。

核心是服務間的 ESB 提供的連通性。ESB 是多協議的，支持點到點和發布-訂閱兩種通信類型，并支持快速處理消息的中介服務。IBM WebSphere MQ，IBM WebSphere MQ Integrator Broker 以及支持 Web 服務和 Java 消息服務（JMS）的 WebSphere 都屬于第一個類別。

服務存在于抽象的托管環境（容器）中，并且提供了特定的編程框架。容器加載服務的實現代碼，提供到 ESB 的連接性，并管理服務實例。不同類型的服務存在于不同的容器中。（在典型的遞規設計的例子中，ESB 本身被認為是用于中介服務的容器。）表 1 列出了一些主要的 IBM SOA 托管環境和托管的組件類型。

表 1. 托管各種組件和服務類型的容器

服務/組件類型	容器
用 COBOL、PL/1 和其他語言編寫的事務處理程序	CICS 或者 IMS（信息管理系統 -- 一種企業事務處理系統）。程序員可以使用 SOAP/HTTP、WebSphere MQ 和 J2EE J2C 連接來訪問服務。
業務流程編排	WebSphere Business Integration Server Foundation。該容器支持長期存在的工作流，這些工作流實現了 Web 服務接口并調用其他 Web 服務上的操作。它同樣支持長期運行的業務活動事務。
應用程序適配器 -- 為現有的應用程序和系統提供 SOA/Web 服務的會話虛包（facade）。	WebSphere Business Integration Server Foundation 提供的應用程序適配器容器。適配器在 SOA 協議和格式，以及現有應用程序和系統的協議和格式之間進行轉換。例如，SAP 適配器將 SOA 編碼并通過 HTTP 傳輸的 XML 轉換到 SAP 的現有業務應用程序編程接口格式和 Remote Function Call（RFC）。
預定義的 SQL 查詢、XML 查詢或數據庫存儲過程實現的服務	DB2 結合 WebSphere Application Server。查詢的參數來自 SOA 操作的輸入消息以及提供輸出消息的結果。
使用 Java 類和 EJB 實現的服務。	WebSphere Application Server。

結束語
IBM SOA 編程模型系列文章的第一篇概述了 IBM 工具和產品如何適用于模型，以及開發人員如何有效的在應用程序開發中使用它。

• 使用 SDO 簡化數據訪問
• 服務定義以及組件模型發展狀況的介紹
• 用組件類型來簡化開發
• 基本組件類型
• 服務組合和定制
• 流程組件：BPEL 和業務狀態機
• 定制服務：設計模式，模板和可變點
• 面向服務的用戶接口
• 用于管理的 SOA 方法
• SOA 軟件生命周期開發工具
• SOA 的安全性

期待。