OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tosca-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: ODCA feedback on TOSCA TC



Thank you for the comments from ODCA. I acknowledge receipt of the below as TOSCA TC Co-Chair. Please be assured that the TC will carefully consider these comments.



Paul Lipton



From: tosca-comment@lists.oasis-open.org [mailto:tosca-comment@lists.oasis-open.org] On Behalf Of Keehan, Karen A
Sent: Friday, January 11, 2013 7:17 PM
To: tosca-comment@lists.oasis-open.org
Cc: Giri, Ravi A; Chet Ensign; Ryan Skipp; Spence, Catherine
Subject: [tosca-comment] ODCA feedback on TOSCA TC


The following is feedback from ODCA based on ODCA Usage Models (UMs). The comparison(s) are against the ODCA requirements in ‘Interop Across Clouds’, ‘Service Orchestration’ and ‘VM Interoperability’ documents which can be accessed here along with the rest of our UMs.



ODCA [Manageability | CIaaS | Services] WG



Cloud Consumers

Cloud Service Providers


Logical Cloud 'layers' - IaaS, PaaS, SaaS

Agnostic to Cloud Layers, applies to generic 'services'


Portability & Interconnect-ability are the 2 two elements that define interoperability. Considerations for both of these  as they apply to IaaS, PaaS and SaaS is explicitly called out in the usage models. Portability is understood to be event driven.

A service defined using the templates can be hosted with any service provider that is TOSCA compliant or even across service providers. i.e., Vendor Agnostic definition, deployment, migration and management of services.


Due to the cloud provider focus, PaaS and SaaS considerations -  application portability, inter-connectability between environments are not addressed


Security WG has extensive and comprehensive details

on requirements to cover possible use cases across tiers

Security is no explicitly called out or indicated as a mandatory requirement.

The TOSCA template language is extensible enough to potentially allow security requirements to be defined (e.g.: using custom name/value pair attributes) but

The lack of explicit security focus is a gap.


There are specific service tiers defined - Bronze, Silver, Gold

and Platinum

There are no tier definitions, but requirements (and capabilities) that align to the ODCA service tiers can technically be captured in the template that is used to define the service and it's components.


It would be useful to consider Bronze / Silver / Gold / Platinum impacts here there isnt a One size fits all in this space, especially when, public, private and hybrid models are in context of the rest of the interoperability

Service Catalog

ODCA has the definition of a service catalog which can be used to 'discover' services and their capabilities and serve as a broker across  cloud service providers



The model seems to have a direct Cloud to Cloud relationship, whereas ODCA see the need for an intermediate Service Catalogue very seldom will 2 Cloud Providers directly expose their direct Cloud environments they would have APIs but these would use a Service Catalogue for brokering between Cloud, and this seems to be missing from the concept


It would appear a catalogue would have to be created per node, with commercial, service and technical capabilities described a more effective way is a central catalogue mapping all the node capabilities and topologies and dependencies, making maintenance and control of publishing easier

The concept of a service catalog is not called out explicitly but the service template itself can be part of the catalog and the standardization allows easier discovery of the service and it's capabilities as well as automated mapping to expected requirements.


But, very few organization would be amenable to allowing full XML service template definitions to be available for 'discovery' - so this is limited due to security concerns





The language constructs do allow inheritance of requirements, capabilities, states and interfaces using the DerivedFrom attribute, so needing to specify a service catalog per node can be avoided

Use Cases

There is extensive documentation of a broad range of use cases from a cloud consumer point of view and the requirements for each of them is also captured

The major use cases (cloud provider specific) for TOSCA are:

1. Services as marketable entities - standardized service templates as a means of creating a 'marketplace' for 'interoperable' IT services

2.      Portability of Service Templates - Portability of a 'service' means that the service definition can be understood across vendors. i.e., service templates defining the structure and orchestration created by one vendor (service provider) can be parsed/understood by any other vendor that is 'TOSCA compliant'.

3.      Service Composition - allows vendor agnostic composition of service. i.e., components for a service could be from any vendor and are replaceable using the service template as a layer of abstraction for vendor selection flexibility

4.      Relation to Virtual Images -the service templates allow composition of service from various virtualization technologies, or a combination of them.

Language Considerations

ODCA prefers RESTful interfaces / web services



Kind Regards,

Karen Keehan

Intel Corporation | Director, Industry Collaborations, Open Data Center Alliance (ODCA) | 303-513-1703 mobile |  303-993-4740 office



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]