Servidores de Aplicação
Aula 15
Este material é parte integrante da disciplina oferecida pela UNINOVE.
O acesso às atividades, conteúdos multimídia e interativo, encontros virtuais, fóruns de discussão e a comunicação com o professor devem ser feitos diretamente no ambiente virtual de aprendizagem UNINOVE.
Uso consciente do papel.
Aula 15: Integrando tecnologias da camada web a EJBs e JPA,
segundo o modelo MVC – Parte I
Objetivo: Apresentar a integração dessas tecnologias para implementar um
aplicativo distribuído, de acordo com o MVC, usando a JPA e conceitos de EJB que não foram vistos nas aulas anteriores.
Introdução
Nesta aula apresentaremos os passos para implementar uma aplicação simples, que consulta bases de dados usando arquivos JSP, Servlets e EJBs. Ela relaciona algumas bebidas e seus fornecedores a partir da interação com o que usuário informou em um formulário, de acordo com o fluxo apresentado na Figura 1.
Figura 1 – Fluxo de páginas da funcionalidade
Conforme a figura, a primeira página a ser apresentada ao usuário é um formulário no qual ele informa sua preferência sobre a bebida. Com base nessas informações, o sistema apresenta uma página com a lista de marcas que atendem às características informadas. Nessa lista ele pode selecionar um dos itens para identificar os vendedores dessa marca ou retornar à página anterior. Ao selecionar um item, o sistema apresenta uma lista dos vendedores da marca ao usuário. Nessa tela, ele pode retornar para a página inicial ou para a página anterior.
Definindo a arquitetura
Após definir o funcionamento do aplicativo, é interessante definir a arquitetura (neste exemplo, o MVC) e os componentes do software, a responsabilidade de cada um deles e o modo como interagem entre si.
A plataforma Java EE permite implementar esse software usando páginas JSP, Servlets e EJBs do seguinte modo: as páginas JSP podem ser usadas para interagir com o usuário, apresentando os resultados do processamento, os formulários para o utilizador digitar os dados (também pode ser feito por páginas puramente HTML), isto é, a camada View. Os Servlets atuam como controles do aplicativo, tratando as requisições HTTP que chegam a ele e redirecionando essas requisições para a camada Model ou para a camada View. Essa é a camada Controller. Por último, as informações trafegadas pela aplicação são armazenadas em bases de dados. As classes que gerenciam o acesso à base de dados são programadas sob a forma de beans de sessão EJB e classes de entidade programadas de acordo com a especificação JPA. Esses componentes representam a camada Modelo. Esse ciclo de operação é apresentado na Figura 2.
Criando a base de dados
Para a base de dados desse aplicativo, são necessárias pelo menos duas tabelas, marca e vendedor, que armazenam todas as informações relacionadas às características de uma marca de cerveja, como nome, cor, fabricante e tipo de fermentação, e as informações sobre os vendedores, respectivamente.
A Figura 3 representa o diagrama de relacionamento para essas tabelas. Além das colunas mencionadas anteriormente, é necessário adicionar uma coluna ID em cada uma das tabelas, que será a chave primária de cada uma delas. Para a tabela marca haverá uma coluna ID, que será uma chave estrangeira de acordo com a coluna ID da tabela vendedor, com o relacionamento de muitos vendedores para uma determinada marca.
Figura 3 – Relacionamento entre entidades.
A primeira tabela a ser criada é a vendedor, que lista todos os nomes de vendedores disponíveis, de acordo com o script a seguir:
CREATE TABLE vendedor (
id numeric(10,0) NOT NULL, nome character(20),
CONSTRAINT id_vendor PRIMARY KEY (id ) );
Agora, deve ser criada a tabela marca, cujo script de criação vem a seguir: CREATE TABLE marca
(
id numeric(10,0) NOT NULL, marca character(20),
vendedor numeric(10,0), cor character(10),
fermentacao character(10), fabricante character(20),
CONSTRAINT pk_id PRIMARY KEY (id ),
CONSTRAINT cerva_vendedor_fkey FOREIGN KEY (vendedor) REFERENCES vendedor (id)
ON UPDATE NO ACTION ON DELETE NO ACTION );
Criando as classes de entidade
Como já visto em aulas anteriores, as classes de entidade são usadas para persistir dados. No contexto de desenvolvimento de software, persistência significa o ato de armazenar automaticamente os dados contidos em objetos nas bases de dados. A API de Persistência Java (JPA) é uma tecnologia de mapeamento objeto-relacional que permite gerenciar dados armazenados nos objetos durante a execução do software, e as bases de dados relacionais, de modo transparente para o desenvolvedor. Porém, ao contrário do que foi feito nas aulas 13 e 14, as classes de entidade são criadas a partir do modelo de dados. Isso é feito por meio de um utilitário que existe na maioria das ferramentas de desenvolvimento, que se conecta ao banco de dados a partir da unidade de persistência que foi criada, e por meio de um processo de engenharia reversa, cria o mapa objeto-relacional representado nas classes de entidade.
Após executar a engenharia reversa, na classe de entidade marca, haverá o seguinte atributo declarado:
@JoinColumn(name = "VENDEDOR", referencedColumnName = "ID") @ManyToOne
private Vendedor vendedor;
A anotação @JoinColumn serve para indicar que a classe de entidade Marca tem uma relação de chave estrangeira com a tabela Vendedor, através da coluna ID (definidos pelos parâmetros name e referencedColumnName respectivamente), enquanto que a anotação @ManyToOne indica que há um relacionamento de muitos para um com a classe de entidade Vendedor, através do objeto vendedor.
Na classe de entidade Vendedor, há a seguinte declaração de atributos: @OneToMany(mappedBy = "vendedor")
private Collection<Marca> marcaCollection;
A anotação @OneToMany indica que a classe vendedor possui um relacionamento de um para muitos com a classe de entidade marca. Esse relacionamento é mapeado pelo atributo vendedor (declarado na classe de entidade Marca) e por uma lista de objetos do tipo marca, que têm esse vendedor associados a eles.
Assim, quando a JPA for usada para listar um determinado vendedor, automaticamente o atributo marcaCollection trará para a memória todas as marcas que estão associadas a ele, sem que seja necessário fazer uma nova seleção na base de dados.
Além disso, há a criação dos comandos de seleção SELECT em cada uma dessas classes de entidade, como a linha a seguir:
@NamedQuery(name = "Vendedor.findById", query = "SELECT v FROM Vendedor v WHERE v.id = :id")
Essa consulta é semelhante àquela feita nas aulas 13 e 14, com a diferença de que esta possui a cláusula WHERE para definir um parâmetro para pesquisa de registros. O JPA cria esses comandos de consulta automaticamente a fim de que o desenvolvedor possa usá-las do mesmo modo como foi feito nas aulas 13 e 14, para as situações em que os mecanismos de consulta automática que ela provê (find(), findAll(), etc...) não conseguem suprir as necessidades dos aplicativos.
Beans de sessão do tipo session facade
Como visto anteriormente, os EJB são sempre usados por um cliente para realizar alguma operação associada à regra de negócios. O nome bean de sessão quer dizer que o EJB é usado durante um determinado período de tempo, normalmente quando a sessão de conexão entre o cliente e o EJB está ativa.
No caso desse projeto, será usado um tipo específico de EJB, conhecido como “Session Facade”. A função principal de um “Session Facade” é servir como uma interface de comunicação entre o lado cliente da aplicação e as classes de entidade (a camada Controller do MVC).
Por ser um padrão de Java EE, o Netbeans possui um utilitário que cria esses beans a partir das classes de entidade. Desse modo, após executar esse utilitário, a área de trabalho ficará similar à Figura 4.
Figura 4 – Projeto com os “Session Facades”.
Esses beans de sessão já implementam os mecanismos de persistência fornecidos pela JPA (create, edit, remove, find, findAll, findRange e count). Basicamente, esse é um processo automático que executa parte do trabalho feito manualmente nas aulas 13 e 14.
Vídeo
Este procedimento continua na aula 16, que contém um vídeo, disponível no AVA, que ajudará com o processo de programação desse aplicativo.
Conclusão
Até o momento, o único trabalho do projetista de software para implementar esse aplicativo era escrever os scripts que criam as tabelas no banco de dados. A partir disso, foi criada uma unidade de persistência, usada para criar o mapa objeto-relacional para o banco, além dos componentes de controle que ligam a camada do Model à camada View.
Com essa geração automática de código, foram vistos alguns conceitos adicionais de JPA que não foram necessários nas aulas 13 e 14, em razão da simplicidade do evento.
Na prática, os aplicativos possuem uma complexidade maior do que o exemplo desta aula, mas ele permite vislumbrar as facilidades que essas APIs dão ao desenvolvedor de software. O projeto e implementação desse aplicativo prosseguirá na aula 16.
Caso fique alguma dúvida, leve a questão ao Fórum e divida-a com seus colegas e professor.
REFERÊNCIA
KEITH, Mike.; SCHINCARIOL, Merrick. EJB 3 Professional: Java Persistence API. United States of America: APress, 2008.
