Your SlideShare is downloading. ×
Desenvolvendo Produtos Com Java EE
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Desenvolvendo Produtos Com Java EE

1,014

Published on

Técnicas e padrões de arquitetura

Técnicas e padrões de arquitetura

Published in: Technology, Travel
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,014
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
44
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Desenvolvendo produtos com Java EE Técnicas e padrões de arquitetura Fábio Ramon Senac-SP
  • 2. Objetivos e conteúdo
    • Apresentar padrões de arquitetura para o desenvolvimento de produtos na plataforma JEE
    • Conteúdo
      • Produto X Sistema
      • Requisitos Gerais
      • Padrões de arquitetura
      • Frameworks
      • Conclusão
  • 3. Produtos versus Sistemas
    • Clientes heterogêneos X Cliente específico
      • Independente do ambiente operacional
      • Independente da plataforma
        • Servidor de aplicação
        • Banco de dados
      • Independente da topologia
        • DMZ
        • Cluster / Load Balance
      • Look & feel plugável
  • 4. Produtos versus Sistemas
    • Clientes heterogêneos X Cliente específico
      • Flexível quanto às soluções de terceiros
        • Frameworks
        • Softwares de integração
        • Softwares de comunicação
      • Flexível e conciso quanto às questões de segurança
      • Maior independência possível com relação a padrões de arquitetura
  • 5. Produtos versus Sistemas
    • Pontos chaves
      • Se um produto deve ser:
        • Flexível
        • Independente
        • Eficiente
      • Então o produto necessita:
        • De uma arquitetura robusta
        • Ser extremamente modularizável
        • Ser facilmente extensível
  • 6. Requisitos gerais de um produto
    • Multiplataforma
    • Escalável
    • Independente do servidor de aplicação e do banco de dados
    • Independente de frameworks
    • Não ser construído sobre outro produto específico
    • Sua homologação não dependa da homologação de outros produtos ou bibliotecas
  • 7. Requisitos gerais de um produto
    • Padrões fortes de segurança (autenticação, autorização e auditoria)
    • Mecanismo flexível e amigável de log
    • Fácil usabilidade
    • Interface gráfica totalmente customizável
  • 8. Conseqüências dos requisitos gerais
    • Versão da linguagem Java: 1 ou 2 anterior à versão corrente
    • Utilizar somente SQL ANSI
    • Não se apoiar em características específicas de nenhum servidor de aplicação ou web container
    • Trabalhar com os principais frameworks MVC, de inversão de controle e de persistência
  • 9. Conseqüências dos requisitos gerais
    • Implementar mecanismos eficientes de configuração
    • Implementar log e traces finos
    • Em resumo:
      • Mais código
      • Mais controle
      • Menos recursos de programação disponíveis
  • 10. Padrões de arquitetura
    • Emprego extensivo de interfaces
    • Todas as instanciações por fábricas abstratas
    • Wrappers, proxies e/ou adaptadores para os serviços de todos os frameworks empregados
    • Desacoplamento entre módulos
  • 11. Padrões de arquitetura
    • Camadas de software bem definidas
      • Apresentação
        • Visualização
        • Controle
        • Databind
      • Negócio
        • Serviços
        • Entidades
      • Persistência
  • 12. Um modelo de arquitetura de produto
  • 13. Características do modelo
    • Classes em azul: superclasses de infra-estrutura da aplicação
    • Classes em amarelo: fábricas da infra-estrutura
    • Classes em branco: templates de classes da aplicação
  • 14. Características do modelo
    • Camadas da aplicação:
      • MODELO (MVC)
      • CONTROLE (MVC)
      • VISUAL (MVC)
      • FACHADA (Adaptador ou Wrapper do negócio)
      • SERVIÇO (lógica de negócio)
      • ACESSO DADOS (objetos de negócio e utilitários de acesso a dados)
  • 15. Emprego de interfaces Classe da aplicação Interface da aplicação
  • 16. Emprego de interfaces
    • Possibilita desacoplar componentes
    • Permite trocar implementação para solução específica do cliente
    • Permite introduzir um proxy para um serviço externo ou remoto como implementação
    • Facilita desenvolvimento em paralelo dos diferentes módulos
  • 17. Fábricas abstratas
  • 18. Fábricas abstratas
    • HomeFactory gera as implementações das fábricas
      • Configurado por XML
    • Implementações podem ser quaisquer:
      • Instanciadores comuns
      • Fábricas de frameworks (Spring, etc.)
      • Homes de EJBs
    • Implementações podem fazer a injeção de dependência
  • 19. Desacoplamento entre módulos Dados Intranet Web Internet XML Repositório de dados Acesso aos dados Componentes de negócio Regras de apresentação Conteúdo estático Cliente magro App SOAP
  • 20. Desacoplamento entre módulos
    • Dois tipos de módulos:
      • Módulos do produto
      • Módulos específicos da instalação
    • Módulos específicos podem ser incorporados ao produto
    • Montar uma instalação específica consiste em configurar quais módulos pertencem a ela
  • 21. Conclusão (parte 1)
    • Desenvolver um produto com Java EE implica atender uma série de requerimentos de arquitetura que não costumam surgir no desenvolvimento de um sistema dedicado. Além das implicações básicas tais como independência do banco de dados e de plataforma, surgem outras necessidades que vão desde a maior flexibilidade nas integrações com outros sistemas, até oferecer um leque maior de tecnologias e frameworks dos quais o produto possa depender.
  • 22. Conclusão (parte 2)
    • Adotar padrões de arquitetura que permitam, por exemplo, intercambiar frameworks de persistência de dados, garante que o produto possa atingir um mercado maior, sem esbarrar em questões de padrões e políticas permitidos ou não no ambiento do cliente.
  • 23. Dúvidas
    • Obrigado
      • [email_address]

×