OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[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=29459#action_29459 ] 

Frank Leymann  commented on TOSCA-4:
------------------------------------

Addressing Derek's Comment from 07/Feb/12:

Ad „Un-typed/un-named interfaces"

It's no problem at all to associate a NAME attribute to the proposed <Interface> element. I don't get the point why you call operations „un-typed": operations have a name as well as input and output parms, i.e. they have a signature; admittedly, since we combine operations from completely different invocation styles, these signatures are not "beautiful".  

We want to stay out of multiple inheritance as long as possible for avoiding complexity. Also, because an interface (as defined today) is coupled with a node type, we did not see a meaningful scenario in which a given node type inherits from multiple node types. 

Your proposal (1) seems to imply that we add a means to define interfaces separately. Wouldn't this be yet another interface description language?  Well, yes, the Interface element is some sort of IDL, but it's coupled with a node type, i.e. it cannot be viewed as "yet another IDL". 

Ad "Hardcoding operation implementation style at meta level" 

Admittedly, I don't quite get the point, but I try a response: An operation may be associated with multiple implementations (i.e. <ImplementationArtifact> elements). And issue TOSCA-5 proposes to allow implementation artifacts also at the node template level (to override, add to,... the implementation artifacts defined at the node type level). Is that what you are looking for?

Ad "Mixing of WSDL, REST, and Script in same interface"

From a definitional point of view changing an implementation from one style to another is ok: you just redefine the interface by dropping the old style and adding the new style.  But this change has "governance" implications in case the operation is already in use by some plans. Supporting an operation in more than one style in fact requires defining separate operations.

Remark:  Exchanging implementations of an operation without impacting the operation itself could be done based on WSDL bindings (which is not what we propose). But this would imply a different style of interface definition in TOSCA (and additional definitions in WSDL like REST- and Script-bindings) and would introduce an ESB as prereq for a TOSCA environment. Again: this is not what we propose. 

The purpose of operations is to be used by tasks in plans. For this purpose, a human being (the "plan deployer") has to "bind" appropriate operations to all tasks - which is the usual proceeding today.  This human being has to find corresponding operations, i.e. typically, there is no automatism involved. From this point of view, a canonicalization doesn't seem to be necessary. 

Ad "Script operations..."

We would appreciate help by TC members for a detailed description of all the information required for script operations. 


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