Facade
17] { O padr~ao de projeto Web Interceptor pode ser considerado umacustomizac~ao do Facade para sistemas Web. De fato, eles possuem muitas carac- ter sticas em comum e possuem intenc~oes similares: prover uma interface de acesso unica aos componentes do sistema
Front Controller
1] { Este padr~ao de projeto J2EE dene um componente quefunciona como ponto inicial de contato ao sistemaWeb. Mas a principal diferenca em relac~ao ao Web Interceptore que o Front Controllerpossui logica para decidir que componente deve receber a requisic~ao, enquanto que o Interceptador apenas repassa a requisic~ao de acordo com congurac~oes por ele carregadas
Intercepting Filter
1] { O Web Interceptor tem um comportamento similar aeste padr~ao de projeto J2EE, ja que ambos tem como objetivo realizar algum processamento antes da execuc~ao da operac~ao propriamente dita. A diferenca e que o Intercepting Filter n~ao funciona como ponto de entrada para todos os componentes do sistema, eles s~ao apenas acoplados aos servlets para realizar um pre-processamento.
2.2
Web Handlers
Contexto
Em sistemasWeb baseados no modelo de pedido-resposta e comum existirem diferentes requisic~oes (pedidos) gerando dinamicamente a mesma pagina HTML como resposta. Esta situac~ao pode ser percebida em um exemplo bem simplicado de sistema bancario que possui apenas as operac~oes de credito e debito em conta corrente, alem de uma operac~ao de login no sistema. O funcionamento deste e especicado atraves do mapa navegacional da Figura 2.5, que usa a notac~ao de Diagrama de Estados de UML 25], onde as operac~oes s~ao desenhadas como eventos e as paginas HTML (din^amicas ou estaticas) como estados.
De fato, analisando a gura percebe-se que as operac~oes Debito, CreditoeLogin,
apesar de serem operac~oes distintas, geram como resposta de sua execuc~ao a mesma pagina (Menu de Movimentac~oes). Este fato, apesar de exemplicado com um menu
principal, ocorre em diversas outras situac~oes.
Figura 2.5: Mapa navegacional simples do sistema bancario.
Outra situac~ao comum em sistemas desta natureza e termos uma mesma requisic~ao gerando diferentes respostas, dependendo da origem da requisic~ao ou do resultado do de seu processamento. Para exemplicar esta situac~ao, considere que o cliente, alem de realizar movimentac~oes em conta (debito e credito), pode fazer atualizac~oes em seu cadastro. A Figura 2.6 exemplica bem a situac~ao em que a mesma operac~ao, Login, e
executada a partir de contextos diferentes (Pagina de Login 1ePagina de Login 2)
e deve gerar uma sa da espec ca (Menu de Atualizac~aoe Menu de Movimentac~oes)
dependendo da origem da requisic~ao. Estas duas paginas de login possuem o conteudo bem diferente pois elas est~ao em contextos distintos e n~ao possuem relac~ao direta.
As situac~oes ilustradas pelas Figuras 2.5 e 2.6 s~ao bastante comuns em sistemasWeb
n~ao triviais. Estas geralmente trazem problemas de implementac~ao, como duplicac~ao e complexidade do codigo, quando n~ao e aplicada uma estruturac~ao de componentesWeb
adequada ao problema (veja Sec~ao 4.3). Em situac~oes onde a mesma pagina pode ser gerada como resultado da execuc~ao de diferentes requisic~oes (Ilustrado pela Figura 2.5) e comum ocorrer duplicac~ao de codigo relativo a montagem desta pagina em cada um dos
Figura 2.6: Mapa navegacional completo do sistema bancario.
componentes que tratam as requisic~oes. Ja emsituac~oes onde uma mesmaoperac~ao pode gerar diferentes paginas como resultado de seu processamento (Ilustrado pela Figura 2.6) e comum haver um aumento na complexidade de implementac~ao do componente que executa a requisic~ao, ja que este precisa decidir que resposta apresentar, alem de possuir o codigo relativo a montagem de cada uma das paginas de resposta gerada por ele.
Problema
Evitar a duplicac~ao de codigo e complexidade na estruturac~ao de sistemas Web com relacionamento M:N entre a apresentac~ao e o processamento.
Forcas
Evitar a duplicac~ao do codigo referente a montagem da apresentac~ao. Evitar a duplicac~ao do codigo de processamento da requisic~ao.
N~ao tornar o codigo do componente Web mais complexo quando a quantidade de
operac~oes que geram a mesma pagina de sa da aumenta.
N~ao tornar o codigo do componenteWebmais complexoquando aumenta o numero
de paginas de sa da poss veis para a mesma operac~ao.
Soluc~ao
A soluc~ao e baseada na construc~ao de entidades denominadas handlers. Existem dois tipos destes: Handlers de Apresentac~ao e Handlers de Processamento. Os primeiros
cont^em apenas codigo relativo a montagem das paginas din^amicas e os outros possuem codigo (ou chamadas) relativo a execuc~ao da logica de negocio. Com esta estruturac~ao e necessario criar umhandler de processamento para cada operac~ao do sistema e um de apresentac~ao para cada pagina din^amica.
Cada requisic~aoWeb dispara uma execuc~ao do lado do servidor que dinamicamente associa um par dehandlers(um de apresentac~ao e um de processamento) para responder ao cliente. Esta composic~ao din^amica e determinada por um par^ametro da requisic~ao do cliente. A entidade responsavel pela montagem deste par e delegac~ao da requisic~ao primeiro para o handler de processamento e depois para o de apresentac~ao e o
Con-
trolador de Handlers
, que e especicado com mais detalhes nas Sec~oes Estrutura e Implementac~ao.Oshandlersde processamento, alem de conterem chamadas as operac~oes do sistema, possuem codigo responsavel pela validac~ao dos dados vindos do cliente Web, e codigo responsavel pela preparac~ao dos dados para seu par de apresentac~ao.
Os handlers de apresentac~ao tambem possuem validac~ao de dados, alem de codigo de montagem das paginas din^amicas. Esta validac~ao e necessaria porque estes precisam validar os dados gerados pelo seu pares, ja que eles s~ao entidades independentes e podem ser compostos de diferentes formas.