亲爱的 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 的代码这一事实的限制。但它确实有一些零零碎碎的东西。但这不是唯一的问题。

此存储库的旧版本加载了用于启动服务器的代码。本质上，是构建 WAR 文件并使用 Tomcat 启动它的 DIY（自己动手）变体。

哎呀！

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

现在，几乎所有内容都开箱即用地运行在正确的 Apache Tomcat 版本上。

Spring Data 入门

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

您上次手动编写 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（消息传输优化机制）。

在某个时候，您已经涵盖了所有方面，不再需要更多。这就是为什么股票报价演示被删除的原因。它在集成技术方面没有提供太多不同的内容，所以我将其删除了。

在将许多内容委托给 Spring Boot 和 Spring Data 之后，我们需要维护的示例数量减少了，并且可以更轻松地为社区提供最新的、连贯的示例。

对 SOAP 和 REST 的思考

既是 Spring Web Services（SOAP）的项目负责人，又是 Spring HATEOAS（REST）的关键贡献者，这本身就具有一定的讽刺意味。我已经与这两个社区的成员合作了数年。

深入参与基于契约的范式真正突出了（对我而言）SOAP 和 REST 之间的差异。

SOAP 关注的是捕获连接两个系统的契约。虽然详细制定两个系统之间通信流量的细节听起来不错，但它也存在副作用。这种定义明确且详细的契约带来的后果是，接口变得非常脆弱。哪怕是最细微的更改都可能导致系统中断，即需要所有相关方进行更新。当您的业务走向国际化并达到现代规模时，这种情况会进一步放大。

另一方面，REST 基于系统级转换并灵活地提供这些选项。由于没有契约，因此可以发送超过用户所需的内容，从而提供了一种将向后兼容性引入消息传递的方式。用户可以自由选择仅使用他们想要的部分。如果您保留旧链接并提供新链接，则可以实现所谓的 Postel 定律或健壮性原则。“发送时要保守，接收时要宽容”。

我们见证了 Web 的成功，它很大程度上依赖于 HTML，并且您无需在网站每次更新时都更新浏览器。甚至有一些研究表明，与服务器团队相比，在 API 的整个生命周期中，向后兼容的灵活 API 会降低客户端和服务器团队的总体成本。

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

尽管如此，某些系统仍然与 SOAP 绑定，您需要尽可能多的帮助。Spring Web Services 旨在尽可能降低复杂性。我们会在您前进的每一步陪伴您。

我们需要您的帮助！

尽管进行了所有这些更改和更新，但我相信仍然有一些部分被忽略了。或者某些部分可以得到更多关注和改进。

我们需要您的帮助来完成这些工作！

如果您在示例中发现任何问题，或者您认为存在严重偏差的地方，请不要犹豫，提交工单。

说到社区，如果没有Gyula Szalai，这项工作将无法完成，他在 2014 年获取了我们的 MTOM 示例副本，将其 Maven 化，并将其推送到 Github。在凌晨 2:00 与 SOAP 恶魔搏斗可能很棘手。有了这个可运行的示例，才真正为向您提供此版本铺平了道路。

此致,

-Greg Turnquist