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