Container gerencia servlets

LINGUAGEM DE
PROGRAMAÇÃO III
APLICAÇÕES WEB

CONTAINER
• O container gerencia e executa o servlet. Porque?
1. Suporte para comunicações:
– oferece uma maneira simples para comunicação
entre os seus servlets e o servidor;
– Você deve se preocupar apenas com a lógica do
seu próprio negócio, que está contida no seu
servlet
– O container conhece o protocolo de
comunicação entre ele mesmo e o servidor

CONTAINER
2. Gerenciamento do ciclo de vida:
– O container controla e a vida e a morte dos
servlets;
– Carrega classes, inicialização servlets, chama
métodos do servlet, coleta lixo;
– Você não precisa se preocupar com o
gerenciamento dos recursos

CONTAINER
3) Suporte a Multithread:
– O container cria automaticamente uma nova
thread em java para cada solicitação do servlet
recebida.
– O container cria e gerencia as thread para
várias solicitações
– A thread termina quando o servlet conclui a
execução do método de serviço HTTP para a
solicitação daquele cliente

CONTAINER
4. Certeza de segurança
– Você pode gerenciar e alterar sua segurança
sem tocar, ou recompilar, seus arquivos-fonte
em java, usando um arquivo XML (deployment
descriptor)
5. Suporte ao JSP
– O container se encarrega de traduzir o código
JSP em código JAVA

Como o container trata uma
solicitação

Exemplo simples de código servlet
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class teste extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
try {
out.println("<html>");
out.println("<head>");
out.println("<title>Servlet teste</title>");
out.println("</head>");
out.println("<body>");
out.println("<h1>Servlet teste at " + request.getContextPath() + "</h1>");
out.println("</body>");
out.println("</html>");
} finally { out.close(); }
}
}

try {
}
}
99,9% de todos os servlets desenvolvidos
anulam ou o método GET ou o método POST.
Isto é, apenas um dos métodos é utilizado no
servlet. Como já mencionado na aula anterior,
a maioria utiliza POST.

try {
}
}
99,9% de todos os servlets desenvolvidos no
mundo são HTTPSERVLETS

try {
}
}
REQUEST: é aqui que o seu servlet consegue as
referências dos objetos solicitação
RESPONSE: é aqui que o seu servlet consegue as
referências dos objetos reposta
(ambos criados pelo container)

try {
}
}
Uma forma de imprimir a resposta do servlet no
navegador – não é utilizado no mundo real com
frequencia (utilize apenas para testes). PrintWriter
imprimirá a resposta que o seu servlet recebe do
container e, ainda poderá escrever um código
HTML no objeto de resposta.

Testando um Servlet no Netbeans
• Criar uma aplicação web no netbeans
• Criar um servlet
• Sem fazer qualquer tipo de alteração nos
arquivos criados, executar o arquivo
• O navegador será aberto automaticamente
com a resposta
• Mais detalhes serão vistos na aula sobre
servlets
• http://docs.oracle.com/javaee/6/api/javax/s
ervlet/package-summary.html

Como o Container encontra o
Servlet?
• A URL que chega como parte da solicitação
do cliente é mapeada para um servlet
específico no servidor
• A solicitação do usuário deve mapear para
um servlet específico e cabe ao
desenvolvedor entender e configurar este
mapeamento.

Um servlet pode ter três nomes
• RESUMO:
1. Nome da URL conhecido pelo cliente
2. Nome interno secreto conhecido pelo
distribuidor
3. Nome do arquivo verdadeiro

• Um servlet tem um nome do caminho para o arquivo
(um caminho para um arquivo de classe real)
• O desenvolvedor da classe do servlet escolhe o
nome da classe e o nome do pacote que define
parte da estrutura de diretórios
• O local no servidor define o nome completo do
caminho
• Entretanto, qualquer pessoa que distribua o servlet
também pode atribuir a ele um nome especial de
distribuição

• Um nome especial de distribuição é um nome
interno secreto, que não precisa ser igual ao nome da
classe ou do arquivo
• Ele pode ser igual ao nome da classe ou o caminho
relativo para o arquivo da classe, mas também pode ser
diferente
• O servlet tem um nome público de URL, que é o nome
que o cliente conhece, o nome codificado no HTML.
• Quando o usuário clicar em um link, este nome público
de URL é enviado ao servidor na solicitação HTTP, e é
ele quem vai até o servlet correspondente

• Mapear o nome dos servlets aumenta a flexibilidade
e a segurança da sua aplicação
• Por este motivo não usamos o mesmo nome para o
servlet
• Escrevendo o caminho verdadeiro em seus arquivos,
terá problemas quando precisar reorganizar a
aplicação em novos diretórios
• O cliente não precisa saber o caminho verdadeiro,
sem contar que ele podem tentar acessar
diretamente o servlet

Deployment Descriptor XML
• O DD é criado para informar ao Container como
executar seus servlets e JSPs.
• É usado para mapeamento dos nomes e
mapeamento das URLs aos servlets
• Um elemento XML é usado para mapear o nome
público de URL conhecido pelo cliente para o seu
próprio nome interno (<servlet-mapping>)
• Outro elemento XML é usado para mapear o seu
próprio nome interno para um nome de classe
(<servlet>)

Exemplo de código XML
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
<servlet>
<servlet-name>teste</servlet-name>
<servlet-class>teste.teste</servlet-class>
</servlet>
<servlet-mapping>
<url-pattern>/teste</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
</web-app>
O elemento <servlet>
informa ao container quais
arquivos de classe
pertencem a uma aplicação
em particular

<servlet>
</servlet>
<servlet-mapping>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
</web-app>
O elemento <servlet-name>
é usado para unir um
elemento <servlet> a um
elemento específico
<servlet-mapping>.
O usuário final NUNCA vê
este nome
Ele é usado somente em
outras partes do DDXML

<servlet>
</servlet>
<servlet-mapping>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
</web-app>
No elemento <servlet-
class> você insere o nome
da classe sem acrescentar a
extensão .class

<servlet>
</servlet>
<servlet-mapping>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
</web-app>
Considere o elemento
<servlet-mapping> como
aquilo que o container usa
na execução, quando uma
solicitação chega para
perguntar “qual servlet eu
devo chamar para esta URL
solicitada?”

<servlet>
</servlet>
<servlet-mapping>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
</web-app>
Isto é o que o cliente vê e
usa para chegar ao servlet,
mas este é um nome criado,
que NÃO é o nome
verdadeiro da classe do
servlet
Apenas para ficar mais
claro, neste exemplo o
nome da URL-PATTERN está
igual ao nome da classe,
entretanto observe que o
correto é utilizar-se de
outro nome

DD XML
• Além de mapear urls os DD XML ainda podem:
• Personalizar atribuições de segurança
• Páginas de erro
• Bibliotecas de tags
• Informações sobre a configuração inicial
• Acesso a enterprise javabeans específicos
• Etc
• Com isso, mesmo aqueles que não são programadores
java podem personalizar sua aplicação java
• O DD oferece um mecanismo declarado para a
customização das suas aplicações, sem tocar no código
fonte!
• VISUALIZANDO O DDXML NO NETBEANS

MVC em Servlets/JSPs
• View:
– Responsável pela
apresentação.
– A view pode ser
qualquer cliente
(celular, tv, tablet,
web, etc)
– Recebe o estado do
modelo do controlador
– Recebe os dados de
entrada do usuário
que volta do
controlador
– O JSP é o view

• Controller:
– Retira da solicitação
do usuário os dados
de entrada e
interpreta o que eles
significam par ao
modelo
– Obriga o modelo a se
atualizar e
disponibiliza o estado
do novo modelo para
a view
– O servlet é o
controlador

• Modell:
– Abriga a verdadeira
lógica e o estado do
modelo
– Conhece as regras
para obtenção e
atualização do estado
– É a única parte do
sistema que se
comunica com o
banco de dados
– A classe java comum
será o modelo

• MVC retira a lógica de
negócio para fora do
servlet e a coloca em
um modelo, uma antiga
classe plana e
reutilizável JAVA (classe
java normal).
• O modelo é a
combinação dos
dados de negócio e
os métodos que
operam nesses
dados

Container Web e Container EJB
• Container Web: usado para componentes web
como servlets e jsps. Tomcat é apenas um Container
Web e não uma aplicação J2EE completa, pois ele
não possui um Container EJB. O Apache é um
servidor HTTP que trabalha junto com o Tomcat
para aplicações não-EJB.
• Container EJB: usado para componentes de
negócios. Um servidor de aplicação J2EE incluit
tanto o Container Web quanto o Container EJB.
WebLogic e o Jboss são dois dos servidores EJB
mais comuns. Um servidor EJB completo incorpora
inúmeras específicações (servlets, jsp, j2ee, ejb,
etc).http://www.oracle.com/technetwork/java/javae
e/ejb/index.html

Exemplo
• Vamos desenvolver uma aplicação simples
usando JSP e Servlet com MVC
• A aplicação será uma especialista em
cervejas
• Os usuários poderão navegar na aplicação,
responder perguntas e receber conselhos

EXEMPLO
1. O cliente solicita a página
FORM.HTML

EXEMPLO
2. O container vai buscar a
página FORM.HTML

EXEMPLO
3. O Container retorna a
página ao browser, o usuário
responde às perguntas do
formulário

EXEMPLO
4. O browser envia os dados da
solicitação ao Container

EXEMPLO
5. O Container encontra o
servlet correto baseado na URL
e passa a solicitação para o
servlet

EXEMPLO
6. O servlet pede ajuda ao
BeerExpert (POJO)

EXEMPLO
7. A classe responsável retorna
uma resposta, a qual o servlet
adiciona ao objeto solicitação

EXEMPLO
8. O servlet encaminha a
solicitação ao JSP

EXEMPLO
9. O JSP recebe a resposta do
objeto solicitação

EXEMPLO
10. O JSP gera uma página para
o Container.

EXEMPLO
11. O Container retorna a
página par ao usuário

Como funciona o mapeamento
1. Ao preencher o formulário, o usuário clica no botão
enviar. O browser gera a URL de solicitação.
2. O Container procura o DD e encontra o servlet mapping
com o url pattern que coincide com o /SelectBeer.do. A
barra (/) representa a raíz do contexto da aplicação.
SelectBeer.do é o nome lógico de um recurso)
<servlet-mapping>
<servlet-name>Exemplo</servlet-name>
<url-pattern>/SelectBeer.do</url-pattern>
</servlet-mapping>

3. O Container vê que o servlet name para esta url pattern é
EXEMPLO. Este não é o nome verdadeiro de um arquivo
de classe servlet. EXEMPLO é o nome de um servlet, e
não de uma CLASSE servlet. Para o Container, servlet é
aquilo que foi definido no DD, abaixo da tag <servlet>. O
nome do servlet é simplesmente o nome usado no DD,
para que as outras partes do DD possam mapeá-lo.
<servlet>
<servlet-class>teste.SelectBeer</servlet-class>
</servlet>

4. O Container procura dentro das tags <SERVLET> a tag <SERVLET-
NAME>
5. O Container usa a <SERVLET-CLASS> da tag <SERVLET> para
descobrir que classe servlet é responsável por tratar esta solicitação.
Se o servlet não tiver sido inicializado, a classe é carregada e o
servlet é inicializado.
<servlet>
<servlet-class>teste.SelectBeer</servlet-class>
</servlet>
<servlet-mapping>
<url-pattern>/SelectBeer.do</url-pattern>
</servlet-mapping>

6. O Container inicia
uma nova thread
para tratar a
solicitação, e passar a
soliciação para a
thread (método
service do servlet)
7. O Container envia a
resposta de volta ao
cliente

Container gerencia servlets

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

Similaire à Container gerencia servlets

Similaire à Container gerencia servlets (20)

Plus de Elaine Cecília Gatto

Plus de Elaine Cecília Gatto (20)

Dernier

Dernier (20)

Container gerencia servlets