Enterprise

JavaBeans 3.0
Parte 1: Introdução

< Por: Rafael

Rafael Zancan Frantz >

ATENÇÃO: Este material contém algumas imagens retirardas da docomentação oficial da SUN e
adaptadas para este material. As mesmas podem ser encontradas no site www.sun.com. O objetivo
deste material é recompilar uma série de informações existentes em diversas fontes e que possam
ser utilizadas para o estudo da tecnologia EJB 3.0 pelo leitor. Ao final do material são apresentadas
as bibliografias utilizadas para a elaboração do material. Sugere-se que as mesmas sejam utilizadas
para aprofundar os conhecimentos nesta tecnologia.

1
O que é um Enterprise JavaBean
JavaBean

Os Enterprise JavaBeans foram criados em Março de 1998, na primeira

especificação da Sun com o intuito de promover uma arquitetura de objetos distribuídos pela
Internet.

A definição da Sun Microsystems para Enterprise JavaBeans é:

“The Enterprise JavaBeans architecture is a Component architecture for the

development and deployment of component-based distributed business applications.
Applications written using the Enterprise JavaBeans architecture are scalable,
transactional, and multi-user secure. These applications may be written once, and then
deployed on any server plataform that supports the Enterprise JavaBeans
specifications”.

Fazendo parte de uma infra-estrutura de middleware em um modelo Web, os EJBs

simplificam consideravelmente a criação da infra-estrutura, mas acrescenta outras
dependências em uma implementação específica de um Application Server.

A tecnologia Enterprise JavaBeans (EJB) de components, ou simplesmente "enterprise

beans", provê um ambiente para o gerenciamento de componentes. Eles podem simplificar o
processo de desenvolver aplicações escaláveis, portáveis e reutilizáveis no seu ambiente de
negócios. O uso de enterprise beans requer um investimento de tempo, codificação e
treinamento. Em oposição a alguns que cultuavam, principalmente no começo da
tecnologia, que no desenvolvimento de EJBs o programador precisava somente desenvolver a
lógica de negócios os EJBs requerem muita experiência na administração e configuração dos
serviços gerenciados pelo container e como são um pool de tecnologias é importante para o
o coordenador do projeto ter “know how” de várias conceitos como de objetos distribuídos,
RMI (Java Remote Method Invocation), conceitos de transações, conhecimento de
mapeamento de dados Java com os de Bancos de dados pelo JDBC e outros.

Para alguns, esta tecnologia parece complicada, mas eles podem simplificar o
desenvolvimento de aplicações de negócio por resolver alguns requerimentos de serviços nos
quais em um sistema robusto faz diferença.

Até a versão 2.1 o desenvolvedor precisava configurar muitas coisas em arquivos XML,
porém a partir da versão 3.0 muitas das configurações que eram feitas em XML agora
podem ser feitas através de anotações. O uso de anotações simplificou muito a escrita de
componentes EJB.

2
 Vários requerimentos que um sistema robusto necessita estão listados abaixo junto com
o que os EJBs oferecem para suprir estas demandas. A maioria destes requerimentos são
aplicáveis na aplicação desde que tenham as seguintes necessidades.

· Gerenciamento da Persistência.
Persistência Muitas aplicações empresariais manipulam os dados
persistentes. Um bean de entidade (um EJB que representa o dado persistente em um
meio de armazenamento como um banco de dados relacional) é projetado para
prover gerenciamento automático de dados persistentes, inclusive dados legados. Isto
é feito a partir da versão 3.0 de EJB utilizando a API de persitência, Java Persitence
API.

· Acesso concorrente a dados.

dados Aplicações empresarias multi-usuárias devem prover
acesso concorrente a dados sem sacrificar a consistência. Enterprise beans são
projetados para gerenciar acessos concorrentes e possuem automaticamente resursos
multi-thread.

· Acesso remoto a dados.

dados Aplicações empresariais tipicamente acessam dados a partir
de recursos remotos múltiplos. A tecnologia de EJB fornece interfaces remotas de
negócio para esta transparência de localização, aumentando assim a disponibilidade
da aplicação.

· Modelo desenvolvido baseado em componentes.

componentes Componentes de software podem
prover reusabilidade, portabilidade e uma clara separação da interface com a
implementação. Enterprise beans provê estes benefícios porque são verdadeiros
componentes de software.

