Enterprise Java Beans (I)diego/disciplinas/2014_2/... · Enterprise Java Beans (III) • O J2EE define três tipos diferentes de EJBs. –Beans de sessão. •Tipicamente não persistente.

Enterprise Java Beans (I)

Professor: Diego Passos

UFF

[email protected]

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.








}

• 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.








}

• Ú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;


public interface ProfileManagerLocal extends

EJBLocalObject {


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;


public interface ProfileManagerLocal extends

EJBLocalObject {


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 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.







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.







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.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;


public class ProfileManagerBean implements SessionBean {

...


• 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.");

}


– 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.");

}


• 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.

Enterprise Java Beans (I)diego/disciplinas/2014_2/... · Enterprise Java Beans (III) • O J2EE define três tipos diferentes de EJBs. –Beans de sessão. •Tipicamente não persistente.

Documents