Discussions

News: Spring's Rod Johnson Has His Head in the Clouds


  1. There aren't really any 'household names' when it comes to the IT world, but if there was a list of Java rock-stars, Rod Johnson’s name would be at the top of the list. If not by reading Professional Java Development with the Spring Framework (2005) or J2EE without EJB (July 2004), you probably know of Rod owing to fact that it was his big brain that conceived of, and initiated, the development of the Spring framework. Thank him or blame him, but Rod is responsible for Spring.

    So, what has Rod been up to lately? Well, like a Hollywood actor promoting his latest movie on late night talk shows, he's been doing the PR circuit, hyping up VMWare's latest acquisition of RabbitMQ.

    Now, not everyone is completely in tuned with what's been going on at the corporate level in the IT industry, so a quick question might be: 'why is Rod working for VMWare?' Well, that's actually a silly question, because VMWare bought SpringSource in August of 2009, so he still works for Spring, but he also works for VMWare, and when they buy something like RabbitMQ, he's there to chat about it.

    So, the next question is 'why would VMWare need RabbitMQ?' I mean, what the heck does ghosting a VMWare image have to do with an open-source implementation of the AMQP messaging standard? Well, that's a dumb question too. Remember, even though Rod works for VMWare, he's still a Spring guy. So the question really is, 'why does Spring need a messaging implementation?' I mean, Spring applications are deployed successfully all around the world, right, and nobody has ever complained about Spring's messaging support, have they?

    Again: dumb question. The messaging isn't about Spring, but really, it's about the cloud, and clearly it seems that cloud computing is the IT space in which VMWare, SpringSource, RabbitMQ, and Rod Johnson for that matter, all believe they can make the biggest splash. The cloud is the closest thing we have right now in the IT industry to the wild, wild west, and it seems that everyone wants to get in there and shoot things out. And in this type of shootout, a strong messaging implementation is the right type of pistol to be packing.

    So, why is messaging so important in the cloud? Now THAT is a good question.

    In traditional, non-cloud applications, a component calls another component on machine A, which then calls another few components on machine B, and then maybe another component on machine C. Sure, there may be a cluster in there to complicate the call path, but that's essentially it. But in the cloud, it's different. Well, it’s somewhat the same; lets just say it's the same, but it's different. 

    In the cloud, component A will still call component B, but both component A and component B are in the cloud, and they aren't on Machine A and Machine B, but they're one Machine 'N', where 'N' is a number too large to count, and probably far too expensive to pay for. So jockeying calls around the cloud becomes impossible unless you know how to queue these interactions up properly. That's a tough job to do on your own, unless you've got the right software to do it for you.

    But the point is, any competitive cloud implementation is going to need a top notch messaging implementation to keep track of all those components communicating with each other across N number of servers and machines. So, if you want to keep your cloud working reliably, you need some fast and reliable messaging, and without it, you won't be a player in the cloud.

    And from what I can see, that's why VMWare has picked up RabbitMQ - because Rod Johnson has his head in the clouds. 


    SpringSource Acquires RabbitMQ Cloud Messaging Technology

    ----------


    Threaded Messages (39)

  2. I would appreciate if someone can enlighten me. I would like to see, but I just don't. Take this quote from blog for example:

    "cloud applications require a fundamentally different messaging infrastructure"

    or this quote from thread post: "But in the cloud, it's different."


    Can someone name me some business domain other than niche markets (Google, Yahoo, Facebook and similar) where this entire buzz can be applied at all? I am not even going to acknowledge that it actually can improve existing soltuions. What are the differences? I simply don't get it.

    Which industry is it:
    - insurance
    - trading
    - public/government sector
    - telecom
    - health
    - retail
    -...
  3. I would appreciate if someone can enlighten me. I would like to see, but I just don't. Take this quote from blog for example:

    "cloud applications require a fundamentally different messaging infrastructure"

    or this quote from thread post: "But in the cloud, it's different."


    Can someone name me some business domain other than niche markets (Google, Yahoo, Facebook and similar) where this entire buzz can be applied at all? I am not even going to acknowledge that it actually can improve existing soltuions. What are the differences? I simply don't get it.

    Which industry is it:
    - insurance
    - trading
    - public/government sector
    - telecom
    - health
    - retail
    -...
    Well... yes, yes, yes, yes, yes, yes, and yes. GigaSpaces has customers in insurance, trading, public sector, telecom, health industry, retail industry, entertainment industry, many others - so yeah, the cloud has a lot of applications.

    The problem for me in RabbitMQ (and any MQ system, really) is that your resource connections are still largely TCP/IP based. JMS gives you a hub to work with, and clustering the MQ itself... well, you're moving the TCP/IP connection around, but it's still there.

    The boundaries still exist. What happens when you cluster a messaging server like RabbitMQ, or cluster a processing grid like GridGain, or cluster a datagrid like Coherence or Gemfire... well, you can establish lots of direct links to various nodes in those clusters, but you're only lessening the impact of the boundaries between nodes, not eliminating them.

    That's one reason why I think GigaSpaces is an excellent platform (Proof that I think this: I left TheServerSide to work for them!) - what XAP does is fairly simple: give you a data grid *and* a processing grid in one shot. The processing of datum X takes place in the JVM in which X lives; no network is involved for the primary transaction.

    The network only plays in to handle synchronization, but even there you're talking about a largely peer organization, so you're only sending the data a few directions, instead of sending it to a master hub (which the propagates to N nodes, where N is the number of nodes, or even just a portion of those in sharded data grids).

    Data access is fast, because data is local. Processing is fast, because processing power is local.

    The Elastic Data Grid mentioned earlier today means that it scales automatically to fit the requirements you set, and modifies its own sharding to fit the network topology.

    Anyway, enough of that - Cameron got me started down a thought path.

    Captcha: "French colonna" - odd, because Colonna looks like a Roman family name rather than Gallic?

  4. "GigaSpaces has customers in insurance, trading, public sector, telecom, health industry, retail industry, entertainment industry, many others - so yeah, the cloud has a lot of applications."

    You see, this is exactly what I am talking about. Cloud is just buzzword and everyone is rebranding their solutions to have cloud somewhere in their name. For example take a look at this letter from Gigaspaces.
    http://www.theserverside.com/news/thread.tss?thread_id=48157

    They say:

    "Gigaspaces XAP is that application server,", and also "Built from the ground-up for Service-Oriented Architecture"

    You are basically just rebranding same ol' stuff to suite current buzzwords. First it was app server, then it was all about SOA, and now it is Cloud. And you even flag your grid solution as Cloud. And then you have Google like cloud. So thats how people get confused because there is no clear definition what cloud is.

    IMHO, saying Gigaspaces is cloud is silly. With all due respect.
  5. "GigaSpaces has customers in insurance, trading, public sector, telecom,
    health industry, retail industry, entertainment industry, many others -
    so yeah, the cloud has a lot of applications."

    You see, this is exactly what I am talking about. Cloud is just buzzword and everyone is rebranding their solutions to have cloud somewhere in their name. For example take a look at this letter from Gigaspaces.
    http://www.theserverside.com/news/thread.tss?thread_id=48157

    They say:

    "Gigaspaces XAP is that application server,", and also "Built from the ground-up for Service-Oriented Architecture"

    You are basically just rebranding same ol' stuff to suite current buzzwords. First it was app server, then it was all about SOA, and now it is Cloud. And you even flag your grid solution as Cloud. And then you have Google like cloud. So thats how people get confused because there is no clear definition what cloud is.

    IMHO, saying Gigaspaces is cloud is silly. With all due respect.
    That's a fair statement - but it has to do with what people think the "cloud" is rather than anything else. 

    To me, a cloud is defined similarly to quanta: you sort of know where an electron is, because you know it's around an atom's nucleus SOMEWHERE, but you don't know exactly where. Tenancy is vague. You connect to one of a number of candidate nodes ("positions?") and use that connection as necessary. 

    If you happen to change which node you're talking to while you're talking to it, well, that's not relevant; the idea is that an "electron" is an electron is an electron is an electron. The cloud is made up of peers. 

    Now, I can't speak to the BEA statement you referred to - because I don't think it's the world's most astute idea either, everything has its role - and I can certainly and gladly agree that the cloud is occluded by marketing hype and buzzwords that really have no definite meaning.

    But I don't think you can throw out the idea or (obviously) GigaSpaces simply because of a bevy of inspecific terms. It's like art; you try and try and try again until you figure out the right way to say it and communicate and connect.

    I'd say that we ARE an app server - albeit not a Java EE app server. Java EE has a specific definition. App server, as a generic term, does not.

    We do provide SOA capabilities - after all, JavaSpaces is a messaging platform that easily creates services.

    We are cloud, too, because of the tenancy issue, which we fit very well.

    In fact, I think that's the biggest problem we (GigaSpaces) have: we are hard to define because we're very flexible. It might have been easier if we included FEWER features, because we would have had definitive answers when people say "what is it you do and how?"

    As it is: We kinda do *THAT*, for many values of THAT, and we kinda do it generally however you want to do it.

    Captcha: "U.S majorca." Nonsensical twaddle.
  6. Multi-tenancy is one trait that you see in cloud infrastructure that you typically don't see in enterprise environment. I don't know how RabbitMQ helps in this regard and I don't even know if RabbitMQ can handle messages of web scale - that's hundreds of millions of messages. Sometimes, the infrastructure developed for enterprises simply don't scale to cloud levels.
  7. And I still haven't received answer about what exactly is different. What makes RabbitMQ more cloudy than ActiveMq or HornetQ? Is it because HornetQ does not provide AMQP support? Is it because RabbitMQ is written in Erlang? Are they providing some new communication patterns not known to human kind? How can I apply new SS offerings, such as Spring Cloud Edition with RabbitMQ addon to solve concrete business problems from domains I listed above?

    Not trying to bash anything or anyone, just being curious.
  8. still dont get it ?[ Go to top ]

    so from the post - if i try to understand the problem arouind messaging in the cloud - Is the real problem around knowing which "machine" in the cloud to go to to pick up your message ?
    And how is RabbitMQ helping ?

    can the author elaborate ?

  9. Actually...I was hoping...[ Go to top ]

    @Shawn

    To be honest, I was somewhat hoping that TheServerSide community could do some of the elaborating on those points. Why else would the message queue be so important to VMWare/Spring/Cloud? And more to the point, it's about the cloud, that's all in their press release.
  10. still dont get it ?[ Go to top ]

    so from the post - if i try to understand the problem arouind messaging in the cloud - Is the real problem around knowing which "machine" in the cloud to go to to pick up your message ?
    And how is RabbitMQ helping ?

    can the author elaborate ?



    I'm clearly not the author, so YMMV - but here's my view, as an old JMS fan.

    JMS is great because it desynchronizes external calls. You queue up requests (in a queue, no less) and consumers pull those requests off and process them as fast as they can. If you can process 40 requests at a time, and you get 300, well... that's fine, the initial 40 will be consumed and the worker processes will chew through the rest of them as they can.

    So we have three architectural components here: the producer (a web app?), the MQ server, and the consumers, which themselves are likely to produce results for the web app to present.

    We can establish links over the network for every one of those, plus we have to consider the MQ itself, which is likely to have a backup (for failover) as well as a database for persistence (the most common persistence mechanism.) 

    All of that costs in terms of network time, etc. The message queue gives you desynchronized calls, which is great and cannot be overvalued (it really is important) but it still leaves the network involved for most of your communication, even if it can pack on a whole lot of messages over the same socket. 

    It has to know where the MQ server lives, too.

    Most of your cloud products get rid of at least some of that: you don't have to tell it specifically where the messaging system lives (if you use a messaging paradigm). The problem, as I said, is that you're still leaving those architectural boundaries in place.

    You can certainly find implementations that lessen those boundaries - for example, not involving the network if a queue is being accessed locally. But I don't know how easy that is to configure or how common it is.

    Captcha: "committee ammo". Ooo, politics!
  11. Rod has his feet on the ground[ Go to top ]

    OK, first the sales pitch; AMQP, RabbitMQ being the best implementation of AMQP will allow applications, in VMWare's case perhaps cloud or grid hosted to communicate with other applications in an open (at the wire-level) way.

    RabbitMQ is often used to replace ActiveMQ in production environments as it's far more reliable, the protocol is standardised [almost] and supported by a huge number of major industry bodies including several investment banks, Redhat, Cisco etc.

    In acquiring RabbitMQ it gives VMWare a good list of customers they can sell more product to, most of whom are technical, an excellent team of Erlang programmers and a position at the table at AMQP, probably one of the best.

    All this adds up to a very good reason to buy Rabbit MQ.

    On the flip side, it will be interesting to watch iMatix's 0MQ now that they have made the conscious decision to opt out of AQMP and of course I'm sure VMWare haven't finished making acquisitions so watch this space for the next announcement.

    Lastly, my personal congratulations to Alexis and the team and VMWare on a great move.

    -John-
    CTO Incept5
  12. Rod has his feet on the ground[ Go to top ]

    "RabbitMQ being the best implementation of AMQP"

    Do you have any, let's say, case studies to back this up? For example, Red Hat messaging is doing some cool things as well, such as RDMA, plus their tweaked broker's journal (optimized for RHEL) should be definitely faster than RabbitMQs.


    "On the flip side, it will be interesting to watch iMatix's 0MQ"

    Well to the best of my knowledge these guys are basically trying to do almost same thing as these guys, who are doing for about almost 10 years. I wish them a good luck cause they are gonna need it.
    http://29west.com/
  13. Rod has his feet on the ground[ Go to top ]

    It's not all about speed, it's about supported languages, adherence to standards, product support etc. etc.  RedHat's was one of several companies that put into the Apache version, they had a head start because JP Morgan "lent" one of their chief programmers who formally worked on the iMatix AMQP product. RedHat's AMQP is good, extremely good on Redhat OS (and Centos) but VMWare are not going to buy Redhat are they?

    I've used most of the AMQP implementations, in production, Google me and you'll see I know quite a bit about it. RabbitMQ IS currently the best AMQP implementation in my opinion but I'm not knocking Qpid, it's very good too and the whole point of AMQP is that there are several implementations.

    29West on the other hand is another very cool messaging product, a very interesting acquisition by Informatica.

    -John-
  14. Rod has his feet on the ground[ Go to top ]

    "It's not all about speed, it's about supported languages, adherence to standards, product support etc. etc."

    Agreed. Like I said in similar thread:

    "Speaking with business hat on, I fail to see any serious business doing any kind of important/mission critical work with non-mainstream/proprietary language [Erlang]. Simply risks of things going wrong and potential costs of fixing those are too huge. Sure, doing 'integration with twitter via cloud' types of apps is ok, but running mission critical messaging is a no-no.
    Disclaimer: Speaking with tech hat on, I think RabbitMq is excellent product."
  15. Rod has his feet on the ground[ Go to top ]

    I'm not an Erlang programmer, I've installed it on my Mac and compiled RabbitMQ using it but that's about my limit on being able to program it. I have read quite a bit about the language though and been to a number of presentations by the L-Shift team (behind Rabbit) and I have to say it's the perfect language for implementing the AMQP spec. You say it's not main-stream but bear in mind that it as old as C++ and comes from Ericsson and has been used extensively in the telecom industry, it also has huge respect in the investment banking world, it's not just another cool language like Groovy or Scala, it was designed for a specific purpose. You'd be surprised how many main-stream applications were written in Erlang.

    -John-
  16. Thanks for the succinct, technical description of how this fits in with VMWare's business objectives. I think that was something missing in the article, so thanks for helping to fill the void.
  17. Rod has his feet on the ground[ Go to top ]

    On the flip side, it will be interesting to watch iMatix's 0MQ now that
    they have made the conscious decision to opt out of AQMP

    Here are the reasons why they've dropped AMQP. 

    Andreas
  18. Rod has his feet on the ground[ Go to top ]

    Here are the reasons why they've dropped AMQP. 

    Andreas
    I have read both 0-10 and 1.0 specs, and do agree that 0-10 is too complex, while 1.0 looks really promising.

    He does make couple of good points, but what he is essentially proposing is to recreate messaging concepts from scratch and to get rid of the entire legacy buggage (like JMS concepts, concepts from WeblogicMQ and so on). This of course will not work, nor it is welcomed, since APIs like JMS, even though not perfect, are good.

    Also, proposals he makes about getting rid of centralized server concept ain't gonna happen either because 99% of programmers out there are having hard time working with current centralized/synchronous/managed development models, and making it even more complex is not wise. Good programmers will most likely roll their own messaging protocols anyway for their domain specific problems.

    And at the end, he claims simplicity but proposes complexity, which by itself is against what AMQP is all about: integration and interoperability.
  19. Rod has his feet on the ground[ Go to top ]

    And at the end, he claims simplicity but proposes complexity, which by itself is against what AMQP is all about: integration and interoperability.

    Here are more details, especially why AMQP is incompatible to itself.

    Andreas
  20. Rod has his feet on the ground[ Go to top ]

    Here are more details, especially why AMQP is incompatible to itself.
    Andreas
    John O'Hara (pro-amqp) said that Pieter Hintjens (anti-amqp) hasn't been participating in official AMQP meetings for ages. And indeed, if you check official AMQP list like I did, you may see loads of messages from PH excusing himself.

    It is always easier to quit than to stay and fight and improve things. I agree that AMQP versions prior to 1.0 are far from perfect, but 1.0 does look solid and simple. Building good standards takes time, and making mistakes in the way is understandable as long as we learn from them. And by looking at AMQP 1.0, to me it seems that AMQP leaders have indeed done so.

    PH (who, as far as I know, is one of the original creators of AMQP) addresses at the same time both technical and organizational issues. I addressed technical above, and organizational problems are always going to be there, no matter what technology, protocol, company, expert group or whatever, and it is ok as long as something good comes out of it (like AMQP 1.0).

    Organizational solution he is proposing is: I don't agree with you, so I quit. In the process I will disregard interests of my customers.

    Technical solution: let's reinvent everything from scratch, throwing even good parts of AMQP (there have to be SOME good parts in the specs even if you dont like it). Moreover, let's ignore all abstractions from standard APIs like JMS, since they are bad. Let's propose solution needed for niche markets (trading and similar industry) and push it to all other business markets who actually dont care if message has header of size 64 or 1 byte, nor they care about extreme performance requirements.

    AMQP is about interoperability, integration and good performance, not the best possible performance in the universe.

    Disclaimer: Again, not affiliated with any party involved with this story.
  21. Pro and anti-AMQP?[ Go to top ]

    It is true that iMatix more or less dropped out of the AMQP working group processes in 2007-08.  Before that we wrote the original spec, and acted as project manager for the working group, and were extremely active.  It is a shame that most of that history is private.  We worked hard to bring AMQP discussions into the public light.

    But to call us "anti-AMQP" is just wrong.  We burnt-out after several years of being unable to make the AMQP process work in a (to us) sane fashion.  I explained this in the "pain is not a good sign" section of my long analysis.

    There were other firms that burned out.  Cisco dropped out, at the same time as we did, as their efforts to get better framing kept getting rejected.  Other firms like IONA and 29West simply never participated at all.

    And AMQP invents everything from scratch.  Multiple times.  AMQP/1.0 is entirely incompatible with AMQP/0.9.1, not even the core concepts remain.

    In the end, our customers do not really care about standards.  We've asked them.  They simply do not.  What they care about is cost, reliability, performance.  Latency does matter.  Throughput does matter.

    And so ZeroMQ is an open source project that will eventually deliver a stack of standards that will be simple, built by a rich and experienced community, and properly integrated into the IETF stack.

    Note that as well as writing standards for fun, I'm also one of the founders of the Digital Standards Organization and ex-president of the FFII.  Communities, collaboration, and the benefits of open processes are not theoretical to me.  AMQP has failed and will continue to fail because essentially it's a closed process owned by a very few firms.

    Rabbit Tech did a great deal in exiting now, because it's extremely unlikely they could have implemented AMQP/1.0 without a lot of extra money.
  22. Pro and anti-AMQP?[ Go to top ]

    "But to call us "anti-AMQP" is just wrong."

    English ain't my native so I apologize if it sounded harsh. What I meant in lack of knowing better word is: anti-amqp is someone who does not see AMQP as future of messaging.

    "In the end, our customers do not really care about standards.  We've asked them.  They simply do not.  What they care about is cost, reliability, performance.  Latency does matter.  Throughput does matter."

    Well I believe that your customers are from niche market since there are lots of business markets who do not have volumes/latency/throughput needs as those found in market feeds, and they prefer standardized solutions. Many of the concepts from ZeroMQ documentation are specifically targeted towards market data feeds. Majority of businesses do not need kernel-bypass, 1 byte header, lock-free/wait-free algos and similar technology. They need standard solutions that will guarantee fast and easy integration and interoperability.

    "And AMQP invents everything from scratch.  Multiple times.  AMQP/1.0 is entirely incompatible with AMQP/0.9.1, not even the core concepts remain."

    I agree, mistakes have been made, problems have been detected (such as how credit/flow control should work on exchange with multiple queue bindings etc). But we have learned from those, and IMHO, AMQP 1.0 looks solid, simple and mature.

    "Note that as well as writing standards for fun, I'm also one of the founders of the Digital Standards Organization and ex-president of the FFII."

    I never questioned your expertise nor good intentions. I am just pointing out that you are targeting different markets (low latency/high throughput) than those who sacrifice some speed for interoperability. At least that is the impression I get.

  23. Who's behind the mask?[ Go to top ]


    I agree, mistakes have been made, problems have been detected (such as how credit/flow control should work on exchange with multiple queue bindings etc). But we have learned from those, and IMHO, AMQP 1.0 looks solid, simple and mature.
    Chief Thrall-

    Are you going to remove your mask and disclose your true identity?

    You seem fairly knowledgeable about AMQP and your above comment implies you were involved in the AMQP 1.0 spec.

    Go on... I'm curious :)
  24. Who's behind the mask?[ Go to top ]

    Chief Thrall-
    Are you going to remove your mask and disclose your true identity?

    You seem fairly knowledgeable about AMQP and your above comment implies you were involved in the AMQP 1.0 spec.

    Go on... I'm curious :)

    Hi Tim,

    My name says it all: I am Thrall, son of Durotan, chief of the Horde. =)

    On the serious note, when I had chosen this account name back in the old days, I didn't thought I would post regularly, and in the mean time I discovered that posting like this has advantages: I can say exactly what I mean and at the same time it does not interfere with my professional career since the two are detached.

    But Tim rest assured, I am so insignificant and unknown, if I told you, or anyone else, my name, it would be first time you ever heard of me.

    Also, disclaimer, I am not, nor I was ever, affiliated with any company or person participating in these threads (VMWare, Spring, Red Hat, AMQP members, Mule...). I use open source software, appreciate standards, and defend them when noone will.
  25. Ignoring JMS...[ Go to top ]

    You do realize that people program applications in languages other than Java?  0MQ supports Ada, C, C++, CLisp, Haskell, Java, Lua, C#, COBOL, PHP, Python, Ruby.  So... why would we aim for JMS?

    The ZeroMQ API is in fact based on BSD sockets, which does count as a standard API.  AMQP does not define any standard API, not JMS nor anything else.  iMatix did propose a standard API in 2006.  Rejected, like all our suggestions.  After a while that gets tiresome, trust me, especially when what gets voted is such rubbish (you read AMQP/0-10?)

    In ZeroMQ/1.0 we did reuse some concepts from AMQP, such as exchanges, but we dropped these in ZeroMQ/2.0 because they are still more complex than we need to do messaging.
  26. Ignoring JMS...[ Go to top ]

    "You do realize that people program applications in languages other than Java?  0MQ supports Ada, C, C++, CLisp, Haskell, Java, Lua, C#, COBOL, PHP, Python, Ruby.  So... why would we aim for JMS?"

    Of the languages you listed, only C/C++, Java, C# and Python would be relevant (which business uses Haskell for messaging anyways). Now, if we have JMS abstractions (which are good concepts IMHO) a de-facto standard in Java world, and no other language has globally agreed upon JMS-like API standard, why not reuse those concepts and ideas? Why reinvent from scratch? Stating that JMS abstractions are not good is silly since it is probably the first globally accepted 'standard' for messaging. And it works. And AMQP model maps nicely to JMS concepts. And every developer out there knows it. And there are hundreds of articles and books about it.
  27. Ignoring JMS...[ Go to top ]

    "AMQP does not define any standard API, not JMS nor anything else."

    Yes, but its underlying logical concepts, especially those from AMQP 1.0, map easily to JMS concepts, which is, by itself, 'conformance' to JMS, and definitely business benefit.

    My impression of your proposal is that JMS, either at API or concept level, does not play any important role in messaging. When I think of it, people who created JMS were definitely experts, so the truth must be somewhere between what you are saying, and what I am saying: JMS is important.
  28. JMS & messaging[ Go to top ]

    I'm well aware of JMS, the original AMQP designs were based on reverse engineering the JMS spec, which you'll see in concepts like synchronous fetching from a queue.  AMQP at one stage had a "destination" concept.

    However, we soon realized that JMS is fundamentally incoherent, with destinations being both routing (topics) and storage (queues).  Comes, I guess, from JMS's origins as a common API for two very different products.

    AMQP/1.0 has always aimed to have good JMS support but in our view, JMS is a legacy API representing the past.  I'm sure we could make a JMS API for 0MQ easily, but somehow, I doubt anyone will do that.  Yet people make bindings for all sorts of cases.  Today I found a Camel and an OpenCOBOL binding.

    I personally do not believe JMS plays an important role in the future of messaging.  It was built by experts but based on legacy queue and topic systems that belong in the 20th century.  However, and this is worth saying explicitly, my opinion means nothing: anyone can implement JMS on top of 0MQ, if they need it.  It's not trivial, but then JMS on AMQP is not trivial either (five years, and we're still waiting for it to work properly).

    My main regret about AMQP is its failure to engage a community of standards developers and I tried really hard to make this happen, e.g. via http://wiki.amqp.org.  0MQ is not yet into speed as a standards project but it will become one, and we have standards like RestMS (http://www.restms.org) that will fit nicely on top.

    iMatix does utterly believe in free and open standards.  We just do not trust AMQP to become one, after what is now more than five years of exhaustive participation followed by suspended judgement.

    Really, I hope I'm wrong and AMQP works somehow.  The working group is filled with people I've worked with closely over years.  There is no joy in seeing AMQP/1.0 delayed year after year, while people invest deeper and deeper in AMQP/0.9.1, not realizing it's a lost investment.
  29. JMS & messaging[ Go to top ]

    "but based on legacy queue and topic systems that belong in the 20th century"

    This is, I would say, one of the points where we disagree. IMHO, concepts of queue and topic are like fundamentals for messaging, whatever abstractions you create you will end up with queue-like (topic-like) behavior.

    In any case, I wish you guys good luck, it is clear you are are experts in what you do, and I am going to keep an eye on zero-mq, and who knows, maybe in the future your contributions will influence even unbelievers like me to 'see' what we do not see as of now.

    And thanks for RestMS link. Looks cool, gotta check it out.
  30. Queues and topics[ Go to top ]

    Yes, queues and topics are definitely fundamentals for messaging.  Read the end of my (much too) long article on AMQP and you'll see some alternative ideas for how queues could work.  0MQ depends on queues, and does topic routing, it just does not try to conflate the two concepts as JMS does, nor does it create artificial queues where they're not needed, as AMQP does (e.g. two queues between the topic exchange and the recipient: an explicit one on the server and an implicit one at the recipient edge).

    My overall view of messaging for some years now has been that we need three layers: low-latency, enterprise, and Internet.  0MQ would thus be complimentary to AMQP (and both of them to RestMS).

    But what I see today is that RestMS can evolve really quickly, and 0MQ can evolve really quickly, leaving AMQP kind of squashed in the middle.  When we add enterprise-quality reliability protocols on top of 0MQ, as we'll eventually do, where does AMQP sit?

    Positive conclusion: competition is healthy, and maybe AMQP needs something chasing its heels, to pick up its game.  Seen like that, iMatix can't really play both sides.
  31. Queues and topics[ Go to top ]

    BTW, is there 'official' zero-mq spec (in RFC-like form, or similar) somewhere to download? I looked at the zero-mq site but could not find it.

    I would like to read it. Thanks.
  32. Interesting article. Thought I am not sure why Rob and Spring have to do with AMQP at VMWare.
    By reading up on AMQP it looks like VMWare wants to use this standard to manage inter VM communication which probably makes sense. But I am wondering what technology VM used to to use before this?
  33. AMQP vs EJB[ Go to top ]

    Spent about an hour reading bunch of articles about AMQP, and the imatix article link given in an earlier post about AMQP's deficiencies....

    Here's what I think VMWare want's to achieve with aquiring RabbitMQ. This might be a pretty far fectched idea...but not impossible...

    1) Messaging seems to be pretty important to lots of sectors (finance, retail, insurance, social networks, cloud computing)

    2) JMS was created to standardize messaging, but it being just an api and a framework, has not really solved the interoperability issues..

    3) There's lot of promising AMQP implementations, but the implementations are bloated or the spec itself is bloated (hint...does it remind you of EJB :-) 

    So its not really, VMware, but SpringSource that want's to do something about this important feature 'Messaging', which has conflicting ,bloated specs, non-interoperable implementations etc. They want to take one pretty good implementation (whether standard or not) and make it easy to use, just like how they made J2EE easy with Spring.  RabbitMQ is to messaging, what Spring is to J2EE/EJB

    I think this might be a good thing, is VMWare/SpringSource can pull this out, and create a useful, simple messaging platform that may not be necessarily standards or specification compliant and drive its adoption. Spring already has good adoption in Financial industry....if they can achieve the same thing with Messaging (RabbitMQ and AMQP in general already seem to have good finance industry backing),  then standards/specs will automatically catch up with them....

    It's Spring all over again with Rabbit !
  34. AMQP vs JMS[ Go to top ]

    2) JMS was created to standardize messaging, but it being just an api and a framework, has not really solved the interoperability issues..
    The big thing in JMS is the standardized API. If you don't use proprietary vendor features, it would be theoretically enough to change the JNDI provider URL to switch vendors. You don't need to change your client code.

    Since AMQP only standardize on the wire level, you either need to use a proprietary API of the AMQP broker you currently use or you need to implement your own AMQP client lib. I don't think the latter option is practical. AMQP wire level is too complicated and implementation is too costly. So most clients will use proprietary APIs. 

    So now do the vendor switch. Hopefully one vendor's client lib will work with the other vendor's broker. If not - good luck in replacing one proprietary API with another.

    AMQP will put application clients into the pre-JMS era with vendor lockins on the API level. Ok, one can say just implement JMS on top of AMQP. But AMQP has this concept of exchanges etc which is (at least currently) not compatible with JMS. So to use AMQP in it's full range, one must use the proprietary API.

  35. AMQP vs JMS[ Go to top ]

    Replace 'AMQP' in your comment with 'XMPP' or 'HTTP' or 'TCP'.  Protocols are the only way to provide behavioural interoperability across platforms and vendors.  For example the client and server can be implemented by different parties, reducing maintenance complexity. APIs are useful for exposing fragments of protocol behaviour in specific developer idioms.  

    Cheers

    alexis
    RabbitMQ
  36. LOL

    As many post and the author of this article.  No surprise here that they bought a MQ implementation.  Still, I now understand how VMWARE + Spring + Rabbit makes sense now! Thanks!
  37. I'm not too sure this has a lot to do with the hyped 'cloud'. But I don't have any better guesses. 

    I wish I knew well the differences between RabbitMQ and Active MQ well. I'm familiar with ActiveMQ because we use it a lot for jBilling. It works very well. But I guess that it is not too much of an acquisition target considering that is part of Apache. So if you think that your long term business plans should include an MQ implementation, you have to go buy something else. RabbitMQ is opens source (Mozilla license) and they probably own 100% of the IP. And who knows, maybe it is way better than ActiveMQ too... 

    I look forward to see how this fits Ron's strategy with Spring. 

    Cheers,

    E. Conde
    Lead Developer
    jBilling.com - Open Source Billing

  38. RabbitMQ is opens source (Mozilla license) and they probably own 100% of the IP. 
    Portions are owned by LShift, Cohesive and Rabbit. Not sure of the break down between - or how many developers on RabbitMQ are now with VMWare - but would be interesting to know.
  39. There's about ten of us in the team, now at VMware.  All the IP has transferred too.  Does that answer your question?

    alexis

    RabbitMQ

  40. Cloud is the Buzzword now..[ Go to top ]

    Does it matter? Cloud is the buzzword now...extremely hot too ... Like SOA, now everyone needs to be Cloud-compliant! Nomenclature can change overnight within the Cloudspace...Cloud is a bigger (much bigger) and broader catchword than Spring... So VMWhare goes for it...When technology fails and marketing succeeds, companies cannot eb blamed for going for marketing slogans !