SlideShare uma empresa Scribd logo
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
Servlets 2.5
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.
Application Controller
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.
Application Controller
• Diagrama de Classes
Application Controller
• Diagrama de Seqüência
Application Controller
• 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;
  }

Mais conteúdo relacionado

Semelhante a Servlets 2.5

Te aula2
Te aula2Te aula2
Te aula2
rafaeljrssg
 
Servlets
ServletsServlets
Curso de Servlets
Curso de ServletsCurso de Servlets
Curso de Servlets
Marcelo Gonçalves
 
Servlets e jsp
Servlets e jspServlets e jsp
Servlets e jsp
Alan Oliveira
 
servlet-introducao
servlet-introducaoservlet-introducao
servlet-introducao
Fábio Nogueira de Lucena
 
Servlet jsp tomcat 8
Servlet jsp tomcat 8Servlet jsp tomcat 8
Servlet jsp tomcat 8
maxrosan
 
Apostilava Java EE 5 - 2007
Apostilava Java EE 5 - 2007Apostilava Java EE 5 - 2007
Apostilava Java EE 5 - 2007
Rafael Benevides
 
Te servelts
Te serveltsTe servelts
Te servelts
rafaeljrssg
 
Cactus - Testes em J2EE com Jakarta Cactus
Cactus - Testes em J2EE com Jakarta CactusCactus - Testes em J2EE com Jakarta Cactus
Cactus - Testes em J2EE com Jakarta Cactus
Denis L Presciliano
 
Trabalho ProgramaçãO Comercial Ii
Trabalho ProgramaçãO Comercial IiTrabalho ProgramaçãO Comercial Ii
Trabalho ProgramaçãO Comercial Ii
Mateus Ramos Pereira
 
Programação para Web II: Estrutura de um projeto Java Web
Programação para Web II: Estrutura de um projeto Java WebProgramação para Web II: Estrutura de um projeto Java Web
Programação para Web II: Estrutura de um projeto Java Web
Alex Camargo
 
Java Web - MVC básico com JSP e Servlets
Java Web - MVC básico com JSP e ServletsJava Web - MVC básico com JSP e Servlets
Java Web - MVC básico com JSP e Servlets
Eduardo Mendes
 
Servlets e JSP
Servlets e JSPServlets e JSP
Servlets e JSP
Daniel Brandão
 
Filtros
FiltrosFiltros
padrao de projeto2
padrao de projeto2padrao de projeto2
padrao de projeto2
Walney Negreiros
 
Mvc model view controller - java para desenvolvimento web
Mvc   model view controller - java para desenvolvimento webMvc   model view controller - java para desenvolvimento web
Mvc model view controller - java para desenvolvimento web
Valdir Junior
 
Java RMI
Java RMIJava RMI
365on Lab - Asp.Net MVC
365on Lab - Asp.Net MVC365on Lab - Asp.Net MVC
365on Lab - Asp.Net MVC
Alexsandro Almeida
 
Introdução ao desenvolvimento web com Java
Introdução ao desenvolvimento web com JavaIntrodução ao desenvolvimento web com Java
Introdução ao desenvolvimento web com Java
FellipeFonseca
 
Criando APIs com Node e TypeScript
Criando APIs com Node e TypeScriptCriando APIs com Node e TypeScript
Criando APIs com Node e TypeScript
Andre Baltieri
 

Semelhante a Servlets 2.5 (20)

Te aula2
Te aula2Te aula2
Te aula2
 
Servlets
ServletsServlets
Servlets
 
Curso de Servlets
Curso de ServletsCurso de Servlets
Curso de Servlets
 
Servlets e jsp
Servlets e jspServlets e jsp
Servlets e jsp
 
servlet-introducao
servlet-introducaoservlet-introducao
servlet-introducao
 
Servlet jsp tomcat 8
Servlet jsp tomcat 8Servlet jsp tomcat 8
Servlet jsp tomcat 8
 
Apostilava Java EE 5 - 2007
Apostilava Java EE 5 - 2007Apostilava Java EE 5 - 2007
Apostilava Java EE 5 - 2007
 
Te servelts
Te serveltsTe servelts
Te servelts
 
Cactus - Testes em J2EE com Jakarta Cactus
Cactus - Testes em J2EE com Jakarta CactusCactus - Testes em J2EE com Jakarta Cactus
Cactus - Testes em J2EE com Jakarta Cactus
 
Trabalho ProgramaçãO Comercial Ii
Trabalho ProgramaçãO Comercial IiTrabalho ProgramaçãO Comercial Ii
Trabalho ProgramaçãO Comercial Ii
 
Programação para Web II: Estrutura de um projeto Java Web
Programação para Web II: Estrutura de um projeto Java WebProgramação para Web II: Estrutura de um projeto Java Web
Programação para Web II: Estrutura de um projeto Java Web
 
Java Web - MVC básico com JSP e Servlets
Java Web - MVC básico com JSP e ServletsJava Web - MVC básico com JSP e Servlets
Java Web - MVC básico com JSP e Servlets
 
Servlets e JSP
Servlets e JSPServlets e JSP
Servlets e JSP
 
Filtros
FiltrosFiltros
Filtros
 
padrao de projeto2
padrao de projeto2padrao de projeto2
padrao de projeto2
 
Mvc model view controller - java para desenvolvimento web
Mvc   model view controller - java para desenvolvimento webMvc   model view controller - java para desenvolvimento web
Mvc model view controller - java para desenvolvimento web
 
Java RMI
Java RMIJava RMI
Java RMI
 
365on Lab - Asp.Net MVC
365on Lab - Asp.Net MVC365on Lab - Asp.Net MVC
365on Lab - Asp.Net MVC
 
Introdução ao desenvolvimento web com Java
Introdução ao desenvolvimento web com JavaIntrodução ao desenvolvimento web com Java
Introdução ao desenvolvimento web com Java
 
Criando APIs com Node e TypeScript
Criando APIs com Node e TypeScriptCriando APIs com Node e TypeScript
Criando APIs com Node e TypeScript
 

Servlets 2.5

  • 1. J2EE – JSP e Servlets [ Aula 2 ] Autor: Eduardo R. Carvalho email: ercarval@gmail.com
  • 2. 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
  • 3. 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).
  • 4. 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.
  • 5. 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.
  • 6. 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
  • 8. 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. }
  • 9. 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>
  • 10. 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
  • 11. Jsp jsp jsp jsp servlet servlet servlet servlet
  • 13. 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.
  • 14. 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.
  • 15. 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.
  • 16. Front Controller • Diagrama de Classe
  • 18. 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.
  • 19. Application Controller 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.
  • 22. Application Controller • 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.
  • 23. 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
  • 24. 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.
  • 25. 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.
  • 27. 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; }