Tutorial – Aplicações Multicamadas

Parte I – Lógica de Negócios

Agosto, 2008

Oscar A. Konno Sampaio

Descrição do Sistema
Iremos construir um sistema de loja de e-comerce para a loja ACME.
Partiremos de um modelo simples apenas com as entidades básicas para
demonstrar os princípios do desenvolvimento de aplicações multicamadas.

Não será dado muitos detalhes sobre a camada Web já que a mesma foi
estudada na disciplina Linguagens e Padrões Web.

Casos de Uso
Para este curso, iremos inicialmente desenvolver os mesmos exemplos
utilizados na disciplina anterior, porém agora utilizando os conceitos de
camadas.

Os casos de uso a serem implementados serão na primeira parte do curso

serão:

• Cadastro de Categorias (tutorial)

• Cadastro de Fornecedores (exercício – avaliação prática)

• Cadastro de Produtos (exercício – avaliação prática)

Modelo
Produto – representa um produto que pode ser vendido na loja. É definido
por um nome, uma descrição e um preço

Categoria – classificação dos produtos

Fornecedor – fornecedor de um produto

Cliente – uma pessoa física que pode efetuar compras na loja.

Carrinho – contem as itens (produtos) que o cliente acumula até efetivar a

compra.

Pedido – documento que representa a efetivação da compra pelo

cliente.Possui os itens que o cliente comprou (produto e quantidade), um
endereço de entrega e os dados do pagamento.
Cadastro de Categorias
1. Cadastro de Categorias

1.1.O usuário entra na opção cadastro de Categorias;

1.2. O sistema mostra todos as categorias cadastradas;

1.3.O sistema para cada categoria lista fornece a opção de editar,

mostrar os detalhes ou remover; além disso fornece a opção de criar
uma nova categoria (1.3.1).

1.3.1. Inserir um novo cadastro

1.3.1.1.O usuário seleciona inserir uma nova categoria

1.3.1.2.O sistema solicita os dados do novo cadastro;

1.3.1.3.O usuário preenche os dados da nova categoria a ser inserida e

submete ao sistema

1.3.1.4.O sistema valida os dados e caso esteja ok efetua o cadastro da

categoria, o sistema volta a tela inicial (1.2)

1.3.2. Editar uma Categoria

1.3.2.1.O usuário seleciona editar uma das categorias listadas

1.3.2.2.O sistema mostra a categoria selecionada e fornece a opção do

usuário alterar os valores dos campos da categoria. O usuário
altera os campos e submete o formulário

1.3.2.3.O sistema acata as alterações salvando no banco de dados. Após

isso volta para a tela inicial do cadastro (1.2)

1.3.3. Remover uma categoria

1.3.3.1.O usuário seleciona remover uma categoria

1.3.3.2.O sistema solicita que o usuário confirme a remoção da

categoria. Caso o usuário confirme a categoria é removida e o
sistema volta para a tela inicial do cadastro (1.2)

Lógica de Negócios
Para que possamos efetuar o cadastro de um produto é necessário termos
uma classe de negócio responsável por gerenciar as categorias de produtos.
Esta classe irá fazer as operações básicas de inclusão, exclusão, alteração e
obtenção de categorias de produto.

Iremos criar uma classe chamada CategoriaFacade que será responsável por
estas operações básicas sobre as categorias de produto.
Tutorial – ACME Multicamadas
Criando e Configurando o projeto JEE
Iremos criar um aplicativo JEE com dois módulos, um módulo EJB que
conterá a lógica de negócios e um módulo WEB que irá conter a lógica de
apresentação no servidor.

Criando um aplicativo JEE

1. Seleciona Arquivos  Novo Projeto

2. Selecione Corporativo  Aplicação Corporativa

3. Nomeie o projeto como AcmeApp e escolha a localização do projeto

4. Configure o GlassFish como o servidor de aplicativo e escolha a

versão do JEE como a 5

5. Selecione os módulos EJB e Web para criação

6. Clique em Finalizar

Parte 2 – Módulo EJB

Configurando a camada de persistência

A camada de persistência no JEE é implementada pelo JPA – Java persistence
API, que consistem em uma API que permite obter, criar, deletar e alterar os
objetos Java em um banco de dados relacional.

A configuração do JPA consiste em definir uma unidade de persistência que

aponta para o banco de dados
 1. Clique com o botão direito no módulo EJB e escolha Novo  Outros

2. Selecione a categoria “Persistence” e o tipo “unidade de persistência”

3. Preencha os dados do provedor de banco de dados como abaixo:

4. Clique em finalizar

Nome da Unidade de persistência nome que será utilizado para referenciar

