Aplicações Baseadas em Objetos Distribuídos, Histórico e

Aplicabilidade do EJB
André Ricardo Gnhoato1, Antônio Carlos Gimenez Junior1, João Carlos Varão Siqueira1
1
Instituto de Informática –Universidade Tecnológica Federal do Paraná – Campi Medianeira

Avenida Brasil, nº 4232 - CEP 85.884-000 - CP 271–Medianeira – PR – Brasil.

andregnhoato@gmail.com, juniorgimenez@hotmail.com, jjcvs@msn.com

Abstract. This article presents a framework showing your EJB component architecture for
developing and deploying business applications, as well as dusting off leave applications are
scalable, transactional, insurance, and multiuser skills.
Resumo. Este artigo apresenta o framework EJB mostrando sua arquitetura de
componentes para desenvolvimento e implantação de aplicativos de negócios,
Espanando também como deixar os aplicativos escaláveis, transacionais, seguros e
multiusuários.

1. Arquitetura de componentes de servidores

Enterprise JavaBeans (EJB) é uma arquitetura de componente voltado para servidores

baseadas em aplicações distribuídas escritas em Java.
Desde sua introdução, há alguns anos, essa tecnologia Enterprise JavaBeans ganhou
força entre os fornecedores de plataformas e equipes de desenvolvimento das empresas. Isso
ocorre porque o modelo de componente EJB simplifica o desenvolvimento dos componentes
de negócios que são transacionais, escalável e portáteis. Servidores EJB’s reduzem a
complexidade dos componentes de negócios em desenvolvimento, fornecendo suporte
automático para serviços de sistema, como transações, segurança e conectividade de dados,
permitindo aos desenvolvedores concentrar no desenvolvimento da lógica do negócio.
A especificação EJB descreve uma arquitetura de servidor baseada em componentes:
A arquitetura EJB é uma arquitetura de componentes para o desenvolvimento e
implantação de aplicações baseadas em componentes de negócio distribuídos.
O objetivo desta especificação é definir um padrão, de modo que diferentes
fornecedores são capazes de programar estas normas. Como esse padrão define cada detalhe
essencial da arquitetura, uma aplicação escrita utilizando a arquitetura Enterprise JavaBeans
torna-se escalável, transacionais, segura e multiusuário.

Figura 1: Visão geral de um ambiente EJB básico

 • Os componentes EJB são executados dentro do contêiner de um servidor EJB.
• O contêiner tem a conexão com o banco de dados ou outros componentes.
• Um cliente pode acessar os EJB’s da mesma Java Virtual Machine (JVM) ou de outra
JVM. O componente EJB home é comparável a uma fábrica de objetos EJB. Os EJB’s
objects obtido a partir do componente EJB home, pode ser objetos locais ou remotos.

2. Histórico

As arquiteturas têm sido submetidas a grandes mudanças evolutivas. A mudança de uma

camada, tipo de sistemas em mainframe de duas camadas baseados em sistemas de
cliente/servidor, abordou-se a necessidade de separar camada da aplicação da camada de
recursos. Durante o início dos anos 90, empresas tradicionais fornecedores de sistemas de
informação começaram a responder às necessidades dos clientes, mudando para duas
camadas, cliente/servidor, e logo para multicamadas visando à flexibilidade. Este modelo
multicamadas é o modelo atual, em que se distribuí o software em um conjunto de máquinas,
que compreende uma parte de um todo da aplicação.
Os novos modelos separam a de lógica de negócios dos serviços do sistema e interface
de usuário, colocando-o em uma camada intermediária (middleware) entre os dois. A evolução
dos novos serviços de middleware - monitores de transação, middleware orientado a
mensagem, e servidores de aplicação Web - deu um impulso adicional a esta nova
arquitetura. Além disso, o uso crescente da Internet e intranets para aplicações empresariais
contribuíram para uma maior ênfase desempenho, facilitando a implementação para clientes
que executam em browsers.
O projeto multicamadas simplifica o desenvolvimento, implantação e manutenção de
aplicativos corporativos. Ele permite que os desenvolvedores se concentrem sobre os detalhes
da programação a sua lógica de negócios, contando com diversos serviços de back-end para
fornecer a infraestrutura e aplicações para o cliente (ambos autônomos e dentro de
navegadores da Web) para proporcionar a interação do usuário.

3. Porque EJB?

