扩展OSWorkflow(一、引子，从WPS到EOS到中国企业工作流)

    几个月前公司有个项目，项目建设内容较为简单，使用Websphere process server(以下简称WPS)建设几条流程。
    在该项目前期，我曾经带领一个团队使用wps做了一个项目，这个项目中有八九条流程，在使用wps的过程当中，我发现wps根本不适合做一些复杂的人工审批工作流，ibm软件日趋全球化，但却忽略了很多本土化的东西，譬如说wps，作为金融行业融合企业内部服务的soa总线级产品，其内嵌的ESB根本达不到应有的性能(每笔交易时间)，而作为电信行业流程引擎，却忽略了最重要的中国国情--人工审批。在前几天上海分公司信息化部召开的技术讨论会议中，我就目前公司内部系统中几个技术难点发出提问，ibm的工程师与老板都不知所云。
    中外文化差异很大，国外的工作流希望自动化环节更多一些，减少人工参与，降低上行下达过程中人为的，可能造成误差，而中国则不然，中国要求自动化环节少一些，决策都由人来审批，从处长到经理，从经理到分管领导，审批通过还不能作数，要签字盖章，留作日后证据。为什么会有这样的差异，这个问题暂且交给余秋雨之流去论述，我们只讲技术，既然中国企业工作流中讲究的是审批，那问题就来了，人工审批工作流复杂无比，譬如说会签、联签、发散、汇聚、选择下一节点、选择下一节点处理人等等，这都不是一个符合wfmc或bpel标准的工作流就能做出来的，包括最初的普元，几年前来我们公司做技术交流和产品介绍的时候，我们就这些技术难点提出疑问，EOS完全无法满足电信行业需求，于是其回去闭门苦练，一年后再来介绍时，工作流已经基本上能满足99%的审批要求，而WPS刚刚进入中国市场在中国做审批工作流连一个像样的大型成功案例都没有，就更无法满足需求了。
    但介于公司内部系统的现状，使用WPS还是有一些benefit的,公司建设内部管理系统使用了Websphere portal，Domino，Tivoli，MQ，MB等软件，在集成展现上使用portal，内部oa使用lotus，统一认证，统一用户管理使用了TAM，TIM，EAI使用了MB，这样如果工作流使用wps的话，至少做一些展现、SSO、UM等都不存在问题，再加上IBM几个销售卖力的忽悠，领导被骗进，公司吃药，使用了wps，秉承技术人员认证负责的态度，用就用了，把它用到最好，是我的责任，于是我进行了一系列的探索，前期使用wps建设时候，由于其无法满足“选择下一节点处理人”的需求，我自己封装了一大堆的代码，补充wps的流程预知功能，等项目结束后，我惊讶的发现，我自己写的那部分代码，居然已经构成了一个小型工作流引擎，汗颜的同时，我也在思考，既然这样，我不然干脆就做一个轻量级的工作流引擎来取代wps的HumanTask组件进行人工审批，让wps发挥其ESB的功能，当系统之间窜接的过程中遇到个别简单的审批，则采用wps本身的人工任务，但如若需要进行复杂的人工审批流程，则进入我自己的轻量级工作流引擎进行审批，我为自己的这个想法感到兴奋、跃跃欲试，接下来的工作就是选型了，目前市面上的工作流引擎很多，普元的，西安协同的，这些都需要购买license，不考虑，开源框架里有jbpm，osworkflow,shark等，经过考虑再三，jbpm和shark过于封闭，不利于改造成适应行业需求的流程引擎，于是采用osworkflow(以下简称os)，自己在os上扩展了一层，我把它叫做ExtOSWorkflow，从取英文首字母来命名简称，变成了EOS，我狂晕，于是不偷懒，我把它叫做ExtOS，在ExtOS中，我扩展改造了很多功能，差不多改掉了除核心以外的一半的源码，完成功能其中包括：完整的待办任务列表、在办任务列表、已办任务列表、流程历史、流程会签、流程回退、流程委派、子流程、流程时限监控，流程版本控制等，其中会签与版本控制功能尚在继续开发，其余的已经实现，总结之余发表篇文章到blog、圈子、论坛，也想借机引起正在做同类产品的同行的讨论，抛砖引玉吧，关于osworkflow的封装，请听下回分解