Tecnologias a Utilizar

Voce quer usar ejbs e NAO quer usar MVC? :?

Rafael

Não gostaria de usar Frameworks Prontos … gostaria de fazer (servlets + jsp) dentro dos padroes MVC

Fernando

Vira de cabeça para baixo e reprocessa.

Vamos lá…

• começaria do basico, Utilizaria JAVA …

COOL +

• EJBs

Errado, tente evitá-los

• Jldap para controle de usuarios com grupos e permissoes

???

Create table user (nome varchar(30), senha varchar(20));

• não gostaria de utilizar frameworks MVC (sugerido Struts pela empresa … )

Errado, USE! Struts, WebWork, JSF, JBanana, etc

• Controles de Telefonia por applets acessando servidores por socket.

??? Nossa… Socket? Não da para usar WebServices não, ou um servlet?

• Relatorios on-line com jasper reports + JSP

É bomzinho, mas eu gosto mais do JFreeReport

• Logicas de acesso a a dados implementadas por stored procedures ( minhas DAOs ficariam mais simples … !!!)

Ficariam beeeem simples, aliás, vc nem precisa de DAOS ehehehhe. Dica… tente não usar essas stored procedures

• Logicas de geracao de relatorios implementados por stored procedures

Idem ao anterior

• Alta disponibilidade (3000 a 4000 acessos simultaneos )

3000 a 4000 acessos simultâneos? O que tu vai fazer, um Grid de reconhecimento de padrões das fotos tiradas a cada segundo dos satélites da nasa da Terra?

Não precisa exagerar… começe do início… do Java

Pq vc nao gostaria de usar frameworks? o trabalho que vc vai ter pra implementar do zero eh abusrdo de grande.

Qtas dezenas de servidores voces terao disponiveis para rodar o sistema?

Rafael

Boa sorte, mas você vai gastar mais tempo fazendo seu framework MVC do que o próprio sistema. Não reinvente a roda (apesar de eu odiar clichês).

Se você vai ter uma carga grande feito essa, EJBs são uma boa pedida, mas fuja de EntityBeans. Isso te da clustering e alta disponibilidade facilmente. Para callcenters a melhor coisa a fazer é usar MDBs, a escalabilidade do sistema vai ser muito melhor.

Edit(Falei M):
LDAP é uma ótima escolha, só toma cuidado com o servidor que escolher.
Fuja da idéia do Vitor, gerenciamento de usuarios de verdade é usando LDAP.

Use um framework MVC, supondo que você leve tempo ZERO para escrever ele, você vai gastar mais tempo corrigindo os bugs dele que aprendendo alguma solução existe.
Esqueça applets, você vai ter que assiná-los para usar sockets com os telefones, prefira JWS. Tente usar uma API dos aparelhos caso o vendor ofereça.

Outra coisa, um sistema desse porte não é simples, já trabalhei com um concorrente seu e digo que algumas metas são bem trabalhosas de atingir.

Essa dica aqui vai de graça, faça testes de carga ao longo de todo projeto e desde o inicio.

louds:

LDAP é uma ótima escolha, só toma cuidado com o servidor que escolher.
Fuja da idéia do Vitor, gerenciamento de usuarios de verdade é usando LDAP.

+1. Pra qualquer coisa que você pretenda integrar, LDAP é bem melhor que aquela tabelinha sem-vergonha que você modelaria. Contudo, daí as empresas deixarem você usar LDAP…

Se te deixam, comece já!

mister__m:

louds:

LDAP é uma ótima escolha, só toma cuidado com o servidor que escolher.
Fuja da idéia do Vitor, gerenciamento de usuarios de verdade é usando LDAP.

+1. Pra qualquer coisa que você pretenda integrar, LDAP é bem melhor que aquela tabelinha sem-vergonha que você modelaria. Contudo, daí as empresas deixarem você usar LDAP…

Se te deixam, comece já! :-D

Po, será que é só eu que não gosto de LDAP? hehehe

Sei la… muita complicação para pouco resultado… claro, a não ser que você realmente vá usar todos os recursos da LDAP, como validação em árvores e aquela coisa toda…

Por que ? Ejbs não são melhores pra grandes aplicações

3000 a 4000 logins simultaneos … hehehe escrevi errado. oque me daria em media de 1000 acessos

Qual concorrente Louds ??

scottys0:

vfpamp:

• EJBs
  Errado, tente evitá-los
  

Por que ? Ejbs não são melhores pra grandes aplicações

São, e não são…

Vai do que você fizer e como fizer. O problema do EJB é que ele é um elefante branco altamente mutável (Vide EJB2.0 e EJB3.0) e nada portável entre os servidores :P. Além de, claro, ser chato e trabalhoso pra cassete.

My 2 cents

Rafael Steil:

Pq vc nao gostaria de usar frameworks? o trabalho que vc vai ter pra implementar do zero eh abusrdo de grande.
Qtas dezenas de servidores voces terao disponiveis para rodar o sistema?
Rafael

“Alguns” Intel® Xeon™ … com 2 GB de memoria …

vfpamp:

São, e não são…

Vai do que você fizer e como fizer. O problema do EJB é que ele é um elefante branco altamente mutável (Vide EJB2.0 e EJB3.0) e nada portável entre os servidores :P. Além de, claro, ser chato e trabalhoso pra cassete.

My 2 cents :D

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

Session Beans são legais se usados com moderação e MDBs, mais ainda. Se você tiver como usá-los de forma invisível, é quase perfeito

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).

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

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á

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

heheh… gato escaldado…hehehe!!!
descobri isso na pratica… :mrgreen:

[]'s

Fabrício Cozer Martins:

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

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:

Thiago Senna:

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

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

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

Foi mau então pelo Pico Container!!!

Falha nossa!!!

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

Abraços!

Olá

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