What is best-practice when designing SOA WCF web-services?

Question

Given an operation contract such as:

[OperationContract]
void Operation(string param1, string param2, int param3);

This could be redesigned to:

[MessageContract]
public class OperationRequest
{
    [MessageBodyMember]
    public string Param1 { get; set; }

    [MessageBodyMember]
    public string Param2 { get; set; }

    [MessageBodyMember]
    public int Param3 { get; set; }
}

[MessageContract]
public class OperationResponse
{
}

[OperationContract]
OperationResponse Operation(OperationRequest request);

One thing I like about the MessageContract is that I get a little more explicit control over the format of the SOAP message.

Similarly, I could write nearly the same code, but use a DataContract:

[DataContract]
public class OperationRequest
{
    [DataMember]
    public string Param1 { get; set; }

    [DataMember]
    public string Param2 { get; set; }

    [DataMember]
    public int Param3 { get; set; }
}

[DataContract]
public class OperationResponse
{
}

[OperationContract]
OperationResponse Operation(OperationRequest request);

One thing I like about the DataContract is that I can define IsRequired, Order, and Name.

Today I expect the only consumer will be a WCF client. However, I want to design contract first and adhere to SOA practices as much as possible. Rather than have WCF dictate my SOAP, WSDL, and XSD, I want the XML to define the WCF layer, but use WCF to generate this so as not to add any custom message processing to WCF. I want to follow the most common SOA XML conventions which I believe is probably all tags beginning in lowercase - am I right? And I want to be as version tolerant as possible.

Is it wise to always create Request and Response messages like this? Which of the three formats promotes the best SOA practices? Should I go one step further and define both a DataContract and a MessageContract whereby the MessageContract only contains the DataContract? Or should I only ever use DataContracts if I am truly exposing a new type (i.e. do not create message types as containers)?

A loaded set of questions I know, but I am trying to get to the heart of it, and I am not sure separating the questions provides sufficient context to get the answer I am looking for.

Answer 1

its always a best practice not to have multiple parameter in a operation contract, always have a type that wraps all the required parameters, this will help out in the long run. Your existing clients won't break when you add a new optional parameter.

I work in a business integration team where we integrate with other companies fairly regularly, (AT&T, Cox, Exxon ...) and have never seen a web service call that took more than a single parameter.