Qual é a melhor maneira de fazer failover offline de um cliente baseado em desktop que usa um serviço da Web?

Tenho três projetos recebidos que compartilham um problema comum:

eles precisam ter a lógica em um sistema web e precisam de um aplicativo local (por exemplo, ponto de venda) que se comunique com esse sistema por meio de um serviço web RESTful.

Minha solução

A solução que eu consegui encontrar é implementar no serviço de enfileiramento de mensagens do aplicativo de desktop para armazenar operações enquanto o serviço está offline, mais precisamente, enfileiramento de mensagens assíncrono . No entanto, essa é a parte mais fácil (se essa for a melhor solução). Também estou preocupado com a sincronização de dados e resolução de conflitos.

O sistema principal precisa ser baseado na Web, já que um aplicativo da Web é necessário para relatórios e monitoramento pelas partes interessadas, e os serviços da Web lidam com solicitações de vários estabelecimentos.

Os clientes de desktop (preferencialmente thin) serão implementados com Java (mais especificamente Netbeans) e o sistema web com Symfony2. Dois dos projetos exigem integração de hardware para o cliente, portanto, tornar o aplicativo de desktop com tecnologia da Web (por exemplo, Appcelerator Titanium) pode ser um grande problema.

Minha pergunta

Qual é a melhor solução escalável, significando eficiência máxima com o mínimo de esforço (e de preferência sem custos adicionais, como a compra de um servidor de backup para operação local)?
Quem mais já lidou com isso antes? Como você resolveu seu problema? Que lições você pode compartilhar?
Como você lidou com a sincronização?

Editar: adicionada uma peça que faltava à minha pergunta no ponto 3

— dukeofgaming
fonte

Respostas:

Eu sei que sua pergunta é java, mas eu realmente gosto dessa arquitetura de estilo de barramento de mensagens para esse tipo de coisa.

Basicamente, quando as mensagens são enviadas, elas recebem potencialmente duas respostas. O primeiro é do cache local, o segundo vem do servidor quando ele é conectado.

Tenho certeza de que você pode adaptar essa arquitetura (rhino bus e nhib) à sua (MQ e hib) com bastante facilidade.

— Ribeiro
fonte

Sim, eu estava procurando exatamente esse tipo de arquitetura orientada a mensagens. Os argumentos do cache e a última frase do seu link me convenceram.

— Dukeofgaming

Faça tudo localmente e sincronize periodicamente .

Aqui está o que eu faria se fosse você (não estou ciente da estrutura de sincronização em Java como temos no .NET).

Mantenha um registro de data e hora no aplicativo local que reterá a última vez que você se conectou com sucesso.

Independentemente da hora em que você se reconectar, esse registro de data e hora será usado para extrair novos dados e enviar novos pedidos gerados localmente.

Você manterá dois carimbos de data e hora. Um para definir quando o pedido foi criado (local ou online) e outro para quando foi gravado pelo servidor.

Eu não recomendo o serviço de enfileiramento de mensagens para isso. Eu usei o MQ no passado para um site de comércio eletrônico que precisava ser conectado ao Navision. Tudo foi operado dentro da Navision, e as alterações foram enviadas ao site de comércio eletrônico através do MQ, incluindo o status do pedido e tudo, incluindo descrições de produtos, preços, etc. Novos pedidos também foram enviados à Navision pelo MQ.

— Walter
fonte

Hmmm, eu gosto da idéia de um modelo push, mas vejo o problema de que, se o tempo do computador for alterado, pode haver perda de dados. BTW, eu tenho a convenção de ter cada registro de data e hora estampado nos meus designs de banco de dados. Por que você não recomenda o MQ?

— Dukeofgaming

É isso mesmo, você deve usar PCs e UTC sincronizados no tempo, mas agora é bastante padrão (pelo menos no Windows). Às vezes, o MQ é necessário, mas acho que seria demais para o tipo de aplicativo que você está desenvolvendo.

Ok, então, para priorizar a confiabilidade, é melhor pensar que o aplicativo de desktop será desconectado e, portanto, é melhor tratá-lo como um cidadão de primeira classe. No entanto, ainda tenho a impressão de que o MQ ser um substituto mais fácil para uma implementação de banco de dados local. Além disso, acho que fazer todas as operações CRUD no servidor implicitamente tem melhor segurança. O que você acha desses dois pontos?

— Dukeofgaming

@dukeofgaming: no meu caso, os pedidos podem ser retirados de qualquer POS (também o aplicativo pode ser usado como um sistema de recebimento de pedidos e não como um sistema de processamento de pedidos), incluindo a web. Tudo foi distribuído pelo país. Era absolutamente necessário que todos os computadores fossem autônomos em caso de desconexão. O MQ também funcionaria nesse cenário, então não sou contra. Apenas sinto que é mais fácil implementar uma sincronização de dados forte entre servidores e clientes principais. Portanto, a operação CRUD no servidor mestre não era uma opção.

+1 - é assim que eu já vi isso no passado. Eu diria também que o uso do uniqueidentifier (Guids) como chaves primárias simplifica imensamente as coisas. Fazer isso é uma daquelas coisas que realmente facilita sua vida no futuro, se você precisar de sincronização.

— Scott Whitlock

Ou você deve observar implementações de bancos de dados de sistemas conectados ocasionalmente, que fazem o trabalho pesado de sincronizar clientes remotos com o servidor. (O SQL Server possui isso com o SQL CE até certo ponto, o Outlook faz isso).

Dessa forma, você pode fazer todas as alterações localmente em um banco de dados pequeno (ele mantém registros de data / hora lógicos etc.) para que você não precise se preocupar com relógios de PC etc.) e sempre que estiver on-line, sincronize-o com os principais servidor.

Eu não aceitaria uma solução REST quando o sistema não puder ficar online a maior parte do tempo.

— Subu Sankara Subramanian
fonte

Você está descrevendo um banco de dados distribuído ?, pode elaborar isso?

— Dukeofgaming

Não - este não é um banco de dados distribuído no sentido do mundo real. Um banco de dados distribuído normalmente espera que quase tudo também esteja online, mas a lógica da replicação entre os pares que foram desativados também se aplica aqui. Existem alguns bancos de dados de desktop / dispositivo que têm a facilidade de executar o trabalho de replicação ( blogs.msdn.com/b/stevelasker/archive/2007/03/18/… ) - Portanto, tudo o que você precisa fazer é configurar este dispositivo db, registre suas alterações aqui e, quando você se conectar à rede de computadores, chame a sincronização - e isso fará a transferência de dados para o servidor principal.

— Subu Sankara Subramanian