上周的一次培训中，我第一次使用了 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 的设计初衷不是为了简化代码；而是为了让您专注于重要的事情。代码简化作为一种副作用，当然是我们都可以欣赏的，我敢肯定！