Introducing the

As we have seen in previous articles. Creating a Windows Communication Foundation (WCF) service begins with annotating the class with a <ServiceContract> attribute and an <OperationContract> for each exposed operation. The design of WCF uses these attributes to expose the service endpoints and to determine the mapping of incoming and outgoing data between the worlds of .NET and SOAP. For example if we look at a simple WCF service we can see how this is implemented.

At run time WCF uses the service contract to perform the dispatching and serialization of data.  The process of dispatching determines which methods are called for an incoming SOAP message. Serialization is the process of mapping between data found in the SOAP message and the corresponding .NET objects needed for the method call. By default WCF uses a simplified version of the XMLSerializer engine called the Data Contract. By definition the data contract is a formal agreement between a service and a client that abstractly describes the data to be exchanged. This means that in order to communicate the client and the service do not have to share the same data types, only the same data contracts. This contact defines for each parameter or return type what data is serialized or de-serialized for exchange. To keep the programming model simple WCF includes built in data contracts for the .NET Framework primitive types; like integers and strings. Also several other types like DateTime and XmlElement. The default data contract is defined by the types used in the method signature exposed by the <OperationContact>.

Of course most applications contain complex or custom types for data interchange. Beyond the normal .NET Framework primitives WCF requires a customized data contract to influence the serialization process. This is done by applying the <DataContract> attribute to classes, structures and enumerations. Once the target method has been determined, WCF relies on the method’s data contract to perform the serialization. The <DataMemberAttribute> is then applied to each member of the data contract to indicate it should be serialized.

For example if we wanted to build a WCF service that exposed and collects a set of name attributes we could do this using the following example.

Note: In this example we modify the basic WCF template that is available as part of the beta WCF designer here and use this to build a DataContract example.

The Service

1.       Create a new Website

2.       Modify the Web.Config file to include metadata by editing the existing entry and changing it to the following

<?xml version="1.0"?>

<configuration xmlns="https://schemas.microsoft.com/.NetConfiguration/v2.0">

      <system.serviceModel>

            <services>

                  <!-- Before deployment, you should remove the returnFaults behavior configuration to avoid disclosing information in exception messages -->

                  <service name="MyService" behaviorConfiguration="MyServiceTypeBehaviors">

                        <endpoint contract="IMyService" binding="mexHttpBinding" address="mex"/>

                  </service>

            </services>

            <behaviors>

                  <serviceBehaviors>

                        <behavior name="MyServiceTypeBehaviors" >

                              <serviceMetadata httpGetEnabled="true" />

                        </behavior>

                        <behavior name="returnFaults" >

                              <serviceDebug includeExceptionDetailInFaults="true" />

                        </behavior>

                  </serviceBehaviors>

            </behaviors>

      </system.serviceModel>

      <system.web>

            <compilation debug="true"/>

      </system.web>

</configuration>

3.       Test the basic service and you should see the following

4.       By default this service exposes a service contract with two <OperationContract> attributes.

The second operation contract is the one that we will use to implement a DataContract. The default code for this is shown below.

The DataContract1 class points to is where the DataContract attribute is implemented.

In order to properly implement the <DataContract> modify the code to include the <DataMember> attribute as shown below

The Client

For the client side example we will build a windows form client that implements the service. If you are unsure of how to build the basic application take a look at this previous article here. Once you have the client application connected and the service reference added. We can implement the data contract. One of the nice features of the data contract is that when it is exposed using the DataMemember attribute you get IntelliSense support within the client as shown below.

We can add the following code to the Windows form to return the data from the service.

Run the applications and you can see that the data is returned.