在上週的一次培訓中，我第一次使用了 Spring Web Services 的第一個候選釋出版本。距離 Arjen 釋出他珍愛的 RC1 才過了兩個星期，所以向一些與會者展示這個新產品非常棒。

在 Web Services 部分之前，我們做了一些 JMX 和 remoting，展示了 Spring 的匯出器功能。 你可能知道，這允許你將任何 Spring 管理的 bean 匯出到遠端端點或 JMX 登錄檔，只需極少的宣告性配置

<bean id="myService" class="com.mycompany.MyServiceImpl">
    <property name="myDao" ref="myDao"/>
</bean>

<bean class="org.springframework.remoting.rmi.RmiServiceExporter">
	<property name="serviceName" value="myService"/>
	<property name="serviceInterface" value="com.mycompany.MyService"/>
	<property name="service" ref="myService"/>
</bean>

這一切都非常容易，並且與觀眾通常對 Spring 的看法非常一致：Spring 正在使所有曾經非常困難的東西變得如此簡單；它只需要幾行 XML（或者我們目前正在實現的其他一些配置選項）就完成了。 這當然是真的，但這不是我希望人們在離開 Core Spring 培訓時留下的印象。

幸運的是，透過 Spring Web Services 的形式，Arjen 給了我一些極好的材料，可以一勞永逸地說，我們希望你對 Spring 的看法與“僅僅新增幾行 XML 然後我們就完成了”完全不同。 不是那樣的！

回到我上週進行的培訓；當我開始我通常關於 Web Services 的談話時，我們剛剛完成了 JMX。簡短的版本基本上是：Web Services != remoting，你最好學會接受這個事實，這意味著實現 Web Service 所需的工作量 != 將服務匯出到 RMI 端點所需的工作量（我懷疑在所有情況下 != 都很可能被 > 替換）。

Arjen 和我正在撰寫一篇文章，將更詳細地解釋這一點。 在此之前，Spring Web Services 參考手冊和 Arjen 的個人部落格 應該會給你提供大量關於這一切背後的推理的資訊。

然而，上週讓我（非常愉快地）驚訝的是，一位參加培訓的人突然打斷我說：“嘿，我知道了，Spring 方法不一定是為了簡化我的程式碼或減少程式碼量，而是為了消除不必要的複雜性，讓我專注於重要的事情。”。

這傢伙（Thomas，是的，就是你:)），太對了。 Spring Portfolio 的每個部分都專注於完全做到這一點

依賴注入和 AOP 專注於提供一種乾淨而強大的方法來注入依賴項和實現橫切行為。模組化和關注點分離是應該容易實現且非常重要的問題。 Spring 的 DI 容器和 AOP 功能專注於允許您實現模組化和良好的關注點分離。它們主要不是為了簡化您的程式碼。事實上，這是使用 DI 和 AOP 的結果之一，我幾乎會說這是一個很好的副作用 ;-)。

Spring 的遠端匯出器旨在提供一種近乎透明的方式來從遠端位置呼叫伺服器端程式碼。當想要實現基於 RMI 的遠端端點時，我們隱含地表明我們希望將我們的服務與我們的客戶端緊密耦合。 Spring 的遠端匯出器並非旨在僅用四行 XML 來完成此操作。它們旨在獲得這種近乎透明的程式設計體驗。事實上，它可以用區區四行 XML 完成，再次，這是一個不錯的副作用。

現在是關鍵... 當我們實現 Web Service 時，我們隱含地表明我們希望將我們的服務與任何可能使用我們服務的潛在客戶端鬆散耦合。我們不是（或者不應該）尋找一種透明的方式來使用 <soap:Envelope> 和 <soap:Body> 標籤發出方法呼叫。 版本管理、靈活性和保持向後相容的能力是實現強大 Web Service 的關鍵，這些 Web Service 經受住時間的考驗並將我們的客戶端與我們的服務鬆散耦合。 Spring Web Services 旨在解決這些問題並允許您非常容易地解決它們。 它不是為了簡化您的程式碼！ 儘管我非常肯定，在許多情況下，當您使用 Spring Web Services 時最終得到的程式碼會盡可能簡單易懂！

上週五我臉上帶著燦爛的笑容走到了我的車。 我們結束了這次培訓，理解了最重要的一課：Spring 的設計目的不是為了簡化程式碼；它的設計目的是讓您專注於重要的事情。 作為副作用獲得的簡化程式碼，當然是我們都可以欣賞的東西，我確信！