第一篇：移動應急平臺集成

移動應急平臺集成移動應急平臺滿足移動現(xiàn)場音視頻采集、現(xiàn)場通信和指揮調度等應急處置需要，包括移動數(shù)據(jù)庫、移動應用軟件以及通信設備，能夠與國務院、部門和省級等相關應急平臺互聯(lián)互通。

移動平臺應提供傳輸信道，保證移動平臺附近的固定長多接入視頻會議。既滿足“靜中通”，也滿足“動中通”。

5.9.1、移動應急平臺建設目的移動應急平臺的建設首先服務于兩個基礎目的：

? 現(xiàn)場通信調度服務：

提供事發(fā)現(xiàn)場和附近的現(xiàn)場通信和調度服務，滿足現(xiàn)場溝通和指揮的需要 ? 打通前后端信息傳輸通道：

? 提供前端事發(fā)現(xiàn)場和后端指揮中心之間的信息傳輸通道，上傳現(xiàn)場視頻信息，承接指揮中心的指令和相關信息推送

? 其次，移動應急平臺，尤其是大中型應急平臺還要充當“現(xiàn)場指揮部”的功能，除了基礎通信和指揮調度功能外，還能夠提供應急數(shù)據(jù)查詢分析，應急業(yè)務調用等功能，甚至可以具備提供現(xiàn)場小型會議場所的功能。

5.9.2、XX省政府移動急平臺建設內容

目前XX省政府移動應急平臺建設規(guī)劃建設X套中型移動應急平臺和X套小型移動應急平臺。其中，小型移動應急平臺包含：

? VSAT小型移動平臺（含VSAT便攜站、話音設備、視頻接入、加密設備）

? BGAN小型移動平臺（含BGAN便攜站、加密設備）

? 終端和安全設備（含加密PDA、加密手機、衛(wèi)星移動電話、便攜電腦及應用、安全配件）

第二篇：盛傳移動商務信息平臺

盛傳移動商務信息平臺

簡介及應用鴻程企業(yè)管理咨詢有限公司地址:寧波海曙區(qū)靈橋廣場5樓D03李經理近年來，美發(fā)行業(yè)發(fā)生了翻天覆地的變化，很多企業(yè)在經歷過最初的創(chuàng)業(yè)階段之后開始走向成熟。整個行業(yè)產值高速增長，并且逐步成為就業(yè)人數(shù)最多的勞動密集型行業(yè)之一。目前，國內美發(fā)行業(yè)已經走上了規(guī)?；l(fā)展的道路。在當前信息化高度發(fā)達的社會中，企業(yè)之間的競爭已經從原來原始單一的產品規(guī)模的競爭轉化到了復雜多樣化的經營管理包括：產品品牌，服務質量，人才，客源的開發(fā)和維護，成本的控制等等，以及企業(yè)文化建設，信息等等諸多方面的競爭。其中又以管理競爭為重中之重。美發(fā)行業(yè)的規(guī)?；瘓F化的發(fā)展已經成為一個必然趨勢。整個行業(yè)出現(xiàn)了眾多品牌林立，良莠不齊的局面競爭空前激烈。好比一場規(guī)模浩大的馬拉松角逐，誰能夠跑在前面，關鍵是依賴自身的實力。在同樣的規(guī)模，同樣的市場，同樣的產品，同樣的人員，同樣的資金下，管理思想與管理方式就成為實力區(qū)別的根本所在。一個有著好的管理思想，管理模式的美發(fā)店，即使規(guī)模小，卻可以在很短的時間內發(fā)展壯大。反之，有些已經達到一定規(guī)模的企業(yè)，由于管理跟不上發(fā)展的步伐，不得不停止發(fā)展甚至縮小規(guī)模，這種現(xiàn)象在我們身邊比比皆是。管理已經成為美容美發(fā)行業(yè)發(fā)展的關鍵因素。隨著整個行業(yè)向著規(guī)范化發(fā)展的道路邁進，美發(fā)行業(yè)管理軟件也應運而生，成為與美發(fā)行業(yè)共同發(fā)展，協(xié)助這個行業(yè)邁向更高層面的重要支柱之一。1.員工沒有積極性、自由散漫、難于管理，服務質量不能提高，客戶滿意度低 2.好不容易把員工從一

個生手培養(yǎng)成熟練工，員工卻要離職，人員流失率非常高 3.庫存產品被大量的消耗，卻不知如何被消耗，成本黑洞嚴重吞噬營業(yè)利潤 4.客戶沒有被持續(xù)性積累，好不容易吸引來了新客戶，老客戶卻在悄悄的流失 5.營銷策略單一，沒有核心競爭力，營銷活動往往只會拷貝別人的模式，沒有獨創(chuàng)性 6.對各種營銷活動缺乏科學的判斷和考量，無從知曉營銷活動的有效性 7.管理模式粗放，決策往往是管理者拍主觀決定，缺乏大量詳實的報表統(tǒng)計分析 8.經營管理缺乏科學依據(jù)，往往拷貝其他店的管理模式，沒有形成適合的管理方式。1.會員在各門店間無法實現(xiàn)跨店消費、跨店儲值、跨店查詢等，給會員帶來麻煩的同時，降低了會員對企業(yè)的忠誠度 3.產品的調撥分配沒有科學的工具，在統(tǒng)計庫存數(shù)據(jù)時耗費大量人力 5.無法及時獲得各門店營業(yè)的第一手數(shù)據(jù)，人工統(tǒng)計的數(shù)據(jù)存在一定虛假，給企業(yè)經營帶來隱藏的巨大風險 7.原有的收銀軟件無法支持不斷擴張的企業(yè)規(guī)模，數(shù)據(jù)傳輸非常慢，同時容易出現(xiàn)錯誤，導致結帳時間過長，會員卡金額出錯等問題，給企業(yè)發(fā)展造成嚴重阻礙5.無法及時匯總各店的營業(yè)數(shù)據(jù)，會員數(shù)據(jù)，人事數(shù)據(jù)，庫存數(shù)據(jù)等信息，企業(yè)決策變成空中樓閣，且決策周期過長?；谝陨现T多問題的存在，美發(fā)行業(yè)的管理者迫切地需要學習先進管理思想、管理模式，幫助他們解決管理中的瓶頸，且能夠幫助解決經營管理中的各種實際問題，使經營管理變得高效、科學。吸引一個新客戶所耗費的成本大約相當于保持一個現(xiàn)有客戶的5倍?！?－ 摘自《營銷管理》第9版 美 菲利普·考特勒 會員制客戶管理模式，是店家為了維系與客戶的長期交易關系，而發(fā)展出的一種較為成功的關系營銷模式。會員卡是這種營銷模式的載體。在具體實踐中，會員卡根據(jù)客戶管理模式和促銷方式的不同，可分為折扣卡、記帳卡、儲值卡等類型。其中，以儲值卡和折扣卡最為店家喜愛，因為它所代表的關系鏈最牢固，能為商戶鎖定大量的老顧客。但在具體操作過程中，由于需要處理大量的客戶信息、交易信息和資金流動，人工操作費時費力，差錯頻繁。為了加快信息處理速度，縮短交易的認證時間和避免差錯，快速統(tǒng)計店內經營數(shù)據(jù)并通過分析統(tǒng)計數(shù)據(jù)找出店內存在的問題，計算機信息處理技術的應用勢在必行。為了讓現(xiàn)有的客戶不流失，同時能不斷發(fā)展新的客戶群體，與客戶保持良好的溝通至關重要。但這恰恰是很多店家感到頭疼的一個問題。在手機和網(wǎng)絡日益普及的今天，通過短信和網(wǎng)絡保持與客戶的互動溝通是解決這一問題的最佳方法，盛傳移動商戶信息平臺就是應這樣的需求而開發(fā)的。盛傳移動商務信息平臺是深圳盛傳科技有限公司為專業(yè)美發(fā)行業(yè)量身定做的一套功能強大的商務信息化管理系統(tǒng)。系統(tǒng)以互聯(lián)網(wǎng)作為支撐載體IE瀏覽器訪問，將客戶管理、短信群發(fā)、顧客消費收銀、會員消費后卡內余額短信提醒、消費三天后短信自動回訪、員工信息管理、員工考勤管理、庫存管理、員工業(yè)績統(tǒng)計、店內業(yè)績統(tǒng)計、手機查詢業(yè)績等功能模塊緊密結合起來，并采用科學的由連鎖總部統(tǒng)一管理各分店的模式，給連鎖商戶提供非常好的支持。操作簡單方便，界面美觀大方，能幫助經營者擺脫繁瑣的手工操作，更有效的管理店內日常事務?？茖W的管理方法會給您帶來無限的效益，盛傳能帶給您的不僅僅是數(shù)據(jù)統(tǒng)計，還有全新的顧客消費

