Java EE EJB 3.0

Java EE com EJB 3.0 (JSR-220)
Outubro de 2007

Audiência, pré-requisitos e
referências
 Audiência
 Desenvolvedores que desejam aprender sobre a plataforma JEE
 Pré-requisitos
 Desenvolvedores com pelo menos 1 ano de experiência em sistemas
distribuídos, usando tecnologia Java (web/cliente servidor)
 Referências (material de apoio)
 EJB 3.0 - livro: Mastering Enterprise JavaBeans Third Edition – ISBN-10:
0764576828
 Disponível para download, gratuito, no site http://www.theserverside.com
 Possui código fonte disponível (exemplos)
 http://www.theserverside.com/tt/books/wiley/masteringEJB/index.tss
 JPA -
http://www.theserverside.com/tt/articles/content/JPA101_Chapter/article.htm
l
 NetBeans IDE – versão 5.5.1
 http://www.netbeans.org/


Ementa do curso

Introdução à conteiners EJB e a necessidade de ambientes distribuídos

Plataforma Java EE e Containers EJB

JBoss Application Server

Introdução ao Java EE 5

Java EE 5 – Especificações

Java EE 5 x J2EE - Diferenças

EJB 2.1 x EJB 3.0 – O que mudou?

EJB 2.1 – Características

EJB 2.1 – Limitações

EJB 3.0 – Características

EJB 3.0 – Especificações

EJB 3.0 – Novidades

EJB 3.0 - Interoperabilidade com EJB 2.x

Ementa do curso

Stateless Session Beans

Statefull Session Beans

SessionBeans e WebServices

Introdução à JPA

Serviço de Email

Introdução a JMS e Message Driven Beans

EJB 3.0 - Transações

Segurança com JAAS

EJB Timers e Interceptors

Capítulo 1
Introdução à containers EJB e a
necessidade de ambientes
distribuídos

necessidade de ambientes distribuídos
 Plataforma Java EE e Containers EJB
 A plataforma Java EE é baseada em um modelo de componentes bem
definido, robusto, escalável e em constante evolução. Cada
componente da plataforma Java EE tem como foco objetivos
específicos de uma aplicação corporativa, e dessa forma tais
componentes executam em um ambiente de execução especial,
conhecido como container Java EE.
 Um servidor de aplicações Java EE possui basicamente dois tipos de
container: o container Web onde são disponibilizados e executados os
componentes Servlet e JSP, responsáveis pela camada de
apresentação de uma aplicação corporativa, e o container EJB onde são
executados os componentes Enterprise Java Beans, responsáveis pelas
regras de negócio e de acesso a dados de uma aplicação corporativa.
 O primeiro benefício direto dessa divisão é permitir aos
desenvolvedores focar nas características específicas de um
determinado componente e ambiente de execução e também

 Entretanto, o maior benefício resultante dessa abordagem é poder tirar
proveito de toda a infra-estrutura de serviços que um servidor de
aplicações Java EE (e seus containers) oferece, possibilitando obter de
forma transparente suporte para vários serviços tais como segurança,
controle de transações, resource pooling (instâncias de objetos,
conexões e outros), controle automático do ciclo de vida dos
componentes e outros, evitando a recorrência dessa preocupação em
projetos e permitindo aos desenvolvedores focar na implementação
das regras de apresentação, navegação, integração e regras de
negócios específicas de uma determinada solução, de acordo com o
nicho de negócios específico que uma solução deve atender
(financeira, telecomunicações, agronegócios e outros).
 O slide seguinte mostra a arquitetura típica de um servidor de
aplicações, destacando os containers Web e EJB e os serviços e APIs
que suportam os componentes que executam nesses containers.

Data
necessidade de ambientes distribuídos JDBC

Application Logic
RDBMS
Client
JavaMail
HTML/ Web Container
XML Mail Server

Servlets JSPs J2EE RMI
Application
Server Java Application
RMI/IIOP

JavaMail
JDBC
JNDI

JMS
JTA

JAF
Applet
EJB Container IIOP

Session Beans Entity Beans
CORBA
Client JNDI
Application
RMI/IIOP

JavaMail
JDBC
JNDI

JMS
JTA

JAF
Directory Services
JMS

Message Queue

 Considerando especificamente os componentes Enteprise Java Beans,
desde a primeira versão da especificação EJB esse modelo de
componentes considera a necessidade de execução e suporte a um
ambiente distribuído, onde componentes específicos executam em
camadas distintas e tem responsablidades bem definidas.
 Como consequência, para obter a confiabilidade e robustez que são
requisitos mais cruciais de uma aplicação corporativa, um ambiente
distribuído deve suportar vários aspectos tais como suporte a chamada
remota de métodos (RPC-Remote Procedure Call), balanceamento de
carga (load-balancing), suporte à falhas (failover), operação em
cluster, controle de transações e execução concorrente, apenas para
citar alguns aspectos importantes.
 Como já foi citado anteriormente, tais questões são endereçadas de
forma transparente por um servidor de aplicações Java e, obviamente,
por um container EJB.

Introdução à conteiners EJB e a
necessidade de ambientes
distribuídos
 JBoss Application Server
 JBoss é um servidor de aplicação Java EE certificado para o
desenvolvimento e disponibilização de aplicações Java
Enterprise, sendo que o mesmo nasceu como um projeto Open-
source, logo no início da especificação de Enteprise Java Beans.
Na época, estavam disponíveis apenas containers Web sendo o
mais conhecido o Tomcat e então foi criado o projeto EJBOSS
(EJB Open-Source Software) e posteriormente o seu criador
mudou o nome do projeto para JBOSS.
 Atualmente é considerado o servidor de aplicações líder de
mercado, com o maior número de deployments mundialmente,
sendo que o JBoss Group agora é parte da Red Hat, que
adquiriu o mesmo em 2006.
 O JBoss é o servidor de aplicações utilizado para a realização

Capítulo 2

 “O Java EE 5 reduz significativamente o custo e a
complexidade para o desenvolvimento e
disponibilização de soluções multi-camadas, resultando
em serviços que podem ser disponibilizados e
extendidos de forma simples e rápida” - Sun
Microsystems
 O Java EE 5 define uma especificação que engloba
outras especificações que são componentes da
plataforma Java EE 5, sendo essa especificação
chamada de “umbrella”
 Java Platform, Enterprise Edition 5 (Java EE 5) - JSR-
244

Java EE 5 - Especificações
 APIS WebServices
 Implementing Enterprise Web Services
 JSR-109 - http://jcp.org/en/jsr/detail?id=109
 Java API for XML-Based Web Services (JAX-WS) 2.0
 Java API for XML-Based RPC (JAX-RPC) 1.1
 Java Architecture for XML Binding (JAXB) 2.0
 SOAP with Attachments API for Java (SAAJ)
 Streaming API for XML
 Web Service Metadata for the Java Platform

 APIs Web
Java Servlet 2.5
JSR-154 - http://jcp.org/en/jsr/detail?id=154
JavaServer Faces 1.2
JavaServer Pages 2.1
JavaServer Pages Standard Tag Library

 APIs Enterprise (inclui EJB 3.0)
 Enterprise JavaBeans 3.0
 J2EE Connector Architecture 1.5
 Common Annotations for the Java Platform
 Java Message Service API

 APIs Enterprise (continuação)
 Java Persistence API
 Java Transaction API (JTA)
 JavaBeans Activation Framework (JAF) 1.1
 JavaMail

 APIs de Segurança e Gerenciamento
 J2EE Application Deployment
 J2EE Management
 Java Authorization Contract for Containers

 J2EE, poderoso mas complexo
 Java EE 5 mantêm as capacidades da plataforma, mas agora de
forma muito mais simples e produtiva, sendo esse o foco
principal da JSR-24
 Características do Java EE 5
 Uso de Annotations
 Alteraa forma como as bibliotecas e as ferramentas tratam
