- o mesmo consta na camada "Business"
- � uma classe que utiliza o Pattern Singleton, portanto, uma �nica
inst�ncia da mesma existir� na mem�ria da JVM do container para toda a
aplica��o. Economia de recursos, n�?!
- possui um m�todo getHome() que devolve um obj EJBHome. (at� a� voc�s j�
conhecem)
- Nesse caso, valeria a pena ter um m�todo getLocalHome() para devolver um
objeto EJBLocalHome? Ou o lookup feito dentro do container � algo muito
r�pido e essa preocupa��o n�o teria sentido?
EJB Design Patterns (Marinescu - Pag 92)
--------------------------------------------------------------------------
- o mesmo consta na camada "Client" com o nome de EJBHomeFactory
- Bem parecido com o existente no "Core J2EE Patterns", muda um pouco a
implementa��o interna, mas � bem id�ntico.
Perguntas:
--------------------------------------------------------------------------
1) Pelo que li, estes patterns tratam o "client" como um "client web", ou
seja, em todos os casos o "client" est� "rodando" dentro do Web Container,
que por sua vez est� na mesma JVM que o EJB Container. (isso � verdade para
todos os App Servers?).
- N�o necessariamente. O Web pode (deve) rodar numa maquina no DMZ e o EJB
deve rodar atras do firewall em, logicalmente, duas maquinas separados.
2) Esses patterns est�o corretos ou n�o existe um "certo ou errado" para
cada um deles? Achei 03 formas de se implementar a mesma coisa e constando
com o mesmo nome!!! Isso � mesmo um Pattern?
-- � sim. O da Sun eu acho mei ridiculo. o singleton do marinescu e alur � a
mesma coisa mas depende de como vc separa a camada de negocios da camada
web. o meu componente sempre tem uma classe commun de java com os mesmos
metodos de negocio que os facades e delegates. este classe utiliza o
servicelocator.
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.
--------------------------------------------------------------------------
Agrade�o novamente a aten��o de todos e espero poder em breve colaborar com
alguma coisa nas discuss�es dessa lista.
Forte abra�o a todos.
Zanata
---------------------------------------------------------------------
Para cancelar a subscri��o, envie mensagem para:
[EMAIL PROTECTED]
Para comandos adicionais, envie mensagem para:
[EMAIL PROTECTED]
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.377 / Virus Database: 211 - Release Date: 15/7/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.377 / Virus Database: 211 - Release Date: 15/7/2002
---------------------------------------------------------------------
Para cancelar a subscri��o, envie mensagem para:
[EMAIL PROTECTED]
Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
