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=31743#action_31743 ] 

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

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}

which is certainly doable (modulo the fact that Ce's don't come in a template variant), but comes at the price that we'd still have to *talk* about "Components that are provided by the application" vs "Components that are provided by the platform" and we'll have to add a "provenance" field to the structure.  This strikes me as way more complicated than simply adding those three component types to the (already simple) universe. But more importantly, it is a *stylistic* issue, not a material one. Even in OO, it is trivial to define class aliases a la

    class A
        ...

    class B < A

    class C < A

which makes these roles explicit while still allowing the code to operate on A when so desired. So, overall, I really don't understand the argument. It doesn't make sense technically (it works in OO just fine) and it doesn't make sense pedagogically (I'd rather talk about "ApplicationComponents" instead of "Components that are provided by the application").


To your (2), keep in mind that *every* resource is different anyway. An Apache component has virtually no overlap with a MySQL component or a RabbitMQ one. Even different Apache components are likely to be different, so perhaps the problem is in approaching this from an OO angle?


To your (3), see my solution proposal to my question (2) above. In short, we don't need 3 arrays. We only need one.


> You claim that there are "quite tangible differences" between the types. Could you expand on what these differences are?

As an application owner, I *own* Ca as well as Ce. As a result, I can modify them at will, just like R. This is not true for Cp (or P). When a PaaS user is deleted, the platform can drop any Ca associated with the user. For performance monitoring, the sum of all Ca usage metrics matters, not Cp. For billing, on the other hand, Cp matters, not Ca. And so forth. In essence, PaaS is about running application components on platform components, hence this difference shows up virtually everywhere. This is why I believe it makes no sense to try to do without the distinction.


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