[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=29667#action_29667 ]
Frank Leymann commented on TOSCA-4:
------------------------------------
Ad "Derek 01/Mar/12" Motivation:
The current spec allows to standardize a node type called JEE_AS. Next, the two vendors define their node types Ven1_AS and Ven2_AS inheriting from JEE_AS (via the NodeType/DerivedFrom element). In doing so, they (i) may override an inherited operation (and changing the signature), or (ii) keep the signature intact but override the Implementation Artifact (based on the new syntax proposed in TOSCA-4).
Alternative (i) requires (based on todays spec) that plans are bound to the operations of the new signature. Admittedly a pain. But vendors might decide to build modelling tools that allows modelers to use the supertype JEE_AS and re-write the plan by substituting the JEE_AS operaration by the refined Ven1_AS and Ven2_AS operations.
Alternative (ii) allows a plan modeler to refer to the JEE_AS operation but because that overriding Implementation Artifact is bound/called this overriding implementation maps the "general signature" onto the "vendor specific signature". This is another incarnation of the principle, that template modeling and plan modeling should be simple, but the "pain is put onto the node type vendor" (see the discussion on encapsulating environment dependencies in plans or in operations, respectively).
But the important point is that a plan is portable independent from the approach chosen - one of the goals of the standard specification. And vendors might distinguish themselves by the degree of ease of template modeling and plan modeling.
> 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
> Reporter: Frank Leymann
> Assignee: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]