[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=35160#action_35160 ]
Gilbert Pilz commented on CAMP-29:
----------------------------------
To be clear, this proposal does *not* remove the array of Links to Components from the Platform resource. Oracle's concern is that, if a provider chooses to represent any long-running, shared services with a single, global Component resources (rather than representing them with multiple, per-Assembly facade Components) the Consumer needs a way to navigate to those resources. Since there may be no active Assembly trees that include these Component resources the choices are either (a) via the ServiceTemplate that describes the Component in question, (b) via a global array at the Platform level, (c) both. Since the spec already does (b), we thought it best to leave that particular piece alone from now so we could concentrate on the other changes.
With regards to your other comments, I think there is a lot of promise in these ideas and my sense is that we could both clarify and simplify the spec by concentrating on these resource model issues. One thing that has been bothering me lately is the disconnect between the terminology and information model in the DP and the terminology and information model in our resource model. Most of this disconnect is due to the fact that we developed the resource model first and the DP later and, for whatever reason, didn't try to make the DP conform to the existing resource model. Anish and I have been kicking around the idea of almost literally representing the DP as a resource tree and using that tree to replace AssemblyTemplate/ApplicationComponentTemplate/PlatformComponentRequirement. I think the idea of "this is the DP in YAML" -> "this is the DP in JSON" is relative intuitive and saves our audience the mental effort of trying to figure out the mapping between DP "artifacts" and resource model "ApplicationComponentTemplates" etc. (something we can't even do).
> "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]