1. Inicio
  2. Pregunta y respuesta
  3. Alternativas a NServiceBus que no usa MSMQ

Alternativas a NServiceBus que no usa MSMQ

2009-09-26 17 views
10

Creo que el título lo resume todo ... Tenemos un sistema .NET 2.0 que intenta implementar un pub/submodelo distribuido. Me encontré con NServiceBus, RhinoBus y MassTransit. Desafortunadamente, estos están basados ​​en MSMQ. Tengo la tarea de descubrir alternativas de pub/sub que usa una alternativa de mensajería diferente ...Alternativas a NServiceBus que no usa MSMQ

la única razón para buscar alternativas a MSMQ es superar la restricción del tamaño del mensaje. Desde nuestros mensajes de aplicaciones empresariales potencialmente pueden obtener truncada debido a la restricción por mensaje ...

ningún tipo de orientación es muy apreciada

Fuente

2009-09-26 G33kKahuna

+1

[MassTransit] (http://readthedocs.org/docs/masstransit/en/latest/) es compatible con RabbitMQ y AzureServiceBus. – Henrik

Respuesta

2

Hay una Roadmap para NServiceBus que los estados tienen la intención de ofrecer un transporte más enchufable para permitir alternativas a MSMQ.

MassTransit también sugieren que están apuntando a apoyar alternativas.

Desafortunadamente, ninguno de ellos está ahí todavía.

Fuente

2009-09-26 21:29:16 Duncan

-1

Utilizo un par de tablas de base de datos para esto.

Fuente

2009-09-28 18:42:33

+0

No creo que esto responda la pregunta ... – Henrik

+3

Claro que sí. Utilizo las tablas de la base de datos como colas persistentes para evitar tener que usar MSMQ. Funciona muy bien incluso con múltiples lectores y escritores. Las transacciones de base de datos proporcionan control de concurrencia. También proporcionan persistencia en caso de fallas del sistema. –

+1

Tendría que estar de acuerdo. Arrancamos una implementación de BizTalk de un minorista importante y la reemplazamos por tres tablas de SQL Server. Más simple y más barato. Obviamente, no estaban usando BizTalk por su funcionalidad. – Perhentian

0

Si tiene el presupuesto para ello, siempre puede usar Biztalk.

Si usted quiere hacer algo más interesante que podría utilizar Microsoft Azure servicio de autobuses http://www.microsoft.com/azure/servicebus.mspx

Usted podría utilizar corredor de servicio de SQL http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx. No estoy seguro de si hubo un plan para descontinuar esta finicidad.

O lo que quiere la cosa más simple que funciona, utilice una tabla de SQL :)

Fuente

2009-09-30 14:03:24

+0

Sus sugerencias parecen radicales; NServiceBus se anuncia como una plataforma para sincronizar y/o cargar caché InProc entre servidores. Mira los blogs de Udi Dahan. Azure y BizTalk son plataformas de mensajería entre sistemas; aka EDI y el primero hace un viaje de ida y vuelta a Microsoft ... :) MSMQ no es una solución empresarial escalable y confiable. Es ideal para pequeños movimientos de paquetes, pero no para datos de escala empresarial. Los desafíos varían desde la fragmentación del disco primario que afecta al sistema operativo, el sistema operativo bloquea el truncamiento del mensaje. SQLCE es una opción, pero ha demostrado ser un cuello de botella de rendimiento para las actividades de InProc. – G33kKahuna

+0

Sí, estoy de acuerdo que fue un poco radical, solo para darle una idea del alcance completo de las opciones. Si está buscando SQLCE, ¿está trabajando en dispositivos móviles? Si es así, eche un vistazo a Microsoft Sync Framework http://msdn.microsoft.com/en-us/sync/default.aspx –

+1

@ G33kKahuna: "MSMQ no es una solución empresarial escalable y confiable", ¿por qué cree eso? ¿Puedes señalarme en la dirección correcta algo que indique cuáles son sus límites? Actualmente estoy evaluando si MSMQ es adecuado para un proyecto y sería bueno saber más sobre esto. – adrianbanks

6

Heh, vieja pregunta, pero vale la pena mencionar que NServiceBus ahora es compatible con ActiveMQ (como una alternativa) con otros en desarrollo. También se ha hablado de implementar un "Bus de Datos" para superar la limitación del tamaño del mensaje, pero no sé el estado de esto.

La infraestructura está en su lugar para conectar diferentes transportes, y recuerdo haber visto discusiones sobre la utilización de Sql Server Service Broker, aunque no sé si alguna vez se tomó más allá de las discusiones iniciales.

Fuente

2010-11-05 17:46:04 ckramer

-2

Actualmente estoy trabajando en un bus de servicio basado en WCF de fuente abierta. Puede encontrarlo aquí: http://rockbus.codeplex.com/. Admite suscripciones dinámicas (@ tiempo de ejecución), repositorio de suscripciones (base de datos), transportes conectables, enrutamiento basado en contenido basado en XPath, entrega transaccional a través de protocolos wcf, entrega de redireccionamiento, evaluación de suscripción conectable y más. ¡Echar un vistazo!

Fuente

2011-06-29 06:48:20 Bram

+0

Sea cuidadoso al responder con respuestas idénticas; en estos dos casos específicos, parece estar en el lado seguro de la línea, pero no se exceda. Las respuestas deben abordar las preguntas individuales. ¡Gracias! – sarnold

1

Pregunta anterior pero vale la pena proporcionar una respuesta actualizada. Para aquellos que desarrollan aplicaciones de nivel empresarial, Windows Azure Service Bus realmente ha recorrido un largo camino desde su inicio y vale la pena mirar de cerca a cualquiera que esté interesado en implementar un modelo de pub/sub. Éstos son algunos aspectos destacados de Windows Azure Service Bus ...

  • incluye un Windows Azure Tools SDK for .Net lo que hace muy fácil el desarrollo en cualquier lenguaje .NET.

  • Hay un Explorer Tool que es una interfaz GUI que proporciona la facilidad de administrar y probar sus colas. Una versión está integrada en Visual Studio y otra es una aplicación independiente.

  • contiene tres modelos de mensajería

    • Relay - Diseñado para la comunicación entre aplicaciones en las instalaciones y aplicaciones en la nube
    • Pub/Sub - conocidos como "Temas" en Azure, que ofrece el modelo de publicación/suscripción de mensajes.
    • Corredores Mensajería: mensajes desacoplados donde el remitente y el receptor no tienen que estar en línea al mismo tiempo.

  • Soporta comportamiento transaccional (entrega de los mensajes guarateeed)

  • mejor de todo, Microsoft ve un futuro en la computación en nube lo que esto sólo va a mejorar.

  • La mayor desventaja de esta tecnología es que Windows Azure está diseñado para entornos empresariales a gran escala y, por lo tanto, es muy costoso.

Aquí es un buen sitio web que proporciona muchos más detalles acerca de las últimas capacidades de Windows Azure Service Bus

BTW: No estoy afiliado con Micrsoft de cualquier manera. Solo provengo de un contexto de uso de NServiceBus y me pareció muy fácil realizar la transición a Windows Azure Service Bus, ya que los modelos son similares.

Fuente

2012-09-11 04:10:22

Cuestiones relacionadas

 Cuestiones relacionadas