Gente, N�o quis causar pol�mica e pe�o desculpas novamente.
Fiz minha inscri��o na lista a poucos dias e nem tive tempo de ver o hist�rico das mensagens, talvez minhas perguntas j� tivessem sido respondidas e eu nem fui atr�s disso. Por isso achei que estaria causando algum transtorno para esta comunidade. N�o me incomodei com os coment�rios e agrade�o muito ao Sven e a todos os amigos pelos esclarecimentos, s� achei que eu estava falando demais (como estou fazendo agora :] ). J� que posso ficar, ag�entem mais um pouco. Mas mantenham a calma, OK?! :) Agora estou com uma d�vida em rela��o ao pattern "Service Locator". Na Apostila da Sun (J2EE Patterns, SL-500, Volume 1, p�g. 12-69) ---------------------------------------------------------------- - Aparece um Service Locator (EJBServiceLocator) que � um SessionBean Stateful e cont�m um m�todo getHomeObject() que devolve ao Client a Home do EJB solicitado atrav�s do nome contido na JNDI. � isso mesmo pessoal, o treco consta como um SessionBean Stateful, sendo assim, cada cliente manteria um Session desses "levantado" na mem�ria da JVM do container. Correto? - o mesmo consta na camada "Business" - achei essa abordagem muito estranha. No Core J2EE Patterns (Alur et Al. - p�g 328 - Edi��o Brasileira - Ed Campus) ------------------------------------------------------------------------- - 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?). 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? 3) Suponha que eu tenha um "Client Swing" que precisa enxergar alguns SessionBeans. O correto seria ter um ServiceLocator no lado "Client"? 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 - 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 - 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. 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). � correto chamar um SessionBean Stateless do Client Remoto? 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]