體驗與顧客服務方式，全面提升店家的形象和檔次。店務版客戶管理添加客戶資料會員刷卡消費會員資料管理批量導入客戶客戶資料恢復短信平臺短信自定義發(fā)送短信群發(fā)會員生日提醒短信回訪設置未發(fā)送短信短信發(fā)送記錄短信回復記錄短信發(fā)送統(tǒng)計運行記錄項目消費記錄員工服務記錄賣品銷售記錄會員充值記錄員工開卡記錄項目銷單記錄賣品銷單記錄充值銷單記錄水單審查系統(tǒng)設置會員卡設置服務項目設置員工級別設置開支類型設置商品類型設置會員卡積分規(guī)則優(yōu)惠券設置會員分類設置積分兌獎設置生日自動提醒系統(tǒng)管理管理員管理管理員權限短信充值記錄系統(tǒng)操作日志日常開支管理員工管理員工管理員工組管理恢復刪除員工考勤班次設定考勤刷卡當天考勤記錄員工考勤統(tǒng)計庫存管理賣品資料管理產品入庫產品出庫庫存報警查詢統(tǒng)計報表項目及提成統(tǒng)計員工業(yè)績統(tǒng)計分組業(yè)績統(tǒng)計店內業(yè)績統(tǒng)計店內儲值統(tǒng)計店內業(yè)績曲線客流量曲線賣品業(yè)績曲線 數(shù)據(jù)數(shù)據(jù)數(shù)據(jù) 1.會員卡類型設置店里發(fā)行的所有會員卡類2.服務項目設置店里推出的服務項目洗剪吹燙染護3.員工級別設置發(fā)型師、技師、助理、前臺4.日常開支類型設置生活費、鋪租、水電費等等

5.商品類型設置洗護類、造型類6.其他設置（會員卡積分規(guī)則、積分兌獎設置、生日提醒等）7.錄入員工資料、錄入賣品資料。1.流水單輸入現(xiàn)金用卡2.店內開支記錄 員工上下班考勤刷卡核對數(shù)據(jù)報表員工業(yè)績表店內業(yè)績表審查輸入的流水單非持卡會員現(xiàn)金消費刷卡、用卡消費、會員卡充值開卡、保存顧客資料開支記錄產品入庫、出庫 則會員資料提交以后，顧客手機馬上能收到這樣一條短信尊敬的王小

姐，衷心感謝您對XX店的大力支持，您本次開卡充值500元本店將以最高品質竭誠為您服務 :尊敬的王小姐，歡迎光臨XX店，您本次消費30元，卡內余額470元，本店全體員工恭候您下次光臨 在服務項目設置中，我們可以設定每個項目是否要發(fā)送回訪短信只要顧客消費了需要回訪的項目，比如燙發(fā)或染發(fā)，則三天后，系統(tǒng)能夠自動發(fā)送短信到顧客手機上做回訪，回訪短信的內容可以在“短信發(fā)送””短信回訪內容設置“中設定。尊敬的王小姐：您好，衷心感謝您對XX店的大力支持！請問您在我店做的發(fā)型好打理嗎？您對我們發(fā)型師的服務還滿意嗎？你覺得我們的收費合理嗎？期待您回復寶貴意見，以便于我們下次能更好的為您服務。謝謝！店長投訴熱線：***

1.會員消費后短信告知卡內余額2.三天后短信自動回訪3.跟顧客緊密的互動和溝通4.顧客生日自動提醒5.人性化的短信群發(fā)功能1.數(shù)據(jù)店內電腦和網(wǎng)絡雙重備份，店內電腦出現(xiàn)任何問題損壞、被盜都不會丟失顧客資料和營業(yè)數(shù)據(jù)。2.數(shù)據(jù)多重加密保護，防止泄露。3.獨有的店內業(yè)績縮水開關，防止工商稅務稽查。

第三篇：醫(yī)院信息集成平臺建設方案

信息集成平臺建設方案 建設需求

一個完善的醫(yī)院信息系統(tǒng)通常由上百個子系統(tǒng)組成，牽涉眾多的專業(yè)領域。這么龐大的系統(tǒng)需要非常專業(yè)化的軟件開發(fā)分工，整合不同廠商有特色的專業(yè)系統(tǒng)是醫(yī)院信息系統(tǒng)的發(fā)展趨勢，醫(yī)院信息化能夠取得成功必須保證各個系統(tǒng)的有效集成和數(shù)據(jù)的高度共享。然而這些系統(tǒng)通常是隨著醫(yī)院的發(fā)展需求逐步建設的，它們來源于不同的廠家，基于不同的技術，缺乏統(tǒng)一的信息交換標準，這些系統(tǒng)的集成整合已經逐漸成為醫(yī)院數(shù)字化發(fā)展亟待解決的主要問題。

