評論專欄: 為執行建模，再論

簡介： 為執行建模技術已經被廣泛地應用於業務流程管理（BPM）解決方案的設計。本文突出了在如何將這個概念應用於成功的 BPM 專案交付方面的一些發展。 本文來自於 IBM WebSphere Developer Technical Journal 中文版。

為執行建模 & BPM

在 2008 年的一篇關於 IBM® WebSphere® 業務流程管理工具的 文章 中曾討論過為執行而建模的方法。在 2009 年的一篇 後續文章中 討論了 IBM 的 BPM 堆疊產品 V6.2 版本的改進，這些產品簡化了為執行建模的流程。現在到了 2010 年，由於我們已經在這個領域有了一些實際的實現體驗，另外業務流程管理方面也出現了一些新的工業標準，因此現在是時候來再次討論一下這個主題了。

什麼是為執行建模？

為執行建模並不是一個新概念，因為這種方式已經在傳統的軟體和系統開發中被用了有一些時間了。它總是開始於一個用某種可視語言表達的高階平臺獨立模型（PIM）。這個模型然後會被以一種針對特定平臺的特定的程式語言翻譯或轉換為一個特定於平臺的模型（PSM），然後才可被編譯後執行。實際上，這個方法使用了 Object Management Group (OMG) 的 Model Driven Architecture (MDA) 的原理。圖 1 顯示了這兩個模型之間的關係。

圖 1. 模型轉換

這個受模型驅動的架構開始於我們熟知的並且是長期建立起來的將系統的運轉與該系統如何使用其平臺功能的細節分離開來的想法。MDA 的三個首要目標就是通過關注點的架構分離的可移植性、互操作性和可重用性。

BPM 解決方案交付是一種新的受業務驅動和以流程為中心的交付應用程式的方法。它能夠也應該使用在過去十幾年間的軟體開發和系統工程中所積累的最佳實踐。MDA 原理當然也可以應用在這裡，但由於 MPM 解決方案交付比較獨特，因為它更強調可重複的業務設計並需要業務使用者和分析人員更多的參與，因此在採用為執行而建模技術時需要加以特別的考慮。

很多公司均已經為基於 WebSphere BPM 產品套件的解決方案交付使用了為執行而建模的方法和技巧。圖 2 顯示了從業務模型轉換為技術業務模型再到實現模型的典型轉換。

圖 2. 從業務模型到實現模型

圖 2 顯示了這三個階段:

• 一個業務分析員或業務流程架構師在 Basic 或 Advanced 模式下在 IBM WebSphere Business Modeler 中建立一個業務模型。這個業務模型圖形化地顯示了業務流程並使用了與業務分析員和主題專家相關的語義。這個業務模型也可被用於模擬。
• 一個技術業務分析員或技術流程架構師在 IBM WebSphere Process Server 模式下優化此模型，生成一個技術業務模型來圖形化地給出業務流程並開始將業務語義翻譯成技術語義。技術業務分析師從 WebSphere Business Modeler 作為一個專案交換檔案匯出技術業務模型，這個檔案的格式為 .zip，內含組成這個實現模型的所有執行時工件。
• 一個流程架構師或整合開發人員將這個實現模型匯入到 IBM WebSphere Integration Developer。 這個實現模型圖形化地給出要實現的業務流程。整合開發人員可進一步完善這個模型並完成從業務語義到技術語義的翻譯。

這裡有一點非常重要，需要注意，即雖然是工作在 WebSphere Business Modeler 內，但底層的那些模型還是表示為一個特定於 Modeler 的 BOM（業務物件模型）流程模型。當作為一個專案交換檔案匯出模型時，這些 BOM 流程模型就會被轉換為 BPEL 流程模型，而這正是您在 WebSphere Integration Developer 內處理的語義。

使用者在使用為執行建模的方式交付 WebSphere BPM 解決方案方面有了一些成功經驗，尤其是在再物件導向和以整合為中心的流程領域。而它的實現是通過使用 BPEL 作為轉換自業務流程模型的底層特定於平臺的模型（PSM）獲得。 BPEL 是一種開放的行業標準，也是一種經過驗證的流程編排語言，並特別側重於 Web 服務整合。現在，很多公司都具有基於 BPEL 的關鍵流程應用程式在生產中執行，提供了所需的事務整體性、安全性和效能。

雖然就執行時而言，目前的 WebSphere 的為執行建模提供了強壯的解決方案，但是在開發流程方面仍有改進的空間，尤其是在迭代開發的模型同步領域。

圖 3 給出了在目前的工具條件下這個情況是如何處理的。

圖 3. 用 WebSphere BPM 工具進行的迭代開發流程

如您所見，這個流程可能會相當複雜，並且會涉及幾個手動步驟，而手動步驟很容易發生錯誤。實際的使用者體驗也表明這種方式對於經常需要進行更改的情況將非常有挑戰性，這就是廣為人知的 “roundtriping” 問題。當然，這個問題並不是 WebSphere BPM 堆疊獨有的。只要您在具有不同語義的不同領域間進行模型轉換，模型同步都將是一個挑戰。

於是出現了為執行建模的一些最佳實踐。一種是在 WebSphere Integration Developer 內減少對代表著業務模型的業務邏輯模組的更改。由於業務邏輯模組內的元素直接與 WebSphere Business Modeler 內的元素對映，所以應該在 WebSphere Business Modeler 內做更改。尤其應該減少對流程的結構性更改。

像這樣的建議對於減少模型同步的需要可能會有所幫助，但是它們並不能完全消除這種需求，而這就為我們帶來了另一種方式。

Lombardi Software 是 BPM 軟體和服務的領先提供商，該公司於今年年初被 IBM 收購，它對為執行建模有著自己獨特的見解，因為它會在流程的整個生命週期都保持此模型具有相同的格式。圖 4 給出了 Lombardi Teamworks BPM 套件的架構。

圖 4. Lombardi Teamworks 為執行建模的方式

如上所示，在 Teamworks 內定義的所有流程元素均儲存在一個單一的 Shared Model 中，用以表示流程內的每個元素，從流程圖到業務資料、使用者介面和系統整合。藉助 Shared Model 架構，在一個流程元素內所作的更改會（根據訪問許可權）立即可見並可由其他流程元素訪問。這就使得流程元素之間的依賴性一目瞭然，也就讓流程設計者能夠進行更好的交流並有助於流程質量的提高。

那麼，為什麼這一點對於為執行建模如此重要呢？因為業務建模者和開發者（如圖 4 所示）處理的是相同的共享底層流程模型 —— 只是從不同的檢視和透檢視 ——- 此模型永遠不會不同步，並且 roundtripping 問題也沒有了！這個範型會激勵更為迭代和敏捷的開發，業務管理者和 IT 部門也會有更緊密的協作。

現在，對於為執行建模我們有了兩種策略：

• 轉換模型以實現優化的執行時行為。
• 跨流程生命週期共享模型。

哪個更好？答案仍要依賴於您實現的是哪種業務流程以及哪些因素對您最為重要，比如是對敏捷和迭代開發的支援，還是對 round-trip 的支援，又抑或是執行時健壯性、持續流程改善、鼓勵業務/IT 協作的簡單易用性，等等。

希望這些資訊能夠幫助您在為您特定的需求選擇正確的方法和工具時擴充套件您的思維和決策過程。

原文連結:http://www.ibm.com/developerworks/cn/websphere/techjournal/1004_col_xu/1004_col_xu.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-669854/，如需轉載，請註明出處，否則將追究法律責任。