书摘与采访：SOA 100 问 - 问与答

Kerrie Holly 和 Ali Arsanjani 编著的《 SOA 100 问：问与答》一书深入解析了 SOA，它涵盖了很多 SOA 相关的话题，包括 SOA 基础知识，它对业务及组织的影响，SOA 方法与架构以及 SOA 的未来。

在这本《SOA 100 问：问与答》中，Kerrie Holley 和 Ali Arsanjani 通过问与答的形式为读者带来了全面的 SOA 实施指南。该书收录了大量来自业务及 IT 干系人的关键问题与答案，有一些答案是约定俗成的，并且提供了可能的基本实施路线图。

本书由 10 个章节组成：

• SOA 基础知识：给出了面向服务和 SOA 的定义、检验了 SOA 神话、澄清了对 SOA 的误解。
• 业务：探讨了 SOA 背后的业务驱动力，包括企业要更敏捷、更具适应性、更快速响应、更弹性、更加赢利；此外，这一章还谈论了如何计算 SOA 的业务价值，如对 SOA 投资回报（ROI）率的计算。
• 组织：探讨了技术和组织对 SOA 引进和实施的影响。
• 治理：强调了 SOA 治理及其在 SOA 引进过程中所扮演的收获业务价值的角色。
• 方法：涵盖了服务的发现与定义。
• 应用：介绍了应用与服务之间的关系，SOA 对应用开发的影响。
• 架构：阐述了多种视角的架构（例如，应用架构、整合架构、企业架构），探讨这些架构视角的影响及其与 SOA 之间的关系。
• 信息：介绍了数据架构和管理，包括 SOA 中的数据服务、标准数据模型等。
• 基础设施：探讨了中间件对 SOA 的支持，包括企业服务总线（ESB）、服务注册、服务监控和管理等。
• 展望：探讨了 SOA 将走向何方，新 SOA 趋势，包括上下文感知（context-aware）的服务。

培生 / 普伦蒂斯霍尔专业出版公司为 InfoQ 读者提供的书摘节选自本书的第 5 章，其重点是服务发现。InfoQ 有幸采访了Kerrie 和Ali。

InfoQ：在将 SOA 定义成一种架构风格时，你们有效地展示了著名的发布 / 发现 / 绑定 (publish/find/bind) 三角，并且如此结论——它不会给你带来任何 IT 之外的东西。然而， SOA 架构风格的另一种定义如下:

“SOA 可定义成一种架构风格，它建议将与业务对齐的企业服务作为设计、构建、组装企业级业务解决方案的基础构件。”

它谈到了 SOA 最重要的特性，即 IT/ 业务对齐和服务组装等，后者作为 SOA 架构风格的定义是否更好一些呢？

Kerrie 和 Ali：我们也许可以重新组织一下第 1 章“SOA 基础知识”中的问题：“SOA 是一种架构模式？”比“SOA 是一种架构风格？”可能更好。是的，我们的回答与“著名的发布 / 发现 / 绑定三角”非常一致，这个著名的三角出现在很多文献中，比如 Oracle 的这篇文章，但是我们的回答所强调的是：SOA 不仅仅是一种架构风格。书中提出的观点是，我们所定义及探讨的是一个SOA 新概念，它不同于90 年代后期所提出的那个SOA 的概念，而且，它并不局限于架构风格或架构模式。

这里有一篇很好的解释SOA 的文章，我强烈推荐读者再读一读它。该文认为应该扩展架构风格的定义，使之包含整个软件生命周期，这与《Convergent architecture: Building model-driven J2EE systems with UML》一书作者在书中所提到的观点一致。将架构风格的定义扩展至包括软件生命周期是有问题的，举例来说，它使各种模式之间、架构边界之间的界限变得模糊不清。Wikipedia 中有架构模式的定义。我们在书中并没区分架构风格和架构模式。不过，我们的定义与架构模式的定义是一致的。从对架构风格这一定义扩展来说，我们依然认为这篇文章中的定义更好。

