理解BPEL

流程
流程也叫业务流程,指定了一组 Web 服务的操作的可能执行顺序、这些 Web 服务间共享的数据、业务流程涉及哪些伙伴以及这些伙伴在业务流程中扮演什么角色、一组组 Web 服务的共同异常处理以及关于多个服务和组织是怎样参与的其它问题。特别是它允许指定 Web 服务间长期运行的事务，提高 Web 服务应用程序的一致性和可靠性。 在BPEL中流程是一种实体, 服务也是一种实体. 所以在BPEL就是描述流程和服务之间如何打交道(交互).

伙伴
在BPEL中,伙伴的定义是相对流程来讲的, 实际上伙伴指的是和流程打交道的服务. 所以 伙伴 = 和流程交互的服务. 在BPEL中,伙伴可以分为三种:

1. 被调用的伙伴(Invoked partner): 就是只由流程调用的服务/伙伴 ,流程 --> 服务 单向
   
2. 客户机伙伴(Client partner): 只调用流程的服务/伙伴, 流程 <-- 服务 单向
   
3. 第三种伙伴: 既可以由流程调用, 也可以调用流程的服务/伙伴, 流畅,<--> 服务 双向

伙伴连接类型
伙伴的第三种类型带来一个问题，这就是参照问题，或者说是看问题的角度问题。如果你站在流程的角度，可以说我需要服务提桶给我一个PortTypeA, 同时我将我的PortTypeB提供给服务。 如果站在服务的角度，可以说，我给流程提供了PortTypeA,同时我需要流程给我PortTypeB. 问题是每个人的角度不同，导致对问题的理解不同。 怎么办呢？我们应该站在那个角度上看问题呢？最好的办法就是我们既不站在流程的角度，也不站在服务的角度上考虑，而是站在第三方的角度上。要想站在第三方角度上考虑，那么伙伴连接类型就派上了用场。我们使用角色这个概念。伙伴连接类型定义了两个伙伴如何交互，并且每一方提供了什么。我们通过角色用来定义在这个交互中每一方伙伴提供了什么。
第三种伙伴需要给流程一个端口类型(PortType), 让流程去使用这个PortType, 同时流程也要提供另一个端口类型(PortType), 供这个伙伴使用.
第三种伙伴引出了服务/伙伴连接类型(Partner Link Type)的概念. 服务连接类型并不是从这些参与方(流程和服务)中的某一方的角度出发来定义流程和服务之间的关系. 它代表了一个第三方的声明.通过这个声明来描述两个或者多个服务之间的关系. 为了达到这个目的, 服务连接类型引入了角色这个概念.服务连接类型定义了一组角色, 其中每个角色指明一种端口类型PortType(其实就是服务). 本质思想是,当两个服务交互时,服务连接类型就是对这两个服务如何交互的声明(阐明各方本质上提供了什么).
转过来说, BPEL通过服务连接类型来定义伙伴: 给伙伴一个名称,然后指明这个伙伴的服务连接类型的名称, 然后分别确定流程在这个服务连接类型中充当的角色和伙伴充当的角色. 回到上面的伙伴类型, 这样来看, 前两种的伙伴在服务连接类型中只有一种角色.

服务引用
当BPEL运行时, 伙伴必须解析为实际的WEB服务,所以伙伴实际上就是一个有类型的服务引用.其类型信息来自服务连接类型和其角色.至于伙伴如何绑定到特定的服务上, 那是支持BPEL服务器的事情, 例如Glassfish.