1

Enterprise JavaBeans 3.0

Parte 1: Introdução

< Por: RPor: RPor: RPor: Rafael Zancan Frantzafael Zancan Frantzafael Zancan Frantzafael 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.

2

O que é um Enterprise O que é um Enterprise O que é um Enterprise O que é um Enterprise JavaJavaJavaJavaBeanBeanBeanBean

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.

3

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ênciaGerenciamento da PersistênciaGerenciamento da PersistênciaGerenciamento da 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 Acesso Acesso Acesso concorrente concorrente concorrente concorrente a dadosa dadosa dadosa 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 Acesso Acesso Acesso remoto remoto remoto remoto a dadosa dadosa dadosa 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 componentesModelo desenvolvido baseado em componentesModelo desenvolvido baseado em componentesModelo desenvolvido baseado em 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.

· PortabiliPortabiliPortabiliPortabilidadedadedadedade. 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çaControle Transacional e de SegurançaControle Transacional e de SegurançaControle Transacional e de 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 dispobilidadeAlta dispobilidadeAlta dispobilidadeAlta 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.

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

4

para maximizar a eficiência de recursos. Componentes podem ser migrados para

balancear carga sem um cluster de processadores.

· Neutralidade do Neutralidade do Neutralidade do Neutralidade do tipo de ctipo de ctipo de ctipo de cliente.liente.liente.liente. 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

5

checarQuantidadeMaterial() e entregarMaterial(). Invocando estes métodos, os

clientes remotos podem utilizar os serviços do controle de material fornecidos pela aplicação.

6

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 1 1 1 –––– Session Session Session Session B B B Beaneaneaneanssss:::: Executa uma tarefa para um cliente 1.1 1.1 1.1 1.1 –––– StatelessStatelessStatelessStateless: : : : Sem informação de estado

1.2 1.2 1.2 1.2 –––– StatefulStatefulStatefulStateful: : : : Com informação de estado

2222 –––– Message Driven B Message Driven B Message Driven B Message Driven Beaneaneaneans (MDB)s (MDB)s (MDB)s (MDB):::: Atua como um listener para a API Java Message

Service (JMS), processando mensagens assincronamente.

3333 –––– Entity Entity Entity Entity B B B Beanseanseanseans:::: Representa um objeto de entidade de negócios que existe no armazenamento persistente

7

Uma arquitetura com Enterprise Java BeansUma arquitetura com Enterprise Java BeansUma arquitetura com Enterprise Java BeansUma 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.

8

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:Métodos de CallBack:Métodos de CallBack: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

9

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:EJBContext Interface:EJBContext Interface: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 InteJNDI (Java Naming and Directory InteJNDI (Java Naming and Directory InteJNDI (Java Naming and Directory Interface):rface):rface):rface): 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.

10

O Conteúdo de um enterprise beanO Conteúdo de um enterprise beanO Conteúdo de um enterprise beanO 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.

11

Empacotamento da aplicaçãoEmpacotamento da aplicaçãoEmpacotamento da aplicaçãoEmpacotamento 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.

12

Benefícios da utilização de EJBsBenefícios da utilização de EJBsBenefícios da utilização de EJBsBenefí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

13

Quando usar EJBsQuando usar EJBsQuando usar EJBsQuando 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.

14

Tipos de EJBsTipos de EJBsTipos de EJBsTipos de EJBs

Um componente EJB possui três tipos fundamentais: entity beansentity beansentity beansentity beans, session beanssession beanssession beanssession beans e

message drive beansmessage drive beansmessage drive beansmessage drive 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. SessionSessionSessionSession Beans Beans 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 DrivenMessage DrivenMessage DrivenMessage Driven Beans Beans Beans Beans:::: é um listener para a API Java Message Service (JMS),

processando mensagens de modo assíncrono.

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

15

Convenções de nomes paConvenções de nomes paConvenções de nomes paConvenções de nomes para EJBra EJBra EJBra 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.

ItemItemItemItem

SintaxeSintaxeSintaxeSintaxe

ExemploExemploExemploExemplo

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.

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