[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=31742#action_31742 ] 

Gilbert Pilz commented on CAMP-29:
----------------------------------

The "horses analogy" works the other way for me. With respect to which horse I might be willing to ride, I don't care if you call a certain horse "a riding horse", if it stands 16 hands high and is known to be high-spirited, I don't want to ride it. What is important is the characteristics of the horse, not how it is labeled.

Here are some of the problems with segregating the components:

1.) The segregation is compounded by the fact that we also have Templates, Capabilities, and Requirements. If we added the "External" distinction to the "Application/Platform" distinction, we would have a total of 12 different things. Having this many distinct resource types makes the spec harder to read and understand. For example, when you talk about an "External Component Requirement" is it important that it is "External" or that it is a "Requirement"? Even now, some of the original spec authors disagree about whether "Platform Component Requirement" is an entity that is produced by the Application Developer or provided by the platform.

2.) From a coding perspective, having to write and maintain separate objects for what are essentially the same types of resources makes it more difficult to implement the spec as well as increases the opportunity for bugs. Once again there is likely to be a multiplying factor. In my (admittedly non-optimized) implementation, there are 3 Java classes for every resource type (an external bean that is used by the Jackson libraries, a servlet that services requests for that type of resource, and an internal, Tomcat-specific class). 

3.) From a debugging perspective, having to read through three different arrays of links to essentially the same types of resource is inefficient and bothersome.

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

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