实施SOA是运行时治理还是设计时治理

David Linthicum在他最近的博文中定义了两大SOA治理的类别：

SOA治理技术有两类：运行时，或者说是加强服务策略执行的能力。以及设计时，或者说是支持服务策略的设计和实施的技术。策略用于放置在服务周围控制谁能访问服务以及能做什么的。

以Dave的观点，云计算正快速地成为很多企业最流行的趋势，它将有效地抹杀设计时的SOA治理，而倾向于运行时治理：

……关注运行时服务的执行能够带来更多的价值。许多现有的SOA治理的玩家都提供了足够的设计和实施的能力，所以单独的设计时工具是不再需要了。云计算单纯地加速了对运行时SOA治理的关注，而设计时治理迟早会退出历史舞台。

K. Scott Morrison的观点和Dave一致，他说到：

在SOA的大纪元中（2009年1月1日之前），设计时治理是王道。它非常符合大型企业级SOA的计划—管理—控制的原则……而相反，运行时治理却往往被看成可以拖一拖的工作……云转变了二者的优先级顺序。即使你在公有云中只部署一个服务，你也必须要准备好运行时的治理。

在他看来，设计时治理将不会完全消失，但是它将之在SOA的实现增长时才有价值（比较我原先的博文）：

最后，云中的治理优先级归根结底是一个非常简单的准则：一个功能的重复定义可能不至于导致你丢饭碗；而如果你为企业数据的破坏留下后门则有可能。

William Vambenepe进一步探讨了这个话题，他定义了一个SOA++模型（以服务中心的IT管理），统一了框架、 API、模型和工具：

所有IT资源……都可以被想象成可被消费的服务（如，由 hypervisor暴露的“X86+以太网模拟”服务、由应用服务器暴露的“J2EE兼容平台”服务、由数据库暴露的“RDB服务”、通过基于HTTP的SOAP或XML/JSON暴露的Web服务等等。）

只需简单地向服务提供者的API发送一个请求，它们可以像服务一样被建立起来。

它们不仅可以想服务一样被建立，而且还可以像服务一样通过良结构的文档（通常是标准的）接口调用。

它们还能以类似于服务为中心的方式进行管理，比如通过性能尺度，SLA，策略等。

你可能要必须处理三类编排代码（例如，当应用慢下来时，可能通过如下三种方式解决：修改应用的依赖，重新配置基础设施，或发起新的部署）。

这三类间的关系可能会跨越组织边界和引入外部提供者，还可能是收费的服务。

这样一来，你的IT自动化系统的确需要一个简单的、一致的、标准的方式去处理这些关系。在你已经已经简化并标准化（自动化将应用于的）环境之后，自动化的效果才能达到最佳。

在该模型中，服务或容器支持良定义的带有通过策略和SLA定义的质量需求的运行契约。其结果是，它们需要一个管理框架来监控这些策略和SLA、一个公共安全基础设施来度量或计费等——这就是一个完全丰满的运行时治理。

SOA和云计算之间的紧密合作点亮了运行时SOA治理的重要性，这固然很好，但是为了它而忽视了设计时治理似乎有失妥当。到头来，SOA的承诺依然是业务和IT的对齐，而如果服务的设计不再参照企业业务模型的分解，实践诺言是不可能的。这意味着设计时治理仍然是真正的SOA实施的核心所在。争论的焦点不该是哪个SOA治理更重要，而是如何正确地实施它们。