Cola en OneWay Mensajes WCF utilizando Windows Service y SQL Server

Necesito implementar un mecanismo de cola para las solicitudes de servicio WCF. El servicio será llamado por los clientes de una sola manera. Estos mensajes de solicitud se deben almacenar en una base de datos de SQL Server y un servicio de Windows pone en cola los mensajes. La hora en que se procesan las solicitudes será configurable. Si se produce un error al procesar el mensaje, debe volver a intentarlo hasta 100 veces y, si aún falla, debe finalizar.

También debería haber un mecanismo para controlar el número de transacciones realizadas en un día y el número de fallas.

PREGUNTAS

  1. Si estuviera usando MSMQ, los clientes podrían haber reenviado el mensaje a la cola sin conocer el punto final del servicio. Pero estoy usando SQL Server para almacenar los mensajes de solicitud. ¿Cómo pueden los clientes enviar las solicitudes a SQL Server?

  2. ¿Es la solución factible? ¿Tenemos algún artículo / libro que explique cómo implementar lo anterior?

  3. ¿Cuáles son los pasos para evitar que el servicio y el cliente lleguen a un estado fallado en este escenario?

  4. ¿Cuál es el mejor método para almacenar el mensaje entrante en la base de datos?

  5. ¿Cuál es el mejor método para implementar el mecanismo de rebash? ¿Ya existe algo para no tener que reinventar la rueda?

  6. ¿Hay algún libro / artículo que explique esta implementación?


NOTAS

  1. El contenido del mensaje será XML complejo. Por ejemplo, artículos de gastos de viaje de un empleado o una lista de empleados.

LEYENDO

  1. Registro de solicitud WCF a la base de datos

  2. Procesamiento garantizado de datos en el servicio WCF

  3. MSMQ contra SQL Server Service Broker

  4. ¿Es posible persistir y luego reenviar mensajes WCF a los servicios de destino?

  5. Servicio de enrutamiento WCF 4: problema de puente de protocolo

  6. https://softwareengineering.stackexchange.com/questions/134605/designing-a-scalable-and-robust-retry-mechanism

  7. Integrando SQL Service Broker y NServiceBus

  8. ¿Puede un suscriptor también publicar / enviar mensajes en NServiceBus?

Soy un DBA, por lo que saborea mi respuesta, pero esto es lo que haría:

  1. Si usa SQL 2005+, use Service Broker para almacenar los mensajes en la base de datos en lugar de almacenarlos en una tabla. Obtiene un mecanismo de cola con esto, por lo que puede deshacerse de MSMQ. También tendrá una tabla, pero solo almacenará el identificador de la conversación (esencialmente, un puntero al mensaje) junto con la cantidad de veces que intentó este mensaje. Por último, querrá una especie de “buzón de correo muerto” donde irán los mensajes que scopen su umbral de rebash.
  2. En su código de procesamiento de mensaje, haga lo siguiente:
    • Comience una transacción
    • Recibe un mensaje fuera de la cola
    • Si el recuento de rebashs es mayor que el umbral, muévalo al cuadro de letra muerta y comprométalo
    • Incrementa el contador en la tabla para este mensaje
    • Procesar el mensaje
    • Si el proceso tuvo éxito, comprometa la transacción
    • Si el proceso falló, coloque un nuevo mensaje en la cola con los mismos contenidos y luego confirme la transacción.

Tenga en cuenta que no hay reversiones planificadas. Las reversiones en Service Broker pueden ser malas; si revierte 5 veces sin una recepción exitosa, la cola quedará deshabilitada tanto para la puesta en cola como para la eliminación. Pero aún desea tener transacciones para el caso cuando el procesador de mensajes muere en el medio del procesamiento (es decir, el servidor se bloquea).

1. Si estuviera usando MSMQ, los clientes podrían haber reenviado el mensaje a la cola sin conocer el punto final del servicio.

Sí, pero tendrían que conocer el punto final MSMQ para enviar su mensaje a la cola …..

Pero estoy usando SQL Server para almacenar los mensajes de solicitud. ¿Cómo pueden los clientes enviar las solicitudes a SQL Server?

Los clientes no ingresarán sus solicitudes en SQL Server; eso es lo que hará el servicio en el servidor. El cliente simplemente llama a un método de servicio, y el código allí almacenará la solicitud en la tabla de SQL Server.

2. ¿Es la solución factible? ¿Tenemos algún artículo / libro que explique cómo implementar lo anterior?

