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-29) "Application Component" and "Platform Component" should be collapsed into a single "Component"; "Application Component Template" and "Platform Component Template" should be collapsed into a single "Component Template"


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

Alex Heneveld commented on CAMP-29:
-----------------------------------

The distinction between Platform and Application Component -- which seems natural in some use cases -- gets confusing in practice.  If I have somehow uploaded instructions for creating a template which can be used in other assemblies (e.g. a machine image, or a TOSCA file), am I introducting PCT's or ACT's?  It doesn't quite fit in the split.  Then if I wish to make use of something from one of my Assemblies in another of my Assemblies, or if I wish to publish something and share it with someone else, does it become some kind of "shared ACT" or "stub PCT"?

Another pathological example -- let's say an assembly requires a git repository, which I can either supply myself as a URL (becoming an App Component) or the platform can make for me (thus a Platform Component).  Now we have the same functional piece in the assembly -- the repo -- but it is an AC or a PC depending where it comes from.

All these problems go away if we remove the attempt to distinguish them.  I do not see any technical reason why we need the split.  There is a lot of useful potential information about resources which is hinted at in the ACT/PCT split: 

* who created it
* who manages it
* who can delete it
* who can see it
* when it gets automatically deleted

But these data are more complex than the simple split does justice to, and ultimately this split will make it harder to evolve answers to these questions, so I *strongly* support this issue until we have a better idea of how to answer the questions above.

> "Application Component" and "Platform Component" should be collapsed into a single "Component"; "Application Component Template" and "Platform Component Template" should be collapsed into a single "Component Template"
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMP-29
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-29
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>            Reporter: Gilbert Pilz
>            Assignee: Gilbert Pilz
>            Priority: Critical
>
> There is no justification for the complexity caused by segregation of components and templates into "Application" and "Platform" sub-types. The methods for discovering a template, figuring out whether that template describes a services that will meet your requirements, indicating that your application will make use of the service described by that template, indicating that your application is using a service, etc. do not vary between "Application" things and "Platform" things. At present, the only purpose of the Application/Platform distinction is to indicate the provenance of a component/template. If such an indication is necessary, it can be provided by some other mechanism such as an attribute (e.g. { "provenance" : "platform" })

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