孰轻孰重:运行时 SOA 治理还是设计时 SOA 治理?

  • Boris Lublinsky
  • 马国耀

2010 年 2 月 1 日

话题:SOA治理云计算DevOps架构

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?

 

SOA治理云计算DevOps架构