· Portabilidade
Portabilidade.
dade Uma aplicação que é portável através de múltiplas plataformas de
hardware e sistemas operacionais faz melhor uso de dos recursos da sua empresa,
principalmente em se tratando de sistemas heterogêneos e provê uma futura
flexibilidade de integração. A portabilidade diminui os riscos de uma aplicação tornar-
se obsoleta quando sistemas operacionais são atualizados ou hardware são
substituídos. A especificação das tecnologias J2EE, assegura que os serviços para
sistemas empresariais estejam disponíveis através de vários fornecedores e
plataformas.

· Controle Transacional e de Segurança.

Segurança Dados empresariais devem ser atualizados
consistentemente e somente por aqueles que estiverem autorizados. Enterprise beans
provê um controle declarativo das configurações de segurança e de transações,
simplificando a customização e aumentando a flexibilidade. Enterprise beans podem
também controlar as transações e a segurança programaticamente.

· Alta dispobilidade.
dispobilidade Sistemas de missão crítica necessitam estar disponíveis todo
tempo. Implementações de Enterprise Beans podem prover controle a falhas
automaticamente quando um servidor sai do ar por crash ou para manutenções,
quando a rede está indisponível ou não confiável. Enterprise beans também gerencia
uma religação de dados quando acontece uma falha de sistema.

· Escalabilidade.
Escalabilidade Aplicações normalmente crescem, aumentando o número de
usuários e novos requisitos. Por terem um ciclo de vida gerenciado pelo container as
instâncias dos beans que servem as requisições podem ser colocadas em um pool
3
 para maximizar a eficiência de recursos. Componentes podem ser migrados para
balancear carga sem um cluster de processadores.

· Neutralidade do tipo de cliente.

cliente. Algumas aplicações requerem acesso por muitos
tipos de cliente. Objetos de negócios como enterprise beans provêm accesso para um
modelo de aplicação para qualquer tipo de cliente. Clientes Java podem acessar os
enterprise beans através das interfaces padrões (Home e Remote). Clientes não Java
podem acessar enterprise beans usando CORBA (Common Object Request Broker
Architeture) ou interfaces Web services.

No passado as empresas construíram seu próprio Middleware com o intuito de se

fazer uma solução que fosse adequada às realidades da empresa mas esbarraram nos
seguintes inconvenientes:

- Custo de manter uma equipe de desenvolvimento.

- Um middleware de alto nível é estremamente complicado de construir e de manter

uma equipe de manutenção para o código.

- Pouca reusabilidade da solução, porque estes sistemas muitas vezes não eram
adequados para a realidade WEB e desta forma o percentual de reconstrução era
muito alto e principalmente quando era necessário a construção de pontes (bridges),
porque as diferentes tecnologias não conversavam satisfatoriamente o custo
aumentava ainda mais.

- Caso fosse necessário conectar com um outro DBMS que não fosse o que foi feito
no projeto original exigia uma reprogramação muito grande principalmente por que
poucos sistemas eram três camadas com um foco orientado a MVC (Model-View-
Controller).

O conceito de Enterprise Java Beans não é recente, vêm dos monitores transacionais,
os “TP monitors” que vieram de um ambiente Mainframe. Estas máquinas antigas, porém
eficientes no papel que se dispuseram a fazer, trabalham com os monitores transacionais
porém de uma forma monolítica e não uma forma distribuída. Partindo deste princípio
formamos uma definição de EJB além da já apresentada e cunhada pela SUN.

“Enterprise Java Beans é um padrão de modelo de componentes no lado

servidor para aplicações de negócio distribuídas.”

EJBs são os componentes J2EE que executam a tecnologia de Enterprise JavaBeans.

Os EJBs funcionam no container EJB, um ambiente de runtime dentro de algum servidor
J2EE. Embora transparente ao desenvolvedor de aplicação, o container de EJB fornece
serviços a nível de sistema (como transações, por exemplo) a seus EJBs. Estes serviços
permitem construir e disponibilizar rapidamente os EJBs, que dão forma ao núcleo de
aplicações transacionais J2EE.

Escrito na linguagem de programação de Java, um EJB é um componente server-side

que encapsula a lógica do negócio de uma aplicação. A lógica do negócio é o código que
cumpre a finalidade de uma aplicação. Em uma aplicação de controle de material didático,
por exemplo, os EJBs podem executar a lógica do negócio nos métodos chamados
4
checarQuantidadeMaterial() e entregarMaterial(). Invocando estes métodos, os
clientes remotos podem utilizar os serviços do controle de material fornecidos pela aplicação.

5
Tipos de Enterprise Bean

Existem três tipos de enterprise beans, os quais serão estudados aqui neste curso. Os
capítulos seguintes discutem estes tipos de beans mais detalhadamente.