Inúmeros sites estão funcionando usando Java sem usar a tecnologia EJB. Os
desenvolvedores estão utilizando servlet/JSP (Java Server Pages) e gerenciando transações
utilizando commit e rollback que está embutido no JDBC sem a ajuda de servidores de
aplicação. Mas ao fazer isso, os desenvolvedores de aplicativos são confrontados com muitos
desafios. Alguns dos mais importantes estão em gerenciar concorrência, persistência e as
transações. Como resultado, os desenvolvedores têm que quer desenvolver um código
proprietário ou comprar suporte de frameworks para resolver.
Esses problemas são resolvidos usando Enterprise JavaBeans (EJB). O uso de EJB’s
permite aos desenvolvedores concentrar-se na lógica de negócios, deixando a parte de
infraestrutura de codificação e lógica, middleware para o EJB, assim os desenvolvedores se
tornam mais produtivos e eficientes.
Como a maioria das outras tecnologias, EJB não fornece uma solução única para todos
os problemas. A utilização de enterprise beans traz vantagens e desvantagens. No entanto, as
vantagens superam as desvantagens, especialmente para aplicações mais complexas que
exigem um modelo de persistência distribuído robusto e sofisticado.
Mais uma vez, não é toda aplicação que considera-se o EJB um ambiente beneficio.
Para ajudá-lo a decidir se esta tecnologia é adequada, este artigo fornece algumas razões para
considerar a usá-lo.

4. Distribuição de Objetos

Ao usar o Enterprise JavaBeans, objetos distribuídos são utilizados para a construção de um

sistema em escala empresarial. Em resumo, isso significa que as partes de seu programa pode
ser implantado em tantas máquinas físicas distintas e em tantos sistemas operacionais,
separando os processos conforme apropriado para alcançar o desempenho, escalabilidade e
disponibilidade de seu sistema.

5. Arquitetura Baseada em Componentes Portáteis

Para muitos futuros clientes, o ponto chave é conseguir uma total independência de
plataforma e uma implementação do servidor de aplicativo. A arquitetura EJB, que é uma
arquitetura de componentes padrão da indústria, pode ajudar a atingir esses objetivos. O
desenvolvimento Enterprise Beans para WebSphere geralmente podem ser implantado em
servidores de aplicativos que não seguem o padrão IBM, e vice-versa. Isso foi demonstrado
durante a conferência JavaOne junho de 1999, onde a aplicação de venda de carros foi
implantada em vários pontos de venda com a utilização de um servidor de aplicação de
vendas. Enquanto que no curto prazo muitas vezes é mais fácil e mais rápido para tirar
proveito dos recursos que podem ser contrários à normalização, mas a padronização oferece
as melhores vantagens em longo prazo.
Além disso, os clientes devem considerar a crescente disponibilidade de ferramentas e
implementações otimizadas do padrão EJB. Porque a maioria dos clientes não está no negócio
de middleware, seus esforços podem ser mais bem orientados para as atividades que estão
mais diretamente relacionados aos seus negócios.

6. Persistência de objetos

Na maioria dos casos, o estado de um objeto persistente é armazenado em um banco de dados

relacional.
Infelizmente, objetos e bancos de dados relacionais diferem muito uns dos outros.
Bancos de dados relacionais têm capacidades limitadas de modelagem, como objeto,
herança e encapsulamento, em comparação com Java. Além disso, tipos de dados SQL não
correspondam aos tipos de dados Java, levando a problemas de conversão. Todos esses
problemas são resolvidos pelo uso de beans de entidade CMP.

7. Independência do esquema do banco

A tecnologia EJB permite uma clara separação da lógica de negócios e do acesso do banco de
dados. A lógica comercial é independente do esquema do banco de dados e pode ser
implantado em organizações com esquemas de banco de dados diferente ou mudando.

8. Gerenciamento de transações

Acesso concorrente a dados compartilhados pode ser uma das maiores dores de cabeça a um
desenvolvedor. A consideração de todas as questões relacionadas como o travamento do banco
de dados, simultaneidade, ou mesmo perda de integridade dos dados pode levar à criação de
grandes esquemas complexos para gerenciar o acesso a dados compartilhados no nível de
banco de dados.
EJB trata automaticamente essas ameaças complexa do projeto e simultânea questões
partilhada de dados. Como mencionado anteriormente, o container EJB fornece todos os
serviços de transações necessárias para o controle de acesso a dados de back-end de forma
transacional.

9. Múltiplas fontes de dados com capacidades transacionais

Muitas aplicações requerem a capacidade de acessar múltiplas fontes de dados para exemplo,
um programa pode utilizar os dados em ambos DB2 uma camada intermediária ou banco de
dados Oracle e um mainframe CICS ou IMS sistema acessível através do WebSphere MQ.
 O fundamental é que algumas aplicações exigem que esse acesso esteja totalmente
