¿Cómo asegurar la transferencia de mensajes por / pull de votación desde un servidor web

Question

Esto se basa en ¿Cómo enviar mensajes entre empresas . Si decido que la empresa S (upplier) debe sondear las órdenes de la empresa (B) de alguna manera sencilla HTTP basado cuál es la mejor aplicación.

• Asumo la empresa B tiene un servidor web corriendo y la base de datos back-end de este servidor web es duradera. Debemos hacer el menor número de posibles hipótesis acerca de los procesos de almacenamiento en S y si son capaces de mantener el estado (por ejemplo, una lista de GUID ya transmitidos)
• La conexión a Internet entre B y S no es fiable.
• Tenemos que llegar a consistencia eventual es decir en un momento dado en el tiempo entre todos los pedidos y B S debe ser transferido.

¿Cuál es la mejor práctica para implementar un sistema de este tipo?

Answer 1

Un enfoque para este tipo de problema es utilizar algún tipo de cola producto, como una persona IBM inmediatamente me considero MQ. Sin embargo, como no estoy realmente MQ persona a mí mismo, al igual que probablemente estaría feliz con enfoque basado en el servicio que usted está tomando.

Hay dos enfoques posibles que vienen a la mente. Uno es utilizar la mensajería fiable WS, que empuja el problema de fiabilidad hacia abajo en el servicio Web infraestructura. La otra es manivela su propio protocolo fiable en la parte superior de simple, pero poco fiable, los servicios.

No tengo serias experiencia práctica de implementar un sistema de mensajería fiable WS, yo creo que se puede hacer para el trabajo, pero sí requiere un cierto grado de control sobre los participantes - ya que es un nosotros estándar relativamente reciente no puede garantizar que cualquier dado tienda tendrá una implementación a mano, y la interoperabilidad entre los proveedores puede ser un problema. Cuanto más control que tengo sobre las pilas SW en cada extremo del más inclinado que sería el uso de WS mensajería fiable. [Debo mencionar WS Atómica Transacción también, que también puede ser usado para construir los servicios realiable, se aplican las mismas preocupaciones inter-op.]

¿Qué pasa con roll-su-propio? La clave aquí es hacer que todos los servicios de idempotente. Como no tenemos garantías de transacciones que abarcan los dos sistemas debemos asumir que cualquier llamada de servicio dado puede fallar con resultado desconocido.

Me voy a suponer que B quiere tener la confirmación de que S ha tomado un pedido, por lo tanto necesitamos información de actualización, tanto en B y S cuando una orden se transfiere.

B debe ofrecer servicios como los siguientes:

 Give me the next order(s)

 I have stored {orders ...}

Entonces, ¿cómo definimos "siguiente". El caso más simple funciona muy bien si los volúmenes que nos ocupan pueden nos permiten tener un único "hilo" de la transferencia. Entonces B no se detiene fuera de los pedidos enviados uno a la vez, y los pedidos tienen una monótona creciente identificación. entonces podemos simplificar a:

 I have stored order <65,004> please give me the next

Tenga en cuenta que se trata de una solicitud de idempotente: con seguridad se puede repetir muchas veces. También tenga en cuenta que S debe prever la posibilidad de conseguir el mismo orden dos veces, y comprobar si hay duplicados.

Answer 2

Lo que probablemente está buscando es dos fases. Está bien descrito en Internet, aquí por ejemplo:

http://en.wikipedia.org/wiki/Two-phase_commit_protocol

El quid de la cuestión:

El comprometen avanza el proceso como sigue:

* Phase 1
      o Each participating resource manager coordinates local 
        operations and forces all log records out:
      o If successful, respond "OK"
      o If unsuccessful, either allow a time-out or respond "OOPS" 
* Phase 2
      o If all participants respond "OK":
            * Coordinator instructs participating resource managers to "COMMIT"
            * Participants complete operation writing the log record
              for the commit 
      o Otherwise:
            * Coordinator instructs participating resource managers to "ROLLBACK"
            * Participants complete their respective local undos 

debería funcionar para cualquier tipo de datos.

Answer 3

Bien, en primer lugar no se puede garantía nada sobre un enlace fiable. Problema El dos generales demuestra esto para ambos protocolos deterministas y no deterministas. Todo lo que se puede hacer es mitigar la falta de fiabilidad a un grado aceptable.

El método más fácil es, en su caso, una vez que el servidor recibe una petición de sondeo, se envía el número de respuestas x, todos con el mismo GUID. Por ejemplo.

S: B, anything new?
S: B, anything new?
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
B: Yes, S, I need some shoes (order #124).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
B: Yes, S, I need some shoes (order #124).
S: B, anything new?
B: Yes, S, I need some shoes (order #124).
S: B, anything new?
B: Yes, S, I need some shoes (order #124).
...

S puede reciba correo basura con las órdenes, pero dado que el # se envía con cada solicitud, no es un gran problema. Si nos lo hemos perdido antes, nos estamos ahora. Si no conseguimos que antes, woohoo! Tenemos ahora. El sistema funciona! Se dará cuenta de que B envía mensajes 5 veces en mi ejemplo. En un escenario realista es probable que enviar un mensaje a cientos o miles de veces, hasta que tenga la fiabilidad deseada.

Ahora la solución anterior está procesando y gran ancho de banda, pero funciona. Un método más inteligente es hacer lo que hace TCP:. Tiene un apretón de manos de tres vías

S: Hello B. Are you there? -> SYN
B: Hello S, yep I'm here. What's up? -> SYN+ACK
S: Oh good, you're there. -> ACK
S: B, anything new?
B: Yes, S, I need a jacket (order #123).

Pero .. HTTP ya lo hace. Así que si hay algo que no llegar a algún lugar, usted sabrá. El tiempo de conexión, la conexión se rompió, etc.

Ahora, se puede volver a escribir estos escenarios dentro del nivel de aplicación (introducir WS-Reliable Messaging), pero en realidad TCP ya es fiable. Algunos críticos de estos marcos de jabón (ish) y faux-protocolos (que trabajan en la parte superior de HTTP por lo general) acusarlos de reinventar la rueda en esencia - y los problemas de la rueda -. En un nivel más alto de abstracción

La conclusión es que cualquier sistema puede fallar, incluyendo sistemas de mensajería fiables.

En lo que se refiere a la coherencia de eventos, creo que puede ser confundido. consistencia eventual sólo se aplica a los sistemas de almacenamiento distribuidos en los que después de un Write(), puede no ser capaz de recuperar de forma determinista con un Read() desde hace algún tiempo. Este no parece ser el problema en absoluto. Es decir, veo lo que está diciendo, pero en un sistema eventually consistent, se supone una (bastante) conexión fiable entre los nodos. Usted no hace esa suposición (a pesar de que creo que deberías .. TCP es bastante maldito fiable).

Answer 4

Sobre la base de lo que, dina mencionado. Webservices sería una solución perfecta para el problema anterior. Algunos protocolo puede ser acordado que definiría el número de registros.

S ---> D ( Call a service which would list record keys)
D----> S ( provide xml of keys)
S----> D ( Request each of the records)
D----> S ( Submit record)

En el caso de una nueva entrada de registro que se hizo después de la sincronización, el destino puede invocar un servicio desplegado en la fuente, que se ocuparía de un nuevo registro.

Ya que la comunicación se maneja comprar un motor de servicios web, usted no necesita preocuparse por los parámetros del mensaje. SSL puede ser añadido para la seguridad.

Saludos!

Answer 5

creo que está tratando de decir que la Compañía B es un participante pasivo. S (proveedor) sólo tiene la capacidad de obtener todas las órdenes que los puestos B (consistencia eventual). Pero B no necesita o no se preocupan por lo que los pedidos ya S tiene (sin necesidad de comprometerse).

Si la empresa B tiene un reloj semi-precisa, puede utilizar la fecha como el GUID monótonamente creciente, dependiendo de la resolución de los acontecimientos - que no querrá sondeo si necesita una resolución de milisegundos de todos modos. Sólo utilizar el reloj de B por lo que no tiene que preocuparse acerca de la sincronización. Si B publica todos los órdenes, S solo puede recoger los pedidos de donde se dejó la última vez.

No estoy seguro de si nos referimos mejores prácticas o mejores ventajas y desventajas para un sistema fácil de implementar. Dependiendo del volumen y tiempo de respuesta, no hay necesidad de que sea un sistema dinámico si está de todos modos de votación. Volcado de órdenes como archivos de texto (nombrados por fecha y hora) en un directorio indicado por la fecha y les tire todo abajo (o selectivamente). Incluso se puede almacenar en directorios por hora o lo que tenga sentido. HTTP GET es idempotente.

Esto puede ser feo, pero parece que no esperas mucho la complejidad de la empresa B. Usar SSL y autenticación y está bloqueado y cifrados.

Si usted no necesita el rendimiento no hay nada malo con sencillo. ¿Qué es lo que realmente obtiene de un protocolo complicado?