J2EE - JSP e Servlets

J2EE – JSP e Servlets
[ Aula 2 ]
Autor: Eduardo R. Carvalho
email: ercarval@gmail.com

Agenda
• Introdução Servlets
• Ciclo de Vida Objetos
• Meu Primeiro Servlet
• Entendendo o descritor de distribuição (DD)
– Design Patterns
• Front Controller
• Application Controller
• Command
• Singleton
• ServiceLocator

Servlets
• Servlets vivem para servir clientes. A função de um
servlet é receber uma solicitação do cliente e
devolver uma resposta. A solicitação talvez seja
simples: "traga-me a pagina de Boas Vindas !!". Ou
pode ser complexa "Finalize o meu processo de
carrinho de compras." A solicitação traz consigo
dados cruciais o código do seu servlet tem de saber
como encontrá-los e utilizá-los.
• A resposta leva a informação necessária para o
Browser saber montar a pagina e o código do seu
servlet tem que saber como enviá-los. Ou não ... em
vez disso, seu servlet pode decidir encaminhar a
solicitação adiante (para outra pagina, servlet ou
JSP).

Servlets – Ciclo de Vida
O usuário clica em um link
que tem uma URL para um
servlet servlet.

container

O container “vê” que a
solicitação é para um
resposta servlet servlet e cria dois objetos:
1. HttpServletRequest
(solicitação)
container solicitação 2. HttpServletResponse
(resposta)

O container encontra o
servlet correto baseado na
ULR da solicitação, cria
servlet uma thread para a
solicitação e chama o
thread
metodo service() do
service(solicitação,resposta) servlet, passando como
container
argumentos os objetos
solicitação e resposta.

Servlets – Ciclo de Vida
O Metodo service() descobre qual
metodo do servlet chamar baseado
no método HTTP(GET,POST,etc.)
servlet enviado pelo cliente. O cliente envia
uma solicitação HTTP GE, para que o
metodo service() chame o metodo
doGet() do servlet, passando os
doGet(solicitação,resposta)
objetos solicitação e resposta.

O servlet usa o objeto resposta para
escrever a retornar para o cliente. A
servlet resposta volta através do Container.

resposta
thread

Quando o metodo service() termina
a thread morre ou retorna para o
servlet pool de threads gerenciadas pelo
Container. As referencias dos
X obejtos solicitação e resposta saem

container X X thread do escopo e eles se dão mal ...
(prontos para virarem lixo).
O cliente obtém a resposta.

Servlets – Solicitação [Threads]
• Cada solicitação roda em uma thread separada ?

Solicitação HTTP Solicitação HTTP A Cada nova solicitação o
1 1 container aloca uma Thread
para atende-las.
Cada Thread aloca novos
objetos solicitação e
resposta.
servlet
2 thread A 2
thread b

resposta solicitação solicitação resposta

Servlets – Diagrama de Classe

Servlet – Meu Servlet !!!
• public class MyServlet extends HttpServlet {
• private static final String CONTENT_TYPE = "text/html; charset=windows-1252";

• public void init(ServletConfig config) throws ServletException {
• super.init(config);
• }

• public void doGet(HttpServletRequest request,
• HttpServletResponse response)
• throws ServletException, IOException {
• response.setContentType(CONTENT_TYPE);
• PrintWriter out = response.getWriter();
• out.println("<html>");
• out.println("<head><title>MyServlet</title></head>");
• out.println("<body>");
• out.println("<p>The servlet has received a GET. This is the reply.</p>");
• out.println("</body></html>");
• out.close();
• }

• public void doPost(HttpServletRequest request,
• HttpServletResponse response)
throws ServletException, IOException {
23. //comentado por motivos de espaço..
24. }
25. }

Servlets – web.xml [DD]
• ... <?xml version = '1.0' encoding = 'windows-1252'?>

• <servlet>
• <servlet-name> MyServlet </servlet-name>
• <servlet-class>
• br.com.meuteste.apresentacao.web.MyServlet
• </servlet-class>
• </servlet> nickName para
• <servlet-mapping> seu Servlet
• <servlet-name>MyServlet</servlet-name>
• <url-pattern>/myservlet</url-pattern>
• </servlet-mapping> url que será
• <session-config> disponibilizada para
• <session-timeout> 35</session-timeout> o servlet
• </session-config>
• <mime-mapping>
• <extension>html</extension>
• <mime-type>text/html</mime-type>
• </mime-mapping>
• ....
• </web-app>

Exercícios
• Seguindo o modelo já comentado anteriormente de MVC 2 em
que e servlet é o responsável execução da ação recebendo os
dados da requisição, vamos criar um servlet para remover os
códigos contidos na pagina de login.jsp
• Criar o Servlet LoginAction que tenha o mesmo comportamento
da pagina jsp

Jsp
jsp jsp jsp

servlet servlet servlet servlet

