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