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