As near as I can tell, this comes down to one of four possible rationales, all of which are equally likely:
- Many current web developers have never worked with enterprise tools sufficiently to understand that Message Oriented Middleware actually exists, and is worth using. Considering the number of times I've seen, even in Java applications, people going through massive coding gymnastics to avoid JMS or any similar solution, this would not surprise me. The LAMP stack defines itself almost directly by opposition to traditional "enterprise" tools, and while that's a good thing in a lot of respects, it means that users most comfortable with that stack are pretty ignorant of the good stuff that's out there.
- Microsoft has never made a reasonable MOM system, and anyone primarily familiar with Microsoft tools has thus never used one, given that the Microsoft development ecosystem is really defined by slavish acceptance of strict vendor lock-in.
- XMPP is more web-friendly (ooh! Well-defined XML!) and thus a better match for web developers, in their opinion. Again, much like #1, I just don't buy this.
- AMQP isn't done yet, and isn't a real standard yet. Therefore, people who are at least partial to avoiding vendor lock-in can't provide it as a protocol that can be used. XMPP is done and available today.
While you can use XMPP for this, why not just use AMQP or JMS or some other similar system designed for precisely this type of many-to-many matching?
Posts
15 comments:
I think you came up with the answer to not use AMPQ (I have only read about this solution). But I do know that JMS (being a Java based solution) is not going to be the first choice for anyone but an enterprise developer. There is openjms but in the open source world I think (this is my perception) that JMS is too heavy. While XMPP is open and free and should scale.
Lest anyone think I'm nothing but an AMQP-hater, I think on the whole they've hit stuff pretty well, and I have no doubt that 1.0 will actually satisfy my requirements. More importantly, even AMQP 1.0 without any of my recommendations will be better than Not Having AMQP. My points were mostly that adoption of AMQP 1.0 will be hindered by not supporting existing MOM frameworks.
But in terms of JMS, yes, you're right, the whole "JMS == Java" thing is a bit crazy. However, all of the major commercial JMS providers (Tibco EMS, SonicMQ, Fiorano) have Java, C#, and various flavors of C++ clients you can hook into, meaning that these days you're really just seeing Generic MOM defined by the semantics in the JMS specification. It's also not a wire protocol, it's an application API, which makes it quite different.
And that perception that "JMS is heavy" is what I'm trying to hit at. It's really not, it's just Scary and Different. JMS and proper MOM can be as lightweight or heavyweight as you want.
Or try this ;-)
http://anders.conbere.org/journal/rabbiter-open-federated-pubsub-server/
alexis
Actually, my inspiration was this LShift post, but that appears to work the opposite direction.
But yes, I think we're both on the same mental page here.
@kirk yes; rabbiter is an evolution of the work described in that blog post. We planned the former before creating the latter. It's a great use case.
@tonetheman - XMPP is no more open and free than AMQP. What is your point?
Hi,
first let me tell you that I like and make use of MOM although I don't work on anything enterprise. I'm a LAMP developer.
The problem for LAMP developers with the current MOM tools is lack of bindings for their language of choice. Most MOM systems have C++, C#, Java bindings because that is where the enterprise money is.
But is rare to find bindings for Perl, Python, Ruby or PHP, so a regular LAMP will stay away.
Yet XMPP bindings are available for all those languages, *and* the big social networks sites are offering services over XMPP.
Those two things make XMPP win right now.
Best regards,
@melo: 100% agreement there. In fact, I've written about that at length in the context of AMQP in particular.
Also, I think my #4 point was attempting to cover that: AMQP should allow for language experts to write language-idiomatic bindings to a variety of MOM systems. Until it's fully baked though, we don't have that option. That's where XMPP has the temporary win.
@melo yes that is spot on. This is why in addition to an XMPP binding, RabbitMQ's AMQP broker also has a good Python client and a good Ruby client.
Hi Alexis,
sure!
I haven't saw a decent AMQP Perl module yet, I guess I'll have to write one myself some day :)
Best regards,
@melo maybe so :-)
In fact, if you are interested, there is someone on the rabbitmq-discuss mailing list who says he has been looking at doing a Perl client; guided by Ben's handy guide: http://hopper.squarespace.com/blog/2008/6/21/build-your-own-amqp-client.html
You could also try connecting to RabbitMQ from Perl using STOMP, which is what people did before there was a proper Ruby client.
Another place to meet and talk with folks about this is on #rabbitmq on IRC.
You might want to respond to this.
Hi Kirk,
I believe that I'm the reason you heard this argument before (at least one of the people).
Bear in mind that the folk using commercial MOM products tend to know all their users by first name. Their technical constraints are very different to a LiveJournal or Google Talk.
For you next post: Why CORBA is better than REST. :-)
@Graham:
First of all, the RESTful approach comment is ludicrous if you'd actually read my blog in detail. In particular, I direct you at this presentation I gave at qCon London this year, entirely focused on applying RESTful techniques to financial systems integration.
That being said, you're one person who's espoused that view, but by far not the only one. Look at the links that I provided in the original post.
I think you're also coming to this pretty late in the game to be honest. In my opinion, the battles are largely over. Let's look at just the modern web space:
* Twitter attempted to use XMPP for their firehose services. They abandoned it. It didn't scale.
* Twitter at one point attempted to use it for internal distribution. They abandoned it. It didn't scale.
* Gnip attempted to use XMPP for their firehose services. They abandoned it. It didn't scale.
* Soocial bases their entire data fabric on RabbitMQ, not XMPP.
* LastFM uses a combination of a JMS provider (I won't say which one) and RabbitMQ for their data distribution internally.
* One of the most attended presentations at qCon London this year was Messaging is not just for Investment Banks.
XMPP is not just about data distribution, and those aren't the hard problems in the XMPP space. The hard problems in the XMPP space are identity federation and point of presence (a standard XMPP server handles anywhere from 1 to 2 orders of magnitude more POP updates than actual data updates).
Moreover, if you want to deal with real MOM using XMPP, people are tackling that as well.
My point is now as it was then: XMPP is designed for one thing, which is online p2p (and p2p2p2p2p) chat. When you can grab an open source real MOM broker, like RabbitMQ, qPid, or OpenAMQ, and deploy it in 5 minutes, and know that it will support any machine-machine traffic you need at internet scale, why in the world would you try to cram a square peg into a round hole?
Use the best tool for the job, not just the one that's the most convenient.
@Graham and anybody else who finds this at this point. Take a look here: http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes
It's a super-recent evaluation of the state of play for SecondLife's use of MOM, and even though they're using a chat approach for a lot of stuff, they're still leaning towards AMQP, and in particular, RabbitMQ or qPid C++.
Thanks Kirk, very interesting article.
There's a good discussion about Twitter's message queue going on here: http://unlimitednovelty.com/2009/04/twitter-blaming-ruby-for-their-mistakes.html
Post a Comment