IBM：SOA治理简介(1)

治理和管理需求

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

在本文中，我们将了解治理和管理的含义以及其之所以重要的原因。然后，我们将讨论以下 SOA 治理的一些重要方面：

通过本文，您将能很好地理解为何 SOA 工作需要 SOA 治理的支持。您将建立起如何为您的组织构建其 SOA 治理方案的一些基本理念。

没有治理时的情况

在讨论什么是治理之前，让我们了解一下公司 IT 部门中通常的情况；即没有治理时的情况如何。

希望提供服务时

让我们假定您开发了一个很不错的小型服务来进行货币值转换。您需要在正在处理的订单处理程序的几个不同位置使用此服务，因此将代码编写为具有可重用功能，以便从程序中的任何位置进行调用。由于在另一个程序中需要此服务，因此将代码放到 Java .jar 文件中，以便将其添加到任何需要此服务的程序的类路径中。但该服务存在一个问题，由于需要使用货币汇率（如 Yahoo 的货币转换器网站发布的汇率）进行初始化，因此启动需要很长时间。这些步骤在每次需要对货币量进行转换时，都会花太多的时间进行初始化。因此，您在自己的小程序中承载转换器，这个程序在启动并初始化后将始终运行，可以随时通过远程 API 从任何程序对其进行调用。此 API 可以作为 SOAP-over-HTTP Web 服务实现，也可以是支持 RMI-over-IIOP 的远程 Enterprise JavaBean (EJB) 接口。

您现在获得的就是一个货币转换器服务。不仅您的多个程序可以使用它，您的部门同时也很喜欢这个小东西，开始从他们自己的程序对其进行调用。不久后，您可能不知道，公司的其他部门中您从来没有听说过的程序也在使用这个服务了。转换器运行频率非常高，而导致其响应时间延长，因此您劝说经理购买更为强大的计算机来承载您的服务。经理并不喜欢将预算中的资金花在另一台进行简单工作的计算机上，不过您说服了他。

一个周末，计算机系统崩溃了，而这却是您公司的某个从来没有听说过的人打电话到您家里告诉您的，他让您到办公室进行必要的工作，以便使转换程序重新开始运行。后来，您的经理说其他部门的人抱怨您的转换器汇率更新并不及时。他希望您对此进行处理，但不希望耽误您的本职工作。您怎么开始对所有这些负责了呢？

有一天您说“去他的”。您不想再负责转换器的工作，将其关闭了。大量的投诉电子邮件开始在公司内出现，人们尝试找出谁负责转换器程序以及为什么没有再运行了。其中很多电子邮件抱怨说，由于没有了转换器服务，很多非常有用的程序不再能继续工作了。客户非常生气，您的公司因此而蒙受着利润损失——如果运气不好，每个人发现要对此负责的是您，您很可能会被辞退。怎么会是这样呢？

希望使用服务时

现在让我们看一下另一方面。假定您是该公司中的另一名员工，在处理产品目录应用程序。不同国家的用户希望能够看到以其相应货币表示的产品价格。一位同事告诉您可以调用此服务将每个产品的价格转换为使用用户的货币表示。您试了一下，的确可以正常工作，因此使用该服务实现了您的应用程序。您的经理非常高兴您能以创记录的时间完成新功能，客户非常喜欢这个功能，网站的销售额大幅度提高。

然后，您的网站在某个周末停止工作了：无法以其他货品显示价格。您的经理打电话到家里，要求您赶快修复程序。您打电话到同事家，得知是他的朋友的朋友告知他这项服务的。同时，销售副总裁的助手打电话告诉您客户对此很不满意。您告诉他是朋友的朋友编写的这个服务。副总裁的助手打电话给这个人，让他马上到办公室进行相关工作，以使此服务恢复运行。尽管您的应用程序本身没有问题，而是调用的服务出现了问题，您同时也因为目录应用程序停止工作而被指责。这怎么会是您的错呢？

