SOA领域中的业务流程执行语言（BPEL），在近几年里还没有发生改变。尽管开发人员可以享受其带来的稳定性，但是，甚至是经验丰富的开发人员也会遇到常见的问题。据专家所说，当路面凹凸不平时，SOA问题就会显现，有一些问题是出在BPEL上，而且在实行之前需要认真计划。

BPEL中出现的问题可以分两类：技术问题和流程问题。Vaughn Bullard是弗吉尼亚州BuildAutomate咨询有限公司的创始人及首席执行官，据他所说，这些问题通常会融合在一起，特别是当业务流程没有与BPEL相适应的情况下。这就需要编制流程代码来适应BPEL模型。

Bullard说：“由于BPEL目前是个流行术语，所以有的用户将BPEL视为解决业务流程问题的灵丹妙药。”这就产生了昂贵的、广泛的自定义代码。为了避免该问题的发生，他建议检验流程，在执行之前确保这些代码符合BPEL的要求。

Nauman Noor是公司总部设在纽约的管理咨询师，他认为，未标准化的流程同样会引起BPEL问题，最终结果会与企业所设定的完全不符。他说，之前我们就要考虑合理化及重组，而不是按原样捕捉流程，确保所有事情都能实现自动化，这是根据业务所设计出来的最终状态。

关于流程而不是BPEL本身的另一个问题是安全性问题，并且要定义基于角色和服务的访问。Bullard说：“当执行BPEL时要有安全性作保障。” 他继续补充道，这些原则需要适当定义和执行，以至于当用户执行该流程时会调用另一个流程，用户在访问流程时不会出现任何问题。

Bullard说，建立责任追究体系的服务水平协议（SLA）和企业服务管理及治理也成功地实现了BPEL执行。他说：“如果你在没有执行企业服务管理的情况下想要实现BPEL，那么就会出现一些你所不了解的流程。”他补充说道，当企业在流程间需要达到安全水平的服务来确保其可用性时，SLA也会显得很重要。

不稳定的流程及依赖关系会造成业务流程执行语句偏离计划

与此同时，技术上出现的典型问题是，BPEL执行可能与原计划相违背。Bullard说，例如，如果未能终止子流程，那么子流程的依赖关系可能会引发一些问题。他说：“如果没有正确编码子流程，那么子流程就会待在那里并被挂起。”他还补充道，阻止流程被挂起的关键方法是确保强大的企业服务管理实施到位。

根据Bullard的观点，依赖于非Web的服务组件也可以将活动扳手添加到BPEL部署中。他说：“如果正与非Web服务系统进行连接，并等待流程返回……它的主流程会再次与BPEL模型不匹配。当你正要执行BPEL涵盖的任何SOA时，你需要制定许多规则。”

工作在咨询公司Capgemini的解决方案架构师Léon Smiers认为，解决方案架构也是一个令人担忧的问题。他说，一困难的分层架构、复杂的集成或重负荷过程在数据库中或使用面向商业的通用语言能得到最好的处理。。

Smiers说，在一个项目开始之前，开发人员也需要一个数据模型。通常，他们发现他们无法发现一个适合的数据模型，也不能集成系统，因为，因为系统本身还未能做好集成的准备工作。

Smiers说：“跨应用程序你需要具备一些世界语。如果有一个稳定的数据模型，那么创建BPEL式流程就容易了。”他补充说，如果数据模型随后需要更改，那么在执行之前具备一个数据模型也会节省时间。

因为BPEL的趋势是重用技术，专家们还建议开发人员有逻辑地描述工作流，这样有助于或协助重用代码。Noor说：“工作流必须适当地进行组件化，并着眼于模块化。”他建议，如果开发人员认为会存在共用组件或者图书馆，那么首先勾勒出工作流，然后按其发展方向进行改善。他补充说，在长久的运行中额外的努力会节省时间，因为，它允许开发人员重用组件。

最后，Noor说，由于BPEL工具是由不同供应商所提供的，因此不能期望工具间能互用。他说，想要更换供应商的企业需要将工作流与新工具搭配使用。

这些建议的共同思路是，即使是已经尝试过的或者成为现实的技术，如BPEL，着手开发之前也要制定实施计划。检验流程、创建数据模型和获得稳定的企业服务管理及SLA在运行过程中很大程度上阻止了BPEL问题的发生。