IIS is well known to most developers, particularly .NET developers, so not much needs to be said by way of introduction. Suffice it to say that many organizations will already have an IIS instance running, there will probably be personnel dedicated to its maintenance, and most developers have already used it extensively.
IIS is already integrated with ASP.NET. As such, it has out-of-the-box support for many useful features such as isolation of application pools, process recycling, idle shutdown, and process health monitoring. It also enables message-based activation. If your application needs to have high availability and be scalable, IIS is an ideal choice. IIS can easily be clustered. It can be hosted behind a firewall. It can be run behind a load balancer. By nature, it’s well suited to processing high request volumes.
Although it is also a strength, IIS has been targeted to many attacks in the past because of publicized security flaws. Its prevalence makes it an attractive attack target for many hackers. But the costs here are more than offset by the benefits provided precisely by its popularity. Most importantly though, IIS limits the bindings you can use and support. IIS only supports message transport via HTTP. As you might recall from the discussion on bindings, the http-based binding set is easy to use, but it’s also quite limiting, and because you can use only HTTP, it makes this option unusable for many.
Refrence : Developing Windows Azure and Web Services Exam Ref 70-487
