Médio.
[quote=luiz_ross]
Uma pergunta, que tipo de sistema é esse, no qual vc´s querem utilizar EJB´s, é grande, pequeno, médio porte?[/quote]-
foi apenas um exemplo de OBJETO COMPLEXO que seria complicado para passar via WebServices… pode ser um objeto complexo de qualquer outra natureza… e sinceramente ? estou exemplificando… nao precisa levar ao PEH DA LETRA… apenas entender o principio …
-
Cara… vc entendeu o q eu quiz diser com RMI , O RMI BASICAO… que todo mundo dah exemplo… fazer um servidor RMI de um lado e um cliente acessando os objetos do outro… EH CLARO QUE RMI eh protocolo… soh foi um exemplo… po… vamo faze uma forcinha pra entender…
-
gostei da sua sugestao… entao pra vc seria:
CLIENT->SESSION->HIBERNATE->DB ? certo ?
[quote=pcalcado]
Se você retornar resultset para os clientes da sua aplicação, você não rpecisa de um servidor, faça todo mundo se conectar ao banco de dados.
O que ele qis dizer: camadas, camadas, camadas, camadas.
Claro que RMI não tem pooling, ele é um protocolo, não um container, por isso EJB (e outros) implementam pools em cima de RMI. Se você vai fazer algo MUUUUUUUIIITO simples, pode tentar implementar um pool de serviços, mas se for assim é melhor usar stateless beans.
Pois é, esse é o caso com EJBs também, na maioria das vezes.
Eu não posso dizer sua melhor opção, só posso te mostrar alternativas, quem conhece o problema é você. A questão é: o que você disse sobre HTTP e sessões não procede, em minha opinião. HTTP tem milhares d eproblemas, mas não esses.
Não improta se voc~e está usando Session Beans ou não, se você tem uma aplicação complexa e msitura código de dados com lógica de negócios, vai ter problemas.
A impressão que tenho é que seus EJBs vão 9nesse caso) ter a lógica e o acesso ao banco. Vou repetir:
- Coloque sua lógica num Domain Model de POJOs
- Separe o acesso á banco de dados em uma camada própria.
Estrutura razoável:
Cliente <-> Session Beans <-> POJOs do Domain Model<-> Camada de Dados[/quote]
[quote=chun]1) foi apenas um exemplo de OBJETO COMPLEXO que seria complicado para passar via WebServices… pode ser um objeto complexo de qualquer outra natureza… e sinceramente ? estou exemplificando… nao precisa levar ao PEH DA LETRA… apenas entender o principio …
- Cara… vc entendeu o q eu quiz diser com RMI , O RMI BASICAO… que todo mundo dah exemplo… fazer um servidor RMI de um lado e um cliente acessando os objetos do outro… EH CLARO QUE RMI eh protocolo… soh foi um exemplo… po… vamo faze uma forcinha pra entender…
[/quote]
Não levei ao pé da letra, só respondi o que você falou. Minha sugestão final é:
1 - Estude RMI melhor para você entender o “BASICAO” e um pool (pool de que? Skeletons? Stubs? Afinal, esse não é RMI basicão?)
2 - Estude sistemas distribuidos melhor, objetos complexos passados numa rede têm limitações em qualquer tecnologia usada (mesmo EJBs), se não não existiria DTO.
3 - Seja menos arrogante e prepotente, esse não é um bom meio de obter ajuda, pelo menos não de mim
Não. O que falei foi onde você pode entrar com EJBs stateless, no seu esquema falta uma camada de negócios.
[quote=chun]1) foi apenas um exemplo de OBJETO COMPLEXO que seria complicado para passar via WebServices… pode ser um objeto complexo de qualquer outra natureza… e sinceramente ? estou exemplificando… nao precisa levar ao PEH DA LETRA… apenas entender o principio …
-
Cara… vc entendeu o q eu quiz diser com RMI , O RMI BASICAO… que todo mundo dah exemplo… fazer um servidor RMI de um lado e um cliente acessando os objetos do outro… EH CLARO QUE RMI eh protocolo… soh foi um exemplo… po… vamo faze uma forcinha pra entender…
-
gostei da sua sugestao… entao pra vc seria:
CLIENT->SESSION->HIBERNATE->DB ? certo ?
[/quote]
1)SOAP é suficiente para mandar objetos extremamente complexos. Os casos onde ele falha é quando os objetos não deveriam ser enviados via rede. Se o seu exemplo era meramente ilustrativo, sem relação com uso real, de nada ele vale e seu argumento não parece válido.
2)Você teria que implementar pooling manualmente, caso seja necessario. A priore, o rmid vai sofrer o mesmo load que um container EJB, já que não existe como diminuir o número de conexões cliente.
3)Não, o sugerido seria: CLIENT<-> SESSION FACADE <-> DOMAIN MODEL <-> HIBERNATE.
-
até agora vc soh falou e nao respondeu a pergunta… se eu acessar o mesmo metodo de um mesmo objeto num servidor que esteja servindo objetos via RMI ( usando Naming.rebind ) , o q vai acontecer ?
-
voce que esta arrogante ENTENDENDO o q eu quis dizer e querendo falar besteira… querendo aparecer perante aos outros… invez de responder vc quer discutir ateh o minimo detalhe… depois eu que sou arrogante ?
[quote=pcalcado][quote=chun]1) foi apenas um exemplo de OBJETO COMPLEXO que seria complicado para passar via WebServices… pode ser um objeto complexo de qualquer outra natureza… e sinceramente ? estou exemplificando… nao precisa levar ao PEH DA LETRA… apenas entender o principio …
- Cara… vc entendeu o q eu quiz diser com RMI , O RMI BASICAO… que todo mundo dah exemplo… fazer um servidor RMI de um lado e um cliente acessando os objetos do outro… EH CLARO QUE RMI eh protocolo… soh foi um exemplo… po… vamo faze uma forcinha pra entender…
[/quote]
Não levei ao pé da letra, só respondi o que você falou. Minha sugestão final é:
1 - Estude RMI melhor para você entender o “BASICAO” e um pool (pool de que? Skeletons? Stubs? Afinal, esse não é RMI basicão?)
2 - Estude sistemas distribuidos melhor, objetos complexos passados numa rede têm limitações em qualquer tecnologia usada (mesmo EJBs), se não não existiria DTO.
3 - Seja menos arrogante e prepotente, esse não é um bom meio de obter ajuda, pelo menos não de mim
Não. O que falei foi onde você pode entrar com EJBs stateless, no seu esquema falta uma camada de negócios.[/quote]
- me diz uma coisa… prq desperdicar DIAS e até MESES fazendo isso manualmente se jah existe algo pronto ? existiria ganho em implementar tudo na mao ? ( acredite , jah pensei em fazer isso )
[quote=louds][quote=chun]1) foi apenas um exemplo de OBJETO COMPLEXO que seria complicado para passar via WebServices… pode ser um objeto complexo de qualquer outra natureza… e sinceramente ? estou exemplificando… nao precisa levar ao PEH DA LETRA… apenas entender o principio …
-
Cara… vc entendeu o q eu quiz diser com RMI , O RMI BASICAO… que todo mundo dah exemplo… fazer um servidor RMI de um lado e um cliente acessando os objetos do outro… EH CLARO QUE RMI eh protocolo… soh foi um exemplo… po… vamo faze uma forcinha pra entender…
-
gostei da sua sugestao… entao pra vc seria:
CLIENT->SESSION->HIBERNATE->DB ? certo ?
[/quote]
1)SOAP é suficiente para mandar objetos extremamente complexos. Os casos onde ele falha é quando os objetos não deveriam ser enviados via rede. Se o seu exemplo era meramente ilustrativo, sem relação com uso real, de nada ele vale e seu argumento não parece válido.
2)Você teria que implementar pooling manualmente, caso seja necessario. A priore, o rmid vai sofrer o mesmo load que um container EJB, já que não existe como diminuir o número de conexões cliente.
3)Não, o sugerido seria: CLIENT<-> SESSION FACADE <-> DOMAIN MODEL <-> HIBERNATE.
[/quote]
Pelo seu histórico nesse fórum, pode ficar tranquilo que não vou responder mais a esta thread.
Boa sorte com seu sistema.
Otimo , de pessoas como vc, eu dispenso as opinioes, bem prq nao levao a lugar nenhum… ficar discutindo “prq RMI eh protocolo , e bla bla bla” , por favor…
[quote=pcalcado][quote=chun]
3) voce que esta arrogante ENTENDENDO o q eu quis dizer e querendo falar besteira… querendo aparecer perante aos outros… invez de responder vc quer discutir ateh o minimo detalhe… depois eu que sou arrogante ?
[/quote]
Pelo seu histórico nesse fórum, pode ficar tranquilo que não vou responder mais a esta thread.
Boa sorte com seu sistema.[/quote]
Qual a sua preocupação? Concorrência ou Escalabilidade?
[]'s
Marco Campêlo
Mais concorrencia…
eh um pepino acessarem o mesmo objeto e o mesmo metodo ao mesmo tempo… pra mim vai ser normal…
Qual a sua preocupação? Concorrência ou Escalabilidade?
[]'s
Marco Campêlo[/quote]
[quote=chun]2) me diz uma coisa… prq desperdicar DIAS e até MESES fazendo isso manualmente se jah existe algo pronto ? existiria ganho em implementar tudo na mao ? ( acredite , jah pensei em fazer isso )
[/quote]
Bom, pooling de Session Beans é mais uma balela de publicidade que algo de utilidade prática. Um SLSB vai realmente precisar de pooling caso ele tenha inicialização complexa. Os containers fazem pooling porque associam um monte de coisa a eles.
Soluções de pooling existem hoje e implementar um servidor RMI usando apenas o spring framework pode ser mais simples que parece. Ahh, esqueci, nada de open source.
Pode existir algum ganho de performance caso sua aplicação não use todos recursos do container. No seu caso acho melhor ir pela opção mais segura, use session beans.
Outra coisa, eu concordo com o phillip que você deve tentar ser mais acessivel quando ler e responder aos demais. Como você que está apresentando a dúvida, ele não tem como assumir que a parte que você omitiu, a mais importante, tinha ficado clara. Que é a falta de uma camada de negocios em todas as alternativas que você apresentou.
[quote=chun]Mais concorrencia…
eh um pepino acessarem o mesmo objeto e o mesmo metodo ao mesmo tempo… pra mim vai ser normal…[/quote]
Não entendi muito bem sua preocupação pois entendo que o RMI será utilizado apenas no transporte e questões como concorrência independem de você estar utilizando RMI ou qualquer outra tecnologia de aplicações distribuídas.
Você pode ter problemas de concorrência até em Servlets, se você botar a variável errada no lugar errado! 
[]'s
Marco Campêlo
quando digo RMI , quero dizer “Disponibilizar abjetos via Named.rebind() usando o protocolo RMI sob IIOP/JRMP”
[quote=mcampelo][quote=chun]Mais concorrencia…
eh um pepino acessarem o mesmo objeto e o mesmo metodo ao mesmo tempo… pra mim vai ser normal…[/quote]
Não entendi muito bem sua preocupação pois entendo que o RMI será utilizado apenas no transporte e questões como concorrência independem de você estar utilizando RMI ou qualquer outra tecnologia de aplicações distribuídas.
Você pode ter problemas de concorrência até em Servlets, se você botar a variável errada no lugar errado!
[]'s
Marco Campêlo[/quote]
Essa parte eu entendi!
Mas continuo achando que o problema de concorrência não é relacionado a RMI, EJB, Servlets, etc.
Se você tem um Session Façade que chama a regra de negócio da sua aplicação que está escrita em POJOs (ou seja, não estamos mais falando de EJB), dependendo de como você estruturou essas suas classes (de regras de negócio), você pode vir a ter problemas de concorrência. E aí cairíamos num caso onde mesmo tendo EJB no meio do caminho, o problema de concorrência ainda acontece.
[]'s
Marco Campêlo
O grande problema de RMI puro, como você colocou na thread, é que você vai ter que lidar com o ambiente multi-threaded, o que não significa necessariamente perder performance ou funcionalidade; isso depende do resto da sua arquitetura.
Mas, sendo bem prático, se seu problema é não poder usar open-source e somente padrões, recomendo Session Beans + JDO.
EXATO !!!
Session beans + SQL DIRETO VIA JDBC vc consideraria insanidade ?
[quote=mister__m]O grande problema de RMI puro, como você colocou na thread, é que você vai ter que lidar com o ambiente multi-threaded, o que não significa necessariamente perder performance ou funcionalidade; isso depende do resto da sua arquitetura.
Mas, sendo bem prático, se seu problema é não poder usar open-source e somente padrões, recomendo Session Beans + JDO.[/quote]
Nao, nenhum, pra falar a verdade. A discussao acabou indo pra um lado nao muito produtivo, mas se vc quer se livrar de problemas de escalabilidade e concorrencia, Session Beans sao bacanas…
…mas… (sempre tem um “mas…”)
Se voce nao tomar cuidado e prestar atencao no que esta fazendo, o seu sistema acaba ficando dependente dos Session Beans, e isso acaba arrastando o application server junto, o que te dificulta demais fazer testes unitarios. Dai a qualidade do codigo e a produtividade da sua equipe apontam pro chao e ligam o afterburner. Entao, nao exagere, faca dentro dos Session Beans apenas o estritamente necessario, e boa sorte.
E tente ouvir mais os conselhos de caras como o Shoes, que estao hoje em dia tendo que limpar a merda que arquitetos meia-boca fizeram por nao prestar atencao a esse tipo de discussao.
Shun
Este tipo de colação é uma verdadeira sacanagem hein! Por curiosidade olhei seu histórico, e esta mesma história se repetiu … mas com palavras diferentes.
Tente não levar a mau, mas é um tipo de coisa que deixaria qualquer um aqui com os nervos a flor da pele. Procure minimizar estes tipos de colocões quando você não concordar com uma opinião contrária ou diferente da sua.
Abraços e Boa Sorte!
Thiago
Se não estivermos falando de 3 tabelas e uma dúzia de consultas além do CRUD, sim 
[quote=cv]Se voce nao tomar cuidado e prestar atencao no que esta fazendo, o seu sistema acaba ficando dependente dos Session Beans, e isso acaba arrastando o application server junto, o que te dificulta demais fazer testes unitarios. Dai a qualidade do codigo e a produtividade da sua equipe apontam pro chao e ligam o afterburner. Entao, nao exagere, faca dentro dos Session Beans apenas o estritamente necessario, e boa sorte.
[/quote]
Pois é, essencial dizer isso também 
Fui “cegado” pela restrição absurda de não usar open-source e não comentei sobre coisas do tipo.