上週的一次培訓中，我第一次使用了 Spring Web Services 的第一個釋出候選版本。距離 Arjen 釋出他寶貴的 RC1 還沒到兩週，所以向一些與會者展示這款新產品非常棒。

在 Web 服務部分之前，我們做了一點 JMX 和遠端呼叫，展示了 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 然後我們就完成了”是完全不同的。它不是那樣的！

回到我上週進行的培訓；當我們剛結束 JMX 部分時，我開始了我通常關於 Web 服務的講解。簡而言之就是：Web 服務 != 遠端呼叫，您最好習慣這樣一種事實，即這意味著實現 Web 服務所需的工作量 != 將服務匯出到 RMI 端點所需的工作量（我懷疑在所有情況下，“!=”都可以被“>”替換）。

Arjen 和我正在撰寫一篇將更詳細地解釋這一點。在此之前，Spring Web Services 參考手冊和Arjen 的個人部落格應該能為您提供有關這一切背後原因的大量資訊。

然而，上週令我（非常愉快地）感到驚訝的是，培訓中的一位與會者突然打斷了我，說：“嘿，我明白了，Spring 方法不一定是為了簡化我的程式碼或減少程式碼量，而是為了消除不必要的複雜性，讓我能夠專注於重要的事情。”。

這位夥計（Thomas，是的，就是你 :)）說得真是太對了。Spring Portfolio 的每個部分都專注於做 exactly that

依賴注入和 AOP 專注於提供一種簡潔而強大的方法來注入依賴項和實現跨切面行為。模組化和關注點分離是應該輕鬆實現的事情，而且是非常重要的問題。Spring 的 DI 容器和 AOP 功能專注於讓您實現模組化和良好的關注點分離。它們並不主要專注於簡化您的程式碼。使用 DI 和 AOP 產生這個結果，我幾乎可以稱之為一種有趣的副作用 ;-)

Spring 的遠端匯出器旨在提供一種幾乎透明的方式來從遠端位置呼叫伺服器端程式碼。當我們想要實現基於 RMI 的遠端端點時，我們就是在隱式地表明，我們希望將我們的服務與我們的客戶端緊密耦合。Spring 的遠端匯出器並非設計成僅用四行 XML 來實現這一點。它們旨在提供這種近乎透明的程式設計體驗。能夠僅用四行 XML 實現這一點，再次強調，是一個有趣的副作用。

現在是關鍵……當我們實現 Web 服務時，我們就是隱式地表明，我們希望我們的服務與任何可能使用我們服務的潛在客戶端鬆散耦合。我們並不是（也不應該）尋找一種透明的方式來使用 <soap:Envelope> 和 <soap:Body> 標籤來發出方法呼叫。版本管理、靈活性和保持向後相容的能力是實現健壯、經久耐用的 Web 服務以及實現客戶端與服務鬆散耦合的關鍵。Spring Web Services 的設計就是為了解決這些問題，並讓您能夠非常輕鬆地解決它們。它並非旨在簡化您的程式碼！儘管我非常確信，在許多場景中，使用 Spring Web Services 最終得到的程式碼將盡可能簡單易懂！

上週五，我帶著滿臉的笑容走到了我的車旁。我們結束了這次培訓，理解了最重要的課程：Spring 的設計初衷不是為了簡化程式碼；而是為了讓您專注於重要的事情。程式碼簡化作為一種副作用，當然是我們都可以欣賞的，我敢肯定！