《SOA 治理》作者访谈

由 Clive Gee，William A. Brown，Robert G. Laird，Tilak Mitra 合著的图书《SOA 治理：实现并保持业务和IT 的机动性》不仅为读者带来了SOA 治理相关话题的详尽描述，而且还提供了可以直接用来建立和实现文中提出的治理模型的工作包以及案例分析，向读者展现了如何将这些方法以及工作包应用到现实生活中。

InfoQ 有幸采访了这本书的作者。

InfoQ：人们广泛地认为 SOA 的主要优势是重用，你们同意这种看法吗？

本书作者：我们应当同意重用是 SOA 的优势之一，但不一定是最主要的优势。以 IT 为中心的人可能会强调重用的优势，并单从重用的角度来创建 SOA 的业务案例。有助于重用的服务一般是 IT 通用的服务，例如编辑服务，日志服务，安全服务等等。毫无疑问，重用很有价值，我们也无意贬低重用的地位。

事实上，重用的概念从面向对象（OO）诞生的那天起就已经被人们很好的理解并应用。在 OO 中，重用的粒度体现在类的级别上。在 SOA 中，一流结构是服务。服务是在比对象和组件更高层（向业务对齐的方法）的抽象之上的定义。站在提升业务和 IT 机动性的高度去定义服务（业务服务和 IT 服务）的能力是每一位 SOA 架构师所必备的基本素质。

通过组装一个或多个 IT 服务来定义业务服务的能力提升了重用的抽象层次，这是 SOA 的主要优势之一。这个优势使得业务以业务服务的方式来定义企业操作，而 IT 定义一组可以用来实现业务服务的 IT 服务。业务服务和 IT 服务之间的可追溯性通过在软件栈的多个层次提高重用，为企业带来了他们极需的 IT 和业务对齐。

然而，SOA 更重要的优势是业务机动性。这需要企业在 IT 和业务之间拥有真正的合作关系，并且已经完成业务目标和业务流程的分析、业务服务的分解以及支撑业务机动性的架构元件。这件事并不容易做，而且缺乏经验丰富的执行者。

InfoQ：您推荐哪些工具来支撑书中提到的治理流程？

本书作者：这本书的一个重要主题是创建和管理用于计划、定义、设计、创建、测试和运营所有服务及自动业务流程的服务工厂。和其他生产流程一样，适当的自动化和工具对我们的服务工厂也很有帮助。处在服务周期的不同阶段，实现 SOA 治理所需的工具有所不同：

• 实现治理的最重要的能力是有效的双向沟通。任何可以实现这个目标的工具，比如内部网、“自备午餐”会议、协作性消息工具、电子邮件或面对面会议都可以为实现治理提供有效帮助。
• 拥有标准的、企业范围的业务实体和消息模型对于开发适合企业的服务来说至关重要。一款为这些消息模型提供版本管理和发布功能的工具是企业的实物资产。在多个物理表示对应于同一逻辑业务实体的场合，详细描述这些离散表示之间映射关系的数据字典也相当关键。
• 我们经常见到的重用的障碍之一，是把业务需求仅记录在个别 IT 项目的文档中，这种方式导致新项目很难甚至不可能找到它们（业务需求）。使用通用数据库或存储空间来为业务需求、业务规则、术语和参照标准等提供版本管理和发布的功能，并依据业务实体和（或）业务流程建立索引，可以为重用提供很大的支持，还能减少不必要的重复劳动并降低运维系统的复杂度。
• 有必要为所有的技术需求文提供管理、发布和升级等功能，这些需求包括架构原则、架构决策、策略和标准、最佳实践、推荐设计模式、清单以及清单指导等。 这可以使用定制工具实现，或直接从管理良好的企业内网获得。
• 我们见过一些 SOA 的实现使用模型驱动的设计方法，在这种方法中，大部分的分析，设计甚至测试都是通过可视化工具进行的，并且大部实际代码都是自动生成而非手写的。因为模型比源代码更容易被理解，它可以帮助读者确保设计出精准描述业务和技术的需求并且代码准确地反映设计。目前 IBM 等提供商提供了很好的商业服务开发工具（SDK），这些工具拥有上述建模和代码生成的功能。
• 在大企业中，提供管理合规检查结果的工具可以最大限度地降低成本。这些工具有的就像使用通用的个人工作汇报工具一样简单，有的是市场上已有的着眼于策略合规检查的自动化工具。
• 对于已创建很多服务（50 个或者更多）或者开始将服务提供给第三方使用的企业来说，服务目录或服务注册表就变得更加关键。理想情况下，服务注册应该根据目标用户分成两个独立的部分：
  • 对于潜在服务消费者（例如内部部门、合作伙伴或客户），目录或注册库应该包含以下信息：可以公开使用的服务详细信息（包括其版本细节）；如何获得这些服务的使用权；如何从技术角度去访问这些服务（如，通过服务描述语言 WSDL 定义服务接口）；治理服务使用的 SLA 条款等。除此之外，还应该包含对计划中的新服务以及服务版本的详细信息，以获得关于服务的内容和价值的反馈。该目录或注册库不应该包含任何关于服务实现的细节；SOA 的一个关键特征是任何服务的实现可以在服务“契约”（即接口，如 WSDL）不变的情况下随时被修改。一般来说，每个服务的描述信息应该只能让那些潜在的服务使用者看到；还有一些服务只为内部使用者所见。
  • 对于服务开发人员，应当有更广泛的内容，包括服务内部信息，如非功能性需求，详细设计等。这部分注册库还应包含不能被直接发布成服务的底层组件，例如用来组装复合服务的独立代码段。
