亲爱的 Spring 社区：

Spring Web Services 示例（spring-ws-samples）已升级！

您可能知道，此示例集合的许多部分可以追溯到 2006 年。今天，我很高兴地报告它已通过多种方式进行了更新。

• Spring Boot 简介

• Spring Data 简介

• 删除过时的技术

• 删除冗余示例

这是一项艰巨的任务，花了我几周时间，但鉴于 SOAP 令人难以置信的持久性，这是为了服务 Spring 社区而必须完成的事情。

Spring Boot 简介

这个代码库中一个最明显的缺失就是 Spring Boot 的身影。

如果你长期关注本博客网站，你就会知道 Spring Boot 有多酷、多受欢迎。这些示例是在 Spring Boot 出现之前很久创建的，它们需要更新以充分利用最先进的技术。但这不仅仅是因为我们只是“自用”自己的东西。

Spring Boot 引入了任何项目都应该采纳的关键概念。其中最重要的是保持稳定、安全的版本。每当 Spring 组合产品报告漏洞时，我们的团队都会评估影响，制定计划，推出变更，并通知社区，以便每个人都可以安全升级。

通过简单地提升 Spring Boot 的版本来升级应用程序真是不可思议。再加上 Spring 团队对向后兼容性的投入，当你选择 Spring Boot 时，你就知道你拥有一个坚实的技术栈，并且不会被时代抛弃。

将所有这些示例都迁移到 Spring Boot 上是一个关键性的改变，这将使我们未来的更新更加容易。

但这还不是全部。

Spring Boot 的另一个魔力在于减少了你个人必须编写的代码量。正如我曾经在一次 SpringOne 大会上所说，你没有编写的代码就没有 bug。能够舍弃大部分基础设施，转而由 Spring Boot 处理，真是极大的解脱。

当然，这必须以 Spring Boot 中没有**很多**基于 Spring WS 的代码为前提。但它确实有一些零散的代码。但这并不是唯一需要考虑的问题。

这个代码库的旧版本充满了用于启动服务器的代码。本质上，它是自己动手 (DIY) 烘焙 WAR 文件并用 Tomcat 启动它的变体。

天哪！

正如 Josh Long (又名 @starbuxman) 喜欢说的：“制作 JAR 而不是 WAR。” 通过升级到基于 JAR 的方法并依靠 Spring Boot 的 Apache Tomcat 自动配置，我们能够从构建系统和代码库中删除所有此类内容。

现在，几乎所有东西都能在适当版本的 Apache Tomcat 上开箱即用。

Spring Data 简介

**航空**示例是基于一个航班预订系统，您可以在其中查找航班然后提出预订请求。它使用 JPA 存储所有这些数据。

你上次手动编写 JPA 是什么时候？我的意思是，**所有**的，手动编写。

通过迁移到 Spring Data JPA 基于仓库的解决方案，大约一半的自定义代码被废弃，转而使用带有查找方法和 `@Query` 注解方法的接口。（参见前面关于你不需要编写的代码的评论！）

这不仅仅是关于删除不必要的代码。它比这更深入。通过使用现代框架方法，你还可以知道资源得到了妥善管理。事务得到了正确处理。数据存储根据行业标准得到了更好的利用。

这是一个胜利。

移除过时技术

2000 年代初期许多基于 SOAP 的工具都是基于 Ant 的，而 Ant 已经被 Maven 和 Gradle 取代。

当你使用像 Ant 这样的低级构建系统时，你会发现自己花在构建系统上的时间远远超过了应有的份额。通过将事情提升到 Maven，并辅以少量的嵌入式 Ant 任务，进行项目级别的更改变得容易得多。

除此之外，迁移到 Spring Boot 2.3.1.RELEASE 暴露了这些示例是基于 Spring Framework 3 运行的。

哇！真是怀旧。很高兴知道当我将所有内容都提升到 Spring Framework 5 时，**所有**东西都运行得相当流畅，只有一个例外（Apache XML Beans 中一个很早以前就被弃用和删除的编组组件）。

