Exportar (0) Imprimir
Expandir Tudo

Hospedar serviços WCF com pontos de extremidade do Service Bus no IIS

Atualizado: janeiro de 2014

Autores: Santosh Chandwani

Revisor: Seth Manheim

Este tópico descreve como hospedar serviços WCF com pontos de extremidade do Microsoft Azure Service Bus nos Serviços de Informações da Internet (IIS) versão 7.5, incluso no Windows Server 2008 R2 e no Windows 7. O Microsoft Azure Service Bus fornece recursos de conectividade e mensagens exigidos por aplicativos executando a plataforma no ou em cenários híbridos. Este tópico se concentra nas etapas necessárias para hospedar serviços que foram desenvolvidos usando o SDK do 1.5 ou posterior, em IIS.

O Microsoft Azure Service Bus fornece uma infraestrutura hospedada, segura e amplamente disponível para comunicação generalizada, distribuição de evento em grande escala, nomeação e publicação de serviços. O Service Bus fornece opções de conectividade para WCF e outros pontos de extremidade, incluindo os pontos de extremidade REST, que seriam difíceis ou impossíveis de serem atingidos. Os pontos de extremidade podem ser localizados atrás dos limites de conversão de endereços de rede (NAT), associados a endereços IP atribuídos dinamicamente ou alterados com frequência, ou ambos.

O Service Bus fornece recursos de mensagens "retransmitidas" e "orientadas". No padrão de mensagens retransmitidas, o serviço de retransmissão oferece suporte a mensagens unidirecionais diretas, mensagens de solicitação/resposta, mensagens full duplex e mensagens ponto a ponto. As mensagens orientadas fornecem componentes de mensagens assíncronos e duráveis, como filas, tópicos e assinaturas, com recursos que oferecem suporte a desacoplamento temporal e publicação/assinatura: remetentes e destinatários não precisam estar online ao mesmo tempo; a infraestrutura de mensagens armazena mensagens de maneira confiável até que o destinatário esteja pronto para recebê-las. Estes padrões são importantes para aplicativos que estejam migrando para a plataforma .

As ferramentas do Service Bus inclusas com o SDK do simplificam a integração de aplicativos .NET locais com o serviço. O SDK fornece integração perfeita com o Windows Communication Foundation (WCF) e outras tecnologias da Microsoft para aproveitar ao máximo os conjuntos de habilidades existentes do desenvolvedor. O SDK do Service Bus inclui associações do Service Bus para diversas associações de retransmissão HTTP e net.TCP, e uma associação de mensagens para mensagens orientadas. Encontre a lista completa de associações de "retransmissão" do Service Bus em Associações do Service Bus e a associação de mensagens em NetMessagingBinding.

Apesar desses serviços terem sido desenvolvidos para fornecer uma experiência .NET de primeira classe ao desenvolvedor, é importante observar que cada um deles fornece interfaces baseadas em protocolos padrão do setor, possibilitando que os aplicativos que executem qualquer plataforma seja integrado a elas via protocolos REST, SOAP ou WS-*. Também há SDKs do Service Bus para Java e Ruby disponíveis para download aqui.

O principal desafio em hospedar um serviço WCF usando associações do Service Bus em IIS está relacionado à ativação. Por padrão, o IIS inicializa um aplicativo da Web quando a primeira solicitação é recebida.

No entanto, para o serviço WCF local com uma associação de retransmissão do Service Bus para começar a receber mensagens do Service Bus na nuvem, o serviço local precisa abrir uma porta de saída e criar um soquete bidirecional para comunicação. Ele se conecta ao Service Bus, autentica-se e começa a escutar mensagens antes que o cliente envie solicitações. O serviço de retransmissão envia mensagens para o serviço local através do soquete bidirecional já instalado.

Da mesma maneira, uma associação de “mensagens” fornece uma bomba automática de mensagens que puxa mensagens de uma fila ou assinatura, e é integrada ao mecanismos ReceiveContext do WCF. Esta associação também precisa iniciar uma conexão de saída para o Service Bus na nuvem, bem como autenticar-se antes que a bomba de mensagens seja ativada.