Design Patterns
• O que é um Padrão (Pattern) ?
– Define padrão como uma solução permanente para um
problema em um contexto. Contexto é o ambiente ,
circunstancias, situação ou condições interdependentes
dentro do qual algo existe.

• O que é uma Estratégia ?
- Os padrões são descritos em um nível alto de
Abstração. Ao mesmo tempo cada padrão inclui várias
estratégias que fornecem detalhes de implementação
em diversos níveis de abstração.
- Os padrões estão descritos em um nivel mais alto de abstração.
- Os padrões incluem a maioria das implementações recomendadas ou mais comuns
como estratégia.
- As estratégias fornecem um ponto de flexibilidade para cada padrão.Os
desenvolvedores descobrem ou inventam novas maneiras de implementar os padrões.
- As estratégias promovem uma comunicação melhor, fornecendo nomes para aspectos
de níveis mais baixos de uma determinada solução.

Pattern Front Controller
Problema
Você deseja um ponto de acesso centralizado para tratamento da solicitação da
chamada de apresentação
O Sistema requer um ponto de acesso centralizado para tratamento da
solicitação. Sem um ponto de acesso central, o código de controle que
é comum em todas as solicitações duplicado em vários locais, como
dentro das varias visualizações. Quando o código de controle é
misturado com o código de criação da visualização, a aplicação fica
menos modular e coesa.

Além disso, o controle distribuído é mais difícil de se manter e uma
única alteração de código poderá exigir que as alterações sejam feitas
em vários lugares.

Forças
– Você deseja evitar que a lógica de controle seja duplicada.
– Você deseja aplicar uma lógica comum a diversas solicitações.
– Você deseja separar a lógica de processamento do Sistema da visualização.
– Você deseja centralizar os pontos de acesso controlados no Sistema.

Front Controller
Solução
Use um Front Controller como ponto inicial de contato para tratar todas as solicitações
relacionadas. O Front Controller centraliza a lógica de controle, a qual, de outro modo,
poderia ser duplicada, e gerencia as atividades de tratamento de solicitações principais.

Normalmente o Padrão Front Controller utiliza um Application Controller, que é
responsável pelos gerenciamentos de ação a uma solicitação.
– Gerenciamento de ação refere-se à localização e ao roteamento de ações
especificas que servirão a uma solicitação.
– Gerenciamento de visualização refere-se à localização e distribuição, para
visualização apropriada. Embora esse comportamento possa ser incorporado
ao Front Controller, particionando-o em classes separadas como parte de um
Padrão Application Controller, melhora a modularidade, a capacidade de
manutenção e a reutilização.

Estratégia de implementação, Commnad and Controller

O Application Controller descreve o uso geral dos comandos para executar o
gerenciamento de ação como parte de sua Estratégia Command Handler. Usar um
gerenciador de comandos como um Front Controller é denominado Estratégia “The
Command and Controller”.
O uso do Padrão Command (GOF) fornece uma interface generica para os objetos
Helper que prestam serviço a um solicitação. Isso minimiza o acoplamento entre
os componentes e fornece um mecanismo flexivel que facilmente extensível para
os desenvolvedores adcionarem comportamentos de manipulação de solicitação.

Front Controller

• Diagrama de Classe

Front Controller
• Diagrama de Seqüência

Application Controller
Problema
Você deseja centralizar e modular o gerenciamento de ação e visualização.
Na camada de visualização, existem normalmente duas decisões a serem
tomadas na chegada de cada requisição.
- A solicitação de entrada (requisição) deve ser resolvida para uma ação
que serve à solicitação. Isso é denominado gerenciamento da ação.
- A visualização apropriada é localizada e distribuída. Isso é denominado
gerenciamento da visualização
Você pode encapsular o gerenciamento de ação e da visualização em
diferentes partes da aplicação.Embutir este comportamento dentro de
um Front Controller centraliza esta funcionalidade, mas a medida que a
aplicação cresce torna o código mais complexo, é uma boa idéia mover
esse comportamento para um conjunto de classes, melhorando a
capacidade de criação de módulos, reutilização e extenção.
Forças
– Você deseja reutilizar o código de gerenciamento de ação e visualização.
– Você deseja melhorar a extensibilidade do tratamento de solicitação, como
por exemplo, adicionar incrementalmente funcionalidade de caso de uso a
uma aplicação
– Você deseja melhorar a modularidade e a capacidade de manutenção de um
código, tornando mais fácil de estender a aplicação e testar partes diferentes
do código de tratamento de solicitação independente do container Web.

Solução
Use um Application Controller para centralizar a recuperação e a chamada dos
componentes de processamento de solicitação, como comandos e visualizações.

Na camada de apresentação, você mapeia os parâmetros de solicitação de entrada
para especificar as classes de processamento da solicitação e visualiza os
componentes que tratam cada solicitação.

