Arquitetura p/ novo proj com PDV, acesso web, e mais

Olá,

fui convidado a uma discussão para iniciar a arquitetura de um projeto acadêmico que tem os seguintes requisitos e características:

1- Existe uma empresa distribuidora dos produtos a serem vendidos.
2- Existem lojas que vendem esses produtos.
3- Deve existir um site que aceite pedidos pela internet. Ao se fazer o pedido, a loja mais próxima do cliente faz a entrega! A entrega deve ser rápida, imediata, como remédios, ou DVD.
5- A interface para os caixas das lojas (PDV) deve ser rica, veloz.
6- Ao cair o estoque de determinado produto em uma loja, a distribuidora deve ser “avisada”, e um novo pedido de venda por atacado daquele produto deve ser feito e agendado para entrega na loja.
7- Tudo deve ser multiplataforma e as maqs cliente nos PDV´s devem rodar em Linux.

Aí começam as dúvidas:
a) centraliza tudo em um servidor central (mesmo que c/ distribuição de carga)?
b) Cada loja tem o seu servidor? Como sincronizar com o servidor da distribuidora?
c) A aplicação nos PDV´s deve ter interface browser (html), ou Swing/SWT?
etc, etc…

Gostaria de ouvir opiniões…

Como uma drogaria que tem uma distribuidora e sua própria rede de farmácias faria?

Olá

Felipe, você que já trabalha com desenvolvimento web há algum tempo deve ter todas estas respostas. Qual é a sua opinião?

Quanto a mim me desculpe mas infelizmente não posso dar a minha pois lá em casa tem gente que depende de mim.

[]s
Luca

Isto aqui é um fórum, certo?!

Local onde pessoas tem liberdade de postar um assunto, dúvida, blá, blá, blá… Não importa se entende de java (ou qqer outra tecnologia), ou se fez curso entende pouco, ou se fez 4 anos de faculdade (só vendo java) e ainda entende muito pouco.

Isto é um fórum, certo?! Não é um sistema de controle p/ verificar oque cada um sabe, oque não sabe… Pq ser for, então devia ser colocado um componente para validar se os POSTs são dignos ou não, antes de serem enviados para cá.

Não gosto de escrever posts assim, mas eu também estou interessado em saber sobre as possíveis soluções para o problema q o Felipe postou.

Não entendi nenhum dos dois replies desse tópico.

Bem, quanto às suas perguntas:

a. apenas um servidor central é sempre ótimo, mas as aplicações de caixas não devem depender da internet para funcionar. Fazer uma coisa bem feitinha, que sabe quando está online e, caso não, guardar as informações para serem enviadas para o servidor central quando a mesma voltar.
b. ^
c. cara, normalmente aplicações de caixa devem ser rápidas, e num ambiente web tem que fazer muita ginastica para colocar teclas de atalho e outras coisitas que facilitam a operação do software. Eu recomendo uma app normal distribuida com Java Web Start.

Felipe,

Vou manifestar a minha opiniao, mas por favor, nao joguem pedra pois posso ta falando mer**… rs* :oops:

Entao, eu faria num servidor centralizado… se o servidor central nao der conta do recado vc poderia fazer cluster com outros servidores… acho q fazendo assim vc vai facilitar mto o seu trabalho… ai q questao B morre…

Agora, se optar pela B, pode usar Web Services para fazer os servidores “conversarem”…

A interface eu faria (apesar de totalmente a favor de web) em Swing… Confesso q nao sei explicar pq escolheria o Swing… apenas uma intuicao de q seria melhor…

Bom, é isso… espero ter ajudado em alguma coisa… :wink:

[]´s

Luca, não entendi muito bem a sua resposta, mas…
Acho que se vc tem alguma solução que vc ache interessante, vc poderia compartilhar pelo menos alguns conceitos, para ajudar a todos aqui. Não é para isso que serve este fórum? mas em fim… tudo bem…

Eu trabalho com web há algum tempo, mas justamente por isso não tenho a resposta para este caso. Nunca trabalhei com uma estrutura cliente servidor. E acho que neste caso, isso talvez possa ser interessante para as lojas, caso elas tenham cada uma um servidor próprio.

