[EJB 3.1] Novidades na especificação - Parte 1

O mercado brasileiro ainda nem assimilou direito a especificação de EJB 3.0 e a JSR-318 - Enterprise JavaBeans 3.1 já foi aprovado pela maioria dos membros do comit executivo para as especificações SE / EE do Java. O único membro que reprovou a JSR foi a Apache.


Isso porque a Apache Software Foundation diz que a spec lead (SUN) esta em desacordo com a JSPA. O que foi explicado pela própria Sun.

The spec lead of the EJB 3.1 specification has confirmed that the TCK would contain no "field of use restrictions", as originally raised by Apache with regard to another JSR (i.e. the SE TCK licensing). That is a good thing.

However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR.

Consequently, in the future, for any submitted JSR (by SUNW or not), we will specifically expect the spec lead to provide clear information on that aspect and take the answer in account when casting our vote.

As novidades na especificação 3.1 visou simplificar a já fácil especificação 3.0 dos EJBs, aumento o uso de annotations e consequentemente o uso ioc, conforme segue:

• Uma visão Local simplificada que forneça acesso ao Session Bean sem a necessidade de uma interface de negócio local.

• Empacotamento e o deployment de componentes EJB diretamente de uma arquivo .war sem a necessidade de um ejb-jar.

• Um componente Session Bean Singleton que forneça um acesso fácil para estado compartilhado, assim como callbacks de startup/shutdown da aplicação.

Isso quer dizer que agora temos um novo tipo de Session Bean, diferente de um Session Beans Stateful ou Stateless, o Session Bean Singleton é um componente que é instanciado apenas uma vez por aplicação. Em casos onde o conteiner é distribuído para várias JVMs, cada aplicação irá possuir uma instância de um bean Singleton para cada JVM. O Session Bean Singleton é compartilhado e suporta acessos concorrentes.
Uma vez instanciado, o tempo de duração da instância do Session Bean Singleton é o mesmo do Contêiner onde ele foi criado. O que mantêm o estado entre as invocações do cliente mas o conteiner não é obrigado a preservar o estado do bean em um suposto crash ou shutdown no conteiner. Resumindo, Singleton Session Beans NÃO são passivados (é assim que se traduz ?).
Outra coisa, um Session Bean Singleton pode ser utilizado como um cliente web service. Somente um Session Bean Stateless ou Single podem fornece uma visão cliente de web service.

Eis o ciclo de vida de Singleton Session View.

• O ciclo de vida de um session bean singleton inicia quando o conteiner invoca o método newInstance da classe Session Bean para uma instância do Singleton. A seguir, o conteiner realiza as injeções de dependência especificado pelas anotações na classe bean ou pela DD. O conteiner chama o método callback PostConstruct para o bean, se houver.

• A instancia do SB Singleton esta agora pronta para delegar a chamada do método de negócio para qualquer cliente ou a chamada do conteiner para método callback disparado por timeout.

• Quando a aplicação esta em shutdown, o conteiner invoca o método callback PreDestroy do Singleton, se houver. Isto finaliza o ciclo da instancia do session bean singleton.

Inicialização do Singleton

O conteiner decide o momento de instanciar o bean Singleton. Se o conteiner encontrar a anotação Startup na classe Singleton ou se o deployment descriptor estiver especificado startup na classe bean o conteiner DEVE instanciar durante o startup da aplicação. O exemplo abaixo inicializa a classe Singleton com estado compartilhado:

@Startup
@Singleton
public class SharedBean implements Shared {
private SharedData state;
@PostConstruct
void init() {
// initialize shared data
...
}
...
}

Outra novidade, é a possibilidade de criar uma cadeia de dependência entre múltiplos componentes Singleton em uma aplicação, através da anotação DependsOn.

@Target(value=TYPE)
@Retention(value=RUNTIME)
public @interface DependsOn

Esta anotação é utilizada quando precisamos iniciar uma instancia de um bean Singleton antes de instanciar outro objeto. Se um Singleton precisa invocar outro Singleton a partir do método PostConstruct, não é necessário uma ordenação via metadados (DD). Exemplo:

@Singleton
public class B { ... }
@DependsOn("B")
@Singleton
public class A { ... }

Essa anotação diz para o conteiner para garantir que o Singleton B é inicializado antes do Singleton A.
É possível incluir um ou mais valores no atributo value de DependensOn, onde cada valor especifica o ejb-name do Singleton destino utilizando a mesma sintaxe do atributo beanName() de @EBJ. Exemplo:

@Singleton
public class B { ... }
@Singleton
public class C { ... }
@DependsOn({"B", "C"}) // A só será iniciado após B e C serem iniciados
@Singleton
public class A { ... }

Isso garante que A só será iniciado após B e C serem iniciados. No caso de múltiplos valores, a ordem que os valores foram informados em value não garante a ordem de execução em runtime.

Ex,: Se o Singleton B possui uma dependência na ordenação no Singleton C, é a responsabilidade do Singleton B de capturar o que está explicito em seu metadado. Exemplo:

// 2 componentes Singleton empacotados em ejb-jars diferentes
// mas no mesmo arquivo .ear
// empacotado no arquivo b.jar
@Singleton
public class B { ... }
// packaged in a.jar
@DependsOn("b.jar#B")
@Singleton
public class A { ... }

Isto demonstra o uso do nome totalmente qualificado da sintaxe do ejb-name para referencia ao componente Singleton empacotado em um módulo diferente na mesma aplicação.

Lembra no EJB 3.0 para evitarmos nomes ambíguos

@EJB(beanName="netfeijao-ejb.jar#NetFeijaoEJB")

Em breve vou publicar mais sobre a nova especificação, para saber mais leia o artigo publicado no server-side, e a página da JSR..

1. JSR 318: Enterprise JavaBeans 3.1
2. Artigo na Server Side