*Words of Wisdom From The Elder

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.