I added a proposal for resolving this issue: http://www.oasis-open.org/apps/org/workgroup/tosca/download.php/45048

Regarding the RESTful operations, the implication is that any parameters to be included in the url would be specified as query params. Are we disallowing services that expect params using the URI;name=value;... syntax, or form based parameters?

Also, for script operations, do we need an attribute specifying the location of the script, or is that defined by an implementation artifact?

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?

Operation dependencies on node state

In order to be able to execute any particular operation, I presume there an expectation that the node would be in a specific operational state, i.e. if the operation requires the node to be running and possibly not processing requests? Is it the job of the plan to ensure this state? It seems operations must declare which node states they may be executed in.

A corollary question is can operations affect node states? I always assumed operations like start and stop would exist.

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

RESTful operations can pass input in the "name=value" format: this is referred to as "query string". The Parameter elements describe exactly the "name" part of a query string.
Note, that we do not foresee that the query string can pass matrix parameters (i.e. those in the "name_1;name_2=value,name_3=value...") because this is not supported by all http servers.

Form-based passing of input and output is covered by specifying corresponding QNames of the requestBody and/or responseBody attributes.

The implementation artifact has a type, and the content of such an implementation artifact is type-specific. We may define a couple of types (and their formats). One of these types may define that the location of the script is the content of the artifact, while another type of artifact might define how to specify scripts in place. And of course each of these types may define as content any kind and any number of type-specific "metadata" for the implementation artifact.

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

As of today, we only support state information in the context of plans: the Plan element has a nested PreCondition element. This precondition can be used to check whether or not a plan can/should/... be executed.

I would argue that adding preconditions to operations will significantly complicate the practical use of TOSCA. Assume a plan runs, and on operation is invoked by the plan the precondition of which is not satisfied. Should the plan abort? Should only parts of the plan abort? Which part? What would you do in order to make sure that the precondition is finally satisfied? In TOSCA, the only means we have is to run another plan that performs management operations to move the corresponding node into a state that enables the execution of the operation. And the latter plan might have a precondition saying that it runs in case the state of the node is in a non-desirable state. Thus, the plans in TOSCA really have a central role...

The good news is that by using BPMN, we can cope with such situations: We can define compensation actions in case errors occur (e.g. the state is determined to be wrong); we can precisely define the scope of the compensation actions. The compensation action might be another process (the one i mentioned before) fixing the situation; after the situation has be fixed, the original plan can retry the failed part; etc.

Finally: Yes, it is the purpose of the operations to affect the states of nodes, the environment, the real world. Otherwise, TOSCA wouldn't work as intended. Because operations typically are TOSCA agnostic, it is the plan that must get the return values of the operations, determine which part of the response are relevant for future operations/tasks/plans and reflect that in the TOSCA "container". For the purpose, we have to have an interface that allows this.

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.

When discussing TOSCA Issue 4, the question came up how dependent plans are on the actual Cloud infrastructure a TOSCA Cloud Application will be installed in. The following document (a pdf of a presentation) discusses this question: http://www.oasis-open.org/apps/org/workgroup/tosca/download.php/45225

We have added a discussion covering the dependency of plans on specific infrastructure. Frank owns this discussion/issue, too, BUT specific proposals, if any, that spring from this discussion should be a SEPARATE JIRA issue.

Following up on my questions from the 2/23/12 TC meeting, I would like request some details about slide one of http://www.oasis-open.org/apps/org/workgroup/tosca/download.php/45225, posted by on 2/22/12 by Frank, since I cannot find them in the current draft.

1) A description of plan execution including the general constraints of each step and results of each step.
2) A description of what an implementation would be required to support regarding plan execution. Specifically, I am asking from an interoperability perspective. I.e. what are the capabilities most implementations should have to achieve baseline interoperability? What kinds of deployment artifacts should they support? etc.

I discuss this comment in context of issue TOSCA 9.

Derek Palma introduced questions related to the relationship between container infrastructure and plans. This was identified as being a different concern. See TOSCA-9 (http://tools.oasis-open.org/issues/browse/TOSCA-9) for this discussion.

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.

Clarification for "Hardcoding operation implementation style at meta level"

Assuming implementations can vary for same set of operations in an interface and signatures are invariant, how does one identify the current implementation or desired semantics? Inspection of implementation metadata? What if by change the implementation artifacts names are invariant? (I don't really recommend this, I am just trying to answer my question.)

I wonder again why Interfaces are not named. A QNAME can easily describe this idea versus having to look elsewhere. Here I again repeat my question why well named interfaces are not in the design.

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

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.

General comment on Ad "Derek 01/Mar/12":

One might think about inventing a mechanism that allows to refer to super types only (JEE_AS instead of Ven1_AS or Ven2_AS) and let "the system" find out at runtime what the appropriate implementation is. But vendor specifc implementations typically have different dependencies, for example: Ven1_AS may work well with VenX_DB and VenY_DB, while Ven2_AS works only with VenA_DB. Such dependencies would have to be defined/declared by "some means", i.e. they have to be made explicit. One way of making such dependencies explicit in a portable manner is by rendering them in plans.

Again, vendors might differentiate themselves by fancy tools that generate topology templates and plans from very special representations that are proprietary. The generated service definition can then be moved into any TOSCA compliant environment. But again, this is my very personal view...

I added a revision of the proposal for resolving issue TOSCA-4: http://www.oasis-open.org/apps/org/workgroup/tosca/download.php/45499/latest

This revision changed the syntax of the <Interface> element to reflect the requirement for:
multiple interfaces of a node type,
(ii) naming interfaces,
(iii) specifying dependencies of an implementation artifact.

Also, the corresponding text explaining the syntax has been changes and further extended.

List item (iii) is new and has not been discussed in the TC. Its justification is as follows: an operation that is supposed to hide environment dependencies must be able to either declare its assumption about the TOSCA container environment it is running in, or (ii) to discover the capabilities of this environment. An example of such a dependency is the interface available in the environment to handle images.

Alternative is reflected in the proposed syntax: the implementation artifact simply lists a set of URIs that declare these dependencies. A TOSCA environment (knowing its capabilities) can then select during binding of a plan the matching implementation artifact for a task in a plan.

Alternative (ii) would require a to define and standardize a corresponding API that would have to be supported by TOSCA environments. Furthermore, the need to use this API would make writing operations a bit more cumbersome, or might even require to change existing implementations of operations. Thus, alternative is considered to be preferable.

At this time, I presume WD04 will be folded into CSD02. If not, I will change the version assignment.

Re-opening to resolve issue in JIRA as per minutes of 2012-04-29.

Resolved and all spec changes approved as per minutes of 2012-04-29 meeting.

Motion: Approve http://www.oasis-open.org/apps/org/workgroup/tosca/download.php/45532/TOSCA-v1.0-wd04.zip and close TOSCA-4.

This issue should have been marked closed, not resolved. No additional proposal/product needed.