系統(tǒng)集成平臺的構建主要面向兩個核心問題：一個是為各種醫(yī)療應用提供統(tǒng)一的醫(yī)療數(shù)據(jù)訪問服務，從而消除各種醫(yī)療應用系統(tǒng)與醫(yī)療數(shù)據(jù)中心的直接耦合性；另一個是為各種臨床信息系統(tǒng)提供系統(tǒng)集成服務，系統(tǒng)集成服務基于系統(tǒng)集成模型，通過HL7和DICOM等標準通訊協(xié)議為各種醫(yī)療應用系統(tǒng)提供集成服務，確保各個臨床信息系統(tǒng)在工作流整合的基礎上實現(xiàn)交互協(xié)作，從而以數(shù)字化的形式完成各項醫(yī)療業(yè)務。建設目標

系統(tǒng)間的整合、集成和擴展一直都是制約醫(yī)院數(shù)字化發(fā)展的主要障礙，由于不同廠商之間的產品不兼容，使得醫(yī)院整體信息化步履維艱。通過建設一個規(guī)范的系統(tǒng)集成平臺，在IHE、DICOM、HL7等國際標準的基礎上，制定覆蓋醫(yī)療所有業(yè)務流程的系統(tǒng)集成規(guī)范，開發(fā)基于規(guī)范的系統(tǒng)集成平臺，為遺留的、當前的以及將來的系統(tǒng)提供了一個統(tǒng)一且標準的數(shù)據(jù)交換和工作流協(xié)同的平臺。信息集成方法

信息集成方法有三，即應用集成、數(shù)據(jù)集成、界面集成，這三種集成方式各解決不同方面的問題。應用集成指應用程序之間實時或異步交換信息和相互調用功能，可以采用HL7消息，Web Service，CORBA，EJB，DCOM，RPC等標準，采用消息中間件，BPM等中間件實現(xiàn)；數(shù)據(jù)集成是指應用系統(tǒng)的數(shù)據(jù)庫系統(tǒng)之間的數(shù)據(jù)交換和共享，以及數(shù)據(jù)之間的映射變換，常采用ETL（Extract-Transform-Load）工具實現(xiàn)；界面集成含義是應用程序界面之間相互關聯(lián)引用合成，采用技術包括ActiveX插件、Portlet、IFrame等。

協(xié)同應用從早期單純的點對點接口方式，發(fā)展到現(xiàn)如今的集成平臺方式。各種方式中：

? 點對點接口方式的復雜性在于要和不同的系統(tǒng)建立1：N的接口，假定有N個系統(tǒng)相互之間需要建立接口，則接口數(shù)為 N*(N-1)/2。

? 集成平臺方式中，在N個系統(tǒng)需要進行應用協(xié)同的情況下，只需要開發(fā)N個適配器接口即可，減少了集成平臺的系統(tǒng)負荷。

由于醫(yī)院信息系統(tǒng)復雜性，我們根據(jù)不同的需求和應用場景，設計分別采用上述三種不同集成方法和手段進行信息集成。應用集成

和醫(yī)技輔診科室信息系統(tǒng)（如PACS/RIS、LIS、MUSE等）的信息集成，這種場景，信息交互的數(shù)據(jù)量不大，實時性要求不高，且各信息系統(tǒng)各專業(yè)廠商實現(xiàn)方式相差較大，采用基于集成平臺的應用集成方式是最優(yōu)選擇。

集成平臺體系結構如下圖所示，集成平臺對外提供支持多種方式的集成服務：包括WebService服務、TCP監(jiān)聽服務、文件監(jiān)測服務、FTP服務、SQL監(jiān)控服務等方式。

醫(yī)院信息系統(tǒng)在國際、國內廣泛采用的有一套集成規(guī)范，即：醫(yī)療健康信息集成規(guī)范（IHE）規(guī)范。IHE規(guī)范未定義新的集成標準，而是采用了“標準協(xié)調”過程推動基于工業(yè)標準的醫(yī)療IT系統(tǒng)互操作性。在IHE中，消息傳遞采用的是HL7（2.x版本)標準，影像傳遞采用DICOM標準。本集成平臺的集成嚴格參照該規(guī)范進行：信息集成平臺在進行消息時采用HL72.4標準進行消息傳遞、在消息內部傳遞DICOM StudyUID，以滿足后續(xù)DICOM圖像應用時的需要。

臨床信息集成用于對各臨床信息系統(tǒng)進行信息層面的集成事務處理。事務的定義參照IHE規(guī)范執(zhí)行，消息的交互標準參照HL7 2.4標準執(zhí)行。

集成平臺內部引擎本身由Ensemble集成平臺基礎之上進行二次開發(fā)而來，依托Ensemble本身對各種適配器的支持，集成平臺對外能夠提供多種接入服務方式：TCP、文件夾監(jiān)聽、FTP文件監(jiān)聽、自定義WebService、SQL監(jiān)聽等形式。以更多接入方式進行各種不同方式集成各業(yè)務系統(tǒng)。

集成流程以業(yè)務流程可視化、可編輯化對外提供工作流程的制定與使用。集成引擎基于標準的業(yè)務流程執(zhí)行語言（Business Process Execution Language）進行擴展應用，以描述交互應用。4.1 信息集成模塊與示例

信息集成組件主要由以下幾部分組成Business Service業(yè)務服務、Business Process業(yè)務處理、Business Operation業(yè)務操作，這幾部分共同作用下，將集成事務與消息傳遞進行完成。其中，Business Service主要負責進行消息的監(jiān)聽與接收；Business Process負責全局的消息路由轉發(fā)、事務流程處理、消息匹配映射等工作職責；Business Operation負責將轉換完成、最原子化的一個操作，發(fā)送/調用信息集成的目標端。同時在三者相互作用下，消息的反饋準確的返回到Business Process，由Process來講反饋消息控制返回到消息發(fā)送方。示意圖如下（后續(xù)對該示例進行說明）：

4.1.1 業(yè)務服務監(jiān)聽與接收

在當今醫(yī)院中，存在各種各種的醫(yī)療業(yè)務系統(tǒng)，醫(yī)療業(yè)務系統(tǒng)的多樣性，就將導致與其集成時，接入方式的多樣性，如部分系統(tǒng)已實現(xiàn)TCP的發(fā)送傳遞；部分已實現(xiàn)文本輸出等。集成平臺作為醫(yī)院信息系統(tǒng)的中轉、適配角色，在接入方式的多樣性成為必要條件。如前所述，在這方面，集成平臺允許的接入方式有：TCP、FILE、FTP、SQL、SOAP(WebService)、HTTP、MAIL等多種方式與相應的適配器。

在多種方式的接入過程中，將不同來源的消息通過統(tǒng)一的出口轉交給業(yè)務處理部分，由其進行路由住轉發(fā)、消息匹配映射、業(yè)務流程處理等相關的工作。

在本示例中，EMRS通過WebService的服務監(jiān)聽（BS.WS.EMRWS）方式將消息內容傳遞進集成平臺，在通過驗證后，將該消息轉發(fā)給了業(yè)務處理模塊中的路由模塊。

4.1.2 消息路由轉發(fā)