Conversando com alguns amigos, acho que chegamos numa solução mais ou menos assim…

. cada loja tem seu servidor próprio.
. os caixas teriam aplicações Swing.
Isso para que o ambiente dos caixas das lojas seja rápido na conexão com o servidor, e a interface seja rica. Neste caso, a inteligência de negócios está no swing e na hora H abre uma conexão remota com o servidor de banco de dados e faz o que tem que fazer lá? Ou de repente apenas empacota um XML com os dados e acessa um Web Service no servidor da loja. Se sim, entao a inteligência de negócios tá no servidor. Mas alguma precisa estar tbem no swing, para validações e tal, não? XML pra cá e pra lá poderia ficar lento?

. Como “avisar” o servidor da distribuidora que o estoque caiu? Webservices? Pode ser!
. Por outro lado, os servidores de cada loja teriam que ter algo como um web service para que, quando um usuário final acessasse o site (que seria no servidor da distribuidora), este servidor falaria com os servidores das lojas mais próximas ao usuário, para saber se tem estoque.
. Ao mesmo tempo, o servidor da distribuidora precisa saber todos os dados de todas as lojas, para poder fazer um BI, um datamining, etc. Como sincronizar estes dados?


E se a solução fosse um servidor centralizado?
. aí os caixas das lojas teriam uma aplicação standalone que não dependa da instabilidade da conexão. Mas como sincronizar os dados de estoque da própria loja, se ela tem 3 caixas com 3 aplicações standalone rodando? Já precisariam de um servidorzinho, não? Então acho que esta opção não é muito boa.


Além disso tudo, como tentar ao máximo reaproveitar código!
. aplicação Standalone, Swing, Web, WebServices…

Acho um puta estudo de caso. Sei que alguém já fez isso… Pois como funcionam os bancos, com 24h, tudo real time? Como funciona o zonasulatende.com.br , com seus mercados espalhados e um site de compras online? Eu não sei! Por isso gostaria de saber um pouco mais da experiência de cada um .

Alguém já fez algo deste tipo? Pode compartilhar pelo menos os problemas, os erros?

Grande abraço
Felipe

Sim já fizemos um sistema bem complicadinho de gestão econômico financeira, controle de estoque simples, filiais etc. Infelizmente ainda não conhecíamos Java.

Optamos mesmo por um servidor central, pois assim é possível ter quantos clientes for que a coisa funciona do mesmo jeito. Apesar de requerer um investimento pesado com hardware logo de cara, depois fica bem redondo.

Imagine a seguinte situação:

  1. Filial 1 vende um todynho
  2. A aplicação faz uma requisição ao servidor, avisando que 1 todynho saiu do estoque, então deve ser decrementado 1 todynho da tabela filial1 -> estoque -> achocolatados
  3. Um serviço que roda no servidor percebeu que o estoque de todynhos na filial1 está quase acabando, e manda um email para o fornecedor requerindo mais todynhos.

Mas … e se a conexão tivesse caido?
Bem, então ao lançar a venda de um todynho no caixa, a aplicação guarda esta informação num xml (ou qualquer outro lugar) e, quando a conexão voltar, envia este arquivo para o servidor, que realizará o resto do serviço.

Nós aqui na empresa SEMPRE preferimos fazer clientes mais magrinhos, que façam a menor quantidade de coisas possível, deixando o trabalho grosso no servidor.

E quanto a tecnologia, aconselho EJBs; comecei a estudar essa tecnologia faz algumas semanas, e creio que é exatamente o que você precisa neste projeto :smiley:

E cara, se você já trabalhou com web, então tudo o que fez foi permitir a conversa entre clientes e servidor hehe

Olá

[quote=“felipenasc”]Luca, não entendi muito bem a sua resposta, mas…
[/quote]

Felipe, li rápido sua mensagem e entendi que estava querendo uma solução para um problema profissional. Se assim fosse você teria merecido minha irada resposta. Espero que realmente eu tenha entendido errado e então peço desculpas.

