WCF (Windows Communication Founation) - ABC in Detail

Thank you everyone for liking and sharing my last post on WCF. We are now aware of assemblies and namespace required to create the service. In this post, we will explore ABC of WCF.

Introduction

WCF offers much more functionality than Web services, few features are Security, Multiple Transport and Encoding and Transaction, etc. There are multiple bindings option available, which support different features. Let’s explore them in more details. Before creating our WCF service, we will see ABC of WCF.

ABC (Address, Binding and Contract)

The most important thing to remember in WCF is that the client and service communicate with each other by agreeing on these three things.

1. Address: This lets you know the location on server. Different bindings support different address types.
2. Binding: Defines which protocol is being used.
3. Contract: This defines each method exposed from service.

Let’s see each one in more detail.

Contract

As described above, contracts are nothing but what service is going to share with outside world. There are multiple types of attributes, which complete the service.

1. ServiceContract
2. OperationContract
3. DataContract
4. MessageContract

1. [ServiceContract] Attribute

An interface is decorated with ServiceContract attribute to participate in WCF service. It defines the below things:

1. Name and namespace for the service
2. Signature of the service
3. Location of service
4. Data Type of the message

It offers the below properties which can be used:

1. CallbackContract: It is used in case of duplex binding, to setup the callback functionality.
2. ConfigurationName: Default name is name of service implementation call. It is optional.
3. ProtectionLevel: Allows us to specify the degree to which we need the encryption, default is none, we can provide digital signatures as well.
4. SessionMode: Used to specify if the service supports session are allowed, not allowed or required.

2. [OperationContract] Attribute

Methods are decorated with OperationContract attribute, so they can participate in service.

Below are the properties which it provides:

1. AsyncPattern: Indicates whether the operation is implemented asynchronously
2. IsInitiating: Specifies whether the operation can be initial operation in session
3. IsOneWay: Specifies if operation is single input message with no output
4. IsTerminating: Specifies whether the runtime should attempt to terminate the current session after the operation completes

3. [DataContract] Attribute

Data Contract is nothing but the entities/ classes with properties, we need to decorate them with DataContract attribute so they can be serialized and deserialized.

The properties within classes are decorated with [DataMember] attribute, so they can take part in service data exchange. Your return type can be any of the variable types like string, int and Boolean, etc., but if we are using the complex data type in this case our own class, it should be marked with [DataContract] attribute.

Below are the properties which it supports:

1. IsReference: Value that indicates whether to preserve object reference data.

4. [MessageContract] Attribute

In most of the cases, a Data Contract is sufficient to control the service, but in case we need better control over our SOAP message being created, we can use Message Contract. Using this, we can define header and body, which can be another data contract.

Bindings

Once we are done with the defining contracts, the next step is to choose a hosting agent. There are several options to choose from, which depends on our need. Each binding is for specific needs. Below are some of the characteristics:

1. The transport layer used
2. The channel used
3. Encoding mechanism
4. Web service protocol support

We can divide the bindings in 3 types - HTTP based, TCP based and MSMQ based. Let’s see each one.

1. HTTP-based: If we want our service to be accessed across multiple OS or multiple programming architectures, HTTP based bindings are our obvious choice. Let’s see the bindings supported.
   1. BasicHttpBinding: It is used in case of web service, offers backward compatibility, the message encoding used is Text/XML, supports WS-basic profile.
   2. WsHttpBinding: It gives all functionality which BasicHttpBinding offers, apart from that it offers transaction support, reliable message and WS-Addressing.
   3. WSDualHttpBinding: Offers all functionality offered by WsHttpBinding, but the main purpose is to be used with duplex communication.
   4. WsFederationHttpBinding: This is used when security within the organization is the most important aspect.
2. TCP-based: If we want to share the data in compact binary format, these bindings are of best use.
   1. NetNamedPipeBinding: This is best binding to be used if our service and client both are hosted on the same machine, use TCP protocol to exchange data. It supports transaction, reliable session and secure communication.
   2. NetPeerTcpBinding: This binding provided secure binding for P2P network, offers all functionality fro NetNamedPipeBinding.
   3. NetTcpBinding: Used for secure and optimized binding for cross-machine communication between .NET application.
3. MSMQ-based: If we want to use MSMQ server to exchange data, we can use these bindings:
   1. MsmqIntegrationBinding: We can use this binding to send and receive data from existing MSMQ applications that use COM, C++.
   2. NetMsmqBinding: This is used to communicate between cross-machine using queue. This is preferred binding when using MSMQ.

Address

Once we are done with defining contracts and finalizing the binding, the final information left is the address. This is most important aspect as client will not be able to access our service without a proper address. The format of the service address depends upon the type on binding we are using.

If we see from a high level, below are the things which our address represents:

1. Scheme: The transport protocol (HTTP, TCP, etc.)
2. MachineName: Fully qualified domain name of the machine
3. Port: This is optional if we are using default 80 port
4. Path: The path of WCF service

The information above can be used to define a common template for address.

scheme://<MachineName>[:Port]/Path

In case of HTTP-based binding, this can be represented as:

http://localhost/MyService

In case of TCP-based binding apart from name pipes, this can be represented as:

net.tcp://localhost/MyService

MSMQ bindings are bit different as we can choose from public or private queue:

net.msmq://localhost/private$/MyPrivateQueue

In case of name pipes, it goes like:

net.pipe://localhost/MyService

Conclusion

Now, we are aware of ABC of WCF service as well as the namespace and core assemblies used to create the WCF service. While creating any WCF service, we need to choose the type of binding carefully, as the list of features we can use depends upon them.

TCP bindings are most secure and reliable of them, but we need to expose the service to multiple clients - HTTP would be the obvious choice.

In our next post, we will create our first WCF service.

You can follow my official Facebook page. You can also subscribe my blog for more information.

You can mail me at santosh.yadav19613@gmail.com in case you have any questions.