SOA 治理不是一组实践操作，而是很多彼此协调工作的系列操作实践。SOA 治理的每个方面都值得在以后的文章中进一步地深入讨论。此处的讨论仅是简单的概述。有关其中一些方面的更多信息，可以参阅本文最后的参考资料部分。
服务定义
SOA 治理最基础的方面就是监视服务的创建过程。必须对服务进行标识，必须描述其功能，确定其行为范围并设计其接口。治理 COE 可以不执行这些任务，但要确保有人执行这些任务。COE 对创建服务和需要使用这些服务的团队进行协调，以确保满足相关的需求，并避免重复工作。
通常，什么应该是服务这个问题的答案并不明显。功能应该与一组可重复的业务任务匹配。服务的边界应当封装一项可重用、不受上下文约束的功能。接口应该公开服务进行的工作，但要隐藏服务是如何实现的，并允许更改实现或采用替代实现。从头设计服务时，可以将其设计成对业务进行建模;包装现有服务时，创建并实现好的业务接口可能会更难。
定义服务边界的潜在困难的一个有意思的例子就是在何处设置事务边界。服务通常在自己的事务中运行，确保其工作要么完全完成，要么完全回滚。不过，服务协调程序(也称为协调器或编排器)可能希望在单个事务中调用多个服务(最好是通过指定的交互，如 WS-AtomicTransactions)。此任务要求服务接口公开其事务支持，以便能参与调用方的事务。但这样的公开要求对调用方信任，对提供者具有很大的风险。例如，提供者可能会锁定执行服务的资源，但如果调用方永远不完成事务(没有提交或回滚)，提供者将很难干净地释放资源锁定。正如这种情况所表明的，服务的范围以及谁具有控制权有时候并不太容易确定。
服务部署生命周期
服务并不会瞬间立即形成，然后永远存在。和任何软件一样，需要进行规划、设计、实现、部署、维护，并最后退役。应用程序生命周期可以为公开性的，从而影响组织的很多方面;但服务的生命周期的影响甚至可能更大，因为多个应用程序可能会依赖于单个服务。
当考虑使用注册中心时，服务的生命周期变得最为明显。何时应将新服务添加到注册中心?注册中心中的所有服务是否都具有必要的可用性，可以随时进行重用?是否应将已退役的服务从注册中心删除?
虽然并没有适合所有组织和所有服务的万用生命周期模式，不过，服务开发生命周期通常都具有五个主要的阶段：
已计划。已标识了新服务并正在设计中，不过尚未实现或正在实现中。
测试。实现后，必须对服务进行测试(稍后将对测试进行更详细的说明)。有些测试可能需要在生产环境中执行，此环境会将服务作为活动服务处理。
活动。这是服务可供使用的阶段，我们通常所谈说的服务实际是处于此阶段的服务。这是一个服务，处于可用状态，在实际运行并且确实可完成相应的工作，而且尚未退役。
已弃用。此阶段描述仍然处于活动状态但不会再存在很长时间的服务。这将警告使用者停止使用此服务。
已退役。这是服务的最后一个阶段，表示一个不再提供的服务。注册中心可以保存有关曾经处于活动状态但不再可用的服务的记录。此阶段是不可避免的，不过很多提供者或使用者都未将此阶段纳入计划中。
退役可以有效地关闭服务版本，应该事先对退役数据进行计划和公布。在退役前，服务应在一段合适的时间内处于已弃用状态，以便以编程方式警告用户，从而使他们据此进行相应的计划。弃用和退役计划应在 SLA 中指定。
此列表中可能不会出现的一个阶段是“维护”阶段。维护在服务处于活动状态时进行;可能会对服务重新进行测试，以再次验证其具有恰当的功能，不过这可能给依赖于活动服务提供者的现有用户带来问题。
维护在服务中出现的频率远比您可能预期的要低很多;服务的维护通常不会涉及到更改现有服务，而会产生一个新的服务版本。
服务版本治理
提供服务后不久，这些服务的用户就开始需要进行一些相应的更改。需要对问题进行修复，需要添加新功能，需要重新设计接口，还需要删除不需要的功能。服务反映业务的情况，因此，随着业务发生变化，服务也需要进行相应的更改。
不过，对于服务的现有用户，需要采用巧妙的方式进行更改，以便不会干扰他们的成功操作。同时，现有用户对稳定性的需求不能对用户希望使用其他功能的需求造成障碍。
服务版本治理可满足这些相互矛盾的目标。版本治理允许满足服务现有功能的用户继续以不变的方式使用服务，并同时允许对服务进行改进，以满足具有新需求的用户。当前服务接口和行为将保留为一个版本，而同时会将较新的服务作为另一个版本引入。版本兼容性允许使用者调用不同但兼容的服务版本。
版本治理可帮助解决这些问题，但同时也带来了一些新问题，例如需要进行迁移工作。
服务迁移
即使使用版本治理，使用者也不能期望永远提供和支持某个服务(或更准确地说，希望使用的一个服务版本)。服务提供者最终一定会停止提供此服务。版本兼容性可以帮助延迟这个“最后审判日”，但却不能消除这个问题。版本治理并不会使服务开发生命周期过时，而会允许生命周期扩展到多个连续的代。
当使用者开始使用服务时，将会创建对该服务的依赖关系，必须对此依赖关系进行管理。管理技术可用于有计划地周期性迁移到服务的较新版本。此方法还允许使用者利用添加到服务的新功能。
不过，即使在采用了最佳治理的企业中，服务提供者也不能仅依赖于使用者迁移。由于各种原因(遗留代码、人力、预算、优先级)，一些使用者可能无法及时地进行迁移。这是否意味着提供者必须永远支持相应的服务版本?提供者是否可以在所有使用者已进行了迁移后直接禁用相应的服务版本?
这两个极端都不甚合意。一个不错的折衷办法是为每个服务版本采用有计划的弃用和退役计划，如服务部署生命周期中所述。
服务注册中心
服务提供者如何提供和宣传其服务?服务使用者如何查找其希望调用的服务?这些都在服务注册中心的职责范围内。服务注册中心将担当可用服务清单的角色，并提供调用服务的地址。
服务注册中心还可以帮助进行服务版本的协调工作。使用者和提供者可以指定它们需要或提供的版本，注册中心将随后确保仅列举出使用者所需版本的提供者。注册中心可以管理版本兼容性，跟踪版本间的兼容性并列举出使用者所需的版本或兼容版本的提供者。注册中心还可以支持服务状态，如测试状态和(如前面提到的)已弃用状态，且仅向希望使用服务的使用者提供具有这些状态的服务。
当用户开始使用服务时，将在此服务上创建一个依赖关系。每个使用者清楚地知道其所依赖的服务，但在企业全局范围内，这些依赖关系可能很难检测，更谈不上管理了。注册中心不仅列出服务和提供者，还可以跟踪使用者和服务间的依赖关系。这个跟踪功能可以帮助回答一个很古老的问题：谁在使用此服务?可识别依赖关系的注册中心能向使用者通知提供者方面的更改情况，如某个服务变成了已弃用状态。
IBM 的 WebSphere Service Registry and Repository 是一款用于实现服务注册中心的产品。它担当服务定义的存储库以及这些服务的提供者的注册中心角色。它提供了一个中心目录，供开发人员查找可重用服务，并且在运行时使用，以便服务使用者和企业服务总线 (ESB) 查找服务提供者及调用服务的地址。
服务消息模型
在服务调用中，使用者和提供者必须就消息格式达成一致。当独立开发团队分开设计两个部分时，他们很容易陷入难于就公共消息格式达成一致的困境。再加上数十个使用典型服务的应用程序和使用数十个服务的典型应用程序，您就不难理解直接协商消息格式如何会变成需要全力投入来完成的任务。
用于避免消息格式混乱的一种常见方法是使用规范数据模型。规范数据模型是一组公共数据格式，独立于任何应用程序，由所有应用程序共享。这样，应用程序就不必就消息格式达成一致，可以直接同意使用现有规范数据格式。规范数据模型处理消息中的数据格式，因此仍然需要对消息格式的其他部分达成一致(如 Header 字段、消息有效负载包含什么数据以及数据如何安排)，但规范数据模型可极大地促进协议的达成。
中央治理委员会可以充当中立方，负责开发规范数据模型。作为应用程序调查和服务设计工作的一部分，还可以设计在服务调用中使用的公共数据格式。
服务监视
如果服务提供者停止工作，您如何知道呢?是否要等到使用这些服务的应用程序停止，使用这些应用程序的人开始抱怨，才会知道服务已停止了呢?
结合使用多个服务的组合应用程序的可靠性只与其依赖的服务的可靠性相当。由于多个组合应用程序可能共享一个服务，单个服务出现故障可能会影响很多应用程序。必须定义 SLA，以描述使用者可以依赖的可靠性和性能。必须监视服务提供者，以确保其达到了所定义的 SLA。
一个与此相关的方面是问题确定。当组合应用程序停止工作时，确定为什么会这样。这可能是由于应用程序用于与用户进行交互的 UI 停止了运行造成的。但也可能 UI 运行正常，但所使用的其他服务或这些服务使用的某些服务未正常运行。因此，务必注意，不仅要监视每个应用程序的运行状况，还要监视每个服务(提供者整体)和各个提供者的运行状况。单个业务事务中服务间的事件的相关性非常重要。
此类监视可以帮助在问题出现前检测和防止问题。可以检测不均衡和停机状况，能在这些情况造成重大影响前发出警告，甚至可以尝试自动纠正问题。可以对长时间的使用情况进行度量，以帮助预测使用率会变得更高的服务，以便为其提供更高的容量。
服务所有权
当多个组合服务使用一个服务时，谁负责此服务?是那个人或组织负责它们吗?如果是其中一个，是哪一个?其他人是否认为他们拥有这个服务的所有权?欢迎来到服务所有权的混沌世界。
无论是社区公园、可重用 Java 框架，还是服务提供者，任何共享资源都很难获得和得到相应的照顾。不过，所需的采用池化技术的资源可提供远远超过任何参与者成本的价值：公路系统就是这样。
企业通常围绕其业务操作组织员工报告结构和财务报告结构。SOA 采用相同的方式围绕相同的操作组织企业的 IT，负责特定操作的部门也可以负责这些操作的 IT 的开发和运行。该部门拥有这些服务。SOA 中的服务和组合应用程序经常并不遵循企业严格的层次报告和财务结构，从而在 IT 责任方面造成空白和重叠。
一个相关的问题就是用户角色。由于 SOA 的重点是保持 IT 和业务的一致，而另一个重点是企业重用，组织中很多不同的人员对什么将成为服务、这些服务如何工作以及将如何使用都有发言权。这些角色包括业务分析人员、企业架构师、软件架构师、软件开发人员和 IT 管理员。所有这些角色在确保服务正确为企业需求和工作服务方面都负有责任。
SOA 应该能反映其业务。这通常意味着要更改 SOA 来适应业务，但在这种情况下，可能有必要更改业务来与 SOA 匹配。如果不可能，则需要提高多个部门间的合作水平，以分担开发公共服务的任务。这样的合作可以通过跨组织的独立委员会来实现，此委员会实际上拥有服务，并对其进行管理。
服务测试
服务部署生命周期包括测试阶段，在此阶段，团队将在激活服务前确认服务能正确工作。如果测试了服务提供者，且表明其工作正常，使用者是否需要也对其进行重新测试?是否采用同样的严格要求对服务的所有提供者进行测试?如果服务更改，是否需要对其进行重新测试?
SOA 增加了以独立的方式测试功能的机会，并提高了对其按预期工作的期望值。不过，SOA 也为每个不一定信任服务的新使用者提供了重新测试相同功能的机会，以便确定服务一致地工作。同时，由于组合应用程序共享服务，单个存在错误的服务就可以对一系列看起来不相关的应用程序造成负面影响，从而扩大这些编程错误的后果。
为了利用 SOA 的重用好处，服务使用者和提供者需要就提供者合理的测试级别达成一致，并需要确保测试按照双方达成的协议执行。然后，服务使用者只需要测试自己的功能以及到服务的连接，并假定服务将按照预期的方式工作。
服务安全
是否允许任何人调用任何服务?具有一系列用户的服务是否允许其所有用户访问所有数据?服务使用者和提供者之间交换的数据是否需要进行保护?服务是否需要足够的安全，以满足其最偏执的用户或最懒散的用户的需求?
对于任何应用程序，安全是一个困难但必要的命题。功能需要限制为授权的用户，需要对数据进行保护，以防止被窃听。通过提供更多的功能访问点(即服务)，SOA 有可能会大幅度增加组合应用程序中的漏洞。
SOA 可创建非常容易重用的服务，甚至哪些不应该重用这些服务的使用者也能对其进行重用。即使在授权用户中，并非所有用户都应该具有服务能够访问的所有数据的访问权。例如，用于访问银行帐户的服务应该仅提供特定的用户帐户(尽管其代码也具有访问其他用户的其他帐户的权限)。一些服务使用者比相同服务的其他使用者具有更大的数据保密性、完整性和不可否认性。
服务调用技术必须能够提供所有这些安全功能。必须对服务的访问进行控制，且将访问权仅限于授权使用者。用户标识必须传播到服务中，并用于授权数据访问。数据保护的质量必须表示为相应范围内的策略。这就允许使用者说明最低级别的保护和最大功能，并能与可能实际包含其他保护的相应提供者进行匹配。
本文说明了为什么 SOA 治理对企业的 SOA 成功非常关键。治理涉及到建立相关职责和授权负责方，而管理则涉及到确保治理策略实际执行。技术不仅可以用于设置治理，也可以用于执行管理。服务调用期间管理的治理可以由 ESB 进行有效的管理，可简化提供者和使用者的职责。