Se o problema fosse meu sugeriria:[list]1- Clientes com swing + JavaWebStart acessando servlets por http. Consistência local com observers
2- Servidor local com tomcat (atenção com performance que pode ser horrível se mal configurado), hibernate + hqsql (ou MySQL) para armazenar logs (e transações temporárias) interligado por http(s) (ou sockets) a um servidor central
3- Em caso de falha nas comunicações as transações seriam acumuladas temporariamente no servidor local e mais tarde replicadas no servidor central
4- O servidor local poderia fazer também as comunicações de TEF, consultas aos bancos e outras coisicas mais que algumas lojas concorrentes já fazem.
5- O servidor local pode até ser uma das máquinas cliente
6- O servidor central na verdade precisa ser espelhado e usar todos os recursos de balanceamento de carga e alta disponibilidade. A base de dados de preferência deve ser paralela armazenada em SAN. Sem economias aqui. Use gigabit, unix de verdade, máquinas multiprocessadas, muita memória, segurança dos dados, segurança física, backups frios e quentes, monitoramento da rede, tudo que tem direito. Tomcat aqui nem pensar, procure pelo OrionServer que é muito rápido. O JBoss é bom para cluster mas precisa de alguém que o entenda para ter performance pois há que eliminar umas gordurinhas.
7- Comunicação não discada onde for possível
8- As palavras chaves neste tipo de arquitetura são desfazimento, transações ACID (tipo tudo ou nada), two phase commit, preocupações desta ordem.Pattern: cadeia de responsabilidades
9- As entregas do seu problema formam um clássico problema acadêmico de roteamento que é fonte de consultoria para alguns professores mais espertos em grafos e pesquisa do caminho crítico. Na sua faculdade mesmo deve ter gente capacitada nisto.[/list]
Importante:[list]a) WebServices não tem NENHUMA serventia aqui. Mas sei de casos análogos também sem mistura Windows-Linux onde são usados apenas para tornar mais genérico o desenvolvimento. Em suma, o benefício não é da aplicação e sim do futuro uso em outro cliente.
b) A adoção de EJBs não vai facilitar tanto assim desenvolvimento e pode onerar tanto a performance como o custo do site do servidor central.
c) As mensagens das transações podem ser em XML mas tenha em mente que um parser XML pesa muito no cliente que por outros motivos precisa ser leve. Pode ser melhor pensar em um protocolo caseiro tipo csv (Comma Separated Value File) ou até mesmo o danado do ISO8583.
d) Estude bem o protocolo SSL (procure o livro do Eric Rescorla) e o imite espaçando a troca de chaves assimétricas para usar mais tempo as chaves simétricas. Isto melhora muito a performance em relação ao uso do https.
e) Não esqueça que tudo isto precisa estar embasado em um estudo de planejamento de capacidade que futuramente deverá ser verificado com testes de stress. Provavelmente o cliente vai querer um contrato com níveis de serviço definidos de forma clara e o pior erro será se o site não der conta do recado. Melhor errar para mais.[/list]
Poderia falar muito mais com muito gosto pois este ambiente é justamente onde me sinto mais a vontade. Minha experiência com sites deste tipo inclui um case bancário com mais de 10 mil terminais cliente e outros cases também com muitos clientes.

Em troca desta longa resposta você fica me devendo o nome do curso, da cadeira e do professor que pediu este projeto. Me diga também quantos alunos estarão envolvidos nele e qual o prazo.

[]s
Luca

Oi Luca,

valeu pela resposta. Acho que todos aqui vão apreciar este conjunto de conceitos. Mesmo sendo alguns desconhecidos inclusive para mim, é um excelente começo do que procurar.

Dá pra ver que vc tem experiência no assunto, se um dia eu tiver um caso profissional deste estudo de caso, e neste tempo ainda não conseguir fazer algo desta natureza, ou ainda não me sentir seguro o bastante, pode ter certeza que lhe indicarei (caso interesse).

Em relação ao que estou lhe devendo agora, como vc pediu:

