Lincoln Souza Rocha, M.Sc.(lincolnrocha@gmail.com)

Padrões do Catálogo J2EE

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çõ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

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

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

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 message-driven 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

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

71

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

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

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

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

Lincoln Souza Rocha, M.Sc.(lincolnrocha@gmail.com)

Padrões do Catálogo J2EE