1 – Session Bean
Beans
eans: Executa uma tarefa para um cliente
1.1 – Stateless:
Stateless: Sem informação de estado
1.2 – Stateful:
Stateful: Com informação de estado

2 – Message Driven BBean

eanss (MDB)
ean (MDB):: Atua como um listener para a API Java Message
Service (JMS), processando mensagens assincronamente.

3 – Entity Beans
Beans:
eans: Representa um objeto de entidade de negócios que existe no
armazenamento persistente

6
Uma arquitetura com Enterprise Java Beans

A arquitetura EJB define um modelo de sistema distribuído, baseado em

componentes. O modelo de programação define um conjunto de perfis, através de um
conjunto de contratos, que definem uma plataforma comum de desenvolvimento. O
principal objetivo destes contratos é assegurar a portabilidade através dos vendedores de
servidores de EJB ou de componentes, enquanto suportam um rico conjunto de
funcionalidades.

Container de EJB

O conceito de Container na arquitetura J2EE define um conjuto de componentes que

atendem uma especificação. Existem diversos tipos de container como Applet Container,
WEB Container, EJB Container. Para um componente rodar nestes ambientes, o mesmo tem
que atender as especificações descritas destes containers.

Baseado na definição de EJB poderíamos definir um container acrescentando que os

componentes rodam em um programa que define o funcionamento de runtime (tempo de
execução) da especificação. Se o tipo de container define o padrão de objetos distribuídos
então estaremos falando em EJB Container.

Um Enterprise Bean não pode rodar fora de um container, porque o mesmo gerencia
todo o aspecto de um enterprise bean em um ambiente de execução, por exemplo: o acesso
remoto ao bean, segurança, persistência, transações, concorrência, acesso aos recursos de
pool, etc.

O container isola o enterprise bean a partir do acesso direto das aplicações clientes
quando essas invocam uma chamada remota a um Enterprise Bean. Inicialmente, o
container, intercepta a invocação para assegurar: persistência, transação e segurança pelas
propriedades do Bean para toda a operação que o cliente executar. Como o container
gerencia todos esses fatores automaticamente para o bean, então o desenvolvedor não
precisa implementar este tipo de lógica no código do bean. O desenvolvedor pode focar nas
as regras de negócio enquanto o container cuida dos serviços solicitados pelo bean, os quais
são definidos em um arquivo chamado deployment descriptor. Veremos este arquivo mais
adiante.

7
 Figura 1-1: Arquitetura de um sistema com EJBs

O container gerenciará muitos beans simultaneamente do mesmo modo que o Web

Container gerencia muitos servlets. Para reduzir o consumo de memória e processamento, o
pool de recursos do container gerencia os ciclos de vida de todos os beans com muito
cuidado. Quando um bean não está sendo usado, o container colocará no pool o bean para
ser reutilizado por outro cliente, ou possivelmente o eliminará da memória quando o
container decidir que o bean não é necessário ficar no pool. Esta decisão pode ser de acordo
com o número de acessos ao bean. Devido ao fato de que aplicações clientes não têm
acesso direto aos beans, o container vive entre o cliente e o bean, portanto as aplicações
cliente desconhecem completamente as atividades do container.

Um bean que não está em uso, por exemplo, pode ser armazenado a partir da
memória em algum outro mecanismo que varia entre tipos de EJB (Session , Entity e
Message Driven Bean) no servidor, enquanto a referência remota fica intacta. Quando o
cliente invoca um método na interface remota o container simplesmente revitaliza o bean
para servir a requisição, deixando o processo totalmente transparente para a aplicação
cliente.

Um Enterprise Bean depende do container para qualquer serviço que necessite. Se um

Enterprise Bean necessita acessar uma conexão com outro Bean tudo é feito da mesma
forma que um cliente comum passando pelo container.

Para isto o Enterprise Bean interage com o container através de três mecanismos:

· Métodos de CallBack: Todo EJB implementa uma interface Enterprise Bean, sendo
os métodos da interface chamados de métodos de callback. Cada método callback

8
alerta o bean de um diferente evento no seu ciclo de vida e o container invocará estes
métodos para notificar o Bean quando os eventos acontecem (criação, remoção,
persistência, etc.). Os métodos de callback dão chance ao bean de fazer algum
processamento antes ou depois de algum evento gerado pelo container. Até a versão
2.1 os EJBs deveria seguir uma nomenclatura exata para métodos do seu ciclo de
vida, porém com anotações os nomes dos métodos não mais são importantes e
podem variar. A notação antes do nome do método é que irá dizer qual dos métodos
do ciclo de vida que o mesmo representa. Por exemplo
@javax.annotation.PostConstruct será utilizado para anotar um método como
sendo o método a ser executado após a costrução de um Session Bean.

