Padrões do Catálogo J2EE

Padrões do Catálogo J2EE
Lincoln Souza Rocha, M.Sc.
([email protected])

Livros
 Deepak Alur, John Crupi e Dan Malks. Core J2EE
Patters: Best Practices and Design Strategies,
Second Edition (2003). Ed. Prentice Hall PTR
 Bill Dudney, Stephen Asbury, Joseph K. Krozak e
Kevin Wittkopf. J2EE AntiPatterns (2003). Ed.
Wiley Publishing
2

Sites Web
 The J2EE 1.4 Tutorial (http://java.sun.com/j2ee/1
.4/download.html#tutorial)
 Argo Navis – Curso de Padrões de Design J2EE
(J931) (www.argonavis.com)
▪ OBS: Os slides do curso J931 de Helder L. S da Rocha
foram utilizados na confecção desse material
3
Parte I
4
O que é J2EE?
 Arquitetura e Componentes J2EE
 Containers J2EE

5
Acrônimo de Java 2 Enterprise Edition
 Uma plataforma da Sun Microsystems para
desenvolvimento de aplicações empresariais
distribuídas e multicamada
 É fundamentada no Java 2 Standard Edition
(J2SE)

6

Visão Geral
7

Camada Cliente
 Clientes Web (thin client)
▪ (1) Web Pages Dinâmicas: que são geradas por
componentes que executam na camada web
▪ (2) Web Browser: que exibem as páginas recebidas do
servidor
▪ Usualmente não fazem consultas à banco de dados, não
executam regras de negócios complexas ou se
conectam à aplicações legadas
8

Camada Cliente (cont.)
 Applets
▪ É uma pequena aplicação Java que executa na JVM
instalada no Web Browser
▪ Contudo, sistemas clientes provavelmente irão precisar
do Java Plugin e, possivelmente, de um arquivo de
política de segurança para poder executar o applet no
Web Browser
9

Camada Cliente (cont.)
 Aplicações Clientes (application clients)
▪ Executam na máquina cliente provendo um interface
para que os usuários executem suas tarefas
remotamente (rich client)
▪ Tipicamente possuem interfaces gráficas (GUI) feitas em
Swing ou Abstract Window Toolkit (AWT) API, mas
interfaces via linha de comando também são possíveis
10

Servidor J2EE
11

Servidor J2EE - Camada Web
12

Servidor J2EE - Camada Web (cont.)
 Os componentes web são criados usando a
tecnologia JSP (Java Server Pages)
▪ Servlets são classes criadas programaticamente e que
dinamicamente processam requisições e constrem uma
resposta
▪ Páginas JSP são documentos text-based que executam
como servlets mas com uma abordagem mais natural
para criar conteúdo estático
13

Servidor J2EE - Camada de Negócio
14

Servidor J2EE - Camada de Negócio (cont.)
 A camada de negócio é responsável por
implementar, via enterprise beans, a lógica de
negócio da aplicação referente à um domínio de
negócio particular (e.g., bancário, varejo e
Financeiro)
 Existem três tipos de Enterprise Beans
▪ Session Beans, Entity Beans e Message-driven Beans
15

Servidor J2EE - Camada de Negócio (cont.)
 Session Beans: representam a comunicação
transiente com o cliente. Quando o cliente finaliza
a execução, o session bean e seus dados também
são removidos da memória
16

Servidor J2EE - Camada de Negócio (cont.)
 Entity Beans: representam os dados persistentes
armazenados em uma tabela do banco de dados.
Se o cliente terminar a comunicação ou se o
servido for reiniciado o servidor garante que os
dados do entity bean é salvo
17

Servidor J2EE - Camada de Negócio (cont.)
 Menssage-driven Beans: combina características
de session beans e Java Message Service (JMS)
message listener, o que permite que este receba
mensagens JMS assincronamente
18

Camada de Sistema de Informação (EIS)
 O EIS representa a parte de software e hardware
da empresa e inclui sistema de infra estrutura,
servidor de processamento de transações , banco
de dados e sistemas de informação legados
19

Containers: O que são e para que servem?
 São a interface entre os componentes J2EE e as
funcionalidades de baixo nível da plataforma especifica
que suporta o componente
 Funcionam como um middleware abstraindo a arquitetura
de hardware e software subjacente
 A rigor existem quatro tipos de containers J2EE:
▪ Web container, EJB container, Application client container e Applet
container
20

Tipos de Container J2EE
21

Tipos de Container J2EE (cont.)
 Web container
▪ Gerencia a execução de páginas JSP e servlets de
aplicações J2EE. Web containers executam dentro do
servidor J2EE
 EJB container
▪ Gerencia a execução de enterprise beans de aplicações
J2EE. EJB containers executam dentro do servidor J2EE
22

Tipos de Container J2EE (cont.)
 Application client container
▪ Gerencia a execução de componentes da aplicação
cliente. Tanto a aplicação como o container executam
na máquina cliente
 Applet container
▪ Gerencia a execução de applets. É formado basicamente
por um Web Browser e o Java Plugin que executam
juntos na máquina cliente
23
Parte II
24

Procedimentos recomendados para
desenvolver aplicações J2EE. Divide as
aplicações em camadas
 Camada cliente: interface do usuário ou de
serviços. Tipicamente representa uma aplicação
independente ou browser rodando applets ou
páginas HTML
 Camada Web: consiste de servlets e páginas JSP
com o objetivo de capturar requisições e
processar respostas para a camada cliente
25
 Camada EJB: contém toda a lógica da aplicação e
representa o modelo de negócio implementado
em EJBs
 Camada de integração: contém lógica de acesso
ao EIS
 Camada de dados (EIS): consiste de sistemas de
bancos de dados, transações e outros recursos
legados
26

Soluções de design baseadas no J2EE
Blueprints
 Representam soluções consideradas melhores
práticas para implementar vários componentes
essenciais em cada uma das camadas
identificadas pelo J2EE Blueprints
 Usam e se baseiam em vários padrões GoF
27

São padrões de design e não de
implementação (idioms)
 Podem ser implementados usando tecnologias
diferentes (e.g., usando RMI ou CORBA)

Objetivos
 Reduzir o tráfego de rede, aumentando a
eficiência e facilitando a escalabilidade
 Reduzir o acoplamento entre as camadas e os
componentes
28

Não existe um só catálogo de padrões
 Este curso se baseia no catálogo do Sun Java
Center (SJC), cujos padrões estão documentados
no site da Sun e em livros como “Core J2EE
Patterns: Best Practices and Design Strategies”
 Os SJC J2EE Patterns são divididos em camadas
lógicas que refletem a organização dos J2EE
Blueprints
29

O catálogo atual (setembro/2003) define 21
padrões
 Camada de apresentação: 8 padrões
 Camada de negócios: 9 padrões
 Camada de integração: 4 padrões

Os nomes dos padrões são significativos
30
Padrões refletem soluções para problemas
genéricos descritos em abstrações de alto
nível
 Estratégias mostram formas de implementar
os padrões usando tecnologias e linguagens
de programação específicas

31
Um padrão geralmente possui diversas
diferentes estratégias de implementação
 Neste curso serão apresentados os padrões e
suas principais estratégias recomendadas
pelo SJC

32


Intercepting Filter
 Viabiliza pré- e pós-processamento de requisições
Front Controller
 Oferece um controlador centralizado para gerenciar o

processamento de uma requisição
Context Object
 Encapsula estado de forma independente de

protocolo para compartilhamento pela aplicação
Application Controller
 Centraliza e modulariza o gerenciamento de Views e
de ações
33


View Helper
 Encapsula lógica não-relacionada à formatação
Composite View
 Cria uma View composta de componentes

menores
Service To Worker e Dispatcher View
 Combinam Front Controller com um Dispatcher e
Helpers. O primeiro concentra mais tarefas antes
de despachar a requisição. O segundo realiza mais
processamento depois
34

Business Delegate
 Desacopla camadas de apresentação e de serviços

Service Locator
 Encapsula lógica de consulta e criação de objetos
de serviço

Session Facade
 Oculta complexidade de objetos de negócio e
centraliza controle
35

Application Service
 Centraliza e agrega comportamento para oferecer
uma camada de serviços uniforme

Business Object
 Separa dados de negócios e lógica usando modelo

de objetos
Composite Entity
 Implementa Business Objects persistentes
combinando Entity beans locais e POJOs (Plain
Old Java Objects)
36

Transfer Object
 Antigamente chamado de Value Object ou DTO
 Reduz tráfego e facilita transferência de dados entre

camadas
Transfer Object Assembler
 Antigamente chamado de Value Object Assembler
 Constrói um Value Object composto de múltiplas

fontes
Value List Handler
 Lida com execução de queries, caching de resultados,
etc.
37

Data Access Object
 Abstrai fontes de dados e oferece acesso transparente

aos dados
Service Activator
 Facilita o processamento assíncrono para

componentes EJB
Domain Store
 Oferece um mecanismo transparente de persistência

para objetos de negócio
Web Service Broker
 Expõe um ou mais serviços usando XML e protocolos
Web
38
39



Procure no catálogo um padrão que realize o
objetivo desejado
 Tabela de padrões
 Roadmap
Roadmap associa intenção com padrões
 "Se você procura por isto... use os padrões tais"
Consulte o padrão desejado e analise
 Analise o problema que ele resolve
 Analise a solução que ele propõe
 Escolha uma estratégia e implemente
40

Padrões se encaixam bem quando é
necessário alterar uma arquitetura para
melhorar algum aspecto de um sistema
 Performance
 Escalabilidade
 Reuso e manutenção

A maior parte dos padrões foram construídos
visando esse tipo de evolução
41
Parte III
42
Introdução
 Front Controller

43


A camada de apresentação encapsula toda a
lógica relacionada com a visualização e
comunicação com a GUI
 Requisições e respostas HTTP
 Gerenciamento de sessão HTTP
 Geração de HTML, JavaScript e recursos lado-cliente
Principais componentes: Servlets e JSP
 JSP é indicado para produzir interface do usuário
 Servlets são indicados para processar dados recebidos
e concentrar lógica de controle
44
45

Objetivo
 Centralizar o processamento de requisições em
uma única fachada. Front Controller permite criar
uma interface genérica para processamento de
comandos
46

Problema
47

Descrição do problema
 Deseja-se um ponto de acesso centralizado para
processamento de todas as requisições recebidas
pela camada de apresentação para
▪ Controlar a navegação entre os Views
▪ Remover duplicação de código
▪ Estabelecer responsabilidades mais definidas para cada
objeto, facilitando manutenção e extensão: JSP não
deve conter código algum ou pelo menos não código de
controle
48

Descrição do problema (cont.)
 Se um usuário acessa um View sem passar por um
mecanismo centralizado, código de controle é
duplicado e misturado ao código de apresentação
▪ Também não é possível controlar a navegação: cliente
pode iniciar em página que não deveria ter acesso
49

O que se deseja? (Forças)
 Evitar a duplicação de lógica de controle
 Aplicar lógica comum para múltiplas requisições
 Separar a lógica de processamento do sistema da
View
 Centralizar o controle de pontos de acesso do
sistema
50

Solução
51

Descrição da solução
 Controlador é ponto de acesso para
processamento de requisições
▪ Chama serviços de segurança (autenticação e
autorização)
▪ Delega processamento à camadas de negócio
▪ Define um View apropriado
▪ Realiza tratamento de erros
▪ Define estratégias de geração de conteúdo
52

Descrição da solução (cont.)
 O controlador pode delegar processamento a
objetos Helper (Comandos ou ações, Value Beans,
etc.)
 Solução depende do uso de um Application
Controller
▪ Usado para redirecionar para o View correspondente
53

Processamento de uma requisição
 Envolve dois tipos de atividades
▪ Manuseio da requisição
▪ Processamento do View
 Durante o manuseio da requisição, é preciso
realizar diversas atividades:
▪
▪
▪
▪
Manuseio de protocolo e transformação de contexto
Navegação e roteamento
Processamento do serviço
Repasse da requisição
54

Diagrama de classes
FrontController: ponto de entrada para manuseio de requisições
ApplicationController: gerencia de ações e views
Command: encapsula uma ação específica para requisição
View: representa a página retornada ao cliente
55
56

Estratégias de implementação
 Servlet Front Strategy
▪ Implementa o controlador como um servlet
 Command and Controller Strategy
▪ Interface baseada no padrão Command (GoF) para
implementar Helpers para os quais o controlador delega
responsabilidades via Application Controller
▪ Esta é a estratégia mais comum
 Logical Resource Mapping Strategy
▪ Requisições são feitas para nomes que são mapeados a
recursos (páginas JSP, servlets) ou comandos (web.xml)
▪ Multiplexed Resource Mapping Strategy usa wildcards para
selecionar recursos a serem processados: *.do
57

Conseqüências
 Controle centralizado
▪ Facilidade de rastrear e logar requisições
 Melhor gerenciamento de segurança
▪ Requer menos recursos. Não é preciso distribuir pontos
de verificação em todas as páginas
▪ Validação é simplificada
 Melhor possibilidade de reuso
▪ Distribui melhor as responsabilidades
58

Padrões relacionados
 J2EE Patterns
▪ Intercepting Filter
▪ Application Controller
▪ View Helper
▪ Dispatcher View and Service to Worker
59
Parte IV
60


Introdução
Transfer Object
61

A camada de negócios encapsula a lógica
central da aplicação. Considerações de
design incluem
 Uso de session beans para modelar ações.
Stateless para operações de um único método.
Stateful para operações que requerem mais de um
método (que retém estado entre chamadas)
 Uso de session beans como fachadas à camada de
negócios
62
 Uso de entity beans para modelar dados
persistentes como objetos distribuídos
 Uso de entity beans para implementar lógica de
negócio e relacionamentos
 Eventos e operações assíncronas com messagedriven beans
 Cache de referências para EJBs em Business
Delegates
63
64

Objetivo
 Reduzir a quantidade de requisições necessárias
para recuperar um objeto. Transfer Object
permite encapsular em um objeto um
subconjunto de dados utilizável pelo cliente e
utilizar apenas uma requisição para transferi-lo
65

Problema
66

Descrição do problema
 Cliente precisa obter diversos dados de um
Business Object
 Para obter os dados, é preciso realizar diversas
chamadas ao componente
▪ As chamadas são potencialmente remotas
▪ Fazer múltiplas chamadas através da rede gera tráfego e
reduz o desempenho da aplicação
67

Solução
68

Descrição da solução
 Uma única chamada remota é necessária para
transferir o Transfer Object
▪ O cliente pode extrair as informações de interesse através de
chamadas locais
 Cópia do cliente pode ficar desatualizada
▪ Transfer Object é solução indicada para dados read-only ou
informações que não são alteradas com freqüência, ou ainda,
quando as alterações não são críticas (não afetam o processo)
 Objeto alterado pode ser enviado de volta ao servidor
69

Diagrama de classes
Client: geralmente um componente de outra camada.
Component: qualquer componente de outra camada que o cliente usa para enviar e
receber dados.
TransferObject: é um POJO (Plain Old Java Object) serializável que contém atributos
suficientes para agregar e carregar todos os dados
70
71

Estratégias de implementação
 Updatable Transfer Objects Strategy
▪ Permite a transferência de um objeto para o cliente, a
alteração do objeto pelo cliente e sua devolução ao
servidor
 Multiple Transfer Objects Strategy
▪ Permite a criação de Transfer Objects diferentes a partir
de uma mesma fonte
72

Estratégias de implementação (cont.)
 Entity Inherits Transfer Object Strategy
▪ Entity Bean herda de uma classe de Transfer Object
 Transfer Object Factory Strategy
▪ Suporta a criação dinâmica de Transfer Objects
73

Conseqüências
 Simplifica Entity Bean e interface remota
 Transfere mais dados em menos chamadas
 Reduz tráfego de rede
 Reduz duplicação de código
 Pode introduzir objetos obsoletos
 Pode aumentar a complexidade do sistema
▪ Sincronização
▪ Controle de versões para objetos serializados
74

Padrões relacionados
 J2EE Patterns
▪ Session Facade
▪ Transfer Object Assembler
▪ Value List Handler
▪ Composite Entity
75
Parte V
76
Introdução
 Data Access Object

77

A camada de integração encapsula a lógica
relacionada com a integração do sistema com
a camada de informação distribuída (EIS)

É acoplada com a camada de negócios
sempre que esta camada precisar de dados
ou serviços que residem na camada de
recursos (dados)
78

Os componentes nesta camada podem usar
tecnologias de acesso aos serviços
específicos que isolam (JDBC, JMS,
middleware proprietário, etc.)
79
80

Objetivo
 Abstrair e encapsular todo o acesso a uma fonte
de dados. O DAO gerencia a conexão com a fonte
de dados para obter e armazenar os dados
81

Problema
82

Descrição do problema
 Forma de acesso aos dados varia
consideravelmente dependendo da fonte de
dados usado
▪ Banco de dados relacional
▪ Arquivos (XML, CSV, texto, formatos proprietários)
▪ LDAP
83

Descrição do problema (cont.)
 Persistência de objetos depende de integração
com fonte de dados (ex: business objects)
▪ Colocar código de persistência (ex: JDBC) diretamente
no código do objeto que o utiliza ou do cliente amarra o
código desnecessariamente à forma de implementação
▪ Ex: difícil passar a persistir objetos em XML, LDAP, etc.
84

Solução
85

Descrição da solução
 Data Access Object (DAO) oferece uma interface
comum de acesso a dados e esconde as
características de uma implementação específica
▪ Uma API: métodos genéricos para ler e gravar
informação
▪ Métodos genéricos para concentrar operações mais
comuns(simplificar a interface de acesso)
86

Descrição da solução (cont.)
 DAO define uma interface que pode ser
implementada para cada nova fonte de dados
usada, viabilizando a substituição de uma
implementação por outra
 DAOs não mantêm estado nem cache de dados
87

Diagrama de classes
Client: objeto que requer acesso a dados: Business Object, Session Façade, Application Service,
Value List Handler, ...
DataAccessObject: esconde detalhes da fonte de dados
DataSource: implementação da fonte de dados
Data: objeto de transferência usado para retornar dados ao cliente. Poderia também ser usado para
receber dados.
ResultSet: resuldados de uma pesquisa no banco
88
89

Estratégias de implementação
 Custom DAO Strategy
▪ Estratégia básica. Oferece métodos para criar, apagar,
atualizar e pesquisar dados em um banco
▪ Pode usar Transfer Object para trocar dados com
clientes
90

Estratégias de implementação (cont.)
 DAO Factory Method Strategy
▪ Utiliza Factory Methods em uma classe para recuperar
todos os DAOs da aplicação
 DAO Abstract Factory Strategy
▪ Permite criar diversas implementações de fábricas
diferentes que criam DAOs para diferentes fontes de
dados
91

Conseqüências
 Transparência quanto à fonte de dados
 Facilita migração para outras implementações
▪ Basta implementar um DAO com mesma interface
 Reduz complexidade do código nos objetos de
negócio (ex: Entity Beans BMP)
92

Conseqüências (cont.)
 Centraliza todo acesso aos dados em camada
separada
▪ Qualquer componente pode usar os dados (servlets,
EJBs)
 Camada adicional
▪ Pode ter pequeno impacto na performance
 Requer design de hierarquia de classes (Factory)
93

Padrões relacionados
 J2EE Patterns
▪ Transfer Object
▪ Transfer Object Assembler
▪ Value List Handler
 GoF
▪ Factory Method
 POSA - 1
▪ Broker
94
Padrões do Catálogo J2EE
Lincoln Souza Rocha, M.Sc.
([email protected])