o código
 Conventions (or container defaults)
O desenvolvedor deixa a maior parte do trabalho de
configuração para os containers, que fornecem um conjunto
bem definido de valores default, que foram convencionados
levando em conta os casos mais comuns

 Dependency Injection
 “Do not call me, I will call you”. As dependências são
injetadas automaticamente nos componentes pelo
container, com ajuda das annotations. Não é preciso buscar
os recursos explicitamente
 Deployment Descriptors são opcionais
 “boilerplate code” ficou obsoleto e os deployment
descriptors são opcionais
 Mecanismo Leve de Persistência
 JPA - Modelo de persistência unificado, não limitado a EJBs.
As classes podem ser usadas em outros componentes,
inclusive fora do servidor de aplicação. As Entities agora são
classes POJO, (Plain Old Java Object), suportando conceitos

 Entity Manager API
 Principal mudança do Java EE 5, considerando a interação
com banco de dados. O EM gerencia o ciclo de vida e estado
das entities, suportando CRUD, pesquisa, execução de
queries (inclusive dinâmicas), mecanismo de vinculação,
liberação e unificação (attach/detach/merge)
 JP-QL – Java Persistence QL
O antigo EJB-QL 2.1 foi melhorado e agora suporta: named
queries, queries com named parameters, dynamic queries,
bulk updates e deletes. O JP-QL também suporta queries SQL
nativas
 Característicasherdadas dos “concorrentes” – JBoss
Hibernate, Oracle Toplink, JDO

Capítulo 3
EJB 2.1 x EJB 3.0 – O que mudou?

EJB 2.1 x EJB 3.0 – Diferenças
 EJB 2.1 - Características
 Apesar da especificação EJB 2.1 possuir recursos poderosos
(mas ainda assim ser incompleta), a mesma é muito complexa
 Muitas classes e interfaces que devem ser implementadas
 JNDI lookups – não existe DI
 Uso de interfaces do pacote javax.ejb
 Modelo de programação confuso
 Deployment Descriptors (DDs) são obrigatórios
 Vários anti-patterns - Entity Beans

 EJB 2.1 - Limitações
 Para criar um EJB simples você precisar criar vários DDs,
geralmente um definido pela especificação e um proprietário,
de acordo com servidor de aplicação alvo
 Um conjunto de três arquivos-fonte (pelo menos) deve ser
criado
 Múltiplos métodos callback devem ser implementados e alguns
possivelmente nem serão usados
 Você tem que arremesar e tratar vários tipos de exceções,
desnecessariamente
 Os EJBs não podem ser testados fora do container;
 EJB-QL é limitada e difícil de usar, forçando a utilização de JDBC
e SQL ou outro mecanismo de persistência para cobrir as

 EJB 3.0 - Características
 Facilidade no desenvolvimento, simplicidade
 Poucas classes e interfaces, uso de POJOs (Plain Old Java
Objects) e POJI (Plain Old Java Interfaces)
 Dependency Injection (sem JNDI lookups)
 Não requer implementação de interfaces específicas
 Não requer deployment descriptors (opcional)
 Mecanismo de persistência simplificado
 Mapeamento O/R robusto e com suporte a conceitos OO
(herança, polimorfismo, etc)

 EJB 3.0 - Especificações
 JSR-000220 Enterprise JavaBeans 3.0 – FR (Final Release) –
Specifications
 As especificações foram segmentadas visando facilitar o aprendizado
por parte dos desenvolvedores de aplicações, bem como a
implementação dos containers EJB por parte dos desenvolvedores de
servidores de aplicações (Vendors)
 Desenvolvedores de aplicações que desejam usar EJB 3.0 para
aplicações comerciais, corporativas
 Enterprise JavaBeans 3.0 Final Release (ejbcore)
 ejb-3_0-fr-spec-ejbcore.pdf
 Enterprise JavaBeans 3.0 Final Release (persistence)
 ejb-3_0-fr-spec-persistence.pdf
 Enterprise JavaBeans 3.0 Final Release (simplified)
 ejb-3_0-fr-spec-simplified.pdf

 EJB 3.0 - Especificações
 Desenvolvedores que desejam construir um container que
implementa as especificações de EJB 3.0
 Enterprise JavaBeans 3.0 Final Release (ejbcore)
 ejb-3_0-fr-spec-ejbcore.pdf
 Enterprise JavaBeans 3.0 Final Release (persistence)
 ejb-3_0-fr-spec-persistence.pdf
 Enterprise JavaBeans 3.0 Final Release (simplified)
 ejb-3_0-fr-spec-simplified.pdf

 EJB 3.0 - Novidades
 DI – Dependency Injection
 Os recursos são injetados quando a instância é construída.
Referências para:
 EJBContext

 DataSources

 UserTransaction

 Environment Entries
 EntityManager

 TimerService

 Outros EJBs

 Visão do cliente (client view) simplificada
 Session beans agora usam interfaces Java simples
 Não requer EJB(Local)Home interfaces
 Não requer EJB(Local)Object interfaces

A classe do bean (bean class) é uma classe Java simples,
portanto:
 É uma classe Java plana (POJO)
 Implementa interfaces Java comuns (POJI)

 JPA – Java Persistence API
 Simplifica
o modelo de programação de entidades (agora
chamadas de entities e não entity beans)
 Suporte para modelagem OO, incluindo herança e
polimorfismo
 Endereça as limitações anteriores que existiam para as
queries EJB-QL
 Suportamapeamento O/R de forma robusta e com várias
abordagens
 As entidades podem ser usadas (e testadas) fora do
container
 Remove a necessidade de usar alguns patterns, como

 JPA – Mapeamento O/R
 Facilidadepara que os desenvolvedores Java executem o
mapeamento de um modelo de objetos para um banco
relacional
Odesenvolvedor fica seguro sobre o mapeamento entre o
DB Schema e o modelo de domínio dos objetos
O desenvolvedor controla o mapeamento da forma como
quiser, restrito ao modelo do banco
 Osmapeamentos podem ser expressos usando annotations
ou XML

 JPA – Entity Manager
O EntityManager serve como uma interface “home”
genérica, considerando as operações que envolvem entities
 Possui métodos para gerenciamento do ciclo de vida do
bean
 Persist, remove, merge, flush, refresh, etc

 Funcionalidadesimilar ao Hibernate Session, JDO
PersistenceManager e outros similares

 EJB 3.0 - Interoperabilidade com EJB 2.X
 Aplicações escritas usando a API EJB 2.1 e anteriores funcionam
sem alterações nos containers EJB 3.0 (backward compatibility)
 Flexibilidade para migração de containers
 Novas aplicações usando EJB 3.0 podem ser clientes de EJBs
antigos (specs anteriores), sem mudanças na visão do
cliente pré-existente

EJB 3.0 – exercício
 Iniciar o IDE NetBeans e selecionar File > New
Project > Enterprise > Enterprise Application.
Definir o nome do projeto como JavaEEcomEJB3.0,
selecionar o servidor Jboss Application Server 4,
selecionar a Java EE version como Java EE 5,
aceitar o checkbox que define os nomes para os
projetos web (Create Web Application Modue) e ejb
(Create EJB Module). Clicar em Finish (próximo
slide). Os projetos Enteprise (Java EE 5), EJB 3.0 e
Web serão mostrados na aba Projects do NetBeans
(slide seguinte).

EJB 3.0 – criação do projeto

Capítulo 4
Stateless Session Beans (SLSB)

Stateful Session Beans - definição
 Independente da versão de EJB em questão (EJB 2.x. ou 3.0),
geralmente um session bean é um componente reusável que
possui serviços (métodos) que suportam uma determinada regrada
de negócio. Os serviços desse session bean são definidos
basicamente pela sua interface de negócio (business interface),
que por sua vez também passou a ser um POJI.
 Um stateless session bean, como o próprio nome diz, não guarda
