WCF Key Points

#1. In WCF Protocol Choice, Message Format, Encoding Format, Hosting Environment, Process Allocation etc, almost everything is configurable and hence called as loosely coupled.

#2. A WSDL (Web Service Description Language) file will define the following details of a WCF service.
  • Provides the information about the service contract and operations available.
  • Provides the information about all the end points exposed by the WCF service.
  •  Provides the information about the messages and types that can be exchanged between the client and the WCF service.
  •  WSDL also provides any information about the policies used.
 #3. Below are the advantages of defining the service contract at Interface level:
  • Defining service contracts using interfaces, removes coupling to service implementation. Later the implementation can be changed at will without affecting the clients.
  • Defining service contracts using interfaces, also allows a service to implement more than 1 contract. 
#4. MessageParameter attribute used to define a custom name instead of actual parameter name and return types in WSDL.

#5. There are 4 different types of representing the Complex type in WCF.

  • Serializable types - Us the Serializable attribute on the type that you want to serialize
  • Data contracts - Use DataContract attribute on the type and DataMember attribute on every member of the type, that you want to serialize. You can apply DataMember attribute either on a filed or a property.
  • Known types - Use Known types to enable polymorphic behavior in service contracts.
  • IXmlSerializable - IXmlSerializable types provide XSD schema to Web Services Description Language (WSDL) and metadata exchange (MEX). 
Serializable is a bad option as it will serialize everything irrespective of accessibility. There will be no control on what to be serialized, Naming conventions and Data types.

IXMLSerializable is different from serializable. It sends the XSD schema of a complex type. But it considers only public members for serialization. It must require a public parameter-less constructor for a class to do this kind of serialization. In long run for a bigger scoped applications, how you can wrap every property of a variable as public. So, the preferred way is [Data Contract].

The preferred way for serializing complex types in WCF is to use data contracts. Using Data Contracts provides us with the following advantages.
  • Using DataMember attribute, you can control which members of the class to serialize.
  • You can also control the order in which members are serialized using Order parameter of the DataMember attribute..
  • You can also provide explicit Name to the serialized members using Name parameter of the DataMember attribute.
  • You can also specify if a member is required or optional using IsRequired parameter of the DataMember attribute.
A "Known Type" attribute is used in case of representing the inheritance in data contracts. This will help in avoiding the ambiguity at client side while deserialization. 
public class Shape { }

[DataContract(Name = "Circle")]
public class CircleType : Shape { }

[DataContract(Name = "Triangle")]
public class TriangleType : Shape { }

public class CompanyLogo
    private Shape ShapeOfLogo;
    private int ColorOfLogo;

Now on the client side, while deserialization engine knows about both the CirlceType and Traingletype, it will be easier to match it to the type name and deserialize the CompanyLogo object with out any ambiguity.

#6. WCF Services are version tolerant. The following table summarizes the changes to a service contract and impact on existing clients.

#7. IExtensibleDataObject is a interface which is recommended to be implemented for all data contracts to support Version tolerance. 

 Round-tripping occurs when data passes from a new ver­sion to an old ver­sion and back to the new ver­sion of a data con­tract. Round-tripping guar­an­tees that no data is lost. Enabling round-tripping makes the type forward-compatible with any future changes sup­ported by the data con­tract ver­sion­ing model.

The only disadvantage of IExtensibleDataObject is some times the contract will be rejected and unnecessary usage of server resources.

Below is the way to implement IExtensibleDataObject :

Data Contract:

public class Person : IExtensibleDataObject
    public string fullName;
    private ExtensionDataObject theData;

    public virtual ExtensionDataObject ExtensionData
        get { return theData; }
        set { theData = value; }


  class SampleService : ISampleService
  #region ISampleService Members
    public Person SampleMethod(Person msg)

      msg.lastName = "First Name";
      msg.firstName = "Last Name";
      msg.Message = "This is the Reply message.";
      return msg;

How to control the IExtensibleDataObject behavior:

#8. If there is an unhandled exception in WCF, the the service model returns a general SOAP fault, that does not include any exception specific details by default. However, you can include exception details in SOAP faults, using IncludeExceptionDetailsInFaults attribute. If IncludeExceptionDetailsInFaults is enabled, exception details including stack trace are included in the generated SOAP fault. IncludeExceptionDetailsInFaults should be enabled for debugging purposes only. Sending stack trace details is risky.

Is it helpful for you? Kindly let me know your comments / Questions.

No comments:

Post a Comment