Padrão de envio de mensagens e-commerce.

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!

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

SOAP - http://www.w3schools.com/soap/default.asp

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

cv wrote:BEA ____ (esqueci o nome),

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

cv wrote:Vale a pena, caso vc precise de confiabilidade e tenha uma boa
grana pra gastar em infra-estrutura (ActiveMQ eh opensource, mas ainda
assim...)

CV, para este projeto, por enquanto não tenho grana não, mas e quanto a
esse ActiveMQ? É bom? Estável?

Valew!

pcalcado wrote: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.

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

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

rborges wrote: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.

rborges wrote:
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.

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

rborges wrote: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$$$!!!!).

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.

rborges wrote:
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.

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.

rborges wrote:
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.

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.

rborges wrote:
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...

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

Notícias, artigos e o maior fórum brasileiro sobre Java