亲爱的 Spring 社区成员们：

Spring Web Services 示例 (spring-ws-samples) 已升级！

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

• Spring Boot 简介

• Spring Data 简介

• 删除过时技术

• 删除冗余示例

这是一项历时数周的艰苦工作，但考虑到 SOAP 惊人的持久性，为了服务 Spring 社区，这项工作是必须完成的。

Spring Boot 简介

这个仓库中一个最显著的缺失就是 Spring Boot 的身影。

如果你长期关注这个博客网站，你就会知道 Spring Boot 有多酷、多受欢迎。这些示例是在 Spring Boot 问世很久之前创建的，需要更新才能充分利用最新技术。但我们这样做不仅仅是因为“自产自销”（dogfooding）我们的产品。

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 是什么时候？我的意思是，全部都手动处理。

通过迁移到 Spring Data JPA 基于 Repository 的解决方案，大约一半的自定义代码被放弃，取而代之的是带有 finder 方法和 `@Query` 注解方法的接口。（回想一下之前关于你没有写的代码的评论！）

而且这不仅仅是删除不必要的代码。它更深入。通过使用现代框架方法，你也知道资源得到了妥善管理。事务处理正确。数据存储也更符合行业标准。

这是一种胜利。

删除过时技术

许多早在21世纪初的基于 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 marshaller 解决了这个问题，然后我们就继续了。

我还得以放弃 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