欢迎来到 SOA 治理的世界。或，在本例中，缺乏有效治理的世界。服务提供者和服务使用者都开始负责很多最初的职责之外的事务。如何在不造成这样的失控局面的前提下使用服务呢？

什么是 SOA 治理？

我们已经了解了治理无效时可能出现的情况。那么，如果治理更好，IT 是不是会工作得更好？首先，我们需要了解什么是治理，以及它如何影响 IT 和服务。

通常来说，治理意味着建立和执行工作组为了一起工作而一致同意的工作指南。具体来说，治理包括两个方面：

• 建立责任、授权和通信链，以对人员进行权利分配，确定谁有权进行哪些决策
• 建立度量、策略和治理机制，以支持各个人员执行各自的角色任务和旅行相关职责

治理与管理有以下几个方面的区别：

• 治理确定谁具有权利和责任进行决策
• 管理是进行决策和实施决策的过程

因此，治理说明应该完成哪些工作，而管理用于确保完成此工作。

治理更为具体的一个形式是 IT 治理，用于完成以下任务：

• 建立与 IT 关联的决策权利
• 建立用于度量和治理 IT 决策及执行的机制和策略

即，IT 治理讨论的是关于谁负责 IT 部分中的什么，以及部门如何知道相应的人员履行了这些职责。

SOA 向治理添加了以下几个独特的方面：

• 充当 IT 治理的扩展，重点关注服务的生命周期，以确保 SOA 的业务价值
• 确定谁应该监视、定义和授权对企业内现有服务的更改

治理在 SOA 中比在普通 IT 中更为重要。在 SOA 中，服务使用者和服务提供者运行于不同的进程中，由不同的部门开发和管理，为了成功地一起工作，需要进行大量的协调工作。为了 SOA 能成功，多个应用程序需要能共享相同的服务，这意味着它们需要进行协调，以便共享和重用这些服务。这些就是治理问题，比采用独立应用程序时（甚至包括使用可重用代码和组件时）要复杂得多。

随着各个公司开始使用 SOA 来更好地保持 IT 与业务间的一致，可以使用 SOA 治理来非常理想地改进总体 IT 治理。如果公司要实现 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 更好地工作，而不会让治理方面的顾虑淹没了所有其他事项。

SOA 治理的各个方面

SOA 治理不是一组实践操作，而是很多彼此协调工作的系列操作实践。SOA 治理的每个方面都值得在以后的文章中进一步地深入讨论。此处的讨论仅是简单的概述。

服务定义

SOA 治理最基础的方面就是监视服务的创建过程。必须对服务进行标识，必须描述其功能，确定其行为范围并设计其接口。治理 COE 可以不执行这些任务，但要确保有人执行这些任务。COE 对创建服务和需要使用这些服务的团队进行协调，以确保满足相关的需求，并避免重复工作。

通常，什么应该是服务这个问题的答案并不明显。功能应该与一组可重复的业务任务匹配。服务的边界应当封装一项可重用、不受上下文约束的功能。接口应该公开服务进行的工作，但要隐藏服务如何实现的，并允许更改实现或采用替代实现。从头设计服务时，可以将其设计成对业务进行建模；包装现有服务时，创建并实现好的业务接口可能会更难。

定义服务边界的潜在困难的一个有意思的例子就是在何处设置事务边界。服务通常在自己的事务中运行，确保其工作要么完全完成，要么完全回滚。不过，服务协调程序（也称为协调器或编排器）可能希望在单个事务中调用多个服务（最好是通过指定的交互，如 WS-AtomicTransactions）。此任务要求服务接口公开其事务支持，以便能参与调用方的事务。但这样的公开要求对调用方信任，对提供者具有很大的风险。例如，提供者可能会锁定执行服务的资源，但如果调用方永远不完成事务（没有提交或回滚），提供者将很难干净地释放资源锁定。正如这种情况所表明的，服务的范围以及谁具有治理权有时候并不太容易确定。