Enterprise Java Beans 3.1

Por que eu devo ler este artigo:O artigo explora alguns dos novos recursos da Java EE 6, especificamente o que h� de novo no EJB 3.1 (JSR 318). Apresenta um detalhamento das melhorias e novidades da tecnologia EJB, com exemplos de aplicaç�o em cen�rios reais, c�digos e dicas de arquitetura.

Fornecer uma atualizaç�o das novidades do EJB 3.1 para desenvolvedores, arquitetos, interessados na tecnologia ou aqueles que, de alguma forma, estejam envolvidos em projetos que utilizam EJBs.

O tema � �til para empresas que utilizam EJBs e desejam manter seus produtos com tecnologia de ponta ou, at� mesmo, melhorar sua produtividade. � importante tamb�m para profissionais que desejam ampliar seus conhecimentos atualizando-se com o que est� por vir na tecnologia.

Enterprise Java Beans

A nova tecnologia traz melhorias muito importantes em recursos j� existentes, dentre os quais se destacam o serviço de agendamento (Timer Service) e a padronizaç�o de nomes JNDI globais. Adicionalmente, h� alguns recursos novos que ampliam as possibilidades de uso dos componentes EJB, especialmente o novo tipo de componente Singleton Bean.

Um ponto importante que pode ser percebido com o advento da especificaç�o da nova tecnologia, bem como com a motivaç�o da comunidade, � a forte preocupaç�o com a simplicidade de uso. Agora, as interfaces passam a ser opcionais, h� a possibilidade de chamadas ass�ncronas de forma simplificada e pode-se implantar EJBs na camada web.

Adicionalmente, h� a possibilidade de se utilizar EJBs no ambiente Java SE e tamb�m contar com vers�es mais leves de servidores (EJB Lite).

Este artigo apresenta os novos recursos dispon�veis na tecnologia Enterprise Java Beans 3.1. Foi realizado um estudo da especificaç�o (JSR 318) de modo a cobrir e esclarecer tais novidades, com a preocupaç�o de fornecer exemplos reais e apresentar dicas baseadas na experi�ncia com a arquitetura Java EE.

Para aqueles que j� conhecem EJBs, � uma �tima oportunidade de se atualizar, para os que est�o iniciando, � um momento igualmente oportuno, afinal, o uso dessa tecnologia est� mais f�cil do que nunca.

Dentre as inovaç�es trazidas pela nova tecnologia, esse artigo destacar�:

Singleton Beans;
Interface opcional para componentes;
Timer Service;
Deploy de EJBs na camada web (.war);
Chamadas ass�ncronas a m�todos;
Nomes JNDI globais padronizados;
EJB Lite;
Embeddable EJB.

N�o deixe de ler nessa ediç�o a entrevista sobre Java EE 6 e EJB 3.1 realizada no JavaOne 2009 com o especialista Reza Rahman.

Java EE 6

Java EE � a plataforma Java para criaç�o de aplicaç�es web e aplicaç�es corporativas distribu�das de larga escala (com uso de EJBs). Essa tecnologia possui uma s�rie de aspectos para a criaç�o de sistemas de qualidade, tais como: segurança, performance, distribuiç�o, concorr�ncia (multi-threading), escalabilidade, controle transacional, persist�ncia e outras tantas necessidades arquiteturais. A id�ia central � que o desenvolvedor deve se preocupar apenas com a regra de neg�cio e com a aplicaç�o, deixando que a plataforma Java EE cuide da infra-estrutura. Com ela � poss�vel criar aplicaç�es de forma independente de plataforma e de servidor, obtendo o que se chama de WODA (Write Once Deploy Anywhere), ou seja, voc� escreve a aplicaç�o uma �nica vez e implanta em qualquer servidor compat�vel.

Java EE 6 (JSR 316) possui recursos promissores que inovam ainda mais a plataforma tanto no mundo web quanto EJB, e � claro, com o compromisso de manter a compatibilidade com as vers�es anteriores. Essa � uma especificaç�o guarda-chuva, ou seja, relaciona outras especificaç�es, sendo que em todas h� a preocupaç�o de simplificar ainda mais o trabalho de desenvolvimento e implantaç�o das aplicaç�es.

EJB 3.1

Enterprise Java Beans (EJBs) � a tecnologia Java padronizada para a criaç�o de componentes em uma arquitetura distribu�da, escal�vel, confi�vel e robusta. Em uma aplicaç�o n-camadas com esse tipo de necessidade arquitetural, usualmente utiliza-se EJBs para a camada de neg�cios. Para executar uma aplicaç�o que utiliza EJBs � necess�rio um servidor de aplicaç�o, o qual � chamado de cont�iner.

Uma das principais e recentes mudanças ocorridas no EJB foi em sua vers�o 3.0, quando sua utilizaç�o se tornou mais simples e produtiva, mantendo todo o poder da tecnologia. Agora, com EJB 3.1 (JSR 318) a curva de aprendizado se torna ainda mais r�pida e h� recursos que prometem alavancar ainda mais o seu uso.

Glassfish V3

O Glassfish � um servidor de aplicaç�es Java EE maduro, robusto e livre. � a implementaç�o de refer�ncia para a especificaç�o do EJB 3.0, e agora do EJB 3.1, em sua vers�o V3. Todos os c�digos aqui tratados j� podem ser codificados e testados com o Glassfish. Mas � necess�rio utilizar uma vers�o recente (promoted build ou nightly build). A vers�o aqui utilizada foi a b57, que vem junto com o NetBeans 6.8 M1.

Enterprise Java Beans 3.1

Nos t�picos a seguir ser�o apresentadas as principais novidades do EJB. A vers�o 3.1 vem recheada de novidades e melhorias que tornam a tecnologia mais poderosa, produtiva e f�cil de aprender. Esse artigo procura detalhar cada um desses novos recursos, com exemplos de c�digo e dicas importantes.

Singleton Beans

Esse tipo de componente EJB segue os preceitos do Design Pattern Singleton, cuja responsabilidade � garantir que exista somente uma inst�ncia de uma classe na aplicaç�o. O componente Singleton Bean garante que apenas uma inst�ncia do componente existir� e ser� compartilhada por todos os usu�rios da aplicaç�o (Figura 1), e o que � melhor, com toda a infra-estrutura fornecida pelo cont�iner, como nos demais componentes EJB. Segundo a especificaç�o, em um ambiente distribu�do haver� uma inst�ncia por JVM, o que merece um pouco de atenç�o.

Figura 1. Representaç�o de um Singleton Bean.

Em muitos cen�rios h� a necessidade de armazenar informaç�es de forma compartilhada a todos os usu�rios da aplicaç�o. Para isso, na web h� o escopo de application, j� com EJBs n�o havia um modo. Uma das formas seria utilizar uma classe Java simples (POJO) contendo atributos est�ticos, mas da� surge uma quest�o: como fica o acesso concorrente (multi-threading) a essas informaç�es, segurança, transaç�o e outros tantos serviços fornecidos pelo cont�iner? Singleton Beans se aplicam muito bem a essa necessidade.

Para criar um EJB como Singleton Bean basta utilizar a annotation @Singleton na classe do componente. Veja um exemplo simples na Listagem 1.

Listagem 1. Criaç�o de um componente Singleton.


    package br.com.globalcode.ejb31;
   
  import javax.ejb.Singleton;
   
  @Singleton
  public class SingletonHelloBean implements SingletonHelloRemote {
    public String getMessage() {
      return "Hello. Welcome to Singleton EJB 3.1 World.";
    } 
  }

