Foreword on Reporting Services Katmai "Rehosting"

The upcoming major release of SQL Server Reporting Services (or RS) brings about many changes. If you had played with a CTP version, you will undoubtedly notice significant changes to the way RS is configured. You would probably be surprised to find that IIS is no longer required. In fact, most of the configuration changes are the result of removing the IIS dependency.

This is a very interesting area that comes with many questions and challenges. First of all, why we did it? Initially the motivation was to reduce configuration complexity. IIS management involves a set of tools (UI, metabase, ADSI and WMI). IIS7 is a totally different beast. Hosting a web service like RS require much less than what IIS can offer. Second, an administrator may not want IIS on the server. One may argue that in terms of attack surface, hosting a web service in another process is just as bad as hosting it in IIS, since they require the same port to be open to public. This is true to some degree. Without getting into the details, it can be said that Katmai RS can choose to listen on a more restrictive set of urls, thereby reducing surface area.

Writing a hosting process for RS presented a universe of opportunities for better memory/resource management and better scheduling algorithm. Thanks to the support from SQL server engine folks, RS now fully embrace the SQL OS infrastructure, including SQL CLR and SNI (SQL Networking Interface). This is where the "rehosted" solution really shines. Although RS doesn't currently take full advantage of SQL OS, it is the right path for a server process to follow.

I will end the preamble here. I hope to find enough time to go into the specifics of rehosting. If there are particular areas that are of interest to you, feel free to leave me a note.