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=31734#action_31734 ] 

Tobias Kunze  commented on CAMP-29:
-----------------------------------

We should keep in mind that we have 3 types of components: application, platform and external. While every concrete component will be pretty much unique in terms of the information it exposes and will have only a minimal set of common information, irrespective of its type, these types do differ with respect to how they can be used. 

So to me the question is: what is this issue about?

    1) Are we concerned about talking about behavioral types that don't differ in an OO sense?
    2) Are we concerned that we have three "arrays" in a component linking it to the three different types?
    3) Are we concerned about something else?

If (1), since there are quite tangible differences between the types, do we want to introduce the terms in the non-normative parts of the spec (so we don't have to talk about "Components that are provided by the Platform User") but not in the normative parts?
If (2), why don't we simplify the arrays down to one "components" array?

Clearly, new ApplicationComponent() and new Component(provenance: "application") are merely cosmetic differences (with the former being less ugly IMHO), so I'd think it comes down to whether talking about ApplicationComponents vs PlatformComponents and ExternalComponents makes sense or not. Since the differ behaviorally, I'd think it does, and if it does, I think we should have the types. In fact, since all components are of one of these types, I'd argue that "Component" is merely an abstract superclass.


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