Recent AWS Customer Success Stories & Videos

More AWS Customer Success Stories...

« Case Studies | Main | Top City Books - Three Way Mashup »


TrackBack URL for this entry:

Listed below are links to weblogs that reference Openfount Queued Server:

» Openfount Queued Server from Stefan Tilkov's Random Stuff
The Openfount Queued Server is based on Amazons S3 very cool stuff. More information on the Amazon Web Services blog, some comments by Richard Wallis [via Mark Baker].... [Read More]


Feed You can follow this conversation by subscribing to the comment feed for this post.

Charles Kendrick

With that model, the "server" could be a browser. Sounds odd, until you consider that if you had an AJAX client, you'd be able to write the "server" with the same technology.

Bill Donahue

Hi Jeff,

Your post is spot on. Currently, we use S3 exclusively, due to the well known cross domain scripting issues with XmlHttpRequest. The Ajax application is hosted on S3, and all client interaction is directly to S3, so there are no cross domain issues. However, we would 'love' to use SQS. The only reason that we can't, is because the domain name of the SQS soap calls are different from S3, so any XmlHttpRequest will fail on the client. If the domain names were the same, then we could use both. SQS is the corrent abstraction. We simulate queues on S3, and have a protocol that is used to make sure each request is only handled by one server (if you have multiple servers processing the same queue). But SQS already has this built in, so we're just reinventing the wheel to get around this very irritating XmlHttpRequest restriction.

There is work being done to fix the XmlHttpRequest issue on the client side, but aligning all the browsers will take time, and may not even happen. If you have any influence over these issues, we're 'begging' - make the domain names for S3 and SQS the same! It's a good business proposition for Amazon as well, since SQS would be used to process the request/response traffic for a typical web application, if they are using a Queued Server. As you state in your post, S3 (or SQS) is being used to buffer any bandwidth mismatch between the client and server, among other things. It could generate lots of income.

>It appears that the client need not even know the domain name or the IP address of the

Yes, this is corrent, the client and server know nothing about each other. Both only interact with the queues on S3. So for applications requiring privacy, it should be the preferred architecture. It also dramatically simplifies server side programming.

>I can't tell for sure, but I am assuming that the client has some form of event loop or
>notification system, making it easy to build dynamic, Ajax-style applications.

Yes, this is correct. It's a notification. An Ajax SOAP (HTTP) call passes in a callback that gets called when the request completes. From the programmmers perspective, everything looks like a normal soap call to an arbitrary endpoint.

>It isn't clear if this includes fees for S3 and SDS or not.

No, the fees don't include S3 or SQS. As you can see our fees are very low. The most anyone will pay, is $83 a month, and that's for over one billion users per month.

To give you an idea of the costs, the development of our sample client and the Java Queued Server cost us a few dollars (<$10). Granted, there weren't many users, and the client just does a single soap call when you click a button. Nevertheless, anyone with a Web 2.0 idea can quickly get to market for a few dollars.

Since the server only interacts with S3, you can write it in any language. We supply the Java server now, and are going to add one for each language that S3 supports, including Python, Perl, and Ruby. You could even write a server using a command shell, since there are curl tools for interacting with S3.

Thanks for the post.



hi bill,

I found your domain name question was answered at this forum post

"When the production version of SQS launches,its URLs will also end in"


The comments to this entry are closed.

Featured Events

The AWS Report

Brought to You By

Jeff Barr (@jeffbarr):

Jinesh Varia (@jinman):

Email Subscription

Enter your email address:

Delivered by FeedBurner

April 2014

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30