InfoQ：在书中你们写道：“即便未部署（一个或多个）服务的 SOA 技术实现，也可以称之为 SOA 项目。”你们的意思是 Web 服务或 ESB 构成了 SOA 项目？

Kerrie 和 Ali：是的，在第 1 章的问题 5 中，我们回答了“怎样的项目可称作 SOA 项目”，我们的观点是——部署 / 实现 Web 服务或企业服务总线构成了 SOA 项目。然后进一步谈到，SOA 项目的类型有多种多样，不同类型的 SOA 项目带来的价值也不同。我们要传达的信息是，与其去争论一个项目是不是 SOA 项目，还不如去想想能从这个项目中得到哪些益处。一个项目，如果仅仅部署一个多几个 Web 服务，或仅仅实施 ESB 模式或 ESB 产品技术，即便能收获 SOA 价值，其收益也是很少的。OSIMM 标准列出了较宽跨度的 SOA 成熟度模型，同时又介绍了各种成熟度能够得到的收益。

企业可以从较低的成熟度级别开始，从服务的角度说，就是实施较少的 Web 服务。这类项目可能会加速与第三方的交互，从而有助于业务流程的改进。这种项目也可称为 SOA 项目，尽管只实施了一个或几个 Web 服务。与此类似，企业也可以采用 ESB 模式或 ESB 技术，其中服务和 / 或 ESB 模式有助于应用的整合，这样的项目也是 SOA 项目。

InfoQ：正如你在书中所写的，“度量 IT 解决方案的回报是极其困难的”，那么计算 SOA 的投资回报（ROI）更加复杂。能否给出一些切实可行的而非空洞客套的计算 SOA ROI 的建议?

Kerrie 和 Ali：有些企业必须要做商业价值分析或 ROI 分析。我们仍然推荐项目团队使用传统的商业价值和业务 ROI 分析方法，而不是 SOA ROI。然而，这样的回答对于某些企业来说是不够的。从实际的角度看，有些企业需要通过传统的 ROI 方法来分析收益，分析新技术、技能建设、甚至计划扩展等方面的投资回报。

许多企业和分析公司发布了他们的计算方法及建议，我们相信在这里能找到好的方法和答案。譬如，Tibco 有一个免费的 SOA ROI 计算器可供下载，在这里；IBM 的业务价值分析工具可从这里下载。

如下是一些公开发表的文章，它们很好地描述了各种 ROI 计算算法：

• 度量 SOA 的 ROI
• 在 Oracle 网站上搜索“ROI of SOA through reuse”即可返回一篇计算 ROI 的 PDF 文档。
• 面向服务的架构：在新经济体环境下度量 SOA 的 ROI ，这是 IBM 的业务价值学院发布的可供下载的 PDF 文件，其中包含了 SOA ROI 的计算方法。

InfoQ：书中有这样一个问题，“SOA 能否应用于业务架构？或 SOA 只应该应用于 IT？”，该问题是否可以这么解读，“能否脱离业务架构去实施 SOA？”如果底层业务架构尚不明确，谈何实现业务 /IT 对齐的目标呢？

Kerrie 和 Ali：SOA 可作为定义业务架构的驱动力，比如目标 - 服务建模（Goal-Service Modeling）就是这样的工具。所以，SOA 可用于优化业务和 IT 架构。然而，你问了一个很好的问题，它不同于我们在书中第 2 章的第 14 问，而且绝对值得一答。

没错，在尚未完全优化的业务架构的情况下是能够开展 SOA 实施的，但是企业对业务架构的定义和使用越成熟，它从 SOA 实施（SOA 实施使用业务架构并在其之下运行）中收获的业务对齐及收益也越大。如果我们把业务架构看作业务流程和业务目标，那么它们的缺失将严重影响业务和 IT 对齐。因此，若没有底层业务架构，就不大可能实现业务企业的业务目标和业务设计。但是，这并非意味着（开展 SOA 项目之前）必须拥有企业范围的业务架构或各方面都已完善的业务架构。

InfoQ：在书中你们谈到了不同的服务类型，如业务服务、IT 服务、信息服务、工具服务等。这基本表明任何分布的事物都是服务，SOA 是一个分布式计算范型。我们是否应该这样开始：将服务等同于业务服务，而将其他一切都看成组件（可能是分布式的）？

Kerrie 和 Ali：不能简单地将 SOA 称之为分布式计算范型，虽然它明显地支持这一范型。在第 3 章，第 24 问中，我们谈到了服务分类的价值。然而，从我们的回答中并不能推断出一切分布的事物就是服务。事实上，有一些分布式组件，他们既不是服务，我们也不会通过服务访问或调用它们。业务服务是一个分类，而且将服务归入这一类时应该有一定意图的，这才是我们所强调的。因此，正如你能在第 24 问的回答中能够见到的，扩展服务的分类使其包含除了业务服务之外的其他类别是有价值的。此外，我们不能将任何事物笼统地归类成业务服务或分布式组件。在第 1 章的问题 3 中，我们描述了服务的一些特性。在问题 24 中，我们进一步描述了服务分类的价值。在第 7 章“架构”的问题 65 中，我们回答了（服务）接口与（服务）契约之间差异的问题，这一回答能够解释服务与组件之间的差别。二者都是需要的，但它们是不同的。在第 5 章“方法”得的问题 40 中，我们阐述了为什么除了使用组件之外还使用服务对于应用的结构化是必须的。

InfoQ：在谈论 SOA 给系统开发带来的变化时，特别对于如何使用现有服务集构建更好、更可靠的实现，你们的讨论很精彩。但是，起初没有任何服务时，怎样办呢？

Kerrie 和 Ali：千里之行始于足下。所以，如果希望让一个应用逐渐变得更敏捷、更可靠，那么在开始构建该应用时，我们就开始让它变成现实。如果我们面对的是一组应用，那么它就应该在需要时递增地改造。所以，最初，我们的当前状态（As-Is）没有服务；而只有当我们开始了新项目或实施转型时，我们才可能从当前状态发展成目标和远景状态。企业现在就应该改变系统开发方法，赶早不赶晚，越早的企业走得越快。

InfoQ：在服务发现部分的一个精彩讨论中出现了一点点自相矛盾。一方面，你们谈到在特定项目中定义并实现服务，而你们又谈到了域分解、基于目标的建模和资产分析，而每一个都是企业范围的方法。二者如何共存？

Kerrie 和 Ali：在第 5 章“方法”问题 41 中，我们回答了“如何发现服务”的问题。域分解（Domain decomposition）、目标服务建模（Goal Service Modeling）和资产分析（Asset Analysis）可应用于项目级，可用于企业级，也可用于混合环境。例如，在一个项目中，目标服务建模可用来保证启动该项目的业务战略意图、期望的业务产出，也可用于记录待定（To-Be）业务流程，为项目提供商业用例；而资产分析可用于确定企业及应用集合中是否存在服务和组件可重用在该项目中。

这三个互补的技术既可用于单个项目，可用于企业级的战略转型中，可也用于混合环境中，比如某些企业目标是通过一个包含多个项目的项目集实现的。服务发现方法可从较大的网状结构中受益，比如整合企业范围；但它也可用于一个较窄的领域内，比如单个项目中。

InfoQ：全书谈论的一个现实是，SOA 不会改变以应用为中心的 IT 思考方式，这与服务发现与实施的方法似乎有着直接的矛盾。一方面，服务本身是迷你型应用；而另一方面，SOA 的整体目标是打破应用竖井——数据和自动化的孤岛。应用的服务似乎仅使用到了 SOA 技术，而非架构风格，相反企业服务则让应用淘汰。请详细解释这个矛盾。

Kerrie 和 Ali：SOA 思想和 SOA 项目除了将应用当作业务资产之外，也把服务当作业务资产，这可能会改变以应用为中心的 IT 思考方式。SOA 的关注点不仅仅是打破竖井，还包括消除竖井带来的负面作用，如无法访问应用内部的功能，无法快速对锁在应用中的功能进行重配置。我们鼓励使用服务，既为了需求的管理，又为了应用的结构化，所以服务要变成头等业务资产。服务并不为应用而存在；服务提供了延展应用生命力的方法，促进并加快了反映 IT 系统内在业务意图的能力。

