This question comes up a lot in conversations I have with developers.
“Why would I want to switch to ASMX services?”
One analogy I have come up with to explain the difference between the two is an airplane analogy.
I associate ASMX services with a Cessna 150 cockpit and I associate WCF services with a 747 Jumbo Jet cockpit.
I’ll be honest, I’ve never flown a plane but I think I’m smart enough to crank a Cessna 150 if I had to figure it out. The above screen shot is a real Cessna 150 cockpit. There are a few gauges, some knobs, etc. Really not that bad. And I think this explains ASMX really well. ASMX services are easy to crank and jump start. Think about it. We take an existing Asp.Net website and add a file called “asmx”. Any method we attribute with [WebMethod] magically turns into a service. Objects we pass in and pass out that have public getters and setters will be serialized into XML.
1: [WebMethod]
2: public string FlyToDestination(Location loc)
3: {
4: // up up and away
5: }
The barrier to cranking and getting going with an ASMX service is really simple. And because it is simple, we’ve adopted them on a massive scale. Let’s turn our attention to WCF.
WCF is a jack of all trades. Think of it like a large plane that can repurposed for hauling passengers, hauling cargo, military use or whatever. We are dealing with a plane but it is all about how that plane is configured. Because things can be configured a lot of ways with the WCF 747 plane there are a lot more buttons in the airplane cockpit as compared to the Cessna 150. The flip side of this is that once you understand how to configure WCF you’ve got one of the most versatile plane in the world!
From a developers stand point, the same logic or code written in an ASMX service works in WCF. The code between the curly braces is the same. The bottom line in either case is a method gets called and an object gets passed in (we call this a message when talking about services). The difference in WCF is we program to a specific contract. Here’s the same example above done in WCF.
1: [ServiceContract]
2: public interface IAirportService
3: {
4: [OperationContract]
5: string FlyToDestination(Location loc);
6: }
7:
8: public class AirportService : IAirportService
9: {
10:
11: public string FlyToDestination(Location loc)
12: {
13: // up up and away
14: }
15: }
Instead of attributing the specific method like we do in ASMX, in WCF we attribute the Interface. Programming to an Interface is a good thing and the reason this is done is to loosely couple the host of the service from the implementation. Doing this opens the door for hosting WCF services not only in IIS but console apps, Winforms, WPF, etc. Since we’ve programmed to a contract (which is just an Interface), any class that implements the Interface can be a service. This is powerful. This is powerful because how we expose this service is up to us (again it is all about configuration). Because we can expose our AirportService a number of ways we can see that WCF provides developers the ability to write code once and repurpose their code as needed.
Exposing a WCF service requires a little more training from this point forward ( just like flying a 747) because we have to understand how to configure the service. It is this little bit of extra effort required to understand WCF configuration that stops a lot of developers from using WCF. This is a shame because when the developer using ASMX wants to guarantee message delivery, participate in transactions, or use binary serialization instead of XML, they’ve got a lot of work ahead of them as compared to WCF.
The moral of the story is ASMX is simple and because it is simple, it isn’t very powerful. Take the time to learn about WCF because this is the future of the .Net platform, thus it will be time wisely spent. If you’ve been holding back I encourage you to step out of your old ASMX habits and learn the ways of WCF.
If you would like to dig a little deeper with WCF I encourage you to check out my “Demystifying Windows Communication Foundation” power point. In there you’ll find a lot more details about how WCF works.
http://keithelder.net/Presentations/DemystyfyingWCF/DemystifyingWindowsCommunicationFoundation.ppt
Happy messaging.
[…] Elder nicely compares ASMX to WCF here. Check it […]
[…] comprendere appieno la differenza che intercorre tra Asmx e WCF è opportuno leggere questo eccellente articolo di Keith Elder, che spiega molto bene la diffenza di vedute dei due sistemi, evidenziando le limitazioni del primo […]
In the graphic analogy the second cockpit is not of 747. What sya???
[…] Elder nicely compares ASMX to WCF here. Check it […]
Interesting to see … thank you it’s well done , well written article 🙂
You can create an asmx with visual studio, it creates everything you need. There an asmx file, an appcode folder with your .cs file, a bin folder with your .dll and a web.config file. Then when you add it to IIS for example, it works.
Sabine, I’m with you. You’re supposed to be able to send out ASMX style services by just setting a flag to WsHttpBinding somewhere. i’ve yet to find a simple example of this however. if you’ve got anything working, could you give me a hint on how to do this? I have 100 ASMX style webservices talking to an iPhone app, and want to build 200 more and maintain the existing 100. I don’t want to pay my iPhone consultants to re-write old APIs, and come u p with new code to talk to something that’s not ASMX. Thanks in advance, john@ViridianTech.com
nice work.
This is an old article but still relevant… and confirm my choice of staying with asmx. I want a plane where anybody not familiar with a plane can understand it in a glance. Not the case of the 747…
I work in a aera where the logic of the web service has to be reallly easy to read. SIMPLE is the keyword. To keep up with the analogy, my work is to deal with an entire airport on my own, so I have to be able to fly a plane, repair it, maintain it, work in the control tower and do the dishes.
So it’s an old way of doing things, but at least I understand the whole chain and when a bug occurs, I know what I’m doing so I can easily repair it.
The thing I like about asmx is that I can read the code on the server where it’s deployed… It’s means that wherever I am, I can connect to the sever and see the logic of my web service to be able to answer quicky to a question “what if we do that?” as I don’t know every detail of my web services, instead of lauching a solution in visual which is not available from everywhere.
Where does this place the Concorde? 🙂
[…] http://keithelder.net/2008/10/17/wcf-vs-asmx-webservices/ […]
WCF is so complicated they made WebAPI for REST services… and nobody cared because ServiceStack is much better!
That’s definitely a compliment! 🙂
NEEEERRRRDDDD!!!! 😀
Boats are greater than planes any day! My boat is named *Sea Sharp* so pretty fitting huh? 🙂 http://www.flickr.com/photos/keithelder/6253622521/in/set-72157627914934580
Glad it helped Adam.
“I realize this is an older article” posted two years ago.
Well…. I realize this is an OLD article… but it has yet again assisted with a minor-league developer in understanding the differences. Great Job!
Hey Andrew,
The road map right now is WCF for messaging. Really isn’t anything else in terms of doing really good messaging. And Glenn at MSFT is doing a great job of bringing in REST and other things into WCF that are expanding it. Glenn is on the right track with what they are adding to WCF and very open about it by posting to wcf.codeplex.com. There’s a lot of work going on there with RIA Services, Web and so on that is really where *newer* messaging paradigms are getting added to WCF.
Think about it, ASMX is just one thing. You want to do REST. Can’t do it. REST is the *new shiny toy*. Because of WCF’s flexible/pluggable architecture things like that can be added to enhance WCF. ASMX is still living in an old SOAP world. So moving forward and for the future, WCF is going to get enhanced as new ways of messaging come up. ASMX will still be its plain old self (if they don’t phase it out). I say it is better to get on board now than be left behind. Plus you only have to use in WCF what you need to get the job done.
And in recent years, we’ve seen thinking go in the opposite direction on web services — to the even simpler REST architectures which use GET/POST protocols to send data to methods using Json notation.
Well, as my high school physics teacher used to say…don’t argue by analogy.
what is ASMX?full form?
I like the idea behind WCF, but the configuration is nightmarish.
A very good way to explain the pros and cons between ASMX and WCF. It was well understood, so many thanks.
Keith,
Thanks for the reply and explanation. I guess you are saying that the Cessna/747 analogy applies to the power of WCF, but not as much so to the maintenance. That is good to know. And yeah, I do like the sound of 100-300% performance increase. Who wouldn’t? 🙂
Andrew
Hey Andrew, great questions. In terms of performance WCF is about 10-15% faster than asmx out of the box (due to a better serializer). You are right, this article is old but it is something I still see devs fighting with. The great thing about .NET 4.0 today is WCF is just as simple as ASMX. This is all due to default behaviors and default bindings. If you crack open VS2010 and create a web project and add a .svc file to the project you’ll notice a couple of things. 1) it just works 2) it works as simple as ASMX services 3) there is hardly any configuration in the web.config. .NET 3.5/3.0 I can’t say this but .NET 4.0 makes WCF simple and there are a lot of things happening in the WCF space thanks to Glen running the team. Definitely check out http://wcf.codeplex.com/ for what the team is doing and where they are headed. Lots of good work going on.
Ok, now back to the performance thing. How does roughly 100%-300% faster over ASMX services strike you? The reason is using WCF NetTcpBinding you have binary over the wire and it is a vast improvement over ASMX. I mean why wouldn’t you want your .NET clients to leverage your service as FAST as they can? All you have to do is write it and configure it for tcp, done. Your other clients can leverage the same service and hit another endpoint such as the BasicHttpBinding where that binding is the same as ASMX and provides good interoperability. You write one service, expose it two different ways. .NET clients are rocking binary, others xml. I think that is a huge win and that’s how my team builds our services. I have another blog article on how to do that. Hope this all helps.
Keith,
I realize this is an older article, but google has it ranked as the second hit on ‘wcf vs asmx’ so it might still be relevant to post this here.
This is a good article and I think it comes across well, but something I have been asking myself lately in converting our old ASMX services to WCF is whether or not its always worth it. Even in the analogy you’ve used here, there are many reasons why a Cessna is a much better solution, not the least of which is the simplicity required in maintaining it. One man can easily be responsible for maintaining many Cessnas, but certainly couldn’t be asked to maintain even a single 747. Given that the performance boost is frequently not huge and probably only noticeable under very heavy load, is the extra complexity worth it if you are sticking with IIS and HTTP anyways? Does Microsoft’s roadmap give us a choice?
Thanks,
Andrew
Thank you for the excellent article
Great question Rick. The very first thing that comes to mind is speed. Using the airplane analogy a 747 is faster than a Cesna 150. WCF’s serialization is faster than ASMX. It was built with that in mind. Watch this talk I did for Channel 9 awhile back and look at the difference in speed in ASMX vs WCF services using the exact same data. Here’s the link:
http://keithelder.net/2009/09/02/video-wcf-deployment-strategies-on-channel9/