在一些應用場景中，如電子病歷系統(tǒng)、重癥監(jiān)護系統(tǒng)、HIS系統(tǒng)三者進行信息傳遞時，部分信息是需要三者之間交互的，而部分信息僅僅需要兩者之間交互，這在消息轉發(fā)路由時，需要有一定的控制，起到閘門的作用。如：HIS系統(tǒng)進行入院登記時，需要將病人的信息發(fā)送到電子病歷系統(tǒng)與重癥監(jiān)護系統(tǒng)；而在重癥監(jiān)護系統(tǒng)采集到病人生命體征信息時，僅僅將此信息發(fā)送到電子病歷系統(tǒng)即可。因此，在集成平臺中，引入消息路由轉發(fā)的相關模塊就顯得比較重要。

在本示例中，EMRCTLRouter這個消息路由者在接受到BS.WS.EMRWS的消息時，可能會轉發(fā)至EMRPlaceOrder、EMROrderCA、BadMessageHandle三個相關的處理模塊。而具體轉發(fā)至何模塊，由消息頭定義中的相關信息具體定義。消息路由者起到解析與轉發(fā)的作用。

4.1.3 事務業(yè)務流程處理

即時消息路由已經正確路由轉發(fā)了消息到準確的端點，但是在對應的端點內，還會有一些業(yè)務流程需要進行處理。如在EMRS下達一個新的Order的時候，需要的一定的情況下產生不同的業(yè)務流程分支：如該病人為門診病人或者住院病人，則有必要產生HL7 消息中的住院病人登記信息與門診病人登記信息：ADTA01與ADTA04。

在本示例中，BPEMRPlaceOrder的內部業(yè)務流程如下，每一個結點代表著一次邏輯處理過程：

4.1.4 消息匹配映射

在一些情況下，消息的傳遞方并無必要產生HL7標準格式消息的情況下，如EMRS與集成平臺為內部互調時，雙方之間提供預定義的WebService的接口，以快速的開發(fā)與進行集成。此時便需要在WebService中定義的消息格式與標準HL7消息格式之間進行著匹配轉換的工作。而該轉換工作的處理調用是由事務業(yè)務流程處理模塊來發(fā)起調用的。

4.1.5 終端消息發(fā)送

在進行正確的消息格式轉換與業(yè)務邏輯處理，此時的消息已經成為一個符合終端系統(tǒng)需要的消息格式。在事務業(yè)務流程處理中，會將此消息投遞給相應的終端系統(tǒng)。

在投遞消息完成工，事務業(yè)務流程處理模塊會進入等待反饋的狀況，等待終端系統(tǒng)反饋一個應答消息，以表示該消息在終端系統(tǒng)中被準確的處理。事務處理模塊收到該應答消息，并組織成發(fā)送端系統(tǒng)需要的消息格式，并作為應答系統(tǒng)，反饋至發(fā)送端系統(tǒng)。

4.2 集成事務處理流程規(guī)劃

上述主要針對集成平臺中各個模塊作用于應用場景進行了闡述，下面將以IHE規(guī)范中醫(yī)囑下達方醫(yī)囑執(zhí)行的完整業(yè)務流程為例，進行完整的集成事務流程描述。該流程反應了普遍的醫(yī)囑流程，多數(shù)院內的醫(yī)囑流程都可參照執(zhí)行，為醫(yī)院的信息系統(tǒng)集成方式提供良好的參考。本示例中，目標系統(tǒng)以PACS為例。上層應用程序新開申請單集成平臺PACS住院病人：發(fā)送ADT^A01消息/門診病人：發(fā)送ADT^A04消息響應ADT^A01消息/響應ADT^A04消息發(fā)送ORM^O01消息(control code=NW)響應ORM^O01消息對檢查申請進行安排后，發(fā)送SIU^S12消息響應SIU^S12消息查詢申請安排情況開始檢查時，發(fā)送ORM^O01消息(control code=SC Order Status=SC)響應ORM^O01消息檢查完成后，發(fā)送ORM^O01消息(control code=SC Order Status=CM)響應ORM^O01消息有圖像數(shù)據(jù)（圖像匹配）后，發(fā)送ORM^O01消息(control code=SC Order Status=DA)響應ORM^O01消息發(fā)送DFT^P03消息響應DFT^P03消息通知收費系統(tǒng)進行收費查詢申請檢查信息報告完成后，發(fā)送ORU^R01消息(OBX.11=P，初步報告)響應ORM^O01消息查詢申請檢查報告報告審核后，發(fā)送ORU^R01消息(OBX.11=F，最終報告)響應ORM^O01消息查詢申請檢查報告

另外，在院內經常出現(xiàn)的是在IHE規(guī)范中描述的：執(zhí)行者醫(yī)囑流程，即由醫(yī)囑執(zhí)行者（PACS系統(tǒng)中，為檢查科室）進行醫(yī)囑下達的過程并執(zhí)行的流程。如下圖所示： PACS發(fā)送ORM^O01(control code=SN)消息時，消息中必須包含病人號（PID.3），也就是說病人已經掛過號。上層應用程序集成平臺PACS急診檢查登錄時，發(fā)送ORM^O01消息(control code=SN)發(fā)送響應ORR^O02消息(control code=NA)開始檢查時，發(fā)送ORM^O01消息(control code=SC Order Status=SC)響應ORM^O01消息檢查完成后，發(fā)送ORM^O01消息(control code=SC Order Status=CM)響應ORM^O01消息發(fā)送DFT^P03消息響應DFT^P03消息通知收費系統(tǒng)進行收費查詢檢查信息報告完成后，發(fā)送ORU^R01消息(OBX.11=P，初步報告)響應ORU^R01消息查詢檢查報告報告審核后，發(fā)送ORU^R01消息(OBX.11=F，最終報告)響應ORU^R01消息查詢申請檢查報告更新或合并病人信息發(fā)送ADT^A08消息，更新病人信息/發(fā)送ADT^A40消息，合并病人號響應ADT^A08消息/響應ADT^A40消息 數(shù)據(jù)集成

在實際業(yè)務應用中，日常醫(yī)院的HIS庫與ERMS庫之間存在較多需要高頻率、高性能要求的交互，如計價信息與藥品庫存等信息的實時共享等。針對這樣的應用場景，我們采用了ETL工具(GoldenGate)在數(shù)據(jù)庫底層進行的DB層同步方式。目前，醫(yī)院已經存在比較完整的醫(yī)療信息系統(tǒng)，這些醫(yī)療信息是以JW1H系統(tǒng)為基礎，增加醫(yī)院自己的需求發(fā)展而來。ERMS電子病歷系統(tǒng)是一個完整的獨立產品，他有他自己完整一套的系統(tǒng)架構和數(shù)據(jù)中心結構，而在系統(tǒng)架構和數(shù)據(jù)中心結構上醫(yī)院現(xiàn)有醫(yī)療信息系統(tǒng)和EMRS電子病歷系統(tǒng)都存在較大差異，這就決定了現(xiàn)有系統(tǒng)和EMRS電子病歷系統(tǒng)很難共用一個數(shù)據(jù)庫?？闪硗庖环矫?，EMRS電子病歷系統(tǒng)和醫(yī)院現(xiàn)有醫(yī)療信息系統(tǒng)都是醫(yī)院系統(tǒng)不可分割的一部分，他們即有自己工作的重點，又有相互聯(lián)系和配合，只有相互無間的結合，才能快速、高效和正確地完成日常工作。應用EMRS電子病歷系統(tǒng)之后，醫(yī)院現(xiàn)有醫(yī)療信息系統(tǒng)的主要工作就會變成傳統(tǒng)意義上的HIS業(yè)務工作，如經濟管理、人員管理和物資管理等，而EMRS電子病歷系統(tǒng)主要完成以患者為中心的診療行為業(yè)務工作。

