|
Hosting AJAX on S3 with Openfount
For today's Friday podcast I interviewed Bill Donahue, who has a new
product called Openfount that
makes intriguing use of the Google Web Toolkit and Amazon
S3. Sadly I made a boneheaded mistake as I began to edit the
audio file, and wound up losing most of it. So after giving myself a dope slap I
resolved to write up an explanation of Openfount as informed
by our conversation.
Openfount's big idea is that a solo developer ought to be able to
deploy an AJAX application to the web without worrying about how to
scale it out if it becomes popular. If you park the application's
HTML, JavaScript, and static data files on Amazon's S3 storage
service, you can make all that stuff robustly available at a cost that
competes favorably with conventional hosting. But applications that
only talk to static data files aren't very interesting or
useful. You'll want them to talk to services as well.
For reasons of security, though, the XMLHttpRequest mechanism at the core
of AJAX can't reach beyond the origin server. And S3, as the origin
server, can host content but not services. So what to do?
Enter Openfount's Queued Server. Instead of contacting a remote server
directly, the AJAX client enqueues requests on S3, and reads responses
from S3. Elsewhere on the Internet, you locate the server that reads
those requests from S3, processes them, and writes the responses back
to S3. That server can offer services directly, can proxy for remote
services, or both.
Note that this server works more like a client, in the sense that it's
not listening for requests on a port, but rather polling S3. That's
obviously non-optimal, but according to Bill Donohue it's entirely
workable. And you can use many of these servers if needed. Openfount
uses a protocol to guarantee a one-to-one mapping of requests to
servers.
Another intriguing aspect of this setup is that the AJAX client
and the Queued Server are truly decoupled. The client doesn't know the
server's IP address, and indeed the server need not even have a
permanent IP address. In this architecture, Amazon's S3 namespace
plays the role of DNS.
The Queued Server is Java-based but, because it's so simple -- all it
really does is treat S3 as a queue -- versions for other languages
will be easy to create.
On the AJAX side, Openfount extends the Google Web Toolkit (GWT), adding
support for the S3 API, for XML and SOAP processing, and for
cryptography. I'd known that GWT apps are written in Java and then
translated into JavaScript, but hadn't thought about the benefits of
that arrangment. One is that
you can use the Eclipse IDE, with its robust debugger, to develop your
AJAX app. Another is that the Java-to-JavaScript
translator is a very general-purpose tool that can be used to port
Java libraries to the AJAX environment.
Although Openfount is currently GWT-based, Donahue says he's already
been asked to support other AJAX toolkits. First on the to-do list is Dojo.
I find the whole thing fascinating. A couple of years ago, there was a
lot of talk about how content delivery networks like Akamai were also
becoming service delivery networks. You'd write your service in Java
or .NET, configure it for a well-specified deployment target, and then
drop it into the network where it would replicate out to the edge.
I haven't seen a whole lot of action on that front. Meanwhile S3,
which was never designed as a service delivery network, is being
pushed by its users into that space. Perhaps "pushed by its users" is
the key point. As a general-purpose infrastructure, S3 makes no
assumptions about Java or .NET or Web services standards. Users who
push it in the direction of service delivery will show Amazon how they
want it to work. Then Amazon can, and I suspect will, react accordingly.
S3 just keeps getting more interesting. It's like a Rorshach
inkblot. People see it as backup, cheap bandwidth, cached content
delivery, application hosting, you name it. I'm really curious to see
where this goes next.
Update:
Julien Couvreur says via email:
Overall, OpenFount seems like a bad idea and I remain unconvinced of
the benefits of this architecture.
Doesn't Amazon already have a web service for queueing? Why use S3?
Also, S3 is a paying service. Doesn't polling add to your cost, by
creating lots of small requests from the client and from the back-end
server fulfilling the queued requests?
Also, in order to scale, it's not enough for your front-end servers to
be "web scale" like S3. Your back-end server, which is doing the
actual processing also needs to handle the load. S3 appears to be used
for load balancing, which is not the biggest problem in scaling...
Leveraging S3 for scale is nice, but it seems that it should be
combined with a cross-domain solution to support the most dynamic bits
(transactions and such).
Here was my response:
> Doesn't Amazon already have a web service for queueing?
Yes [SQS, or Simple Queue Service], and it would be preferable. But
it's only in beta as yet.
| Doesn't polling add to your cost, by creating lots of small
| requests from the client and from the back-end server fulfilling
| the queued requests?
Not if you only check headers, I believe, but good point, that should
be clarified.
| Leveraging S3 for scale is nice, but it seems that it should be combined
| with a cross-domain solution to support the most dynamic bits
| (transactions and such).
Yes, Bill realizes that. And I think we both saw this as an
exploratory and iterative thing, which could lead AWS to evolve its
API just as Google Maps was led by its early developer/users to create
and evolve an API.
Bill Donahue adds:
Here's the way I would summarize the Queued Server idea after getting
feedback:
1. Is it a perfect solution? No. But for users who don't have the
ability or money to set up a web infrastructure, it is the best
solution available now.
2. Could it lead to an almost perfect solution? Yes. A couple of
optimizations to S3/SQS would make it almost perfect.
Amazon seems very willing to pursue these ideas, so we'll see what
happens.
I like Richard
Wallis' take. On his blog he writes, in part:
Globally distributed SOA seems to be looming out of the mist, and it is a different shape to what was envisioned a few years back. No sign of the network of UDDI servers scattered about the planet, just lots of loosely coupled applications sitting above utility core services and domain specialist platform providers.
| 
NEWS 
