[TOSCA-23] TOSCA should allow for defining interfaces for RelationshipType to allow for building "connectors" between Nodes - OASIS Technical Committees Issue Tracker

Details

Type: Improvement
Status: Closed
Priority: Major
Resolution: Unresolved
Affects Version/s: CSD03
Fix Version/s: CSD03
Component/s: Spec
Labels:
None

Proposal:

Hide

We propose the introduction of interfaces for TOSCA Relationship Types as well in order to allow for defining additional manageability operations that are relevant when nodes are set in relation to other nodes. To be more precise, the possibility for defining such interfaces on Relationship Types would allow for defining connectors for specific types of source and target nodes, where the connector itself provides the operations and implementation artifacts to establish a relationship of the respective Relationship Type between two nodes. The Node Types to be related to each other would in turn remain self-contained, and the ability to relate one Node Type to any additional other Node Type could be achieved by defining a new connector instead of having to modify one of the Node Types.

Thus, we are proposing to extend the concept of TOSCA Relationship Types with interfaces that allow for defining the operations and implementation artifacts a management engine can use to establish a relationship of a respective Relationship Type between two nodes of certain Node Types. The addition of interfaces to Relationship Type has several other implications as listed below:
• To allow for refining or overriding operations of a Relationship Type - for example, if a certain combination of application server and database require a special implementation - an inheritance mechanism as defined for Node Types already is required for Relationship Types as well.
• Which such an inheritance mechanism, the semantics attribute of Relationship Type could become obsolete, since a set of super types could be defined (e.g. 'Hosted On', 'Connects To', etc.) from which other, concrete Relationship Types would be derived. Each such super type would then implicitly embody certain semantics.
• Since an operation and its implementation typically only makes sense and works for specific types of source and target nodes of a relationship, Relationship Types should allow for restricting the set of valid source and target Node Types. For example, an operation to establish a JDBC database connection between an application server and a database would not make sense when connecting a 'Virtual Server' node to a 'Shared Storage Device' node.

Show
We propose the introduction of interfaces for TOSCA Relationship Types as well in order to allow for defining additional manageability operations that are relevant when nodes are set in relation to other nodes. To be more precise, the possibility for defining such interfaces on Relationship Types would allow for defining connectors for specific types of source and target nodes, where the connector itself provides the operations and implementation artifacts to establish a relationship of the respective Relationship Type between two nodes. The Node Types to be related to each other would in turn remain self-contained, and the ability to relate one Node Type to any additional other Node Type could be achieved by defining a new connector instead of having to modify one of the Node Types. Thus, we are proposing to extend the concept of TOSCA Relationship Types with interfaces that allow for defining the operations and implementation artifacts a management engine can use to establish a relationship of a respective Relationship Type between two nodes of certain Node Types. The addition of interfaces to Relationship Type has several other implications as listed below: • To allow for refining or overriding operations of a Relationship Type - for example, if a certain combination of application server and database require a special implementation - an inheritance mechanism as defined for Node Types already is required for Relationship Types as well. • Which such an inheritance mechanism, the semantics attribute of Relationship Type could become obsolete, since a set of super types could be defined (e.g. 'Hosted On', 'Connects To', etc.) from which other, concrete Relationship Types would be derived. Each such super type would then implicitly embody certain semantics. • Since an operation and its implementation typically only makes sense and works for specific types of source and target nodes of a relationship, Relationship Types should allow for restricting the set of valid source and target Node Types. For example, an operation to establish a JDBC database connection between an application server and a database would not make sense when connecting a 'Virtual Server' node to a 'Shared Storage Device' node.

Description

TOSCA allows for defining interfaces for Node Types to provide manageability operations that a TOSCA management environment can use to control instances created from that Node Types. When viewed in isolation, a Node Type and its interfaces can be designed self-contained, i.e. without a direct dependency on other Node Types or their interfaces. Referring to the application server example above, the 'Application Server' Node Type interface could define all the operations to deploy, operate and decommission an application server instance as a standalone component. However, as soon as one node is set in relation to one or more other nodes, additional operations are often required to establish the respective relationships. For example, if an application server shall be connected to a database, an additional 'connectToDatabase' operation would be required to establish a database connection between the application server and the database. With the current design of TOSCA, this would mean to define another operation in the interface of the 'Application Server' Node Type.

This seems ok for general application server and database scenarios, since connecting an application server to a database is a common operation and therefore fits into the interface of an 'Application Server' Node Type. In more specific cases, however, the approach can lead to problems, when different operations (or at least different implementation artifacts) are required depending on the specific type of peer node. For example, different operations or implementation artifacts will be required when connecting an application server to an IBM DB2 database or an Oracle database, or even for different versions of the same database product. Extending the interface of a Node Type would require the definition of a new Node Type that derives from the original Node Type. The derived Node Type would then be specific to a certain other Node Type it can be set in relation to - maybe even a specific version of another Node Type. However, that approach break the self-contained design of Node types and limits the re-use of derived Node Types.

TOSCA should allow for defining interfaces for RelationshipType to allow for building "connectors" between Nodes

Details

Description

Attachments

Activity

People

Dates