事实证明，Apache XML Beans **仍然**存在，但那三个人可能**已经**知道如何将他们的应用程序集成在一起了。

迁移到 JAXB 编组器解决了这个问题，我们继续前进。

我也能够放弃 OpenJPA 并转向更流行的 Hibernate。将所有东西都迁移到现代的 JPA + Hibernate 让我们重新加入了一个庞大的社区。如果社区中的任何人需要帮助，现在整个社区在 StackOverflow 等地方做出回应将变得容易得多。

移除冗余示例

这次更新不仅仅是提升版本。它还包括评估我们拥有的所有模块。

更新了**航空**示例后，该示例包括演示 SAAJ、Axis1、JAX-WS、JMS 和 Spring WS，很明显，**每个**演示都展示了多个 SOAP 提供程序。还有一些演示包括基于 SOAP 的安全提供程序以及 MTOM（消息传输优化机制）。

在某个时刻，你已经覆盖了所有基础，不再需要更多了。这就是为什么 Stock Quoting 演示被撤下。它在集成技术方面没有提供太多不同的东西，所以我把它撤下了。

将大部分工作委托给 Spring Boot 和 Spring Data 后，我们需要维护的示例数量减少了，这使得我们更容易为社区提供最新的、具有凝聚力的示例。

SOAP 和 REST 的内省

作为 Spring Web Services (SOAP) 的项目负责人和 Spring HATEOAS (REST) 的主要贡献者，这其中存在着某种讽刺。我与这两个社区的成员合作多年。

深入研究基于契约的范式，确实凸显了 (对我而言) SOAP 和 REST 之间的差异。

SOAP 旨在捕捉连接两个系统的契约。虽然敲定两个系统之间通信流量的细节听起来不错，但它有一个副作用。这种定义良好且详细的契约的后果是接口变得非常脆弱。最微小的更改都可能破坏事物，即要求更新所有相关方。当您的业务走向国际并达到现代规模时，这种情况会被放大。

另一方面，REST 基于系统级转换并灵活地提供这些选项。由于缺乏契约，可以发送比用户需要更多的信息，从而提供了一种将向后兼容性纳入消息传递的方式。用户可以自行决定只消费他们想要的部分。如果您在提供新链接的同时保留旧链接，您可以实现所谓的 Postel 定律或鲁棒性原则：“在您发送的内容上要保守，在您接受的内容上要自由。”

我们已经看到了网络的成功，它在很大程度上建立在 HTML 和这样一个事实之上：您不必每次网站更新时都更新浏览器。甚至有研究表明，在 API 的整个生命周期中，具有向后兼容性的灵活 API 总体上降低了客户端和服务器团队的成本。

在更新每一个演示时，我感受到了这种缺乏灵活性。每个演示似乎都需要与调整一系列镜子以精确瞄准激光束相同的努力。我怀念创建基于 JSON 的服务与超媒体结合的轻松。（也许有一天我会就这个主题制作一个视频！）

尽管如此，有些系统仍然与 SOAP 紧密相连，你需要尽可能的帮助。Spring Web Services 旨在尽可能地降低复杂性。我们会在每一步都与你同行。

我们需要你的帮助！

尽管有所有这些更改和更新，我确信有些部分被忽略了。或者有些部分需要更多的关爱。

我们需要你的帮助才能做到！

如果你在示例中的任何地方发现问题，或者你觉得有些地方严重不一致，请不要犹豫 开一个工单。

说到社区，这项工作如果没有 Gyula Szalai 就无法完成，他曾在 2014 年获取了我们的 MTOM 示例的副本，将其 Maven 化，并推送到 Github。凌晨两点与 SOAP 恶魔战斗可能很棘手。有了这个可行的示例，确实为将此版本发布给您铺平了道路。

干杯，

-Greg Turnquist