estado entre duas invocações de um dos seus métodos, sendo que
um mesmo cliente poderá usar duas instâncias diferentes de um
session bean quando chamando um mesmo método,
consecutivamente, não há garantia que uma mesma instância será
usada para um mesmo cliente (o container mantém um pool de
instâncias do stateless session bean).

Stateless Session Beans - definição
 Dessa forma, o importante é lembrar que um stateless
session bean não armazenará estado entre duas
chamadas de método e que dessa forma, todo o estado
que um determinado método de negócio necessita para
operar corretamente deve ser passado na chamada ao
método.
 No contexto específico da especificação EJB 3.0, um
stateless session bean passou a ser basicamente um
POJO, com a diferença que esse POJO também pode ser
gerenciado pelo container e não exige a implementação
de interfaces específicas, como javax.ejb.SessionBean.

Stateless Session Beans - definição
 Uma referência indireta (stub) para um stateless session
bean pode ser recuperada através do nome da interface,
utilizando um busca (lookup) no contexto JNDI ou então pode
ser injetado (dependency injection) através da anotação
@EJB, sendo essa a grande novidade do EJB 3.0. No caso,
não é mais necessário ter uma Home interface como era o
caso de versões de EJB anteriores ao EJB 3.0.
 As interfaces de negócio de um session bean podem ser
declaradas como remotas ou locais - @Remote ou @Local,
dependendo da anotação que for usada na classe do bean e
como default será definida como local caso não seja
especificada nenhuma anotação.

Stateless Session Beans –
implementação
 Um stateless session bean deve possuir a anotação
@Stateless, ou então deve ser definido como Stateless
através do uso do deployment descriptor, como na
versão EJB 2.x.
 Como dito anteriormente, a classe do bean não precisa
mais implementar a interface javax.ejb.SessionBean.
 No slide seguinte temos um exemplo de definição de
um stateless session bean (POJO), bem como de uma
interface de negócio (POJI). Observe as anotações
@Stateless, @Local e @Remote.

implementação
...
@Stateless
public class ServidorFacade implements ServidorFacadeLocal {
@PersistenceContext
private EntityManager em;

public ServidorFacade() {
}
public void create(Servidor servidor) {
em.persist(servidor);
}
public void edit(Servidor servidor) {
em.merge(servidor);
}
...

implementação
...
@Local
public interface ServidorFacadeLocal {

void create(Servidor servidor);
void edit(Servidor servidor);
void destroy(Servidor servidor);
Servidor find(Object pk);
List findAll();
List findAllIds();

}
...

Stateless Session Beans – exercício
 1) Completar o código da classe StatelessSessionBean disponível na pasta /src da estrutura de
projeto, incluindo as anotações necessárias para definição de um SLSB.
 Incluir as anotações @Stateless, @Remote, @Local;
 Compilar o código de forma que não apresente erros, empacotar as classes e efetuar o deploy na pasta
JBOSS_HOME/server/default/deploy do servidor JBoss.
 2) Usar o NetBeans para criar SLSB com nome StatelessSessionBean. Seguir os passos abaixo,
detalhados nos slides que seguem:
 Selecione o pacote do projeto EJB com botão direito,, selecionar New > Session Bean;
 Definir o pacote como com.synos.treinamento.sjeeejb3;
 Definir o nome do bean como StatelessSessionBean;
 Selecionar os checkboxes para interfaces Remote e Local;
 Clicar em Finish. Será exibido o código para o SLSB, observe a anotação @Stateless.
 Adicionar um método de negócio, clicar no código com botão direito > EJB Methods > Add Business
method;
 Compilar e empacotar o código usando o NetBeans;
 Realizar o deploy do EJB. Todos os passos estão detalhados nos slides seguintes.

Stateless Session Beans – exercício

Capítulo 5
Stateful Session Beans (SFSB)

 Um stateful session bean tem a capacidade de manter estado
entre duas chamadas de métodos, ou seja, se um cliente de um
stateful session bean estiver usando uma mesma referência (stub)
entre duas chamadas de método, há a garantia de que as
chamadas serão atendidas por uma mesma instância de um SFSB.
Existe um relacionamento um para um entre um SFSB e o cliente
do mesmo.
 A interface de negócio de um stateful session bean que usa a
versão 3.0 da especificação de EJB também é uma POJI (Plain Old
Java Object). A interface também pode ser definida como local ou
remota - @Local ou @Remote - da mesma forma que é feito para
os stateless session bean e também será definida por default como
local caso não haja nenhuma anotação.

 Da mesma forma que os stateless session bean, não é mais necessário ter
uma Home interface como era o caso de versões de EJB anteriores ao EJB
3.0.
 SFSB podem implementar a interface SessionSynchonization, o que
permite o stateful ter informações sobre o estado da transação no qual ele
está participando, como por exemplo ser informado sobre uma transação
que falhou, através de chamadas aos metódos da interface. No caso, só é
possivel implementar essa interface caso a aplicação esteja usando
Container Managed Transactions (CMT). Esse assunto será discutido
posteriormente durante o curso. Abaixo temos os três métodos dessa
interface:
 void afterBegin() throws EJBException, RemoteException
 void beforeCompletion() throws EJBException,RemoteException
 void afterCompletion(boolean committed) throws EJBException,
RmoteException

Stateful Session Beans -
implementação
 A implementação de um SFSB também é bem simples. Basta
anotar a classe do bean com a anotação @Stateful e para ter a
manutenção de estado entre chamadas, criar varíaveis de
instância para armazenar o mesmo.
 É importante ressaltar que a classe do bean precisa implementar a
interface java.io.Serializable (bem como todas as variáveis de
instãncia), de forma que o bean possa ser passivado (serializado)
quando as instâncias não estiverem sendo utilizadas, permitindo
ao container gerenciar seus recursos de forma mais adequada,
bem como ser ativado (deserializado).
 O desenvolvedor pode definir métodos arbitrários e marcá-los com
as anotações @PrePassivate e @PostActivate, sendo que os
mesmos serão chamados antes da passivação e após a ativação de
um SFSB.

Stateful Session Beans -
implementação
...
@Stateful
String cluster;
}
public void setCluster(String cluster) {
this.cluster = cluster;
}
public String getCluster() {
return this.cluster;
}
...

Stateful e Stateless Session Beans
– métodos callback
 Existem métodos que permitem um session bean incorporar pontos de extensão aos
eventos do ciclo de vida (criação, destruição, passivação, ativação) normal do
mesmo, de forma que possa ser executado código específico na ocorrência desses
eventos. Os métodos bem como a descrição dos mesmos estão listados abaixo:
 @PostConstruct: o método com essa anotação será chamado pelo container
logo após a instanciação do bean. Essa anotação é válida para stateless e
stateful session beans;
 @PreDestroy: o método com essa anotação será chamado pelo container antes
do container destruir uma instância do bean presente no pool de instâncias.
Essa anotação é válida para stateless e stateful session beans;
 @PrePassivate: o método com essa anotação é chamado antes do container
passivar uma instância de um stateful session bean. Essa anotação é válida
apenas para statefull session beans;
 @PostActivate: o método com essa anotação é chamado assim que um bean
que estava passivado se tornar ativo novamente. Essa anotação é válida apenas
para statefull session beans.

Stateful Session Beans – exercício
 1) Completar o código da classe StatefulSessionBean disponível na pasta /src da estrutura de
projeto, incluindo as anotações necessárias para definição de um SFSB.
 Incluir as anotações @Stateless, @Remote, @Local;
 Compilar o código de forma que não apresente erros, empacotar as classes e efetuar o deploy na pasta
JBOSS_HOME/server/default/deploy do servidor JBoss.
 2) Usar o NetBeans para criar SFSB com nome StatefulSessionBean. Seguir os passos abaixo,