· EJBContext Interface: Todo EJB obtém um objeto de contexto de EJB, o qual é uma
referência direta para o container. A interface EJBContext provê métodos para
interagir com o container tanto que o bean pode requisitar a informação sobre o seu
ambiente como a identificação do cliente ou o status de uma transação ou pode obter
referências remotas para ele mesmo.

· JNDI (Java Naming and Directory Interface):

Interface): JNDI é uma extensão da plataforma
Java para acesso a sistemas como LDAP (Lightweight Directory Access Protocol),
sistemas de arquivo, etc. Todo bean automaticamente tem acesso para um sistema
especial chamado Enterprise Naming Context (ENC). O ENC é gerenciado pelo
container e acessa os beans usando JNDI. O JNDI ENC permite um bean acessar
recursos como conexões JDBC, outros enterprise beans, e propriedades específicas
para aquele bean. Isto é feito internamente, porém como já dissemos a programação
é a mesma que a de um cliente comum.

9
O Conteúdo de um enterprise bean

Para desenvolver um enterprise bean, você deve fornecer os seguintes arquivos:

1) Descritor de implantação (deployment descriptor): Um arquivo XML que especifica

as informações sobre o bean, como seu tipo de persistência e atributos de
transação. Isto pode ser feito via anotações. Porém se o arquivo XML for fornecido
as configurações postas no mesmo irão sobrescrever as anotações

2) Classe do enterprise bean (enterprise bean class): Implanta os métodos definidos

nas interfaces local e/ou remota

3) Interfaces: A interface remota é necessária para o acesso remoto. Para acesso

local, a interface local é necessária. Estas interfaces serão estudadas mais adiante.

4) Classes auxiliares (helper classes): Outras classes necessárias para a classe do

enterprise bean, como classes de exceção e de utilitários.

Você empacota os arquivos da lista anterior em um arquivo JAR EJB, o módulo que
arqmazena o enterprise bean. Um arquivo JAR EJB é responsável e pode ser usado por
diferentes aplicações.

Para montar uma aplicação J2EE, você empacota um ou mais módulos – como
arquivos JAR EJB – em um arquivo EAR que contém o arquivo JAR EJB do bean e outros
arquivos, também implanta o enterprise bean no servidor J2EE.

10
Empacotamento da aplicação

Os componentes J2EE são empacotados separadamente e agrupados em uma

aplicação J2EE para implantação. Cada componente, seus arquivos relacionados com os
arquivos GIF e HTML ou classes de utilitários do lado servidor, e um descritor de implantação
são montador em um módulo e adicionados à aplicação J2EE. Uma aplicação J2EE é
composta por módulos de componentes do cliente da aplicação, enterprise bean ou web. A
solução empresarial final pode usar uma aplicação J2EE ou ser composta de duas ou mais
aplicações J2EE, dependendo das exigências do projeto.

Uma aplicação J2EE e cada um de seus módulos possuem seus próprios descritores
de implantação. Um descritor de implantação é um documento XML com uma extensão
.xml que descreve configurações de implantação de um componente. Um descritor de
implantação do módulo do enterprise bean, por exemplo, declara atributos de transação e
autorizações de segurança para um enterprise bean. Como as informações do descritor de
implantação são declarativas, elas podem ser alteradas sem modificar o código-fonte do
bean. No momento de execução, o servidor J2EE lê o descritor de implantação e age sobre o
componente adequadamente.

Uma aplicação J2EE com todos os seus módulos é entregue em um arquivo Enterprise
ARchive (EAR). Um arquivo EAR é um arquivo Java Archive (JAR) padrão com uma extensão
.ear. Dentro deste arquivo EAR normalmente você adiciona arquivos Web Archive (WAR) e
JAR.

- Cada arquivo JAR EJB contém um descritor de implantação, arquivos do enterprise

beans e arquivos relacionados

- Cada arquivo JAR do cliente da aplicação contém um descritor de implantação, os

arquivos de classes para o cliente da aplicação e arquivos relacionados.

- Cada arquivos WAR contém um descritor de implantação, arquivos do componente

Web e recursos relacionados.

A utilização de módulos e arquivos EAR possibilita a montagem de várias aplicações

J2EE diferentes usando alguns dos mesmos componentes. Nenhuma codificação adicional é
necesária; é apenas a questão de montar os vários módulos J2EE em arquivos EAR J2EE.

11
Benefícios da utilização de EJBs

