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