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