Mas entenda, talvez eu n�o tenha me expressado direito ou falei bobagem
mesmo. :)
- Eu teria uma �nica inst�ncia do ServiceLocator (sigleton) no meu EJB
Container.
- O meu SessionBean Stateless (EJBLocator) faria acesso ao ServiceLocator
e "pegaria" essa Home se ela j� estivesse no "cache" do ServiceLocator.
- Como o Stateless n�o mant�m estado e tamb�m n�o "amarra" uma refer�ncia
ao client (o contexto mascara isso), eu n�o teria que me preocupar com
a "passiva��o" do mesmo.
Exemplo (c�digo grosseiro):
public class EJBLocator implements javax.ejb.SessionBean {
...
public javax.ejb.EJBHome getHome(String jndiName) {
MeuServiceLocator sl = MeuServiceLocator.getInstance();
return sl.getHome(jndiName);
}
...
}
� isso mesmo?
[]s
Zanata
>
> 3) Suponha que eu tenha um "Client Swing" que precisa enxergar alguns
> SessionBeans. O correto seria ter um ServiceLocator no lado "Client"?
> ve aqui em cima. compilando a minha classe no app swing, n�o tenho
> acouplamento direto do app para os ejb.
>
> Tive uma id�ia para substituir esse ServiceLocator que seria instanciado
no
> lado Client mas n�o sei se � a mais correta e gostaria de discutir com
> voc�s esse caso. A estrat�gia seria a seguinte:
>
> - Implemento um ServiceLocator que ser� instanciado apenas na JVM do EJB
> Container
> -- N�o � valido. Vc precisa passar os homes para o seu controller (mvc)
ver
> a resposta de 2.
>
> - Implemento um SessionBean Stateless (vamos cham�-lo de EJBLocator) que
> ter� um m�todo getHome() e esse por sua vez far� acesso ao ServiceLocator
> que j� est� instanciado no meu EJB Container
> -- E ae, qual o ganho ??? no caso a unica diferenca � que somente precisa
> codificar uma unica vez. mas na hora de passifica��o ele poderia perder a
> referencia.
>
>
> - O meu client swing faria apenas um lookup/narrow inicial para o
EJBLocator
> - Da� em diante, quando o client precisasse de algum Session/Entity, faria
> a chamada ao getHome() atrav�s do objeto remoto do EJBLocator e receberia
> um obj. EJBHome.
> -- E uma solu��o.
>
> Minha motiva��o foi a de manter apenas um ServiceLocator para toda a
> aplica��o (lados: client e server). O fato de querer utilizar um
> SessionBean Stateless, foi o de reduzir o n�mero de inst�ncias do
> EJBLocator no EJB Container, pois com isso eu consigo minimizar a
> utiliza��o de recursos (supondo que eu tivesse v�rios clients em
> funcionamento e muitas chamadas para EJBs em cada um desses clients).
>
> -- s� que vc n�o sabe a quantidade de servicelocators instanciados...
>
> � correto chamar um SessionBean Stateless do Client Remoto?
>
> Sim
>
> O que voc�s acham? Se n�o deu para entender alguma coisa do que disse,
pe�o
> que questionem novamente, pois eu n�o pesquisei o assunto com
profundidade.
>
>
---------------------------------------------------------------------
Para cancelar a subscri��o, envie mensagem para:
[EMAIL PROTECTED]
Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
