Tópicos

Introdução To top of page

Essa diretriz focaliza a identificação de Beans de Sessão. Orientação adicional sobre Beans de Sessão é fornecida em Diretrizes: Beans de Sessão. Orientação geral sobre EJBs é fornecida por Diretrizes: Enterprise JavaBeans.

Identificando Beans de Sessão To top of page

As classes de controle são sempre candidatas adequadas para os beans de sessão, uma vez que os beans de sessão são adaptados para fornecer lógica de controle, especificamente quando essa lógica de controle envolve uma conversação com um cliente. Um bean de sessão também é sempre identificado como uma fachada para um conjunto de objetos na Camada de Negócios (consulte Padrão de Fachada de Sessão a seguir). Além disso, desde o J2EE 1.4, os beans de sessão sem preservação de estado podem ser utilizados para implementar serviços da Web.

Se você estiver trabalhando com o J2EE 1.3, uma prática padrão é manipular todo o acesso ao cliente remoto por meio de EJBs de sessão, que manipulam EJBs de entidade na mesma JVM por meio de interfaces de componentes locais.

Modelando Beans de Sessão To top of page

Consulte Diretrizes: Identificando EJBs (Enterprise JavaBeans).

Com Preservação de Estado versus Sem Preservação de EstadoPara o início da página

Há dois tipos de beans de sessão: com preservação de estado e sem preservação de estado. Parte da identificação de um bean de sessão é a definição de suas responsabilidades - uma das quais pode ser manter o estado do cliente entre as chamadas.

Os beans de sessão com preservação de estado contêm informações de estado sobre a conversação entre o cliente e o contêiner EJB. Uma instância de bean de sessão com preservação de estado existe apenas durante a conversação do cliente. Normalmente, esses beans executam os serviços utilizando esses dados para o cliente. Os serviços fornecidos pelo bean de sessão com preservação de estado podem coordenar as interações de outros objetos de negócios (beans de sessão e beans de entidade). Por exemplo, um carrinho de compras contendo objetos para compra pode ser implementado utilizando um bean de sessão com preservação de estado, porque ele retém as informações enquanto o cliente está interagindo com o aplicativo. Como os beans de sessão com preservação de estado são alocados para um cliente específico, eles consomem mais recursos do sistema que um bean de sessão sem preservação de estado, visando a vantagem de reter o estado do cliente. O contêiner gerencia esses recursos, normalmente "passivando" (gravando no disco) os beans de sessão com preservação de estado e reativando-os quando e conforme necessário.

Os beans de sessão sem preservação de estado não contêm informações de estado sobre a conversação entre o cliente e o contêiner EJB. "Sem preservação de estado" significa realmente sem estado da conversação do cliente. Portanto, um bean de sessão sem preservação de estado pode conter outros tipos de estado, como uma conexão com o banco de dados, que pode ser utilizada por qualquer cliente. Esses beans executam serviços genéricos que não utilizam dados do estado do cliente de chamadas de método anteriores, mas em vez disso, recebem toda a entrada apropriada como parâmetros na chamada de método atual ou obtêm os dados de outras origens durante a chamada de método (como de beans de entidade ou acessando um banco de dados por meio do JDBC). Os beans de sessão sem preservação de estado são normalmente desenhados a partir de um conjunto pronto e utilizados para dispatch, conforme necessário, para manipular os pedidos que chegam. Como todas as instâncias são equivalentes, os beans de sessão sem preservação de estado não precisam conhecer seu cliente. Isso pode permitir aumento no desempenho e na escalabilidade. Os beans de sessão sem preservação de estado são mais eficientes porque é possível compartilhar uma instância entre os pedidos não-contíguos, em vez de "ligar" a uma determinada sessão de atividade.

Em geral, escolha o tipo de bean de sessão que mais naturalmente se adapte à conversação com o cliente. Há estratégias para forçar o ajuste de um bean de sessão com preservação de estado em um bean de sessão sem preservação de estado, como armazenar o estado do cliente no cliente e reenviar em cada chamada ou armazenar e recuperar o estado do cliente a partir de um banco de dados em cada chamada de método. Essas estratégias, entretanto, podem realmente reduzir a escalabilidade em razão de códigos extras no tráfego de rede e no acesso a dados.

Se o bean de sessão for criado para implementar um serviço da Web, será necessário utilizar um bean de sessão sem preservação de estado, conforme definido na especificação da API JSR 1.3.

Diferentes abordagens sobre o design do estado do cliente são descritas por Diretrizes: Projetando o Estado para Aplicativos J2EE.

Padrão de Fachada de SessãoPara o início da página

Uma utilização comum dos beans de sessão é como uma fachada que encapsula interações entre os objetos na Camada de Negócios. O bean de sessão serve para resumir essa complexidade, fornecendo uma interface mais simples para os clientes. Esse padrão é descrito detalhadamente em Padrões do J2EE - Padrão de Fachada de Sessão ([ALU01]).

Por exemplo, geralmente é um bom hábito tirar a lógica entre os beans de entidade e mover para os beans de sessão para minimizar o acoplamento entre os beans de entidade. Os beans de entidade podem ser acessados por meio de interfaces locais, uma vez que a fachada do bean de sessão fornece acesso aos clientes remotos. Essa abordagem é mais efetiva quando há vários beans de entidade estreitamente relacionados.

Nó de Extremidade de Serviços da WebPara o início da página

Como vimos anteriormente, os beans de sessão sem preservação de estado podem ser utilizados para implementar serviços da Web. Esse bean também é chamado de Bean de Implementação de Serviço e precisa preencher os requisitos a seguir:

  • Ele deve ter um construtor público padrão.
  • Ele deve implementar todos os métodos declarados pelo Service Endpoint Interface e seu método de negócios deve ser público e não final ou estático.
  • Ele deve ser um bean sem preservação de estado.
  • A classe deve ser pública, mas não final ou abstrata.

Para obter informações adicionais sobre como utilizar os beans de sessão para implementar serviços da Web, consulte as especificações EJB 2.1 e JSR-109.

Rational Unified Process   2003.06.15