保证Java客户端可以使用.NET WCF服务 [英] Guaranteeing that a .NET WCF Service can be consumed by a Java client

问题描述

我正在创建一个将由.NET和Java客户端应用程序使用的WCF服务。

I am creating a WCF Service that will be consumed by both .NET and Java client applications.

我们团队中没有任何Java经验，所以寻找要遵循的准则或规则，以确保我们不会在WCF服务界面中意外包含任何类型，或者做任何其他事情以防止它被Java客户端应用程序使用。

We do not have any Java experience in the team, so are looking for guidelines or rules to follow to ensure that we do not accidentally include any types in our WCF Service interface or do anything else that would preclude it from being consumed by a Java client application.

我们的担忧是否有充分根据？如果是这样，我们应该警惕什么？

Are our worries well-founded? If so, what should we be wary of?

一个值得关注的例子是a。 NET DateTime 值在服务接口中以Java客户端可以正确理解的方式表示。

One example of a concern is whether a .NET DateTime value is represented in the service interface in a manner that can be correctly understood by a Java client.

关注的第二个例子是使用任何可以为null的值类型（ bool？， int？ etc）。

A second example of a concern is the use of any nullable value types (bool?, int? etc).

目前有些我们的开发团队是手写.xsd文件，用于定义WCF接口方法将作为参数的各种对象，并作为返回值返回。然后他们使用xsd.exe从这些中自动生成C＃类。

At present some of our development teams are hand-writing .xsd files to define the various objects that the WCF interface methods will take as arguments and return as return values. They are then using xsd.exe to auto-generate C# classes from these.

这背后的基本原理是它保证生成的类不包含任何东西。特定于.NET。

The rationale behind this is that it guarantees that the generated classes won't contain anything that is .NET-specific.

缺点是这增加了开发负担，也使我们无法使用< summary> 标签（相当于javadoc评论的.NET）。

The downside is that this adds a development burden and also precludes us from documenting these classes using <summary> tags (.NET equivalent of javadoc comments).

推荐答案

从XSD开始的建议是一个很好的建议。这并不能保证每一方的兼容性，因为XML Schema非常庞大，并且没有Web服务堆栈支持所有这些。 （例如：列表）。

The recommendation to start with XSD is a good one. That will not guarantee compatibility on each side, as XML Schema is really big and no web services stack supports all of it. (Example: lists).

所以，从XSD开始，但仅限于主流类型。基元，由基元组成的复杂类型，相同的数组。您可以安全地嵌套复杂类型和数组。 （复杂类型的数组，包含数组或复杂类型的复杂类型等）。

So, start with XSD, but confine yourself to mainstream types. Primitives, complextypes composed of primitives, arrays of same. You can safely nest complextypes and arrays. (arrays of complextypes, complextypes that contain arrays or complextypes, etc).

远离限制，替换组，列表，派生和任何其他XSD esoterica。应该避免使用XSD枚举。

Stay away from restrictions, substitution groups, lists, derivations, and any other XSD esoterica. Even XSD enumerations should be avoided.

关于dateTime：
使用可以为空的日期时间是不够的。还有格式问题。 .NET DateTime是一个比Java Calendar更高的分辨率数量，因此，将.NET时间传递给Java可能会导致Java端出现反序列化异常。 （编辑：在.NET端的XmlElement属性中使用DataType =dateTime装饰器可以确保正确序列化）

About dateTime: It's not enough to use a nullable datetime. There are formatting concerns as well. The .NET DateTime is a higher resolution quantity than a Java Calendar and as a result, shipping a .NET time to Java can result in de-serialization exceptions on the Java side. ( using the DataType="dateTime" decorator in the XmlElement attribute on the .NET side can make sure you serialize properly)

< a href =http://blogs.msdn.com/dotnetinterop/archive/2005/12/06/interop-and-datetime-formatting.aspx =noreferrer>关于此的一些旧建议。

最后，您不能在生成的类上使用代码内XML文档。使用C＃的部分类，您可以使用所需的in-code doc从生成的类中编写单独的代码。即使您重新生成代码，您的部分类代码也将保持不变。 编辑：编译时，文档会出现在课程中。

Finally, it is not true that you cannot use in-code XML doc on the classes that get generated. With C#'s partial classes, you can write separate code from the generated classes with the in-code doc you want. Even if you re-gen the code, your partial class code will remain unchanged. When you compile, the doc will appear on the classes.

编辑：有人问，如果使用XSD-first不足以保证互操作，为什么要使用它？我的回答：这不是保证，但这是一个很好的步骤，它有所帮助。它使您远离设计代码（Java或C＃或VB等）的接口，这些接口暴露特定于.NET DataSet，泛型字典，Java ResultSets等特定于平台的东西，所有这些都会出现互操作问题。在XSD的边缘部分仍然存在缺陷，但通常可以避免那些设计周到的人。

Someone asked, if using XSD-first is not enough to guarantee interop, why use it? My answer: it is not a guarantee but it is a good step, it helps. It keeps you away from designing interfaces in code (either Java or C# or VB, etc) that expose platform-specific things like .NET DataSets, generic Dictionaries, Java ResultSets, etc, all of which present interop problems. There are still pitfalls in the more marginal parts of XSD, but you can usually avoid those with thoughtful design.

我应该在原来的答案中提到过，你可以将迭代过程应用到界面的开发中。在XSD中设计，然后从XSD + WSDL生成（客户端）存根和（服务器）框架代码，然后再调整并再次执行。

I should have mentioned in my original answer that you can apply an iterative process to the development of the interface. Design in XSD, then generate (client) stub and (server) skeleton code from the XSD+WSDL, then adjust and do it again.

这篇关于保证Java客户端可以使用.NET WCF服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！