兩者之間存在著千絲萬縷的關系，以醫(yī)囑業(yè)務舉例，如EMRS電子病歷系統(tǒng)下達、轉抄和校對醫(yī)囑之后，醫(yī)院現(xiàn)有醫(yī)療信息系統(tǒng)需要完成對應的業(yè)務操作，如醫(yī)囑擺藥和醫(yī)囑收費操作等，這就需要在這兩個系統(tǒng)之間同步數(shù)據(jù)信息，而涉及到同步的醫(yī)療業(yè)務往往涉及的醫(yī)療各個環(huán)節(jié)，如診療、藥房、收費、人員管理等，因此需要信息同步的數(shù)據(jù)量會比較大，而同時為了不造成醫(yī)療業(yè)務的延遲和脫節(jié)，也需要很高的實時性。

在這種應用場景下已不適宜采用基于集成平臺的，通過消息交互的應用集成方式。消息集成方式，往往需要一個發(fā)起方和接受方，而發(fā)起方和接受方往往需要一些額外的支持，如發(fā)起方需要調用接受方提供的接口等，期間可能還涉及到一些負責的來回交互，最主要的是，消息集成在數(shù)據(jù)量很大的情況下，處理速度不是很快，因此，我們將通過數(shù)據(jù)集成的方式來實現(xiàn)數(shù)據(jù)同步，數(shù)據(jù)庫集成工具采用Oracle GoldenGate。

醫(yī)院涉及到需要數(shù)據(jù)同步的包括兩個部分：HIS數(shù)據(jù)庫和EMRS數(shù)據(jù)庫。我們將采用GoldenGate實現(xiàn)HIS數(shù)據(jù)庫數(shù)據(jù)和EMRS數(shù)據(jù)庫之間的數(shù)據(jù)雙向同步。其基本結構圖如下圖所示： HIS數(shù)據(jù)庫服務器GoldenGate雙向復制PRIDE數(shù)據(jù)庫服務器 從上圖我們可以看到發(fā)生在HIS數(shù)據(jù)庫上的相關數(shù)據(jù)變化通過GoldenGate實時同步到EMRS數(shù)據(jù)庫，而發(fā)生在EMRS數(shù)據(jù)庫上的相關數(shù)據(jù)變化通過GoldenGate也會實時同步到EMRS數(shù)據(jù)庫。其中具體的實現(xiàn)過程如下圖所示：

從上圖我們可以看到數(shù)據(jù)同步的核心是GoldenGate，在HIS數(shù)據(jù)庫和EMRS數(shù)據(jù)庫上變化數(shù)據(jù)的捕獲、傳遞和復制都是通過他來完成的。當EMRS數(shù)據(jù)庫發(fā)生數(shù)據(jù)變化的時候，如EMRS下達、校對醫(yī)囑之后，此時運行在EMRS數(shù)據(jù)庫服務器上的GoldenGate將捕獲該功能業(yè)務對應的變化數(shù)據(jù)，并通過網(wǎng)絡傳遞到HIS數(shù)據(jù)庫，HIS數(shù)據(jù)庫接收到這些變化數(shù)據(jù)之后，運行在HIS數(shù)據(jù)庫服務器上的GoldenGate解析這些變化數(shù)據(jù)并應用到HIS數(shù)據(jù)庫，此時如擺藥程序就能看到相應的醫(yī)囑記錄并進行擺藥。反之HIS數(shù)據(jù)庫上的變化數(shù)據(jù)也是經過上述過程應用到EMRS數(shù)據(jù)庫。

通過GoldenGate我們可以很好地實現(xiàn)了HIS數(shù)據(jù)庫和EMRS數(shù)據(jù)庫的之間的獨立和聯(lián)系，使他們各盡其職，分工明確，一起很好地共同支撐整個醫(yī)院的正常運營。5.1 GoldenGate概述

Oracle GoldenGate軟件是一種基于日志的結構化數(shù)據(jù)復制軟件，它議決剖析源數(shù)據(jù)庫在線日志或歸檔日志取得數(shù)據(jù)的增量改變，再將這些改變運用到目標數(shù)據(jù)庫，從而完成源數(shù)據(jù)庫與目標數(shù)據(jù)庫同步。GoldenGate 能夠在異構的IT基本結構（包括幾乎一切常用操作系統(tǒng)平臺和數(shù)據(jù)庫平臺）之間完成大量數(shù)據(jù)亞秒一級的及時復制,從而在能夠在應急系統(tǒng)、在線報表、及時數(shù)據(jù)倉庫供應、買賣跟蹤、數(shù)據(jù)同步、集中/分發(fā)、容災等多個場景下運用，而我們采用的場景是數(shù)據(jù)雙向復制，GoldenGate雙向復制的工作原理如下圖所示：

如上所示，GoldenGate在實現(xiàn)數(shù)據(jù)同步的時候，主要涉及到三個重要進程：抽取進程、投遞進程和應用進程。

1.抽取進程：就是上圖Capture進程，該進程主要負責讀取數(shù)據(jù)庫對應的日志文件，將數(shù)據(jù)變化保存到隊列文件中；

2.投遞進程：也叫傳輸進程，該進程主要負責將源數(shù)據(jù)庫中產生的變化的隊列文件進過壓縮和加密等方式，通過網(wǎng)絡傳輸?shù)侥康臄?shù)據(jù)庫； 3.應用進程：也叫接納進程，該進程主要負責將投遞進程傳遞過來的源數(shù)據(jù)庫的數(shù)據(jù)變化隊列文件解析出來，并應用到目的數(shù)據(jù)庫中。上述三個進程完成了從源數(shù)據(jù)庫到目的數(shù)據(jù)庫的單項同步，如果再加上從目的數(shù)據(jù)庫到源數(shù)據(jù)庫的相似的三個進程，就實現(xiàn)了源數(shù)據(jù)庫和目的數(shù)據(jù)庫之間的雙向同步。

5.2 GoldenGate的特性

1.基于日志的實時數(shù)據(jù)復制：相比傳統(tǒng)依賴數(shù)據(jù)庫觸發(fā)器和規(guī)則的方法來捕獲數(shù)據(jù)變化，GoldenGate采用讀取日志方式對源數(shù)據(jù)庫影響小很多，速度也快很多。

