Introdução ao java EE Enterprise Java Beans Métodos Assíncronos Injeção de Dependência e ...

111 Pages·2014·1.81 MB·Portuguese

Introdução ao java EE
Enterprise Java Beans
Métodos Assíncronos
Injeção de Dependência e JNDI ENC
Agendamento
Interceptadores
Transações
Segurança
Empacotamento

Erick Ferreira Macedo
Introdução ao java EE

Razões para usar EJBs

• Escalabilidade é obrigatória , EJBs podem ser distribuídos em múltiplos computadores
enquanto permanecem transparente para o clientes
• Transações são obrigatórias.
• Diferentes tipos de cliente podem acessar a aplicação , EJBs podem ser acessados de
múltiplas maneiras ; EJBs Local e Remoto , e WebService Soap e Rest.
• Gerenciamento de concorrência é desejável. O Container EJB gerencia a concorrência.
• Segurança é obrigatória, disponível como segurança declarativa não afetando a
implementação , também permite segurança programática
• Portabilidade em diferentes servidores é desejável.

Razões para não usar EJBs

• Container EJB não é desejado.
• Container EJB não está disponível
• Uma ou mais das restrições de programação EJB não pode ser respeitada.

Como alternativa você pode usar um servidor de aplicação que contem um container embeddable EJB
3.1 que permite somente o uso do EJB Lite

EJB Restrições Programática

Há uma série de restrições de programação que um desenvolvedor EJB deve seguir, a fim de
garantir a portabilidade entre diferentes Container

Programming Restriction Motivation
Um EJB não deve usar campos estáticos Garantir a consistência em um ambiente
graváveis. distribuído.
Um EJB não deve usar primitivas de Não vai funcionar em um ambiente
thread synchronization para sincronizar a distribuído.
execução de múltiplas instâncias, exceto
se o EJB é um bean de sessão Singleton
com bean managed concurrency.
Um EJB não deve usar a funcionalidade Servidores geralmente não permitem o
de AWT para gerar a saída para um acesso ao teclado ou a tela de um
monitor ou obter entrada de um teclado. programa aplicativo.
Um EJB não deve acessar arquivos e Os componentes de negócios deve usar
diretórios no sistema de arquivos uma API do gerenciador de recursos, tais
diretamente. como JDBC, para acessar os dados
persistentes.
Um EJB não deve agir como um servidor Conflitos com os deveres do servidor de
de rede, escuta em um soquete, aceitar aplicativos.
conexões em um soquete ou usar um
soquete para múltiplos cast.
Ele pode atuar como um cliente socket de Poderia comprometer a segurança.
rede.
Um EJB não deve tentar definir a fábrica Poderia comprometer a segurança.
de soquete usado por ServerSocket e Interfere com a capacidade do container
soquete ou tentar definir a fábrica de para gerenciar o ambiente de tempo de
manipulador de fluxo usado por URL. execução.
Um EJB não deve tentar gerenciar threads Interfere com a capacidade do container
ou grupos de threads. para gerenciar o ambiente de tempo de
execução.
Um EJB não deve tentar ler ou escrever Poderia comprometer a segurança.
um descritor de arquivo diretamente.
Um EJB não deve tentar obter as Poderia comprometer a segurança.
informações de política de segurança para
uma fonte de código particular.
Um EJB não deve tentar carregar uma Poderia comprometer a segurança.
biblioteca nativa.
Um EJB não deve tentar burlar as regras Poderia comprometer a segurança.
da linguagem de programação Java ao
acessar pacotes e classes.
Um EJB não deve tentar definir uma Poderia comprometer a segurança.
classe em um pacote.
Um EJB não deve tentar acessar ou Poderia comprometer a segurança.
modificar os objetos de configuração de
segurança (Policy, Security, Provider,
Signer e Identity).
Um EJB não deve tentar usar a subclasse Poderia comprometer a segurança.
ou recursos objeto de substituição do
Protocolo de serialização Java.
Um EJB não deve passar isso como um O container pode usar um mecanismo de
argumento de método ou resultado. Em proxy para, por exemplo, controlar o
vez disso, utilizar o resultado de um dos acesso simultâneo da instância EJB. A
métodos getXXXObject no referência injetado em clientes
SessionContext ou do EJB é uma referência para o proxy e
classe EntityContext. não a uma instância da classe de
implementação EJB.

