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

[Sam Johnston]

On Tue, May 26, 2009 at 11:55 AM, Edmonds, AndrewX <
andrewx.edmonds at intel.com> wrote:

>  Creating our own protocol, from scratch, with our own ideas as to how
> things should be represented, categoried, associated etc. significantly
> raises the risk of failure as well as the barrier to entry - that's reason
> enough in itself not to do it, particularly when perfectly good alternatives
> already exist. My point is that your current proposal is very nearly Atom
> anyway so why not just use it? Your "simplification" complicates.
>
>  [AE: ] the Atom issue: that’s why I asked you to take the most basic model
> and use it in an Atom context (inheritance or composition). Update: the
> example on the wiki is interesting!
>
Yes, I'm sure you'll agree there's no more fat to cut off when using raw
HTTP and the advantage of being able to use HTML forms directly makes for a
trivial API to interface with.

> Surely the requirement for a unique identifier for each resource is so
> bleeding obvious that it's implicit... you can already add an "id" field.
>
> [AE: ] stating that something is implicitly obvious is not enough for a
> specification
>
It's in the existing specification - it just vanished from yours.

>  [AE: ] Agreed and nor am I arguing against HTTP and do see its value. My
> response was in the context of the model in question.
>

So it would follow that you're ok with raw HTTP for individual resources?

 So these things can exist independently of groups? I'd have known that
> already if it were a common format but here I have to resort to reading the
> XSD.
>
> [AE: ] You have to read something to understand a specification – some will
> read things raw, others higher level formalisms. Personally I got more out
> of reading OVF’s XSD than I did reading a rendering of it or the IIOP spec
> doc than decoding CDR PDUs.
>
My point is that it should not be necessary to RTFM (and it isn't if you use
protocols that people are already familiar with).

>
>
>  [AE: ] J tag == folksonomy. I guess you are referring to ontology?
>
>  Taxonomy - a subtle but important difference.
>
> [AE: ] Ok so sounds like another requirement for the OCCI registry, if you
> deem necessary a managed set of hierarchical terms. Do we want to manage
> something like this or should we let each provider manage their own set of
> terms?
>
I didn't say hierarchical but categorisation is a different animal to
tagging. People will need to group by things like operating system,
location, business unit, data center, security levels, etc. and we should
give them a reasonable amount of flexibility to do so.

> This is yet another reimplementation of an existing, well established
> concept that developers will have to learn.
>
> [AE: ] Again, it would be great if you could show us how to reuse
> atom:linkType and extended with the requirements listed at the
> nouns/verbs/attributes wiki page.
>
Why would you graft parts of an existing standard into another, knowing that
you're then introducing multiple namespaces just to get the base protocol up
and running? I've previously given various examples of fleshed out Atom
links - you just need to graft them in and namespace them (e.g.
<atom:link>).


> How do I carry critical information that we nonetheless consider out of
> scope (e.g. OVF)
>
>
>
>  [AE: ] can introduce xsd:anyType into the model easily
>
>  Ok so I've got an anyType and I want to know what it's for (relation) and
> how to read it (content type) - how will that be expressed? Yet again, all
> roads lead to Atom.
>
> [AE: ] How does Atom do it? From what I can see atom:entry allows for
> atom:contentType, which is just a sequence of xs:any – problem you describe
> still remains with Atom.
>
It specifies rel= and type= attributes on the links as well as making
provision for extension (e.g. local identifier like "eth0").

>
>    - How do we extend the spec? (e.g. rinse & repeat)
>
>  [AE: ] Extend the XSD.
>
>  As I said. Anyway I've thus far managed to avoid having to touch XSD so I
> guess we'll have to schedule an XSD vs RELAX NG schema war at some point
> too... in any case better schema than no schema.
>
> [AE: ] Careful not to feed the trolls :p This is a potential flame indeed
> but if someone wants to propose something contra to XSD then code it up and
> offer it for consideration.
>
Iff a convincing case is made for building from the ground up (and I am
convinced by it) then I'll do exactly that... until then I'll make do
without.

>
>    - How do vendors/users extend the spec? (e.g. namespaces?)
>
>  [AE: ] As above plus some notions of governance from OCCI, yet to be
> discussed.
>
>  The point is the problem is already solved [by Atom] and we're going to
> have to cover the same ground.
>
> [AE: ] Problem of governance? If it’s that have you more details? Issue of
> XSD import and entity extension are dealt with.
>
The Atom spec devotes an entire section to Extending
Atom<http://tools.ietf.org/html/rfc4287#section-6>...
this is something you would have to consider and codify yourself if you were
to stray from the beaten path.

