Question

编写Web服务接口是否有好处，其方法都采用并返回XML文档，而不是更常用的本机类型和类的参数列表？

我们有一些像这样设计的现有Web服务。传递给它们的方法的XML文档通常很大（因为它们包含可能与方法调用相关的100个数据）。我们使用XSD文件来验证XML文档，但整体客户端开发人员的体验很差且很慢。当然最好有一个强类型接口？

Web服务是用C＃编写的，客户端是用C＃编写的，也是Java编写的（我们的一些业务伙伴使用Java）。

Answer 1

如果您完全确定您的最终用户/客户端技术是什么（例如纯功能集可能是最富有的纯.NET和Java），那么请务必继续使用强类型接口（如果可用）。但是如果你的客户群是Perl，PHP，ASP，Python等的混合包，那么我会让这些人保持简单易用的生活。

我们有许多网络服务必须由这种混合的客户端消费，虽然我希望让我们的生活变得简单，但我们必须简单地愚蠢以确保最大的互操作性。

Answer 2

另一个原因是某些非常复杂的XML文档，可以表示为类，但这会很尴尬。例如，具有许多重复元素的深层嵌套文档（例如：doc.a[3].b.c[4].d[52].e）很快就会很烦人。

此外，请记住，并非所有XML架构构造都可以直接转换为类。他们不是故意的。构建为XML而不是类型的XML Schema可能根本不会转换为类。

Answer 3

有几个原因，以及一些相关的想法：

互操作性。它肯定会加速一些粗糙的边缘，但如果你坚持简单的类，你不应该有问题。还有可能首先签订合同，但是你必须再次理解这些限制，有些情况下类生成器不能很好地工作:(但即便如此，你可以将这个部分加载为XML，而不是为整件事做这件事。
您想用它来处理不同类型的消息。甚至可以聚合这些消息。它不是唯一的解决方案，因为对定义的一些工作，您可以将这些场景纳入类型化消息。
它不需要理解所涉及的所有位，只需将适当的部分发送到适当的系统。这个是引人注目的，但即便如此，我认为没有理由不考虑如何聚合不同系统的xsd并将它们合并为您的Web服务定义。无论如何，这可能都需要完成。

关于互操作性，请注意您可以坚持使用简单模式并仍然键入它。如果这是您关注的问题，您不需要放弃对富客户端的支持，那么它的简单模式就是最好的。这些是您想要某些语言的模式类型。

Answer 4

我曾经听说比较一个服务方法和“字符串xml”进/出这比写这样的C＃函数：

public object DoSomething(object o){

}

我想有时可能会有它的用法，以防你希望你的服务支持多个版本的模式，但它实际上不是一个透明的设计，因此应该避免使用。

我甚至看到为保险公司设计服务标准的组织定义了这样的服务。 [叹息]