我正在创建一个 WCF 服务，该服务将由 .NET 和 Java 客户端应用程序使用。
我们在团队中没有任何 Java 经验，因此正在寻找要遵循的准则或规则，以确保我们不会意外地在 WCF 服务接口中包含任何类型，也不会执行任何其他会阻止 Java 客户端应用程序使用该类型的行为。
我们的担心是否有充分的理由？如果是这样，我们应该警惕什么？
关注的一个示例是 .NET 值是否以 Java 客户机可以正确理解的方式在服务接口中表示。DateTime
关注点的第二个示例是使用任何可为 null 的值类型 （等）。bool?int?
目前，我们的一些开发团队正在手写 .xsd 文件，以定义 WCF 接口方法将作为参数并作为返回值返回的各种对象。然后，他们使用 xsd.exe 从这些类自动生成 C# 类。
这背后的基本原理是，它保证生成的类不会包含任何 .特定于网络。
缺点是这增加了开发负担，并且还阻止我们使用标记（.NET相当于javadoc注释）来记录这些类。<summary>
从 XSD 开始的建议是一个很好的建议。这并不能保证每一端的兼容性，因为XML架构非常大，并且没有Web服务堆栈支持所有这些。（例如：列表）。
所以，从XSD开始，但把自己限制在主流类型。基元，由基元组成的复杂类型，相同的数组。您可以安全地嵌套复杂类型和数组。（复杂类型的数组，包含数组或复杂类型的复杂类型等）。
远离限制、替换组、列表、派生和任何其他 XSD 深奥。甚至应避免 XSD 枚举。
关于日期时间：仅使用可为空的日期时间是不够的。还有格式问题。.NET DateTime 是比 Java 日历分辨率更高的数量，因此，将 .NET 时间传送到 Java 可能会导致 Java 端出现反序列化异常。（编辑：在.NET端的XmlElement属性中使用DataType=“dateTime”装饰器可以确保您正确序列化）
关于这一点的一些旧建议。
最后，不能对生成的类使用代码内 XML 文档，这是不正确的。使用 C# 的分部类，可以使用所需的代码内文档编写与生成的类不同的代码。即使重新生成代码，分部类代码也将保持不变。编辑：编译时，文档将显示在类上。
编辑：有人问，如果使用 XSD-first 还不足以保证互操作，为什么要使用它呢？我的回答是：这不是一个保证，但这是一个好的步骤，它有帮助。它使您远离在代码（Java，C#或VB等）中设计接口，这些接口公开了特定于平台的东西，如.NET DataSets，通用字典，Java ResultSets等，所有这些都存在互操作问题。在 XSD 的更边缘的部分仍然存在陷阱，但您通常可以避免那些经过深思熟虑设计的陷阱。
我应该在我最初的答案中提到，您可以将迭代过程应用于界面的开发。在 XSD 中进行设计，然后从 XSD+WSDL 生成（客户端）存根和（服务器）框架代码，然后进行调整并再次执行。
