Idéias de desenvolvimento - ERP Java

Programação Java
#1

Pessoal,

Estou em uma empresa que está se preparando para migrar uma base de sistemas em Clipper, Clarion e Delphi inteiramente para Java.
Todos os sistemas serão inteiramente migrados.

Hoje a empresa possui vários mini-sistemas que, juntos, formam uma espécie de ERP.

Assim sendo, vamos iniciar o desenvolvimento com muita calma e organização, para que ao longo do processo, as bibliotecas criadas sejam portáveis para sistemas menores, novas versões, enfim…
Desde o início já estamos deixando bem definido o padrão MVC.

Ocorre o seguinte: qual tecnologia utilizar?
Sei que é virtualmente impossível uma resposta exata, mas queria opiniões.

A abordagem SWING + Hibernate não parece ser das melhores, até porque traz alguns problemas quando utilizada em grandes ambientes, como alguns de nossos clientes atuais (um exemplo: ao atualizar o sistema, toda a empresa tem q parar, atualizar máquina-a-máquina, e depois reiniciar o sistema…)

Mas a abordagem 100% web parece ligeiramente chata. Não difícil, mas a nossa experiência até o momento é APENAS com sistemas desktop, e montar interface WEB definitivamente não é nosso ponto forte…

Existe também algumas questões a serem abordadas:

  • Segurança. Procurei aprender sobre Spring Security mas parece funcionar APENAS para WEB e não para aplicações do jeito que descrevi (locais + hibernate)
  • Interface extremamente amigável. Nossos usuários estão acostumados a entrar em contato conosco até para descobrir como criar atalhos no desktop, e uma interface amigável é INDISPENSÁVEL para evitar MAIS chamadas de call-center…
  • Log. Eu sei que com Log4J é ultra-simples, mas preciso de uma situação um pouco mais complicada: log local e log remoto (database). Parece que o Log4J faz isso.
  • Autenticação Active Directory. Dentre os clientes atuais, um banco utiliza Windows Server 2003 (ele é OBRIGADO a ter este sistema) com controle de domínio, active directory, diferentes roles por usuários e tudo mais. Seria extremamente interessante para eles já usar a presente estrutura do AD. Sei que é possível via Spring Security, mas voltamos para o problema de um servidor WEB.
  • Comunicação com outros sistemas. Preciso de comunicação. Integração. Preferencialmente via WebServices.
  • Comunicação via WEB. Os dados (SGBD) tem que possuir a capacidade de ser um servidor remoto.

ME PARECE que a melhor solução para reunir tudo isto, de forma bem inteligente e bem “bacana” seria mesmo em um sistema totalmente WEB com Servlet + EJB como camada funcional e HTML + Ajax como camada de interface, junto de alguns JSP.

Como fica o JSF? Seria uma alternativa interessante?

Serei o responsável por coordenar esta migração e, TUDO indica que vamos usar NetBeans principalmente porque nossos atuais programadores são MUITO familiarizados com a facilidade do “clica e arrasta” para se montar telas. A vantagem do JSF é enorme neste ponto porque o NetBeans fornece um editor gráfico relativamente bom para isto, o que já ajuda muito no desenvolvimento inicial.

Mas também não quer dizer que só podemos usar NetBeans. A escolha inicial foi feita justamente pelo editor gráfico. No entanto, Eclipse possui vários outros pontos importantes a serem levados em consideração.

Estava pensando em:

  • JSP + Servlet + EJB
  • Spring MVC + Spring Security
  • Hibernate
  • JBoss

Mas fuçando a internet descobri muita coisa sobre
RPC
WebServices
e uma série de outras tecnologias.

RPC, como ficaria a performance via internet? Tenho medo de que seja muito eficiente local mas ao comunicar SWING + WEB via RPC a performance caia drasticamente…

Opiniões, por favor :?:

#2

