访谈和书摘：Eben Hewitt 的新书《Java SOA Cookbook》

Eben Hewitt 的新书《Java SOA Cookbook》从Java 实现的角度讨论了面向服务架构（ SOA ）主题。在这本书中，Eben 讨论了 SOA 模型基础，如何使用 Web 服务来实现它，工具和最佳实践。全书采用“问题 - 解决方案 - 讨论”的写作风格，共分 4 个部分：

• SOA 基础
• Web 服务
• 业务流程
• 互操作性和服务质量

作者在讨论的开始介绍了 XML Schema 和 SOA 数据模型，以及如何使用 Java API 来处理 XML 文档。在讨论使用诸如 JAX-WS 和 SAAJ 这样的 API 来创建 Web 服务应用时，作者也给出了相应的代码示例。

Web 服务在实现 SOA 架构（使用以 SOAP 为基础）和 RESTful 架构风格中的作用也在本书中进行了讨论。 RESTful Web 服务的例子包括：使用 Servlet 创建一个“使用 HTTP 来传输普通 XML 文档（Plain Old XML (POX) document over HTTP）”服务，使用 JAX-WS 创建一个 RESTful 服务，以及使用 Jersey 容器来安装 JAX-RS 实现。

本书第 9 章讨论了如何使用 BPEL 来进行服务编配，BPEL 引擎采用的是 Apache ODE 。本章一些高级的编配用例包括：并行执行活动，并行执行活动的同步，在特定点按时执行活动，在特定延迟之后执行活动，选择性事件处理，以及给业务流程增加人工任务。

本书还讨论了其他主题，如 SOA 治理，讨论涉及确定服务的数据所有权模式，服务文档化，以及安装服务注册库。本书最后讨论了企业服务总线（ ESB ），ESB 在 SOA 实现中的作用，Java 业务集成（ JBI ），以及商业（Oracle Service Bus、Software AG/webMethods ESB 和 TIBCO BusinessWorks）及开源（Mule、Apache ServiceMix 和 OpenESB）ESB 容器。

InfoQ 就本书、主要的写作动机和其他主题对 Eben 进行了采访。本次访谈中涉及的一些主题有：

• SOA 在企业架构中的作用
• 敏捷和精益软件开发环境下的 SOA 实现
• SOA 实现框架和工具

同时，我们从《Java SOA Cookbook》节选了样章（SOA 治理章节；1,353 KB PDF）供读者下载试读。

InfoQ：《Java SOA Cookbook》背后的主要写作动机是什么？

Eben Hewitt（EH）：我撰写《Java SOA Cookbook》是为了帮助 Java 开发者写出 SOA 架构策略建议的那种应用。随着 SOA 这些年来变得流行，有不少从“管理者指南”角度撰写的 SOA 书籍，这些建议非常笼统、层次非常高，在读了几本这样的书之后，你会想“太好了，这就是我想要做的”，然后坐在 IDE 前，你却写不出一行代码。我就是想消除这种断层。本书中有几章关于 Addressing 和 MTOM 这两种 WS-* 方法的内容，但也有一章关于 REST 原则，以及如何使用 JAX-RS 参考实现。

本书还包含了设计方面的内容，如哪种 XML Schema 设计模式可以帮助你实现 SOA 中可能使用的规范数据模型（Canonical Data Model）。但这不是本书的重点。

作为架构师，我需要去帮助我有幸与之共事的开发者去理解这些复杂的 API 如何一起使用，从哪儿开始，哪些是需要的，哪些是可以丢掉的，以及如何处理它们的交互，用具体的方式去帮助他们认识到 SOA 的目标。因此，本书实际是为他们而写的。书中包含了许多诸如哪些 XML Schema 设计模式可以帮助你来实现规范数据模型，JAX-WS 注解如何映射到 WSDL，如何根据 Schema 进行验证，如何创建项目等内容。于是，我开始整理笔记并意识到它们需要稍微正式一点，以便真的能帮助开发者节约时间。我把本书的想法发给了 Simon St. Laurent，并且很高兴看到 O’Reilly 接受了它。

InfoQ：SOA 在企业架构（EA）领域中的作用是什么？

EH：对于负责 EA 的人来说，服务组合（Service Portfolio）管理是关键。不论你是象大家近些年来认为的 SOA 已死或是相反，服务仍然还是存在。值得注意的是，Open Group 已经给 TOGAF 增加了一个 SOA 模块。我认为 SOA 之战已经尘埃落定，该是时候让 EA 来考虑在实现服务之后的下一步工作了。可能是 BPM，它是个绝佳的素材；也可能是事件处理；或者要我来说，二者都是。我可是希望鱼和熊掌可以兼得。

