Martin Parry from Microsoft’s Developer and platform group presented the upcoming server version of IIS 7 last week in Reading. The new version has some really interesting features that will make life easier for developers.
A client server?
It is a bit strange for a product that has the word “services” in its name to have a client version, but basically the “client” variant of the Internet Information Services was released with Vista, and “server” will come with Windows Server 2008, hopefully later this year. The “server” version is presently available as a release candidate, and can be downloaded with WS2008. Martin did not go into much detail about the differences of those two versions, but he said that the client has limited functionality and throughput. The good news is that the limitation of a single web site, that bugged web developers on Windows XP with IIS 6, is now removed.
As the demonstration switched from Vista to a virtual WS2008 server to show the new management console and diagnostics features, I can only suppose that such features are not yet integrated into the “client” version.
What was before w3svc is now split into two services. W3svc still exists, but it only deals with the HTTP kernel driver. The rest is in in the Windows Process Activation Service (codename WAS), which is further modularised into the Configuration manager, Process manager and Listener adapter interface. The responsibilities of the first two modules are pretty clear from their names, but the third module is a real novelty. It uses the Windows Communication Framework to allow plugging various listeners into the pipeline, so that requests can come across HTTP, but also raw TCP, named pipes or MSMQ message queues.
When the request comes in, it is sent through the request pipeline. This is where the biggest difference from IIS 6 comes into play — a modular architecture of the request pipeline. It looks like IIS7 is completely rewritten in .NET, because it enables developers to replace any part of the request pipeline with a custom module, written either in .NET or native code. Although .NET HTTP modules were supported in IIS6, the request had to come under the ASP.NET domain to use such flexibility, and you could not really replace standard functionality for authentication or logging or inject something into the pipeline without writing an ISAPI extension. Now, ASP.NET HTTP modules are truly utilised to the full extent. If you want, you can remove any standard module and replace it with your own, and do all that in .NET.
This gets even better — if you write a module in .NET, it does not have to be globally active or installed for the whole server. It can be loaded from web.config in a web application folder, so no special administrative privileges are required to change the pipeline.
Native modules and ISAPI extensions are still supported, but they have to be registered on the server level and have to be defined globally. You can, however, prevent the worker process from loading them for your application.
One more good thing about this is that the standard pipeline is now broken down into a number of DLLs, and you can actually prevent the system from loading any one of them. With IIS6, they were all in three big DLLs and loaded by default. Excluding modules that are not required will help lock down the server better, so this is a good security feature.
No more metabase
Another nice new feature of IIS 7 is that the configuration is now truly modularised. The big metabase is gone — and is now replaced with a system-wide text file called applicationHost.config (the IIS equivalend of machine.config) and web-site or folder local configuration in web.config files. The good news is that web.config can now override any setting. That includes modules, as I’ve already mentioned, but also error handlers, MIME mappings and all the other stuff that had to be edited in the metabase earlier.
The new administration console supports “delegation” — giving privileges to administer parts of the site or certain options to individual users. This works even with HTTP authentication of non-windows users, so you no longer have to open a local system or domain account for individual web site administrators. Any activity can be marked as not delegated, read-only or read/write for a particular user, and the user’s view is trimmed according to permissions. The console can even work remotely over HTTPS. All these improvements should appeal to people using shared hosting services or maintaining a large number of web sites.
IIS7 comes with something called “runtime status and control API” which allows developers to programmatically access diagnostic information about the running server. Lots of information on application pools and active requests should be available via this API, and it is also accessible within the IIS admin tool. Martin showed a demo of that tool, quickly displaying all active requests, their details and information on worker processes. The console even displays the module that is currently executing the request, which will be great for troubleshooting.
For better problem-solving, IIS7 also supports “failed requests tracing” (codename FREB). That basically comes down to dumping lots of tracing information into files only if certain conditions are met, such as status code, timeout or a generated trace event of a specific severity. The XML result contains the whole pipeline, duration of every executed step in milliseconds, exception information and a lot more. This feature does have performance implications (as tracing is buffered for all requests, and then only flushed if the trigger condition is met), and has to be enabled on the web site level. So I guess that it should not be used for general alerting, but only turned on when a serious problem is being looked at.
IIS7 seems like a nice idea, especially the modularised pipeline, and I see how it could help us do our work faster. I’d like to see the production version and its performance before passing final judgement, but the demo really looked prommissing.
One thing that is notably missing, at least in my opinion, is the ability to run services that are not request-based. For more complex background processing, IIS7 still requires a windows service and the web application will have to use IPC to talk to it. Microsoft PR seems to have moved from the claim that IIS is an application server, with IIS 7 now presented as a “web application server” rather than an “application server” as was IIS6, so it does not seem likely that we will soon get the option to start a background service and chat with it from the web layer without the overhead of IPC and switching from managed mode.
For more information on the upcoming release, see Microsoft’s new IIS portal, IIS.NET.
Image credits: Karl-Erik Bennion