Container EJB Lite VS EJB Full

EJB Lite é um subconjunto da API do EJB 3.1 , permitindo que os desenvolvedores de EJB reduza a
dimensão e complexidade enquanto continua sendo compatível com e especificação EJB 3.1.

Feature Full EJB 3.1 API EJB 3.1 Lite API
Java Persistence 2.0 Disponível Disponível
Session beans local/no interface client view. Disponível Disponível
Session beans 3.0 remote client view. Disponível Não Disponível
Session beans 2.x remote client view. Disponível Não Disponível
Session beans exposed as JAX-WS web Disponível Não Disponível
service endpoints.
Session beans exposed as JAX-RPC web Disponível Não Disponível
service endpoints.
EJB timer service. Disponível Não Disponível
Asynchronous invocation of session beans. Disponível Não Disponível
RMI-IIOP interoperability. Disponível Não Disponível
Message driven beans. Disponível Não Disponível
Interceptors Disponível Disponível
Bean and container managed transactions. Disponível Disponível
Declarative and programmatic security. Disponível Disponível
Embeddable API. Disponível Disponível

Session Beans - Stateful, Stateless ou Singleton

Existe três tipos de EJB Session Beans – Stateful , Stateless ou Singleton

Stateful Session Beans

Beans de sessão com estado, mantem o estado de conversação com um único cliente , as razões para
escolher são :

- O EJB precisa manter o estado com o cliente entre diferentes invocações
- O EJB fica transparente para o cliente.
- O EJB gerencia o fluxo de outros EJBs.

Stateless Session Beans

Beans de sessão sem estado pode existir em um pool no qual o Container pode escolher qualquer
Bean para servir a requisição. Stateless pode manter o estado de uma variável de instancia mais não
com um cliente especifico, as razões para escolher são :

- O EJB não precisa manter um estado especifico com o cliente.
- O EJB tem uma melhor escalabilidade
- O EJB tem uma melhor performance
- O EJB pode ser exposto com um WebService
- O EJB executa tarefas genéricas que pode ser terminado em uma única invocação de método

Singleton Session Beans

Beans Singleton são Beans o quais existe somente uma única instancia por aplicação , eles podem ser
configurados para permitir acesso concorrente , porem cuidados especiais devem ser tomados quando
se projeta um EJB Singleton afim de proteger recursos que não deve ter acesso concorrente, as
razões para escolher são :

- O EJB compartilha o estado por toda aplicação
- O EJB é acessado por varia threads simultaneamente
- O EJB pode ser usado para inicializar ou finalizar uma tarefa no contexto da aplicação.
- O EJB pode ser exposto com um WebService

Tipos de acesso do Cliente (Local , Remote ou WebService)

- Local : é acessado na mesma aplicação , mesma JVM Ex: Web Componente e EJBs.
- Remote : é acessado na mesma JVM ou VMs que estão em outro computadores
Ex:Web Componente, EJBs e aplicação clientes.
- WebService : Um Session Bean pode ser exposto como SOAP ou RESTful e permite acesso a
qualquer WebService cliente em qualquer linguagem.
Message Driven Beans

Beans MDB são EJB para processar mensagens, as razões para escolher são :

- O EJB pode ser invocado por mensagem assíncrona.
- O EJB pode executar processo de negócio de longa duração sem afetar o cliente.
- O EJB mantem baixo acoplamento com cliente, pois o cliente não se relaciona com o EJB.

