Setting the Use and Style Properties

Download sample

This sample demonstrates how to use the Use and Style properties on the XmlSerializerFormatAttribute and the DataContractFormatAttribute. These properties affect how messages are formatted. By default, the message body is formatted with the style set to Document. These settings can be specified at either the service contract level or the operation contract level.

Note:
The setup procedure and build instructions for this sample are located at the end of this topic.

The Style style property determines how the WSDL metadata for the service is formatted. Possible values are Document, and Rpc. RPC means that the WSDL representation of messages exchanged for an operation contains parameters as if it were a remote procedure call. The following is an example.

<wsdl:message name="IUseAndStyleCalculator_Add_InputMessage">
    <wsdl:part name="n1" type="xsd:double"/>
    <wsdl:part name="n2" type="xsd:double"/>
</wsdl:message>

Setting the style to Document means that the WSDL representation contains a single element that represents the document that is exchanged for an operation as shown in the following example.

<wsdl:message name="IUseAndStyleCalculator_Add_InputMessage">
    <wsdl:part name="parameters" element="tns:Add"/>
</wsdl:message>

The Use property determines the format of the message. Possible values are Literal and Encoded; the default value is Literal. Literal means that the message is a literal instance of the schema in the WSDL as shown in the following Document/ Literal example.

<Add xmlns="http://Microsoft.ServiceModel.Samples">
    <n1>100</n1>
    <n2>15.99</n2>
</Add>

Encoded means that the schemas in the WSDL are abstract specifications that are encoded according to the rules found in SOAP 1.1 section 5. The following is an RPC/Encoded example.

<q1:Add xmlns:q1="http://Microsoft.ServiceModel.Samples">
    <n1 xsi:type="xsd:double" >100</n1>
    <n2 xsi:type="xsd:double" >15.99</n2>
</q1:Add>

The WS-I Basic Profile 1.0 prohibits the use of Encoded and you should only use it when required by legacy services. The Encoded message format is only available when using the XmlSerializer.

To allow you to see the messages being sent and received, this sample is based on the Tracing and Message Logging. The service configuration and source code have been modified to enable and utilize tracing and message logging. In addition, the WsHttpBinding has been configured without security, so the logged messages can be viewed in an unencrypted format. The resulting trace logs (System.ServiceModel.e2e and Message.log) should be viewed by using the Service Trace Viewer Tool. The traces are configured to be created in the C:\LOGS folder. Create the folder before running the sample. To view message contents in the Trace Viewer tool, select Messages in both the left and the right panes of the tool.

The following code shows the service contract with the Use property set to Encoded and the format of the message body changed from the default Document to Rpc.

[ServiceContract(Namespace="http://Microsoft.ServiceModel.Samples"),
XmlSerializerFormat(Style = OperationFormatStyle.Rpc, 
                                 Use = OperationFormatUse.Encoded)]
public interface IUseAndStyleCalculator
{
    [OperationContract]
    double Add(double n1, double n2);
    [OperationContract]
    double Subtract(double n1, double n2);
    [OperationContract]
    double Multiply(double n1, double n2);
    [OperationContract]
    double Divide(double n1, double n2);
}

To see the difference between the different Use and Style settings, modify them in the service, regenerate the client, run the sample, and examine the c:\logs\message.logs file with the Service Trace Viewer tool. Also observe the impact on the metadata by viewing https://localhost/ServiceModelSamples/service.svc?wsdl. The metadata for services is typically broken up into multiple pages. The main wsdl page contains the WSDL bindings, but view https://localhost/ServiceModelSamples/service.svc?wsdl=wsdl0 to observe the message definitions.

To set up, build, and run the sample

1. Ensure that you have performed the One-Time Setup Procedure for the Windows Communication Foundation Samples.

2. Create a C:\LOGS directory for logging messages. Give the user Network Service write permissions for this directory.

3. To build the C# or Visual Basic .NET edition of the solution, follow the instructions in Building the Windows Communication Foundation Samples.

4. To run the sample in a single- or cross-machine configuration, follow the instructions in Running the Windows Communication Foundation Samples.

Send comments about this topic to Microsoft.
© Microsoft Corporation. All rights reserved.