Curso: Mestrado em Engenharia de Software pela PUC-Rio - Dpto de Informática
Cadeira: não há.
Prof Orientador: Carlos José Pereira de Lucena
Prof Co-Orientador: Arndt Von Staa
Alunos envolvidos: 3 (eu e mais 2)

Eu, como os outros dois, faço mestrado em tempo integral (apesar de ainda desenvolver para terceiros, mas sem vínculo empregatício, quando pinta alguma coisa.). Sendo assim, temos interesse e tempo em pesquisar coisas novas (ao menos novas para nós), mesmo que fora das disciplinas (ficamos o dia inteiro dentro do lab). Estávamos conversando outro dia, e estes requisitos foram montados a partir da pergunta de como seria uma solução para uma aplicação de uma rede de farmácias, ou então de como é a solução usada nos bancos, ou em supermercados como o zona sul, que oferece lojas e site, e entrega a domicilio. Em fim…foi isso. Resolvemos tentar montar uma solução, e muitas perguntas ficaram no ar.

Eu fiz eng. elétrica na graduação, e comecei a trabalhar com software no final da graduação…então muitos conceitos e experiência em software eu não adquiri quando mais jovem… tentando correr atras do tempo perdido…

estou querendo propor minha dissertação em algo do tipo “Um framework de integração de frameworks e bibliotecas open-source para o desenvolvimento de sistemas de informãção web J2EE”. Isso para propor um framework que disponibilize uma arquitetura “legal” integrando Struts, Hibernate, Log4j, Quartz,… e ao mesmo tempo fornecendo serviços parar envio de mensagens eletrônicas, manipulação de erros no nível de objetos de negócio, internacionalização, autenticação e autorização, etc… O único exemplo que “vi” parecido é o Expresso, mas ele é muito preso em si próprio. Procuro por algo mais flexível que permita a troca de um componente por outro, ex.: hibernate por castor, ou Struts por WebWork…será que dá, que fica legal?? Não sei, é isso que quer ver!

Mas apesar de conhecer um pouco de web, nunca fiz nada com standalone ou cliente servidor (“pré-web”). Por isso o interesse em um estudo de caso como este, que junte os dois mundos. E ainda, como fazer de tal forma que se possa reaproveitar o máximo de código, já que temos Swing, Servlets, JSP , MVC, Persistência, distribuição, transações temporárias, etc, etc…

Valeu e abraço

*** SPOTLIGHT !!! ***

[quote=“Luca”]Olá

[quote=“felipenasc”]Luca, não entendi muito bem a sua resposta, mas…
[/quote]

Felipe, li rápido sua mensagem e entendi que estava querendo uma solução para um problema profissional. Se assim fosse você teria merecido minha irada resposta. Espero que realmente eu tenha entendido errado e então peço desculpas.

