Mas a id�ia � utilizar os entity para manuten��o (inclus�o, altera��o e exclus�o), deixando para os sessions a tarefa de consulta....
Eduardo Fabricio Elias Analista de Sistemas - Divis�o de Inform�tica Centro de Integra��o Empresa Escola - CIEE-RS Fone: 51 32847029 http://www.ciee-rs.org.br -----Mensagem original----- De: Giovani Salvador [mailto:[EMAIL PROTECTED]] Enviada em: quarta-feira, 17 de outubro de 2001 7:54 Para: [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Assunto: [java-list] Re:RES: [java-list] D�vida sobre EJBs - Uma considera��o S� tem uma coisa a ser considerada no uso de entity�s para as tabelas. Como um entity cria uma inst�ncia para cada tupla recuperada, imagine um select que traga 5000 registros? -------- Mensagem Original ------------------- Data : Ter 16/10/2001 19:37 De : Eduardo Fabricio Elias <[EMAIL PROTECTED]> Para : '[EMAIL PROTECTED]' <[EMAIL PROTECTED]> Assunto: RES: [java-list] D�vida sobre EJBs � Luiz, Realmente, parece-me que o ideal � utilizar 1 entity para cada tabela, dividindo assim a camada de persist�ncia da camada de regra de neg�cio, que ficaria a cargo dos session bean... Coisa de loco... Assim teria bem definido a interliga��o entre o mundo relacional e objeto. Eduardo Fabricio Elias Analista de Sistemas - Divis�o de Inform�tica Centro de Integra��o Empresa Escola - CIEE-RS Fone: 51 32847029 http://www.ciee-rs.org.br -----Mensagem original----- De: Elcio [mailto:[EMAIL PROTECTED]] Enviada em: s�bado, 13 de outubro de 2001 20:20 Para: [EMAIL PROTECTED] Assunto: Re: [java-list] D�vida sobre EJBs Ol� novamente Luiz, Os EJBs s�o um campo novo para mim tamb�m. Embora n�o tenha, efetivamente, nenhum projeto na �rea, estou fazendo uma bateria de testes utilizando o JBOSS como conteiner, em uma plataforma totalmente open source. Meu interesse e testar os EJBs com Load Balance, ou seja simulanda gramde carga de solicita��es e fazendo a distribui��o do processamento entre duas m�quinas diferentes... � tudo muito facinante, mais confesso que n�o tenho tido tempo necess�rio para fazer tudo que tenho vontade. Agente se fala, t+ Elcio ----- Original Message ----- From: "Luis Cabral" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 09, 2001 7:35 AM Subject: Re: [java-list] D�vida sobre EJBs > Elcio > > Obrigado pela resposta t�o detalhada. > Realmente h� muitos conceitos novos, que at� > consigo entender, mas o que me � dif�cil � vislumbrar > como uma aplica��o real poderia ser estruturada > utilizando EJBs. Ainda h� muito a estudar! > > Para o problema do pedido que citei, a op��o > que devo usar � utilizando JSPs e servlets, sendo > que o processamento mais complexo (valida��es etc) > ficaria dentro do banco Oracle na forma de > Stored Procedures. Para mim, essa � a forma mais > f�cil de implementar e com o melhor desempenho. > > Talvez EJBs n�o sejam a solu��o ideal para tudo? > > Se for poss�vel, vc poderia citar em que tipo de projeto > vc utiliza EJBs, caso os use? > > Obrigado! > Luis Cabral > > ----- Original Message ----- > From: "Elcio Abrah�o" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, October 07, 2001 8:50 PM > Subject: Re: [java-list] D�vida sobre EJBs > > > > Caro Luiz, > > > > Enterprise Java Beans foram criados para facilitar a vida dos > > desenvolvedores de aplica��es distribuidas. A id�ia � que os EJBs sejam > > respons�veis pelo processamento da l�gica de neg�cios em seu sistema > > distribuidos. Os m�todos dos EJBs s�o acessados atrav�s de Conteiners e os > > EJBs podem ser de tr�s tipos: > > > > - Session Bens: podem conter m�todos necess�rios a logica de sua aplica��o > e > > podem ser divididos em beans que geram ou n�o variaveis de sess�o. Os > beans > > que n�o geram vari�vies de sess�o n�o persistem durante a sess�o de um > > usu�rio, ja os que geram vari�veis de sess�o s�o persistentes durente toda > a > > sess�o de um usu�rio. > > > > - Entity Beans: Voc� pode criar para cada tabela de seu Bco de dados um > > Entity Bean. Criar 25 Entity Bens pode ser a princ�pio assustador mais > > haver�o algumas vantagens interessantes, pois o programador pode deixar > por > > conta do Conteiner do Bean a sincroniza��o dos dados com o banco de dados. > > Esse processo � denominado Conteiner Managed Persistence (CMP). Utilizando > > este facilidade o programador n�o tem que mais se preocupar em redigir o > > c�digo que faz a leitura, grava��o de dados no Banco de Dados. Cada > momento > > em que h� uma atualiza��o no Bean esta atualiza��o e sincronizada com o > Bco > > de Dados. H� ainda como continuar fazendo as grava��es e leituras com > nosso > > c�digo utilizando o Beam Managed Persistence, onde n�s mesmo escrevemos os > > m�todos para a sincroniza��o do banco. A utiliza��o de cada maneira � > > definida nos deployments descriptors de cada Bean. > > > > - Message Bens: Muito �teis quando desejamos enviar mensagens acincronas, > os > > seja n�o depende de resposta imediata, como as chamadas de m�todo. > > > > Al�m do mencionado acima os EJBs fornecem as seguintes facilidades: > > > > - Pooling de Objetos: V�rios Beans s�o colocadas em um pooling na mem�ria, > a > > disposi��o dos usu�rios. Quando um bean � requisitado sua refer�ncia � > > passada ao usu�rio, o que aumenta a velocidade de processamento pois o > bean > > j� est� carregado, se todos os beans do pooling j� foram utilizados e h� > > mais uma requisi��o o Conteiner provid�ncia o carregamento de mais uma > c�pia > > do Bean. Terminado o uso os beans voltam para o pooling. > > > > - Gerenciamento das Sess�es dos Usu�rios: O Conteiner � respons�vel pelo > > gerenciamento das vari�veis de se��o de cada usu�rio. Assim se as sess�es > > s�o compartilhadas por varios aplicativos em diverentes m�quinas e locais > o > > Conteiner e respons�vel pela grava��o dos vari�veis de sess�o e por seu > > posteiror reutiliza��o. > > > > - Pooling de Connec��es do Banco de Dados: O Conteiner tamb�m fica com a > > responsabilidade de fazer um pooling de connec��es com o banco de dados. > > Aquilo que muitos de nos implement�mos em nosso c�digo, � feito > > automaticamente pelo Conteiner que mentem um certo n�mero de conec��s > > abertas e as distriui ou fecha conforme a necessidade da aplica��o. > > > > - Gerenciamento de Transa��es: Olha s� que interessante, agora voc� pode > > determinar que determinado m�todo de um Bean � controlado por transa��o, > ou > > seja , quando o m�todo � invocado � automaticamente inicializada um > > Transa��o, que pode ser Commitada no final, ou pode-se feito um roll-Back, > > veja bem um roll-back de um m�todo !!! Isso tudo sem o programado escrever > 1 > > linha de c�digo sequer.... > > > > - Gerenciamento de Seguran�a: EJB podem fazer o controle da seguran�a com > > m�nima codifica��o por parte do programador, tanto autentica��o de > usu�rios > > como checagem de n�vel de acesso. > > > > - Gerenciamento de Persist�ncia: Como eu j� descrevi no Item Entity Beans, > > basta declararmos no deployment descriptor quais as colunas de nosso banco > > SQL desejamos sincronizar que o Container cuida do resto. > > > > Enfim, os EJBs, s�o um pouco mais complexos que voc� deve ter imaginado, > > mais foram uma grande sacada do pessoal da SUN. > > > > Luiz, o que descrevi acima voc� poder� encontrar com mais detalhes no > livro: > > EJB Professional Ed 2001, da Wrox, s�o 1257 pags. > > > > Espero ter ajudado, provavelmente temos outros colegas que possam > contribuir > > mais com suas d�vidas, > > > > Abra�o, > > > > Elcio A. > > > > > > ----- Original Message ----- > > From: Luis Cabral <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Sunday, October 07, 2001 9:44 AM > > Subject: [java-list] D�vida sobre EJBs > > > > > > > Ol� > > > > > > Tenho mais uma d�vida sobre EJBs. > > > (� que eu venho do ambiente cliente-servidor, > > > e tento entender o melhor uso de EJBs > > > comparando com aplica��es "tradicionais"...) > > > > > > Imaginando um sistema cliente-servidor > > > tradicional, em que o usu�rio, por exemplo, > > > informa uma data, e o sistema traz todos os > > > pedidos daquela data. A� o usu�rio pode > > > consultar e alterar o status de cada pedido. > > > E, por fim, ele clica algo e todas as altera��es > > > s�o salvas. > > > > > > Se eu quiser desenvolver um sistema similar > > > utilizando EJBs (n�o importando qual seria o > > > front-end), como funcionaria? No momento > > > da consulta do usu�rio, seriam instanciados > > > "n" Entity Beans, que ficariam bloqueados at� > > > o usu�rio confirmar as altera��es? Ou a forma > > > correta seria inicialmente fazer apenas uma > > > consulta (como se fosse um relat�rio), e quando > > > o usu�rio confirmasse, a� sim seriam criados > > > Entity Beans para os registros modificados > > > para atualizar o banco? > > > > > > Em outras palavras, vejo que Entity Beans � > > > para manipular "linha a linha"... E quando o usu�rio > > > quiser alterar v�rias linhas ao mesmo tempo? > > > > > > Obrigado! > > > Luis Cabral > > > > > > > > > > > > > > > ------------------------------ LISTA > SOUJAVA ---------------------------- > > > http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP > > > d�vidas mais comuns: http://www.soujava.org.br/faq.htm > > > regras da lista: http://www.soujava.org.br/regras.htm > > > para sair da lista: envie email para > [EMAIL PROTECTED] > > > > ------------------------------------------------------------------------- > > > > > > > > > > > > ------------------------------ LISTA SOUJAVA ---------------------------- > > http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP > > d�vidas mais comuns: http://www.soujava.org.br/faq.htm > > regras da lista: http://www.soujava.org.br/regras.htm > > para sair da lista: envie email para [EMAIL PROTECTED] > > ------------------------------------------------------------------------- > > > > > > ------------------------------ LISTA SOUJAVA ---------------------------- > http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP > d�vidas mais comuns: http://www.soujava.org.br/faq.htm > regras da lista: http://www.soujava.org.br/regras.htm > para sair da lista: envie email para [EMAIL PROTECTED] > ------------------------------------------------------------------------- > > ------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP d�vidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm para sair da lista: envie email para [EMAIL PROTECTED] ------------------------------------------------------------------------- ------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP d�vidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm para sair da lista: envie email para [EMAIL PROTECTED] ------------------------------------------------------------------------- ************************************************** Giovani Salvador http://pagina.de/siglas (Siglas de inform�tica) PROCERGS - Cia. de Processamento de Dados do Estado do Rio Grande do Sul Setor TSI - Tecnologia para Sistemas de Informa��o ICQ #44904309 ************************************************** ������ ------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usu�rios Java da Sucesu-SP d�vidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm para sair da lista: envie email para [EMAIL PROTECTED] -------------------------------------------------------------------------
