Saturday 31 March 2012

ASP.NET Web API Series - Part 2: Async basics and background

[Level T2]

Async is here, async is there, async is everywhere. [For a newer related post see here]

Not sure above line is from which film (or did I just make it up?) but surely a quick look at the ASP.NET MVC 4 and its Web API features just shows how much asynchronous programming is encouraged.

In this short post, I just want to cover some of the basics and background for async in Web API without going  into async keyword or .NET 4.5 features. Remember, all of the async features of ASP.NET Web API is accessible in .NET 4.0 and VS 2010 without using VS 2011 and async keyword. It is true, though, that with new language features expected in .NET 4.5 this would be even more tersely possible.

One of the obvious reasons asynchronous programming is encouraged is the fact that servers nowadays run tens of parallel processors and ability to run the code in parallel is very important.

Yet, I would also like to see this from another angle. I do not want to approach this as a conspiracy theory but I think there is an important change in IIS that we need to be aware of which affects scalability of ASP.NET Web Applications. OK, will give you a clue: what was the fundamental architecture change from IIS 6.0 to IIS 7.0? Well, yes, integrated pipeline! So let's look at how it affects the threading in IIS.

This was actually a question that I answered in StackOverflow. When I was reviewing this I looked around and found my own answer from last year. It can probably tell you a bit how terrible my memory is! So one of the changes was (a good background here) to remove the limitation of ASP.NET on the number of threads (if I remember correctly, IIS 6.0 had 250 threads per application pool) and only have a limitation on the number of requests queued. This can be set per each application pool in the advanced settings menu:


As the above article mentions, IIS 7.0's integrated pipeline is as scalable as amount of work done async:
... in IIS 7.0 integrated mode, ASP.NET restricts the number of concurrently executing requests. The difference only matters when the requests are asynchronous (the request either has an asynchronous handler or a module in the pipeline completes asynchronously). Obviously if the reqeusts are synchronous, then the number of concurrently executing requests is the same as the number of threads concurrently executing requests, but if the requests are asynchronous then these two numbers can be quite different as you could have far more reqeusts than threads.
So basically, the more async is used for long-running IO-bound operations (talking to other services, reading from disk, connecting to databases), the more threads are free to process incoming requests. This is particularly important in the light of the fact that serving static content under integrated pipeline has to go through ASP.NET runtime hence each using up a thread. So if you have 500 concurrent users and they are loading a page each containing 5 static content, if there is no Async used, some of these users will experience 503 errors for some of the content as the queue will get full.

Now, let's see how we can use Async in ASP.NET Web API in .NET 4.0 without using async keyword which is introduced in .NET 4.0.

All you have to do is to return a started Task<T>. Note the started, if you just create and return the task, the response will not return back from server and request will be timed out.

So here is a typical Async task:
  
  
   // GET /api/HelloWorld
  [HttpGet]
  public Task<string> AsyncCall()
  {
   return
    Task.Factory.StartNew<string>(
     () =>
     {
      Thread.Sleep(5000);
      return "Hello World";
     }
    );
    
  }

This is a minor enhancement on our HelloWorldController and in order to simulate the long running task, I have put a Thread.Sleep for 5 seconds. Now if you browse, you will experience a noticeable delay (for 5 seconds) before you get back the response.

Now the question is, does the task really runs in a different thread? Well, easy to test. All we have to do is to name the controller thread and see if the task thread name is the same:

  
  // GET /api/HelloWorld
  [HttpGet]
  public Task<string> AsyncCall()
  {
   Thread.CurrentThread.Name = "AsyncCall";
   return
    Task.Factory.StartNew<string>(
     () =>
     {
      Thread.Sleep(5000);
      return "This is the thread name:" + Thread.CurrentThread.Name;
     }
    );
    
  }
  
The result is:
  
      "This is the thread name:"

So the thread name was empty string proving the thread doing the task was indeed different.

Conclusion


Use of Async programming with the help of PTL is highly encouraged especially in IIS 7.0. This will improve scalability of the web application and is very easy to do.

For more in depth Async coverage, move on to the next post Async Deep Dive.

Wednesday 28 March 2012

ASP.NET Web API Series - Part 1: Getting started...

[Level T1]

OK, in order to get started you may have a look at these excellent resources.

Alternatively, I will cover a little bit of background on how to get up and running.

FAQ

  • Where would I download it from? You may get it from here.
  • Do I need .NET Framework 4.5 to run it? No, it quite happily works with .NET 4.0. In fact if you have .NET 4.5 installed on your machine, you need to uninstall it.
  • Can I run it in Visual Studio 2010? Yes. In fact AFAIK it currently does not run in Visual Studio 2011.
  • Is it safe to install this on my main development machine? Most probably yes. I have not seen any problems so far and not aware of any problems reported.
  • How would I create a new Web API project? After installation, just go to Visual Studio 2010/Create new project and from "Web Projects" choose "ASP. NET MVC 4.0". You will be shown a menu from which you may select "Web API".
  • How easy is it to pick up ASP.NET Web API? If you are familiar with ASP.NET MVC, then very easy. If you come from a Web Forms or WCF background, you need to get up to speed with HTTP and REST fundamentals.

