OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Feedback on CAMP Version 1.1 Draft 03 (Dated: 31 July 2013)


Recently I got an opportunity to go through the 
CAMP Version 1.1 Draft 03 (dated: 31 July 2013)

In case this draft is still receiving comments,
I would like to submit the following feedback to TC.

Best Regards,
Devdatta Kulkarni (Rackspace)


I have organized the feedback into two sections:
- conceptual questions / suggestions
- typos

A] Conceptual Questions / suggestions:

1) The specification uses the word 'self-service' as part of definition of the API.
It is not clear what is exactly meant by the term self-service in the context of the API.

2) Page 16, Figure 2.2, ApplicationComponentTemplate (ACT) box
I would assume that an ApplicationComponentTemplate (ACT) would typically be used by more than one
assembly templates. For instance, an ACT for database might be used by all the assembly templates
that depend on that database platform component. If TC agrees to this point of view, then
the suggestion would be to make the assemblyTemplate a LinkArray in the ACT box in Figure 2.2

3) Page 16, Figure 2.2, ApplicationComponent (AC) box
Currently, the AC box does not have reference to the ACT box. Why is that?
Wouldn't it make sense for an AC to maintain a link to the ACT from which it has been derived?

4) Page 20, Figure 2.6, Assembly box
The Assembly resource does not have direct link to Platform Component(s), but has an 
indirect link through Application Component. Why is that?
From an Assembly's point of view, isn't it true that an assembly depends on application components
and platform components, and so, wouldn't it make sense to have a link to platform components
also in an assembly. With the current model, if one has to use sensors on platform components 
that are being used by an assembly, one would have to navigate through the application components.
This can be potentially inefficient.

5) Page 20, Figure 2.6
I feel that the organization of the boxes and the relationships between 
AssemblyTemplate, ApplicationComponentCapability, ApplicationComponentRequirement, and 
ApplicationComponentTemplate can be (should be?) redone.
I don't think it accurately captures the corresponding description in paragraph 6
on page 21 (para starting with "An Application Component can express .. ").
IMO, the english description is much clearer than the Figure.

6) Page 21, top paragraph
I feel that the term "template" is used in two different ways in the specification.
One use of template is to mean a blueprint from which things are "created".
An example of this usage is the AssemblyTemplate and Assembly distinction.
The other use of template is to mean a blueprint that is used for "requirements resolution".
An example of this usage is discussion involving use of PlatformComponentTemplate to 
discover the desired platform components. The paragraph starting with "An Application Component
can express .. " is leading to this confusion in my mind.
May be this discussion could be rewritten?

7) Page 21, Section 2.2
It is not clear why should it be possible to create an assembly template just from a deployment plan (DP).
An assembly template is by definition an 'uninstantiated' representation of an assembly.
An assembly by definition is a running application that includes application source code, db schemas, etc.
A DP by definition does not include application source code.
Therefore, it follows that an assembly template created from a DP cannot lead to an assembly.
So then the question becomes why should it be possible to use DP to create an assembly template?
IMO, creation of an assembly template should only be possible via a PDP.

8) Page 30, Section 4.2
Is there any guidance wrt what should be an 'artifact' and what should be a 'service' in modeling an application?

9) Page 30 and 31, Section 4.2
What do artifacts and services translate into, when a PDP is pushed to the platform? My guess is:
- artifacts map to application components / application component templates
- services map to platform components / platform component templates
If this high-level mapping is correct then the next question is whether they map to a component or 
a component template?

10) Page 32, Example 4 and Page 33, Example 5
Having two different ways to specify the artifacts and services might be confusing.
I understand that the specification may not want to recommend one representation over other,
but, imo, representation in Example 5 is easier to follow (and understand) than that in Example 4.

11) Page 33, Example 5
The specification does not specify any ordering on the artifact types. But such an ordering
would be needed in some situations. For instance, in Example 5, the SqlScript needs to executed before deploying
the war file so as to provide a 'good' experience to the end user.
If the specification is not going to require ordering in the artifacts, and assuming that 
such an order might be important in some cases, what can be done?
Is the 'extensions' mechanism useful for this?

12) Page 98, D.5
It would be useful if 'operations' and 'sensors' are added to the representation of the 
Database resource

B] Typos:

1) Page 18, line 3 from the top.
"are show" should be "are shown"

2) Page 20, Figure 2.6, Platform box
"platformComponentCapabilities" is miss-spelt

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]