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

[Sam Johnston]

On Thu, May 7, 2009 at 9:32 AM, Alexis Richardson <
alexis.richardson at gmail.com> wrote:

> Sam,
>
> On Thu, May 7, 2009 at 12:57 AM, Sam Johnston <samj at samj.net> wrote:
> >
> > I can see some value in running a knife down the middle... hence the talk
> > about OCCI Core vs OCCI IaaS - where the former is a protocol ala HTTP
> > (actually based on HTTP + Atom + magic fairy dust for search, caching,
> etc.)
> > and the latter more an API that animates the resources with
> > controllers/actuators, network and storage links, attributes, etc.
>
> Admittedly I don't fully understand this but at face value I'd suggest
> providing 'Core' first, whatever that is.
>

The ideal core protocol would contain no references to infrastructure,
rather allow manipulation of resources (CRUD, linking, actuators)
irrespective of what the resource was. It would thus be reusable for any
resource (as Google have done for 16 different
services<http://code.google.com/apis/gdata/>and who knows how many
different resource types already with GData).

The IaaS part would then define compute, storage and network resources and
the various actions and linkages that make sense, leaving as much room as
possible for innovation but ensuring the common parts are interoperable. In
a year or two when people realise infrastructure is boring we'd just need to
define resources for platform and software services rather than rewrite the
protocol (almost certainly without backwards compatibility), or worse,
create a new one.


> >> > How would you recommend we deal with cases where XML is well supported
> >> > but JSON is not well known?
> >> >
> >> > * .NET
> >> > * Many 'enterprises'
> <snip>
>
> Personally I am in favour of JSON if it works and endorse Ben's
> comment about not being tied down to whatever is in Visual Studio
> today.  I do think .NET will support JSON as a first class data format
> in its official tools.
>

I've made it quite clear that I don't believe JSON will work (giving various
technical reasons for same though there are various non-technical reasons
too) and was hoping to see at least some of the outstanding questions
addressed today now everyone's back to work.

"First class citizen" support of JSON is another of the more serious
concerns - as it's executable(!?!?) JavaScript code it's obviously a first
class citizen for JavaScript, but even for Java there are no less than 18
different projects listed at json.org in addition to the unsupported
reference code <http://www.json.org/java/>. Enterprise movers and shakers
will be pleased to know Python has just added the json
module<http://docs.python.org/library/json.html>,
only most of them are lucky to be using 2.5, let alone 2.6/3.0. For
Microsoft's .NET languages though they're out of luck (except for some JSON
code buried in ASP.NET AJAX <http://www.asp.net/ajax/>) and it's the same
story pretty much wherever you look - with the exception of PHP, native (let
alone "first class citizen") support of JSON is very much a work in
progress.

Most of the enterprise developers I know/work with wouldn't be allowed to
touch most of this stuff without approval which (depending on the
organisation) can be notoriously difficult to get - especially where legal
has to approve the license. Native support is no problem though and I doubt
there's a language in common use today that lacks native XML functionality.
Ask again on an OCCI 2.0 timeframe.


> If it is acceptable to use JSON in OCCI in order to stick to one
> format for now (and learn from Sun's work) then great.  I note that
> GData supports JSON.  I'd like to hear more from the .NET and
> 'enterprise' crowd though.
>

Has anyone (including Sun for that matter) implemented, let alone achieved
interoperability with the Sun Cloud APIs? If not, what is there to learn
that we haven't already gleaned from them (e.g. actuators)? I'm very happy
to have Sun involved in this process (especially veterans like Tim) but they
have stated they have no plans to implement the API I do think our
requirements differ somewhat - Sun need an API for exposing the
functionality of a specific public cloud service while we need one for
exposing the [current and future] functionality of *every* service, public
and private (including arbitrarily complex enterprise systems).

Also am I the only one to notice that JSON is not in fact a standard, rather
the work of one (admittedly rather clever) Yahoo
engineer<http://en.wikipedia.org/wiki/Douglas_Crockford>?
RFC 4627 <http://www.ietf.org/rfc/rfc4627.txt> is informational and "does
not specify an Internet standard of any kind", having crept in under the
guise of defining the application/json media type. That's fine for
integration/convenience, but not for interop. Is it even possible (let alone
sensible) to build a standard on top of a non-standard? Is there any
precedent for SSO standards based on JSON? I still can't find any successful
JSON-only APIs in the wild and this is one of my outstanding questions.

>> > 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.
> >
> > I'll check it out.
>
> Great!
>

Ok so I'm an idiot (perhaps we both are) -
YAGNI<http://en.wikipedia.org/wiki/YAGNI>is basically saying we don't
need multiple formats despite there being
various demands for same. It does seem likely that Sun don't need multiple
formats for their service, but that's not to say we don't - the TXT format
is an absolute requirement for use case E.2. "Simple scripting of cloud from
Unix shell<http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/SimpleScriptingOfCloudFromUnixShell>"
for example

>> > 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.
> >
> > I definitely want us all to be on the same wavelength whatever we end up
> > doing, but I also want to avoid closing doors unnecessarily (e.g. for
> > enterprise/private cloud deployments). Sun Cloud API does look
> particularly
> > good for public cloud (certainly better than the incumbent).
>
> We do need to be careful about the difference between sticking to our
> charter to the letter (public cloud first) and not closing doors.
> It's a fine line.
>

Perhaps I'm going too far with genericity/extensibility but better too far
than not far enough. This is more a side effect of accelerating change and
not knowing what computing will look like next year, let alone for the
entire useful lifetime of the standard!

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090511/84cbefeb/attachment.html