Já que o IIS e o Windows Activation Service (WAS) dependem da ativação baseada em mensagens, por padrão os aplicativos da Web hospedados em IIS/WAS são inicializados somente após a primeira solicitação chegar. Portanto, a ativação comum baseada em mensagens de IIS/WAS não funciona para serviços WCF com associações do Service Bus, pois tais associações devem primeiro estabelecer uma conexão de saída para o serviço a fim de receber mensagens. Este requisito significa que, quando hospedados em IIS, tais serviços WCF devem ser explicitamente inicializados, ou eles precisam de mecanismos alternativos para inicializar o aplicativo automaticamente. Este tópico descreve dois métodos para inicializar o aplicativo automaticamente usando o mecanismos Auto-Start do ASP.NET e o recurso Auto-Start do Microsoft AppFabric. Como alternativa, é possível usar um serviço NT como host.

As associações do Service Bus que utilizam o HTTP não são integradas com os pipelines HTTP gerenciados/não gerenciados. Logo, a compatibilidade do ASP.NET possui defeitos e certos cenários, como compartilhar o estado da sessão entre o serviço e um aplicativo do ASP.NET hospedado no mesmo domínio do aplicativo, não funciona para serviços WCF com associações do Service Bus.

Para desenvolver serviços WCF com pontos de extremidade do Service Bus, consulte a seção Desenvolver aplicativos que utilizam o Service Bus no MSDN. Diversos aplicativos de amostraestão disponíveis.

Considere um simples serviço WCF Echo que possua um ponto de extremidade WCF webHttpBinding. Um trecho de código para o serviço aparece como a seguir:

public class WebHttpService : IWebHttpService
{
    public string Echo(string value)
    {
        return string.Format("Echoing: ‘{0}’", value);
    }
}

A próxima etapa é atualizar o serviço para usar dois pontos de extremidade do Service Bus que utilizem a associação webHttpRelayBinding. É possível hospedar este serviço em IIS para benefícios a partir dos recursos de hospedagem de IIS/WAS.

O exemplo a seguir adiciona informações de ponto de extremidade à seção Services do arquivo Web.config. Neste trecho, substitua o namespace de serviço EchoService, as informações do nome de serviço sb-test e as informações de emissor pelo namespace de serviço e o serviço.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.serviceModel>
  <services>
    <clear />
    <service behaviorConfiguration="MyServiceTypeBehavior" 
      name="Microsoft.ServiceBus.Samples.WebHttpService">
      <endpoint address="https://sb-test.servicebus.windows.net/WebHttpService/"
      behaviorConfiguration="sharedSecretClientCredentials" 
binding="webHttpRelayBinding"
      bindingConfiguration="WebHttpRelayEndpointConfig" 
name="RelayEndpoint"
      contract="Microsoft.ServiceBus.Samples.IWebHttpService" />
    </service>
  </services>

    <bindings>
      <webHttpRelayBinding>
        <binding name="WebHttpRelayEndpointConfig">
          <security relayClientAuthenticationType="None" />
        </binding>
      </webHttpRelayBinding>
    </bindings>

    <behaviors>
        <!-- Service Bus endpoint behavior-->
        <endpointBehaviors>
          <behavior name="sharedSecretClientCredentials">
            <webHttp/>
            <transportClientEndpointBehavior credentialType="SharedSecret">
              <clientCredentials>
                <sharedSecret issuerName="ISSUER_NAME" issuerSecret="ISSUER_KEY" />
              </clientCredentials>
            </transportClientEndpointBehavior>
          </behavior>
        </endpointBehaviors>
   </behaviors>
  </system.serviceModel>

Por padrão, os serviços publicados na retransmissão do Service Bus são "encobertos" e não visíveis no feed ATOM de Service Registry. Para obter detalhes, consulte a seção Descobrir e expor um serviço do Service Bus. Observe que essa etapa para tornar o serviço visível no feed Service Registry é opcional.

