Compartilhar via


Hospedagem no serviço de ativação do processo do Windows

O Serviço de Ativação de Processos do Windows (WAS) gerencia a ativação e a vida útil dos processos de trabalho que contêm aplicativos que hospedam os serviços do Windows Communication Foundation (WCF). O modelo de processo WAS generaliza o modelo de processo IIS 6.0 para o servidor HTTP ao remover a dependência do HTTP. Isso permite que os serviços WCF usem protocolos HTTP e não HTTP, como o Net.TCP, em um ambiente de hospedagem que suporte a ativação baseada em mensagens e oferece a capacidade de hospedar um grande número de aplicativos em uma determinada máquina.

Para obter mais informações sobre como criar um serviço WCF executado no ambiente de hospedagem WAS, consulte Como: Hospedar um serviço WCF no WAS.

O modelo de processo WAS fornece vários recursos que permitem que os aplicativos sejam hospedados de maneira mais robusta, mais gerenciável e que use os recursos de forma eficiente:

  • A ativação baseada em mensagens de aplicativos e aplicativos de processo de trabalho inicia e para dinamicamente em resposta a itens de trabalho de entrada que chegam usando protocolos de rede HTTP e não HTTP.

  • Reciclagem robusta de aplicativos e processos de trabalho para manter a integridade dos aplicativos em execução.

  • Configuração e gerenciamento centralizado de aplicativos.

  • Permite que os aplicativos aproveitem o modelo de processo do IIS sem exigir o volume de implantação de uma instalação completa do IIS.
    O Windows Server AppFabric funciona com IIS 7.0 e Windows Process Activation Service (WAS) para fornecer um ambiente de hospedagem de aplicativos avançado para serviços NET4 WCF e WF. Esses benefícios incluem gerenciamento do ciclo de vida do processo, reciclagem de processos, hospedagem compartilhada, proteção rápida contra falhas, processo órfão, ativação sob demanda e monitoramento de integridade. Para obter informações detalhadas, consulte Recursos de hospedagem do AppFabric e Conceitos de hospedagem do AppFabric.

Elementos do Modelo de Endereçamento WAS

Os aplicativos têm endereços Uniform Resource Identifier (URI), que são as unidades de código cujo tempo de vida e ambiente de execução são gerenciados pelo servidor. Uma única instância do servidor WAS pode abrigar muitos aplicativos diferentes. Os servidores organizam os aplicativos em grupos chamados sites. Dentro de um site, os aplicativos são organizados de maneira hierárquica que reflete a estrutura dos URIs que servem como seus endereços externos.

Os endereços de aplicativo têm duas partes: um prefixo de URI básico e um endereço relativo específico do aplicativo (caminho), que fornecem o endereço externo para um aplicativo quando combinados. O prefixo de URI base é construído a partir da associação do site e é usado para todos os aplicativos no site. Os endereços de aplicativo são então construídos pegando fragmentos de caminho específicos do aplicativo (como "/applicationOne") e anexando-os ao prefixo URI base (por exemplo, "net.tcp://localhost") para chegar ao URI completo do aplicativo.

A tabela a seguir ilustra vários cenários de endereçamento possíveis para sites WAS com ligações de site HTTP e não HTTP.

Cenário Associações de site Caminho do aplicativo URIs do aplicativo básico
Somente HTTP http: *:80:* /appTwo http://localhost/appTwo/
HTTP e não HTTP http: *:80:*

net.tcp: 808:*
/appTwo http://localhost/appTwo/
net.tcp://localhost/appTwo/
Somente não HTTP net.pipe: * /appThree net.pipe://appThree/

Serviços e recursos dentro de um aplicativo também podem ser abordados. Dentro de um aplicativo, os recursos do aplicativo são endereçados em relação ao caminho do aplicativo base. Por exemplo, suponha que um site em um nome de computador contoso.com tenha associações de site para os protocolos HTTP e Net.TCP. Suponha também que o site contenha um aplicativo localizado em /Billing, que exponha um serviço em GetOrders.svc. Então, se o serviço GetOrders.svc expusesse um ponto de extremidade com um endereço relativo de SecureEndpoint, o ponto de extremidade de serviço seria exposto nos dois URIs a seguir:

  • http://contoso.com/Billing/GetOrders.svc/SecureEndpoint
  • net.tcp://contoso.com/Billing/GetOrders.svc/SecureEndpoint

WAS Runtime

Os aplicativos são organizados em sites para fins de endereçamento e gerenciamento. Em tempo de execução, os aplicativos também são agrupados em pools de aplicativos. Um pool de aplicativos pode abrigar muitos aplicativos diferentes de vários sites diferentes. Todos os aplicativos dentro de um pool de aplicativos compartilham um conjunto comum de características de tempo de execução. Por exemplo, todos eles são executados na mesma versão do CLR (Common Language Runtime) e todos compartilham uma identidade de processo comum. Cada pool de aplicativos corresponde a uma instância de um processo de trabalho (w3wp.exe). Cada aplicativo gerenciado executado dentro de um pool de aplicativos compartilhado é isolado de outros aplicativos por meio de um CLR AppDomain.

Confira também