essage Queuing (MQ) has long been a foundation for applications that require asynchronous and disconnected communications. Implementations of Message Queuing such as Microsoft's MSMQ
, IBM's WebSphere MQ
, TIBCO's Rendezvous
, and Progress Sonic's SonicMQ
are all mature, highly reliable, and highly scalable. Now, Amazon, in a new bid to sell its capabilities as services, has entered the fray with its Amazon Simple Queue Service (SQS).
Until now, large vendors have hawked MQ services as infrastructure productsproducts clients buy licenses for and install on their own hardware; but Amazon's SQS is entirely based on a service model, with no upfront software licensing or hardware setup. Amazon SQS is a Web service in which all messages are sent through, stored on, and retrieved from Amazon's servers. All that's necessary is that your application understand and adhere to the SOAP, HTTP Query, or REST protocols that Amazon SQS understands. This article focuses on how to take advantage of Amazon SQS from .NET applications using SOAP.
Why Consider Amazon SQS?
There are several good reasons why your organization might want to consider Amazon SQS over another MQ solution:
- All communication between your applications and Amazon SQS is over HTTP and so for most of you will not require poking holes in your firewalls. This makes it perfect for applications that cross organizational boundaries.
- Amazon SQS has no upfront or ongoing hardware and software licensing costs. That's an attractive option, particularly when startup costs for current messaging products can mount to thousands of dollarsand maintenance can be equally expensive.
- Scalability is built-in. Amazon.com's existing and well-tested infrastructure provides your applications flexibility to scale on demand.
- You get the proven reliability of Amazon.com's resilient infrastructure without making any upfront investment.
Still, before you jump, there is a downside:
- You pay by the message volume and storage requirements to the tune of 10 cents for each 1000 messages and 20 cents per gigabyte of message storage required. So if your business requires a large number of messages or sends and receives very large messages, then you should commit to making a full cost comparison between traditional MQ software and SQS.
- You must trust Amazon.com with your message content. The license agreement does claim that "...we will not disclose, sell, or license your SQS Content
" but nevertheless, Amazon will have access to that content.
- Your applications must be able to tolerate the latency and vicissitudes of Internet connectivity. In other words, if you have applications with time-constrained throughput, don't throw your MQ infrastructure away just yet. In addition, Amazon SQS does not provide any local client storage, meaning that for applications to send messages, Internet connectivity to Amazon SQS is mandatory.
Without further ado, let's get started on the nuts and bolts of using Amazon SQS. The downloadable code
that accompanies this article is a Windows Forms-based application that provides an Amazon SQS dash board. In the remainder of this article, you'll see the steps required to set up an application to use Amazon SQS, and some practical example functions, such as retrieving a list of your Amazon SQS Queues and creating a message on Amazon's SQS Queue.
You will need Visual Studio 2005 (the Express Edition
works fine) and the Web services Extensions (WSE) for the 3.0 version of the .NET framework
installed to use Amazons' Simple Queue Service. Finally, you'll need the OpenSSL Tool
to convert Amazon's X-509 certificates to PKCS12a form that works with Visual Studio.