Além disso, os beans encapsulam a lógica de negócio.
Assim o desenvolvedor pode cuidar só do que interessa, que é o desenvolvimento da lógica do modelo de negócio, pois o contêiner vai cuidar das questões de transações, envolvendo os beans e também da parte de segurança.
Os Enterprise Beans podem também rodar em muitas máquinas, tornando as aplicações mais escaláveis.
Os Enterprise beans podem ser de três tipos:
Session Bean => É um bean usado para a comunicação do cliente, pode implementar um web service.
Message Bean => É como uma espécie de listener, que fica estudando por um tipo de mensagem recebida.
Entity Beans -> São beans persistentes.
Session Bean
Têm o array $_SESSION do PHP não tem? Ele é uma estrutura que só contém dados. Porém um Session Bean é um objeto - Um bean - que contém dados e métodos. Para que o cliente possa se comunicar com as entity beans, os sessions beans encapsulam essa complexidade.
É importante saber que os Sessions Beans são transientes, ou seja, eles não são persistentes, acabou a interação com o cliente eles são removidos.
Acontece porém que durante esse tempo de vida eles podem ser Stateless ou Statefull. Isso, como o nome diz, eles são Stateless se não guardam estado, e Statefull se guardam o estado da transação.
Sim, e pra que guardar ou não guardar estado? Ai depende. Se você quiser, por exemplo, fazer uma aplicação que guarde os itens adicionados a um carrinho de compras, usando o metodo SessionBean.adicionarAoCarrinho( ) , você pode usar um Statefull. A desvantagem é que cada cliente tem que ter uma instância diferente de um Session Bean desse.
O SessionBean Stataless só segura os valores dos atributos durante a requisição. Porém muitos clientes podem reaproveitar as instâncias.
Os Session Beans Stateless podem implementar WebServices - Alias, eles são os únicos Enterprise Beans que podem fazer isso!!!!
Os Session Bens Stateless são mais escaláveis que os Session Beans Statefull.
Os SessionBeans StateFull são indicados quando precisamos manter as informações sobre a interação realizada com um cliente específico.
Message Bean
Vá até o espelho e diga e mande uma mensagem em voz alta fazendo careta: ASSÍNCRONO. ASSÍNCRONO. ASSÍNCRONO.
Pronto, mandou essa mensagem para você mesmo? Memorize:
MESSAGE BEANs são usados quando se precisa trocar informações com a aplicação servidora de forma ASSÍNCRONA.
Os Message Beans são, assim como os Session Beans Stateless, desprovidos de estado. Assim, vários clientes podem reaproveitar uma instância de um Message-Bean.
Um Message-Bean pode processar requisições de múltiplos clientes.
Para acessar um Message Bean deve-se usar um driver como o Java Message Service - JMS. Message Beans são tem interfaces que definem o acesso do cliente.
As interfaces de acesso aos Session Beans (LEMBRE-SE, MESSAGE BEANS NÃO TÊM INTERFACES DE ACESSO E SÃO ACESSADAS VIA JMS) são definidas nos bean's business interface.
Porém um Session Bean pode ter mais de um Business Interface.
Os SessionBeans podem ser acessado remotamente ou localmente.
Remotamente, usa-se a anotação @Remote.
Questão de concurso: Para ser um bean remoto, ele pode ser acessado da própria JVM em que os Enterprise beans. (Note, ele PODE... não ele DEVE, então pode estar na mesma JVM também)
Exemplo:
@Remote
public interface ServicosBancarios{
depositar();
sacar();
}
Já os Beans acessados localmente DEVEM estar na mesma JVM que os Enterprise Beans.
@Local
public interface ServicosLocais{
...
}
Ciclo de Vida dos Enterprise Beans.
Primeiro você deve saber que cada tipo de Enterprise Java Bean tem um ciclo de vida diferente.
StateFull Session Bean
Esse é o mais complicado, isso porque o EJB contêiner pode escolher entre desativar o Bean ou então colocar o Bean no disco (passivate). Geralmente o EJB usa o algoritmo do último recentemente usado para aplicar a passivação. Quando o cliente chama alguma coisa então ele coloca o Bean novamente para o estado de pronto.
Aí tem algumas anotações que dizem que método chamar na transição de cada estado.
@PostConstruct é a anotação que diz qual método chamar depois que o Bean é inicializado.
@PrePassivate é a anotação que vai dizer qual método ser chamado imediatamente antes de passivar.
@Remove é a anotação que indica qual método chamar para remover o Bean
@PreDestroy é anotação que diz qual método chamar antes de destruir o Bean
StateLess SessionBean
Esse é mais simples, Se o Bean não existe, ele é criado, quando deixa de ser usado, ele é destruído. Note que um Bean Stateless não precisa ser passivado. Porque não??? Porque ele não armazena nenhum dado de nenhum usuário específico, tal qual o Session StateFull.
Message Bean
O Message Bean é similar ao Session StateLess Bean, também não é Passivado. O que o servidor faz é criar um Pool de Message Beans, e eles ficam escutando para ver se chega mensagem.
No comments:
Post a Comment