Brian Sherwin's Blog

After beating myself over the head a couple of times this week, I finally found a solution to doing what I wanted to in regards to Web Services and Inheritance/Interface serialization issues.

Basically what I wanted to do is to create something along the lines of:

public abstract class Response
{
}

public class ZipResponse : Response
{
}

public class StateResponse : Response
{
}

Ultimately what I wanted to do was get a single webservice definition that looked like this:

[WebMethod]
public Response GetResponse(string RequestType, string RequestValue)
{
}

Disregard for a moment that this violates the SRP (single responsibility principle) and go with me on this.  (Note: this is to simulate a WebSphere service I am attaching to, so I don't have control on what their service produces).

So anyway, I wanted to get a response that had similar elements from the perspective of XML, but they were completely different objects in my application once I serialized/deserialized them.

I tried interfaces--you can't serialize them.  I tried inheritance--can't have the same name objects (i.e. Response) that serialize differently in the same namespace (i.e. http://tempuri.org)  I tried one last ditch effort after reading you can serialize complex objects--including XmlNode.

Basically, I serialize my object, select the root node and return it--Presto! it does exactly what I need.

[WebMethod]
public XmlNode HelloWorld(string RequestType, string RequestValue)
{
    Response myResponse = new ResponseFactory(RequestType);
    //do business stuff on myResponse object 
    XmlDocument doc = new XmlDocument();
    //Serialize the object to an XmlDocument
    myResponse.Serialize(doc);
    XmlNode node = doc.SelectSingleNode(@".");
    return node;
 }

Now I can simulate creating multiple business objects and always return valid responses with a this single webservice method.