Claro, no veo ningún gran problema. El único punto que no me queda claro ahora es: ¿cómo sabrán los clientes sus resultados? ¿Necesitan obtener resultados de otro servicio o algo así?

3. ¿Cuáles son los pasos para evitar que el servicio y el cliente lleguen a un estado fallado en este escenario?

Como siempre, solo asegúrese de que su código de servicio capte todas las excepciones y las maneje internamente, o devuelva fallas SOAP interoperables en lugar de excepciones .NET.

Parece que lo que quieres hacer es similar a esto:

enter image description here

En este caso, puede usar netMsmqBinding entre su servicio y los consumidores de su servicio.

Lo único que no saldrá de la caja es volver a intentarlo. Sin embargo, si hace que la cola sea transaccional, esta funcionalidad puede implementarse en su código de servicio.

Si hay una falla en su operación de dequeue, el mensaje no se eliminará de la cola. Por lo tanto, estará disponible para futuros bashs de dequeue.

Sin embargo, necesitaría implementar un código de umbral de bash de rebash que falla un mensaje después de un cierto número de bashs.

Sugeriría un enfoque diferente a los sugeridos aquí. Si puede hacerlo, consideraría la introducción de un marco de mensajería como NServiceBus . Satisface muchos de los requisitos que tiene listos para usar. Permítanme tratar de abordar esto en el contexto de sus requisitos.

El servicio será llamado por los clientes de una sola manera.

Toda la comunicación entre los puntos finales en NServiceBus es de una sola manera. El transporte subyacente que NServiceBus usa es MSMQ, al igual que su enfoque WCF, su cliente se está comunicando con colas, en lugar de puntos finales de servicio específicos.

Estos mensajes de solicitud se deben almacenar en una base de datos de SQL Server y un servicio de Windows pone en cola los mensajes.

Si desea almacenar sus mensajes de solicitud en una base de datos, puede configurar NServiceBus para reenviar todos los mensajes enviados a su solicitud de punto final de procesamiento a otra cola de “auditoría”, que puede usar para mantener la base de datos. Esto tiene el beneficio adicional de separar la lógica de la aplicación de la implementación de auditoría.

La hora en que se procesan las solicitudes será configurable.

NServiceBus le permite diferir cuando se envía un mensaje. Normalmente, se envía un mensaje a través del método Send de una instancia de Bus – Bus.Send (msg). Puede usar el método Defer para enviar el mensaje en el futuro, por ejemplo. Bus.Defer (DateTime.Now.AddDays (1), msg); No hay nada más que realmente deba hacer, NserviceBus manejará el mensaje una vez que se haya alcanzado el tiempo especificado.

Si se produce un error al procesar el mensaje, debe volver a intentarlo hasta 100 veces y, si aún falla, debe finalizar.

Por defecto, NServiceBus activará su mensaje en una transacción tan pronto como su mensaje salga de la cola. Esto garantiza que, en caso de error, el mensaje se retrotrae a la cola de origen. En tal caso, NServiceBus intentará reprocesar el mensaje automáticamente una cantidad configurable de veces. El valor predeterminado es 5. Por supuesto, puedes configurar esto para lo que quieras, aunque no estoy seguro de por qué querrías configurar esto en 100. En cualquier caso, NServiceBus usa esta configuración para detener un ciclo interminable de rebashs automáticos. Una vez que se ha alcanzado el límite, el mensaje se envía a una cola de errores donde se encuentra hasta que solucione los problemas que causaron la excepción o hasta que decida volver a enviar el mensaje a la cola para su procesamiento. De cualquier manera, tiene la seguridad de que el mensaje nunca se pierde.

También debería haber un mecanismo para controlar el número de transacciones realizadas en un día y el número de fallas.

La belleza de usar MSMQ como transporte es que la monitorización del rendimiento puede lograrse a nivel de infraestructura. El rendimiento de sus aplicaciones se puede medir por cuánto tiempo permanecen en la cola. NServiceBus viene con monitores de rendimiento que registran el tiempo que un mensaje está en la cola y también puede agregar percusiones incorporadas en Windows para rastrear otras actividades. Para controlar los errores, todo lo que necesita hacer es verificar la cantidad de mensajes en la cola de errores.

Una de las principales características de NServiceBus es la fiabilidad. WCF solo hará tanto por ti, y luego estarás solo. Eso es mucho código, complejidad y, francamente, enormemente propenso a errores. Las cosas que he descrito aquí son todas características estándar de NServiceBus y apenas he arañado la superficie con todas las demás cosas que puedes hacer con ella. Te recomiendo echarle un vistazo.