Indigo services are self-contained. That is, Indigo doesn’t define a specific application model that governs the type of applications that can host Indigo services. Instead, we support a couple of broad classes of hosting scenarios and let developers choose the hosting model that’s right for their particular application.

Self-Hosted Services (a.k.a “Bring your own app domain”)

You can host Indigo services in any AppDomain where you can create an instance of ServiceHost<T> — that is to say, pretty much anywhere. This enables some interesting scenarios:

• Console applications. Probably not how you’d like to deploy your services in production apps, but it’s really handy for development. Console applications are easy to debug, and you can write out lots of trace information to the console window to easily see what’s going on inside you application.
• Avalon/WinForms applications. This model makes it easy for your rich client applications to communicate with the outside world. For example, you can imagine a peer-to-peer collaboration client that used Avalon for its UI and hosted an Indigo service that allowed other clients to connect to it and share information.
• NT Services. This is a server-side scenario where the AppDomain that hosts Indigo services is registered as a managed NT Service, with process lifetime being controlled by the SCM. This is one way of hosting long-running Indigo services in a server environment, although we have others.

Web-hosted Services (a.k.a. Living in IIS today)

On today’s operating systems, (XP/2k3), the preferred solution for highly available, highly scalable service hosting is IIS. IIS offers the integrated managability and scalability that customers expect from an enterprise-class server product. However, the IIS feature set is closely tied to HTTP scenarios, which introduces some caveats. Here’s how this shakes out:

• IIS 5.1 on Windows XP. Provides message-based activation for Indigo services over HTTP using the IIS 5.1 process model. In this case, IIS5.1 owns HTTP traffic on port 80 – other self-hosted Indigo services on the same box cannot use port 80 to communicate.
• IIS 6.0 on Windows Server 2003. Provides message-based activation for Indigo services over HTTP and uses the IIS 6 process model. Indigo services can run in the same AppDomain/Application Pool/Worker Process as other applications hosted by IIS6. Because Indigo and IIS6 both use the kernel-mode HTTP stack (HTTP.sys), IIS6 can share port 80 with other self-hosted Indigo services running on the same machine.

WAS-hosted services (a.k.a. Living with IIS tomorrow)

WAS (Windows Activation Services) are new in Longhorn. IIS 7 will use Windows Activation Services to accomplish message-based activation over HTTP. There will be additional Indigo components that plug into WAS to provide message-based activation over the other protocols that Indigo supports (TCP and Named Pipes). Because this is a Longhorn feature, there’s not much that I can say about it at this point. However that will certainly change as we get closer and closer to Longhorn’s ship date.

Questions, comments, and feedback on the hosting models I’ve laid out here are certainly appreciated.