[occi-wg] OCCI Model UML, XSD, XML, Code...

Mon May 25 11:56:30 CDT 2009

Andy,

Thanks for your efforts - I find it easiest to look at this
rendering<http://forge.ogf.org/sf/wiki/do/viewAttachment/projects.occi-wg/wiki/NounsVerbsAndAttributes/occi-instance.xml>to
work out what it boils down to and I can't help but to notice there
are
already some strong similarities with Atom (as well as some serious
limitations courtesy the "simplification"):

   - How do I tell the difference between resources without a unique
   identifier (Atom "id")
   - How do I tell when the resource was updated (Atom "updated") and/or
   what version it is (ETag)
   - How do I find one or more resources by search/category/tag/etc.?
   - How do I represent a single object?
   - How do I differentiate between tag vocabularies - "small" and
   "virtualmachine" are talking about two completely different concepts (Atom
   "category")
   - How do I create generic links to supporting resources e.g. screenshots,
   consoles, etc. (Atom "link")
   - How do I create associations with arbitrary resources e.g. users (Atom
   "link")
   - How do I carry critical information that we nonetheless consider out of
   scope (e.g. OVF)
   - How do we extend the spec? (e.g. rinse & repeat)
   - How do vendors/users extend the spec? (e.g. namespaces?)
   - How do I import/export resource(s) (e.g. OVA)
   - etc.

You need not answer these questions but the thought exercise should leave
you with something that looks almost identical to Atom. I know because this
was the exact process I used to arrive at Atom in the first place - library
and information science is similar regardless of the subject.

Following a (long) conversation over (numerous) beers with Alexis on Friday
I have come to the conclusion that the meta-model is quite separate from the
representation, which is to say that collections, organisation, association,
etc. can be done generically while providing a simple "OCCI" representation
of the various resources is a domain-specific task.

For the former (meta-model) HTTP and/or Atom clearly make the most sense but
for the latter we need to be careful not to end up reinventing CIM. Gary's
list of network attributes gave me pause over the weekend and I think the
best way to filter this is to consider what functionality is
*supplied*rather than what functionality is
*demanded*. That is to say, today public cloud providers do IPv4 so we
provide attributes for IPv4. If multiple vendors do IPv6 we add IPv6. If
nobody does IPX/SPX then too bad for those who need it. This stuff still
needs to go somewhere though, which is why multiple representations are
essential.

If it wasn't already clear, I'm *very* anti the approach of modeling the
problem and blatting out one or more representations, irrespective of the
delimiters used. A lot of good work has already been done on HTTP and Atom
meta-models and giving everyone else the forks by creating yet another
domain-specific language is not something I plan to be in any way associated
with... the result will almost certainly be an interop train wreck not
unlike WS-*

In summary I'd like to see us use Atom where absolutely necessary (e.g.
collections) and raw HTTP with multiple representations everywhere else. One
of those representations can be a restricted syntax based on features with
multiple deployments (but users would also be free to send/receive OVF or
even their own home grown guff if they want).

Sam

On Mon, May 25, 2009 at 5:57 PM, Edmonds, AndrewX <andrewx.edmonds at intel.com
> wrote:

> I've been spent some time on the proposed meta-model [1] and model [1] UML
> that is up on the wiki along with the inputs of others. Following some
> discussions with Roger and Andre, I decided to take the model in its UML
> form and create the corresponding XSD. In fact Roger might have the a RDF
> version of the XSD sometime. This XSD can be found here [2]. Now I don't
> class myself as a XSD expert so any comments, updates etc are appreciated.
> From this XSD I was able to generate an API to create and manipulate an
> in-memory representation of a model instance. This example code can be found
> here [3]. It's Java and uses XMLBeans[4], but there are many other libraries
> out there that will allow the generation of an API in languages such as
> Python[5], Ruby[6], CSharp[7] (typically any language that has SOAP
> libraries will have an XSD class generator). After rendering the in-memory
> model the XML rendering is specific but adheres to the OCCI model schema and
> can be viewed here[8]. Again how things appear in the XML can be tweaked via
> iteration of the schema. For those JSON peeps out there there's an already
> XSLT transform sheets out there that will convert this XML to JSON using
> different conventions [9][10].
>
> This model is abstract in a sense it does not import any dependencies, such
> as Atom. @Sam perhaps you could take what I've done and either by way of
> model inheritance or composition show how Atom would integrate with this
> model?
>
> My view on Atom is that it is useful as a wrapper to renderings of OCCI
> model instances. If I wanted to publish an OCCI model via Atom then I'd
> insert a model instance rendering into an atom:entry element (note we could
> include JSON via CDATA but this is where JSON perhaps gets a little ugly).
> This would be OCCI using Atom by way of composition and would allow both
> Atom and OCCI live harmoniously together or separately and not require Atom
> dependencies should that be the choice of a provider. What's important is
> that the OCCI model be it via Atom or something else could be understood by
> a receiving system. Using Atom with OCCI by way of inheritance makes the
> previous "with or without" approach a little more difficult as there's a
> hard-dependency on Atom.
>
> Atom reminds me somewhat of WS-Agreement, SOAP etc. It doesn't solve your
> domain-specific model problems (i.e. what you are trying to represent -
> OCCI==Infrastructure), only provide a means to send this content about and
> mechanisms supporting this but perhaps not directly to the model contained
> as content. We still have to understand and represent our
> noun/verb/attribute triplets. Atom doesn't really help out bar the features
> it offers by way of sitting on top of HTTP. Now of course you can extend
> Atom base types (in fact AFAIK they're just xs:complexTypes W3C XSD types)
> but the point is you have to extend them to _something_. That something is
> your domain specific model. There is value however in Atom, not from the
> model point of view - it's a very simple model. The value in Atom is in the
> directions the specifications gives pertaining to Atom service behaviour.
> Another way to view Atom is the interoperability glue in between the now
> almost commonly accepted cloud stack of Infrastructure -> Platform ->
> Service. This is where OCCI could learn quite an amount but when you
> consider that the basis of these behaviours are steeply entrenched in REST
> design principles it's easy to see 1) why Atom is attractive 2) that you
> don't necessarily need Atom to have correct and/or standard service
> behaviour - just adopt good, sound REST design principles!
>
> On more specifics and related to the attributes of each noun, we are still
> rather under-specified especially in the Storage and Network nouns. @Richard
> and @Gary (in separate threads) started a useful discussion on attributes
> for these nouns. Perhaps you two guys could add your findings and
> suggestions to the wiki?
>
> Andy
>
> PS: for those of you wanting to run the code I've exported the eclipse
> project and can be found here [11].
>
> [1]
> http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/NounsVerbsAndAttributes
> [2]
> http://forge.ogf.org/sf/wiki/do/viewAttachment/projects.occi-wg/wiki/NounsVerbsAndAttributes/occi.xsd
> [3]
> http://forge.ogf.org/sf/wiki/do/viewAttachment/projects.occi-wg/wiki/NounsVerbsAndAttributes/OCCITest.java
> [4] http://xmlbeans.apache.org
> [5] http://www.rexx.com/~dkuhlman/generateDS.html<http://www.rexx.com/%7Edkuhlman/generateDS.html>
> [6] http://dev.ctor.org/soap4r/browser/trunk/bin/xsd2ruby.rb
> [7] http://xsd2code.codeplex.com/Wiki/View.aspx
> [8]
> http://forge.ogf.org/sf/wiki/do/viewAttachment/projects.occi-wg/wiki/NounsVerbsAndAttributes/occi-instance.xml
> [9] http://code.google.com/p/xml2json-xslt/
> [10] http://www.bramstein.com/projects/xsltjson/
> [11]
> http://forge.ogf.org/sf/wiki/do/viewAttachment/projects.occi-wg/wiki/NounsVerbsAndAttributes/OCCIModel-eclipse-project.zip
>
> Andy Edmonds
> skype: andy.edmonds
> tweets: @dizz
> tel: +353 (0)1 6069232
>
> IT Research - IT Innovation Centre - Intel Ireland Ltd.
> Intel Ireland Limited (Branch)
> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> Registered Number: E902934
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> -------------------------------------------------------------
> Intel Ireland Limited (Branch)
> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> Registered Number: E902934
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090525/16928a93/attachment.html 