detalhados nos slides que seguem:
 Selecione o pacote do projeto EJB com botão direito,, selecionar New > Session Bean;
 Definir o nome do bean como StatefulSessionBean;
 Selecionar os checkboxes para interfaces Remote e Local;
 Clicar em Finish. Será exibido o código para o SFSB, observe a anotação @Stateful;
 Adicionar um atributo e um método de negócio que usa o atributo, clicar no código com botão direito > EJB
Methods > Add Business method;

Stateful Session Beans – exercício

Capítulo 6
Session Beans e Web Services

 O suporte a Web Services foi introduzido na especificação EJB a partir da versão 2.1
e com a especificação EJB 3.0 o suporte ficou ainda mais simples e direto
 Para expor os serviços de um componente stateless session bean como um
WebService basta incluir a anotação @WebService bem como expor os serviços
(métodos) desse Web Service utilizando a anotação @WebMethod, sendo essa
última anotação opcional e caso a mesma não seja especificada todos os métodos
públicos da classe do Web Service serão expostos como serviços
 O arquivo WSDL com a descrição do WebService será gerado automaticamente pelo
container. Uma discussão mais abrangente sobre o conceito de Web Services e SOA
está além do escopo desse curso, por se tratar de um assunto bem extenso.
 O empacotamento do serviço utiliza um arquivo ejb-jar normal, comum para
qualquer componente EJB e se não forem usadas as anotações indicadas, ainda sim
é possível utilizar um arquivo webservice.xml detalhando o mapeamento do Web
Service e dos serviços (métodos que ele oferece, bastando incluir o arquivo
webservice.xml a pasta META-INF do pacote ejb-jar.
 O próximo slide apresenta um exemplo de classe com as anotações necessárias
para expor um componente EJB stateless session bean como Web Service.

...
@Stateless
@WebService(serviceName=”MyServer”, portName=”MyServerPort”)
@PersistenceContext
private EntityManager em;

}
public void create(Servidor servidor) {
em.persist(servidor);
}
@WebMethod
public void edit(Servidor servidor) {
em.merge(servidor);
}

Session Beans e Web Services -
exercício session bean StatelessSessionBean como WebService utilizando as
1) Expor o stateless
anotações @WebService e @WebMethod. Completar as anotações nó código da pasta
/src e conferir o resultado com o código da solução.
 2) Usar o NetBeans para expor o stateless session bean StatelessSessionBean como
WebService.

Capítulo 7
JPA – Java Persistence API

 Esse capítulo introduz a JPA – Java Persistence API e suas principais caractéristicas e
anotações, no contexto do curso de EJB 3.0, que trata também outras APIs da
especificação. Para um estudo detalhado da JPA, aconselhamos o curso Java
Persistence Architecture (SJPA) 20 h, também ministrado pela Synos.
 A Java Persistence API (JPA) fornece um padrão para utilização de POJOs (Plain Old
Java Objects) como entidades que representam dados de em uma tabela de banco
de dados, através de um mecanismo de mapeamento objeto-relacional. A JPA
aproveitou muitos conceitos e padrões que já eram adotados por outros
mecanismos de persistência level como Hibernate e Toplink, por exemplo.
Entretanto, um dos grandes benefícios da JPA é que ela é um padrão definido pelo
JCP, dentro do escopo da especificação de EJB 3.0 (JSR-220). Outros benefícios são
listados abaixo:
 Simplificação significativa das APIS para mapeamento O/R e persistência
 As entities pode ser executadas (e consequentemente testadas) fora do
container EJB
 Suporte a conceitos OO tais como como herança e polimorfismo
 Introdução da JP-QL, que melhora bastante o suporte a execução de queries

 Entities
 Entidade é uma classe que representa uma tabela em um
mecanismo de persistência de dados, podendo ser
persistida e posteriormente recuperada (não-volátil)
 As entidades são classes POJO simples com anotações e
não requerem mais a implementação de interfaces
específicas
 Toda entidade deve ter um construtor padrão (no-
arguments constructor)
 Toda entidade possui uma chave primária (identity), pode
ser persistida e recuperada (persistability) e pode
participar em uma transação (transactionability)

 Entities
 Abaixo temos um exemplo de entidade utilizando as
anotações @Entity, @Column e @Id:
@Entity(name = "MOBILE_ENTITY")
class MobilePhoneEntity{
public MobilePhoneEntity() {} //no-arg constructor
@Column(name = “MOBILE_MODEL”, nullable = true, length = 35)
private String model;
@Column(name = “MOBILE_MANUFACTURER” nullable = true, length = 100)
private String manufacturer;
private Double price;
@Id
@Column(name = “MOBILE_IMEI_NO”, nullable = false)
private String imeiNumber;

 Entities
A Chave primária (@Id) pode ser simples ou composta
 Para suportar chaves-compostas deve ser definida uma
classe para representar a chave-composta
A chave primária pode ser atribuída pelo
desenvolvedor ou gerada automaticamente usando a
anotação @GeneratedValue

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private String imeiNo;

 Entities – Ciclo de Vida

 Entities – Ciclo de Vida
 New
 Quando a instância da entidade foi criada usando a palavra-chave new
 Não possui Id
 Managed
 Quando a instância da entidade tem um Id associado a um contexto de
persistência
 Removed
 Quando a instância da entidade tem um id persistente associado a um
contexto de persistência
 A instância está marcada indicando que o registro deve ser excluído do
banco de dados
 Detached
 Quando a instância da entidade tem tem um id persistente, mas não está
associada a um contexto de persistência

 Entities – Herança
 Abaixo estão especificadas as três estratégias de herança que podem
ser utilizadas:
 Single Table Strategy
 Todas as classes na hierarquia são mapeadas para uma tabela única,
utilizando um campo descriminador para identificar uma classe
específica
 Table Per Class Strategy
 Cada classe na hierarquia é mapeada para uma tabela e todas as
propriedades das classes são mapeadas para colunas da tabela
correspondente
 Joined Subclass Strategy
 A tabela raiz da hierarquia é representada por uma tabela e cada
subclasse é representada por uma tabela separada que contém campos
específicos para a subclasse e também campos que representam as
chaves primárias

 Detached Entities
 Entidades desacopladas não estão associadas a um
contexto de persistência
 Uma entidade deve obrigatoriamente implementar a
interface Serializable se ela for trafegar na rede
(chamadas remotas)
 Asentidades desacopladas tornaram os design patterns
DTO/TO/VO obsoletos
 Deveser usado o método merge() para tonar a entidade
managed novamente

 Entities – EntityManager
 O EntityManager é a interface que o desenvolvedor possui para
controlar o ciclo de vida da entidade, através dos métodos abaixo:
 new()
 Cria uma nova entidade
 persist()
 Persiste uma entidade
 refresh()
 Atualiza o estado da entidade
 remove()
 Marca uma entidade para remoção
 merge()
 Sincroniza o estado de entidades desacopladas

 EntityManager - criação
 Em uma aplicação Java EE, o EntityManager pode ser
injetado pelo container.
@Resource
private EntityManager entityManager;
 Em uma aplicação Java SE, o Entity manager pode ser
obtido através da interface EntityManagerFactory e da
classe Persistence
 EntityManagerFactory entityManagerFactory =
Persistence.createEntityManagerFactory(“PersistentUnitNam
e”);
 EntityManagereManager =
entityManagerFactory.createEntityManager();

 EntityManager e Query
O EntityManager também é uma factory para objetos que
implementam a interface Query, que permite realizar
pesquisas customizadas
 createQuery()
 retorna uma instância de query usando JP-QL
 createNamedQuery()
 retorna uma instância de query identificada
 createNativeQuery()
 retorna uma instância de query usando SQL nativo

 Queries
 Melhorias implementadas na JP-QL
 Suporte a Group By e Having
 Sub-queries

