親愛的 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