C# Java/WCF互操作何时真正需要WSIT？Java/asmx需要它吗？

SOAP被认为是Web服务的可互操作标准，那么什么时候真正需要WSIT呢

扮演魔鬼代言人：

---

另外，就我所见，WCF远不止SOAP，它们似乎以REST为目标。微软和SUN不是在掩盖这样一个事实：他们在巨大的SOAP复杂性上犯了一个错误，现在在不公开承认的情况下采用REST，并用WSIT和WCF为销售新工具在其上建造了另一堵复杂的墙：）

如果你提到这一点，它是一系列web服务的实现技术只是一个例子。顺便说一句，我认为WSIT已经被整合到了

SOAP是一种规范，定义了交换web服务消息的协议。它告诉你读和写什么，但实际上并没有读和写——它不是软件，只是软件应该如何运行的规范

WSIT和WCF都提供遵守SOAP规范的webservice实现——它们都是SOAP规范的实现。您不必使用这些框架——您可以自己编写XML，但从现有实现开始当然要容易得多，因此您可以关注Web服务的逻辑，而不是plumnbing

您需要SOAP—这是两个独立实现的共同点，也是使WSIT/AxisWCF互操作成为可能的关键因素。如果您少考虑实现技术，多关注服务公开的外部接口（即SOAP），可能会有所帮助

---

OO编程中的接口/实现类分离有许多相似之处。一旦您有了一个实现接口的实例，您就不会真正关心实际的实现细节——只关心实现是否遵循指定的接口。对于web服务，您（通常）不关心服务或客户端是否在WSIT、Axis、WCF、asmx中实现，或者任何其他编程语言—您只关心它公开/使用SOAP接口。

这并没有向我解释为什么它是必要的，因为SOAP应该是可互操作的？这就像说TCP/IP应该是可互操作的。SOAP中打包的内容和打包方式使其具有互操作性。例如，您可以在SOAP中将调用编码为RPC或doc。就我所知，WSDL定义了一个契约接口，那么为什么需要另一种契约呢？另外，就我所见，WCF远不止SOAP，它们似乎以REST为目标。微软和SUN不是在隐瞒一个事实，即他们在巨大的SOAP复杂性上犯了一个错误，现在在不公开承认的情况下采用REST，并使用WSIT和WCF在其上构建另一堵复杂的墙：）您不需要另一个契约-WSDL是定义端点和发送/接收消息的契约，但是，如果您发送的消息是自主开发的专有内容，那么您将找不到能够进行开箱即用通信的客户机。如果您选择SOAP作为您的消息格式，那么您有一个供客户遵循的公共合同，通常带有开箱即用的支持。WSIT/WCF是该合同的实施，负责大部分实施细节。