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=31752#action_31752 ] 

Adrian Otto commented on CAMP-29:
---------------------------------

Tobias' last comment on this issue really made me smile. Regardless if this is stylistic or not, we have an abundance of very similar entities, and it would be much easier to comprehend the subject matter if we describe them with fewer terms. Case in point:

> To your (1), assuming CAMP-5 is accepted, we'll have Assembly (A), ApplicationComponent (Ca) and PlatformComponent (Cp) with respective Templates ('), 
> ExternalComponent (Ce) as well as Requirement (R) and Capability (P):
>
>    {A, Ca, Cp, Ce, A', Ca', Cp', R, C}
>
>We are now debating to "simplify" this down to just Component (C):
>
>   {A, C, A', C', R, P} 

Yes, exactly. This could be further simplified to:

Assembly, Component, Templates, and Capabilities.

That's it. So we have four entity types to teach about, rather than 9. Yes, the 9 permutations would still actually exist, and we would need mechanisms to identify which is which in it's own context, an yes you may end up with the same OO classes at the end of the day. Luckily these entities have attributes that could clearly express that. I have first-hand experience conveying CAMP's technical concepts, and when I use only four terms to convey the different types of resources, people tend to understand it much faster.

As authors of the specification, we should strive to make the subject matter as clear and concise as we reasonably can. I think this is a good way to do that.

Of course we should not take this to the extreme, and just call everything a "resource". We should try to strike a sensible balance.

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