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/Infrastructur...
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@ogf.org on behalf of Ralf Nyren Sent: Sat 04-Sep-10 12:41 To: occi-wg@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/Infrastructur... _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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. * 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. * 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. * 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. 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:) (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. 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?:) (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. For instance: Compute is assigned the http://schemas.ogf.org/occi/infrastructure#compute Category. 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? (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? Cheers Gyula ________________________________ Feladó: occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org> [occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org>] ; meghatalmazó: Thijs Metsch [tmetsch@platform.com<mailto:tmetsch@platform.com>] Küldve: 2010. szeptember 4. 12:54 Címzett: Ralf Nyren; occi-wg@ogf.org<mailto:occi-wg@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@ogf.org<mailto:occi-wg-bounces@ogf.org> on behalf of Ralf Nyren Sent: Sat 04-Sep-10 12:41 To: occi-wg@ogf.org<mailto:occi-wg@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/Infrastructur... _______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
Ditto on the good work! :-) Inline... Andy andy.edmonds.be 2010/9/4 Csom Gyula <csom@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/ExamplesUseCa... 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@ogf.org<mailto:occi-wg-bounces@ogf.org> [ occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org>] ; meghatalmazó: Thijs Metsch [tmetsch@platform.com<mailto:tmetsch@platform.com>] Küldve: 2010. szeptember 4. 12:54 Címzett: Ralf Nyren; occi-wg@ogf.org<mailto:occi-wg@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@ogf.org<mailto:occi-wg-bounces@ogf.org> on behalf of Ralf Nyren Sent: Sat 04-Sep-10 12:41 To: occi-wg@ogf.org<mailto:occi-wg@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/Infrastructur... _______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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@edmonds.be> wrote:
Ditto on the good work! :-)
Inline...
Andy andy.edmonds.be
2010/9/4 Csom Gyula <csom@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/ExamplesUseCa... 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@ogf.org<mailto:occi-wg-bounces@ogf.org> [ occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org>] ; meghatalmazó: Thijs Metsch [tmetsch@platform.com<mailto:tmetsch@platform.com>] Küldve: 2010. szeptember 4. 12:54 Címzett: Ralf Nyren; occi-wg@ogf.org<mailto:occi-wg@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@ogf.org<mailto:occi-wg-bounces@ogf.org> on behalf of Ralf Nyren Sent: Sat 04-Sep-10 12:41 To: occi-wg@ogf.org<mailto:occi-wg@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/Infrastructur... _______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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@edmonds.be> wrote:
Ditto on the good work! :-)
Inline...
Andy andy.edmonds.be
2010/9/4 Csom Gyula <csom@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/ExamplesUseCa... 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@ogf.org<mailto:occi-wg-bounces@ogf.org> [ occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org>] ; meghatalmazó: Thijs Metsch [tmetsch@platform.com<mailto:tmetsch@platform.com>] Küldve: 2010. szeptember 4. 12:54 Címzett: Ralf Nyren; occi-wg@ogf.org<mailto:occi-wg@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@ogf.org<mailto:occi-wg-bounces@ogf.org> on behalf of Ralf Nyren Sent: Sat 04-Sep-10 12:41 To: occi-wg@ogf.org<mailto:occi-wg@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/Infrastructur... _______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi, this model contains basic changes:), some notes/questions: [1] Does the model drop categories, ie. reflection and composition or did you just leave it out for simplification? Actually I think such drop would help the model, well at least in my point of view: (1) until the model is small (only 3 primary classes within the Infrastructure model and some other secondary tech class) reflection does not give much and also (2) until there is no mixin example compisition gives nothing. Also when needed such behaviour could be added later... during the evolution of the model (ie. when targeting PaaS, SaaS). [2] I couldn't catch the roal of templates, yet. In existing services (like EC2 (?), libcloud API, OpenNebula) templates define predefined attributes that is they act like a bootstrap for creating resources. I do not see this behaviour within the model - so what is the role of templates?:) [3] I think dangling links could/should be refined. According to CAP theorem [1] distributed systems seem to have some limitation, however I really think that eventually the cloud/should be notified on resource changes it is interested in. That is: maybe not always consistent, but at least eventually they are (ie.: BASE [2]). This might have impact on the model ie. you may decide that you put such notifications within the protocol's scope but strictly speaking this is not necessarry (OCCI simply reflects the data received through CMS-backend integration but doesn't assist it). Cheers, Gyula --- [1] CAP: http://www.julianbrowne.com/article/viewer/brewers-cap-theorem [2] BASE: http://www.infoq.com/articles/pritchett-latency, http://blog.tekelec.com/blog/bid/9608/FAQ-What-does-Soft-State-mean ________________________________ Feladó: Gary Mazz [garymazzaferro@gmail.com<mailto:garymazzaferro@gmail.com>] Küldve: 2010. szeptember 6. 23:39 Címzett: Ralf Nyren Másolatot kap: Andy Edmonds; Csom Gyula; occi-wg@ogf.org<mailto:occi-wg@ogf.org> Tárgy: Re: [occi-wg] Update of Core & Models and Infrastructure 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@edmonds.be><mailto:andy@edmonds.be> wrote: Ditto on the good work! :-) Inline... Andy andy.edmonds.be 2010/9/4 Csom Gyula <csom@interface.hu><mailto:csom@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/ExamplesUseCa... 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@ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org> [ occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org>] ; meghatalmazó: Thijs Metsch [tmetsch@platform.com<mailto:tmetsch@platform.com><mailto:tmetsch@platform.com><mailto:tmetsch@platform.com>] Küldve: 2010. szeptember 4. 12:54 Címzett: Ralf Nyren; occi-wg@ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org><mailto:occi-wg@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@ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org> on behalf of Ralf Nyren Sent: Sat 04-Sep-10 12:41 To: occi-wg@ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org><mailto:occi-wg@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/Infrastructur... _______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg _______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg _______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
Hi, Comments inline, have to run to a meeting Csom Gyula wrote:
Hi, this model contains basic changes:), some notes/questions:
[1] Does the model drop categories, ie. reflection and composition or did you just leave it out for simplification?
The idea of reflection and composition are design elements and patterns with can be construed as implementation (technology and language) specific. The abstracted model should be technology agnostic, focusing on the elements, their relationships and rules that govern the permitted behaviors. The original UML was closer to an agnostic representation, but once attributes were shifted towards other UML entities, it became an object oriented design model.
Actually I think such drop would help the model, well at least in my point of view: (1) until the model is small (only 3 primary classes within the Infrastructure model and some other secondary tech class) reflection does not give much and also (2) until there is no mixin example compisition gives nothing. Also when needed such behaviour could be added later... during the evolution of the model (ie. when targeting PaaS, SaaS).
Using relationships that are interpreted as more complex and implementation design patterns, such as refection, should be avoided. OCCI is technically a composable cloud infrastructure service technology, I'm not sure why its in there... maybe an artifact of the oo design. Before we move up the food chain, to PaaS and SaaS, we still have to consider a provider to provider interface as well as identity certificate integration.
[2] I couldn't catch the roal of templates, yet. In existing services (like EC2 (?), libcloud API, OpenNebula) templates define predefined attributes that is they act like a bootstrap for creating resources. I do not see this behaviour within the model - so what is the role of templates?:)
From the description it seems to as you describe in your comments. I don't remember a discussion on templates in the weekly meeting... It just seems to have appeared :) I'll comment on this later. BTW, we also left out mapping canonical forms of resources and how to transition from proprietary canonical name spaces to an occi canonical name space.
[3] I think dangling links could/should be refined. According to CAP theorem [1] distributed systems seem to have some limitation, however I really think that eventually the cloud/should be notified on resource changes it is interested in. That is: maybe not always consistent, but at least eventually they are (ie.: BASE [2]). This might have impact on the model ie. you may decide that you put such notifications within the protocol's scope but strictly speaking this is not necessarry (OCCI simply reflects the data received through CMS-backend integration but doesn't assist it).
Agreed, this falls back to my comment on a provider to provider interface or better called a occi to occi interface..
Cheers, Gyula
---
[1] CAP: http://www.julianbrowne.com/article/viewer/brewers-cap-theorem [2] BASE: http://www.infoq.com/articles/pritchett-latency, http://blog.tekelec.com/blog/bid/9608/FAQ-What-does-Soft-State-mean
________________________________ Feladó: Gary Mazz [garymazzaferro@gmail.com<mailto:garymazzaferro@gmail.com>] Küldve: 2010. szeptember 6. 23:39 Címzett: Ralf Nyren Másolatot kap: Andy Edmonds; Csom Gyula; occi-wg@ogf.org<mailto:occi-wg@ogf.org> Tárgy: Re: [occi-wg] Update of Core & Models and Infrastructure
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@edmonds.be><mailto:andy@edmonds.be> wrote:
Ditto on the good work! :-)
Inline...
Andy andy.edmonds.be
2010/9/4 Csom Gyula <csom@interface.hu><mailto:csom@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/ExamplesUseCa... 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@ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org> [ occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org>] ; meghatalmazó: Thijs Metsch [tmetsch@platform.com<mailto:tmetsch@platform.com><mailto:tmetsch@platform.com><mailto:tmetsch@platform.com>] Küldve: 2010. szeptember 4. 12:54 Címzett: Ralf Nyren; occi-wg@ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org><mailto:occi-wg@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@ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org> on behalf of Ralf Nyren Sent: Sat 04-Sep-10 12:41 To: occi-wg@ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org><mailto:occi-wg@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/Infrastructur... _______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
Ok, I'm back This is my opinion on template... I'm glad to see them :) Templates are deployed by several cloud systems as an way of easily managing cloud configurations. But, there are few possible use cases. I think these are the most useful, feel free to add to them. 1) Templates represent unrealized definitions of the desired configurations prior to provisioning. 2) Templates represent unrealized definitions of the desired configurations after provisioning. This type may change across providers and the actual configuration or contract is based on provider capabilities 3) Templates represent instantiated configurations organized based on the consumers' configuration. Gary Mazz wrote:
Hi,
Comments inline, have to run to a meeting
Csom Gyula wrote:
Hi, this model contains basic changes:), some notes/questions:
[1] Does the model drop categories, ie. reflection and composition or did you just leave it out for simplification?
The idea of reflection and composition are design elements and patterns with can be construed as implementation (technology and language) specific. The abstracted model should be technology agnostic, focusing on the elements, their relationships and rules that govern the permitted behaviors. The original UML was closer to an agnostic representation, but once attributes were shifted towards other UML entities, it became an object oriented design model.
Actually I think such drop would help the model, well at least in my point of view: (1) until the model is small (only 3 primary classes within the Infrastructure model and some other secondary tech class) reflection does not give much and also (2) until there is no mixin example compisition gives nothing. Also when needed such behaviour could be added later... during the evolution of the model (ie. when targeting PaaS, SaaS).
Using relationships that are interpreted as more complex and implementation design patterns, such as refection, should be avoided. OCCI is technically a composable cloud infrastructure service technology, I'm not sure why its in there... maybe an artifact of the oo design. Before we move up the food chain, to PaaS and SaaS, we still have to consider a provider to provider interface as well as identity certificate integration.
[2] I couldn't catch the roal of templates, yet. In existing services (like EC2 (?), libcloud API, OpenNebula) templates define predefined attributes that is they act like a bootstrap for creating resources. I do not see this behaviour within the model - so what is the role of templates?:)
From the description it seems to as you describe in your comments. I don't remember a discussion on templates in the weekly meeting... It just seems to have appeared :) I'll comment on this later.
BTW, we also left out mapping canonical forms of resources and how to transition from proprietary canonical name spaces to an occi canonical name space.
[3] I think dangling links could/should be refined. According to CAP theorem [1] distributed systems seem to have some limitation, however I really think that eventually the cloud/should be notified on resource changes it is interested in. That is: maybe not always consistent, but at least eventually they are (ie.: BASE [2]). This might have impact on the model ie. you may decide that you put such notifications within the protocol's scope but strictly speaking this is not necessarry (OCCI simply reflects the data received through CMS-backend integration but doesn't assist it).
Agreed, this falls back to my comment on a provider to provider interface or better called a occi to occi interface..
Cheers, Gyula
---
[1] CAP: http://www.julianbrowne.com/article/viewer/brewers-cap-theorem [2] BASE: http://www.infoq.com/articles/pritchett-latency, http://blog.tekelec.com/blog/bid/9608/FAQ-What-does-Soft-State-mean
________________________________ Feladó: Gary Mazz [garymazzaferro@gmail.com<mailto:garymazzaferro@gmail.com>] Küldve: 2010. szeptember 6. 23:39 Címzett: Ralf Nyren Másolatot kap: Andy Edmonds; Csom Gyula; occi-wg@ogf.org<mailto:occi-wg@ogf.org> Tárgy: Re: [occi-wg] Update of Core & Models and Infrastructure
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@edmonds.be><mailto:andy@edmonds.be> wrote:
Ditto on the good work! :-)
Inline...
Andy andy.edmonds.be
2010/9/4 Csom Gyula <csom@interface.hu><mailto:csom@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/ExamplesUseCa...
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@ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org> [ occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org>] ; meghatalmazó: Thijs Metsch [tmetsch@platform.com<mailto:tmetsch@platform.com><mailto:tmetsch@platform.com><mailto:tmetsch@platform.com>]
Küldve: 2010. szeptember 4. 12:54 Címzett: Ralf Nyren; occi-wg@ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org><mailto:occi-wg@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@ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org> on behalf of Ralf Nyren Sent: Sat 04-Sep-10 12:41 To: occi-wg@ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org><mailto:occi-wg@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/Infrastructur...
_______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org>
http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
Hi, thanks for your response! As for identity management I definitely agree:) I think authentication and authorization are key parts of a CMS system, including the front end as well. As a minimum the model might support user entity (including credentials) and ownership relation and maybe ACLs. Regarding templates... Within my limited experience of cloud templates I've met the following pattern. A template is a (1) named configuration with (2) hardwired (frozen) values for cpu and memory and (3) everything else is up to the user to fill in during provisioning. So a template reprsents nothing but a computing power. The current model seems to support the above scope. Well maybe it would be nice if it exposed not just a name ("small", "large", etc) but the hardwired cpu, memory values as well but otherwise it seems to be inline with existing practices. Also I've made a more detailed, high level analysis on templating... but I'm not sure whether it is of your interest or not:) Cheers, Gyula ________________________________________ Feladó: Gary Mazz [garymazzaferro@gmail.com] Küldve: 2010. szeptember 8. 10:11 Címzett: Csom Gyula Másolatot kap: Ralf Nyren; Andy Edmonds; occi-wg@ogf.org Tárgy: Re: [occi-wg] Update of Core & Models and Infrastructure Ok, I'm back This is my opinion on template... I'm glad to see them :) Templates are deployed by several cloud systems as an way of easily managing cloud configurations. But, there are few possible use cases. I think these are the most useful, feel free to add to them. 1) Templates represent unrealized definitions of the desired configurations prior to provisioning. 2) Templates represent unrealized definitions of the desired configurations after provisioning. This type may change across providers and the actual configuration or contract is based on provider capabilities 3) Templates represent instantiated configurations organized based on the consumers' configuration. Gary Mazz wrote:
Hi,
Comments inline, have to run to a meeting
Csom Gyula wrote:
Hi, this model contains basic changes:), some notes/questions:
[1] Does the model drop categories, ie. reflection and composition or did you just leave it out for simplification?
The idea of reflection and composition are design elements and patterns with can be construed as implementation (technology and language) specific. The abstracted model should be technology agnostic, focusing on the elements, their relationships and rules that govern the permitted behaviors. The original UML was closer to an agnostic representation, but once attributes were shifted towards other UML entities, it became an object oriented design model.
Actually I think such drop would help the model, well at least in my point of view: (1) until the model is small (only 3 primary classes within the Infrastructure model and some other secondary tech class) reflection does not give much and also (2) until there is no mixin example compisition gives nothing. Also when needed such behaviour could be added later... during the evolution of the model (ie. when targeting PaaS, SaaS).
Using relationships that are interpreted as more complex and implementation design patterns, such as refection, should be avoided. OCCI is technically a composable cloud infrastructure service technology, I'm not sure why its in there... maybe an artifact of the oo design. Before we move up the food chain, to PaaS and SaaS, we still have to consider a provider to provider interface as well as identity certificate integration.
[2] I couldn't catch the roal of templates, yet. In existing services (like EC2 (?), libcloud API, OpenNebula) templates define predefined attributes that is they act like a bootstrap for creating resources. I do not see this behaviour within the model - so what is the role of templates?:)
From the description it seems to as you describe in your comments. I don't remember a discussion on templates in the weekly meeting... It just seems to have appeared :) I'll comment on this later.
BTW, we also left out mapping canonical forms of resources and how to transition from proprietary canonical name spaces to an occi canonical name space.
[3] I think dangling links could/should be refined. According to CAP theorem [1] distributed systems seem to have some limitation, however I really think that eventually the cloud/should be notified on resource changes it is interested in. That is: maybe not always consistent, but at least eventually they are (ie.: BASE [2]). This might have impact on the model ie. you may decide that you put such notifications within the protocol's scope but strictly speaking this is not necessarry (OCCI simply reflects the data received through CMS-backend integration but doesn't assist it).
Agreed, this falls back to my comment on a provider to provider interface or better called a occi to occi interface..
Cheers, Gyula
---
[1] CAP: http://www.julianbrowne.com/article/viewer/brewers-cap-theorem [2] BASE: http://www.infoq.com/articles/pritchett-latency, http://blog.tekelec.com/blog/bid/9608/FAQ-What-does-Soft-State-mean
________________________________ Feladó: Gary Mazz [garymazzaferro@gmail.com<mailto:garymazzaferro@gmail.com>] Küldve: 2010. szeptember 6. 23:39 Címzett: Ralf Nyren Másolatot kap: Andy Edmonds; Csom Gyula; occi-wg@ogf.org<mailto:occi-wg@ogf.org> Tárgy: Re: [occi-wg] Update of Core & Models and Infrastructure
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@edmonds.be><mailto:andy@edmonds.be> wrote:
Ditto on the good work! :-)
Inline...
Andy andy.edmonds.be
2010/9/4 Csom Gyula <csom@interface.hu><mailto:csom@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/ExamplesUseCa...
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@ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org> [ occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org>] ; meghatalmazó: Thijs Metsch [tmetsch@platform.com<mailto:tmetsch@platform.com><mailto:tmetsch@platform.com><mailto:tmetsch@platform.com>]
Küldve: 2010. szeptember 4. 12:54 Címzett: Ralf Nyren; occi-wg@ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org><mailto:occi-wg@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@ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org> on behalf of Ralf Nyren Sent: Sat 04-Sep-10 12:41 To: occi-wg@ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org><mailto:occi-wg@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/Infrastructur...
_______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org>
http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
participants (6)
-
Andy Edmonds -
Csom Gyula -
Gary Mazz -
Michael Behrens -
Ralf Nyren -
Thijs Metsch