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

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

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