Coordination
在介绍WS-Coordination规范前，首先让我们了解一下Coordination的概念以及它的应用背景。
简而言之,一个实体和一个活动的参与者之间传递消息的过程就可以称之为Coordination。例如在实现分布式事务时，就需要由事务管理器在各个资源管理器之间相互协调，并且由2PC（两阶段提交协议）规定了具体的协调过程。为了控制工作流的运行，也会需要使用协调者与工作流中的各个活动打交道。使用Coordination的目的可以是为了在多个参与者之间达成一致的结果，也可以仅仅是为了在某个特定的条件下让参与者都接收到在应用领域中某个特定的消息。
根据以上特点，不难推断在分布式领域中存在许多需要使用Coordination的应用。但是，在实际的应用中，不同的开发平台都使用各自不同的协调框架。比如在OASIS的Business Transactions Protocol和OMG的Object Transaction Service中同样为了实现分布式事务却各自设计了不同的协调框架。在这种情况下不仅出现了重复设计的问题，并且由于协调框架与事务处理框架的紧密结合，使得开发者无法灵活高效的使用到Coordination的功能。 因此设计出一个更加通用并且专门针对Coordination需求的框架，成为了一项非常有应用价值的任务。Coordination框架在事务处理，工作流管理甚至活动状态管理中都将发挥重要作用。
WS-Coordination
为了能够在Web Services的环境下拥有一个通用的协调框架，以解决各种需要使用协调功能的应用，BEA,IBM,MS等公司共同制定了WS-Coordination规范。WS-Coordination规范的一个重要特点就是它提供一个开放的协调框架，每个具体的应用都可以在此基础上设计自己的协调协议以控制整个协调过程，以达到各自的应用目的。比如在WS-AtomicTransaction规范中，设计了Completion和2PC(2 Phrase Commit)两套协议以实现Web Services组合活动的事务性。
WS-Coordination中的概念：
活动： 由一系列Web Services为实现某个功能组合而成的单元。
参与者： 活动中的某个Web Service。
协调者： 和活动参与者发生协调行为的实体。
协调类型： 根据协调过程的目的划分的类型。如WS-AtomicTransaction规范中定义的协调类型为AtomicTransaction。
协调协议： 协调过程中协调者与参与者消息交互过程(状态图)。如WS-AtomicTransaction规范中定义的Completion和2PC(2 Phrase Commit)两套协议。
协调协议服务：根据协调协议创建的服务，用于协调消息的传递。服务以Web Service的形式存在。如WS-AtomicTransaction规范中为Completion和2PC协议，分别在协调者和参与者之间创建的服务，服务中定义了协调消息交换的具体格式。
协调服务： 包含组成协调框架的激活服务，注册服务和特定的协调协议服务。
在详细介绍WS-Coordination之前，首先了解一下作为一个通用协调框架所应该具有的功能：
1. 根据协调类型，创建出具体的协调协议服务。
2. 在活动的参与者与Coordinator之间建立联系，以便接收协调协议中的消息。
3. Coordinator与活动参与者之间传递协调消息。
为了实现以上的功能需要协调服务的支持，下面就协调服务中各个具体服务做详细介绍:
Activation Service
激活服务提供了根据申请的协调类型创建出相应的协调协议服务和Coordination Context的功能。由于该服务是异步的，所以在服务的请求方和服务的实现方都定义了相应的接口，其中服务实现方提供启动激活功能的接口，而服务请求方提供将激活结果返回的接口。Activation Service的WSDL文件如下所示：
<!-- Activation Service portType Declaration -->
<wsdl:portType name="ActivationCoordinatorPortType">
<wsdl:operation name="CreateCoordinationContext">
<wsdl:input message="wscoor:CreateCoordinationContext"/>
</wsdl:operation>
</wsdl:portType>
<!-- Activation Requester portType Declaration -->
<wsdl:portType name="ActivationRequesterPortType">
<wsdl:operation name="CreateCoordinationContextResponse">
<wsdl:input message="wscoor:CreateCoordinationContextResponse"/>
</wsdl:operation>
<wsdl:operation name="Error">
<wsdl:input message="wscoor:Error"/>
</wsdl:operation>
</wsdl:portType>
List 1 Activation Service WSDL Interfaces
激活服务成功运行的返回结果是CoordinationContext，利用CoordinationContext可以将协调信息随应用服务中消息向所有的参与者传播，这样就可以将它们加入到整个协调框架中，从而进一步建立协调协议服务与参与者之间的联系。由此可见激活服务实现了对通用协调框架所要求的第一个功能，并且为实现第二个功能提供了必要的条件---CoordinationContext。
CoordinationContext中包含了协调过程标识符，协调类型，Registration Service的引用地址以及其他一些针对特定应用领域的扩展信息。而Registration Service的引用地址在其中最为重要，利用它参与者才能使用注册服务建立与协调服务的联系。
以下是协调类型为AtomicTransaction的激活服务的请求和响应的SOAP消息示例：
<soapenv>
<soapbody>
<wscoor:CreateCoordinationContext>
<ActivationService>
<Address>
http://myActiviationService
</Address>
</ActiviationService>
<RequesterReference>
<Address>
http://myApplicationProgram
</Address>
</RequesterReference>
<CoordinationType>
http://xml-soap.org/2002/xx/AtomicTransaction
</CoordinationType>
</wscoor:CreateCoordinationContext>
</soapbody>
<soapenv>
List 2. 发送CreateCoordinationContext 请求
<soapenv>
<soapbody>
<wscoor:CreateCoordinationContextResponse>
<RequesterReference>
<Address> http://myApplicationProgram </Address>
</RequesterReference>
<CoordinationContext>
<Identifier>
http://myCoordinationService/ts/activity1
</Identifier>
<CoordinationType>
http://xml-soap.org/2002/xx/AtomicTransaction
</CoordinationType>
<RegistrationService>
<Address>
http://myCoordinationService/tm/myRegistrationService
</Address>
</RegistrationService>
</CoordinationContext>
</wscoor:CreateCoordinationContextResponse>
</soapbody>
</soapenv>
List 3. 协调服务返回一个协调上下文
Registration Service
当Activation Service创建出Coordinator之后，Registration Service也随之被创建出来， 并且可以通过CoordinationContext获得其引用地址。
活动的发起者在调用Activation Service创建新的Coordinator后得到CoordinationContext。此时，它将把获得的CoordinationContext附在调用Web Services的SOAP请求的Head中，随着SOAP请求依次发送给各个参与者服务。这样各个参与者就获得了Registration Service的引用地址，利用Registration Service，参与者就可以建立自己与Coordinator的联系，并根据注册协议的类型接受和发送某个特定协调协议服务的消息，从而与Coordinator产生交互完成协调的过程。与Activation Service一样，Registration Service也支持异步的使用方式，服务响应和请求两端的WSDL文件分别如下所示：
<!-- Registration Service portType Declaration -->
<wsdl:portType name="RegistrationCoordinatorPortType">
<wsdl:operation name="Register">
<wsdl:input message="wscoor:Register"/>
</wsdl:operation>
</wsdl:portType>
<!-- Registration Requester portType Declaration -->
<wsdl:portType name="RegistrationRequesterPortType">
<wsdl:operation name="RegisterResponse">
<wsdl:input message="wscoor:RegisterResponse"/>
</wsdl:operation>
<wsdl:operation name="Error">
<wsdl:input message="wscoor:Error"/>
</wsdl:operation>
</wsdl:portType>
List 4 Registration Service WSDL Interface
当参与者使用Registration Service完成注册后，得到一个返回结果其中包含了所注册协调协议的服务地址。此时在协调服务与参与者之间建立了一个双向联系。参与者可以从Coordinator处接收到它所注册的协调协议中的消息(如2PC协议中的Prepare消息)，如果协议支持参与者也可以向Coordinator发送消息(如2PC协议中的Prepared消息)。
以下参与者向Registration Service注册2PC协议的请求和响应的SOAP消息示例：
<soapenv>
<soapbody>
<wscoor:Register>
<RegistrationService>
<Address>http://myRegistrationService</Address>
</RegistrationService>
<RequesterReference>
<Address>http://myDatabaseWebService</Address>
</RequesterReference>
<ProtocolIdentifier>
http://xml-soap.org/2002/xx/AtomicTransaction/2PC
</ProtocolIdentifier>
<ParticipantProtocolService>
<Address>http://myResource</Address>
</ParticipantProtocolService>
</wscoor:Register>
</soapbody>
</soapenv>
List 5. 发送Register请求
<soapenv>
<soapbody>
<wscoor:RegisterResponse>
<RequesterReference>
<Address> http://myDatabaseWebService</Address>
</RequesterReference>
<CoordinatorProtocolService>
<Address> http://myCoordinator </Address>
</CoordinatorProtocolService>
</wscoor:RegisterResponse>
</soapbody>
</soapenv>
List 6. 注册服务返回协调协议服务的引用地址
Coordination Process
下面将对Coordination工作的过程做简要描述：
在如下的一个活动(服务组合)中：
public Result CompositionService(Parameter p)
{
Result a=ServiceA(p);
Result b=ServiceB(p);
Result c=ServiceC(p);
return a+b+c;
}
其中ServiceA, ServiceB, ServiceC都是Web Services, CompositionService可以是Web Service也可以不是。
CompositionService是活动的发起者，如图中的Application Service所示，而ServiceA, ServiceB, ServiceC都是活动的参与者也就是图中Participant Service。图中的Coordinator部分已经在前面详细介绍过，在此不再重复。
1． 活动发起者（即Application Service）请求创建Coordinator（包括Coordination Context, Registration Service, Coordination Protocol Service）。
2． 根据请求中给定的协调类型，返回相应的Coordination Context，其中包含了Registration Service的引用地址，如图中蓝色虚线所示。
3． 如果协调类型需要，活动发起者使用注册服务将自己的引用地址注册到相应的Coordination Protocol Service上。
4． 注册服务将活动发起者所注册的Coordination Protocol Service的引用地址返回给活动发起者，如图中红色虚线所示。
5． 活动发起者依次调用活动中包含的Web Services（即Participant Service），并将在步骤2中获得Coordination Context添加到服务请求的SOAP Head中。
6． 和步骤3类似，Participant Service使用Coordination Context中包含的Registration Service的引用地址将自己注册到相应的Coordination Protocol Service上。通常来说步骤6是必须的而步骤3视具体应用而定。
7． 注册服务将活动发起者所注册的Coordination Protocol Service的引用地址返回给Participant Service，如图中红色虚线所示。
通过以上7个步骤(其中3,4可选)，Participant Service和Coordinator之间建立起了双向联系，之后它们就可以根据具体的协调协议开始针对某个应用目的的协调过程。
Summary
在本文中介绍了有关WS-Coordination规范的产生背景，并详细介绍了Coordinator中所包含的功能，最后给出了使用该规范在Coordinator和Participant Service之间建立协调关系的具体过程。由于本文主要介绍WS-Coordination规范，所以没有介绍在建立协调关系后针对某个应用的协调过程。在WS-AtomicTransaction和WS-BussinessActivity规范中介绍了如何实现活动事务性的协调协议，读者可以参考它们的基础上设计自己的协调协议以实现特定的应用目的。
下面给出WS-AtomicTransaction规范中制定的两个协调协议的状态图，以供参考：
Completion Protocol
The coordinator accepts:
Commit
Upon receipt of this notification, the coordinator knows that the participant has
completed application processing and that it should attempt to commit the
transaction.
Rollback
Upon receipt of this notification, the coordinator knows that the participant has
terminated application processing and that it should abort the transaction.
The initiator accepts:
Committed
Upon receipt of this notification, the initiator knows that the coordinator reached
a decision to commit.
Aborted
Upon receipt of this notification, the initiator knows that the coordinator reached
a decision to abort.
2PC Protocol
The participant accepts:
Prepare
Upon receipt of this notification, the participant knows to enter phase 1 and vote
on the outcome of the transaction. If the participant does not know of the
transaction, it must vote to abort. If the participant has already voted, it should
resend the same vote.
Rollback
Upon receipt of this notification, the participant knows to abort, and forget, the
transaction. This notification can be sent in either phase 1 or phase 2. Once
sent, the coordinator may forget all knowledge of this transaction.
Commit
Upon receipt of this notification, the participant knows to commit the transaction.
This notification can only be sent after phase 1 and if the participant voted to
commit. If the participant does not know of the transaction, it must send a
Committed notification to the coordinator.
The coordinator accepts:
Prepared
Upon receipt of this notification, the coordinator knows the participant is
prepared and votes to commit the transaction.
ReadOnly
Upon receipt of this notification, the coordinator knows the participant votes to
commit the transaction, and has forgotten the transaction. The participant does
not wish to participate in phase 2.
Aborted
Upon receipt of this notification, the coordinator knows the participant has
aborted, and forgotten, the transaction.
Committed
Upon receipt of this notification, the coordinator knows the participant has
committed the transaction. That participant may be safely forgotten.
Replay
Upon receipt of this notification, the coordinator may assume the participant has
suffered a recoverable failure. It should resend the last appropriate protocol
notification.
参考资料：
WS-Coordination Specification
WS-AtomicTransaction Specification
