This documentation is archived and is not being maintained.

Wide Support for Protocols

Visual Studio 2010

Applies to: Windows Communication Foundation

Published: June 2011

Author: Robert Dizon

This topic contains the following sections.

The WCF programming model provides various capabilities, such as SOAP services, web HTTP services, data services, rich internet application (RIA) services, and workflow services. SOAP services support interoperability between systems that are built with Java, other platforms, and those that use messaging standards that are supported by Microsoft®. SOAP services also support transports such as HTTP, TCP, named pipes, and MSMQ. Web HTTP services and data services both support REST. Web HTTP services enable you to control the service location, request and response, formats, and protocols. Data services enable you to expose data models, and data-driven logic as services. WCF also includes two programming models: The service model and the channel model. The service model provides a framework for defining data contracts, service contracts and service behaviors. The channel model supports specifying formats, transports, and protocols.

Both SOAP and REST services can provide functionality to web applications, and both can be used to exchange information in the web's distributed environment. Each one has its own advantages, and limitations.

SOAP is used in client-server scenarios to exchange information. The SOAP client invokes a web service that is on the server. The SOAP web service returns data to the client. This section explains the structure of SOAP requests and responses. It uses the sample application, which you can download, as an example. To duplicate the steps shown in this article, use the WCF Test Client tool by typing wcftestclient.exe at the Microsoft® Visual Studio® 2010 development system command prompt.

Referenced Image

Add a new service reference at My Service Projects for the WCF service located at http://win-5uv7qm0esb:7070/Service1.svc. Double-click GetData as shown below. In the test form, enter an input parameter (either 1 or 2). Click Invoke. The response is the string "WS #1: 1". The following figure illustrates the request parameter and the response.

Referenced Image

The following XML code is the actual SOAP request and response. SOAP messages have a header and a body section. SOAP headers provide information about the message itself. For example, the header can specify how the body is authenticated and what encryption is used.

For the SOAP specifications on World Wide Web Consortium (W3C) at

SOAP Request

<s:Envelope xmlns:a="" xmlns:s="">
    <a:Action s:mustUnderstand="1"></a:Action>
  <s:Body>    <GetData xmlns="">      <value>1</value>   </GetData>  </s:Body>

SOAP Response

<s:Envelope xmlns:s="" xmlns:a="" xmlns:u="">
    <a:Action s:mustUnderstand="1" u:Id="_2"></a:Action>
    <ActivityId CorrelationId="69bc2846-37df-4a3c-9071-46236cb8d89c" xmlns="">2a8bcb4b-4cc0-40ae-bd2b-59eeb431fbce</ActivityId>
    <a:RelatesTo u:Id="_3">urn:uuid:c1864eb8-58a9-4d30-9e7e-cbfb0a481653</a:RelatesTo>
    <o:Security s:mustUnderstand="1" xmlns:o="">
      <u:Timestamp u:Id="uuid-9213e222-e5aa-49d0-aa37-86021fa1108d-22">
      <c:DerivedKeyToken u:Id="uuid-9213e222-e5aa-49d0-aa37-86021fa1108d-18" xmlns:c="">
          <o:Reference URI="urn:uuid:a698f587-0fcf-4871-a865-d4da0273403c" ValueType="" />
      <c:DerivedKeyToken u:Id="uuid-9213e222-e5aa-49d0-aa37-86021fa1108d-19" xmlns:c="">
          <o:Reference URI="urn:uuid:a698f587-0fcf-4871-a865-d4da0273403c" ValueType="" />
      <e:ReferenceList xmlns:e="">
        <e:DataReference URI="#_1" />
        <e:DataReference URI="#_4" />
      <e:EncryptedData Id="_4" Type="" xmlns:e="">
        <e:EncryptionMethod Algorithm="" />
        <KeyInfo xmlns="">
            <o:Reference ValueType="" URI="#uuid-9213e222-e5aa-49d0-aa37-86021fa1108d-19" />
        <e:CipherData>        <e:CipherValue>jUNsHysH1ZG/XyyLiGOTojfpaqrY+qKMBE5Bk7BtL4mefU1ljzbL+EgVum/ACt/SIP+Xwe9jKFWMAmQwb9ShAsPWo6oLF/egwlf2Cpllt1LtSi3360FD4kv3odB6SoQe/vHawk/16U2PS90fzLU5Y1JI+u7M3Wp630kcqI4EiWKI34yV5y6xCk0pUNRA0geN5TOjAxfPkYCjNii9Xda7Gu6cX6ivIDQd5QYQufww0l4vCBlOLZTqZoDS+ 
  <s:Body u:Id="_0">
    <GetDataResponse xmlns="">
      <GetDataResult>WS #1: 1</GetDataResult>

All the data that is related to the client's request and to the web service's response is located in the body of the message. One point to remember is that XML messages do add overhead, in order to support interoperability. On the other hand, interoperability is one of the biggest advantages to adopting SOAP services. With SOAP, two incompatible systems can invoke each other's services to accomplish business objectives. These messages either can travel internally, between departments, or remotely, to business partners.

The following example demonstrates the flexibility that the SOAP service offers in terms of its ability to use different transports. It shows how to change the transport protocol from wsHttpBinding to the netTcpBinding. From the command line, run the service configuration editor (svcconfigeditor.exe). Click File, click Open, and select the Config File option. Go to the web service that is hosted in IIS, and open the Web.config file. Expand the Endpoints folder, and click Endpoint1. In the right pane, under Endpoint Properties, click Binding.

Referenced Image

A drop-down menu appears. The following figure illustrates the menu.

Referenced Image

Click mexHttpBinding, which stands for Metadata Exchange HTTP.

Open the WCF Test Client tool. Add or refresh the web service. The left pane should show that the service uses the Metadata Exchange HTTP binding. The following figure illustrates this.

Referenced Image

For more information on SOAP Protocol Standard visit this link:

Previous article: Actions to Take

Continue on to the next article: Operation-based SOAP vs. Resource-based REST