Java, WCF & Web Services Interoperability (part 1 of N): Be XML Schema Aware

@YaronNaveh

So, you want to write an Axis2 web service and have .Net WCF clients too? Or maybe you already have a .Net 2.0 endpoint and want it to be consumed by WSIT? Yes, that’s possible, but there is some important stuff you should know about. Whether you are a .Net WCF, AXIS2, Metro or any other framework developer/tester – you want to stay tuned for this series.

This first post deals with XML schema, what you can do with it and – more importantly – what you shouldn’t do with it. I’m not going to preach you on service-first vs. wsdl-first approaches –
others wrote some good posts on it. I am going to recommend you on some good habits no matter which approach you take.

DO be aware of your schema
If you are a wsdl-first type of developer then the schema is the first item you get to be aware of. But even if you prefer working with annotated classes: Be aware of how the different language types and annotations affect your wsdl – you don’t want to find yourself with a non-interoperable wsdl at a late stage.

DO be aware of schema subsets
This one is more for Java developers wanting to build service that interoperate with WCF. Microsoft has decided that WCF will support only a subset of the XML schema as a first class member. The main reason is probably to promote simplicity. This subset does NOT include xsd:choice, xsd:attribute and some other very common structures. This is the WCF supported subset – be aware of it!
One word of restriction is required: Even if you use unsupported schema constructs in your wsdl WCF proxies have a “backward compatible” mode and they “downgrade” themselves to the .Net 2.0 supported schema subset which is larger. So it’s not the end of the world. However for various reasons, including performance and programming model ease of use – try to stick to the WCF supported subset.

DO ensure schema completeness
If your schema uses some type – you have to define that type in the schema or reference another schema that defines it. In the past there were some issues with types that one framework could understand internally and that’s why it didn’t put them in the wsdl - causing other frameworks to fail. So whenever you use a system type which is not the simple integer/string/etc. you should ensure its definition appears in the wsdl. For example if you are writing a .Net 2.0 web service and one method looks like this:

[WebMethod]
public Guid GenerateId()

You can notice how the wsdl contains the Guid definition:

<s:simpleType name="guid">
<s:restriction base="s:string">
<s:pattern value="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}" />
</s:restriction>
</s:simpleType>

Of course the same goes for java types such as maps and vectors – make sure they appear in the wsdl.

DO NOT use schema types which are known to be problematic
One example here is xsd:date and xsd:time which are not directly supported by .Net. The .Net framework treats them both as xsd:dateTime so some semantics would get loss.


That’s it for today. Stay tuned for the following posts in this series. If you have any schema related tips feel free to drop a comment.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!