[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=29650#action_29650 ] 

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

Motivation for "Implications of un-typed/un-named interfaces" issue:

Consider modeling J2EE applications servers from different vendors. Assume they each have their own vendor specific operations, deployEAR,UndeployEAR which function in proprietary manner. This means these 2 operations from each vendor will have different signatures and some variation in semantics (even though they still deployEAR/undeployEAR). Then assume J2EE vendors or a management vendor standardizes the deployEAR/undeployEAR operation for app server, defining another 2 (deployEAR and undeployEAR) operations with another signature. We want J2EE node types to support the proprietary form since some existing plans uses them, but also provide the standardized ones for use by plans which prefer the standardized interfaces.

So before standardized deployEAR/undeployEAR operations are invented we have node types which extend a common J2EE Node Type
J2EE AS <- Vendor1J2EE AS implements Vendor1Deploy/UndeplyEAR 
J2EE AS <- Vendor2J2EE AS implements Vendor2Deploy/UndeplyEAR 

After standardized the deployEAR/undeployEAR operations are invented, they are associated with the J2EE AS Node Type since these operations are common to all J2EE ASes. Now the concrete AS Node Types have two sets of operations: The standardized ones contributed by the common J2EE super Node Type and the ones contributed by the vendor specific Node Types.

Q1) What if there is a name collision across the two sets of operations? How is the desired operation resolved at design time? How is it resolved at runtime or can this ever occur?

Q2) What if we want to change the semantics of one of the operations without changing the signature? How can this be reflected. Is this a new version? We must rename the signature and recognize it at design time.

Q3) What if we don't have a super class and want to place the new operations into the vendor specific Node Type?

By mixing all operations into an unnamed set at the most concrete Node Type we cannot even know which deployEAR/unployEAR operations are compatible with each other without a detail operation metadata analysis. 

Q4) How can different versions of the same sets of operations be supported?

Q5) If there are different implementations of same operations, how are they differentiated? Looking at implementation metadata?

Q6) It feels like not grouping operations into an interface leaves the problems interfaces were invented to solve to begin with. E.g. PortTypes in WSDL or typed interfaces in programming languages. I am wondering why this is feature is excluded from the design. 

The cost of labeling interfaces is just a QNAME for each interface element and allowing multiple interfaces for a Node Type. Both of these could be optional for the simple case.



> 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