Freigeben über


Windows a Plataforma de Aplicações: WCF & “Internet Information Service”

Ola, tudo bem ?

Vamos continuar de falar e analisar as possibilidades da hospedagem de serviços WCF no “Internet Information Server”. Nos blogs anteriores sobre este assunto eu tentei formalizar algumas perguntas que precisam ser respondidos antes da escolha do contêiner. Vamos começar, resumindo os pontos de conversa dos blogs anteriores.

Antes da escolha, você preciso se perguntar seguintes perguntas:

  • Quais possibilidades eu tenho para hospedar serviços WCF ?
  • Quais são os vantagens de cada uma ?
  • Quais são as melhoras praticas da Microsoft?

Vamos definir três tipos básicos de hospedagem de serviços WCF:

  1. “Self-Hosting” - .Net Application
  2. “Windows Service”
  3. “IIS, WAS”

Em neste post nos vamos tratar item 3. IIS e o contêiner de Serviços WCF mais usado no mercado por causa da flexibilidade e do desacoplamento entre a aplicação e a configuração. Uma das perguntas mais importantes é como nos podemos garantir o isolamento das aplicações e qual é o impacto na escolha do contêiner de hospedagem.

 

.Net Application Domain

Na parte da plicacao nos podemos garantir o isolamento via a “.Net Application Domain”. Uma “.Net Application Domain” é usado para isolar os aplicativos uns dos outros.  A separação é necessária, para que aplicativos não se afetam mutuamente. Uma “.Net Application Domain” do Common Language Runtime está contido em um processo de sistema operacional. Um processo pode conter uma ou várias “.Net Application Domains” mas por rações de gerenciamento nos estamos sugerindo seguir a regra 1:1. Se você gostaria conhecer mais sobre este assunto acesso o link: https://blogs.technet.com/markuschristen/archive/2009/08/05/hospedar-servi-os-wcf-com-um-windows-service.aspx

Importante: Concluindo, nos podemos falar que toda Aplicação .Net precisa uma “Application Domain” que e hospedado dentro de um Windows Process.

Para determinar qual hospedagem e a mais adequado para seu cenário, você precisa responder seguinte perguntas

  • Disponibilidade: Você precisa acessar seu serviço , 24/7 ?
  • Confiabilidade: O que acontece quando seu serviço para ?
  • Processo de Gerenciamento: Você precisa informações sobre a operação do seu serviço ?
  • Processo de Versionamento: Você precisa suportar vários versões do seu serviço ?
  • Processo de Implementação: Qual e seu processo de implementação? Você precisa usar o processo de empacotamento o xcopy e suficiente ?
  • Chamada de Persistência: Você precisa uma chamada de persistência ?

Estas perguntas, baseado na minha experiência, podem agora ajudar definir qual contêiner de hospedagem é o mais adequado para seu cenário.

 

“Internet Information Service”

Como todo aplicação .Net precisa um contêiner de hospedagem, nos podemos considerar o “Internet Information Service” o mais importante para serviços WCF no mercado corporativo. WCF e suportado deste da versão Windows XP, mas com limitações dependendo da versão do sistema operacional. Dependendo da versão homologado no seu ambiente você precisa iniciar um novo processo de homologação ou conviver com as limitações.

O “Application Pool” é um “Windows Process” separando as aplicações via processos Windows chamado W3wp.exe. Estes processos são iniciados apenas quando for necessário (Sobre Demanda) . Em outras palavras, o IIS vem com um modelo de ativação (Http Activation) que permite a ativação do “Application Pool” quando ele recebe um pedido de um aplicativo específico acoplado no “Application Pool”. Isso habilita o IIS hospedar milhares de aplicativos em um servidor sem manter os processos executando em memoria.

Para hospedar um serviço WCF no IIS, você precisa de um serviço com a extensão svc (WCF – Service) . O arquivo associa um serviço com a implementação e o meio para o IIS criar o ServiceHost para você. O IIS assume a interação entre seu serviço e o ServiceHost, você não preciosa instanciar e iniciar o ServiceHost para seu serviço, que simplifica o processo da codificação do serviço. O código do serviço, pode residir , em um “Assembly” separado, registrado no GAC, ou reside na pasta bin do aplicativo, ou em um arquivo C# que reside na pasta de “App_Code” do aplicativo web. Este cenários ajuda definir padrões de hospedagem para todas “Aplicações” Serviços no seu ambiente.

A grande pergunta, porque o IT-Pro precisa saber tudo disto ? A resposta e simples, quem e responsável para manter e providenciar o ambiente de hospedagem de serviços e o IT-Pro. Mas como esta a distribuição das responsabilidades e tarefas ?

                       image

A configuração é bem semelhante ao arquivo App.Config do blog anterior,   que configura o serviço . Ligeiras mudanças são realizadas, conforme é mostrado abaixo:

                      image

Passo 5 mostra que o IT-Pro precisa definir o web.config para o novo serviço.

É importante mencionar que na criação do endpoint não é necessário de definir o atributo “Address,”o endereço é determinado baseado no arquivo *.svc.  Se você quer entender melhor toda “Schema” usa o “Microsoft Service Configuration Editor” que mostra todas as possibilidades de configuração.

Disponibilidade

  • Gerenciado via o “Internet Information Service” sem intervenção na fase de desenvolvimento
  • O Internet Information Service” possui suporte interno para reiniciar serviços quando ocorrem falhas ou atendem limites definidos como memória ou utilização de CPU.
  • Os processos são iniciados apenas quando for necessário (Sobre Demanda)
  • Possiblidade de usar equipamentos de balanceamento de carga como NLB, Big5 etc.

Confiabilidade

  • O Internet Information Service permite escolher uma identidade de segurança específicas em que você quiser o serviço executado incluindo contas internas de serviço de sistema ou rede.

Processo de Gerenciamento

  • Em geral, os IT-Pros sabem muito sobre o Gerenciador de controle de serviços e outras ferramentas, no entanto, para fazer serviços sustentável, você provavelmente teria que adicionar alguns recursos de log e instrumentação  (SCOM 2008)
  • IIS Manager ou PowerShell

Processo de Versionamento

  • Versionamento precisa ser providenciado via código customizado (Codificação) e processos de IT-Pros.

Processo de Implementação

  • Criacao de um pacote MSI
  • Copiar os arquivos para o novo destino

Chamada de Persistência

  • Chamada de persistência via código customizado ou os chamadas de persistência oferecido via os padrões do IIS.

Pré-requisitos:

Mais perguntas ? Ate o próximo Blogs, Markus

Technorati Tags: WCF,IIS