【IT168 分析评论】
正如许多正在实施SOA计划的企业经过艰难努力所学到的那样，SOA治理不是一个可有可无的选择。相反，SOA治理对于SOA应用的长期健康发展和有效性都是非常重要的。使用SOA治理中特别具有挑战性的是SOA架构中的一些互动软件。一些具有超前意识的机构已经转向SOA治理自动化以帮助管理这个艰巨的任务。本文提供了一系列简单的技巧和策略以提高选择和使用SOA治理技术的成功率。下面是改善SOA治理结果的10个策略。
策略1：将SOA治理技术作为你的整个SOA路线图的一部分
应用范围：服务生命周期的所有阶段
许多机构落入陷阱之中，把SOA治理推迟到SOA服务运行大部分业务之后。等待做出这个决定通常意味着一旦你选择了一个治理基础设施，你就需要付出额外的努力、成本和开销。更新所用的时间总是超过原来的预期，并且要消耗宝贵的资源。这些增加的负担能够破坏整个SOA计划。由于这些理由，你不要等待有“足够的”服务之后再考虑SOA治理，这是非常重要的。由于许多SOA计划都依赖一个架构委员会的观点，治理的话题肯定要列入这些工作组的议事日程。
策略2：保证你的治理平台不依赖于任何服务部署技术
应用范围：设计时间
当谈到从不同的机构抽调软件开发人员的时候，肯定会引起争议的一个问题是关于.NET和Java相对优点的争论。当选择一个治理平台的时候，最重要的是选择的技术至少能够兼容用Java和.NET开发的服务。如果你的治理平台仅支持一种开发技术，你最终就要安装许多治理软件。
当选择治理平台的时候，下一个重大决策是决定选择开源软件解决方案还是专有的产品。
开源软件的好处包括：
·减少锁定一家厂商的可能性。
·遵守许多企业内部的基础设施软件规定中的“仅使用开源软件”的政策。
·减少财务开支，让企业更有可能选择这种治理软件。
专有的解决方案的好处包括：
·把设计、开发和管理工具牢固地集成在一起。
·更简单地“一站式购买”，简化许多事情，同时产生更好的“开箱即用”的体验。
·一个日益增长的趋势是软件厂商以开源软件的方式提供自己的解决方案。
策略3：保证你的治理平台能够支持全面的服务部署技术
应用范围：设计时间
虽然许多人错误地认为Web服务是实施SOA的唯一方法，但是，还有许多其它技术能够同样好地完成这个工作。这些技术包括Java对象、CORBA和其它服务实施技术。考虑到这些事实，无论你选择什么实施策略，你的治理平台能够识别和兼容广泛的服务是非常重要的。治理解决方案应该尽可能地不受干扰，因为它不可能修改你的机构现有的服务。
如果你不能选择一个满足这些要求的解决方案，那么，你就只能治理你的企业的一部分，或者需要部署多个治理平台。这两个结果都是不理想的。部分治理与根本没有治理差不多。许多管理员和程序员在克服与治理有关的问题时都选择了错误的道理从而浪费了许多时间。
策略4：认识到测试作为你的整个SOA治理责任的一部分的重要性
应用范围：测试和治理保证
一个令人遗憾的事实是，质量保证经常在软件开发的各种要素中摆在次要的位置。虽然这在制造传统的竖井式的应用程序时也许是可以容忍的，但是，这种做法在实施SOA的机构中不行的。由于服务构成了多个应用程序的基础，用适当的时间和注意力进行测试是非常重要的。治理保证的整个范围也将扩大：重要的是你的测试要超越单个的服务，包含多个服务的复杂的组合。组合测试通常需要大量的性能驱动的回归测试。由于运行时间组合应用是很难分辨的，也许有必要使用观测或者其它监视技术确定真正的服务相互作用。最后，由于服务和治理的关系非常密切，认真考虑把你选择的测试软件结合到你的整个治理环境中是明智的。
策略5：搜集重要的与治理有关的测量结果并且定期进行评估
应用范围：运行时间
现代治理平台能够捕捉大量的运行数据。这种信息的真正质量是很高的。遗憾的是，当面对海量的统计数据时，管理员会忽略这些数据，除非有需要直接修改的问题。这里的教训是仅仅搜集测量数据是不够的，你需要评估这些数据并且对这个数据采取行动。你可以使用许多智能产品了解你搜集到的海量数据的意义。
策略6：通过多个IT资源层跟踪活动
应用范围：测试与质量保证/运行时间
虽然一个面向服务的计划旨在把商务逻辑集中到一个可再利用的、可组合的服务集合中，但是，重要的是不要忘记这些服务通常要面对许多现有的资源，如数据库、应用服务器、对象等等。这个结果是一个架构由许多“移动部件”组成。由于这些潜在的故障点，这些问题很难解决是很自然的。简单地找到这个问题的根源就是一个繁重的任务。在许多情况下，这个问题不是服务的错误，而是底层资源的问题。
然而，用户并不在乎问题发生在什么地方，他们只需要解决问题(或者避免这些问题!)。如果要解决这个现实问题，重要的是你的治理平台除了跟踪和解决传统的Web服务问题之外还能够监视和解决其它问题。通过向管理员提供所有技术资源的全景图，一个设计良好的解决方案能够帮助阻止发生这些问题，帮助迅速解决发生的任何问题。
策略7：消除存储与注册之间的障碍
应用范围：运行时间
这两类产品之间存在许多混淆的概念，包括不同的定义和对责任的解释。然而，不管这些产品的具体解释是什么，这两种产品在有效的SOA实施中都发挥着重要作用，包括在设计和运行时间阶段。下面解释这两种产品在这两个重要阶段是如何使用的。
服务注册回答下列设计时间问题：
·服务在哪里?
·它的目的是什么(通常是简短的回答)?
服务注册回答下列运行时间问题：
·这个服务的版本是什么?
·这个服务的合同在什么地方?
·这个服务的政策实际上是什么?
服务存储回答下列设计时间问题：
·它的目的是什么(通常是简短的回答)?
·这个服务的版本(包括代码)是什么?
服务存储回答下列运行时间问题：
·谁在一直使用这个服务?
·这儿服务提供的响应类型是什么?
·这个服务发生了什么问题?
最后,重要的是指出许多厂商正在积极地把注册和存储结合在一起。无论你是否采用集成的解决方案，明智的做法是保证你的投资能够解决上述问题。
策略8：当选择一个治理产品的时候，写一个计划良好的正式的RFP
适用范围：所有的阶段
首先，重要的是你要知道你需要什么：没有任何东西可以替代家庭作业和准备。在选择数据库、应用服务器或者其它关键的基础设施技术的时候，你要采取同样的原则和流程。不要试图采用一个样板的RFP(征求建议书)，要保证它反应你们的机构的需求。
如果你不能编写这种文件，你可以认真考虑雇佣一个不依赖于任何厂商的外部咨询机构为你编写一个文件，然而，你要记住，如果你利用外部的帮助进行设计或者实施你的SOA，要设法把创建RFP的过程与技术厂商分开。这很容易想到严重的利益冲突。接下来，让厂商认真考虑你的RFP并且做出相应的答复，重点是质量而不是数量。最后，一旦你缩小了选择的厂商的范围，通常是要求这些厂商参加一个试验计划或者概念证明。
策略9：避免需要修改代码的治理工具
应用范围：设计时间和运行时间
为了提高效率，有些产品需要修改一些代码，如加入特殊的头文件，设置文件或者连接专有的库。这需要开发人员完全遵守规定。即使在最优惠的条件下，这也是很难获得的。如果部署一个没有这些增加的组件的服务，你就不能获得你的环境的真实的情况，从而导致基于不完整的和不准确的数据的错误决策。除了使你的开发人员的生活更复杂和减少有效的治理的可能性之外，这种专有的扩展还会严重地破坏你的不依赖于任何厂商的机会。由于这些原因，你部署的任何治理解决方案都要尽可能地在没有干扰的情况下工作是非常重要的。
策略10：要保证治理工具适合你现有的IT环境
应用范围：运行时间
对于大多数机构来说，实施一项面向服务的计划都要采用许多新的工具集、流程和方法。治理仅仅是增加的一项考虑因素之一。不过，需要指出的是这对于大多数企业来说都不是一个新的话题。事实上，以IT为重点的治理技术已经存在多年了。一些最知名的产品包括Tivoli、OpenView和Unicenter。这些软件频繁地用来监视服务器、客户机、网络和软件应用程序的健康。IT机构对于这些解决方案有广泛的知识并且依靠这些知识保持业务顺利地运行。
随着服务成为你的计算基础设施的较大的一部分，强迫你的IT机构学习和维护完全不同的工具集是不明智的。理想的情况是你的SOA治理工具应该与其它IT管理平台集成在一起。过度的复杂性和培训的需求会减少治理软件使用的机会。