O gerenciamento da ação localiza e chama as ações para tratar as solicitações
especificas, enquanto o gerenciamento de visualização navega e distribui para
visualização apropriada ou para o mecanismo de geração de visualização.
Embora um Front Controller atue como um ponto de acesso centralizado e
controlador para solicitações de entrada, o mecanismo para identificar e chamar
comandos, e para identificar e distribuir para visualizações pode ser dividido em
seu próprio conjunto de componentes.
A separação desse código do Front Controller oferece vários benefícios. Primeiro, ele
separa esse comportamento de gerenciamento de solicitação básico do código
especifico do protocolo do Front Controller. Isso melhora a modularidade do
sistema, além de melhorar a capacidade de reutilização. Certos componentes do
Application Controller podem ser reutilizados para tratar solicitações a partir de
vários canais, como uma aplicação ou um serviço Web.
Nota: Os principais aspectos do tratamento de solicitação, como
validação,tratamento de erro,autenticação e controle de acesso, podem ser
facilmente conectados em um mecanismo de tratamento de solicitação de é
centralizado e modularizado dessa maneira.

• Diagrama de Classes

• Diagrama de Seqüência

• Explicando o Diagrama
– Client
• Chama o Application Controller, podendo ser um FrontController
ou um InterceptingFilter.
– ApplicationController
• Usa o Mapper para resolver a solicitação de entrada para a ação
e a visualização apropriadas, para qual ele delega ou distribui.
– Mapper
• Usa um Map para converter uma solicitação de entrada na ação
e na visualização apropriada. Um Mapper atua como fabrica.
– Map
• Mantém referências aos tratamentos que representam recursos
de destino. Os mapas podem ser realizados como uma classe ou
um registro
– Target
• Um recurso que ajuda a preencher uma solicitação especifica,
incluindo comandos, visualizações e folhas de estilo.

Command
• Diagrama de Classe
Tem a finalidade de desacoplar o
executor da ação.
Fazendo com que execute
comandos / ações de maneira
transparente para o cliente

ServiceLocator
Problema
Você deseja localizar de maneira transparente os componentes e serviços de negócios
uniformemente.
Os clientes de aplicações J2EE precisam localizar componentes serviços da
camada de negócios ou integração. Por exemplo, quando os
componentes de integração necessitam obter fontes de dados JDBC.
Eles geralmente são definidos em um repositório (registro) central. Os
Clientes usam a API JNDI (Java Naming and Directory Interface) para
interagir e com esse registro e obter um InitialContext que
armazena o nome do componente para a vinculação de objetos.
Quando você implementa um mecanismo de pesquisa nos seus clientes,
lida com vários componentes relacionados à complexidade e à
duplicação do código, degradação de desempenho e dependência de
fornecedor.
Outro problema é que o InitialContext e outras fábricas de contexto
registradas no registro JNDI são implementações dadas pelo
fornecedor.Se os Clientes da aplicação acessarem as implementações
especificas de tais objetos, isso acarretará uma dependência do produto
ou do fornecedor na aplicação e tornará o código não portável.

ServiceLocator
Forças

• Você deseja usar a API de JNDI para pesquisar e usar componentes de negócio
ou de integração, como DataSources ( Pool de Conexões JDBC).
• Você deseja centralizar e reutilizar a implementação de mecanismos para
pesquisa de clientes de aplicações J2EE.
• Você deseja encapsular as dependências de fornecedor para implementações de
registro e ocultar a dependência e complexidade de outros clientes.
• Você deseja evitar um overhead de desempenho relacionado a criação de
contexto inicial e às pesquisas de serviços.
• Você deseja restabelecer uma conexão a uma instancia de EJB acessada
anteriormente

Solução
Use um ServiceLocator para implementar e encapsular o serviço e a pesquisa de
componente . Ele oculta os detalhes de implementação do mecanismo de
pesquisa e encapsula as dependências relacionadas.

Um ServiceLocator normalmente é implementado como um Singleton,uma única
instancia da classe ServiceLocator na Memória da VM.

ServiceLocator

Diagrama de Classe

ServiceLocator
public class ServiceLocator {
private static ServiceLocator me;
private InitialContext ic;
private Map cache; //used to hold references to EJBHomes/JMS Resources for re-use

/**
* Creates a new ServiceLocator object.
* @throws ServiceLocatorException DOCUMENT ME!
*/
private ServiceLocator() throws ServiceLocatorException {
try {
ic = new InitialContext();
cache = Collections.synchronizedMap(new HashMap());
} catch (NamingException ne) {
throw new ServiceLocatorException(ne);
} catch (Exception e) {
throw new ServiceLocatorException(e);
}
}

/**
* Retrieves Singleton Instance for ServiceLocator
* @return ServiceLocator serviceLocator
*/
public synchronized static ServiceLocator getInstance() {
try {
if (me == null) {
me = new ServiceLocator();
}
} catch (ServiceLocatorException se) {
se.printStackTrace(System.err);
}
return me;
}

J2EE - JSP e Servlets

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie J2EE - JSP e Servlets

Ähnlich wie J2EE - JSP e Servlets (20)

J2EE - JSP e Servlets