views:

1663

answers:

6

I think the title sums it all .... We have a .NET 2.0 system trying to implement a distributed pub/ sub model. I came across NServiceBus, RhinoBus and MassTransit. Unfortunately, these are MSMQ based. I am tasked to figure out pub/ sub alternatives that uses a different messaging alternatives ...

the only reason for seeking MSMQ alternatives is to overcome the message size restriction. Since our enterprise app messages can potentially get truncated due to per message restriction...

any guidance is much appreciated

+1  A: 

There is a Roadmap for NServiceBus that states they intend to offer a more pluggable transport to allow alternatives to MSMQ.

MassTransit also suggest they are aiming to support alternatives.

Unfortunatley none of these are there yet.

Duncan
+1 Glad I saw your comment before writing the exact same thing, personally I am very fond of NServiceBus.
mhenrixon
A: 

I use a couple of database tables for this.

ebpower
I don't think this answers the question...
Henrik
Sure it does. I use database tables as persistent queues to avoid having to use MSMQ. It works very well even with multiple readers and writers. Database transactions provide concurrency control. They also provide persistence in case of system crashes.
ebpower
A: 

If you have the budget for it you can always use Biztalk.

If you want to do something more interesting you could use Microsoft Azure Service Bus http://www.microsoft.com/azure/servicebus.mspx

You could use SQL service broker http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx . Not sure if there was a plan to discontinue this finctionality.

Or it you want the simplest thing that works, use a sql table :)

Shiraz Bhaiji
Your suggestions seem radical; NServiceBus is advertised as a platform to synchronize and/or load InProc cache between servers. Check out Udi Dahan's blogs. Azure and BizTalk are inter-system messaging platforms; aka EDI and the former makes a roundtrip to Microsoft ... :)MSMQ is not a scalable and reliable enterprise solution. It's great for small packet movements but not enterprise scale data. Challenges vary from primary disk fragmentation that affects OS, OS locks to message truncation. SQLCE is an option but has shown to be a performance bottleneck for InProc activities.
G33kKahuna
Yes, I agree it was a bit radical, just meant to give you an idea of the full scope of options. If you are looking at SQLCE, are you working on mobil devices? If so take a look at Microsoft Sync Framework http://msdn.microsoft.com/en-us/sync/default.aspx
Shiraz Bhaiji
@G33kKahuna: "MSMQ is not a scalable and reliable enterprise solution" - why do you think that? Can you point me in the right direction to something that indicates what its limits are? I'm currently evaluating whether or not MSMQ is suitable for a project and it would be good to know more about this.
adrianbanks
G33kKahuna - NServiceBus is not only about that. See the NServiceBus.com site. I would disagree that MSMQ cannot be made to scale, as I've done it, and it is very reliable (depending on the reliability of the IO you put under it).
Udi Dahan
A: 

If you are OK with a "broker" type approach I am currently looking at http://wso2.com/products/enterprise-service-bus/ ??

Simon Thompson
A: 

How about not store it in queue at all? If you have large data set you receive from integration partner, store it somewhere (you want to keep the original data), parse it into database, or do something different from other true messages. Take a look at this article: http://msdn.microsoft.com/en-us/library/ms954587.aspx#dataoutsideinside_topic5 . It talks about differentiating reference data from other kind of data.

harrychou