Why we use MessageContract when DataContract already is there?

1. What is Data Contract?

·         Data Contracts are used to describe the data types used by a service. Interoperability is possible through this since it uses metadata of the services in background. Data Contracts can be used to describe either parameters or return values.

·         Data contracts are used to define the data structure. Messages that are simply a .NET type, let’s say lain old CLR object, and generate the XML for the data you want to pass.

·         Data Contracts describes the data types used by a service.

·          Data Contracts can be used to describe either parameters or return values.

·         Data Contracts are unnecessary if the service only uses simple types

·         Data contracts enable interoperability through the XML Schema Definition (XSD) standard.

·         Example

        Basic DataContract is defined:

1.                  [DataContract] 

2.                  public class Shape { } 

3.                   

4.                  [DataContract(Name = "Circle")] 

5.                  public class CircleType : Shape { } 

6.                   

7.                  [DataContract(Name = "Triangle")] 

8.                  public class TriangleType : Shape { } 

2. What is message contract?

·         Message contracts are preferred only when there is a need to "control" the layout of your message (the SOAP message); for instance, adding specific headers/footer/etc to a message.

·         Message contracts describe the structure of SOAP messages sent to and from a service and enable you to inspect and control most of the details in the SOAP header and body.

·         Whereas data contracts enable interoperability through the XML Schema Definition (XSD) standard, message contracts enable you to interoperate with any system that communicates through SOAP.

·         While, MessageContract(s) describes the structure of SOAP messages(since SOAP is context oriented - passing-on complete information about object) sent to/from a service and enable you to inspect and control most of the details in the SOAP header and body.

·         1. Generic - MessageContract enables you to interoperate with any system that communicates through SOAP.

2. Control - Using message contracts, we get complete control over SOAP messages sent to/from a service by having access to the SOAP headers and bodies. 3. Object Context - This(SOAPing) allows use of simple or complex types to define the exact content of the SOAP.

·         Example

Following is a simplest message contract:

[MessageContract] 

public class BankingDepositLog 

{ 

  [MessageHeader] public int numRecords 

  [MessageHeader] public DepositRecord records[]; 

  [MessageHeader] public int branchID; 

} 

Why we use MessageContract when DataContract already is there?

A very simple answer to the question is, when you need a higher level of control over the message, such as sending custom SOAP header, you then use MessageContract instead of DataContract. But in my opinion, most of the messaging needs can be catered by DataContracts.

Sometimes complete control over the structure of a SOAP message is just as important as control over its contents. This is especially true when interoperability is important or to specifically control security issues at the level of the message or message part. In these cases, you can create a message contract that enables you to use a type for a parameter or return value that serializes directly into the precise SOAP message that you need.

why it is useful to use MessageContract(s), that is, to pass information in SOAP headers, you will have to dive into the SOAP advantages

We Can’t Mix Data and Message contract

Most important thing is we can’t mix Data and Message contract Because message-based programming and parameter-based programming cannot be mixed, so you cannot specify a DataContract as an input argument to an operation and have it return a MessageContract, or specify a MessageContract as the input argument to an operation and have it return a DataContract. You can mix typed and untyped messages, but not messageContracts and DataContracts. Mixing message and data contracts will cause a runtime error when you generate WSDL from the service.

Answer is

When we need a higher level of control over the message, such as sending custom SOAP header, then we can useMessageContract instead of DataContract . But in general cases, most of the messaging needs can be fulfilled by DataContracts.