如上圖所示，GoldenGate是通過數(shù)據(jù)日志挖掘的方式實現(xiàn)的。2.事務完整性：GoldenGate只復制成功提交的事務，同時目標數(shù)據(jù)庫按照源數(shù)據(jù)庫的操作順序，而且，可以中斷可以自動恢復，這些保證了源和目標之間的事務完整性。

3.檢查點機制保障數(shù)據(jù)無丟失：GoldenGate的抽取和復制進程使用檢查點機制記錄完成復制的位臵。對于抽取進程，其檢查點記錄當前已經抽取日志的位臵和寫隊列文件的位臵；對于投遞進程，其檢查點記錄當前讀取隊列文件的位臵。

上圖中，Capture、Pump和Devlivery將傳遞狀態(tài)存儲至checkpoint file確保其恢復性，檢查點機制可以保證在系統(tǒng)、網(wǎng)絡或GoldenGate進程故

障重啟后數(shù)據(jù)無丟失。

可靠的數(shù)據(jù)傳輸機制：GoldenGate用應答機制傳輸交易數(shù)據(jù)，只有在得到確認消息后才認為數(shù)據(jù)傳輸完成，否則將自動重新傳輸數(shù)據(jù)，從而保證了抽取出的所有數(shù)據(jù)都能發(fā)送到目標端。數(shù)據(jù)傳輸過程中支持128位加密和數(shù)據(jù)壓縮功能。界面集成

對于醫(yī)學影像、心電圖波形數(shù)據(jù)，臨床醫(yī)生的需求是，不僅能瀏覽圖像和波形，還須有對其處理的要求，通常對應系統(tǒng)供應商提供了DICOM影像瀏覽器和心電圖瀏覽器，這些瀏覽器提供相應的工具來處理、管理、傳輸和轉換圖像和波形。針對這種帶專業(yè)處理功能的人機交互界面的應用程序，我們采用界面集成的方式，集成專業(yè)瀏覽器插件或應用程序。

針對這種方式的場景，EMRS系統(tǒng)將采用界面集成應用的方式集成數(shù)據(jù)綜合瀏覽視圖，在臨床數(shù)據(jù)中心一節(jié)中已提到，該視圖采用組件化方式進行開發(fā)，實質是各類專業(yè)瀏覽插件的容器，支持對各種醫(yī)學影像（X-Ray、CT、MRI、超聲、胃腸鏡）、心電圖、監(jiān)護數(shù)據(jù)和麻醉監(jiān)護數(shù)據(jù)等在內的多種醫(yī)療數(shù)據(jù)的綜合閱覽分析。

至于各專業(yè)瀏覽器插件內部的實現(xiàn)，可能又會采用應用集成的方式，但通常為了提高性能，和多媒體資料庫中心采用直連的方式獲取影像和波形。

以DICOM影像瀏覽器組件為例，其內部采用DICOM標準進行醫(yī)學影像格式定義與交互傳輸。該模塊以OCX控件的方式實現(xiàn)，同時提供給集成事務處理模塊和醫(yī)護工作站使用。EMRS醫(yī)護工作站使用DICOM引擎主要實現(xiàn)從影像中心查詢和獲取影像等功能。6.1 DICOM影像應用流程規(guī)劃

DICOM影像的顯示流程如上圖所示，主要由以下幾步組成：

醫(yī)護工作站通過調用DICOM引擎，設臵參數(shù)（Study UID或Study Type + Study ID，DICOM Server的IP、Port、AE）*，請求獲取一個檢查的影像；

DICOM引擎啟動DICOM Query服務，獲取檢查影像數(shù)，事件通知醫(yī)護工作站，醫(yī)護工作站可以根據(jù)返回的影像數(shù)啟動初始化進度條；

DICOM引擎啟動DICOM Move服務，向影像中心請求影像； 影像中心啟動DICOM Storage服務，向DICOM引擎發(fā)送影像；

DICOM引擎每接收到一個新文件，事件通知醫(yī)護工作站，醫(yī)護工作站可以在此事件的處理中打開并顯示此文件，同時改變進度條位臵；

DICOM引擎接收到DICOM Move響應，表明文件獲取已經結束，事件通知醫(yī)護工作站。核心價值

通過建立集成信息平臺，集成各類應用系統(tǒng)以及日常運營的業(yè)務，通過該平臺整合醫(yī)院內部業(yè)務應用系統(tǒng)，形成一個互聯(lián)互通的醫(yī)院業(yè)務協(xié)作網(wǎng)絡。醫(yī)院信息集成平臺可以很好支持不同系統(tǒng)之間的醫(yī)療數(shù)據(jù)整合、業(yè)務整合與數(shù)據(jù)共享，快速實施應用程序節(jié)點部署以及各醫(yī)療子系統(tǒng)之間的協(xié)同通訊。在醫(yī)院信息系統(tǒng)中的各子系統(tǒng)中，比如HIS,LIS,RIS,OA等，傳遞和展現(xiàn)整個醫(yī)療過程中的相關信息。同時，集成信息平臺為臨床數(shù)據(jù)中心的數(shù)據(jù)來源提供了技術基礎和保障，通過信息標準、交換原則的制定，對業(yè)務系統(tǒng)提供標準的信息交換服務，確保數(shù)據(jù)交換過程的安全性、可靠性，實現(xiàn)數(shù)據(jù)在系統(tǒng)平臺范圍內自由、可靠、可信的交換。

通過醫(yī)院信息平臺建設，一方面可以規(guī)避“點對點”式的信息共享與交換，并使得醫(yī)院可以基于信息平臺整體上進行業(yè)務流程優(yōu)化與管理，對內提高管理水平，對外以統(tǒng)一的方式接入?yún)^(qū)域衛(wèi)生協(xié)同網(wǎng)絡，更好地為人民健康服務。另一方面利于醫(yī)院信息系統(tǒng)建設的持續(xù)性發(fā)展，以適應未來的需求變化，避免信息化建設的大范圍的推倒重來；另外，持續(xù)性發(fā)展還必須要有一套合適的實施和服務模式作支撐。

第四篇：技術架構師解讀用友UAP集成平臺

技術架構師解讀用友UAP集成平臺

關鍵詞：用友UAP,集成平臺,ESB,主數(shù)據(jù)

中國軟件網(wǎng)：用友UAP集成平臺支持用戶、界面、信息、服務、流程等集成功能，能夠方便支持第三方應用與用友(NC)產品快速集成。日前，記者采訪了用友集團UAP中心集成產品開發(fā)部經理粟竹冉，產品與技術管理部技術架構師龍樂樂，他們就用友UAP集成平臺特性以及業(yè)界熱點話題分享了自己的看法。

(CSDN.NET)集成平臺是用友統(tǒng)一應用平臺UAP的一部分，由一系列軟件框架及服務套裝實現(xiàn)企業(yè)所需要的各種級別的集成要求，主要包含了套件ESB(企業(yè)服務總線)、MDM(主數(shù)據(jù)管理)、IDM(身份管理)等。

