实现 TCS 

    面向服务的体系架构包含一组服务，每个服务需要特定系统资源来执行其工作。一个预定服务可能需要有权安排信息，而一个发货服务可能需要调用上述的预定服务来安排一个特定的发送给客户的存货条目。服务可以声明其功能、向注册中心提交此信息，并提供安全通信。TCS 可以在事务过程中利用此信息，定位正确的服务集、发现其功能，并依次向每个服务传递环境信息。

    资源发现和注册（UDDI）

    TCS 可以通过两种方式了解到哪个服务参与到事务中：每种都是计划性的，通过服务协调者在给 TCS 的注册消息中指定服务细节，或者通过在注册中心中进行查询。UDDI (Universal Description Discovery and Integration) 注册规范设计让服务实现者连同集成信息（例如安全性、事务意识、恢复等）一起注册服务。

    资源功能声明（策略）

    事务中涉及的服务需要对 TCS 声明其功能。 6 特别地，一个服务必须声明其处理事务的能力，或者如果它不能（举例来说，CreateOrder 服务必须拥有 CancelOrder 服务），就要提供补偿服务。此外，功能声明说明了安全策略，以便多种服务可以参与安全事务通信。

    安全（验证或授权）

    服务负责实现安全性。安全策略 7 定义用于在 TCS 和服务之间创建一个安全访问通道的声明。策略定义了安全协议及 TCS 和服务之间的安全互通性所需的信任通道。

    分布式环境中的并发控制

    除了服务所需的其他资源管理以外，处理并发的能力是纠正事务管理的关键。每个参与 TCS 中事务的服务必须能够确保事务过程中执行的变更不被其他事务覆盖。 8 例如，一个事务开始时，用新购买的产品更新客户订单。在该订单处理时，另一个事务开始取消某些变更。如果这些事务冲突了，那么要取消的产品将被替代，其他将要被供应的可能取消 —— 一点也不管客户要的内容！

    因此，当服务参与事务时必须实现某种形式的数据加锁或发布策略。这与关系数据库中为了维护多个并发事务所使用的操作类似。这些策略包括检查每个操作的时间戳及为进度确定的正确顺序，以及什么时候或如何锁定记录（举例来说，乐观的 vs 悲观的加锁）。最后，当资源出现死锁（一个服务持有另一个服务需要的锁，反之亦然）时，服务将需要实现某种形式的死锁消除。 9

    恢复及重试

    TCS 的最后一个需求是在事务失败时实现重试及恢复。要考虑两种事务失败：第一种是所有服务都能够参与事务时，而第二种是包括一个或多个不能参与事务的服务。在第一种情况下，TCS 可以使用两阶段提交协议 10 来管理事务步骤。在第二种中，服务必须拥有补偿服务来考虑第一种动作的取消。第一种情况的一个典型的例子是所有的服务访问标准的关系数据库（其实现了两阶段提交），或者由 OpenGroup X/Open transaction 语义定义。 11 第二种（不幸地是更加通用）的一个实例是在服务完成处理时提交操作 —— 例如对饭店预定利用饭店的 Web 服务接口。

    TCS 也可以实现重试语义。在这种情况下，TCS 将长期执行的事务存储到持久存储设备上，并且试图在较后的时间完成事务。例如，如果在购买旅行计划的地方建立事务，那么航空预定部分也许在饭店、汽车、高尔夫、正餐、巡航等部分之前完成。TCS 可能在舍弃初始的航空预定之前推选重试任一或所有余下的事务单元。这是“保险的”事务的一个实例，TCS 将试图通过多次重复提交失败单元来完成事务。

    在面向服务的体系架构中实现事务的挑战

    存在许多在面向服务的体系架构中实现事务管理才有的挑战。首要的是服务自身的特性：服务是松散耦合的，所以它们试图成为无状态、异步、分布式，且不透明的。无状态的服务意识不到事务状态，因此如果事务失败时，不能请求它们“回滚”一组变更。如果按照 Web 服务来实现一个服务，那么当前的协议利用 Internet 的异步特性，这意味着服务不能够及时地对请求进行响应。对于并行操作，这不是一个因素，但考虑当事务是串行的且来自一个服务调用的信息可能是其他服务调用所需时。

    以 Web 服务形式实现的服务是可以在任何位置访问到的，因此它们是分布式的定义的，对潜在性、可靠性，和安全性的关注的引入影响了事务管理。

    最后，服务只是由对 TCS 的确定接口可知的，在服务处理的内部没有详细信息。这导致“黑盒”使用模式，一个服务在不知道客户端知识的情况下利用其他服务，因而传播带有二次影响的变更。对于事务，这可能意味着，作为事务一部分的服务可能调用了同是该事务一部分的另一个服务。这可能导致重要的并发问题，因为第一个调用可能更改了第二个所需的数据，导致一个很难跟踪的问题。

    假设存在所有这些挑战，创建一个可靠的 TCS 对任何实现面向服务的体系架构的人来说都是困难的任务。TCS 必须能够管理带有嵌套、并发、安全、进度，及本文中所讨论的所有其他问题的任意复杂的事务。因此一个可怜的服务架构师能做什么？本文的第二部分将通过介绍一个事务控制服务的候选架构来解决这些问题。