Serviços para Intranet

Olá pessoal, tudo certo?

Vamos falar hoje sobre Serviços de Intranet, um cenário importante para aplicações corporativas. Esse tipo de serviço vive atrás do firewall e por isso não utiliza protocolos de interoperabilidade, como SOAP, HTTP, etc. Cenários utilizando .NET Remoting e Enterprise Services são muito comuns na implementação de serviços para aplicações intranet e estão sendo gradativamente substituídos por serviços com WCF. Nesse contexto, podemos relacionar alguns tipos de implementação de serviços para intranet, como:

• Aplicações cliente/servidor clássicas, onde clientes Windows comunicam com serviços dentro do mesmo domínio Windows;
• Aplicações Web ASP.NET que consomem serviços atrás do firewall, expondo funcionalidades de negócio para as aplicações;
• Serviços distribuídos através de uma infra-estrutura orientada a serviços, consumidos por processos de negócios, camadas diversas, etc.;

A seguir, vamos olhar cada tipo de serviço e suas principais características.

Aplicações Cliente/Servidor

Em um típico cenário cliente/servidor, aplicações cliente acessam serviços instalados em servidores remotos dentro do domínio. Um banco de dados é usualmente parte da configuração, acessado através de serviços, nunca diretamente a partir da aplicação ou da camada de apresentação. Nesse cenário, WCF oferece grande facilidade para a exposição de funcionalidades para clientes remotos dentro da intranet.

A figura a seguir ilustra esse cenário, considerando a autenticação através de um AD ou lista de usuários válidos.

by M. L. Bustamente

A proteção das mensagens durante a comunicação entre cliente e servidor pode ser obtida através de criptografia e assinatura via certificados, criando um transporte com segurança.

A tabela a seguir apresenta as principais características e alternativas de configuração do cenário cliente/servidor:

Note que para alguns cenários, podemos utilizar protocolos de mensagens SOAP + XML, ao invés de SOAP + encoding binário. Devemos avaliar o impacto de performance nessa situação.

Outro ponto importante nessa discussão é que utilizando o Windows Server 2008, podemos configurar nossos serviços como hosted no WAS - Windows Activation Services, permitindo protocolos como TCP, Named Pipes e MSMQ, como vemos na figura a seguir:

Como alternativa ao WAS sobre Windows Server 2008, podemos publicar nossos serviços WCF em serviços NT (Windows NT Service), o que fará nosso transporte ser baseado em protocolo TCP para a entrega de mensagens. Assim, estaremos usando sockets TCP para a comunicação entre cliente e serviço.

Publicar serviços WCF através de Windows NT Service gera alguns contra-tempos, como:

• sempre que o serviço é atualizado, devemos reinicializar nosso Windows NT Service, para que as alterações sejam refletidas na produção;
  
• durante o processo de reinicialização do serviço, requisições feitas para o WCF serão rejeitadas. É importante notar que nesse cenário não existirá um mecanismo de enfileiramento de requisições ou mensagens, como ocorre no hosting baseado no WAS - Windows Activation Services;
  
• Finalmente, Windows NT Service não suporta pooling, monitoração, recycling ou gerenciamento de idle-time (ociosidade) para otimização de recursos;

De fato, para cenários de serviços no ambiente intranet, a utilização de WAS para hosting é a melhor opção por seus vários benefícios. Porém, para cenários de distribuição de serviços em ambientes não controlados, onde não garantimos a presença do WAS, Windows NT Service é a alternativa mais adequada.

Aplicações Web ASP.NET

Vejamos um segundo cenário de serviços na intranet. Em aplicações orientadas a serviços, uma camada de apresentação baseada em ASP.NET pode consumir serviços WCF através do firewall, acesando funcionalidades encapsuladas por esses serviços. Embora seja possível uma aplicação ASP.NET realizar chamadas diretas para os componentes de negócio, o uso de uma camada WCF oferece uma série de benefícios, como:

• Serviços podem encapsular necessidades de negócio recorrentes, permitindo que diversas aplicações reutilizem as mesmas funcionalidades, aumentando o reuso;
  
• A criação de uma fronteira de processos entre as páginas ASP.NET e os componentes de negócio pode aumentar a segurança do ambiente, reduzindo a superfície de ataque para códigos maliciosos ou acessos diretos aos dados da aplicação;
  
• Em muitos ambientes, uma DMZ é exigida entre a lógica de negócio e a camada de apresentação, significando um segundo firewall na infra-estrutura. Serviços WCF podem tornar mais fácil o consumo de funcionalidades através do segundo firewall.

A figura a seguir ilustra o cenário onde páginas ASP.NET e serviços WCF encontram-se na mesma máquina:

by M. L. Bustamente

A tabela a seguir apresenta as principais características de configuração do cenário onde serviços e páginas ASP.NET estão na mesma máquina:

Para cenários onde a camada de serviços encontra-se em outra máquina ou atrás de um firewall (como uma segunda DMZ), nosso protocolo de transporte torna-se o TCP e podemos utilizar certificados X.509 para a comunicação segura durante a troca de mensagens.

A figura a seguir ilustra o cenário onde páginas ASP.NET e serviços WCF encontram-se em máquinas diferentes:

 
by M. L. Bustamente

Assim, vimos que existem diferentes alternativas de configuração de um ambiente ASP.NET com serviços WCF, variando de acordo com as considerações de segurança e infra-estrutura presentes na solução.

Serviços Distribuídos para Arquiteturas Orientadas a Serviços

Um dos grandes benefícios na construção de arquiteturas orientadas a serviços é a composição de funcionalidades, obtida através do consumo de serviços distribuídos ao longo da organização. Um cenário típico de composição oferece uma camada de apresentação em ASP.NET, consumindo camadas de serviços WCF para processos, funcionalidades de negócio, acesso a dados, etc., permitindo uma escalabilidade crescente ao longo de sua utilização.

A figura a seguir apresenta um exemplo desse tipo de cenário:

Vejamos as opções de configuração indicadas para o cenário de serviços distribuídos na intranet.

Foi um longo post, mas conseguimos passar pelos principais cenários presentes no ambiente de intranet, enquanto utilizamos serviços WCF para encapsular nossa lógica de negócios e funcionalidades de aplicações.

No próximo post, vamos falar de um novo cenário, serviços de mensageria e chamadas assíncronas, fiquem ligados!

Por enquanto é só! Até o próximo post :)

Waldemir.

Technorati Tags: SOA,WCF,Services,Web Services,Intranet Services