SOA和BPM結合的三種方法[1]

SOA和BPM結合的三種方法[1]

作者：rathink_bpm　來源：CSDN博客

　　在SOA和BPM聯合發展的浪潮下，我們首先要明確的是，BPM與SOA的本質是截然不同的:SOA是一種架構方法，BPM則是一組流程協調管理理念。沒有SOA之前，BPM產品已經出現并成功應用。BPM的主要應用場合有如下幾點：

　　1.業務流程自動化。這是業務流程自動化(BPA)的概念，BPA按照業務需求自動化流程，這是現在工作流技術還在繼續做的事情。

　　2.整合應用系統，實現異構系統之間無縫交流。這涉及到EAI的概念，不過實現方法和老的EAI技術是完全不同的。

　　3.企業流程建模分析。這是BPM的核心，在詳細了解企業流程劃分之后，用全局的視角，對流程進行梳理，并給出企業流程全局圖。

　　4.監控企業活動，實現企業流程持續改進。這是業務活動監控(BAM)的功能，BAM需要用前面的企業流程全局圖，分析企業流程效果和效率，提供優化方向，實現企業級的流程管理。

　　在上面描述的BPM的四大應用場合中，每個都和SOA有千絲萬縷的聯系。從技術層面看，SOA和BPM結合有多種方法,SCA的WS-BPEL客戶端和實現模型規范說明了WS-BPEL2.0怎么樣和SCA結合在一起使用，具體方法有如下三種。

　　BPEL流程作為構件的實現

　　在SCA中，可以把一個有效的BPEL流程作為一個構件的實現。對于一個構件的定義來說，可以使用子元素來表示本構件是用一個BPEL流程來實現的。子元素的process屬性指明了這個可執行的BPEL流程的目標名稱。

　　這個方法是從BPEL開始的。先定義好一個BPEL流程，然后把它納入到SCA容器中去

　　BPEL定義構件的類型

　　當一個構件使用了一個BPEL流程定義的構件來實現的時候，BPEL流程定義也決定了這個構件的類型。如果一個構件類型只使用WSDL接口來定義服務和引用，我們可以用BPEL來得到這樣的構件類型。這點可以通過“反射”機制來實現。

　　BPEL中的合作伙伴鏈接對應于SCA中的服務和引用。在SCA中，服務和引用的區別是在一次會話中，哪一方第一次發起通信;而在BPEL中，合作伙伴鏈接是不關心誰是會話的發起者的。所以，為了在BPEL流程和構件類型中做一個映射，必須找到一個辦法鑒別出會話的發起人。在BPEL中，一個合作伙伴鏈接要想發起一個會話有如下可能：在活動中接收一個消息，在活動的子元素中接收一個消息，在一個事件處理器的子元素中接收一個消息。在上述情況下，應該把合作伙伴鏈接映射為SCA中的服務，反之則映射為SCA中的引用。

　　如果合作伙伴鏈接映射為SCA中的服務，那么服務的類型就對應于BPEL中的合作伙伴鏈接類型，如果合作伙伴鏈接映射為SCA中的引用，就和服務的情況相反。服務構件的服務是可以有WSDL PortType接口的。

　　為BPEL加入SCA擴展

　　我們可以在BPEL中加入SCA擴展，從而產生SCA的構件類型定義，并利用它來完成SOA的裝配。例如，一個BPEL的變量聲明可以包含一個SCA的擴展，這樣的擴展表明，這個變量代表了一個SCA構件的屬性。

　　從上面的討論看出，BPM和SOA結合的方法可以幫助BPM實現更多的功能。在SOA環境下的BPM與非SOA環境下的舊式工作流相比有如下的不同：

　　1.跨組織的業務流程描述語言和工具。在工作流系統上馬早期，經常會發現同一個企業內部不同組織單元、部門的流程采用不同的描述方法，比如A/B/C/F四個部門的賬目管理系統采用某種工作流系統，而A/B/D/E四個部門的訂單和銷售管理系統又采用另外一種工作流系統。這種情況在大型企業集團內部尤為明顯，影響了各業務單元的業務協同和業務最佳實踐的提煉和推廣。而BPM致力于跨組織的業務流程描述語言和工具，避免了企業各部門進行業務流程交流和溝通時各說各話的情況。

　　2.統一的流程架構。企業內部從單一管理主題出發進行設計的工作流，通常在企業中缺乏對業務運營活動的總體考慮，局限于本部門或者本業務的業務需求，各部門和各管理專題之間的流程無法銜接，信息的共享和傳遞困難，存在大量流程斷點。而BPM在流程之間進行銜接、協調，避免了流程孤島的產生。BPM的目標是形成端到端的流程體系，提高整個業務流程運行的效率、成本、質量，在激烈的市場競爭環境下，滿足客戶的需求。

原文轉自：http://www.anti-gravitydesign.com