transacional que a integridade dos dados é mantida através de fontes de dados. Por exemplo,
um aplicativo pode exigir que a colocação de um pedido de usuário será composto por
armazenar as informações de forma detalhada em um banco de dados Oracle e,
simultaneamente, colocar uma ordem de transferência com um sistema CICS através do
WebSphere MQ. Se uma a atualização do banco de dados ou o enfileiramento MQ falhar, a
transação inteira deve rolar para trás.
No passado, as únicas opções com as quais a construção de sistemas como estes foram
monitores de transação, tais como Encina, CICS, ou smoking, que costumava ter
interfaces não padronizadas era necessário desenvolvimento em linguagens como COBOL,
C++ ou C.
EJB suporta múltiplas transações simultâneas, com total compromisso e
capacidade de reversão em múltiplas fontes.

10. Arquitetura da camada central

Muitas vezes, as empresas consideram seu software de aplicação, nomeadamente a regras de

negócios e estruturas de dados que compõem a lógica do negócio, como empresas ativas.
Portanto, elas estão preocupadas com a proteção desses ativos a partir da Internet pública.
EJB permite que a empresa use uma arquitetura de camada intermediária de modo que
lógica de apresentação pode ser separada da lógica de negócios. Esta separação torna possível
a utilização de um segundo firewall, entre estas duas camadas diferentes para maior
isolamento de todos os componentes do aplicativo que contém lógica de negócios.

11. Vários tipos de clientes acessando dados compartilhados

Muitas vezes, um único pedido terá vários tipos de clientes que precisam de acesso a mesmo
conjunto de informações. Por exemplo, um aplicativo pode ter um web-based HTML front-
end para os clientes externos, e um mais completo de aplicativos Java front-end para usuários
internos. Tradicionalmente, este problema tem sido resolvido pelo cancelamento duas versões
do mesmo aplicativo que compartilham os mesmos dados de fontes (Tabelas). No entanto,
esta não é eficiente tanto em tempo de programação ou utilizando o banco de dados, se
bloqueios múltiplos bancos de dados poderia ser realizada de uma só vez.
A solução de EJB para este problema é colocar dados comum e de lógica de negócios
em um conjunto único de EJBs que são acessados por diferentes tipos de cliente (por
exemplo, HTML / servlet e aplicação). EJBs de controle de acesso aos dados de back-end e
gerir internamente as transações correntes e bloqueio de banco de dados. Isso reduz o esforço
de programação total, eliminando a duplicidade de código na aplicação e por reduzindo a
quantidade de esforço despendido na escrita lógica de controle de banco de dados.

12. O acesso a dados compartilhados

Tradicionalmente, as soluções de grandes clientes exigem uma aplicação para gerenciar o

acesso a dados compartilhados ao nível de banco de dados. Isto resulta frequentemente em
regimes de alta complexidade para lidar com o bloqueio de banco de dados e de
simultaneidade, ou, alternativamente, com a perda de integridade dos dados quando estes
assuntos não são considerados.
EJB trata automaticamente desses processos complexos e simultâneos, quanto à
questão de dados compartilhados, pois além de oferecer suporte a programação distribuída
apresenta-se:
• Compatível com qualquer base de dados;
• Administra automaticamente o ciclo de vida, persistência e segurança;
• Possibilita o Controle de concorrência e Gerência de Transações da Aplicação.
13. Método de nível de segurança

Certos tipos de aplicações têm restrições de segurança difíceis de programar. Por exemplo,
solicitações de segurança para o acesso aos dados do usuário, a fim de atender às normas da
empresa.
De certa forma não havia uma maneira rápida, prática e eficiente para restringir o
acesso a um objeto ou a métodos de um determinado usuário utilizando-se EJB, porém, esta
complexidade se apresenta nas versões anteriores a versão 3.0, que tornou sua manipulação e
processamento mais simples, pois é efetuada à partir de “anotações”.
Para realizar esta tarefa, realizava-se a restrição de acesso ao nível do banco de dados,
e depois se verificava os erros lançados a nível de conexão (JDBC), ou restringindo o acesso
ao nível da aplicação onde cada usuário possui sua área de trabalho.
Contudo, são criados grupos de usuários que podem ser criados e autorizados ou até
mesmo negados os seus direitos de execução. No WebSphere1, esses mesmo grupos de usuário
podem ser concedidos ou negados o acesso aos recursos da Web (Servlets, JSPs e páginas
HTML).

14. Programação baseada em Componentes

Entende-se que através da utilização de EJB obtém-se um padrão para a implementação da

regra de negócio em aplicações multi-camadas.
Com este entendimento, EJB define uma programação baseada em componentes que
são tratados do lado do servidor, de maneira a facilitar a utilização de regras para o uso da
Aplicação.
São eles:
• EntityBeans: representam os objetos do negócio que serão armazenados em uma base
de dados (persistência); eles podem ser compartilhados por vários clientes,
necessitando assim de uma chave-primária (um identificador único daquele objeto
‘Id’).
• SessionBeans: representam os objetos que gerenciam a ‘lógica do negócio’ e não tem
caráter de persistência; são voláteis e tem um ciclo de vida muito curto. Como não são
objetos armazenados, existem apenas durante a execução de um serviço, uma sessão
cliente-servidor. Existem dois tipos de Componentes SessionBean, o Stateless
SessionBean e o Stateful SessionBean.

