访谈和书摘：Eben Hewitt的Java SOA食谱

Eben Hewitt撰写的Java SOA Cookbook从Java实现的角度介绍了面向服务的体系结构（ SOA ）主题。 在本书中，Eben讨论了SOA模型的基础知识，使用Web服务和工具以及最佳实践的实现。 这本书以问题-解决-讨论的形式编写。 它分为四个部分：

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

作者从XML架构和SOA数据模型的介绍以及如何使用Java API处理XML文档开始讨论。 还通过代码示例讨论了使用API​​（例如JAX-WS和SAAJ ）创建Web服务应用程序。

讨论了Web服务在使用SOAP和RESTful体系结构样式实现SOA体系结构中的作用。 RESTful Web服务示例包括通过带有Servlet的HTTP Service创建纯旧XML（POX）文档，带有JAX-WS的RESTful Service以及使用Jersey容器设置JAX-RS实现。

第9章介绍了使用Apache ODE BPEL引擎使用BPEL进行服务编排。其中涉及的一些高级编排用例包括并行执行活动，同步并行执行的活动，在特定时间点执行活动，在特定时间点执行活动。特定的延迟，选择性的事件处理以及将人工任务添加到业务流程中。

还针对确定服务的数据所有权方案，记录服务并设置服务注册表讨论了诸如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上却不知道键入什么。 我想缩小差距。 它既有关于WS- *方法的章节，也有诸如寻址和MTOM之类的章节，也有关于REST原理以及如何使用JAX-RS参考实现的章节。

本书确实提供了设计方面的信息，例如哪些XML Schema设计模式可以帮助您实现可在SOA中使用的规范数据模型。 但这不是它的重点。

在担任架构师的过程中，我需要帮助与幸运的开发人员进行交流，以解决所有这些复杂的API如何相互配合，从哪里开始，需要什么，可以扔掉什么以及如何处理。帮助他们以具体方式实现SOA目标的管道。 所以确实是为他们写的。 有很多东西可以进行整理，例如哪种XML Schema设计模式可以帮助您实现规范的数据模型，以及JAX-WS批注如何映射到WSDL，如何对模式进行验证，如何设置项目，等等。 因此，我开始编译我的笔记，并意识到它们需要某种形式上的形式才能真正帮助节省开发人员的时间。 我把这本书的想法寄给了西蒙·圣·洛朗（Simon St. Laurent），很高兴奥莱利（O'Reilly）接受了。

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

EH ：对于EA办事处，服务组合管理是关键。 无论您认为过去几年中所设想的SOA是否已死，服务都将继续存在。 作为指标的价值，The 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。

DDD在创建和维护规范数据模型方面也很有用，这是SOA的重要组成部分。 所以很明显，我指的是更多的调查模式，而不是具体的面向对象模式。

InfoQ ：在团队使用敏捷和精益方法（例如Scrum，XP和看板）的软件开发环境中，应该如何实现SOA？

EH ：敏捷可与SOA一起很好地工作。 这就是我们在公司实践SOA的方式。 它适用于Scrum和XP。 看板是较新的，我不知道有哪个团队真正在看板模式下追求SOA。 通常，敏捷团队致力于单个项目，并专注于将其付诸实践，但是使用SOA，您会遇到引发可重用服务的跨项目问题。 因此，作为一名架构师，您需要了解项目团队的工作，并帮助他们了解何时可以将正在处理的内容写为服务或重用现有服务。 然后，您可以添加用于定义服务接口的待办事项并提交，以确保团队不会陷入困境。 然后，您可以与企业一起定义接口并编写开发人员可以依赖的API。 然后，开发人员在后端将它们捆绑在一起，服务使用者在前端可以写些东西，并且在中间遇到了各种各样的问题。 这似乎从不同的角度（包括测试）最大化了并行开发的机会，并使工作Swift完成。 这对我们来说很好。

特别是，精益是实现业务流程自动化的好方法。 您可以对业务流程进行建模，并在运行时获得服务实现的支持，并使用监视工具衡量其有效性，然后运行模拟以帮助您分析流程瓶颈在哪里。 精益框架非常适合此生命周期，并且我们将开始进行更多探索。

InfoQ ：您能否谈谈SOA实施框架和工具的当前状态，以及SOA架构师在选择SOA框架时应该寻找什么？

EH ：好的。 我们采取的方法是开始开源。 我在JavaOne上谈到了这一点。 我可能有点标准，所以最初我们使用纯XML，BPEL，JBI，XPath，Java等来完成所有工作，并选择了支持此功能的工具。 这给了我们几件事。 首先，我们可以从最少的前期投资开始，进行试验，弄清思路。 这有助于确保我们的教育工作可以在各种平台上进行应用，这样，如果我们想朝另一个方向发展，便可以轻松制定退出策略。

最终，我们确实想要在开源领域还不是很成熟的工具。 尤其是，某些供应商拥有围绕人工任务和BAM（业务活动监控）创建自动化流程的出色工具。 当您不被所有XML淹没时，生产率也可以大大提高。