A fim de definir a política de detectabilidade como "Público", primeiro crie um BehaviorExtensionElement personalizado para ServiceRegisterySettings na seção system.serviceModel do arquivo Web.config.

<system.serviceModel>
  <extensions>
    <behaviorExtensions>
<add name="ServiceRegistrySettings"
type="Microsoft.ServiceBus.Samples.MyServiceRegistrySettingsElement, WebHttpService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </behaviorExtensions>
  </extensions>

A próxima etapa é criar uma classe chamada MyServiceRegistrySettingsElement que herde de BehaviorExtensionElement. Por exemplo:

public class MyServiceRegistrySettingsElement : BehaviorExtensionElement
{
    public override Type BehaviorType
    {
        get { return typeof(ServiceRegistrySettings); }
    }

    protected override object CreateBehavior()
    {
        return new ServiceRegistrySettings() 
{ DiscoveryMode = this.DiscoveryMode, 
  DisplayName = this.DisplayName };
    }

    [ConfigurationProperty("discoveryMode", DefaultValue = DiscoveryType.Public)]
    public DiscoveryType DiscoveryMode
    {
        get { return (DiscoveryType)this["discoveryMode"]; }
        set { this["discoveryMode"] = value; }
    }

    [ConfigurationProperty("displayName")]
    public string DisplayName
    {
        get { return (string)this["displayName"]; }
        set { this["displayName"] = value; }
    }
}

Para opcionalmente habilitar o rastreamento de diagnóstico para o serviço WCF, é possível habilitar um ouvinte de rastreamento. Para fazer isso, adicione a seção a seguir ao arquivo Web.config:

<system.diagnostics>
  <sources>
    <source name="System.ServiceModel" switchValue="Warning">
      <listeners>
        <add name="traceListener"
             type="System.Diagnostics.XmlWriterTraceListener" 
             initializeData="C:\Log\Traces.svclog" />
      </listeners>
    </source>
  </sources>
</system.diagnostics>

Observe que a pasta na qual os rastreamentos serão emitidos (“C:\Log” no trecho acima) não será criada automaticamente, ele já deve existir.

É possível hospedar serviços WCF pontos de extremidade do Service Bus em IIS aproveitando o recursos Auto-Start do ASP.NET para inicialização. O recurso Auto-Start permite a inicialização de aplicativos da Web sem necessidade de aguardar uma solicitação externa. Este recurso carrega e inicializa proativamente qualquer dependência, como abrir conexões do banco de dados, carregar módulos entre outras. Ele pré-carrega os processos de trabalhado no início do servidor da Web, antes que a primeira solicitação chegue. Além disso, permite a recuperação de falhas e para plug-ins de código personalizados para executar inicialização avançada.

Há três alterações que devem ser feitas para aproveitar o recurso Auto-Start do ASP .NET:

  • Configuração do pool do aplicativo

  • Adicionar um provedor de Auto-Start personalizado

  • Usar de uma fábrica de hospedagem de serviços personalizada para recuperação de falhas

Para aproveitar o recurso Auto-Start, hospede o serviço WCF em um aplicativo virtual que por sua vez é associado a um pool de aplicativo que tenha como alvo o tempo de execução do .NET versão 4.0.

HostingWCFServices1

Em seguida, o pool do aplicativo IIS deve ser configurado para Auto-Start. Isso pode ser feito ao editar o arquivo applicationHost.config. O atributo startMode para o pool de aplicativo usado deve ser definido como AlwaysRunning no arquivo de configuração em %windir%\System32\inetsrv\config\applicationHost.config.

Neste exemplo, o pool do aplicativo é "WebHttpServicePool":

add name=" WebHttpServicePool" autoStart=“true” managedRuntimeVersion="v4.0" startMode="AlwaysRunning" />

