[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=29668#action_29668 ]
Frank Leymann commented on TOSCA-4:
------------------------------------
Ad "Derek 01/Mar/12" Q1...Q6:
Ad Q1: a task in a plan is always associated to a single particular operation (which true for both, BPMN as well as BPEL, for example). So there is no runtime resolution. If you want this runtime resolution, you must hide the different implementations behind a WSDL port type that can be resolved by an underlying ESB at runtime. This would be a design consideration of the vendors standardizing the JEE_AS.
Ad Q2: the only way to exchange "the semantics of an operation" is to substitute its implementation artifact. This can be done by changing the service template and specify the new Implementation Artifact; or you substitute the old implementation by the new one without updating the corresponding service template. The advantage of the former is that you always have a service template representing the newest variant; the advantag of the latter is speed and simplicity. Note, that there is no versioning concept in TOSCA today; our hope is to be able to focus on solving simple portability scenarios in TOSCA V1 and concentrate on advanced issues (like versioning) in a later TOSCA release.
Ad Q3: you need to define a new node type. Versioning would make this easier.
Ad Q4: no surprise anymore, we don't support versioning as of today.
Ad Q5: Implementation Artifacts have an ID (todays spec) or the refer to an operation name and specify a type (TOSCA-4 proposal). However, the different implementations can be distinguished (metadata).
Ad Q6: the rational was to avoid defining "yet another interface definition" language. My very personal opinion is that we can solve a couple of problems you sketch with WSDL, but in some communities WSDL sound to heavy-weight. This is why we came up with a spec that allows WSDL, but also supports REST (which is preferred by those considering WSDL to heavy), and to support scripts as first class citizen because of their overwhelming importance in the domain.
> 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]