用友UAP集成平臺架構圖 摘自UAP技術白皮書

用友UAP集成平臺支持用戶、界面、信息、服務、流程等集成功能，能夠方便支持第三方應用與用友(NC)產品快速集成。日前，記者采訪了用友集團UAP中心集成產品開發(fā)部經理粟竹冉，產品與技術管理部技術架構師龍樂樂，他們就用友UAP集成平臺特性以及業(yè)界熱點話題分享了自己的看法。

用友集團UAP中心集成產品開發(fā)部經理 粟竹冉

據(jù)悉，UAP ESB的關鍵特性包括：全生命周期管理的集成開發(fā)環(huán)境，面向服務的組件編程架構，支持SCA事務模型、分布式異構系統(tǒng)事務，支持集群及負載均衡，提供服務倉庫實現(xiàn)跨平臺服務的統(tǒng)一管理，內置基于流程虛擬機的消息流和工作流引擎，支持WebService協(xié)議，提供JMS、Http、Tcp/Socket協(xié)議支持等。

對于開源解決方案，粟竹冉表示，用友開發(fā)過程中調研過相關開源產品，功能很強大，但缺點是服務方面做得不好，另外就是監(jiān)控功能做得很粗糙。用友UAP團隊越來越重視借鑒對開源產品的設計理念和思想，但還是持比較謹慎的態(tài)度。

用友集團UAP中心產品與技術管理部平臺技術架構師 龍樂樂

此外，用友UAP集成平臺中的主數(shù)據(jù)管理和身份管理功能還沒有正式對外發(fā)布，在之前一直以項目的形式存在，未來用友將把它們作為獨立的產品開發(fā)。用友UAP主數(shù)據(jù)管理系統(tǒng)負責主數(shù)據(jù)服務管理調度、數(shù)據(jù)讀取轉換存儲以及和其他業(yè)務系統(tǒng)的數(shù)據(jù)交換，主要分為幾個組成部分：主數(shù)據(jù)建模、主數(shù)據(jù)共享、主數(shù)據(jù)服務、主數(shù)據(jù)適配器。

龍樂樂分享了用友UAP平臺身份管理的兩個典型應用場景：第一是對人員進行統(tǒng)一的身份管理。包括從入職、職務變遷到離職的整個過程進行統(tǒng)一管理。另一個場景是統(tǒng)一認證和身份庫，服務于SSO，跟企業(yè)門戶結合，形成一個全面的安全結構。

對于計劃實施主數(shù)據(jù)管理方案的用戶，龍樂樂建議分為以下幾個步驟來準備：(1)調研企業(yè)數(shù)據(jù)標準化狀態(tài);(2)規(guī)劃企業(yè)主數(shù)據(jù)結構;(3)主數(shù)據(jù)編碼要規(guī)范化和標準化;(4)建模時要反映每個廠商的業(yè)務模型，所對應的主數(shù)據(jù)業(yè)務模型是什么;(5)想清楚實施的難度。

第五篇：開源工作流框架及平臺集成分析報告（范文）

開源工作流框架及平臺集成分析報告

目 錄

Java主要開源工作流列表.......................................................................................................1 1.1.jBpm..............................................................................................................................1 1.2.OSWorkflow.................................................................................................................1 1.3.Enhydra Shark...............................................................................................................1 1.4.Activiti5........................................................................................................................1 1.5.OpenWFE.....................................................................................................................1 1.6.Werkflow.......................................................................................................................1 1.7.OFBiz............................................................................................................................2 1.8.Flow4J...........................................................................................................................2 1.9.ObjectWeb Bonita.........................................................................................................2 1.10.OBPM...........................................................................................................................2 四大開源工作流框架分析.......................................................................................................2 2.1.JBpm.............................................................................................................................2

優(yōu)點...................................................................................................................................2 缺點...................................................................................................................................3 2.2.OSWorkflow.................................................................................................................3

優(yōu)點...................................................................................................................................3 缺點...................................................................................................................................3 2.3.Enhydra Shark...............................................................................................................3

優(yōu)點...................................................................................................................................3 缺點...................................................................................................................................3 2.4.Activiti5........................................................................................................................4

優(yōu)點...................................................................................................................................4 缺點...................................................................................................................................4 與統(tǒng)一開發(fā)平臺集成...............................................................................................................4 3.1.流程定義插件集成.......................................................................................................4 3.2.核心包及jar包集成...................................................................................................4 3.3.部署方式.......................................................................................................................4 3.4.版本選擇與維護問題...................................................................................................5 1.2.3.1.Java主要開源工作流列表

1.1.jBpm jBpm是一個靈活可擴展的工作流管理系統(tǒng)。作為 jBpm運行時server輸入的業(yè)務流程使用簡單強大的語言表達并打包在流程檔案中。jBpm將工作流應用開發(fā)的便利性和杰出的企業(yè)應用集成（EAI）能力結合了起來。

1.2.OSWorkflow OSWorkflow是一個靈活的工作流引擎，設計成可嵌入到企業(yè)應用程序中。它提供了許多的持久化API支持包括：EJB,Hibernate,JDBC和其它。

1.3.Enhydra Shark Shark完全基于WfMC和OMG標準，使用 XPDL作為工作流定義語言。流程和活動的存儲使用Enhydra DODS(一個開源OR映射工具)。

1.4.Activiti5 Activit5繼承了jBpm4的所有優(yōu)點，支持最新BPMN2.0規(guī)范，實現(xiàn)了流程的可視化以及創(chuàng)新的Activiti Cycle協(xié)作組件，此外，通過與Mule的集成加強了其集成能力。

1.5.OpenWFE OpenWFE是一個開放源碼的Java工作流引擎。它是一個完整的業(yè)務處理管理套件：一個引擎，一個工作列表，一個Web界面和一個反應器（存放自動代理）?？梢耘c應用程序很好的給合。

1.6.Werkflow Werkflow是一個靈活可擴展的基于流程和狀態(tài)的工作流引擎。它的目標是滿足可以想象的所有工作流程，從企業(yè)級的業(yè)務流程到小范圍的用戶交互流程。通過使用可插拔和分層結構，可以方便地容納各種工作流語義.第1頁 1.7.OFBiz OFBiz是一個非常著名的開源項目，提供了創(chuàng)建基于最新J2EE/XML規(guī)范和技術標準，構建大中型企業(yè)級、跨平臺、跨數(shù)據(jù)庫、跨應用服務器的多層、分布式電子商務類WEB應用系統(tǒng)的框架。OFBiz最主要的特點是OFBiz提供了一整套的開發(fā)基于Java的web應用程序的組件和工具。包括實體引擎, 服務引擎, 消息引擎, 工作流引擎, 規(guī)則引擎等。

1.8.Flow4J Flow4J是一個可在Eclipse平臺下以拖放的方式進行工作流建模的插件.。

