[OASIS Issue Tracker] Commented: (TOSCA-4) Modification of the <Interfaces> element of Node Types

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

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

Derek Palma commented on TOSCA-4:
---------------------------------

Here are a few comments/questions regarding the Interfaces element.

Implications of un-typed/un-named interfaces 

The current specification provides a language element for defining the interfaces of a d. As defined, each interface is an un-named and un-typed set of operations.  This makes it difficult to define well defined sets of operations (e.g. like portTypes in WSDL and the typed interfaces we see in programming languages) that can be implemented by different Node Types. The only option today is single inheritance of Node Types. This is problematic if more than one set of operations needs to be standardized (e.g.  start/stop/status, and deploy/update/undeploy)  across Node Types.
Ways around these limitations include:
1.	Extending interface semantics. Adding Interface QNames, interface references for referring to reused interfaces, and preserving the support for more than one interface element. One interface without a QNAME could still be allowed to support existing semantics for cases where typing is not needed.
2.	Allowing a Node Types to be derived from one or more Node Types (multi-inheritance)


Hardcoding operation implementation style at meta level 

The implementation of a Node Type operation implementation at the meta level. This means makes operation implementations invariant across Node Templates. In order to specify a Node Template with an alternative implementation, a new Node Type must be created. The only viable solution is create a new Node Type which is derived from the first and provide an alternative implementation in the sub type. Creating a new subtype can confuse humans and tools if the new Node Type is interpreted as the definitive type for Node Template Operations. Additionally, if a third Node Type is required with a different implementation, there is no type hierarchy which can preserve the intended semantics (i.e. do you make the third Node Type a sub type of the first or the second?)


Mixing of WSDL, REST, and Script in same interface

TOSCA 4 proposal allows including any mix of WSDL, REST, and Script operations in the same interface. What are the implications of changing from one style to another? For example, if the start operation is implemented as a WSDL operation, and now we want to implement it with a script. Does this create a different start operation (i.e. operation signature)? How do we compute the canonical form of the signature for each style? This begs to answer how to find a specific operation and the possible ambiguities. Nevertheless, it still seems desirable to be able to use any kind of operation implementation in the same interface.


Script operations must capture the requirements of environment presumed by the script.

   Input/Output parameters. Command line. Serialized data such as JSON. Location of  files or file descriptors. Can we agree on one general way?

   Failure reporting. Error code. Can all scripts do it the same way?

   Required interpreter. What is the language interpreter version required? What is responsible for installing it. When and how is it determined if this constraint is met?

   Required libraries and packages. Which libraries and packages (binary dependencies) does the script have?  What is responsible for installing them. When and how is it determined if these constraints are met?

   Operating System. Any operating system specific dependencies? 

   User ID, current working directory, paths. How is the script invoked?


> 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
>    Affects Versions: WD1
>            Reporter: Frank Leymann 
>            Priority: Critical
>
> 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