• 存放源代码或配置信息等资产的一个或一组注册库。在从测试到产品阶段迁移新服务或新系统时，或者软件维护时，能够重建特定物理配置的能力显得非常重要。一个广为人知的案例，一个很大的美国公司因为无法用一个星期左右的时间将一个关键的 IT 系统重置到先前状态，继而无法成功升级系统，从而被它的竞争者所取代，导致他们的股票崩盘。
• 要实现任何实际层面的服务运营治理，工具和基础设施非常关键。这些工具和基础设施应能监控服务和自动流程执行的所有信息，包括它们的使用频率、版本、服务响应时间以及错误情况和系统能力监控等。
• 随着企业级 SOA 越来越成熟，相关数据会越来越多，如关于服务开发和运行效率的数据，关于 SOA 开发和治理工作的重要性，业务影响以及 SOA 对整个企业的价值的数据等。同时，要生成很多报表，按月、按季度、按年或者随需生成。好的工具可以很大程度上提高创建这类表格的效率；我们看到很多这样的解决方案，其中有简单的业务数据分析 / 报表生成工具，也有非常复杂的实时监控服务以及流程运行状态的“面板”等。

InfoQ：书中谈及较少的一个话题是如何为实现 SOA 解决方案选择合适的服务。如何解决这个问题，你们有何建议，前提条件是什么？

本书作者：从我们的经验来看，合适的服务可以通过自顶向下的分析方法来确定，也可以有机地根据明显需求而建立，还可以通过将遗留系统的能力转化成服务的方式来实现。这些都是有效的方法。自顶向下的方法需要相应的企业架构能力（因此我可以假定拥有一个 EA 组是先决条件），合作的能力以及分析业务流程和将流程分解成业务服务的能力。这些服务应有助于实现业务机动性。有机地增长服务更容易实现，因为很多方面都可以提供服务的需求。服务治理应该保证所有正在建设服务在服务开发控制点遵循架构标准、策略以及向导等。

InfoQ：你们在书中建议把业务资助纳入 SOA 工厂的一部分，那你们建议如何引入它？

本书作者：我曾经在 Teco 公司工作过，我会每月安排一次与每位业务副总裁 1 小时的头脑风暴讨论会。会上，我从不讨论 SOA，从不使用技术术语，也从不说“架构” 这个词。相反，我们在白板上讨论业务。我们讨论如何让业务服务有价值，帮助他们压缩成本及推动产品更快进入市场。他们对那些可以推动业务的“他们的”服务和项目相当有激情。结果，尽管他们并不知道 SOA，他们却变成了 SOA 的业务资助方。和客户谈论业务问题和业务解决方案吧，很快就有项目的业务资助方了。

InfoQ：似乎在你们看来，成功实现 SOA 的唯一途径是通过 ESB 实现服务基础设施的标准化。那么你们是否认为 ESB 是实现 SOA 的前提呢？你们是否认为一个企业应该有一个（联邦的）ESB 来实现 SOA 呢?

本书作者：尽管企业服务总线（ESB）不是成功实现 SOA 的绝对前提，但是它的确可以为服务端点路由、数据仲裁等提供基础基设，对于服务数量很大或者服务实现十分复杂的情况更为有用。对于拥有这类情况的公司，我们肯定建议使用一款商业 ESB 而不是关起门来自己开发 ESB 的功能。

严格地从管理的角度来说，ESB 为监控服务的内部指标简单地提供了统一接触点，服务的内部指标包括数据仲裁的数量和范围和服务执行过程中各分支节点的使用频率等。虽然这些不完全是实现整体 SOA 成功的关键因素，这些信息对于获得效率最大化非常有用。至于是否要为 SOA 的实现建立联邦 ESB 的问题，我们觉得由公司的具体情况而定。例如，我们的一个客户有好几个 IT 开发团队，分布在三大洲。这种情况下，实现一个联邦 ESB 是很困难的，此外，大部分服务执行是在一个地理范围之内的。

查看英文原文： Interview with the Book Authors: Brown, Laird, Gee, Mitra: SOA Governance 。

译者简介：

马国耀，2007 年毕业于北京大学信息技术学院，硕士学位。他感兴趣的技术领域是 SOA，ESB，J2EE，Java 编程，开源项目等。业余时间爱好五子棋，围棋，获中国棋院授予的五子棋初段段位。他热情乐观，愿与天下各路豪杰结为朋友，可以通过 maguoyao (at) gmail.com 联系到他。

感谢胡键对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。