在上周的一次培训中，我第一次使用了 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 的设计目的不是为了简化代码；它的设计目的是让您专注于重要的事情。 作为副作用获得的简化代码，当然是我们都可以欣赏的东西，我确信！