从SOAD到SOAG

　　从早先SOA 概念的提出，到如今SOA 的观念逐渐被大家正确认识，现在大家的观念已经不仅仅停留在 SOA 解决方案的构建和设计，也就是SOAd (SOA development)的阶段。因为 SOA 不仅仅是像企业服务总线 (Enterprise Service BUS)这样的技术，而是包括面向 SOA 的软件开发生命周期管理。

　　SOA并非仅是一次服务实践、或一套工具，而是确定最佳实践、方法论、工具、多个切入点，以及对整个生命周期进行改革的整体观点。应当在整个生命周期阶段的端到端治理环境下，完成上述措施，部署的过程应当是自动的、渐进式的。在整个生命周期阶段，应制订相应的战略。

　　如今非常多的 CIO 开始转型。他们开始认识到，SOA不仅仅是如何运用 IT 来构建 SOA 应用，如何设计和开发 SOA 应用;而是进一步，如何更好地管理 IT 和业务需求，并使两者能平衡发展。

　　治理和管理需求

　　SOA是一项引人注目的技术，用于开发与业务模型保持最佳一致性的软件应用程序。不 过，SOA 会提高业务和信息技术以及 IT 部门和各个团队间所需的合作和协调级别。这个合作和协调是通过 SOA 治理提供的，涵盖了用于指定和管理如何支持服务和 SOA 应用程序的各个任务和流程。

　　没有一个完善的 SOA 治理解决方案，企业所实施的 SOA 应用将会面临巨大的风险。也就是说，当企业开始构建起自己的 SOA 应用时，将不得不面对如何治理SOA 解决方案整个生命周期的问题。这就是 IBM 提出的“SOA 治理” (SOA governance) 观念。

　　什么是SOA 治理？

　　“SOA 治理”包括什么?这包括了在 IT 层面的治理观念，还有针对 SOA 的治理框架。从 IT 的角度来看，需要有一个能管理和跟踪整个 SOA 应用的生命周期的机制，也就是一个能管理从发现业务需求，到转变业务需求为 IT 实现，并在运作中跟踪业务需求最终价值的实现的机制。然后是运用什么样的管理政策和系统，来监控管理这些决定企业业务能否成功的因素，来确保企业在所有的 环节都在进行着这些环节所应该做的事情。建立连锁责任关系的状态。包括授权、决策等。为了对正在开展中的活动进行动态地评估，制定政策并对整个生命周期进 行控制，并与业务建立联系，这对于确定连锁责任关系以及授权至关重要。

　　如果用一句话来总结，“SOA 治理”其实就是如何来监控 SOA 的整个生命周期。也就是用怎样的方法论来发现业务需求，来打包服务，使之组件化，组成一个完整的 SOA 应用;并在这一过程中，用什么样的方法论来管理，并随着市场上的变化，来更改业务需求，使整个 SOA 应用能跟进和适应新的业务需求;如此循环迭代地发展和演进。

　　关于 SOA 治理有一个非常有趣的现象是，SOA 治理不仅仅涉及到开发团队，而是同时牵涉到业务所有的利益干系人。这是 SOA 非常重要的一个部分，因为针对相应的业务过程所实现的，并集成在一起的服务，经常是在业务中需要综合和跨越多个业务流程的。一旦针对 SOA 实现方案定义了相应的治理方式，那就得在整个组织中部署这个治理模式。

　　SOA治理实践

　　在实践中，SOA 治理指导可重用资产的开发，确立如何设计和开发服务，以及这些服务如何随时间增长进行更改。它将在服务提供者和服务使用者之间建立一个协议，告知使用者可以希望得到什么功能，告知提供者应该提供什么功能。

　　SOA 治理并不设计服务，而是指导将如何设计服务。这可帮助回答很多有关 SOA 的问题：提供了哪些服务？谁可以使用这些服务？它们的可靠性如何？将在多长时间内支持这些服务？是否可以确定这些服务不会更改？如果为了各种目的（如修复 错误或添加新功能）而希望进行更改时该怎么办？如果两个使用者希望相同的服务以不同的方式工作时该怎么办？是否因为您决定公开服务就意味着有责任永远为其 提供支持？如果您决定使用服务，是否能保证明天不会关闭这个服务？

　　SOA 治理以现有IT治理技术和实践为基础。使用 Java 2 Platform, Enterprise Edition (J2EE) 等面向对象的技术时，IT 治理的一个关键方面就是代码重用。代码重用也体现了 IT 治理的难点所在。每个人都认为可重用资产很好，但实际工作时却非常困难：谁为开发可重用资产付款？开发团队是否会实际尽力进行重用？是否每个人都认同可重 用资产的单一行为集，或者每个人都采用自己的自定义版本，实际上完全不能进行重用？SOA 和服务使这些治理问题变得更加重要了，它们的结果也因此变得更为重要。

　　治理更多的是政策问题，而不是技术或业务问题。技术的重点是匹配接口和调用协议。 业务的重点是为客户服务的功能。技术和业务都关注的是需求。虽然治理也涉及这些方面，但它更多的是要确保所有部分一起工作，独立的工作彼此并不会冲突。治 理并不会确定决策的结果是什么，而是考虑必须进行哪些决策以及谁进行这些决策。

　　使用者和提供者双方彼此就如何一起工作达成一致。这些认识上的一致大部分都能通过 服务水平协议（Service-Level Agreement，SLA）进行捕获，形成服务提供者愿意提供且服务使用者愿意接受的可度量目标。这个协议就像各方之间的契约，而且可以成为事实上的具 有法律效力的合同。SLA 至少要清楚说明提供者必须进行怎样的工作，以及使用者可以期望得到什么服务。

　　SOA 治理是由精英团队（Center of Excellence，COE）（一组知识丰富的 SOA 技术人员）制订的，他们负责建立策略并监督其执行，从而帮助确保企业的 SOA 成功。COE 将建立各种策略，以用于标识和开发服务、建立 SLA、管理注册中心以及进行其他提供有效治理的工作。COE 成员随后将这些策略付诸实施，指导和帮助团队开发服务和组合应用程序。

　　治理 COE 制订了策略后，就可以使用相关技术来管理这些策略。技术并不会定义 SLA，但可以用于执行和度量遵从情况。例如，技术可以限制哪些使用者可以调用某个服务以及何时可以调用服务。可以向使用者发出警告，告知服务已经弃用。 可以对服务的可用性和响应时间进行度量。

　　技术执行治理策略的一个不错的途径是通过企业服务总线（Enterprise Service Bus，ESB）和服务注册中心的组合。可以采用特定的方式公开服务，以便只有特定的 ESB 才能调用该服务。然后 ESB/注册中心就可以治理使用者的访问，监视和测定使用情况，确定 SLA 遵从情况等。通过这种方式，服务可以将重点放在提供业务功能上，而 ESB/注册中心则主要负责治理方面的工作。

　　治理可能成为 SOA 中任何错误的替罪羊。和性能一样，治理可能成为极大的顾虑，成为所有问题的托词和每个有问题的解决方案的正当借口。只需要在任何 SOA 讨论中扔出一句火药味十足的话（好比扔出了一颗“手榴弹”），然后就可以看着原本有用的讨论瞬时间陷入一片静寂。SOA 的一个挑战就是明智地使用治理来使SOA 更好地工作，而不会让治理方面的顾虑淹没了所有其他事项。