I did actually look into MT's ActiveMQ transport, but it had some serious limitations and didn't pass along many of the features of AMQ. Not to mention it (AMQ transport) was abandoned and never really completed.
On a seperate note, I just read into some of the details of MantaRay and it seems that to be decentralized and still implement the part of the JMS spec where two consumers of a queue get delivered to in a round robin fashion, it had to introduce the concept of a "queue coordinator", similar to the distributor NSB, RSB, MT introduced. The difference I see is that with MantaRay, is that the queue coordinator can be any of the peers listening to that queue. No need for a seperate process, as each endpoint can effectively participate in the distribution. Again, thanks for your time in listening to my banter. ;-) -T On Jan 21, 10:52 am, Adam Miller <[email protected]> wrote: > 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 > thathttp://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%2Bunsubscribe@ > > > >> > > googlegroups.com> > > <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%2Bunsubscribe@ > > > >> googlegroups.com> > > <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%2Bunsubscribe@ > > > >> googlegroups.com> > > <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 > > ... > > read more » -- 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.
