Tony, I have no experience with AMQ or MR so I can't really speak to any of that. Though, I am aware that Masstransit does support more transports out-of-the-box than Rhino ESB and nServicebus (though its fair to mention that nServiceBus has a roadmap established to support more transports). You might want to check them out - http://masstransit-project.com, source is available on github. I have only "played" with masstransit using the MSMQ transport so I don't know if they require a separate distribution service for load balancing when using AMQ or not. Though their message forums could probably quickly answer that http://groups.google.com/group/masstransit-discuss.
-- Adam On Fri, Jan 21, 2011 at 11:26 AM, Tony <[email protected]> wrote: > Fair points both of you are making. Thanks for spending the time to > discuss this with me. > > As for the centralized/decentralized topic, well there are > decentralized options with certain JMS based MOMs. ActiveMQ has a pure > multicast capability and so does MantaRay, which is purely > decentralized natively. Both are used in the enterprise and both > implement the JMS spec. I have extensive experience with TIBCO EMS, > which is also a JMS based system, but have little experience with > ActiveMQ and MantaRay. This may be (and probably is) a question better > suited for another forum, but if AMQ and MR implement the JMS spec, > how can they provide the round robin delivery we've always used to > scale services out? > > Anyway, thanks for your insight into why the distributor process is > necessary. It helps me understand more about MSMQ and the culture > around .Net service bus implementations. > > -T > > > > > > > On Jan 21, 8:52 am, Adam Miller <[email protected]> wrote: > > Just re-read my post again and thought I should add something. If you > > really wanted to have 1 single instance of MSMQ you should be very aware > of > > the gotchas and take those into consideration in your > > deployment/infrastructure. Though I would imagine you would need to > > consider the same things with JMS using the same setup. Especially since > as > > Udi points out that clustering is not the same thing in the MS and Java > > worlds. > > > > On Fri, Jan 21, 2011 at 9:49 AM, Adam Miller <[email protected] > >wrote: > > > > > > > > > > > > > > > > > I re-read this before I wrote it and I pre-apologize for any > incoherence > > > (late night). I hope you can follow. > > > > > I don't want to go speaking for others, but I'm assuming that the > reasoning > > > as to why Rhino ESB, nServiceBus and Masstransit use another service as > a > > > distributor or load balancer is because of the decentralized nature of > MSMQ. > > > It doesn't mean that it is impossible for you to have all of your > services > > > subscribe to the same single queue in MSMQ (in MSMQ 4 you can now read > from > > > a remote queue in a transaction) as you describe with JMS. My > assumption is > > > that these service buses don't support using 1 single MSMQ because they > are > > > supporting the more likely scenarios of using MSMQ and also supporting > MSMQ > > > 3 where you cannot read from a remote queue in a transaction. > > > > > Technically, if you wanted to have 1 single instance of MSMQ and use > Rhino > > > ESB you just need to change the code a little to support this (all > services > > > listening to the same queue), though you will also have to use MSMQ 4 I > > > believe (Server 2008). In doing this you won't have a "load balancing > > > algorithm" in place like round robin, you would let the nature of the > queue > > > be the load balancer. > > > > > - Adam > > > > > On Fri, Jan 21, 2011 at 1:12 AM, Udi Dahan < > > > [email protected]> wrote: > > > > >> Tony, > > > > >> One of the things to be careful with in comparing Microsoft and Java > > >> technology is the different meaning of words. > > > > >> In the JMS world, clustering implies scaling out - in Microsoft, it > means > > >> failover for high availability. > > > > >> Also, most JMS rollouts tend to go with a centralized broker while > most > > >> MSMQ rollouts have everything decentralized - there is no central > broker. > > > > >> Also, keep in mind that most production environments are virtualized > so > > >> underneath the distributed environment, all messages can still be > maintained > > >> in a fault-tolerant way on top of a SAN. > > > > >> In that sense, it's something of an apples to oranges comparison. > > > > >> -- Udi Dahan > > > > >> *From:* [email protected] [mailto: > > >> [email protected]] *On Behalf Of *Tony > > >> *Sent:* Friday, January 21, 2011 2:22 AM > > >> *To:* Rhino Tools Dev > > >> *Subject:* [rhino-tools-dev] Re: Load Balancing Using Rhino Service > Bus > > > > >> To clarify further (because now that i read my post, it still didn't > > >> make much sense to me either haha), my point is that a JMS broker can > > >> load balance two services simply by them listening to the same queue. > > >> This is not how MSMQ works, which is why you need a separate process > > >> to do this. So if you already have to cluster your broker anyway, > > >> isn't it also beneficial to have your broker load balance as well? So > > >> you don't have to cluster yet another process on top of everything > > >> else you're clustering (DB, etc.)? I've been watching .Net service bus > > >> implementations for a while now and I've wished that one would take > > >> advantage of the load balancing nature of a JMS broker, but abstract > > >> the cumbersome API JMS imposes. > > > > >> -T > > > > >> On Jan 20, 4:36 pm, Tony <[email protected]> wrote: > > >> > Let me clarify a bit. In a JMS environment, the broker acts as a > load > > >> > balancer naturally through implementing the JMS specification. JMS > > >> > brokers are then clustered, similar to how you would cluster MSMQ. > So, > > >> > through a clustered broker, you achieve both reliable message > > >> > brokerage plus built in load balancing. It seems to me that when > using > > >> > MSMQ, you now have to cluster your broker AND a separate distributor > > >> > process. > > > > >> > Is this not the case, or am I missing a component of how > NServiceBus, > > >> > MT, and RSB are structured around MSMQ? > > > > >> > Thanks in advance for your input.... > > > > >> > -Tony > > > > >> > On Jan 19, 3:11 am, Udi Dahan <[email protected]> > > >> > wrote: > > > > >> > > Tony, > > > > >> > > Are you assuming that a JMS broker is not a single point of > failure? > > > > >> > > -- Udi Dahan > > > > >> > > From: [email protected] > > >> > > [mailto:[email protected]< > [email protected]>] > > >> On Behalf Of Tony > > >> > > Sent: Tuesday, January 18, 2011 7:50 PM > > >> > > To: Rhino Tools Dev > > >> > > Subject: [rhino-tools-dev] Load Balancing Using Rhino Service Bus > > > > >> > > My apologies if this has been answered before, but is there a > facility > > >> > > for load balancing the handling of messages in RSB? With > NServiceBus > > >> > > and MassTransit, there is a seperate process called the > Distributor > > >> > > that achieves this. Does RSB have something similar? Also, is > there a > > >> > > way to have RSB use a JMS based broker instead of MSMQ? JMS based > > >> > > brokers handle load balancing natively just by having multiple > > >> > > subscribers listen to the same queue. The broker then delivers on > a > > >> > > round-robin basis. No more need for a seperate process and single > > >> > > point of failure like with the Distributor approach. > > > > >> > > Thanks in advance.... > > > > >> > > -T > > > > >> > > -- > > >> > > You received this message because you are subscribed to the Google > > >> Groups > > >> > > "Rhino Tools Dev" group. > > >> > > To post to this group, send email to > [email protected] > > >> . > > >> > > To unsubscribe from this group, send email to > > >> > > [email protected]<rhino-tools-dev%[email protected]> > <rhino-tools-dev%2Bunsubscribe@ googlegroups.com> > > >> . > > >> > > For more options, visit this group athttp:// > > >> groups.google.com/group/rhino-tools-dev?hl=en. > > > > >> > > _____ > > > > >> > > No virus found in this message. > > >> > > Checked by AVG -www.avg.com > > >> > > Version: 10.0.1191 / Virus Database: 1435/3388 - Release Date: > > >> 01/18/11 > > > > >> -- > > >> You received this message because you are subscribed to the Google > Groups > > >> "Rhino Tools Dev" group. > > >> To post to this group, send email to [email protected] > . > > >> To unsubscribe from this group, send email to > > >> [email protected]<rhino-tools-dev%[email protected]> > <rhino-tools-dev%2Bunsubscribe@ googlegroups.com> > > >> . > > >> For more options, visit this group at > > >>http://groups.google.com/group/rhino-tools-dev?hl=en. > > >> ------------------------------ > > > > >> No virus found in this message. > > >> Checked by AVG -www.avg.com > > >> Version: 10.0.1191 / Virus Database: 1435/3391 - Release Date: > 01/19/11 > > > > >> -- > > >> You received this message because you are subscribed to the Google > Groups > > >> "Rhino Tools Dev" group. > > >> To post to this group, send email to [email protected] > . > > >> To unsubscribe from this group, send email to > > >> [email protected]<rhino-tools-dev%[email protected]> > <rhino-tools-dev%2Bunsubscribe@ googlegroups.com> > > >> . > > >> For more options, visit this group at > > >>http://groups.google.com/group/rhino-tools-dev?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Rhino Tools Dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<rhino-tools-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/rhino-tools-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
