Sunday, February 3, 2013

WCF versus ASP.Net API

This is a slight diversion from my ongoing ASP.Net MVC tutorial but there is relevance even if it may not seem like light reading.

I just sat down this morning to familiarise myself with Windows Communication Foundation or WCF for short. WCF is a framework for building service oriented applications and allows data to be sent asynchronously from one service to another. The client can be a web page, a mobile application or a desktop application such as Microsoft Excel. I was beginning to wonder why I hadn't delved into it previously as my final year project at Trinity College in 2001 was based on loosely coupled web services which I used to develop an Enterprise Resource Planning system. WCF hadn't yet come on the scene in 2001. Microsoft were busy developing Simple Object Access Protocol (SOAP) which is a specification for exchanging messages using XML.

Microsoft combined SOAP with Web Services Description Language (WSDL) to produce WCF which integrated web services into windows applications. It did solve many issues of previous messaging systems such as a single programming model which could be extended to support future transport protocols and messaging formats. I had considered SOAP in my final year project but at the time it was relatively new and there was significant overhead over XML over HTTP which at the time appeared to be a very lightweight and flexible alternative. Most of my applications were web based, so I developed my own little framework at the time using XMLHTTP, Javascript and Classic ASP which worked really well and was flexible enough to adapt to most problems that confronted me. AJAX came out a couple of years later as a formalisation of the XML over HTTP framework, made popular by Google. With the popularity of the web, the lightweight frameworks became popular especially for non critical applications.

When ASP.Net 2.0 came along, I started to look into it as the the missing link in my application was an Object Oriented approach to the business logic. Perhaps having come from a lightweight and flexible approach to web services, I found ASP.Net very heavy and disorganised. With ASP.Net, although I could now create classes for my objects which I felt was important to put some order on my business logic, I considered the tight binding of the User Interface and the business logic through the code behind method to very messy. ASP.Net seemed OK for very small applications but led to a lot of redundant code for larger applications. My lightweight application using XML over HTTP continued to do the business so it is unlikely that WCF would have interested me. With a little influence from Ruby on Rails, thankfully Microsoft redeemed themselves with ASP.Net MVC. And now with .Net 4, Microsoft have delivered Web.API which is very interesting.

After doing a little research into WCF, I started to wonder if there are more than a  few confused developers out there since Microsoft's decision to move Web API from WCF over to ASP.Net MVC. Have a look at Microsoft's 2006 article 'Future of ASP.Net Web Services in the context of Windows Communication Foundation' versus Microsoft's recent roadmap for Web API. Clearly Microsoft's focus has shifted towards web technologies and HTTP is now clearly the protocol of choice.

If HTTP is your preferred transport protocol, for the most part the same end result can be achieved using both Web API and WCF frameworks as WCF now supports HTTP and RESTful web services. Once you have invested in a technology such as WCF, you are less inclined to make any sudden moves to the latest technologies as the bleeding edge can be more than slightly uncomfortable. Microsoft realise this and will continue to support WCF but it is starting to become clear that there are two camps emerging, the ASP.Net/WCF and MVC/Web API.

My personal preference is MVC/Web API but I am slightly biased towards the MVC framework, also because I have not put considerable investment in ASP.Net but importantly because of the pure simplicity of MVC. MVC has simple convention rules which imposes structure on applications that has enormous benefit for projects especially for large teams. Being able to look at a project you are not familiar with and immediately knowing where the models are, that all data access is contained in neat data repository files for each model and the UI contains the minimum of business logic thus allowing the UI guys and girls to be creative without the overhead of intermingled code. Now extend this slightly and you get an asynchronous messaging system. This is where convention over configuration comes into its own. Web API supports numerous clients including Web, Mobile and desktop applications and is likely to extend further as the end service only needs a URL and the ability to consume popular formats such as XML, JSON and a range of other formats. Due to the general popularity of the OAuth framework for open standard authorisation and Microsofts integration of OAuth2 in MVC4, it appears to be gaining popularity for securing Web API messages. The concepts of OAuth should be familiar for anyone who has used payment systems such as PayPal. A full list of applications that support OAuth can be found on Wikipedia.

ASP.NET API is a framework for building non-SOAP based services over HTTP only whereas Windows Communication Foundation is designed to exchange SOAP-based messages using variety of transport protocols like HTTP, TCP, NamedPipes or MSMQ etc. If you need to support a variety of transport protocols, or the slower performance of HTTP is a consideration, WCF will continue to be the popular. ASP.Net API is certainly one to watch as the web gains popularity as the platform for business applications.