a unidade de persistência.

Provedor de persistência – biblioteca implementa o JPA e que será utilizada

para persistir os dados no banco. Existem várias opções como o TopLink,
Hibernate, OpenJPA , etc.

Fonte de dados – aqui temos um conceito novo, o de nome JNDI.

JNDI – Java Naming and Directory Service

O servidor JEE gerencia vários recursos e componentes que podem esta localizados
tanto na própria máquina em que está rodando ou em outra máquina ou mesmo
em outro servidor JEE. Para localizar um determinado recurso o JEE utiliza um
servidor de nomes (Naming Service) , que consiste de uma espécie de lista de
telefônica onde os vários recursos são acessados através de um nome.
O serviço que implementa esta lista é chamado de JNDI (Java Naming and Directory
Interface). Toda vez que quisermos que um determinado recurso, como um banco
de dados, um componente criado por nós ou por terceiros seja acessível para
outros componentes ou aplicativos, devemos registrá-lo no JDNI. Outros
componentes para utilizarem o recurso irão obtê-lo do JNDI, passando o nome com
o qual foi registrado. O JNDI fornece um modo unificado de localização de recursos
no JEE.

No nosso exemplo estamos acessando um banco de dados utilizando o

nome JNDI do mesmo (jdbc/sample). Veja no documento “Como Fazer” como
criar um novo banco de dados e associá-lo a um nome JNDI para utilizá-lo
em uma unidade de persistência.
O que é o JPA

A plataforma Java EE 5 introduziu o JPA – Java Persistence API que unificou e

padronizou o mecanismo de persistência antes implementados por diversas
bibliotecas como o Hibernate, TopLink, JDO, etc.
Esta API apesar de ser parte da especificação JEE pode também ser utilizada fora
de um servidor de aplicativo como em aplicações JSE ou WEB.
O JPA tem as seguintes características chaves:
• As entidades do modelo são POJOs, ou seja são classes Java comuns.
• Mapeamento objeto-relacional padronizado – um dos pontos chaves da
persistência de objetos em banco de dados consiste do mapeamento entre
as classes e as entidades do modelo relacional do banco de dados, ou seja,
como as classes e suas propriedades são mapeadas em tabelas e seus
campos no banco de dados. Antes do JPA, cada fabricante possuía a sua
forma de definir este mapeamento. O JPA padronizou este mapeamento
especificando duas formas de fazê-lo: via arquivo de configuração XML ou
utilizando anotações1 nas classes a serem persistidas.
• Regras de empacotamento simples – Como as entidades a serem persistidas
são simplesmente classes Java, estas podem ser empacotadas em qualquer
lugar em uma aplicação JEE, não necessitando de nenhum tratamento
especial.
• Entidades como DTO - Como o objetos persistidos são pojos, podem ser
serializados e transmitidos para outros aplicativos e serem utilizados
independente do ambiente de persistência. Como resultado, os objetos
podem ser utilizados como DTOs.
• EntityManager API – A interação com o JPA é feita através do EntityManager,
uma classe que implementa as operações necessárias para obter, alterar,
criar ou deletar uma entidade.

Criando o modelo de negócios

A camada de modelo consiste das classes representando as entidades
participantes do negócio. No nosso caso as Categorias e produtos. Estas
classes devem ser persistidas no banco de dados pois queremos que uma
vez cadastradas sejam salvas em um meio persistente de forma a não
perdermos o trabalho caso o servidor saia fora do ar.

1. Clique com o botão direito sobre o módulo EJB do projeto e selecione

a opção “NovoClasse de Entidade...”

2. Preencha os dados como abaixo

1
As Anotações foram introduzidas com o Java 5.0 (Tiger). Consiste de meta
informações inseridas no código Java que permitem ao container adicionar
comportamentos ao tratar a classe. No caso do JPA, as anotações são utilizadas
para informar ao container como ele deve persistir a classe no banco de dados –
qual tabela e campos correspondem ao objeto, o relacionamento com outras
entidades, qual a chave primária, etc.
Preste atenção no pacote onde deverá ser criada a classe.

O netbens irá criar uma classe como abaixo:

