JPA - Java Persistence API

Esta página é uma compilação das pesquisas realizadas por duas equipes
A primeira pesquisa foi realizada por Edcarlos Ferreira, Rodrigo Oliveira e Tiago Pena em 2007-2
A segunda pesquisa foi realizada por Vinícius Dalmolin, Djalma e Felipe em 2007-2


pesquisa realizada por Edcarlos Ferreira, Rodrigo Oliveira e Tiago Pena em 2007-2

Java Persistence API(JPA) é a especificação para gerenciamento de persistência e mapeamento objeto relacional. Criada para diminuir a complexidade no desenvolvimentos de aplicações JEE e Java SE que utilizam dados persistentes, com uma completa especificação para realizar o mapeamento objeto relacional, utilizando annotations da linguagem Java (Java SE 5.0 ou superior). Suporta, também a uma rica linguagem de consulta, semelhante a SQL.

O conceito principal relacionado a API JPA é o de entidade. Uma entidade corresponde a um objeto que pode ser gravado na base de dados através de um mecanismo de persistência. A classe que implementa a entidade persistente é um POJO.

Para utilizar JPA, deve-se escolher um provedor JPA, ou seja, uma implementação da API. A JPA é uma API para frameworks, tendo-se como implementação de referência o Oracle TopLink Essentials. Existem outros provedores JPA no mercado, como o Hibernate Entity Manager, Bea Kodo eo Apache JPA.

1392494035_a4d76e44c7_o.jpg
1392494017_00fb56fffa_o.gif
1392494009_8b489eeb7b_o.gif
1392494025_7c52dd1b1d_o.gif

Provedores JPA.


Persistência Leve

Define-se como persistência, a informação que "vive" fora do programa que a criou. É largamente utilizado em sistemas de grande porte e de alta complexidade, por exemplo, GUI que necessitam armazenar preferências dos usuários nas diversas invocações dos programas, em aplicações web, etc.

A persistência leve, consiste no armazenamento e recuperação de dados, com o mínimo esforço de programação. Por exemplo, utilizando-se serialização, estamos implementando persistência leve, pois na serialização é feita a persistência de objetos java diretamente em arquivos com esforço mínimo, mas de robustez mínima, se comparado com outros mecanismos disponíveis de persistência.

Mecanismos de Persistência