 Suporte a novas funções SQL
 UPPER, LOWER, TRIM, CURRENT_DATE e outras
 Funções SQL adicionais
 Joins

 Consultas polimórficas
 Suporte consultas dinâmicas (Dynamic Queries) e
consultas nomeadas (Named Queries)

 Queries - exemplos
 Dynamic Queries
public List findWithName (String name) {
return em.CreateQuery (
“SELECT c FROM Customer c” +
“WHERE c.name LIKE :custName”)
.setParameter(“custName”, name)
.setMaxResults(10)
.getResultList();
}

 Named Queries
@NamedQuery(
name=“findCustomersByName”,
queryString=“SELECT c FROM Customer c” +
“WHERE c.name LIKE :custName”
)
@PersistenceContext public EntityManager em;
List customers = em.createNamedQuery(“findCustomersByName”).setParameter(“cust
Name”, “smith”).getResultList();

 Mapeamento O/R
A JPA possui várias anotações que permitem efetuar o
mapeamento objeto-relacional de forma bem flexível
 Relacionamentos entre entidades (tabelas)
 Junções (Joins)
 Tabelas e colunas
 Estruturasde banco de dados (sequences, colunas
auto-increment)

 Mapeamento O/R - relacionamentos
 Os relacionamentos entre as entidades podem ser
definidos utilizando as anotações abaixo
@OneToOne

@OneToMany

@ManyToOne

@ManyToMany

 Mapeamento O/R – operações em cascata
 Permitir propagar o alcance de uma operação para
afetar entidades relacionadas
 As operações em cascada ocorrem somente quando
as
 entidades estão associadas ao PersistenceContext
Cascade=PERSIST

Cascade=REMOVE

Cascade=MERGE

Cascade=REFRESH

Cascade=ALL

 Persistence Context
 Um Persistence Context trabalha em conjunto com o
EntityManger para gerenciar um conjunto definido de entidades
 Ele cuida das mudanças que uma entidade pode sofrer,
suportando o Entity Manager nas tarefas de commit e rollback
de alterações
 Quanto um EntityManager é criado, ele está implicitamente
associado a um Persistence Context
 Existem dois tipos de Persistence Context
 Persistence Context com escopo de transação – o tempo de vida
desse PC depende do tempo de vida de uma transação (para um
grupo de entities em um ponto específico no tempo)
 Persistence Context extendido – o PC vai existir mesmo após a
execução de uma transação e as entities permanecem associadas

 Persistence Unit
 Uma persistence unit fornece um agrupamento lógico para um grupo de
entidades que devem compartilhar uma mesma configuração
 Um arquivo persistence.xml file é utilizado para gerenciar uma ou mais
persistence units.
 Cada persistence unit é configurada com um provedor junto com um data-
source JDBC e um grupo de entities associado. Exemplo:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="mobile-broker-ejbPU" transaction-type="JTA">
<jta-data-source>java:/MobileBrokerDS</jta-data-source>
<properties/>
</persistence-unit>
</persistence>

JPA – Java Persistence API – exercício
 1) Completar o código da classe MyEntity disponível na pasta /src da estrutura de projeto,
incluindo as anotações necessárias para definição de uma Entity.
 Incluir a anotação @Entity;
 Conferir o resultado na pasta /solucoes;
 2) Usar o NetBeans para criar uma Entity com nome MyEntity.
 Selecione o pacote do projeto EJB com botão direito,, selecionar New > Entity Class;
 Definir o nome do bean como MyEntity e clicar no botão Create Persistence Unit;
 Selecionar o datasource JavaEEcomEJB3.0, disponibilizado previamente na pasta
JBOSS_HOME/server/default/deploy – arquivo java-ee-com-ejb-3-ds.xml.
 Selecionar também o radio button Drop and Create, que vai criar e dropar as tabelas no banco de dados
MySQL, conforme a entidade vá sofrendo alterações (cria todo o DDL para as operaões no banco). Clicar
em Create;
 Clicar em Finish. Observe as anotações @Entity, @Id e @GeneratedValue;

JPA – Java Persistence API – exercício

Capítulo 9
Introdução a JMS e Message-
Driven Beans (MDBs)

Driven Beans
 JMS – Java Message Service
 JMS é um padrão de mensageria desenvolvido com o intuito de
endereçar algumas desvantagens apresentadas por outros
padrões de mensageria. O JMS tem basicamente duas partes,
uma API que o desenvolvedor utiliza para enviar e receber
mensagens e uma SPI – Service Provider Interface – utilizada
para permitir a integração de diferentes tipos de
implementações (providers) JMS.
 Uma implementação específica possui os detalhes que são
necessários para realizar a integração a um MOM (Message-
Oriented Middleware) específico, sendo que um provider JMS
trabalha com um conceito parecido com o dos drivers JDBC
(interfaces genéricas com implementações específicas).

Driven Beans
 JMS – Java Message Service
 Existem dois tipos de modelos de mensageria, Publish-
Subscribe (Topics) e Point-to-Point (Queues):
 Publish-Subscribe – Com esse modelo, você pode ter muitos
produtores para uma mensage em tembém muitos consumidores
da mensagem, caracterizando uma implementação de um modelo
distribuído para propogação de eventos. Os subscribers registram
seu interesse em receber um determinado evento e os publishers
criam os eventos que serão propagados, sendo que ambos utilizam
um Topic.
 Point-to-Point – Com esse modelo, você poderá ter apenas um
consumidor para cada mensagem enviada. Vários consumidores
podem pegar mensagens de uma mesma Queue, mas a mensagem
será consumida apenas uma vez, por apenas um dos
consumidores.

Driven Beans
 MDB – Message-Driven Bean
 Message-driven beans não possuem uma interface de negócios
(business interface), ou seja, não é possível invocar diretamente
um MDB. Entretanto, o MDB deve implementar uma interface
chamada javax.jms.MessageListener, que por sua vez possui
um método onMessage(Record inputData).
 No EJB 3.0, a classe do MDB deve usar a anotação
@MessageDriven, que especifica a Queue ou Topic que um MDB
deve utilizar. Como dito anteriormente, a classe do bean
também deve implementar a interface MessageListener e
sobrescrever o método onMessage(). Quando uma mensagem
chega a Queue ou Topic no qual o MDB está vinculado, o
container invoca o método onMessage() do bean e passa a
mensagem enviada como um argumento para o método.

Driven Beans
 MDB – Message-Driven Bean
 Message-driven beans não possuem uma interface de negócios
(business interface), ou seja, não é possível invocar diretamente um
MDB. Entretanto, o MDB deve implementar uma interface chamada
javax.jms.MessageListener, que por sua vez possui um método
onMessage(Record inputData).
 No EJB 3.0, a classe do MDB deve usar a anotação @MessageDriven,
que especifica a Queue ou Topic que um MDB deve utilizar. Como dito
anteriormente, a classe do bean também deve implementar a interface
MessageListener e sobrescrever o método onMessage(). Quando uma
mensagem chega a Queue ou Topic no qual o MDB está vinculado, o
container invoca o método onMessage() do bean e passa a mensagem
enviada como um argumento para o método.
 No próximo slide temos um exemplo de MDB implementando conforme
o contrato da interface MessageListener e as anotações
correspondentes e posteriormente um exemplo de um cliente JMS,

Driven Beans
@MessageDriven(activateConfig = {@ActivationConfigProperty
(propertyName="destinationType", propertyValue="javax.jms.Queue"),
@ActivationConfigProperty(propertyName="destination", propertyValue="queue/mdb") })
public class EmailBean implements MessageListener {
public void onMessage (Message msg) {
try {
TextMessage tmsg = (TextMessage) msg;
Timestamp sent = new Timestamp(tmsg.getLongProperty("sent"));
... ...
} catch (Exception e) {
e.printStackTrace ();
}
}
// ... ...
}

