Discussions

News: Advanced Message Queue Protocol Released

  1. Advanced Message Queue Protocol Released (15 messages)

    The Advanced Message Queuing Protocol (AMQP) specification 0.8 has been announced today by the newly formed AMQP working group which consists of JP Morgan Chase, RedHat, Twist, Iona, and others. AMQP is an open specification for queue-based messaging that is technology agnostic, designed for performance and completely interoperable; it defines defines a protocol and model for queue-based messaging. The AMQ protocol aims commoditize the messaging middleware industry and provivde true interoperability across technology stacks in any language or operating system. JMS APIs over AMQ could easily interoperate with .NET clients or any other language or platform that can communicate via AMQP. From Advanced Message Queue Protocol to Commoditize Messaging:
    "Every bank is spending tens of millions of dollars every year on MQSeries and Tibco RV just to send messages inside their own bank." John continued, "the goal is to take out the vendors and commoditize it", much like web servers have been commoditized by Apache. Messaging has not been commodized yet. Over 90% of messaging according to John is IBM and Tibco RV, a small percentage is owned by Sonic and the rest is shared by 30 or so other vendors, mostly JMS vendors. Just as today no one can try to sell a web server, in the future, AMQ aims to commoditize the middleware industry. Implementations of AMQP will also be required to be open and royalty free, which will most likely be backed by professional open source business models. RedHat is currently working on an implementation that will be built into the operating system, making AMQ as free and available as SendMail, and accessible from any technology API such as JMS. Since the protocol is open and interoperable, Cisco is working on hardware implementations in their routers which will work fine in-between AMQ implemenations in different technologies.
  2. Very interesting. JP Morgan Chase is the first name on the list. It actually is a "user". IBM, as a big "provider" is missing... From the news, it seems this is a communication protocol for underlying mechanism. Any impact to existing users? If I call JMS, do I have to modify my program? Wei Jiang Acelet Consume JMS tasks by clicking
  3. Very interesting. JP Morgan Chase is the first name on the list. It actually is a "user". IBM, as a big "provider" is missing...

    From the news, it seems this is a communication protocol for underlying mechanism. Any impact to existing users? If I call JMS, do I have to modify my program?
    I'd have thought there'd be a JMS provider turn up at some point which implements AMQP so no, JMS should be all you need on the Java platform. I made a few more comments on AMQP on the InfoQ site. James LogicBlaze Fuse: Open Source SOA
  4. I'd have thought there'd be a JMS provider turn up at some point which implements AMQP so no, JMS should be all you need on the Java platform.
    I agree with you on this one. All major JMS providers already provide client side APIs in C/C#, etc. So, for the application developers and the industry in all, the only reason to shift to "JMS over AMQP" would be performance and any other scalability features that AMQP has to provide. -GT http://gautam_tandon.home.comcast.net
  5. The key here seems to be interoperability. If I understand the intent of the spec correctly, brokers from different vendors will be able to talk to each other as long as they are AMQ compliant. So, if MQSeries implements AMQ and Tibco implements AMQ, they should be able to talk to each other and exchange messages (which would make bridge products less relevant). This is what I expect the key proposition of the spec to be.
  6. AMQP is client-to-broker. But has also be proven in a clustering scenario and in WAN bridging. This would mean, using your example, I could take the MQ client and use it to talk to the TibCo server if they were to support AMQP. If the protocol gains that level of stability and maturity then one can imagine a "Middleware Enabled Network" infrastructure (in hardware, ultimately, a bit like a SAN). This is the kind of convergence you need for SOA to take hold without fear of vendor lockin, and to allow that market to blossom and reach its potential. But none of this can happen unless people like those on the TSS community "get it" and are supportive enough to move forwards with this. Regards John O'Hara - JPMorgan
  7. Of course connecting brokers...[ Go to top ]

    ... is a lot like having one as the client of another, so connecting trading partners brokers over the Net is slated too; provided both sides have AMQP capability you don't care what software they're running.
  8. But none of this can happen unless people like those on the TSS community "get it" and are supportive enough to move forwards with this.
    Wouldn't buyin from the major vendors (IBM, etc.) help as well?
  9. But none of this can happen unless people like those on the TSS community "get it" and are supportive enough to move forwards with this.


    Wouldn't buyin from the major vendors (IBM, etc.) help as well?
    Given that IBM has so much market share in this area and one of the main effects of this would be to level the playing field for other players, I can't see them pushing this. What's in it for IBM? IBM would likely only come around if the standard was already widely accepted.
  10. Exactly![ Go to top ]

    This is the kind of convergence you need for SOA to take hold without fear of vendor lockin, and to allow that market to blossom and reach its potential.
    Either this or something else like it - HTTP just isn't going to cut it unless it is extended (mod_pubsub seems dead or going nowhere) last time I checked. And WS-* is DOA. Good luck!
  11. You're missing the point, you can talk RMI over JRMP or IIOP but the secret is to "speak" the same protocol. AMQP is a protocol much in the same way as HTTP. So, for example, you can use ANY HTTP server with ANY HTTP client, Apache talks to IE, IIS talks to FireFox (at least at the HTTP level). Just having a C/C++ interface is a start but it will not inter-operate with other implementations unless it implements AMQP. Sonic is a good example here, they provide a huge range of connectors and adapters but if you build your system around Sonic you'll be locked in. Build it around AMQ and you can use any AMQ vendor to impliment your messaging. At the moment IONA seems to be your best bet at this level. -John-
  12. >> I'd have thought there'd be a JMS provider turn up at some point which implements AMQP so no, JMS should be all you need on the Java platform.

    I agree with you on this one.

    All major JMS providers already provide client side APIs in C/C#, etc.
    I think you've got this backwards. One of the main points of JMS was to provide a common interface to existing messaging implementations. AMQP would seem to be expanding on this to interlanguage standardization.
  13. If this gains momentum[ Go to top ]

    I know many financial firms use MQSeries because other messaging systems don't come close. If this gains momentum and open source provides comparable reliability, scalability and throughput, it's going to get harder for IBM and Tibco. Competition is a good thing. peter
  14. Re: If this gains momentum[ Go to top ]

    I know many financial firms use MQSeries because other messaging systems don't come close. If this gains momentum and open source provides comparable reliability, scalability and throughput, it's going to get harder for IBM and Tibco. Competition is a good thing.

    peter
    I don't think that some of the other known solutions can't provide similar capitilities ( reliability, scalability and throughput,... ) too. Maybe, in some enterprises the decisions are influenced by political reasons. For this and naturally some other reasons, a product-selection can be destinated to some selective manufacturer. An other important fact too is, that today exists great potential on experts with extended Know-how in this mentioned products and the associated Business Processes too. Roland SOA & ESA Kompetenznetzwerk
  15. I know many financial firms use MQSeries because other messaging systems don't come close. If this gains momentum and open source provides comparable reliability, scalability and throughput, it's going to get harder for IBM and Tibco. Competition is a good thing.

    peter
    Unless of course you want to do pub/sub. MQ is great at P2P and terrible at large scale pub/sub. Ask 3 IBM employees which IBM product to use for pub/sub. Your choices are: MQ WebSphere Event Broker MQ 6.1 pure Java JMS impl / ESB You will get three different answers. As a messaging biggot, I will be very excited if this catches on.
  16. most of the cases I know of are P2P. it's probably a bias from an OMS (order management systems) perspective. I've used weblogic's JMS for pub/sub a few years back. I haven't used MQSeries for pub/sub, so I can't say anything meaning on MQ pub/sub. I have tested ActiveMQ for pub/sub and it did quite well compared to other JMS servers. peter