PessoALL, A URL a segir cont�m alguns patterns que s�o utilizados no PetStore. O pattern Value List Handler tamb�m � conhecido como Paga-by-Page Iterator.
http://java.sun.com/blueprints/patterns/j2ee_patterns/catalog.html A pr�xima URL cont�m todos os patterns "oficiais" J2EE, que s�o bem descritos no livro "Core J2EE Patterns". ISBN: 0-13-064884-1 http://developer.java.sun.com/developer/restricted/patterns/J2EEPatternsAtAG lance.html Abra�os, Jeferson Alexander Alexandre G. L. Fernandes writes: > Sven van �t Veer wrote: >> >> Na verdade seu caso � um caso tipico do pattern Value List Handler. D� >> uma olhada na site da sun. > Oi, Sven, eu n�o conhe�o este pattern, e tamb�m n�o o encontrei no site da sun... >Tem certeza de que � este nome mesmo? > >> >> No seu caso utiliza��o de EJB � a op��o certa, somente acho que n�o >> deveriam ser EntityBeans, a n�io ser que cada find devolve somente >> poucas entities. Os ejb�s nem precisam ser distribuido, podem ficar em >> uma maquina so, basta vc criar um outro connection pool. > Pelo que tinha entendido do problema proposto, trata-se de consultas read-only, como >de fato a Alessandra confirmou num email mais recente. Isso pra mim descarta a >possibilidade de EntityBean, e tamb�m elimina a necessidade de usar bibliotecas XA. >Se vc n�o vai escrever nada, n�o precisa controlar a transa��o distribu�da. > Ah, e finalmente, se n�o for pra distribuir, a� � que n�o precisa de EJB mesmo!!!! > > Mas Alessandra, agora que vc disse que trata-se de um projeto pra faculdade faz mais >sentido sua necessidade de usar ejb. O que vc quer saber � como fazer um EJB disparar >v�rios processos de consulta paralelos e ficar esperando todos os resultados voltarem >pra process�-los e mandar uma resposta para quem o chamou. Se n�o me engano, foi >exatamente o que vc escreveu no primeiro email, mas o processo de entendimento do >problema nem sempre � linear... :) > > Resposta: n�o sei. N�o sei fazer isso sem usar threads, e como ejb n�o pode disparar >threads, ent�o eu o "tirei fora da jogada". Talvez com message driven beans seja >poss�vel criar um esquema do tipo bulletin board, em que vc pendura requisi��es em >uma lista e um processo (que n�o � um ejb! :) ) fica respons�vel por chamar os >objetos respons�veis por solucionar cada um deles (acho que tem um pattern pra isso). >Mas n�o sei como eu faria pra deixar o ejb "esperando", nem como fazer o call back >(message driven beans resolve isso?). Talvez usar beans stateless e vc mesma >controlar um contexto, ao qual diferentes inst�ncias do bean teriam acesso... > > Hoje, pra um projeto real que tivesse uma arquitetura semelhante � que vc est� >propondo, talvez eu optasse por usar classes normais como providers de cada banco, >disparadas em diferentes threads por um proxy que tamb�m seria uma classe n�o ejb, >RMI pra distribuir estes providers e o pool do jdbc. N�o seria uma maravilha da >implementa��o, mas com certeza funcionaria a contento! :) > > Por �ltimo, quanto � usar o esquema proposto pelo �lvaro, Session beans acessando >persist�ncia implementada com DAO's, (que considero a melhor arquitetura para >sistemas mais robustos) isso eliminaria a possibilidade de usar threads. Da� vc teria >que implementar com message driven beans mesmo. > > � isso a�! Lamento n�o poder ajudar mais. > []'s > Alexandre > (com participa��o especial do Marcelo Vessoni) > > --------------------------------------------------------------------- > Para cancelar a subscri��o, envie mensagem para: >[EMAIL PROTECTED] > Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED] > ___________________________________________________________________________ Jeferson Alexander _/_/_/ _/ _/ _/ _/ PS Consultant _/ _/ _/ _/_/ _/ Professional Services _/_/_/ _/ _/ _/ _/ _/ SUN MICROSYSTEMS DO BRASIL - BSB _/ _/ _/ _/ _/_/ Tel: +55 61 99887769 _/_/_/ _/_/_/ _/ _/ e-mail: [EMAIL PROTECTED] M I C R O S Y S T E M S http://www.sun.com.br ___________________________________________________________________________ --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
