对工作流的小小认识

       今天在javaeye里收到网友的消息，想交流一下工作流。虽然自己去年在开发OA系统时曾设计并实现了工作流系统（http://yongtree.iteye.com/blog/211321），但是对于工作流的认识还是处在一个比较肤浅的认识。本着交流与学习的心态，在此简单说一下自己对于工作流的一些小小的认识，抛砖引玉，希望各位朋友们能分享自己的经验。
  工作流具体的概念和功能我就不多说了，还是说一下在设计和开发工作流过程中的一些体会吧。
      首先，我们需要一个什么样的工作流？为什么这么问呢，这就是因为我们做任何系统都不能脱离实际的业务需求，除非是平台提供商，功能要包罗万象，否则就仔细考虑一下我们的系统应该满足怎样的业务需求，根据需求做出最合适的设计。加入我们去年做的，就是为公司做一个小型的OA系统，加入工作流的目的就是为了在OA系统中实现审批的功能，其实功能不需要太复杂，如果我们也像西安协同和北京易维那样做一个大型的工作流系统，我们人力财力都无法支撑，即使开发出来，也不见得都有所用。所以开发前想一想我们需要多少的功能。在我开发的工作流中，我在设计的时候考虑过自动路由的功能，也将其设计进去，但是在开发的过程中，发现这是一个很难的环节，如果把时间都耗费在这上面，必将造成项目进度的拖延，所以也就没有开发。后来系统运行的事实证明，用户根本不在意这样的工作流程，人们还是相关手工选择路由。所以说，并不见得功能全面的系统就是好系统，这可能还会到来更多的操作复杂性，用户都是很懒的，做他们最需要的系统这是我们在开发前设计时要考虑的。
      其次，我们采用什么样的工作流引擎？工作流系统是一个系统工程，内涵大量的通用的业务、理论知识，选择一个合适的工作流引擎既可以提高我们的开发效率，又能降低开发成本。现在业内有很多免费开源的工作流引擎供我们选择，老牌的shark，轻量级的OSWorkflow，还有发展潜力更大的JBOSS的jbpm。根据自己的采用的开发技术，综合这些工作流引擎的功能，选择一个合适的工作流引擎，将您的系统在它的基础上扩展，不失一种好的方案。由于我做的工作流比较小，只要能满足集团的需要就可以了，所以在选择工作流引擎的时候由于考虑到学习的时间成本，我选择自己开发工作流引擎，采用和工作流标准的xml描述流程的方式不一样的方式，采用数据库为主的流程描述，以XML的描述作为辅助，开发一个及其轻量级的流程运行环境。
      最后，耦合还是分离？什么是耦合，也就是说工作流和它所处的系统关联太深，离开了外围的大系统工作流就变的一无是处了。流程和表单是否紧密相连，表单里有流程的信息，流程中有对表单有过多的控制。这些就要看需求和对工作流的理解了，我当初想把工作流做成一个通用的中间件，可以在其他系统上也能比较好的集成，所以设计的时候工作流和OA之间几乎没有数据结构和类结构的关联，之间的通讯是通过两者之间构造的接口进行通信，虽然没有耦合，便于工作流系统的移植，但是也造成了开发的复杂性，消耗了大量的时间成本，也引起了一点点的性能缺失。在表单的处理上，我和项目经理在初期存在着分歧，我认为工作流系统中必须集成非常灵活的电子表单，让用户自定义表单，但是经理认为这样非常复杂，有难度，要求采用预设好的web表单。但是最后在领导的要求下，我们还是引入了简单的电子表单。我们的电子表单在表现上采用了对在线编辑器进行改造构建电子表单，效果还是不错的。同时，我的思路是表单不要和流程耦合太深，纠缠不清。流程就是流程，表单就是业务数据，各施其责，二者通过相关的接口进行相互合作，这在我们项目组也有一些异议，最后我还是采用了我的思路，不知道大家对于这有没有其他意见。
  工作流是我毕业后第一年就设计和开发的，过程充满了痛苦和心酸，但是一路走来我发现自己成长了不少。我的那个工作流系统依然在不断的完善中，也希望对工作流感兴趣的朋友们能分享你们的认识和心得，让更多的人参与进来。