Estendendo a hospedagem usando ServiceHostFactory

A API padrão ServiceHost para serviços de hospedagem no Windows Communication Foundation (WCF) é um ponto de extensibilidade na arquitetura WCF. Os utilizadores podem derivar as suas próprias classes de host de ServiceHost, geralmente para sobrescrever OnOpening() para usar ServiceDescription para adicionar pontos de extremidade padrão imperativamente ou modificar comportamentos, antes de abrir o serviço.

No ambiente de auto-hospedagem, você não precisa criar um personalizado ServiceHost porque escreve o código que instancia o host e, em seguida, chama o Open() depois de instanciá-lo. Entre esses dois passos você pode fazer o que quiser. Pode, por exemplo, adicionar um novo IServiceBehavior:

public static void Main()  
{  
   ServiceHost host = new ServiceHost( typeof( MyService ) );  
   host.Description.Add( new MyServiceBehavior() );  
   host.Open();  
  
   ...  
}  

Esta abordagem não é reutilizável. O código que manipula a descrição é codificado no programa host (neste caso, a função Main(), por isso é difícil reutilizar essa lógica em outros contextos. Há também outras maneiras de adicionar um IServiceBehavior que não exigem código imperativo. Você pode derivar um atributo de ServiceBehaviorAttribute e colocá-lo no tipo de implementação do seu serviço, ou pode tornar um comportamento personalizado configurável e compô-lo de forma dinâmica usando a configuração.

No entanto, uma pequena variação do exemplo também pode ser usada para resolver este problema. Uma abordagem é mover o código que adiciona o ServiceBehavior de Main() e para o método OnOpening de um derivado personalizado de ServiceHost:

public class DerivedHost : ServiceHost  
{  
   public DerivedHost( Type t, params Uri baseAddresses ) :  
      base( t, baseAddresses ) {}  
  
   public override void OnOpening()  
   {  
  this.Description.Add( new MyServiceBehavior() );  
   }  
}  

Então, dentro de Main() você pode usar:

public static void Main()  
{  
   ServiceHost host = new DerivedHost( typeof( MyService ) );  
   host.Open();  
  
   ...  
}  

Agora você encapsula a lógica personalizada em uma abstração limpa que pode ser facilmente reutilizada em muitos executáveis de host diferentes.

Não é imediatamente óbvio como usar esta personalização ServiceHost de dentro dos Serviços de Informações da Internet (IIS) ou do Serviço de Ativação de Processos do Windows (WAS). Esses ambientes são diferentes do ambiente de auto-host, porque o ambiente de hospedagem é aquele que instancia o ServiceHost em nome do aplicativo. A infraestrutura de hospedagem do IIS e do WAS não sabe nada sobre seu derivado personalizado ServiceHost .

O ServiceHostFactory foi projetado para resolver este problema de aceder ao seu ServiceHost personalizado dentro do IIS ou WAS. Como um host personalizado que é derivado de ServiceHost é configurado dinamicamente e potencialmente de vários tipos, o ambiente de hospedagem nunca o instancia diretamente. Em vez disso, o WCF usa um padrão de fábrica para fornecer uma camada de indireção entre o ambiente de hospedagem e o tipo concreto do serviço. A menos que você diga o contrário, ele usa uma implementação padrão de ServiceHostFactory que retorna uma instância de ServiceHost. Mas também pode disponibilizar a sua própria fábrica que retorna o seu host derivado, especificando o nome do tipo CLR da sua implementação de fábrica na diretiva @ServiceHost.

A intenção é que, para casos básicos, implementar sua própria fábrica seja um exercício simples. Por exemplo, aqui está um ServiceHostFactory personalizado que retorna um ServiceHost derivado:

public class DerivedFactory : ServiceHostFactory  
{  
   public override ServiceHost CreateServiceHost( Type t, Uri[] baseAddresses )  
   {  
      return new DerivedHost( t, baseAddresses )  
   }  
}  

Para usar essa fábrica em vez da fábrica padrão, forneça o nome do tipo na diretiva @ServiceHost da seguinte maneira:

<% @ServiceHost Factory="DerivedFactory" Service="MyService" %>

Embora não haja limite técnico para fazer o que desejar com o ServiceHost que você retorna de CreateServiceHost, sugerimos que mantenha suas implementações de fábrica o mais simples possível. Se você tiver muita lógica personalizada, é melhor colocar essa lógica dentro do seu host em vez de dentro da fábrica para que ela possa ser reutilizável.

Há mais uma camada para a API de hospedagem que deve ser mencionada aqui. WCF também tem ServiceHostBase e ServiceHostFactoryBase, a partir do qual ServiceHost e ServiceHostFactory respectivamente derivam. Esses existem para cenários mais avançados, onde você deve trocar grandes partes do sistema de metadados por suas próprias criações personalizadas.