Meet Your New Web Service: Moving from ASMX to WCF

ASP.NET Under the Hood





Meet Your New Web Service: Moving from ASMX to WCF


By Michele Leroux Bustamante


Q. Now that .NET 3.0 has been released, should I be using WCF or ASMX Web services in my ASP.NET applications? Are ASMX and WSE obsolete?


A. Prior to the release of .NET 3.0 and Windows Communication Foundation (WCF), developers have been building Web services with ASMX ASP.NET s answer to the Web service and Web Service Enhancements (WSE) to include interoperable protocols related to addressing, security, and large binary attachments. Now, WCF is here a rich and complete platform for distributed communication behind the firewall and for Web services using the latest and greatest Web service standards. The question is, which technology should you use to build Web services going forward?


This is the first in a series of articles on WCF as the new and improved Web service technology for ASP.NET developers. In this article I ll discuss the evolution of Web service technologies and compare and contrast key aspects of ASMX, WSE, and WCF. I ll discuss standard support, future applicability, and practicality of each platform. I ll also comment on the learning curve from ASMX and WSE to WCF to prepare you for future installments on this subject.


Evolution of Web Service Standards and Platforms

Introduced in 1999, SOAP and WSDL standards were short specifications that finally made it possible to describe a public endpoint, its operations, and the request and reply messages associated with each operation in such a way that it could be programmatically consumed to generate client code that invokes the endpoint. Before these specifications existed we had XML schema to describe payloads sent to and returned from an endpoint but developers had to find some means to communicate which endpoint to hit, and which schema were associated with those endpoints. Developers also had to write custom code to generate or process XML (leveraging a parser, of course), and to send HTTP GET and POST requests to the appropriate endpoint.