Observe que um pool de aplicativo IIS pode hospedar diversos aplicativos virtuais. Neste exemplo, o aplicativo é "/WebHttpService". Isso pode ser configurado ao adicionar os atributos serviceAutoStartEnabled e serviceAutoStartProvider a uma entrada de aplicativo no arquivo applicationHost.config. Por exemplo:

<sites>
    <site name="Default Web Site" id="1">
        <application path="/WebHttpService" 
                     applicationPool="WebHttpServicePool" 
                     serviceAutoStartEnabled="true" serviceAutoStartProvider="AutoStartWebHttpService">
             <virtualDirectory path="/"
                     physicalPath="C:\inetpub\WebHttpService" />
        </application>
    </site>
</sites>

Observe que no IIS, se o pool de aplicativo for interrompido explicitamente por algum motivo, o atributo serviceAutoStartEnabled será redefinido como false. Nesse caso, você pode precisar defini-lo novamente como true para restaurar estar funcionalidade.

O atributo serviceAutoStartProvider mencionado na etapa anterior refere-se a uma classe personalizada que encapsula a lógica de inicialização do aplicativo. A classe ServiceAutoStart é automaticamente invocada quando o pool do aplicativo e o aplicativo são pré-carregados (antes que qualquer solicitação da Web externa seja recebida para o aplicativo). A classe ServiceAutoStart é automaticamente invocada para iniciar o host de serviço que por sua vez registra o ponto de extremidade do Service Bus na nuvem. Quando o método Preload é invocado, ele garante que o host de serviço seja ativado através de um chamado para ServiceHostingEnvironment.EnsureServiceAvailable().

Neste exemplo, classe ServiceAutoStart faz parte do assembly Microsoft.ServiceBus.Samples. O arquivo applicationHost.config deve ser atualizado como a seguir:

<system.applicationHost>

...
<serviceAutoStartProviders>
    <add name="AutoStartWebHttpService" 
         type="Microsoft.ServiceBus.Samples.AutoStartWebHttpService, WebHttpService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</serviceAutoStartProviders>

</system.applicationHost>

O código para a classe AutoStartWebHttpService será como exibido abaixo.

public class AutoStartWebHttpService : System.Web.Hosting.IProcessHostPreloadClient
{
    public void Preload(string[] parameters)
    {
        bool isServceActivated = false;
        int attempts = 0;
        while (!isServceActivated && (attempts <10))
        {
            Thread.Sleep(1 * 1000);
            try
            {
                string virtualPath = "/WebHttpService/WebHttpService.svc";
                ServiceHostingEnvironment.EnsureServiceAvailable(virtualPath);
                isServceActivated = true;
            }
            catch (Exception exception)
            {
                attempts++;
                //continue on these exceptions, otherwise fail fast
                if (exception is EndpointNotFoundException
                    || exception is ServiceActivationException
                    || exception is ArgumentException)
                {
                    //log
                }
                else
                {
                    throw;
                }
            }
        }
    }
}

Observe que na amostra acima, o virtualPath deve ser atualizado conforme apropriado para o aplicativo.

Se o host do serviço WCF falhar, o IIS/WAS não poderá recriar o objeto do host. Neste caso, é possível reciclar o pool do aplicativo manualmente.

A fim de recriar o objeto do host automaticamente em um cenário de falha, é possível usar o padrão de fábrica do host de serviço personalizado de WCF. Consulte Host de serviço personalizado para obter detalhes.

Você pode adicionar a classe de fábrica do host de serviço personalizado ao serviço do WCF. Por exemplo:

public class ServiceHostFactoryWebHttpService : ServiceHostFactory
{
    Type incomingServiceType;
    Uri[] incomingBaseAddresses;

