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"
       <atom:title>My Blog</atom:title>
           href="http://some-blog-service.org/joe" >
         <atom:title>My Blog Entries</atom:title>
           href="http://pictures-r-us.example.com/atompub/joe" >

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.