No POST anterior, dei uma pincelada bem por cima sobre a estrutura básica de uma aplicação WEB.
É hora de mais detalhes.
O servidor WEB
Quando vemos a palavra "servidor", estamos nos referindo tanto ao hardware como ao software. Um servidor WEB é capaz de processar requisições HTTP enviadas através de browsers (clientes). Isso significa que quando estamos em um site e preenchemos um formulário ou clicamos em um botão, o browser (navegador) irá enviar uma solicitação HTTP para o servidor web. Um dos servidores WEB mais conhecidos e utilizados até o momento é o Apache.
Mas por que eu preciso de um servidor WEB?
Justamente para processar as requisições HTTP oriundas dos clientes. Mas não só por isso. Um servidor WEB é capaz de armazenar outras páginas que serão acessadas pelos usuários, armazenar sons, imagens, scripts auxiliares (PHP, Perl, etc). Ele é capaz de lidar com muitos acessos simultâneos, utilizando o mecanismo de threads. Ele é capaz de processar e criar páginas dinamicamente e devolver uma página diferente ao usuário, como por exemplo retornar uma página de erro ou de sucesso, se a determinada ação foi ou não bem sucedida.
O container
O container é um software que gerencia uma porção de coisas que são essenciais para sua aplicação. É ele que cuida do gerenciamento de segurança, do suporte a threads, gerenciamento do ciclo de vida das sessões, e muito mais! Um Web Container é um poderoso amigo que ajuda o servidor WEB a tratar solicitações em que o mesmo não é capaz de tratar, como solicitações dinâmicas. Exemplo? O usuário está em um site de compras e decide verificar se aquele CD que ele tanto quer está disponível em estoque. Então ele escolhe o CD e clica em "Pesquisar estoque". Bom, essa solicitação vai chegar no servidor WEB e ele dirá "opa, preciso de ajuda! Eu realmente não sei como verificar isso, vou chamar o meu amigo Container". Então o servidor WEB encaminha a solicitação ao Container. E é o container que vai direcionar essa solicitação para um de seus vários programas auxiliares que sabem como verificar o estoque para aquele CD. Depois que é feita essa verificação, o container responde ao servidor WEB que o CD está sim disponível no estoque, e o servidor web por sua vez "monta" uma resposta e a envia para o cliente. Simples, não?
Existem vários Web Containers disponíveis no mercado. Um deles é o Tomcat (desenvolvido inclusive pelo pessoal da Apache). O Tomcat acaba atuando como servidor web e container web, quando não se tem um servidor web instalado, mas nada comparado a robustez do Apache. Porém, o Tomcat não é um servidor JEE completo (ele consegue apenas entender Servlets e JSP). Um servidor JEE completo, contempla um servidor EJB + container web. Ainda não chegamos lá, mas um servidor JEE completo, por exemplo, é o JBoss, mas vamos com calma :)
A seguir, uma figura que exemplifica isso que expliquei acima, mostrando os dois tipos - Um servidor JEE completo e apenas um WEB Container:
Figura 1: Estrutura (adaptado de Head First - Servlets e JSP (pág. 65))
Por hoje é só pessoal!
No próximo POST é hora de começar a ver sobre Servlets!
Um abraço e até a próxima.
