J2EE and .NET Interoperability

[MrManly]

I need to write a web service in J2EE that returns an XML document. My requirement is that the client will be C#/.NET based. I need to know the best way to do this.

I have the string "public String getFile(String name)" version working where I can receive the data on the .NET side. But I don't think this is the best approach.

I though about using SAAJ and sending the XML file as an attachment, but I'm not sure how the C# client could read it. Can .NET access SOAP attachments?

I also thought about using "public Document getFile(String name)" and returning an XML document. But all I saw on the .NET side was the class XmlDocument. Does anyone know if this approach would work?

Thanks,
-MrManly

 

[kamper]

I'm guessing that serializing an xml document to a full blown soap type isn't a good idea. DOM is the only real xml api standard and it doesn't specify the internals of how a parsed xml document is stored in memory so I doubt the .net version and the version of whatever java xml parser you're using would mesh very well.

I also don't see any advantage of using an attachment over just a simple string, although I haven't used attachments myself. Either way, though, you're still serializing the xml document out to a string and the attachments just add extra complexity. I've worked on a number of projects where xml documents were passed as strings across soap webservices and serialized/deserialized at the ends.

Another thing to consider is REST. It's not technically web services, but you pass parameters over http and get an xml document back with less framing overhead. That'd work if you only need to pass primitive arguments into the method and only need a single xml document back. Although, if you've already got the soap framework set up to your satisfaction then it would actually be more work to convert to REST.

 

[MrChad]

I agree with Kamper. I would build a webservice method that returns an XML String. You can easily load this into an XML parser on the client (.NET) side. Adding an attachment is an unnecessarily complex approach.

 

[UCJefe]

Agree w/ both of the above. String or byte-array is the way you want to go. The whole point is to language independent types. C# won't be able to deserialize a Java Document object. What don't you like about returning a string?

 

[kamper]

Originally posted by: UCJefe
Agree w/ both of the above. String or byte-array is the way you want to go. The whole point is to language independent types. C# won't be able to deserialize a Java Document object. What don't you like about returning a string?

Alright, I'm speaking from a lack of understanding here, but I'm leery of using a byte[], just because I'd rather let the two sides work their character encoding magic to make sure that everything gets moved across properly. If you decide when and how to change from String to byte[] and back then you might be throwing away encoding information that would otherwise have been handled automatically.

Why did you suggest byte[] in the first place? Is there some reason it'd be better?

 

[MrManly]

Originally posted by: UCJefe
Agree w/ both of the above. String or byte-array is the way you want to go. The whole point is to language independent types. C# won't be able to deserialize a Java Document object. What don't you like about returning a string?

This article rants about returning XML as string variables:
MSN Blog
He would rather have the function return a type of XMLDocument. If I used is approach, how what would the J2EE web service return? Document?

public Document getFile(String fileName) {}

-MrManly

 

[kamper]

Originally posted by: MrManly

Originally posted by: UCJefe
Agree w/ both of the above. String or byte-array is the way you want to go. The whole point is to language independent types. C# won't be able to deserialize a Java Document object. What don't you like about returning a string?

This article rants about returning XML as string variables:
MSN Blog
He would rather have the function return a type of XMLDocument. If I used is approach, how what would the J2EE web service return? Document?

public Document getFile(String fileName) {}

-MrManly

That guy's an idiot. He doesn't understand that the whole world doesn't run the exact same version of .net to use web services and he doesn't understand that serialization happens either way you do it. Serialization of a full out Document to real soap would be far, far more bloated than changing it back to the string representation.

I'm not going to translate directly to soap, but here's the basic idea of serializing a single xml element to a string and soap respectively:

Edit: stupid fusetalk developers are too lazy to properly implement escape characters, even in a code block :disgust:. Please visually remove the spaces in "& lt;" and "& gt;"

 

[MrManly]

Just an update to this thread.

I decided to pass the XML around as a string. Of course, it works fine.

-MrManly