SOA治理的最佳实践

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

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

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

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

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

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

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

　　多一点宽容

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

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

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

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

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

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

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