我对BPM认识之路（7）：初识BPM，原来竟是一场误解

LINK：我对BPM认识之路（1）：引言
LINK：我对BPM认识之路（2）：从国内工作流应用谈起（上）
LINK：我对BPM认识之路（3）：从国内工作流应用谈起（下）
LINK：我对BPM认识之路（4）：突围之仗（上） 
LINK：我对BPM认识之路（5）：突围之仗（中） 
LINK：我对BPM认识之路（6）：突围之仗（下）


我对BPM认识之路（7）：初识BPM，原来竟是一场误解

注解：     本系列是以连续续写的方式，逐天抽空完成，我也尽量保证主题思想的延续性。之前的一些文章写作，大多是全部完成后，反复斟酌修改。 这是第一次采用这样方式来写一个完整的主题，所以难免存在文字累赘、偏题之处，阅读时候请见谅。     文章主题思想是通过自己的视角，通过自己对BPM的一些逐渐认识和理解，叙说BPM。因为本人之前更专注于Workflow领域，所以本系列是先从WF说起，一步步引出BPM的。

          这一篇拖的有些久。中间赶上元旦，放了几天假，只顾着放松，有些懒散了。刚过完元旦，忽然得知老婆怀孕了，又是一件非常高兴的事宜，高兴的都顾不上上网了。
 

       2003年3月，当BPEL1.1发布的时候，我还在捣鼓一个基于FSM模型的公文审批流转产品。可想而知，那时候对BPEL是没有任何意识的，可能稍稍有些感触地，就是那时候，BEA的weblogic workshop7中的流程定义语言JPD。

       可惜那时候主要精力都在国内的电子政务和办公自动化流程应用上，所接触的场景，是国外那种面向“自动化”流程所不能够支持的。

       那时候，即使面对刚发布不久的WfMC的XPDL，也有很多不理解和不认同。这在我2003年底写的《工作流模型分析》中有所阐述。

 

       但随后不久的BPEL/BPEL4WS与BPEL却是“芝麻开花——节节高”。之后的两年时间里，尝试跟了跟BPEL的规范及相关产品，但是终因没有实际应用而多次放弃。毕竟BPEL所阐述的应用场景和应用思想，在那个时候还是过于超前的。

 

       2005年中的时候，为当时所在的公司（USE）写完一个工作流引擎之后，回首一思索，突然觉得自己，不能再被当前的workflow技术所困扰了。面对发展迅速的BPEL和BPM概念和应用，应该跟进了。

       虽然看到了BPM未来的发展趋势和势头，但是究竟什么才是BPM呢？这个问题，在当时的我来说，是无法回答的：业务流程、整合、web服务······等等，所有这些都将业务流程执行语言（BPEL）推到了BPM的前头。

 

       现在想在，那时候最大的错误，就是把“BPEL”与“BPM”做了几乎的等价，以为只有采用BPEL规范，才是BPM的解决之道。—— 我也相信，这两年，甚至现在，也依然有很多人，还在坚守着这样的“误解”。——　国内没有什么文章把这两者区分开来分析和阐述，再看看当时那些支持BPEL规范的厂商吧：IBM，Microsoft，BEA，Oracle。对这些厂商来讲，BPEL是一个核心，所有的整合和执行、交互、交换都需要围绕这个业务流程执行语言展开。

 

       正是在这样一种误解之下，我觉决定从BPEL去开始对BPM的理解。这是一个错误的开始，但是比较幸运的是，这个错误的开始并没有持续多久便结束了。

       2005年中，公司项目某项目组可能需要给一个客户采用IBM WBI实施业务流程管理，于是我便申请从平台部门调到那个项目组负责这方面的预研。很显然这个预研是围绕BPEL的实践展开的。

 

      通过那段时间的预言，让我对 BPEL 语言有了一定的了解，但是更多感触则是， BPEL 只是这些大厂商的 EAI/BPM 解决方案中的一个小部分而已，或者说是一件单调的外衣。这套外衣必须有大量的点缀： Transformer Service,Adapter Service 等等。

 

      可惜我没有太多的机会去解决更深层面的概念和技术。不久这个项目就被客户取消了，我又重新调回到平台部门，继续那个不痛不痒的 Platform 研发。

 

      接下来，一年时光很快就晃荡完了。虽然 BPM 这个疑问依然还在我脑海中萦绕，却再没有碰到这样的项目，对 BPEL 似乎也渐渐的淡忘了。

作者：胡长城
网名：银狐999
时间：2006年12月27日夜　
主页：http://www.javafox.org
Blog：http://blog.csdn.net/james999
公司：TIBCO CDC / Infrastructure Administrator Team