Message Contracts in WCF and the Smart Client Software Factory

We’re developing a new product and we took the chance to change from ASMX web services to WCF. We’re using the Service Software Factory and the Smart Client Software Factory from patterns & practices. I have to admit we’re not experts in WCF yet, but the best way to learn is to practice.

The Service Factory makes it easy to declare Data Contracts (there is even an option to decorate an existing class), Message Contracts and Service Contracts. Basically, a Service Contract defines one or more Operation Contracts that use the Data Contracts as parameters.

So where do the Message Contracts come into play? The Service Software Factory Help says:

“A message contract is a class that represents a request or response message. While data contracts represent types that are reused across services and operations within a service, message contracts are defined for a specific operation on a service and are not reused.”

This and the example that follows on how to define the Message Contracts led us to think about the Message Contracts more as wrappers for the request and response for an operation.

A cool bonus is that on the client side, when you add the service reference, you get the operation signature without the message contract part – instead of

void MyOp (MyOpRequest request);

you get

void MyOP(SomeClass obj, int intParam);

where obj and intParam are the members you declared for MyOpRequest.

What happens if you have more than one member in MyOpResponse?

The first member is treated as return value, but the others are added to the parameter list as out params, for example:

Guid MyOP(SomeClass obj, int intParam, out SomeReturnClass objReturn);

This is not a problem if you use the service reference directly and don’t mind getting the results from both the return value and the out parameters (I personally prefer not).

But if you also use the Smart Client Software Factory and the Disconnected Service Agent like we do, you’ll get into more trouble.

First of all, the generated code does not compile in this case. The parameter list for the agent’s proxy methods are generated using the Type.Name property, which for the out parameters is something like “SomeReturnClass&”. You can modify the t4 file to deal the out parameters for this method, but then you also have to take them into account for the call forwarding and for the callback.

Although it’s doable, it seems to me like it’s no worth it – I prefer to declare a data contract instead of a message contract, have the return values packed in a single object and save myself the time needed to change the SCSF for this case.

I think the second part of the Service Software Factory Help definition for Message Contracts is more appropriate:

“Message contracts can also be used to control the naming of custom message headers, and the way a message body is formatted, wrapped, and encoded.”

I also went back to my guide for WCF, Juval Lowy’s Programming WCF Services, and this is what I found:

“Message contracts:

Allow the service to interact directly with messages. Message contracts can be typed or untyped, and are useful in interoperability cases and when there is an existing message format you have to comply with. As a WCF developer, you should use message contracts only rarely, so this book makes no use of message contracts.”

No wonder I didn’t remember reading anything about them.