OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Commented: (CAMP-67) resource model lacks explicit information about the state of dependencies


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

Mark Carlson commented on CAMP-67:
----------------------------------

Currently the ACT has:
{
  "uri": URI,
  "name": String,
  "type": "applicationComponentTemplate",
  "description": String,
  "created": Timestamp,
  "representationSkew": String, ?
  "tags": [ String, + ], ?
  "assemblyTemplate" : Link,
  "applicationComponentTemplates" : [ Link + ], ?
  "platformComponentTemplates" : [ Link + ], ?
  "applicationComponentRequirements" : [ Link + ], ?
  "platformComponentRequirements" : [ Link + ] ?  
}

Which has separate arrays of links for both PCTs and PCRs, but no way to correlate the entries in the two arrays.

Suggest we integrate these two Link arrays into an array of JSON objects with elements (Links) for the PCR and PCT that are related. To be consistent, also do the same for ACRs and ACTs as show below:

{
  "uri": URI,
  "name": String,
  "type": "applicationComponentTemplate",
  "description": String,
  "created": Timestamp,
  "representationSkew": String, ?
  "tags": [ String, + ], ?
  "assemblyTemplate" : Link,
  "applicationComponentDependencies": [
        {
            "applicationComponentTemplate" : Link, 
            "applicationComponentRequirement" : Link
        }, +
  ], ?
  "platformComponentDependencies": [
        {
           "platformComponentTemplate" : Link,
           "platformComponentRequirement" :  Link
        }, +
  ], ? 
}

If the Template link is populated for all of the array members, the dependencies are satisfied. On input of a DP, there would only be Requirement links populated until such time as Templates are found or created for each dependency (via manual or auto-wired resolution).  If Requirements are not being used, those elements of the JSON object would not be populated.



> resource model lacks explicit information about the state of dependencies
> -------------------------------------------------------------------------
>
>                 Key: CAMP-67
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-67
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Gilbert Pilz
>            Assignee: Gilbert Pilz
>
> Section 2.1.2 of WD10 contains the following language:
> "An Application Component Template cannot be instantiated unless all of its dependencies are satisfied. An Application Component Template shall be referenced by a single Assembly Template. An Assembly Template shall not be instantiated until all of its Application Component Templates are successfully instantiated."
> However, nowhere in the spec does it say how either the platform or the client are supposed to determine whether or not an ApplicationComponentTemplate (ACT) has had all its dependencies satisfied. Leaving other application components out of the picture for now, an ACT can have links to both PlatformComponentRequirements (PCRs) and PlatformComponentTemplates (PCTs). The semantics of the PCR links are "I have these requirements". The semantics of the PCT links are "I use the service described by this PCT".
> 1.) Can we mandate that every PCR is satisfied by a single PCT link or is it possible for a single PCR to require two or more PCT links?

-- 
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

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]