cómo implementar llamadas de servicio web idempotentes

Estoy desarrollando una solución basada en wcf para una capa de servicio web que utilizarán los dispositivos móviles "ocasionalmente conectados". El servicio no usará colas (en esta etapa) debido a las complejidades adicionales, por lo que en su lugar estará operando un enfoque simple de Solicitud / Respuesta.

Por supuesto, al ser un dispositivo móvil, es posible que los dispositivos se queden sin señal a mitad de la inserción / actualización. El servicio web en sí puede haber completado la transacción, pero el cliente nunca recibirá este mensaje. Debido a esto, reenviará la solicitud, momento en el cual el servidor debe reconocer esto como una solicitud duplicada y devolver la misma respuesta que intentó en primera instancia.

Por lo tanto, estoy tratando de hacer que los servicios sean Idempotentes. Para lograr esto, estoy implementando objetos DTO de parámetros de solicitud, que consisten en el RequestID, más los parámetros necesarios para completar la llamada.

Sin embargo, mi dificultad es implementar una forma de monitorear los identificadores de solicitud. Dado que el servicio no tiene estado actualmente, la única forma en que puedo imaginarlo es tener una tabla ServiceRequest en la base de datos, que tomará el RequestID como primario. Obviamente, consultar sobre esto indicará si la solicitud ya se ha procesado, ya que el cliente enviará el mismo RequestID. Pero el servicio también necesita saber qué mensaje devolver. En el caso de una inserción / actualización, el ID raíz agregado agregado también deberá almacenarse en algún lugar, ya sea directamente en la tabla de solicitud o en una tabla RequestToObjectLookup

Entonces, me pregunto si hay una mejor práctica para implementar esto. Mis pensamientos son tener una (s) tabla (s) de ServiceRequest (específica del servicio), que almacene requestids, información adicional y también una búsqueda del ID del objeto de resultado (en un guardar / insertar / actualizar). Entonces, cuando llega una nueva solicitud, esta tabla se puede consultar primero antes de continuar con el resto de la solicitud, ya sea para realizar el guardado o simplemente devolver el objeto actualizado anteriormente (que se realizó en el primer intento de solicitud).

También estoy pensando (como se dijo) que solo necesito mantener la identificación del agregado raíz referenciada con la solicitud, ya que solo debería poder usar las relaciones para obtener el resto de la información.

La eliminación puede hacerse idempotente al permitir solo la eliminación basada en ID. Deberá tener alguna forma para que las ID permanezcan "en uso" y tal vez caduquen.

Con tal sistema de reservas; La creación de un objeto se puede hacer reservando primero una ID y luego una segunda llamada para crear el objeto con esa ID (esencialmente una actualización del nuevo objeto vacío). Cuando se solicita una ID, el servidor tomará cualquier ID libre y creará un objeto no inicializado con esa ID, la segunda llamada para inicializar incluirá la ID devuelta previamente (más todos los datos requeridos). Esto significa que la segunda llamada es, en esencia, una llamada de actualización que es idem potente en sí misma (llamarla con los mismos datos varias veces dará como resultado el mismo resultado).

Si la reserva se produce varias veces, se devuelven varias ID y el objeto inicializado permanecerá. Estos objetos no inicializados pueden ser limpiados por un rhoomba después de un tiempo automáticamente.

Esto incumbe al cliente para asegurarse de que si obtienen una identificación, son responsables de llamar a la inicialización. Si el cliente se cae a mitad de la transacción, debe mantener su propio registro para las operaciones, de modo que sepa, por ejemplo, que obtuvo una identificación y que estaba ocupado inicializando el objeto.

La actualización es más difícil de hacer idempotente, pero una operación de comparación y configuración (con resultado verdadero / falso) ayudará.