Hi friends,
Again new WCF article
We are currently migrating a small web services built on top of ASP.NET in .NET 2.0 (commonly referred to as ASMX Web Services) over to the Windows Communication Foundation (WCF) platform available in .NET 3.0.
The reason behind this is we want speed which WCF provides.
The primary reason we want to do that is because we would like to take advantage of the binary message serialization support available in WCF to speed up communication between the services and their clients. This same technique was possible in earlier versions of the .NET Framework thanks to a technology called Remoting, which is now superseded by WCF. In both cases it requires that both the client and server run on .NET in order to work. But I digress.
Since the ASMX model has been for a long time the primary Microsoft technology for building web services on the .NET platform, I saw Microsoft has made nice setting in app.config of WCF migration path to bring all those web services to the new world of WCF.
The quick way
If you built your ASMX web services with code separation (that is, all programming logic resided in a separate code-behind file instead of being embedded in the ASMX file) it is possible to get an ASMX web service up and running in WCF pretty quickly by going through a few easy steps:
- Your WCF web service class no longer inherits from
the System.Web.Services.WebService class so remove it.
- Change the System.Web.Services.WebService attribute on the web service class to the System.ServiceModel.ServiceContract attribute.
- Change the System.Web.Services.WebMethod attribute on each web service method to the System.ServiceModel.OperationContract attribute.
- Substitute the .ASMX file with a new .SVC file with the following header:
Here is a summary of the changes you’ll have to make to your ASMX web service:
Where the change applies | ASMX | WCF |
Web service class inheritance | WebService | - |
Web service class attribute | WebServiceAttribute | ServiceContractAttribute |
Web service method attribute | WebMethodAttribute | OperationContractAttribute |
Data class attribute | XmlRootAttribute | DataContractAttribute |
Data class field attribute | XmlElementAttribute | DataMemberAttribute |
HTTP endpoint resource | .ASMX | .SVC |
As a side note, if you are using .NET 3.5 SP1 the porting process gets a little easier
- WCF services are not bound to the HTTP protocol as ASMX web services are. This means you can host them in any process you like, whether it be a Windows Service or a console application. In other words using Microsoft IIS is no longer a requirement, although it is a valid possibility in many situations.
- Even if WCF services are executed by the ASP.NET worker process when hosted in IIS, they do not participate in the ASP.NET HTTP Pipeline. This means that you have no longer access to the ASP.NET infrastructure services such as HttpContext, HttpSessionState, HttpApplicationState, ASP.NET Authorization and Impersonation in your WCF services.
So what if your ASMX web services are making extensive use of the ASP.NET session store or employ the ASP.NET security model? Is it a show-stopper?
Luckily enough, no. There is a solution to keep all that ASP.NET goodness working in WCF. It is called ASP.NET Compatibility Mode.
Backwards compatibility
Running WCF services with the ASP.NET Compatibility Mode enabled will integrate them in the ASP.NET HTTP Pipeline, which of course means all ASP.NET infrastructure will be back in place and available from WCF at runtime.
You can enable this mighty mode from WCF by following these steps:
- Decorate your web service class with the System.ServiceModel.Activation.AspNetCompatibilityRequirements attribute as following:
[AspNetCompatibilityRequirements(
RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
public class MyService : IMyService
{
// Service implementation
}
- Add the following setting to the application configuration file:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>
Remember that this will effectively tie the WCF runtime to the HTTP protocol, just like with ASMX web services, which means it becomes prohibited to add any non-HTTP endpoints for your WCF services.
Good luck and please, let me know your feedback!
Regards,