Tuesday, December 22, 2009

Introducing WCF 3.5

This post is dedicated to WCF and its basics. We will go through various conceptual points of WCF and learn step by step implementation of WCF.
This post will cover few fundamental topics like:
• What is Windows Communication Foundation?
• Advantage of WCF
• What is an endpoint?
• Structure of endpoint or ABC of an end point.
• Explaining Address
• Explaining Binding and type of binding
• How to select proper binding
• Contracts and type of contracts
• Discussing Service Contract in detail।

What is WCF?
WCF stands for Windows Communication Foundation and comes along with Dot net framework 3.0 onwards and as a part of operating system from Vista onwards.
Business process in today’s market depends on various systems based on systems that runs on different platform within or outside an organization. There must be a way , a solution to have a communication between these various systems.
Why to use WCF?
WCF basically is a Microsoft’s solution to develop communication between distributed application। One may think why to use WCF when we already have lot of options to develop distributed application in past. The one line answer is that WCF acts as an unified technology that encapsulates all existing technologies to develop distributed application such as .NET Remoting, ASMX, MSMQ etc.

Apart from that we get lot of option on how to host the WCF service like IIS, or Widows Activated Service (WAS) etc. That we will discuss in later post.
I am eliminating discussion on history of distributed application since distributed application development is such a huge topic that it will divert our objective to learn WCF basics , However, throughout the document, I will map the similarity between existing distributed application solution to WCF।

Endpoint is the part that a service exposes to the outer system. It defines various details of a service hosted. The consumer reads the endpoint to judge the nature, type of the hosted service.
The ABC of WCF Endpoint:

Three basic component of any WCF service is :
“A” is for Address: Where to find the service
“B” is for Binding: How to communicate with the service
“C” is for Contract: What to send to the service or what to expect from the service.

Address:

It defines where on the network messages should be sent so that the endpoint receives them. This is the location to which messages must be sent by the client.

The address for an endpoint is a unique Uniform Resource Locator (URL) that identifies the location of the service. The address should follow the Web Service Addressing (WS-Addressing) standard, which means it might contain the following four parts:

• Scheme: The top-level portion of the address, this is typically “http” followed by a colon.
This is not the same thing as a protocol, even though it commonly uses the same letters as the protocol.
• Machine: Identifies the machine name, which can be a public URL or a local identifier.
• Port: The optional port number, preceded by a colon.
• Path: The path used to locate the service files. Typically, this is just the service name, but the path

Syntax of an address will be: Scheme://Machine[:Port]/Path1/Path2

Examples:

http://localhost:8080/Service1
http://localhost/Service1/SubService
http://www.ServiceHost.com/Service1
net.tcp://localhost:1234/OrderService

WCF supports several protocols, and each has its own particular addressing format.
1. HTTP protocol:
HTTP services can be either self-hosted or hosted on Internet Information Services (IIS). When addressing an HTTP service in a self-hosted scenario, you use the following format:
http://localhost:8080/QuickReturns/Exchange
2. TCP Protocol:
The TCP transport uses the net.tcp: scheme but otherwise follows the same rules as described
for HTTP addresses. Here is an example:
net.tcp://localhost:8080/QuickReturns/Exchange
3. MSMQ:
You can use the Microsoft Message Queue (MSMQ) transport in an asynchronous one-way
(fire-and-forget) or duplex type of messaging pattern and use the MSMQ features of Windows. net.msmq://localhost/private$/QuickReturnSettleTrade
4. Named Pipes:
It is a common way to provide a means to implement inter- or in-process communication.
The Named Pipes transport in WCF supports only local communication and uses the
net.pipes scheme. Port numbers don’t have any meaning with the Named Pipes transport.
This results in the following address format:
net।pipe://localhost/QuickReturns/Exchange

Binding:

A binding defines how you can communicate with the service. It is the primary extension point of the ABCs of WCF. The binding controls the following:

• The transport (HTTP, MSMQ, Named Pipes, TCP)
• The channels (one-way, duplex, request-reply)
• The encoding (XML, binary, MTOM…)
• The supported WS-* protocols (WS-Security, WS-Federation, WS-Reliability, WS-Transactions)


WCF provides a default set of bindings that should cover most of your requirements. If the default bindings don’t cover your requirements, you can build your own binding by extending from CustomBinding.

There are nine preconfigured bindings in WCF. Each of these provides the means for a particular distributed computing need. There are several factors that determine which binding to choose for a specific application, including security, interoperability, reliability, performance, and transaction requirements.

Table below compares the nine preconfigured bindings by showing the common features they support. This table can be used to select a best binding for a particular need.















Below is the process that will help you to select the binding you required for your application:











Contract:

A contract is a description of the messages that are passed to and from service endpoints.

There are three types of contracts in WCF:

• Service contracts : Service contracts describe the functional operations implemented by the service. A service contract maps the class methods of a .NET type to WSDL services, port types, and operations. Operation contracts within service contracts describe the service operations, which are the methods that implement functions of the service.

• Data contracts: Data contracts describe data structures that are used by the service to communicate with clients. A data contract maps CLR types to XML Schema Definitions (XSD) and defines how they are serialized and deserialized. Data contracts describe all the data that is sent to or from service operations.

• Message contracts: Message contracts map CLR types to SOAP messages and describe the format of the SOAP messages and affect the WSDL and XSD definitions of those messages. Message contracts provide precise control over the SOAP headers and bodies.

We will cover each type of binding and contract as we moves ahead with the implantation of WCF service. All theory will really make all of confuse so we need a bit of coding also..

Explaining Service Contract:

NOTE: before going into code, I would like to mention that all class, attributes specified to WCF comes from System.ServiceModel namespace. So import this namespace before going for coding.
A service contract is a collective mechanism by which a service capabilities and requirements are specified for its consumers.
Few points regarding Service Contract:
• A service contract can be applied to a normal dot net class or an interface.
• Service contract attribute is not inherited. That means if you are inheriting a class that has service contract attribute to it, you need to define the attribute to the derived class also. It will not get inherited automatically.
• Best practice is to use service contract attribute to interface.
• Always use namespace and Name parameter when defining a service contract attribute.

Sample Code:

An interface defined as a service contract without any parameter.
[ServiceContract()]
public interface ITaskManagerService
{ …. }
An interface defined as a service contract without any parameter.
[ServiceContract(Name=”ServiceName”,Namespace=”http://schema.application.com/path1”)]
public interface ITaskManagerService
{ …। }

Explaining Operation Conntract:

The OperationContractAttribute, also defined in the System.ServiceModel namespace, can be applied only to methods. It is used to declare the method as belonging to a Service contract.


[ServiceContract(Name=”ServiceName”,Namespace=”http://schema.application.com/path1”)]
public interface ITaskManagerService
{
[OperationContract(IsOneWay = true,name=”Operation1”)]
void ProcessInsertMessage(Message message);
}
So the above piece of code displays a interface defined as a service contract and its method as an operation contract।

In next article, I will discuss Message Exchange Pattern and two other contracts that is Data Contract and Message Contract.

No comments: