Tecnologias a Utilizar....

Alguns" Intel® Xeon? ... com 2 GB de memoria ...

Hum...2GB de memória pode ser insuficiente para muuitas aplicações, mas creio q um call center não precise de muita coisa.
As máquinas jah foram escolhidas?(compradas?)Se não, recomendaria um "brainstorming" das necessidades do call center(entre acesso á dados,processamento,paralelismo e etc.)Na maioria das vezes, uma solução usando Opteron sai bem mais barato e com desempenho igual.(até mesmo superior).

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Rapaz, eu soh vejo a galera escaldar EJB, alguem defende a utilizacao ?

Sim, os EJBS são úteis quando você quiser obrigar o seu chefe a comprar uma máquina mais possante para você!!! Caso ele não faça isso, a empresa provavelmente vai atrasar o projeto, ai isso fica como uma vinagança sua!

Meu digo por experiência prórpria... estou sendo obrigado a usar EJB! É uma bosta. Muito burocracia, muita linguiça.

Se você for obrigado a usar EJB, por favor, antes de uma olhada no Spring Framework ou Pico Container.... por favor!!!

Abraços!
Thiago senna

This message was edited 1 time. Last update was at 13/04/2005 09:24:31

Acho que ejb, em cenarios especificos podem ser bastante uteis.
ja utilizei session como facades, e cmp na persistencia. tem pros e contras.
se vc vai ter realmente um ambiente distribuido, ejb são a melhor opção.
utilizar session beans acho uma boa. entitys se for usar use cmp, se vc não precise de consultas complexas, pois os recursos do ejb-ql ainda deixam a desejar. mas tenha consciencia que é uma tecnologia complexa, e seria bom que ja tivesse alguem experiente na equipe.

[]'s

Olá

Fabrício Cozer Martins wrote:Rapaz, eu soh vejo a galera escaldar EJB, alguem defende a utilizacao ?

O Louds defendeu! EJBs são ótimos, grande idéia e tudo o mais. Mas o que o Vitor levantou a bola e o Louds cabeceou para o gol com comemoração de cambalhota junto com o mister_m e o João Bier, são as grandes dicas para se usar EJBs:

1. Evite EJbs (o Vitor não disse para não usar), NUNCA use só para aprender.
2. Caso a arquitetura do sistema(*) precise das características para os quais EJBs foram criados então use-os com sabedoria e moderação.
3. Como o Louds disse, evite EntityBeans (o Louds não disse para não usar). O João disse que caso use adote CMP e eu concordo plenamente.
4. Examine com atenção se seu sistema(*) será realmente distribuído. Caso a resposta seja positiva então não tem jeito e será realmente necessário usar interfaces remotas (argh...) a custa de enorme perda de desempenho. Neste caso estes XEONSzinhos com este tantinho de memória podem virar maquininhas. Aliás, assim como o Iron, também acho estas máquinas fracas mesmo que a carga prevista fosse menor do que vc disse.
5. Dica de ouro do Louds: usar MDBs que é o lado do bem dos EJBs

(*) Quem deve impor a arquitetura do sistema são as especificações do negócio e não quem escolhe a tecnologia. Por exemplo: nenhum desenvolvedor deve decidir que o sistema será distribuído, isto deve ser uma decisão do dono do negócio. Assim a gente deve usar a tecnologia para resolver os problemas do negócio e não adotar tecnologia por modismo ou coisa parecida.

Voltando a post inicial:

Não usar frameworks MVC é tolice. Para que reinventar a roda? Isto é um projeto acadêmico?

Como já disseram, LDAP pode ser bom desde que não seja um complicômetro a mais que no fim retarde a entrega o projeto. Faça como o Vitor disse para colocar projeto para funcionar e desenvolva com LDAP em paralelo. Caso ele não fique pronto a tempo vc já tem a autenticação feijão com arroz funcionando.

Controle de telefonia com applets + sockets? Parece bobagem pois acho que já tém um monte de soluções prontas que fazem o controle de telefonia de Call centers. Caso realmente queiram reinventar a roda, usem JWS + http.

E Cache? Não será necessário?

E o formato das mensagens?

Ainda tem trabalho pela frente!

Outra dica de ouro foi desde o início fazer testes de carga. Use o JMeter mesmo a menos que haja muita bala na agulha para contratar a Mercury.

Por fim as sábias palavras do João: "seria bom que ja tivesse alguem experiente na equipe". Acrescento observando que a experiência com o servidor de aplicações a ser escolhido também é importante.

[]s
Luca

Luca wrote:
Por fim as sábias palavras do João: "seria bom que ja tivesse alguem experiente na equipe". Acrescento observando que a experiência com o servidor de aplicações a ser escolhido também é importante.

[]s
Luca

heheh... gato escaldado....hehehe!!!
descobri isso na pratica....

[]'s

JavaEvangelist Membro desde: 09/10/2003 14:23:31 Mensagens: 379 Offline

Fabrício Cozer Martins wrote:
Rapaz, eu soh vejo a galera escaldar EJB, alguem defende a utilizacao ?

Eu tento ...
http://www.guj.com.br/posts/list/0/22573.java#121447

Thiago Senna wrote:
Se você for obrigado a usar EJB, por favor, antes de uma olhada no Spring Framework ou Pico Container.... por favor!!!

Alo Thiago,

em qual sentido PicoContainer substitui EJBs?

Pelo que andei lendo em http://www.picocontainer.org/One+minute+description, não consegui enxergá-lo como um substituto.

Abraços,
Marco Campêlo
Sun Certified Java Idiot

mcampelo wrote:

Thiago Senna wrote:
Se você for obrigado a usar EJB, por favor, antes de uma olhada no Spring Framework ou Pico Container.... por favor!!!

Alo Thiago,

em qual sentido PicoContainer substitui EJBs?

Pelo que andei lendo em http://www.picocontainer.org/One+minute+description, não consegui enxergá-lo como um substituto.

Abraços,
Marco Campêlo
Sun Certified Java Idiot

não conheço muito o spring eo pico container, mas quando o tiago falou em substituir, fala em relação ao gerenciamento de transações, objetos.

se sua app realmente precisar ser distribuida, vc tera que usar ejb(melhor alternativa).

[]'s

jgbt wrote:
não conheço muito o spring eo pico container, mas quando o tiago falou em substituir, fala em relação ao gerenciamento de transações, objetos.

Alo JGBT,

Entendo que o Spring ofereça alguns serviços, mas pelo pouco que li e entendi do PicoContainer, ele é um framework para você gerenciar seus objetos e oferece o tal do IoC/DI que todo mundo gosta tanto de falar como a solução de todos os problemas mundiais!

Mas transação por exemplo, está fora do escopo. Corrijam-me se estiver errado.

Abraços,
Marco Campêlo
Sun Certified Java Jerk

mcampelo wrote:Mas transação por exemplo, está fora do escopo. Corrijam-me se estiver errado.

Do Pico até onde eu sei ele ta fora mesmo. Mas do Spring nao. O Spring tem uma forma muito interessante de controlar as transacoes bem como exceptions tb. Se a aplicacao for distribuida da pra usar Spring substituindo os EJB's sim, só nao sei dizer se é uma vantagem em termos de complexidade e aprendizado.

]['s

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Foi mau então pelo Pico Container!!!

Falha nossa!!!

Considerei que pelo fato de Pico Container ser um Container leve poderia ajudar!

Abraços!

This message was edited 2 times. Last update was at 13/04/2005 14:05:01

Olá

mcampelo wrote:Mas transação por exemplo, está fora do escopo.

Bem, como já disseram O Pico poderia ajudar a desenvolver uma solução na mão (argh...) mas não se presta a resolver o problema.

O Spring como o Fábio disse provê uma solução para o caso que o Rod Jonhson chama de lightweight transaction infrastruture. Veja o livro J2EE Development without EJB que você pode e deve ler um trecho aqui

Segundo o capítulo 9 Transaction Management do livro do Rod Johnson, o gerenciamento de transações com J2EE é tradicionalmente associado com EJBs. Muitas aplicações J2EE usam Container Managed Transactions Stateless Session Beans apenas para demarcar as transações sem necessitar de nenhum outro serviço EJB. Neste capítulo ele mostra outras alternativas ao uso de EJBs.

Ele define lightweight transaction infrastruture como um ambiente com algumas limitações tais como não depender de um EJB container, usar um único DataSource, uma única SessionFactory hibernate e outras limitações mais que são bastante comuns de acontecerem. Pelo que entendi e posso estar errado, apenas nestes casos o Spring fornece uma solução sem que seja necessário sujar as mãos com JTA.

Eu sou fã do Rod Johnson mas ainda tenho algumas esperanças no EJB 3.0

[]s
Luca

Notícias, artigos e o maior fórum brasileiro sobre Java