工作流系统技术可行性分析v1.1【参考】.docVIP

关于工作流系统技术选型可行性分析 系统背景 医院的运作过程本质上是人、财、物等资源的优化和配置，形式上无一不体现为信息流、资金流、物流、价值流等合理的流动；随着分工的日益具体化，合作已成为主题，合作的体现形式必然是一个完整而高效的工作流程；有管理的的活动过程必然是有序的，这种有序性体现为合理的工作流程。因而工作流无处不在。隔离系统的控制逻辑和的业务逻辑，使得业务逻辑的变更对于控制逻辑透明。利用该引擎开发的业务信息系统可以根据具体业务需求量身定制个性化的业务流程，而不用修改控制逻辑，甚至无需修改源代码。提供灵活、丰富的标准开发接口，使得开发人员能采用自己习惯的开发工具在该平台上定制和扩充模块。采用多层分布式技术，力求技术先进性和应用的健壮性。工作流自动化和应用积木化。 技术选型目标 较好的流程定义工具。 工作流技术架构与业务系统之间解耦性较强。 工作流系统定位为嵌入式工作流系统业务流程建模标记法已成为业务人员的流程建模标准引入了Signavio作为面向业务人员的Web建模器Web管理控制台加入了对案例和任务的统计功能Signavio Web、Ecplise pluins)。 开源社区活跃，有较活跃的用户群，拥有较完善的文档。 jbpm4控制台bpm4的下一个版本jBPM5完全放弃了jBPM4的基础代码，基于Drools Flow重头来过JBOSS技术方向转变，后续发展问题突出出来官方提供的控制台必须要基于jboss服务器jBPM的创建者Tom Baeyens离开JBossjBPM5基本上完全抛弃了jBPM4的代码，所有代码全部来自原先的Drools Flow规则引擎(Drools Expert)、事件处理引擎(Drools Fusion)与流程引擎的合三为一入了Guvnor作为流程仓库，这解决了流程的可视化问题流程定义作为资源被管理，我们可以对流程定义进行可视化管理以及全文检索bpm4的下一个版本jBPM5完全放弃了jBPM4的基础代码，基于Drools Flow重头来过官方提供的控制台必须要基于jboss服务器Activiti5是Tom Baeyens加入Alfresco后推出的新的基于jBPM4的开源工作流系统Activiti的开发团队相比与jBPM强大了许多，有23位核心开发者。工作流系统ctiviti规划的功能：包括核心引擎、Web的流程 建模器、协作工具Activiti Cycle、Activiti Probe、Activiti Explorer、与Spring的集成、与Mule的集成等。Activiti cycle协作组件逻辑示意图BPMN2.0图形化规范的支持增加了其流程可视化与管理能力，同时通过创新的Activiti Cycle协作组件支持流程相关人员之间的协调，加强了集成能力Activiti5 由于发布时间较短，文档不够健全，开源社区目前还不够活跃 Activiti5 稳定性不可而知，商业应用还较少。 若选择项目jBPM4 升级到Activiti难度还无法估计 技术选型方案个人建议 评估以上三种技术架构对工作流系统 是否满足 [技术选型目标3.1] 的要求，整理如下（[是] 代表 满足，[否] 代表不满足）: 目标点 jBPM4 jBPM5 Activiti5 1) 是 是 是 2) 是 是 是 3) 是 是 是 4) 是 是 是 5) 否 是 是 6) 是 是 是 7) 是[支持较弱] 是 是 8) 是 否 否 9) 是 否 否 10) 是 是 是 11) 是 是 是 综上所述，个人建议选用jBPM4 , 待Activiti5 成熟后，可升级到Activiti5。