Padrões do Catálogo J2EE. Lincoln Souza Rocha, M.Sc.

Transcrição

1 Padrões do Catálogo J2EE Lincoln Souza Rocha, M.Sc.

2 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

3 Sites Web The J2EE 1.4 Tutorial ( Argo Navis Curso de Padrões de Design J2EE (J931) ( OBS: Os slides do curso J931 de Helder L. S da Rocha foram utilizados na confecção desse material 3

4 Parte I 4

5 O que é J2EE? Arquitetura e Componentes J2EE Containers J2EE 5

6 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

7 Visão Geral 7

8 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

9 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

10 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

11 Servidor J2EE 11

12 Servidor J2EE - Camada Web 12

13 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

14 Servidor J2EE - Camada de Negócio 14

15 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

16 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

17 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

18 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

19 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

20 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

21 Tipos de Container J2EE 21

22 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

23 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

24 Parte II 24

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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 39

40 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

41 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

42 Parte III 42

43 Introdução Front Controller 43

44 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 45

46 Objetivo Centralizar o processamento de requisições em uma única fachada. Front Controller permite criar uma interface genérica para processamento de comandos 46

47 Problema 47

48 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

49 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

50 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

51 Solução 51

52 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

53 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

54 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

55 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 56

57 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

58 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

59 Padrões relacionados J2EE Patterns Intercepting Filter Application Controller View Helper Dispatcher View and Service to Worker 59

60 Parte IV 60

61 Introdução Transfer Object 61

62 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

63 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 64

65 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

66 Problema 66

67 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

68 Solução 68

69 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

70 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 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 72

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 73

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 74

75 Padrões relacionados J2EE Patterns Session Facade Transfer Object Assembler Value List Handler Composite Entity 75

76 Parte V 76

77 Introdução Data Access Object 77

78 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

79 Os componentes nesta camada podem usar tecnologias de acesso aos serviços específicos que isolam (JDBC, JMS, middleware proprietário, etc.) 79

80 80

81 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

82 Problema 82

83 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

84 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

85 Solução 85

86 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

87 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

88 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 89

90 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

91 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

92 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

93 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

94 Padrões relacionados J2EE Patterns Transfer Object Transfer Object Assembler Value List Handler GoF Factory Method POSA - 1 Broker 94

95 Padrões do Catálogo J2EE Lincoln Souza Rocha, M.Sc.