书摘和访谈：Open Source SOA

Jeff Davis 的新书《Open Source SOA》在选择和使用开源产品实施 SOA 方面为我们提供了大量有价值的信息。

在他的这本新书《 Open Source SOA》中，Jeff Davis 讨论了使用开源产品构建 SOA 解决方案的优势。书的开篇首先讨论了 SOA 的主要原理和完整的实施架构，接着介绍了架构中每层选择开源产品的标准，然后详细介绍了每种产品，论述了它们的工作原理和如何在 SOA 实施中使用以及与其它开源产品进行整合。

Manning 为 Infoq 读者提供了该书的第二章节选，本章介绍了SOA 实施如何选择开源产品。该书为我们提供了现有开源SOA 产品的功能介绍和最佳实践的宝贵信息。该书和其 Manning 网站都提供了对应的代码实例，使得该书更适合于开发者。

InfoQ 有幸采访了 Jeff。

InfoQ：在您的这本书中，您将 SOA 定义为“可用于构建新业务流程或者应用的离散的、可复用的业务服务”的集合，而另一方面，您将 SOA 比喻为不同的分布式计算方法。多大程度上您将 SOA 看作是一种技术——分布式系统，还是业务问题？您如何区分服务、业务流程和应用呢？

Jeff：这是个很好的问题！首先，我认为 SOA 是一种架构，它为如何研发软件解决方案提供了蓝图。在某种意义上，SOA 是一种由业务需求驱动的技术挑战，现在的业务需要应用间具备更多的灵活性，并易于整合和共享，同时更敏捷地响应市场变化。如果采用了 SOA 方法论，那么应用在本质上会更加淡化整体性，而更类似于混搭（mashups）。为什么呢？因为应用可能由多种服务组成，这些服务可以由许多各异的应用 / 客户端组成。

我将业务流程看作是多个服务间的服务编排，这些服务可能包含或不包含人工元素（比如任务需要人类介入），在 SOA 中，服务就是积木构件，在书写应用和流程时可以利用这些服务。

InfoQ：有一本书讨论了 Web 服务和 REST 之间的论战。您认为 Web 服务与 REST 会和平共存吗？它们在哪些特定领域更有各自的优势呢？

Jeff：SOAP 的主要优势是 WSDL。它规范了如何调用一个特定的服务。.NET 和 Jave 平台都提供了将 WSDL 生成服务接口的工具。我个人认为这就是 SOAP 的最大价值。当然，这也增加了 SOAP 的复杂性，在试着理解 WSDL 的时侯，很多人都感到害怕。目前，REST 世界有一个类似 WSDL 的产物（但是没有公认的命名）。比如，Web 应用描述语言 (Web Application Description Language) 或 WADL。它与 WSDL 的功能相似。在 SOAP 中 WS-Security 越来越被广泛采用，但 REST 世界中的应用公共安全模式和 SOAP 中不一样。我认为 REST 将会不断繁荣壮大，而在企业应用中，SOAP 将更普遍。

InfoQ：您在这本书里将服务接口和服务契约等同起来，并建议二者都使用 WSDL。您认为 WSDL 对服务的定义够用吗？您如何定义服务的 QOS、服务 / 信息语义呢？

Jeff：是的，WSDL 定义了参数，操作，内容需求，以及基于 SOAP 的 Web 服务的端点。很明显，作为服务的消费者与服务进行交互时，这点是非常重要的。显然，WSDL 并不关注服务的真正实现，它只表示注册的服务哪些是可用的。（除非你在一个大的 WSDL 中定义所有的事情，很多人都这么做）。在下一个章节中我将介绍如何使用 WSO2 的注册产品实现服务注册（我的 blog http://jdavis.open-soa.info/wordpress/ 上将会发表这个章节的内容）。 QoS 相关的语义可以通过 WS-Policy 扩展。例如，可以使用 Apache Synapse 定义策略，策略中定义客户端可以访问服务的次数以及管理服务的优先级。

InfoQ：当我们谈论到 SOA 的核心特征时，会提到服务的无状态性。在您的书中，您也谈到了 SCA 的（有状态）交互。那么 SOA 和 SCA 是如何共存呢？

