透过现象看本质 - 壮志未酬的BPEL

头不痛了，继续扯扯IT那点事。

 

先明确一下本文主旨，本人并不喜欢BPEL，仅从个人观点分析下BPEL因何而来，BPEL的局限，以及本人喜好的业务流程设计方法，希望能引起关心业务流程设计的人的进一步思考，别整天帮着老外吹他们的SOA解决方案来骗自己同胞的钱!

 

 

先理解一下工作流是个啥东东：

 

 

要说bpel，撇不开工作流，而工作流的出现，源于业务流程建模需要，业务流程建模的目标，是分离业务流程的表述与其技术实现，并实现业务流程可视化，而工作流引擎提则供了将业务和技术实现粘合在一起的平台。于是乎，业务人员可以以最低的成本、最直观的方法建模业务流程，工作流引擎则负责根据定义来驱动流程的执行，最后，业务人员可以通过工作流平台实现业务级的监控、统计和优化，整个过程中，技术屏障降至最低，业务的可视化达到最高水平。

 

最NB、最理想的业务流程管理软件，应该是可以不需要软件开发人员而只需要业务建模人员，工作流平台就能够帮助完成业务流程到技术实现的映射，但这样的理想环境离现实毕竟还是有些遥远，实际应用过程中，再好的BPM产品多少还是需要依靠少量技术人员帮助完成技术细节，以及业务建模人员多少也要学习一下所使用的工作流系统的开发规范，但不管怎样，这已经大大大大的降低了实施的成本、实施的周期、与实施的难度，并且让企业管理人员能够更加专注于自己的宝贝“业务”。

 

以上是推动工作流管理系统产生的基本需求。那么怎么样实现一个工作流管理系统呢？一个工作流管理系统的架构大概应该是什么样子呢？实际上要实现类似功能的平台，方法是多种多样，如最简单的方法可以采用基于数据库预配置好活动步骤，每个Task结束后会获取下一步骤的id，依次执行），另外，可以采用有引擎驱动或无引擎驱动方式，等等等等。见过国内不少集成商都有自己的独特引擎，应用于合适的业务，效果也可谓相当不错。

 

但这种没有采用工业标准的工作流管理软件的所谓的最大的问题也出现了，业务流程定义不可重用（因为这是用我们自己的所谓叽里呱啦语言定义的，放到人家讲英语的环境中人家听不懂），也就是说如果企业发展了，系统要升级的话，很难切换到其他符合工业标准的工作流管理系统上，业务的重用上有点问题，业务流程定义不开放。不过如果你很幸运的使用着一个很nb的这类工作流系统的话，而且也不需要换到其他平台上，那么也不用这山望着那山高，在这个独立的系统内使用，完全的OK，最讨厌没事瞎折腾的了。

 

再来看看老外的习惯套路，这点上中国人确实该学着点：建立联盟，定义标准，人家抱着团玩，这多专业呀！如果你也生产了这么一款产品， 但猫不着标准的边，都不好意思拿出手，可算鼓足勇气拿出来给人家，人家还得给你两句：怎么着，新来的吧，知道规矩不？

 

WfMC的标准化（已然是相当遥远的时代的事情了）了一个参考模型，试图统一工作流领域的标准接口，以便不同厂商的产品可以无缝对接，但发展了十好几年，相关产品还是花花绿绿，甚是壮观，很少有自己只实现规范中一个模块的产品，大都是完整的工作流套件，而且都各有主见的进行了扩展，反正只要声称是从一个模子里出来的，没什么人细究的，谁还真没事闲的做流程移植啊！

 

不管怎样，wfmc确实给业务流程抽象提供了一个通用的解决思路，堪称圣经，很多现代工作流管理系统依然遵从这个基本模型，其思想依然有许多可以借鉴的地方，我这里不讨论wfmc参考模型，有兴趣的可以去拜读一下那个规范，了解下思路。

 

下面贴几个wfmc规范里的图，仅供坚持读到这里的人做一参考。

 

 

 

 

 

 

 

 

个人经验，实施工作流应用，架构师须要理解以下关键要素（不管是什么产品，大同小异）：

业务流程描述（定义）：基本活动activity（步骤），控制结构（分支、循环、并行、合并等）。

业务数据结构（数据模型）：工作流变量（对流程执行路径起影响作用），业务数据模型（对流程执行路径无影响）。

接口：工作流管理系统接口（用于操作工作流管理系统），业务服务接口（通常是从流程执行过程中调用服务接口，如调用java class的一个方法）

Human Task子系统（一种特殊的activity，用于实现任务分派）： worklist接口，任务（Task）管理API。

流程监控接口：对流程实例、任务实例进行监控。

Persist系统：流程定义，流程执行实例，任务实例，等相关信息数据库。

业务流程建模：业务流程建模的粒度实际上是相当重要的，需要具备相当深厚的业务功底和对业务的独到理解。

• 过度详细：非紧要步骤以业务节点形式添加到流程定义上，会增加业务噪音，影响运行效率，增加系统负担。
• 粒度太粗：业务步骤可能会被淹没，从工作流系统层面来说，可能对业务运营信息反馈不足。并且，业务逻辑可能被藏于代码实现中。

 （反正你时刻需要铭记使用工作流系统的目的，是BPM，千万别做的只剩个P（屁），丢了B和M，相反B和M是相当重要的前提，没有了B和M，P就真是个屁了，屁价值没有）

 

怎么又冒出来个BPEL？

现如今是个互联的时代，啥啥都要互联，你要是跟别人联不到一块，那去死吧！

现如今是个全球化的时代，世界需要统一用英语沟通，你要是只会汉语，妈的中国人（指大国企）都瞧不起你，而xml是IT的世界语。

