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.
Former URL: http://weblog.infoworld.com/udell/2006/07/07.html#a1483