1. Zuhause
  2. Frage und Antwort
  3. Alternativen zu NServiceBus, die MSMQ nicht verwendet

Alternativen zu NServiceBus, die MSMQ nicht verwendet

2009-09-26 7 views
10

Ich denke, der Titel fasst alles zusammen. Wir haben ein .NET 2.0-System versuchen, ein verteiltes Pub/Sub-Modell zu implementieren. Ich stieß auf NServiceBus, RhinoBus und MassTransit. Leider basieren diese auf MSMQ. Ich bin beauftragt, herauszufinden, Pub/Sub-Alternativen, die eine andere Messaging-Alternativen verwendet ...Alternativen zu NServiceBus, die MSMQ nicht verwendet

der einzige Grund für die Suche nach MSMQ Alternativen ist die Nachrichtengröße Einschränkung zu überwinden. Da unser Unternehmen App-Nachrichten möglicherweise abgeschnitten werden kann aufgrund pro Nachricht Einschränkung ...

jeder Führung ist viel

Quelle

2009-09-26 G33kKahuna

+1

[MassTransit] (http://readthedocs.org/docs/masstransit/en/latest/) unterstützt RabbitMQ und AzureServiceBus. – Henrik

Antwort

2

geschätzt Es gibt eine Roadmap für NServiceBus ist, dass sie eine steckbare Transport zu ermöglichen, Alternativen zu bieten Staaten beabsichtigen, zu MSMQ.

MassTransit schlägt auch vor, dass sie Alternativen unterstützen wollen.

Leider ist keiner von diesen noch da.

Quelle

2009-09-26 21:29:16 Duncan

-1

Ich benutze ein paar Datenbanktabellen dafür.

Quelle

2009-09-28 18:42:33

+0

Ich glaube nicht, dass dies die Frage beantwortet ... – Henrik

+3

Sicher tut es. Ich verwende Datenbanktabellen als persistente Warteschlangen, um die Verwendung von MSMQ zu vermeiden. Es funktioniert sehr gut sogar mit mehreren Lesern und Schreibern. Datenbanktransaktionen ermöglichen die Steuerung des gemeinsamen Zugriffs. Sie bieten auch Beständigkeit bei Systemabstürzen. –

+1

Ich würde zustimmen müssen. Wir haben eine BizTalk-Implementierung von einem großen Einzelhändler herausgerissen und durch drei SQL Server-Tabellen ersetzt. Einfacher und billiger. Offensichtlich verwendeten sie BizTalk nicht für all seine Funktionalität. – Perhentian

0

Wenn Sie das Budget dafür haben, können Sie immer BizTalk verwenden.

Wenn Sie etwas Interessantes tun möchten Sie Microsoft Azure Service Bus http://www.microsoft.com/azure/servicebus.mspx

Sie könnten http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx verwenden SQL-Service-Broker nutzen könnten. Nicht sicher, ob es einen Plan gab, diese Funktionalität zu beenden.

Oder wollen Sie die einfachste Sache, die, verwenden Sie eine SQL-Tabelle funktioniert :)

Quelle

2009-09-30 14:03:24

+0

Ihre Vorschläge scheinen radikal zu sein; NServiceBus wird als eine Plattform zum Synchronisieren und/oder Laden von InProc-Cache zwischen Servern beworben. Sieh dir die Blogs von Udi Dahan an. Azure und BizTalk sind Intersystem-Messaging-Plattformen. aka EDI und ersteres macht eine Rundreise zu Microsoft ... :) MSMQ ist keine skalierbare und zuverlässige Unternehmenslösung. Es eignet sich hervorragend für kleine Paketbewegungen, jedoch nicht für unternehmensweite Daten. Die Probleme variieren von der primären Datenträgerfragmentierung, die sich auf das Betriebssystem auswirkt, Betriebssystemsperren bis hin zur Nachrichtenabkürzung. SQLCE ist eine Option, hat sich jedoch als ein Leistungsengpass für InProc-Aktivitäten erwiesen. – G33kKahuna

+0

Ja, ich stimme zu, es war ein bisschen radikal, nur um Ihnen eine Vorstellung von dem vollen Umfang an Optionen zu geben. Wenn Sie SQLCE betrachten, arbeiten Sie an mobilen Geräten? Wenn ja, schauen Sie sich Microsoft Sync Framework an http://msdn.microsoft.com/en-us/sync/default.aspx –

