访谈和书摘：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中文站用户讨论组中与我们的编辑和其他读者朋友交流。