27
Autor: Eduardo R. Carvalho email: [email protected] J2EE – JSP e Servlets [ Aula 2 ]

Servlets 2.5

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: Servlets 2.5

Autor: Eduardo R. Carvalhoemail: [email protected]

J2EE – JSP e Servlets

[ Aula 2 ]

Page 2: Servlets 2.5

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

Page 3: Servlets 2.5

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).

Page 4: Servlets 2.5

Servlets – Ciclo de Vida

resposta

solicitação

servlet

servlet

service(solicitação,resposta)

thread

container

container

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

servlet

container

O usuário clica em um link que tem uma URL para um servlet.

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

Page 5: Servlets 2.5

Servlets – Ciclo de Vida

servlet

servlet

servlet

thread

doGet(solicitação,resposta)

container

resposta

XX

X

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

thread

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

Quando o metodo service() termina a thread morre ou retorna para o pool de threads gerenciadas pelo Container. As referencias dos obejtos solicitação e resposta saem do escopo e eles se dão mal ... (prontos para virarem lixo).O cliente obtém a resposta.

Page 6: Servlets 2.5

Servlets – Solicitação [Threads]

servlet

• Cada solicitação roda em uma thread separada ?

A Cada nova solicitação o container aloca uma Thread para atende-las. Cada Thread aloca novos objetos solicitação e resposta.

thread A

resposta

solicitação resposta

solicitação

thread b

Solicitação HTTP Solicitação HTTP

1

2

1

2

Page 7: Servlets 2.5

Servlets – Diagrama de Classe

Page 8: Servlets 2.5

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

3. public void init(ServletConfig config) throws ServletException {4. super.init(config);5. }

6. public void doGet(HttpServletRequest request, 7. HttpServletResponse response) 8. throws ServletException, IOException {9. response.setContentType(CONTENT_TYPE);10. PrintWriter out = response.getWriter();11. out.println("<html>");12. out.println("<head><title>MyServlet</title></head>");13. out.println("<body>");14. out.println("<p>The servlet has received a GET. This is the reply.</p>");15. out.println("</body></html>");16. out.close();17. }

18. public void doPost(HttpServletRequest request, 19. HttpServletResponse response)

throws ServletException, IOException {20. //comentado por motivos de espaço.. 21. }22. }

Page 9: Servlets 2.5

Servlets – web.xml [DD]

1. ... <?xml version = '1.0' encoding = 'windows-1252'?>

2. <servlet>3. <servlet-name> MyServlet </servlet-name>4. <servlet-class>5. br.com.meuteste.apresentacao.web.MyServlet6. </servlet-class>7. </servlet>8. <servlet-mapping>9. <servlet-name>MyServlet</servlet-name>10. <url-pattern>/myservlet</url-pattern>11. </servlet-mapping>12. <session-config>13. <session-timeout> 35</session-timeout>14. </session-config>15. <mime-mapping>16. <extension>html</extension>17. <mime-type>text/html</mime-type>18. </mime-mapping>19..... 20.</web-app>

nickName para seu Servlet

url que será disponibilizada para o servlet

Page 10: Servlets 2.5

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

Page 11: Servlets 2.5

jsp

servlet

jsp

servlet

jsp

servlet

Jsp

servlet

Page 12: Servlets 2.5
Page 13: 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.

Page 14: Servlets 2.5

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.

Page 15: Servlets 2.5

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.

Page 16: Servlets 2.5

Front Controller

• Diagrama de Classe

Page 17: Servlets 2.5

Front Controller

• Diagrama de Seqüência

Page 18: Servlets 2.5

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.

Page 19: Servlets 2.5

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.

Page 20: Servlets 2.5

Application Controller

• Diagrama de Classes

Page 21: Servlets 2.5

Application Controller

• Diagrama de Seqüência

Page 22: Servlets 2.5

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.

Page 23: Servlets 2.5

Command

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

Page 24: Servlets 2.5

ServiceLocator

ProblemaVocê 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.

Page 25: Servlets 2.5

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.

Page 26: Servlets 2.5

ServiceLocator

Diagrama de Classe

Page 27: Servlets 2.5

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; }