Olha não tenho experiência na parte de segurança e integração para sugerir soluções, mas quanto ao JSF seria legal usar acho a curva de aprendizado pequena e existe alternativas com ajax para criação de interfaces ricas como o richfaces:http://livedemo.exadel.com/richfaces-demo/richfaces/inplaceInput.jsf?c=inplaceInput.

#3

LordALMMa, eu te indicaria a dar uma olhada no e-Gen(http://www.egen.com.br/), ou no Compiere que é um ERP feito em java.

#4

Olá,

Eu particularmente não gosto do XML para configuração, prefiro configuração programática, você pode encontrar isso em alguns frameworks MVC como Mentawai e VRaptor. Claro que tudo isso depende do tamanho do seu sistema.

Att.
Wallfox

#5

@ Daniel.F

Durante uma reunião minha hoje com um outro diretor surgiu (antes mesmo de ler as respostas aqui) a idéia de JSF + Ajax. Eu mesmo já fiz uns breves estudos de JSF há algum tempo, pelos tutoriais do NetBeans, e aprendi um pouco. Em conjunto com o que aprendi sobre taglib, já dá para fazer MUITA coisa. Ajax para mim ainda é uma área relativamente nova (pasme!), embora eu conheço plenamente o FUNCIONAMENTO do Ajax, nunca efetivamente usei.

MUITO obrigado pelo link. Vai ajudar MUITO mesmo, vlw ^_^.

@ Ironlynx

Obrigado.
Compiere inclusive estava sendo usado acho que pela Goodyear. Um “passarinho me cantou”, não sei se é verdade, mas parece que sim.
e-Gen eu já ouvi falar um pouco, há algum tempo, mas agora ele realmente “faz sentido”. Muito obrigado por me lembrar dele, vou fuçar mais a respeito.
Vlw mesmo.

@ Wallfox

Estamos trabalhando com arquivos XML e Properties.
Precisamos de uma independência total dos módulos do sistema.
Nossos clientes variam muito de tamanho. Temos hoje desde micro-clientes (exemplo: uma vídeo locadora relativamente próxima da sede) até clientes de grande porte (dois bancos de nível nacional e uma mineradora focada em exportação). São mais de 200 clientes “principais”, sem considerar alguns outros menos relevantes para esta migração (clientes de requisições muito específicas, com sistemas muito específicos e de baixa manutenção).
Hoje temos duas “linhas” de sistemas:

  • Padronizados, como sistema de sindicato, sistema de folha de pagamento, sistema financeiro, etc
  • Personalizados, como exemplo: um sistema de sindicato que foi desenvolvido sob medida para atender também ao clube, à sede administrativa, para efetuar empréstimos aos associados, controle médico e de vendas em lojas credenciadas.

Queremos “manter” esse princípio, mas com a seguinte alteração:

  • Módulos padronizados. Por exemplo: uma biblioteca de controle financeiro padrão para pelo menos 90% dos clientes.
  • Interface personalizada. A apresentação do sistema, o comportamento, enfim, o controle geral do sistema será personalizado.
    Isto garante para nós um controle conciso de versões, incrementos do sistema.

PRECISAMOS de configurações via XML/Properties. Sem isto, um sistema deste estilo ficaria MUITO mais complexo ou deixaria de ser POO e se tornaria POG (Programação Orientada à Gambiarra).

O modelo MVC já funciona. O Spring em si funciona perfeitamente. Eu criei, semana passada, um protótipo do sistema para sindicatos, usando JSE com Swing + Spring + Log4J. Sem nenhum acesso a BD ou qualquer funcionamento. Apenas um protótipo gráfico. Funcionou perfeitamente, com uma performance incrível, interface simplificada e focando utilização multi-Threading.

Vlw mesmo assim.

==========================================================

Eu tenho uma grande atração pelo SWING. Acho que sua “amigabilidade” é muito superior a qualquer sistema WEB. Sua forma de trabalhar, de responder ao usuário. Afinal de contas, as pessoas AINDA estão muito acostumadas à interface WINDOWS, tanto que a maior parte de solicitações de desenvolvimento que recebemos é para interface WINDOWS, explicitamente proibindo desenvolvimento baseado WEB.
A idéia inicial do desenvolvimento era justamente em SWING.
Mas o Spring Security simplesmente “travou tudo”. Ele requer um servidor WEB pelo que parece, embora não sei ainda ao certo. Fiz esta pergunta (se requer web) no fórum oficial mas ainda sem resposta.
O problema é que ao buscar mais info sobre o Spring Security eu descobri que, digamos, -500% dos desenvolvedores estão usando SWING puro como tinha sido pensado. A maior parte usa OU tudo totalmente WEB (JSP, JSF, PHP, enfim… o que for necessário para funcionar 200%) OU usa o SWING + RPC para exibir uma interface amigável e executar métodos remotos (RPC) no servidor, de forma centralizada.

Gosto da idéia de RPC. Realmente gosto. Mas tenho medo de sua performance. Um dos momentos críticos vai ser a substituição em um dos bancos. Eles são hoje nosso principal parceiro, e aceitaram contribuir para o desenvolvimento implantando o sistema no ambiente de produção e trabalhando simultaneamente com o sistema legado e este sistema novo. Mas tenho muito receio de “empolgarmos” no RPC e na hora que o banco (que tem, digamos, um número BEM significativo de usuários SIMULTÂNEOS) entrar no ar, o sistema deixe de ser um mega-sistema lindo e maravilhoso SWING + RPC e se torne algo próximo de uma pedra, pura e simples.

SWING seria uma alternativa BEM interessante AO MEU VER, pois eu poderia implantar um sistema autônomo que somente usaria um mínimo de banda, para solicitações e recebimentos de respostas do BD. Acho que seria o que consome menos recursos, mas tem desvantagens:

  • Problemas no controle do sistema
  • Problemas com a segurança do sistema. Solução VIÁVEL (aparentemente a única): Codificar um framework de segurança inteiro em AOP (AspectJ). Pelo menos o Sring ajuda pakas nisso…

Já o modelo WEB corrige isso, mas traz a desvantagem da interface.

Ainda sim, obrigado a TODOS, MESMO, MESMO MESMO, pelas opiniões.
Estamos meio que travados aqui.
Enquanto não resolvemos o futuro, continuamos a modelar os dados e requerimentos mínimos que já conhecemos pelos sistemas atuais.

Como eu disse, não tem como ter uma resposta exata.
No fim das contas, vale um sábio comentário de um amigo meu (que trabalha com .NET): Podemos pregar um prego tanto com um martelo quanto com uma chave de fenda. Realmente podemos. Mas um deles vai ser BEM mais complicado e vai exigir MUITO mais trabalho.

Tenho medo de escolhermos, por exemplo, JSE + SWING e, seguindo a analogia, estarmos optando pela chave de fenda. :cry:
Ou de optarmos pelo modelo WEB e descobrir, lá na frente, que o modelo JSE + SWING servia perfeitamente e muito mais fácil… :shock:

Complicado, não?
:lol:

Novamente, obrigado MESMO a todos.
Já ajudou um pouco a direcionarmos aqui.

Se alguém souber mais a respeito de RPC, POR FAVOR, comente.
Como eu falei no post inicial, não sei como fica a performance.
Não podemos nos dar ao luxo de obrigarmos TODOS os nossos clientes a terem uma internet dedicada de 8Mbps, com um mega servidor de aplicações.
Mas também não podemos nos prender somente aos clientes pequenos, senão a empresa simplesmente perde os seus principais pilares de sustentação atualmente…

Posso estar soando um pouco perdido. Mas não, não é pro soar. É pra MOSTRAR que estamos sim perdidos.
Optamos pelo java depois de um looooooooooooongo processo de quase 6 meses de estudos .NET x Java. Chegamos à conclusão que vamos ter desenvolvimento em AMBOS mas nosso PRINCIPAL foco vai ser o Java.
Agora, estamos perdidos novamente, então eu peço: opiniões, por favor?

:arrow: Vlw, a todos.

#6

Vamos aos puxões de orelha:

:arrow: RPC não é framework, é apenas a arquitetura mais usada (mas não necessariamente a melhor) para comunicação remota. EJB é assim e a maioria dos WebServices são assim. Todas as alternativas apontadas por você involvem RPC no meio.

:arrow: Se os seus programadores estão “acostumados” ao arrasta e solta, isso é problema à vista. Não importa quão maravilhosa a arquitetura é, sem programadores competentes o projeto vai desandar. Sério, não subestime uma equipe ruim!

:arrow: Você disse que ficou seis meses estudando a altenativa entre Java e .Net. O que você fez nesse período? Ficou fazendo reuniões onde os javeiros e dotneteiros ficavam discutindo até um dos lados desistirem? Ou os dois grupos fizeram protótipos? Se aconteceu a primeira opção, e não a segunda, esses seis meses foram simplesmente disperdiçados. Sem botar a mão na massa, fica difícil saber o que é o melhor. É como se tentasse descobrir qual a sobremesa mais gostosa apenas “analisando” os ingredientes. Ora!, faça um terço ou metade da receita e coma pra ver se é bom!

:arrow: Como acredito que você não fez protótipo, agora não sabe (ainda) como seguir adiante. Sinceramente, “modelar os dados e requerimentos mínimos” não vai te ajudar agora. Apenas vai consumir esforço da sua equipe para algo que não é importante no momento. Sugiro que faça um pedaço do projeto, tipo 10% dele, usando tanto o Swing quanto o Web (sim, fazer a mesma coisa duas vezes). Depois disso, tendo coisas concretas, você vai conseguir fazer uma análise do que é o melhor. No final, haverá um esforço de “110%”, mas acredito que é melhor pagar 10% para não ter riscos, do que não pagar esse valor e não saber se vai ser 100% ou 300%.

:arrow: Particularmente, discordo quando você disse que aplicação Desktop é mais amigável. Mas é opinião minha, claro! Na real, as suas análises estão bastante superficiais, você está assumindo que determinadas coisas são assim-e-ponto-final, sem tentar fazer um protótipo e ver se tais são realmente importantes.

:arrow: Não existe “independência total dos módulos do sistema”. Um sistema é constituído de módulos que se comunicam entre si, logo um determinado módulo precisará que um outro módulo exista para fazer o seu trabalho, logo um módulo depende de outros módulos. Independência total é impossível, não trabalhe pensando nisso. O que deve ser feito é reduzir a quantidade de dependências, não eliminá-las. E outra coisa, XML não é a única forma de garantir baixa dependência, a própria OO possui meios para se criar módulos com baixo acoplamento. Se a criação de módulos é crítico, talvez fosse o acaso de considerar o OSGI (o Apache Felix é uma implementação).

:arrow: Acredito que existe algo bastante problemático, o uso de cascata como metodologia de desenvolvimento, e sei disso porque você está preso na análise. Só que as duas dúvidas só serão sanadas quando começar a escrever código, o que não está sendo feito agora. Busque informações sobre metodologias ágeis, tipo XP ou Scrum. Acredito que isso seja mais crítico que a escolha de tecnologia, como você está demonstrando.

Enfim, você precisa de três coisas: programadores competentes, agilidade, e cair na real e fazer código agora! As dúvidas suas não são os seus reais problemas, são apenas sintomas de um problema muito maior e que você não viu.

#7

@ Leonardo3001

Não foram puxões de orelha. Foram críticas furadas baseadas em SUA presunção. Porque VOCÊ leu dois posts meus aqui no GUJ não quer dizer que você faça a MENOR idéia de como a empresa funciona, muito menos lhe dá conhecimento suficiente para sair assumindo verdades.

  • Não falei que RPC era framework.
  • Meus programadores não são incompetentes. Apenas estamos ACOSTUMADOS à editores WYSIWYG. Preferência é diferente de capacidade, até no dicionário.
  • Tadinho. Mais de 20 anos de mercado e a gente escolher Java ao invés de .NET sem nenhum protótipo? Ha-ha-ha!
  • “Sinceramente, “modelar os dados e requerimentos mínimos” não vai te ajudar agora”. Não? Certeza? E se eu dissesse que prefiro trabalhar a ficar esperando respostas dos fóruns? Ah… já ia me esquecendo: Não modelamos APENAS para sistemas novos não. Requerimentos mudam, sabia? Inclusive para sistemas já implantados…
  • Opinião é opinião, mas cuidado. Minha opinião não reflete as escolhas dos clientes. Apenas coincidência. Foi feito um estudo para isso…
  • Nunca falei em os módulos serem INDEPENDENTES ENTRE SI. Se tivesse lido com cuidado ia ver que me refiro à “INDEPENDÊNCIA DE IMPLANTAÇÃO”, ou seja, o mesmo módulo funciona para todos os clientes, em outras palavras, SEM que as preferências de cada cliente estejam escritas no código do sistema…
  • Não usamos cascata. Basta falar isto. Não vou entrar em detalhes, já editei o post porque ficou longo demais. Mas não, não usamos cascata. Você assumiu ERRADO porque está se baseando em meias-palavras que coloquei aqui. Precisaria analisar a situação inteira antes de falar algo deste nível…

Cuidado.
Falar “b e sei disso porque você (…)[/b]” pode ser problemático. Você REALMENTE sabe? Esteve aqui e conferiu pessoalmente o que estamos fazendo? Tem CERTEZA disso? Assume todo e qualquer risco sobre sua opinião, com sua conta em risco?
Assumir uma situação alheia já é complicado. Mas assumir VÁRIAS, como você fez, é totalmente non-sense.

Enfim:

  • Já temos programadores experientes, parabéns por assumir errado.
  • Agilidade você quer dizer no que? Deixar de documentar e correr para código? ‘-’
  • Cair na real e fazer código agora? Bom, já fizemos. E sabe o que é o melhor? EU FALEI NO POST QUE FIZEMOS!
  • As minhas dúvidas são sintomas de problemas maiores que não vi. Nossa, você participou mesmo das aulas de filosofia. Mas será que, por acaso, minha dúvida não seja porque JÁ ESTAMOS com o problema, e queremos mais informações antes de sair tentando resolver para uma das possíveis vertentes?

==========================================
Isto posto,
o tópico finaliza.

Obtive respostas em vários fóruns.
RPC funcionaria bem, sim. Existe claro um problema que vou enfrentar: máquinas mais antigas costumam ter a rede com erros de configuração o que (pasmem) reduz a velocidade de 100Mbps para até 300Kbps (ou até menos). Vou ter que enfrentar isto mas se trabalhar corretamente com criptografia + compactação posso transformar as classes serializadas em pacotes de poucos Kb e transferir de forma muito eficiente.
Vou seguir, portanto, o modelo do governo brasileiro: Sistema WEB, sendo que o cliente inicializa a aplicação via Web-Start (JNLP). Vou usar, dentre outras coisas, RMI.

O Spring funciona 100% standalone. Foi um sacrifício conseguir alguma resposta mas sim, ele funciona. Algumas coisas se tornam mais “manuais” mas ainda sim, é Spring Security e continua comprovadamente eficaz.

WebServices com XML é um dos mais versáteis e vai ser nossa escolha de comunicação com outros sistemas. Não vamos usar o XML para nosso próprio sistema por causa do overhead que o XML gera para enviar a informação, mas se torna justificável quando se trata de comunicação com outros sistemas.

Moderador, se puder, por gentileza, finalize o tópico, ok?

Futuramente vou reunir partes do código, pontos importantes, uma mini “TODO-LIST” e dicas dos problemas que passamos e postar aqui. Pode ajudar outras pessoas.

Flwz e, novamente, obrigado a todos pelas opiniões.

#8

veja isto:

http://www.zkoss.org/demo/zkstudio/zkstudiodemo.dsp

#9