    private void OnServiceHostFaulted(object sender, EventArgs e)
    {
        ICommunicationObject faultedHost = (ICommunicationObject) sender;
        faultedHost.Abort();

        ServiceHost host = new ServiceHost(this.incomingServiceType, this.incomingBaseAddresses);
        host.Faulted += this.OnServiceHostFaulted;

        // Sleep to allow time for resource to come back – may require over 10s 
        // for remote services. Without wait/retry logic, process may throw
        // StackOverflow exception if resource is unavailable for an extended 
        // period of time.
        System.Threading.Thread.Sleep(TimeSpan.FromSeconds(10)); 

        host.Open();
    }

    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
    {
        this.incomingServiceType = serviceType;
        this.incomingBaseAddresses = baseAddresses;
        ServiceHost host = new ServiceHost(serviceType, baseAddresses);
        host.Faulted += this.OnServiceHostFaulted; 
        return host;
    }
}

O código Thread.Sleep neste trecho é ilustrativo. Para serviços de produção, use a lógica aguardar/tentar novamente adequada.

Para invocar a fábrica do host de serviço, é possível adicionar o atributo Factory ao arquivo .svc do serviço WCF. Neste caso, trata-se do arquivo WebHttpService.svc.

<%@ServiceHost language="C#" Debug="true" 
    Service="EchoServiceMicrosoft.ServiceBus.Samples.WebHttpService" 
    Factory="Microsoft.ServiceBus.Samples.ServiceHostFactoryWebHttpService" 
    CodeBehind="WebHttpService.svc.cs" %>

O Microsoft AppFabric 1.1 para Windows Server é um conjunto de extensões IIS que fornece a possibilidade de configurar, gerenciar e monitorar com facilidade aplicativos WCF e WF no IIS. Consulte Microsoft AppFabric 1.1 para Windows Server para obter uma visão geral do Microsoft AppFabric 1.1 para Windows Server e seus recursos.

Esta seção descreve as etapas para uso dos recursos do Microsoft AppFabric para serviços WCF com pontos de extremidade do Service Bus.

O Microsoft AppFabric usa as APIs do Microsoft.Web.Administration (MWA) para ler e gravar o esquema de configuração. As APIs MWA usam esquemas armazenados em %SystemRoot%\System32\inetsrv\config\schema. O arquivo Web.config para o serviço deste exemplo contém uma configuração de ponto de extremidade personalizada para associações do Service Bus, por isso é necessário adicionar o esquema MWA aos pontos de extremidade do Service Bus (link para ServiceBus_schema.xml) e posicioná-lo na pasta do esquema MWA mencionada anteriormente. O MWA obtém automaticamente o esquema e analisa a configuração específica ao Service Bus corretamente.

O recurso Auto-Start do Microsoft AppFabric para serviços WCF e WF é desenvolvido no recurso Auto-Start do ASP.NET 4. Ele possibilita que o serviço seja iniciado automaticamente quando o IIS é reiniciado ou se o pool aplicativo for reciclado.

Em Gerenciador do IIS, selecione o aplicativo (WebHttpService, neste exemplo) e clique em Configurar… abaixo da seção Gerenciar Serviços WCF e WF do painel Ações ao lado direito.

HostingWCFServices2

Esta seleção exibe a caixa de diálogo Configurar WCF e WF do Aplicativo. Clique em Auto-Start no menu do lado esquerdo e, em seguida, clique em Habilitado (todos os serviços auto-start). Clique em Sim para definir o startMode como AlwaysRunning para o pool de aplicativos.

HostingWCFServices3

Para recuperar e recriar automaticamente o objeto de host em um cenário de falha, use o padrão de fábrica do host de serviço personalizado do WCF mencionado na seção Usar uma fábrica de hospedagem de serviços personalizada para recuperação de falhas. O uso do padrão de fábrica do host de serviço personalizado de WCF é necessário para serviços WCF com pontos de extremidade do Service Bus que estejam hospedados no Microsoft AppFabric.

O Microsoft Azure Service Bus oferece suporte para recursos de retransmissão e mensagens, facilitando o acesso do Service Bus na nuvem a partir de serviços WCF. Este artigo documentou um conjunto de atualizações de configuração necessárias para hospedar tais serviços WCF em IIS. Além disso, descreveu o uso do padrão WCF de fábrica do host de serviço personalizado que é necessário para recuperação automática de falhas.

Mostrar:
© 2014 Microsoft