Openfount Queued Server

The Openfount Queued Server looks really interesting. It took me a little while to understand the architecture, but this was time well spent.

Basically, this technology interposes a set of processing queues between a web client and a backend server. The queues are apparently implemented using our S3 and SQS services. The client never talks to the server directly. Instead, it uses APIs from the Queued Server toolkit to write messages into a queue for processing by the server. The server processes messages and then writes return values into another queue, where the client picks them up and displays the results. 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.

Because the server is actively polling the queue for messages, it need not have any public interface at all. No domain name, no IP address, and no vulnerability to well-known generic attacks. In fact, the server could be running behind a cable modem with a dynamic IP address and no one would be the wiser, since it simply reaches out to the world via standard HTTP requests over port 80. In this model the server never accepts incoming calls directly. It reaches out and pulls in requests, and can be very, very choosy about the requests that it accepts.

The clients and servers are isolated and protected from each other. It appears that the client need not even know the domain name or the IP address of the server!

It should be very easy to build very scalable web applications using this technique. When the server is momentarily busy the queues will simply back up a little bit. Since the server is in full control of request processing, it should never get flooded with requests. If the load becomes too much for one server to handle, it should be easy to add more servers. In either case, S3 and/or SQS provide the "elasticity" needed to allow the application to deal with an uneven traffic flow.

There's a tiered pricing model based on the number of unique users per month. Fees start at just $3 per month (100 users or less) and go up to $83 per month (one billion users or less). It isn't clear if this includes fees for S3 and SDS or not.

Update:Bill Donahue, developer of the Openfount product, has posted a must-read followup comment.

-- Jeff;

Comments

[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
>server!

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.

Bill

[Jin]

hi bill,

I found your domain name question was answered at this forum post http://developer.amazonwebservices.com/connect/thread.jspa?threadID=10967&tstart=0

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

Jin