Por diversas razões, os EJBs simplificam o desenvolvimento de aplicações grandes e

distribuídas. Em primeiro lugar porque o container EJB fornece serviços a nível de sistema
aos EJBs, o desenvolvedor EJB pode se concentrar em resolver problemas de negócio. O
container EJB -- não o desenvolvedor EJB -- é responsável por serviços a nível de sistema tais
como a gerência de transação e a autorização de segurança. Em segundo lugar, porque os
EJBs - e não os clientes - contêm a lógica do negócio da aplicação, o desenvolvedor do
cliente pode focar na apresentação do cliente(User Interface, ou UI). O desenvolvedor do
cliente não tem que codificar as rotinas que executam regras de negócio ou acesso a bases
de dados. Em conseqüência, os clientes são mais finos, um benefício que é particularmente
importante para os clientes que funcionam em dispositivos pequenos. Em terceiro lugar,
porque os EJBs são componentes reutilizáveis, o integrador da aplicação pode construir
aplicações novas com EJBs existentes. Estas aplicações podem funcionar em qualquer
servidor J2EE compatível. Existem muitos servidores J2EE disponíveis hoje no mercado.
Servidores estes gratuitos ou pagos. Iremos utilizar aqui um servidor J2EE gratuito chamado
JBoss.

Links interessantes:

JBoss: http://www.jboss.org

NetBeans: http://www.netbeans.org

Sun: http://java.sun.com/javaee

12
Quando usar EJBs

Você deve considerar o uso de EJBs se sua aplicação tiver alguns dos seguintes requisitos:

1. A aplicação deve ser escalável. Para acomodar o crescimento do número de

usuários, você talvez precise distribuir os componentes de uma aplicação em múltiplas
máquinas. Não somente podem os EJBs de uma aplicação funcionar em máquinas
diferentes, mas suas localizações permanecerão transparentes para os clientes.

2. As transações são necessárias para assegurar a integridade dos dados. Os EJBs

suportam transações, os mecanismos que controlam o acesso concorrente de objetos
compartilhados.

3. A aplicação terá inúmeros clientes. Com apenas algumas linhas do código, os

clientes remotos podem facilmente encontrar EJBs. Estes clientes podem ser magros
(thin client), váriados e em grande número.

13
Tipos de EJBs

Um componente EJB possui três tipos fundamentais: entity beans,

beans session beans e
message drive beans.
beans Como regra geral, na qual especificaremos estes tipos mais tarde, um
ENTITY BEAN modela conceitos de negócios que podem ser representados por nomes,
como um comprador, um equipamento, um item de iventário. Em outras palavras entity
beans modelam objetos do mundo real. SESSION BEANS são uma extensão da aplicação
cliente e são responsáveis por modelar processos ou tarefas (ações) e MESSAGE DRIVE
BEANS que são um tipo de bean que se assemelha ao Session Bean e que são acessados a
partir de um sistema de mensagens pelo JMS (Java Message Service).

Resumidamente abaixo os três tipos diferentes de EJBs. Os capítulos seguintes

discutem cada tipo mais detalhadamente.

1. Session Beans:
Beans: executa uma tarefa para um cliente. Pode representar um serviço
(negócio). São divididos em Stateless Session Bean e Stateful Session Bean

2. Message Driven Beans:

Beans: é um listener para a API Java Message Service (JMS),
processando mensagens de modo assíncrono.

3. Entity Beans: representa um objeto de entidade de negócio que existe no

armazenamento persistente.

14
Convenções de nomes para
para EJB

Em função dos enterprise beans serem compostos de múltiplas partes, é importante

seguirmos uma convenção de nomes nas suas aplicações. A tabela abaixo mostra estas
convenções.

Item Sintaxe Exemplo

Nome de um JAR para um EJB (DD)

<nome>JAR CursoJAR
Classe Enterprise Bean
<nome>Bean CursoBean
Interface Remote
<nome>Remote CursoRemote
Interface Local
<nome>Local CursoLocal

Tabela 1-1: Nomenclatura para EJBs

OBS: DD significa que o item é um elemento “deployment descriptor” do bean.

Bibliografia
1 - BURKE, Bill and MONSON-HAEFEL, Richard. "Enterprise JavaBeans 3.0". O'Reilly. 5 ed. 2006. 760 p.

2 - JENDROCK, Eric et al. "The Java EE 5 Tutorial". (http://java.sun.com/javaee/5/docs /tutorial/doc) Consultado em

16/04/2007.

3 - JBoss Web Site: http://labs.jboss.com/portal/jbossejb3. Consultado em 15/04/2007.

15