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=35157#action_35157 ] 

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

Excellent Gil.  To summarise his changes:

* rename PlatformComponentTemplate -> ServiceTemplate
    // these are things people might use;
    // they are not necessarily instances, but rather
    // the things in the catalog which the platform
    // knows how to supply and wire up;
    // may be specific, such as JBoss7 or MySql5,
    // or general, such as AppServer or Database

* merge PlatformComponent and ApplicationComponent into Component
    // these are the running, deployed pieces which comprise
    // an Assembly; these may correspond 1-to-1 with Services,
    // or platforms may create many Component resources to
    // better reflect how a Service is delivered

* drop link from Platform to Components
    // so Platform links to services (the catalog),
    // and Artifacts (user's content), and
    // AssemblyTemplates and Assemblies;
    // with Assemblies linking to the Components


I think we should do a little bit more, either here or in a new issue:

* rename ServiceTemplate (was PCT) -> Service
    // if i see ServiceTemplate I expect to see a Service somewhere;
    // plus it might not be a template (eg if it is a DB-aaS), and whether
    // it is stood up from scratch or multi-tenanted doesn't matter,

* rename ApplicationComponentTemplate -> Artifact
    // these are content items users can
    // deploy to services, often uploaded by users
    // (e.g. as part of a PDP), such as a WAR file;
    // Artifact is a friendlier and simpler name

* merge/rename the various PlatformComponentXxx and ApplicationComponentXxx items
    // there are still quite a few; there should be NO occurrences of 
    // platformcomponent or applicationcomponent when the above changes are done!


The reasoning for this is essentially that ApplicationComponent has always
seemed an ill-defined resource, and it is clearer without it.
I think AppComponent has meant either:

(1) the Artifact itself (simply representing that the Artifact/ACT is now in use
somewhere, which could better be represented by a link from an Assembly or
Component to an Artifact -- this could be an optional part of the spec perhaps?);

or (2) something the platform is running based on an Artifact/ACT (but this is
hard to distinguish from a PC, as the PC is a thing the platform is running)

There were other concepts such as ownership, provenance, sharing, visibility,
lifecycle/deletion, etc, which at times were being implicitly associated with
these resources -- but in different ways by different people!

As was noted on a recent call these must be explicit to be valuable and
for now the suggestion is that CAMP stay silent on these issues and let
the thinking mature via extensions.  V.next may address these issues.



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