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

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Derek Palma commented on CAMP-29:
---------------------------------

We have also experienced situations along the lines of Alex's example. The general use case seems to be when you have a set of 1 or more components you'd like to share with others. This happens often with different teams building different services and one team needs to publish the service to others but still control the lifecycle since they are the developers/owners of the component. We have considered a few approaches:
1)	Providing one or more artifacts as in Alex's example (reuse of artifacts)
2)	Reusing ACTs and more generally ATs

1 seems natural and practical. Having one copy of an artifact allows it to be controlled by the owner and avoids all consumers having to maintain a copy. Of course, if consumers are given a URL from the owner these problems can be avoided with some inconveniences like if the artifact is large and must be copied from the published URL into the platform. However, the more critical issue is that if you intend to share or publish a component, you need a way to define its characteristics an authoritative manner, which is not supported by the current PDP syntax. The obvious thing to do is add a characteristics section which could also be used to contain authorship, version and other important information for consumers. Additionally the platform can add more metadata like with AWS AMIs which specifies the owner and access rights, etc.

I kind of feel 2 is the more general form of 1 but let's treat them separately for now. The interesting aspect of 2 is you are saying you'll reuse someone's ACT in your AT. So is this by reference or by inclusion? Is it transitive? What about cycles? Logically all included components would have to be treated as part of the consumer's app for billing reasons (or maybe not?).
Base on my read of the spec, the 'A' in ACT means the component behavior and lifecycle is under the consumer's control and the 'P; in PCT means that the component behavior and lifecycle is under the platform's control. However, the assumption in both cases is that the PCT is available when needed by the AT. So from the consumer's point of view ACT and PCTs must be available and operational when the app is instantiated. This leaves the behavior which needs to be described and can be done in with characteristics.

A shared ACT smells like a PCT. However, I am not sure what a pure PCT is anymore. Maybe it has special characteristics the platform can endow it. But if there is any way for the consumer to select components by characteristics, these are just additional, albeit unique, characteristics.

In the case the user provides an ACT that has close or identical characteristics to a PCT it again is unclear what the effective difference is. The Shared ACT (call it SCT) now must have characteristics and be considered in matching the consumer's requirements with candidate PCTs and other SCTs in scope.

Mark's comment is interesting, but I don't see how to achieve it with the current spec because of the missing characteristics section in artifacts. And if it is possible, I don't see how matching for PCTs is different for SCTs. PCTs just seem to be some set of CTs which are contributed by the platform. Maybe an SCT is and ACT with a sharable bit set to true like the PCTs. It's not clear from the consumer's perspective. The only reason I can image the consumer needs to be aware of a PCT is to know that he may rely on it being provided by the platform. But this is the same assumption the consumer would make if he consumed SCTs.

Supporting sharing/reuse/composition/substation creates most of these problems, but not supporting these semantics creates others.


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