Hello World

Your ASP.NET Web API project comes with a sample controller called ValuesController. You may rename the class to HelloWorldController. An API controller is pretty much all you need to get it working now - more details below. Project also comes with standard MVC HomeController which will serve the home page.

So let's delete all the contents of the HelloWorldController and put the code below:

namespace GettingStarted.Controllers
{
 public class HelloWorldController : ApiController
 {
  // GET /api/HelloWorld
  public string Get()
  {
   return "Hello World";
  }

 }
}

OK, if you browse to http://localhost:<YourPortName>/api/HelloWorld, you will see this page:

Great! So we made our first ASP.NET Web API service. Now let' see how this magic work.

First of all, we see a controller, similar to MVC controller but it is inherited from System.Web.Http.ApiController rather than System.Web.Mvc.Controller.

Also you may notice that you can get to the home page using the base URL but for our Web API controller, we need to add "/api" to the base URL. This is simply a convention and can be overriden in global.asax:

routes.MapHttpRoute(
 name: "DefaultApi",
 routeTemplate: "api/{controller}/{id}", // note "api/" !!
 defaults: new { id = RouteParameter.Optional }
 );

Does it not look familiar? Yes, it is, almost the same as ASP.NET MVC routing. One difference is that we use MapHttpRoute instead of MapRoute. Welcome to the parallel universes! The other difference is that we do not define an action here.

So how the action gets defined? We used the name Get for our method name. This is not a co-incidence, this basically tells Web API to use this method for GET HTTP verbs. An alternative is to use [HttpGet] attribute and use any name for the method:

// GET /api/HelloWorld
[HttpGet]
public string AnyName()
{
 return "Hello World";
}

Above code works just the same. Now let's look why the data received back was XML? We did not define that we need XML. Well, it is because Chrome (this is the browser I use) sent this Accept header:


Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8


This will kick in the Content Negotiation and Web API chooses application/xml formatter and formats the data as XML. If we remove this header, here is what we get:


200 OK
Date: Wed, 28 Mar 2012 17:47:54 GMT
X-AspNet-Version: 4.0.30319
Transfer-Encoding: chunked
Connection: Close
Pragma: no-cache
Server: ASP.NET Development Server/10.0.0.0
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache
Expires: -1
"Hello World"

Note the JSON content-type. So basically the default formatter is JSON formatter which is the best choice.

Conclusion


Web API is very easy to get started with. In the heart of Web API we find the API controller.

Tuesday 27 March 2012

ASP.NET Web API Series - Part 0: Why not WCF Web API?

[Level C3]

I am starting out a series on ASP.NET Web API. This will start look into features of the beta version that was released in the last few weeks.

But before that, we start with a journey into the history and stages of this framework as it has had quite a few changes in the direction.

Birth of WCF

I remember my enthusiasm with remoting when it came out. I personally preferred it to Web Services and as it turned out, it provided a more seamless transport of DTOs (Data Transfer Objects).

Remoting was superceded with  WCF. When WCF, WPF and WF was announced with .NET 3.0, as a middleware specialist, I naturally picked up WCF to learn. I was amazed with the power and flexibility of design - yet it was extensible. So the world was perfect wasn't it?

Well we later found that, no it was not. So what was the problem?

The fallacy was that WCF at its heart was nothing more than an RPC framework. (details coming!)

Let's remember RPC frameworks were not new. Microsoft had DCOM which later was boosted to COM+. But what they lacked was the interoperability. When XML gained popularity some quickly picked up that XML can solve the interoperability issues of COM+ and SOAP was born. This lead to the development of SOAP web services but we soon realised that we need something bigger and more flexible than ASMX web services to be able to support all the new shiny WS-* standards.

And in the middle of 2000s, we got the WCF. It was built on the top of WSDL goodness (hence interoperable with existing Web Service clients) while abstracting pretty much everything else (transport, synchronicity, one-way or two-way or duplex, ...)

As an RPC framework, WCF sacrifices context of the transport for the seamless marshalling of DTO/payload according to the operation contract. So it is Transport-Agnostic and in that respect, WCF is beautiful or in fact beauteous.

Let's have a look at a typical service operation.

[ServiceContract]
public interface IWidgetService
{
    [OperationContract]
    string GetDescription(int id);
}
This is a typical service interface. GetDescription is is a typical service operation. There is no magic involved here, but according to WCF abstractions, the logical operation has been completely abstracted from the transport being used. You could be using MSMQ, HTTP, TCP, etc to achieve this operation. Microsoft have not implemented FedExBinding (!) but theoretically this message could be transported physically using FedEx/snail mail - perhaps I am taking the abstraction a bot too far. So I could swap the HTTP binding with TCP binding without changing a line in my code, all in the configuration files.

