WCF DataContract/ServiceOperation involving .NET XmlDocument type

Question

hi all,

im just wondering about data contracts to be sent over the wire in WCF communication. i know for the sake of interoperability it is not advisable (maybe not even allowed?) to send native .NET types as part of a data contract.

I wish to have a service which accepts, as an input to a ServiceOperation, a .NET XmlDocument type. If i were to create a wrapper class (that would be marked with DataContract attribute) which holds an XmlDocument type (which would be marked with the DataMember attribute), and use this as the parameter for the ServiceOperation - would this be legal/possible?

How might i ensure interoperability, whilst still having the convenience of the XmlDocument type? Might it be a better design choice to accept a string as the parameter for the ServiceOperation and then instantiate an XmlDocument using the XmlDocument.LoadXml(string) method on the service side?

cheers for any help/views/comments, i'm just starting to get to grips with wcf so i just want to clear up any confusion in my head before i dive head first into creating a service.

THANKS!

Answer 1

Pass a string would be better for interop, but if you want to pass CLR data types you can look into marking up your classes with the KnownType attribute.

Answer 2

More often than not, developers code things for the sake of "interopability", when they really have no reason/need at all to do this.

It's perfectly ok to use native .NET types. Example: Would you break down "Point" to be two integers for the sake of serializing?

Sadly, however, the System.Xml.XmlDocument ... is not serializable :)

You can use "XElement" though... that works perfectly (in the System.Xml.Linq namespace).

Answer 3

What I would do in your second case, is create a data contract in a separate dll, and reference it on both applications (I'm guessing that you have control on both Services). So when you create your proxy class for Service A within Service B, you can say that your data contracts are from a Known Type and point for the data contracts dll. BTW VS 2008 does that by default. If you're using .NET 3.0, you might need to create the classes manually using svcutil.

I hope this helps.

Cheers, Wagner.

Answer 4

Do you have an XSD for your XML document? If so it's pretty easy to generate a DataContract composite structure using svcutil.exe (svcutil.exe /dconly schemaName.xsd). At that point you have a choice of using the DataContractSerializer to move between your XML doc and a Composite of DataContracts that can be used in your service interface and your implementation(s) if you chose to do so.

Also, I agree with the previous poster(s) with the YAGNI comment about compatibility.

JB http://jb-brown.blogspot.com

Answer 5

thanks for the help guys, much appreciated. I do have (or rather i can acquire) a schema for the XML represented by the Xmldocument, so I will look into the DataContractSerializer and see what fruits it will yield! JB Brown, what did you mean by "YAGNI"?

to be honest i was starting to go down the path of scrapping interoperability/compatibility because it's practically guaranteed that in the near future, only .NET applications will be making requests to my service - especially as it's only end point currently, will be a named pipe. If the requirements change in future only then i will factor in interoperability, but for now, the current deadlines demand that i finish up quickly!

Answer 6

You will need to add the [XmlSerializerFormat] attribute.

So (without using Datacontract although you can use that too):

[ServiceContract(Namespace = "urn:SerializationTest")]

[XmlSerializerFormat]

public interface IBlah

{

[OperationContract]

XmlDocument Returnxmldoc();

}