SOA出生的年代，正是BPM发展的第一个高峰，当时论坛上到处都是有关BPM的讨论，甚至连学术期刊也充斥着BPM的文章；前几年是
SOA默默发展期，BPM反倒销声匿迹了，关于
SOA和BPM的讨论也都出现在互不相关的论坛上，讨论它们的人通常也属于不同的圈子；但是现在，
SOA的茁壮成长带动了BPM重振雄风，相关技术的使用者和提供者正日渐将二者结合起来。
在
SOA和BPM联合发展的浪潮下，我们首先要明确的是，BPM与
SOA的本质是截然不同的:
SOA是一种架构方法;BPM则是一组流程协调管理理念。没有
SOA之前，BPM产品已经出现并成功应用，BPM的主要应用场合有如下几点：
· 业务流程自动化。这是BPA的概念，BPA按照业务需求，自动化流程，这是现在工作流技术还在继续做的事情。
· 整合应用系统，实现异构系统之间无缝交流。这涉及到EAI的概念，不过实现方法和老的EAI技术是完全不同的。
· 企业流程建模分析。这个是BPM的核心，在详细了解企业流程划分之后，用全局的视角，对一堆的流程进行梳理，并给出企业流程全局图。
· 监控企业活动，实现企业流程持续改进。这是BAM的功能，BAM需要用前面的企业流程全局图，分析企业流程效果和效率，提供优化方向，实现企业级的流程管理。
· 在上面描述的BPM的四大应用场合中，每个都和
SOA有千丝万缕的关系。从技术层面看，
SOA和BPM结合有多种方法,SCA的WS-BPEL客户端和实现模型规范说明了WS-BPEL2.0怎么样和SCA结合在一起使用，具体方法有如下三种：
BPEL流程作为构件的实现
在SCA中，可以把一个有效的BPEL流程作为一个构件的实现。对于一个构件的定义来说，可以使用子元素来表示本构件是用一个BPEL流程来实现的。子元素的process属性指明了这个可执行的BPEL流程的目标名称。
这个方法是从BPEL开始的：我们先定义好一个BPEL流程，然后把它纳入到SCA容器中去。示例图如下所示：
BPEL流程定义一个构件的类型
当一个构件使用了一个BPEL流程定义的构件实现的时候，BPEL流程定义也决定了这个构件的类型。如果一个构件类型只使用WSDL接口来定义服务和引用，我们可以用BPEL来得到这样的构件类型。这个可以通过“反射”机制来实现：
BPEL中的合作伙伴链接对应于SCA中的服务和引用。在SCA中，服务和引用的区别是在一次会话中，哪一方第一次发起通信；而在BPEL中，合作伙伴链接是不关心谁是会话的发起者的。所以，为了在BPEL流程和构件类型中做一个映射，必须找到一个办法鉴别出会话的发起人。在BPEL中，一个合作伙伴链接要想发起一个会话有如 下可能：在活动中接收一个消息；在 活动的子元素中接收一个消息；在一个事件处理器的子元素中接收一个消息。在上面情况下，应该把合作伙伴链接映射为SCA中的服务；反之则映射为SCA中的引用。
如果合作伙伴链接映射为SCA中的服务，那么服务的类型就对应于BPEL中的合作伙伴链接类型。合作伙伴链接中的指定了服务的WSDL的portType；如果有 ，则它对应于服务的回调接口的WSDL的portType。如果合作伙伴链接映射为SCA中的引用，就和服务的情况相反。如下图，component的service是可以有WSDL PortType接口的。
为BPEL加入SCA扩展
我们可以在BPEL中加入SCA扩展，从而产生SCA的构件类型定义，并利用它来完成
SOA的装配。例如，一个BPEL的变量声明可以包含一个SCA的扩展：
从上面的讨论看出，BPM和
SOA的结合的方法可以帮助BPM实现更多的功能。当前日益复杂的业务流程充满更深层的跨系统交互以及更丰富的用户协作，因而需要更强大的业务流程管理能力，这也正是
SOA对BPM产品的引人注目的业务优势。在
SOA环境下的BPM与非
SOA环境下的旧式工作流相比有如下的不同：
|
服 务 CIO 推 进 信 息 化 
