翻译自Tom Baeyens的《Process Component Models: The Next Generation In Workflow ?》 BEPL扩展

　　BPEL4People给出了人员任务如何被包含于一个BPEL流程之中。BPEL4People使用BPEL扩展机制将人员任务作为一个活动添加到BPEL流程中。此规范定义了BPEL引擎何任务组件之间的消息交换协议。BPEL4People引入了people link的标记。任务分配则是对负责任务的人员和组进行选择。BPEL4People给出了人员以及用户组的描述方式。但是，不管是运行时的任务选择的计算还是组织模型信息的结构都未在规范中规定。最近，研究BPEL4People的公司决定将此规范提交给OASIS标准组织。所以大家可以期待不久的将来BPEL4Poeple会出现在多数的BPEL实现中。

　　BPEL4People经常被认为是向BPEL增加工作流功能的一个补丁，使得BPEL更加适用于BPM。其实不是这样的。当业务分析者建模活动时，他们会将其归结为人工任务或系统处理。BPEL仍然强制要求活动之间的交互通过基于XML的流程变量来完成。如果开发者需要增加XSLT的转换，则将是图中的一个新的活动，尽管业务分析者并不关心技术细节。BPEL流程图中的图形化活动的布局仍然保持与web service何XML技术的紧耦合，以保证分析图在流程执行时的完整性。

　　BPELJ是一个过时的白皮书，它是一个将Java绑定到BPEL流程的标准提案。其包括多方面的内容，如包括Java到BPEL的片段，Java对象作为变量以及BPEL流程中调用Java bean。JCP组织的JSR207 java的流程定义尝试将纳入Java的规范中。但从2003，此项努力没有任何显著的进展。

　　虽然有这么些扩展，BPEL的主要问题仍然存在。当其用于BPM时，其不能相应地支持建模方面。业务分析者在建模中不自由，因为图与WSDL服务有直接和固定的关系。BPM需要图与底层技术的解耦。分析者必须能够自由地画图。且开发者必须能够在不修改图的情况下将流程执行嵌入到应用架构中。这用BPEL明显是不可能的。

　　这是否就意味着BPEL糟糕呢？不，如果BPEL用于构建粗粒度的服务而非细粒度服务的集成技术，其包含你可能用到的所有功能。

　　原文链接：http://gocom.primeton.com/blog12633_19935.htm