In order to have a single entry to the documents created in cause of this discussion, I add the reference to the document that sketches how to encapsulate environment dependencies by plans here: http://www.oasis-open.org/apps/org/workgroup/tosca/download.php/45225

The following presentation discusses the possibilities of encapsulating environment dependencies in operations: http://www.oasis-open.org/apps/org/workgroup/tosca/download.php/45320

We compare this approach with the approach discussed before, namely encapsulating environment dependencies in plans (see reference to the corresponding presentation in the comment before).

Derek asked in his Feb 24 comment for more details about the following:
1) A description of plan execution including the general constraints of each step and results of each step.
2) A description of what an implementation would be required to support regarding plan execution. Specifically, I am asking from an interoperability perspective. I.e. what are the capabilities most implementations should have to achieve baseline interoperability? What kinds of deployment artifacts should they support? etc.

Ad 1: If a plan is specified as a process model (eg. in BPMN or BPEL) it will be executed by a process engine. A language for specifying process models typically (e.g. BPMN and BPEL do) allows to define the constraints of performing each step: the precondition for performing a task are defined by means of the control flow pointing to the task, by so-called transistion conditions and join conditions. Furthermore, the data to be passed to the implementation of the task (in TOSCA context to the operation) is defined, as well as how to materialize this data (by means of so-called data maps). The process engine will use all of this to determine if and when a step is to be performed, it will derive the actual input data to be passed to the implemenation of the step, and it will interact with corresponding middleware to actually invoke the implementation of the step. On return of the implementation invoked, the output data of the implementation will be "folded back" into the process context, i.e. the output data will be persistently stored and made available for future steps. I.e. the definition of how to materialize input data for steps may refer to data that is output of an earlier step.

Ad 2: A TOSCA implementation must be able to process a topology template, and to execute plans. Processing a topology template means (at the end) to be able to deploy the artifacts defined by a topology template (i.e. its implementation artifacts and its deployment artifacts) and make them available for plans or operations. How the latter is done depends on the resolution of issue TOSCA 9. For portability purpose, the TC should agree on a list of artifact types that are mandatory to be supported (e.g. JAR, EAR, PY, OVF,...). Executing plans means to be able to instantiate and run a plan. For portability purpose, the TC should agree on a plan language that is mandatory to be supported. If we decide that this is BPMN, for example, a corresponding process engine will handle the execution of plans, i.e. an implementation of TOSCA would require to have such process engine available in the environment.

This discussion also relates to questions posed by Derek Palma in TOSCA-4 (see http://tools.oasis-open.org/issues/browse/TOSCA-4?focusedCommentId=29526&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_29526).

Does this discussion need text in the spec or in a primer? If so, please provide text for review. Otherwise, we should close this issue.

Can we address Frank's Ad 2 and select the process model and smallest set of implementation artifacts that MUST be supported by a compliant implementation so we can generate real TOSCA compliant plans? This will support additional concrete questions.

Here is a proposal to keep it representative but simple:

Process Model:
BPMN

Implementation Artifacts:
WAR (simpler than EAR)
VMImage (OVF, RAW (versus all possible))
Scripts (SH, PowerScript, Perl, Python)

I am absolutely fine with specifying in TOSCA that BPMN 2.0 is the default language for defining plans.

Wrt "artifacts", we need be more specific.

We define "implementation artifacts" as the "executables" realizing operations. The spec lists potential types of operations, i.e. WSDL port type operations, REST interfaces, and scripts. WSDL port types are often implemented as servlets but also as EJBs (in addition to corresponding Windows components). Thus, we should add EARs to Derek's list. REST interfaces are often realized as servlets, i.e. from a Java perspective JAR files or WAR files should be fine. The list of script languages is fine with me, but I need to delegate the list of scripts to others (this is not my skill area).

We define "deployment artifacts" as the "executables" realizing node types/templates. When a node type/template represents infrastructure, i.e. OS or middleware (DBMS, App Server,...) assuming images is fine. The list of VM image formats to be supported needs to be discussed. Also, we need to include AMIs (or references to them) because of their frequent use. But if we move from infrastructure up towards the implementation, we need to support artifacts that represent service- and process-oriented applications. Thus, the artifact types include WSDL files, BPEL- and BPMN files, EAR/JAR files (implementing the WSDL port types) and so on.

Summary: The list is an excellent base, but we should consider to extend it in order to reflect applications that are often (expected to be) run in a cloud environment.

As you know, specifications in standards are about improving interoperability. That will often involve constraining choice, rather than expanding it or listing it, as long as you can find consensus in the TC. Will you be proposing specific text changes to the spec or text/images for a primer, e.g., BPMN as a SHOULD or a MUST?

If this discussion is also evolving towards a "base set" of operations, properties, and maybe a small number of nodes, should this discussion not be informed by one or more use cases? See TOSCA-8, which suggests but does not yet provide some use cases. I have also uploaded a use case template, which folks could use to get things rolling.

TC approves closing this issue without further action on 9/6 (see https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/46841/TOSCA%20TC%20Minutes%202012-09-06.docx).