我正在创建一个将由.NET和Java客户端应用程序使用的WCF服务.
我们在团队中没有任何Java经验,因此正在寻找遵循的准则或规则,以确保我们不会意外地在WCF服务接口中包含任何类型,或者做任何其他事情以防止它被Java客户端使用应用.
我们的担忧是否有充分根据？如果是这样,我们应该警惕什么？
关注的一个例子是.NET DateTime值是否以Java客户端可以正确理解的方式表示在服务接口中.
一个关注的第二个例子是使用任何空值类型(的bool?,int?等).
目前,我们的一些开发团队正在手写.xsd文件,以定义WCF接口方法将作为参数并返回为返回值的各种对象.然后他们使用xsd.exe从这些中自动生成C#类.
这背后的基本原理是它保证生成的类不包含任何特定于.NET的东西.
缺点是这增加了开发负担,也使我们无法使用
从XSD开始的建议是一个很好的建议.这并不能保证每一方的兼容性,因为XML Schema非常庞大,并且没有Web服务堆栈支持所有这些.(例如:列表).
所以,从XSD开始,但仅限于主流类型.基元,由基元组成的复杂类型,相同的数组.您可以安全地嵌套复杂类型和数组.(复杂类型的数组,包含数组或复杂类型的复杂类型等).
远离限制,替换组,列表,派生和任何其他XSD esoterica.甚至应该避免XSD枚举.
关于dateTime:使用可空的日期时间是不够的.还有格式问题..NET DateTime的分辨率高于Java Calendar,因此,将.NET时间传递给Java可能会导致Java端出现反序列化异常.(编辑:在.NET端的XmlElement属性中使用DataType ="dateTime"装饰器可以确保正确序列化)
对此有一些老建议.
最后,您不能在生成的类上使用代码内XML文档.使用C#的部分类,您可以使用所需的in-code doc从生成的类中编写单独的代码.即使您重新生成代码,您的部分类代码也将保持不变.编辑:编译时,文档将出现在类中.
编辑:有人问,如果使用XSD-first不足以保证互操作,为什么要使用它？我的回答:这不是保证,但这是一个很好的步骤,它有所帮助.它使您远离设计代码(Java或C#或VB等)的接口,这些接口暴露特定于.NET DataSet,泛型字典,Java ResultSets等特定于平台的东西,所有这些都会出现互操作问题.在XSD的边缘部分仍然存在缺陷,但通常可以避免那些设计周到的人.
我应该在原始答案中提到,您可以将迭代过程应用于接口的开发.在XSD中设计,然后从XSD + WSDL生成(客户端)存根和(服务器)框架代码,然后再调整并再次执行.
京公网安备 11010802040832号 | 京ICP备19059560号-6 