Joe Gregorio
Tim has a nice article that begins to frame the discussion around Cloud Computing. I am not going to address the whole article, but only one aspect of it. Here are two quotations from that article that I want to focus on:
So here's my first piece of advice: if you care about open source for the cloud, build on services that are designed to be federated rather than centralized.
A key test of whether an API is open is whether it is used to enable services that are not hosted by the API provider,
Here is an example AtomPub Service Document
that combines two collections from two imaginary
services into a single service. For the sake of the
argument let's presume some-blog-service.org
only hosts blog posts but not media. And let's further
presume that pictures-r-us.org is a site
only interested in hosting your pictures and not your
blog text. I could handwrite the following
AtomPub Service Document and host it somewhere and
I should now be able to point a generic AtomPub blogging
client at said Service Document and have access to
a service that handles both blog text and images with
no apriori coordination needed between the two services.
<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://www.w3.org/2007/app"
xmlns:atom="http://www.w3.org/2005/Atom">
<workspace>
<atom:title>My Blog</atom:title>
<collection
href="http://some-blog-service.org/joe" >
<atom:title>My Blog Entries</atom:title>
</collection>
<collection
href="http://pictures-r-us.example.com/atompub/joe" >
<atom:title>Pictures</atom:title>
<accept>image/png</accept>
<accept>image/jpeg</accept>
<accept>image/gif</accept>
</collection>
</workspace>
</service>
I am in no way saying that AtomPub is the solution. What I am pointing out is that if you want federation then you need to design your protocols and APIs RESTfully. In this example it is hypertext, link following, in the AtomPub spec that allows these two separate services to be linked together.