[OASIS Issue Tracker] Commented: (CAMP-21) Clarify whether App Developers/Admins can assume what the Assembly Template tree looks like until post-deploy

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

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

Alex Heneveld commented on CAMP-21:
-----------------------------------

Some thoughts / language we could use to clarify this in the spec:

   * if platform can't fulfill the instructions/requirements in a PDP then it should fail.
   * however some instructions may indicate optional activities (such as through an extension) and in that case the PDP would not need to fail.
   * to maximise portability, it is recommended to use portable requirements as much as possible, rather than imperative instructions

Additional comment:  as suggested in this issue, a consumer may need to know something about the shape of the deployed application.  we have Requirements, but do we have any way of telling the consumer how requirements have been fulfilled ?  it seems that such a notion, e.g.

   { "fulfilments": [ 
     { "requirement": "1234", "platformComponent": "/component1" },
     { "requirement": "1235", "platformComponent": "/component2" },
     { "requirement": "1236", "assemblyComponent": "/component3" } 
   ]}

This could exist in an Assembly and in a {App,Platform}Component ...

> Clarify whether App Developers/Admins can assume what the Assembly Template tree looks like until post-deploy
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMP-21
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-21
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>            Reporter: Anish Karmarkar
>            Assignee: Gilbert Pilz
>            Priority: Critical
>
> The resources described by CAMP (e.g. Assembly Template, Application Component Template) represent (among other things) points of management control. Different providers may support different levels of management granularity. For, example, consider the Tomcat sample application. This application is made up of a single WAR file (sample.war) that contains a static HTML file (index.html), a JSP file (hello.jsp), and a servlet class (Hello.class).
> One provider could choose to model this application as an Assembly Template with a single Application Component Template consisting of the sample.war file. Another provider could choose to model the application with multiple Application Component Templates - one for the static, index.html file and one for the Servlet/JSP files (hello.jsp and Hello.class). It depends on the level of management granularity implemented by the provider.
> Unless they have out-of-band knowledge of their target platform, App Developers/Admins can't assume anything about the structure of the post-deploy Assembly Template tree other than the fact that one app => one Assembly Template. Any assumptions they do make about this structure may constrain the portability of their app to other platforms.
> [This issue was raised by Gilbert Pilz and was drupal issue # 1092

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