I don't think there's a one-size-fits-all answer to this.
If orchestration is being done where most of the endpoints expect XML/SOAP, then perhaps the canonical domain object should be an XML string. However, in cases where most of the endpoints are bean services (or anything else expecting java objects, like perhaps JMS endpoints), then perhaps the canonical domain object should be a java object.
I guess the things to consider would be:
- of the canonical model itself
- with regard to adaptability/aligment with (most?) of the collaborating endpoint interfaces
- forwards/backwards compatibility, and versioning
- what is in-memory vs. what crosses process/network borders?
- expense of any possible serialization/deserialization points
- expense of querying/walking xml (xpath) graph vs. java object graph
- expense of any possible transformation points
These thoughts are just my gut-reaction to the question...