arquiteturas de persistência com java · tradição visual basic, delphi, oracle forms sql...

Globalcode – Open4Education1

Arquiteturas de Persistência com Java

Renato [email protected]

http://diamond-powder.blogspot.com


Agenda

>Old School: SQL & JDBC

>ORM: Mapeamento Objeto Relacional

>JPA: Padrão para ORM

>Dificuldades na Adoção de ORM

>Persistência com EJB

>Conclusões


Agenda



>JPA: Pardão para ORM



>Conclusões


Old School: SQL & JDBC

>SQL: Fácil e Confiável

>SQL é muito popular

>Diversos profissionais falam SQL

>Desenvolvedores

>Analistas

>DBAs

>Controle sobre o que acontece no BD

Edgar Frank Codd



>JDBC

>Padrão de conectividade com BD Relacionais

>Existe desde o Java 1.1

>Suporta

>Comandos SQL

>Procedures

>Metadados

>A 1ª. API de muitos programadores Java.

>Drivers JDBC até para BD não relacionais.



>JDBC

API JDBC (java.sql)

Aplicação Java

driver tipo 1 driver tipo 2

RDBMS

driver tipo 3 driver tipo 4

driver ODBC client nativo

broker



>Desvantagens:

>Baixa produtividade

>Baixa portabilidade de BD

>Cada BD tem um sabor de SQL

>Mudança no BD = manutenção no SQL

>Mudança de nomenclatura = manut. no SQL


Agenda






>Conclusões


ORM: Mapeamento Objeto Relacional>Mark L. Fussel 1997 - Foundations of ObjectRelational Mapping

>www.chimu.com/publications/objectRelational/

Pure Relational

Light Object Mapping

Medium Object Mapping

Full Object Mapping

Object Server Banco de dados OO

Soluções ORM consagradas

design pattern Data Acces Object (DAO)

tradição Visual Basic, Delphi, Oracle Forms

SQL automático, cache local

transparênciaherançapolimorfismocomposições“persistence byreachability”


ORM: Mapeamento Objeto Relacional

Ligth/Medium

/FullO

bjectMapping

RDBMSJD

BC

objetos

objetos

statements

resultsets


ORM: Mapeamento Objeto Relacional

>Alguns Sabores de ORM em Java

>Hibernate (Core)

>iBatis

>Java Persistence API – JPA (JSR 220/317)

>Java Data Objects - JDO (JSR 243)> abstrações para diversos tipos de repositórios, além do modelo JDBC / banco relacional

>Entity Bean CMP (JSR 19/153) †


ORM: Mapeamento Objeto Relacional>Modelo OO : Modelo Relacional

>Classe : Tabela

>Objeto : Linha

>Atributo : Coluna

>Método : N/A

>Associação : Chave Estrangeira

>Herança : 3 modelagens clássicas

>Single Table

>Joined Subclasses

>Table per Class

>Mapeamento via XML e/ou via Annotations


ORM: Exemplo com Annotations JPA


Agenda






>Conclusões


JPA: Padrão para ORM

Aplicação Java

JPA

Provedor JPA

JDBC

Driver JDBC

RDBMS

Top Link EssentialsHibernate Entity Manager

BEA KodoApache Open JPA

MySQLPostgresOracleJava DB...


JPA: Padrão para ORM

Aplicação Java

JPA

Provedor JPA

JDBC

Driver JDBC

RDBMS

Todos os provedores

obedecem ao padrão de API e

de técnicas de mapeamento

Cada provedor pode oferecer featuresproprietárias


Agenda






>Conclusões


Dificuldades na Adoção de ORM

>O DBA não quer, os comandos SQL já estão otimizados...

> otimização de SQL deve ser a exceção, e não a regra;

> JPA permite o uso de queries nativas;

> Hibernate permite o uso de comandos DML nativos;

DBA

Programador Java


Dificuldades na Adoção de ORM>Desconfiamos do SQL gerado automaticamente ...

> acompanhe o SQL gerado

> via logs

> via ferramentas – ex: Hibernate Tools


Dificuldades na Adoção de ORM>O banco de dados utiliza stored procedures...

> de novo, stored procedures devem ser a exceção> é viável conviver com algumas chamadas a procedures> as procedures são a regra geral ?

