泡泡网企业频道 PCPOP首页      /      正文

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

0人已赞

关注我们

泡泡网

手机扫码关注