@Entity
public class Categoria implements Serializable {
private static final long serialVersionUID = 1L;
private Long id;

public void setId(Long id) {

this.id = id;
}

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public Long getId() {
return id;
}

Observe que em vários pontos do código há linhas começando com o

caracter ‘@’, são as anotações, elas indicam ao JPA como tratar a
persistência desta classe.

A primeira anotação encontrada no código é @Entity, esta anotação informa

ao JPA que a classe - que é definida logo em seguida – deverá ser persistida
no banco de dados.

Mais em baixo encontramos as anotações:

@Id – informa ao JPA que a propriedade id (observar que a anotação foi

posta imediatamente antes do método getter da propriedade id) consiste da
chave primária e portando do campo que identifica a entidade.

@GeneratedValue(strategy = GenerationType.AUTO) – Informa ao JPA

que o campo ID deverá ser gerado automaticamente pelo JPA. Assim nos
não teremos que nos preocupar em atribuir um valor para o mesmo.

Adicionando os campos da entidade

 1. Adicione os seguintes campos à classe Categoria:

private String nome;

private String descricao;

2. Clique com o botão direito no editor de código e selecione “Inserir

código...” e escolha “Getter e Setter”.

Por padrão o JPA irá persistir todos os campos da classe a menos que
anotemos o campo como @Transient.

Criando a lógica de cadastro de Categorias

Para implementar a lógica de cadastro de categorias iremos criar um
Stateless Session Bean:

1. Clique sobre o módulo EJB e escolha “NovoOutros”

2. Selecione a categoria “Persistence” e o tipo “Beans de sessão para

classes de entidade”. Clique em “próximo”

3. Adicione a classe categoria a lista de classes selecionadas

4. Preencha o pacote em que será criado o EJB (com.acme.ejb) e

selecione a opção “criar interface local”
 5. Clique em finalizar. Serão criados dois arquivos:

CategoriaFacade – contém a implementação da lógica de negócios.

No nosso caso os métodos básicos de cadastro de categorias (create,
edit, remove e find)

CategoriaFacadeLocal – consiste de uma interface que será

utilizada nos módulos clientes.

Abra os arquivos e observe o código gerado. Note que a classe

CategoriaFacade é anotada como @Stateless – que informa ao Container
que a classe é um Session EJB do tipo Stateless.

O NetBeans cria automaticamente o código de manipulação das categorias

(procura, edição, criação e deleção). Em todos eles é utilizado o objeto
EntityManager:

@PersistenceContext
private EntityManager em;

A anotação @PersistenceContext diz ao container que ele deve “injetar” na

variável “em“ uma referencia ao EntityManager do JPA, fazendo que este
fique disponível para os métodos da classe. Esta técnica de deixar para o
container a instanciação de um objeto a partir de informações em
anotações é chamada de injeção de dependência ou IOC. Ela será usada
também depois para localizar o EJB que acabamos de criar quando
estivermos construindo a camada de apresentação web.

Observe no método findAll, ele contém uma chamada ao método

createQuery de EntityManager, passando como argumento uma sentença
muito parecida com SQL. Na verdade esta sentença é uma JPQL – Java
Persistence Query Language –diferentemente do SQL que atua sobre o
domínio das tabelas e colunas do banco de dados, o JPQL opera sobre as
classes e suas propriedades.
EJB –Enterprise Java Beans
No JEE 5 os EJB são classes Java normais, pelo menos para o desenvolvedor, o
servidor de aplicativo utiliza as anotações para determinar se uma classe deve ser
tratada como um EJB e qual o tipo dele.

Um EJB, diferentemente de objetos normais, pode ser acessado remotamente e seu

ciclo de vida é controlado pelo container EJB.

O container intermedia as requisições aos EJBs e controla a instanciação e

execução pelos EJBs.

Para transformar uma classe normal em um EJB precisamos anotá-lo com uma das
anotações a seguir:

@Stateless – transforma a classe anotada em um Session EJB Stateless.

@Statefull – transforma a classe em um EJB Statefull

@Stateless

public class CategoriaFacade implements CategoriaFacadeLocal {

@PersistenceContext

private EntityManager em;

...

// Metodos do EJB

Um EJB “vive” realmente dentro de um container. Quando um cliente, uma pagina

JSP ou um Managed bean JSF, por exemplo, faz uma chamada para o mesmo, na
verdade ele não está acessando diretamente o objeto EJB. Na verdade, por trás da
requisição, ocorrem várias coisas:

O cliente obtém uma referencia para um Proxy local do EJB – como na verdade o
EJB pode estar rodando em outro local, em outro servidor, o cliente não tem como
obter uma referencia ao EJB real. Ao invés disso, o servidor fornece um “substituto”
que para o cliente funciona como se estivesse interagindo com o EJB localmente.

Para permitir isso, para cada EJB é criado também uma interface, é esta interface
que o cliente irá utilizar para interagir com o EJB remoto. O substituto criado pelo
servidor JEE implementa a interface com os mesmos métodos do EJB.

Há duas formas de disponibilizar um EJB pelo servidor. Caso o EJB seja utilizado