[OASIS Issue Tracker] Commented: (CAMP-159) two ways to extend a resource type with additional attributes?

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CAMP-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36376#action_36376 ] 

Gilbert Pilz commented on CAMP-159:
-----------------------------------

Tom's question ("Do extension attributes get inherited by sub-types?") brought to mind a use case for adding attributes without creating a sub-type. Suppose I am a Provider that wants to add an extension attribute to every resource, for example, "security_group_uri" (a reference to the security_group resource that defines the security group to which this resource belongs).

If we allow adding attributes without requiring the creation of a new resource sub-type, the Provider can simply add the "security_group_uri" attribute to the base "camp_resource resource" and all the resource types for that Provider automatically inherit this attribute.

If we *don't* allow adding attributes outside of new resource sub-types the Provider would have to extend every CAMP attribute defined in the spec (e.g. provider_assemby, provider_component, provider_service, provider_plan, etc.) and add the "security_group_uri" attribute to each of these new sub-types. The Provider has to do this because our spec says that every resource inherits from the "camp_resource resource" and they *can't* create a "provider_camp_resource resource" and say that, for example, "'component resource' now inherits from 'provider_camp_resource resource'".

> two ways to extend a resource type with additional attributes?
> --------------------------------------------------------------
>
>                 Key: CAMP-159
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-159
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Gilbert Pilz
>            Assignee: Gilbert Pilz
>
> Now that WD35 has added the notion of resource type inheritance we are in a position where there are effectively two ways to extend existing resources.
> One way to do this (the older, pre-WD25 way) is to extend the existing resource type by simply adding attributes. So, for example, if you had a component that needed to advertise an HTTP endpoint you could extend the component resource with an attribute named "example.org:endpoint". So you would see something like this:
> {
>   "uri": "http://example.org/my_paas/components/1787";,
>   "name": "Portal",
>   "type": "component",
>   "description": "main portal web app",
>   "assembly": "http://example.org/my_paas/assemblies/1413";,
>   "status": "RUNNING",
>   "example.org:endpoint": "http://www.whichaway.com/home";,
>   ...
> }
> Note that the value of the "type" attribute is still "component".
> If a Provider does the above the CAMP spec requires them to do a number of things: (1) create an attribute_definition resource for the "example.org:endpoint" attribute and add a Link to this attribute_definition resource from the type_definition resource for the "component" type, (2) document this with a extension resource (see Section 7).
> A post-WD35 way to achieve the same result would be to create a new resource type that is a sub-type of the "component" resource type. Using this mechanism you would see something like this:
> {
>   "uri": "http://example.org/my_paas/components/1787";,
>   "name": "Portal",
>   "type": "example.org:web_app",
>   "description": "main portal web app",
>   "assembly": "http://example.org/my_paas/assemblies/1413";,
>   "status": "RUNNING",
>   "example.org:endpoint": "http://www.whichaway.com/home";,
>   ...
> }
> It looks identical except that the value of the "type" attribute is now "example.org:web_app".
> In this case the Provider would be required to: (1) create an attribute_definition resource for the "example.org:endpoint" attribute, (2) create a type_definition resource that describes the "example.org:web_app" type (with a Link in "inherits_from" to the type_definition resource for the "component" type and a Link in the "attribute_definition_links" to the new attribute_definition resource), (3) document this with a extension resource (see Section 7).
> It seems to me that the second way (creating a new, sub-typed resource) has several advantages. The first is that the Provider has the freedom to indicate, in the type_definition resource that describes the "example.org:web_app" type, that the "example.org:endpoint" attribute is required. You can't really do this if you are just adding attributes to the "component" type, since not every component will have an external endpoint that you can surface. Secondly it seems to me that, if the Provider develops a broad catalog of component types and tries to support them all by simply adding attributes to the component resource, eventually the component resource will become a giant map of optional attributes. The advantages of having a typed resource model largely disappear at that point, although the Consumer and Provider still have to pay the metadata-lookup costs of that model.
> Personally I don't like designs that provide multiple ways of doing the same thing unless there solid reasons for such multiplicity (one way is faster but less flexible, etc.) Can anyone think of a good reason why CAMP should have two ways to add an attribute to an existing resource?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira