Amazon Simple Queue Service (Amazon SQS) offers a reliable, highly scalable hosted queue for storing messages as they travel between computers. By using Amazon SQS, developers can move data between distributed application components performing different tasks, without losing messages or requiring each component to be always available. The following operations are provided:

• CreateQueue: Create queues for your own use, or to share with others.
• ListQueues: List your existing queues.
• DeleteQueue: Delete one of your queues.
• SendMessage: Add any data entries to a specified queue.
• ReceiveMessage: Return one or more messages from a specified queue, which are returned in roughly the same order it was added to the queue.
• DeleteMessage: Remove a message from a specified queue.
• PeekMessage: Return a specific entry from the queue without locking it.
• SetVisibilityTimeout: Control the amount of time after a message has been read that is locked from being read again.
• AddGrant: Allow other users to send messages to or receive messages from your queue.

The pricing is simple: $0.10 per 1,000 messages sent ($0.0001 per message sent), and $0.20 per GB of data transferred. The code looks quite straightforward. From the Enqueue sample, here's the actual sending code (after some setup that includes authentication data):// Authenticating the Request SignRequestHandlerHMAC.setWSSecurityInfo(AWSAccessKeyId, SecretAccessKey); // Create a QueueService object, a Queue QueueService service = getQueueService( url ); // Create the message queue object MessageQueue msgQueue = getMessageQueue( service, queueName ); String msgId = msgQueue.sendMessage( message );What do you think of the product and its implementation?

I applaud them. This is another long-term bet on their part to provide basic infrastructure for internet-based distributed applications. You'd have to send a LOT of messages to get anywhere near the cost of a WebSphere MQ license! :-)

This service is available since a year or more. Have there been any significant improvements since it was first announced?

What would prompt any money making real-world business to use this? This may be attractive to freelance developers trying to build the next bittorrent/search-engine, but it would be tough to make money from. Bad from a shareholder perspective.

It's a very lightweight way to set up reliable messaging between two different businesses. I can see the OSS frameworks like Django/Rails using this as one possible lightweight messaging impl.

Simple, it doesn't cost them much if anything to provide the service. Amazon is basically exposing the services it already uses in house out to the public. It already has a customer service arm set up to handle its file storage service, as well as to support developers who want to interact with Amazons store APIs. Adding this ability costs them essentially nothing. The benefit of it is that it makes ad hoc integration easy from disparate sources. Now you can use a queuing service that scales and is trivial to set up to integrate the two PHP apps you have running at GoDaddy (or whatever $5 host you're using). Now you can make micropayments for infrastructure rather than hosting and maintaining all of it your self.

I alwady use their S3 storage service and it works great and the price is good.

I guess developers would have to build their own transaction controls on top of this API? thanks Johan

I guess developers would have to build their own transaction controls on top of this API?

thanks
Johan

Very well asked. I guess thats why it is named "Simple Queue Service" and hey, how hard can implementing transactions be ? ;-)

I worry about privacy concerns. Now amazon can sniff the data and wonder how they might use to futher their own agenda.

I worry about privacy concerns. Now amazon can sniff the data and wonder how they might use to futher their own agenda.

Ever heard of encryption? Of course you should worry about confidentiality when using external services... but it should go without saying that it's not very different from worrying about your ISPs sniffing the traffic.

Why oh why can't you write the screen of code necessary to do this with a database table? what's the point of this acronym mess? help me understand how you "architects" think, I don't think you people do.

What if you don't have a database in your system? Maybe I want to hook up several Swing rich clients on separate continents via a queue. This service has the potential to unlock new types of low-cost deployments. You might consider spending less time insulting others and more time thinking.