As the PM for hosting and activation on Indigo, I basically own the process model for Windows Communication Foundation services. One of the things that makes my job interesting is that WCF does not, by itself, actually define a particular process model. So I end up spending most of my time thinking about all the various places in which you can run Indigo services. Of the three options (app hosting, managed Windows services, and IIS/WAS), the latter is by far the most interesting, and I intend write in some depth about it here over the coming weeks.
What is WAS, you ask? Put really simply, WAS enables the IIS process model without imposing a dependency on HTTP. I plan on spending several posts here explaining just exactly what that means J
But before I get into WAS though, I thought I’d start with a quick recap of how IIS 6 organizes the world.
The core unit of addressing and management inside of IIS 6 is the application, which (for the purposes of this discussion at least) can be considered to be a chunk of code whose lifetime and execution environment are managed by the server. A single server instance can be home to many different applications; sets of applications are organized into groups called sites. Within a site, applications are structured hierarchically in a manner that reflects their external address URIs. Each site has a site binding, which is used to construct the base URI prefix for all the applications under the site. Application addresses are then constructed by taking app-specific path fragments (like “/myapp”) and gluing them onto the base URI prefix (e.g. “http://localhost:80”) to come up with the full URI to the application (e.g. http://localhost/myapp).
Applications are organized into sites for the purposes of addressing and management. At runtime, applications are grouped together into application pools. An application pool can house many different applications from many different sites. All applications inside an app pool share a common set of runtime characteristics – for example, they all run under the same version of the CLR and share a common process identity. This is because each application pool roughly corresponds to an instance of a worker process (w3wp.exe). I say ‘roughly’ here because there might actually be multiple instances of the worker process associated with the app pool if you’re running on a multi-proc box with web gardening enabled. In those cases, IIS spins up a separate instance of w3wp.exe for each processor, but the general principle remains the same. Each application running in the pool gets its own app domain inside the running worker.
In short, each concept in the IIS model exists to partition the world in various ways:
- Sites: URI space partitioning
- Application Pools: worker process partitioning
- Applications: AppDomain partitioning inside a worker process
The reason I’m spending so much time blathering on about these IIS 6 concepts in a post that’s supposed to be about WAS is simply because WAS retains the same general organization model as IIS 6. In future posts, you’ll see me talking a lot about site bindings, applications, and app pools and I wanted to get a crisp definition of these terms out on the table before I got too deep into WAS-isms.