Outro recurso muito interessante do Singleton Bean � a possibilidade de capturar eventos de callback no �mbito da aplicaç�o, ou seja, executar operaç�es na inicializaç�o e no encerramento de sua aplicaç�o. Para executar uma operaç�o durante a inicializaç�o basta usar a annotation @PostConstruct em algum m�todo desejado para esse prop�sito, j� para o evento de encerramento deve-se utilizar a annotation @PreDestroy. Observe um exemplo desse recurso na Listagem 2.

Listagem 2. Uso das annotations @PostConstruct e @PreDestroy.


    package br.com.globalcode.ejb31;
   
  import java.util.logging.Level;
  import java.util.logging.Logger;
  import javax.annotation.PostConstruct;
  import javax.annotation.PreDestroy;
  import javax.ejb.Singleton;
   
  @Singleton
  public class CallbackHelloBean implements CallbackHelloRemote {
   
    private String message;
   
    @PostConstruct
    public void initialization() {
      Logger.getLogger(CallbackHelloBean.class.getName()).log(Level.INFO, "***** Starting EJB 3.1 Sample App *****", (Object) null);
      message = "Hello. Welcome to Singleton EJB 3.1 with Callback methods World";
    }
   
    @PreDestroy
    public void shutdown() {
      Logger.getLogger(CallbackHelloBean.class.getName()).log(Level.INFO, "***** Stopping EJB 3.1 Sample App *****", (Object) null);
    }
   
    public String getMessage() {
      return message;
    }
  }

Um poss�vel cen�rio para o uso de Singleton Bean seria compartilhar informaç�es do banco de dados, mantidas em mem�ria, para todos os clientes. Sem o recurso de callback, uma estrat�gia seria carregar as informaç�es na primeira chamada de m�todo ao componente (lazy loading), mas se o processo demorasse cinco minutos o primeiro usu�rio teria que aguardar esse tempo.

Usando o novo recurso voc� pode carregar informaç�es antes da primeira chamada a algum componente EJB. No exemplo da Listagem 2 n�o h� garantia de que esse evento ocorra exatamente na inicializaç�o. Nesse caso, o cont�iner garante apenas que o evento de inicializaç�o ocorra em algum momento ap�s a aplicaç�o ter sido carregada (ap�s o deploy da aplicaç�o ou inicializaç�o do servidor) e antes de qualquer chamada de m�todo, o que pode demorar algum tempo. Opcionalmente, para garantir a execuç�o do m�todo anotado com @PostConstruct de forma imediata durante a inicializaç�o (eager initialization), deve-se adicionar a annotation @StartUp na classe do componente (Listagem 3).

Listagem 3. Exemplo de uso da annotation @Startup.


    package br.com.globalcode.ejb31;
  ...
  import javax.ejb.Startup;
  ...
  @Startup
  @Singleton
  public class EagerCallbackHelloBean implements EagerCallbackHelloRemote {
    ...
    @PostConstruct
    public void initialization() {...}
    ...
  }

Tamb�m � poss�vel determinar a ordem na qual os Singleton Beans ser�o inicializados. Para isso, utiliza-se a annotation @DependsOn na classe do bean, informando quais outros beans precisam ser inicializados primeiro.

Veja um exemplo que utiliza essa annotation na Listagem 4. Nesse c�digo o cont�iner ir� garantir que o SingletonA ser� inicializado antes do SingletonB e esse antes do SingletonC.

Listagem 4. Exemplo do uso da annotation @DependsOn.


      @Singleton
   
  public class SingletonA { 
    @PostConstruct
    public void initialization() {...}
  }
   
  @DependsOn(�SingletonA�)
  @Singleton
  public class SingletonB { 
    @PostConstruct
    public void initialization() {...}
  }
   
  @DependsOn({�SingletonB�})
  @Singleton
  public class SingletonC { 
    @PostConstruct
    public void initialization() {...}
  }

Por padr�o, um Singleton Bean � thread-safe, o que significa que cada um de seus m�todos possui acesso sincronizado, em outras palavras, se m�ltiplas chamadas a m�todos do bean ocorrerem ao mesmo tempo apenas uma por vez ser� executada.

Existem cen�rios nos quais isso n�o � desejado, por exemplo, os dados s�o compartilhados apenas para consulta. Nesse caso, existe a annotation @Lock, que permite escolher o modo de concorr�ncia (LockType). Quando n�o for especificado, o padr�o ser� equivalente a @Lock(LockType.WRITE) que, como explicado no in�cio desse par�grafo, indica acesso sincronizado. Se utilizar @Lock(LockType.READ) o acesso concorrente � permitido, ou seja, m�ltiplas chamadas executar�o simultaneamente, o que � �til nos cen�rios apenas de consulta, ou de forma geral, quando os dados e operaç�es n�o s�o sens�veis � concorr�ncia. A annotation @Lock pode ser utilizada nos m�todos ou na classe, quando utilizada na classe se aplica a todos os m�todos.

Na Listagem 5 h� um exemplo real que incorpora os principais recursos de um Singleton Bean. Esse exemplo serve como soluç�o para um cen�rio no qual se deseja garantir que, em uma �nica instalaç�o, dever� haver apenas uma inst�ncia da entidade Empresa (sistema mono-empresa).

Listagem 5. Exemplo real de uso de um Singleton.


    package br.com.globalcode.ejb31realsamples;
   
  import javax.annotation.PostConstruct;
  import javax.ejb.Lock;
  import javax.ejb.LockType;
  import javax.ejb.Singleton;
   
  import javax.persistence.EntityManager;
  import javax.persistence.PersistenceContext;
   
  @StartUp
  @Singleton
  public class EmpresaServiceBean implements EmpresaServiceRemote {
   
    @PersistenceContext
    private EntityManager em;
    private Empresa empresa;
   
    @PostConstruct
    private void carregarEmpresa() {
      empresa = em.find(Empresa.class, new Integer(1));
    }
   
    @Lock(LockType.WRITE)
    public void atualizarEmpresa(Empresa empresa) {
      empresa.setId(1);
      empresa = em.merge(empresa);
    }
   
    @Lock(LockType.READ)
    public Empresa getEmpresa() {
      return empresa.clone();
    }
  }

Nesse c�digo apenas uma inst�ncia do componente EmpresaServiceBean existir�. O m�todo carregarEmpresa() ser� executado imediatamente ap�s a inicializaç�o da aplicaç�o, o m�todo atualizarEmpresa() possui acesso sincronizado e o m�todo getEmpresa() aceita acesso concorrente.

Para a concorr�ncia tamb�m � poss�vel utilizar a annotation @AccessTimeout, a fim de determinar o tempo m�ximo que uma chamada ao m�todo dever� aguardar em caso de lock (existe outra chamada em andamento que n�o liberou o lock). Ao ocorrer o timeout ser� lançada uma exceç�o do tipo javax.ejb.ConcurrentAccessTimeoutException.

Outra forma de tratar o sincronismo programaticamente � utilizando as palavras reservadas synchronized e volatile da linguagem Java.

Assim como nos demais tipos de EJBs, � poss�vel controlar e demarcar transaç�es usando as annotations @TransactionManagement e @TransactionAttribute, como se faz com EJB 3.0. Al�m disso, tudo que pode ser feito por meio de annotations pode ser realizado atrav�s dos tradicionais deployment descriptors, �teis quando se deseja alterar o comportamento da aplicaç�o sem ter que recompilar o c�digo.

