[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (TOSCA-109) Use Case: Modularity for Substitutability and Alternative Implementations.
[ http://tools.oasis-open.org/issues/browse/TOSCA-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34376#action_34376 ]
Dale Moberg commented on TOSCA-109:
-----------------------------------
This comment was based on the working draft 11 version of the early 2013 use case for SugarCRM. Recently a working draft 14 of the SugarCRM example was released which emphasized one basic reorganization of TOSCA model elements. In particular, NodeTypes are refactored so that there are NodeTypeImplementations for a NodeType. So now NodeTemplates have a NodeType, and the NodeTypes themselves are "referenced" by (potentially) multiple NodeTypeImplementations. These NodeTypeImplementations themselves "package up" aggregates of Implementation and Deployment Artifacts. The upshot is that in principle different NodeTypeImplementations can be added, without changing either the NodeTemplates or NodeTypes that exist, and so create new modules (of artifacts) that can realize the requirements of NodeTemplates. While other approaches might support more granular approaches to substitution, (which would have both advantages and introduce complications pertaining to implicit artifact dependencies), it seems that the basic structure now permits genuine expression of alternatives that can be produced by adding NodeTypeImplementations (and related elements) to a ServiceTemplate. The new type of "reference" involves using the NodeType qname value as a way in which NodeTypeImplementations refer to the type that they implement, and thus become candidates for implementation/managment of a NodeTemplate. Given that we can introduce a whole group of Arftifacts as an Implementation, the labels of Artifiacts with capabilities is no longer needed. So I suggest this issue be closed with no action, and our efforts directed to thinking about how alternative implementations can be selected by TOSCA runtimes, perhaps by guidance from hew desired features/properties added to NodeTemplates.
> Use Case: Modularity for Substitutability and Alternative Implementations.
> --------------------------------------------------------------------------
>
> Key: TOSCA-109
> URL: http://tools.oasis-open.org/issues/browse/TOSCA-109
> Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
> Issue Type: Improvement
> Components: Interop, Primer , Spec
> Affects Versions: V1.1_CSD01
> Reporter: Dale Moberg
> Assignee: Dale Moberg
> Fix For: V1.1_CSD01
>
>
> Support for substitutability in Tosca models can be understood in several ways. Strong substitutability allows NodeTemplates to be "replaced" by another NodeTemplate or sub-topology that is functionally equivalent to, or a superset of, the functionality of the replaced NodeTemplate.
> The additional notion of modularity is that the functionally equivalent or functionally expanding topology model could be "added" to the existing model without replacing a part of the existing model. Strong modularity would require that no change is required to any component of the existing xml elements in the model representation. (Of course, the root element ("Definitions") would be changed, but not the descendents of the root.) These additions would add modular alternatives to a Tosca model.
> Modular additions might also exist for components other than NodeTemplates. ArtifactTemplates are also a candidate for alternatives.
> This current issue is to describe enhancements to Tosca 1.0 to accommodate ArtifactTemplate alternatives. Use cases of special concern are (1) supporting alternative databases for an application, (2) supporting communications between on-premise and cloud applications with gateways having capabilities for interoperable secure protocols and (3) alternative implementations of cryptographic modules [added].
> Basic Direction
> The basic direction is to leverage the current support of Requirements and Capabilities, and begin by allowing ArtifactTemplates to have Capabilities and Requirements. Let us view our current Topology as a Specification plane for systems, and our current collection of Artifacts as an Implementation plane of the modeled systems. When we connect Specification with Implementation, it becomes possible to execute the operations as specified in Interfaces on NodeTemplates. [Metaphorically, the topology is like a Java interface that the artifacts, like Java classes, implement.] To enable multiple alternative implementations, we need to enhance Tosca's expressive powers to permit ArtifactTemplates to provide Capabilities that can then be matched with a NodeTemplates requirements.
> There are both Deployment Artifacts and Implementation Artifacts. Implementation Artifacts will need to have both Capabilities as well as an index that indicates what Operation of a NodeType is supported. Initially Deployment Artifacts can presumably be linked to the Installation operation.
> The proposed direction will require several schema changes in the content models (complexTypes) that currently are defined for version 1. It may be possible to unify V 1 syntax with a successor by introducing choices in complexTypes or, in some cases, possible to make more "natural" extensions.
> In effect, a new mechanism of Reference is also introduced in the XML. Beyond Ids and IdRefs, and beyond Qnames, a one to many reference mechanism will be introduced based on matches between the Requirement identifiers and their correlative Capability identifiers. Multiple artifacts will have the same set of Capability identifiers that match a NodeTemplate's Requirement identifiers. It is probably better to call this relation one where a NodeTemplate "denotes" various ImplementationArtifacts, or some other term that has a "one-to-many" connotation.
> If this denotational referential mechanism is added, the "hard links" that currently tie NodeTypes to ArtifactTemplates can be made optional in the schema. When that happens, processing to carry out Operations will have to find Artifacts using the denotational matching sketched above.
--
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]