+1

@ G33kKahuna: "MSMQ ist keine skalierbare und zuverlässige Unternehmenslösung" - warum denken Sie das? Kannst du mir in die richtige Richtung zeigen, was seine Grenzen sind? Ich evaluiere derzeit, ob MSMQ für ein Projekt geeignet ist oder nicht, und es wäre gut, mehr darüber zu erfahren. – adrianbanks

6

Heh, alte Frage, aber erwähnenswert, dass NServiceBus jetzt ActiveMQ (als eine Alternative) mit anderen in der Entwicklung unterstützt. Es wurde auch über die Implementierung eines "Datenbusses" gesprochen, um die Begrenzung der Nachrichtengröße zu überwinden, aber ich weiß den Status davon nicht.

Die Infrastruktur ist in der Lage, verschiedene Transporte zu verbinden, und ich erinnere mich, Diskussionen über Sql Server Service Broker zu sehen, obwohl ich nicht weiß, ob das jemals über die ersten Diskussionen hinaus genommen wurde.

Quelle

2010-11-05 17:46:04 ckramer

-2

Ich arbeite derzeit an einem Open-Source-WCF-basierten Service-Bus. Sie können es hier finden: http://rockbus.codeplex.com/. Es unterstützt dynamische (@ run-time) Subskriptionen, Subscription-Repository (Datenbank), steckbare Transporte, XPath-basiertes inhaltsbasiertes Routing, transaktionale Zustellung über WCF-Protokolle, Roundrobin-Bereitstellung, Plug-in-fähige Subscription-Auswertung und mehr. Guck mal!

Quelle

2011-06-29 06:48:20 Bram

+0

Seien Sie vorsichtig mit identischen Antworten zu antworten; In diesen beiden spezifischen Fällen scheint es nur auf der sicheren Seite der Linie zu sein, aber gehen Sie nicht über Bord. Antworten sollten auf die einzelnen Fragen eingehen. Vielen Dank! – sarnold

1

Alte Frage, aber es lohnt sich, eine aktuelle Antwort zu liefern. Für diejenigen, die Anwendungen auf Unternehmensebene entwickeln, hat Windows Azure Service Bus seit seiner Einführung wirklich einen langen Weg zurückgelegt, und es lohnt sich, einen Blick auf jeden zu werfen, der daran interessiert ist, ein Pub/Sub-Modell zu implementieren. Hier sind einige Highlights von Windows Azure Service Bus ...

  • Enthält eine Windows Azure Tools SDK for .Net die Entwicklung sehr einfach in jeder .NET-Sprache macht.

  • Es gibt eine Explorer Tool, die eine GUI-Schnittstelle bietet, die das Verwalten und Testen Ihrer Warteschlangen erleichtert. Eine Version ist direkt in Visual Studio integriert und eine andere ist eine eigenständige Anwendung.

  • Enthält drei Messaging Modelle

    • Relay - Designed zwischen On-Premise-Anwendungen und Cloud-Anwendungen
    • Pub/Sub-Kommunikation - Bekannt als "Themen" in Azure, den Publish/Subscribe bietet Modell von Messaging.
    • Broker Messaging - entkoppeltes Messaging, bei dem Sender und Empfänger nicht gleichzeitig online sein müssen.

  • Transaktionsverhalten Unterstützt (guarateeed Zustellung von Nachrichten)

  • Best of all, sieht Microsoft eine Zukunft im Bereich Cloud Computing so dass diese nur noch besser werden.

  • Der größte Nachteil dieser Technologie ist, dass Windows Azure für große Unternehmensumgebungen konzipiert ist und daher sehr teuer ist.

Hier ist eine gute Website, die viel mehr Details über die neuesten Möglichkeiten von Windows Azure Service Bus

BTW bietet: Ich kann nicht mit Micrsoft in irgendeiner Art und Weise verbundenen bin. Ich komme nur aus dem Hintergrund der Verwendung von NServiceBus und fand es sehr einfach, zu Windows Azure Service Bus zu wechseln, da die Modelle ähnlich sind.

Quelle

2012-09-11 04:10:22

Verwandte Themen

 Verwandte Themen