Fallacy of WCF


Now here is a challenge. What if I need to specify anything specific to the transport in the runtime? Microsoft's answer has been you actually do not need to because we did not design it as such! This post from 2007 clearly explains it:
Can I get the IP address of a client connecting to my service? 
No. Sorry. In most cases this information is not available. Exposing such functionality is left to the transport to be done in an implementation-specific manner. The most popular transports we supply out of the box do not offer this. ..
Now, this other post from 2006 expects you to expose such information as headers. It is true that this would not change the service interface, but it would clearly change the WSDL.

Now it is history that Microsoft finally gave in and implemented such features - perhaps reluctantly. But it was clear that the community was not impressed by the lack of support for getting such information (one in the first post pointed out "this is basic stuff"). Solution was to use Thread's storage area to store the metadata as message properties:

[ServiceContract]
OperationContext context = OperationContext.Current;
MessageProperties prop = context.IncomingMessageProperties;
RemoteEndpointMessageProperty endpoint =
    prop[RemoteEndpointMessageProperty.Name] as RemoteEndpointMessageProperty;
string ip = endpoint.Address;

So OperationContext.Current very much like HttpContext.Current became the curse of the gnosis of Transport-Agnosticism - if there is such sentence in the English language!

Now using OperationContext.Current per se is not a huge problem especially if it is done sparingly. Reality is a lot of day-to-day RPC operations, would not need to access message properties. So, perhaps life was good enough again and WCF started to be implemented in the enterprise.

Popularity of REST and birth of WCF REST

It is true that life was good again but the industry - especially leaner startup companies - started to re-discover and embrace HTTP. While SOAP reduced HTTP to mere a transport mechanism, REST enthusiasts started to talk about media types, hyperlinks, custom verbs, etc.

Ironically, one of the main features associated with REST (yet having little to do with it) was clean URLs that became hallmark of REST. Since Mircosoft had already started to work on cleaner routing for ASP.NET MVC and supporting alternate HTTP verbs (such as PUT and DELETE) was there, this feature was almost readily available so associating WCF with REST seems like a good idea.

In reality, WCF REST had the same shortcomings of conventional WCF. This fundamental fact cannot be hidden that WCF was designed as a Transport-Agnostic framework and it was impossible to introduce HTTP semantics without complete redesign and losing the Transport-Agnosticity. Hence Microsoft decided to continue enriching WCF with more WS-* standards (e.f. federation) for the enterprise while creating a different system for RESTful HTTP.

WCF and REST?

Reality is marriage of WCF anbd REST was flawed right from the start. WCF is an RPC implementation and as such works based on IDL. WCF uses WSDL as an implementation of IDL, a hangover from the days of Web Services.

I am not trying knock WCF. True, WCF is an RPC implementation, but to my knowledge it is the best one. I think WCF still rocks in the enterprise where services have to comply with reams and reams of in-house rules and regulations - and all interfaces have to be cast in the stone. If all you care is RPC, WCF is your best friend.

Reality is Web 2.0/Cloud/New Web/WhateverYouCallIt outdated all Microsoft Innovations of mid-2000 soon after they came out. On the UI front, WPF and Silverlight succumbed to the popularity of iPad (yes perhaps Steve Jobs did kill Silverlight by banning it from iPad) and HTML5 bandwagon. Simplicity of lean RESTful Web APIs overshadowed WCF. And perhaps WF killed itself by its poor performance, it had no chance of survival when compared to shiny Service Bus implementations out there (namely NServiceBus).

To summaries, WCF and REST belong to two completely different philosophies. While RPC (hence WCF) relies on stringent interface definition, REST embraces discovery of possibilities through hypermedia and content negotiation. RPC restricts change while REST assumes intelligent clients able to react to changes. WCF relies on careful interface definition through WSDL while RESTful HTTP only provides OPTIONS verb to define high level of what is possible. As such, I for one believe RESTful WCF is just an oxymoron!

If you have to choose between REST and WCF, here are a few things you need to consider:

  1. Ease of client coding: WCF client code can be auto-generated by using the WSDL. On the other hand, REST has a client burden in such a way that REST client have to fully understand and respect HTTP  (WCF: 1 - REST: 0)
  2. Client device support: This is where REST shines. You can invoke REST from your browser using Javascript.  (WCF: 0 - REST: 1)
  3. WS* Support: WCF has done a lot of work to fully support WS* protocols. In an enterprise, this can be imporant  (WCF: 1 - REST: 0)
  4. Federated security (OAuth, OpenID, etc): REST and WCF both support them although REST is more aligned for it (WCF: 1 - REST: 1)
  5. Better decoupled implementation: REST scores much higher on that as long as both client and server respect HTTP  (WCF: 0 - REST: 1)
  6. Better use of HTTP features (such as caching): REST scores so much higher. WCF/SOAP always uses POST which is neither Idempotent nor safe while this can be implemented in REST using all varieties of verbs.  (WCF: 0 - REST: 1) 
  7. Supporting various formats: REST can implement content negotiation while WCF mainly uses XML  (WCF: 0 - REST: 1)
