[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (TOSCA-4) Modification of the <Interfaces> element of Node Types
[ http://tools.oasis-open.org/issues/browse/TOSCA-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=29380#action_29380 ]
Frank Leymann commented on TOSCA-4:
------------------------------------
Addressing Derek's Comment from 08/Feb/12:
As of today, we only support state information in the context of plans: the Plan element has a nested PreCondition element. This precondition can be used to check whether or not a plan can/should/... be executed.
I would argue that adding preconditions to operations will significantly complicate the practical use of TOSCA. Assume a plan runs, and on operation is invoked by the plan the precondition of which is not satisfied. Should the plan abort? Should only parts of the plan abort? Which part? What would you do in order to make sure that the precondition is finally satisfied? In TOSCA, the only means we have is to run another plan that performs management operations to move the corresponding node into a state that enables the execution of the operation. And the latter plan might have a precondition saying that it runs in case the state of the node is in a non-desirable state. Thus, the plans in TOSCA really have a central role...
The good news is that by using BPMN, we can cope with such situations: We can define compensation actions in case errors occur (e.g. the state is determined to be wrong); we can precisely define the scope of the compensation actions. The compensation action might be another process (the one i mentioned before) fixing the situation; after the situation has be fixed, the original plan can retry the failed part; etc.
Finally: Yes, it is the purpose of the operations to affect the states of nodes, the environment, the real world. Otherwise, TOSCA wouldn't work as intended. Because operations typically are TOSCA agnostic, it is the plan that must get the return values of the operations, determine which part of the response are relevant for future operations/tasks/plans and reflect that in the TOSCA "container". For the purpose, we have to have an interface that allows this.
> Modification of the <Interfaces> element of Node Types
> ------------------------------------------------------
>
> Key: TOSCA-4
> URL: http://tools.oasis-open.org/issues/browse/TOSCA-4
> Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
> Issue Type: Bug
> Components: Spec
> Affects Versions: WD1
> Reporter: Frank Leymann
> Assignee: Frank Leymann
> Priority: Critical
> Fix For: WD1
>
>
> We propose to drop the <Interfaces> element of node types and support (at most) a single <Interface> for a <NodeType> element. This interface will consist of one of more operations. The implication is that the current <Operation> element must be renamed to better reflect its purpose; because its purpose is to define scripts as operations of node types, we propose to rename todays <Operation> into <ScriptOperation>. As a result of the renaming, an <Interface> consists of <Operation>s that may be either an operation of a port type (i.e. a WSDL operation), a REST API, or a script operation.
> The current <REST> element does not suffice to support the variety of REST APIs found in the industry. The proposal is to extend the current definition accordingly. Beside allowing to define the HTTP method to be used, both, abs_path and absolte_URI variants of request URIs must be supported. The optional body of the request message and the response message must be specifiable. Next, a pure URI variant of passing parameters must be supported, i.e. the new syntax must support to define a URI query string. Also, key HTTP header fields that are relevant for the request must be specifiable.
> Finally, not only script-based operations require implementation artifacts. For example, a REST API may be represented by a WAR file implementing the REST API. This implies to factor out the corresponding <ImplementationArtifacts> element into the embracing (new) <Operation> element.
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]