Jeff：我认为在理想的状态里所有的服务本应该都是完全无状态的，就如同我们每年都期望 Packers 应该赢得超级杯（Super Bowl）一样。不幸地是，这种假设不一定是可行或者现实的。一些复杂的服务需要和客户端进行更多的交互。我认为应该尽可能地避免这种情况，但是有时候很难做到这点。我认为 SCA 对交互的支持是非常灵活的，但是从一个实现的视角来看需要一些时间去领会和理解（希望我的这本书提供了这方面的帮助）。

InfoQ：在您的书中有一个描述 SOA 层的图表，但您没有具体讨论在实施每个 SOA 层时该使用哪些产品或者方法。您认为需要特别地介绍 SOA 吗？关于实施 SOA 您有哪些建议呢？

Jeff：我并没有深入介绍这些内容，因为可供选择的产品实在是太多了。然而，很多流行的 GUI 框架，比如， Flex、Tibco GI、GWT (尤其是 SmartGWT)、Ruby on Rails，都为 Web 服务交互提供了强有力的支持，无论这些 Web 服务是基于 REST 还是原生的 SOAP。我认为客户端层应该简化访问和消费 SOA 环境中暴露的各种服务，但事实上，Web 应用更多地用于管理页面流、安全以及其他内容，然而，对它所拥有的可用服务而言，它就是客户端。

InfoQ：您为我们提供了一张评估开源产品标准的表格，但该表格并没有将“坚持标准”作为评估标准之一。您认为在选择开源产品时对评估其对标准的支持有多重要呢？同样，其他的开源产品，比如 JBoss 和 Mule，都为他们的产品提供了支持服务。那么对于产品，能够购买产品支持服务，在你看来又有多重要呢？

Jeff：很不错的观点。我确实省略了这点。坚持标准是非常重要的，当涉及到如何暴露服务时尤其重要。在 SOAP 中，我认为 SOAP 服务框架创建服务时都遵循 WS- I 标准非常重要，比如，该标准使得.NET 和 Java 客户端可以平稳地相互通信。同样，当你开发 BPEL 脚本时，对你而言，能将这些脚本从一个框架或者应用移植到另一个框架中并且无需全部丢弃私有扩展可能非常重要。然而，Mule 并不是一个遵循 JBI 规范的容器，这有什么问题吗？在你想将适配器从一个 ESB 迁移到另一个时可能是，但通常情况是你选择了一款产品并打算使用一段时间（Mule 支持许多标准，比如 JSON，RSS，SOAP，REST 等），这些因素可能就不是最主要的（与实现、可扩展性相比）了。

至于是否能够购买支持，我认为这为客户提供了不错的定心丸，还可以保证开源产品的长期生命力。如果你仔细观察，可以发现绝大多数成功的开源项目都有赞助公司，它们以某种方式从开源项目获取利润，比如产品支持或者咨询实施。我确实对这样一种模式避而不谈，即开源产品提供的原型在某些方面存在着功能限制，所以不得不购买商业版本来满足我们的需要。比如，与 Mule 或者 Active Endpoints 相比，我更喜欢 JBoss 和 WSO2 的模式。我认为即使有赞助公司在背后支持开源项目，开源社区反馈也是非常重要的，因为这样可以帮助提升产品的功能并为它的长期发展做出一些贡献。

InfoQ：当谈到服务注册时，您经常提到注册 (registry ) 和存储库 (repository )。您认为它们是同一个概念吗？书中关于注册的讨论更多的是围绕支持设计时制品，同时注册产品的选择包含了多种 LDAP 实现，它们为支持运行时（身份）信息提供了优化。您认为注册的运行期使用也和设计时一样吗？

Jeff：我认为服务的动态发现是一种旧概念，它最初由 UDDI 所支持，相当天真，这也是为什么没有人真正这么做的原因。我认为服务注册的主要焦点是 WSO2 和 Mule 如何提升服务注册，它更像是一个协作和支持工具。我认为通过 WSDL 或者 WADL 这些技术规范，服务可以充分地实现自我描述。

InfoQ：在您的评估表中，您将 ESB 从服务组件框架中分离出来，并建议使用 Apache Tuscany 和 Apache Synapse。您认为它们二者是成功实施 SOA 中必不可少的吗？

