Last time around I talked about how the ServiceHostFactory API allows you to use custom derivatives of System.ServiceModel.ServiceHost with the WCF hosting infrastructure that runs in IIS/WAS.

If you've been poking around the System.ServiceModel.Activation OM, you might have noticed that we actually have two service-host-factory-ish classes. Specifically, we have System.ServiceModel.Activation.ServiceHostFactory (which was that subject of my last post), as well as its more mysterious abstract base class System.ServiceModel.Activation.ServiceHostFactoryBase (which has yet to be mentioned at all).

You might have also noticed that the ServiceHost API follows a parallel class structure -- we have System.ServiceModel.ServiceHost that derives from the abstract System.ServiceModel.ServiceHostBase parent class. The similarity in names between ServiceHostBase and ServiceHostFactoryBase is intentional.

The model is that you derive from ServiceHostFactoryBase directly if you're trying to use a custom host that derives directly from ServiceHostBase. If your custom service host instead derives from ServiceHost, you write a factory that derives from ServiceHostFactory.

The spit between ServiceHost and ServiceHostBase is somewhat beyond the scope of this post, although I will say that you can think of ServiceHostBase as an abstract version of ServiceHost that has all the major pieces defined on it but the logic for constructing those pieces is intended to be supplied by derivative classes (i.e. ServiceHostBase builds its runtime via a GOF TemplateMethod pattern). For example, ServiceHostBase has a ServiceDescription, but the logic for building that description is left undefined. This allows something like ServiceHost to come along and implement logic that builds a ServiceDescription by reflecting over a CLR type looking for [ServiceContract]/[OperationContract] attirbutes. People who want to build other programming models on top of our core runtime functionality can implement different ways of building a ServiceDescription based on whatever metadata store they want. This feature is very handy for people who are building more dynamic programming models that aren't completely centered around modeling services as CLR types that wear special metadata.

Deriving your own ServiceHostBase is a pretty advanced scenario and we expect that the number of people who do this on a regular basis will be relatively small. But it's one of those things where it's nice to know that the possibility exists even if you don't use it on a regular basis.

Since the major purpose of ServiceHostBase is to decouple the runtime from CLR types as the metadata source for telling us how to construct that runtime, it follows that the API for ServiceHostFactoryBase would not be defined in terms of System.Type. And, if you look at the API projection of ServiceHostFactoryBase you'll see that it's not:

namespace System.ServiceModel.Activation
{
   public abstract class ServiceHostFactoryBase
   {
      public abstract ServiceHostBase CreateServiceHost( string constructorString,
                                                         Uri[] baseAddresses ); 
   }
}

ServiceHostFactoryBase takes two parameters:

• string constructorString, which is an opaque string that provides initialization data to the Factory/Host. The semantics of constructorString are similar in spirit to the IObjectConstruct pattern from COM+.
• Uri[] baseAddresses. These URI's are provided by the hosting environment (IIS/WAS/ASP.NET) based on the hosting application's configuration. When WCF is hosted in IIS, the base addresses of the services we host there are constrained by the hosting environment. Those base addresses get passed from the hosting environment to the service via this Uri[].

The contents of constructorString are provided via the Service attribute in the .svc file. There are no restrictions on the contents or format of this string -- it's up to the individual factory implementation to define the semantics of this string as it relates to that specific Factory/Host implementation. For example, ServiceHostFactory (the default) treats this string as the CLR type name of the service implementation type. Here's a simplified implementation of the logic in SerivceHostFactory that illustrates how this ties together:

namespace System.ServiceModel.Activation
{
   public class ServiceHostFactory : ServiceHostFactoryBase
   {
      public override sealed ServiceHostBase CreateServiceHost( string constructorString,
                                                                Uri[] baseAddresses )
      {

          Type serviceType = Type.GetType( constructorString );
          return CreateServiceHost( serviceType, baseAddresses );   
      }

      protected virtual ServiceHost CreateServiceHost( Type serviceType, Uri[] baseAddresses )
      {
          return new ServiceHost( serviceType, baseAddresses );
      }
   }
}

So in summary:

• ServiceHostBase is a ServiceHost that doesn't depend on having a CLR type around in order to build a ServiceDescription.
• ServiceHostFactoryBase creates ServiceHostBases from an opaque string passed in through the Service attribute in the @ServiceHost directive.
• We ship a default factory called ServiceHostFactory that interprets the constructor string as a CLR type name and uses that to create new instances of ServiceHost.
• If you want to use a different subtype of ServiceHost, write your own factory that derives from ServiceHostFactory.
• If you want to interpret that contents of the Service directive as something other than a CLR type name, you can derive from ServiceHostFactoryBase and parse that string in whatever way you want.

The last bullet opens up some really interesting possibilities :)