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治理更重要，而是如何正确地实施它们。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。