Servlets 2.5

1.476 visualizações

Publicada em

Mais uma apresentação antiga sendo compartilhada com vcs ....
Ela comenta um pouco de como é a especificação de Servlet

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.476
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
41
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Servlets 2.5

  1. 1. J2EE – JSP e Servlets[ Aula 2 ] Autor: Eduardo R. Carvalho email: ercarval@gmail.com
  2. 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. 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. 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. 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. 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. servlet2 thread A 2 thread b resposta solicitação solicitação resposta
  7. 7. Servlets – Diagrama de Classe
  8. 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. 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. 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. 11. Jspjsp jsp jspservlet servlet servlet servlet
  12. 12. 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.
  13. 13. Pattern Front ControllerProblema 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.
  14. 14. Front ControllerSoluçã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.
  15. 15. Front Controller • Diagrama de Classe
  16. 16. Front Controller• Diagrama de Seqüência
  17. 17. Application ControllerProblema 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çãoVocê 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.
  18. 18. Application ControllerSoluçã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.
  19. 19. Application Controller• Diagrama de Classes
  20. 20. Application Controller• Diagrama de Seqüência
  21. 21. 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.
  22. 22. 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
  23. 23. ServiceLocatorProblema 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.
  24. 24. ServiceLocatorForç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 anteriormenteSoluçãoUse 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.
  25. 25. ServiceLocatorDiagrama de Classe
  26. 26. ServiceLocatorpublic 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; }

×