XSD Validation – Validating Objects with XSDs: Is Re-Serializing Redundant?

I think versioning is probably the best argument. When you have an existing operation contract like

int GetPersons(int countryId);

that you want to enhance, e.g. by another filter later on

int GetPersons(int countryId, int age);

You would have to write a new operation contract and with a new name since it has to be unique. Or you would keep the name and publish a new v2 of your service with the old v1 still being around for backwards compatibility.

If you wrap the parameter into an object you can always extend it with default/optional parameters and all your existing clients will be unaffected when you reuse the same operation contract.

However I would also urge to name your objects appropriately. Even if it just wraps an int, if you start with IntMessage or something similar you're not doing yourself a favor extending it. You'd have to name it e.g. PersonFilter right from the start which means you have to think a little about what this service call should expect as parameter semantically and therefore what it's supposed to do. Maybe (and that's a very vague maybe) that's going to help in developing the right services and maintain a decent sized API.

It allows common data and behavior to be isolated to a base class

That's something to be cautious with. Inheritance and data contracts don't go that well together. It does work, but you'll have to specify all known subtypes of the contract that could go over the wire, otherwise the data contract serializer fails complaining about unknown types.

But what you could do (but still probably shouldn't, I'm still undecided on this) is reuse the same messages among different services. If you put the data contracts in a separate dll you can share that between client and service and you don't need to convert between types when you call different services that expect basically the same message. E.g. you create a PersonFilter and submit that to one service to get a filter list of persons and then to another service and have the same objects on the client. I can't find a good real-world example for that though and the danger is always that an extension to the data-contracts is not general enough for all services that use this contract.

Overall, apart from versioning, I can't really find the killer reason for doing it that way either.

using XSLT to transform messages is a very common technique that you'll find supported in most ESB frameworks such as Apache Camel, Mule, Spring Integration, Ikasan etc.

The trade off is that XSLT can be difficult to maintain and there can be a lack of flexibility in the programming model that it offers. I've found that I'd often have to call out to a datasource to do a lookup or a POJO to perform some other complex transform. In the end up we only used XSLT for fairly simple transforms and had other components in the ESB flow do the rest.

There is also a performance cost in terms of performing the transform and the validation afterwards. There's a large array of libraries to choose from which perform the transform and validation with varying performance characteristics (think memory and CPU impacts).

There's another serialisation cost when you eventually transform back to a Java object.