Colunas Técnicas :: Falando C#

Sessões em ASP.NET e WebServices

Por Mauro Sant'Anna (mas_mauro@hotmail.com). Mauro é um "MSDN Regional Director", consultor e instrutor da MAS Informática (www.mas.com.br), tendo ministrado treinamentos na arquitetura .NET desde outubro de 2000.

O mecanismo usado tanto nos programas ASP tradicional como em programas ASP.NET® é basicamente o mesmo: variáveis de sessão. As variáveis de sessão funcionam como dicionários, onde o aplicativo armazena uma chave (uma string ou número inteiro) e um valor (número, strings e vários outros tipos). O interessante é que cada sessão tem uma cópia deste dicionário, esse conjunto dos pares chave-valor. Uma sessão corresponde, a grosso modo, a uma cópia de um navegador acessando o site. Como o servidor não tem como saber se um navegador remoto foi fechado (já que o protocolo HTTP não mantém conexão), as variáveis deixam de existir por "timeout", normalmente no prazo de vinte minutos.

  • O navegador remoto deve ser capaz de identificar qual dicionário é "dele". Este identificador é uma "chave" na base de dados das variáveis de sessão;

  • A base de dados com todos os dicionários deve ser implementada de alguma forma, em algum servidor.

No ASP tradicional o identificador de sessão é sempre um "cookie" de sessão e a base de dados fica sempre na memória do servidor. Embora eficientes, este mecanismo pode ter alguns problemas:

  • O suporte a cookies pelo navegador pode ser desligado pelo usuário. Alguns usuários confundem os "cookies de sessão" - temporários e inofensivos - com "cookies armazenados", que gravam informações no computador que acessa o site;

  • O fato da base de dados residir na memória do servidor Web dificulta a implementação de sites de muito movimento, onde vários servidores Web servem as mesmas páginas. O problema é que se uma sessão é iniciada em um determinado servidor, os outros servidores não podem mais servir aquele usuário, já que apenas um deles enxerga os valores das variáveis de sessão. Existem formas de contornar este problema, mas nenhuma é perfeita.

O ASP.NET resolve os dois problemas acima. Em primeiro lugar, é possível implementar sessões sem cookies. Em segundo lugar, é possível armazenar a base de dados de sessão de vários servidores Web em um único "servidor de sessão", na rede. Estas opções são especificadas no arquivo de configuração web.config, localizado no mesmo diretório do aplicativo Web.

Entradas no web.config

As entradas que controlam as variáveis de sessão estão sob a tag session. Veja as opções possíveis:

Tag

Significado

Mode

Indica onde são armazenadas as variáveis de sessão.

InProc: Memória do servidor (padrão, igual ao ASP tradicional)

StateServer: Servidor de sessão

SQLServer: Servidor SQL Server

Off: Variáveis de sessão desligadas

Cookieless

Indica se a sessão usará cookies ou não.

False: Com cookies, igual ao ASP tradicional

True: Sem cookies

timeout

Tempo em minutos até que sessões sem uso sejam abandonadas. O padrão é vinte minutos.

stateConnectionString

Nome do servidor e porta usado para a opção mode=StateServer.

sqlConnectionString

String de conexão SQL para a opção mode=SQLServer.

Veja um exemplo completo:

<sessionState 
mode="SQLServer" 
stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source= mas8\MAURO;userid=sa;password=" 
cookieless="true" 
timeout="20" 
/> 

Sessões sem cookies

Para implementar sessões sem cookies, basta abrir o arquivo web.config no Visual Studio .NET ou outro editor de textos, modificar a tag cookieless para true e salvar o arquivo:

<sessionState 
. . . 
cookieless="true" 
/> 

Nada mais precisa ser feito. Observe que a URL passa a conter uma string "mágica". Esta string é a mesma usada no cookie quando cookieless=false e também é a chave usada em todos os bancos de dados. Veja um exemplo:

Observe que os links gerados pelos componentes ASP.NET como DataGrid e Hyperlink refletem as mudanças na URL. Se você estiver gerando manualmente uma tag HREF, a sua tag não será alterada; o melhor mesmo é usar o componente Hyperlink.

Mudando o local de armazenamento

Servidor de sessão

O valor padrão de Mode é InProc, onde a base de dados é armazenada na memória do próprio servidor Web. Podemos armazenar a base em um "servidor de sessão" específico mudando a tag Mode para StateServer. Precisamos dizer quem é o servidor de sessão na tag stateConnectionString:

<sessionState 
. . . 
mode="StateServer" 
stateConnectionString="tcpip=127.0.0.1:42424" /> 

O número "42424" é a porta TCP padrão usada pelo servidor de sessão.

Este servidor de sessão roda um serviço especial chamado "ASP.NET State Service". Este serviço é normalmente instalado junto com o resto do ASP.NET e fica no executável \WINDOWS\Microsoft.NET\Framework\versao\aspnet_estate.exe.". Você pode visualizá-lo junto aos outros serviços:

Evidentemente, o servidor de sessão normalmente não fica no mesmo computador que o servidor Web e sim em um computador dedicado. Note também que ele deve ser ligado manualmente, pois seu estado inicial é desligado com início manual.

SQL Server

Para usar o SQL Server 2000 como servidor de sessão, temos que modificar alguns ajustes no web.config e também criar um banco de dados no servidor. Os ajustes no web.config são os seguintes:

<sessionState 
mode="SQLServer" 
sqlConnectionString="data source= mas8\MAURO;userid=sa;password=" 
/> 

sqlConnectionString é a string de conexão ao SQL Server. Ela identifica o nome do servidor, nome e senha usados na conexão. Evidentemente serão diferentes dos valores mostrados acima.

Você deve também criar o banco de dados rodando o script "InstallSqlState.sql", normalmente a partir do diretório "\WINDOWS\Microsoft.NET\Framework\v1.0.XXXX\".

Rode o "SQL QueryAnalyzer", abra o script e execute-o:

Não é criada nenhuma tabela, e sim várias "stored procedures", estas sim capazes de criar tabelas temporárias. Você pode eliminar o banco de dados rodando o script "UninstallSqlState.sql".

Vantagens de cada modo

Cada modo tem as suas vantagens e desvantagens. InProc oferece a melhor performance de todas, sendo o modo mais recomendável quando apenas um servidor é usado. Já StateServer tem melhor performance que SQLServer e também compatibilidade com "WebFarms". SQLServer também é compatível com "WebFarms", mas com melhor confiabilidade que StateServer, pois o SQL Server pode ser instalado em um "cluster".

Conclusão

Embora do ponto de vista do programador as variáveis de sessão tenham mudado pouco, a sua implementação pode variar bastante e resolver problemas de vários sites com a não-obrigatoriedade do uso de "cookies" e armazenamento dos dados em outros servidores na rede.

Faça o download deste documento:

Sessões em ASP.NET e WebServices

downl.gif formato Word, 224 Kb    

Mostrar: