根據工作流產品在運行時刻與業務應用系統的關系,可以將國內市場上的工作流軟件產品分為嵌入式和獨立運行兩大類。本文希望通過分析這兩類工作流產品的各自特點,為選擇工作流產品的用戶提供一些參考。
          因為工作流軟件一般應用在電子政務、企業辦公和管理軟件上,同時在這些領域使用J2EE架構已是一種趨勢,所以本文只著重于介紹基于J2EE技術實現的工作流引擎
          嵌入式工作流引擎
           
          在部署上,嵌入式工作流引擎是不能單獨運行的,它是以一個軟件組件(或者說構件)的形式運行在使用它的業務應用中。因為工作流技術主要是解決復雜業務流程靈活定制和方便更改的問題,因此在應用邏輯層次上,我們可以把嵌入式工作流引擎看作是業務邏輯層的一部分。
          在與業務應用的交互方式上,嵌入式工作流引擎通過提供WAPI(Workflow API)為展現層或業務邏輯層的其他部分提供服務(如啟動指定工作流程、查詢工作任務、設置流程運行業務數據)。另一方面,工作流引擎經常需要業務相關的數據或邏輯來決定流程流轉,或者需要在不同任務之間傳遞業務數據,這時候,流程引擎會調用業務應用中業務邏輯或數據訪問模塊提供的API接口來完成相應操作。
          獨立運行工作流引擎
           
          獨立運行工作流引擎本身就是一個單獨的應用。作為服務應用如果又沒有基于某個中間件技術的話,獨立運行工作流引擎必須自己實現多線程同步、網路通訊處理、資源池等服務端技術,因此實現的成本高、技術復雜。
          在與業務應用的交互方式上,獨立運行工作流引擎會以遠過程調用的方式提供WAPI(Workflow API)。對于使用Java技術的獨立運行工作流引擎,遠過程調用方式可以是RMI、JMS,或者能夠跨越異構系統的Web Service。
          另外,獨立運行工作流引擎也必須為反過來如何調用業務應用提供解決辦法。一般情況下,獨立運行工作流引擎應該能夠直接調用外部業務應用提供的遠程接口(如基于RMI、JMS或者Web Service的業務接口),另一方面,業務應用也必須為獨立運行工作流引擎提供遠過程調用業務方法。
          當然也有省事而走捷徑的方法,比如國內市場占有率比較高的一款Java獨立運行工作流產品,雖然提供了基于RMI/JMS的WAPI,卻沒有提供工作流引擎直接調用外部業務遠程接口的方法。如果要讓工作流引擎調用外部業務邏輯,你必須編寫一個實現廠商特有接口的Java類,然后將它上傳并注冊到工作流引擎中。
           
          像上圖這種方式是可以解決實際業務問題(你自己編寫的java類可以做任何事情,比如遠程調用或者訪問數據庫)。但很明顯,本來很多不該二次開發做的工作現在必須在二次開發時做了。同時,業務應用邏輯分散在多個應用(你的應用和工作流引擎)中并且某些業務應用邏輯(上傳到引擎的Java類)反過來要依賴廠家的接口,這些都是良好的架構設計要避免的情況。一旦系統后期要做一些變動就會帶來很大麻煩。
          對比
          下面我們就部署、二次開發的難易程度、性能、是否支持分布和EAI,對這兩類工作流引擎做一個對比。
          1、部署: 對于一個基于Java技術的嵌入式工作流引擎,在部署時非常簡單,你只要將對應的jar文件加到classpath中就可以了。獨立運行工作流引擎因為是獨立的應用,并且必須通過RMI/JMS/Web service等遠程調用技術與業務應用交互,所以部署起來要麻煩得多;
          2、二次開發: 由于大部分獨立運行工作流引擎也會在客戶端,提供方便遠程調用的本地調用API,所以在二次開發時,程序員大部分時間都可以不大關注引擎是本地的還是遠程的。但在傳遞某些業務參數和例外處理中,遠程調用還是有些特殊的要求和限制的。因此總的來說,在二次開發上獨立運行工作流引擎對程序員要求高一些;
          3、性能:毫無疑問,因為沒有遠過程調用,嵌入式工作流引擎要占明顯優勢;
          4、分布和EAI:獨立運行工作流引擎能夠和多個業務系統打交道,嵌入式工作流不能直接和宿主系統以外的系統交互。因此只有獨立運行工作流引擎支持分布式應用,和支持通過業務流程做企業應用集成(EAI)。
          如何選擇
          通過上面的對比已經很清楚了。如果你需要工作流程在多個系統中流轉,那么選擇獨立運行工作流引擎。在其他情況下,選擇嵌入式工作流引擎。
          同時,即使你因為分布或EAI而準備選擇獨立運行工作流引擎,你也應當選擇在業務與引擎兩個調用方向上,都直接支持遠過程調用的工作流產品。如果獨立運行工作流引擎在某個調用方向上(比如回調業務應用)沒有提供方法,需要用戶在二次開發時自己解決,這種情況下請選擇嵌入式工作流引擎。
          發展方向
          一般國內獨立運行工作流產品歷史會比較長,大部分是在7-8年前開始立項開發的,那時候正是分布式應用理論最火熱的時候。可隨著人們在實踐中的經驗教訓和積累,發現很多情況下我們不需要復雜的分布式應用。這也是近幾年來在Java世界里,許多人提倡“輕量級”、“no-EJB”的原因。
          事實上,嵌入式工作流引擎經過一定的擴展也能夠處理跨系統的流程交互:
           
          在上圖中,新的嵌入式工作流引擎通過附加工具能夠為外部業務接口(不管是RIM/JMS/Web Service)自動生成適配器(Adapter)供引擎使用,另外引擎會對外提供遠程WAPI(包括客戶端適配器)。具備了遠程交互能力的嵌入式引擎仍然可以作為組件在主要的業務應用中使用,從而使得大部分業務邏輯和引擎之間的交互為本地調用,不會造成性能的損失。
          國際著名工作流專家Michael zur Muehlen 在其 “Workflow-based Process Controlling”一書中談到:“在上個世紀80-90年代,大部分工作流應用采用第一種應用方式(獨立)。現在,對于包含復雜流程的應用系統,許多軟件提供商重新定位和設計它們的工作流產品,使其成為應用系統的構件模塊(即嵌入式)”。你的看法呢?

          posts - 57, comments - 3, trackbacks - 0, articles - 1

          Copyright © 黎民

          主站蜘蛛池模板: 绥德县| 新宾| 鹤庆县| 鄂温| 孙吴县| 蛟河市| 丰顺县| 婺源县| 淮阳县| 建宁县| 长子县| 木里| 梧州市| 济南市| 乌兰浩特市| 常熟市| 巩留县| 苍梧县| 互助| 文山县| 响水县| 威海市| 津南区| 通化县| 赤壁市| 蒲江县| 景谷| 襄汾县| 安庆市| 商丘市| 富蕴县| 威信县| 洛浦县| 扶风县| 甘孜| 水城县| 竹山县| 依安县| 南涧| 海南省| 孙吴县|