Thanks for the post. I’d just like to add a couple of comments. The Queued Server is used as a proxy, but it’s a bit more than that. It can be used just like a general web server, except that clients don’t have to know about the server.

When a client issues a request, it gets queued on S3. The Queued Server picks up the request (by querying the queue), processes it, and then puts the response back on S3. The client picks up the response, and processes it.

The request can be anything. The example we provide shows how to proxy soap calls, but it can be any request.

Using the Queued Server dramatically simplifies server design, because there is no IP address, or even a domain name. Both the client and server interface only with S3, so neither knows about the other. And since everything is hosted on S3, it eliminates the cross domain scripting issues.

Our GWT libraries make all this processing transparent, so a SOAP (or HTTP) request looks just like a normal request.

It’s really two parts – the GWT tools and the Queued Server. The GWT tools can be used independently or in conjunction with the Queued Server, which can also be used with or without the GWT tools.

But they work well together. The GWT tools and the Queued Server provide a very simple, but powerful, web programming model. You build the client in GWT, auto-deploy to S3, and then build a Queued Server to process the requests. No more web server, domain names, IP addresses, just a simple server written in any language to process requests.