[occi-wg] Update of Core & Models and Infrastructure
Gary Mazz
garymazzaferro at gmail.com
Mon Sep 6 16:39:26 CDT 2010
After close examination of the changes, I have a concern about the UML
diagram for the model. The UML is a class diagram used primarily to
describe a data model of an implementation. It also contains the legacy
"Kind" design element which has no purpose other than as a place holder
for a couple of attributes. Below, there is an new element called
Groups. It a way to organize resource sets in a container. This provides
a formalized mechanism to organize provisioned resources not assigned to
another resource, ie. storage. Template is more or less a specialization
of Groups.
A more realistic abstraction is:
Refence Model
*EXTERNAL RESOURCES*
There is also a special case for linking to external resources. There
has been some discussion of about presenting some preview information
about the external resource in the link. This would impose either
requirements and constraints on the external systems as well as
polluting the OCCI model with meta data from systems out of the OCCI domain.
Creating an OCCI resource acting as a proxy to external resources would
limit the impact of external meta data on the OCCI model. The proxy
model would also provide an opportunity to develop standardize mappings
specification from external system metat data to OCCI resource metadata.
Resulting in a cleaner, more manageable model for this use case. See
drawing below:
External Link Diagram
Ralf Nyren wrote:
> Thanks for the comments. I have updated the document.
>
> Changelog:
> * Rewrote Category definition to clarify static types versus introducing
> new behaviour to resource instances.
> * Rewrote Template definition adding recommended use of Templates.
> * Added Template use case examples, i.e. how to use Categories outside of
> the static type system.
> * Added subsection on Category hierarchies.
> * Moved extension stuff to the Extensibility section.
> * The new Extensibility section is somewhat repetitive but as long as it
> is consistent that should be ok.
>
> Hopefully we can finish of the core&models doc soon enough and focus on
> the HTTP Rendering document. The HTTP Rendering document will be what most
> people will read anyway.
>
> regards, Ralf
>
> On Sun, 05 Sep 2010 02:36:46 +0200, Andy Edmonds <andy at edmonds.be> wrote:
>
>
>> Ditto on the good work! :-)
>>
>> Inline...
>>
>> Andy
>> andy.edmonds.be
>>
>>
>> 2010/9/4 Csom Gyula <csom at interface.hu>
>>
>>
>>> Agree:) Some notes and questions:
>>>
>>> (1) Since OCCI has itw own, special view on the "type system" hence a
>>> separate section on the topic
>>> would be useful. Besides extensions as Thijs proposed, I think the
>>> general
>>> type concept
>>> could/should be described. This could help users (either implementors,
>>> extenders or providers)
>>> to get the point and could shorten the learning curve.
>>>
>>> To my understanding (according to the doc and the previous chat) OCCI's
>>> type system has the
>>> following 4 characteristics:
>>>
>>> * Extensible: OCCI lets providers extend the builtin types by (1)
>>> subclassing resources and (2) creating
>>> user defined categories.
>>>
>>>
>> Yep :-)
>>
>>
>>
>>> * Composable: OCCI supports multiple-inheritance-like feature through a
>>> mixin like model - that is
>>> (generic) behaviour can be introduced to OCCI resouces by attaching
>>> categories.
>>>
>>>
>> Yep :-) Just to clarify new behaviours can be introduced to resource
>> instances (this supports the next point you make)
>>
>>
>>
>>> * Static: Similar to traditional OO languages and in contrast with
>>> dynamic
>>> languages, OCCI uses
>>> a static type system. Once defined, a type becomes frozen and cannot be
>>> modified later. That is if
>>> someone wants to introduce a new behaviour to an existing type she can
>>> but
>>> in order to that she
>>> has to subclass the original type, or more explicitely: new attributes,
>>> categories cannot be added
>>> to already defined types.
>>>
>>>
>> Yep :-)
>>
>>
>>
>>> * Discovarable: OCCI has builtin reflection capabilities: through
>>> Categories one could query
>>> the available attrbiutes and actions of a resource. So if someone wants
>>> to
>>> implement some
>>> generic client behaviour (for instance a generic UI client) she gots
>>> some
>>> support from the protocol.
>>>
>>>
>> Yep :-) Minor point but I'd call this reflection as opposed to
>> discoverability.
>>
>>
>>
>>> I just wanted to sum it up cause I think the above feature should be
>>> described and also because my
>>> questions are related to these topics:)
>>>
>>>
>> These four points above should be placed into the model section.
>>
>>
>>
>>> (2) Extensibility: no question. Maybe within 4.1.2.1 (or within a
>>> separate
>>> chapter) it could be further
>>> emphasized that extensibility is a recursive feature, ie. OCCI supports
>>> extension of extensions.
>>> Its just a documentation note, since support for inheritance tree is
>>> implicitely quite clear from the
>>> following sentence on categories:
>>>
>>> "The related set MUST include a, direct or indirect, reference to the
>>> Resource base type category".
>>>
>>> As far as I understand "indirect" is the keyword here:)
>>>
>>> (3) Composable: Namespace support (like occi.xxx.yyy) or kinda could be
>>> handled/clarified at this
>>> level. That is the spec could/should clarify either (1) how to avoid
>>> name
>>> collisions or (2) how name
>>> resolution works in such cases.
>>>
>>>
>> To avoid namespace clashes we've defined that only the OCCI spec can use
>> the
>> occi.* for attribute names and use http://schemas.ogf.org/occi/* for
>> scheme
>> in category. After that there is no further normative guarantee other
>> than
>> the opportunity for implementors to register their extensions with the
>> working group (through mail and entry into a planned wiki registry)
>>
>>
>>
>>> Also I think examples could/should be discovered/provided for the mixin
>>> feature since the domain model
>>> in its current form (including the Core (ie. Kind, Resource, Action and
>>> Link) and the Infrastructure
>>> (Compute, Network and Storage) represents just a single inheritance
>>> tree.
>>> Is there a plan to do so or
>>> some existing example I missed?:)
>>>
>>>
>> Agreed and yes there should be some examples floating about. Maybe:
>>
>> http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/ExamplesUseCaseScenarios
>> and
>> https://docs.google.com/Doc?docid=0AS0AExvzzYt7YWQ2enFodmt6czlfMzRnM25mMnJmZA&hl=en
>>
>>
>>
>>
>>> (4) Discovery: It is clear that for every Cloud object at least one
>>> Category should be assigned (ie.
>>> Kind.categories' multiplicity is 1..*). However it is not clear whether
>>> all
>>> attributes and actions a Cloud object supports should be exposed through
>>> Categories or a Resource can introduce its own
>>> attributes/actions not exposed (hence not discovarable) through any
>>> Category.
>>>
>> IMO the resource should be bound to the contract it presents through
>> categories and so not introduce "backdoor" attributes/actions. We can
>> guarantee this in the spec and recommend that those wishing to extend
>> follow
>> best practices. Those best practises should be detailed in a section
>> dedicated to those wanting to create their own extensions.
>>
>>
>>
>>> For instance:
>>>
>>> Compute is assigned the
>>> http://schemas.ogf.org/occi/infrastructure#computeCategory. Compute has
>>> some attributes within the occi.compute namespace
>>> (architecture, cores, hostname, etc.) and also some actions (start,
>>> stop,
>>> etc.). Now, in this particular case, the question is whether someone
>>> could query the Compute attribute (names), actions through the compute
>>> category or should she consult the spec?
>>>
>>>
>> Why could they not do both?
>>
>>
>>
>>> (5) Kind notation. I am just wondering whether the term is an intuitive
>>> one
>>> or not. Implicitely it has
>>> type/class semantics (at least for me:)). What's more as far as I
>>> remember/know the term "kind"
>>> historically was introduced in place of "type", but could be wrong.
>>> Anyway
>>> Kind represents the
>>> attributes that is common to all cloud objects and not the attributes of
>>> classes (ie. Kind is not for
>>> reflection). In programming languages this distinction is made through
>>> Object and Class classes.
>>> The former represents the common behaviour of all objects and the latter
>>> defines the special
>>> characteristics of types. Maybe another notation? that better reflects
>>> that
>>> "Kind" is about
>>> objects/entites and not about classes/types? that also clearly
>>> distinguish
>>> it from Category?
>>>
>>>
>> Historically, Kind was a synonym for Resource. I'm not sure of what other
>> name we could use but perhaps if we simply explained the difference in
>> the
>> spec that should suffice.
>>
>>
>>
>>> Cheers
>>> Gyula
>>>
>>> ________________________________
>>> Feladó: occi-wg-bounces at ogf.org<mailto:occi-wg-bounces at ogf.org> [
>>> occi-wg-bounces at ogf.org<mailto:occi-wg-bounces at ogf.org>] ; meghatalmazó:
>>> Thijs Metsch [tmetsch at platform.com<mailto:tmetsch at platform.com>]
>>> Küldve: 2010. szeptember 4. 12:54
>>> Címzett: Ralf Nyren; occi-wg at ogf.org<mailto:occi-wg at ogf.org>
>>> Tárgy: Re: [occi-wg] Update of Core & Models and Infrastructure
>>>
>>>
>>>
>>> Great stuff - Thanks Ralf! Especially of keeping the HTTP stuff out of
>>> the
>>> Core :-) Looks much better now.
>>>
>>> Just wondering if we should move the extensibility sections to one
>>> section...but that's just an editorial thought.
>>>
>>> Cheers,
>>>
>>> -Thijs
>>>
>>> -----Original Message-----
>>> From: occi-wg-bounces at ogf.org<mailto:occi-wg-bounces at ogf.org> on behalf
>>> of
>>> Ralf Nyren
>>> Sent: Sat 04-Sep-10 12:41
>>> To: occi-wg at ogf.org<mailto:occi-wg at ogf.org>
>>> Subject: [occi-wg] Update of Core & Models and Infrastructure
>>>
>>> Hi,
>>>
>>> I have finished and uploaded a rather significant update of the Core &
>>> Models [1] document. The Infrastructure document [2] has been updated
>>> accordingly while the HTTP Rendering document is still in the works.
>>>
>>> The Core & Models changelog:
>>> - Updated UML diagram. Fixes the issue with Actions.
>>> - Updated and re-structured description/definition of the base types.
>>> Please read everything through.
>>> - Templates definition added, it is just a Category but without the
>>> requirement to be a type construct.
>>> - Added full description of the Category base type.
>>> - Removed all REST and HTTP stuff. This information will reappear in
>>> the
>>> HTTP Rendering document.
>>> - HTTP related Open Issues will reappear in the HTTP Rendering
>>> document.
>>> - Extension rules properly defined.
>>> - Discovery mechanism from the Core perspective.
>>>
>>> Hopefully the new version should be a lot more consistent and only
>>> address
>>> things relevant to the Core specification. The information which was
>>> specific to the HTTP rendering will reappear in that document when it is
>>> completed.
>>>
>>> I put some effort into describing how to extend OCCI Core so each base
>>> type now has its on subsection describing the rules for domain-specific
>>> extensions.
>>>
>>> Comments welcome.
>>>
>>> regards, Ralf
>>>
>>> [1]
>>>
>>> http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/CoreAndModels
>>> [2]
>>>
>>> http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Infrastructure
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg at ogf.org<mailto:occi-wg at ogf.org>
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>
>>>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20100906/242f08ff/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OCCI Reference Model.png
Type: image/png
Size: 37823 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100906/242f08ff/attachment-0002.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: External Links.png
Type: image/png
Size: 32536 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20100906/242f08ff/attachment-0003.png
More information about the occi-wg
mailing list