我刚刚在 Manning Publications Co 的 Craig Walls 的“Spring in Action”第 2 版中通过 Spring-WS 阅读了有关 SOAP 的内容。他们首先写的是 Contract First，就像 Spring 文档一样，通过制作消息和方法 XML 和然后将其转换为 XSD，然后再转换为 WSDL，同时在 Spring 中连接编组和服务路径。
我必须承认，我不相信。为什么这比创建一个服务接口并基于该接口生成我的服务更好？这非常接近于在 Spring3 中定义我的 REST @Controllers。我是否可以选择使用 Spring 制作 SOAP Web 服务来选择这样的路径？
另外：我想复制一个已经存在的网络服务。我有它的 WSDL，我可以放置我的服务来代替它。这是推荐的吗？如果是这样，推荐的方法是什么？
干杯
Nik
我想你一定有你的电线交叉。
契约首先意味着定义一个 WSDL，然后创建 Java 代码来支持这个 WSDL。
契约最后意味着创建您的 Java 代码，然后生成 WSDL。
最后契约的危险在于，如果您的 WSDL 是从您的 Java 代码自动生成的，并且您重构了您的 Java 代码，这会导致您的 WSDL 发生变化。
2.3.1。脆弱性
如前所述，契约最后开发风格导致您的 Web 服务契约（WSDL 和 XSD）是从 Java 契约（通常是一个接口）生成的。如果您使用这种方法，您将无法保证合同随着时间的推移保持不变。每次更改 Java 合约并重新部署它时，Web 服务合约都可能发生后续更改。
此外，并非所有 SOAP 堆栈都从 Java 合同生成相同的 Web 服务合同。这意味着将您当前的 SOAP 堆栈更改为不同的堆栈（无论出于何种原因），也可能会更改您的 Web 服务合同。
当 Web 服务合同发生更改时，必须指示合同的用户获取新合同并可能更改他们的代码以适应合同中的任何更改。
为了使合同有用，它必须尽可能长时间地保持不变。如果合同发生变化，您必须联系您服务的所有用户，并指示他们获取新版本的合同。
Toolkit 关于 Java 接口更脆弱的观点是正确的，但我认为还有更多。
就像存在对象-关系阻抗不匹配一样，也存在对象-XML 不匹配。Spring Web 服务文档很好地解释了集合和其余部分如何使从 Java 或 .NET 类生成 XML 文档出现问题。
如果您采用 Spring 方法并从模式开始，您会做得更好。它会更稳定，并且允许“鸭子打字”。客户端可以忽略他们不需要的元素，因此您可以通过添加新元素来更改架构而不影响它们。