親愛的 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 會議上說過的，您沒有編寫的程式碼就沒有錯誤。能夠捨棄那些由 Spring Boot 處理的基礎架構部分是一種巨大的解脫。

當然，這必須以 Spring Boot 沒有大量基於 Spring WS 的程式碼為前提。但它確實有一些零星的部分。但這並不是唯一的風險。

此儲存庫的舊版本載入了用於啟動伺服器的程式碼。本質上，是 DIY（自己動手做）變體，用於烘焙 WAR 檔案並使用 Tomcat 啟動它。

哎呀！

正如 Josh Long，又名 @starbuxman，喜歡說的，「製作 JAR 而非 WAR」。透過升級到基於 JAR 的方法並依賴 Spring Boot 的 Apache Tomcat 自動配置，我們能夠從建置系統和程式碼庫中刪除任何此類內容。

現在，幾乎所有東西都可以在適當版本的 Apache Tomcat 上運作，開箱即用。

Spring Data 簡介

airline 範例基於航班預訂系統，您可以在其中查詢航班，然後提出預訂請求。它使用 JPA 來儲存所有這些資料。

您上次手動實作 JPA 是什麼時候？我的意思是，全部。手動實作。

透過遷移到基於 Spring Data JPA 儲存庫的解決方案，大約一半的自訂程式碼被廢棄，轉而使用具有 finder 方法和 @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 marshaller 解決了這個問題，然後我們就繼續前進了。

我也能夠捨棄 OpenJPA 並切換到更流行的 Hibernate。將所有內容遷移到現代 JPA + Hibernate 讓我們重新加入龐大的社群。如果社群中的任何人需要幫助，現在整個社群將更容易在 StackOverflow 等地方做出回應。

移除冗餘範例

這次更新不僅僅是關於提升版本。它還包括評估我們擁有的所有模組。

在更新 airline 範例（包括示範 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。在凌晨 2 點與 SOAP 惡魔戰鬥可能很棘手。有了這個可運作的範例，確實為向您發佈這個版本鋪平了道路。

乾杯，

-Greg Turnquist