[OASIS Issue Tracker] Commented: (TOSCA-9) Environment Dependencie of Plans and Operations

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

    [ http://tools.oasis-open.org/issues/browse/TOSCA-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=29637#action_29637 ] 

Frank Leymann  commented on TOSCA-9:
------------------------------------

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. 

> Environment Dependencie of Plans and Operations
> -----------------------------------------------
>
>                 Key: TOSCA-9
>                 URL: http://tools.oasis-open.org/issues/browse/TOSCA-9
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Improvement
>          Components: Spec
>    Affects Versions: WD1
>            Reporter: Frank Leymann 
>            Priority: Minor
>
> We started a discussion on dependencies of plans on the target environment of cloud services.  This discussion was held in the context of TOSCA Issue 4.  But TOSCA Issue 4 is more focussed on fixing a problem with interface definitions.  
> The main purpose of this issue is to discuss conceptual and architectural aspects on environment dependencies of plans and operations, as well as the relation of plans and operations. 

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