Thursday, November 20, 2008

Windows Communication Foundation Overview

I have been working with Windows Communication Foundation (WCF) for a while now, but I haven't published anything related to it on my blog recently. There are really cool and useful features in WCF 3.5 and I have been also researching about WCF duplex communication paradigm especially for Silverlight 2 applications. But before I get into advanced stuff, I think it would be good to write an overview of this Microsoft technology.

What is Windows Communication Foundation?
  • Windows Communication Foundation (WCF) is a secure, reliable, and scalable messaging platform for the .NET Framework 3.0.
  • WCF is an integrated Microsoft solution for the existing suite of .NET distributed technologies like .NET Remoting, ASP .NET Web Services, MSMQ, COM+ and WSE into a single programming model.
  • With WCF, SOAP messages can be transmitted over a variety of supported protocols including IPC (named pipes), TCP, HTTP and MSMQ.

What are the WCF Characteristics and Benefits?
  • Provides a single programming model (Service Model).
  • Provides a runtime for your services.
  • Service oriented solution for distributed systems.
  • Focused on interoperability.
  • Provides Isolation
  • Secure.
  • Reliable.
  • Simplified.
  • Flexible.
  • Extensible.

WCF requirements?
  • Requires .NET 2.0 Framework.
  • WCF is part of the .NET 3.0 Framework.
  • Visual Studio 2008
  • .NET Framework 3.5 for Silverlight and LINQ best support

WCF Main Components:
  1. Service Contract
  2. Data Contract
  3. Message Contract
  4. Endpoint

WCF Communication Workflow:

Services expose one or more endpoints where messages can be sent. Each endpoint consists of an address, a binding, and a contract. The address specifies where to send messages. The binding describes how to send messages. The contract describes what the messages contain.

Clients need to know this information before they can access a service. Services can package up endpoint descriptions to share with clients, typically by using Web Services Description Language (WSDL). Then clients can use the provided service description to generate code within their environment capable of sending and receiving the proper messages.

1. Service Contract: You model service contracts in .NET using traditional C# interface definitions. You can use any .NET interface as a starting point.To make this a WCF service contract, you must annotate the interface itself with [ServiceContract] and each operation you want to expose with [OperationContract]. These attributes influence the mapping between the worlds of .NET and SOAP. WCF uses the information found in the service contract to perform dispatching and serialization.

[ServiceContract]
public interface IUserManager
{
[OperationContract]
bool AddUser (User user);
}

Dispatching is the process of deciding which method to call for an incoming SOAP message.
Serialization is the process of mapping between the data found in a SOAP message and the corresponding .NET objects used in the method invocation. This mapping is controlled by an operation's data contract.

WCF dispatches based on the message action. Each method in a service contract is automatically assigned an action value based on the service namespace and method name. You can customize the action value for each method using [OperationContract]. A value of * can be used for any action when a specific match doesn't exist.

2. Data Contract: The data contract is defined by the types used in the method signature. The way WCF serializes .NET classes depends on the serialization engine in use. The default serialization engine is known as DataContract, a simplified version of XmlSerializer, the default serialization engine used in ASMX today. DataContract defines attributes for annotating class definitions to influence the serialization process. With DataContract, only fields marked with DataMember will be serialized. And you can serialize private fields.

[DataContract]
public class User
{
[DataMember]
string username;
[DataMember]
string password;
}

You can control the name of each element, the order, and whether a particular element is required, but that's about it. If you need to do anything more sophisticated, WCF lets you fall back to using XmlSerializer. You indicate your desire to use XmlSerializer by annotating the interface with [XmlSerializerFormat]

WCF also supports serializing types marked with [Serializable], which allows .NET remoting types to work with WCF without change. WCF provides an implicit mapping for [Serializable] types where all public/private fields are automatically serialized.

3. Message Contract:If you need to support headers, you can write another class that models the structure of the entire SOAP envelope for the particular operation, specifying which fields map to headers versus the body.You define this mapping with the [MessageContract] attributes [MessageHeader] and [MessageBody]

Using MessageContract is a more advanced technique that is only necessary when you need direct control over the SOAP contract. In normal cases you shouldn't have to touch the messages. But in some cases it becomes necessary. For example, assuming that your service will provide a File Upload operation. Unfortunetly, when using Streams, our operation can not take other parameters. So we cannot tell the fileName to our operation when uploading a file. You may always create two operations, one for setting the fileName, and the other one for uploading the file, but this is not a good solution. In order to solve this problem we will need to create a new message.

[MessageContract]
public class FileMessage
{
[MessageHeader]
public string fileName;

[MessageBody]
public Stream stream;
}

Our message class needs to have the MessageContract attribute. Since WCF only allows the Stream in message body, we are keeping the fileName in message headers. To keep a data in message header we are using the MessageHeader attribute, and to keep a data in message body we are using the MessageBody attribute.

4. Endpoint: The ServiceHost class gives you direct control over the WCF hosting infrastructure. You instantiate ServiceHost based on a particular service type. In addition to specifying the service type, you also specify the base addresses for the different transports you plan to use. This will be used as the base for any relative HTTP addresses I might specify when adding endpoints. The base HTTP address is also used as the default for retrieving the service description.

You then add the service endpoints. Again, a service may have one or more endpoints and each endpoint consists of an address, a binding, and a contract. You provide this information to your ServiceHost by calling AddServiceEndpoint. This is where you specify the service contract you defined.

For the binding, you typically choose from one of the many predefined bindings that ship with WCF and an appropriate address given the binding's transport.

<endpoint address = "xml"
behaviorConfiguration
= "xmlBehavior"
binding
= "webHttpBinding"
contract
= "WCFMSDemo.IPeopleManager" />

Hardcoding endpoint information into the host application is not ideal since endpoint details may change over time. WCF automatically provides this functionality through the predefined configuration section. This increases deployment flexibility since the communication details are completely factored out of the compiled code. You can also configure bindings within . You can even define new custom bindings from scratch using the element, which would be equivalent to deriving a new class from Binding. When it comes to configuring endpoints, bindings, and even behaviors, anything you can do in code, you can also do through configuration

Hardcoding endpoint information into client code is also less than ideal.
So WCF provides a similar configuration mechanism for specifying client endpoints within . The application configuration file specifies the same client endpoint details used in the code.

Now when you want to create a ChannelFactory for the TCP endpoint, you can simply change the configuration name to tcpEndpoint. You can also configure bindings in the client configuration file just like is done in the service configuration file.

If you add this configuration file to the client console application, comment out the code to create the ServiceEndpoint objects, and specify the endpoint names when constructing each ChannelFactory, the result will be the same.

Hope this gives you a nice overview about WCF, what it is, what are its characteristics and benefits and what are the main components and what are their purpose. I hope to be posting more advanced stuff about it soon. Let me know if you have any questions about this and I'll do my best to help you.

Happy WCF!
-arbbot

No comments:

Post a Comment