SOA 引进和服务不会导致应用被淘汰，因为服务很可能打包在应用中，而且并非所有应用都采用 SOA。服务——不论业务线的、部门的或企业级的——处在特定的引进阶段或成熟度，都需要使用 SOA 架构风格和技术。一些服务会用在企业级，而另一些则可能用在特定的业务部门。这样用并不意味着现在只用在某个业务部门中的服务不能方便地扩展到企业级。

InfoQ：在将 SOA 与 DCE 和 CORBA 做比较时，你好像就拿 Web 服务与早期的分布式计算的方法做了比较？这是否表明你将 SOA 与其实施技术等同起来？在定义 SOA 时有哪些关键技术呢？

Kerrie 和 Ali：在第 7 章“架构”，问题 62 中，我们谈到了 SOA 和早前方法如 DCE 和 CORBA 之间的差别。我们强调了 5 个方面的差别：标准、扩展标注语言、访问数据库的方法、契约与接口的比较以及服务作为业务资产，将它们作为 SOA 与早前的 CORBA 和 DCE 之间的显著差别。同时，当我们谈到标准时，我们在 Web 服务的描述上花了大量的笔墨，这可能反而削弱了以上 5 种显著差异的描述。另外，SOA 一定不等于实施 / 实现 SOA 的技术集合。也就是说，技术集合不是定义 SOA 的关键，正如我们在第 1 章“SOA 基础知识”，问题 1“什么是 SOA”中谈到的那样。

InfoQ：书中另一有趣的比较是将 REST 与 SOAP 的对比，这可看作是 SOA 与 ROA 之间的比较么？你们似乎认为资源（R）等同与服务（S），能够详细解释一下？

Kerrie 和 Ali：我们有意探讨了 REST 与 SOAP 之间的对比，因为 REST 总与 ROA（面向资源的架构）相关联而 SOAP 总与 SOA 相关联，但是二者却并不是完全排斥的，REST 实现中也可以使用 SOA。应用是一组事物的结合，它们可以是资源、服务或事件。REST 看上去是 ROA 的主要实现方法，所以才叫 ROA，面向资源的架构或面向 Restful 的架构。将 SOA 与 REST 比较是有问题的，因为他们处在不同的抽象级别，所以即便 ROA 即是 REST，对二者的比较仍然是有问题的。因为，回答该问题取决于我们如何定义 ROA 和 SOA，ROA 由一个人发明，我们还能追溯其历史，但是 SOA 的历史却很模糊，它有多种定义。

我们并不认为 ROA 中的资源等同于服务。事实上，书中并没有提到 ROA 或 ROA 资源的概念。SOA 大多数强调的消息负载（payload）而 ROA 通常强调的是 URL 和请求寻址。所以，ROA 的每个地址有唯一的资源，而每个服务都有一个端点（endpoint）。ROA 大多针对只读数据。然而，应用可以兼用这两种方法，并且这取决于你怎么定义 ROA 和 SOA，尤其当 ROA 的唯一实现是 REST 时，ROA 就可看作是 SOA 的子集。

InfoQ：书中对于 SOA 和 SOI 的比较有点让人迷惑。是否可以这么简单地说：尽管二者共享相同的技术栈，但是 SOI 直接将现有应用的功能暴露成服务接口，而 SOA 直接暴露的是业务对齐的接口而隐藏了现有应用的功能？