Driven Beans
 Cliente JMS – envio de mensagens
 Para enviar uma mensagem para uma Queue (e
consequentemente para um MDB), o cliente JMS deve usar
as classes da API padrão JMS para obter uma referência
para a Queue alvo, através do nome da queue
(queue/mdb) e então enviar a mensagem.
 Os passos são idênticos quando utilizando um Topic ao
invês de uma Queue, mudando basicamente a interface
utilizada bem como as classes Factory.

Driven Beans
try {
InitialContext ctx = new InitialContext();
queue = (Queue) ctx.lookup("queue/mdb");
QueueConnectionFactory factory = (QueueConnectionFactory)
ctx.lookup("ConnectionFactory");
cnn = factory.createQueueConnection();
sess = cnn.createQueueSession(false,QueueSession.AUTO_ACKNOWLEDGE);
} catch (Exception e) {
e.printStackTrace ();
}
TextMessage msg = sess.createTextMessage("TESTE",1000);
sender = sess.createSender(queue);
sender.send(msg);

Driven Beans
 Message-Drive Beans - Callbacks
 Os MDBs podem trabalhar com os callbacks abaixo,
discutidos anteriormente
@PostConstruct: o método com essa anotação
será chamado pelo container logo após a
instanciação do bean.
@PreDestroy: o método com essa anotação será
chamado pelo container antes do container
destruir uma instância do bean presente no pool
de instâncias.

Message-Driven Beans – exercício
 1) Completar as anotações nó código do bean MessageDrivenBean na
pasta /src e conferir o resultado com o código da pasta solucoes;
 2) Usar o NetBeans para criar um message-driven bean que deverá estar
vinculado a queue/A, pré-configurada pelo servidor JBoss um MDB. Seguir
os passos abaixo, detalhados nos slides que seguem:
 Selecione o pacote do projeto EJB com botão direito, New > Message-
Driven Bean;
 Usar o pacote com.synos.treinamento.ejb3.biz.control;
 Definir o nome do bean como MessageDrivenBean;
 Compilar e empacotar o código usando o suporte do NetBeans ao
desenvolvimento de EJBs;
 Realizar o deploy do EJB e criar um cliente JMS simples que enviará
uma mensagem para a queue/A, que por sua vez será consumida pelo
MDB MessageDrivenBean.

Message-Driven Beans – exercício

 Transações – Introdução
 O suporte a transações é uma característica chave de um
servidor de aplicações Java. Ele garante a integridade do
sistema mesmo em caso de falhas na rede ou no hardware de
comunicação.
 Geralmente a lógica de uma aplicação requer que todas as
atualizações consecutivas em um banco de dados sejam bem
sucedidas, caso contrário não deve ocorrer nenhum update e
devemos iniciar novamente a operação. A API de EJB 3.0 tornou
muito fácil a declaração de atributos de transação em um POJO
através do uso de anotações. Na realidade, as transações tem
um papel importante na interação entre session beans e
message-driven beans.

 Gerenciamento de transações
 As transações de um EJB podem ser gerenciadas de três
formas:
 Container – o desenvolvedor especifica os atributos de
gerenciamento e atributos de transação e o container fica
responsável por implementar a lógica de gerenciamento de
acordo com a parametrização informada. O gerenciamento é
realizado no lado do servidor;
 Bean – o desnvolvedor fica responsável por fornecer toda a
lógica de gerenciamento da transação, incluindo os commits
e rollbacks explícitos. O gerenciamento é realizado no lado
do servidor;
 Cliente – o desenvolvedor fica responsável por fornecer a
lógica do gerenciamento no cliente, que utiliza a interface
UserTransaction para realizar as operações de commit e

 Gerenciamento de transações – configuração
 No EJB 3.0, existem anotações que permitem configurar
quem ficará responsável pelo gerenciamento da
transação:
O gerenciamento da transação é configurado com a
anotaçãoo @TransactionManagementType, sendo que
essa anotação deve ser especificada no nível da classe.
O atributo value pode assumir os valores abaixo:
 TransactionManagementType.CONTAINER: o
container gerencia as transações (default).
 TransactionManagementType.BEAN: o bean
gerencia as transações.

 Gerenciamento de transações
O exemplo abaixo mostra o uso da anotação
TransactionManagementType:
@Stateful
@TransactionManagement(value=TransactionManagementType.CONTAIN
ER)
public class CartBean implements Cart {
private ArrayList items;
...
}

 Anotações para controle de transações
 Em aplicações EJB 3.0, se o método requer uma
transação, todas as operações no método, incluindo
atualizações no banco de dados só são efetivadas se o
método retornar normalmente, sem falhas.
 Se uma exceção não tratada é lançada nesse método (ou
em métodos que o método invoca), o gerenciador de
transações desfaz todas as mudanças realizadas.
A anotação utilizada para delcarar os atributos da
transação é a @TransactionAttribute.

 A anotação @TransactionAttribute pode receber os seguintes
argumentos:
 REQUIRED: o método anotado é executado dentro de uma transação. Se o
método chamador já está dentro de uma transação, a transação é utilizada. Se
não, uma nova transação é iniciada.
 MANDATORY: O método anotado tem que ser invodcado no contexto de uma
transação (o metódo chamador deve ter uma transação, obrigatoriamente).
Caso contrário, um erro é lançado.
 REQUIRES_NEW: O método anotado é chamado dentro de uma nova transação.
Se o chamador já possuir uma transação, ela é suspendida.
 SUPPORTS: Se o método anotado é chamado a partir de uma transação, a
transação é utilizada. Se ele for chamado sem uma transação, nenhuma
transação será iniciada.
 NOT_SUPPORTED: Se o método anotado for chamado a partir de uma transação,
um erro será lançado.

 No EJB 3.0, o EntityManager tem que executar em um contexto
transacional para assegurar a integridade do banco de dados. O
transaction manager sempre sincroniza o banco de dados quando ele
realiza o commit, ou antes da próxima query. É possível chamar o método
EntityManager.flush() para forçar os updates na mémória para o banco de
dados, no meio de uma transação.
 Uma transação falha quando a aplicação lança uma RuntimeException ou
uma ApplicationException. Abaixo temos um exemplo de como definir uma
ApplicationException (exceção customizada pelo desenvolvedor):

@ApplicationException(rollback=true)
public class TransException extends Exception {
public TransException () { }
}

 Quando uma transação falha, o banco de dados é restaurado
para o estado antes da transação, mesmo se o contexto de
persistência tiver sido forçado antes da transação terminar e
todos os objetos entity bean gerenciados são detachados
 No exemplo abaixo, é gerada uma instância de classe que
representa uma ApplicationException dentro do método
updateExchangeRate(). Como o método foi declarado como
transacional, a exceção causa o cancelamento de todos as
operações executadas.

@Stateless
public class CalculatorBean implements Calculator {
@PersistenceContext
protected EntityManager em;
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void updateRate (double newrate) throws Exception {
...
// Emulate a failure
double prob = Math.pow (0.5, 1./size);
if (Math.random() > prob) {
// Emulated failure causes rollback
throw new TransException ();
// Or one can throw a RuntimeException to trigger the rollback operation
}
}
}

EJB 3.0 - Transações – exercício
 1) Declarar o método add do stateless session bean StatelessSessionBean
com a anotação @NotSupported. Completar as anotações nó código da
pasta /src e conferir o resultado com o código da solução.
 2) Usar o NetBeans para declarar o método add do stateless session bean
StatelessSessionBean com a anotação @NotSupported
 Realizar o deploy do EJB;
 Criar um client simples e chamar o método add, verificar a exceção
que será informada, o que indica que o atributo foi respeitado.

Capítulo 11
Segurança com JAAS

Segurança com JAAS
 Segurança na plataforma Java EE
 A plataforma Java EE define contratos bem definidos entre quem
