Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Microsoft Embraces AMQP Open Middleware Standard 122

AlexGr writes to tell us that Microsoft apparently has plans to embrace a little known messaging standard called AMQP (Advanced Message Queuing Protocol). Red Hat, a founding member of the AMQP working group, was very excited about the news and wrote to welcome Microsoft to the party. "Suffice it is to say that AMQP is to high-value, reliable business messaging what SMTP is to e-mail. The proprietary message oriented middleware (MOM) products on the market today like IBM's MQ or Tibco's Rendezvous fulfill the same function as AMQP. But they operate exclusively in single-vendor fashion and utterly fail to interoperate with each other. They are also — perhaps not by coincidence — burdensomely expensive. As a result their use is mostly limited to wealthy organizations such as Wall Street banks (at least the ones who are still in business) that need to exchange huge volumes of business messages very reliably and very quickly. But AMQP's supporters feel the market for such reliable messaging could be much larger if a less expensive and truly open solution became available."
This discussion has been archived. No new comments can be posted.

Microsoft Embraces AMQP Open Middleware Standard

Comments Filter:
  • by fuzzyfuzzyfungus ( 1223518 ) on Monday October 27, 2008 @06:17PM (#25534335) Journal
    While "MS Embraces $STANDARD" is certainly rather unusual news(rather, instances of "MS Embraces $STANDARD" that aren't immediately followed by "and Extends" are), I'm not sure that this is actually a big strategic change for MS.

    For a while now, MS has been the big, bad, expensive monopolist, with *nix and FOSS the freedom loving underdogs; but it should be remembered that MS was once the scrappy, cheap alternative to Big Blue and the proprietary Unix club. In most areas that has changed, since MS has largely taken over and started to tighten the screws; but I suspect that crazy expensive corporate middleware is a fairly conservative market.

    This looks more like an alliance of the cheapish, freeish underdogs against the old school proprietary iron guys rather than a change of heart at MS.
  • by argent ( 18001 ) <peter@slashdot . ... t a r o nga.com> on Monday October 27, 2008 @06:23PM (#25534407) Homepage Journal

    While "MS Embraces $STANDARD" is certainly rather unusual news (rather, instances of "MS Embraces $STANDARD" that aren't immediately followed by "and Extends" are), I'm not sure that this is actually a big strategic change for MS.

    Hey, give them time. They haven't hardly had any time at all to come up with incompatible extensions, they don't even have a product out yet. I'm sure they'll come up with their usual high quality subtle inconsistencies and undocumented XML blobs in no time.

  • XMPP (Score:4, Interesting)

    by tmarthal ( 998456 ) on Monday October 27, 2008 @06:23PM (#25534411) Homepage

    This is the first that I've heard of this technology. Can anyone post how this is different than XMPP (http://xmpp.org)? XMPP is the updated name of the Jabber protocol.

    I know that every project that I get on, I try to dissuade the use of JMS (Java Message Service) and use XMPP instead. Is this more of a competitor to the JMS spec, since it "reliable"? (whatever that means)

  • by FranTaylor ( 164577 ) on Monday October 27, 2008 @06:35PM (#25534537)

    Perhaps they feel that Microsoft brings recognition to a technology that RedHat is poised to exploit in their products. RedHat is only too happy to compete with Microsoft on an even playing field.

  • by Kjella ( 173770 ) on Monday October 27, 2008 @06:40PM (#25534601) Homepage

    One might hope that other vendors would use it too, Microsoft may be big but not so big they can break any standard at will. At least in business middleware Microsoft doesn't have a monopoly on vertical will-only-work-with-our-own-products solutions.

  • Re:XMPP (Score:3, Interesting)

    by DragonWriter ( 970822 ) on Monday October 27, 2008 @07:39PM (#25535203)

    No, its not a freaking Instant message protocol. Its for inter computer communication for the doling out of tasks usually with in a cluster.

    XMPP, despite having originated as an IM protocol, has been used as a transport protocol for more general messaging.

  • AMQP for Beginners (Score:3, Interesting)

    by mpapet ( 761907 ) on Monday October 27, 2008 @09:06PM (#25535917) Homepage

    Here's a real-world application for AMQP.

    Let's say there are two banks, BA and WTF. Every day they have debits and credits flying back and forth.

    A protocol like AMQP makes exchanging messages (aka transaction) robust. Bank's IT guy gets mad and pulls the T1 out the wall at BA? Messages do a few things like wait in a queue at BA.

    The messages that were sent to WTF before the cable was pulled were processed by WTF and wait in a queue at WTF unti BA comes back online.

    That's a simple example. There is lots of information outside of the banking world where robust messaging is required.

  • Re:SMTP analogue? (Score:1, Interesting)

    by Anonymous Coward on Tuesday October 28, 2008 @04:03AM (#25538381)

    Suffice it is to say that AMQP is to high-value, reliable business messaging what SMTP is to e-mail.

    So it sort-of works but it's 30 years out of date and every man and his dog has a different opinion as to how to fix its gaping flaws?

    A few years ago I had a look at a very early draft of AMQP. Although I did spot (and report) some potential problems in the draft specification, there was one aspect I did like a lot: the authors had taken Moore's Law into account. For example, some of today's middleware protocols place a unique RequestId n the header of messages. When a protocol does that, the protocol designers should ask themselves "If we use, say, a 32-bit integer for that RequestId/i> then how long will it take at typical message exchange rates for that 32-bit RequestId/i> to overflow? Should we use a 64-bit integer instead?" The authors of the AMQP specification decided to assume that Moore's Law would apply to growth in areas such as bandwidth, quantity of messages exchanged, amount of data in each message, and so on. Based on this assumption, they decided they wanted AMQP to be usable for at least 50 years before having to worry about overflowing integers causing problems for uniqueness of ids or "message is too large to transmit" problems.

    I haven't kept up-to-date with how AMQP has been maturing so I don't have any comment on how good or bad it is in general. However, the idea of designing a specification so it can last at least 50 years of Moore's Law growth is something that all designers should keep in mind.

  • Defacto standard! (Score:3, Interesting)

    by supersnail ( 106701 ) on Tuesday October 28, 2008 @04:46AM (#25538537)

    The defacto standard in this area is Webshere MQ from IBM.

    It has something like 90% of the business relaible messaging market.
    All the other commercial products (MSMQ, Oracle, Tibco etc.) are niche players.

    MA is actually pretty cheap for a "Websphere" branded product starting from free for a
    try this at home folks windows installation, through a few $,000 dollars for a sizeable unix
    shop license to tens of thousands for a mainframe setup (This IS considered cheap for mainframe software!)

    If you can persuade your boss not to pay for software (always desparately hard in a business environment!) then ActiveMQ is the defacto standard for open source implementations. AFIK its just as good as IBMs product as long as you stay in the Java world.

    This all looks like an attempt to cause confusion and muddy the waters with yet another unstandard standard.

  • by aproposofwhat ( 1019098 ) on Tuesday October 28, 2008 @05:47AM (#25538795)

    MS was once the scrappy, cheap alternative to Big Blue and the proprietary Unix club

    When was that, exactly?

    For file and print services, Netware had NT beaten hands down - for RDBMS, Oracle ran way faster on Netware than on NT, and even the mainframe integration on Netware was light years ahead of the Microsoft offerings.

    Novell were just shitty marketers, so Windows (a perfectly adequate desktop OS) ended up competing against real server OSs by default.

    OK, the server flavours of Windows are better now than they used to be, but I'd rather run Linux, a proprietary *nix or (heaven forbid) IBM on a critical system than any number of Windows servers.

    I'd expect to see a couple of the big boys supporting AMQP soon - if only to stop Microsoft diluting and perverting the standard.

  • by E5Rebel ( 1103761 ) on Tuesday October 28, 2008 @08:29AM (#25539693)
    It is the "Extend" part that we need to be worried about because it is the gateway to making propitiatory additions to standards. There is a useful blog entry by Glyn Moody on Microsoft's tactics over Apache, where they have been 'cleared' to contribute patches. This will effectively fork the code, according to Glyn. Will the same happen here? http://www.computerworlduk.com/community/blogs/index.cfm?entryid=1407 [computerworlduk.com]
  • by DragonWriter ( 970822 ) on Tuesday October 28, 2008 @12:07PM (#25542401)

    ZeroMQ is not really a messages broker, messages are directly sent to the recipient without passing through any broker and this is what makes ZeroMQ different and fast. But the end result is that you get the same features as a messages broker, just faster and easier.

    Except, no, you don't get the features of a message broker. Particularly, you don't get reliable messaging. Its not really all that surprising that when you take the "middle" out of "middleware", you get a speed increase, at the same time losing a lot of what makes middleware useful.

Intel CPUs are not defective, they just act that way. -- Henry Spencer

Working...