Enterprise Java Beans
Session Beans
Utilizando a arquitetura EJB, as regras de negócio são implementadas em componentes específicos
que são chamados de SessionBeans. O Container EJB administra esses componentes oferecendo
diversos recursos a eles.
As características dos EJBs favorecem a escalabilidade da aplicação pois, de acordo com a demanda,
o Container EJB cria novas instâncias e cada instância pode atender vários clientes.
O Container EJB administra as instâncias criadas através de um Pool. Cada servidor de aplicação
oferece configurações específicas para melhorar a eficiência no atendimento das chamadas.

Na versão 3.1, o acesso a um EJB local não necessita de uma interface java nem a utilização da
anotação @Local, então basta criar uma classe java anotada com a anotação @Stateless e somente
método públicos do bean serão visíveis, como alternativa poderá ser usado a anotação @LocalBean, o
resultado em ambos os casos é o mesmo, o EJB fica visível apenas na JVM que estiver sendo
executado [visibilidade local].
Além disso, as regras de empacotamento foram simplificadas, os Session Beans podem ser
empacotados em um módulo web.

Uma interface de negocio pode ser uma interface remota ou local, mais não ambas. Quando o cliente
invoca um método em uma interface remota do Bean de sessão, os valores são passado por valores,
isso é independente se o cliente está na mesma VM ou em outra maquina da rede.

Beans de entidades são objetos Java simples, eles podem ser serializados pela rede como objetos java
simples, deste que implementam java.io.Serializable ou Externalizable.

Descritor de implantação

O EJB tem um descritor de implantação XML opcional definido no arquivo META-INF/ejb-jar.xml
do arquivo JAR do EJB

Ex:

<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>PaymentBean</ejb-name>
<remote>br.PaymentRemote</remote>
<local>br.PaymentLocal</local>
<ejb-class>br.PaymentBean</ejb-class>
<session-type>Stateless</session-type>

<resource-ref>
<res-ref-name>dsOracle</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<mapped-name>java:/DefaultDS</mapped-name>
<injection-target>
<injection-target-class>com.Bean</injection-target-class>
<injection-target-name>oracleDB</injection-target-name>
</injection-target>
</resource-ref>

<env-entry>
<env-entry-name>minNumber</env-entry-name>
<env-entry-type>java.lang.Integer</env-entry-type>
<env-entry-value>2000</env-entry-value>
<injection-target>
<injection-target-class>com.Bean</injection-target-class>
<injection-target-name>minNumber</injection-target-name>
</injection-target>
<env-entry>

</session>
</enterprise-beans>
</ejb-jar>

O element <enterprise-beans> contido em <ejb-jar> define um conjunto de EJBs.
O elemento <session> denota que você está implantando um bean de sessão.
O elemento <ejb-name> fornece uma identidade ao bean de sessão que você pode referenciar.
Os elementos <remote> e <local> identificam a interface de negocio do bean.
O elemento <ejb-class> declara a classe do bean.
O elemento <session-type> declara o tipo do bean
Os elementos <resource-ref> e <env-entry> inicializa os campos dsOracle e minNumber da
classe do bean.

O descritor de implantação XML também suporta definições XML parciais.

<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>PaymentBean</ejb-name>
<env-entry>
<env-entry-name>minNumber</env-entry-name>
<env-entry-type>java.lang.Integer</env-entry-type>
<env-entry-value>250</env-entry-value>
</env-entry>
<session>
<enterprise-beans>
</ejb-jar>

EJBContext e SessionContext

EJBContext

Fornece uma visualização do ambiente container

Definição da interface javax.ejb.EJBContext
Métodos

