enterprise java beans (i)diego/disciplinas/2014_2/... · enterprise java beans (iii) • o j2ee...
TRANSCRIPT
Enterprise Java Beans (I)
Professor: Diego Passos
UFF
Baseado no material original cedido pelo Professor
Carlos Bazilio
Java Beans
• Conceito já discutido na disciplina.
• São classes Java que seguem uma convenção.
– Classes contendo construtor padrão sem argumentos.
– Classes contendo métodos get/set para todos os atributos.
– Podem conter outros métodos e construtores também.
• Usadas no desenvolvimento de páginas JSP.
– Ações padrão.
• Usadas no desenvolvimento de aplicações JSF.
– Backing beans e Model beans.
– Têm seus atributos mapeados para componentes de interface.
Java Beans: Cenário Típico JSF (Visto Até Agora)
Java Beans: Cenário Típico J2EE
Enterprise Java Beans
• API para especificação de aplicações multi-camadas, baseadas em componentes, distribuídas e escaláveis.
• É a base da plataforma J2EE.
• Estende o modelo de componentes Java Beans.
– Beans (potencialmente) distribuídas.
– Suporte para aplicações transacionais.
• Referência: http://java.sun.com/products/ejb
Enterprise Java Beans (II)
• No modelo de aplicações J2EE, as EJBs implementam a lógica de negócio.
• Outros componentes da aplicação chamam seus métodos para realizar as operações esperadas da aplicação.
• EJBs também fazem o intermédio com as fontes de dados.
• Assim como os componentes web, a implementação de uma EJB roda em um container especial.
– EJB Container.
– Provê vários serviços às EJBs.
• Processamento de transações.
• Segurança.
• Manutenção do ciclo de vida das instâncias das EJBs.
• Gerenciamento de recursos.
Enterprise Java Beans (III)
• O J2EE define três tipos diferentes de EJBs.
– Beans de sessão.
• Tipicamente não persistente.
• Acessado por um cliente por vez.
• Ciclo de vida tem duração típica de uma sessão (do ponto de vista de um cliente).
• Instâncias podem eventualmente ser reaproveitadas.
• Implementam lógica de negócio da aplicação.
– Beans de entidade.
• Representam dados armazenados em mídia persistente.
– Como uma base de dados em disco.
• Podem ser acessadas concorrentemente.
• Implementam os dados da aplicação.
Enterprise Java Beans (IV)
– Beans orientadas a mensagens.
• Modelo de requisição e resposta assíncronas.
• Cliente envia mensagem JMS.
• Mensagens são mapeadas para operações (métodos) na EJB.
• Resultados das operações são mapeados de volta em mensagens JMS.
EJB – Mais um Exemplo de Arquitetura
Servidor J2EE
Contêiner EJB Contêiner Web
Cliente
Beans de
Sessão
Beans de
Entidade
JSP
Tags
Bean
Servlet
RDBMS
EJB – Servidor de Aplicação
• O gerenciamento de objetos de serviço é uma funcionalidade central de servidores de aplicação, pois permite:
– Fraco acoplamento
• Uma aplicação cliente não precisa instanciar objetos de serviço ou saber o nome das classes de implementação;
• Esta só precisa saber da interface do serviço;
• Permite ao servidor ter alternativas de implementação de serviço sem alteração do código do cliente;
– Independência da rede
• Serviços disponíveis para a maioria dos protocolos de transporte de rede;
• Transparência para o cliente quanto a localização real dos objetos que implementam o serviço;
EJB – Servidor de Aplicação
• (.. ainda sobre o gerenciamento de objetos de serviço):
– Pool de recursos
• O servidor tem controle de recursos críticos;
• A aplicação cliente não precisa destruir os objetos criados;
• Através de um pool de recursos, o servidor controla o excesso de criação de objetos através do reaproveitamento de recursos.
EJB - JBoss
• JBoss é um servidor de aplicação JavaEE completo e certificado;
• Robusto, maduro e validado por aplicações em grandes empresas;
• Empresa patrocinadora foi comprada pela RedHat;
• Incorpora outros projetos de software livre, como o Tomcat e o HSQLDB (antigo Hypersonic);
• Primeiro servidor JavaEE a eliminar os processos manuais de geração de stubs e skeletons (herdados do CORBA);
• Qualquer componente pode ser reiniciado, reconfigurado, substituído ou atualizado “à quente”.
EJB – Jboss (II)
EJB – Jboss (III)
• Uma aplicação web completa pode ser compactada e instalada através de um arquivo .ear (Enterprise ARchive file);
• Um arquivo .ear conterá os arquivos .jar (EJB’s) e .war que compõe a aplicação web;
• No JBoss, uma aplicação é implantada através do diretório (“<jboss>/server/default/deploy”).
EJB – Stub e Skeleton
Código do
cliente
Código do
EJB Stub Skeleton
Cliente Servidor
EJB – Stub e Skeleton (II)
• Em muitos casos, EJBs são acessadas remotamente.
• Internamente, a interação entre cliente e EJB se dá através de RMI.
• Para enviar requisições ao EJB, cliente utiliza uma classe local Stub.
• No lado servidor, além de instanciar o EJB, container instancia uma classe Skeleton.
• Requisições do cliente são passadas ao Stub que as serializa e envia pela rede.
• Skeleton recebe os dados serializados, os transforma em estruturas de dados Java novamente e os repassa ao EJB.
• Na resposta, processo inverso é realizado.
Interface Cliente e Interface Home
• Note que os conceitos de Stub e Skeleton são transparentes para o cliente.
• Cliente não precisa estar ciente do uso do RMI.
– Ou dos conceitos associados.
• Ao contrário, cliente precisa apenas conhecer a interface para acesso dos métodos do EJB.
– A interface do cliente.
– Define os métodos da lógica de negócio.
• Do lado do servidor, o container precisa também saber como acessar/manipular o ciclo de vida de um EJB.
– Precisa de uma interface específica.
– A interface home.
– Define métodos para gerenciamento do EJB.
Acessando um EJB
• Do ponto de vista de um cliente, o acesso típico a um EJB é feito através dos seguintes passos:
– Acessar o serviço JNDI do Servidor de Aplicação que contém o EJB.
– Usar o serviço JNDI para obter a interface home para o EJB.
– Usar a interface home para criar (ou encontrar) uma referência ao EJB.
– Usar a interface do cliente para chamar métodos.
• Cliente, portanto, precisa de informações sobre o serviço JNDI do Servidor de Aplicação.
• Precisa também saber sob qual nome a interface home do EJB está armazenada.
• Finalmente, precisa conhecer a interface do cliente associada ao EJB.
EJB do Ponto de Vista do Container
• Quando um EJB é implementando no container, o desenvolvedor fica encarregado de prover uma série de arquivos.
– A interface cliente.
– A interface home.
– A classe que implementa o EJB.
– Um deployment descriptor do EJB.
• A partir destes arquivos, o container gera automaticamente:
– O stub e o Skeleton (implementações associadas à interface cliente).
– O home (a implementação associada à interface home).
EJB do Ponto de Vista do Container (II)
(Fonte: “Java Enterprise in a Nutshell”)
EJB do Ponto de Vista do Container (III)
• O descritor permite que opções de funcionamento do EJB sejam configuradas em tempo de disponibilização.
• Estas opções definem (entre outras coisas):
– Como funciona o ciclo de vida do EJB.
– Opções de segurança e autenticação.
– Serviços providos pelo Container ao EJB.
– Parâmetros de inicialização do EJB.
• Opções permitem que um mesmo EJB possa ser usado em ambientes diferentes.
– Potencialmente, com necessidades diferentes.
– Facilitam a reutilização dos EJBs.
– Reforçam o modelo de EJBs como componentes reutilizáveis.
EJBs: Acesso Remoto ou Local
• No caso típico de uso de um EJB, este é acessado remotamente.
– Cliente está em uma máquina.
– Container está em outra.
– Interação é feita através da rede.
• Mesmo no caso do cliente e container estarem na mesma máquina, em geral eles rodam em JVMs diferentes.
• No entanto, podemos utilizar as EJBs localmente.
– Isto é, quando cliente e EJB estão na mesma JVM.
– RMI não é necessário.
• Por este motivo, cada uma das interfaces do EJB (cliente e home) pode ter duas versões:
– Local: usada por clientes locais (mesma JVM).
– Remota: usada por clientes remotivos (JVM diferente).
Exemplo de Implementação de um EJB
• Do ponto de vista do desenvolvedor, tipicamente a implementação de um EJB é feita em várias etapas:
– Definição das interfaces cliente (local e remota).
– Definição das interfaces home (local e remota).
– Implementação do bean.
• Nos próximos slides, veremos como isto pode ser feito para um EJB de exemplo.
– ProfileServer.
– Provê informações sobre usuários identificados por nome.
Criação da Interface Cliente
• Interface do cliente contém métodos que estão disponíveis para chamada a partir do cliente.
– Métodos que permitem acesso à lógica de negócio da aplicação.
• Podem ser duas versões:
– Local.
– Remota.
Criação da Interface Cliente (Remota)
import java.rmi.RemoteException;
import javax.ejb.EJBObject;
import com.oreilly.jent.ejb.NoSuchPersonException;
public interface ProfileManager extends EJBObject {
public Profile getProfile(String acctName)
throws NoSuchPersonException, RemoteException;
}
• Interface deve estender a EJBObject.
• Que por sua vez estende a java.rmi.remote.
• Implicitamente faz com que a interface seja uma interface RMI remota.
• Neste exemplo, define um único método: getProfile().
• Retorna uma referência a um Profile (perfil do usuário).
• Poderia haver outros métodos, caso a lógica de negócio demandasse.
Criação da Interface Cliente (Remota)
import java.rmi.RemoteException;
import javax.ejb.EJBObject;
import com.oreilly.jent.ejb.NoSuchPersonException;
public interface ProfileManager extends EJBObject {
public Profile getProfile(String acctName)
throws NoSuchPersonException, RemoteException;
}
• Repare nas exceções que o método pode disparar:
• NoSuchPersonException: específica da aplicação (usuário não encontrado).
• RemoteException: específica do RMI.
• Denota problemas de comunicação.
Criação da Interface Cliente (Remota)
import java.rmi.RemoteException;
import javax.ejb.EJBObject;
import com.oreilly.jent.ejb.NoSuchPersonException;
public interface ProfileManager extends EJBObject {
public Profile getProfile(String acctName)
throws NoSuchPersonException, RemoteException;
}
• Último detalhe:
• Tipos dos argumentos e retorno devem ser serializáveis.
• Isso porque eles serão enviados pela rede.
• O tipo String em Java já tem esta característica.
• O tipo Profile (específico da aplicação) terá que ser implementado assim.
Criação da Interface Cliente (Local)
import javax.ejb.EJBLocalObject;
import com.oreilly.jent.ejb.NoSuchPersonException;
public interface ProfileManagerLocal extends
EJBLocalObject {
public Profile getProfile(String acctName)
throws NoSuchPersonException;
}
• Similar à interface cliente remota.
• Define o mesmo único método.
• Esperado, já que as mesmas funcionalidades do EJB devem estar disponíveis.
• Primeira diferença: estende interface EJBLocalObject.
• Não envolve RMI.
Criação da Interface Cliente (Local)
import javax.ejb.EJBLocalObject;
import com.oreilly.jent.ejb.NoSuchPersonException;
public interface ProfileManagerLocal extends
EJBLocalObject {
public Profile getProfile(String acctName)
throws NoSuchPersonException;
}
• Outra diferença:
• Apenas uma exceção possível (específica da aplicação).
• Não existe comunicação, logo não há exceção associada.
• Finalmente, não há exigência de parâmetros e retorno serializáveis.
• Embora, neste exemplo, eles sejam já que há uma versão remota da interface.
Criação da Interface Home
• Interface que permite ao cliente criar (ou encontrar) uma referência ao EJB.
– Para o cliente, esta referência é do tipo da interface cliente (local ou remota, dependendo do caso).
• Novamente, podem ser duas versões:
– Local.
– Remota.
Criação da Interface Home (Remota)
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
public interface ProfileManagerHome extends EJBHome {
public ProfileManager create() throws CreateException,
RemoteException;
}
• Interfaces home provêm métodos de criação de EJB.
• Container se encarrega de decidir se nova instância deve de fato ser criada ou se instância já existente pode ser aproveitada.
• Pode haver mais de uma versão do método create() recebendo argumentos diferentes.
• Interface deve estender EJBHome.
Criação da Interface Home (Remota)
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
public interface ProfileManagerHome extends EJBHome {
public ProfileManager create() throws CreateException,
RemoteException;
}
• No caso da interface remota, também implicitamente estamos definindo uma interface RMI.
• Por isso, os métodos devem poder criar exceções do tipo RemoteException.
• Além disso, método create() pode disparar também um CreateException.
• Indica um problema na criação da instância do EJB.
Criação da Interface Home (Remota)
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
public interface ProfileManagerHome extends EJBHome {
public ProfileManager create() throws CreateException,
RemoteException;
}
• Método create() deve retornar um tipo que corresponde à interface cliente.
• Neste caso (interface home remota), a interface cliente remota.
• A cada declaração do método create(), corresponderá um método ejbCreate() na implementação do EJB.
• Será visto a seguir.
Criação da Interface Home (Local)
import javax.ejb.CreateException;
import javax.ejb.EJBLocalHome;
public interface ProfileManagerLocalHome extends
EJBLocalHome {
public ProfileManagerLocal create() throws
CreateException;
}
• A interface local é bastante parecida.
• São definidos os métodos create().
• Algumas diferenças:
• Estende EJBLocalHome.
• Métodos não disparam exceção RemoteException.
Implementação do Bean
• Precisamos escrever uma classe Java que efetivamente implementa o Bean.
• Em geral, podemos dividir os métodos desta classe em três categorias:
– Métodos de lógica de negócio.
• Métodos chamados pelos clientes.
• Devem casar com as interfaces cliente.
– Métodos internos (auxiliares) da classe.
• Usados para auxiliar na implementação do lógica de negócio.
• Não são expostos nas interfaces (cliente ou home).
– Métodos que implementam callbacks para o container.
• Métodos que implementam funcionalidades usadas pelo container para gerenciar o ciclo de vida do Bean.
• Incluem (mas não estão restritos) aos métodos ejbCreate() correspondendo aos métodos create() declarados nas interfaces home.
Implementação do Bean (Exemplo)
• Todo EJB deve implementar a interface javax.ejb.EnterpriseBean.
• Geralmente, isso é feito de forma indireta, implementando uma das seguintes interfaces:
– SessionBean
– EntityBean
– MessageDrivenBean
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
import com.oreilly.jent.ejb.NoSuchPersonException;
public class ProfileManagerBean implements SessionBean {
...
Implementação do Bean (Exemplo)
• Método ejbCreate() deve ser implementado.
• Mas a interface javax.ejb.EnterpriseBean também define outros métodos mandatórios.
– ejbPassivate(): chamado quando o bean é serializado para a memória secundária.
• Bean deixa de estar ativo e estado é armazenado em memória secundária
public void ejbCreate() {
System.out.println("ProfileManagerBean created.");
}
public void ejbPassivate() {
System.out.println("ProfileManagerBean passivated.");
}
Implementação do Bean (Exemplo)
– ejbActivate(): chamado quando o bean é deserializado.
• Trazido de volta à memória para atender requisições de clientes.
– ejbRemove(): chamado quando o bean é removido do container.
– MessageDrivenBean
public void ejbActivate() {
System.out.println("ProfileManagerBean activated.");
}
public void ejbRemove() {
System.out.println("ProfileManagerBean removed.");
}
Implementação do Bean (Exemplo)
• Métodos de lógica de negócio:
– Devem corresponder aos métodos da interface cliente.
• Neste exemplo, só há um método neste grupo.
• Este método faz referência ao método interno validateName().
public Profile getProfile(String name) throws
NoSuchPersonException {
if (!validateName(name)) {
throw new NoSuchPersonException("No user found
matching name \"" + name + "\"");
}
Profile profile = new
com.oreilly.jent.ejb.stateless.Profile(name);
return profile;
}
Implementação do Bean: Outras Regras
• Classe que implementa um EJB deve ser pública.
– Permite que o container invoque métodos da classe diretamente.
• A classe não implementa a interface home diretamente.
– Não há métodos create().
– Apenas os correspondentes ejbCreate().
– Container faz o intermédio entre as duas versões dos métodos.
– Entre os artefatos gerados pelo container, estão classes que, de fato, implementam a interface home.
• Proxy.
Próxima Aula
• Disponibilização do EJB no container.
– Arquivo descritor.
– Opções de Segurança.
– Empacotamento do EJB.
• Utilização do Bean no lado cliente.
– Clientes locais vs. Clientes Remotos.
– Localização de interfaces home.
– Criação de beans.
– Invocação de métodos.