Entries created on Tue, 01 Mar 2005

So there's buzz around some new quasi-Open Source MQSeries¹ clone named AMQ. Supposedly, this thing is going to be used for Web Services and Service Oriented Architectures (SOA) in the financial industry initially but then grow horizontally. The idea being that message queuing provides a lot of the functionality not directly handed to you by HTTP, like reliable delivery, publish/subscribe, multiple subscribers, etc.

The article was kind of weird though because some of it doesn't make any sense:

Not only has AMQ drawn the participation of several banks, but also companies such as Red Hat Inc., Novell Inc. and Sun Microsystems Inc. are considering building AMQ into the kernels of Red Hat Enterprise Linux, SuSE Linux and Solaris, respectively, Davies said.

Wtf? No one is building message queuing functionality into the kernel, bro. That's user-land stuff.

Although Davies said he is an avowed Java aficionado and a supporter of the Java Message Service API, he said JMS "fails on the non-Java side as a transport mechanism."

That's like saying JDBC sucks at indexing my tables. JMS is a standard Java interface that various message queuing implementations implement so that coders don't have to write to vendor specific APIs. There's no transport mechanism involved. If AMQ is truly a MQSeries clone, it will have a JMS implementation wrapped around it within a month. Maybe the original intent was to say that no existing F/OSS MQ implementations have open wire formats? Or something?

I think what this article may have actually been trying to say (although we may never know because it is so full of hallow buzzwords) is something like the following:

1. We, the financial industry, hate proprietary shit.

2. We are tired of waiting around for you WS and SOA folks to actually produce something we can use.

3. We just want a non-proprietary MQSeries that we can use over the internet.

4. There are no open protocols for message queuing and, like we said, we need message queuing. Don't even start with that abstracting non-functional concerns crap. We need message queuing, period.

5. We have developed an open protocol for message queuing. We've done this, somewhat mysteriously, behind closed doors.

6. We've implemented this open protocol in C and C++ and we're going to make these implementations available under some kind of open license.

7. We're going to call this Web Services and SOA because that's what my boss' boss said he wanted and since none of you people can tell me what any of this stuff is, I don't think you can say it's not what we've built.

It seems reasonable to believe that all we're looking at here is an internet friendly protocol and app for chucking messages around in a secure manner which, to be honest, is probably all that's needed. Except it seems to be having an identity crises because it's talking about Web Services and we all know by now that Web = HTTP/URIs and AMQ will likely use neither.

REST is already eating one half of the WS-Sandwich on the web with WS-* retreating to Enterprise Level tasks. I don't think it's impossible to imagine a not-to-distant future where ad-hoc message formats pop up and start flying over this AMQ thing to eventually eat the other half of the WS-Sandwich.

WS-Crust anyone?

Footnotes

^1. I don't care that they rebranded it WebSphere MQ. It's MQSeries... Shut-up.

Yahoo! launched a Web Services interface today. I'm gushing with joy over their decision to follow proven web architecture and select a simple REST model over a more complex WS-* model. Let's take a look at an item pulled from their FAQ:

Q: Does Yahoo! plan to support SOAP?

Not at this time. We may provide SOAP interfaces in the future, if there is significant demand. We believe REST has a lower barrier to entry, is easier to use than SOAP, and is entirely sufficient for these services.

Get used to that answer. You won't ever hear it from the evil tool vendors but you can be damn sure you'll be hearing it from the smart service providers that really are looking to court developers.

Also, it was extremely cool to serendipitously stumble across mine own How I explained REST to my wife article after passing from Yahoo!'s Constructing REST Requests page to Wikipedia's REST page.