书摘和访谈：Open Source SOA

作者 Boris Lublinsky 译者 陈义 发布于 2009年11月30日 上午12时32分

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的注册产品实现服务注册（我的bloghttp://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中文站 。