| 時間：2004-09-17 作者： 瀏覽次數(shù)： 1377 本文關(guān)鍵字：BPM, 集成, SOA |
|
面向服務(wù)的體系架構(gòu)（Service-oriented architecture，SOA）已經(jīng)成為軟件工程中一個最重要的主題。無疑，隨著Web服務(wù)的推廣和廣泛接受，以及支持基于SOA解決方案開發(fā)的case風(fēng)格的IDE這一新浪潮的興起，SOA已經(jīng)成為構(gòu)建企業(yè)級分布式應(yīng)用程序的首選藍(lán)圖。與此同時，業(yè)務(wù)流程管理（business process management，BPM）作為操作靈活的新企業(yè)并為其建模的主要支持者，正在強(qiáng)力反彈。
面向服務(wù)的體系架構(gòu)（Service-oriented architecture ，SOA）已經(jīng)成為軟件工程中一個最重要的主題。無疑，隨著Web服務(wù)的推廣和廣泛接受，以及支持基于SOA解決方案開發(fā)的case風(fēng)格的IDE這一新浪潮的興起，SOA已經(jīng)成為構(gòu)建企業(yè)級分布式應(yīng)用程序的首選藍(lán)圖。與此同時，業(yè)務(wù)流程管理（business process management ，BPM）作為操作靈活的新企業(yè)并為其建模的主要支持者，正在強(qiáng)力反彈?；A(chǔ)結(jié)構(gòu)廠商已經(jīng)使BPM成為他們出售的系列產(chǎn)品的主要組件，瞄準(zhǔn)機(jī)會的廠商使用專用的BPM系統(tǒng)提供垂直的業(yè)務(wù)解決方案，純使用BPM的廠商正在得到更加廣泛的接受。
盡管兩種趨勢均顯露出了征兆，它們的趨同現(xiàn)象仍不明顯，而且關(guān)于這種現(xiàn)象沒有統(tǒng)一的看法。它們是互補(bǔ)的表示法嗎？它們會重疊嗎？我該如何一起使用它們？這樣做有沒有另外的優(yōu)點？此外，為什么80年代末期的企業(yè)流程重構(gòu)（BP reengineering）失敗了，而第三次BPM浪潮卻將要取得成功呢？
在這一系列三篇文章中，我將解決這些問題。首先，我將討論一個體系架構(gòu)藍(lán)圖的最佳實踐如何將面向服務(wù)體系架構(gòu)與BPM框架合并，從而為構(gòu)建健壯的企業(yè)級集成解決方案并對其建模提供可重復(fù)的方案。我描述了為什么在當(dāng)今，任何使用技術(shù)支持其任務(wù)陳述需要的企業(yè)比以往更能擁有合適的體系架構(gòu)藍(lán)圖。最后，我討論了什么是實時交易的挑戰(zhàn)，以及BPM方法如何能夠?qū)崿F(xiàn)企業(yè)靈活性、智能企業(yè)建模、系統(tǒng)開發(fā)和以客戶為中心的運作優(yōu)點。
在第二篇文章中，我將應(yīng)用BPM技術(shù)來為一個支持“用于汽車保險”業(yè)務(wù)場景的軟件解決方案建模和設(shè)計體系架構(gòu)。我將講述兩種設(shè)計：一種純BPM設(shè)計和一種混合型設(shè)計。我還將講述一些新興的建模工具和標(biāo)準(zhǔn)，并討論一些建模和各種體系架構(gòu)選擇和策略方面的難題。
在第三篇（也是最后一篇）文章中，我將使用BEA的WebLogic Platform 8.1 構(gòu)建一個POC。我將討論BEA的IDE新引入的可視化編程范型及其優(yōu)缺點，和構(gòu)建完全分布式的企業(yè)級應(yīng)用程序所需的一些技術(shù)。我還將解釋，為什么流行的請求/響應(yīng)模式的WEB協(xié)議與基于事件的流程建模，以及它在進(jìn)行架構(gòu)決策時的意義不一致的原因。
體系架構(gòu)模式 —— 誰需要它們?
軟件工程是藝術(shù)還是科學(xué)？在科學(xué)中，我們有明確的定義、定理和證據(jù)。在藝術(shù)中，我們有工具和技術(shù)、趨勢以及最佳實踐?？茖W(xué)中提出了一些假設(shè)，其中一些變成定理，另外一些在經(jīng)過數(shù)個世紀(jì)的研究之后得到驗證，還有一些永遠(yuǎn)沒有答案。在藝術(shù)中，新技術(shù)帶來新的趨勢，比如新聞和數(shù)字?jǐn)z影。如果軟件工程是一門科學(xué)，定義我們在日常業(yè)務(wù)語言中使用的所有術(shù)語不應(yīng)該是一件困難的事情，像服務(wù)、Web服務(wù)、面向服務(wù)的體系架構(gòu)、BPM和BPM系統(tǒng)（BPMS）。的確，我可以利用數(shù)學(xué)精度來證明一個數(shù)據(jù)庫查詢算法的正確性。但是，我能夠以一種干脆、簡潔且通常會被接受的方式來回答，J2EE中的B2B集成是與純.NET Web服務(wù)解決方案相對的正確答案嗎？據(jù)我了解，對于我們中間的一些人來說，這不是問題。最后，任一種常見的貿(mào)易出版物的隨機(jī)調(diào)查指出，每個人都可以給出自己的定義，而有些人甚至質(zhì)疑IT存在的本質(zhì)。我不得不得出結(jié)論，軟件工程仍然是藝術(shù)多于科學(xué)。這正好是我們需要合適的最佳實踐、框架和可重復(fù)過程的原因。
模式封裝了最佳實踐，簡練地定義了域問題，描述了使問題值得關(guān)注的原因，并提出了解決方案。模式并沒有解決獨特的問題。專業(yè)人員結(jié)合各種模式來解決更為復(fù)雜而且有時更為獨特的問題。Christopher Alexander說：“模式同時也是發(fā)生在世界上的事件和告訴我們?nèi)绾蝿?chuàng)建該事件的規(guī)則，以及我們必須創(chuàng)建它的時刻。它既是過程，也是事件。”我回想起我一直以來最喜歡的定義：對象是帶有狀態(tài)或數(shù)據(jù)及行為的數(shù)據(jù)結(jié)構(gòu)。就目前來說，可以把Web服務(wù)看作帶有一個方法的對象。就像BEA WebLogic Platform 8.1所實現(xiàn)的那樣，會話式Web服務(wù)看起來更像是真正的對象：對它進(jìn)行一次初始化，然后一直執(zhí)行方法。萬一您仍然不能肯定Web服務(wù)是粗粒度的對象，考慮：(1) IBM、BEA和 Microsoft宣布了WS-Eventing規(guī)范。它就像是優(yōu)秀但老式的對象觀察者模式。(2) 開放式網(wǎng)格服務(wù)體系架構(gòu)（Open Grid Services Architecture）實現(xiàn)了網(wǎng)格服務(wù)協(xié)議的Web服務(wù)接口繼承。因此，Web服務(wù)提供數(shù)據(jù)和行為（Alexander的定義中的事件和規(guī)則），而BPMS 實現(xiàn)模式的流程組件。SOA是一個用于解決企業(yè)集成和系統(tǒng)開發(fā)問題的體系架構(gòu)模式。
我們已經(jīng)看到，SOA不是體系架構(gòu)趨勢的革命，而是它經(jīng)過一段時間發(fā)展的演變成果。它圍繞為企業(yè)構(gòu)建分布式系統(tǒng)而發(fā)展。誠然，Web服務(wù)以一種普遍接受且無二義性的方式提供底層技術(shù)，以解決系統(tǒng)連接性問題。也許是頭一次，Web服務(wù)成功地解決了互操作性的問題，而這是 CORBA、COM、 DCOM和 RPC 做夢也從未想過的事情。我肯定，作為中立語言，XML對此也準(zhǔn)備一展身手。然而，SOA中包括進(jìn)來的BPMS框架是一個新的、革命性的元素。Howard Smith 和Peter Fingar 描述的第三次浪潮是指一組全新的概念、框架和主流產(chǎn)品。它正在顯著改變企業(yè)轉(zhuǎn)化的方式，從而靈活地管理和運行全局的和協(xié)作的電子商務(wù)實體。
業(yè)務(wù)流程管理的出現(xiàn)已經(jīng)有一段時間，它更多地用于工業(yè)中，而與IT無關(guān)。并發(fā)工程和六西格瑪被開發(fā)用來解決生產(chǎn)和流程改進(jìn)中的及時協(xié)作問題，并且確實取得了相當(dāng)?shù)某晒ΑＨ欢?，?/span>80年代晚期，出于多方面的原因，業(yè)務(wù)流程重構(gòu)管理獲得的成功非常有限。但是最根本的原因是，重構(gòu)是紙上談兵。沒有軟件來支持這樣一個復(fù)雜的任務(wù)。BPM在沒有考慮IT系統(tǒng)的情況下設(shè)計了自適應(yīng)的企業(yè)。正如David Taylor 所寫：
“對連續(xù)性流程優(yōu)化的需要要求從根本上重新考慮如何設(shè)計和構(gòu)建信息系統(tǒng)。提出解決固定問題的固定解決方案已經(jīng)不再夠用。”
信息系統(tǒng)，像它們支持的業(yè)務(wù)模型一樣，必須在本質(zhì)上就是自適應(yīng)的。
Taylor提出一種基于OO的開發(fā)技術(shù)，作為開發(fā)自適應(yīng)IT的一種方法，這種技術(shù)稱為聚合工程（convergent engineering）。然而，OOP無法成功解決分布式計算和企業(yè)集成的問題。另外，負(fù)責(zé)對企業(yè)建模的業(yè)務(wù)分析人員也沒有采用OO。
BPMS將流程建立為用于建模、軟件設(shè)計和運行時執(zhí)行的統(tǒng)一結(jié)構(gòu)。過去，開發(fā)趨勢一直在影響我們對企業(yè)建模的方式。功能式編程使功能需求技術(shù)流行起來。關(guān)系數(shù)據(jù)庫帶來了RDBS分析和設(shè)計的流行。面向?qū)ο蟮木幊虅t為OO分析和用例開發(fā)鋪平了道路。但是在大多數(shù)情況下，業(yè)務(wù)分析人員不會使用開發(fā)專門術(shù)語，因此產(chǎn)生了對需求可跟蹤性中通常影響的另一種翻譯的需要。
BPM規(guī)范正在快速演變?yōu)闃?biāo)準(zhǔn)。市場中已經(jīng)出現(xiàn)了支持業(yè)務(wù)建模、優(yōu)化和運行時執(zhí)行的產(chǎn)品。正如BEA的WebLogic Platform 8.1和其他BPMS產(chǎn)品所實現(xiàn)的那樣，以流程為中心的BPMS 方法用于系統(tǒng)開發(fā)生命周期，它消除了對運行時阻抗不匹配的業(yè)務(wù)需求。
靈活的企業(yè)擁有自適應(yīng)的業(yè)務(wù)和自適應(yīng)的IT系統(tǒng)。如果構(gòu)建企業(yè)解決方案的過程中出現(xiàn)一個新的問題，那么它一定是需求變化的速度。它的速度之快是前所未有的。BPMS引擎添加了一個新的層到傳統(tǒng)的開發(fā)堆棧（參見圖1）中，并引入服務(wù)質(zhì)量來解決企業(yè)集成中的根本問題。BPMS引擎使編程最易變的部分——集成點——的軟布線變得容易。軟布線是以正式語言顯式描述的，并由BPMS引擎（又名有限狀態(tài)機(jī)引擎）執(zhí)行。正如BEA WebLogic Integrator和其他BPMS產(chǎn)品所實現(xiàn)的那樣，業(yè)務(wù)與IT資源可以同時在一個可視化的只能IDE中查看和修改流程。只需輕擊鼠標(biāo)，便可部署到運行時BPMS執(zhí)行引擎。業(yè)務(wù)模擬可以運行，而性能工程可以在系統(tǒng)完成之前完成；這種方式聽起來就像CASE工具。SOA和BPMS工具將靈活企業(yè)的實時執(zhí)行儀表板帶向主流。
在本文余下的部分中，我將描述一個典型的金融服務(wù)企業(yè)的開發(fā)，并提出一條通向基于BPMS的SOA的遷移路徑。該路徑是增量的，但是它需要戰(zhàn)略思考和對未來遠(yuǎn)景的承諾。作為回報，它將允許投資的早期回報，并將遺留企業(yè)轉(zhuǎn)化為完全自適應(yīng)的靈活企業(yè)。
從企業(yè)遠(yuǎn)景到組織筒倉（Silo）
企業(yè)從遠(yuǎn)景開始。CEO和董事會采用遠(yuǎn)景和行業(yè)使命陳述。C級管理人員定義策略，并適當(dāng)?shù)匕才帕鞒虂砉芾韴?zhí)行（參見圖1）。定義功能角色和責(zé)任，然后創(chuàng)建企業(yè)界線。業(yè)務(wù)分類（Line of business，LOB）在本質(zhì)上可以是水平或垂直的（參見圖2）。垂直LOB具有以下特征：
獨立的操作域。
特有的管理和策略。
開發(fā)和維護(hù)自己的IT—自動化孤島。
足夠大以至于可以創(chuàng)建多種業(yè)務(wù)分類；例如，抵押貸款證券、市政公債、貨幣市場，等等
水平LOB具有不同的特征集合：
提供業(yè)務(wù)控制。
管理的支配和一致。
需要訪問由垂直LOB管理的數(shù)據(jù)。
合適的手動流程和書面報告。
在第二個信息紀(jì)元（不要與第二次浪潮混淆）中，我們使用了各種編程技術(shù)來鏈接自動化孤島，從FTP、數(shù)據(jù)庫復(fù)制、EAI和消息收發(fā)開始。此方法產(chǎn)生了一整套新問題：
· 接口的多重性: 一份Morgan Stanley Dean Witter報告表明，通常的金融服務(wù)客戶需要維護(hù)6000個接口，為此每年花費2500萬美元，而且每年還需構(gòu)建900個新的點到點接口，為此需另外花費2500萬美元進(jìn)行構(gòu)建，并且還要花費400萬美元進(jìn)行維護(hù)。
· 調(diào)停流程: 必須在每一個倉庫上實現(xiàn)，需要消耗有價值的時間和昂貴的資源。這是一項常用技術(shù)，用于檢驗由多個實體修改的引用數(shù)據(jù)。
· 流程: 在中間件中進(jìn)行硬布線。在分析過程中捕捉流程所花費的時間和金錢屬于浪費。企業(yè)最重要的資產(chǎn)——流程——隱藏在n(n-1)個意大利面式接口的迷宮中。
· 開發(fā)新的水平流程：需要多個LOB 的協(xié)調(diào)。
· 實現(xiàn)特定和專用的接口：需要專門化和一次性編程。重用消失，維護(hù)方面的投入顯著增加。
· 異常難于跟蹤： 錯誤解析通常需要訪問多個系統(tǒng)。人工干預(yù)和解釋是不可避免的。找尋答案需要花費大量寶貴時間，并對客戶滿意程度和收益性方面的大致情況有著直接影響。
流程無處不在。您能發(fā)現(xiàn)它們嗎？
對于企業(yè)來說，流程可以是客戶層面上的，也可以是內(nèi)部的，或者可以是更大流程的組成部分。我們在同樣的企業(yè)中可以找到內(nèi)部流程。流程通常涉及到人與系統(tǒng)的交互，或者只是系統(tǒng)之間的交互（參見圖3）。交易流程是大規(guī)模流程的一個很好的例子。行政管理部門的交易人員在他的銷售訂單系統(tǒng)中接收一個來自對沖基金管理人員的交易執(zhí)行命令，或者他接到一份傳真或一個電話。交易人員檢查庫存系統(tǒng)的安全性或資金，并借助他的交易對手執(zhí)行交易。可以制造紙質(zhì)入場券，而交易助手可能必須在下行系統(tǒng)中進(jìn)入它。
當(dāng)因為下行系統(tǒng)之一錯誤地再進(jìn)入，而幫助臺分析人員收到一份異常報告時，另一個內(nèi)部流程啟動了。然后，他在內(nèi)部記事薄之一中查找數(shù)據(jù)（原始進(jìn)入記錄），請求來自事務(wù)部門的傳真（我們假定討論的交易超過了結(jié)算日期），而且因為他在兩天內(nèi)沒有收到回復(fù)，也許他會再次重復(fù)同樣的行為。這個流程最終當(dāng)分析人員解決了問題時終止，當(dāng)然，除非他調(diào)到另一個部門或者調(diào)出公司。然后，顧問們必須參與進(jìn)來，跟蹤問題和流程，這通常需要一大筆錢。
每月的客戶聲明是定期性企業(yè)范圍內(nèi)流程的一個傳統(tǒng)例子，通常為水平LOB所特有。在大多數(shù)情況下，客戶在被不同LOB支持的產(chǎn)品中擁有賬號，例如，股票、U.S.證券和外匯。在月末發(fā)送多個聲明將會十分混亂。法律和一致性問題還需要交叉引用多個倉庫的數(shù)據(jù)。Patriot和 Sarbanes-Oxley Acts (一個新的業(yè)務(wù)流程，但是不賺錢)的一個主要問題是要訪問由大量LOB所擁有的數(shù)據(jù)，有時還要環(huán)繞半個世界。EAI技術(shù)和消息收發(fā)試圖借助早先闡明的限制解決這些問題。
通向靈活性的道路：以BPM為中心的SOA
讓我們考慮帶有Web服務(wù)的、以BPM為中心的SOA如何將現(xiàn)有的遺留企業(yè)轉(zhuǎn)換為自適應(yīng)性的企業(yè)。水平流程和異常管理是用于SOA啟用的理想候選者，可以演示可調(diào)整的和速度快的ROI。沒有經(jīng)歷業(yè)務(wù)流程再造的嚴(yán)謹(jǐn)，我們必須定義良好的流程圖。流程圖也是實行業(yè)務(wù)流程重新設(shè)計的第一步。如果使用BPMS 設(shè)計工具(Proactivity, Intalio, Interfacing Technologies)，您可以把度量關(guān)聯(lián)到流程和行為，例如，性能、開銷、IT資源、FTE、逝去的時間、容量，等等。許多BPMS設(shè)計工具允許您運行模擬，并繼續(xù)進(jìn)行流程優(yōu)化（運行what-if場景），但是這并非本文的重點。對于我們的重點來說，以下列出的是良好流程圖的一些特征：
· 考慮流程而不是功能 : 流程告訴您完成什么工作以及如何完成。功能描述誰在哪里來完成它。
· 從客戶的觀點出發(fā)： 考慮從外部業(yè)務(wù)事件開始的流程，例如，一次交易、一份訂單、一個主張、一個報價請求。
· 在更寬泛的意義上并基于不同的服務(wù)質(zhì)量來劃分客戶類別： 您生態(tài)系統(tǒng)中的性能、供應(yīng)商、業(yè)務(wù)伙伴。
· 流程反映狀態(tài)變化：交易訂單、現(xiàn)金支付。從可管理的流程數(shù)量6－10開始。記住，大多數(shù)人最多只能保留一個頁面上的七樣?xùn)|西。
· 定義核心流程和子流程：這里沒有科學(xué)理論，只有最佳實踐。然而，要當(dāng)心P-calculus2 和Petri-nets；它們將在接下來的10年內(nèi)帶給BPM科學(xué)的嚴(yán)密性。
· 將流程分解為行為
下一個目標(biāo)是通過分解行為來定義小單元。我們將這項工作稱為Elementary Business Services (EBS)。如果您從多維矢量代數(shù)開始回想，空間中的任意一點都可以被定義為單元矢量的線形組合。在我們的例子中，我們以可以通過編排EBS子集來構(gòu)造任何流程的方式定義了所有EBS。正如您可能猜想的那樣，我們將EBS實現(xiàn)為Web服務(wù)。識別EBS的正確集合和粒度水平很重要。這與設(shè)計對象的重要程度相同。相同的規(guī)則和技術(shù)——封裝、狀態(tài)相關(guān)性、內(nèi)聚性、松散耦合和重構(gòu)——同樣適用，這并不使人驚奇。
EBS的業(yè)務(wù)量體現(xiàn)出了大量實際優(yōu)點：
1. 它是要重用的最終指南。可以通過任何想像得到的方式編排EBS，以形成新的LOB。
2. 連續(xù)性流程改進(jìn)不必等到IT適應(yīng)新的業(yè)務(wù)模型。
3. EBS對企業(yè)生態(tài)系統(tǒng)中的企業(yè)和業(yè)務(wù)伙伴可用。
4. 放棄使用一個系統(tǒng)并不是一個一蹴而就的過程，而是一個循序漸進(jìn)的過程。
5. 可以以一種易于管理且性價比高的方式合并和獲得IT。
6. 可以幾乎實時地設(shè)計和執(zhí)行一個新的業(yè)務(wù)流程。
從圖4中可以看出，我們可以使EBS在BEA WebLogic Platform 8.1（集成組件）的一個實例中可用。從技術(shù)上說，在BEA WebLogic Integration中，Web服務(wù)被稱為業(yè)務(wù)流程資源。我們使用IDE編排新流程，使用門戶添加UI，然后將它部署為一組EJB來執(zhí)行。就是這么簡單！現(xiàn)在流程是一項IT資產(chǎn)了，就像數(shù)據(jù)庫表、存儲過程、遺留COBOL書籍和專用的計算c庫。
許多金融服務(wù)機(jī)構(gòu)的業(yè)務(wù)分類是水平的，管理高凈值的私有客戶。在啟用了BPMS SOA的企業(yè)中，開發(fā)IT基礎(chǔ)結(jié)構(gòu)來支持這樣的新LOB完全可以與正確放置業(yè)務(wù)模型并行完成（參見圖5）
考慮Amazon.com 現(xiàn)象，它們并沒有創(chuàng)造任何新的EBS。所有EBS位于任何其他郵件訂單一覽表書店中的恰當(dāng)位置：定購書籍，檢查庫存，信用卡付帳，打印聲明，準(zhǔn)備裝運，給客戶發(fā)送電子郵件。但是它沒有創(chuàng)建新流程，沒有質(zhì)疑已經(jīng)建立好的流程，甚至不用花費什么力氣。
正如Howard Smith 和 Peter Fingar所說的那樣：“在BPM的第三次浪潮中，筒倉式思考和點到點的技術(shù)集成被靈活的、基于業(yè)務(wù)流程的體系架構(gòu)所代替。”此外，Gartner Group 現(xiàn)在聲明，繼續(xù)將業(yè)務(wù)邏輯硬布線到軟件或中間件中或者堅持人工步驟的公司將輸給部署流程管理體系架構(gòu)的競爭對手。
實時處理業(yè)務(wù)
退一步說，預(yù)測將來是很困難的事情，但是我們用非?？茖W(xué)的態(tài)度對待它，而且始終試著這么做，不管對還是錯。統(tǒng)計和預(yù)測是關(guān)于預(yù)測將來的兩門科學(xué)。投資組合評估和保險統(tǒng)計研究是有關(guān)預(yù)測的科學(xué)。實際上，我們的預(yù)測僅僅基于我們已經(jīng)經(jīng)歷過的、過去的性能和趨勢。實時處理業(yè)務(wù)需要預(yù)測未來的業(yè)務(wù)情況。然而，基本的業(yè)務(wù)協(xié)議和框架必須合適。今天，技術(shù)革新、BPMS和SOA是將業(yè)務(wù)目標(biāo)與IT相結(jié)合的基礎(chǔ)。流程提供一個封裝了變化的新層。90年代早期，PowerBuilder和VB風(fēng)格的工具使客戶端/服務(wù)器和關(guān)系數(shù)據(jù)庫系統(tǒng)的開發(fā)流行開來，通過與此相同的方式，BPMS引擎將在未來建立流程驅(qū)動的企業(yè)。事實上我預(yù)測，在我們的一生中，我們將看到對運行時流程的需求，該類流程用于實時變化或?qū)ψ孕薷牧鞒痰男枰?。無疑，人類希望能夠掌管該類變化，但是通過使用UDDI-š (š 代表流程)找出最可能的服務(wù)契約和使用描述域?qū)I(yè)知識和市場情況的規(guī)則進(jìn)行決策，BMPS能夠使這項工作更加容易。隨著BPMS的普及，靈活性將被極端自適應(yīng)所代替。
結(jié)束語
在本文中，我描繪了合并SOA和BPM的藍(lán)圖。從一幅企業(yè)的自頂向下流程圖開始，我們定義了基本業(yè)務(wù)服務(wù)的組合選擇。垂直LOB擁有并部署EBS。Web服務(wù)實現(xiàn)它們，并使它們對企業(yè)可用。通過使用BPMS引擎的一個實例，可以設(shè)計、開發(fā)、測試新的流程，并通過結(jié)合現(xiàn)有的EBS，在數(shù)日內(nèi)添加業(yè)務(wù)值。
在我的下一篇文章中，我將：(1) 講述用于給現(xiàn)實世界業(yè)務(wù)保險流程建模的BPM技術(shù)，并提出一個純BPM解決方案和一個混合解決方案；(2) 使用Web服務(wù)和JMS連接設(shè)計EBS并實現(xiàn)它們；(3) 提出一個使用WebLogic Platform 8.1的物理基礎(chǔ)結(jié)構(gòu)；并 (4)討論面向服務(wù)體系架構(gòu)中的BPMS難題和新出現(xiàn)的模式。
直到：流程無處不在。您能發(fā)現(xiàn)它們嗎？
參考資料
· Carr, Nicholas G. (May 2003). "IT doesn‘t Matter". Harvard Business Review.
· Alexander, Christopher. (1979). The Timeless Way of Building. Harvard University Press.
· Gamma,E.; Helm, R.; Johnson, R.; Vlissides,J. (1995) Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
· Smith, Howard, and Fingar, Peter. (2003). Business Process Management: The Third Wave. Meghan-Kiffer Press.
· Shina, Sammy. (1991). Concurrent Engineering and Design for Manufacturing of Electronics Products. Van Nostrand Reinhold.
· Pande, Peter S., et al (2000). The Six Sigma Way. McGraw-Hill Trade.
· Taylor, David A. (1992). Business Engineering with Object Technology. John Wiley & Sons, Inc.
· Morgan Stanley Dean Witter, (April 2000). "The B2B Internet Report".
· Gartner Group (November 2001). "Business Process Management - Are you experienced?"
