Introduction to .NET Framework 3.0/Windows Communication Foundation

Windows Communication Foundation (codenamed: Indigo) is a new Windows Vista framework designed to make it easier for application in computer or across multiple computers in a network to communicate.

It is one of the four main application development interfaces brought with .NET Framework 3.0. It is compatible for usage with Microsoft Windows XP, Windows 2003, Windows Longhorn Server and Microsoft Windows Vista.

Windows Communication Framework (WCF) combines the features of .NET Remoting, Web services, Distributed Transactions and Message Queues.

WCF uses SOAP messages for communication. When a WCF process communicates with a non–WCF process, XML-based encoding is used for the SOAP messages but when it communicates with another WCF process, the SOAP messages are encoded in an optimized binary format.

WCF Service

A WCF service is made of three components: A service that implements the service to be provided, a host environment where the service runs and one or more endpoints or contracts

WCF provides unification, interoperability and service-oriented development.

Types of Contracts

There are three different types of contracts in use:

• Service Contracts
• Data contracts
• Operation Contracts

Service Contracts

The service contracts refer to the entire service.

A service contract is not different from a webservice but only a part of the service

.

Service Contracts are a group of classes designated as operations. A service contract has a 'service contract' tag as seen in the following example.

[ServiceContract]
interface IMa
{

It performs multiple operations through its different classes. Each of these classes is designated as an "operation".

Classes may be used as service contracts but it is generally recommended that interfaces be used. The advantage of using classes as "Service Contracts" involve speed and simplicity. However, manage classes do not support inheritance and it wouldnt be possible to run all the operations of a service contract at the same time.

It is beneficial to use parameters in service contracts as service contracts often pass on values than reference to values. The primitive data types that service contracts use are serializeable by default.

Data Contracts

Data contracts are generally used to specify the data members used in a contract. Data members are marked with a "Data Members" attribute. Members not specified as 'Data Members' are permitted but they shall not be a part of the contract and could not be implemented.

Syntax

The syntax for DataContracts attribute is

[AttributeUsageAttribute(AttributeTargets.Class|AttributeTargets.Struct|AttributeTargets.Enum, Inherited=false, AllowMultiple=false)] 
public sealed class DataContractAttribute : Attribute

Example:

[DataContract]
public class CustomerDetails
{
    //Serialized Member//
    [DataMember]
    public string CustomerName;

    //Serialized Member//
    [DataMember]
    private int Age;

    // This is not serialized because the DataMemberAttribute 
    // has not been applied.
    private string CustomerMailID;

}

Operation Contracts

Operation contracts are components of a service contract. Each and every method, a component of a service contract are tagged with the Operation contract attribute. Only methods designated as operations are considered as a part of the service.

Syntax

[AttributeUsageAttribute(AttributeTargets.Method)] 
public sealed class OperationContractAttribute : Attribute

Message Contracts

Apart from these three types of contracts, there are message contracts which enable us to enter a parameter or return value. Message Contracts make it easier to serialize data so that a detailed knowledge of SOAP need not be necessary.

The components to be displayed as SOAP headers will be specified using MessageHeader attribute while SOAP body members will be specified using MessageBodyMember attribute.

Syntax

[MessageContract]
public class ABC
{
  [MessageHeader] A;
  [MessageHeader] B;
  [MessageBodyMember] C;
  [MessageBodyMember] D;
  [MessageBodyMember] E;
}

Contract Patterns

There are three types of contracts specified in WCF Programming model:

• Request/Reply Message Pattern
• one-way message pattern
• duplex message pattern

Request/Reply Message Pattern

A Request/Reply Message Pattern is one in which a request by a client is followed by a reply from the server. Here, parameter values could be sent to the server by the client and at the same time return values could be passed by the server to the client.

However, there are major drawbacks in this pattern. If the functions are not in order, then each and every statement is regarded as a request or a reply. This shall include even statements which dont return values.

One-Way Message Pattern

Here, the client makes a request and the server responds and the client functions regardless of whether any message arrives from the server.

Here, the service need not bother about SOAP faults. Generally, the service does not wait for the application to process.

The one-way message pattern is the same as the request-reply pattern except that we set "IsOneWay" property to "true" in order to specify that the pattern is a one-way message pattern.

Duplex Message Pattern

The working behind the duplex message pattern is same as that of request/reply pattern except that the server and the client send messages independently of one another compared to request/reply pattern where both request and reply are parts of the same process.

A WCF Service Code Example

[ServiceContract]
class HelloService 
{ 
  [OperationContract]
  [PrincipalPermission(SecurityAction.Demand, 
    Role = “Adminstrators")]
  [TransactionFlow(TransactionFlowOption.Mandatory)]
  [OperationBehavior(TransactionScopeRequired = true,
    TransactionAutoComplete = true)]
  String Hello(String Greeting) {return Greeting;}
}

<bindings>
  <wsHttpBinding>
    <binding name="Binding1“  transactionFlow="true">
      <security mode="Message">
        <message clientCredentialType="Windows“/>
      </security>
      <reliableSession enabled="true" />
    </binding>
  </wsHttpBinding>
</bindings>

References

1. http://msdn2.microsoft.com/en-us/library/ms733127.aspx
2. http://msdn2.microsoft.com/en-us/library/ms733127.aspx