| 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计算算法：
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, 版权所属培训教育公司。更多内容请访问这里。 | 
