1

Enterprise JavaBeans
Novidades da especificação 2.1
POR HERVAL FREIRE DE A. JÚNIOR (HERVAL@CNNT.COM.BR)

Propondo novos recursos e melhorando pontos fracos, a especificação EJB 2.1 trás
novo fôlego à arquitetura J2EE.
Foi lançada, no mês de Julho deste ano, uma prévia da especificação EJB 2.1. A especificação,
com lançamento oficial previsto para abril de 2003, trás diversas melhorias em relação à versão
anterior, além de algumas modificações mais profundas, como a integração com a nova arquitetura
de Web Services, uma mudança radical na implementação dos Message-driven Beans e um
interessante dispositivo de temporização controlada pelo container. Alguns dos novos recursos da
plataforma serão abordados no decorrer deste artigo.
Este artigo pressupõe conhecimento nos conceitos e tecnologias da plataforma EJB e da
arquitetura de Web Services. Pretendemos mostrar, de maneira breve, alguns destes novos e
excitantes recursos.

Suporte a Web Services

A principal mudança da especificação EJB 2.1 é, sem dúvida, o suporte à arquitetura de Web
Services. Em termos práticos, a nova especificação prevê que qualquer Stateless Session Bean
poderá ser publicado como um Web Service, de forma a ser acessado por sistemas externos
utilizando os protocolos SOAP e WSDL: desta forma, um cliente utilizando o protocolo SOAP 1.1
em qualquer plataforma de programação (.Net, Apache Axis, perl) pode utilizar um Stateless
Session Bean de maneira transparente. Da mesma forma, a especificação também especifica
métodos pelos quais um EJB pode utilizar Web Services externos como se estivesse acessando
métodos em um outro EJB. Para tal interação, são utilizadas duas APIs integrantes do pacote J2EE
1.4 - JAX-RPC e JAXM – propostas e desenvolvidas dentro do Java Community Process da Sun.

A API JAX-RPC é, essencialmente, RMI sobre SOAP. A implementação é similar à implementação RMI
pura e RMI-IIOP (RMI sobre CORBA). Em sua implementação mínima, o JAX-RPC deve suportar, a
possibilidade de execução de chamadas remotas de SOAP sobre HTTP – o que não impede que os
fabricantes decidam implementar o suporte a outros protocolos de transmissão e codificação.

Na especificação EJB 2.1, a API JAX-RPC pode ser utilizada por qualquer tipo de EJB para invocar Web
Services – sejam eles outros EJBs ou não.
 2

O JAX-RPC também é a base para uma nova interface chamada de endpoint: com esta interface, é possível
expor um Stateless Session Bean de forma que o mesmo possa ser utilizado por clientes como um Web
Service.

Um endpoint deve simplesmente implementar a interface javax.rmi.Remote – a implementação do JAX-RPC

fará as devidas conversões de forma a gerar os esqueletos necessários para a invocação remota, da
mesma forma que são gerados os esqueletos para a linguagem CORBA nas versões anteriores de EJBs. A
figura 2 demonstra o cenário imaginado: através dos endpoints, qualquer cliente com suporte ao protocolo
SOAP poderá fazer chamadas ao EJB de maneira transparente.

! ! ! " # $

Agendamento de Processos
Além da integração com Web Services, outras mudanças interessantes também apareceram na
nova especificação da arquitetura EJB. Uma delas é o mecanismo de temporização gerenciada pelo
container - um mecanismo que permite o agendamento de tarefas e a notificação de eventos
temporizados, permitindo que processos sejam agendados para execução em um mecanismo
semelhante aos “cron jobs” do Linux.
O mecanismo permite que qualquer Entity Bean ou Stateless Session Bean seja registrado para
receber notificações do serviço de Timer em um determinado momento ou quando um determinado
período tiver se encerrado. O mecanismo de programação de um Timer é bastante simples: EJBs
que queiram receber notificações do serviço de temporização implementam a interface TimedObject. O
único método da interface, mostrada na listagem 1, é chamado sempre que o Timer associado ao
EJB disparar uma notificação.
% &! ' ( )
public interface javax.ejb.TimedObject {
public void ejbTimeout(Timer timer);
}

O método poderia ser utilizado em um EJB para disparar uma mensagem utilizando JMS ou
enviar um e-mail no dia 5 de cada mês automaticamente, por exemplo.
O objeto que implementa a interface Timer, utilizada como parâmetro para o método ejbTimeout(),
inclui métodos que permitem saber a situação atual do timer ou cancelá-lo, por exemplo. A
interface Timer é mostrada na listagem 2.

% &! '
public interface javax.ejb.Timer {
public void cancel();
public long getTimeRemaining();
public java.util.Date getNextTimeout();
public javax.ejb.TimerHandle getHandle();
 3

public java.io.Serializable getInfo();

}

O serviço de temporização (Timer Service) implementado pelo container EJB pode ser acessado
através da interface TimerService. A interface pode ser acessada através do método
EJBContext.getTimerService(), mostrada na Listagem 3. Um EJB pode criar qualquer número de
Timers para diversos possíveis eventos. Para efetuar suas notificações, todos os Timers invocarão o
mesmo método ejbTimeout() do EJB, que deve cuidar do tratamento diferenciado para cada
temporização em particular.

% * '
public interface javax.ejb.TimerService {
public Timer createTimer(long duration,
java.io.Serializable info);
public Timer createTimer(long initialDuration,
long intervalDuration,
java.io.Serializable info);
public Timer createTimer(java.util.Date expiration,
java.io.Serializable info);
public Timer createTimer(java.util.Date initialExpiration,
long intervalDuration,
java.io.Serializable info);
public Collection getTimers();
}

