The IIS 7.0 lab was wrapped up with a look at the Windows Activation Service (WAS) and an introduction to Indigo and how the 2 work together. Essentially, Indigo is able to be hosted by anything that can act as a service host. This includes not only IIS, but also Windows Services, Enterprise Services, or even an EXE.

I had never heard of WAS until this week. I believe it is something that every IIS administrator and developer should understand the basics of. I will attempt to summarize here without too many technicalities. (I will mess it up if I try to be too specific) With IIS 7.0 the W3SVC that handles http (remember this is just a communication protocol) has been separated from the service which manages configuration and process management. The separate service is WAS. W3SVC in IIS 7.0 has a dependency on WAS, but WAS has no dependencies on W3SVC. What this means is that IIS should no longer be thought of as a "web" server. We already see it hosting services such as remoting, so keep that in mind as you look at how IIS is improving as a first class service host. I'd like to propose that we consider IIS 7.0 as THE service host. Of course those who need transaction support will still want to remain friends with Enterprise Services. I am starting to wonder if the best way to understand IIS 7.0 is to first look at WAS and then look at W3SVC as just another in the line of services that can be activated on demand by a service host.

In addition to loading configuration, WAS is a manager. Like all good managers it tells its servants, or in this case services, when to start and stop, and which cubicles (application pools) they are to function in. In the case of a request coming in on the http binding WAS starts up a W3WP just as IIS 6.0 does today. If there is already a running W3WP servicing the appropriate application pool then WAS can skip the starting up of a new one. Today IIS 6.0 gives us some very powerful health monitoring that allows us to recycle worker process or kill application pools in which failing code is running. This same concept moves forward in IIS 7.0, and is now able to be applied to any process WAS is managing. This may be W3WP for a web application or it may be the Indigo Net TCP service. Given the power of worker process management and the failure protections we see in IIS 6.0 now, combined with the modular architecture of IIS 7.0, I nominate IIS 7.0 WAS as the process host of choice for Indigo. You know I really should dig deeper to see if WAS can replace Enterprise Services for executing managed code and providing transactional support. Comments anyone? The combination of .NET garbage collection and WAS worker process management makes me wonder why anyone would want to write code managed outside of IIS and .NET for distributed applications.

Let me go a bit deeper into some of the advantages of WAS as an Indigo host and W3WP service manager. ASP.NET developers are familiar with the concept of application domains. These act essentially like process boundaries. Within an application domain things like state and session can be shared. Across application domains this requires cross domain calls, security checks, etc. By hosting Indigo services in IIS they are able to participate fully in the same application domains that ASP.NET applications participate in. A single application can for example expose its state and services through a standard browser application, a web service, and now Indigo services and others. The ability to support service oriented architectures really comes to life when every system that wants to connect to a given service can participate in the same process and application boundary. Thomas Deml demonstrated a very simple example of an Winforms application using an Indigo service hosted in IIS. The service was able to return a list of all active requests in an application domain. The Indigo service showed up right alongside the http services being requested and handled in the same process. It was clear that an http and a standard tcp request were both being handled within the same application domain.

A few more pieces of goodness that I took away from this mornings presentation:

• state, globalization, membership and roles all can be shared by Indigo applications in addition to ASP.NET applications.
• Unified deployment model (Indigo services are complied on the fly like asp.net)
• new listeners along side http: Indigo Net.TCP Listener, Indigo Net.Pipe Listener, MSMQ Listener
• WAS has a listener adapter interface for extensibility
• IIS 6.0 rapid fail protection and other IIS 6.0 recycling features now extended to all WAS hosted services
• Indigo destined to run on XP and 2003