One-liner: For a new API, I would definitely choose Web API. For an existing WCF implementation, I would not immediately jump to migrate to Web API. In enterprise, WCF might in fact be a more suitable option.


WCF Web API

Microsoft put Glenn Block, the MEF dealer, in charge of a new project to turn WCF REST into something sensible. As Glenn himself clarified, WCF Web API was an HTTP-friendly (rather than claiming to be RESTful) implementation exposing a lot of the HTTP goodness with little compromise.

One of the main changes was ability to define RPC interfaces as HttpRequest<T> and HttpResponse<T>, allowing transport specific context of HTTP to be accessible within the method.

Now the reason that WCF Web API was later renamed into ASP.NET Web API was perhaps more to do with the political milieu of the Microsoft at the time where WCF teams were integrated into ASP.NET team. As we will later see, a journey that started with WCF REST with WCF gradually moving towards ASP.NET MVC, it has been almost complete now with the new Web API sharing not only routing and HTTP verb definition, but also concepts such as controller. They are so similar that one wonders why on earth we have to have both.

Sunday 25 March 2012

Dependency Injection for Singletons

[Level T2]

This is more of a hypothetical and perhaps philosophical question, but anyway I will shoot:
Now that most DI frameworks support singleton lifetime would you still manually implement the Singleton pattern?
I have seen a lot people answering NO to the question. They believe that the decision to use a singleton pattern can change and changing the lifetime of the object is just change in one line of code or configuration.

But I would answer YES.

Reality is, the reason to use Singleton pattern is usually:

  • Creating the object is expensive
  • Object uses (and commonly caches) data that are expensive to create
  • Object has to collect and keep some state/statistics
Which of above is likely to change over time? I would say practically none. When relying on DI frameworks to do the singleton pattern for you, your class loses its design coherency when it does not communicate its need to be implemented as singleton.


So I personally would implement the Singleton pattern and then register the instance (this is Windsor):

UniversalContainer.Container.Register(
    Component.For<IXsltTransformer>()
    .Instance(XsltTransformerWithCaching.Current)); // .Current is the singleton instance 

As it can be seen, the class XsltTransformerWithCaching is responsible for performing XSLT or XML documents. As we all know, XSLT processor in C# spits out the code for the transformation and builds an assembly at runtime (similar to Serialisation) and if done over and over again, it can cause "memory leaks". As we all know, once an assembly is loaded, it cannot be unloaded - and do not ask for it, it cannot be done.

So I would prefer to bake the singleton into the class.

Friday 23 March 2012

Post level description

For providing better information to help you decide whether a post can be useful to you, posts of this blog have been categorised to 9 levels. Before doing that, let's explain a few terms, since I am using them differently:

  • Platform: here it refers to code platform such as .NET, JVM, Ruby-On-Rails, node.js ... most posts of my blog are .NET (platform-dependent). Note that platform does not necessarily refer to programming language. I regard Javascript as platform-independent.
  • Framework: Refers to big frameworks of a platform. For example ASP.NET MVC or ASP.NET Web API
  • Micro-framework: Refers to smaller frameworks built on the top of a framework. For example CacheCow

Now here is what each category mean
  • Technical T1-4: these posts are technical and involves showing/reviewing code. Platform-dependent unless Javascript.
    • T1: As long as you are familiar with the platform, you should find the post useful (unless poorly written!) - so no priory knowledge of framework
    • T2: Normally an introduction to a Micro-framework or a explaining a feature of a framework
    • T3: Advanced or edge-case discussion of a feature in a platform, framework or micro-framework
    • T4: In-depth discussion of a framework or micro-framework. Most useful for those interested in extending frameworks or under the hood knowledge
  • Conceptual C1-4: platform-independent architectural or software-design talks such as REST, TDD, Agile... 
    • C1: Introduction to a concept. No priori knowledge required
    • C2: Explanation of a concept
    • C3: In-depth discussion and exploration of a concept
    • C4: An op-ed on a concept  - often controversial encouraging discussion
  • None:
    • N: a post on non-tech related stuff

Thursday 22 March 2012

Moved the technical blog

I have decided to move my technical posts here. Although I did not have many technical posts, I will gradually move them and keep the "The one who got away" purely for art/faith related posts.

I am starting out with ASP.NET Web API.