Interface opcional para componentes

No EJB 3.1 o uso de interfaces se tornou opcional com o prop�sito de simplificar o uso de EJBs.

Anteriormente, com os EJBs 2.x, para criar um EJB era necess�rio criar interfaces home e de componente, que podiam ser locais ou remotas e tinham muitas particularidades em sua criaç�o, al�m da necessidade de implementar interfaces de beans (por exemplo, javax.ejb.SessionBean que exige os m�todos ejbXXX()). No EJB 3.0, a interface home j� havia deixado de ser necess�ria e as interfaces de componente, obrigat�rias, se tornaram interfaces Java simples (business interface), o que simplificou muito seu uso.

Como mencionado, agora com EJB 3.1, o uso de interface n�o � mais obrigat�rio. Isso pode gerar alguns questionamentos: a interface n�o � importante? N�o devo usar mais interfaces? E as vantagens do uso de interfaces, como flexibilidade e baixo acoplamento? Um componente de neg�cio n�o deve ter uma interface?

O uso de interfaces � altamente recomendado e voc� ir� utiliz�-las nos componentes de neg�cio exatamente como no EJB 3.0. O prop�sito de torn�-las opcionais � facilitar a criaç�o de componentes para quem est� iniciando com EJBs ou at� mesmo para n�o obrigar o uso de interfaces quando n�o for necess�rio. Imagine utilizar um EJB como controller ou um action na camada web (chamado por um Servlet FrontController, por exemplo). Como as interfaces passaram a ser opcionais para EJBs, voc� pode utiliz�-las apenas quando considerar aplic�vel, o que n�o era poss�vel nas vers�es anteriores. Vale salientar que agora tamb�m � poss�vel adicionar EJBs diretamente na camada web (.war). Nesse cen�rio � muito prov�vel que se utilize EJBs sem necessitar de uma interface, como pode ser visto na Listagem 6. Observe que a classe n�o implementa nenhuma interface.

Listagem 6. Exemplo de EJB sem uso de interfaces.


    package br.com.globalcode.ejb31realsamples;
   
  import java.util.ArrayList;
  import java.util.List;
  import javax.ejb.Stateful;
   
  @Stateful
  public class CarrinhoDeComprasBean {
    private List<Produto> produtos = new ArrayList<Produto>();
    public void addProduto(Produto produto) {
      produtos.add(produto);
    }
  }

Timer Service

Este � outro recurso que trouxe grandes novidades. O uso da Timer Service API ficou muito mais simples e poderoso.

A criaç�o de operaç�es agendadas com Timer Service no EJB 3.0 � mais simples do que com EJB 2.x, mas � limitado em relaç�o �s reais necessidades das aplicaç�es e o agendamento somente pode ser feito programaticamente. Veremos mais sobre tais limitaç�es neste artigo. O agendamento com EJB 3.1 � muito mais completo e permite sua criaç�o atrav�s de annotations (ou Deployment Descriptor) com um estilo similar ao Unix cron.

Unix cron: Cron � um serviço que possibilita aos usu�rios Unix executar comandos em uma certa data/hor�rio ou em per�odos recorrentes. � um mecanismo muito poderoso de agendamento. Para usu�rios Windows, o uso de cron assemelha-se ao agendador de tarefas.

Veja na Listagem 7, primeiramente, como utilizar o recurso com EJB 3.0. Note que o m�todo agendar() realiza um agendamento programaticamente. Esse m�todo precisa ser chamado manualmente para que o agendamento seja efetivamente registrado no cont�iner. No momento configurado, 5h30m diariamente, o m�todo anotado com @Timeout ser� chamado pelo cont�iner.

Listagem 7. Exemplo do uso de Agendamento com EJB 3.0.


    package br.com.globalcode.ejb31realsamples;
   
  import java.io.Serializable;
  import java.util.Calendar;
  import java.util.Date;
  import java.util.List;
  import javax.annotation.Resource;
  import javax.ejb.EJB;
  import javax.ejb.Stateless;
  import javax.ejb.Timeout;
  import javax.ejb.TimerService;
   
  @Stateless
  public class FaturamentoService30Bean implements FaturamentoService30Remote {
   
    @EJB
    private VendasServiceRemote vendasService;
   
    @Resource
    private TimerService timerService;
   
    public void agendar() {
      Serializable info = null;
      Calendar calendar = Calendar.getInstance();
      calendar.set(Calendar.HOUR_OF_DAY, 5);
      calendar.set(Calendar.MINUTE, 30);
      calendar.set(Calendar.SECOND, 0);
      long intervalo = 24L * 60 * 60 * 1000;
      Date inicio = calendar.getTime();
      timerService.createTimer(inicio, intervalo, info);
    }
   
    @Timeout
    private void gerarNotasFiscaisDoDia() {
      //simulaç�o
      List<Pedido> pedidos = vendasService.getPedidosComEntregaParaHoje();
      for (Pedido pedido : pedidos) {
        gerarNotaFiscal(pedido);
      }
    }
   
    private void gerarNotaFiscal(Pedido pedido) {
      //simula uma geraç�o de Nota Fiscal
    }
  }

O modelo de agendamento do EJB 3.0 funciona muito bem apenas para os casos nos quais a tarefa deve ser executada apenas uma vez ou em ciclos bem definidos, por exemplo, a cada dia, hora, minuto, segundo ou semanalmente. Por causa disso, existem outros requisitos que n�o s�o cobertos, tais como:

Operaç�es que devam ser realizadas no primeiro ou �ltimo dia de cada m�s;
Toda segunda, quarta e sexta;
�s 8:00h e 18:00h de cada dia;
�s 23:00h do �ltimo dia de cada m�s;
E v�rios outros.

Com o agendamento do EJB 3.0 � muito complexo atender a essas necessidades, mas o novo mecanismo do EJB 3.1 inovou, permitindo os chamados Calendar-based Timers.

O modelo definido pelo EJB 3.1 tamb�m � chamado de Automatic Timer, conforme a especificaç�o. Seu uso � relativamente simples, de forma que, basta criar um m�todo em um componente EJB e marc�-lo com a annotation @Schedule.

Esse m�todo deve respeitar as seguintes caracter�sticas:

N�o pode utilizar os modificadores final ou static;
Seu retorno deve ser void;
Pode conter um par�metro do tipo javax.ejb.Timer ou nenhum;
N�o deve lançar nenhuma Application Exception.

A sua sintaxe � [public | protected | default] void <nome-m�todo>( [Timer timer] ).

Ap�s o deploy do componente, o m�todo demarcado com essa annotation ser� executado no intervalo determinado.

Cumpre observar que, conforme a especificaç�o, n�o � poss�vel criar um agendamento para o m�todo de um stateful session bean. Essa caracter�stica ainda poder� ser adicionada em uma vers�o futura, conforme tamb�m denota a especificaç�o.

O segredo para o uso deste recurso � o entendimento de como utilizar a annotation @Schedule. A Tabela 1 descreve os principais atributos dessa annotation e seus valores.