无论您做什么，都希望了解供应商对SOA的基本看法。 许多SOA供应商都来自集成空间，因此他们拥有所有这些旧式适配器，并且您获得了适用于PeopleSoft和JDBC和Exchange的适配器，头上贴着ESB标签。 这对供应商来说很方便，但是可能不会让您走得太远。 其他人则将SOA作为事件引擎，从松散耦合和分析的角度来看，这对我非常有吸引力。 其他供应商确实专注于流程，这也非常酷。 除了简单地创建服务目录之外，如果您查看真正的生产率提高在哪里，它们还将在自动化流程中实现，因为业务人员可以理解这些模型，并且他们可以将KPI放在流程的各个步骤中，并且获取生成的仪表板，以帮助他们可视化业务中发生的事情并提高效率。

大型公司进行了大量购物，并且进行了大量合并。 因此请务必确保您的供应商稳定，并且堆栈确实是统一的。 仅仅因为供应商为17个组件添加了相同的品牌名称并不意味着它们实际上已经集成。 您想要获得一些演示，进行概念验证，看看使用他们的工具的开发人员生活中的真实情况是什么样。 真正了解工具如何协同工作。 如果您在堆栈中的工具之间看到大量的导入和导出操作，或者在开发工具中到处都是很多小的代码片段，那么您可能只是在移动问题。

另外，您可以在SOA的各个方面都做到最好，获得您最喜欢的ESB，您最喜欢的BAM，等等。 但是，当出现问题时，您就会遇到哪条喉咙窒息的问题。

InfoQ ：您对REST v。SOAP Web服务体系结构模型有何看法？ SOA开发人员在其应用程序中使用这些SOA模型中的一个或两个时，应考虑哪些设计和体系结构方面的考虑？

EH ：说实话，我认为这是一种错误的反对。 作为开发人员或架构师，您都需要两个都放在后兜。 它们都具有引人注目的功能。 您将需要与使用SOAP的后端系统集成，并且需要与使用Atom或RSS或其他功能的第三方服务集成。 如果您有选择的余地，请根据给定的应用程序，性能要求，客户要求等，使用最佳工具来完成工作。 最终，要成功使用SOA，您需要遵循相同的通用原则：提供相对稳定的，基于标准的接口； 不要泄漏您的实现； 隐藏在抽象层的后面，以保持协议和实现在您的域中独立，将服务用于跨领域的问题，例如安全性，转换和规则； 确保消费者没有与您的模型不当捆绑； 拥有良好的文档以及清晰的版本控制和升级路径； 确保您知道实际上正在运行的服务，并了解谁在使用它们。 无论您选择SOAP还是REST，都需要解决所有这些问题，而这些正是您真正取决于成功的决定。 最后，您不希望您的消费者在厨房里看到香肠的制作方法。

但是这些也不是唯一的选择。 您也可以根据需要使用简单的JMS做很多事情。 这种方法非常快速，非常脱钩，基于标准，并且供应商开始将SOAP over JMS集成到他们的产品中。 这始于BEA，Software AG也正在实施。 您可以使用.NET中的JMS。 它并不能解决所有问题，但是有很多选择。 我已经与对这种方法感到满意的建筑师进行了交谈。

您知道，这类战争会卖票，但您可以使用任何语言或任何风格编写好的和不好的应用程序。 阅读一些相关的WS- *规范，并阅读Roy Fielding的论文，以帮助您选择最适合自己的。 但是，如果您了解并致力于SOA原则，那将很好。

InfoQ ：您对本书和SOA主题还有其他意见或想法吗？

EH ：Java SOA Cookbook做得很好，受到了广泛的好评，这真是太棒了。 我希望它对人们有用，并节省一些时间。

在SOA方面，我将非常感兴趣。 我正在研究的是如何将其用作事件驱动架构的基础，并与之协同工作。 事件允许松散耦合，为商业智能带来良机，而复杂事件处理引擎和事件流处理引擎之类的工具可以提供数据关联，从而以传统领域方法中难以实现的方式促进解释。 因此，按照这些思路，我现在正在研究解构软件体系结构（DSA）的概念。 这确实与许多公认的想法背道而驰。 我在研究生院学习了一些哲学，尤其是关于解构的哲学，多年来观察德里达的解构主义思想在流行文化中被误传了，但是从最初的建筑学开始，它们就以有趣的新方式应用于建筑领域。 1980年代到烹饪艺术界更近了。 我认为我们可以从中学到很多东西并将其应用于软件体系结构中。 例如，在我称之为DSA的情况下，强域模型不再支持具有某些约束的事件，并且上下文变得更加灵活。 如果您想关注我的研究，我会将其研究保留在spearsource.com上。

InfoQ ：谢谢Eben。

翻译自: https://www.infoq.com/articles/hewitt-javasoacookbook/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1