• getCallerPrincipal : é utilizado para obter o objeto java.security.Principal que representa o
cliente
• isCallerInRole : informa se o cliente que acessa o bean é membro de um nível de regra
especifico, identificado pelo nome da regra.
• getRollbackOnly() : método transacional, retorna true se a transação foi marcada para
rollback, utilizado somente em CMT
• setRollbackOnly() : método transacional, um EJB consegui vetar uma transação que é
marcada para rollback e não pode ser confirmada por nenhum outro participante da transação,
incluindo o container, utilizado somente em CMT
• getUserTransaction(): método transacional para controlar programaticamente as transações,
utilizado somente em BMT
• getTimerService : retorna a referencia do TimerService do container, que permite que o bean
sem informação de estado configure notificações dos eventos sincronizados para ele mesmo
que atualmente está acessando o bean
• lookup : é um método conveniente que permite pesquisar entradas no ENC do EJB.
• getContextData() : O método getContextData habilita um método de negócio, o método do
ciclo de vida, ou método de timeout , para recuperar qualquer contexto interceptores /
webservices associada à sua invocação.
• getEnvironment() ,isCallerInRoler(Identity role), getCallerIdentity(),
getEJBHome(),getEJBLocalHome() estão obsoletos e uma RuntimeException é lançada se
esses métodos forem executados.

SessionContext

A interface javax.ejb.SessionContext extends javax.ejb.EJBContext fornece uma visualização do
ambiente do container EJB
SessionContext permite obter informações como o usuário atual que está invocando no EJB ou
pesquisar entradas dentro do ENC do EJB.
Quando um instancia é trocada seu SessionContext muda para refletir o contexto do objeto EJB e o
cliente que invoca o método.

Definição da interface javax.ejb.SessionContext

Métodos

• EJBLocalObject e getEJBObject : deprecated, lança uma exceção se invocado.
• getMessageContext : O método getMessageContext retorna a interface
javax.xml.rpc.handler.MessageContext de um bean de sessão sem estado que implementa um
JAX-RPC web service endpoint
• getInvokedBusinessInterface : permite determinar se seu EJB foi invocado por meio de uma
interface local, remota ou serviço web. Ele retorna a interface de negocio invocada como uma
classe.
• getBusinessObject : retorna uma referência ao EJB atual que pode ser invocado por outros
clientes, já que é ilegal que uma instancia de bean passe uma referencia this a um outro bean,
o parâmetro businessInterface precisa ser uma das interfaces Local ou Remota do EJB.
• wasCancelCalled : É usado para verificar se o cliente cancelou o método assíncrono

Regras EJB

• A classe do Bean deve ser concreta, não pode ser final ou abstrata, uma vez que o container
precisa manipular ela.
• Deve ter um construtor sem argumentos, o container invoca esse construtor para criar o Bean,
observe que o compilador insere o construtor sem argumentos padrão.
• Um EJB pode ser uma subclasse de outro EJB ou de um POJO
• Os métodos de negocio e callback do EJB serão herdados de uma super classe, ou seja,
podem ser definidos em uma superclasse
• As anotações @Stateless e @Statefull na superclasse, será ignorada na subclasse e somente
método de ciclo de vida e atributos de recursos
• são herdados.
• Os nomes dos método de negocio não devem começar com "ejb", mais podem.
• Os métodos de negocio, devem ser públicos não finais ou estáticos, gera conflitos.
• Argumentos de método com EJB remoto deve implementar Serializable.
• Você não pode marcar a mesma interface com mais de uma anotação
• Você não pode ter mais de um método de ciclo de vida na mesma classe EJB.

Erros :
Caused by: java.lang.RuntimeException: br.PaymentEJBBean is final
Caused by: java.lang.RuntimeException: Could not create an instance for
bean class: class br.PaymentBean (se abstract)
Caused by: java.lang.RuntimeException: Could not create no-interface view
for bean class: class br.PaymentEJBBean (sem constructor default)
Caused by: javax.ejb.EJBException: Cannot invoke method imprimir on
nointerface view (caso protected)
Caused by: java.lang.RuntimeException: More
than one 'post-construct' method in PaymentEJBSingleton
Caused by: java.lang.RuntimeException: More than one 'pre-destroy' method
in PaymentEJBStateless

Interface local não é necessária estender a nenhuma outra interface. No EJB 2.1 ou anterior era
obrigatório estender a javax.ejb.EJBLocalObject.

