Request and Response Paradigm in WCF

Question

Recently I read in an article that the Approach 1 following is more preferred/advantagious than Approach 2, while designing OperationContracts in WCF.

Approach 1

[OperationContract()]
ResponseMessageType SomeOperation1 (RequestMessageType reqMessage);

Approach 2

[OperationContract()]
string SomeOperation2 (string parm1, string parm2);

I can understand that any future change in the list of parameters/ type of any parameter, return type will be done just within the Message Contract (RequestMessageType and ResponseMessageType).

But I can't realize how does it become an advantage?

If there are any changes intended, somewhere it has to be done; what's going to be the difference if we do it in the Operation Contract or Message Contract.

I would like to understand and realize the advantages of the First approach.

Answer 1

I think the advantage of doing it in the data contract is that it's easier to modify an existing data contract without breaking compatibility with older clients.

Suppose you want to return additional information to the caller. Using a data contract that's easy, just add an additional field. Older clients will just ignore it. And if you want new clients to be able to talk to old servers, just make the field optional.

I wouldn't know how to do that in the service contract, without introducing a new service contract or at least a new operation contract. The implementation would not be much more difficult, but it would clutter the interface more.

So you have "flexible" data contracts (with maybe many optional fields) vs. service contracts that are cluttered with redundant operations.

It's a compromise, but I favor the "flexible" data contract for most situations.

The exception would be if you control both the client and the server, and can easily assure that every client will be up to date. In that case just modify (and ideally rename) whatever contract you like, and drop support for the old ones.

BTW: the other direction is pretty much similar. You can also include additional (optional) fields in a data contract that the client sends to the server. Maybe new clients want to add some hints that can speed up processing. Or add additional data that's not necessary to complete some operation, but which the server can store in a log to help troubleshooting or whatever.