1. casa
  2. Domanda e risposta
  3. Alternative a NServiceBus che non utilizzano MSMQ

Alternative a NServiceBus che non utilizzano MSMQ

2009-09-26 15 views
10

Penso che il titolo riassuma tutto ... Abbiamo un sistema .NET 2.0 che tenta di implementare un modello di pubblicazione/sub distribuito. Ho incontrato NServiceBus, RhinoBus e MassTransit. Sfortunatamente, questi sono basati su MSMQ. Ho il compito di capire alternative pub/sub che utilizzano alternative di messaggistica diverse ...Alternative a NServiceBus che non utilizzano MSMQ

l'unica ragione per cercare alternative MSMQ è superare la restrizione delle dimensioni dei messaggi. Dal momento che i nostri messaggi enterprise app possono potenzialmente ottenere troncata a causa di restrizione per il messaggio ...

alcuna guida è molto apprezzato

fonte

2009-09-26 G33kKahuna

+1

[MassTransit] (http://readthedocs.org/docs/masstransit/en/latest/) supporta RabbitMQ e AzureServiceBus. – Henrik

risposta

2

C'è un Roadmap per NServiceBus che afferma che intendono offrire un trasporto più pluggable per consentire alternative alla MSMQ.

Anche MassTransit suggerisce di mirare a supportare alternative.

Purtroppo nessuno di questi ci sono ancora.

fonte

2009-09-26 21:29:16 Duncan

-1

Io uso un paio di tabelle di database per questo.

fonte

2009-09-28 18:42:33

+0

Non credo che questo risponda alla domanda ... – Henrik

+3

Certo che lo fa. Uso le tabelle del database come code persistenti per evitare di dover utilizzare MSMQ. Funziona molto bene anche con più lettori e scrittori. Le transazioni di database forniscono il controllo della concorrenza. Forniscono anche la persistenza in caso di crash del sistema. –

+1

Dovrei essere d'accordo. Abbiamo strappato un'implementazione di BizTalk da un importante rivenditore e l'ho sostituita con tre tabelle di SQL Server. Più semplice ed economico. Ovviamente non stavano usando BizTalk per tutte le sue funzionalità. – Perhentian

0

Se si dispone del budget, è sempre possibile utilizzare Biztalk.

Se si vuole fare qualcosa di più interessante che si potrebbe utilizzare Microsoft Azure Service Bus http://www.microsoft.com/azure/servicebus.mspx

È possibile utilizzare il servizio di SQL Broker http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx. Non sono sicuro se ci fosse un piano per interrompere questa finzionalità.

Oppure si desidera la cosa più semplice che funziona, utilizzare una tabella di SQL :)

fonte

2009-09-30 14:03:24

+0

I tuoi suggerimenti sembrano radicali; NServiceBus è pubblicizzato come piattaforma per sincronizzare e/o caricare la cache InProc tra i server. Dai un'occhiata ai blog di Udi Dahan. Azure e BizTalk sono piattaforme di messaggistica tra sistemi; alias EDI e il primo fa un viaggio di andata e ritorno a Microsoft ... :) MSMQ non è una soluzione aziendale scalabile e affidabile. È ottimo per piccoli movimenti di pacchetti, ma non per dati di scala aziendale. Le sfide variano dalla frammentazione del disco primaria che interessa il sistema operativo, i blocchi del sistema operativo fino al troncamento dei messaggi. SQLCE è un'opzione ma si è dimostrato un collo di bottiglia per le prestazioni delle attività InProc. – G33kKahuna

+0

Sì, sono d'accordo che era un po 'radicale, volevo solo darti un'idea della gamma completa di opzioni. Se stai guardando SQLCE, stai lavorando su dispositivi mobili? Se è così, date un'occhiata a Microsoft Sync Framework http://msdn.microsoft.com/en-us/sync/default.aspx –

+1

@ G33kKahuna: "MSMQ non è una soluzione aziendale scalabile e affidabile" - perché la pensi così? Puoi indicarmi la giusta direzione verso qualcosa che indichi quali sono i suoi limiti? Attualmente sto valutando se MSMQ è adatto per un progetto e sarebbe bello sapere di più su questo. – adrianbanks

6

Eh, vecchia domanda, ma vale la pena ricordare che NServiceBus supporta ora ActiveMQ (come alternativa) con altri in fase di sviluppo. Si è anche parlato di implementare un "bus dati" per superare la limitazione della dimensione dei messaggi, ma non conosco lo stato di questo.

L'infrastruttura è in atto per collegare diversi trasporti, e ricordo di aver visto discussioni sull'utilizzo di Sql Server Service Broker, anche se non so se questo è mai stato portato oltre le discussioni iniziali.

fonte

2010-11-05 17:46:04 ckramer

-2

Attualmente sto lavorando su un bus di servizio basato su WCF open source. Puoi trovarlo qui: http://rockbus.codeplex.com/. Supporta sottoscrizioni dinamiche (@ run-time), repository di subcription (database), trasporti a innesto, routing basato sul contenuto basato su XPath, consegna transazionale su protocolli wcf, consegna roundrobin, valutazione di sottoscrizioni a innesto e altro. Dare un'occhiata!

fonte

2011-06-29 06:48:20 Bram

+0

Fai attenzione a rispondere con le stesse risposte; in questi due casi specifici, sembra solo sul lato sicuro della linea, ma non esagerare. Le risposte dovrebbero indirizzare le singole domande. Grazie! – sarnold

1

Vecchia domanda, ma vale la pena di fornire una risposta aggiornata. Per coloro che sviluppano applicazioni di livello enterprise, il Service Bus di Windows Azure ha davvero fatto molta strada sin dal suo inizio e vale la pena dare un'occhiata da vicino a chiunque sia interessato a implementare un modello di pubblicazione/sottotitolo. Ecco alcuni punti salienti di Windows Azure Service Bus ...

  • include un Windows Azure Tools SDK for .Net che rende lo sviluppo molto facile in qualsiasi linguaggio .NET.

  • C'è uno Explorer Tool che è un'interfaccia GUI che fornisce facilità di gestione e test delle code. Una versione è integrata direttamente in Visual Studio e un'altra è un'applicazione autonoma.

  • contiene tre modelli di messaggistica

    • Relay - progettato per comunicare tra le applicazioni on-premise e applicazioni cloud
    • Pub/Sub - noto come "argomenti" di Azure, fornisce il modello publish/subscribe di messaggistica.
    • Broker Messaggistica - messaggistica disaccoppiata in cui il mittente e il ricevitore non devono essere online contemporaneamente.

  • Supporta comportamento transazionale (consegna guarateeed di messaggi)

  • Meglio di tutti, Microsoft vede un futuro nel cloud computing in modo da questo sarà solo migliorare.

  • Il più grande svantaggio di questa tecnologia è che Windows Azure è progettato per ambienti aziendali su larga scala e pertanto è molto costoso.

Ecco un buon sito web che fornisce dettagli molto di più sulle ultime funzionalità di Windows Azure Service Bus

BTW: Io non sono affiliato con Micrsoft in alcun modo. Sono appena tornato da un passato di utilizzo di NServiceBus e ho trovato molto semplice la transizione a Windows Azure Service Bus in quanto i modelli sono simili.

fonte

2012-09-11 04:10:22

Problemi correlati

 Problemi correlati