This post originated from an RSS feed registered with .NET Buzz by Christian Weyer. Original Post: The future of service hosting - or: is Indigo a managed COM+? Feed Title: Christian Weyer: Web Services & .NET Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/cweyer/Rss.aspx Feed Description: Philosophizing about and criticizing the brave new world ... Latest .NET Buzz Posts Latest .NET Buzz Posts by Christian Weyer Latest Posts From Christian Weyer: Web Services & .NET

Now, everybody is talking about this S ... O ... A ... thingie - and I mean: everybody. There are at least as many opinions about those three letters out there as bloggers are.
And then there are quite a handful of very interesting blogs that talk about Indigoand what it will enable in the future. Reliably transmitting messages, all facets of security, policy-enabled and policy-driven communication - you name it.

But hey, you know which question I hear most re: Indigo? "Is it finally a managed COM+?" Ha. Well, my standard answer is "Yes, sort of - but no, sort of not - it depends." You cannot compare COM+/Enterprise Services directly and 1-to-1 with Indigo. Managed code programmers will find Indigo useful for many of the scenarios that COM+ is currently useful for, yes. We need to take a look at what is unmanaged when talking about COM+.
The first piece that comes into everbody's mind when working with COM+ is its host process. In COM+ (and therefore also when you are leveraging its functionality through Enterprise Services in .NET) your apps are hosted within a very well-known process called dllhost.exe. It is an unmanaged Win32 application existing for quite a long time now. It is this process that gets spawned whenever you are activating an object in a COM+ application (server application). Activating - aha. We - sorry, COM+ - bring objects to life by activating them through method calls (simplified view here). This is the model we are used to since MTS in 1996/1997 - it worked but it was never prepared and ready for the new wave of service orientation, obviously.

Now we enter the next phase. Think about a feature that *Web* applications (such as ASP.NET apps) and services (OK, call them *Web* services) have in common ... ? If we abstract unnecessary details away, they both are communicating via messages (HTML vs. XML) and the applications usually get activated by messages. So why don't we rely on an activation model that relies itself on messages? This is where the new WebHost model comes around. WebHost was first mentioned publicily (at least as far as I can remember) in the latest .NET Show episode. Steve Swartz talked a bit about it (beware: they printed it is as 'web host').

WebHost is a unified model for hosting Web applications and services. It is a joint project of the ASP.NET and Indigo teams. Additionally, IIS is providing the operating system infrastructure to activate, monitor and manage worker processes within which ASP.NET applications and Indigo services run. Some of the features of IIS are extended to support multiple protocols, not only HTTP. For example, an Indigo listener service can queue incoming TCP over SOAP messages, and register with IIS to activate a worker process with a protocol handler for those messages. An early version of this can already be seen and tested in the current PDC release of Longhorn.
The WebHost model enables message-activated Indigo services by building on and leveraging existing technologies like the IIS metabase and process model (health monitoring, recycling, demand start, idle timeout). At the application level, the same application domain can host one ASP.NET application and multiple Indigo web services.
In other words, WebHost tries to take general features such as IIS's process activation and change them such that they aren't tied to transport
protocols anymore. The scope of WebHost is primarily focused on application development scenarios for developers that need to use Indigo services in a scalable,
reliable, fault-tolerant environment as commonly known in Web server-based scenarios.

To make sure: WebHost is not meant to displace dllhost.exe. WebHost is meant to support ASP.NET, IIS, and Indigo. As already mentioned above, programmers working with .NET and WinFX in future will find Indigo useful for many of the scenarios that COM+ is currently useful for. When they decide to use Indigo instead of COM+, they should find that WebHost implements all the features that dllhost.exe used to implement. WebHost is the name for a beast that might have the same scope as rpcss.exe and dllhost.exe together. See it as a bit of transport stuff, a bit of protocol stuff and a bit of activation stuff. That's maybe the best analogy in terms of scope.

WebHost is an ongoing project. Bits and pieces of its functionality will be released with every major release to come. So some bits of it will come with Whidbey, other bits with Indigo, other bits with Longhorn. Stay tuned.