Question

Say I have a Person object that has a first name, a last name and an age. I want to send this person object to a web service that only knows and cares about a person object with a first and last name. But I want the xml that represents the full person object including the age to be sent back.

I already have a mechanism for storing the xml in the object behind the scenes and can simply serve that xml up to WCF, but I don’t want to use the normal XmlSerializer. I want to be able to say “here is the xml. wrap it in soap and send it”.

I plan on using WCF. Where would I hook into this process to control the serialization?

More Details

While the example in this question is contrived. It clearly illustrates my problem. Lets say I have an application with a class like so:

/* person A */
class Person {
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public int Age { get; set; }
}

I am passing this to a web service. The web service knows about a different Person class written as:

/* person B */
class Person {
  public string FirstName { get; set; }
  public string LastName { get; set; }
}

The service has a method with the following method signature:

Person SomeOperation(Person p);

When I call this web service from my application and pass it my person A version, the web service receives it just fine. It ignores the Age property. But when it recreates the response the Age property disappears.

I understand why this is happening. WCF is deserializing the response into an actual c# object so the extra XML that was sent with the request is discarded. Because of this, there is no Age property to send back.

I have a mechanism to actually use the XML as the backing store for my objects. If there is XML in the backing store that the object does not need, it just sits there and is not used. I want the full XML used as the backing store to be sent back in the response.

If this were a basic c# application I could simply create an IBasicPerson interface that contains the FirstName and LastName property and have a Person class implement the interface like the below code:

public interface IBasicPerson {
  string FirstName { get; set; }
  string LastName { get; set; }
}

public class Person : IBasicPerson {
  public string FirstName { get; set; }
  public string LastName { get; set; }
  public int Age { get; set; }
}

then I could create an operation in some other class that takes and returns the IBasicPerson interface:

public SomeClass {
  public IBasicPerson SomeOperation(IBasicPerson p) {
    /* do stuff */
    return p;
  }
}

When i call this, it doesn’t care about the Age property and the information does not get lost. This is because both the IBasicPerson in SomeOperation and the actual Person instance passed in refer to the exact same object. However, this is not the case when making WCF calls across the wire.

From the application calling the WCF services point of view the object in the return value of the method is not the same object that was passed in.

My XML backing store solves this problem, but only if I can figure out how to keep it from getting lost. This is why I’m trying to figure out where I should hook into the WCF serialization process.

Answer 1

Check out the IExtensibleDataObject interface – that might just be what you need!

It allows the WCF service to “stash away” any extra info that comes in, and pass it back to the caller when responding to the service call, without knowing what exactly it is that it’s storing. It is often used for versioning your services – so if a new version of the service requires additional parameters, those can be passed to the older service, too, and will be temporarily stored in the ExtensionDataObject of your service implementation.