Criei este tópico para discutir e pedir sugestoes a vocês sobre um projeto de sistema:
Titulo: Sistema de Gerenciamento de Call Center
Descricao: Sistema utilizara tecnologias java para implantar campanhas de abordagem de publico como por exemplo: vendas de cartoes de credito, vendas de outros titulos bancarios, agendamento de visistas bancarias entre outras.
Oque eu tenho em mente:
:arrow: começaria do basico, Utilizaria JAVA :mrgreen:…
:arrow: EJBs,
:arrow: Jldap para controle de usuarios com grupos e permissoes,
:arrow: não gostaria de utilizar frameworks MVC (sugerido Struts pela empresa … )
:arrow: Controles de Telefonia por applets acessando servidores por socket.
:arrow: Relatorios on-line com jasper reports + JSP
Exigencias do projeto.
:arrow: Logicas de acesso a a dados implementadas por stored procedures ( minhas DAOs ficariam mais simples … !!!)
:arrow: Logicas de geracao de relatorios implementados por stored procedures
:arrow: Alta disponibilidade (3000 a 4000 acessos simultaneos :shock: )
Essas são as definições basicas do projeto… Gostaria de sugestoes sobre tecnologias a aproveitas e padrões a se utilizar.
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?
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.
[quote=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.
[/quote]
+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…
[quote=mister__m][quote=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.
[/quote]
+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[/quote]
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
[/quote]
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.
[quote=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[/quote]
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[/quote]
Rapaz, eu soh vejo a galera escaldar EJB, alguem defende a utilizacao ?
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!!!
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.
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:
Evite EJbs (o Vitor não disse para não usar), NUNCA use só para aprender.
Caso a arquitetura do sistema(*) precise das características para os quais EJBs foram criados então use-os com sabedoria e moderação.
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.
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.
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.
