Olá pessoal,
estou desenvolvendo um projeto e-commerce em que um pedido deve ser
processado de forma rápida, quase que simultaneamente à sua requisição.
O pedido deve ser processado e entregue em cerca de 30 a 40 minutos.
Para obter essa velocidade, como a mensagem com o pedido deve ser
transmitida? Via e-mail? Ou existe algum tipo de arquitetura ou tecnologia que
me permita fazer esta tranmissão de forma bastante rápida?
Obrigado pela atenção.
Oi,
E-mail é besteira se você rpecisa de confiabilidade.
O seu sistema de pedidos precisa conversar com o outro ou apenas ter um setor de ‘adminsitração’? Se precisar conversar, procure sobre WebServices e SOAP, se apenas uma parte de adminsitração, guarde tudo no banco de dados mesmo e mostre ao seu adminsitrador 
[]s
Eu escolhendo a segunda opção, de guardar os meus pedidos em banco,
como faria para sempre ficar atualizando a lista de pedidos no meu setor de
administração? Ficaria fazendo consulta ao banco periodicamente?
E como implementar utilizando webservices? Tem algum material? Sou meio
leigo com webservices…
Obrigado!
Alexandre, nao esqueca de dar uma olhada na JMS e nos servidores de filas disponiveis por ai - ActiveMQ, IBM MQSeries, BEA ____ (esqueci o nome), Microsoft MSMQ e tal. Vale a pena, caso vc precise de confiabilidade e tenha uma boa grana pra gastar em infra-estrutura (ActiveMQ eh opensource, mas ainda assim…)
Bea MessageQ, brr…
Mas sim, a sugestão é boa.
Se você guardar seus pedidos em um banco de dados ou coisa que o valha, você vai ter uma tela, página, sei lá… que exibe os pedidos para ele. Para avisar que existem pedidos novos é que o bicho pega, você pdoe usar o e-mail, mas cai no problema do não poder confiar.
De repente é melhor você manter um aplicativo cliente rodando no computador do adminsitrador, que checa periodicamente sobre novos pedidos, fica escondido numa tray ou coisa assim.
[]s
Olá
Se não estou perdendo alguma coisa, seu problema é simples:
a) java dos 2 lados, isto é, java para fazer a requisição do pedido e java para processar o pedido
Envie o pedido zipado como mensagem http com URLConnection. Se não tem problemas com firewall, use sockets (SSL com JSSE). Se quer enviar logo o objeto todo use RMI (ou mesmo o zip do ObjectOutputStream). Importante: use transient para o campos que não precisam ser transmitidos.
b) java na requisição do pedido e qualquer outra coisa do outro lado
Chame um cara que conheça bem WebServices. Se vc não conhece nada, poderá levar uma boa surra até fazer funcionar com desempenho adequado.
Nos 2 casos persista as mensagens (além dos pedidos é claro) em uma base de dados para servir de log em caso de erro. Crie um mecanismo de reenvio de mensagem no caso de falha. Algo mais ou menos assim:
Protocolo de 3 pernas:
1 - envia a mensagem número tal
2 - recebe a confirmação
3 - envia ACK do recebimento da confirmação para o outro lado efetivar o pedido
Em caso de falhar alguma perna, reenvie a mensagem. Você precisará sequenciar as mensagens para saber exatamente qual falhou e que precisará ser reenviada.
É possível criar um protocolo de apenas 2 pernas. No Banco Postal fizemos assim. Mas em geral o de 3 pernas é mais comum.
A solução usando JMS é boa, inclusive pode contar com ajuda de Message Driven Beans que é o lado fácil dos EJBs. O outro lado pode também acessar o serviço de mensageria. Bem, a escolha vai depender dos recursos e do ambiente. Na base do cada caso é um caso.
[]s
Luca
[quote=“cv”]Vale a pena, caso vc precise de confiabilidade e tenha uma boa
grana pra gastar em infra-estrutura (ActiveMQ eh opensource, mas ainda
assim…)[/quote]
CV, para este projeto, por enquanto não tenho grana não, mas e quanto a
esse ActiveMQ? É bom? Estável?
Valew!
[quote=“pcalcado”]De repente é melhor você manter um aplicativo cliente
rodando no computador do adminsitrador, que checa periodicamente sobre
novos pedidos, fica escondido numa tray ou coisa assim.[/quote]
Esta era a minha opção, pois realmente eu terei um ambiente no lado
administrativo, que será feita a listagem dos pedidos que são feitos, para
serem processados, e estava pensando em algo do tipo…fazer a consulta
por novos pedidos de tempo em tempo(tipo, de 3 em 3 minutos)…
Gostaria de saber se essa é a melhor prática. Dessas citadas, qual vocês me
indicam com o melhor desempenho e performance? Quanto a aprender a tecnologia, no
caso de SOAP, tamos aki pra isso né não… 
:shock: :shock:
Obrigado.
Abraços!
Uma opção bem simples é construir uma pagina com JSP/Servlet ou Applet que verificasse isso no banco de dados, atraves da web mesmo. Voce manteria as maquinas numa mesma estrutura fisica e poderia apenas ter uma regra de IPFW para esse acesso ao banco de dados.
A solução com JMS é boa quando vc tem muitos servers ou estrutura complexa. Mas no seu caso vai ser apenas uma ponte desnecessaria para a consulta no banco.
Lembre-se… K.I.S.
Luca…
A sua solução é boa, mas acho que é muito dependente de infra. Isso é bom quando voce tem um fluxo de dados e um cenario que justifique toda essa programação. Lembre-se… É um sistema de e-commerce B2C e nao B2B.
[ ]'s
[quote=“rborges”]Uma opção bem simples é construir uma pagina com JSP/Servlet ou Applet que verificasse isso no banco de dados, atraves da web mesmo. Voce manteria as maquinas numa mesma estrutura fisica e poderia apenas ter uma regra de IPFW para esse acesso ao banco de dados.
A solução com JMS é boa quando vc tem muitos servers ou estrutura complexa. Mas no seu caso vai ser apenas uma ponte desnecessaria para a consulta no banco.
Lembre-se… K.I.S.[/quote]
[quote=“rborges”]
Luca…
A sua solução é boa, mas acho que é muito dependente de infra. Isso é bom quando voce tem um fluxo de dados e um cenario que justifique toda essa programação. Lembre-se… É um sistema de e-commerce B2C e nao B2B. [/quote]
Você esqueceu qeu o principal problema é que o tempo de resposta ao pdido deve ser muito pequeno. A menos que você faça constantes refreshs [uma abordagem meio gmail] na página e mantenha o navegador aberto, isto é um pé no saco.
Para mim esse papo de ‘cliente universal’ já deu no saco, é hroa de assumir que o browser é uma caca para aplicações que exijam um pouco mais.
Alexandre, se você vai usar Java nas duas pontas, esqueça SOAP. Vai ficar muito e desnecessariamente lento. Use algo binário, e aí um JMS pdoe realmente ajudar…
[]s
Mas se voce usar JMS voce precisar de um cliente local que mantenha uma conexao com o App Server… Isso quer dizer: Uma maquina no “DATACENTER” ou coisa parecida e uma maquina assistindo o PDV. Com isso voce ganha brinquedos novos como VPN, Link dedicado e outras coisas legais ( e caras$$$!!!).
Ao se optar por uma solução Web, voce pode fazer uma pagina com Applet/ Servlet que faça essas atualizações. E convenhamos: Uma pagina assim não é o fim do mundo, e colocando um pouco de cuidado se faz uma pagina bem elegante.
Soluções com JMS são boas quando se tem uma infra-estrutura distribuida. Quando se tem as maquinas na mesma infra fisica é besteira. Por isso no topico acima eu questionei o foco da applicação. É B2C e não B2C.
Sobre o navegador aberto, não sei a diferença entre um navegador e um client java puro… Afinal, são processos iguais para a maquina local…
[ ]'s
Olá
O sistema vai rodar todo na mesma rede local? O setor que faz a requisição está em rede local com o setor de expedição? Putz, se é assim tão simplório pode usar Clipper, VB, Delphi ou qq outra coisa. Grava as mensagens em um arquivo e a outra aplicação monitora o diretório para saber se chegou algo novo.
Se é um sistema onde quem faz o pedido está em local remoto e até eventualmente com um palm ou celular e a expedição está longe do servidor que recebe o pedido do vendedor na rua, então o KISS passa a ser “KISS Plus Plus With Atomic Messages”
[]s
Luca
[quote=“rborges”]Mas se voce usar JMS voce precisar de um cliente local que mantenha uma conexao com o App Server… Isso quer dizer: Uma maquina no “DATACENTER” ou coisa parecida e uma maquina assistindo o PDV. Com isso voce ganha brinquedos novos como VPN, Link dedicado e outras coisas legais ( e caras$$$!!!).
[/quote]
Uma palavrinha: assíncrono.
Outra coisa: nem você nem ninguem aqui sabe como é o ambiente dele, qauntos adminsitradores existem, sequer qual a verdadeira função da aplicação.
A página é o de menos, pode ser até em HTML 3, isso não é relevante. Só que vou fazer refresh à cada minuto? HTML não é a solução para todos os problemas do mundo, e o requisito não funcional exige algo mais controlável que um browser e HTTP.
Se vale a pena ou não, a escolha é de quem paga a conta.
Baseado nas idéias do Luca que de vez em quando pipocam no GUJ 
, o que é uma aplicação distribuída? Para mim quaqleur coisa que envolva mais de um nó é distribuído.
E JMS numa rede local não só não é besteira como é usado por aplicações muito pesadas, como cotnrole de SMS, redes GSM, etc, tudo em uma rede local. É um pouco mais complicado que HTTP, ams oferece muito mais vantagens.
Então não tem diferença entre roda um HSQLDB e um Oracle 10G full. Aidna qeu a aplicação tenha o overhead de uma JVM, o brwoser traz tanta budega quando levanta que não compensa. Fora o fato que eu não posso, normalmente, jogar o browser na system tray, ou fazer algo do tipo para não ficar aquele botão inútil na minha barra de tarefas.
Novamente: no silver bullets!
[]s
É… Acho que voce nao pegou o espirito da coisa… Mas tudo bem. É um erro achar que simples é feio… Pelo contrario… Simples é lindo!
Anyway, as soluções propostas são todas tecnicamente excelentes. Acho que agora cabe ao Alexandre ver do ponto de vista gerencial qual se adequa mais a necessidade dele. Nesse ponto as funções dos programadores acaba… 
Sniff…
Alexandre agora é contigo!
[ ]'s
Caro Pcalcado,
Acho que todos sabem que voce é bom… Não é isso que esta em discussão.
Sobre o Banco de Dados, ora ora ora… Nao vamos comparar bananas com alfaces… Controle emocional, mesmo em topicos, é sempre muito bem vindo. Flames não são produtivos.
O ponto não é ser simples ou não, mas sim atender ao requisito da melhor maneira. Após esta frase, se insere o “de forma mais simples possível”. Editar textos no emacs ou vi é lindo, simples, mas minha mãe odeia. Ela prefere a complexidade extrema de um editor parrudo destes, emsmo que para digitar texto sem formatação alguma.
Se ela é a cliente, você vai ter coragem de dizer que ela está erada?
[]s
Ok, PCalcado… Minha fase de discutir o sexo dos anjos ja passou…
Voce venceu. Comemore! ( Moet Chandon é uma boa pedida…)
You make the code, I take care of the money…
Ai ai… lá vamos nós…
Não entendi. Eut e ofendi? Se sim, me desculpe, não era minha intenção, mas eu estou defendendo meu ponto de vista.
[quote=“rborges”]
Sobre o Banco de Dados, ora ora ora… Nao vamos comparar bananas com alfaces… Controle emocional, mesmo em topicos, é sempre muito bem vindo. Flames não são produtivos.[/quote]
Bananas e alfaces são vegetais. Browsers e SGBDs são processos em um sistema operacional.
Lembra disso:
Acho que você comparou um browser à um cliente Java. Bananas, alfaces… como é que era mesmo a comparação?
Novamente desculpe-me se te ofendi, mas não creio que tenha escrito nada ofensivo.
[]s