Amazon Simple Queue Service: Difference between revisions
No edit summary |
|||
Line 42: | Line 42: | ||
==External links== |
==External links== |
||
*[http://www.amazon.com/Simple-Queue-Service-home-page/b?node=13584001 Amazon Simple Queue Service homepage] |
*[http://www.amazon.com/Simple-Queue-Service-home-page/b?node=13584001 Amazon Simple Queue Service homepage] |
||
*[http://elasticmq.org ElasticMQ - replicated message queue implementing the Amazon SQS interface] |
|||
{{Cloud computing}} |
{{Cloud computing}} |
Revision as of 04:38, 23 March 2012
![]() | This article needs attention from an expert in Software. Please add a reason or a talk parameter to this template to explain the issue with the article.(November 2008) |
![](http://upload.wikimedia.org/wikipedia/commons/thumb/b/be/AWS_Simple_Icons_Messaging_Amazon_SQS_Queue.svg/220px-AWS_Simple_Icons_Messaging_Amazon_SQS_Queue.svg.png)
Amazon Simple Queue Service (Amazon SQS) is a distributed queue messaging service introduced by Amazon.com in April 2006. It supports programmatic sending of messages via web service applications as a way to communicate over the Internet. SQS is intended to provide a highly scalable hosted message queue that resolves issues arising from the common producer-consumer problem or connectivity between producer and consumer.
Amazon SQS can be described as commoditization of the messaging service. Well-known examples of messaging service technologies include Java Message Service and Microsoft Message Queuing. Unlike Java Message Service, users would need not maintain their own server, Amazon SQS does it for them and sells the service at a per-use rate.
Expected message latency, as of 2007[update], was 2-10 seconds.
Authentication
Amazon SQS provides authentication procedures to allow for secure handling of data. Amazon uses its Amazon Web Services (AWS) identification to do this, requiring users to have an AWS enabled account with Amazon.com; this can be created at http://aws.amazon.com. AWS assigns a pair of related identifiers, your AWS access keys, to an AWS enabled account to perform identification. The first identifier is a public 20-character Access Key. This key is included in an AWS service request to identify the user. If the user is not using SOAP (protocol) with WS-Security, a digital signature is calculated using the Secret Access Key. The Secret Access Key is a 40-character private identifier. AWS uses the Access Key ID provided in a service request to look up an account's Secret Access Key. Amazon.com then calculates a digital signature with the key. If they match then the user is considered authentic, if not then the authentication fails and the request is not processed.
Message delivery
Amazon SQS guarantees at-least-once delivery. Messages are stored on multiple servers for redundancy and to ensure availability. If a message is delivered while a server is not available, it may not be removed from that server's queue and may be resent. As of 2007[update], Amazon SQS does not guarantee that the recipient will receive the messages in the order they were sent by the sender. If message ordering is important, it is required that the application place sequencing information within the messages to allow for reordering after delivery.
Messages can be of any type, and the data contained within is not restricted. Message bodies were initially limited to 8KB in size but was later raised to 64KB on 2010-07-01[1]. For larger messages, the user has a few options to get around this limitation. A large message can be split into multiple segments that are sent separately, or the message data can be stored using Amazon Simple Storage Service (Amazon S3) or Amazon SimpleDB with just a pointer to the data transmitted in the SQS message.
The service supports both unlimited queues and message traffic.
Message deletion
SQS does not automatically delete messages once they are sent. When a message is delivered, a receipt handle is generated for that delivery and sent to the recipient. These receipts are not sent with the message but in addition to it. They are required to delete the message from the queue. This feature is new as of 2008 where only the message ID was required for message deletion. Because the system is distributed, a message may be sent more than once. In this case, the most recent receipt handle is needed to delete the message.
Once a message is delivered, it has a visibility timeout to prevent other components from consuming already delivered. The "clock" for the visibility timeout starts once a message is sent, the default time being 30 seconds. If the queue is not told to delete the message, using the receipt handle, before the timeout is over, the message becomes visible again and able to be resent. SQS automatically purges messages residing in queues for longer than 4 days. Amazon reserves the right to delete an entire queue without notification if it has not been accessed for 30 consecutive days.
See also
References
- "Amazon Simple Queue Service". 2011-07-08.