mattberther.com » Web service and custom serialization

Web service and custom serialization

Posted May 17th, 2006 by Matt Berther

Why is it that it seems to be so difficult (if not impossible) to utilize the ISerializable interface when using web services?

I have a number of objects that I do not wish to provide default constructors on that I need to pass back and forth across the web service. I could implement ISerializable on them, but I cant figure out a way to set the serialization mechanism to use SOAPFormatter instead of IXmlSerializable.

I could do something like:

[WebMethod]
public void SaveUser(string userXml)
{
    // create soap formatter and deserialize userXml
}

but it seems hackish to do that… What Id like to do is have a hook into the framework that allows me to specify the serialization type, and then I could have

[WebMethod]
public void SaveUser(User user)
{
}

The other workaround would be to have two copies of the objects… One that is used only for serialization, but that stinks even more, I think… If I make a change to one, I have to remember to change it in the other. This will end up leading to a maintenance nightmare.

Any suggestions?

This entry was posted on Wednesday, May 17th, 2006 at 11:55 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Havagan

May 17th, 2006

I rarely use XML so this is a shot in the dark… how about using the XMLTypeMapping to specificy the XML output should conform to SOAP format?

http://www.topxml.com/xmlserializer/customizing_xml_serialization.asp
http://msdn2.microsoft.com/en-us/library/system.xml.serialization.xmltypemapping.aspx

Don Demsak

May 17th, 2006

I’d suggest that you have 2 copies of the “objects”, even though you think it stinks. You have to remember that even though the “objects” have the same name, they are actually built to accomplish 2 different goals. The class that you have now, it is a business object, and thus has to conform to your business rules (which is part of the reason why you don’t have a default constructor). Business classes contain the business data and the business behaviors. On the other hand, you have this representation of your business object that you wish to pass along the wire. The representation is a message, and not a business object. This class will contain a representation of the data contained within the business object, but as it is a message, it contains no business rules.

Once you decouple the message from the business object, you will have an easier time distinguishing between your core business rules, and your message rehydration rules. In do so, you are also better able to handle versioning of your public facing contracts (in web services this is done via WSDL and XML Schema). You can now update and change your business objects as needed, and only add any new data to your message when that new functionality is required. By going down this path you will also be able to utilize the more enterprise friendly Web Services Contract First approach to building web services.

I know that there are a lot of people that will disagree with me, and feel as you do, that by splitting things into messages and business objects, you are just adding to the bloat of a system, but I’ve learned that as long as you don’t hit the architectural issues that you discuss here, that yes, the message based methodology is overkill for your particular project. But once you start to see that there is differences between the way you want to implement the business object, and the way you want to represent it on the wire, then you need to start to think about going down the message path.

A comprising between these 2 designs is to implement the IXmlSerializable interface, on your business classes, but eventually this will also become too cumbersome and you will have to go the route of the message methodology, especially when you have to handle multiple minor versions of your message coming thru the same web service.

Matt Berther

May 17th, 2006

Havagan: It wasnt necessarily that I was married to the idea of this coming back using the SOAP formatter. I just wanted to avoid having a default public constructor on my business classes.

Don: As always, you make a perfectly valid argument. I think this is probably what we’ll end up doing.

Steve Maine

May 20th, 2006

For the record, this story gets a lot better in Indigo. The DataContractSerializer supports [Serializable], ISerializable, [DataContract] and IXmlSerializable, and you can mix and match the various serialization models within the same object graph.