WCF vs ASP.NET Web services

Introduction

In this post I will explain the Difference between ASP.NET web service and programming WCF services like ASP.NET web services. It also discusses how we use the both technologies for developing the web services.

The development of web service with ASP.NET relies on defining data and relies on the XmlSerializer to transform data to or from a service.

Key issues with XmlSerializer to serialize .NET types to XML

■Only Public fields or Properties of .NET types can be translated into XML.
■Only the classes which implement IEnumerable interface.
■Classes that implement the IDictionary interface, such as Hash table can not be serialized.
The WCF uses the DataContractAttribute and DataMemeberAttribute to translate .NET FW types in to XML.

[DataContract]
public class Item
{
[DataMember]
public string ItemID;
[DataMember]
public decimal ItemQuantity;
[DataMember]
public decimal ItemPrice;

}

The DataContractAttribute can be applied to the class or a strcture. DataMemberAttribute can be applied to field or a property and theses fields or properties can be either public or private.


Important difference between DataContractSerializer and XMLSerializer.

■A practical benefit of the design of the DataContractSerializer is better performance over XMLserialization.
■XMLSerialization does not indicate the which fields or properties of the type are serialized into XML where as DataCotratSerializer Explicitly shows the which fields or properties are serialized into XML.
■The DataContractSerializer can translate the HashTable into XML.
Developing Service

To develop a service using ASP.NET we must add the WebService attribute to the class and WebMethodAttribute to any of the class methods.

Example

[WebService]
public class Service : System.Web.Services.WebService
{
[WebMethod]
public string Test(string strMsg)
{
return strMsg;
}
}

To develop a service in WCF we will write the following code

[ServiceContract]
public interface ITest
{
[OperationContract]
string ShowMessage(string strMsg);
}
public class Service : ITest
{
public string ShowMessage(string strMsg)
{
return strMsg;
}
}

The ServiceContractAttribute specifies that a interface defines a WCF service contract, OperationContract Attribute indicates which of the methods of the interface defines the operations of the service contract.

A class that implements the service contract is referred to as a service type in WCF.

Hosting the Service

ASP.NET web services are compiled into a class library assembly and a service file with an extension .asmx will have the code for the service. The service file is copied into the root of the ASP.NET application and Assembly will be copied to the bin directory. The application is accessible using url of the service file.

WCF Service can be hosted within IIS or WindowsActivationService.

■Compile the service type into a class library
■Copy the service file with an extension .SVC into a virtual directory and assembly into bin sub directory of the virtual directory.
■Copy the web.config file into the virtual directory.
Client Development

Clients for the ASP.NET Web services are generated using the command-line tool WSDL.EXE.

WCF uses the ServiceMetadata tool(svcutil.exe) to generate the client for the service.

Message Representation

The Header of the SOAP Message can be customized in ASP.NET Web service.

WCF provides attributes MessageContractAttribute , MessageHeaderAttribute and MessageBodyMemberAttribute to describe the structure of the SOAP Message.

Service Description

Issuing a HTTP GET Request with query WSDL causes ASP.NET to generate WSDL to describe the service. It returns the WSDL as response to the request.

The generated WSDL can be customized by deriving the class of ServiceDescriptionFormatExtension.

Issuing a Request with the query WSDL for the .svc file generates the WSDL. The WSDL that generated by WCF can customized by using ServiceMetadataBehavior class.

Exception Handling

In ASP.NET Web services, Unhandled exceptions are returned to the client as SOAP faults.

In WCF Services, unhandled exceptions are not returned to clients as SOAP faults. A configuration setting is provided to have the unhandled exceptions returned to clients for the purpose of debugging.