Last time I demonstrated how to develop a Windows Communication Foundation (WCF) service. This time we’re going to look at the differences between a ASP.Net WebService and a WCF service. The biggest difference between them is probably that a WebService only can be activated via HTTP and they are tightly coupled with ASP.Net HTTP pipeline. A WCF service on the other hand can be bound to a large variety of network protocols. It also doesn’t require that it is hosted on a web server, it can be hosted in a console application, in a Windows Forms app, or in a WPF application. However WCF does have an ASP.Net compatibility mode setting to enable WCF services to be configured like a web service and also mimic their behavior.
A WebService relies on the XmlSerializer to serialize types into XML and back to a .Net type. The following is a list of the things XmlSerializer can serialize to and from XML.
- Only the public properties (or fields) of an object.
- Collections can be serialized only if the implement the IEnumerable or ICollection interfaces.
- Classes that implements the IDictionary interface, such as Hashtable, cannot be serialized into XML.
- You can use attributes from the System.Xml.Serialization namespace on your own classes and members to control how instances of that class will be serialized.
- You can also generate classes that can be serialized into XML from definitions of the types in XML Schema using the xsd.exe command line tool.
Point 4 and 5 describes how you can define complex types (classes) that can be serialized to and from XML.
In WCF you would also usually begin with the definition of complex types which is done adding the DataContractAttribute and the DataMemberAttribute to the class and its members, as described in my earlier post. The DataContractAttribute can be used on classes or structures and the DataMemberAttribute on properties and/or fields, which can be either private or public.
A few important differences between the DataContractSerializer and the XmlSerializer are:
- The XmlSerializer serialize all public fields and properties, while you have better control using the DataContractSerializer.
- The DataContractSerializer has better performance over XmlSerializer.
- The DataContractSerializer can serialize Hashtables.
To develop a WebService you would normally decorate a class with the WebServiceAttribute and each method with the WebMethodAttribute. This is however not an optimal solution since it does not constitute a contract for the operations performed by the service. ASP.Net 2.0 tried to rectify that by allowing you to use those attributes on an interface as well. That is the preferred method of doing it since the service contract can be reused with various classes that can implement that interface.
A WCF service requires you to create a contract, since the ServiceContractAttribute only can be used on an interface. So a WebService allows you to constitute a contract but doesn’t enforce it while a WCF service do.
Hosting the service
ASP.Net web services are hosted on a Web Server. A WCF service can be hosted on a Web Server but can just as well be hosted by a Console- or Windows Forms application.
I don’t want to make any conclusions about which technique is the best to use, because that depends on the specification. A WebService is usually easier to develop but are somewhat limited. A WCF service is more versatile but can be harder to develop. To make a true comparison you should really compare the two techniques if you want to host the service on a Web Server, such as IIS, since if you want to use another host you can’t use an ASP.Net WebService. I just leave the judgment up to you.