Jeff：我认为 ESB 最适合作为各种协议间的中间件（或者中介），它也是管理安全和策略实施的不二选择。我认为 ESB 不适合用于构建可复用的组件和服务，而像 Tuscany 或者 OSGi 框架更适合做这些。ESB 显著的特点是可以通过其他的协议将现有的遗留服务包装成服务，而不需从零开始实现这些服务。如此看来，ESB 擅长于将旧应用服务化。最初对 ESB 的一些混淆是将它们作为 SOA 的“瑞士军刀”，而忽视了如何构建服务和组件。

本书的一个焦点是如何整合像 Synapse、Tuscany、jBPM、Drools 和 Esper 这些技术，让它们与 SOA 的规则保持一致，利用它们各自的功能。

InfoQ：虽然您提及到了 SCA 工具——一个 Eclipse 插件，但在书中您并没有谈到如何使用它。您认为这个工具将会被广泛使用还是仍处于试验阶段？

Jeff：我确实用过 SCA 的 Eclipse 插件工具，它一直在发展。它的一些特征比如 SCA 图，有时候看起来很漂亮，只是用于构建配置文件时有些不太好用，这只是我的个人观点。我可能有点守旧，但我更想知道它的底层实现。相比之下，从开发的角度而言，我认为 jBPM 插件的图表特征非常有用。我确信 SCA 的可视化工具会不断地发展和改进。

InfoQ：书中对 SDO 的描述，SDO 的优势并不能立即显现。如果说 WSDL 常用于服务设计的话，那么 SDO 提供的多种“规格化”XML 解析有什么优势呢？

Jeff：你确实深入地看了我的这本书！根据我的经验，我更倾向于将 SDO 作为另外一种 XML/Java 的绑定技术，不像 JAXB、Caster 或者 Axiom。因为它与 SCA 紧密地集成在一起，这是很正常的。实际上，如果你是采用自顶向下的方式开发服务，也就是先设计 WSDL，然后可以使用 SDO 的 WSDL-to-Java 工具创建 Java 绑定类（我认为自顶向下的方式是一种基本的构建一致性和设计良好服务的方法）。我使用这种方式处理过相当复杂的 WSDL，并得到了理想的效果。当然，SDO 也提供了对非连接的变化集的支持，可以将离线状态下发生的变化和原始的进行比较，事实上，与变化日志有点相似。事实上，这种用法还不多见，但它确实很有趣。

InfoQ：书中对 BPM 的讨论并没有专门讨论流程建模。您认为流程建模是成功实施 BPM 中必需的吗？您能建议一些适合 jBPM 的开源 BPM 建模工具吗？

Jeff：我认为使用流程建模工具或许存在一些优点，尤其是在构建非常复杂的模型时。然而，经常不会这样，这也不是惯例。显然，在 BPEL 中有一些产品，它们使用 BPMN 符号建模，致力于促进业务分析师和专家开发流程。会生成一些代码，并将 BPEL 作为输出（Intalio 就是使用这种方法）。然而，在实际运用中，它是非常复杂的，因为 BPMN 支持的符号比 BPEL 支持的更丰富，因此一个复杂的转换层就出现了。由于 BPEL 的代码是生成的，不应该被修改或者逆向工程的解决方案也不支持。根据我的经验，这种类型的解决方案经常有问题。

也就是说，通过使用 Eclise 插件构建模型的 jBPM 图的设计目的就是向建模人员屏蔽底层实现。换句话说，即使是非开发人员也可以像使用 Visio 一样构建工作流，而开发人员可以插入具体的实现细节。不同的是，像 Active Endpoints BPEL 设计器之类的产品都假设建模人员都熟悉 BPEL 的相关术语，这些术语对于没有接受过这方面培训的人来说是一种挑战。本书中，我使用 jBPM 演示了一些相当复杂的模型，并描述了 SCA 是如何和 jBPM 相互协作工作的。

InfoQ：这本书介绍了许多关于使用事件流流程实施 BAM 解决方案的有趣细节。那么您想使用事件流流程来启动业务流程或者服务吗？

Jeff：当然！我认为 CEP 应该编织到你所设计的服务和流程中。如果适当地使用 CEP 预先构建服务，那么会相当简单。即使你最初不想处理太多的事件，也可以通过添加一些过滤规则和模式来灵活处理。它和纵横交错的事情相似，比如预先构建的日志，你更乐于以后再做。通过这种方法可以很容易地追踪服务调用的频率和监控错误。这本书中有一些关于如何使用 jBPM 发送事件到 Esper 的实例，书中提到的 Esper 是一个开源的 CEP 产品。

