在上週的培訓中，我第一次使用了 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 然後就完成了」完全不同。不是那樣的！

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

Arjen 和我正在撰寫一篇文章，將會更詳細地解釋這一點。在那之前，Spring Web Services 參考手冊和 Arjen 的個人部落格應該會給你足夠的關於所有這些背後的原因的信息。

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

這個人（Thomas，是的，就是你 :) ），是如此令人難以置信的正確。Spring Portfolio 的每個部分都致力於做到這一點

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

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

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

上週五我臉上帶著大大的笑容走到我的車旁。我們結束了這次培訓，理解了最重要的教訓：Spring 並非旨在簡化程式碼；它旨在讓您專注於重要的事情。作為副作用而獲得的程式碼簡化，當然，我相信這是我們所有人都可以欣賞的事情！