EP3: Utilização de EJB3 e JPA

Exercício-Programa 3: Utilização de EJB3 e JPA

Sistemas de Middleware - Primeiro Semestre de 2009

Descrição

Usando a arquitetura EJB3/JPA, desenvolva um protótipo de aplicação Internet voltada para vídeo-locadoras. Essa aplicação deve lidar com três tipos de entidades JPA:

filme (entidade Movie)
exemplar de filme (entidade MovieCopy)
usuário (entidade Customer)

O uso de tipos de entidades distintos para Movie e MovieCopy captura a diferença entre um "filme abstrato" e um exemplar (cópia física) de filme, em BD (Blu-ray Disc), DVD ou VHS. O filme é o conteúdo de um BD, DVD ou VHS. O que você aluga e leva para casa é o exemplar, não o filme.

Especificação das Entidades e dos Relacionamentos

Um filme tem os seguintes atributos:

id: long que identifica o filme;
name: String com o nome do filme;
director: String com o nome do diretor do filme;
genre: lista de Strings com os nomes de gêneros (comédia, ação, etc.) aplicáveis ao filme;
cast: lista de Strings com nomes de atores/atrizes que trabalham no filme;
year: short com o ano de lançamento do filme;
duration: short com a duração do filme em minutos;
copies: conjunto de objetos MovieCopy com os exemplares do filme.

Estes são os atributos de um exemplar de filme:

id: long que identifica o exemplar de filme;
movie: "filme abstrato" (Movie) correspondente ao exemplar;
mediaType: short contendo 0 (VHS), 1 (DVD) ou 2 (BD);
rented: boolean com valor true se o exemplar estiver alugado e false caso contrário;
taker: o usuário (Customer) que alugou o exemplar de filme, ou null se o exemplar não estiver alugado (ou seja, se movieCopy.isRented() devolver falso);
returnDate: java.util.Date contendo a data de devolução, caso o exemplar esteja alugado. O valor deste atributo é irrelevante se o exemplar não estiver alugado.

Estes são os atributos de um usuário:

id: long que identifica o usuário;
name: String com o nome do usuário;
phone: String com o telefone do usuário;
takenMovieCopies: conjunto de objetos MovieCopy correspondentes aos exemplares de filmes alugados pelo usuário.

Há um relacionamento "um para muitos" entre Movie e MovieCopy (pode haver muitos exemplares de um filme). No lado do Movie, esse relacionamento é representado pelo atributo copies. No lado do MovieCopy, ele é representado pelo atributo movie.

Há também um relacionamento "um para muitos" entre Customer e MovieCopy (um usuário pode alugar muitos BDs, DVDs ou fitas VHS). No lado do Customer, esse relacionamento é representado pelo atributo takenMovieCopies. No lado do MovieCopy, ele é representado pelo atributo taker.

Especificação do(s) Componente(s) Session Bean

Entidades JPA não são acessíveis a clientes remotos. Por esse motivo, todo acesso remoto a uma entidade deve ser mediado por algum session bean implantado no mesmo servidor de aplicações. Os session beans recebem chamadas remotas dos clientes e fazem chamadas locais às entidades JPA. Esse arranjo corresponde ao padrão de projeto conhecido como "sessão de fachada" ou "serviço de fachada".