Se o problema fosse meu sugeriria:[list]1- Clientes com swing + JavaWebStart acessando servlets por http. Consistência local com observers
2- Servidor local com tomcat (atenção com performance que pode ser horrível se mal configurado), hibernate + hqsql (ou MySQL) para armazenar logs (e transações temporárias) interligado por http(s) (ou sockets) a um servidor central
3- Em caso de falha nas comunicações as transações seriam acumuladas temporariamente no servidor local e mais tarde replicadas no servidor central
4- O servidor local poderia fazer também as comunicações de TEF, consultas aos bancos e outras coisicas mais que algumas lojas concorrentes já fazem.
5- O servidor local pode até ser uma das máquinas cliente
6- O servidor central na verdade precisa ser espelhado e usar todos os recursos de balanceamento de carga e alta disponibilidade. A base de dados de preferência deve ser paralela armazenada em SAN. Sem economias aqui. Use gigabit, unix de verdade, máquinas multiprocessadas, muita memória, segurança dos dados, segurança física, backups frios e quentes, monitoramento da rede, tudo que tem direito. Tomcat aqui nem pensar, procure pelo OrionServer que é muito rápido. O JBoss é bom para cluster mas precisa de alguém que o entenda para ter performance pois há que eliminar umas gordurinhas.
7- Comunicação não discada onde for possível
8- As palavras chaves neste tipo de arquitetura são desfazimento, transações ACID (tipo tudo ou nada), two phase commit, preocupações desta ordem.Pattern: cadeia de responsabilidades
9- As entregas do seu problema formam um clássico problema acadêmico de roteamento que é fonte de consultoria para alguns professores mais espertos em grafos e pesquisa do caminho crítico. Na sua faculdade mesmo deve ter gente capacitada nisto.[/list]
Importante:[list]a) WebServices não tem NENHUMA serventia aqui. Mas sei de casos análogos também sem mistura Windows-Linux onde são usados apenas para tornar mais genérico o desenvolvimento. Em suma, o benefício não é da aplicação e sim do futuro uso em outro cliente.
b) A adoção de EJBs não vai facilitar tanto assim desenvolvimento e pode onerar tanto a performance como o custo do site do servidor central.
c) As mensagens das transações podem ser em XML mas tenha em mente que um parser XML pesa muito no cliente que por outros motivos precisa ser leve. Pode ser melhor pensar em um protocolo caseiro tipo csv (Comma Separated Value File) ou até mesmo o danado do ISO8583.
d) Estude bem o protocolo SSL (procure o livro do Eric Rescorla) e o imite espaçando a troca de chaves assimétricas para usar mais tempo as chaves simétricas. Isto melhora muito a performance em relação ao uso do https.
e) Não esqueça que tudo isto precisa estar embasado em um estudo de planejamento de capacidade que futuramente deverá ser verificado com testes de stress. Provavelmente o cliente vai querer um contrato com níveis de serviço definidos de forma clara e o pior erro será se o site não der conta do recado. Melhor errar para mais.[/list]
Poderia falar muito mais com muito gosto pois este ambiente é justamente onde me sinto mais a vontade. Minha experiência com sites deste tipo inclui um case bancário com mais de 10 mil terminais cliente e outros cases também com muitos clientes.

Em troca desta longa resposta você fica me devendo o nome do curso, da cadeira e do professor que pediu este projeto. Me diga também quantos alunos estarão envolvidos nele e qual o prazo.

[]s
Luca[/quote]

Oi Luca…

se me permitir mais perguntas…

em relação aos seus itens:

1- “Swing acessando servlets por http”. Ou seja, swing apenas para dar riqueza ao cliente. Mas então ele apenas faz o papel de um browser “cheio de JavaScript”. A cada tela, faz um request e aguarda a resposta para gerar a nova tela. Ele só tem inteligência de apresentação e validação de input de dados. É isso?
Desculpe mas…quem são os observadores e os observados do seu observer? Não entendi esta consistência local.

2- Este servidor local, além de armazenar logs e transações temporárias (entendo por temporárias as que existem no servidor local mas ainda não no central), será necessário armazenar as infos dos produtos tbem. Pois se não, na hora de passar no caixa, caso não se tenha conexão com o servidor central, não há como mostrar as infos do produto. Certo?

3- ok
4- ok
5- ok
6- ok na teoria, na prática… :frowning:
7- ok
8- é engraçado como a teoria é uma coisa, a prática é outra. Esse Chain of Resp… não tô visualizando.
9- ok

valeu as outras dicas abaixo do “Importante:”

Olá

[quote=“felipenasc”]Curso: Mestrado em Engenharia de Software pela PUC-Rio
Prof Orientador: Carlos José Pereira de Lucena
Prof Co-Orientador: Arndt Von Staa[/quote]

Felipe, colega engenheiro, você não podia estar melhor cercado nos seus estudos. Está ao lado de feras do mais alto gabarito. Beba cada palavra como se fosse a derradeira gota da última Coca Cola do deserto.

Não
O swing precisa existir porque este tipo de aplicação precisa imprimir e receber resposta da impressora confirmando se foi impresso ou não. Precisa também acessar leitor de código de barras, pinpad, etc. Fazer isto com interface html mesmo com muito JavaScript, Applet, JSObjects e outros macetes é bem mais gambiarrento do que com swing. E com swing é possível fazer uma melhor consistência dos dados. Aqui podem entrar os observers. É apenas um modo de fazer e de certa forma bem prático.