Stateless SessionBean: é um componente de negócio que não mantém

conversação com o usuário, ou seja, o pedido do cliente é recebido e
realizado pelo servidor de forma independente, sem manter
informações de estado. Por esta característica, é executado para
processamento de dados.

Stateful SessionBean: é um componente que mantêm estado, ou seja, é

capaz de armazenar dados. Por esta característica, é utilizado quando
uma informação precisa ser armazenada no tempo de execução da
aplicação.

• Message-driven Beans: Incorporado recentemente, este componente representa

objetos que podem ser considerados como message listeners. São executados quando
recebem uma mensagem através do JMS (Java Message Service) e implementam
invocação assíncrona de métodos, similar ao processamento de eventos.

1
Websphere é o nome de uma família de softwares da IBM para criação e execução de aplicações baseadas no
padrão Java J2EE, fornecendo também infra-estrutura para integração de aplicações corporativas.
15. Integração com CORBA

EJBs são construídos sobre uma tecnologia que é uma combinação de Java Remote Method
Invocation (RMI) e Component Object Request Broker (CORBA).
Clientes acessam usando RMI sobre IIOP2. Isso permite que puramente clientes
CORBA possam acessar EJBs como clientes EJB.

16. Projeto e Desenvolvimento

Desenvolvimento e execução de componentes com um mapeamento bem definido entre as

tarefas e funções permitem a execução de um sistema mais elaborado e eficiente.
As várias tarefas dentro de um processo EJB de desenvolvimento e produção são
atribuídos a diferentes papéis que fazem parte da especificação.
A arquitetura EJB define, portanto, seis funções:

• Enterprise Bean Provider;

• Application Assembler;
• EJB Deployer;
• EJB Server Provider;
• EJB Container Provider;
• Systems Administrator.

Ao se criar uma EntityBeans no servidor, está se executando não somente uma função,
mas várias, como segue: Enterprise Bean Provider, Application Assembler, EJB Deployer,
EJB Server Provider, EJB Container Provider, Systems Administrator.
O EntityBean é uma classe Java com a anotação @Entity, normalmente o EJB envia o
objeto EntityBean para uma tabela no banco de dados utilizado.
O nome desta tabela também é definido na classe Bean através da anotação @Table,
sendo que cada coluna desta tabela é um atributo da classe.
As anotações servem para atribuir funções à métodos e classes. A anotação @Id
colocada antes do método define que aquele atributo será a primeira coluna da tabela e o
identificador desta.

Implementação:
@Entity
@Table(name = "Cliente")
public class Cliente implements Serializable{
private int id;
private String nome;

public Cliente () { }

public Cliente (String n) {

this.nome = n;
}
@Id(generate = GeneratorType.AUTO)
public int getId () { return id; }
public void setId (int id) { this.id = id; }

// continua a implementação...
}
Código-fonte 1: Criação EntityBean

2
O protocolo IIOP (Internet Inter-Orb Protocol) é uma implementação do GIOP para o protocolo de rede
TCP/IP. Também pode ser descrito como uma realização concreta das definições abstratas do GIOP.
 A aplicação EJB é representada por uma estrutura de projeto (.ear) que contém os
EntityBeans em um diretório (.par), os SessionBeans e outros componentes que não tratam
persistência ficam armazenado no diretório (.ejb3), entretanto, no diretório META-INF tem-se
o arquivo de configuração da aplicação (aplication.xml), por fim, a camada web é
representada pelo diretório web.war.

Desta forma:

Figura 2: Projeto EJB

O arquivo de configuração da aplicação (aplication.xml), é representado da seguinte

forma:

<application> Nome da Aplicação

<displayname>EJB3Trail</displayname>
<description>Estrutura de um projeto EJB apresentado no Seminário</description>
<module>
<ejb>entities.par</ejb> Nome do arquivo que contém as classes
</module> que implementam persistência.
<module>
<ejb>business.ejb3</ejb> Nome do arquivo que contém as classes
</module> que NÃO implementam persistência
<module>
<web>
<weburi>web.war</weburi>
<contextroot>EJB3Trail</contextroot>
</web>
</module> Nome do arquivo que contém a camada
</application> web.

17. Referências Bibliográficas

http://www.developer.com/java/ent/article.php/1434371/Introduction-to-EJBs.html
http://javafree.uol.com.br/artigo/12088/Tutorial-EJB-Como-e-facil-EJB.html (tutorial de
implementação)
Borges, Alexsandra. EJB - Enterprise JavaBeans. Programa de Educação Tutorial – PET.
UFSC 2005.