What to choose? ASMX web service or WCF in .net 3.5?

Question

The current project i am working on is extensively using web services and is made in .net 3.5. Now as we are going for implementation of second phase we are confused if we shoul

Answer 1

Two further aspects:

1. No matter how you decide this for the server-side, you can easily consume Webservices and WCF Services using only WCF on the client-side. This is of value, if you consume multiple services with a single client.

2. You asked for upcoming themes. If you consider Cloud Computing: It is possible to host WCF Services on Windows Azure.

Answer 2

We just finished a brand new project using WCF instead of ASMX Web Services for the first time. We are VERY happy with the results, but do know that there was a steep learning curve. Even so, we are extremely pleased with the overall results and know that this is the basis for everything Microsoft is doing going forward and it has been totally worth the pain--warts and all.

Quick benefits WE gained OVER ASMX:

1) For internal (behind firewall) service-to-service calls we use the net:tcp binding, which is much faster than SOAP

2) We enabled both a net:tcp endpoint and a "web" endpoint on the same service with only a configuration file update (no code changes)

3) We were able to create AJAX-supporting RESTful web services with only configuration changes and using the DataContractJsonSerializer that's already built in. To do this otherwise, we would have had to write an HTTP Handler (ashx) and handle most of the Json serialization and url parsing by hand.

4) As our site needs to scale for performance optimization and stability, we are looking at converting to using an MSMQ-based messaging structure that is asynchronous AND guaranteed and participates in transactions; WCF provides an MSMQ bindng that requires little-to-no code change in our services--just reference updates and setting up MSMQ properly with the existing services (and adding attributes for Transactional boundaries).

BUT BE WARNED: Really invest in learning this (buy the blue O-Reily book and go through it). There are things like argument-name-changes during development that actually don't break the service references but result in null arguments being passed (built-in version skew handling), hosting models to consider (Windows Service vs. IIS), and instantiation models and FaultExceptions to all REALLY understand. We didn't going in and we had some pains. But we plowed ahead and are VERY happy with our learnings and the flexibility and growth opportunities we have not being tied to ASMX anymore!

Answer 3

There are different points to consider before jumping on to WCF:

1. WCF is architecturally more robust and promotes best practices.
2. If you know what you are doing its "silky smooth" if not you are in for a ride.
3. Do you have enough time to complete the conversion of your services?

Finally I would say that, if you have the time, the bling and the muscle to do the upgrade. Its worth it. If asmx is satisfying all the needs, you may persist with web services.

Answer 4

The WCF model is vastly more flexible, essentially - if you only use it to present a basic http model using basic-profile and xml, with proxy objects - it'll appear very similar.

A brief list of differences though:

• much better support for emerging standards (although WSE2 and WSE3 are available for asmx, it is all much simpler in WCF)
• MTOM inbuilt (and fixes a known bug that I remember finding in WSE3 with MTOM)
• much wider range of supported transports/protocols etc, and the behaviours are fully configurable/extensible; for example allowing you to use a custom serializer/protocol/transport/etc seemlessly, just by changing the config
• much richer configuration, both at config and runtime
• full support for inspectors and custom principals
• ability to share object-models if you want
• you can host it outside of a web-server; a console exe or service, for example

Answer 5

With either WCF or ASMX, make sure you are adding your services to your pages by using the asp:ScriptManager tag. It will build JavaScript proxies for you, and the advantage is that you don't have to build any parsing at all, regardless of the underlying protocol. It's very, very nice. This example is ASMX, but it's every bit as clean as using WCF.

<asp:ScriptManager ID="ScriptManager1" runat="server">
    <Services>
        <asp:ServiceReference Path="~/WebServices/Admin/HospitalLocationService.asmx" InlineScript="true" />
    </Services>
</asp:ScriptManager>

Also, you can make ASMX send JSON by adding the ScriptService and ScriptMethod attributes:

<System.Web.Services.WebService(Namespace:="http://www.fujimed.com/")> _
<System.Web.Services.WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1)> _
<ToolboxItem(False)> _
<ScriptService()> _
Public Class HospitalLocationService
    Inherits System.Web.Services.WebService

    <WebMethod()> _
    <ScriptMethod()> _
    Public Function GetAll() As List(Of HospitalLocationEntity)
        Return (New HospitalLocation()).GetAll().Data
    End Function

    <WebMethod()> _
    <ScriptMethod()> _
    Public Function GetByID(ByVal ID As Integer) As HospitalLocationEntity
        Return (New HospitalLocation()).GetHospitalLocation(ID).Data
    End Function

End Class

Consuming the service, without parsing (this is what the ScriptManager does for you):

 function editLocation(id) {
    vRIS.HospitalLocationService.GetByID(id, getComplete, getError);
 }

 function getComplete(results, context, methodName) {
    document.all['txtLocation'].value = results.Location;
    document.all['txtInterfaceID'].value = results.InterfaceID;
    document.all['selActive'].value = results.Active ? "true" : "false";
    document.all['hdnLocationID'].value = results.ID.toString();
 }

 function getError(errorInfo, context, methodName) {
    Alert(methodName + " : " + errorInfo);
    document.all['txtLocation'].value = "";
    document.all['txtInterfaceID'].value = "";
    document.all['selActive'].value = "false";
    document.all['hdnLocationID'].value = "";
 }

Edited to add: With all the above based on ASMX, I'd still go WCF, for versatility and for the ability to define data contracts. Also, investigate WCF RIA Services; they are targeting support for AJAX as well as Silverlight, and it automates much of the configuration of WCF.

Answer 6

ASMX is great and simple - but it's very limited in many ways:

• you can only host your web services in IIS
• you can only reach your web services over HTTP
• security is very limited

WCF remedies this - and offer much more beyond that. You can host your WCF services in IIS - or self-host in a console app or Win NT Service, as need be. You can connect your WCF services using HTTP, TCP/IP, MSMQ, Peer-to-peer protocols, named pipes for on-machine communications and much more.

I'd definitely recommend you go with WCF. It's a tad more complex than ASMX, but it also offer just sooo much more capabilities and choices!

As for resoures: there's the MSDN WCF Developer Center which has everything from beginner's tutorials to articles and sample code.

Also, I would recommend you have a look at the Pluralsight screen casts on WCF - it's an excellent series going from "Creating your first WCF service" and "Creating your first WCF client" all the way to rather advanced topics. Aaron Skonnard very nicely explains everything in 10-15 minutes screencasts - highly recommended!