desenvolve os componentes de uma aplicação e quem configura as
aplicações no ambiente de execução.
 O desenvolvedor deve declarar os requisitos de segurança para a
aplicação, que devem ser satisfeitos durante a sua configuração. Os
mecanismos de segurança declarativa usados numa aplicação são
definidos no documento de deployment descriptor de uma unidade de
disponibilização do Java EE (arquivos .WAR, .EAR, .JAR). Cada container
mapeia os requisitos da aplicação para os mecanismos que segurança
implementados pelo container, de forma que a infra-estrutura oferecida
pelo servidor de aplicação seja aproveitada.
 A arquitetura de segurança do Java EE possibilita a propagação de forma
transparente das credenciais de segurança de um determinado usuário
entre os componentes de uma aplicação Java EE. Em outras palavras, se o
usuário se logar em uma página web, não precisará se autenticar
novamente para acessar um componente EJB a partir daquela página, onde

Segurança com JAAS
 Segurança Java EE - Autenticação
A autenticação em servidores Java EE utiliza os seguintes
conceitos:
 Realm (domínio) – Uma coleção de usuários e grupos
que são controlados por uma mesma política de
autenticação;
 User (usuário) – A identidade de um indivíduo (ou
programa);
 Group (grupo) – Um conjunto de usuários autenticados;
 Role (papel) – Um nome abstrato para a permissão de
acesso a um conjunto particular de recursos numa
aplicação.

Segurança com JAAS
 JAAS - Java Authentication and Authorization Service
 Java Authentication and Authorization Service (JAAS) é um
conjunto de APIs que permitem a autenticação e autorização de
usuários e forçam o controle de acesso aos recursos de um
sistema.
 O JAAS implementa a versão Java do padrão Pluggable
Authentication Module (PAM). Esse padrão permite que as
aplicações se mantenham independentes da tecnologia de
autenticação usada, sendo que novos módulos podem ser .
Adicionados sem necessidade de modificações na aplicação.
 A implementação usada para a autenticação é determinada em
tempo de execução através das configurações em um arquivo
de login, como por exemplo o arquivo login-config.xml presente
na pasta JBOSS_HOME/server/default/conf do servidor JBoss.

Segurança com JAAS
 JAAS - Java Authentication and Authorization Service
 No JAAS, um Subject (javax.security.auth.Subject) é uma
entidade em um sistema, que será autenticada e para a qual
serão atribuídas permissões. Um subject pode ser qualquer
entidade, como uma pessoa ou um processo.
 Principals representam as identidades do Subject. Devem
implementar as interfaces java.security.Principal e
java.io.Serializable e são distinguidos pelo seu nome. Quando
um subject é autenticado, ele é povoado com um ou mais
principals. Por exemplo, um subject pode ter como identidade o
seu CPF.
 Groups são conjuntos de Principals. A interface
java.security.acl.Group é subinterface de java.security.Principal,
o que significa de que um grupo também é uma identidade do

Segurança com JAAS
 JAAS - Autenticação
 A autenticação no JAAS é feita através do contexto de
segurança (javax.security.auth.login.LoginContext), identificado
por um nome único. Para um contexto são definidos um ou mais
módulos de login (classes que implementam a interface
javax.security.auth.spi.LoginModule).
 Os módulos de login são os responsáveis pela implementação
da tecnologia de autenticação. O exemplo mais comum é a
autenticação baseada em usuário e senha, mas outros módulos
poderiam autenticar o usuário, por exemplo, baseado em
chaves de segurança, biometria e outros. O LoginModule pode
comparar essas informações com dados em um banco de
dados, servidor LDAP, arquivos texto, XML ou qualquer outro
repositório de usuários.

Segurança com JAAS
 O programador da aplicação não precisa se preocupar com o
funcionamento do LoginModule. Deve saber apenas como
especificar, através de um arquivo de configuração, qual o
módulo será usado para autenticar o usuário em um
determinado security domain.
 Para que o LoginModule se comunique com o usuário e obtenha
informações de autenticação, a aplicação usa um
javax.security.auth.callback.CallbackHandler. A aplicação
implementa um CallbackHandler e o passa para o LoginContext,
que o passará aos módulos. Esses LoginModules usarão o
CallbackHandler para solicitar entrada de dados ao usuário e
enviar informações. Cada CallbackHandler pode implementar
sua própria interface com o usuário, podendo ser, por exemplo,
textual, gráfica, formulário web e outras.

Segurança com JAAS
 A interface CallbackHandler define apenas o método abaixo:
void handle(Callback[] callbacks) throws java.io.IOException,
UnsupportedCallbackException;
 O LoginModule passa para o método handle um vetor de
Callbacks (veja o pacote javax.security.auth.callback), como o
NameCallback (requisição de nome do usuário),
PasswordCallback (requisição de senha do usuário) e
TextOutputCallback (informação ao usuário) e o
CallbackHandler implementa a interação com o usuário
necessária para contemplar as ações requisitadas.

Segurança com JAAS
O diagrama de seqüência no slide seguinte mostra a
sequência de autenticação com o JAAS. O JAAS Client é a
aplicação que usará o JAAS, MyCallbackHandler é a
implementação de CallbackHandler específico para a
aplicação. LoginContext é uma classe do sistema (não
será implementado pela aplicação) e SomeLoginModule é
um LoginModule qualquer configurado para a aplicação
(pode ser implementado pela própria aplicação ou por
terceiros).
 Após o sucesso da autenticação, a aplicação obtém um
objeto javax.security.auth.Subject chamando o método
getSubject() de LoginContext. Esse objeto conterá os

Segurança com JAAS

Segurança com JAAS
 Segurança Java EE - Autorização
 A autorização de acesso a recursos no J2EE é feita através de
roles. Para um recurso ou conjunto de recursos é definido a role
necessária ao usuário para que este tenha acesso liberado.
Caso o usuário não esteja autenticado, um novo login poderá
ser exigido. Podem ser usados dois tipos de segurança:
 Segurança Declarativa: as roles são definidas no deployment
descriptor (DD) e autorizam acesso aos recursos Java EE. A
ligação das roles aos usuários é feita pelos containers Java
EE.
 Segurança Programática: quando a segurança declarativa não é
suficiente, pode-se usar componentes de segurança da linguagem
para implementar os requisitos necessários.

Segurança com JAAS
 Controle de acesso a EJBs
O controle de acesso aos EJBs é definido especificando-se no
arquivo /META-INF/ejb-jar.xml as roles existentes e quais são
os roles necessários para permitir ao usuário o acesso aos
métodos do bean, ou então através das anotações
introduzidas no EJB 3.0.
 Abaixo temos um exemplos de configuração de permissão
usando o DD e também uma explicação sobre as anotações
para configuração de permissões.

Segurança com JAAS
 Controle de acesso a EJBs - ejb-jar.xml
<ejb-jar>
<assembly-descriptor>
<security-role>
<role-name>AuthorizedEJBUser</role-name>
</security-role>
<method-permission>
<role-name>AuthorizedEJBUser</role-name>
<method>
<ejb-name>Information</ejb-name>
<method-intf>Remote</method-intf>
<method-name>getInformacoes</method-name>
<method-params>
</method-params>
</method>

Segurança com JAAS
 Controle de acesso a EJBs – ejb-jar.xml (continuação)
<method>
<ejb-name>Information</ejb-name>
<method-intf>Home</method-intf>
<method-name>create</method-name>
<method-params>
</method-params>
</method>
</method-permission>
...
</assembly-descriptor >
...
</ejb-jar>

Segurança com JAAS
 Controle de acesso a EJBs – anotações
O EJB 3.0 fornece anotações para especificar as opções de
segurança, sendo que as anotações abaixo foram introduzidas na
versão 3.0 da especificação:

* @SecurityRoles
* @MethodPermissions
* @Unchecked
* @Exclude
* @RunAs