Kerrie 和 Ali：我们的答案中关于 EAI，SOA 和 SOI 之间的差异，目的在于比较和对比。在第 7 章“架构”的问题 68 中，回答了什么是 SOI 的问题。像 SOA 一样，SOI 有着许多不同甚至偶尔冲突的定义。我们简单地将 SOI 定义成面向服务的整合，在这里 SOA 和 / 或 Web 服务用于实现整合。我们还谈到 SOI 可用于描述使用服务和 / 或 SOA 技术的整合模式。我们把 SOI 看作 SOA 的一部分，而非独立的事物。我们也没有看到区分 SOI 和 SOA 的意义何在。没错，SOA 和 SOI 可以共享相同的技术栈。没错，SOI 将现有应用暴露成服务接口。然而，SOI 也可以被描述或定义成使用 ESB 的使用，它为与业务对齐的服务解决了访问、路由或转换等方面的问题。所以，这一切仍然取决于这一名称所包含的内容。我们用模式的形式描述 SOI？我们将那些模式的实现也包含在 SOI 里面了么？不论上述哪种情况，SOI 都比简单地将现有应用的功能暴露成服务接口来得复杂。

InfoQ：在定义信息服务时，这些服务似乎就是数据的 CRUD 接口。这有好像与 SOA 反模式 CRUD是矛盾的。二者如何共存呢？

Kerrie 和 Ali：这篇关于把 CRUD 作为反模式的文章的关注点是通过.NET 设计 SOA 服务。在阅读 CRUD 反模式的现象与后果时，我发现作者在未给 SOA 服务和 Web 服务下定义的情况下即将二者等同起来。作者进而描述了如何规避该反模式的风险，但解决方案所使用的依然是 CRUD。所以我不认为这是一篇很好地介绍 CRUD 反模式的文章，而更多地是一片介绍使用.NET 实现 CRUD 的反模式的文章。

在第 8 章“信息”的问题 74 中，我们讲述了信息服务的分类，其中有一类数据服务的主要实现了 CRUD。当然，因为它是服务，所以它还必须带有我们在第 1 章“SOA 基础知识”的问题 3 中所描述的服务属性。不论我们如何分类服务，这一点都是不变的。在本书中，我们关注的是 SOA 服务而不是 Web 服务，并且对二者下了定义，描述了二者的差别（参考第 1 章问题 4）。所以，通过理解和实施第一章中所描述的 SOA 服务，我们就能避免出现该问题中提到的这篇文章所讲述的不良后果。此外，在第 8 章“信息”的问题 77 中，我们描述了适于实现 CRUD 型服务的场景。我们规避了 CRUD 反模式中描述的不使用 XML 模式导致的负面后果，因为每个 SOA 服务都有其对应的 WSDL 文件或同等描述文件，而且它是一个契约而不是接口。

InfoQ：在书中，你们好像把注册（registry）和存储（repository）看作同一事物，尽管在现实中他们解决不同的问题。将它们放在一起实施是SOA 最佳实践吗？

Kerrie 和 Ali：在第 9 章“基础设施”的问题 83 中，我们为 SOA 基础设施标识并定义了基本构建，其中包括注册库。我们没有特别地强调存储库，因为存储库在除了 SOA 之外的很多方面都使用过，我们不认为存储库是 SOA 特有的基础构建，尽管存储库在 SOA 基础设施运行过程中可能是必需的，就像集成开发环境对于实现服务的作用一样。所以，注册和存储不是同一事物，而且我们同意它们解决的是不同的问题。

在回答问题 87“ESB 和注册库间的关系”时，我们有一张解释注册库使用生命周期的图，在该图中，存储库也可用于促进服务端点的发现。我们不认为将注册库和存储库在一起实施是最佳实践，同时我们也不反对这样的实施，因为这是一个企业和项目团队必须要做的架构决定之一。打个比方，我们需要元数据对治理、安全、或注册库的生命周期进行管理，此时就应该选择存储库。厂商将注册库与存储库放在一起实现能够带来治理及管理方面的优势。

该书摘是从 Kerrie Holley 和 Ali Arsanjani 博士编著的《SOA100 问：问与答》中摘录的。该书由培生 / 普伦蒂斯霍尔专业出版公司于 2010 年 11 月份出版，ISBN 0137080204, 版权所属培训教育公司。更多内容请访问这里。

查看英文原文： Book Excerpt and Interview: 100 SOA Questions Asked and Answered

感谢胡键对本文的审校。

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