Re: [reverbel-sma] Dúvidas

["Ivan Neto" <ivanneto@xxxxxxxxx>]

Olá Rafael.

Eu posso ter dito alguma bobagem na resposta da sua pergunta sobre
EJB. Se perceber algo, por favor volte a escrever.

> Já que eles não tem estado (e são proibidos de acessar membros estáticos mutáveis,
> IIRC), eles não são necessariamente reentrantes? Nesse caso, para que ter mais de
> uma instância em memória?
Um trecho relacionado a sua pergunta do livro Enterprise Java Beans,
4a edição (O'Reilly):
"Session beans can never be reentrant, and they throw a
RemoteException if a loopback is attempted."

Dois trechos relacionados a sua pergunta da especificação EJB 3.0 (core):
"The container serializes calls to each session bean instance. Most
containers will support many instances of a session bean executing
concurrently; however, each instance sees only a serialized sequence
of method calls. Therefore, a session bean does not have to be coded
as reentrant."
"Note that a session object is intended to support only a single
client. Therefore, it would be an application error if two clients
attempted to invoke the same session object. One implication of this
rule is that an application cannot make loopback calls to a session
bean instance."

Portanto, a espeficação EJB proíbe que beans de sessão (com ou sem
estado) sejam reentrantes. Eu acredito que isso ocorra para facilitar
a vida do programador EJB. Com essa restrição, o programador pode
escrever um bean de sessão sem se preocupar com concorrência. Se os
beans de sessão pudessem ser reentrantes, o programador teria que
lidar com todos os problemas de concorrência. Isso porque o container
não tem como distinguir uma chamada reentrante de uma chamada normal.
Portanto, se o container permitir chamadas reentrantes, ele
automaticamente estará permitindo acesso concorrente ao bean. Com
isso, a responsabilidade de controlar acessos concorrentes seria
delegada ao programador.

Quanto as várias instâncias em memória, eu vejo pelo menos um motivo
para isso. Beans de sessão sem estado não mantém nenhum estado entre
invocações, mas eles podem conter variáveis de instância como qualquer
outra classe Java. Se todas as chamadas fossem delegadas para uma
mesma instância, poderíamos ter acessos concorrentes às variáveis de
instância, que poderiam resultar em problemas. Para evitar isso, o
container EJB faz a seriação de todas as chamadas a um bean de sessão,
e portanto o bean atende a uma chamada de cada vez. Mas muitos
containers permitem a execução de múltiplas instâncias de beans de
sessão em paralelo, permitindo portanto o atendimento de várias
requisições simultaneamente.

> Fiquei curioso sobre como os sistemas de Message Oriented Middleware
> entram na história.
Segundo o livro do Alonso, os Message Oriented Middleware (MOM) são
descendentes diretos dos "queuing systems" encontrados nos monitores
de TP. Nos monitores de TP, os "queuing systems" eram utilizados para
implementar sistemas de processamento em lote ("batch"). Conforme
monitores de TP foram sendo utilizados para integrar um número cada
vez maior de sistemas, ficou claro que era melhor fazer isso através
de interações assíncronas do que utilizando RPC. Com isso, os "queuing
systems" dos monitores de TP ganharam importância, e finalmente se
tornaram sistemas independentes. Esses sistemas independentes são os
MOMs.

Espero ter ajudado.

[]'s

--
Ivan Neto