Atributo	Descriç�o	Valores
second	Utilizado para definir um ou mais segundos de um minuto.	[0,59] Valor Padr�o: �0� � segundo 0 do minuto.
minute	Utilizado para definir um ou mais minutos de uma hora.	[0,59] Valor Padr�o: �0� � minuto 0 da hora.
Hour	Utilizado para definir uma ou mais horas de um dia.	[0,23] Valor Padr�o: �0� � hora 0 do dia.
dayOfMonth	Utilizado para definir um ou mais dias de um m�s.	[1,31] [-7, -1] � utilizado para indicar n dias antes do �ltimo dia do m�s. Last � utilizado para indicar o �ltimo dia do m�s. {x y}onde x = {"1st", "2nd", "3rd", "4th", "5th", "Last"} y = {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"} Utilizado para indicar uma �nica ocorr�ncia de um dia de semana no m�s. Ex.: "2nd Sat" � Segundo s�bado do m�s. Valor Padr�o: "*" � todos os dias do m�s.
month	Utilizado para definir um ou mais meses de um ano.	[1,12] {"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", Dec"} Valor Padr�o: "*" � todos os meses do ano.
dayOfWeek	Utilizado para definir um ou mais dias de uma semana.	[0,7] {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"} 0 e 7 significam Domingo. Valor Padr�o: "*" � todos os dias da semana.
Year	Utilizado para definir um ano em particular.	Ano com quatro d�gitos. Valor Padr�o: "*" � todos os anos.

Tabela 1. Atributos da annnotation @Schedule

Com a combinaç�o desses atributos s�o in�meras as possibilidades de agendamento. Por�m, antes de apresentar alguns exemplos � importante conhecer como atribuir os valores para cada atributo. A Tabela 2 relaciona as poss�veis formas de atribuiç�o.

Forma de atribuiç�o	Exemplos
Valor simples	hour="10" � �s 10:00h da manh� dayOfWeek="Fri" � �s sextas dayOfWeek="5" � �s sextas dayOfMonth="1st Sun" � primeiro domingo do m�s month="Jan" � no m�s de Janeiro month="1" � no m�s de Janeiro year="2009" � no ano de 2009
Faixa de valores	minute="1-5" � nos cinco primeiros minutos da hora dayOfWeek="Mon-Fri" � de segunda a sexta dayOfMonth="1-15" � nos primeiros 15 dias do m�s
Lista de valores	second="15,45" � nos segundos 15 e 45 minute="1-5, 30, 55" � nos minutos de 1 a 5, 30 e 55 dayOfWeek="Mon, Fri, Sun" � segunda, sexta e domingo
Wild card	* indica todos os poss�veis valores para o atributo minute="" � todos os minutos hour="" � todas as horas month="*" � todos os meses
Incrementos	Segue a sintaxe x/y, onde x significa in�cio e y frequ�ncia. Em x pode-se usar * significando 0. Esta notaç�o somente � aceita para segundos, minutos e horas. second="*/20" � nos segundos 0, 20 e 40 second="5/20" � nos segundos 5, 25 e 45 minute="45/5" � nos minutos 45, 50 e 55

Tabela 2. Formas de atribuiç�o de valores para os atributos da annnotation @Schedule

Observe alguns exemplos de como utilizar o agendamento baseado em calend�rio na Tabela 3.

Agendamento	C�digo
Toda sexta-feira � meia-noite	@Schedule(dayOfWeek="Fri")
Todo dia �til	@Schedule(dayOfWeek="Mon-Fri")
A cada hora todos os dias	@Schedule(hour="*")
A cada 30 minutos todos os dias, iniciando no minuto 0 ou 30	@Schedule(hour="/30") ou @Schedule(minute="0, 30", hour="")
Todo dia 5 e dia 20 �s 09:00h	@Schedule(hour="9", dayOfMonth="5,20")
No �ltimo dia do m�s e no dia 15 �s 08:00h	@Schedule(hour="8", dayOfMonth="Last, 15")
Todo dia das m�es	@Schedule(dayOfMonth="2nd Sun", month="May")
No primeiro dia do m�s �s 06:30h	@Schedule(minute="30", hour="6", dayOfMonth="1st")
No pen�ltimo dia do m�s �s 23:00h	@Schedule(hour="23", dayOfMonth="-1")
Na �ltima sexta-feira de cada m�s �s 19:00h	@Schedule(hour="19", dayOfMonth="Last Fri")
Toda sexta-feira 13	@Schedule(dayOfMonth="13", dayOfWeek="Fri")

Tabela 3. Exemplos de agendamento no EJB 3.1.

Al�m de todas as possibilidades apresentadas na Tabela 3, � poss�vel combinar mais de um agendamento para um mesmo m�todo. Para isso utiliza-se a annotation @Schedules. Por exemplo, de segunda a quinta-feira �s 8:00h e �s 18:00h e sexta-feira �s 8:00h e �s 17:00h:


  @Schedules( {
    @Schedule(hour="8, 18", dayOfWeek="Mon-Thu"),
    @Schedule(hour="8, 17", dayOfWeek="Fri")
  } )

Tamb�m � poss�vel especificar o fuso hor�rio atrav�s do atributo timeZone. Por exemplo, todo os dias �s 19:00h, hor�rio de S�o Paulo (hor�rio de Bras�lia):


  @Schedule(hour="19", timezone="America/Sao_Paulo")

Observe um exemplo de c�digo mais completo envolvendo agendamento na Listagem 8.

Listagem 8. Exemplo real de agendamento com EJB 3.1.


    package br.com.globalcode.ejb31realsamples;
   
  import java.util.List;
  import javax.ejb.EJB;
  import javax.ejb.Schedule;
  import javax.ejb.Stateless;
   
  @Stateless
  public class FaturamentoServiceBean implements FaturamentoServiceRemote {
   
    @EJB
    private VendasServiceRemote vendasService;
   
    @Schedule(hour = "5", minute = "30", dayOfMonth = "*")
    private void gerarNotasFiscaisDoDia() {
      List<Pedido> pedidos = vendasService.getPedidosComEntregaParaHoje();
      for (Pedido pedido : pedidos) {
        gerarNotaFiscal(pedido);
      }
    }
   
    private void gerarNotaFiscal(Pedido pedido) {
      //simula uma geraç�o de Nota Fiscal
    }
  }

Por padr�o, um Timer � persistente, o que significa que ele sobrevive a falhas, ao encerramento da aplicaç�o (shutdown) e a eventos como passivation/activation ou load/store. Para modificar esse comportamento deve-se utilizar o atributo persistent com valor false, por exemplo:


  @Schedule( ..., persistent=false)

A anotaç�o @Schedule aceita ainda uma String como informaç�o adicional atrav�s do atributo info, o que pode ser �til caso haja m�ltiplos agendamentos em uma classe e seja preciso identificar qual agendamento foi disparado. No caso, ficaria:


  @Schedule( ..., info="TimerRelatorioSemanal")

Deploy de EJBs na camada web (.war)

A tecnologia Java EE 5, que inclui EJB 3.0, define uma estrita modularizaç�o de seus componentes. Ela determina que uma aplicaç�o web deve ser empacotada dentro de um arquivo .war, EJBs dentro de um .jar com conte�do espec�fico e uma aplicaç�o enterprise em um .ear que, de modo geral, empacota arquivos .jar e .war.

Essa modularizaç�o continua sendo recomendada para aplicaç�es n-camadas. Entretanto, para aplicaç�es Web-centric esse processo pode ser um tanto quanto burocr�tico, dificultando a utilizaç�o de EJBs em uma aplicaç�o com essa arquitetura.

Web-centric:
� um tipo de arquitetura na qual todos os componentes de servidor residem na camada web. Em uma aplicaç�o Java Web-centric, al�m dos componentes JSP, Servlets e ManagedBeans, os componentes de regra de neg�cio e DAOs s�o implantados na mesma camada. No caso, a regra de neg�cio � implementada com POJOs ou outra tecnologia n�o distribu�da. Essa arquitetura � uma das mais comuns utilizadas no desenvolvimento web.

Tal necessidade motivou a possibilidade, com EJB 3.1, de se empacotar EJBs diretamente no arquivo .war da aplicaç�o web, como pode ser visto na Figura 2.

Figura 2. Deploy de EJBs na camada Web.

H� duas formas de realizar esse procedimento: a primeira consiste em empacotar classes de componentes EJB dentro da pasta WEB-INF/classes do .war, a segunda alternativa consiste em adicionar um .jar contendo EJBs dentro da pasta WEB-INF/lib. Vale salientar que esse .jar n�o se refere a um m�dulo EJB, mas sim a um .jar convencional.

De acordo com a especificaç�o, um pacote .war deve conter no m�ximo um ejb-jar.xml, que, por sua vez, � opcional. Esse arquivo, se existir, dever� ser colocado ou na pasta WEB-INF do .war ou na pasta META-INF do .jar da pasta WEB-INF/lib.

Al�m das caracter�sticas j� mencionadas, um EJB empacotado dentro de um .war deve possuir as mesmas exig�ncias de Class Loading e compartilhar o mesmo Component Environment Namespace. Isso garante que um componente web ter� acesso a esse EJB e vice-versa. Al�m disso, esse EJB ter� acesso a todos os componentes registrados no serviço de nomes tal qual um componente web. Por existir o compartilhamento, deve-se tomar cuidado apenas para que o nome do componente n�o conflite com o nome de outro componente ou recurso j� registrado no namespace da aplicaç�o web, algo que n�o � necess�rio ao se utilizar um m�dulo EJB independente.

Component Environment Namespace: Na plataforma Java EE, todos os componentes e recursos devem ser registrados e localizados atrav�s de um serviço de nomes JNDI. Quando se deseja chamar um m�todo de um EJB, ou obter do cont�iner uma conex�o com o banco de dados, o primeiro passo � localizar o elemento desejado nesse serviço. O Namespace de um componente � uma �rea no serviço de nomes na qual se registram apenas elementos acess�veis por esse componente. Quando se menciona que dois ou mais componentes compartilham o mesmo Namespace isso significa que eles ter�o acesso aos mesmos elementos (outros componentes ou recursos).

Chamadas ass�ncronas a m�todos

At� a vers�o EJB 3.0, a �nica forma de se criar um mecanismo de chamadas ass�ncronas era atrav�s de Message Driven Beans (MDBs), que � uma ferramenta poderosa, confi�vel e tolerante a falhas de middleware orientado a mensagens (MOM). MDB se aplica muito bem ao modelo de chamadas ass�ncronas, contudo, h� certo n�vel de complexidade ao se trabalhar com filas de mensagens. A tecnologia geralmente utilizada para essas filas � JMS. Em determinados cen�rios, nos quais se deseja apenas o modelo de chamada ass�ncrona, o uso de MDBs pode ser trabalhoso, principalmente nos casos em que a toler�ncia a falhas e outras garantias inerentes a filas de mensagens n�o s�o necess�rias.

Middleware Orientado a Mensagens (MOM): � um tipo de arquitetura que utiliza filas de mensagens, cuja comunicaç�o n�o � direta como em uma chamada de m�todo, mas � baseada em troca de mensagens. Essa arquitetura garante uma alta disponibilidade, confiabilidade, escalabilidade e baixo acoplamento. � muito utilizada no Brasil por grandes corporaç�es e instituiç�es financeiras.

Com o prop�sito de permitir chamadas ass�ncronas de forma simplificada, no EJB 3.1 h� a possibilidade de demarcar m�todos como ass�ncronos atrav�s do uso da annotation @Asynchronous (ou atrav�s do deployment descriptor). Essa demarcaç�o pode ser feita para os m�todos da classe do componente, para a pr�pria classe, para os m�todos das interfaces ou nas pr�prias interfaces. Quando aplicado � classe ou interface, todos os seus respectivos m�todos ser�o tratados como ass�ncronos.

Em uma chamada convencional (s�ncrona) o c�digo chamador aguarda o m�todo chamado terminar sua execuç�o para prosseguir. Com a chamada ass�ncrona (Figura 3), enquanto o m�todo executa em uma thread separada, o c�digo chamador continua executando sem aguardar pelo resultado, o que permite criar chamadas com certo grau de paralelismo e/ou permitir que o usu�rio interaja com a interface gr�fica, enquanto o m�todo chamado de um enterprise bean continua executando.

Figura 3. Representaç�o de uma chamada ass�ncrona.

O desenvolvedor dever� levar em conta que, para um m�todo ass�ncrono, o tipo de retorno deve ser void ou Future<V>.

No caso de um m�todo com retorno void, n�o h� nenhuma forma pela qual o componente possa devolver um valor para quem o chamou, claro, � void, mas o detalhe importante � que esse m�todo n�o pode lançar nenhuma Application Exception, pois nesse caso n�o h� como ela ser propagada.

No segundo caso, provavelmente menos comum que o primeiro, o m�todo retorna um objeto que implementa a interface java.util.concurrent.Future<V>, onde V indica um tipo de objeto parametrizado para a interface (uso de generics). Esse objeto permite o retorno de forma ass�ncrona, que o cliente poder� obter em algum momento futuro.

Al�m da obtenç�o do retorno, o objeto Future permite que Application Exceptions sejam propagadas e obtidas pelo c�digo cliente. Ao criar o m�todo com esse tipo de retorno o desenvolvedor dever� devolver uma inst�ncia de javax.ejb.AsyncResult<V>.

Nas Listagens 9, 10, 11 e 12 h� alguns trechos de c�digo que denotam a criaç�o de m�todos que permitir�o a chamada ass�ncrona.

Listagem 9. Exemplo de m�todo para chamada ass�ncrona.


    @Session
  public class FaturamentoServiceBean implements FaturamentoServic {
    @Asynchonous
    public void efetuarPagamento() {
      ...
    }
  }

Listagem 10. Exemplo com a marcaç�o na classe.


    @Session
  @Asynchonous
  public class FaturamentoServiceBean implements FaturamentoServic {
    public void efetuarPagamento() {...} //Ass�ncrono
    public void emitirNotaFiscal() {...} //Ass�ncrono
  }

Listagem 11. Exemplo de m�todo para chamada ass�ncrona com retorno.


@Stateless
public class HelloBean implements HelloRemote {
  @Asynchronous
  public Future<String> lerMensagem() {
    return new AsyncResult<String>("Hello World.");
  }
}

Listagem 12. Outro m�todo para chamada ass�ncrona com retorno.


  @Session
  public class GerenciadorPedidosBean implements GerenciadorPedidos {
    @Asynchonous
    public Future<StatusPedido> efetuarPedido() {
      StatusPedido status = ...
      return new AsyncResult<StatusPedido>(status);
    }
  }

Ao utilizar a annotation @Asynchronous no m�todo da interface n�o � necess�rio especificar o retorno Future no m�todo da classe, pois nesse caso o cont�iner encapsula o objeto AsyncResult automaticamente. Entretanto, como a assinatura ficaria diferente, n�o se pode implementar a interface diretamente, mas sim utilizar a annotation @Remote ou a @Local. As Listagens 13 e 14 mostram como ficam a interface e a classe do componente, respectivamente.

Listagem 13. Interface que define um m�todo ass�ncrono.


    @Remote
  public interface GerenciadorPedidos {
    @Asynchronous
    public Future<StatusPedido> efetuarPedido();
  }

Listagem 14. EJB que implementa um m�todo definido como ass�ncrono em sua interface.


    @Session
  @Remote(GerenciadorPedidos.class)
  public class GerenciadorPedidosBean {
    public StatusPedido efetuarPedido() {
      StatusPedido status = ...
      return status;
    }
  }

Do ponto de vista do cliente do componente, ao efetuar uma chamada de forma ass�ncrona, o desenvolvedor pode utilizar o objeto Future<V>, se retornado, para:

Obter o valor de retorno do m�todo chamado;
Obter uma exceç�o gerada pelo m�todo chamado;
Efetuar uma tentativa de cancelar a chamada, sendo que n�o h� garantias de que o cancelamento seja poss�vel.

O objeto Future<V> retornado n�o � exatamente o mesmo retornado pelo EJB, mas sim uma inst�ncia gerada pelo cont�iner, ou seja, n�o � a mesma refer�ncia. Isso se deve ao fato de que, quem gerencia as chamadas aos EJBs � o cont�iner, sendo assim ele ir� prover a infra-estrutura necess�ria para que o objeto Future seja retornado a quem o chamou. Portanto, o desenvolvedor deve considerar que a informaç�o desejada ser� obtida de forma transparente, n�o importando a implementaç�o de Future<V>.

Considere a seguinte chamada ass�ncrona:


  Future<StatusPedido> future = gerPedidos.efetuarPedido();

Para se obter o valor de retorno � necess�rio chamar o m�todo get() no objeto Future. Se o retorno ainda n�o estiver pronto o m�todo get() ficar� esperando. Al�m disso, se esse m�todo retornar uma Application Exception, deve-se utilizar um bloco try/catch e capturar a exceç�o java.util.concurrent.ExecutionException, conforme a Listagem 15.

Listagem 15. Trecho de c�digo que utiliza o objeto Future.


  try {
    StatusPedido status = future.get();
  } catch (InterruptedException ex) {
    ...
  } catch (ExecutionException ex) { 
    Throwable appEx = ex.getCause(); //Exception original
    ... 
  }

Atrav�s da chamada ao m�todo boolean cancel(boolean mayInterruptIfRunning), do objeto Future, � poss�vel solicitar um cancelamento de uma chamada ass�ncrona. Se esse m�todo retornar false significa que o cancelamento n�o � mais poss�vel, ou depende do bean, pois a tarefa j� iniciou sua execuç�o. Nesse caso, pode-se efetuar essa chamada passando no par�metro mayInterruptIfRunning o valor true, para que, mesmo assim, efetue-se uma tentativa de cancelamento. Essa �ltima forma s� � poss�vel se o c�digo do bean for implementado de forma adequada, como na Listagem 16, cujo c�digo utiliza o m�todo context.wasCancelCalled() a fim de se testar se o cancelamento foi efetuado com mayInterruptIfRunning=true e abortar sua execuç�o.

Listagem 16. Trecho de c�digo que utiliza o m�todo wasCancelCalled().


  @Resource
  private SessionContext ctx;
  ...
  @Asynchronous
  public Future<String> metodo() {
    ...
    if (ctx.wasCancelCalled()) {
      ...
    }
  }

A chamada ass�ncrona apenas coloca o m�todo em um estado pronto para execuç�o dentro de uma nova thread. A partir da�, a responsabilidade � do cont�iner, ou seja, � ele quem controla a execuç�o desse m�todo.

Confira nas Listagens 17 e 18 um exemplo de c�digo real que envolve um cen�rio de processamento de pagamentos. Nele, o m�todo simularUmaTransacao() simula uma transaç�o financeira, por exemplo, de cart�o de cr�dito, que demora um certo tempo para concluir, justificando a necessidade de uma chamada ass�ncrona.

Listagem 17. Exemplo de interface que utiliza chamadas ass�ncronas.


    package br.com.globalcode.ejb31realsamples;
   
  import java.util.concurrent.Future;
  import javax.ejb.Asynchronous;
  import javax.ejb.Remote;
   
  @Remote
  public interface PagamentoServiceRemote {
    public Future<StatusPagamento> confirmarPagamento(InfoPagamento infoPagamento);
    
    @Asynchronous
    public Future<StatusPagamento> processarPagamento(InfoPagamento infoPagamento);
  }

Listagem 18. Implementaç�o que utiliza chamadas ass�ncronas.


    package br.com.globalcode.ejb31realsamples;
   
  import java.util.concurrent.Future;
  import java.util.logging.Level;
  import java.util.logging.Logger;
  import javax.ejb.AsyncResult;
  import javax.ejb.Asynchronous;
  import javax.ejb.Remote;
  import javax.ejb.Stateless;
   
  @Stateless
  @Remote(PagamentoServiceRemote.class)
  public class PagamentoServiceBean {
   
    public StatusPagamento processarPagamento(InfoPagamento infoPagamento) {
      simularUmaTransacao(infoPagamento);
      return StatusPagamento.AGUARDANDO_CONFIRMACAO;
    }
   
    @Asynchronous
    public Future<StatusPagamento> confirmarPagamento(InfoPagamento infoPagamento) {
      simularUmaTransacao(infoPagamento);
      return new AsyncResult<StatusPagamento>(StatusPagamento.OK);
    }
   
    private void simularUmaTransacao(InfoPagamento infoPagamento) {
      for (int i = 0; i < 30; i++) {
        try {
          Thread.sleep(1000);
        } catch (InterruptedException ex) {
          Logger.getLogger(ConfirmacaoPagamentoServiceBean.class.getName())
            .log(Level.SEVERE, null, ex);
        }
      }
    }
  }

Mais detalhes podem ser obtidos no JavaDoc da interface java.util.concurrent.Future.

As chamadas ass�ncronas n�o substituem os MDBs ou filas de mensagens, s�o apenas uma forma mais simplificada, como j� mencionado. Em cen�rios de alta confiabilidade e escalabilidade prefira o uso de MDBs.

Nomes JNDI globais padronizados

Esse recurso simplifica muito a criaç�o de aplicaç�es clientes de EJBs, pois permite a portabilidade sem muito esforço.

Ao desenvolver aplicaç�es distribu�das, podem ocorrer certas situaç�es nas quais se faça necess�rio o lookup dos componentes remotos de forma program�tica, por exemplo, em um Service Locator ou um cliente Desktop. Nessas situaç�es n�o h� o recurso de injeç�o de depend�ncia. Para compreender melhor o benef�cio dessa padronizaç�o � preciso entender o problema.

Lookup de componentes: Como EJB � uma tecnologia para computaç�o distribu�da, � necess�rio um mecanismo pelo qual certo componente da aplicaç�o possa encontrar e acionar componentes atrav�s da rede. Em Java esse mecanismo usa um serviço de nomes baseado em JNDI. Para disponibilizar um componente, ele deve ser registrado com um apelido nesse serviço de nomes. Para localizar esse componente devemos fazer uma pesquisa pelo apelido desejado. A esse processo de busca � dado o nome de lookup. Um exemplo pode ser observado na Listagem 19.

Listagem 19. Exemplo de lookup program�tico.


    Context context = new InitialContext();
  Object o = context.lookup("app/GerenciadorPedidosBean/remote");
  GerenciadorPedidos gerPedidos = (GerenciadorPedidos) o;

Considere os trechos de c�digo das Listagens 20 e 21 e leve em conta a estrutura de deploy da Figura 4. Nessa figura � apresentada uma estrutura tradicional de empacotamento de componentes em uma aplicaç�o Java EE, na qual os componentes web s�o empacotados no arquivo app-web.war, a classe do EJB (GerenciadorPedidosBean) e sua interface remota (GerenciadorPedidos) s�o empacotadas no arquivo app-ejb.jar e esses arquivos, por sua vez, s�o empacotados no arquivo app.ear.

Listagem 20. Trecho de c�digo de um EJB com atributo name definido.


    package br.com.globalcode.ejb;
   
  @Stateless(name="GerenciadorPedidos") //name seria GerenciadorPedidosBean se n�o especificado 
  public class GerenciadorPedidosBean implements GerenciadorPedidos {...}

Listagem 21. Interface para o EJB da Listagem 20.


  package br.com.globalcode.ejb;
   
  @Remote
  public interface GerenciadorPedidos {...}

Figura 4. Estrutura de deploy.

A Tabela 4 relaciona o nome JNDI global do componente quando implantando em cada um dos principais cont�ineres de mercado. Observe que o nome utilizado por cada fabricante difere dos demais.

Servidor	Nome JNDI Global (N�o padronizado)
JBoss	"app/GerenciadorPedidosBean/remote"
GlassFish	"app/GerenciadorPedidosBean/remote"
WebSphere	"GerenciadorPedidos"
OC4J	"app-ejb/GerenciadorPedidosBean/GerenciadorPedidos"

Tabela 4. Nomes JNDI em cada servidor EJB 3.0.

Ao utilizar injeç�o de depend�ncia n�o h� preocupaç�o, pois o pr�prio servidor resolve a localizaç�o do componente desejado, atrav�s do atributo beanName. Exemplo:


  @EJB(beanName="GerenciadorPedidos")
  private GerenciadorPedidos gerenciadorPedidos;

O principal problema ocorre quando � preciso efetuar um lookup program�tico, conforme o c�digo da Listagem 19. Ao mudar a aplicaç�o para um servidor de outro fabricante esse c�digo deixa de funcionar. Para evitar esse problema existem alternativas, por exemplo, utilizar o namespace local (�java:comp/env�) e efetuar um mapeamento desse nome l�gico para o nome f�sico do componente registrado no servidor. Mas, nesse caso, � necess�rio criar um deployment descriptor espec�fico de fabricante, o que torna o processo muito trabalhoso. Existe ainda um atributo da annotation que define o bean (@Stateless, por exemplo) denominado mappedName, mas, conforme a especificaç�o de EJB 3.0, ele n�o � obrigat�rio, de forma que muitos fabricantes o ignoram.

Com o prop�sito de eliminar a necessidade de configuraç�es espec�ficas e permitir a portabilidade de uma forma ainda mais transparente, a nova especificaç�o prop�e tr�s formatos de nomes. Ao implantar um componente o cont�iner ir� registr�-lo automaticamente com cada um desses nomes. A padronizaç�o utiliza a seguinte sintaxe para nomes JNDI globais:


  java:global[/<app-name>]/<module-name>/<bean-name>[!<fully-qualified-interface-name>]
  java:app[/<module-name>]/<bean-name>[!<fully-qualified-interface-name>]
  java:module/<bean-name>[!<fully-qualified-interface-name>]

Os elementos que comp�e essa sintaxe s�o definidos por:

<app-name> - � o nome da aplicaç�o (.ear), se houver;
<module-name> - � o nome do m�dulo web ou EJB;
<bean-name> - � o nome do componente;
<fully-qualified-interface-name> - � o nome do pacote mais �.� mais interface implementada pelo componente.

Reiterando, essa padronizaç�o se refere ao formato dos nomes que o cont�iner utilizar� para registrar os componentes EJB no momento da implantaç�o. Vale salientar que, atrav�s de XMLs (Deployment Descriptors), os nomes JNDI podem ser alterados e seguir qualquer crit�rio, mas isso n�o deve ser necess�rio ao se utilizar EJB 3.1.

Nos casos em que h� apenas uma interface, o cont�iner registra nomes adicionais no JNDI para cada uma dessas formas, sem preencher o par�metro [!<fully-qualified-interface-name>]. Se n�o houver nenhuma interface esse par�metro tamb�m � ignorado. Na exist�ncia de mais de uma interface ser� criada um nome adicional para cada uma. Note que um mesmo componente pode ser localizado atrav�s de diferentes nomes.

Para um melhor entendimento � necess�rio considerar as diferentes possibilidades de empacotamento de EJBs: .jar apenas, .jar dentro de um .ear, .war apenas, e .war dentro de um .ear. Em cada uma das situaç�es o cont�iner ir� criar automaticamente um conjunto de nomes diferentes. Tome os c�digos das Listagens 20 e 21 como base. Na sequ�ncia, s�o exibidos os nomes JNDI globais criados automaticamente pelo cont�iner para cada tipo de empacotamento. Esses nomes poder�o ser utilizados para efetuar o lookup de um modo compat�vel com qualquer cont�iner.

Nomes JNDI para implantaç�o do bean empacotado diretamente no app-ejb.jar:

java:global/app-ejb.jar/GerenciadorPedidos java:global/app-ejb.jar/GerenciadorPedidos!br.com.globalcode.ejb.GerenciadorPedidos java:app/GerenciadorPedidos java:app/GerenciadorPedidos!br.com.globalcode.ejb.GerenciadorPedidos java:module/GerenciadorPedidos java:module/GerenciadorPedidos!br.com.globalcode.ejb.GerenciadorPedidos
Nomes JNDI para implantaç�o do bean empacotado no app-ejb.jar, que por sua vez � empacotado no app.ear:

java:global/app/app-ejb/GerenciadorPedidos java:global/app/app-ejb/GerenciadorPedidos!br.com.globalcode.ejb.GerenciadorPedidos java:app/app-ejb/GerenciadorPedidos java:app/app-ejb/GerenciadorPedidos!br.com.globalcode.ejb.GerenciadorPedidos java:module/GerenciadorPedidos java:module/GerenciadorPedidos!br.com.globalcode.ejb.GerenciadorPedidos
Nomes JNDI para implantaç�o do bean empacotado diretamente no app-web.war:

java:global/app-web/GerenciadorPedidos java:global/app-web/GerenciadorPedidos!br.com.globalcode.ejb.GerenciadorPedidos java:app/GerenciadorPedidos java:app/GerenciadorPedidos!br.com.globalcode.ejb.GerenciadorPedidos java:module/GerenciadorPedidos java:module/GerenciadorPedidos!br.com.globalcode.ejb.GerenciadorPedidos
Nomes JNDI para implantaç�o do bean empacotado no app-web.war, que por sua vez � empacotado no app.ear:

java:global/app/app-web/GerenciadorPedidos java:global/app/app-web/GerenciadorPedidos!br.com.globalcode.ejb.GerenciadorPedidos java:app/app-web/GerenciadorPedidos java:app/app-web/GerenciadorPedidos!br.com.globalcode.ejb.GerenciadorPedidos java:module/GerenciadorPedidos java:module/GerenciadorPedidos!br.com.globalcode.ejb.GerenciadorPedidos

Atualmente, o uso de lookups program�ticos � desaconselh�vel para muitos cen�rios. Ao inv�s disso, recomenda-se o uso de injeç�o de depend�ncia. Nesse caso, o nome no qual o componente � registrado ou localizado fica transparente.

EJB Lite

EJB Lite � definido apenas como um subconjunto da EJB 3.1 API, n�o contendo nenhum tipo de API adicional. Sua motivaç�o vem do fato de que nem toda aplicaç�o que utiliza EJBs necessita de todos os recursos dispon�veis em sua API, o que traz muitas vantagens. Uma delas � permitir que os fabricantes Java EE forneçam uma vers�o reduzida de seus servidores, minimizando a utilizaç�o de recursos e diminuindo o tempo de inicializaç�o, ou ainda, novos fabricantes n�o precisam implementar todos os serviços para disponibilizar uma vers�o m�nima que suporte EJBs. Com isso, � prov�vel que haja mais empresas com servidores compat�veis com Java EE. De forma geral, EJB Lite � uma excelente alternativa para cen�rios mais simplificados que necessitem dessa tecnologia.

Conforme a especificaç�o, o suporte a EJB Lite se limita (se � que se pode chamar de limitaç�o com tantos recursos) a:

Session beans dos tipos: stateless, stateful e singleton;
o Apenas as vis�es de interface local ou sem o uso de interfaces (n�o s�o permitidas interfaces remotas);
o Somente chamadas s�ncronas a m�todos;
Transaç�es gerenciadas pelo cont�iner e programaticamente;
Segurança declarativa e program�tica;
Interceptors;
Suporte a Deployment Descriptor (ejb-jar.xml);
Java Persistence API 2.0;
Embeddable API.

A API completa de EJB 3.1 define ainda outras exig�ncias, mas que n�o fazem parte de EJB Lite, a saber:

Interface remota para session beans;
EJB 2.x;
Message Driven Beans;
Chamadas ass�ncronas;
Web Services JAX-WS e JAX-RPC;
EJB Timer Service;
Interoperabilidade RMI-IIOP.

Vale salientar que algumas tecnologias ser�o marcadas para remoç�o futura na especificaç�o, conceito de pruning, indicando que nas pr�ximas vers�es essas APIs se tornar�o opcionais:

Web Services JAX-RPC;
Entity beans EJB 2;x/1.x e tecnologias derivadas, como CMP, CMR e EJB-QL.

Embeddable EJB

O objetivo dessa tecnologia � permitir o uso de EJBs no ambiente Java SE, o que pode ser muito �til em cen�rios de testes, processamentos batch e uso de EJBs em aplicaç�es Desktop ou baseadas em Console.

A id�ia � permitir a carga de um Embeddable Container, que, por sua vez, carregar� os EJBs dispon�veis no classpath da JVM. Esse tipo de cont�iner � um ambiente para execuç�o de EJBs utilizando apenas Java SE, ou seja, fora da plataforma Java EE. A forma de carregar esse tipo de cont�iner � atrav�s do c�digo:

EJBContainer ec =
javax.ejb.EJBContainer.createEJBContainer();

� poss�vel tamb�m configurar propriedades espec�ficas, como por exemplo, definir quais m�dulos ser�o carregados.

Observe a Listagem 22, no caso apenas o m�dulo EJB app-ejb.jar � carregado, repare no uso da propriedade EJBContainer.EMBEDDABLE_MODULES_PROPERTY, dessa forma � poss�vel controlar apenas os m�dulos EJB que ser�o carregados.

Listagem 22. Exemplo do uso de propriedades para o Embeddable Container.


    Properties props = new Properties();
  props.setProperty(EJBContainer.EMBEDDABLE_MODULES_PROPERTY, �app-ejb�);
  EJBContainer ec = EJBContainer.createEJBContainer(props);

� poss�vel configurar tamb�m as propriedades EJBContainer.EMBEDDABLE_INITIAL_PROPERTY para definir a classe que carregar� o cont�iner e EJBContainer.EMBEDDABLE_APP_NAME_PROPERTY para definir o nome da aplicaç�o (<app-name>) que ser� utilizada para registrar os componentes no JNDI.

A especificaç�o exige que os fabricantes forneçam suporte a EJB Lite em seus Embeddable Containers. Opcionalmente, o fabricante pode implementar a API completa de EJBs em seu ambiente embeddable.

Quanto � funcionalidade, o desenvolvedor pode contar com as mesmas caracter�sticas esperadas em cont�ineres tradicionais, limitadas a EJB Lite, o que aumenta ainda mais a portabilidade, ou seja, se o desenvolvedor n�o utilizar nenhum recurso muito avançado � poss�vel executar os mesmos EJBs em um servidor de aplicaç�o Java, em um servidor web Java ou at� mesmo diretamente na JVM.

Na v�deo aula deste artigo apresentamos as novidades do EJB 3.1 na pr�tica e tamb�m abordamos a integraç�o entre JSF 2.0 e o EJB 3.1, destacando como ficou f�cil criar componentes reutiliz�veis

Conclus�es

Os novos recursos de EJB 3.1 aqui apresentados s�o promissores e devem alavancar ainda mais a adoç�o da tecnologia, principalmente pela simplicidade de uso em situaç�es nas quais, anteriormente, a aplicabilidade de EJBs poderia ser question�vel. Verificando as evoluç�es da tecnologia e acompanhando as discuss�es da comunidade, � poss�vel notar que h� uma forte preocupaç�o com a produtividade e em diminuir a curva de aprendizado para quem inicia na tecnologia.

Tamb�m, nota-se que h� muito esforço em adequar os elementos mais comuns da API, relacionados por EJB Lite, para aplicaç�es com arquitetura Web-centric ou Desktop, cen�rios nos quais o uso de EJBs n�o � utilizado atualmente.

H� muitos pontos de melhoria, ampliando a gama de possibilidades ao se utilizar EJBs, dentre eles: Singleton Bean, Timer Service, chamadas ass�ncronas e nomes JNDI globais.

Vale lembrar que os c�digos aqui utilizados est�o dispon�veis no da Java Magazine. Basta descompactar o arquivo, instalar o NetBeans 6.8 M1 com o Glassfish V3, abrir os projetos e aproveitar. Nele h� um conjunto de Hello Worlds implementados e funcionando, al�m de exemplos did�ticos que foram criados para esse artigo.

Enfim, o que era bom ficou ainda melhor com EJB 3.1. Para aqueles que conhecem EJB, agora podem contar com uma tecnologia ainda mais poderosa. Para quem estiver iniciando, EJB ficou mais f�cil de aprender!

Enterprise Java Beans 3.1

Após sua versão 3.0, que revolucionou a criação de aplicações Java EE distribuídas, surge o EJB 3.1, ainda mais fácil de utilizar e com novos recursos promissores.

Enterprise Java Beans

Java EE 6

EJB 3.1

Glassfish V3

Enterprise Java Beans 3.1

Singleton Beans

Interface opcional para componentes

Timer Service

Deploy de EJBs na camada web (.war)

Chamadas ass�ncronas a m�todos

Nomes JNDI globais padronizados

EJB Lite

Embeddable EJB

Conclus�es

Artigos relacionados