《SOA 快速指南 1 2 3》系列文章是筆者在近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。該系列文章以一個示例場景為背景， 總結(jié)了利用 IBM 的方法實施 SOA 的一般步驟，并詳細闡述了每個實施步驟中使用的 IBM 的方法學、技術(shù)和產(chǎn)品。
以服務為中心的業(yè)務活動管理與監(jiān)控是最近出現(xiàn)的一種熱門的 IT 技術(shù)，它的目的在于幫助企業(yè)管理人員實時獲悉企業(yè)運營狀況，了解企業(yè)的戰(zhàn)略實施進展。本文結(jié)合一個汽車貸款流程介紹了在 SOA 的環(huán)境下如何基于IBM的現(xiàn)有產(chǎn)品構(gòu)造業(yè)務活動管理解決方案。希望通過本文的介紹，能夠幫助讀者理清業(yè)務流程管理所包含的基本概念，并了解構(gòu)建解決方案所需要的基本步驟。
從此處鏈接到
項目實現(xiàn)。
關(guān)于作者
IBM中國軟件開發(fā)實驗室 SOA 設計中心是 IBM 全球四個 SOA 設計中心中最大的一個，成立一年多來，已經(jīng)取得了可喜的成果。我們在全球范圍內(nèi)實施了多個 SOA 應用項目，為多個行業(yè)的客戶提供了 SOA 解決方案。我們正在實施的 SOA 項目涵蓋了很多的重要行業(yè)，包括零售業(yè)、航運業(yè)、電力、銀行、保險等等。通過這些不斷增長的成功案例，我們不僅深入地推廣了 SOA 的理念，樹立了 SOA 成功實施的范例，也為我們的隊伍積累了經(jīng)驗，培養(yǎng)了人才。與此同時，我們還是 IBM 開發(fā) SOA 的軟件平臺的主力軍。這個新的平臺基于模型驅(qū)動的思想，旨在最大化地重用軟件資產(chǎn)，它為 SOA 項目的實施提供了一整套源自成功實踐的方法論、設計范式和工具集。它的出現(xiàn)將極大地方便 SOA 系統(tǒng)架構(gòu)師、設計人員、開發(fā)人員，使他們能夠快速地開發(fā) SOA 應用項目。
參與本系列文章撰寫的主要技術(shù)人員包括：
金戈， IBM 中國軟件開發(fā)實驗室 IBM 中國SOA 設計中心客戶服務經(jīng)理, IBM 中國 SOA 設計中心架構(gòu)師。多年軟件設計和解決方案設計經(jīng)驗，精通軟件工程、分布式中間件、Linux以及系統(tǒng)管理，并擁有豐富的Linux和SOA架構(gòu)、設計、開發(fā)技術(shù)經(jīng)驗。聯(lián)系方式：jinge@cn.ibm.com。
姚輝，IBM 中國軟件開發(fā)實驗室 IBM 中國SOA 設計中心高級工程師。具有多年的面向?qū)ο笤O計與開發(fā)經(jīng)驗，目前專注于SOA的相關(guān)理論與項目實踐。對EA、SOA、BPM、EAI等領(lǐng)域有濃厚的興趣。聯(lián)系方式：yaohui@cn.ibm.com。
趙勇，IBM 中國軟件開發(fā)實驗室 IBM 中國SOA 設計中心工程師。具有多年的 J2EE 和 Web Service 開發(fā)經(jīng)驗，目前專注于 SOA 項目實踐和相關(guān)的理論，工具的研究和開發(fā)。對ESB、SCA、BPEL、自動化測試和極限編程等技術(shù)有濃厚的興趣。聯(lián)系方式：zhaoyong@cn.ibm.com。
譚佳，IBM 中國軟件開發(fā)實驗室 IBM 中國SOA 設計中心工程師。擁有多個SOA項目實施經(jīng)驗，目前對于J2EE、SOA、EAI、BPM、Data Mining和語義網(wǎng)等相關(guān)技術(shù)有濃厚興趣。聯(lián)系方式：
tanjia@cn.ibm.com。
第 1 部分：SOA采納步驟和價值分析2006 年 12 月
本文前半部分首先概覽了實施SOA的簡單步驟，然后介紹了貫穿本系列文章的示例場景。在文章的后半部分著重介紹了IBM SOA成熟度模型和SOA評估框架，并分析了示例場景中采納SOA的步驟和價值。
第 2 部分：服務建模2006 年 12 月
本文首先介紹了服務建模的方法學；對示例場景進行流程建模，為服務建模做準備；在第一部分文章對現(xiàn)有業(yè)務和 IT 環(huán)境分析的基礎上，結(jié)合價值分析和流程建模的結(jié)果，設計了目標的業(yè)務和 IT 場景；基于業(yè)務組件模型、流程模型以及業(yè)務目標進行服務建模的前兩個步驟——服務發(fā)現(xiàn)和服務規(guī)約。
第 3 部分：服務實現(xiàn)及架構(gòu)設計2007 年 1 月
本文的目的是進行服務建模的第三部分：服務實現(xiàn)，并完成架構(gòu)設計的工作。第二部分已經(jīng)整體的闡述了服務建模的概念和方法，本文就不再重復，因此首先介紹 IBM的SOA的參考架構(gòu)，作為架構(gòu)設計的指導；然后結(jié)合場景的業(yè)務目標以及IT環(huán)境設計試點項目的架構(gòu)，并重點突出關(guān)鍵點的架構(gòu)決策。
第 4 部分：快速實現(xiàn)服務集成模型2007 年 2 月
本文承接前面系列文章的分析和建模的結(jié)果，主要進行SOA實施的層面上的探討，首先介紹SOA項目實施的準備工作，然后介紹在實施過程中怎樣利用分析建模的結(jié)果定義服務并將服務分配到模塊中，根據(jù)模塊的分析得到服務的集成模型，從中總結(jié)出一些有價值的指導原則和實施細則，希望對SOA項目方面的開發(fā)測試人員有所幫助。本文假定讀者能夠使用WID進行基本的SCA開發(fā)和相關(guān)的操作。
第 5 部分：逐步實現(xiàn)服務和持續(xù)集成2007 年 2 月
本文承接上篇文章定義的服務模塊和服務集成模型，首先簡要介紹了服務模塊的逐步實現(xiàn)，對各種服務模塊進行分析；然后闡述了如何根據(jù)模擬服務進行迭代的開發(fā)和集成，其中涉及到服務組件的測試，模擬測試客戶端，以及模擬服務的實現(xiàn)；最后強調(diào)了SOA實施中的持續(xù)集成和持續(xù)測試。我們希望通過本文使讀者對SOA項目的開發(fā)和測試形成基礎的認識，對于一些重要的方法和特殊的手段能夠有所了解。
第 6 部分：以服務為中心的業(yè)務活動管理與監(jiān)控2007 年 2 月
《以服務為中心的業(yè)務活動管理和監(jiān)控》是本系列文章的最后一個部分，將結(jié)合本系列文章所使用的汽車貸款實例介紹如何實現(xiàn)構(gòu)建企業(yè)的業(yè)務流程管理模型。本文的組織方式是：第二節(jié)介紹業(yè)務活動監(jiān)控的基本概念，即什么是業(yè)務監(jiān)控，它與傳統(tǒng)商業(yè)智能之間的關(guān)系是什么；第三節(jié)描述創(chuàng)建業(yè)務流程管理模型的基本步驟，即從何入手建立一個完整的企業(yè)業(yè)務活動監(jiān)控模型，第四節(jié)則結(jié)合本系列的業(yè)務場景使用IBM最新推出的WBI Modeler 6來介紹如何構(gòu)造一個業(yè)務活動監(jiān)控模型，最后是總結(jié)。希望通過本文的介紹，能夠幫助讀者理清基本的概念脈絡，了解構(gòu)建業(yè)務活動監(jiān)控模型主要的實施步驟，從而為在將來的項目中實現(xiàn)業(yè)務活動管理奠定良好的基礎。
SOA 快速指南 1 2 3，第 1 部分: SOA 采納步驟和價值分析
文檔選項
將此頁作為電子郵件發(fā)送拓展 Tomcat 應用
下載 IBM 開源 J2EE 應用服務器 WAS CE 新版本 V1.1級別: 初級
金 戈, IBM軟件部企業(yè)集成解決方案架構(gòu)師, IBM 中國軟件開發(fā)實驗室 SOA設計中心
姚 輝 (
yaohui@cn.ibm.com), IBM 中國SOA 設計中心高級工程師, IBM 中國軟件開發(fā)實驗室
趙 勇 (
zhaoyong@cn.ibm.com), IBM 中國SOA 設計中心工程師, IBM 中國軟件開發(fā)實驗室
譚 佳, IBM 中國SOA 設計中心工程師, IBM 中國軟件開發(fā)實驗室
2006 年 12 月 26 日
《SOA 采納步驟和價值分析》是本系列文章的第一部分。本文前半部分首先概覽了實施 SOA 的簡單步驟，然后介紹了貫穿本系列文章的示例場景。在文章的后半部分著重介紹了IBM SOA 成熟度模型和SOA評估框架，并分析了示例場景中采納 SOA 的步驟和價值。
以服務為中心的業(yè)務活動管理與監(jiān)控是最近出現(xiàn)的一種熱門的IT技術(shù)，它的目的在于幫助企業(yè)管理人員實時獲悉企業(yè)運營狀況，了解企業(yè)的戰(zhàn)略實施進展。
《SOA 快速指南 1 2 3》系列文章是筆者近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。該系列文章結(jié)合一個汽車貸款流程， 介紹了在 SOA 的環(huán)境下如何基于 IBM 的現(xiàn)有產(chǎn)品構(gòu)造業(yè)務活動管理解決方案，詳細闡述了每個實施步驟中使用的 IBM 的方法學、技術(shù)和產(chǎn)品。希望通過本文的介紹，能夠幫助讀者理清業(yè)務流程管理所包含的基本概念，并了解構(gòu)建解決方案所需要的基本步驟。
回頁首本系列是 IBM 中國軟件開發(fā)實驗室 SOA 設計中心近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。
項目概述 第 1 部分：SOA 采納步驟和價值分析 第 2 部分：服務建模 第 3 部分：服務實現(xiàn)及架構(gòu)設計 第 4 部分：快速實現(xiàn)服務集成模型 第 5 部分：逐步實現(xiàn)服務和持續(xù)集成 第 6 部分：以服務為中心的業(yè)務活動管理與監(jiān)控 SOA是一個既簡單又復雜的技術(shù)。簡單地說，SOA就是一組設計原則，這些設計原則既有SOA特有的，如服務是第一概念[CBDI]，業(yè)務和IT對齊，為靈活而構(gòu)建；也有被早已被業(yè)界廣泛接受和使用的，如松散耦合、隔離關(guān)注、模塊化、可重用性等。復雜地說，SOA是由這些設計原則衍生出的各種技術(shù)，如SOA成熟度模型、服務建模方法學、SOA編程模型、企業(yè)服務總線、服務注冊庫等。
同樣，對SOA的采納（Adoption）形式也具有從簡單到復雜各種形式。一個分布式企業(yè)IT系統(tǒng)全面向SOA轉(zhuǎn)型固然是SOA，而像HousingMap.com這樣將Google Map提供的Web服務和Craiglist提供的Web服務集成起來提供全新的業(yè)務模式也不能不算SOA。筆者作為主要的技術(shù)人員主導或參加了若干SOA的實施案例，這里面有短暫的SOA試點項目，也有大跨度的SOA實施。從實踐的角度而言，筆者認為一般的SOA的實施項目應該包含如下步驟：
0. SOA采納步驟和價值分析：由于客戶現(xiàn)有IT環(huán)境和業(yè)務環(huán)境的不同，采納SOA的價值和采納的步驟也會相應不同。對任何一個企業(yè)或者是應用提供商，在采納SOA之前最好深刻理解SOA的內(nèi)涵和外延，并客觀分析采納SOA的好處以及帶來的風險，并實際情況規(guī)劃SOA實施的步驟。
1. SOA監(jiān)管：和傳統(tǒng)技術(shù)不同的是，SOA是一個橫向的技術(shù)，它不僅影響IT系統(tǒng)的設計者和開發(fā)者，它更需要改變業(yè)務部門對IT系統(tǒng)的看法，也需要運營部門改變系統(tǒng)運營的方式。幾乎所有的相關(guān)人的活動都會圍繞著服務模型和服務元數(shù)據(jù)。因此服務模型和服務元數(shù)據(jù)質(zhì)量直接決定著企業(yè)向SOA轉(zhuǎn)型的效果。簡單的說，SOA監(jiān)管通過建立適當組織和流程保證服務模型和服務元數(shù)據(jù)在創(chuàng)建時和運行時的質(zhì)量。可以預見的是，一個企業(yè)采納了SOA后，SOA監(jiān)管會成為企業(yè)IT部門的重要任務之一。
2. 服務建模：如何根據(jù)服務建模方法學創(chuàng)建符合SOA設計原則的服務模型是實施SOA中及其重要的一步。發(fā)現(xiàn)服務候選、決定服務暴露和進行服務規(guī)約是這一步的重要內(nèi)容。
3. 服務實現(xiàn)和架構(gòu)設計：根據(jù)確定的服務模型，結(jié)合現(xiàn)有IT環(huán)境確定服務和服務組件的實現(xiàn)策略，并設計用于實現(xiàn)服務的基礎架構(gòu)(如ESB、流程服務引擎、人工服務容器等)是也是實施SOA過程中及其重要的一步。服務組件劃分、服務實現(xiàn)決策和服務基礎設施設計是這一步的重要內(nèi)容。
4. 以服務為中心的開發(fā)和集成：在SOA的實施項目中，開發(fā)和集成的模式都會發(fā)生相應的變化，服務會成為開發(fā)階段的中心概念。服務模型映射到編程模型，逐步實現(xiàn)服務，并在服務層次上進行持續(xù)的集成是這一階段的主要內(nèi)容。
5. 服務管理：以上的步驟主要側(cè)重在功能層次上如何一步步實現(xiàn)SOA，而服務管理則側(cè)重于在SOA實施中如何實現(xiàn)非功能性需求，這包括服務性能、服務安全等。
本系列文章將圍繞SOA的實施步驟組織，但是SOA監(jiān)管和服務管理不在本系列文章的范圍內(nèi)。
回頁首本系列文章所涉及的場景是一個汽車貸款審批業(yè)務流程，從申請人提交申請到汽車銷售商接受貸款并發(fā)貨（或者申請人接收拒絕通知）。
從銀行的業(yè)務角度，該業(yè)務流程的外部參與者包括最終用戶（申請人、汽車銷售商）和合作伙伴（保險公司），內(nèi)部參與者包括業(yè)務執(zhí)行人員（信貸員）以及風險管理人員(信貸經(jīng)理)。從技術(shù)實現(xiàn)的角度，該業(yè)務流程既包含自動化的內(nèi)部功能（查詢存貸款記錄）和外部功能（保險公司提供擔保），也包括人工活動（信貸經(jīng)理審批）。因此，該場景具備一般業(yè)務流程的典型性，基于該場景的SOA實施示例具備更大的借鑒意義。
從圖2可以看出，信貸員是整個業(yè)務流程的樞紐，負責與客戶、信貸經(jīng)理、相關(guān)應用系統(tǒng)打交道。這種業(yè)務模式既增大了信貸員的工作強度，也增加了過程中的操作風險以及道德風險。
從圖3可以看出，在業(yè)務流程中起到樞紐作用的信貸員，通過不同的方式訪問不同的系統(tǒng)，獲取申請人的相關(guān)信息，同時通過電子辦公系統(tǒng)向信貸經(jīng)理提交貸款審批申請。多樣化的人機界面既增加了對信貸員的IT技能要求，也極大的降低了信貸員的工作效率。
回頁首如上所述，SOA是由一些設計原則衍生出的一系列技術(shù)。和傳統(tǒng)的方法不同的是，SOA的這些衍生技術(shù)遍布企業(yè)IT生命周期，以及企業(yè)IT系統(tǒng)的各個層次。為了評估一個企業(yè)的實施SOA的程度，我們需要一個覆蓋全面的評估標準和一種對成熟度的劃分。SOA評估框架就是這里說的評估標準，而SOA成熟度模型就是一種對SOA成熟度的劃分。SOA的評估框架和SOA成熟度模型是了解企業(yè)IT和業(yè)務環(huán)境現(xiàn)狀，分析企業(yè)采納SOA的步驟和價值的重要工具。這里我們以IBM的SOA評估框架和SOA成熟度模型為例進行介紹。
IBM的SOA評估框架主要分析企業(yè)IT系統(tǒng)在如下四個方面的特性:
1. 組織和流程：企業(yè)是否有實施SOA的經(jīng)驗，實施SOA的范圍多大，企業(yè)是否規(guī)劃過需要實現(xiàn)的SOA的能力，業(yè)務部門是否理解SOA實施的價值和過程，特別是業(yè)務部門參與重要性，是否有系統(tǒng)的方法指導服務的發(fā)現(xiàn)和設計，業(yè)務部門在服務的發(fā)現(xiàn)和設計中參與的程度如何;
2. 應用：目前應用如何暴露可重用的邏輯？應用間連通的實時和異構(gòu)特性如何？企業(yè)開始在多大構(gòu)建復合應用？
3. 架構(gòu)：目前企業(yè)應用集成現(xiàn)狀？企業(yè)應用的組件化程度如何？是否存在服務模型？范圍多大？
4. 基礎架構(gòu)：基礎架構(gòu)如何保持可擴展性和靈活性保證滿足業(yè)務部門的需要？基礎設施如何響應業(yè)務流程性能的變化？是否存在統(tǒng)一的安全架構(gòu)和規(guī)范？
同時，IBM的SOA成熟度模型將SOA成熟度劃分為7個層次：
L1. 孤立的：大多數(shù)為孤立應用，存在集成也基本上以數(shù)據(jù)集成為主；當需求發(fā)生變化時，需要大量的瑣碎的架構(gòu)調(diào)整；
L2. 集成的：應用間存在大量集成，但是以點到點的連接方式為主，應用程序的重構(gòu)主要通過數(shù)據(jù)集成完成；
L3. 組件化的：將主要的或關(guān)鍵的應用從功能角度進行了組件劃分，原有的J2EE/.Net等應用通過重構(gòu)實現(xiàn)這些組件，組件間的集成通過組件接口和相互間的契約完成；
L4. 簡單服務：存在業(yè)務部門內(nèi)的服務模型和構(gòu)建在服務上的業(yè)務流程集成；
L5. 組合服務：存在企業(yè)范圍內(nèi)和企業(yè)間的服務模型，已經(jīng)在服務模型基礎上完成價值鏈集成；
L6. 虛擬化服務：基礎設施如服務器和存儲已經(jīng)完成虛擬化，服務運行在這些虛擬化的基礎設施之上；基礎設施、服務組件、服務、業(yè)務流程被極大解耦；通過對基礎設施的監(jiān)控和管理來保證服務質(zhì)量；
L7. 動態(tài)配置服務：服務可以根據(jù)業(yè)務策略和IT策略進行動態(tài)組裝；
回頁首我們對示例場景中SOA現(xiàn)有成熟度分析總結(jié)如下：
1. 組織和流程：無論是在貸款業(yè)務部門，還是在其他業(yè)務部門，都沒有進行過SOA的實施；業(yè)務人員普遍認為SOA是技術(shù)層面的事情，是IT部門的事情，業(yè)務部門在SOA實施中沒有任何責任；
2. 應用：構(gòu)建在主機上的核心銀行系統(tǒng)業(yè)務邏輯體現(xiàn)為CICS的事務，業(yè)務邏輯劃分清晰，但是邏輯和表示緊耦合，而且其業(yè)務邏輯劃分和整體需求有一定差距，該銀行已經(jīng)構(gòu)建EAI的基礎設施，核心銀行系統(tǒng)的業(yè)務邏輯可以通過EAI中的消息總線訪問；房貸和車貸系統(tǒng)分布構(gòu)建在J2EE和.Net平臺之上，設計系統(tǒng)時對組件化考慮的很充分，主要的業(yè)務邏輯都構(gòu)建在公共的組件基礎之上，如果其他系統(tǒng)需要訪問房貸和車貸系統(tǒng)，需要進行點到點的集成；保險公司擔保網(wǎng)關(guān)是外部系統(tǒng)，已經(jīng)服務化。
3. 架構(gòu)：企業(yè)消息總線可以連通除房貸和車貸系統(tǒng)以外的大部分系統(tǒng)，但是消息總線中介能力不強，主要集中在消息轉(zhuǎn)換，對重復業(yè)務邏輯的訪問需要應用層處理；
4. 基礎架構(gòu)：服務器、存儲和網(wǎng)絡設施異構(gòu)性很大，業(yè)務系統(tǒng)性能的調(diào)控相當剛性；已經(jīng)具有統(tǒng)一的安全架構(gòu)，如認證、授權(quán)和加密；
綜合分析可見，對于整體企業(yè)而言其SOA成熟度，位于L2和L3之間；房貸和車貸系統(tǒng)SOA成熟度位于L3。
對于SOA的轉(zhuǎn)型，該企業(yè)的近期目標是希望能夠在現(xiàn)在的現(xiàn)有的房貸和車貸系統(tǒng)之上構(gòu)建復合應用以支持汽車貸款審批流程；而該企業(yè)的長遠目標是構(gòu)建企業(yè)范圍的服務模型，并逐步改造所有的應用為復合應用，并期望實現(xiàn)價值鏈集成。由此可見，對于圍繞汽車貸款審批流程的房貸和車貸系統(tǒng)SOA改造的目標成熟度是L5；從企業(yè)范圍而言，希望現(xiàn)在房貸和車貸構(gòu)建SOA應用，而逐步擴展到整個企業(yè)，所以其目標成熟度先是L4，然后遷移到L5。
回頁首結(jié)合示例場景的特點和SOA轉(zhuǎn)型的需要，我們建議如下SOA采納步驟：
第一步：以汽車貸款審批流程為中心進行SOA試點 （ L2/3 -> L4 ）在這一步中，圍繞汽車貸款審批流程進行服務建模分析，并在現(xiàn)有系統(tǒng)上構(gòu)建企業(yè)服務總線。這一步的主要目標有四：第一）測量SOA可能帶來的業(yè)務層面的價值，通過服務組裝完成汽車貸款流程，來驗證如何通過服務中介、服務替換和服務重新組裝適應可能的業(yè)務變化，從而實現(xiàn)業(yè)務流程從建?！詣踊O(jiān)控‘優(yōu)化的全生命周期；第二）測量SOA可能帶來的IT層面價值，通過將已有系統(tǒng)暴露為服務，并構(gòu)建ESB實現(xiàn)虛擬化的服務，來驗證將現(xiàn)有系統(tǒng)暴露為服務的技術(shù)可行性，驗證ESB如何通過實現(xiàn)廣泛連接性、驗證如何通過服務中介完成重復邏輯合并和異構(gòu)系統(tǒng)集成、驗證如何SOA架構(gòu)如何適應IT層面的變化如系統(tǒng)集中、系統(tǒng)合并和系統(tǒng)升級；第三）深化IT部門對實施SOA的技術(shù)理解，包括服務建模方法學、SOA架構(gòu)設計、相關(guān)技術(shù)和產(chǎn)品的成熟度（安全，性能，…）； 第四）深化IT部門和業(yè)務部門對實施SOA的方法和價值理解，包括SOA背后的價值驅(qū)動，如何建立SOA組織和流程進行SOA監(jiān)管等；
第二步：重構(gòu)貸款系統(tǒng)以實現(xiàn)貸款部門的服務模型，并將業(yè)務流程實現(xiàn)為復合應用 ( L2/3 -> L4 ) 在這一步中，圍繞貸款部門的業(yè)務流程進行服務建模（這不僅包括貸款業(yè)務部門內(nèi)部的服務，還包括可能訪問到的核心銀行系統(tǒng)的服務），并將主要業(yè)務流程遷移為復合應用。這一步的主要目標有三：第一）繼續(xù)深化IT部門對實施SOA的技術(shù)理解，并培養(yǎng)SOA實施的各層次的技能；為企業(yè)范圍內(nèi)的SOA實施做技術(shù)準備，如各種SOA實施技術(shù)規(guī)范－SOA參考架構(gòu)，服務模型規(guī)范，企業(yè)服務總線規(guī)范等； 第二）繼續(xù)深化IT部門和業(yè)務部門對實施SOA方法和價值理解，初步建立業(yè)務部門內(nèi)的SOA監(jiān)管組織、流程和基礎設施（如服務注冊庫）等；第三）驗證現(xiàn)有SOA技術(shù)和產(chǎn)品在大規(guī)模應用時的成熟度；
第三步：以消息總線的改造為中心，構(gòu)建SOA監(jiān)管組織和流程，并創(chuàng)建企業(yè)服務模型和企業(yè)范圍內(nèi)SOA的基礎架構(gòu)；( L4 -> L5) 這一步選擇以消息總線為中心的原因在于，1）消息總線涉及主要的業(yè)務邏輯和業(yè)務流程，而且該企業(yè)在構(gòu)建消息總線時已經(jīng)對核心的業(yè)務進行了必要的調(diào)查和分析，這是服務建模的良好基礎；2）消息總線是主要的應用集成設施，這是企業(yè)服務總線構(gòu)建的良好基礎。通過這一步驟，企業(yè)范圍的SOA基礎架構(gòu)基本形成，這包括SOA監(jiān)管組織和流程、企業(yè)范圍內(nèi)服務模型、企業(yè)服務總線和SOA參考架構(gòu)；
第四步：逐步遷移主要業(yè)務流程為復合應用，并完善SOA監(jiān)管和服務模型；(L4->L5) 這一步主要是在前一步的建立的SOA基礎架構(gòu)之上逐步將應用遷移到復合應用。實際上第三步和第四步應該是融和在一起的；
第五步：圍繞價值鏈整合實現(xiàn)快速響應IT系統(tǒng); (L5) 當完成SOA基礎設施建設和復合應用遷移后，企業(yè)已經(jīng)具備條件進行流程優(yōu)化和價值鏈整合。這種條件下，無論是IT層面的調(diào)整，還是業(yè)務層面的調(diào)整，都可以通過服務模型和企業(yè)服務總線隔離變化，從而使用盡量小的代價完成對變化的適應，也即達到快速響應的IT。
本系列文章的后續(xù)部分將圍繞SOA采納的第一步 -- 以汽車貸款審批流程為中心進行SOA試點 為背景介紹SOA實施的其他步驟
SOA 快速指南 1 2 3，第 2 部分: 服務建模
文檔選項
將此頁作為電子郵件發(fā)送拓展 Tomcat 應用
下載 IBM 開源 J2EE 應用服務器 WAS CE 新版本 V1.1級別: 初級
金 戈, IBM軟件部企業(yè)集成解決方案架構(gòu)師, IBM 中國軟件開發(fā)實驗室 SOA設計中心
姚 輝 (
yaohui@cn.ibm.com), IBM 中國SOA 設計中心高級工程師, IBM 中國軟件開發(fā)實驗室
趙 勇 (
zhaoyong@cn.ibm.com), IBM 中國SOA 設計中心工程師, IBM 中國軟件開發(fā)實驗室
譚 佳, IBM 中國SOA 設計中心工程師, IBM 中國軟件開發(fā)實驗室
2006 年 12 月 26 日
《服務建模》是本系列文章的第二部分。本系列的第一部分概覽了實施 SOA 的簡要步驟，并針對示例場景分析了采納 SOA 的步驟和價值。本文首先介紹了服務建模的方法學；對示例場景進行流程建模，為服務建模做準備；在第一部分文章對現(xiàn)有業(yè)務和 IT 環(huán)境分析的基礎上，結(jié)合價值分析和流程建模的結(jié)果，設計了目標的業(yè)務和 IT 場景；基于業(yè)務組件模型、流程模型以及業(yè)務目標進行服務建模的前兩個步驟——服務發(fā)現(xiàn)和服務規(guī)約。
以服務為中心的業(yè)務活動管理與監(jiān)控是最近出現(xiàn)的一種熱門的IT技術(shù)，它的目的在于幫助企業(yè)管理人員實時獲悉企業(yè)運營狀況，了解企業(yè)的戰(zhàn)略實施進展。
《SOA 快速指南 1 2 3》系列文章是筆者近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。該系列文章結(jié)合一個汽車貸款流程， 介紹了在 SOA 的環(huán)境下如何基于 IBM 的現(xiàn)有產(chǎn)品構(gòu)造業(yè)務活動管理解決方案，詳細闡述了每個實施步驟中使用的 IBM 的方法學、技術(shù)和產(chǎn)品。希望通過本文的介紹，能夠幫助讀者理清業(yè)務流程管理所包含的基本概念，并了解構(gòu)建解決方案所需要的基本步驟。
回頁首本系列是 IBM 中國軟件開發(fā)實驗室 SOA 設計中心近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。
項目概述 第 1 部分：SOA 采納步驟和價值分析 第 2 部分：服務建模 第 3 部分：服務實現(xiàn)及架構(gòu)設計 第 4 部分：快速實現(xiàn)服務集成模型 第 5 部分：逐步實現(xiàn)服務和持續(xù)集成 第 6 部分：以服務為中心的業(yè)務活動管理與監(jiān)控 眾所周知，面向?qū)ο蟮膽脴?gòu)建在類和對象之上。
隨后發(fā)展起來的建模技術(shù)將相關(guān)的對象按照業(yè)務功能進行分組，就形成了組件的概念；對于跨組件的功能調(diào)用，則采用接口的形式暴露出來。
進一步的將接口的定義與接口的具體實現(xiàn)進行解耦，就催生了SOA。而作為業(yè)務和IT之間的契約的服務，是SOA最重要的概念。
因此面向?qū)ο?、基于組件、面向服務是三個遞進的抽象層次。
現(xiàn)在我們有OOAD（Object Oriented Analysis Design）和CBD（Component Based Development）來進行面向?qū)ο蠛突诮M件的建模與開發(fā)。但是沒有一個好的方法來進行SOA的分析、設計和開發(fā)。SOMA（Service Oriented Modeling Architecture）就是在這個背景下誕生的，其主要目的就是填補OOAD和CBD在建模領(lǐng)域留下的空白，為SOA實施提供一個方法學的指導。
需要特別指出的是，SOMA的出現(xiàn)并不是要替代OOAD或者CBD，正如CBD需要借助OOAD一樣，SOMA也要借助OOAD和CBD進行實現(xiàn)層面的建模。
與OOAD和CBD相比較而言，SOMA貫穿整個IT建設的生命周期，在項目規(guī)劃、設計、實施、運行中都起到重要的作用。本文就不展開闡述了，相關(guān)信息可見參考資料。
SOMA另外一個顯著的特點就是將IT與業(yè)務對齊。在具體的實施過程中，SOMA將業(yè)務特性，如：業(yè)務目標、關(guān)鍵業(yè)務指標等，延伸到IT的分析和架構(gòu)決策過程，從而縮小業(yè)務與IT之間的差距。具體來看，業(yè)務組件模型（或者類似業(yè)務分析方法論的結(jié)果）、端到端的業(yè)務流程以及關(guān)鍵業(yè)務指目標是SOMA的三項主要輸入，SOA的實現(xiàn)則是SOA的輸出，從這也可以看出SOMA的定位是在業(yè)務和IT之間。
按照實施的階段，SOMA分為服務發(fā)現(xiàn)、服務規(guī)約以及服務實現(xiàn)三個階段。
1）服務發(fā)現(xiàn)：采用自上而下、自下而上和中間對齊的方式，得到服務的候選者。
自上而下 （業(yè)務領(lǐng)域分解）方式從業(yè)務著手進行分析，我們將業(yè)務進行領(lǐng)域分解、流程分解，以及進行變化分析。
業(yè)務組件模型是業(yè)務領(lǐng)域分解的輸入。根據(jù)業(yè)務組件模型的詳細描述，我們可以將業(yè)務領(lǐng)域按照業(yè)務職責細分為業(yè)務范圍，并直接其映射到IT范疇的子系統(tǒng)，實現(xiàn)業(yè)務與IT的無縫連接。
頂級的業(yè)務流程是流程分解的輸入。將業(yè)務流程分解成子流程或者業(yè)務活動，逐級進行，直到每個業(yè)務活動都是具備業(yè)務含義的最小單元。流程分解得到的業(yè)務活動樹上的每一個節(jié)點，都是服務的候選者，構(gòu)成了服務候選者組合。在大部分情況下，服務候選者組合都是一個很長的列表，加上自下而上和中間對齊方式還有可能發(fā)現(xiàn)新的服務，因此將服務候選者按照某種方式進行分類是一件非常必要的事情。業(yè)務領(lǐng)域分解的結(jié)果——業(yè)務范圍是一個業(yè)務概念，同時可以無縫映射到IT范疇，因此它是一個好的分類原則。根據(jù)業(yè)務范圍，服務候選者組合可以被劃分服務候選者目錄。
變化分析的目的是將業(yè)務領(lǐng)域中易變的部分和穩(wěn)定的部分區(qū)分開來，通過將易變的業(yè)務邏輯及相關(guān)的業(yè)務規(guī)則剝離出來，保證未來的變化不會破壞現(xiàn)有設計，從而提升架構(gòu)應對變化的能力。變化分析可能會從對未來需求的分析中發(fā)現(xiàn)一些新的服務候選者，這些服務候選者需要加入到服務候選者目錄中。
自下而上（已有資產(chǎn)分析）方式的目的是利用已有資產(chǎn)來實現(xiàn)服務，已有資產(chǎn)包括：已有系統(tǒng)、套裝或定制應用、行業(yè)規(guī)范或業(yè)務模型等。
通過對已有資產(chǎn)的業(yè)務功能、技術(shù)平臺、架構(gòu)以及實現(xiàn)方式的分析，除了能夠驗證服務候選者或者發(fā)現(xiàn)新的服務候選者，還能夠通過分析已有系統(tǒng)、套裝或定制應用的技術(shù)局限性盡早驗證服務實現(xiàn)決策的可行性，為服務實現(xiàn)決策提供重要的依據(jù)。
中間對齊（業(yè)務目標建模）方式的目的是幫助發(fā)現(xiàn)與業(yè)務對齊的服務，并確保關(guān)鍵的服務在流程分解和已有資產(chǎn)分析的過程中沒有被遺漏。
業(yè)務目標建模將業(yè)務目標分解成子目標，然后分析哪些服務是用來實現(xiàn)這些子目標的。在這個過程中，為了可以度量這些服務的執(zhí)行情況并進而評估業(yè)務目標，我們會發(fā)現(xiàn)關(guān)鍵業(yè)務指標、度量值和相關(guān)的業(yè)務事件。
結(jié)合這三種方式的分析，我們發(fā)現(xiàn)服務候選者組合，并按照業(yè)務范圍劃分為服務目錄。同時為服務規(guī)約做好其他準備，如：通過對已有資產(chǎn)分析進行的技術(shù)可行性評估、通過業(yè)務目標建模發(fā)現(xiàn)的業(yè)務事件等等。
2）服務規(guī)約：定義實現(xiàn)服務的服務組件的細節(jié)，包括，數(shù)據(jù)、規(guī)則、服務、可配置概要、可能的變更，同時還會涉及到消息、事件的定義和管理。
經(jīng)過服務發(fā)現(xiàn)的階段，我們得到了候選服務目錄，接下來就需要決定暴露哪些服務。理論上所有的服務候選者都可以暴露為服務，但是一旦暴露為服務，該服務候選者就必須滿足附加的安全性、性能等方面的要求，企業(yè)還必須為服務的規(guī)劃、設計、開發(fā)、維護、監(jiān)管支付額外的開支，因此我們會根據(jù)一定的規(guī)則來決定將哪些服務候選者暴露為服務。
這些規(guī)則包含以下幾個方面：
業(yè)務對齊：該服務候選者可以支持相關(guān)的業(yè)務流程和業(yè)務目標。
可組裝：該服務候選者滿足技術(shù)中立、自包含以及無狀態(tài)等特點，同時還滿足復合應用的相關(guān)非功能性需求。
可重用：該服務候選者可以在不同的應用、流程中重用，從而減少重復的功能實現(xiàn)，降低開發(fā)和維護的成本。
基于企業(yè)應用開發(fā)的經(jīng)驗，我們還可以有其他一些方面的考慮。
在決定暴露特定的服務候選者為服務以后，服務規(guī)約還需要定義服務的消息、非功能性需求以及服務之間的依賴關(guān)系、組合關(guān)系。
3）服務實現(xiàn)：
根據(jù)對業(yè)務領(lǐng)域的理解和現(xiàn)有IT系統(tǒng)的分析，將服務的實現(xiàn)分配到相應的服務組件，并決定服務的實現(xiàn)方式。具體的實現(xiàn)方式，可以由已有系統(tǒng)暴露相關(guān)功能為服務，或者重新開發(fā)相關(guān)功能提供服務，也可以由合作伙伴來提供服務。無論采用哪種方式，都需要對于關(guān)鍵點進行技術(shù)可行性的分析。
回頁首定義和建模業(yè)務流程是提升業(yè)績的關(guān)鍵因素。業(yè)務流程是一種可變的交互模式，當某個組織在實現(xiàn)特定的業(yè)務目標時，在該組織的組件及其環(huán)境之間發(fā)生了這些交互。業(yè)務流程通常很復雜，因為在應對獨特而瞬息萬變的環(huán)境時，人們會不斷進行大量的更改。沒有正式的流程文檔和流程管理系統(tǒng)的話，這些流程復雜性就會使組織遇到不必要的障礙和瓶頸。一個良好構(gòu)建的業(yè)務流程模型可以幫助您定位和排除那些隱藏的低效、高成本以及帶來延遲的業(yè)務活動。
IBM? WebSphere? Business Modeler 是一個業(yè)務過程建模工具，該工具使您能夠建模、設計、分析與生成業(yè)務過程報告、集成新的和修訂的工作流，以及定義您的組織、資源和業(yè)務項。
本文的主題是服務建模，因此有必要闡述流程建模與服務建模的關(guān)系。
首先，進行著兩項活動的角色有明顯的不同，流程建模一般由業(yè)務人員或者業(yè)務咨詢專家進行，而服務建模由SOA架構(gòu)師在業(yè)務專員的支持下進行。
其次，兩項活動看待研究對象的角度不同。流程建模從組織結(jié)構(gòu)、業(yè)務流程及相關(guān)資源的角度來看待業(yè)務，流程建模關(guān)注業(yè)務活動之間的流動；服務建模則利用服務——業(yè)務與IT的契約來分析業(yè)務，服務建模關(guān)注業(yè)務活動之間的層次化和組合關(guān)系。
除了上面兩點不同以外，這兩項活動還是相互依賴，迭代進行的。粗粒度的流程模型是服務建模的重要輸入之一，幫助SOA架構(gòu)師了解業(yè)務需求。服務建模的過程發(fā)現(xiàn)并規(guī)約了服務，產(chǎn)生的結(jié)果——服務列表以及服務的主要業(yè)務屬性幫助業(yè)務人員準確的定義流程模型中的業(yè)務活動和業(yè)務項。但是服務建模中IT的成分如安全性、可靠性， 流程建模并不關(guān)注；
而流程建模中的模擬運行和優(yōu)化又和服務建模沒有直接的關(guān)系。
根據(jù)對當前業(yè)務流程的分析，我們可以進行業(yè)務流程建模。圖2展示了目標業(yè)務流程模型。
點擊查看大圖回頁首通過對現(xiàn)有業(yè)務環(huán)境的分析，新的業(yè)務流程必須將信貸員從繁復的人工操作中解放出來，通過自動化的方式降低信貸員的工作強度；同時通過業(yè)務規(guī)則的約束，控制過程中的操作風險和道德風險。圖3就是我們設計的目標業(yè)務環(huán)境，信貸員只是整個流程中的參與者之一，由自動化的汽車貸款審批業(yè)務流程來擔當承擔業(yè)務流程的樞紐。
IT環(huán)境的目的是解釋應用或流程在執(zhí)行的過程中會與哪些相關(guān)的業(yè)務系統(tǒng)交互（包括交互的方式），此外，還解釋相關(guān)業(yè)務人員與流程的交互方式。通過對IT環(huán)境的分析，我們可以了解已有系統(tǒng)的功能和相關(guān)技術(shù)指標，為后面的服務實現(xiàn)和架構(gòu)設計提供重要的信息。根據(jù)業(yè)務模型的轉(zhuǎn)型，相應的IT環(huán)境如圖4所示。汽車貸款審批業(yè)務流程能夠通過計算機技術(shù)自動與相關(guān)系統(tǒng)互聯(lián)互通，同時申請人、信貸員以及信貸經(jīng)理作為人工任務的執(zhí)行者參與到業(yè)務流程中。
回頁首服務建模按照服務發(fā)現(xiàn)、服務規(guī)約和服務實現(xiàn)這三個步驟進行，本文會涉及前面兩個步驟。服務實現(xiàn)與架構(gòu)設計是本系列文章的下一篇文章的主題。
自上而下方式
通過對業(yè)務流程的分解，我們可以得到服務的候選者。如圖5所示，每一個業(yè)務活動的單元都是服務的候選者。
點擊查看大圖中間對齊方式
通過與業(yè)務分析人員或業(yè)務咨詢顧問的協(xié)作，我們可以獲取服務建模的輸入——業(yè)務目標。在本示例中，業(yè)務指標為"降低成本"和"降低欺詐風險"，并且通過銷售成本、自服務比例和壞賬率這三個關(guān)鍵業(yè)務指標來度量業(yè)務目標的實施情況。部分服務候選者可以與關(guān)鍵業(yè)務指標聯(lián)系起來，例如：評估信用等級以及審批等服務候選者可以降低壞賬率。
自下而上方式
通過對現(xiàn)有IT環(huán)境的分析，我們可以掌握現(xiàn)有系統(tǒng)的基本信息。了解到核心系統(tǒng)可以提供獲取存、貸款記錄的功能。
根據(jù)與業(yè)務目標的聯(lián)系、與現(xiàn)有系統(tǒng)功能的映射，可以驗證我們自上而下分析方法的結(jié)果，或者發(fā)現(xiàn)自上而下分析方法的遺漏。結(jié)合業(yè)務領(lǐng)域的分析，我們可以得到服務候選者列表。
由于服務候選者比較多，可以采用領(lǐng)域分解的結(jié)果來將服務候選者進行分類。領(lǐng)域分解的工作通常由資深的業(yè)務專家來進行，在本示例中，基于示范的目的，我們認為目標業(yè)務流程所涉及的業(yè)務范圍包括客戶服務和風險控制，并將它們作為分類的依據(jù)，得到服務候選者目錄。
回頁首有了服務候選者目錄，最重要的步驟就是服務暴露的決策，根據(jù)業(yè)務對齊、可重用性、業(yè)務可組裝性等準則，我們決定暴露以下服務：
服務
業(yè)務對齊
可組裝
可重用
1 汽車貸款流程
Y
Y
1.1 確認購車價格
Y
Y
1.2 評估信用等級
Y
Y
Y
1.2.1 查詢存款記錄
Y
Y
Y
1.2.2 查詢貸款記錄
Y
Y
Y
1.2.3 計算信用等級
Y
Y
Y
1.4 審批
Y
Y
Y
1.6 擔保
Y
Y
Y
1.7 發(fā)放貸款
Y
Y
Y
在決定暴露的服務以后，就需要對這些服務進行消息的定義和非功能性需求，同時需要定義相關(guān)的業(yè)務事件、規(guī)則。
服務
輸入
輸出
業(yè)務事件
業(yè)務規(guī)則
非功能性需求
1 汽車貸款流程
1 汽車貸款流程
Application
applyResult
1.1 確認購車價格
carModel
carPrice
1.2 評估信用等級
Applicant
creditResult
信用等級報警
基于存款、貸款記錄的信用評估業(yè)務規(guī)則
1.2.1 查詢存款記錄
Applicant
depositHistory
性能（略）
1.2.2 查詢貸款記錄
Applicant
loanHistory
性能（略）
1.2.3 計算信用等級
applicant, depositHistory,loanHistory
creditResult
性能（略）
1.4 審批
Application
approveResult
審批結(jié)果通知
授權(quán)額度業(yè)務規(guī)則
1.6 擔保
Application
assureResult
可用性（略）
1.7 發(fā)放貸款
loanRequest
loanResult
貸款發(fā)放通知
事務（略）
實際項目中，服務規(guī)約會比較復雜，既包括具體的服務的操作、輸入消息、輸出消息，也包括相關(guān)聯(lián)的業(yè)務目標、業(yè)務規(guī)則、業(yè)務事件，此外，非功能性需求等方面也是需要在服務實現(xiàn)以前定義。上表僅僅列舉幾個方面做簡單的示意。
除了對單個的服務本身進行規(guī)約，服務規(guī)約還包括服務之間關(guān)系的描述，例如服務之間的依賴關(guān)系和包含關(guān)系。
在本示例中，汽車貸款流程由其他服務組裝而成，評估信用等級由查詢存款記錄、查詢貸款記錄和計算信用等級組裝而成；執(zhí)行審批以前，必須先完成評估信用等級，因此從業(yè)務的角度來看，審批服務依賴于評估信用等級
SOA快速指南 1 2 3，第 3 部分: 服務實現(xiàn)及架構(gòu)設計
文檔選項
將此頁作為電子郵件發(fā)送拓展 Tomcat 應用
下載 IBM 開源 J2EE 應用服務器 WAS CE 新版本 V1.1級別: 初級
姚 輝 (
yaohui@cn.ibm.com), IBM 中國SOA 設計中心高級工程師, IBM 中國軟件開發(fā)實驗室
金 戈, IBM軟件部企業(yè)集成解決方案架構(gòu)師, IBM 中國軟件開發(fā)實驗室 SOA設計中心
趙 勇 (
zhaoyong@cn.ibm.com), IBM 中國SOA 設計中心工程師, IBM 中國軟件開發(fā)實驗室
2007 年 1 月 31 日
《服務實現(xiàn)及架構(gòu)設計》是本系列文章的第三部分。在第二部分，我們完成了服務建模的前兩個步驟：服務發(fā)現(xiàn)和服務規(guī)約。本文的目的是進行服務建模的第三部分：服務實現(xiàn)，并完成架構(gòu)設計的工作。第二部分已經(jīng)整體的闡述了服務建模的概念和方法，本文就不再重復，因此首先介紹IBM的SOA的參考架構(gòu)，作為架構(gòu)設計的指導；然后結(jié)合場景的業(yè)務目標以及IT環(huán)境設計試點項目的架構(gòu)，并重點突出關(guān)鍵點的架構(gòu)決策。
以服務為中心的業(yè)務活動管理與監(jiān)控是最近出現(xiàn)的一種熱門的IT技術(shù)，它的目的在于幫助企業(yè)管理人員實時獲悉企業(yè)運營狀況，了解企業(yè)的戰(zhàn)略實施進展。
《SOA 快速指南 1 2 3》系列文章是筆者近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。該系列文章結(jié)合一個汽車貸款流程， 介紹了在 SOA 的環(huán)境下如何基于 IBM 的現(xiàn)有產(chǎn)品構(gòu)造業(yè)務活動管理解決方案，詳細闡述了每個實施步驟中使用的 IBM 的方法學、技術(shù)和產(chǎn)品。希望通過本文的介紹，能夠幫助讀者理清業(yè)務流程管理所包含的基本概念，并了解構(gòu)建解決方案所需要的基本步驟。
回頁首本系列是 IBM 中國軟件開發(fā)實驗室 SOA 設計中心近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。
項目概述 第 1 部分：SOA 采納步驟和價值分析 第 2 部分：服務建模 第 3 部分：服務實現(xiàn)及架構(gòu)設計 第 4 部分：快速實現(xiàn)服務集成模型 第 5 部分：逐步實現(xiàn)服務和持續(xù)集成 第 6 部分：以服務為中心的業(yè)務活動管理與監(jiān)控 SOA參考架構(gòu)是一種組織SOA的構(gòu)建元素--服務的方式，IBM希望通過這種參考架構(gòu)為企業(yè)架構(gòu)提供一種指導和參考，使得新的需求能夠更快的得到響應。參考架構(gòu)如圖1所示。
其中左側(cè)的綠色部分表示建模和組裝，中間的藍色部分表示部署，右邊的深藍色部門表示管理。中樞部分是企業(yè)服務總線（Enterprise Service Bus），在服務之間提供連通性支持。
參考架構(gòu)描述了企業(yè)范圍內(nèi)SOA方案所需要的關(guān)鍵能力。
工具是集成架構(gòu)的基本組件，SOA參考架構(gòu)則提供了開發(fā)服務和業(yè)務創(chuàng)新優(yōu)化服務。開發(fā)服務用于實現(xiàn)新開發(fā)的組件以及重用基礎架構(gòu)的能力；業(yè)務創(chuàng)新優(yōu)化服務用于從IT和業(yè)務兩個層面來監(jiān)控和管理運行情況。
企業(yè)服務總線是SOA參考架構(gòu)的核心。它為整個架構(gòu)范圍內(nèi)所有服務提供相互通訊的能力。其中傳輸服務、事件服務以及中介服務都是通過ESB來提供的。
交互服務將IT的功能和數(shù)據(jù)傳遞給最終用戶，并滿足用戶特定的使用習慣。
流程服務提供服務控制能力，將多個服務串起來實現(xiàn)一個業(yè)務流程。
信息服務通過聯(lián)合、復制和轉(zhuǎn)換來解決基于不同實現(xiàn)方式的不同數(shù)據(jù)源之間的數(shù)據(jù)共享難題。
SOA解決方案中的很多服務都是有已有應用提供的，訪問服務提供已有應用、打包應用程序與ESB之間的橋接能力，使得已有應用的功能以服務的形式對外暴露出來。
在業(yè)務流程需要與外部的合作伙伴、供應商交互的情況下，伙伴服務提供一組文檔、協(xié)議以及伙伴管理的能力。
應用服務為新的應用組件提供運行時服務。
作為所有能力的基礎，基礎服務用于優(yōu)化通過率、性能和可靠性。
IT服務管理服務包括對服務、應用和資源的管理和保護能力，如通過負載均衡來有效的分配系統(tǒng)計算資源。
SOA參考架構(gòu)是一個完整的企業(yè)架構(gòu)，可以覆蓋整個企業(yè)范圍內(nèi)集成的需求。參考架構(gòu)中的服務通過模塊化的方式進行集成，因此SOA的實現(xiàn)可以從一個小的項目來啟動，在新的項目實施的時候，新的功能能夠輕松的加到架構(gòu)中，通過漸進的方式在企業(yè)范圍內(nèi)擴大集成的范圍。
回頁首無論怎樣進行服務建模，服務最終都將由不同的服務組件來實現(xiàn)。因此服務實現(xiàn)是銜接服務建模和組件詳細設計的關(guān)鍵步驟。正如我們在第二部分提到過，服務實現(xiàn)首先將服務分配到相應的服務組件，然后逐個分析服務實現(xiàn)方式并進行技術(shù)可行性的驗證。
在服務發(fā)現(xiàn)的過程中，我們根據(jù)業(yè)務領(lǐng)域的分析結(jié)果將服務按照業(yè)務范圍進行分類。在服務實現(xiàn)的過程中，將業(yè)務范圍直接映射到服務組件，從而實現(xiàn)業(yè)務與IT的一致性。
服務實現(xiàn)的方式如圖2所示。"客戶服務"業(yè)務組件將實現(xiàn)貸款流程、查詢存貸款記錄、發(fā)放貸款等服務。"風險管理"業(yè)務組件將實現(xiàn)評估信用等級、審批、擔保等服務。
在我們的示例中，對于服務實現(xiàn)方式的選擇，可以分為以下幾類：
映射已有功能服務：如查詢存款記錄、查詢貸款記錄和擔保。其好處非常明顯，就是重用已有功能，保護企業(yè)的投資；避免重復功能的存在，降低維護成本。但是在選擇的過程中，需要考慮傳輸協(xié)議、消息格式的差異，是否可以通過引入中介來彌合服務調(diào)用者和實現(xiàn)者之間的差距。需要特別提出的是擔保服務，該服務由合作伙伴提供，通過中介將外部的服務進行映射（還需要重點考慮安全性相關(guān)的問題），在業(yè)務流程中就可以無縫的使用了。
新建流程服務：如汽車貸款流程、評估信用等級。前者是一個長流程（Long Running），由于有人工活動的參與，使得長流程的執(zhí)行不能在可預期的短時間（如：幾秒鐘）內(nèi)完成，需要相關(guān)人員在完成自己的任務以后，流程才能進入下一步，常常是幾天甚至幾個月才能完成整個流程；后者是一個短流程（Micro Flow）。在傳統(tǒng)的方案中，業(yè)務流程通常采用硬編碼的方式將多個功能組裝起來；與之相對，我們推薦采用工作流（如BPEL）的方式將服務組裝起來，從而達到靈活組裝、靈活應對變化的目的。
新建人工服務：如審批。人工服務是相對于自動化服務而言。自動化服務通常由IT系統(tǒng)來提供，不用人為的干預；人工服務則是由企業(yè)的員工、合作伙伴員工或者最終用戶來執(zhí)行，但是它同樣具備完整的服務描述。采用統(tǒng)一的服務描述來定義人工服務，可以將人工服務與自動化服務統(tǒng)一對待，除了可以在多個應用之間重用人工服務以外，還可以在服務實現(xiàn)從人工活動遷移到IT系統(tǒng)的過程中保持系統(tǒng)的柔性。
新建業(yè)務規(guī)則服務：如計算信用等級。由于這部分功能不穩(wěn)定，會隨著國民經(jīng)濟的發(fā)展、物價水平以及社會環(huán)境的變化而變化。將易于變化的這部分邏輯從穩(wěn)定的架構(gòu)中剝離出來，可以增強IT應對業(yè)務變化的能力。采用業(yè)務規(guī)則來實現(xiàn)相應的服務，可以相對靈活的進行修改來適應業(yè)務的變化，業(yè)務規(guī)則引擎已經(jīng)在大量的行業(yè)得到廣泛的應用。
新建功能服務：如確認購車價格。針對以前沒有的功能，或者以前采用人工方式完成的功能，現(xiàn)在可以引入自動化服務來提高業(yè)務流程的運行效率。在這里實現(xiàn)了新建功能服務以后，也能在其他的應用中逐步引入，從而達到在企業(yè)范圍內(nèi)重用的目的。
回頁首完成了服務實現(xiàn)的決策，也就對系統(tǒng)的架構(gòu)提出了明確的需求。不同方式實現(xiàn)的服務，需要系統(tǒng)架構(gòu)提供不同的能力，例如流程引擎、人工服務引擎以及業(yè)務規(guī)則引擎等。參考IBM的SOA參考架構(gòu)，我們設計一下系統(tǒng)架構(gòu)，將各種不同的服務實現(xiàn)的元素部署到系統(tǒng)架構(gòu)中，如圖4所示。
架構(gòu)關(guān)鍵點分析：
ESB實現(xiàn)機制：
選擇一：WebSphere Enterprise Service Bus 優(yōu)點：內(nèi)置的轉(zhuǎn)換、路由中介，并且可以通過客戶化中介擴展；采用標準的編程模型（SCA, SDO）。
選擇二：WebSphere Message Broker
優(yōu)點：靈活的轉(zhuǎn)換、路由能力；對負載均衡、高可用性上有很好的支持；支持基于MQ的可靠傳輸；支持多樣化的連接方式。
結(jié)論：此場景主要是業(yè)務部門級別應用，涉及的應用大多數(shù)都采用標準化技術(shù)，如：XML、Web Service等，也沒有特別的分布式應用的需求。因此采用選擇一，并利用WebSphere Adapter for CICS將非標準化的CICS應用連接到WebSphere Enterprise Service Bus。在隨著企業(yè)向SOA全面轉(zhuǎn)型的以后，建議引入Message Broker作為企業(yè)服務總線的骨干，當前方案中的WebSphere Enterprise Bus作為一個業(yè)務部門級別的節(jié)點接入骨干，形成整個企業(yè)的服務總線。
應用服務的集成：
選擇一：Web Service
優(yōu)點：支持分布式調(diào)用；跨平臺；支持開放性標準。
選擇二：EJB
優(yōu)點：支持分布式調(diào)用；支持不同的J2EE中間件平臺。
結(jié)論：企業(yè)服務總線是基于J2EE的實現(xiàn)，采用EJB的方式暴露應用服務，具備更好的性能。因此選擇方案二。即使將來希望采用Web Service方式，在WebSphere Application Server上也能夠很方便的將EJB（Session Bean）暴露為Web Service。
貸款系統(tǒng)的集成：
選擇一：通過Web Service訪問貸款系統(tǒng)。
優(yōu)點：支持開放性標準。
選擇二：直接通過JDBC訪問貸款系統(tǒng)數(shù)據(jù)庫。
優(yōu)點：支持分布式調(diào)用；性能較高。
結(jié)論：通過Web Service 訪問貸款系統(tǒng)，應用層訪問的方式，保證業(yè)務的完整性，隔離具體的業(yè)務實現(xiàn)。同時避免直接訪問數(shù)據(jù)庫帶來的安全策略等問題。因此采用選擇一。
最終，方案的架構(gòu)涉及以下IBM的產(chǎn)品。
IBM WebSphere Process Server提供的流程引擎、人工任務引擎和業(yè)務規(guī)則引擎為流程服務、人工服務以及基于業(yè)務規(guī)則的服務提供運行環(huán)境。
IBM WebSphere Enterprise Service Bus提供的連通性能力以及轉(zhuǎn)換、路由中介能力為企業(yè)服務總線提供運行環(huán)境。
IBM WebSphere Business Adapter 的連通性能力幫助我們將基于CICS的核心系統(tǒng)功能暴露為功能服務。
IBM WebSphere Application Server提供的J2EE容器為新開發(fā)的功能服務提供運行環(huán)境。
為了驗證架構(gòu)的可擴展性，可以引入一些變化的場景來分析。
保險公司的多樣化支持
由于各家保險公司的IT建設水平參差不齊，因此架構(gòu)需要能夠支持不同形式的接入。
對于能夠獨立提供服務網(wǎng)關(guān)的保險公司，采用Web Service或者socket的方式通過ESB接入。
對于不能提供服務網(wǎng)關(guān)的保險公司，可以實現(xiàn)一個人工服務，該人工服務遵循與合作伙伴服務同樣的服務規(guī)約?？梢宰尡ｋU公司的人員訪問該人工服務，或者由銀行職員通過傳真、電話確認信息，然后訪問人工服務。
上面這兩種形式的擔保服務，對于業(yè)務流程是透明的，ESB會根據(jù)用戶選擇的保險公司，將請求路由到保險公司的服務網(wǎng)關(guān)或者人工服務。在保險公司建立或者升級自己的服務網(wǎng)關(guān)的時候，系統(tǒng)只需要配置或者修改ESB就可以滿足業(yè)務的需求。
評估信用等級的變化
現(xiàn)階段，國內(nèi)還沒有統(tǒng)一的信用評估方案，隨著相應的業(yè)務環(huán)境變化導致對信用評估帶來的變化，是可以預計到的。
短期的變化可能是信用評估的規(guī)則發(fā)生變化。由于每年各地的平均收入水平變化，信用評估的規(guī)則可能相應的調(diào)整?；跇I(yè)務規(guī)則實現(xiàn)的計算信用等級服務，可以靈活的進行規(guī)則的修改。
長期的變化可能是引入統(tǒng)一的信用評估平臺。由國家或者第三方機構(gòu)提供一個全國范圍內(nèi)統(tǒng)一的信用評估平臺。只需要將現(xiàn)有的評估信用等級業(yè)務子流程替換為外部的統(tǒng)一信用評估平臺提供的合作伙伴服務，通過ESB來彌合傳輸協(xié)議和消息格式的不同，整個業(yè)務流程依然保持不變。
通過對上述變化場景的簡單分析，我們驗證了架構(gòu)的可擴展性。當然這種可擴展性只能是在一定的程度上滿足業(yè)務的變化，也只有通過對業(yè)務變化的前瞻性分析，對系統(tǒng)架構(gòu)進行修正，才能更好的保證架構(gòu)的可擴展性。這整個過程是一個迭代進行的過程
SOA快速指南 1 2 3，第 4 部分: 快速實現(xiàn)服務集成模型
文檔選項
將此頁作為電子郵件發(fā)送拓展 Tomcat 應用
下載 IBM 開源 J2EE 應用服務器 WAS CE 新版本 V1.1級別: 初級
金 戈, IBM軟件部企業(yè)集成解決方案架構(gòu)師, IBM 中國軟件開發(fā)實驗室 SOA設計中心
姚 輝 (
yaohui@cn.ibm.com), IBM 中國SOA 設計中心高級工程師, IBM 中國軟件開發(fā)實驗室
趙 勇 (
zhaoyong@cn.ibm.com), IBM 中國SOA 設計中心工程師, IBM 中國軟件開發(fā)實驗室
譚 佳, IBM 中國SOA 設計中心工程師, IBM 中國軟件開發(fā)實驗室
2007 年 2 月 01 日
《快速實現(xiàn)服務集成模型》是本系列文章的第四部分。本文承接前面系列文章的分析和建模的結(jié)果，主要進行SOA實施的層面上的探討，首先介紹SOA項目實施的準備工作，然后介紹在實施過程中怎樣利用分析建模的結(jié)果定義服務并將服務分配到模塊中，根據(jù)模塊的分析得到服務的集成模型，從中總結(jié)出一些有價值的指導原則和實施細則，希望對SOA項目方面的開發(fā)測試人員有所幫助。本文假定讀者能夠使用WID進行基本的SCA開發(fā)和相關(guān)的操作。
以服務為中心的業(yè)務活動管理與監(jiān)控是最近出現(xiàn)的一種熱門的IT技術(shù)，它的目的在于幫助企業(yè)管理人員實時獲悉企業(yè)運營狀況，了解企業(yè)的戰(zhàn)略實施進展。
《SOA 快速指南 1 2 3》系列文章是筆者近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。該系列文章結(jié)合一個汽車貸款流程， 介紹了在 SOA 的環(huán)境下如何基于 IBM 的現(xiàn)有產(chǎn)品構(gòu)造業(yè)務活動管理解決方案，詳細闡述了每個實施步驟中使用的 IBM 的方法學、技術(shù)和產(chǎn)品。希望通過本文的介紹，能夠幫助讀者理清業(yè)務流程管理所包含的基本概念，并了解構(gòu)建解決方案所需要的基本步驟。
回頁首本系列是 IBM 中國軟件開發(fā)實驗室 SOA 設計中心近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。
項目概述 第 1 部分：SOA 采納步驟和價值分析 第 2 部分：服務建模 第 3 部分：服務實現(xiàn)及架構(gòu)設計 第 4 部分：快速實現(xiàn)服務集成模型 第 5 部分：逐步實現(xiàn)服務和持續(xù)集成 第 6 部分：以服務為中心的業(yè)務活動管理與監(jiān)控 在本系列的前面3篇文章中，我們已經(jīng)了解到，通過業(yè)務價值分析和服務建模，經(jīng)過服務架構(gòu)的分析和設計，我們能夠確定需要實現(xiàn)的服務接口和消息規(guī)約，以及服務之間的調(diào)用關(guān)系?，F(xiàn)在我們的任務就是如何實現(xiàn)和構(gòu)建這樣一個以服務為中心的應用系統(tǒng)。
實現(xiàn)服務集成模型是本文的主要內(nèi)容，我們將討論如何獨立實現(xiàn)相應的集成模塊，由架構(gòu)組在整體層面上把握路線，建立集成模型。本系列文章的第五篇將進一步討論如何逐步實現(xiàn)服務和持續(xù)集成服務。
首先簡單分析一下我們的目標，我們的工作此時能得到的輸入就是本系列文章的前3篇文章中的輸出（服務規(guī)約、服務實現(xiàn)決策以及系統(tǒng)架構(gòu)），我們的目標就是獲得相應的輸出：一個以服務為中心的應用系統(tǒng)。
我們將會采取如下的基本步驟來實現(xiàn)我們的目標：
1 項目準備:準備相關(guān)的軟件：硬件環(huán)境和組件開發(fā)團隊。
2 在開發(fā)環(huán)境中定義服務：使用WID工具定義服務的基本元素。
3 決定服務之間的物理關(guān)系和服務集成模型：主要是得到服務集成的順序和路徑。
4 逐步實現(xiàn)服務：使用模擬服務的方法快速實現(xiàn)服務和快速測試。
5 持續(xù)集成服務：根據(jù)服務模型的順序持續(xù)的集成服務，構(gòu)建完整的應用系統(tǒng)。
在開發(fā)過程中會包括迭代的開發(fā)和持續(xù)測試。
首先我們回顧前文的工作成果，我們確認系統(tǒng)將要提供以下服務：
服務編號 服務名稱
S0 汽車貸款流程服務
S1 確認購車價格
S2 查詢存款記錄
S3 查詢貸款記錄
S4 發(fā)放貸款
S5 評估信用等級
S6 計算信用等級
S7 審批
S8 擔保
因此我們將開始實現(xiàn)層面的探討，我們將討論服務組件的劃分和實現(xiàn)過程，服務的組成和聚合關(guān)系。模擬服務的實現(xiàn)和測試，UI和后臺系統(tǒng)的準備。
在本文中，我們主要根據(jù)既定的系統(tǒng)架構(gòu)，實現(xiàn)每個服務的基本框架和SCA模塊的基本內(nèi)容，用于驗證概念，與客戶交流，安排開發(fā)計劃和進度。在實際的項目中，最主要的通過本文的工作內(nèi)容，得到項目結(jié)構(gòu)的全景，通過評審、項目組會議和演示等手段，使得全組對整個系統(tǒng)的實現(xiàn)架構(gòu)和組成，每個組員的工作，系統(tǒng)的開發(fā)和部署單元等都要有全面的了解。
目前供選擇的支持SCA編程模型和面向服務的體系架構(gòu)的開發(fā)的工具還不是很多。IBM公司于2005年10月發(fā)布的WID6.0是目前比較好的能夠支持SCA的開發(fā)工具。實際上IBM公司提供了整條產(chǎn)品線能夠?qū)崿F(xiàn)基于SOA的應用從建模，開發(fā)，部署，監(jiān)控等一系列階段的支持，請參見圖1。
為了更好的說明SOA的生命周期和IBM產(chǎn)品的對應關(guān)系，這里我們提供一個簡單的產(chǎn)品表格（以最新的WebSphere 6系列版本為例），參見表1：
本系列文章前三篇探討的內(nèi)容都是由SOA項目小組的早期成員（架構(gòu)組成員和項目負責人，客戶代表，業(yè)務分析師，現(xiàn)存系統(tǒng)架構(gòu)師等）一同完成的，從現(xiàn)在開始，項目小組的重心向開發(fā)的方向轉(zhuǎn)變，工作開始產(chǎn)生新一輪的迭代，新的成員加入，原有成員或離開從事新的項目，或堅守崗位，成為項目開發(fā)的主要骨干。
我們認為，本系列文章的前三篇所探討的話題，從時間的角度來講，主要發(fā)生在項目的早期，視項目大小，其所用時間可能從10天到數(shù)月不等，參與人員可能從4、5人到十數(shù)人不等。除了客戶人員外，項目組在早期可能只包括業(yè)務分析人員，SOA架構(gòu)師和IT架構(gòu)師。因此和傳統(tǒng)的項目類似，在項目的早期，團隊構(gòu)成以分析人員，設計人員和架構(gòu)師為主。
當SOA項目進行到實現(xiàn)階段，架構(gòu)設計已經(jīng)比較明確，此時開發(fā)人員和測試人員就要加入，原小組成員需要一天到數(shù)天的時間進行知識共享，使得新加入的人員對項目背景，所實現(xiàn)系統(tǒng)的功能有明確的認識。然后根據(jù)項目情況和個人情況，組建開發(fā)小組。此時我們建議架構(gòu)師轉(zhuǎn)變角色為開發(fā)小組的TeamLeader，保證開發(fā)和項目設計的持續(xù)性。同時我們強調(diào)小組之間的交流和信息共享，以保證項目進度的透明性，使得開發(fā)人員對SOA的認識保持一致。
在我們的項目實例中，我們項目小組的組成如表2所示。
通常項目團隊的分組可能面臨兩種選擇：
一種是水平分組：按照應用的水平層次進行分組，如UI相關(guān)，流程相關(guān)，中介相關(guān)，服務實現(xiàn)后臺系統(tǒng)等。
一種是垂直分組：按業(yè)務功能劃分，以業(yè)務流程為中心，功能相關(guān)的UI，流程，模塊，后臺系統(tǒng)為一組。
在以服務為中心的SOA項目中，我們推薦將項目以服務為中心分為2個大的Work Stream：
1 服務實現(xiàn)：
包括新的服務和對現(xiàn)有服務的包裝，這樣實現(xiàn)的服務將作為基本的服務組件分布在服務模塊中，等待互相調(diào)用和被流程等方式進行編排。
2 服務集成
包括從UI到業(yè)務流程，或者SCA之間的裝配。
這樣考慮主要是因為服務的實現(xiàn)是可以獨立的完成（我們強調(diào)SOA中的Service是粗粒度的業(yè)務服務），而服務的集成主要體現(xiàn)在流程以及服務模塊之間的裝配，這樣的劃分對于我們將來的持續(xù)集成有著非常重要的意義。
每個Work Stream之中，可能需要按業(yè)務或者技術(shù)側(cè)重分成若干小組，同時Work Stream之中，根據(jù)人員技能的不同，每個開發(fā)人員的角色會有側(cè)重。各Work Stream之間需要保持相應的交流，對于一些重要的技術(shù)人員或者領(lǐng)域?qū)＜遥梢栽赪ork Stream之間實現(xiàn)共享，例如在我們的例子中，有一名BPEL專家主要承擔流程編排，并同時為各小組提供相關(guān)咨詢。
在表3中我們列出SOA項目通常情況下開發(fā)人員角色（基于J2EE的SOA項目，以IBM產(chǎn)品為例），供讀者參考。
回頁首在相關(guān)的準備工作完成以后，我們將逐步開始接觸服務的實現(xiàn)，首先我們會定義服務的基本元素，包括服務的消息格式和服務接口的定義，以及服務的分組。
在前面的系列文章中，我們經(jīng)過分析已經(jīng)能夠給出服務之間的規(guī)約，現(xiàn)在是時候要開始在開發(fā)環(huán)境中實現(xiàn)這些定義了。
在項目實施中，我們通?；谝恍┍砀裥问降囊?guī)約進行開發(fā)，這些表格的定義基本上是以業(yè)務人員為主，是側(cè)重于真實的業(yè)務數(shù)據(jù)的定義，可能會和以前的業(yè)務系統(tǒng)的實現(xiàn)有差別，但是請不要懷疑，畢竟，SOA系統(tǒng)并不是以前的業(yè)務系統(tǒng)的簡單重構(gòu)，而是需要我們從業(yè)務（Business）服務的角度，規(guī)劃和設計企業(yè)的IT架構(gòu)。
這里給出一些示例：表4和表5。
2.1.1 業(yè)務對象
業(yè)務對象（Business Object）簡稱BO，在某種程度上你可以認為BO就是SDO一種特例，關(guān)于BO的信息，請參考參考資料《深入了解WPS中的業(yè)務對象Business Object》。
示例中的一個業(yè)務對象在WID中的定義如圖2下所示。
在使用WID實施SOA解決方案時，我們推薦將所有的公用的業(yè)務對象和服務接口實現(xiàn)于一個Library項目中，供所有需要的模塊引用。對于模塊內(nèi)部的私有業(yè)務對象和接口，則由模塊自己管理。
BO之間的關(guān)系可能有如下幾種，我們這里簡單討論處理這些關(guān)系的時候需要注意的要點：
1 引用
在WID中，雖然在業(yè)務集成視圖提供了可視化的編輯BO的方式，但你仍然會不時的打開BO對應的XSD定義文件，進行一些手工的操作。
例如，如果你在業(yè)務對象A中引用業(yè)務對象B，后來又刪除了該引用，你仍然需要手工刪除業(yè)務對象A對應的XSD的import。在SOA迭代的開發(fā)過程中，BO之間的關(guān)系會經(jīng)常的發(fā)生變化，開發(fā)人員必須保證開發(fā)工具的視圖和定義BO的XSD之間的一致。
2 繼承
請注意WID支持BO之間的繼承關(guān)系，其實現(xiàn)是通過XSD的extension來實現(xiàn)的，WSDL中的消息也是通過XSD來定義的，因此也支持繼承。在一個復雜的系統(tǒng)中，業(yè)務對象不可能都是一個獨立的存在，因此在定義BO的時候，你可能需要考慮繼承。并且，我們更關(guān)注模塊之間共享的BO，這些BO作為消息線索，將串聯(lián)起主要的業(yè)務流程，具有非常明顯的業(yè)務含義。
例如：我們可能考慮一個抽象的汽車業(yè)務對象，派生出客車，貨車等不同的業(yè)務對象，其對應的貸款規(guī)則可能會有變化，通過在流程中組件之間使用抽象的汽車類型，而某些組件內(nèi)部使用具體類型，我們可以靈活處理，并且類型發(fā)生變化時并不影響主要的業(yè)務流程。
3 映射
在更為復雜的情況下，WID 支持BO之間的Mapping和Transformer ，從而支持接口之間的Mapping，當然，你也可以使用Mediation模塊里面的XSLTTransform來實現(xiàn)消息的轉(zhuǎn)換。
例如保險系統(tǒng)的查詢接口，需要使用保險人的姓名，地區(qū)，和身份證證件號作為輸入，我們可以定義一個保險人查詢條件業(yè)務對象，使用貸款申請人到保險人的映射來自動完成轉(zhuǎn)換。
實際項目中，在使用WID工具定義業(yè)務對象同時，應當盡量將所有的變更記錄在案，并和設計文檔保持同步。你可以采用自動化的方法，將注釋保留在代碼中，使用工具生成文檔，這樣自動保證設計文檔和實現(xiàn)的同步。對于定義BO的注釋，我們推薦在屬性頁的注釋面板中添加適當?shù)淖⑨?，對于在系統(tǒng)間流動的BO，會被不同的開發(fā)人員引用，適當?shù)淖⑨尶梢源罅繙p少你的口舌。對于業(yè)務對象中屬性，需要考慮到是不是數(shù)組，以及是不是必需等問題，我們應該合理的使用這些定義，可以在早期測試的時候發(fā)現(xiàn)很多問題。在項目實現(xiàn)過程中，一個微小屬性的變化可能帶來一系列的問題，因為BO中的屬性是強類型的，并且通常會和WSDL接口和Java代碼產(chǎn)生很緊密的關(guān)聯(lián)，所以我們應當盡量的事先考慮周全。
2.1.2 服務接口
服務接口的定義在目前的WID中實際上支持兩種定義方式，WSDL和Java接口，但一般情況下，模塊之間的接口我們使用WSDL，因為WSDL擴展性和通用性都比較好。而模塊內(nèi)部，我們可能使用WSDL，也可能使用Java。如果你的一個Java服務組件不得不引用一個無狀態(tài)的SessionBean，你就不得不使用該SessioBean的接口來定義這個組件的接口。在使用WSDL接口定義的時候，盡量不要過早的在Process中綁定接口，因為一旦接口的參數(shù)的數(shù)據(jù)組織格式發(fā)生變化，Process的調(diào)用接口和分配變量部分會發(fā)生很大的變化。
如果你希望暴露的接口和你的組件接口不盡相同，你可以使用接口映射，接口之間的映射就需要用到業(yè)務對象的映射，而且也可以使用Mediation來做，實際上完成的功能基本上是一樣的。
在WID中定義的一個接口示例如圖3所示。
2.1.3 業(yè)務對象的映射
SOA采用分層的方法來隔離關(guān)注，利用分層可以提高開發(fā)和運行時的靈活性，但是層次之間以及層次的對象之間，經(jīng)常會需要互相映射，這是SOA項目實踐中非常常見的一個問題，在定義業(yè)務對象的時候，同樣需要考慮這樣的問題。
SDO的目的是統(tǒng)一數(shù)據(jù)的格式，然而在遺留系統(tǒng)中難免會有不同的數(shù)據(jù)源（數(shù)據(jù)庫， LDAP等）雖然SDO提供了訪問不同數(shù)據(jù)源的方式，但是你仍然不能避免SDO和Java對象之間的轉(zhuǎn)化。通常情況下，如果被集成的后臺系統(tǒng)是EJB，我們可以使用Web Service來包裝EJB，然后在SCA模塊中導入該Web Service 可以實現(xiàn)自動調(diào)用，在導入WSDL的同時，WSDL中定義的消息會自動轉(zhuǎn)化為BO的XML Schema定義。此時我們就可以通過使用Mapping或者XSLT Transformer來實現(xiàn)BO之間的映射，從而隱式的實現(xiàn)BO到Java的映射。如果你的Java對象的定義不含弱類型對象，或者不含特定的業(yè)務邏輯，只是簡單的映射，你可以使用JAXB或者XMLBeans輕松的通過配置實現(xiàn)Java對象到XML的映射，通過XML快速生成SDO。
有2種情況你將不得不親自面對Java對象和BO之間的互相映射（轉(zhuǎn)化）：
1 在特定情況下，因為效率，事務等的需要，不得不在SCA中直接集成EJB，并且你無法使用WSDL輕易的實現(xiàn)映射，尤其是當數(shù)據(jù)種隱含若類型對象或者隱含特定的業(yè)務邏輯。對于常見的J2EE系統(tǒng)，我們會遇見諸如Vector，List，HashMap這樣的參數(shù)類型，對于這些弱類型的Java對象，雖然WSDL提供了Any 類型，但是一般不太容易交互，所以對于這種情況，你不得不需要使用良定義的Java對象來包裝參數(shù)，或者將包裝后的方法暴露成Web Service，或者直接手工實現(xiàn)Java和SDO的轉(zhuǎn)化。
2 對于UI的重用性，有時候也要涉及BO和Java對象之間的轉(zhuǎn)化。
對于這些情況，我們推薦你使用自己編寫的TransformerFactory來生成每個對象和SDO的轉(zhuǎn)化類。我們實現(xiàn)的TransformerFactory實際上是一個Java代碼生成器。
值得注意的是，在生成Transformer的同時，我們可以捎帶生成測試數(shù)據(jù)生成器，使用該生成器，你可以在項目的早期生成滿足需要的測試數(shù)據(jù)，以方便單元測試，集成測試，實現(xiàn)自動化的測試。
在我們的例子中，銀行內(nèi)部的房貸系統(tǒng)就是這樣一個后臺系統(tǒng)，它暴露出EJB的接口，并且設計上采用Command模式，其中包含大量的弱類型參數(shù)以保證擴展性，因此我們無法使用WSDL映射來實現(xiàn)自動調(diào)用，不得不采用Java代碼手工轉(zhuǎn)化。我們在生成轉(zhuǎn)化類的同時也生成測試數(shù)據(jù)生成類，這也是我們使用TransformerFactory捎帶帶來的一個優(yōu)點。
回頁首根據(jù)本系列前面的分析，我們已經(jīng)定義了將實現(xiàn)的服務和接口，但是如何下手開始做服務的編碼呢？在SOA的角度，應用程序無非是服務的裝配形式，但是，如何組織這些服務呢？SCA 的組件天然的有2種組裝模式，一種是模塊組裝，一種是系統(tǒng)組裝，所謂模塊組裝，就是SCA定義了一種SCA的模塊，模塊內(nèi)部會有一個或多個SCA的服務組件通過流程，調(diào)用，等方式組成一組功能的集合，該功能的集合（模塊）具有顯著的業(yè)務層面上的價值和意義，所謂系統(tǒng)組裝主要就是BPEL，SCA調(diào)用等方式，將不同的模塊組織，以完成業(yè)務流程和業(yè)務功能。
WID 為我們提供了很好的SCA開發(fā)環(huán)境，在WID的環(huán)境中進行SOA的開發(fā)一般涉及到 SCA模塊，Mediation模塊，Library等模塊。而一個SCA或Mediation模塊就會對應多個WID的Project（一個基本的項目，一個Ear項目，一個EJB項目，還有EJB客戶端和Web項目等），如果每個服務對應一個模塊，就會產(chǎn)生太多的部署單元，系統(tǒng)給人的感覺整體上會雜亂無章，因此我們推薦使用以下地方做法來給服務歸類，使用不同的模塊來組織這些服務。
1首先將所有的服務歸為大類，對于每一類中的多個服務，按照流程相關(guān)，中介相關(guān)，現(xiàn)有系統(tǒng)相關(guān)，新建服務相關(guān)，其他相關(guān)等模式進行組織。
2 在這個基礎上在按功能和業(yè)務邏輯上的相關(guān)性進行組合，還要考慮部署，開發(fā)等的問題，最終均衡各方面的決策，實現(xiàn)一個比較中肯的分類，要以有利于開發(fā)和部署為原則，還要和集成的步驟和層次相吻合。
對于每個服務 ，我們可能會使用一些簡單的表格來分析，參見表6。
對于我們的實際例子，我們最終建立如下的幾個SCA模塊：
1 購車貸款審批流程模塊
這個模塊完全是一個流程模塊，它實現(xiàn)貸款的流程，調(diào)用其他的SCA服務或者Java服務組件來完成功能。其中包括一個子流程：信用評估流程模塊。
2 信用評估流程模塊
將信用評估子流程獨立出來是希望將來靈活的變化或者根據(jù)地區(qū)進行定制的時候使得影響面盡量的小。
3 中介模塊
我們抽象出一個中介模塊，暴露出后臺系統(tǒng)的服務接口，對于不同的客戶請求，可能需要路由到不同的后臺系統(tǒng)進行不同形式的業(yè)務操作，該模塊實現(xiàn)了一個中介組件。因為后臺系統(tǒng)基于CICS，我們使用MQ CICS Adapter實現(xiàn)調(diào)用的服務組件。
4 貸款系統(tǒng)包裝
對于無法直接集成的現(xiàn)有系統(tǒng)，需要單獨實現(xiàn)SCA模塊，這樣便于測試，模擬，也便于集成時隔離和發(fā)現(xiàn)問題，同樣有利于后臺系統(tǒng)地方變更和遷移。視功能情況的分配可能需要分配多個這樣的模塊。因此我們有一個對貸款系統(tǒng)的包裝模塊和一個外部保險擔保系統(tǒng)的包裝模塊。
5 保險擔保系統(tǒng)包裝
保險擔保系統(tǒng)包裝模塊主要實現(xiàn)了對保險擔保系統(tǒng)的包裝，提供了擔保信息查詢的服務。
6 汽車價格查詢模塊
汽車價格查詢模塊是一個新建服務模塊。新建服務的模塊主要是針對我們服務建模的時候新發(fā)現(xiàn)的服務而言的。對于新的汽車報價查詢模塊，銀行希望自己實現(xiàn)一個簡單的數(shù)據(jù)庫查詢系統(tǒng)，從某服務提供商處獲取數(shù)據(jù)，每周更新一次。
通過對模塊組成和服務調(diào)用的分析，我們可以清晰了解到從服務的角度看，系統(tǒng)將要實現(xiàn)的物理結(jié)構(gòu)。此時，關(guān)于各個模塊的接口，實現(xiàn)方式，邏輯功能，以及一些規(guī)約等都要歸檔，作為下一步開發(fā)的基礎。
根據(jù)以上的分析，我們會得出表7，將服務映射到SCA模塊中實現(xiàn)。
該結(jié)果將作為進一步分析的依據(jù)，成為服務集成模型的重要元素。
回頁首SCA作為SOA的編程模型，可以給我們帶來顯著的價值，易于集成，實現(xiàn)高靈活性和高開發(fā)效率。到目前為止，我們完成了服務和消息的定義，我們將獨立的實現(xiàn)服務模塊，UI，和后臺系統(tǒng)，所有的這一切都是為了集成，集成為我們最終的應用程序。我們的目標就是要以服務為中心，持續(xù)集成。
首先讓我們關(guān)注服務集成的模型，我們所謂的服務集成的模型主要只服務之間關(guān)系建立的計劃安排和實現(xiàn)步驟。
為什么需要一個服務集成模型？主要有以下兩點的考慮：
1 降低風險
2 最大限度利用資源
使用自動化的測試和基于模擬服務的持續(xù)集成將是我們實現(xiàn)目標的主要手段。
請注意，我們設計的示例場景經(jīng)過簡化，結(jié)構(gòu)已經(jīng)比較簡單。我們可以假想將示例放在一個更大范圍的應用中來看，該應用集成了網(wǎng)上購車，汽車貸款申請，新車手續(xù)辦理和車險辦理的一條龍服務，極大的方便了用戶。在這樣一種環(huán)境下構(gòu)建服務的集成模型，持續(xù)的進行服務集成將變得更為重要?？刂坪媚K之間的關(guān)聯(lián)，制定合理的集成模型可以有效的控制項目的風險。
一個SCA模塊將一些相關(guān)的服務按一定的關(guān)系進行組裝，這些關(guān)系我們可以分為：順序，循環(huán)，調(diào)用，路由等。模塊內(nèi)部的集成也就是模塊內(nèi)的服務組件之間的集成，從Export直到Import之間的路線的完成，實際上也就是服務調(diào)用和服務之間的關(guān)系的確立，參見圖4。在模塊內(nèi)部的服務進行實現(xiàn)的同時，或者還沒有進行實現(xiàn)的時候，就應該開始模塊內(nèi)部的集成。盡早集成，可以在沒有功能的情況下用模擬服務實現(xiàn)集成，以獲得一個模塊內(nèi)部運行路線的全局觀念。在開發(fā)的過程中不斷的迭代，來實現(xiàn)真實的服務替代模擬服務，對于項目的正常推進是非常重要的。
我們建議如果模塊不是足夠復雜，模塊的實現(xiàn)可以作為一個原子的活動，不用區(qū)分服務和模塊內(nèi)部的集成，但是如果模塊的規(guī)模比較大，對于模塊內(nèi)部的服務實現(xiàn)上還是要有一些考慮。
一般來說我們總是會優(yōu)先實現(xiàn)簡單的服務，對于功能復雜的服務，我們會使用門面或者代理的設計模式，將復雜的業(yè)務邏輯分解為獨立的實現(xiàn)，在簡單服務中包裝或者代理這些服務，這樣也有利于隨時修改調(diào)用代碼或者硬編碼實現(xiàn)模擬服務以供測試使用。
請注意在模塊內(nèi)部的集成時，你不一定需要為模塊暴露出接口，也不一定要對任何import進行綁定，因為隨著全局觀念的清晰化和你對項目認識的深入，很多預先定義的接口形式和綁定方式會發(fā)生變化。雖然WID的開發(fā)工具使得我們對于項目開發(fā)過程中的變化的可以快速響應，無需付出巨大代價，但是我們?nèi)匀恍枰M可能的將變更帶來的風險降到最低。
集成（或組裝）是SCA中非常重要的概念，你可以想象如果我們的應用程序是一輛汽車，我們的服務就是汽車零件，服務模塊這是汽車中的大型部件，最終，我們需要通過組裝來實現(xiàn)我們的SOA應用，并且由于組件之間的良定義的接口，我們的組件都是可以替換的。在 SCA的編程模型下，模塊之間的集成主要依賴于SCA調(diào)用和BPEL。參見圖5。
在模塊內(nèi)的集成進行的同時，項目領(lǐng)導小組則開始進行服務模塊之間的集成模型的定義。在我們的實例中，我們增加了2組UI模塊，供2種場合的使用（個人上網(wǎng)，業(yè)務大廳辦理）。
在WID提供的SOA開發(fā)模式下，我們認為一個SOA應用會主要由以下一些部分構(gòu)成：UI、業(yè)務流程模塊、SCA模塊和后臺系統(tǒng)。
不同的部分會含有多個模塊，模塊之間的集成，在我們的例子中，我們可以分為兩個層次 ：
1 垂直層次：
UI->服務組合->服務實現(xiàn)->后臺系統(tǒng)：主要可能分為 與UI的集成，與流程的集成，與現(xiàn)有系統(tǒng)的集成。由于工作量的不均衡，其完成的時間和集成發(fā)生的時間點不可能一致。
2 水平層次：
同一類型的模塊（如果我們把相關(guān)的UI也按模塊的相關(guān)性分組），之間的進度也不是一致的。
因此，我們會有如下的集成關(guān)系分析表：
其中：UI1指大廳用戶界面，UI2指網(wǎng)絡用戶； L1，核心系統(tǒng)；L2，貸款系統(tǒng)；L3，保險系統(tǒng)。
對改表格的橫向和縱向的分析將表明我們的模塊之間的關(guān)系和集成度。
為了保證團隊工作量的一致，同時為了降低最終集成的風險，最優(yōu)化資源，達到最大的效率，都需要我們持續(xù)的集成。我們?nèi)匀粡囊粋€以流程為中心的開發(fā)小組為例，首先要考慮模塊之間的交叉依賴性，被調(diào)用的越多的模塊要盡早集成，然后考慮越先完成的模塊要越先集成。對于有的模塊可能會被多個模塊調(diào)用，因此有重用交叉的地方優(yōu)先實現(xiàn)。對于決定系統(tǒng)架構(gòu)的關(guān)鍵路徑上的組件，同樣考慮要優(yōu)先實現(xiàn)，優(yōu)先集成。
經(jīng)過各種方面的考慮，我們最終會得出組件的實現(xiàn)順序和集成順序，均衡的安排工作量。對于集成的服務模塊，首先我們就有實現(xiàn)模塊所需時間的考慮，對于模塊之間的每個集成都要分析其實現(xiàn)方式，工作量，技術(shù)風險等，最終會為每個業(yè)務流程得出一個按時間排列的實現(xiàn)和集成任務列表。
根據(jù)以上的工作和分析，開發(fā)組進本定義了系統(tǒng)的體系結(jié)構(gòu)和一些基礎的服務元素，并定義了完整的集成模型，和均衡的計劃。下面就需要開發(fā)人員根據(jù)時間安排，按計劃的實現(xiàn)服務，持續(xù)的集成服務。至于如何實現(xiàn)持續(xù)的集成，我們需要單獨實現(xiàn)各服務組件和全面的單元測試，在下一篇文章中，我們將詳細探討。
SOA 快速指南 1 2 3，第 5 部分: 逐步實現(xiàn)服務和持續(xù)集成
文檔選項
將此頁作為電子郵件發(fā)送拓展 Tomcat 應用
下載 IBM 開源 J2EE 應用服務器 WAS CE 新版本 V1.1級別: 初級
金 戈, IBM軟件部企業(yè)集成解決方案架構(gòu)師, IBM 中國軟件開發(fā)實驗室 SOA設計中心
姚 輝 (
yaohui@cn.ibm.com), IBM 中國SOA 設計中心高級工程師, IBM 中國軟件開發(fā)實驗室
趙 勇 (
zhaoyong@cn.ibm.com), IBM 中國SOA 設計中心工程師, IBM 中國軟件開發(fā)實驗室
譚 佳, IBM 中國SOA 設計中心工程師, IBM 中國軟件開發(fā)實驗室
2007 年 2 月 06 日
《逐步實現(xiàn)服務和持續(xù)集成》是本系列文章的第 5 部分。本文承接上篇文章定義的服務模塊和服務集成模型，首先簡要介紹了服務模塊的逐步實現(xiàn)，對各種服務模塊進行分析；然后闡述了如何根據(jù)模擬服務進行迭代的開發(fā)和集成，其中涉及到服務組件的測試，模擬測試客戶端，以及模擬服務的實現(xiàn)；最后強調(diào)了SOA實施中的持續(xù)集成和持續(xù)測試。我們希望通過本文使讀者對 SOA 項目的開發(fā)和測試形成基礎的認識，對于一些重要的方法和特殊的手段能夠有所了解。
以服務為中心的業(yè)務活動管理與監(jiān)控是最近出現(xiàn)的一種熱門的IT技術(shù)，它的目的在于幫助企業(yè)管理人員實時獲悉企業(yè)運營狀況，了解企業(yè)的戰(zhàn)略實施進展。
《SOA 快速指南 1 2 3》系列文章是筆者近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。該系列文章結(jié)合一個汽車貸款流程， 介紹了在 SOA 的環(huán)境下如何基于 IBM 的現(xiàn)有產(chǎn)品構(gòu)造業(yè)務活動管理解決方案，詳細闡述了每個實施步驟中使用的 IBM 的方法學、技術(shù)和產(chǎn)品。希望通過本文的介紹，能夠幫助讀者理清業(yè)務流程管理所包含的基本概念，并了解構(gòu)建解決方案所需要的基本步驟。
回頁首本系列是 IBM 中國軟件開發(fā)實驗室 SOA 設計中心近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。
項目概述 第 1 部分：SOA 采納步驟和價值分析 第 2 部分：服務建模 第 3 部分：服務實現(xiàn)及架構(gòu)設計 第 4 部分：快速實現(xiàn)服務集成模型 第 5 部分：逐步實現(xiàn)服務和持續(xù)集成 第 6 部分：以服務為中心的業(yè)務活動管理與監(jiān)控 在本系列文章的第4篇中，我們通過分析給出了模塊和服務的劃分，模塊的集成模型。持續(xù)的集成需要經(jīng)過確實可靠的測試。值得注意的是，在開發(fā)和集成的同時，我們一般只實現(xiàn)模塊的部分功能，隨后一邊集成，一邊迭代的實現(xiàn)服務組件的功能。在SOA的開發(fā)中，持續(xù)的測試和自動化的測試顯得尤為重要，因為很多潛在的問題只能在Runtime的時候被測試出來，因此不能將風險留給最后的集成階段，必須持續(xù)測試，并保留測試數(shù)據(jù)、測試代碼和測試腳本。從而在項目后期構(gòu)建完整的集成測試腳本，實現(xiàn)自動化測試，對系統(tǒng)的變更做最快的反應。
在上面的規(guī)劃和設計完成后，我們的開發(fā)人員對系統(tǒng)的了解已經(jīng)比較熟悉，因此我們可以根據(jù)文檔，每個開發(fā)小組并發(fā)進行服務的獨立實現(xiàn)。在這個部分，流程和中介等部分的工作依靠WID的強大功能，實現(xiàn)起來并不會很耗費時間。UI，新實現(xiàn)的服務，包裝現(xiàn)有服務的工作量相對較大。我們并不要求這些服務在快速實現(xiàn)服務集成模型的階段完全實現(xiàn)，出于測試和部分集成的需要，可以先實現(xiàn)有限的路徑或者嘗試一些模擬服務的實現(xiàn)，在模擬服務中我們根據(jù)業(yè)務邏輯，返回一些硬編碼的數(shù)據(jù)，隨著開發(fā)和集成的深入，模擬的部分越來越少，從而迭代的實現(xiàn)系統(tǒng)的功能。
在開發(fā)階段開始后，各小組可以獨立進行各自模塊的開發(fā)，基本上每個小組會負責相關(guān)的一些模塊。每個小組的成員，都會"OWN"一些模塊，請注意，一定要很顯式的確定小組成員和模塊之間的關(guān)系，明確責任感和代碼的所有人。每個人對于自己模塊的實現(xiàn)都會有自己的方式，但是不能脫離統(tǒng)一的架構(gòu)和服務的規(guī)約。
我們不建議模塊之間的過早綁定，因此凡是與綁定相關(guān)的工作，除非必要，不然都不要先實現(xiàn)，每個模塊應當聚焦于該模塊自身的功能。延時綁定的可能會帶來以下兩點好處：
1 在開發(fā)過程中綁定方式等各種條件會隨著認識的深入和項目的進展而變化，過早的綁定往往可能需要重新設置，當然使用WID工具，這樣的變更往往不是很耗費時間，但是變更帶來的單元測試和集成測試以及重新部署等工作，可能會消耗比較多的時間。
2 單元測試階段可以隔離組件間的影響，專注于組件內(nèi)部的測試，不需要過早的建立組件之間的聯(lián)系，以免得到擴散的測試結(jié)果。
如我們的上文分析，不同的模塊的進展可能不太一樣，基本上按照集成的順序，各模塊時間上的需求是越來越大，因此我們可能在模塊和人員的配置上做一些有預見性的調(diào)整，比如對于我們示例系統(tǒng)的6個模塊，在當前階段，我們可能需要6名開發(fā)人員，每人負責其中一個模塊，很快隨著項目的進展，2流程和1個中介模塊就會快速完成。此時可以保留一名開發(fā)人員負責這3個模塊，其他人員去幫助時間需求更大的模塊。主要因為WID實現(xiàn)了很多自動化的方式，提高了BPEL和SCA的開發(fā)效率。
在我們的示例中，我們的SCA模塊都被業(yè)務流程組裝起來，如圖1所示。
本章節(jié)的以下部分將分別討論不同模塊的實現(xiàn)和相關(guān)的經(jīng)驗。
在SOA的環(huán)境下，流程作為集成服務的主要手段，起著非常重要的作用，通常情況下，業(yè)務流程是最接近展現(xiàn)層，流程向下集成不同的SCA模塊，向上提供了用戶交互和服務調(diào)用的功能，主要被UI集成。WPS中的BPEL流程引擎提供了豐富和功能強大的API，很容易的可以被JSP，SWT等客戶端工具集成。
關(guān)于具體的BPEL開發(fā)，這里不打算詳細介紹。在WPS6和WID中，流程的實現(xiàn)更為簡單，只需要簡單的拖拽和設置，你就能完成一個業(yè)務流程的建模。當然IBM也提供了更為復雜和專業(yè)的WBM（WebSphere Business Modeler），用于完整的業(yè)務流程建模，使用WBM導出的模型文件，WID可以直接射程業(yè)務流程組件。
對流程中的每個活動，你都可以增加業(yè)務事件的監(jiān)控，設定CEI的消息，以實現(xiàn)業(yè)務監(jiān)控的相關(guān)功能。
在單獨實現(xiàn)流程的時候，我們可能需要定義一些模擬的后臺實現(xiàn)，使得開發(fā)人員專注于流程本身（分支，選擇，子流程等），所有的Parnter的實現(xiàn)我們可以先使用Java 組件的方式，使用偽代碼或者上文提到的測試數(shù)據(jù)生成器。
業(yè)務流程本身我們是要定義在一個SCA的模塊中，盡量使得這個模塊只包括流程的邏輯，這樣從部署，測試，變更控制等角度來看，都具有很重要的意義。
當這部分工作完成后，看起來這個就是一個完整的流程，包含了"預定"的業(yè)務功能，我們部署在自己的測試環(huán)境中，使用BPC Explorer 可以進行測試，觀察流程在測試數(shù)據(jù)的運行情況下是否符合我們的預期，人工活動的交互是否滿足等。此時的測試還是比較簡單的單元測試，主要測試流程的完整性,流程調(diào)用和一些簡單的業(yè)務邏輯。
注：你可以在部署完流程模塊后在瀏覽器中鍵入"http://localhost:9080/bpc/"來訪問BPCExplorer，具體的用法使用請參考WID的聯(lián)機幫助文檔。
在示例應用中我們的業(yè)務流程定義如圖2所示。
業(yè)務流程模塊中會包含人工服務，需要注意對于包含人工活動的流程，需要設定流程類型為longrunning，同時需要設置相關(guān)的事務屬性和會話屬性，詳情請參考相關(guān)文檔。這里不作詳細介紹。
這里我們并不打算詳細的介紹SCA的基礎知識，如欲了解更多SCA的信息，請參考相關(guān)的參考資料。
SCA的一個非常重要的特點就是隔離關(guān)注，SCA模塊強制的將服務的接口和服務的綁定完全分離，服務就是業(yè)務的服務，而綁定則是服務的外在表現(xiàn)和通信協(xié)議，和服務本身的邏輯是沒有交叉的，具體說來，一個模塊可以暴露出同一個接口的多種綁定形式，這就可以被不同的業(yè)務環(huán)境集成。
相比導出的綁定形式 （SCA，JMS，Web Service ），WID中SCA的導入綁定形式相比增加了無狀態(tài)session bean的形式。之所以要增加這個綁定，是為了更好的集成現(xiàn)有的J2EE應用，但是導出則沒有這種方式，則是為了向上提供一致性。前面我們也提到，一般的服務組件如果是Java實現(xiàn)，通常的接口是SDO作為數(shù)據(jù)交換的格式，而如果你的組件import了一個SessionBean，你會發(fā)現(xiàn)你的服務組件的接口返回的仍然是該SessionBean的Java對象，此時Java對象和SDO之間的轉(zhuǎn)化就不可避免了，我們在上一篇文章中已經(jīng)探討過這個問題。
在SCA的世界里，所有的服務都是SCA的服務，但是只不過是綁定的形式不一樣，這符合我們一般的思維模式，比如服務本身的邏輯我們可以類比于是MVC模式中的model，而多種不同形式的綁定就相當于View。
通常我們在WID中一般實現(xiàn)一個SCA模塊的過程如下所示：
1 確定模塊內(nèi)的服務組件：定義服務組件；
2 確定模塊的接口：定義組件的導出；
3 確定模塊要引用的SCA服務：定義組件的導入；
4 確定內(nèi)部服務組件的實現(xiàn)方式：采用流程、中介、業(yè)務規(guī)則或是Java實現(xiàn)組件的業(yè)務邏輯；
5 確定組件之間的關(guān)系：采用流程、連線或者Java代碼編排服務。
組件的實現(xiàn)方式的選擇，可能和具體的業(yè)務邏輯相關(guān)聯(lián)，比如包含路由，分支，映射等更能的組件，就要實現(xiàn)成Mediation Component， 如果作為集成的簡單的客戶端，那么Java Component則是不錯的選擇。如果你希望將業(yè)務規(guī)則，狀態(tài)轉(zhuǎn)化等邏輯從應用中剝離出來，你可以選擇Business Rule或者狀態(tài)機這樣的實現(xiàn)方式。例如在我們的例子中，最終判斷貸款結(jié)果的過程就可以使用業(yè)務規(guī)則來實現(xiàn)，WPS內(nèi)建了業(yè)務規(guī)則引擎，而WID內(nèi)置了規(guī)則編輯器使得你可以將規(guī)則作為服務組件的一種實現(xiàn)方式，采用一種可視化的方式，將業(yè)務邏輯中最容易變化的部分剝離出來，采用專門的服務組件實現(xiàn)，可以很靈活的配置業(yè)務規(guī)則。使用業(yè)務規(guī)則編輯器你可以很方便的創(chuàng)建業(yè)務規(guī)則集，并將規(guī)則和接口綁定，還可以實習很多靈活的配置，對于規(guī)則類型的業(yè)務邏輯，采用業(yè)務規(guī)則來實現(xiàn)可以提高效率。
在實現(xiàn)階段服務還未完成時，根據(jù)SOA項目松耦合的特點，我們可以使用模擬服務暫時替代，保證測試過程的暢通和持續(xù)的集成測試，實現(xiàn)迭代的開發(fā)，下文會有詳細論述。
ESB的實現(xiàn)實際上就表現(xiàn)為采用中介模塊虛擬化原有服務，利用路由實現(xiàn)連通性，利用Mediation實現(xiàn)服務的適配。它能夠顯著的增加業(yè)務邏輯的靈活性，隔離底層服務的區(qū)別，提供虛擬化的統(tǒng)一的業(yè)務服務視圖。
WID很明顯的將中介模塊和普通的SCA模塊區(qū)分開來，你只有在中介模塊中才能使用中介組件，中介組件主要實現(xiàn)服務的路由，消息的轉(zhuǎn)換等工作。在考慮一個服務中介組件的時候，你首先需要確定中介的類型，盡量將相關(guān)的中介邏輯都要放在一個mediation組件中。
一個中介模塊中可能有多個中介消息流，在這些消息流之間流動的除了消息外，還有一些上下文，你可以在每個中介節(jié)點中讀寫上下文，實現(xiàn)局部的消息傳遞。
在我們的例子中，我們采用一個中介模塊來實現(xiàn)業(yè)務流程到核心系統(tǒng)的路由和消息轉(zhuǎn)換，將中介層從業(yè)務邏輯中剝離，可以極大的提高系統(tǒng)的靈活性，實現(xiàn)服務之間的松散耦合。
貸款審批中的中介模塊的例子如圖3所示。
請注意接口和Partner之間的連線，每個連線都是一個中介流，我們可以進行編輯，增加ESB的相關(guān)功能。所以在實現(xiàn)角度ESB包括2層意思，一是ESB服務器，也就是我們選擇的WS－ESB Server，他提供運行時的中介和路由能力；二就是ESB的運行時模塊，也就是我們的中介模塊，上圖中的多條連線以及連線內(nèi)的中介流，他們利用運行時的能力，實現(xiàn)了服務的虛擬化。
1.4.1 新建服務模塊
在SOA的項目實踐中，對于新建服務，實現(xiàn)方式上我們有兩種選擇：
1 獨立完成，如采用傳統(tǒng)J2EE等方式，實現(xiàn)后采用SCA包裝。這樣的考慮主要是現(xiàn)有業(yè)務模式已經(jīng)比較成熟，有很多可重用的設計模式和框架，類包的支持，使得新建的服務可以和容易的實現(xiàn)。因此，在實現(xiàn)新建的服務后，以Web Service或者JMS或者EJB的方式暴露出來，在SCA中集成他們，在流程中調(diào)用SCA，這是一種比較理想的實現(xiàn)方式。
2 直接在SCA模塊中實現(xiàn)業(yè)務邏輯。適當情況下，業(yè)務邏輯可以存在于SCA的組件中，比較常見的是Java組件或者業(yè)務規(guī)則組件，狀態(tài)機等。這樣做可以減少在不同的層次之間的調(diào)用和映射，提高效率。
具體考慮服務的實現(xiàn)方式可能基于不同的應用會有不同的結(jié)果，我們推薦新建服務使用最適合的方式實現(xiàn)，然后使用SCA模塊進行調(diào)用和集成，這樣才能體現(xiàn)SCA的優(yōu)點，一旦后臺系統(tǒng)發(fā)生變化，SCA作為中間層會向上屏蔽這些區(qū)別。這樣所有SCA服務所在的中間層也就是一個ESB。
1.4.2 后臺系統(tǒng)包裝
SOA將現(xiàn)有系統(tǒng)作為可重用的IT資產(chǎn)管理，重用的方式就需要將這些系統(tǒng)包裝成為服務，被業(yè)務系統(tǒng)集成和使用。IBM的產(chǎn)品家族為集成現(xiàn)有系統(tǒng)提供了很多的途徑，包括Adapter、EJB、Web Service、JMS等方式。
例如，在我們的例子中，我們的房貸系統(tǒng)使用的是基于Command模式的EJBFacad來實現(xiàn)，我們不得不使用Java組件包裝在后臺系統(tǒng)，首先實現(xiàn)Java對象到Java對象的Mapping，然后在實現(xiàn)包裝系統(tǒng)的Java對象到SDO的映射。
使用以上技術(shù)，我們將現(xiàn)有系統(tǒng)映射成為SCA模塊，現(xiàn)有系統(tǒng)的功能通過該SCA的導出，被暴露成可重用的標準化的服務接口，作為進一步集成的基礎，通過重用實現(xiàn)了價值的最大化。
回頁首由于項目進度的不均勻性，以及服務實現(xiàn)和服務裝配2個不同開發(fā)路線上的進度的不均衡，在實際的SAO項目中，經(jīng)常會發(fā)生開發(fā)被阻塞或者成員處于等待集成的狀態(tài)中，因此我們非常有必要實現(xiàn)一些模擬的服務來供我們進行單元測試和集成測試。
對于Java組件，狀態(tài)機，業(yè)務規(guī)則或者中介等組件，他們內(nèi)建的業(yè)務邏輯應該首先經(jīng)過組件級別的單元測試，才會被允許集成。對于組件的集成你可以使用ITC(Integration Test Client)來完成。ITC提供了Emulator 的方式測試流程的運行和連貫性，全部采用人工活動來模擬輸入。
同樣如果你的邏輯被封裝在Java代碼中，以服務組件作為門面的話，你可以采用傳統(tǒng)的方法如JUnit對你的代碼進行測試。注意，此時的測試因為
1 缺乏Runtime 的上下文環(huán)境；
2 缺乏真實的業(yè)務環(huán)境。
所以此時的測試不見得能夠說明問題，但是作為單元測試，能夠保證組件在測試條件下正常工作，就算為集成和集成測試打了一個好基礎。
在使用ITC的時候，所有的服務調(diào)用都是模擬實現(xiàn)的，你需要手工的輸入服務的返回值，這樣主要是為了專門測試集成。為了能夠在單元測試的時候測試一些業(yè)務邏輯，這里有個小竅門，你可以在配置頁面鐘中刪除那些Emulator以實現(xiàn)自動調(diào)用。
在UI的工作沒有完全完工之前，我們需要一個模擬的客戶端，來和流程交互，測試流程的功能。當流程和后面的模塊集成后，就可以一直測試到后臺系統(tǒng)，同樣對于SCA的模塊在單元測試的時候，我們也需要的一個模擬的客戶端。
使用ITC 首先我們可以使用WID的Integration Test Client，從右鍵菜單"Test Component"進入該測試界面，ITC會自動生成界面供你選擇希望測試的接口的方法，并可以輸入?yún)?shù)，開始測試。ITC會將測試結(jié)果和測試過程中捕獲的異常以可視化的方式展現(xiàn)出來。ITC適用于所有的SCA模塊，包括流程模塊。在ITC中如果你不希望每次都要輸入測試參數(shù)，你可以選擇將測試參數(shù)保存進一個數(shù)據(jù)池，并將該次測試保存為配置文件，就可以自動加載了。
使用BPC Explore 對于流程模塊，如果已經(jīng)和后臺系統(tǒng)或者虛擬服務連接，我們可以使用BPC瀏覽器來測試流程模塊。如前文所述，該方法簡單快捷，但是你可能不太容易進行持續(xù)的，自動化的測試。值得注意的是，很顯然在BPC瀏覽器的后臺，服務器端的代碼是在調(diào)用BPE的API進行流程的交互，因此你可以自己手工編寫測試代碼去調(diào)用BPE API與流程容器交互，寫出專門的針對流程的自動測試代碼。
手工編寫測試代碼
請注意，任何時候我們都推薦使用測試代碼進行測試，雖然不是一勞永逸的事情，但的確可以為你帶來以下優(yōu)點：
1 靈活，你可以用各種方式測試你的組件，并通過代碼記錄下來，你可以靈活的修改它。
2 重用，固化在代碼中的測試邏輯，其重用性顯然具有重要的價值。
3 自動化，這個是我們認為最重要的地方，借助于自動化的工具（JUnit和ANT），我們可以實現(xiàn)完全自動化的測試。
4 全面，你可以增加數(shù)據(jù)驗證等測試功能，全面的測試你的業(yè)務邏輯。
針對一個SCA模塊的測試代碼看起來像這個樣子（示例）：
public ConfirmTaxAmount locateService_ConfirmTaxAmountPartner() { return (ConfirmTaxAmount) ServiceManager.INSTANCE .locateService("ConfirmTaxAmountPartner"); } /** * Method generated to support implemention of operation "confirmTaxAmount" defined for WSDL port type * named "interface.ConfirmTaxAmount". * * The presence of commonj.sdo.DataObject as the return type and/ or as a parameter * type conveys that its a complex type. Please refer to the WSDL Definition for more information * on the type of input, output and fault(s). */ public DataObject confirmTaxAmount(DataObject input1) { //TODO Needs to be implemented. return locateService_ConfirmTaxAmountPartner().confirmTaxAmount(input1); }
請注意要在你的測試代碼運行時加載SCA runtime的類包，或者使用WID 環(huán)境變量。
如上所述，我們同樣可以直接調(diào)用BPE API和業(yè)務流程的引擎進行交互，生成高質(zhì)量的流程自動化測試代碼，實現(xiàn)上則更為復雜，這里就不做詳細介紹。
因此我們可以看到，使用一些自動的客戶端有以下一些問題：
1 自動化程度低；
2 缺乏數(shù)據(jù)驗證的有效方法；
3 不能應付復雜情況，比如數(shù)據(jù)復制，上下文關(guān)系等。
我們推薦你使用自己的測試代碼以保證最好的效率和靈活性。另一個有趣的方法是：
如果你的測試非常的多，手寫自己的測試代碼可能是一個比較大的工作量，因此我們推薦你研究ITC的API，使用Ant，你可以通過自動化的調(diào)用ITC的后臺API，加載多個測試文件，實現(xiàn)自動化的測試。關(guān)于這方面的話題，每一個展開都會有很多的內(nèi)容，有興趣的讀者可以自己發(fā)揮，自行研究。
僅有組件的有限功能的單元測試，顯然是遠遠不夠的。對于已經(jīng)實現(xiàn)的服務組件，根據(jù)我們的集成計劃，服務就可以開始適當?shù)募珊图蓽y試了，此時需要考慮服務的模擬實現(xiàn)。
例如當我們已經(jīng)完成了一個流程模塊和一個中介模塊，中介后面的現(xiàn)有服務包裝模塊還未實現(xiàn)，我們不可能讓項目組處于等待狀態(tài)，因此我們需要模擬一個服務包裝模塊的服務實現(xiàn)。也就是說我們的服務包裝模塊的服務組件會有2套實現(xiàn)，一套是用于測試，一套用于開發(fā)。
具體的做法比較簡單，我們以一個流程模塊調(diào)用一個SCA模塊為例：
1 配置文件：
你可能需要實現(xiàn)一個簡單的配置文件，可能就是一個簡單的property文件：
testURL=localhost isTest=yes
2 實現(xiàn)一個模擬的SCA模塊，其中的服務組件完全是硬編碼的模擬服務，該模塊的導出應該和真實的SCA模塊完全一致。
3 在流程和模塊之間應該實現(xiàn)一個中介模塊，其導出也是和測試模塊一致。
4 在中介中根據(jù)isTest的值進行路由，如果是測試，就路由到測試的模擬服務中，否則就調(diào)用正常的服務模塊。
這樣在你的真實的服務沒有完成前，你盡可以提供測試的服務實現(xiàn)。一旦服務完成，你只需要修改配置文件就可以輕松的切換測試狀態(tài)，調(diào)用真實服務。這樣做的意義不僅限于可以提前供服務編排的測試，保留這些測試代碼和模擬服務可以提供2個優(yōu)點：
1 回歸測試，用于流程或者組件重構(gòu)；
2 適當避免真實的調(diào)用，在測試階段節(jié)約寶貴的時間。（在使用WID以及配套的重量級開發(fā)環(huán)境時進行測試時，頻繁的啟動和調(diào)用服務會花掉測試人員很多的時間，因此除非必要，盡量使用模擬的服務測試前臺的功能。）
一旦你開始使用模擬服務，你的測試代碼就可以派上用場，會被頻繁的重用，或者加入自動構(gòu)建的腳本中，我們多次強調(diào)，自動化測試在SOA這種繼承性很強的項目中具有顯著的意義。
對于模擬服務的實現(xiàn)程度，最開始你可能都不用考慮業(yè)務邏輯，直接返回一些硬編碼的值（還記得我們的測試數(shù)據(jù)生成器嗎？），隨著測試和開發(fā)的深入，你可能需要模擬一些簡單的業(yè)務邏輯，僅可能的保證測試的質(zhì)量。你的模擬服務要盡量滿足部分測試的目的，主要有以下一些測試目的：
1 測試業(yè)務對象和接口在運行時的狀態(tài)；
2 測試中介和流程的行為是否符合預期；
3 測試被集成的模塊之間的連通性 ；
4 測試錯誤輸入的反應情況。
回頁首持續(xù)集成的基礎就在于服務模擬的演進，隨著集成和測試的深入，模擬服務的表現(xiàn)會越來越接近真實的服務，在機會成熟的時候，我們會完全連接真實服務進行測試。從而最終實現(xiàn)完整的SOA應用。當我們的測試數(shù)據(jù)能夠滿足真實的業(yè)務情況的時候，我們的SOA應用就被建立起來了。
注意在以上各階段的實現(xiàn)過程中，我們要持續(xù)進行評審和討論，保證設計和實現(xiàn)按照既定的路線前進，所有的變更在計劃控制范圍內(nèi)。
評審和討論的目的有2個：
1 發(fā)現(xiàn)不合理的地方；
2 以一種契約的形式規(guī)定開發(fā)過程。
可能的評審和討論內(nèi)容如下：
1 業(yè)務對象(BO)和服務接口（WSDL）的定義，包括對象映射和接口映射。
此時的評審主要是要邀請客戶的業(yè)務專家，客戶的技術(shù)決策人員，對BO的定義，接口的約定，與后臺系統(tǒng)的差距，實現(xiàn)的連通性，整體結(jié)構(gòu)的合理性，進行探討。
對于發(fā)現(xiàn)的不合理的地方，需要重構(gòu)我們的BO和接口，當經(jīng)過一定的返工，再討論后，我們可以以某種契約形式固定這些接口和BO，作為進一步開發(fā)的基礎。
在修改BO的時候，如果添加和刪除BO中的屬性，可能需要手工刪除import的那個xsd。
添加和刪除WSDL接口中的參數(shù)，可能會造成流程調(diào)用該服務時的參數(shù)格式的問題，你可能需要手工修改WSDL文件。
2服務的組裝和服務的實現(xiàn)
服務的組裝和實現(xiàn)包括流程，中介，組件的調(diào)用等，在開發(fā)過程中，可能會產(chǎn)生如下的變化：
1 人工服務的實現(xiàn)可能會被機器服務取代；
2 服務的綁定方式會發(fā)生變化；
3 由于接口的變化和BO的變化帶來的影響；
4 服務實現(xiàn)的變化，例如：可能由Java實現(xiàn)轉(zhuǎn)化為Business Rule實現(xiàn)。
對于這些或者不能避免，或者可以避免的變化，架構(gòu)組的成員都要仔細討論，評估變化帶來的影響，做出決策，保證項目的順利進行。
通常情況下流程集成，我們的SOA應用和一般的應用從UI的角度看起來并沒有太大的區(qū)別。因此在UI的實現(xiàn)上，常見的方式都能夠適用，最終的裝配可能有2種形式：
1 UI+BPEL；
2 UI+SCA 調(diào)用。
無論是那種情況，UI的model可能都是對應SDO，因此可能需要適當?shù)姆绞阶鲆恍㏒DO的轉(zhuǎn)化，你可以在JSF中直接使用SDO作為數(shù)據(jù)源進行展現(xiàn)，而且這也是一種比較合理的做法。
對于UI和BPEL流程的集成，我們可能會使用一些BPE的API，我們會在JSP或者Action中啟動一個流程，并持續(xù)的和流程交互，UI的輸入會被映射到流程的人工服務。
對于UI和SCA的集成 也會用到WPS中的SCA API，具體可以參考相關(guān)的Sample我們推薦 UI、Process和SCA 各司其職，主要的業(yè)務功能仍然使用其最適合的方式，SCA和流程主要作為集成的手段，這樣，對于開發(fā)部署，變更等，系統(tǒng)具有更大的靈活性。在流程模塊中，盡量不包含流程以外的業(yè)務邏輯，業(yè)務功能應當在業(yè)務流程之后的SCA模塊中實現(xiàn)。
根據(jù)我們定義的集成模型，和我們持續(xù)的集成，迭代的開發(fā)，最終所有的集成會在預定的時間完成，此時我們需要進行完整的全面測試，測試路徑將涵蓋UI、流程、SCA模塊和后臺系統(tǒng)。
我們可以先測試一個流程中的一個功能，保證從UI到后臺系統(tǒng)的連通性，驗證體系結(jié)構(gòu)的可行性。注意如果你對整個結(jié)構(gòu)沒有把握的話，這個過程可能提前。通常情況下，具備基礎的SOA開發(fā)經(jīng)驗的工程師和架構(gòu)師在設定的架構(gòu)，都能夠滿足運行時候的需要，而不會產(chǎn)生全面集成時的大的架構(gòu)變更。
業(yè)務功能測試是一項很巨大的工作，最好確保有一些自動測試代碼和log分析工具來協(xié)助你進行測試，目前IBM公司也在開展一些SOA testing 方面的工作，希望將來會有整套的方法論和測試工具支持SOA測試。
部署也應該進行測試，以保證你的開發(fā)平臺和最終的運行環(huán)境匹配，因此當你開發(fā)進行到一定的程度，應當進行部署方面的測試，部署的測試主要是進行部署和連通性測試，保證環(huán)境的問題盡早暴露。因此部署測試應該在至少全部的應用框架都能夠運行，但是功能尚未全面完成的時候開始的。
一個具體的SOA項目可能會有數(shù)十個部署單元，構(gòu)建自動部署的腳本是十分必要和明智的，可以幫你節(jié)約很多的人力和時間，尤其在項目的后期，進行持續(xù)的測試和改進的時候，你會頻繁的部署和測試。一般我們使用基于ANT的自動化部署腳本，可以方便的解決問題。
使用Ant工具和jacl部署腳本以及我們在項目過程中積累的測試用例和測試代碼，我們最終將完成從開發(fā)到部署到測試的自動化集成。
最終的測試腳本會首先從CVS上下代碼，然后基于預先配置的類路徑自動構(gòu)建項目，然后實打包項目的EAR文件，然后是部署，最后是使用我們前面完成的測試代碼，自動運行測試腳本，打印測試結(jié)果。這樣項目的開發(fā)團隊可以實現(xiàn)很高的開發(fā)效率。這里我們重復強調(diào)一點，因為采用很多動態(tài)的技術(shù)和弱類型的對象，SCA編程模型對運行時的要求變得更高，很多問題只能在運行時才會發(fā)現(xiàn)，因此，持續(xù)的測試和自動化的測試將會使得你的SOA開發(fā)達到事半功倍的效果。
回頁首回顧我們整個的開發(fā)過程，我們會有如下的關(guān)鍵體會：
1 借助新的SOA編程模型來保證設計和實現(xiàn)階段服務模型的一致性。
服務模型包括服務的消息，接口，服務之間的關(guān)系等，我們認為服務模型的概念會一直延伸到SCA模塊的層次。在我們的實現(xiàn)中我們借助工具，使用SCA編程模型保證了服務模型從消息定義到服務實現(xiàn)的一致性。
2 通過服務集成模型來降低SOA項目的實施風險：
服務集成的模型包括SCA內(nèi)部的裝配和SCA模塊之間裝配，以及這些裝配的時間，進度，資源的安排。一旦項目的服務集成模型被定義，開發(fā)和測試的進度也就基本確定。
3 利用分層和映射來提高SOA開發(fā)和運行時的靈活性：
SOA采用分層的方法來隔離關(guān)注，層次之間以及層次的對象之間，服務之間，經(jīng)常會需要映射，這是SOA項目實踐中非常關(guān)鍵的一個問題。
4 利用持續(xù)的自動化的測試來提高SOA實施的質(zhì)量和效率：
我們一直推薦采用測試代碼的方法進行測試，除了靈活性的考慮，更多的是看重自動化測試帶來的優(yōu)點。對于SOA架構(gòu)下的復雜應用，自動化的測試具有相當重大的意義。
SOA 快速指南 1 2 3，第 6 部分: 以服務為中心的業(yè)務活動管理與監(jiān)控
文檔選項
將此頁作為電子郵件發(fā)送拓展 Tomcat 應用
下載 IBM 開源 J2EE 應用服務器 WAS CE 新版本 V1.1級別: 初級
金 戈, IBM軟件部企業(yè)集成解決方案架構(gòu)師, IBM 中國軟件開發(fā)實驗室 SOA設計中心
姚 輝 (
yaohui@cn.ibm.com), IBM 中國SOA 設計中心高級工程師, IBM 中國軟件開發(fā)實驗室
趙 勇 (
zhaoyong@cn.ibm.com), IBM 中國SOA 設計中心工程師, IBM 中國軟件開發(fā)實驗室
譚 佳, IBM 中國SOA 設計中心工程師, IBM 中國軟件開發(fā)實驗室
2007 年 2 月 06 日
《以服務為中心的業(yè)務活動管理和監(jiān)控》是本系列文章的最后一個部分，將結(jié)合本系列文章所使用的汽車貸款實例介紹如何實現(xiàn)構(gòu)建企業(yè)的業(yè)務流程管理模型。本文的組織方式是：第 2 部分介紹業(yè)務活動監(jiān)控的基本概念，即什么是業(yè)務監(jiān)控，它與傳統(tǒng)商業(yè)智能之間的關(guān)系是什么；第 3 部分描述創(chuàng)建業(yè)務流程管理模型的基本步驟，即從何入手建立一個完整的企業(yè)業(yè)務活動監(jiān)控模型，第 4 部分則結(jié)合本系列的業(yè)務場景使用 IBM 最新推出的 WBI Modeler 6 來介紹如何構(gòu)造一個業(yè)務活動監(jiān)控模型，最后是總結(jié)。希望通過本文的介紹，能夠幫助讀者理清基本的概念脈絡，了解構(gòu)建業(yè)務活動監(jiān)控模型主要的實施步驟，從而為在將來的項目中實現(xiàn)業(yè)務活動管理奠定良好的基礎。
以服務為中心的業(yè)務活動管理與監(jiān)控是最近出現(xiàn)的一種熱門的IT技術(shù)，它的目的在于幫助企業(yè)管理人員實時獲悉企業(yè)運營狀況，了解企業(yè)的戰(zhàn)略實施進展。
《SOA 快速指南 1 2 3》系列文章是筆者近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。該系列文章結(jié)合一個汽車貸款流程， 介紹了在 SOA 的環(huán)境下如何基于 IBM 的現(xiàn)有產(chǎn)品構(gòu)造業(yè)務活動管理解決方案，詳細闡述了每個實施步驟中使用的 IBM 的方法學、技術(shù)和產(chǎn)品。希望通過本文的介紹，能夠幫助讀者理清業(yè)務流程管理所包含的基本概念，并了解構(gòu)建解決方案所需要的基本步驟。
回頁首本系列是 IBM 中國軟件開發(fā)實驗室 SOA 設計中心近年來在 SOA 項目實施中的經(jīng)驗結(jié)晶。
項目概述 第 1 部分：SOA 采納步驟和價值分析 第 2 部分：服務建模 第 3 部分：服務實現(xiàn)及架構(gòu)設計 第 4 部分：快速實現(xiàn)服務集成模型 第 5 部分：逐步實現(xiàn)服務和持續(xù)集成 第 6 部分：以服務為中心的業(yè)務活動管理與監(jiān)控 在當前激烈競爭的市場環(huán)境下，企業(yè)管理人員面臨著巨大的壓力提高生產(chǎn)率和削減運營成本。從戰(zhàn)術(shù)執(zhí)行的角度來考慮，公司管理人員需要一種手段來幫助自身從紛繁復雜的表象中獲取知識，實時獲悉企業(yè)戰(zhàn)略實施情況，及時了解企業(yè)運營過程中存在的風險，并做出及時地響應，從而將公司打造成為能夠快速適應外界環(huán)境變化的有機實體。業(yè)務流程管理（Business Process Management, BPM）為實現(xiàn)這一目的提供了有針對性地解決手段。據(jù)InformationWeek統(tǒng)計，85%的企業(yè)CIO都認為業(yè)務流程管理將成為公司利潤提升的主要手段。但是，從現(xiàn)有的企業(yè)IT環(huán)境來看，當前信息技術(shù)很難為構(gòu)建靈活的業(yè)務流程解決方案提供直接地支持，這其中存在兩個問題：首先是技術(shù)異構(gòu)問題，從長期來看，企業(yè)出于保護投資或是選擇項目實施合作伙伴的原因，企業(yè)信息系統(tǒng)建設通常采用了不同的技術(shù)。在經(jīng)過多年的積累后，企業(yè)內(nèi)部的每一個應用都形成了一個小的信息孤島，IT本身就成為了一個大麻煩；其次是實時性和適應性的問題，當前市場上存在的商業(yè)智能軟件能夠以數(shù)據(jù)報表的形式為管理人員提供決策支持，但是傳統(tǒng)的商業(yè)智能軟件主要是對于企業(yè)運營歷史數(shù)據(jù)的分析和處理，它能夠為企業(yè)高層管理人員制定合理的戰(zhàn)略提供量化的支持，但是無法反映企業(yè)戰(zhàn)術(shù)層面的執(zhí)行問題，無法快速響應業(yè)務流程執(zhí)行的異常情況，也無法按照需求的快速變化調(diào)整公司運營策略，這種情況被David Luchham稱為"IT Blindness"。
面向服務的業(yè)務流程管理為解決以上問題提供了可能性。從概念上來看，業(yè)務流程管理可以劃分為三個層面的內(nèi)容：業(yè)務流程建模、流程執(zhí)行和流程指標監(jiān)控。流程建模用于構(gòu)建公司的業(yè)務運營流程模型，它從公司日常的生產(chǎn)經(jīng)營活動入手，使用業(yè)務活動之間的序列關(guān)系描述企業(yè)的業(yè)務模型，幫助業(yè)務分析人員識別流程中的瓶頸，從而為流程優(yōu)化奠定良好基礎。業(yè)務流程建模是整個過程的第一步，也是最關(guān)鍵的一步，它不僅需要確定業(yè)務活動之間的序列關(guān)系，還需要確定業(yè)務模型中所包含的業(yè)務績效指標信息。在分析人員確定企業(yè)的流程模型之后，軟件架構(gòu)師需要將流程模型轉(zhuǎn)化為以服務為單元的體系結(jié)構(gòu)模型，并由開發(fā)人員和集成人員加以實現(xiàn)。需要指出的是，業(yè)務流程的運行平臺通常是企業(yè)服務總線，它體現(xiàn)形式可能是BPEL，也可能是MQ Flow，它們一個共同的特點是跨越了多個應用系統(tǒng)。最后是流程監(jiān)控，流程監(jiān)控是對于業(yè)務操作的記錄，它一方面保存了業(yè)務運行的業(yè)務數(shù)據(jù)，如銷售金額，另外一方面也保存了流程本身的信息，如時間信息和異常情況等。從運行的角度來看，流程監(jiān)控軟件會按照分析人員規(guī)約的流程監(jiān)控模型收集系統(tǒng)業(yè)務事件，加以分析處理，進而將其轉(zhuǎn)化為對于業(yè)務人員具有明確含義的關(guān)鍵業(yè)務指標，并以圖形化的方式將分析結(jié)果展現(xiàn)在用戶面前。流程建模、流程執(zhí)行與流程監(jiān)控構(gòu)成了一個閉環(huán)的回饋系統(tǒng)，該系統(tǒng)使得企業(yè)能夠根據(jù)自身業(yè)務流程特點，準確識別企業(yè)運行過程中存在的種種問題，并快速適應外界環(huán)境的變化。
業(yè)務流程管理主要包含業(yè)務目標、關(guān)鍵業(yè)務績效指標和業(yè)務度量等基本概念。業(yè)務目標是整個業(yè)務流程管理構(gòu)建過程的起點，它描述了機構(gòu)為達成良好增長所需要達到的條件，其描述方式通常是使用自然語言，如"本年度公司銷售額增長率為10%"、"本季度公司利潤增長率為5%"、"專利申請總數(shù)達到1000件"等。業(yè)務目標可以認為是公司高層管理人員按照公司的戰(zhàn)略規(guī)劃為整個組織所設定的里程碑，它不僅可以作為公司業(yè)績的體現(xiàn)，也可以作為員工績效考核的基礎。業(yè)務目標具有如下幾個特點：首先是可分解性，即整個公司擁有一個總體目標，其下屬機構(gòu)應該根據(jù)其自身環(huán)境確定每一個分部門的目標取值，每一個員工也會確定自己在本年度的個人績效指標；其次是可實踐性，業(yè)務目標必須建立在高層管理人員對于公司實際情況以及整個市場環(huán)境的精確判斷上，它必須是可操作的；最后是風險性，業(yè)務目標只是一種預期，而市場環(huán)境瞬息萬變，所以管理人員也必須意識到業(yè)務目標只是一種手段來幫助企業(yè)更好的成長。業(yè)務目標的確定不能僅僅局限于公司領(lǐng)導的經(jīng)驗，同時還需要行業(yè)咨詢?nèi)藛T的幫助。在設計整個公司戰(zhàn)略規(guī)劃時，領(lǐng)導通常需要在業(yè)內(nèi)資深咨詢?nèi)藛T的幫助下構(gòu)建企業(yè)總體執(zhí)行戰(zhàn)略，同時將業(yè)務目標作為一種戰(zhàn)術(shù)手段推進執(zhí)行的力度和激勵員工的士氣。
在確定公司的業(yè)務目標后，如何推進公司能夠順利地達成該目標成為執(zhí)行的關(guān)鍵。業(yè)務流程管理認識到每一個公司所從事的業(yè)務活動都可以被劃分為若干具有明確業(yè)務含義的業(yè)務流程，從流程出發(fā)度量整個公司的運營狀況比單純從數(shù)據(jù)出發(fā)更加容易，而且也擁有更加豐富的監(jiān)控內(nèi)容。所以，IT業(yè)界紛紛推出構(gòu)建在SOA基礎上的業(yè)務流程管理軟件。為了從IT層面上支撐整個業(yè)務流程管理框架，業(yè)務流程管理還需要一組細化概念的幫助，其中最為重要的是關(guān)鍵業(yè)務績效指標(Key Performance Indicator)和業(yè)務度量(Metric)。關(guān)鍵業(yè)務績效指標是對于當前企業(yè)運營流程的度量，它通常是從高層描述了企業(yè)運營的某一個側(cè)面，如貸款申請中的業(yè)務增長率和不良貸款變化率等。KPI是業(yè)務目標在特定流程層面上的細化，通?？梢允褂脭?shù)值來度量，并且業(yè)務人員會為其設定變動的上限和下限范圍。業(yè)務度量則是對于KPI的細化，它代表了一個可獨立計算的數(shù)據(jù)項，但是可能在業(yè)務上并沒有明確的含義，如貸款申請流程的啟動時間和結(jié)束時間，而業(yè)務人員可能真正關(guān)心的是所有流程的平均處理時間。通常而言，每一個業(yè)務度量都代表了一次業(yè)務流程執(zhí)行實例的特定側(cè)面，而關(guān)鍵業(yè)務指標則是對于這些側(cè)面的統(tǒng)計度量。所以，關(guān)鍵業(yè)務指標從IT層面上提供了一種可量化可操作的手段幫助公司高層管理人員實時獲悉企業(yè)戰(zhàn)略執(zhí)行情況，了解運營過程中存在的風險，并為構(gòu)建快速適應外界環(huán)境變化的機構(gòu)奠定良好基礎。
為了實現(xiàn)以上需求，從運行層面來看，面向服務的業(yè)務流程管理需要提供如下功能：首先，業(yè)務流程管理必須支持從各種數(shù)據(jù)源提取有意義的業(yè)務數(shù)據(jù)，并將它們組合成為具有明確業(yè)務含義的關(guān)鍵績效指標(KPI)，這些數(shù)據(jù)源可能是關(guān)系型數(shù)據(jù)庫，也可能是企業(yè)服務總線中的消息Hub；其次，業(yè)務流程管理需要針對流程運行的異常情況及時發(fā)送相關(guān)預警消息。業(yè)務人員在訪問界面上設定某些關(guān)鍵績效指標的閥值，當指標取值一旦超出預期范圍，系統(tǒng)需要為業(yè)務人員發(fā)送預警消息，其手段可以采用郵件、即時消息或是短消息等；最后，業(yè)務活動監(jiān)控需要以報表的形式對于歷史數(shù)據(jù)做出相應的統(tǒng)計，系統(tǒng)按照特定的緯度對于數(shù)據(jù)做分類計算，如按照產(chǎn)品種類、時間范圍或是空間范圍等，這些統(tǒng)計數(shù)據(jù)以儀表盤（Dashboard）的方式為管理人員提供了直觀的交互界面。
理清了業(yè)務流程管理所包含的基本概念內(nèi)涵，接下來我們來看業(yè)務流程管理與商業(yè)智能(Business Intelligence, BI)之間的關(guān)系。商業(yè)智能為公司高層管理人員提供了一種量化的決策分析支持手段，它從公司歷史業(yè)務數(shù)據(jù)入手，通過挖掘當前數(shù)據(jù)模式與預測未來趨勢，BI為管理人員制定公司長期的經(jīng)營戰(zhàn)略奠定了良好基礎。而業(yè)務流程管理則關(guān)注公司流程執(zhí)行層面，它注重的是公司短期戰(zhàn)術(shù)的執(zhí)行，為公司運營提供了更加精細的監(jiān)控手段。從本質(zhì)來看，商業(yè)智能關(guān)注的是公司長期戰(zhàn)略規(guī)劃的問題，而業(yè)務流程管理解決的是公司短期戰(zhàn)術(shù)執(zhí)行的問題。業(yè)務流程管理與商業(yè)智能的區(qū)別在于：首先，從實施目的來看，業(yè)務流程管理更加著重于流程的管理與再造，通過使用流程建模工具將公司日常操作形式化，業(yè)務流程管理可以幫助管理人員更好的識別流程中的活動瓶頸，為流程優(yōu)化奠定基礎；而商業(yè)智能則著重于從現(xiàn)有數(shù)據(jù)集合眾挖掘有意義的業(yè)務指標，為管理人員做出正確的長期戰(zhàn)略決策提供幫助。其次，從建模內(nèi)容來看，業(yè)務流程管理的內(nèi)容包括流程建模、服務建模和業(yè)務對象建模等，而商業(yè)智能的基本實現(xiàn)步驟主要是基于現(xiàn)有數(shù)據(jù)庫定義規(guī)約數(shù)據(jù)的挖掘維度，從中提取有明確業(yè)務含義的內(nèi)容。再次，從操作對象來看，業(yè)務流程管理主要針對的是系統(tǒng)存在的服務和流程，而商業(yè)智能主要操作的對象則是數(shù)據(jù)庫中當前存儲的數(shù)據(jù)。最后，從實現(xiàn)手段來看，業(yè)務流程管理主要基于實時從業(yè)務流程中獲取的業(yè)務事件，并將其轉(zhuǎn)化成為有意義的業(yè)務數(shù)據(jù)，而商業(yè)智能則需要按照數(shù)據(jù)挖掘模型，從數(shù)據(jù)庫中提取有意義的數(shù)據(jù)。另一方面，業(yè)務流程管理與商業(yè)智能之間又存在著緊密的聯(lián)系，商業(yè)智能為業(yè)務流程管理的數(shù)據(jù)分析與聚合提供了良好的實現(xiàn)手段。在涉及到業(yè)務指標的多維計算與挖掘時，商業(yè)智能作為一種成熟的技術(shù)實現(xiàn)手段可以為業(yè)務流程管理提供良好的支持。
在用戶實施業(yè)務流程管理解決方案的過程中，第一步通常是明確企業(yè)的流程模型和服務模型。流程模型是具有明確業(yè)務含義的業(yè)務活動序列，它是對于企業(yè)日常操作的抽象，流程分解對于服務識別具有極其重要的意義。每一個服務都代表了系統(tǒng)中具有明確業(yè)務意義并且可復用的功能。本系列前述文章已經(jīng)詳細描述了如何從需求入手構(gòu)造企業(yè)的流程模型和服務模型，本文不再贅述，下面本文將詳細介紹如何基于已有流程模型構(gòu)造企業(yè)的業(yè)務流程管理解決方案。
WBI Modeler 6.0業(yè)務指標規(guī)約主要可以分為三個方面：業(yè)務指標規(guī)約、數(shù)據(jù)緯度分析和預警消息定義，這三個方面各有側(cè)重，分別用于解決不同問題。
業(yè)務指標規(guī)約：業(yè)務指標定義最主要的目的是解決從問題域的業(yè)務目標描述到解域的業(yè)務指標規(guī)約的問題。在業(yè)務人員看來，業(yè)務目標通常是使用自然語言描述的業(yè)務陳述，如"本年度公司利潤率預期增長10%"，"貨物訂單處理時間不超過三天"等。但是計算機通常無法識別以上陳述，其中的概念鴻溝就是通過業(yè)務指標定義來彌補。業(yè)務咨詢?nèi)藛T或是業(yè)務分析員按照預先規(guī)約的業(yè)務流程與業(yè)務對象，建立形式化的業(yè)務指標規(guī)約模型，并將其與業(yè)務事件相互映射。在本階段，相關(guān)人員使用WBI Modeler提供的關(guān)鍵績效指標(KPI)、業(yè)務度量(Metric)、觸發(fā)器(Trigger)、秒表(Stopwatch)和計數(shù)器(Counter)等基本概念來建模公司的業(yè)務度量指標。其中，關(guān)鍵績效指標和業(yè)務度量是最核心的概念，而其它概念則是對于以上概念的延伸和擴展。
數(shù)據(jù)維度分析：實時數(shù)據(jù)維度分析是整個業(yè)務監(jiān)控模型構(gòu)建中重要的一環(huán)。業(yè)務指標規(guī)約解決了模型定義的問題，但是公司真正關(guān)心的是如何更好的從這些數(shù)據(jù)中挖掘出與績效考核和流程優(yōu)化相關(guān)的信息，這些系統(tǒng)通常是基于某些可比較的維度，所以為業(yè)務指標模型定義合適的數(shù)據(jù)分析維度非常重要。大致而言，數(shù)據(jù)分析維度的定義通常是基于一些分類信息，如產(chǎn)品類別、處理時間和銷售地點等。業(yè)務流程管理基于這些分析類別，幫助公司管理人員按照區(qū)域或時間段實時展現(xiàn)和分析整個公司的運營情況，比如全國哪一個區(qū)域客戶投訴率最低，哪一個區(qū)域取得了最大增長等，然后據(jù)此調(diào)整公司戰(zhàn)術(shù)，為關(guān)鍵績效指標的實現(xiàn)奠定良好的基礎。
預警消息定義：預警消息是業(yè)務異常在流程執(zhí)行層面的具體體現(xiàn)。當關(guān)鍵績效指標未滿足業(yè)務人員預先設定的區(qū)域變動閥值時，系統(tǒng)會自動提示業(yè)務操作人員，警告用戶當前流程執(zhí)行出現(xiàn)問題，需要人工干預加以解決。流程異?？赡軄碜杂诙喾N原因，從流程實例運行的角度來看，可能是由于實例運行時間超過了最大服務時間，如貸款申請時間超過了銀行預先申明的5個工作日等；從業(yè)務數(shù)據(jù)的角度來看，可能是由于業(yè)務數(shù)據(jù)統(tǒng)計數(shù)值未達到預先設定的目標，如某一個特定時間段銀行的不良貸款率快速增長，超過了預先設定最大限額。所以，識別并定義這些預警消息是創(chuàng)建實時企業(yè)極其重要的一個環(huán)節(jié)。構(gòu)建一個良好的預警消息模型依賴于兩個方面的能力，首先業(yè)務人員需要清楚什么是真正的業(yè)務異常，什么樣的異常需要用戶及時的處理，另外一個方面則需要設定良好的變動閥值，閥值變動范圍過窄會使得用戶每天會收到大量的預警消息，從而降低用戶處理業(yè)務異常的意愿和能力。
業(yè)務目標、關(guān)鍵績效指標和業(yè)務度量是整個業(yè)務流程管理框架的核心概念，它們覆蓋了整個業(yè)務層面對于流程管理的需求。但是，從技術(shù)實現(xiàn)的角度來看，這些概念過于抽象，仍然無法保證實現(xiàn)一個良好的可操作的業(yè)務流程管理框架，這其中的問題主要是業(yè)務領(lǐng)域與IT域之間存在的差距。為了解決該問題，IBM WebSphere Modeler 6.0在以上三個概念的基礎上構(gòu)建了一個更加豐富的概念集合，如計數(shù)器、觸發(fā)器和環(huán)境事件等，這些內(nèi)容為開發(fā)人員實現(xiàn)基于流程的業(yè)務監(jiān)控奠定了良好的基礎。整個實施模型的概念框架如下圖所示：
關(guān)鍵業(yè)務績效指標(KPI)：KPI是對于業(yè)務目標的量化規(guī)約，在WBI Modeler中每一個KPI都對應于一個業(yè)務流程類型，而不是業(yè)務流程實例。缺省情況下，KPI定義至少應該包含以下屬性：名稱、類型、計算函數(shù)、度量數(shù)據(jù)來源以及波動范圍邊界（通常包含上邊界與下邊界兩種）等。
業(yè)務度量(Metric)：業(yè)務度量是對于流程實例運行過程中某一個側(cè)面的記錄，同時也是對于KPI的細化，它可能并不具有明確的業(yè)務含義，但是多個業(yè)務度量指標合起來可以計算一個業(yè)務績效指標。比如，銀行貸款流程實例的啟動時間和終止時間對于業(yè)務人員是無意義的，但是該流程的平均處理時間對于業(yè)務人員而言則是有意義的。大致而言，WBI Modeler中的業(yè)務度量可以分為三類：業(yè)務數(shù)據(jù)度量、實例度量和聚合度量等。業(yè)務數(shù)據(jù)度量記錄了流程執(zhí)行過程中業(yè)務數(shù)據(jù)的屬性變動，或是業(yè)務數(shù)據(jù)自身；實例度量則記錄了流程執(zhí)行的結(jié)果；聚合度量是對于其他度量數(shù)據(jù)的統(tǒng)計和計算，它用于發(fā)現(xiàn)以上度量集合中的最大值、最小值或是平均值。
秒表（Stopwatches）：秒表是一種特殊的業(yè)務度量類型，它記錄了流程、活動或是活動集合執(zhí)行所花費的時間。秒表具有兩個特殊的屬性：啟動時間和終止時間，當接收到啟動時間時秒表開始計時，接收到停止事件時終止計時，接收到重置時間則將計數(shù)值清零。所以，秒表可以接收多種觸發(fā)事件。
計數(shù)器（Counters）：計數(shù)器也是一種特殊的業(yè)務度量類型，它記錄了業(yè)務事件發(fā)生的次數(shù)。計數(shù)器的一個基本屬性是計數(shù)值，它通常根據(jù)某一個預先設定的條件來確定是否將計數(shù)值加一、減一或是清零。
觸發(fā)器（Triggers）：觸發(fā)器提供了一種機制能夠啟動某些動作的執(zhí)行，比如，開發(fā)人員能夠通過觸發(fā)器來執(zhí)行業(yè)務度量數(shù)據(jù)更新的動作。大致而言，觸發(fā)器有兩種：外部觸發(fā)與內(nèi)部觸發(fā)。外部觸發(fā)是指當流程狀態(tài)被改變或是接收到某一個活動的輸入時，流程實例顯式發(fā)出一條觸發(fā)消息，推動整個業(yè)務流程管理的執(zhí)行，而內(nèi)部觸發(fā)則是指模型內(nèi)部的業(yè)務度量值被更新或是計數(shù)器發(fā)生變化并且滿足某一條件后觸發(fā)器被執(zhí)行。觸發(fā)器提供了一種機制使得開發(fā)人員能夠靈活的定義整個監(jiān)控模型的執(zhí)行步驟，從模型整體來看，觸發(fā)器會最終會構(gòu)成一條執(zhí)行鏈。
事件（Events）：事件可以分為兩類：輸入事件（Inbound Event）與環(huán)境事件（Situation Event）。輸入事件是指流程監(jiān)控引擎所接受到的外部事件，該事件一般會觸發(fā)整個監(jiān)控過程的執(zhí)行，如流程開始運行，或是貸款被批準時，流程引擎都可能產(chǎn)生輸入事件，從而啟動觸發(fā)某些外部觸發(fā)器的執(zhí)行。環(huán)境事件則是指由流程引擎主動發(fā)出的事件，如果關(guān)鍵業(yè)務指標或是業(yè)務度量滿足特定的邊界條件，則監(jiān)控引擎會自動發(fā)出業(yè)務事件提醒業(yè)務人員，此時發(fā)出的事件就是我們之前討論的預警消息。
回頁首針對本文所使用汽車貸款流程，下面我們來介紹如何創(chuàng)建該銀行的業(yè)務流程管理解決方案。從業(yè)務流程管理的整個生命周期來看，流程建模為運行時刻的流程監(jiān)控提供了元模型，該模型會指導監(jiān)控引擎從紛繁復雜的IT系統(tǒng)中抽取真正有意義的事件和數(shù)據(jù)，并最終匯集成為業(yè)務績效指標數(shù)據(jù)。從汽車貸款流程來看，其基本的業(yè)務步驟包括：用戶提交申請，信貸專員實行資信評估，信貸經(jīng)理審批，最后知會申請人審批結(jié)果。我們現(xiàn)在的問題就是為這樣一個簡單的流程構(gòu)造一個真正反應用戶需求而且靈活易于擴展的業(yè)務監(jiān)控解決方案。從實施步驟來看，整個過程可以被劃分為如下步驟：識別業(yè)務目標、確定關(guān)鍵業(yè)務績效指標、構(gòu)建映射關(guān)系、建立預警規(guī)則和設計觸發(fā)時間。
1) 識別業(yè)務目標：確定公司業(yè)務目標是整個方法中的第一步。分析人員通過與業(yè)務人員反復討論，首先需要確定公司整體的業(yè)務目標規(guī)劃。這一步驟中非常重要的一個原則就是分析人員需要與真正的業(yè)務人員緊密協(xié)作，需要由業(yè)務人員來確定什么是其公司的業(yè)務指標，而不能由分析人員越俎代庖。就汽車貸款流程而言，不良貸款比率與流程執(zhí)行時間是兩個比較重要的指標，其中不良貸款比率決定了公司的盈利狀況，而貸款流程的執(zhí)行時間則反映了貸款部門的工作效率，從而進一步影響了客戶的滿意度。本文將貸款流程執(zhí)行時間的業(yè)務目標定義為5個工作日答復客戶，不良貸款比率的業(yè)務目標設定為10%。公司整體業(yè)務目標規(guī)劃的確定并不是本階段的結(jié)束，開發(fā)人員還需要根據(jù)某些維度來細化業(yè)務目標，比如按照時間段、產(chǎn)品類別和公司機構(gòu)等做進一步的細化分，確定每一個類別的業(yè)務目標。最后給出的結(jié)果是一份詳細描述了客戶需求的業(yè)務目標規(guī)約文檔。
2) 確定關(guān)鍵業(yè)務績效指標：在確定業(yè)務目標后，設計人員需要將業(yè)務目標轉(zhuǎn)換為業(yè)務度量，即以量化的手段來描述業(yè)務目標。KPI可以是業(yè)務目標的量化體現(xiàn)，它從流程執(zhí)行的層面定義了如何計算業(yè)務目標取值，以及該取值目標變動范圍的大小。以汽車貸款流程為例，流程執(zhí)行時間存在一個最大執(zhí)行時間，一旦某一個申請案例處理時間超過該時間，需要及時通知相關(guān)的業(yè)務人員，并做出相應的決策以保證業(yè)務能夠及時被完成。本文將貸款申請流程的關(guān)鍵績效指標標準取值為4天，變動范圍為-1~+1天。從運行的角度來看，KPI的標準取值與變動閥值通常是可配置的。
3) 構(gòu)建映射關(guān)系：KPI定義了業(yè)務人員需要監(jiān)測的內(nèi)容，但是如何基于現(xiàn)有數(shù)據(jù)計算KPI還需要開發(fā)人員做進一步的映射。一般而言，KPI的計算公式是在業(yè)務度量數(shù)據(jù)上施加相關(guān)的聚合函數(shù)，如求最大值、最小值或平均值等。所以，第三步需要定義相關(guān)的業(yè)務度量模型，并在業(yè)務度量以及KPI之間建立相關(guān)映射。仍然以汽車貸款流程的平均處理時間為例，設計人員需要首先創(chuàng)建兩個業(yè)務度量來保存貸款流程實例的啟動時間和結(jié)束時間，然后創(chuàng)建一個實例度量來保存單個流程實例的處理時間，最后對于所有的實例度量求平均值，從而計算所需要的流程平均處理時間。
4) 建立預警規(guī)則：在確定KPI以及相關(guān)的映射關(guān)系后，開發(fā)人員還需要建立預警規(guī)則。預警規(guī)則通常是具有明確業(yè)務含義的提示信息，它用于在流程執(zhí)行出現(xiàn)異常時向相關(guān)人員發(fā)送預警消息，如KPI取值超出其變動范圍。在該步中，開發(fā)人員需要首先根據(jù)業(yè)務績效指標，確定規(guī)則觸發(fā)的條件，然后確定條件一旦被觸發(fā)系統(tǒng)所需要采取的動作，可以采取的動作類型包括向業(yè)務人員發(fā)送電子郵件，發(fā)送手機短消息或是向應用特定的數(shù)據(jù)庫中寫入紀錄等。以汽車貸款流程為例，預警規(guī)則可以定義為當汽車貸款申請流程執(zhí)行時間超過5個正常工作日時會自動向相關(guān)業(yè)務人員發(fā)送警告消息。需要注意的是，預警消息不一定只能服務于關(guān)鍵績效指標，開發(fā)人員同樣可以為業(yè)務度量定義預警規(guī)則。
5) 選擇觸發(fā)事件：業(yè)務流程監(jiān)控與傳統(tǒng)商業(yè)智能的重要區(qū)別之一就在于其主動性，即能夠?qū)崟r響應外界環(huán)境變化，整個監(jiān)控過程由觸發(fā)事件來啟動。觸發(fā)事件來源有很多種，事件可能來自于流程運行所提供的狀態(tài)事件，也可能是應用系統(tǒng)顯式發(fā)出的異步消息。當觸發(fā)事件發(fā)生時，系統(tǒng)啟動業(yè)務績效指標的計算，然后根據(jù)計算結(jié)果選擇是否發(fā)出預警消息。從某種意義上來看，觸發(fā)事件實際上是IT系統(tǒng)執(zhí)行日志的體現(xiàn)。當某些動作發(fā)生時，IT系統(tǒng)顯式的告訴業(yè)務活動監(jiān)控構(gòu)件，系統(tǒng)數(shù)據(jù)已經(jīng)被改變，并且根據(jù)用戶定義的監(jiān)控模型需要采取某些行動。
下圖是對于業(yè)務平均處理時間監(jiān)控指標的建模。從圖中我們可以看出，在流程啟動即第一個活動開始運行時觸發(fā)貸款申請啟動觸發(fā)器，該觸發(fā)器直接啟動了秒表計時。在流程運行結(jié)束時即最后一個活動完成時觸發(fā)貸款申請結(jié)束觸發(fā)器，該觸發(fā)器結(jié)束秒表計時。所以，每一個流程實例都會擁有業(yè)務處理時間。KPI對于所有的業(yè)務處理時間執(zhí)行平均值運算，獲得的就是整個流程的平均業(yè)務處理時間，而且能夠以圖形化的方式顯示給業(yè)務人員。
回頁首面向服務的業(yè)務流程監(jiān)控是一種新型的IT技術(shù)，它以流程為基本監(jiān)控單元，幫助業(yè)務管理人員實時獲悉企業(yè)內(nèi)部運營狀況，分析未來趨勢，挖掘業(yè)務運營風險，從而為創(chuàng)建快速響應的實時企業(yè)奠定良好基礎。本文首先闡述了業(yè)務流程管理的基本概念，然后對于在SOA的環(huán)境下如何構(gòu)造業(yè)務流程管理解決方案作了較為深入的說明，最后結(jié)合銀行貸款流程場景的說明如何構(gòu)造業(yè)務流程管理的解決方案。希望通過本文的介紹，能夠幫助開發(fā)人員深入了解業(yè)務流程管理的基本概念，并為在將來的項目開發(fā)中正確使用相關(guān)技術(shù)做好準備。
