SOA治理的实践
2008-11-26  作者:佚名 

  SOA治理的最佳实践

  SOA治理本质上是社会性的,因此,需要开发人员和架构师不断沟通。

  1.建立评估小组。治理策略的制定、维护和修改应该通过一个小组进行,而不是某些人的独断行为。

  2.先开发一个交互性的框架。标准是SOA的基石,从一开始,就要建立一个可扩展的提供交互功能的框架,详细记录组织中使用的协议。

  3.不要太具体。过于详细的策略是很难维护的,也会约束创造力。为了降低企业应用的风险,要留有机动余地。

  4.尽早、尽可能频繁的交流。策略决不是一次就可以解释清楚的,管理人员需要确信修改是否已经传达到位,整个过程都需要有反馈。

  5.建立COE(CenterofExcellence)。在大型组织中,COE中有专职人员支持SOA,包括SOA治理。有效的COE可以为SOA项目提供指导和培训,从而使得SOA治理工作更集中。

  6.严格执行既定的策略。没有执行,策略就毫无价值。尽可能把策略融入服务中,否则,就要让开发人员了解违反这些策略的严重后果。

  多一点宽容

  SOA治理和SOA本身一样,不是绝对的。你希望建立一个广泛的、模块化的IT环境,能提供给企业以前所未有的灵活性,然而,要设想出每一个变化是不现实的——你也不能指望制定出一组策略能把未来的所有情况都考虑进来。

  这就是提出“多一点宽容”的原因。SOA应用涉及真实的业务交易,因此,需要详细而且是仔细的规则以及正式的变更管理。但是在某些情况下,比如说Web2.0类型的应用中,开发人员可以多发挥一些自己的创造性,而不用拘泥于架构小组的死规定。

  CheapGas是一个大型的网站,它帮助用户在指定区域中寻找离自己最近、最便宜的供气站。CheapGas借用了Google的地图服务和另一个网站GasBuddy.com的数据服务。与大多数企业级的Web服务不同,CheapGas几乎就没有采用什么治理。尽管也采用了一些标准,比如HTTP、GoogleMapsAPI等,但是那些在一些大型关键企业级应用中常用的WS*协议几乎无一采用。

  Influence公司的CTODionHitchcliffe说:“如果使用Web服务90%是用于展现数据,那最好采用RSS,而不是SOAP。”RSS通过HTTP交付数据采用一种非常“宽容”的格式,非常可靠,很少发生意外。SOAP有它的适用领域,但是更简单、更能容错的方法通常能更快地提交结果,也更容易被采用。选择使用哪种方法取决于你的应用和你所能接受的风险程度。

  在《DesignRules》一书中,作者描述了在软件架构的设计规则指导下,架构如何让设计人员自由地试验各种不同的方法。作者认为这种试验能产生很大的价值,相反,过于严格的治理将束缚开发者的双手,导致SOA的价值大打折扣。

  需要SOA治理还有一个原因是要选择安全Token,到底是要支持SAML、Kerberos,还是别的什么标准?变通的方法是支持各种安全Token,不过这需要部署Token交换服务。

  包容多种协议与治理并不矛盾,它们是互为补充的。你的服务包容性越强,建立更健壮的系统时,治理就越少。一个定义得非常合理的服务的最大回报在于,它能以一种开发者没有专门为之设计的地方和方式使用,从而发挥出设计者所没有想到过的价值。这也真是SOA所追求的最大目标。