What is TOSCA?

TOSCA was brought up in an online discussion recently, so I had to go away and figure out what it is all about. TOSCA stands for Topology and Orchestration Specification for Cloud Applications. I managed to extract the following from the OASIS Technical Committee web page. You can find the complete charter here: https://www.oasis-open.org/committees/tosca/charter.php

• Name of the TC: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) Technical Committee
• Statement of Purpose: The goal of the Topology and Orchestration Specification for Cloud Applications (TOSCA) TC is to substantially enhance the portability of cloud applications and the IT services that comprise them running on complex software and hardware infrastructure. The IT application and service level of abstraction in TOSCA will also provide essential support to the continued evolution of cloud computing. For example, TOSCA would enable essential application and service lifecycle management support, e.g., deployment, scaling, patching, etc., in Software Defined Environments (SDE) such as Software Defined Data Centers (SDDC) and Software Defined Networks (SDN).TOSCA will facilitate this goal by enabling the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behavior of these services (e.g., deploy, patch, shutdown) independent of the supplier creating the service, and any particular cloud provider or hosting technology. TOSCA will also enable the association of that higher-level operational behavior with cloud infrastructure management.

  This capability will greatly facilitate much higher levels of cloud service/solution portability without lock-in, including:

  • Portable deployment to any compliant cloud
  • Easier migration of existing applications to the cloud
  • Flexible bursting (consumer choice)
  • Dynamic multi-cloud provider applications

  Ultimately, this will benefit the consumers, developers, and providers of cloud-based solutions and provide an essential foundation for even higher-level TOSCA-based vocabularies that could be focused on specific solutions and domains.

• Scope of Work: It is the goal of the TOSCA TC to complete a revision of the Topology and Orchestration Specification for Cloud Applications, submitted as a foundational specification by Capgemini, CA Technologies, Cisco, Citrix, EMC, IBM, NetApp, PwC, Red Hat, SAP, Software AG, Virtunomic, and WSO2 , and to complete the associated XML Schema plus conformance statements that meets the needs of members of the TOSCA TC and the IT industry as soon as possible, consistent with the OASIS process.The TOSCA TC will leverage this submission as a foundation for further standardization of a basic set of non-service specific and non-product specific components (for example, “database” or “OS”) as opposed to service specific and product specific components (such as “MySQL” or “Linux”), relationships and properties with extension mechanisms to add additional components, relationships and properties. Further standardization on product -specific vocabularies, based on these extension mechanisms, is out of scope for this TC.

  The scope of the TOSCA TC’s work is to produce specifications that standardize the concepts as well as XML documents and XML Schema renderings of the areas described below by further refinement and finalization of the input document and any subsequent input documents accepted by the TOSCA TC. The following items are specifically in scope of the resulting TOSCA specification:

  1. A language that provides the ability to specify a Service Template that can define the topology (or structure) of a service and that can utilize existing process modeling standards (especially BPMN 2.0) to define orchestration (via “plans”) that can invoke the manageability behavior of cloud services.
  2. A syntax for naming component types, components, relationship types, relationships, and properties, and for grouping of components.
  3. Standardization of a basic set of non-service specific and non-product specific component types, relationship types and properties and operations, which includes all type attributes and all contained elements.
  4. The ability to constrain the use of the various elements and their properties that define the topology of a service.
  5. The ability to cross-reference Service Templates to enable composition of services and to enable the management of instantiations of a Service Template in heterogeneous environments.
  6. The ability to use virtual images as implementation artifacts for parts of a Service Template.
  7. The ability to use application artifacts (e.g. JEE, ABAP, etc) as deployment artifacts for parts of a Service Template.
  8. The ability to use other artifacts (e.g. EAR files, OVF files, SCA components, etc) as deployment artifacts for parts of a Service Template.
  9. The ability to annotate the various elements that define the topology of a Service Template with policies that influence use of instances of a Service Template. Such annotations could leverage a wide range of policy languages (e.g. WS-Policy, KaoS , etc.).