当然，EA 知道 SOA 不可能解决所有事情，就像模型驱动架构不能解决所有事情一样。因此，在我看来，SOA 在 EA 中的作用是启蒙，同时扮演服务目录管理者，创建标准，在服务设计、开发、API、版本管理、监视等方面提供指导，然后确定你自己关于在哪些地方自动化流程的策略，以及在事件模型中工作的方式。

SOA 已经经历了黑格尔说的扬弃，并且现在可以只作为整体的一部分来促进新的创新。在某些业务中，这些创新之一可能是使用服务目录来解放遗留系统的外在策略。很明显，EA 需要对此密切关注。

InfoQ：领域驱动设计（DDD）概念最近引起了非常多的注意。DDD 关注的是把业务领域的概念映射到软件制品，而这正是 SOA 要完成的目标。在后台缺乏坚实的领域模型和实现的条件下，SOA 实现是否可以成功？SOA 是否是对 DDD 的补充？

EH：领域驱动设计的核心实际是鼓励开发者和分析师以业务的语言去关注领域，而且它可以和其他策略合作得很好，包括 SOA。如果使用 RESTful 架构并将业务对象映射到资源，DDD 的作用尤其强大。我猜有些分析师会把这称为 WOA。

在创建和维护 SOA 的重要组成——规范数据模型方面，DDD 同样也非常有用。因此，我显然会对调查研究的模式谈得更多些，而对具体的面向对象模式则涉及较少。

InfoQ：在使用诸如 Scrum、XP 和看板（Kanban）这样的敏捷和精益方法论的软件开发环境中应该如何实现 SOA？

EH：敏捷和 SOA 可以搭配得很好。这也是我们公司实践 SOA 的方式。它可以与 Scrum 及 XP 结合使用。看板相对较新，我还不知道有哪个团队真的在看板模型下从事 SOA 的。典型的敏捷团队致力于单个项目，专注于把它实现，但是在 SOA 环境下，你必须关注多个项目，这样才能发现可重用的服务。因此，作为架构师，你需要了解各项目团队目前的工作，帮助他们看到正在做的工作何时可以写成一个服务或重用现有服务。然后，你就可以增加一个定义服务接口的 Backlog，并对它负责，这样团队的工作就不会停顿。接着，你就可以根据业务定义接口，书写开发者可以依赖的 API。然后，开发者在后台跟它配合，服务消费者在前台根据它书写，大家最后在中间汇聚在一起。这似乎最大化了各方面（包括测试）并行开发的可能，可以迅速的完成工作。在我们看来，这样的效果非常好。

精益尤其是实现业务流程自动化的好方法。你对业务流程进行建模，服务实现在运行时对其进行支持，然后使用监视工具来度量它们的效能，最后运行仿真来帮助你分析业务瓶颈所在的。精益框架非常适合这种生命周期，我们也正开始这方面的进一步探索。

InfoQ：你能谈谈 SOA 实现框架和工具的现状，以及在选择 SOA 框架时 SOA 架构师应该注意的地方吗？

EH：当然可以。我们采用的方式是从开源开始。我在 JavaOne 上已经讨论了这一主题。我可能有点迷信标准，因此我们一开始所做的任何事情都是直接使用 XML、BPEL、JBI、XPath、Java 等等，然后选择支持它的工具。这对我们有几个好处。首先，这可以让我们的先期投入最少，稍作尝试，就可以得出我们的想法。这也确保了我们的教育成果可以在不同平台下得到应用，这样，在我们想退出某一策略去尝试另一个方向时可以轻易的完成。

最后，我们确实会需要某种在开源领域还不成熟的工具，尤其是在某些厂商对创建支持人工任务的自动化流程和 BAM（业务活动监视）方面已经有了极好工具的情况下。如果你没有把所有的东西都用 XML 来实现的话，生产率也可以得到大幅提高。

不论你采用什么方法，你都需要理解厂商对 SOA 的基础愿景。很多 SOA 厂商都来自集成领域，因此他们用适配器来支持所有这些遗留的东西，你可以在贴着 ESB 标签的礼盒中找到 PeopleSoft、JDBC 和 Exchange 它们的适配器。这暂时对厂商来说很方便，但不会让你走得长远。有些厂商则将 SOA 视为一个事件引擎，从松耦合和分析的角度看，它对我很有吸引力。有些则实际关注的是流程，这也很酷。除了简单地创建服务目录，要是你关注于从哪里可以提高生产力，那其要点则在于自动化流程，因为这些模型可以被业务人员理解，而他们可以在流程中相关步骤设置一些 KPI，然后获得生成的仪表盘来帮助他们发现业务发生的事情，然后提高效率。

