Web服务的设计目的是要解决工作单元问题，并使其可以在平台独立的状态下被访问。在各单元，从计算运费单元到获取股票报价单元，汇集后，这些单元仍能继续发展，形成更为庞大整体的一部分：业务流程单元。与SOAP，WSDL和WS-*拥有相同的技术背景，标准在创建个人的网络服务中发挥着重要作用。业务流程执行语言（BPEL，Business Process Executive Language）重视Web服务编写的业务流程所需的技术要求。下面我们将细细分析BPEL、Web服务和业务流程背后的实际领域专家三者之间的关系，请您接着往下看。

　　在关于软件的设想甚至还未出炉之前，一次汇聚了公司资深专家的会议中提出的业务流程的概念已经步入了我们的生活。这些专家都熟知某一特定业务流程，并且决定采用数字化实现业务流程。从产品采购，租用过程到物流管理，这些都可以应用BPEL的高级描述性能。

　　但是说到高级，我们会想到典型的BPEL语法——与网络服务的个人编程相比——BPEL仍然具有教条性，容易受到一些技术性的影响。当BPEL首次作为公司级或项目级应用，尤其是如果个人网络服务之间的路径没有很好的绘制时，BPEL可能无法实现其目的。而有效利用BPEL的主要宗旨之一就是要发展服务重用。

　　就本例而言，相比于使用BPEL理念进行修订，将业务流程分解成易于管理的工作单元更为必要。被分解出的每一个单元被分别拥有、开发和测试，而这不仅通过经典的分而治之的发展方法增强了可管理性，而且还简化了许多涉及Web服务的设计问题。毕竟，为“臃肿”的Web服务和“苗条”的Web服务设计SOAP、WSDL和WS-*逻辑是两回事，而后者的优势是每一个“苗条”的 Web服务随后可按顺序的不同进行堆栈，或者在业务需求发生变化时，根据供应商的不同进行堆栈。

　　一旦Web服务的所有环节处于工作状态， 要实现BPEL流程就需要考虑两个重要的基础条件：执行环境和执行工具。BPEL环境——有时被称为BPEL引擎，或干脆称之为BPM——可以以多种形式呈现。我们有开源环境，比如ActiveBPEL，我们有大型供应商提供的产品，我们也有小型合作伙伴提供的其它产品。

　　选择BPEL引擎的过程，工作量非常大，但这是相当关键的一步，不仅因为有很多的BPEL引擎被BPEL工具紧紧限制，而且还因为很多BPEL引擎捆绑携带许多附加产品。正因为BPEL拥有如此强大的整合服务能力，许多厂商认识到对许多企业的业务流程来说，对BPEL以外的支持，是一个必要条件。从那些规范略高于现有BPEL的工作——例如业务流程的管理监测——到更复杂的整合情况，比如工作流程的人力资源环节或ERP型人机对话，这些往往都不使用Web服务。问题是你将需要多少或哪些非BPEL能力，而我们只能在仔细分析业务流程后才能给出答案，从而确定是否使用标准的Web服务建立架构还是需要其他技术支持。

　　至于工具，因为BPEL是基于XML的语法，而且经过WSDL契约的检查——对实现业务流程的基本网络服务进行了弥补，因此，工具的使用往往是必需的。不过，虽然您可能不会通过简单的XML编辑器，使用其中的一个或两个Web服务，来构建基于BPEL的流程，但是，如果在BPEL契约中需要将安全、业务或落后的替代品纳入设计范围，那么两个以上服务的应用往往需要使用更加专业的工具。

　　正如前面所指出的，你会看到工具与BPEL运行之间具有很强的相关性。大多数工具的目的不仅要方便BPEL实际流程的部署和设计，而且还在某一特定的BPM中提供许多非BPEL特性支持。这极有可能会迫使你做出一个坚定的承诺——无论是工具还是BPEL运行——都需要一个特定的供应商满足其所有的BPEL需求。

　　业务流程是一个被普遍理解的概念，但应用Web服务的特性实施业务流程时，除了需要考虑与BPEL标准的共同联合外，还有一系列的问题需要考虑。从把业务流程适当分解成个别单元；以一种更有利于管理的方式应用SOAP，WSDL和WS-*；到实际的选择工具和运行来支持BPM计划。每一个都是除了BPEL外需要考虑的因素 。