Melhorias na EJB-QL
A linguagem de consulta EJB-QL também sofreu melhorias na nova edição da especificação EJB.
As novidades incluem a cláusula ORDER BY e algumas novas funções que facilitam o tratamento
das queries, como veremos a seguir.
A cláusula ORDER BY funciona de forma idêntica à cláusula da linguagem SQL padrão,
podendo utilizar as palavras reservadas ASC e DESC para ordenação ascendente e descendente. Um
exemplo de utilização em uma sentença EJBQL é dado na Listagem 4.

% + ! " # , % ! - ( .
SELECT OBJECT( I )
FROM Invoice as I
ORDER BY I.date DESC, I.number

Também foram adicionadas 6 novas funções à EJB-QL, uma para a cláusula WHERE (a função MOD) e
cinco para a cláusula SELECT (AVG, COUNT, MAX, MIN e SUM). A aplicação das funções é igual à versão
correspondente em linguagem SQL padrão: AVG e SUM podem ser aplicadas apenas a valores
numéricos, enquanto COUNT, MAX e MIN podem ser aplicadas a qualquer campo, incluindo Dates e
Strings. Um exemplo de utilização é dado na listagem 5.

% / "0 - " # , % ! !12 3 ! 4

SELECT COUNT( I ), SUM ( I.total )
FROM Invoice as I
WHERE I.paid = FALSE

Sistema de “Message Linking”

Um recurso bastante interessante proposto para a especificação EJB 2.1, o mecanismo de
encadeamento de mensagens permite que o direcionamento de um serviço de mensagens seja
definido em tempo de deployment, de forma a garantir o desacoplamento dos componentes.
De maneira simplificada, o Message Linking permite definir que a saída de um serviço de
mensagens qualquer (JMS ou JAXM) deve ser dada como entrada para um outro serviço,
permitindo que desenvolvedores decidam o fluxo dos dados em uma etapa posterior à codificação e
possam modificar o fluxo (workflow) com mais facilidade.
 4

Message Driven Beans

Por último, os Message Driven Beans também foram melhorados: se antes só era possível
trabalhar com o modelo JMS (Java Message Service), agora é possível conectar um MDB a
diversos outros provedores de mensagens.
Os serviços de mensagens foram introduzidos no EJB 2.0, na forma de JMS (Java Message
Service). A idéia dos serviços de mensagens assíncronas permite um novo mundo de possibilidades
na programação de serviços e foram, juntamente com as mudanças no funcionamento dos Entity
Beans, a mudança mais profunda da arquitetura EJB 1.1 para o EJB 2.0.
O EJB 2.1 amplia o poder dos Message Driven Beans da versão anterior para além do JMS.
Fabricantes de Servidores de Aplicações compatíveis com EJB 2.1 deverão dar suporte ao JMS e,
além dele, a quaisquer outros tipos de sistemas de mensagens assíncronas. O provável que todos os
fabricantes venham a implementar suporte a JAXM para os Message Driven Beans, o que permite a
utilização de MDBs como Web Services. Indo mais além, é provável que se implementem MDBs
com suporte a SMTP para e-mail, SNMP para controle de dispositivos de rede e outros protocolos
de comunicação e mensagens instantâneas, como o SMS.
O que garante que um MDB da nova arquitetura será portável entre containeres de diversos
fabricantes é a nova arquitetura utilizada. Chamada de J2EE Connector Architecture (JCA 1.5), a
arquitetura garante que, se um fabricante decidir criar um componente baseado em conectores, o
mesmo será portável entre containeres diversos que implementem o mesmo serviço. Assim, se dois
fabricantes implementam serviços de mensagens SMTP, por exemplo, o desenvolvedor pode
projetar um MDB para envio de e-mails e garantir que o mesmo será portável entre os Servidores de
Aplicação. A figura 3 demonstra este cenário.

* 5 6 7 ! # ! ! 8 /

A API JAXM (Java API for XML Messaging) é uma API de geração de mensagens XML. O JAXM é
orientado a documentos: enquanto a API JAX-RPC trata de esconder a implementação do SOAP com RMI,
a JAXM trabalha diretamente com a estrutura dos documentos XML utilizados na comunicação entre os
Web Services. Esta API permite a construção de um novo tipo de MDB, que consome mensagens SOAP e
se comporta como um Web Service.

Um container compatível com a arquitetura EJB 2.1 pode implementar Message Driven Beans que
trabalhem com a API JAXM de forma assíncrona (como o serviço JMS) ou síncrona (trabalhando com
processos de requisição-resposta), como mostrado na figura 4. Este novo tipo de EJB é possível graças à
generalização dos MDBs, que agora podem trabalhar com qualquer sistema de mensagens, além do JMS.
 5

+ & ! 12 6 6 7# 9! ! 9! !

Conclusões
É bom lembrar que muita coisa ainda pode mudar, visto que a versão divulgada da especificação é
um rascunho para apreciação pública. Vale a pena esperar pelos recursos de integração entre
plataformas da nova especificação: as novidades propostas não só corrigem problemas das edições
anteriores, como também adicionam recursos que haviam sido esquecidos. Os novos recursos de
temporização e arquitetura de conectores também abrem um novo leque de opções para o
desenvolvimento e garantem um novo fôlego a uma das plataformas de construção de sistemas
corporativos mais populares no momento.

:
" 1; " # :< :==) ! = = ) = <
>" ! " !> + 3 " " 4 < :==) ! =)
6 3 6 4> < :==) ! = =)
"! " ! !! < > / < :==) ! =) = !!