Crie um ou mais componentes de serviço do modelo EJB3 (stateless session beans que ofereçam os seguintes serviços a clientes remotos:

cadastramento de um filme;
cadastramento de exemplares de um filme;
cadastramento de um usuário;
busca de um filme por id;
busca de filmes por nome (pode haver mais de um filme com o mesmo nome);
busca de filmes por diretor;
busca de filmes por gênero e ano (exemplo: buscar todas as comédias lançadas em 2004)
busca de usuário por id;
busca de usuários por nome;
busca de usuários por telefone;
locação de um exemplar de filme a um usuário;
encerramento de locação (devolução de filme).

As operações de busca de filme devem devolver um objeto auxiliar com todas as informações relevantes sobre o filme e sobre os exemplares do filme. De modo análogo, as operações de busca de usuário devem devolver um objeto auxiliar com os dados do usuário. Esses objetos auxiliares são denominados data transfer objects (DTOs). O uso de DTOs por uma sessão de fachada ou por um serviço de fachada pode reduzir significativamente o número de chamadas remotas. Esta é uma possível definição das classes dos DTOs correspondentes aos filmes (MovieDTO) e aos usuários (CustomerDTO):

    public class RentedMovieCopyInfo implements java.io.Serializable {
        public long movieCopyId;
        public String customerName;
        public String customerPhone;
        public java.util.Date returnDate;
    }

    public class MovieDTO implements java.io.Serializable {
        public long id;
        public String name;
        public String director;
        public java.util.List<String> genre;
        public java.util.List<String> cast;
        public short year;
        public short duration;
        public java.util.List<Long> inStoreCopies; // ids dos exemplares disponíveis
        public java.util.List<RentedMovieCopyInfo> rentedCopies;
    }

    public class CustomerDTO implements java.io.Serializable {
        public long id;
        public String name;
        public String phone;
    }

Especificação do Cliente

O cliente remoto deve deve ser um cliente Web que expõe ao operador de um browser toda a funcionalidade do sistema. Esse cliente interage com o operador e chama o(s) componente(s) EJB3 que oferece(m) os serviços de cadastramento, busca, locação e devolução. Ele deve ser implementado usando uma ou mais das seguintes tecnologias: servlets, JSP ou JSF. O cliente não precisa autenticar a identidade do operador do browser.

Servidor Java EE

O sistema deve rodar no JBoss Application Server, versão 5.0.1.GA ou 5.1.0.GA.

Observações

Note que o cliente Web se comunica com o(s) componente(s) EJB3 por meio de chamadas remotas. Isso significa que ele pode ser implantado num servidor de aplicações diferente daquele que contém as entidades JPA e o(s) componente(s) EJB3. (Na verdade o cliente Web não precisa rodar num servidor Java EE completo, ele requer apenas um container para servlets, JSP e JSF.) Evidentemente o cliente Web pode também ser implantado no mesmo servidor que contém a camada de entidades e a de serviços (EJB3). Para efeito de testes, esta é a alternativa mais simples.

É interessante pensar nas seguintes questões:

Temos um cliente Web rodando no mesmo servidor que a camada de entidades JPA e a camada EJB3. Gostaríamos de implantar esse cliente em outro servidor. Precisamos alterar alguma coisa no cliente? Em caso afirmativo, que arquivo(s) deveria(m) ser alterado(s)?
Neste EP o cliente Web interage com a camada EJB3 via chamadas remotas, mesmo que ele esteja rodando no mesmo servidor que a camada EJB3. Se essa camada oferecesse também interfaces locais, um cliente co-locado poderia usar os serviços dela de modo mais eficiente. Considere a possibilidade de criar uma camada de serviços com interfaces remotas e interfaces locais. Uma possível decisão de projeto é fazer com que não hajam diferenças significativas entre as interfaces remotas e as locais. Outra possível abordagem é criar interfaces locais diferentes das remotas, levando em conta o fato das chamadas locais serem mais eficientes. (Note que a motivação para se usar DTOs é bem menor no caso das interfaces locais.) Quais as vantagens e as desvantagens dessas duas abordagens?
Se tivermos certeza que nunca será necessário implantar o cliente Web num servidor diferente do que contém a camada de entidades JPA, podemos eliminar completamente a camada EJB3 e fazer o cliente Web chamar diretamente a camada de entidades. Quais as vantagens e as desvantagens dessa abordagem? Há algum cenário em que vale a pena ter uma camada EJB3 mesmo sabendo que ela estará sempre co-locada com o cliente Web?

Bom trabalho!

FAQ

Questão 1: Pode fazer em grupo?
Resposta: Este trabalho deve ser feito em grupos de uma ou duas pessoas.

Questão 2: Pode haver grupo com mais de duas pessoas?
Resposta: Não.

Questão 3: O que exatamente deve ser entregue?
Resposta: Veja abaixo o ítem "Entrega".

Entrega

O trabalho deve ser entregue até 12/06, através do sistema Paca/Moodle.

Entregue um arquivo tar.gz ou zip que satisfaça os seguintes requisitos:

O nome do arquivo deve ser da forma ep3-<nomes-dos-membros-do-grupo>.tar.gz ou ep3-<nomes-dos-membros-do-grupo>.zip. Por exemplo: ep3-joao-maria.zip. No nome do arquivo devem ser omitidos os acentos dos nomes dos membros do grupo. Além disso, a separação entre palavras não deve ser feita com espaços. Ou seja, o arquivo não deve se chamar "ep3-joão-maria.tar.gz" nem "ep3 joao maria.tar.gz".
O desempacotamento do arquivo tar.gz ou zip deve produzir um diretório com o mesmo nome do arquivo, menos o sufixo .tar.gz ou zip. (Exemplo: ep3-joao-maria.) Todos os arquivos desempacotados devem estar dentro desse diretório.
O diretório desempacotado deve conter:
- Todos os arquivos fonte em Java, JSP e XML da aplicação Internet.
- Um arquivo build.xml para a ferramenta ant. O build.xml deve incluir as seguintes funções (targets, ou alvos):
  - "build" - Este deve ser o alvo default, que automatiza a geração da aplicação. Ele deve compilar os fontes Java e empacotar num arquivo .ear os arquivos .class produzidos na etapa de compilação, os descritores de implantação XML, e os arquivos JSP/JSF da aplicação. O arquivo .ear deve conter tanto o cliente Web (servlets, JSP ou JSF) como as camadas EJB3 e JPA. Em outras palavras, a implantação do arquivo .ear num servidor Java EE deve fazer o cliente Web e as camadas EJB3 e JPA rodarem nesse mesmo servidor.
  - "deploy" - Este alvo implanta a aplicação na configuração "default" do servidor JBoss. Implantar a aplicação significa copiar o arquivo .ear para o diretório ${JBOSS_HOME}/server/default/deploy.
  - "undeploy" - Este alvo desimplanta a aplicação da configuração "default" do servidor JBoss. Desimplantar a aplicação significa remover do diretório ${JBOSS_HOME}/server/default/deploy o arquivo .ear que o alvo deploy copiou para aquele diretório.
  Depois de dar "ant build" e "ant deploy", deve ser possível utilizar o sistema através de um browser. O "ant undeploy" restaura o estado original da configuração "default" do servidor JBoss.
- Um arquivo README, com as seguintes informações:
  - Um "receituário" de como gerar e usar a aplicação. Caso seja necessário definir variáveis de ambiente e/ou editar algum arquivo de propriedades antes de rodar o ant, esta parte deve detalhar o que precisa ser feito.
  - A URL que dá acesso à aplicação através de um browser.
  - Uma explicação breve sobre a estrutura da aplicação. (Como é a organização das classes? Você implementou o cliente usando servlets, JSP ou JSF?...)
  O arquivo README deve ser de texto puro (ASCII). Quem preferir, pode colocar num documento separado a explicação sobre a estrutura da aplicação e deixar no README só o receituário para geração e a URL de acesso. Esse documento separado, se existir, pode ser tanto um arquivo de texto ASCII como um arquivo pdf. (Não quero arquivos doc em formato MS-Word.)

Last modified: Wed May 27 11:42:29 BRT 2009