WCF primer - Messages III

This is post 5 in this series, you can find the landing page here.

Changing requirements may be the only constant in software development.  As a direct consequence, there is a need for versioning.

Versioning scenario's

A few scenario's can exist:

Data contract change	Connecting client consequence
New non required field added	None. fields are initialized to default values.
New required fields added.	Exception is thrown because of the error in deserialization.
Remove non required fields	No exception, the extra data is sent to service, where it is subsequently lost in deserialization.
Remove required fields	Exception is thrown when deserializing a message fromt he service (required fields are missing)
Modify existing member data types	as long as the data types can be cast to each other, there's no problem, otherwise an exception occurs.

 

IExtensibleDataObject

As per the point above, when sending extra members, the data is lost at the service boundary (upon deserialization of the message).  As this behaviour may not be exactly what you want, WCF exposes the IExtensibleDataObject interface, which allows you to preserve unknown serialization members.

The premise for using this interface is version tolerance, but personally I think this is a load of cr*p. 
The IExtensibleDataContract not only opens you up to get DDOS'd (by sending huge amounts of extra data), it also violates  a principle which is (imho) basic in SOA: once a contract has been published, there's NO way to change the contract.  Versioning should be done explicitly, deploying the new version on a different url is necessary.