孰轻孰重：运行时 SOA 治理还是设计时 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 治理更重要，而是如何正确地实施它们。

查看英文原文： What Is More Important: Run-time or Design-time SOA Governance?