¿Cuál es la mejor manera de hacer una conmutación por error sin conexión de un cliente basado en escritorio que utiliza un servicio web?

Tengo tres proyectos entrantes que comparten un problema común:

necesitan tener la lógica en un sistema web y necesitan una aplicación local (por ejemplo, un punto de venta) que se comunique con dicho sistema a través de un servicio web RESTful.

Mi solución

La solución que se me ocurrió es implementar en la cola de mensajes de la aplicación de escritorio para almacenar operaciones mientras el servicio está fuera de línea, más precisamente, la cola de mensajes asíncrona . Sin embargo, esa es la parte fácil (si tal es la mejor solución). También me preocupa la sincronización de datos y la resolución de conflictos.

El sistema principal debe estar basado en la web, ya que se requiere una aplicación web para los informes y el monitoreo por parte de las partes interesadas, y los servicios web manejarán las solicitudes de varios establecimientos.

Los clientes de escritorio (preferiblemente delgados) se implementarán con Java (más específicamente Netbeans) y el sistema web con Symfony2. Dos de los proyectos requieren integración de hardware para el cliente, por lo que la aplicación de escritorio con tecnología web (por ejemplo, Appcelerator Titanium) podría ser un gran problema.

Mi pregunta

¿Cuál es una mejor solución que escala, lo que significa la máxima eficiencia con el mínimo esfuerzo (y preferiblemente sin costos adicionales, como comprar un servidor de respaldo para la operación local)?
¿Quién más ha tratado esto antes? ¿Cómo resolviste tu problema? ¿Qué lecciones puedes compartir?
¿Cómo lidiaste con la sincronización?

Editar: se agregó una parte faltante a mi pregunta en el punto 3

— dukeofgaming
fuente

Respuestas:

Sé que su pregunta es Java, pero realmente me gusta esta arquitectura de estilo de bus de mensajes para este tipo de cosas.

Básicamente, cuando se envían mensajes, reciben potencialmente dos respuestas. El primero es del caché local, el segundo proviene del servidor una vez que se conecta.

Estoy bastante seguro de que podría adaptar esta arquitectura (bus rinoceronte y nhib) a la suya (MQ y hib) con bastante facilidad.

— Arroyo
fuente

Sí, estaba buscando exactamente ese tipo de arquitectura orientada a mensajes. Los argumentos de caché y la última oración en su enlace me convencieron.

— dukeofgaming

Haga todo localmente y sincronice periódicamente .

Esto es lo que haría si fuera usted (no conozco el marco de sincronización en Java como tenemos en .NET).

Mantenga una marca de tiempo en la aplicación local que se mantendrá la última vez que se conectó con éxito.

Independientemente del momento en que vuelva a conectarse, esa marca de tiempo se usará para extraer nuevos datos y luego enviar nuevos pedidos generados localmente.

Luego mantendrá dos marcas de tiempo. Uno para definir cuándo se creó el pedido (localmente o en línea) y otro cuando el servidor lo ha registrado.

No recomiendo Message Queue Server para eso. Utilicé MQ en el pasado para un sitio web de comercio electrónico que tenía que estar conectado a Navision. Todo fue operado dentro de Navision, y los cambios enviados al sitio web de comercio electrónico a través de MQ, incluido el estado del pedido y todo, incluidas las descripciones de productos, precios, etc. También se enviaron nuevos pedidos a Navision a través de MQ.

— Walter
fuente

Hmmm, me gusta la idea de un modelo push, sin embargo, veo el problema de que si se cambia el tiempo de la computadora podría haber pérdida de datos. Por cierto, tengo la convención de tener todos y cada registro de fecha y hora en mis diseños de base de datos. ¿Por qué no recomienda MQ?

— dukeofgaming

Así es, debe usar PC y UTC sincronizados con el tiempo, pero ahora es bastante estándar (al menos en Windows). MQ a veces es necesario, pero creo que sería demasiado para el tipo de aplicación que está desarrollando.

Bien, para priorizar la confiabilidad, es mejor pensar que la aplicación de escritorio se desconectará y, por lo tanto, es mejor tratar la aplicación de escritorio como un ciudadano de primera clase, sin embargo, todavía tengo la impresión de que MQ lo haría ser un reemplazo más fácil para la implementación de una base de datos local. Además, creo que hacer que todas las operaciones CRUD en el servidor implícitamente tenga una mejor seguridad. ¿Qué opinas de estos dos puntos?

— dukeofgaming

@dukeofgaming: en mi caso, los pedidos podrían tomarse desde cualquier punto de venta (también la aplicación podría usarse como un sistema de toma de pedidos y no como un sistema de procesamiento de pedidos), incluida la web. Todo se distribuyó por todo el país. Era absolutamente necesario que cada escritorio fuera autónomo en caso de desconexión. MQ también funcionaría en ese escenario, así que no estoy en contra. Simplemente siento que es más fácil implementar una sincronización de datos sólida entre los servidores maestros y los clientes. Por lo tanto, la operación CRUD en el servidor maestro no era una opción.

+1: así es como lo he visto en el pasado. También diría que el uso de uniqueidentifier (Guids) como claves primarias simplifica enormemente las cosas. Hacer eso es una de esas cosas que realmente te hacen la vida más fácil en el futuro si necesitas sincronización.

— Scott Whitlock

O bien, debe observar implementaciones de bases de datos de sistemas ocasionalmente conectadas que hacen el trabajo duro de sincronizar clientes remotos con el servidor. (SQL Server tiene esto con SQL CE hasta cierto punto, Outlook lo hace).

De esta manera, puede hacer todos sus cambios localmente en una pequeña base de datos de huella (mantiene versiones / marcas de tiempo lógicas, etc. para que no tenga que preocuparse por los relojes de la PC, etc.) y cada vez que se conecta, sincroniza esto con el principal servidor.

No buscaría una solución REST cuando el sistema no puede estar en línea la mayor parte del tiempo.

— Subu Sankara Subramanian
fuente

¿Estás describiendo una base de datos distribuida ?, ¿puedes dar más detalles al respecto?

— dukeofgaming

No, este no es un db distribuido en el sentido del mundo real. Una base de datos distribuida generalmente espera que casi todo esté en línea también, pero la lógica de replicación entre pares que se cayó también se aplica aquí. Hay algunas bases de datos de escritorio / dispositivo que tienen la facilidad de hacer el trabajo de replicación ( blogs.msdn.com/b/stevelasker/archive/2007/03/18/… ) - Entonces, todo lo que tiene que hacer es configurar este dispositivo db, registre sus cambios aquí y cuando se conecte a la red de la computadora, llame a la sincronización, y eso hará la transferencia de datos al servidor principal por usted.

— Subu Sankara Subramanian