Os desenvolvedores necessitam realizar persistência dos seus objetos e são muitas as opções: JDBC, Serialização, JDO, Ferramentas de Mapeamento Objeto/Relacional. Em meio a tantas opções, surge a pergunta: Por que JPA? Pra quê mais um framework??? Abaixo fazemos um comparativo e tentamos chegar as respostas.

  • Serialization é muito fácil de usar, mas muito limitado também. Faz persistência dos objetos em arquivos ou os envia pela rede, mas não trabalha com grandes volumes de dados. Não possuem nenhum suporte a integridade e nem acesso concorrente aos dados, ou seja, não é nenhum pouco recomendável, pois não suporta as operações mais triviais de persistência de dados.
  • Utilizado pela maioria dos desenvolvedores, a API JDBC manipula dados persistentes em bancos de dados relacionais. JDBC cobre muita das carências encontradas na Serialização: com ela é possível tratar grande volumes de dados, possui mecanismos de integridade dos dados, suporta acesso concorrente, e tem uma sofisticada linguagem de consulta em SQL. A desvantagem da JDBC é a grande dificuldade encontrada na sua utilização. O paradigma relacional usado pela JDBC não foi desenvolvido para armazenar objetos, e por esta razão somos forçados a abandonar a programação orientada a objetos e diversos trechos do código.
  • Existem diversos softwares comerciais que realizam o mapeamento entre os objetos e os bancos de dados relacionais(ORM). Estes frameworks permitem que o desenvolvedor se concentre no modelo de objetos, deixando de lado a péssima combinação do paradigma orientado a objetos com a o paradigma relacional. O problema começa quando se percebe o fato de que cada software comercial, possui a sua própria API, tornando o seu código amarrado a essa API e a um único fornecedor. O fornecedor pode aumentar os preços, não fornecer as possíveis correções as falhas, além de tornar mais difícil migrar para outras tecnologias sem ter de reescrever todo o código.
  • Em alternativa aos problemas com o ORM, algumas empresas desenvolveram um tipo de banco de dados específicos para armazenar objetos. Estes Banco de dados de Objetos (ODB's) oferecem muito mais facilidades de utilização que os ORM´s. O Grupo de Gerenciamento de Bancos de Dados de Objetos, o (ODMG), foi formado para criar uma API padrão para acesso a bancos de dados de objetos; poucos fornecedores de ODB's seguem as recomendações do ODMG. Muitas companhias hesitam em mudar do velho e bom sistema relacional para o relativamente desconhecido banco de dados de objetos. Poucas ferramentas de análise de dados estão disponíveis para sistemas de bancos de dados de objetos, fora a vastíssima quantidade de dados já armazenados nos velhos bancos de dados relacionais. Assim os ODBś não correspondem as expectativas dos seus criadores.
  • A Edição Enterprise, da plataforma java, apresenta a entidade Enterprise Java Beans. Entidades EJB 2.x são componentes que representam a informação persistente em repositório de dados. Como as soluções ORM, entidades EJB fornecem uma visão orientada a objetos de dados persistentes. Diferentemente dos ORM, as entidades EJB 2.x, não se limitam apenas aos bancos de dados relacionais; a informação persistente que eles representam podem vir de EIS (Enterprise Information System) ou de qualquer outro dispositivo de armazenamento. Também, as entidades EJB 2.x utiliza um padrão estrito, tornando-os portável entre os fornecedores. O problema encontrado com o padrão EJB 2.x, é que ele é um tanto quanto limitado nos conceitos orientados a objetos que pode representar. Características avançadas como herança, polimorfismo e relações complexas estão ausentes. Adicionalmente, as entidades EJB 2.x, são difíceis de codificar e exigem servidores parrudos e bastante caros para rodar.
  • A especificação JDO utiliza uma API bastante similar a JPA. JDO, entretanto, suporta bancos de dados não-relacionais, uma característica que alguns discutem diluir a especificação.

JPA combina as melhores características dos diversos mecanimos de persistência. Criar entidades sob JPA é simples como serializar classes. JPA suporta grandes conjuntos de dados, consistência dos dados, uso concorrente, capacidade de consultas do JDBC. Assim como os ORM's e os JDO's, JPA permite o uso dos conceitos avançados de orientação a objetos como herança. JPA evita ficar preso a um único fornecedor por confiar em uma especificação estrita, como entidades EJB 2.x e JDO. JPA foca em bancos de dados relacionais. E como JDO, é muito fácil de usar.

JPA não é ideal para toda aplicação. Mesmo sendo uma tentadora alternativa para outros mecanismos de persistência.


Gerenciador de Entidades e Ciclo de Vida de um Objeto Persistente

A necessidade de propagar o estado de um objeto da memória para o banco de dados, torna necessária a interação entre a aplicação e a camada de persistência. Com a JPA, essa tarefa é realizada chamando o gerenciador de persistência, conhecido também como gerenciador de entidades(Entity Manager), responsável por quase todas as operações sobre objetos persistentes.

Relacionado, também a esta especificação, existe o conceito de contexto persistente(Persistence Context), que é uma área de memória onde se encontram os objetos persistentes. Na interação com o mecanismo de persistência, faz-se necessário para a aplicação ter conhecimento sobre os estados do ciclo de vida da persistência.

A persistência possibilita que o objeto(estado) continue a existir mesmo após a destruição do processo que o criou em uma aplicação orientada a objetos, sendo armazenado em disco, podendo ser recriado no futuro em outro objeto. Quatro estados compõem o ciclo de vida de uma entidade: new, managed, removed e detached, ver figura abaixo:

1460125260_80d84b758b_o.gif

Um objeto no estado new é definido a partir do operador new e que não possui um valor para o seu identificador persistente.

Já em um objeto no estado managed é aquele que tem um valor para o seu identificador persistente e está associado a um contexto de persistência. Assim o Gerenciador de Entidades fará com que a base de dados seja atualizada com os novos valores dos atributos persistentes no final da transação.

O estado removed, refere-se a objetos associados a um contexto de persistência, mas que estão marcados para exclusão na base de dados no final da transação, permanecendo nesse estado.

Finalmente, também existem objetos que se encontram no estado detached, que possuem registros correspondentes na base de dados, mas sem associação com um contexto de persistência.


Compiladores vs. JPA

Ao realizarmos um cross-check com os conceitos relativos aos compiladores e a JPA, percebemos a utilização de diversas técnicas.

O primeiro ponto a ser observado é o processo de tradução existente da própria compilação realizada por se tratar de uma especificação da linguagem de programação Java, existe também a tradução do texto-fonte escrito na linguagem Java para outra linguagem de alto nível, a linguagem SQL. Essa tradução é realizada através de um conceito de compilação, que utiliza a XML e annotations como meta-linguagem, fazendo com que o fonte em Java puro, gere código-objeto executado em qualquer SGBD relacional baseado na linguagem SQL.


Referências e Equipe

Referências

  • Hibernate.org
            • Site de um provedor de implementação da JPA. Ferramenta free e com boa documentação.
  • Screencast JPA by Caelum
          • Pequeno vídeo nos formatos .flv(Flash, para ver no browser) e no formato do quick time, que demonstra a construção de uma pequena aplicação utilizando JPA.
  • JPA no Wikipedia
                  • Enciclopedia Wiki, com muitas informações sobre JPA e correlatos.
  • Bea Docs
                          • Outra implementação da JPA, com bastante documentação e um how-to muito rico.

Orkut us

Team


pesquisa realizada por Vinícius Dalmolin, Djalma e Felipe em 2007-2

JPA – Java Persistence API

JPA na realidade é uma API, um conjunto de Interfaces que descrevem como trabalhar com o mapeamento objeto relacional.O JPA é um framework utilizado na camada de persistência para o desenvolvedor ter uma maior produtividade, com impacto principal num modo para controlarmos a persistência dentro de Java. Pela primeira vez, nós, desenvolvedores temos um modo "padrão" para mapear nossos objetos para os do Banco de Dados. Persistência é uma abstração de alto-nível sobre JDBC.

Objeto/Relacional (ORM)

Mapeamento objeto/relacional é automatizado (e transparente) persistência de objetos em aplicações Java para tabelas em um banco de dados relacional, usando metadata que descreve o mapeamento entre os objetos e o banco de dados.

• Mecanismo sofisticado para mapeamento de objetos Java em memória, para tabelas do banco de dados
• Permite persistir objetos em banco de dados relacionais
• Permite pesquisas complexas
• Permite debug e auditoria(log) das operações entre a aplicação e o banco de dados

JPA Requisitos de persistência

• Simplificação do modelo de programação e publicação
• Melhoria de desempenho do ambiente de execução
• Criação de clientes de testes usando entidades independentes dos containers
• Modelagem de domínio permitindo herança e polimorfismo
• Mapeamento Objeto/Relacional
• Melhoria das capacidades de pesquisa

Padronizando a persistência com o EJB3 JPA

EJB3 JPA está padronizando o meio de persistir os dados através dos objetos POJOS. POJO é um acrônimo para Plain Old Java Objects que é principalmente usado para denotar um objeto Java que não segue nenhum tipo de modelo de objetos, convenções ou frameworks.
A especificação EJB declara um modelo de programação POJO que encapsula a regra de negócio da aplicação e define os EJB3 Session beans como POJOS através das anotações marcadas nestes beans. Com isso, uma entity é nada mais nada menos que um objeto de negócio, com poucas responsabilidades, que foi marcada através de anotações para ser remota/local, de sessão ou de persistência. Como qualquer POJO, uma entity pode ser tanto uma classe abstrata quanto uma concreta e podendo herdar as características de outro POJO.
Com isso, as entities agora não ficam limitadas aos módulos EJB podendo então serem invocadas e testadas fora de um contêiner EJB (por exemplo, um contêiner WEB) e sem a necessidade de um session bean façade.
O EJB3 JPA padroniza a forma do mapeamento objeto relacional através das anotações e de descritores XML, permitindo assim uma maior flexibilidade para o desenvolvedor e sem a necessidade de pesadas configurações

JPA Modelo de programação

Entidade é o objeto que pode ser gravado pelo mecanismo de persistência.
• Toda entidade tem de ter um construtor sem argumentos
• Toda entidade tem de ter uma chave primária
• Chave primária pode ser simples ou composta
• Chave primária pode ser mapeada para campo ou propriedade
• Entidades não associadas a um contexto de persistência
• Tem de implementar interface Serializable se o objeto desacoplado tem de ser enviado via rede
• Não há mais necessidade do padrão de desenho DTO

Ciclo de Vida de Entidade

• New
– Criada usando a palavra-chave new
– Não tem id persistente
• Managed
– Tem um id persistente associado a um contexto de persistência
• Removed
– Tem um id persistente associado a um contexto de persistência
– Está escalonada para ser excluída do banco de dados
• Detached
– Tem um id persistente, mas não está associada com um contexto de persistência

Fonte de Pesquisa:
- http://www.hibernate.org
- http://www.mundooo.com.br
- http://www.jeebrasil.com.br

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License