jBPM4工作流应用开发指南

首先十分感谢作者给我这个机会在他的作品即将问世之前做一些感想，也正好让我能在忙碌中抽空回顾一下这么多年在技术平台方面走过的路以及在Workflow方面的点点滴滴。因为本书是介绍jBPM的专业书籍，所以我谈不上给些什么评论，只是将对作者的印象和对书中内容引发的一些思考和回味分享给大家。

首先就要从我跟作者如何相识的初次合作谈起了。记得那应该是2005年，我们经历了两年多搭建面向ERP项目的研发平台初具规模，正在10多个大型项目中服务。当时从底层技术框架、代码生成工具、组织权限等诸多技术问题都得到了充分的考虑和解决。当然肯定少不了对Workflow业务的解决。当时我们选用的WfMC的XPDL语法，从引擎、设计器、监控器、模拟器、组织模型全套都实现了。最初因某些项目原因采用的.NET，后迁移到Java平台下，并且以Hibernate做存储，也是采用的微内核和状态机的设计思路。提供了一整套的API（类似jBPM等主流工作流引擎提供的方式）。但在几个大项目实际使用中发现这种纯粹API二次开发的方式，基于封闭工作流系统无法高效地支撑业务快速开发及流程仿真重组。

对业务系统快速实施有价值的是整合了组织定义、流程定义、业务表单定义、业务数据权限定义工具等全集成的定制系统，不用通过编写代码业务需求人员通过拖曳即可完成各种层级集团应用的定义，并适当设置一定的业务脚本即可完成业务系统的定义。所以我们在2005年6月启动了这件事情，基于已有的组织权限、工作流基础上加入业务表单定义及整合的设计定义功能。然后在公司内部到处挖人，我习惯于以技术geek的方式在公司内部到处引诱人，都是先通过非正式的方式从技术角度找到有想法感兴趣的人，然后再用各种手段搞到这个人加入。

记得那个时候一个意气风发、满怀抱负的年轻小伙子给我留下了深刻的印象。他刚刚做完一个电信的项目，爱好非常广泛，JS很好，也会Flash，想法特别多，手特别快。所以我就通过各种手段搞到这个家伙加入我们，那就是年轻时的作者。很快他先搞定了业务表单定义的技术攻关，可能当时我们是最早使用XmlHttpRequest的（Ajax的核心），然后基于Workflow如何接收表单传递过来的数据，然后接手了整个Workflow的优化及实现各种变态的中国特色的工作流需求。我们在10月左右发布了一个完整的版本，支持了上面讲到的那些功能。现在回头看看大家都很神奇，10个人不到3个月就搞定了这么复杂的东西，也许换到今天开源技术如此成熟可能都未必能做到。之后这个家伙就一定要坚持在专业上坚持以Workflow为方向不断成为专家。

再一晃就是多年以后的事情了，我也从搭建ERP研发平台到互联网SNS大型数据平台又转回到专属行业ERP产品平台。不论管理大型团队多少年，始终秉承着对技术的痴迷，从未放弃对任何技术细节的关注，也越来越推崇中庸、推崇妥协。

这期间我们有过断断续续的联系，也曾经为一些点子一起疯狂、一起兴奋，不过终究没有找到合适的机会再次合作。收到作者的邀请时，十分地受宠若惊，当时手头的事情也特别多。而且类似的书我也见得特别多，不外乎就是英翻中，所以就根本没放在心上。直到后来拿到作品仔细阅读了一番，渐渐地能体会和重现这个家伙几年的历程——一直在专业（Workflow）的道路上滋滋以求。

当然文中难免有大量资料的复制，但是能花大量心血组织起来，如此翔实全面地介绍已实属不易。而且加上了这家伙从当年我们一起做流程系统时的经验和他在jBPM系列产品应用实施上多年的咨询经历。

最近我也在平台中的多处集成了jBPM用于解决传统审批流，跨业务域集成BPM，以及ETL流等，当然不会孤立使用Workflow，肯定是结合ESB、MDA、规则引擎等一起使用。一直想给大家从概念到Workflow的历史、再到如何运用jBPM解决各种问题等进行一个全面的讲解，正好拿到这本书，省了我很大的力气。

这几年IT业内浮躁风气、快餐文化盛行，用过Spring、Struts、jBPM就敢说自己是架构师。而很少有人能够踏踏实实潜心研究各种技术的根源，为什么要这么设计，如何扩展更为有效。从我们做平台的人的角度来看简单会用没什么，关键是能理解精髓并扩展或改造才是本事。

像作者这样致力于在国内传播Workflow的模型，让更多的人少走弯路，快速上手，并不断将多年研究的心得和成果同大家分享的人太少了，国内太少这种人了。也许这本书可以为不少人提供了解jBPM的素食套餐。尤其本书中“第20章 中国特色工作流的jBPM实现”十分具有实战意义，是特别值得国内使用jBPM做应用的人们参考的最佳实践。

笔触于此，抬眼已很晚了，一气呵成就先写这么多。让我们一起读完全书后再回来一起思考和回味下面这两个问题吧！

l 有想法、专注、愿意分享的年轻人，我们应该有怎样的IT人生？

l 业内规范的演化进步，我们又会遭遇怎样的IT进程？