现如今是个咨询的时代，你要不把简单事整复杂了，人家会说你不专业。(其实各行各业都是如此，都需要建立坚固的行业壁垒。都希望把事情做简单，但又害怕把业务做简单了，自己没value，所以逼得只能整天在词汇创新，挖地沟上下功夫。大把的专业词汇，云里雾里的理论，这叫什么，这叫差异，没了差异，就不值钱了，坚决鄙视这类垃圾人士)

 

这个时代背景下，Wfmc模型为什么阻止不了BPEL的出现，个人认为有下述几点原因：

wfmc制定时间太早，service provider接口也未进行严格标准的定义。

wfmc流程定义语言xpdl，以及bpmn等，天生的“残疾”也始终未能登上一统天下的宝座。

 

而BPEL，统一了基于web service的流程定义和执行。

 

BPEL其实是个挺有意思的东西，流程即service，service即流程：

• BPEL本身是个web service，有WSDL定义。
• BPEL可以调用Web Service，服务提供端是WSDL描述的。
• BPEL采用XML作为流程定义的载体。

这三个特点决定了BPEL的一切都是建立在“标准”只上的，平台中立，语言中立，标准化，便于重用，造就了BPEL的“伟大”用途，尽管全世界超过80%的web service是java平台上实现的，但这不妨碍人家是平台中立的标准。

 

与wfmc参考模型的区别：

其实两个东西不是一个层面的东西，不应该拿来比较，BPEL是一个独立的流程定义规范，其目标是实现web service的编排，旨在定义平台中立的业务流程执行标准，属于业务流程定义语言层面的规范，其规范中并不涉及整个业务流程系统体系架构的参考，仅相当于wfmc中的xpdl规范。至于引擎实现，监控等，给厂商足够的自由去发挥。而wfmc参考模型的工作流系统，是一个比较全面的参考实现，bpel引擎架构的实现，很大程度上还是脱离不了这个参考模型，而且，很多wfmc标准的工作流产品，也支持bpel。

 

为何壮志未酬？

但早该大气已成的bpel，多年了一直在不温不火的低调中前行，收复天下的重任看来真的难以堪负，除了在国际大厂商的鼎力支持的领域，似乎并不得志。

 

究其缘由，我认为源于整个软件界的错误导向，什么错误导向呢？就是可视化流程编程。业界普遍认同的业务流程开发过程是从业务流程建模开始，逐步细化流程的步骤，作为BPEL开发的输入原型，在BPEL中继续细化完成流程的实现，这过程全部可以实现可视化，以拖拉拽的方式，这是听起来多么多么美好的事情啊，开发变得简单的不得了，这世界变得多么傻瓜化呀，但请千万不要忘记，这世界上，有些事情是绝对绝对不能让傻瓜去做的，编程问题必须让程序员去做！

 

问题：

1. 业务粒度难以控制，极容易得到滥用。后果：“假”的业务流程管理。
2. bpel调用bpel，其内部层级受屏蔽，因为都是web service。后果：容易将业务关系复杂化，对系统性能影响也较大。
3. 业务流程建模的最后一公里，依然需要编程人员的帮助，需要通过“编程”实现（尽管是拖拉拽的可视化，但实际上还是一种形式的编程），完全依靠业务人员的理想场景是不存在的。主流国外厂商的解决方案中，在业务流程细化链条上，也是定义了众多的角色，通过逐步细化的方法，最终交由BPEL开发人员实现，而通常在这一层面的实现中，已然囊括了众多的非业务活动元素在里边。后果：使流程关系的不再仅仅是业务，太多的技术活动被牵涉进来，流程变得庞大。
4. “规则”的地位变得尴尬，不统一：由于分支，循环结构的引入，大量的业务规则被“硬编码”在流程中，散步于各种各样的流程中，规则的统一管理变得混乱，即使采用规则引擎统一管理，又怎能保证规范的使用了规则引擎，何况引入规则引擎，又增加了系统管理的复杂度。后果：业务规则硬编码于多个BPEL”代码"中，管理复杂度提高。
5. 架构的复杂度没有降低，反而提高：bpel流程即service，service即bpel流程的关系，致使业务系统的扩展依赖于不断膨胀的业务流程的数量，而bpel并没有提供应用系统架构的参考，而且bpel层面不存在统一架构，必须从更高的应用设计上加以考虑。后果：因此实际系统实现中，需要仔细考虑应用系统架构、分层、重用等问题，为设计高效、可靠、稳定的系统增加了不小的难度。
6. etc，哎呀妈呀，快别打了，太惨俩啊！！！

总之，也不是说BPEL一无是处，但实际应用BPEL实现业务流程管理，确实需要避开许多陷阱。一个完好的应用架构规范是必须的，比如什么level的业务用bpel建模，service的层次、粒度，service的实现规范，规则放在哪里管理等等。否则完成的系统必将是个鸡肋系统。

 

 

个人崇拜简单架构的设计方法，认为无论采用什么软件产品，什么样的价格，只要解决好以下个问题，这个架构必是完美的架构：

1. 统一&简单的架构：复杂的设计一定不是好的设计。简单架构下能够支持一致的开发方法会大大降低成本，提高效率。
2. 能够使业务人员关注业务：简单流程+业务数据模型+极低的技术要求。
3. 编程问题必须让程序员去做：框架是系统质量的重要保障，极高水平的开发人员必须具备一两个。
4. 配置化：很多国内电信公司非常喜欢基于关系数据库的配置方法，这的确是个很好方法。
5. 任何系统的建设都有其重要的关注点，首要考虑关注点最为重要，而其技术标准反倒不是首要考虑因素。
6. 在架构问题上，具备独到见解者为圣，跟风做东郭先生必遭人唾弃。思胜于学！