在大公司里会有很多东西要购买，要合并。因此，一定要小心地确保供应商的稳定，所用技术的确是统一的。不要仅因为 17 个组件的前缀都贴有相同的标签就认为它们就真的能集成在一起。你需要做些示例，进行概念证明，看看开发人员日常使用这些工具的效果。对于这些工具的集成进行严格验证。要是你看到技术集中的工具之间存在着大量的导入导出，或看到大量小代码片段在开发工具中随处可见，你的问题可能就已经取得了一定进展。

或者，你也可以选择 SOA 中每一个方面最好的工具，购买中意的 ESB，得到喜欢的 BAM，依次类推。但等到问题出现，你可能就觉得进退两难了。

InfoQ：你对 REST 和 SOAP Web 服务架构模型之间的对立是如何理解的？在应用中使用这两个 SOA 模型之一或都使用时，SOA 开发者在设计和搭建架构时应该考虑哪些？

EH：老实说，我认为这种对立完全是错误的。作为开发者或架构师，你应该在后备箱里为二者都留出位置。它们二者都具有引人注目的特性。集成后台系统时，你需要使用 SOAP；在集成第三方服务时，你会用到 Atom、RSS 或其他服务。在选择时，要因地适宜，根据应用、性能需求、客户端需求等做出判断。最后，要想 SOA 取得成功，你得坚持相同的通用原则：提供相对稳定、基于标准的接口；不要暴露实现，将之隐藏在一个抽象层之后，以保持协议和实现独立于领域；对于诸如安全、转换和规则这样的横切点问题，使用服务；确保消费者没有不恰当的绑定到你的模型上；创建良好的文档，包含清晰的版本管理和升级路径；确保你知道实际运行的是哪个服务，并清楚谁正在使用你的服务。不论你是选择 SOAP 还是 REST，这些问题你都需要解决，它们才是决定你成功的关键。最后，你不会期望你的消费者进入厨房，知道香肠是如何制造出来的。（译注：语出德国名相俾斯麦的名言：“世界上有两样东西，你尽可以去喜欢它，但是一定不要去见识它的制作过程。其中，一个是香肠，一个是法律。”。德国人喜欢吃香肠，却没几个人愿意去了解香肠的制作过程。因为香肠制作过程看了实在让人倒尽胃口，甚至让人对自己至爱的香肠的卫生和美味产生怀疑，于是，以后每次吃香肠时总是不禁浮现香肠的制作场景，不免胃口全无。慢慢地，吃香肠的嗜好就丢掉了。）

但它们俩并非唯一的选择。比方说，你也可以直接使用 JMS 来做很多事情，这完全取决于你的需求。这种方式非常的快，非常的解耦，基于标准，厂商们正开始在他们的产品中使用 JMS 来传递 SOAP 消息（SOAP over JMS）。回想起来，BEA 和 Software AG 也采用了这种实现。你可以让 JMS 和.NET 一起工作。这并不能解决所有事情，但这也是些选择。我与喜欢这种方法的架构师们已经对此进行过讨论。

这种论战虽然会吸引眼球，但你知道，任何语言或风格，都可能会导致好的程序和坏的程序，这要看是什么人在使用它。读一些相关的 WS-* 规范，再读读 Roy Fielding 的博士论文，它们可以帮助你选择最适合你的方案。但只要理解并遵循 SOA 原则，那么你将不会有什么大问题。

InfoQ：你对于本书和 SOA 主题还有什么其它的评论和想法吗？

EH：《Java SOA Cookbook》是本不错的书籍，收到的反馈也很好，真是太棒了。我希望它能对人们有帮助，可以节约他们的时间。

就 SOA 来讲，我非常想知道它将走向何方。我想了解的是，它将如何发挥作为事件驱动架构基础的作用，以及如何与之协同工作。事件允许松耦合，为商业智能也提供了帮助，象复杂事件处理引擎和事件流处理这样的工具可以提供数据关联性，这将有利于解释一些难以用传统领域方法解释的事情。那么，在接下来的数行里，我想谈一下我目前正在从事的解构软件架构（Deconstructed Software Architecture，DSA）的概念。它与被人们接受的很多概念都不相同。我在研究生时学习了一些哲学，尤其是解构，并经过多年观察到德里达的解构思想在流行文化中被广泛传达错误了，但后来它们也以有趣新奇的方式在一些领域得到了应用，从开始于 20 世纪 80 年代早期的建筑结构，到最近的厨房艺术。我认为它有很多值得我们学习并应用到软件架构的东西。例如，在我称为 DSA 的软件架构中，强领域模型更倾向于事件，它具有某种约束，上下文则成为一种更易变的概念。我会继续在这一领域的研究，如果有兴趣想了解其近况，请访问 spearsource.com。

InfoQ：非常感谢，Eben。

查看英文原文： Interview and Book Excerpt: Eben Hewitt’s Java SOA Cookbook 。

感谢黄璜对本文的审校。

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