tag:blogger.com,1999:blog-6053747786603248705.post8318694093772912972..comments2023-12-15T09:29:32.069+01:00Comments on Blog of Guy Crets: AMQP enthusiasm?Guy Cretshttp://www.blogger.com/profile/12357277914036649295noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-6053747786603248705.post-77387069826375950372008-08-15T19:28:00.000+02:002008-08-15T19:28:00.000+02:00To add to what Pieter said, RabbitMQ does some ser...To add to what Pieter said, RabbitMQ does some server-server communication using the <A HREF="http://hopper.squarespace.com/blog/2008/6/22/introducing-shovel-an-amqp-relay.html" REL="nofollow">relay queue pattern</A>.<BR/><BR/>We have also experimented with combining XMPP federation and addressing with AMQP routing and delivery. Feel free to contact us for details.alexishttps://www.blogger.com/profile/12281522589184676541noreply@blogger.comtag:blogger.com,1999:blog-6053747786603248705.post-85710896791908063662008-08-15T19:23:00.000+02:002008-08-15T19:23:00.000+02:00AMQP does in fact support very nice server-to-serv...AMQP does in fact support very nice server-to-server messaging, based on the notion of chaining together exchanges in a client-server pattern. It requires no special protocol support.<BR/><BR/>OpenAMQ does this, and it's fully interoperable with other AMQP implementations. See the documentation of federation on http://www.openamq.org/doc:user-3-advanced.<BR/><BR/>The key is that the exchange-queue-binding semantic can be stretched across networks by making the server act as a client to other servers.<BR/><BR/>Federation is not properly described in the AMQP specifications because the editors are not really aware of how it works. But OpenAMQ has done this since its first release.Pieter Hintjenshttps://www.blogger.com/profile/14420256135656470367noreply@blogger.comtag:blogger.com,1999:blog-6053747786603248705.post-19211030584072998302008-08-11T15:30:00.000+02:002008-08-11T15:30:00.000+02:00GuyThank-you for your feedback on AMQP. I'm with ...Guy<BR/><BR/>Thank-you for your feedback on AMQP. I'm with RabbitMQ and would like to add to what Matthew and Paul said.<BR/><BR/>First of all, we have had a lot of interest in RabbitMQ and AMQP from all sorts of end users and customers. I mention this because then, the obvious question becomes: why do people care? I think there are three reasons: new use cases, integration, and cost benefits of using a protocol. While global addressing is in scope for AMQP as Matthew explains, it is not needed for any of those cases.<BR/><BR/>In terms of use cases you mention that WS-* does not provide an open reliable queue, and this also impacts things like .NET WCF which btw <A HREF="http://www.rabbitmq.com/dotnet.html" REL="nofollow">works with RabbitMQ</A>. But there are many other cases as well for example providing messaging 'that just works' and is stable, and scalable, for emerging platforms such as Ruby. A graphic is <A HREF="http://www.lshift.net/blog/2008/07/01/slides-from-our-erlang-exchange-talk" REL="nofollow">here</A>. <BR/><BR/>Giving people a messaging platform that is both open and actually works across multiple languages and cases, then delivers better integration. As Paul Fremantle pointed out <A HREF="http://pzf.fremantle.org/2008/08/amqp-beyond-firewall.html" REL="nofollow">on his blog</A>, there are many companies who just need integration and lots of it, in house.<BR/><BR/>There is also a case to be made for the benefits of open protocols (compared to open APIs) in delivering true interoperability without costly customisation. Jeff Gould talked about this <A HREF="http://www1.interopsystems.com/analysis/can-amqp-break-ibms-mom-monopoly-part-1.html" REL="nofollow">in his article</A>. Protocols allow users to cope with many more integration cases (e.g. where timeout is involved) which again turns out to be very useful because it lets you manage more cases with one technology which is much cheaper as you scale up to many different scenarios.<BR/><BR/>On the B2B front, while federation would be very useful, we have also seen customers who want client-server B2B. For example exchanges, aggregators and utilities, who want the 'cheapest way to connect business messaging interoperably'. The key need here seems to be to connect to another party without requiring them to use the same product or same version of a product.<BR/><BR/>Last but not least we have had a stab at federation by integrating AMQP with XMPP. This has gotten a fair amount of interest from commentators (google for it...) but the original integration is described <A HREF="http://www.lshift.net/blog/2008/07/01/rabbitmq-xmpp-gateway-released" REL="nofollow">here</A>.<BR/><BR/>Anyway - I hope this is helpful..<BR/><BR/>alexisalexishttps://www.blogger.com/profile/12281522589184676541noreply@blogger.comtag:blogger.com,1999:blog-6053747786603248705.post-74793908177222529952008-08-10T13:04:00.000+02:002008-08-10T13:04:00.000+02:00GuyI've posted a response here:http://pzf.fremantl...Guy<BR/><BR/>I've posted a response here:<BR/>http://pzf.fremantle.org/2008/08/amqp-beyond-firewall.htmlAnonymoushttps://www.blogger.com/profile/15326219720808613358noreply@blogger.comtag:blogger.com,1999:blog-6053747786603248705.post-12852301394239565982008-08-09T22:49:00.000+02:002008-08-09T22:49:00.000+02:00Guy,For context, I chair the AMQP User SIG and we ...Guy,<BR/><BR/>For context, I chair the AMQP User SIG and we appreciate your comments and insight. <BR/><BR/>With regards to the current spec, 0-10, you are correct that it does not address broker to broker federation. For many of us involved, this is an essential aspect of the protocol that has to be in place before it is a viable Internet scale solution.<BR/><BR/>But we have to deliver in steps. Please see to the AMQP User Requirements for a more complete picture of the scope of the protocol and the specification roadmap. <BR/><BR/>http://jira.amqp.org/confluence/display/AMQP<BR/>/AMQP+1-0+Business+Requirements<BR/><BR/>A refinement of these requirements under review can be found at:<BR/><BR/>http://jira.amqp.org/confluence/display/AMQP<BR/>/AMQP+1.0+Business+Requirements+-+Revised<BR/><BR/>Your comments and feedback are greatly appreciated.<BR/><BR/>It is worth noting that both openAMQ(zeroMQ) and RabbitMQ have federation solutions functioning but as a specification team we have not turned our attention to standardizing the protocol.<BR/><BR/>Our aims is to delight, not disappoint - explicitly not with vendor lock in strategies.<BR/><BR/>Step by step we are getting there, especially through community review and support such as yours.<BR/><BR/>Matthew ArrottUnknownhttps://www.blogger.com/profile/03795184193730147613noreply@blogger.com