> seu fornecedor de banco de dados agradece !> seu gerente de TI já ouviu falar em TCO ?



>JDBC direto é mais performático ...

>Já tivemos problemas de desempenho com frameworkORM ...

> Estude melhor seu framework:

>Mecanismos de Cache;

>Estratégias de recuperação Lazy / Eager



>O Banco de Dados estámal normalizado, não encaixa em nosso modelo de classes ...

> O Hibernate, por exemplo, possui vários recursos para conviver com bancos de dados mal normalizados;

> Distorcer um pouco o modelo de classes não é proibido;

>Errar é humano, insistir no erro... Normalize seu banco de dados !


Agenda






>Conclusões


Persistência com EJB

>EJB não é uma API de persistência

>EJB é um modelo para componentes de negócio distribuídos

>Vários tipos de aplicações clientes podem utilizar as mesmas regras de negócio;

>Infra-estrutura do Container de EJBs>Segurança, Controle Transacional, Escalabilidade

>Acesso a Recursos Computacionais Corporativos

>Padrão de Mercado para Componentes de Negócio


serviço de

diretóriosLDAP


>EJBs são componentes de negócio que funcionam em um Middleware, o container de EJBs

containerde

EJBs

EIS

RDBMS

container web

webbrowser

servidor de

mensagensJMS JCA

HTTP

RMI JNDI

RDBMSRDBMS

JDBCoutras

palataformas SOAP

RMI/IIOP

REST



>Evite utilizar seu banco de dados como Middlewarede integração

RDBMS

Aplicação X Aplicação Y

Aplicação Z




> EJBs suportam vários mecanismos para integrar com aplicações, mesmo que externas à rede local

containerde

EJBs

JMS

SOAP

REST

JCA

RMI


servidor de

mensagens



> Containers de EJBs possuem gerenciadores de transações distribuídas (two-phase commit)

containerde

EJBs

EIS

RDBMS

JMSJCA

RDBMSRDBMS

JDBC




>Containers EJB >= 3 oferecem suporte JPA embutido

containerde

EJBs RDBMSRDBMS

RDBMS

JPA JDBC




>EJBs minimizam a necessidade de Stored Procedures

Aplicação X

Aplicação Y

Aplicação Z

Aplicação W

containerde

EJBs RDBMSRDBMS

RDBMS

JPA JDBC



>Arquiteturas com EJBs são S.O.A. !

>SOA = Service Oriented Architecture>Arquiteturas Orientadas a Serviços>Serviços:

>possuem fortes contratos de software: entradas, saídas, exceções;>são encapsulados: expõem apenas comportamentos definidos no contrato;>são fracamente acoplados, podem ser substituídos desde que mantenham o contrato;

>EJBs podem ser facilmente transformados em WebServices


Agenda






>Conclusões


Conclusões

>Onde Estávamos:>Arquiteturas “Pure-Relational” ou “Data-Driven”

>Baixa produtividade “old-school”

>Banco de Dados = middleware de integração

>Stored Procedures = camada de serviços

>Dependência de fornecedor de banco de dados


Conclusões

>Aqui Estamos:

> Maturidade de Frameworks ORM, apesar de resistência cultural

> Aumento da produtividade

> Potencial dependência de Frameworks ORM

> SQL / Procedures / JDBC considerados para situações muito particulares

> Middlewares de Integração (ex: EJB Container)

> S.O.A.


Conclusões

>Aqui Estamos:>Bancos Relacionais mantém sua importância no ambiente corporativo, porém as arquiteturas “Pure-Relational” ou “Data-Driven” estão obsoletas;>Arquiteturas baseadas em ORM e EJB/SOA diminuem o TCO e são mais ágeis e competitivas para reagir às evoluções do negócio.


Conclusões

> Para Onde ?>Bancos de Dados OO ?

>Web 3.0 ?> Web Semântica

> RDF / SPARQL


Para refletir...

> Você está em um ambiente de desenvolvimento:

>“old-school” ?

>“pure-relational” ?

>“data-driven” ?

> E está se conformando ?


Para refletir...

> Desenvolvedor:

> os ventos do mercado estão a seu favor !

> faça alguma coisa !


Perguntas e Respostas

arquiteturas de persistência com java · tradição visual basic, delphi, oracle forms sql...

Documents