Servidores de Aplicação
Aula 10
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 10: Projeto de aplicativo distribuído em camadas, segundo
MVC
Objetivo: Apresentar um projeto de software que será usado para desenvolver um aplicativo em camadas, segundo o modelo MVC.
Introdução
Para demonstrar como se projeto um aplicativo distribuído, iniciemos com um projeto simples, usando o padrão de projeto MVC como referência. O aplicativo consistirá de um componente instalado num servidor de aplicações, que responderá a dois clientes diferentes, o primeiro, é um cliente web, e o segundo é um cliente desktop, que, para facilitar a implementação, desenvolveremos sob a forma de um aplicativo de linha de comando.
Pelo conceito do MVC, deve haver três camadas, a primeira é a View, onde ficam os clientes do componente instalado no servidor, que será a camada de Controller. A terceira camada seria o Model, onde ficariam as regras de negócio e o modelo de dados usado pelo aplicativo. Esta terceira camada será implementada num exemplo futuro.
Selecionando as tecnologias de Java EE
As tecnologias de Java EE que melhor se enquadram para este exemplo são as JSP e Servlets para desenvolver o cliente web, e EJBs de tipo Session Bean para o componente instalado no servidor. O outro aplicativo cliente será uma aplicação desenvolvida usando Java SE.
A Figura 1 apresenta um esquema de como essas tecnologias devem ser distribuídas dentro do modelo MVC e, antes de usá-las, estudaremos um pouco mais de detalhes sobre essas tecnologias.
EJBs de tipo Session Bean
Dentre as diversas tecnologias disponibilizadas pela linguagem Java, o modelo de arquitetura baseada em JavaBeans é que melhor permite o desenvolvimento de software baseado em componentes. Da evolução dos JavaBeans, resultou o Entreprise Java Beans (EJB), um framework executado no lado servidor da aplicação, que simplifica o processo de desenvolver aplicações cuja arquitetura se baseia em componentes distribuídos e que são escritas em Java.
Os EJBs foram projetados para permitir a portabilidade das aplicações que os usam, e serem reutilizáveis em qualquer solução de middleware disponível no mercado. Por isso, eles permitem aos arquitetos e programadores escrever aplicações escalonáveis, confiáveis e seguras, sem a necessidade de fazer todo esse trabalho a partir do zero, pois os EJBs já apresentam uma infraestrutura pré-escrita. Isso também acelera o desenvolvimento das aplicações a serem executadas no lado do servidor.
Esse modelo determina que para escrever um EJB de tipo Session Bean, é necessário usar as anotações @Stateless e @Stateful uma linha antes da declaração da classe, para indicar se ele possui ou não um estado a ser armazenado na memória. @Stateless indica que o resultado do processamento do EJB não precisa ser armazenado na memória para uso posterior, que é o caso do nosso exemplo. Mas recomenda-se que um EJB que efetua o login de um usuário num site de e-commerce use a anotação @Stateful, para que a validação do login seja mantida na memória e que possa ser usada posteriormente para outras funções. O restante da declaração do EJB é igual a uma classe Java normal, como pode ser observado na listagem a seguir:
@Stateless
public class NomeDoEJB implements NomeDoRemote{ public String getMessage() {
/*
Lógica do método
*/
return "Esta linha devolve um resultado". }
public void setMessage() { // código do método } }
Nessa declaração, o comando “public class NomeDoEJB” declara a classe
Java que executará a regra de negócios, e o comando “implements
NomeDoRemote” declara a interface, ou interfaces, de comunicação que habilita o
acesso dos clientes ao EJB, como pode ser observado na Figura 1, onde os clientes o acessam através de interfaces locais e remotas. A necessidade dessas interfaces é um requisito da arquitetura distribuída, que define que um componente deve ser acessado desse modo por uma questão de segurança.
Em Java, uma interface de comunicação de EJB também é escrita como se fosse uma classe convencional, como pode ser observado na listagem a seguir:
@Remote
public interface NomeDoRemote { String getMessage().
}
Nessa declaração, a anotação @Remote indica ao servidor de aplicações que esta interface atende a qualquer cliente que seja remoto ao EJB, ou seja, executado em um ambiente diferente deste EJB. Em contra partida, se usar a anotação @Local no lugar de @Remote, isso indicará ao servidor de aplicações que os clientes locais, ou seja, executado no mesmo ambiente deste EJB poderão usá-lo.
O comando “public interface NomeDoRemote” declara o nome da interface que está conectada à classe do EJB, atente-se ao fato de que o nome deve ser o
mesmo que foi usado no comando “implements NomeDoRemote” durante a
declaração do EJB.
A função de uma interface de comunicação é determinar quais os métodos da classe do EJB que podem ser usadas. Ao observar as duas listagens, perceba que a
interface possui apenas a declaração “String getMessage();” que é a declaração do
método “public String getMessage()” declarado no EJB. Isso significa que apenas o
método “getMessage()” será acessível pelos clientes.
Um cliente pode tentar acessar o método “setMessage()”,declarado no EJB. Entretanto, como esse método não está declarado na interface, o cliente receberá um erro, informando que esse método não existe no servidor de aplicações, e, muito provavelmente, o desenvolvedor somente descobrirá isso no momento em que o aplicativo for usado.
Cliente web
Para testar a chamada do EJB por um cliente web, faremos uma página JSP, que possui um link chamado de Servlet, que declarará o EJB como se fosse um objeto (ou uma variável) através do comando:
@EJB
private NomeDoRemote testeEJB.
A anotação @EJB indica que o Servlet usará um EJB instalado no servidor de aplicações. Neste caso, esta ação somente é possível porque o cliente web e o EJB estão sendo executados do mesmo ambiente. Se estiverem em ambientes diferentes, a forma de endereçamento é similar ao que será feito com o cliente desktop.
Depois dessa etapa, o EJB será usado através do objeto “testeEJB” como um
programa comum escrito em Java.
Cliente desktop
Como um aplicativo desktop é executado fora do ambiente do servidor de aplicações, ele necessita usar a tecnologia JNDI para fazer o endereçamento do EJB.
A tecnologia JNDI define um conjunto de propriedades para localizar serviços remotos. Para facilitar futuras atividades de manutenção, os desenvolvedores costumam manter essas propriedades em arquivos específicos com a extensão “.properties”. Assim, o endereçamento de um EJB a partir de um cliente desktop seria definido pela listagem a seguir:
Properties props = new Properties();
props.load(new FileInputStream("jndi.properties")); InitialContext ctx = new InitialContext(props);
NomeDoRemote testeEJB = (NomeDoRemote)
Nessas linhas, o comando “props.load(new
FileInputStream("jndi.properties"));” indica que as propriedades de acesso e
endereçamento serão lidas do arquivo "jndi.properties". Depois, a instrução
“InitialContext ctx = new InitialContext(props);” criará uma conexão com o servidor de
aplicações remoto. Uma vez que a conexão esteja estabelecida, a instrução
“NomeDoRemote testeEJB = (NomeDoRemote) ctx.lookup("NomeDoRemote");”
declara o objeto testeEJB com objeto que pode ser acessado pelo restante do cliente desktop.
Conclusão
Nesta aula, foram abordadas algumas questões relacionadas à teoria que permite usar as tecnologias de Java EE para implementar aplicações distribuídas de acordo com o modelo MVC. A próxima aula será um exercício prático de implementação deste projeto.
* O QR Code é um código de barras que armazena links às páginas da web. Utilize o leitor de QR Code de sua preferência
REFERÊNCIAS
GONÇALVES, Antonio. Beginning Java EE 6 Platform with GlassFish 3: From Novice to Professional. United States of America: A Press, 2009.
