[occi-wg] Is OCCI the HTTP of Cloud Computing?

[Alexis Richardson]

Tim,

Thanks for this.

On Thu, May 7, 2009 at 12:17 AM, Tim Bray <Tim.Bray at sun.com> wrote:
> On May 6, 2009, at 1:44 PM, Alexis Richardson wrote:
>
>>  Failure is a possibility and for this reason
>> we have set ourselves a very tight schedule so that if we fail we can
>> fail fast and the interoperability community can learn from our
>> findings.
>
> FWIW, I've never seen a non-trivial language/protocol/API/standard/whatever
> designed in less than a year, elapsed.

We're trying to make use of work already done, as much as possible, to
move things along.  If we can get to a place where people can at least
properly explore interop, I think that's a good start for something
that will evolve (cf. your comments about how you are exploring the
Sun API by building some clouds).


>>> We are going to run with our CC-licensed REST API ...  There are other
>>> parties also experimenting with
>>> using it as a front-end to various cloud-computing services.
>>
>> Cool - can you or they contribute some use cases please?   We needs
>> dem use cases :-)
>
> Good point.  We have internal ones, had actually never thought of publishing
> them.  I'll see what I can do.

Awesome, thanks.


>>>  They do not rely on interoperable models,
>>> they rely on agreement on what bytes I send you and what bytes you
>>> send me and what the meanings of the fields are.  ....
>>
>> That sounds like a protocol mindset - consistent with your RFC comment
>> above.  But is OCCI a protocol?  Or is it an API?  What are your
>> thoughts here?
>
> I don't understand the difference, to be honest.

I think they are different - see below.


> The problem is that when you say API people expect object models and
> methods, and history should have taught us that those are very difficult to
> make portable across networks.  I confess to having a protocol mindset since
> I'm a Web guy.

You know much more about this than I do, so at the risk of looking
foolish, I'll pedantically state my own view on protocols vs APIs.

* Protocols can specify a sequence of behaviours, eg a 3-way handshake
to establish a connection, eg also continuations (such as used by
trickles - http://www.cs.cornell.edu/~ashieh/trickles/index.php)
* APIs are functional, so remain silent on what happens after a
request is replied to.
* By specifying behaviour, protocols disambiguate more interaction
scenarios thereby improving interop.
* Example API - JMS. It's hard to swap out one JMS server for another
because they may behave in different ways.  Often the client and
server must be provided by one vendor and, indeed, taken from one
software distribution.  Versioning can be a problem.
* Example protocol - TCP.  This is basically plug and play if you
stick to the core.  Same for HTTP.  You can get a browser from one
vendor and it should work with someone else's web server and web site.
* Often, but not always, protocols are based on wire formats, reducing
the scope for variations due to language choice, for example nuances
between how the JVM and CLR model objects.  Returning to JMS as an
example, it's a fiddle to get JMS working well in .NET.

Most internet RFCs are protocols afaict - hence their success.

IMO, the 'good' REST/HTTP designs enforce a protocol-like discipline,
even though the limitations of HTTP plus the focus on nouns and verbs
also admit of API-like designs.  I'd suggest that HATEOAS forces
interface designers to think in terms of application state evolving
outside the scope of a single HTTP request, therefore it pushes them
towards a protocol way of thinking.  By constrast, RESTful interfaces
that implement pure CRUD, look a lot like CRUD APIs that just so
happen to be expressed using HTTP verbs.

/end digression




>> More generally: What is the right way to make a cloud interface more
>> like a protocol?
>
> My opinion: Be RESTful, to the extent possible.

+1



>> How would you recommend we deal with cases where XML is well supported
>> but JSON is not well known?
>>
>> * .NET
>> * Many 'enterprises'
>
> Hmm... if you're in Java or Python or Ruby or of course JavaScript, it's
> super-easy to consume and generate JSON.  If C# & friends are behind in this
> respect I can't see it staying that way for very long, my impression is that
> those guys are serious about keeping up with the joneses.
>
>> If we 'went with JSON' then would it be plausible to have XML adaptors
>> for non-JSON settings?
>
> Specifying the mapping is extra work.  I suggest that YAGNI.

If we agree that all our data formats *can* be written in JSON, then
an option for OCCI's initial deliverable is to mandate that they are
written in JSON or at least provide this as a reference.  I'd like to
see a list of objections to this.




>> What about plain text - any view on that?
>
> Well, in our API, it turned out that the things we wanted to send back and
> forth were numbers, labels, lists and hashes.  Without exception.  JSON had
> everything we needed built-in and nothing we didn't need.
>
>> Do you think Atom is a bad thing for our use cases?
>
> I'm not sure; I enumerated the things that I think would make Atom
> attractive.  For our use cases in the Sun API, it didn't seem like a
> terribly good match.

OK.

alexis