Interface remota não é necessária estender a nenhuma outra interface. No EJB 2.1 ou anterior era
obrigatório estender a javax.ejb.EJBObject

Existe três tipos de Session Beans (Stateless , Stateful , Singleton)

• Stateless : O Bean não mantem o estado e server qualquer cliente
• Stateful : O Bean mantem o estado com um único cliente
• Singleton : O Bean é compartilhado entre todos cliente, permite gerenciamento concorrente
pelo bean ou container.
As classes de implementação dos Session Beans são anotadas com @Stateful, @Stateless ou o
@Singleton. Elas contem os seguintes elementos opcionais.

Elemento Opcional Descrição
description Descrição sobre o Session Bean
mappedName Usado para especificar ao fornecedor
informações de para deploy, o uso desse
elemento não torna o EJB portátil
name O EJB-name do bean.
O padrão é o nome não qualificado da classe

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar version="3.1" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="
http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-
jar_3_1.xsd">
<enterprise-beans>
<session>
<ejb-name>StatefulSession1</ejb-name>
<local>com.ivan.scbcd6.StatefulSession1Local</local>
<ejb-class>com.core.StatefulSession1Bean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
...
</ejb-jar>

O <session-type> pode conter os seguintes valores Singleton, Stateful e Stateless
Visualização dos Sessions Beans
As anotações @LocalBean, @Local e @Remote são usada para especificar a disponibilidade dos
session beans .
@LocalBean : Essa anotação é usada na classe de implementação para disponibilizar uma
visualização Local sem interface, está anotação não contem atributos.
Ex: @LocalBean

@Local : Essa anotação é usada para anotar uma interface que será implementada pela classe no
Bean ou na própria classe do Bean para especificar a interface, disponibiliza uma visualização Local
com interface, está anotação contem o atributo value que recebe um array de classes (Class[]).
Ex : @Local({IStatefulSessionLocal 1.class , IStatefulSessionLocal 2.class} )

@Remote : Essa anotação é usada para anotar uma interface que será implementada pela classe no
Bean ou na própria classe do Bean para especificar a interface, disponibiliza uma visualização
Remota com interface, está anotação contem o atributo value que recebe um array de classes
(Class[]).
Ex : @Remote(value = {IStatefulSessionRemote1.class , IStatefulSessionRemote2.class} )

No descritor de implantação os elementos <local-bean>, <local> e <remote>, pode ser usado para
especificar os diferentes tipo visualização dos Session Beans

Exemplo de um descritor de implantação para a anotação @LocalBean
Configuração no deployment descriptor (ejb-jar.xml) um EJB no-interface
<ejb-jar .>
<enterprise-beans>
<session>
<ejb-name>StatelessSessionBean </ejb-name>
<local-bean />// equivalente @LocalBean
<ejb-class>com.StatelessSessionBean</ejb-class>
<session-type>Stateless</session-type>
</session>
</enterprise-beans>
</ejb-jar>

Ciclo de vida

• @PostConstruct : Invocado depois da instancia ser criada e antes de ser usada, permite
inicializações para o Bean. Disponível em Stateless, Statefull, Singleton e MDB.
• @PreDestroy : Invocada quando a instancia do Bean está sendo retirada pelo Container,
usado para liberar recursos. A classe do bean só pode definir um método PreDestroy. A
especificação não garante que o @PreDestroy será invocado se o Bean lançar exceções de
sistemas , ou o container travar ou timeout ocorrer quando o Stateful estivar passivado.
Disponível em Stateless, Statefull Singleton e MDB
• @PrePassivate : Invocado antes do Stateful ser passivado. o container pode decidir
desativar uma instancia temporariamente se não estiver em uso, usado para liberar recursos
e manipular, salvar dados de objetos que não podem ser serializados. Disponível em Stateful
• @PostActivate : Invocado depois do Stateful ser ativado, o container pode decidir ativar
novamente quando o cliente precisar dela, usado para realocar recursos e reconstituir
objetos que não foram serializados na passivação. Disponível em Stateful