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
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
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 - 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 (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 (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
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ções33
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
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
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
Objetivo Centralizar o processamento de requisições em
uma única fachada. Front Controller permite criar uma interface genérica para processamento de comandos
46
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
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
55
FrontController: ponto de entrada para manuseio de requisiçõesApplicationController: gerencia de ações e viewsCommand: encapsula uma ação específica para requisiçãoView: representa a página retornada ao cliente
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
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 message-driven beans
Cache de referências para EJBs em Business Delegates
63
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
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
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
70
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
72
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
73
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
74
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
75
Padrões relacionados J2EE Patterns
▪ Session Facade▪ Transfer Object Assembler▪ Value List Handler▪ Composite Entity
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
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
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
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
88
Client: objeto que requer acesso a dados: Business Object, Session Façade, Application Service, Value List Handler, ...DataAccessObject: esconde detalhes da fonte de dadosDataSource: implementação da fonte de dadosData: 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
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