BPEL扩展

    BPEL4People定义了在BPEL过程中包含人工任务的方式。BPEL4People使用BPEL扩展机制将人工任务作为活动加入到一个BPEL过程中。这个规范定义了BPEL引擎和任务组件之间的消息交换协议。BPEL4People引入了人员链接（people link）的概念。任务分配就是对负责一项任务的人员或组的选择（Selection）。BPEL4People规定了人员或组的描述方式。但是，对于选择（Selection）的运行时计算和身份信息结构并没有包括在规范当中。最近，支持BPEL4People的公司决定将此规范提交给OASIS进行标准化。因此，在不久的将来有望在大多数BPEL实现中找到BPEL4People。

    BPEL4People加入的工作流功能，通常被视为是对BPEL修正，这有助于BPEL更好的与BPM相适应。但这种情况不现实。当分析员建模活动时，他们通常将之对应到人工任务或系统处理。BPEL仍然强制活动之间的通信需由基于XML的过程变量完成。如果开发者需要加入一个使用XSLT的转换，即使业务分析师根本不关心这个技术细节，它也会是一个突然出现在图中的新活动。BPEL过程图的图形活动布局仍然与WEB服务和XML技术的耦合过于紧密，以致于无法在保持分析图完整的同时使过程可执行。

    BPELJ是一个旧的白皮书，它是关注Java和BPEL过程绑定的标准提案。其中涵盖了多个方面内容，如在BPEL过程中包含Java代码片段，将Java对象作为变量和从BPEL过程调用Java beans。JCP中的JSR 207 Process Definition for Java试图将此作为Java标准。但自从2003后，就没有看到这方面的任何进展。

    即使有了这些扩展，BPEL的主要问题依旧存在。当它用于业务过程管理时，它不能很好地支持过程建模。业务分析师在建模时不能自由发挥，因为图需要与WSDL服务建立直接和紧密的关系。BPM需要将图和底层技术解耦。分析师必须能完全自由地画图，而开发者必须能够在不改动图的情况下把过程执行嵌入到应用架构中。BPEL对此无能为力。这意味这BPEL很烂吗？不。假如BPEL被作为一种从细粒度服务中创建粗粒度服务的集成技术来使用的话，它拥有你需要的一切特性。

    BPMN

    什么是BPMN

    BPMN目前被作为一种建模符号使用。它定义了用于过程建模的方框和箭头的外观。对于BPMN是否应该定义执行语义和它是否应该只关注图形表示的问题上，以前和现在都有非常多的讨论。

    
 
    这个规范包括图形形状，含义描述和每个结构的属性集合。BPMN期望解决BPMN结构和属性与特定过程执行语言的映射问题。规范本身就包括了一个这样的BPMN和BPEL映射。BPMN没有定义XML或其他文件格式。一个可能性是BPDM（见下）在未来会定义一个这样的文件格式。在给出对于BPMN的思考和观点之前，我想首先给出一些关于分析过程和可执行过程之间差异的更多背景。

    分析和执行

    当某人用方框和箭头画了一个图，这个图可以表示许多不同的事物：

    *文档，向其他人解释人和系统是如何一起工作来达成某个目标的
    *一个可执行过程，就像任何其他软件一样，向计算机系统解释其行为方式
    *一个与某个软件技术部件（如Java类）相关联的状态机，它可能和任何业务过程都没有关系
    *一种通信协议，描述多方间的消息交换
    *Web应用的一组页面，箭头表示导航选择

    让我们进一步看看图的这两个用途：为分析而画的图和为一个可执行过程而画的图。首先，业务层面的人员不会考虑系统的边界。对于一个分析过程中的自动化模块而言，分析员通常不知道它如何执行或在哪个系统上执行。第二，当分析员为业务过程写文档时，其目的是为了向另一个人解释人和系统协作的方式。作为描述的一部分，图有助于给出一个快速的概览。过程描述可以假设读者对被解释过程的上下文已知。因此过程描述的详细程度可以变化。

    这与可执行过程区别非常大，后者是业务过程管理系统（BPMS）的输入。可执行过程精确定义了这个BPMS应该如何运转。从这点来讲，它就是软件，与编程语言唯一不同之处就是所用的语言。所以可执行过程语言向系统解释了它该做什么。

    当使业务过程自动化时，分析和可执行过程的联系来自于这一共同需求：一个计算机系统需要跟踪业务过程中所有活动的进展。为了达到这个目的，活动结束时需要告知管理这些信息的系统。系统或许可以自己执行某些活动，这些活动被称为自动活动。

    即使在今天，许多BPM系统的市场营销都是这样：“让你的业务分析师画出业务过程的工作方式，然后这个图形描述将在BPMS上运行。”哪个经理愿意让一个不懂技术的业务分析师画的东西运行在生产线上？！BPM系统的机会在于如下事实：业务过程分析图可以和可执行业务过程图看起来非常相似。图可以促进分析员和开发者的沟通，但始终是开发者负责可执行过程的所有技术细节。

    当分析员画的图作为可执行过程的基础时，假如可执行过程语言不能灵活地将图和技术解耦，图就有可能不得不进行改变。例如，假设需要先收集一个人提供的输入信息，然后再将其作为输入传给Java代码去执行，业务分析师可能会对此建模成两个连续活动。但是，如果要用BPEL使这个过程可执行，可能必须加入一个赋值活动来将入参转换成Java代码需要的格式。这说明当分析过程作为可执行过程的基础时，通常需要进行转换。

    另一方面我想指出的是：过程语言在复杂度和适用范围上可以有很大的不同。一些过程语言能力有限，只适用某一特定用途。一个文档管理系统中用于批准的语言就是一个好例子。这种语言可以非常简单而且不需要太多的技术细节。这种图在过程中占很大比重，非技术人员确实可以用这种方法构建一个完全可执行的过程。但对于象BPEL或jPDL这样的通用过程语言而言，情况就不一样了。这些语言有更大的适用范围，因此它们更加复杂而且需要更多的技术细节。此时，总是需要一个开发者来管理技术细节。