Re: [reverbel-sma] Dúvidas

["Ivan Neto" <ivanneto@xxxxxxxxx>]

Olá Rafael.

Estou respondendo para a lista, pois acho que sua intenção era
responder para lá, não era?

On 8/14/06, Rafael de F. Ferreira <rafael@xxxxxxxxxxxxxxxxxx> wrote:
> Oi Ivan.
>
> On 8/14/06, Ivan Neto <ivanneto@xxxxxxxxx> wrote:
> > Olá Rafael.
> >
> > Eu posso ter dito alguma bobagem na resposta da sua pergunta sobre
> > EJB. Se perceber algo, por favor volte a escrever.
>
> Você respondeu bem o que eu queria saber. Peço desculpas se não fui
> muito claro na pergunta.
Sua pergunta estava clara sim. Eu estou meio "enferrujado" nesse
assunto de EJB, por isso disse que talvez tenha dito alguma besteira
:-).

> Então os beans stateless na verdade só não mantém estado de sessão com
> o cliente, mas tem permissão para manter um estado de instância. O
> único caso de uso que eu consigo imaginar para isso é fazer um cache
> meia-boca de alguma computação mais cara. Meia-boca porque o escopo de
> um cache desses seria limitado a somente uma instância da
> implementação. Devem existir outros casos de uso que eu não
> considerei, alguém tem sugestões?
Exatamente. Cada instância de bean de sessão sem estado pode ter um
"estado" nas suas variáveis de instância. Mas como o cliente não sabe
exatamente qual instância vai tratar a requisição dele, ele não pode
confiar no valor dessas variáveis de instância. Portanto, para o
cliente é como se o bean fosse sem estado.

As variáveis de instância de um bean sem estado podem ser úteis no
caso em que vários métodos do bean acessam essa variável de instância.
Se esses métodos fazem chamadas entre si, as variáveis de instância
evitam que se fique passando um monte de argumentos, já que os dados
podem ser acessados pela classe a partir das variáveis de instância.

Eu acho que a especificação EJB permite variáveis de instância em
beans sem estado para não limitar muito o programador. Acho que a
idéia é mais ou menos a seguinte: o programador escreve a classe dele
seguindo um mínimo possível de regras (por exemplo, sem utilizar a
palavra-chave synchronized), e o container cuida do resto
(concorrência, segurança, transações, etc). Se por um acaso o
programador achar conveniente ter uma variável de instância no bean,
ele pode ter, e não precisa sem preocupar com acessos concorrentes: o
container faz isso por ele.

> Se os beans fossem obrigados a serem totalmente desprovidos de estado,
> então eu acredito que não haveria problemas de concorrência, uma vez
> que não haveria nenhum dado compartilhado para sincronizar. Nesse caso
> eu acho que não seria preciso fazer pooling dos objetos - uma
> instância seria suficiente.
Sim, concordo com você, uma instância seria suficiente. Eu acho que
isso não ocorre no EJB porque nesse caso o programador teria que se
preocupar em escrever código capaz de lidar com acessos concorrentes.

> Legal. Abusando um pouco (já que a biblioteca não tem uma cópia do
> livro do Alonso), você tem idéia de quando eles apareceram? Só
> pergunto por curiosidade mesmo.
O livro do Alonso não menciona quando eles apareceram. Mas achei esse
site (as informações parecem ser confiáveis):

http://www.sei.cmu.edu/str/descriptions/momt.html

Lá diz: "Implementations of MOM first became available in the
mid-to-late 1980s."

Sobre o livro do Alonso, em breve deve haver uma parte do livro
disponível no xerox do CAMAT. Aliás, o livro é bem interessante. Ele
fala da evolução dos distemas de informações distribuídas desde o
começo (mainframes com terminais burros), passando pelos middlewares
RPC, monitores de TP, Object Brokers, MOM, etc, até middlewares de EAI
(Enterprise Application Integration) e web services. É uma leitura
"light" e interessante.

> >
> > Espero ter ajudado.
> >
> > []'s
> >
> > --
> > Ivan Neto
> >
>
> Muito obrigado
> []'s
> --
> Rafael de F. Ferreira.


--
Ivan Neto