InfoQ：这本书大篇幅地介绍了 Drools 的用法，但是规则、服务以及业务流程之间的关系仍然不是非常清晰。您可以详细描述它们之间的关系吗？

Jeff：我认为规则是如何将服务组合成复合应用或者流程的粘合剂。在这方面，我认为规则引擎对 SOA 而言非常重要，这就是为什么我要这本书中详细讨论这个主题的原因。例如，在业务流程中的工作流通常是由决策驱动的。例如，如果你有一个订单流程工作流，本质上说，和审批相关的决策无疑就是业务规则。因此，业务规则对于业务流程非常关键。这本书中我们讨论了 Drools RuleFlow，它描述了在 Drool 的上下文中如何创建业务流程。

一直以来阻碍业务规则在企业中被广泛应用的问题是如何在应用中整合业务规则引擎。即使在应用中已经嵌入了规则引擎，你未必就取得了多大的进展，因为你的规则仍然深埋在应用之内。反之，如果你将这些规则从应用中抽取出来，作为单独的决策服务，它们更具备可见性。而且，通过一个业务规则管理库，比如 Drools Guvnor（本书中已描述的）提供的功能，更易于集中维护这些规则。当你从应用中提取这些规则并将它们放到可供业务人员访问的中心库时，你可以真正地将这些业务规则当作是可管理、可监控以及易于变更的真实资产。

InfoQ：ESB 的一个卖点是安全的透明实现。您在书中描述 Synapse 时，讨论了安全的某些方面，包括 WS-Security 的实现。但有一个方面您没有谈到，也就是当在属于不同安全域（比如 WS-Trust 或者 OpenID）的服务间路由请求消息时，证书转换的身份管理如何处理。在这方面，您对安全产品有哪些建议吗？

Jeff：对。在这本书中，我并没有介绍身份管理，它是一个广泛的主题。显然，近几年来这个领域中出现了一些标准，比如，SAML。然而，我认为由于它的复杂性，它还没有被大型企业所广泛采用。另一方面，OpenID 取得了极大的成功，但是它更专注于 Web 应用，而不是 Web 服务。到目前为止，除了支持 OpenID 的 WSO2 认证产品外，还没有出现一些令人满意的开源安全产品，对于对这一领域感兴趣的人而言，WSO2 的认证产品是非常值得关注的。

InfoQ：您可以为开始使用开源产品实施 SOA 的人们提供一些建议吗？

Jeff：哈哈。推荐购买我的这本新书！坦率地说，令人值得庆幸的是，目前有大量的、可供选择的开源产品协助我们实施 SOA。显然，在我的这本书中，我只介绍了诸如 ESB、CEP、BPM、服务 / 组件框架和业务规则这些产品的一种开源产品，而除此之外，还有许多同样出色的开源产品。我认为在选择开源产品时，最重要的是评估该开源产品社区的活跃度，以及其背后的赞助商的大力支持。正如我经常所说，商业产品更加具有风险性，尤其是在当前的环境下，因为许多公司突然倒闭或者被收购，用户又使用了他们的产品，这些产品很可能只拥有少量的客户群。另外，像我在本书中提及的主流开源产品拥有广大的用户，源码免费公开，并且有许多非常熟悉这些源码的开发人员。所以说商业产品更具有风险！

Jeff：非常感谢你提出的问题，这些问题都很精彩！

InfoQ 的读者在 Manning.com 上购买这本书时，可以使用 ‘infoq35’ 打折。

查看英文原文： Book Excerpt and Interview: Open Source SOA 。

译者简介：陈义，计算机应用技术专业硕士研究生，一直专注于 SOA、BPM、ESB、EAI 和 MOM 的研究及应用。热衷于开源 SOA 项目，有志致力于 Mule、ServiceMix、ODE、ActiveBPEL、ActiveMQ、OpenJMS、Camel、CXF、XFire 以及 Tuscany 在中文社区的研究和推广工作。您可以通过 honnom (at) 163.com 联系到他。

感谢胡键对本文的审校。

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