Sim.
Na verdade a arquitetura ideal é com tudo on line. Prever um servidor local com uma base de dados free serve só para as lojas com conexão discada e é um quebra galho. De tempos em tempos a base local precisa ser replicada no servidor central. A existência deste servidor local complica um bocado todo o projeto mas é a contingência necessária para não parar vendas nas lojas.

Tudo será resultado do planejamento de capacidade. O throughput previsto vai determinar a melhor solução. Se for de poucas operações HTTP por segundo ou de poucas transações por segundo o Tomcat rodando em plataforma Intel confiável pode atender perfeitamente. Plataforma Intel confiável significa processador com excelente refrigeração, fonte de 1a linha, energia estabilizada, ambiente refrigerado. De jeito nenhum se pode abrir mão dos servidores espelhados. A base de dados em plataforma Intel precisa rodar em outro micro também espelhado e igualmente bom de preferência usando Raid. Tudo isto custa bem pouquinho, já trabalhei com vários sites assim sem grandes problemas. A alta disponibilidade funciona direitinho e salva a pele de quem assinou o contrato (SLA).

Mas sabe o que acontece na prática?
Você projeta um negócio grande como este, o dono gasta uma mixaria porque só compra PCs, gasta pouco com Linux, MySQL, Tomcat ou JBoss e o projeto todo fica barato. Ora, um projeto barato só pode redundar para você projetista uns trocadinhos.
Então você põe logo um WebSphere em cada um dos AIX multiprocessados, especifica Oracle Enterprise paralelo e ainda sugere uma sala cofre para o data center. O custo todo vai lá em cima e o tanto que você cobrar vai parecer bem pouquinho e o cara paga numa boa.

Na prática isto é o mais fundamental em um sistema transacional que conversa com vários servidores. As transações viajam até onde precisam ir e devem voltar até serem impressas corretamente. Em caso de qualquer falha precisam ser desfeitas. Não é difícil bolar isto, mas é a diferença entre uma aplicação transacional que funciona e outra que não serve para nada.

A cadeia de responsabilidades é muito útil em sistemas transacionais porque geralmente se tem tarefas enfileiradas. Uma das grandes vantagens de usar patterns bem conhecidos é que a equipe depois que entende o modelo, desenvolve as novas facilidades do sistema de modo semelhante ao que já foi feito, mesmo que os integrantes da equipe sejam outros.

Últimos conselhos:

  1. Aprender frameworks você pode fazer sozinho agora ou mais tarde. Aproveite seu ambiente de mestrado que melhor não podia ser para discutir coisas que só se aprende em faculdade. Por exemplo: neste seu projeto a diferença entre o sucesso (o cliente comprar o projeto) e o fracasso (o cliente não comprar a idéia) serão as argumentações do planejamento da capacidade. Discuta capacity planning. Para começar leia um livrinho bem fininho do Darci Prado sobre teoria das filas e da simulação. Depois como engenheiro encare Planejamento de capacidade para serviços web de Menascé e Almeida. Pode comprar em português que os próprios autores revisaram.

  2. Um item que esqueci de falar na minha outra mensagem ou falei pouco foi sobre segurança. Além de transmitir os dados criptografados é preciso armazenar os dados mais sensíveis também criptografados. Mas tudo isto de nada servirá se não houver segurança nos servidores. É preciso prever firewalls e ainda garantir a segurança física. Já imaginou se a noite entra um ladrão e rouba todos os computadores do site servidor central?

Bem, fico por aqui.

<editado>Depois que li que pretende desenvolver um novo framework ao invés de aprender um pronto. Se for para fins acadêmicos vá em frente mas saiba que na prática pode ser mais ou menos reinvenção da roda.</editado>

[]s
Luca

Obrigado Luca.
Suas dicas são ótimas.

Já estou providenciando o material sugerido para leitura. Até a próxima e parabéns!

Abcs
Felipe