>
>    - How do I import/export resource(s) (e.g. OVA)
>
>  [AE: ] Now we’re into application specific functionality/features…
> something of an orthogonal for modelling activities. Perhaps closest here is
> model transforms.
>
>  I'd say that this requirement is extremely pertinent for model
> discussions - it obviously needs to support this functionality somehow or it
> will be impossible to get anything in/out of an implementation (and
> therefore to achieve portability between them). Transforms are something
> else entirely.
>
> [AE: ] Just to be clear, the requirement in the general is the need to
> support multiple existing resource representations OVA being one along with
> others such as OVF?
>
Yes - our own narrow view of the world is only a very small part of the
detailed representation(s) required to enable portability.

>  Your "nice" is my "necessary". Units are optional - at the very least we
> need to specify the smallest units (e.g. Mb for memory) but after that
> making the protocol pretty [to humans] makes it harder to interpret [for
> computers] - and therefore less interoperable. Jury's still out on this one
> for me.
>
> [AE: ] Lets mark the need for arbitrary infrastructure parameters in the
> wiki. Tell any scientist that units are optional! J Unfortunate things
> (NASAs Mars Climate Orbiter) happen when there’s confusion on units.
>
I never said anything about units until you raised the matter, and when I
did I said we just need to define what the standard unit is (be it
megabytes, gigabytes, etc.). Supporting many units (e.g. Bytes vs Megabytes
vs Gigabytes etc.) is optional and possibly dangerous as your example
demonstrates.

>   [AE: ] Meta-model constrains the model. The model defines how a model
> instance can be created. Representation is the model instance and can be
> rendered. So in my view they are related, albeit through 2 levels of
> indirection.
>
>  How does the proposed meta-model constrain the model?
>
> [AE: ] It does so by defining the common relationships between entities.
> Granted however it is not as rigorous as what you would get from a model
> driven architecture approach but I’m not advocating that here.
>
Wait, what? Generic links "constrain" the model? I'd have argued exactly the
opposite - they liberate it (but I'm not going to because I'm well bored of
circular discussions already).

> Something better appeared, along with the realisation that if we don't give
> folks like SNIA a way to play then they'll blaze their own trail. In reality
> it's not much more complicated - networks just became first class citizens
> which allows for extensibility. Ditto for storage.
>
> [AE: ] Fair point
>
This is really quite important.

> Atom is quite clearly *not* domain-specific (as evidenced by its rapid,
> widespread adoption in the cloud space for a myriad applications)... the
> concepts apply to any information organisation activity.
>
> [AE: ] My point here was that we need to specify what goes inside the
> atom:entry element should Atom be used.
>
Not if we put the OCCI descriptor format in the content element rather than
extending Atom... refer to the wiki.

> We do need to have a simple "OCCI" format to represent functionality that
> has multiple implementations, agreed. That said, if we palm the metadata
> (id, updated, etc.) and metamodel (links) off to HTTP/Atom as suggested by
> Alexis last week then the resulting format ends up being a lot more like
> what Chris and Richard from ElasticHosts were pushing for. In fact it gets
> so simple that key-value pairs in $PREFERRED_FORMAT makes the most sense,
> and having multiple formats available *for interop* becomes feasible. This
> fits with the HTML forms model too, which is also highly advantageous -
> creating and updating resources is as simple as a HTML form submission with
> no other formatting required.
>
> [AE: ] Sounds interesting – even more interesting is this very approach
> without the dependency on Atom should someone choose not to use it.
>
No, that's not more interesting because you still need collections and Atom
is the right tool for the job. There's nothing that we don't have to create
ourselves that fits the bill and the argument that Atom adds any more
complexity than a home grown equivalent is bunk. Look at where you ended up
after introducing my fixes... at something almost identical to Atom, which
is exactly what I've been saying the whole time.

> The only representation we care about is the simplest representation
> necessary to create resources - cores, speed, memory etc. for compute, size
> for storage and ip, netmask and gateway for network, etc. The others will
> use existing standards:
>
> [AE: ] If wanting to reuse existing standards, why not or should we then
> just reuse CIM entity types for the above attributes (core, speed, memory
> etc)?
>
Maybe we should, and if we're doing that then maybe we should just drag in
CIM itself... I don't know as I haven't looked all that closely at it after
being scared off by the complexity.

> [AE: ] Embedding OVF/VMX will then contain duplicate and redundant data. If
> that data differs which is authorative?
>
> OCCI, bearing in mind that the most likely cause for this is an import and
the specs are very likely to differ somewhat between hosts. In any case,
updating OCCI is likely to result in updates to the VM settings anyway -
this is (necessarily) loosely coupled.

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.
>
>
>
> -------------------------------------------------------------
>
> 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/20090526/ac99bc1c/attachment.html