I’m setting up a new .NET 4.0 WCF service with a method (operation) that takes strongly typed XSD generated data types as parameters. This makes things clean and tidy for the client – the client can work with strong types and not have to think about XML.
However, in the implementation of the WCF service, I would prefer to deal with the parameter data as XML documents (LINQ XDocument) instead of the deserialized object types. It’s nice that WCF will deserialize to explicit types, but for my generic algorithm it’s more convenient and more flexible to deal with the xml documents instead, primarily because the incoming data is polymorphic.
I know I can just take the parameter objects and serialize them back down to XML, but this seems wasteful.
I understand that I could probably replace the strongly typed params with XElement to get what I want for implementation convenience, but this will lose the benefits of strong typing (compiler checks, intellisense, self documentation) for the client.
Is there any way to tell WCF that in my service implementation I don’t need the parameter objects deserialized, that I want them as XML instead?
Or, is there a way to access the raw XML of the params as they were prior to WCF deserializing them into objects? If I can’t prevent WCF from spending time deserializing the objects at least this would avoid the cost of reserializing them back to XML.
One way to do this would be to create a message inspector that would inspect the incoming message on the server, and acting on it (e.g. storing it away or something).
Pablo Pialorsi has a great blog post on how to write a message inspector, step-by-step
Inspecting the message would give you access to the parameters in the raw SOAP message format.
I thought maybe a parameter inspector might be the better choice, but it would appear as though these inspectors only get their go at the parameters for any service call once those parameters have been deserialized into objects already, so that doesn’t sound like a viable approach….