Basicamente, de acordo com a especificação de EJB, os Session Beans representam objetos transientes. Disponibilizados em um servidor de aplicações, eles podem ser acessados remotamente por diversos clientes. São os responsáveis por modelar processos de negócios de um determinado caso de uso e de tarefas referentes a um cliente.

Bom, conhecendo os princípios básicos dos Session Beans, podemos começar a entender as diferenças e o motivo do uso entre os dois tipos em que são classificados: Stateless e Stateful.

Stateless

Normalmente destinam-se a executar automaticamente operações individuais não mantendo o seu estado para cada invocação de um método. Cada cliente pode usar em qualquer momento uma instância de um Stateless Session Bean. São leves, pois o servidor de aplicação mantem um certo número de instâncias preparadas para receber requisições de seus clientes. Ao término de cada requisição suas instâncias retornam para o pool para serem reutilizadas. Por isso um pequeno número de Stateless Session Beans garante um número relativamente grande de requisições de clientes.

Stateful

Sua principal característica é a manutenção de estado entre as suas operações. Por isso é associado a um cliente específico. Para manter os estados das operações o Stateful Session Bean implementa a interface SessionSynchronization. Sendo assim o cliente pode facilmente configurar os valores dos atributos do bean, para serem utilizados nos métodos de negócios. Mas a manutenção de estados tem seu preço, uma instância não pode ser facilmente devolvida ao seu pool enquanto uma sessão entre o bean e o cliente ainda está ativa. Vale lembrar que os dados de uma sessão são transientes e não foram projetados para serem persistentes

Diferenças e afins

Quando usamos Stateful mantemos o estado da conversação com o cliente. Esse estado é mantido somente enquanto durar essa conversação. Ou seja, quando o cliente termina a sessão o estado do bean é destruído. Para isso temos que garantir que quando a conversação é encerrada nem o estado nem o bean deveriam ter utilidade para o cliente.

Totalmente o oposto disso o tipo Stateless mantém estado de conversação apenas durante a vigência da invocação de um método. Após isso, os estados de todas as variáveis do bean são perdidos. Portanto os beans Stateless nos dão alguns benefícios como: escalabilidade, pois são capazes de atender de forma escalável um grande número de requisições comparadas aos beans Stateful; e desempenho, pois container EJB nunca irá mover um bean Stateless da memória RAM para um armazenamento secundário, o que poderá fazê-lo com um bean Stateful.

Boas práticas

A escolha do tipo de um session bean tem que ser realizada cuidadosamente. Sabemos que os Stateful Session Beans têm um preço caro no mercado. As interfaces de acesso devem ser analisadas cautelosamente. Interfaces remotas envolvem acesso a rede podendo ser crucial para um baixo desempenho e a escalabilidade das nossas aplicações. Se utilizarmos somente uma máquina virtual então uma interface local será o suficiente.

Caso utilizarmos Injeção de Dependência devemos certificar que não estamos injetando um Stateful Session Bean em um Stateless Session Bean. Pois informações de estados serão armazenadas em uma instância variável e estarão disponíveis para todos os clientes, contendo assim informações imprecisas. Agora injetarmos um Stateful Session Bean em outro pode ser uma boa solução para alguns casos.

Uma boa prática é separar em interceptadores as rotinas de logging e de auditoria, tento assim as regras de negócios limpas de outras funções que não condizem com o processo em si. Devemos ter cuidado também nos tipos de dados que estaremos armazenando em nossos Stateful Beans, principalmente com aqueles grandes objetos compostos. Existem algumas formas de melhorar o uso de um Stateful Bean, que estarei comentando nos próximos posts como: passivation e configuração de timeout ideal.