We ve come a long way since then, but it s amazing to think about the simplicity of the early specifications (SOAP and WSDL). By their simplicity, adoption was promoted Web service platforms appeared left and right. Interoperability issues quickly surfaced, forcing platform vendors to pay close attention to their XML parsers and SOAP engines to improve consistency in how XML schema and WSDL were interpreted. In the meantime, standards building on SOAP and WSDL emerged to deal with addressing and routing scenarios, security, large binary attachments, reliable messaging, transactions, policy, and more. Like with SOAP and WSDL, these advanced standards collectively labeled WS* cycle through phases of development and approval, vendor adoption, and interoperability testing. A healthy collection of these advanced standards have been fully ratified by W3C ( and OASIS (, while others are still in the development or approval process.


In short, standards make Web services work; platforms implement standards, and, as those implementations evolve, they reach a consistency that promotes interoperability. For the ASP.NET platform, ASMX is the Web service technology that implements the fundamental Web service supporting only SOAP and WSDL. Web Services Enhancements (WSE) version 1.0 evolved to support very early implementations of non-ratified standards for addressing, routing, security, and large binary attachments. WSE 2.0 was released for the ASP.NET 1.x stack with implementations for the ratified addressing (WS-Addressing) and security (OASIS Web Service Security) standards and for the latest state of non-ratified standards for security (WS-Trust, WS-SecureConversation) and for large binary attachments (DIME). WSE 3.0 was released for the ASP.NET 2.0 stack with implementations MTOM, the ratified standard which makes DIME obsolete, and for further evolutions of advanced security standards. This is where it stops.


Enter the .NET Framework 3.0 and WCF. WCF is a platform that incorporates all the latest and greatest WS* standards, ratified and non-ratified, with the extensibility to evolve (like WSE) with the standards as they are ratified and updated. WCF includes security, reliable messaging, transactions, and other standards that will never be supported by WSE. WSE was always intended to support transition to WCF.


As a side note, WCF is more than simply a Web service platform. It is actually a platform for all forms of distributed communication formerly achieved with .NET remoting, Enterprise Services and COM+, and Web services. It unifies the developer experience so developers can learn a single object model to achieve all three results (I m focusing this article only on WCF as a Web service platform).


Architectural Similarities

Given that the standards are really what are behind a Web service, and that the technology platform is merely a facilitator for the standard, let s compare the architecture of Web service technologies for the .NET platform. ASP.NET provides ASMX, WSE is an extension to ASMX (really, simply a class library with custom configuration settings and a wizard), and WCF is a new technology stack hooked through the ASP.NET pipeline (for HTTP communication), but has its own processing model apart from ASP.NET.


Figure 1 illustrates the core components of all three technology stacks for a simple Web service and client. If you compare ASMX, ASMX with WSE, and WCF, from a high level they share similar architectural features:

  • All three expose an endpoint, either .asmx or .svc, for Web services hosted in IIS. For Windows Vista and Windows Longhorn Server, you can also host with the Windows Activation Service (WAS); this also requires an endpoint.
  • The service endpoint is associated with a service type that holds the code for each operation. In the case of .asmx endpoints, it s a type that inherits the WebService base type and implements the WebServiceAttribute from the System.Web.Services namespace. In the case of .svc endpoints, it s a type that implements a service contract using the ServiceContractAttribute from the System.ServiceModel namespace.
  • If the implementation is well designed, the service type never includes actual business logic. Instead, the service is the window through which business assemblies can be invoked a service-oriented boundary, if you will.
  • All three produce WSDL documents that describe the Web service contract. This document can be used by proxy generators for any Web service platform to generate code to communicate with the Web service.
  • All three include a proxy generator that can generate the necessary proxy code and configuration settings to communicate to the Web service to which the WSDL document points. Proxies in all cases are essentially wrappers for service operations and messages, converted to methods with parameters and a return value that can be represented as the message schema on the wire. Each technology provides a different proxy base type that handles the heavy lifting of serialization and deserialization (System.Web.Services.Protocols.SoapHttpClientProtocol, Microsoft.Web.Services3.WebServicesClientProtocol, and System.ServiceModel.ClientBase, respectively).


Figure 1: Architectural comparison of ASMX, ASMX with WSE, and WCF.


Migrating code from ASMX with WSE to WCF isn t much of a stretch from this perspective. In the simplest view, you are swapping .asmx for .svc, WebServiceAttribute/WebService for ServiceContractAttribute, and ASMX/WSE configuration for WCF configuration. The business logic remains the same. Of course, there is a learning curve involved, so it is important to evaluate the need to move from one technology to the other.


Support for Web Service Protocols

Compatibility between ASMX, ASMX with WSE, WCF, and other Web service platforms, and their respective value, really boils down to protocol support. After you ve overcome the hurdle of the application architecture, what you really need to establish are the desired protocols you wish to support for each service.


The primary point of compatibility is in the service operations and the actual message schemas that define the input (parameters) and output (return value) message for each. This requires agreement on SOAP and WSDL only. But, once we begin talking about security, message encoding formats, reliability, transactions, and other facets of Web service messaging, you must look more closely at the standards being applied and compatibility between platforms.


In reality, today s Web services largely apply ratified standards for messaging and security, including WS-Addressing, MTOM, and OASIS Web Service Security (WSS). These standards are implemented by WSE 3.0 and WCF. There are, however, important standards emerging that will improve security, reliability, and system consistency and these will not be implemented in WSE 3.0. Thus, as a forward-thinking approach, WCF is a necessity.


You should also look at each platform for its overall value in your system development efforts. Although ASMX with WSE 3.0 may solve most of today s Web service requirements, they still aren t viable technologies for distributed communications behind the firewall. Instead of learning .NET remoting or Enterprise Services for those other cases, WCF can be applied to any distributed communication setting. In this way, you are investing in learning a single communication stack, designing services independent of deployment protocol, and later deploying those services as either Web services or as endpoints available over named pipes, TCP, MSMQ, or any other custom protocol. The table in Figure 2 compares the protocols supported by ASMX with WSE and WCF.





Transport Protocols



Message Encoding

Text, MTOM, DIME (obsolete)

Text, MTOM, Binary

Web Service Protocols

SOAP, WSDL, WS-Addressing, MTOM, OASIS WS-Security, WS-Trust, WS-SecureConversation, SAML

SOAP, WSDL, WS-Addressing, MTOM, OASIS WS-Security, WS-Trust, WS-SecureConversation, SAML, WS-ReliableMessaging, WS-AtomicTransaction

Figure 2: The protocols supported by ASMX with WSE and WCF.


WSE and WCF are extensible environments that can support custom transport protocols, message encoding formats, and other messaging protocols. Still, WSE is not considered a viable option for binary distributed communication over TCP (as is WCF); in particular, because WCF supports system programming features for security, reliability, and transactions equivalent to what Enterprise Services supports.


Getting Started with WCF

There is a learning curve involved when you move to WCF. Some of the basic things you ll have to master are:

  • Designing service contracts
  • Serializing complex types
  • Host configuration settings
  • Proxy generation


In fact, WCF isn t any harder to master than ASMX or WSE it simply has more features than the two put together, because it also supports .NET remoting and Enterprise Services scenarios. Just as you would explore the Web service standards supported by WSE to employ them, you ll do the same with WCF. Just as you would explore security boundaries and distributed transactions with Enterprise Services, you ll do the same with WCF.


Having said that, what follows is a quick step-by-step introduction to a basic WCF Web service to give you a taste equivalent to what you would have with ASMX.


Installing Support for WCF

Before you can develop with WCF you must install, in this order, the necessary .NET 3.0 technologies:

  • Microsoft .NET Framework 3.0 Runtime (already installed on Windows Vista machines)
  • Microsoft Windows SDK for Vista and .NET Framework 3.0
  • Visual Studio 2005 Extensions for .NET Framework 3.0 (WCF and WPF)


The Visual Studio extensions provide WCF project and service templates to assist you.


Creating a WCF Service Project

You can add a new WCF Service to an existing ASP.NET Web site, or create a new Web site using the WCF Service template shown in Figure 3.


Figure 3: Creating a new WCF Service project.


This WCF Service template generates a new ASP.NET Web site, with a WCF service (in the same spirit as a new ASP.NET Web Service template produces a new ASMX Web service). WCF services hosted in IIS are exposed through a .svc endpoint instead of a .asmx endpoint (see Figure 4).


Figure 4: Files generated for a new WCF Service Web site.


The .svc file contains a reference to a service type, which can be a source file located in the \App_Code directory:


<% @ServiceHost Service="MyService" CodeBehind="~/

 App_Code/Service.cs" %>


You can also supply a service type that belongs to another assembly referenced by the Web site:


<% @ServiceHost Service= MyNamespace.MyService %>


In either case, the service type is a class that implements a service contract.


Creating a Service

A service contract is simply a definition for a set of operations for a service. As with ASMX, you should define an interface with those operations, then implement the interface on a service type. Here is the service contract generated by the WCF Service template:


using System;

using System.ServiceModel;


public interface IMyService



   string MyOperation1(string myValue1);


   string MyOperation2(DataContract1 dataContractValue);



Service contracts are marked with the ServiceContractAttribute from the System.ServiceModel namespace. In addition, you ll have one or more methods in the interface, marked with the OperationContractAttribute to indicate they should be included in the WSDL contract for the service that implements this contract. In this example, DataContract1 is a complex type that is passed to MyOperation2. (I won t dive in to complex types and serialization in this overview.)


To implement the contract, provide a class that implements the service contract interface. Here is the implementation provided in the generated code:


public class MyService : IMyService


 public string MyOperation1(string myValue1)


     return "Hello: " + myValue1;


 public string MyOperation2(DataContract1 dataContractValue)


     return "Hello: " + dataContractValue.FirstName;




You ve seen a service contract and a service implementation. What s interesting is that I didn t simply show you how to create a WCF Web service I showed you how to create a service that can be later hosted in IIS over HTTP as a traditional Web service, or hosted behind the firewall as a distributed TCP endpoint using binary serialization!


Hosting a Service

Following the steps so far, you have a service contract, a service type, and a service host (the Web site). In the web.config file a preliminary configuration has been created for the new service, inside the section. This is the section that contains configuration settings for your WCF services hosted by the application. The configuration should look like Figure 5 to more-or-less mimic an ASMX Web service endpoint.








      binding="mexHttpBinding" />











Figure 5: Mimic an ASMX Web service endpoint.


In summary, the configuration section does the following:

  • Exposes a BasicHttpBinding endpoint. An endpoint describes the address, binding, and contract. The address in this case is the .svc file. The binding describes the protocols used to access the service. In this case, the default settings for BasicHttpBinding are used, which means HTTP protocol is used to access the service, and that no WS* security features are enabled. The contract indicates which operations will be accessible by this endpoint.
  • Supplies a ServiceDebugBehavior, enabling exceptions to be reported to callers. This is consistent with ASMX, in that exceptions are wrapped as SOAP faults so the client can inspect them. It is recommended this be disabled in production environments (a deeper subject for a later time).
  • Supplies a ServiceMetadataBehavior, enabling HTTP GET access, so the service endpoint can be browsed to with access to the generated WSDL document. This is consistent with ASMX.
  • Exposes a metadata exchange endpoint so that clients can generate a proxy using metadata exchange instead of using the WSDL document. This must be enabled to add a service reference, which I ll describe next.


If you edit the automatically generated configuration file to reflect these settings, you ll be able to browse to the Service.svc endpoint, as shown in Figure 6.


Figure 6: Browsing to a WCF service endpoint.


Generating a Proxy

The final step in this crash tour for creating and consuming WCF Web services is to look at how clients consume the service. As with ASMX, there is a way to generate a WCF proxy to invoke the service instead of using a .NET 2.0 or WSE proxy. After creating a client application, instead of adding a Web Reference, you ll add a Service Reference, as shown in Figure 7.


Figure 7: Adding a service reference.


This generates a proxy that inherits ClientBase as discussed in Figure 1. It also generates a configuration for the client that indicates the service endpoint and the type of protocols to use, namely, BasicHttpBinding, as shown here:




    contract="WCFClient.localhost.IMyService"  />



The proxy is initialized with this configuration when constructed; combined with the metadata of the service contract, this is enough for it to know how to send and receive messages between client and service. The following few lines of code is all it takes to invoke the service:


localhost.MyServiceClient proxy =

 new WCFClient.localhost.MyServiceClient();

string s = proxy.MyOperation1("WCF Client");


Introducing Exploring WCF Web Services

At this point you ve seen the basics for creating and consuming WCF Web service endpoints, with some comparisons drawn to ASMX. This simple walkthrough reduces the complexity of WCF by focusing on a single goal, replacing what ASMX gives you. Clearly there is more to this learning curve as we have not yet discussed serialization of complex types, how to achieve similar results as with your favorite WSE scenarios, and how to weigh and incorporate the vast number of additional configuration buttons and knobs provided by WCF. It is undoubtedly the richest communication platform we have seen to date. Luckily, if you focus on specific scenarios, such as the migration of existing ASMX or ASMX with WSE services, it is possible to isolate WCF service design and configuration elements to help you on your way.


WCF will most definitely have an impact on how you approach developing Web services going forward. At asp.netPRO we want to provide you with a dedicated column titled Exploring WCF Web Services that will help you migrate successfully from ASMX and WSE to WCF, teach you the basics, discuss ASP.NET compatibility, and help tackle advanced concepts. Feel free to send questions, as always, to [email protected] for your ASP.NET topics and for WCF topics as they relate to Web service development. We re listening! Thanks for reading!


Michele Leroux Bustamante is Chief Architect at IDesign Inc., Microsoft Regional Director for San Diego, Microsoft MVP for Connected Systems, and a BEA Technical Director. At IDesign Michele provides training, mentoring, and high-end architecture consulting services, specializing in scalable and secure .NET architecture design, globalization, Web services, and interoperability with Java platforms. She is a board member for the International Association of Software Architects (IASA), a frequent conference presenter, conference chair of SD s Web Services and Web Development tracks, and a frequently published author. Michele recently completed the book Learning WCF, published by O Reilly (book blog: Reach her at or


Additional Resources

WSE Developer Center:

WCF Home:

Michele s blog:

Michele s WCF book:





Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.