WCF Pub/Sub con caché de suscriptor

Question

Problema: cómo proporcionar un servicio de pub/sub distribuido, escalable y resistente a desastres con WCF.

Detalles:

Tenga en cuenta que este enfoque se está considerando, además de soluciones de mensajería/middleware como TIBCO EMS.

He estado buscando en WCF, particularmente cómo se puede utilizar para ofrecer pub/sub. Sobre este tema, este artículo es muy bueno: WCF pub-sub.

En el artículo, el autor intenta abordar el problema de tener varios editores (como se hubiera hecho con una capa de servicio escalada en varios cuadros). El problema es que si el cliente A se registra con Publisher A pero Publisher B desea publicar un evento, entonces el editor B no sabrá sobre el cliente A. es decir, nadie le dijo al editor B que el cliente A quería recibir una notificación sobre los eventos. El autor sugiere un servicio pub/sub como una solución. El servicio pub/sub almacenaría suscripciones centralmente. Sin embargo, si quería hacer que el servicio de pub/sub resistente fuera resistente al tener un servicio secundario/dual de pub/sub, entonces tengo el mismo problema original.

Por lo tanto, creo que hay un par de soluciones al problema:

1. detalles tienda de abonado en una memoria caché distribuida (ver preguntas: q1 y q2).
2. Almacenar detalles del suscriptor en una base de datos/sistema de archivos central.

¿Alguien puede pensar en otras soluciones (es decir, no he echado de menos alguna característica fantástica mágica de WCF?) Cualquier comentario apreciados.

Answer 1

Tuve el mismo problema e investigué mucho sobre el tema. El problema es realmente simple. Desea mantener un estado centralizado, pero de forma distribuida. Descubrí que la mejor manera de lograr esto es mediante el uso de un caché distribuido. Mire la velocidad, por ejemplo. No existe una solución nativa de WCF que yo sepa que pueda resolver el problema de la administración del estado. Incluso he examinado los servicios duraderos, donde WCF maneja el estado, pero no es adecuado para un servicio pub/sub, porque el estado necesita centralizarse para todas las conexiones de los clientes. El almacenamiento de datos en una base de datos también es una opción, pero el costo es la necesidad de una base de datos, e incluso con una base de datos puede tener un único punto de falla si la base de datos no está agrupada por varias máquinas.

Al final, pensé que es realmente costoso implementar algo con cero puntos de falla y si decide ir allí, entonces eche un vistazo a Azure, el futuro del almacenamiento está en la nube, los servicios de Azure serán totalmente escalable y distribuido, pero aún no hemos llegado.

Answer 2

Creo que WCF simplemente no está allí todavía. Lo que necesita es un corredor que maneje todos estos detalles para que pueda implementar su lógica comercial. Hay algunos muy buenos como ActiveMQ. Si necesita orquestación, probablemente quiera utilizar un autobús que también se puede sentar encima de un intermediario. Creo que WCF es maravilloso, pero tratar de convertirlo en algo que no es, no es una buena idea.