SOA 治理的各个方面

　　SOA 治理不是一组实践操作，而是很多彼此协调工作的系列操作实践。SOA 治理的每个方面都值得在以后的文章中进一步地深入讨论。此处的讨论仅是简单的概述。有关其中一些方面的更多信息，可以参阅本文最后的参考资料部分。

　　服务定义

　　SOA 治理最基础的方面就是监视服务的创建过程。必须对服务进行标识，必须描述其功能，确定其行为范围并设计其接口。治理 COE 可以不执行这些任务，但要确保有人执行这些任务。COE 对创建服务和需要使用这些服务的团队进行协调，以确保满足相关的需求，并避免重复工作。

　　通常，什么应该是服务这个问题的答案并不明显。功能应该与一组可重复的业务任务匹配。服务的边界应当封装一项可重用、不受上下文约束的功能。接口应该公开服务进行的工作，但要隐藏服务是如何实现的，并允许更改实现或采用替代实现。从头设计服务时，可以将其设计成对业务进行建模;包装现有服务时，创建并实现好的业务接口可能会更难。

　　定义服务边界的潜在困难的一个有意思的例子就是在何处设置事务边界。服务通常在自己的事务中运行，确保其工作要么完全完成，要么完全回滚。不过，服务协调程序(也称为协调器或编排器)可能希望在单个事务中调用多个服务(最好是通过指定的交互，如 WS-AtomicTransactions)。此任务要求服务接口公开其事务支持，以便能参与调用方的事务。但这样的公开要求对调用方信任，对提供者具有很大的风险。例如，提供者可能会锁定执行服务的资源，但如果调用方永远不完成事务(没有提交或回滚)，提供者将很难干净地释放资源锁定。正如这种情况所表明的，服务的范围以及谁具有控制权有时候并不太容易确定。

　　服务部署生命周期

　　服务并不会瞬间立即形成，然后永远存在。和任何软件一样，需要进行规划、设计、实现、部署、维护，并最后退役。应用程序生命周期可以为公开性的，从而影响组织的很多方面;但服务的生命周期的影响甚至可能更大，因为多个应用程序可能会依赖于单个服务。

　　当考虑使用注册中心时，服务的生命周期变得最为明显。何时应将新服务添加到注册中心?注册中心中的所有服务是否都具有必要的可用性，可以随时进行重用?是否应将已退役的服务从注册中心删除?

　　虽然并没有适合所有组织和所有服务的万用生命周期模式，不过，服务开发生命周期通常都具有五个主要的阶段：

　　已计划。已标识了新服务并正在设计中，不过尚未实现或正在实现中。

　　测试。实现后，必须对服务进行测试(稍后将对测试进行更详细的说明)。有些测试可能需要在生产环境中执行，此环境会将服务作为活动服务处理。

　　活动。这是服务可供使用的阶段，我们通常所谈说的服务实际是处于此阶段的服务。这是一个服务，处于可用状态，在实际运行并且确实可完成相应的工作，而且尚未退役。

　　已弃用。此阶段描述仍然处于活动状态但不会再存在很长时间的服务。这将警告使用者停止使用此服务。

　　已退役。这是服务的最后一个阶段，表示一个不再提供的服务。注册中心可以保存有关曾经处于活动状态但不再可用的服务的记录。此阶段是不可避免的，不过很多提供者或使用者都未将此阶段纳入计划中。

　　退役可以有效地关闭服务版本，应该事先对退役数据进行计划和公布。在退役前，服务应在一段合适的时间内处于已弃用状态，以便以编程方式警告用户，从而使他们据此进行相应的计划。弃用和退役计划应在 SLA 中指定。

　　此列表中可能不会出现的一个阶段是“维护”阶段。维护在服务处于活动状态时进行;可能会对服务重新进行测试，以再次验证其具有恰当的功能，不过这可能给依赖于活动服务提供者的现有用户带来问题。

　　维护在服务中出现的频率远比您可能预期的要低很多;服务的维护通常不会涉及到更改现有服务，而会产生一个新的服务版本。