业务过程执行的7个谬误是（业务过程执行的7个谬误）
BPMN有大量的只是用于产生BPEL的属性 ，这些一般都可以被忽略 。
通过完全忽略BPEL ，一些更小的公司开始示范了BPM购买者和行业分析师的成功做法 。像Lombardi 、Appian和Savvion这样的厂商 ，把精力放在以人为中心的过程而不是集成 。这样导致了一种新风格的BPMS ，其中可执行的设计直接建立在过程模型之上 ，以BPMN活动的实现的属性的形式 。
这种工具本身鼓励整个实现周期中业务-IT的协作 。并且非常适合敏捷迭代方法论 ，这种方法显著地缩短了从模型到已部署的解决方案的周期时间 。
你不能仅仅因为从来没有业务分析师愿意书写一些类似XPath表达式或其它表达式语言 ，就将开发人员排除在BPM生命周期之外 。
事实上 ，如果[他的BPMN使用者]已经做出了他们BPM运行时的决策 ，那么它通常就是BPEL 。它是一个标准 、一个日用品 ，而且可以找到开源实现 。它被IBM和 Oracle用在他们的BPM运行时中 。因此 ，在选择BPEL时有强制性因素 。但是BPMN和BPEL不是都在进行标准化吗？不 ，这当然不合逻辑 。
在“双向工程已死 ”营地（roundtripping-is-dead camp）待了大约一年之后 ，我现在发现自己不得不再次面临这个问题 。在我的BPMN培训中 ，例如 ，学生想要知道在他们的BPMN图中使用什么策略或模式才能非常匹配他们期望的BPEL实现 。这并不是我一开始期望去考虑的问题 。
未来工作的一个可能方法是扩展提议的技术 ，覆盖BPMN模型更大的子集 ，如对相关的异常处理和其它高级结构（如OR-joins）建模 。不幸的是 ，BPMN的许多高级结构并没有细化 ，依旧处于由相关标准化团体改进的过程中 。使用BPEL你没有忽略你不支持的元素的自由 。BPEL就是BPEL ，你必须支持规范中的一切 。剩余的被称为私有扩展 。它们只存在于它们自己的名字空间 ，BPEL 1.1的一个有根据的批评就是一个真正的过程需要太多的元素 。BPEL 2.0要好一些 ，但是人工任务 、子过程和其他的基本的东西仍需要2.0中的扩展 ，如 ，近乎神话的BPEL4People 。我认为BPM也一样 。只不过是编写XML脚本 ，开发人员并不把它放在眼内 。直到我确实开始深入BPM框架……我并不认为必须提供这些增值框架 。当我开始把它们当作一个可靠的和容错的状态机思考的时候 ，我开始真正意识到BPM框架的潜力 。然后 ，当你结合你的过程和事务管理与补偿使用时 ，你就得到了一个真的好的抽象 ，这在你开发你的应用时可以派上用场 。
创心域SEO版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！