Segurança com JAAS
 O exemplo abaixo mostra um EJB simples, um SLSB chamado PingEjb e também
inclui uma checagem de autorização.
@Remote({Ping.class})
@Stateless
public class PingEjb implements Ping {
@PermitAll
public String pingPermitAll() {
return "PingEjb: pingPermitAll";
}
@DenyAll
public String pingPermitAll() {
return "PingEjb: pingDenyAll";
}
@RolesAllowed({"staff"})
public String ping() {
return "PingEjb: ping";
}
}

Segurança com JAAS
 Noexemplo, note as três anotações de segurança no bean PingEjb:
@PermitAll,
@DenyAll, and @RolesAllowed. No caso, o Java EE 5 introduziu cinco
anotações, restando também as anotações @DeclareRoles e
@RunAs.
 @PermitAll – todos os roles podem invocar métodos
 @DenyAll – nenhum role pode acessar os métodos
 @RolesAllowed – no exemplo, somente usuários com role “staff”
podem acessar o método
 Vejamos outro exemplo de como proteger os métodos de um EJB
3.0:

Segurança com JAAS
@RunAs(value="staff")
@DeclareRoles({"staff", "temporary"})
@RolesAllowed({"ttrole"})
@Stateless
public class HelloEjb implements Hello {
@Resource private SessionContext sc;
@EJB private Ping ping;

}

Segurança com JAAS
public String hello() {
if (!sc.isCallerInRole("staff") &&
!sc.isCallerInRole("temporary")) {
return "HelloEjb: hello";
} else {
throw new RuntimeException(
"of role staff or temporary");
}
@RolesAllowed({"myrole"})
public String ping() {
return ping.ping();
}
}

Segurança com JAAS
 Existem duas anotações @RolesAllowed no exemplo HelloEjb, um
no nível da classe, outro no nivel do método.
 A anotação @RolesAllowed no nível da classe se aplica a todos os métodos de
negócio do bean. Entretanto, ela pode ser sobreposta por uma anotação
específica para um método, no nível do método, se ela existir. Observe que o
método ping está sujeito a uma anotação no nível de método
@RolesAllowed({"myrole"}).
 A anotação @RunAs especifica um role para invocações subsequentes dentro de
um método, mas não para invocações diretas do método em questão. No
exemplo, HelloEjb.ping() invoca o método Ping.ping() como um usuário de role
"staff" ao invés de usar o role do usuário logado.
 A anotação @DeclareRoles é utilizada para definir roles utilizadas pelo
componente. No HelloEjb, os roles "staff" e "temporary" podem ser usados pela
chamada isCallerInRole() dentro do método hello.

 1) Declarar o método add do stateless session bean StatelessSessionBean
com a anotação @DenyAll. Completar as anotações nó código da pasta
/src e conferir o resultado com o código da solução.
 2) Usar o NetBeans para declarar o método add do stateless session bean
StatelessSessionBean com a anotação @DenyAll
 Realizar o deploy do EJB;
 Criar um client simples e chamar o método add, verificar o que será
informado, o indicando que o atributo foi respeitado, ou seja, nenhuma
role pode acessar o método.

Segurança com JAAS – exercício

Capítulo 12

 EJB Timers
 O serviço EJB Timer é fornecido pelo container EJB com o intuito de
possibilitar a implementação de execuções baseadas em um intervalo de
tempo e agendamento para execução de tarefas.
 A especificação de EJB suporta duas formas de objetos Timer:
 Timer de ação simples – um timer de ação simples é um timer que
expira apenas uma vez (ao contrário de um timer de intervalo, onde
múltiplas expirações são possívels).
 Timer de intervalo – um timer de intervalo (ou timer multi-ação) vai
recorrer no tempo considerando múltiplos de um determinado
intervalo, de forma que esse tipo de timer terá portanto múltiplas
expirações em intervalos de tempo regulares.

 EJB Timers
 A API EJB Timer fornece quatro interfaces para a implementação de
serviços temporizados.
 javax.ejb.TimerService - essa interface suporta os componentes EJB na criação de
timers (ação simples ou intervalo) bem como a recuperação de timers existentes
(criados por outros EJBs).
 javax.ejb.Time - essa interface permite recuperar informações sobre os objetos Timer
que foram criados anteriormente pelos EJBs.
 javax.ejb.TimedObject - componentes EJB pode implementar essa interface para
receber notificações baseadas em intervalos de tempo (callbacks) em objetos Timer.
O método ejbTimeout() será invocado pelo container quando o tempo expirar.
 javax.ejb.TimerHandle – essa interface é implementada pelo container de forma que
um EJB possa utilizar esse handle para reconstruir um objet timer um um outro
momento (semelhante a um javax.ejb.Handle), sendo que obviamente a interface
TimerHandle extende a interface Serializable possibilitando ao TimerHandle ser
serializado. Devido a esse fato, objetos TimerHandle são objetos locais não sendo
permitido passar objetos TimerHandle como argumentos para chamadas de método
remotas.

 EJB Timers
 É possível configurar um timer EJB 3.0 usando um stateless session bean
ou message-driven bean. O serviço do Timer (Timer Service) pode ser
acessado usando anotações ou fazendo um lookup no contexto JNDI.
 Abaixo temos um exemplo de implementação de um TimedObject
utilizando a anotação @Resource em um método para injetar a referência
a um Timer:
@Stateless public class AmbienteFacade implements AmbienteFacadeLocal
{
...
@Resource Timer EmpDurationTimer;
...
}

 EJB Interceptors
 Serviços em tempo de execução como controle de transações e segurança são
executados em um bean quando um método é invocado. Esses serviços
geralmente são implementados como métodos interceptores gerenciados pelo
container. Entretanto, a versão 3.0 de EJB também permite aos desenvolvedores
implementar interceptores definidos pelo mesmo, que podem ser executados
antes e depois da execução de um método. Essa possibilidade é muito útil pois
permite ao desenvolvedor ter mais controle sobre uma transação por exemplo,
verificações de segurança e outros.
 Os interceptores oferecem um controle fino sobre o fluxo de invocação de um
método, podendo ser usados por Session Beans (stateful e stateless) e Message-
Driven Beans.
 Interceptors podem ser definidos na própria bean class ou em uma classe
externa, sendo que os métodos interceptores sempre serão chamados antes da
execução dos metódos de negócio de um bean.
 Abaixo temos a assinatura típica de um método interceptor.

public Object <methodName>(javax.ejb.InvocationContext)

 Um método interceptor define um parâmetro do tipo InvocationContext, e essa
interface por sua vez define os métodos abaixo:

public interface InvocationContext{
public Object getBean();
public Method getMethod();
public Object[] getParameters();
public void setParameters(Object params[]);
public EJBContext getEJBContext();
public Object proceed() throws Exception;
}

A anotação @Interceptor determina um interceptor
definido em uma outra classe, sendo que se mais de um
interceptor for necessário, é possível usar a anotação
@Interceptors.
A anotação @AroundInvoke indica que um método atua
como interceptor, sendo que interceptor podem ser
aplicados a todos os métodos de negócio de um bean. O
código abaixo é um exemplo de um interceptor definido
na própria classe do bean e logo em seguida temos um
exemplo de um interceptor definido em uma classe
externa.

@StateLess

@Interceptor("MyCustomInterceptor")

public class BusinessBean{

@AroundInvoke

public Object customInterceptor(InvocationContext invContext)

throws Exception{
...
invContext.proceed();

}

}

public class MyCustomInterceptor{

@AroundInvoke

public Object customInterceptor(InvocationContext invContext)

throws Exception{

...

invContext.proceed();

}

}

Java EE EJB 3.0

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (9)

Semelhante a Java EE EJB 3.0

Semelhante a Java EE EJB 3.0 (20)

Mais de Juarez Junior

Mais de Juarez Junior (20)

Java EE EJB 3.0