1.9.ObjectWeb Bonita Bonita 是一個符合WfMC規(guī)范、靈活的協(xié)同工作流系統(tǒng)。對于各種動作如流程概念建模、定義、實例化、流程控制和用戶交互等提供了全面的集成圖形工具。100% 基于瀏覽器、使用SOAP和XML數(shù)據(jù)綁定技術的Web Services封裝了已有的工作流業(yè)務方法并將它們以基于J2EE的Web Service形式發(fā)布。

1.10.OBPM OBPM是一個開源，輕量級的BPM系統(tǒng)。它的目標是讓非IT人員也可以輕松構建IT業(yè)務處理流程。OBPM內建工作流引擎（Workflow Engine）, Form構建器，Report設計器。OBPM支持瀏覽器（IE/Firefox）做為客戶端，同時還提供了強大的圖形客戶端。

2.四大開源工作流框架分析

2.1.JBpm 優(yōu)點

1、JBpm是最適合擴展的代表，是在所有開源引擎中最適宜被商業(yè)化應用的一款；

2、JBpm使用了開源框架Hibernate3, 支持當前大多數(shù)流行的數(shù)據(jù)庫, 針對不同數(shù)據(jù)庫有一個對應的初始化腳本文件.3、JBpm將數(shù)據(jù)的管理職能分離出去，自己專注于商務邏輯的處理

4、使用Jpdl流程定義語言，直觀易懂，可以手工修改，并且有一個Eclipse流程定義插件。

5、文檔豐富，用戶群最大，開源組織十分活躍，被jboss收購后發(fā)展趨勢良好；

第2頁 缺點

1、Eclipse流程定義插件不開源；

2、Hibernate3做持久化層，會產生冗余表和數(shù)據(jù)；

3、JBpm3、JBpm4、JBpm5版本互不兼容，發(fā)展趨勢不明確；

2.2.OSWorkflow 優(yōu)點

1、OSWorkflow是最輕量型的代表，也是一款非常靈活和低級別定位的工作流引擎的實現(xiàn)框架，可視化圖標的流程在osworkflow 里都可以用代碼實現(xiàn)；

2、OSWorkflow 有著非常優(yōu)秀的靈活性，它能為應用程序開發(fā)者提供集成，也能與現(xiàn)有的代碼和數(shù)據(jù)庫進行集成；

3、OSWorkflow基于Action驅動，符合框架開發(fā)人員的操作方式及編程習慣；

缺點

1、實現(xiàn)一個工作流系統(tǒng)非常繁瑣，每一個流程步驟實現(xiàn)均需要代碼改變狀態(tài)字段；入門難度較高；

2、組件功能匱乏，復雜流程項目需要基于其引擎做大量的二次開發(fā)，不適用；

3、配置項和開發(fā)代碼量相對較多，后期維護成本較高；

2.3.Enhydra Shark 優(yōu)點

1、工作流體系最為完備和復雜，秉承“模塊化”的思想，比較容易擴展；

2、代碼量較少，易于閱讀、易于改寫、易于維護；

3、有一個Jawe來圖形化定義流程，圖形化功能相對較強，可以編輯活動變量，流程邏輯控制屬性.缺點

1、相比其他完全開源的框架，Shark2.0后，很多組件、文檔商業(yè)化，需要付費；

2、版本更新慢，代碼也不再按照開源方式來完成，商業(yè)化的定位限制了其發(fā)展。

第3頁 2.4.Activiti5 優(yōu)點

1、Activiti最大的優(yōu)勢是采用了PVM（流程虛擬機），支持BPMN2.0規(guī)范及其之外的流程格式；

2、與外部服務有良好的集成能力擴展，通過與Mule的集成加強了其集成能力；

3、繼承了jBpm4的所有優(yōu)點，實現(xiàn)了流程的可視化以及創(chuàng)新的Activiti Cycle協(xié)作組件；

4、對流程引擎運行期實例提供管理及監(jiān)控的Web控制臺。

缺點

1、數(shù)據(jù)持久層采用MyBatis3，沒有遵循JPA規(guī)范；網(wǎng)絡上反應“回退功能”實現(xiàn)起來比較困難；

2、核心是 BPMN 2.0 的流程引擎，BPMN2規(guī)范發(fā)展的比較慢，語言本身也過于復雜可讀性差。

3.與統(tǒng)一開發(fā)平臺集成

3.1.流程定義插件集成

1.JBpm與Activiti都有基于eclipse圖形化插件和基于Web的流程設計器，2.OSWorkflow推薦手工編寫 xml 格式的工作流程描述符，有基于Eclipse GEF技術開發(fā)的osworkflow建模工具；

3.Shark有JAWE作為定義工具，是否可與平臺IDE集成還需要預研。

3.2.核心包及jar包集成

1.都屬于輕量級工作流框架：jBpm.jar 1.06M；activiti-engine-5.9 1.1MB；osworkflow-2.8.0.jar 393KB；

2.Shark核心包大小在6M左右，但是依賴jar包過于龐大，其他三個框架依賴jar包都不多，但是否與平臺jar包沖突還需驗證；

3.3.部署方式

1.JBpm與Activiti都可以與應用項目集成也可以單獨部署；

2.OSWorkflow不可單獨部署，一般推薦與spring集成，方便事務管理及功能擴展；

第4頁 3.Shark可集成也可單獨部署：可以直接作為java庫來使用；也可以單獨部署，作為CORBA ORB 或 Web 服務來使用；

3.4.版本選擇與維護問題

1.JBpm4 積累文檔豐富.網(wǎng)上具有大量的共享技術資源，也是最穩(wěn)定的版本，但是目前已停止開發(fā)和更新；jBpm5基本上完全拋棄了jBpm4的代碼，所有代碼全部來自原先的Drools Flow，資料和文檔相對較少；

2.OSWorkflow是opensymphony下的一個開源項，2.8版本穩(wěn)定，文檔不是很詳細，有較多網(wǎng)絡資源，曾是ERP軟件開發(fā)中廣泛應用的工作流框架，JBpm的出現(xiàn)帶走了很多用戶，使其發(fā)展乏力；

3.Enhydra Shark2.0后，很多組件、文檔商業(yè)化，需要付費，而且版本更新慢，商業(yè)化的定位限制了其發(fā)展；

4.Activiti5是JBoss jBpm架構師加入Alfresco后的作品，繼承了jBpm4的所有優(yōu)點，保持開發(fā)更新中，用戶不斷增加，較多用戶推薦，開源社區(qū)活躍，發(fā)展前景看好。

4.總結

總體來看，四款工作流引擎框架與平臺集成難度都不大，但所依賴第三方jar是否與平臺沖突還需具體驗證；從應用項目開發(fā)角度來看，JBpm4、Activiti5友好度較高，難易程度適中容易上手，而OSWorkflow、Shark則顯得較為復雜；從文檔資料及后期項目維護角度來看，Activiti5無論從版本升級，網(wǎng)絡資料及社區(qū)活躍度來看都更勝一籌，其他三款框架都多少存在一些難度和問題。

第5頁