Topology and Orchestration Specification for Cloud Applications Version 1.0 Plus Errata 01

OASIS Standard incorporating Draft 02 of Errata 01

25 November 2013 14 August 2014

Specification URIs

This version:

http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/csd02/TOSCA-v1.0-errata01-csd02-complete.pdf (Authoritative)

http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/csd02/TOSCA-v1.0-errata01-csd02-complete.html

http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/csd02/TOSCA-v1.0-errata01-csd02-complete.doc

Previous version:

http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/csd01/TOSCA-v1.0-errata01-csd01-complete.pdf (Authoritative)

http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/csd01/TOSCA-v1.0-errata01-csd01-complete.html

http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/csd01/TOSCA-v1.0-errata01-csd01-complete.doc

Latest version:

http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/TOSCA-v1.0-errata01-complete.pdf (Authoritative)

http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/TOSCA-v1.0-errata01-complete.html

http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/TOSCA-v1.0-errata01-complete.doc

Technical Committee:

OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

Chairs:

Paul Lipton (paul.lipton@ca.com), CA Technologies

Simon Moser (smoser@de.ibm.com), IBM

Editors:

Derek Palma (dpalma@vnomic.com), Vnomic

Thomas Spatzier (thomas.spatzier@de.ibm.com), IBM

Additional artifacts:

This prose specification is one component of a Work Product that also includes:

·         Topology and Orchestration Specification for Cloud Applications Version 1.0 Errata 01. Edited by Derek Palma and Thomas Spatzier. 14 August 2014. Committee Specification Draft 02. http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/csd02/TOSCA-v1.0-errata01-csd02.html. Latest version: http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/TOSCA-v1.0-errata01.html.

·         XML schemas: http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/csd02/schemas/.

Related work:

This specification includes change markings to indicate Errata for:

·         Topology and Orchestration Specification for Cloud Applications Version 1.0. Edited by Derek Palma and Thomas Spatzier. 25 November 2013. OASIS Standard. http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html.

Declared XML namespace:

·         http://docs.oasis-open.org/tosca/ns/2011/12

Abstract:

The concept of a “service template” is used to specify the “topology” (or structure) and “orchestration” (or invocation of management behavior) of IT services. Typically, services are provisioned in an IT infrastructure and their management behavior must be orchestrated in accordance with constraints or policies from there on, for example in order to achieve service level objectives.

This specification introduces the formal description of Service Templates, including their structure, properties, and behavior.

Status:

This document was last revised or approved by the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca#technical.

TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’s public comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at https://www.oasis-open.org/committees/tosca/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (https://www.oasis-open.org/committees/tosca/ipr.php).

Citation format:

When referencing this specification the following citation format should be used:

[TOSCA-v1.0]

Topology and Orchestration Specification for Cloud Applications Version 1.0 Plus Errata 01. Edited by Derek Palma and Thomas Spatzier. 14 August 2014. OASIS Standard incorporating Draft 02 of Errata 01. http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/csd02/TOSCA-v1.0-errata01-csd02-complete.html. Latest version: http://docs.oasis-open.org/tosca/TOSCA/v1.0/errata01/TOSCA-v1.0-errata01-complete.html.

Notices

Copyright © OASIS Open 2014. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.

 

Table of Contents

1        Introduction. 7

2        Language Design. 8

2.1 Dependencies on Other Specifications. 8

2.2 Notational Conventions. 8

2.3 Normative References. 8

2.4 Non-Normative References. 9

2.5 Typographical Conventions. 9

2.6 Namespaces. 10

2.7 Language Extensibility. 10

3        Core Concepts and Usage Pattern. 11

3.1 Core Concepts. 11

3.2 Use Cases. 12

3.2.1 Services as Marketable Entities. 12

3.2.2 Portability of Service Templates. 13

3.2.3 Service Composition. 13

3.2.4 Relation to Virtual Images. 13

3.3 Service Templates and Artifacts. 13

3.4 Requirements and Capabilities. 14

3.5 Composition of Service Templates. 15

3.6 Policies in TOSCA. 15

3.7 Archive Format for Cloud Applications. 16

4        The TOSCA Definitions Document 18

4.1 XML Syntax. 18

4.2 Properties. 19

4.3 Example. 22

5        Service Templates. 23

5.1 XML Syntax. 23

5.2 Properties. 26

5.3 Example. 37

6        Node Types. 39

6.1 XML Syntax. 39

6.2 Properties. 40

6.3 Derivation Rules. 43

6.4 Example. 43

7        Node Type Implementations. 45

7.1 XML Syntax. 45

7.2 Properties. 46

7.3 Derivation Rules. 48

7.4 Example. 49

8        Relationship Types. 50

8.1 XML Syntax. 50

8.2 Properties. 51

8.3 Derivation Rules. 52

8.4 Example. 53

9        Relationship Type Implementations. 54

9.1 XML Syntax. 54

9.2 Properties. 54

9.3 Derivation Rules. 56

9.4 Example. 57

10      Requirement Types. 58

10.1 XML Syntax. 58

10.2 Properties. 58

10.3 Derivation Rules. 59

10.4 Example. 60

11      Capability Types. 61

11.1 XML Syntax. 61

11.2 Properties. 61

11.3 Derivation Rules. 62

11.4 Example. 62

12      Artifact Types. 64

12.1 XML Syntax. 64

12.2 Properties. 64

12.3 Derivation Rules. 65

12.4 Example. 65

13      Artifact Templates. 67

13.1 XML Syntax. 67

13.2 Properties. 67

13.3 Example. 69

14      Policy Types. 70

14.1 XML Syntax. 70

14.2 Properties. 70

14.3 Derivation Rules. 71

14.4 Example. 72

15      Policy Templates. 73

15.1 XML Syntax. 73

15.2 Properties. 73

15.3 Example. 74

16      Cloud Service Archive (CSAR) 75

16.1 Overall Structure of a CSAR. 75

16.2 TOSCA Meta File. 75

16.3 Example. 76

17      Security Considerations. 80

18      Conformance. 81

Appendix A.       Portability and Interoperability Considerations. 82

Appendix B.       Acknowledgements. 83

Appendix C.       Complete TOSCA Grammar 85

Appendix D.       TOSCA Schema. 93

Appendix E.       Sample. 110

E.1 Sample Service Topology Definition. 110

Appendix F.        Revision History. 113

 

 


1      Introduction

Cloud computing can become more valuable if the semi-automatic creation and management of application layer services can be ported across alternative cloud implementation environments so that the services remain interoperable. This core TOSCA specification provides a language to describe service components and their relationships using a service topology, and it provides for describing the management procedures that create or modify services using orchestration processes. The combination of topology and orchestration in a Service Template describes what is needed to be preserved across deployments in different environments to enable interoperable deployment of cloud services and their management throughout the complete lifecycle (e.g. scaling, patching, monitoring, etc.) when the applications are ported over alternative cloud environments.

2      Language Design

The TOSCA language introduces a grammar for describing service templates by means of Topology Templates and plans. The focus is on design time aspects, i.e. the description of services to ensure their exchange. Runtime aspects are addressed by providing a container for specifying models of plans which support the management of instances of services.

The language provides an extension mechanism that can be used to extend the definitions with additional vendor-specific or domain-specific information.

2.1 Dependencies on Other Specifications

TOSCA utilizes the following specifications:

2.2 Notational Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

This specification follows XML naming and design rules as described in [UNCEFACT XMLNDR], i.e. uses upper camel-case notation for XML element names and lower camel-case notation for XML attribute names.

2.3 Normative References

[RFC2119]               S. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF", BCP 14, RFC 2119, March 1997.
http://www.ietf.org/rfc/rfc2119.txt

[RFC 2396]              T. Berners-Lee, R.T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax, http://www.ietf.org/rfc/rfc2396.txt,", RFC 2396, August 1988.1998.
http://www.ietf.org/rfc/rfc2396.txt

[XML Base]             XML Base (Second Edition), W3C Recommendation, http://www.w3.org/TR/xmlbase/

[XML Infoset]          XML Information Set, W3C Recommendation, http://www.w3.org/TR/2001/REC-xml-infoset-20011024/

[XML Base]             XML Base (Second Edition), J. Marsh, R. Tobin, eds. World Wide Web Consortium, 28 January 2009. This edition of XML Base is:
http://www.w3.org/TR/2009/REC-xmlbase-20090128/.
The latest edition of XML Base is available at:
http://www.w3.org/TR/xmlbase/.

[XML Infoset]          XML Information Set , J. Cowan, R. Tobin, Editors, W3C Recommendation, 24 October 2001. This edition of XML Infoset is:
http://www.w3.org/TR/2001/REC-xml-infoset-20011024/.
The latest edition of XML Infoset is available at:
http://www.w3.org/TR/xml-infoset.

[XML Namespaces] Namespaces in XML 1.0 (SecondThird Edition), W3C Recommendation, http://www.w3.org/TR/REC-xml-names/T. Bray, D. Hollander, A.

Layman, R. Tobin, H. Thompson, eds. World Wide Web Consortium, 8 December 2009. This edition of Namespaces in XML is:
http://www.w3.org/TR/2009/REC-xml-names-20091208/.

The latest edition of Namespaces in XML is available at: http://www.w3.org/TR/xml-names/.

[XML Schema Part 1]          XML Schema Part 1: Structures, W3C Recommendation, Second Edition. H.S. Thompson, D.

Beech, M. Maloney, N. Mendelsohn, eds. World Wide Web Consortium, 28 October 2004, http://www.w3.org/TR/xmlschema-1/ . This edition of XML Schema Part 1 is:
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/.

The latest edition of XML Schema Part 1 is available at:

http://www.w3.org/TR/xmlschema-1/.

[XML Schema Part 2]          XML Schema Part 2: Datatypes, W3C Recommendation, October 2004, http://www.w3.org/TR/xmlschema-2/  Second Edition. P. Biron, A. Malhotra, eds. World Wide Web Consortium, 28 October 2004.

[XMLSpec]             XML Specification, W3C Recommendation, February 1998, http://www.w3.org/TR/1998/REC-xml-19980210

This edition of XML Schema Part 2 is:
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.

The latest edition of XML Schema Part 2 is available at:

http://www.w3.org/TR/xmlschema-2/.

[XMLSpec]             Extensible Markup Language (XML) 1.0 (Fifth Edition), T. Bray, J.

Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau, eds. World Wide Web Consortium, 26 November 2008.

This edition of XML 1.0 is:
http://www.w3.org/TR/2008/REC-xml-20081126/.

The latest edition of XML 1.0 is available at:
http://www.w3.org/TR/xml/.

 

2.4 Non-Normative References

[BPEL 2.0]              Web Services Business Process Execution Language Version 2.0. OASIS Standard. 11 April 2007. http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html.

[BPMN 2.0]             OMG Business Process Model and Notation (BPMN) Version 2.0, http://www.omg.org/spec/BPMN/2.0/

[OVF]                     Open Virtualization Format Specification Version 1.1.0, http://www.dmtf.org/standards/published_documents/DSP0243_1.1.0.pdf

[XPATH 1.0]            XML Path Language (XPath) Version 1.0, W3C Recommendation, November 1999, http://www.w3.org/TR/1999/REC-xpath-19991116 , J. Clark, S. J. DeRose,

Editors, W3C Recommendation, 16 November 1999,

http://www.w3.org/TR/1999/REC-xpath-19991116.

Latest version available at:
http://www.w3.org/TR/xpath.

[UNCEFACT XMLNDR]        UN/CEFACT XML Naming and Design Rules Technical Specification, Version 3.0, http://www.unece.org/fileadmin/DAM/cefact/xml/UNCEFACT+XML+NDR+V3p0.pdf

 

2.5 Typographical Conventions

This specification uses the following conventions inside tables describing the resource data model:

In addition, this specification uses the following syntax to define the serialization of resources:

2.6 Namespaces

This specification uses a number of namespace prefixes throughout; they are listed in Table 1. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [XML Namespaces]). Furthermore, the namespace http://docs.oasis-open.org/tosca/ns/2011/12 is assumed to be the default namespace, i.e. the corresponding namespace name tosca is omitted in this specification to improve readability.

 

Prefix

Namespace

tosca

http://docs.oasis-open.org/tosca/ns/2011/12

xs

http://www.w3.org/2001/XMLSchema

Table 1: Prefixes and namespaces used in this specification

 

All information items defined by TOSCA are identified by one of the XML namespace URIs above [XML Namespaces]. A normative XML Schema ([XML Schema Part 1][XML Schema Part 2]) document for TOSCA can be obtained by dereferencing one of the XML namespace URIs.

2.7 Language Extensibility

The TOSCA extensibility mechanism allows:

The specification differentiates between mandatory and optional extensions (the section below explains the syntax used to declare extensions). If a mandatory extension is used, a compliant implementation MUST understand the extension. If an optional extension is used, a compliant implementation MAY ignore the extension.

3      Core Concepts and Usage Pattern

The main concepts behind TOSCA are described and some usage patterns of Service Templates are sketched.

3.1 Core Concepts

This specification defines a metamodel for defining IT services. This metamodel defines both the structure of a service as well as how to manage it. A Topology Template (also referred to as the topology model of a service) defines the structure of a service. Plans define the process models that are used to create and terminate a service as well as to manage a service during its whole lifetime. The major elements defining a service are depicted in Figure 1.

 

A Topology Template consists of a set of Node Templates and Relationship Templates that together define the topology model of a service as a (not necessarily connected) directed graph. A node in this graph is represented by a Node Template. A Node Template specifies the occurrence of a Node Type as a component of a service. A Node Type defines the properties of such a component (via Node Type Properties) and the operations (via Interfaces) available to manipulate the component. Node Types are defined separately for reuse purposes and a Node Template references a Node Type and adds usage constraints, such as how many times the component can occur.

 

 

Figure 1: Structural Elements of a Service Template and their Relations

For example, consider a service that consists of an application server, a process engine, and a process model. A Topology Template defining that service would include one Node Template of Node Type “application server”, another Node Template of Node Type “process engine”, and a third Node Template of Node Type “process model”. The application server Node Type defines properties like the IP address of an instance of this type, an operation for installing the application server with the corresponding IP address, and an operation for shutting down an instance of this application server. A constraint in the Node Template can specify a range of IP addresses available when making a concrete application server available.

A Relationship Template specifies the occurrence of a relationship between nodes in a Topology Template. Each Relationship Template refers to a Relationship Type that defines the semantics and any properties of the relationship. Relationship Types are defined separately for reuse purposes. The Relationship Template indicates the elements it connects and the direction of the relationship by defining one source and one target element (in nested SourceElement and TargetElement elements). The Relationship Template also defines any constraints with the OPTIONAL RelationshipConstraints element.

For example, a relationship can be established between the process engine Node Template and application server Node Template with the meaning “hosted by”, and between the process model Node Template and process engine Node Template with meaning “deployed on”.

A deployed service is an instance of a Service Template. More precisely, the instance is derived by instantiating the Topology Template of its Service Template, most often by running a special plan defined for the Service Template, often referred to as build plan. The build plan will provide actual values for the various properties of the various Node Templates and Relationship Templates of the Topology Template. These values can come from input passed in by users as triggered by human interactions defined within the build plan, by automated operations defined within the build plan (such as a directory lookup), or the templates can specify default values for some properties. The build plan will typically make use of operations of the Node Types of the Node Templates.

For example, the application server Node Template will be instantiated by installing an actual application server at a concrete IP address considering the specified range of IP addresses. Next, the process engine Node Template will be instantiated by installing a concrete process engine on that application server (as indicated by the “hosted by” relationship template). Finally, the process model Node Template will be instantiated by deploying the process model on that process engine (as indicated by the “deployed on” relationship template).

Plans defined in a Service Template describe the management aspects of service instances, especially their creation and termination. These plans are defined as process models, i.e. a workflow of one or more steps. Instead of providing another language for defining process models, the specification relies on existing languages like BPMN or BPEL. Relying on existing standards in this space facilitates portability and interoperability, but any language for defining process models can be used. The TOSCA metamodel provides containers to either refer to a process model (via Plan Model Reference) or to include the actual model in the plan (via Plan Model). A process model can contain tasks (using BPMN terminology) that refer to operations of Interfaces of Node Templates (or operations defined by the Node Types specified in the type attribute of the Node Templates, respectively), operations of Interfaces of Relationship Templates (or operations defined by the Relationship Types specified in the type attribute of the Relationship Templates, respectively), or any other interface (e.g. the invocation of an external service for licensing); in doing so, a plan can directly manipulate nodes of the topology of a service or interact with external systems.

3.2 Use Cases

The specification supports at least the following major use cases.

3.2.1 Services as Marketable Entities

Standardizing Service Templates will support the creation of a market for hosted IT services. Especially, a standard for specifying Topology Templates (i.e. the set of components a service consists of as well as their mutual dependencies) enables interoperable definitions of the structure of services. Such a service topology model could be created by a service developer who understands the internals of a particular service. The Service Template could then be published in catalogs of one or more service providers for selection and use by potential customers. Each service provider would map the specified service topology to its available concrete infrastructure in order to support concrete instances of the service and adapt the management plans accordingly.

Making a concrete instance of a Topology Template can be done by running a corresponding Plan (so-called instantiating management plan, a.k.a. build plan). This build plan could be provided by the service developer who also creates the Service Template. The build plan can be adapted to the concrete environment of a particular service provider. Other management plans useful in various states of the whole lifecycle of a service could be specified as part of a Service Template. Similar to build plans such management plans can be adapted to the concrete environment of a particular service provider.

Thus, not only the structure of a service can be defined in an interoperable manner, but also its management plans. These Plans describe how instances of the specified service are created and managed. Defining a set of management plans for a service will significantly reduce the cost of hosting a service by providing reusable knowledge about best practices for managing each service. While the modeler of a service can include deep domain knowledge into a plan, the user of such a service can use a plan by simply “invoking” it. This hides the complexity of the underlying service behavior. This is very similar to the situation resulting in the specification of ITIL.

3.2.2 Portability of Service Templates

Standardizing Service Templates supports the portability of definitions of IT Services. Here, portability denotes the ability of one cloud provider to understand the structure and behavior of a Service Template created by another party, e.g. another cloud provider, enterprise IT department, or service developer.

Note that portability of a service does not imply portability of its encompassed components. Portability of a service means that its definition can be understood in an interoperable manner, i.e. the topology model and corresponding plans are understood by standard compliant vendors. Portability of the individual components themselves making up a particular service has to be ensured by other means – if it is important for the service.

3.2.3 Service Composition

Standardizing Service Templates facilitates composing a service from components even if those components are hosted by different providers, including the local IT department, or in different automation environments, often built with technology from different suppliers. For example, large organizations could use automation products from different suppliers for different data centers, e.g., because of geographic distribution of data centers or organizational independence of each location. A Service Template provides an abstraction that does not make assumptions about the hosting environments.

3.2.4 Relation to Virtual Images

A cloud provider can host a service based on virtualized middleware stacks. These middleware stacks might be represented by an image definition such as an OVF [OVF] package. If OVF is used, a node in a Service Template can correspond to a virtual system or a component (OVF's "product") running in a virtual system, as defined in an OVF package. If the OVF package defines a virtual system collection containing multiple virtual systems, a sub-tree of a Service Template could correspond to the OVF virtual system collection.

A Service Template provides a way to declare the association of Service Template elements to OVF package elements. Such an association expresses that the corresponding Service Template element can be instantiated by deploying the corresponding OVF package element. These associations are not limited to OVF packages. The associations could be to other package types or to external service interfaces. This flexibility allows a Service Template to be composed from various virtualization technologies, service interfaces, and proprietary technology.

3.3 Service Templates and Artifacts

An artifact represents the content needed to realize a deployment such as an executable (e.g. a script, an executable program, an image), a configuration file or data file, or something that might be needed so that another executable can run (e.g. a library). Artifacts can be of different types, for example EJBs or python scripts. The content of an artifact depends on its type. Typically, descriptive metadata will also be provided along with the artifact. This metadata might be needed to properly process the artifact, for example by describing the appropriate execution environment.

TOSCA distinguishes two kinds of artifacts: implementation artifacts and deployment artifacts. An implementation artifact represents the executable of an operation of a node type, and a deployment artifact represents the executable for materializing instances of a node. For example, a REST operation to store an image can have an implementation artifact that is a WAR file. The node type this REST operation is associated with can have the image itself as a deployment artifact.

The fundamental difference between implementation artifacts and deployment artifacts is twofold, namely

  1. the point in time when the artifact is deployed, and
  2. by what entity and to where the artifact is deployed.

The operations of a node type perform management actions on (instances of) the node type. The implementations of such operations can be provided as implementation artifacts. Thus, the implementation artifacts of the corresponding operations have to be deployed in the management environment before any management operation can be started. In other words, “a TOSCA supporting environment” (i.e. a so-called TOSCA container) MUST be able to process the set of implementation artifacts types needed to execute those management operations. One such management operation could be the instantiation of a node type.

The instantiation of a node type can require providing deployment artifacts in the target managed environment. For this purpose, a TOSCA container supports a set of types of deployment artifacts that it can process. A service template that contains (implementation or deployment) artifacts of non-supported types cannot be processed by the container (resulting in an error during import).

3.4 Requirements and Capabilities

TOSCA allows for expressing requirements and capabilities of components of a service. This can be done, for example, to express that one component depends on (requires) a feature provided by another component, or to express that a component has certain requirements against the hosting environment such as for the allocation of certain resources or the enablement of a specific mode of operation.

Requirements and capabilities are modeled by annotating Node Types with Requirement Definitions and Capability Definitions of certain types. Requirement Types and Capability Types are defined as reusable entities so that those definitions can be used in the context of several Node Types. For example, a Requirement Type “DatabaseConnectionRequirement” might be defined to describe the requirement of a client for a database connection. This Requirement Type can then be reused for all kinds of Node Types that represent, for example, application with the need for a database connection.

 

Figure 2: Requirements and Capabilities

 

Node Templates which have corresponding Node Types with Requirement Definitions or Capability Definitions will include representations of the respective Requirements and Capabilities with content specific to the respective Node Template. For example, while Requirement Types just represent Requirement metadata, the Requirement represented in a Node Template can provide concrete values for properties defined in the Requirement Type. In addition, Requirements and Capabilities of Node Templates in a Topology Template can optionally be connected via Relationship Templates to indicate that a specific requirement of one node is fulfilled by a specific capability provided by another node.

Requirements can be matched in two ways as briefly indicated above: (1) requirements of a Node Template can be matched by capabilities of another Node Template in the same Service Template by connecting the respective requirement-capability-pairs via Relationship Templates; (2) requirements of a Node Template can be matched by the general hosting environment (or the TOSCA container), for example by allocating needed resources for a Node Template during instantiation.

3.5 Composition of Service Templates

Service Templates can be based on and built on-top of other Service Templates based on the concept of Requirements and Capabilities introduced in the previous section. For example, a Service Template for a business application that is hosted on an application server tier might focus on defining the structure and manageability behavior of the application itself. The structure of the application server tier hosting the application can be provided in a separate Service Template built by another vendor specialized in deploying and managing application servers. This approach enables separation of concerns and re-use of common infrastructure templates.

Figure 3: Service Template Composition

From the point of view of a Service Template (e.g. the business application Service Template from the example above) that uses another Service Template, the other Service Template (e.g. the application server tier) “looks” like just a Node Template. During deployment, however, this Node Template can be substituted by the second Service Template if it exposes the same boundaries (i.e. properties, capabilities, etc.) as the Node Template. Thus, a substitution with any Service Template that has the same boundary definitions as a certain Node Template in one Service Template becomes possible, allowing for a flexible composition of different Service Templates. This concept also allows for providing substitutable alternatives in the form of Service Templates. For example, a Service Template for a single node application server tier and a Service Template for a clustered application server tier might exist, and the appropriate option can be selected per deployment.

3.6 Policies in TOSCA

Non-functional behavior or quality-of-services are defined in TOSCA by means of policies. A Policy can express such diverse things like monitoring behavior, payment conditions, scalability, or continuous availability, for example.

A Node Template can be associated with a set of Policies collectively expressing the non-functional behavior or quality-of-services that each instance of the Node Template will expose. Each Policy specifies the actual properties of the non-functional behavior, like the concrete payment information (payment period, currency, amount etc) about the individual instances of the Node Template.

These properties are defined by a Policy Type. Policy Types might be defined in hierarchies to properly reflect the structure of non-functional behavior or quality-of-services in particular domains. Furthermore, a Policy Type might be associated with a set of Node Types the non-functional behavior or quality-of-service it describes.

Policy Templates provide actual values of properties of the types defined by Policy Types. For example, a Policy Template for monthly payments for US customers will set the “payment period” property to “monthly” and the “currency” property to “US$”, leaving the “amount” property open. The “amount” property will be set when the corresponding Policy Template is used for a Policy within a Node Template. Thus, a Policy Template defines the invariant properties of a Policy, while the Policy sets the variant properties resulting from the actual usage of a Policy Template in a Node Template.

3.7 Archive Format for Cloud Applications

In order to support in a certain environment the execution and management of the lifecycle of a cloud application, all corresponding artifacts have to be available in that environment. This means that beside the service template of the cloud application, the deployment artifacts and implementation artifacts have to be available in that environment. To ease the task of ensuring the availability of all of these, this specification defines a corresponding archive format called CSAR (Cloud Service ARchive).

Figure 4: Structure of the CSAR

A CSAR is a container file, i.e. it contains multiple files of possibly different file types. These files are typically organized in several subdirectories, each of which contains related files (and possibly other subdirectories etc). The organization into subdirectories and their content is specific for a particular cloud application. CSARs are zip files, typically compressed.

Each CSAR MUST contain a subdirectory called TOSCA-Metadata. This subdirectory MUST contain a so-called TOSCA meta file. This file is named TOSCA and has the file extension .meta. It represents metadata of the other files in the CSAR. This metadata is given in the format of name/value pairs. These name/value pairs are organized in blocks. Each block provides metadata of a certain artifact of the CSAR. An empty line separates the blocks in the TOSCA meta file.

Figure 5: Structure of the TOSCA Meta File

The first block of the TOSCA meta file (Block_0 in Figure 5) provides metadata of the CSAR itself (e.g. its version, creator etc). Each other block begins with a name/value pair that points to an artifact within the CSAR by means of a pathname. The remaining name/value pairs in a block are the proper metadata of the pointed to artifact. For example, a corresponding name/value pair specifies the MIME-type of the artifact.

Figure 6: Providing Metadata for Artifacts

 

4      The TOSCA Definitions Document

All elements needed to define a TOSCA Service Template – such as Node Type definitions, Relationship Type definitions, etc. – as well as Service Templates themselves are provided in TOSCA Definitions documents. This section explains the overall structure of a TOSCA Definitions document, the extension mechanism, and import features. Later sections describe in detail Service Templates, Node Types, Node Type Implementations, Relationship Types, Relationship Type Implementations, Requirement Types, Capability Types, Artifact Types, Artifact Templates, Policy Types and Policy Templates.

4.1 XML Syntax

The following pseudo schema defines the XML syntax of a Definitions document:

01  <Definitions id="xs:ID"

02               name="xs:string"?

03               targetNamespace="xs:anyURI">

04   

05    <Extensions>

06      <Extension namespace="xs:anyURI"

07                 mustUnderstand="yes|no"?/> +  

08    </Extensions> ?

09   

10    <Import namespace="xs:anyURI"?

11            location="xs:anyURI"?

12            importType="xs:anyURI"/> *

13   

14    <Types>

15      <xs:schema .../> *

16    </Types> ?

17   

18    (

19      <ServiceTemplate> ... </ServiceTemplate>

20    |

21      <NodeType> ... </NodeType>

22    |

23      <NodeTypeImplementation> ... </NodeTypeImplementation>

24    |

25      <RelationshipType> ... </RelationshipType>

26    |

27      <RelationshipTypeImplementation> ... </RelationshipTypeImplementation>

28    |

29      <RequirementType> ... </RequirementType>

30    |

31      <CapabilityType> ... </CapabilityType>

32    |

33      <ArtifactType> ... </ArtifactType>

34    |

35      <ArtifactTemplate> ... </ArtifactTemplate>

36    |

37      <PolicyType> ... </PolicyType>

38    |

39      <PolicyTemplate> ... </PolicyTemplate>

40    ) +

41   

42  </Definitions>

4.2 Properties

The Definitions element has the following properties:

According to these rules, it is permissible to have an Import element without namespace and location attributes, and only containing an importType attribute. Such an Import element indicates that external definitions of the indicated type are in use that are not namespace-qualified, and makes no statement about where those definitions might be found.

A Definitions document MUST define or import all Node Types, Node Type Implementations, Relationship Types, Relationship Type Implementations, Requirement Type, Capability Types, Artifact Types, Policy Types, WSDL definitions, and XML Schema documents it uses. In order to support the use of definitions from namespaces spanning multiple documents, a Definitions document MAY include more than one import declaration for the same namespace and importType. Where a Definitions document has more than one import declaration for a given namespace and importType, each declaration MUST include a different location value. Import elements are conceptually unordered. A Definitions document MUST be rejected if the imported documents contain conflicting definitions of a component used by the importing Definitions document.

Documents (or namespaces) imported by an imported document (or namespace) are not transitively imported by a TOSCA compliant implementation. In particular, this means that if an external item is used by an element enclosed in the Definitions document, then a document (or namespace) that defines that item MUST be directly imported by the Definitions document. This requirement does not limit the ability of the imported document itself to import other documents or namespaces.

Note: The specification supports the use of any type system nested in the Types element. Nevertheless, only the support of xs:schema is REQUIRED from any compliant implementation.

A TOSCA Definitions document MUST define at least one of the elements ServiceTemplate, NodeType, NodeTypeImplementation, RelationshipType, RelationshipTypeImplementation, RequirementType, CapabilityType, ArtifactType, ArtifactTemplate, PolicyType, or PolicyTemplate, but it can define any number of those elements in an arbitrary order.

This technique supports a modular definition of Service Templates. For example, one Definitions document can contain only Node Type and Relationship Type definitions that can then be imported into another Definitions document that only defines a Service Template using those Node Types and Relationship Types. Similarly, Node Type Properties can be defined in separate XML Schema Definitions that are imported and referenced when defining a Node Type.

All TOSCA elements MAY use the documentation element to provide annnotation for users. The content could be a plain text, HTML, and so on. The documentation element is OPTIONAL and has the following syntax:

01  <documentation source="xs:anyURI"? xml:lang="xs:language"?>

02    ...

03  </documentation>

Example of use of a documentation element:

01  <Definitions id="MyDefinitions" name="My Definitions" ...>

02   

03    <documentation xml:lang="EN">

04      This is a simple example of the usage of the documentation

05      element nested under a Definitions element. It could be used,

06      for example, to describe the purpose of the Definitions document

07      or to give an overview of elements contained within the Definitions

08      document.

09    </documentation>

10   

11  </Definitions>

4.3 Example

The following Definitions document defines two Node Types, “Application” and “ApplicationServer”, as well as one Relationship Type “ApplicationHostedOnApplicationServer”. The properties definitions for the two Node Types are specified in a separate XML schema definition file which is imported into the Definitions document by means of the Import element.

01  <Definitions id="MyDefinitions" name="My Definitions"

02    targetNamespace="http://www.example.com/MyDefinitions"

03    xmlns:my="http://www.example.com/MyDefinitions">

04   

05    <Import importType="http://www.w3.org/2001/XMLSchema"

06      namespace="http://www.example.com/MyDefinitions">

07   

08    <NodeType name="Application">

09      <PropertiesDefinition element="my:ApplicationProperties"/>

10    </NodeType>

11   

12    <NodeType name="ApplicationServer">

13      <PropertiesDefinition element="my:ApplicationServerProperties"/>

14    </NodeType>

15   

16    <RelationshipType name="ApplicationHostedOnApplicationServer">

17      <ValidSource typeRef="my:Application"/>

18      <ValidTarget typeRef="my:ApplicationServer"/>

19    </RelationshipTemplate>

20   

21  </Definitions>

5      Service Templates

This chapter specifies how Service Templates are defined. A Service Template describes the structure of a cloud application by means of a Topology Template, and it defines the manageability behavior of the cloud application in the form of Plans.

Elements within a Service Template, such as Node Templates defined in the Topology Template, refer to other TOSCA element, such as Node Types that can be defined in the same Definitions document containing the Service Template, or that can be defined in separate, imported Definitions documents.

Service Templates can be defined for being directly used for the deployment and management of a cloud application, or they can be used for composition into larger Service Template (see section 3.5 for details).

5.1 XML Syntax

The following pseudo schema defines the XML syntax of a Service Template:

01  <ServiceTemplate id="xs:ID"

02                   name="xs:string"?

03                   targetNamespace="xs:anyURI"

04                   substitutableNodeType="xs:QName"?>

05   

06    <Tags>

07      <Tag name="xs:string" value="xs:string"/> +

08    </Tags> ?

09   

10    <BoundaryDefinitions>

11      <Properties>

12        XML fragment

13        <PropertyMappings>

14          <PropertyMapping serviceTemplatePropertyRef="xs:string"

15                           targetObjectRef="xs:IDREF"

16                           targetPropertyRef="xs:string"/> +

17          </PropertyMappings/> ?

18      </Properties> ?

19   

20      <PropertyConstraints>

21        <PropertyConstraint property="xs:string"

22                            constraintType="xs:anyURI"> +

23          constraint ?

24        </PropertyConstraint>

25      </PropertyConstraints> ?

26   

27      <Requirements>

28        <Requirement name="xs:string"? ref="xs:IDREF"/> +

29      </Requirements> ?

30   

31      <Capabilities>

32        <Capability name="xs:string"? ref="xs:IDREF"/> +

33      </Capabilities> ?

34   

35      <Policies>

36        <Policy name="xs:string"? policyType="xs:QName"

37                policyRef="xs:QName"?>

38          policy specific content ?

39        </Policy> +

40      </Policies> ?

41   

42      <Interfaces>

43        <Interface name="xs:NCName">

44          <Operation name="xs:NCName">

45            (

46              <NodeOperation nodeRef="xs:IDREF"

47                             interfaceName="xs:anyURI"

48                             operationName="xs:NCName"/>

49            |

50              <RelationshipOperation relationshipRef="xs:IDREF"

51                                     interfaceName="xs:anyURI"

52                                     operationName="xs:NCName"/>

53            |

54              <Plan planRef="xs:IDREF"/>

55            )

56          </Operation> +

57        </Interface> +

58      </Interfaces> ?

59   

60    </BoundaryDefinitions> ?

61   

62    <TopologyTemplate>

63      (

64        <NodeTemplate id="xs:ID" name="xs:string"? type="xs:QName"

65                      minInstances="xs:integer"?

66                      maxInstances="xs:integer | xs:string"?>

67          <Properties>

68            XML fragment

69          </Properties> ?

70   

71          <PropertyConstraints>

72            <PropertyConstraint property="xs:string"

73                                constraintType="xs:anyURI">

74              constraint ?

75            </PropertyConstraint> +

76          </PropertyConstraints> ?

77   

78          <Requirements>

79            <Requirement id="xs:ID" name="xs:string" type="xs:QName"> +

80              <Properties>

81                XML fragment

82              <Properties> ?

83              <PropertyConstraints>

84                <PropertyConstraint property="xs:string"

85                                    constraintType="xs:anyURI"> +

86                  constraint ?

87                </PropertyConstraint>

88              </PropertyConstraints> ?

89            </Requirement>

90          </Requirements> ?

91   

92          <Capabilities>

93            <Capability id="xs:ID" name="xs:string" type="xs:QName"> +

94              <Properties>

95                XML fragment

96              <Properties> ?

97              <PropertyConstraints>

98                <PropertyConstraint property="xs:string"

99                                    constraintType="xs:anyURI">

100                constraint ?

101              </PropertyConstraint> +

102            </PropertyConstraints> ?

103          </Capability>

104        </Capabilities> ?

105 

106        <Policies>

107          <Policy name="xs:string"? policyType="xs:QName"

108                  policyRef="xs:QName"?>

109            policy specific content ?

110          </Policy> +

111        </Policies> ?

112 

113        <DeploymentArtifacts>

114          <DeploymentArtifact name="xs:string" artifactType="xs:QName"

115                              artifactRef="xs:QName"?>

116             artifact specific content ?

117          </DeploymentArtifact> +

118        </DeploymentArtifacts> ?

119      </NodeTemplate>

120    |

121      <RelationshipTemplate id="xs:ID" name="xs:string"?

122                            type="xs:QName">

123        <Properties>

124          XML fragment

125        </Properties> ?

126 

127        <PropertyConstraints>

128          <PropertyConstraint property="xs:string"

129                              constraintType="xs:anyURI">

130            constraint ?

131          </PropertyConstraint> +

132        </PropertyConstraints> ?

133 

134        <SourceElement ref="xs:IDREF"/>

135        <TargetElement ref="xs:IDREF"/>

136 

137        <RelationshipConstraints>

138          <RelationshipConstraint constraintType="xs:anyURI">

139            constraint ?

140          </RelationshipConstraint> +

141        </RelationshipConstraints> ?

142 

143      </RelationshipTemplate>

144    ) +

145  </TopologyTemplate>

146 

147  <Plans>

148    <Plan id="xs:ID"

149          name="xs:string"?

150          planType="xs:anyURI"

151          planLanguage="xs:anyURI">

152 

153       <Precondition expressionLanguage="xs:anyURI">

154         condition

155       </Precondition> ?

156 

157       <InputParameters>

158         <InputParameter name="xs:string" type="xs:string"

159                         required="yes|no"?/> +

160       </InputParameters> ?

161 

162       <OutputParameters>

163         <OutputParameter name="xs:string" type="xs:string"

164                          required="yes|no"?/> +

165       </OutputParameters> ?

166

167      (

168        <PlanModel>

169          actual plan

170        </PlanModel>

171       |

172        <PlanModelReference reference="xs:anyURI"/>

173      )

174 

175    </Plan> +

176  </Plans> ?

177 

178</ServiceTemplate>

5.2 Properties

The ServiceTemplate element has the following properties:

5.3 Example

The following Service Template defines a Topology Template containing two Node Templates called “MyApplication” and “MyAppServer”. These Node Templates have the node types “Application” and “ApplicationServer”. The Node Template “MyApplication” is instantiated exactly once. Two of its Node Type Properties are initialized by a corresponding Properties element. The Node Template “MyAppServer” can be instantiated as many times as needed. The “MyApplication” Node Template is connected with the “MyAppServer” Node Template via the Relationship Template named “MyHostedRelationship”; the behavior and semantics of the Relationship Template is defined in the Relationship Type “HostedOn”, saying that “MyApplication” is hosted on “MyAppServer”. The Service Template further defines a Plan “UpdateApplication” for performing an update of the “MyApplication” application hosted on the application server. This Plan refers to a BPMN 2.0 process definition contained in a separate file.

01  <ServiceTemplate id="MyService"

02                   name="My Service">

03   

04    <TopologyTemplate>

05   

06      <NodeTemplate id="MyApplication"

07                    name="My Application"

08                    type="my:Application">

09        <Properties>

10          <ApplicationProperties> 

11            <Owner>Frank</Owner>

12            <InstanceName>Thomas’ favorite application</InstanceName>

13          </ApplicationProperties>

14         </Properties>

15      </NodeTemplate>

16   

17      <NodeTemplate id="MyAppServer"

18                    name="My Application Server"

19                    type="my:ApplicationServer"

20                    minInstances="0"

21                    maxInstances="unbounded"/>

22   

23      <RelationshipTemplate id="MyDeploymentRelationship"

24                            type="my:deployedOn">

25        <SourceElement ref="MyApplication"/>

26        <TargetElement ref="MyAppServer"/>

27      </RelationshipTemplate>

28   

29    </TopologyTemplate>

30   

31    <Plans>

32      <Plan id="UpdateApplication"

33          planType="http://www.example.com/UpdatePlan"

34          planLanguage="http://www.omg.org/spec/BPMN/20100524/MODEL">

35        <PlanModelReference reference="plans:UpdateApp"/>

36      </Plan>

37    </Plans>

38   

39  </ServiceTemplate>

6      Node Types

This chapter specifies how Node Types are defined. A Node Type is a reusable entity that defines the type of one or more Node Templates. As such, a Node Type defines the structure of observable properties via a Properties Definition, i.e. the names, data types and allowed values the properties defined in Node Templates using a Node Type or instances of such Node Templates can have.

A Node Type can inherit properties from another Node Type by means of the DerivedFrom element. Node Types might be declared as abstract, meaning that they cannot be instantiated. The purpose of such abstract Node Types is to provide common properties and behavior for re-use in specialized, derived Node Types. Node Types might also be declared as final, meaning that they cannot be derived by other Node Types.

A Node Type can declare to expose certain requirements and capabilities (see section 3.4) by means of RequirementDefinition elements or CapabilityDefinition elements, respectively.

The functions that can be performed on (an instance of) a corresponding Node Template are defined by the Interfaces of the Node Type. Finally, management Policies are defined for a Node Type.

6.1 XML Syntax

The following pseudo schema defines the XML syntax of Node Types:

04  <NodeType name="xs:NCName" targetNamespace="xs:anyURI"?

05            abstract="yes|no"? final="yes|no"?>

06   

07    <Tags>

08      <Tag name="xs:string" value="xs:string"/> +

09    </Tags> ?

10   

11    <DerivedFrom typeRef="xs:QName"/> ?

12   

13    <PropertiesDefinition element="xs:QName"? type="xs:QName"?/> ?

14   

15    <RequirementDefinitions>

16      <RequirementDefinition name="xs:string"

17                             requirementType="xs:QName"

18                             lowerBound="xs:integer"?

19                             upperBound="xs:integer | xs:string"?>

20        <Constraints>

21          <Constraint constraintType="xs:anyURI">

22            constraint type specific content

23          </Constraint> +

24        </Constraints> ?

25      </RequirementDefinition> +

26    </RequirementDefinitions> ?

27   

28    <CapabilityDefinitions>

29      <CapabilityDefinition name="xs:string"

30                            capabilityType="xs:QName"

31                            lowerBound="xs:integer"?

32                            upperBound="xs:integer | xs:string"?>

33        <Constraints>

34          <Constraint constraintType="xs:anyURI">

35            constraint type specific content

36          </Constraint> +

37        </Constraints> ?

38      </CapabilityDefinition> +

39    </CapabilityDefinitions>

40   

41    <InstanceStates>

42      <InstanceState state="xs:anyURI"> +

43    </InstanceStates> ?

44   

45    <Interfaces>

46      <Interface name="xs:NCName | xs:anyURI">

47        <Operation name="xs:NCName">

48          <InputParameters>

49            <InputParameter name="xs:string" type="xs:string"

50                            required="yes|no"?/> +

51          </InputParameters> ?

52          <OutputParameters>

53            <OutputParameter name="xs:string" type="xs:string"

54                             required="yes|no"?/> +

55          </OutputParameters> ?

56        </Operation> +

57      </Interface> +

58    </Interfaces> ?

59   

60  </NodeType>

6.2 Properties

The NodeType element has the following properties:

6.3 Derivation Rules

The following rules on combining definitions based on DerivedFrom apply:

6.4 Example

The following example defines the Node Type “Project”. It is defined in a Definitions document “MyDefinitions” within the target namespace “http://www.example.com/sample”. Thus, by importing the corresponding namespace in another Definitions document, the Project Node Type is available for use in the other document.

01  <Definitions id="MyDefinitions" name="My Definitions"

02               targetNamespace="http://www.example.com/sample">

03   

04    <NodeType name="Project">

05   

06      <documentation xml:lang="EN">

07        A reusable definition of a node type supporting

08        the creation of new projects.

09      </documentation>

10   

11      <PropertiesDefinition element="ProjectProperties"/>

12   

13      <InstanceStates>

14        <InstanceState state="www.example.com/active"/>

15        <InstanceState state="www.example.com/onHold"/>

16      </InstanceStates>

17   

18      <Interfaces>

19        <Interface name="ProjectInterface">

20          <Operation name="CreateProject">

21            <InputParameters>

22              <InputParamterInputParameter name="ProjectName"

23                             type="xs:string"/>

24              <InputParamterInputParameter name="Owner"

25                             type="xs:string"/>

26              <InputParamterInputParameter name="AccountID"

27                             type="xs:string"/>

28            </InputParameters>

29          </Operation>

30        </Interface>

31      </Interfaces>

32    </NodeType>

33   

34  </Definitions>

The Node Type “Project” has three Node Type Properties defined as an XML elelment in the Types element definition of the Service Template document: Owner, ProjectName and AccountID which are all of type “xs:string”. An instance of the Node Type “Project” could be “active” (more precise in state www.example.com/active) or “on hold” (more precise in state “www.example.com/onHold”). A single Interface is defined for this Node Type, and this Interface is defined by an Operation, i.e. its actual implementation is defined by the definition of the Operation. The Operation has the name CreateProject and three Input Parameters (exploiting the default value “yes” of the attribute required of the InputParameter element). The names of these Input Parameters are ProjectName, Owner and AccountID, all of type “xs:string”.

7      Node Type Implementations

This chapter specifies how Node Type Implementations are defined. A Node Type Implementation represents the executable code that implements a specific Node Type. It provides a collection of executables implementing the interface operations of a Node Type (aka implementation artifacts) and the executables needed to materialize instances of Node Templates referring to a particular Node Type (aka deployment artifacts). The respective executables are defined as separate Artifact Templates and are referenced from the implementation artifacts and deployment artifacts of a Node Type Implementation.

While Artifact Templates provide invariant information about an artifact – i.e. information that is context independent like the file name of the artifact – implementation or deployment artifacts can provide variant (or context specific) information, such as authentication data or deployment paths for a specific environment.

Node Type Implementations can specify hints for a TOSCA container that enable proper selection of an implementation that fits into a particular environment by means of Required Container Features definitions.

7.1 XML Syntax

The following pseudo schema defines the XML syntax of Node Type Implementations:

61  <NodeTypeImplementation name="xs:NCName" targetNamespace="xs:anyURI"?

62                          nodeType="xs:QName"

63                          abstract="yes|no"?

64                          final="yes|no"?>

65    

66    <Tags>

67      <Tag name="xs:string" value="xs:string"/> +

68    </Tags> ?

69   

70    <DerivedFrom nodeTypeImplementationRef="xs:QName"/> ?

71   

72    <RequiredContainerFeatures>

73      <RequiredContainerFeature feature="xs:anyURI"/> +

74    </RequiredContainerFeatures> ?

75   

76    <ImplementationArtifacts>

77      <ImplementationArtifact interfaceName="xs:NCName | xs:anyURI"?

78                              operationName="xs:NCName"?

79                              artifactType="xs:QName"

80                              artifactRef="xs:QName"?>

81          artifact specific content ?

82      <ImplementationArtifact> +

83    </ImplementationArtifacts> ?

84   

85    <DeploymentArtifacts>

86      <DeploymentArtifact name="xs:string" artifactType="xs:QName"

87                          artifactRef="xs:QName"?>

88          artifact specific content ?

89      <DeploymentArtifact> +

90    </DeploymentArtifacts> ?

91   

92  </NodeTypeImplementation>

7.2 Properties

The NodeTypeImplementation element has the following properties:

7.3 Derivation Rules

The following rules on combining definitions based on DerivedFrom apply:

7.4 Example

The following example defines the Node Type Implementation “MyDBMSImplementation”. This is an implementation of a Node Type “DBMS”.

01  <Definitions id="MyImpls" name="My Implementations"

02    targetNamespace="http://www.example.com/SampleImplementations"

03    xmlns:bn="http://www.example.com/BaseNodeTypes"

04    xmlns:ba="http://www.example.com/BaseArtifactTypes"

05    xmlns:sa="http://www.example.com/SampleArtifacts">

06   

07    <Import importType="http://docs.oasis-open.org/tosca/ns/2011/12"

08            namespace="http://www.example.com/BaseArtifactTypes"/>

09   

10    <Import importType="http://docs.oasis-open.org/tosca/ns/2011/12"

11            namespace="http://www.example.com/BaseNodeTypes"/>

12   

13    <Import importType="http://docs.oasis-open.org/tosca/ns/2011/12"

14            namespace="http://www.example.com/SampleArtifacts"/>

15   

16    <NodeTypeImplementation name="MyDBMSImplementation"

17                            nodeType="bn:DBMS">

18   

19      <ImplementationArtifacts>

20        <ImplementationArtifact interfaceName="MgmtInterface"

21                                artifactType="ba:WARFile"

22                                artifactRef="sa:MyMgmtWebApp">

23        </ImplementationArtifact>

24      </ImplementationArtifacts>

25   

26      <DeploymentArtifacts>

27        <DeploymentArtifact name="MyDBMS"

28                            artifactType="ba:ZipFile"

29                            artifactRef="sa:MyInstallable">

30        </DeploymentArtifact>

31      </DeploymentArtifacts>

32   

33    </NodeTypeImplementation>

34   

35  </Definitions>

The Node Type Implementation contains the “MyDBMSManagement” implementation artifact, which is an artifact for the “MgmtInterface” Interface that has been defined for the “DBMS” base Node Type. The type of this artifact is a “WARFile” that has been defined as base Artifact Type. The implementation artifact refers to the “MyMgmtWebApp” Artifact Template that has been defined before.

The Node Type Implementation further contains the “MyDBMS” deployment artifact, which is a software installable used for instantiating the “DBMS” Node Type. This software installable is a “ZipFile” that has been separately defined as the “MyInstallable” Artifact Template before.

8      Relationship Types

This chapter specifies how Relationship Types are defined. A Relationship Type is a reusable entity that defines the type of one or more Relationship Templates between Node Templates. As such, a Relationship Type can define the structure of observable properties via a Properties Definition, i.e. the names, data types and allowed values the properties defined in Relationship Templates using a Relationship Type or instances of such Relationship Templates can have.

The operations that can be performed on (an instance of) a corresponding Relationship Template are defined by the Interfaces of the Relationship Type. Furthermore, a Relationship Type defines the potential states an instance of it might reveal at runtime.

A Relationship Type can inherit the definitions defined in another Relationship Type by means of the DerivedFrom element. Relationship Types might be declared as abstract, meaning that they cannot be instantiated. The purpose of such abstract Relationship Types is to provide common properties and behavior for re-use in specialized, derived Relationship Types. Relationship Types might also be declared as final, meaning that they cannot be derived by other Relationship Types.

8.1 XML Syntax

The following pseudo schema defines the XML syntax of Relationship Types:

93  <RelationshipType name="xs:NCName"

94                    targetNamespace="xs:anyURI"?

95                    abstract="yes|no"?

96                    final="yes|no"?> +

97   

98    <Tags>

99      <Tag name="xs:string" value="xs:string"/> +

100  </Tags> ?

101 

102  <DerivedFrom typeRef="xs:QName"/> ?

103 

104  <PropertiesDefinition element="xs:QName"? type="xs:QName"?/> ?

105 

106  <InstanceStates>

107    <InstanceState state="xs:anyURI"> +

108  </InstanceStates> ?

109

110  <SourceInterfaces>

111    <Interface name="xs:NCName | xs:anyURI">

112      ...

113    </Interface> +

114  </SourceInterfaces> ?

115 

116  <TargetInterfaces>

117    <Interface name="xs:NCName | xs:anyURI">

118      ...

119    </Interface> +

120  </TargetInterfaces> ?

121 

122  <ValidSource typeRef="xs:QName"/> ?

123

124  <ValidTarget typeRef="xs:QName"/> ?

125 

126</RelationshipType>

8.2 Properties

The RelationshipType element has the following properties:

8.3 Derivation Rules

The following rules on combining definitions based on DerivedFrom apply:

8.4 Example

The following example defines the Relationship Type “processDeployedOn”. The meaning of this Relationship Type is that “a process is deployed on a hosting environment”. When the source of an instance of a Relationship Template refering to this Relationship Type is deleted, its target is automatically deleted as well. The Relationship Type has Relationship Type Properties defined in the Types section of the same Definitions document as the “ProcessDeployedOnProperties” element. The states an instance of this Relationship Type can be in are also listed.

01  <RelationshipType name="processDeployedOn">

02   

03    <RelationshipTypeProperties  <PropertiesDefinition element="ProcessDeployedOnProperties"/>

04   

05    <InstanceStates>

06      <InstanceState state="www.example.com/successfullyDeployed"/>

07      <InstanceState state="www.example.com/failed"/>

08    </InstanceStates>

09   

10  </RelationshipType>

9      Relationship Type Implementations

This chapter specifies how Relationship Type Implementations are defined. A Relationship Type Implementation represents the runnable code that implements a specific Relationship Type. It provides a collection of executables implementing the interface operations of a Relationship Type (aka implementation artifacts). The particular executables are defined as separate Artifact Templates and are referenced from the implementation artifacts of a Relationship Type Implementation.

While Artifact Templates provide invariant information about an artifact – i.e. information that is context independent like the file name of the artifact – implementation artifacts can provide variant (or context specific) information, e.g. authentication data for a specific environment.

Relationship Type Implementations can specify hints for a TOSCA container that enable proper selection of an implementation that fits into a particular environment by means of Required Container Features definitions.

Note that there MAY be Relationship Types that do not define any interface operations, i.e. that also do not require any implementation artifacts. In such cases, no Relationship Type Implementation is needed but the respective Relationship Types can be used by a TOSCA implementation as is.

9.1 XML Syntax

The following pseudo schema defines the XML syntax of Relationship Type Implementations:

127<RelationshipTypeImplementation name="xs:NCName"

128                                targetNamespace="xs:anyURI"?

129                                relationshipType="xs:QName"

130                                abstract="yes|no"?

131                                final="yes|no"?>

132 

133  <Tags>

134    <Tag name="xs:string" value="xs:string"/> +

135  </Tags> ?

136 

137  <DerivedFrom relationshipTypeImplementationRef="xs:QName"/> ?

138 

139  <RequiredContainerFeatures>

140    <RequiredContainerFeature feature="xs:anyURI"/> +

141  </RequiredContainerFeatures> ?

142 

143  <ImplementationArtifacts>

144   <ImplementationArtifact interfaceName="xs:NCName | xs:anyURI"?

145                            operationName="xs:NCName"?

146                            artifactType="xs:QName"

147                            artifactRef="xs:QName"?>

148        artifact specific content ?

149    <ImplementationArtifact> +

150  </ImplementationArtifacts> ?

151 

152</RelationshipTypeImplementation>

9.2 Properties

The RelationshipTypeImplementation element has the following properties:

9.3 Derivation Rules

The following rules on combining definitions based on DerivedFrom apply:

9.4 Example

The following example defines the NodeRelationship Type Implementation “MyDBMSImplementation”.MyDBConnectImplementation”. This is an implementation of a NodeRelationship Type “DBMSDBConnection”.

01  <Definitions id="MyImpls" name="My Implementations"

02    targetNamespace="http://www.example.com/SampleImplementations"

03    xmlns:bn="http://www.example.com/BaseRelationshipTypes"

04    xmlns:ba="http://www.example.com/BaseArtifactTypes"

05    xmlns:sa="http://www.example.com/SampleArtifacts">

06   

07    <Import importType="http://docs.oasis-open.org/tosca/ns/2011/12"

08            namespace="http://www.example.com/BaseArtifactTypes"/>

09   

10    <Import importType="http://docs.oasis-open.org/tosca/ns/2011/12"

11            namespace="http://www.example.com/BaseRelationshipTypes"/>

12   

13    <Import importType="http://docs.oasis-open.org/tosca/ns/2011/12"

14            namespace="http://www.example.com/SampleArtifacts"/>

15   

16    <RelationshipTypeImplementation name="MyDBConnectImplementation"

17                                    relationshipType="bn:DBConnection">

18   

19       <ImplementationArtifacts>

20         <ImplementationArtifact interfaceName="ConnectionInterface"

21                                 operationName="connectTo"

22                                 artifactType="ba:ScriptArtifact"

23                                 artifactRef="sa:MyConnectScript">

24         <</ImplementationArtifact>

25       </ImplementationArtifacts>

26   

27    </RelationshipTypeImplementation>

28   

29  </Definitions>

The Relationship Type Implementation contains the “MyDBConnectionImpl” implementation artifact, which is an artifact for the “ConnectionInterface” interface that has been defined for the “DBConnection” base Relationship Type. The type of this artifact is a “ScriptArtifact” that has been defined as base Artifact Type. The implementation artifact refers to the “MyConnectScript” Artifact Template that has been defined before.

10 Requirement Types

This chapter specifies how Requirement Types are defined. A Requirement Type is a reusable entity that describes a kind of requirement that a Node Type can declare to expose. For example, a Requirement Type for a database connection can be defined and various Node Types (e.g. a Node Type for an application) can declare to expose (or “to have”) a requirement for a database connection.

A Requirement Type defines the structure of observable properties via a Properties Definition, i.e. the names, data types and allowed values the properties defined in Requirements of Node Templates of a Node Type can have in cases where the Node Type defines a requirement of the respective Requirement Type.

A Requirement Type can inherit properties and semantics from another Requirement Type by means of the DerivedFrom element. Requirement Types might be declared as abstract, meaning that they cannot be instantiated. The purpose of such abstract Requirement Types is to provide common properties for re-use in specialized, derived Requirement Types. Requirement Types might also be declared as final, meaning that they cannot be derived by other Requirement Types.

10.1 XML Syntax

The following pseudo schema defines the XML syntax of Requirement Types:

153<RequirementType name="xs:NCName"

154                 targetNamespace="xs:anyURI"?

155                 abstract="yes|no"?

156                 final="yes|no"?

157                 requiredCapabilityType="xs:QName"?>

158

159  <Tags>

160    <Tag name="xs:string" value="xs:string"/> +

161  </Tags> ?

162 

163  <DerivedFrom typeRef="xs:QName"/> ?

164 

165  <PropertiesDefinition element="xs:QName"? type="xs:QName"?/> ?

166   

167</RequirementType>

10.2 Properties

The RequirementType element has the following properties:

10.3 Derivation Rules

The following rules on combining definitions based on DerivedFrom apply:

10.4 Example

The following example defines the Requirement Type “DatabaseClientEndpoint” that expresses the requirement of a client for a database connection. It is defined in a Definitions document “MyRequirements” within the target namespace “http://www.example.com/SampleRequirements”. Thus, by importing the corresponding namespace into another Definitions document, the “DatabaseClientEndpoint” Requirement Type is available for use in the other document.

01  <Definitions id="MyRequirements" name="My Requirements"

02    targetNamespace="http://www.example.com/SampleRequirements"

03    xmlns:br="http://www.example.com/BaseRequirementTypes"

04    xmlns:mrp="http://www.example.com/SampleRequirementProperties>">

05   

06    <Import importType="http://docs.oasis-open.org/tosca/ns/2011/12"

07      namespace="http://www.example.com/BaseRequirementTypes"/>

08   

09    <Import importType="http://www.w3.org/2001/XMLSchema"

10      namespace="http://www.example.com/SampleRequirementProperties"/>

11   

12    <RequirementType name="DatabaseClientEndpoint">

13      <DerivedFrom typeRef="br:ClientEndpoint"/>

14      <PropertiesDefinition

15        element="mrp:DatabaseClientEndpointProperties"/>

16    </RequirementType>

17   

18  </Definitions>

The Requirement Type “DatabaseClientEndpoint” defined in the example above is derived from another generic “ClientEndpoint” Requirement Type defined in a separate file by means of the DerivedFrom element. The definitions in that separate Definitions file are imported by means of the first Import element and the namespace of those imported definitions is assigned the prefix “br” in the current file.

The “DatabaseClientEndpoint” Requirement Type defines a set of properties through an XML schema element definition “DatabaseClientEndpointProperties”. For example, those properties might include the definition of a port number to be used for client connections. The XML schema definition is stored in a separate XSD file that is imported by means of the second Import element. The namespace of the XML schema definitions is assigned the prefix “mrp” in the current file.

11 Capability Types

This chapter specifies how Capability Types are defined. A Capability Type is a reusable entity that describes a kind of capability that a Node Type can declare to expose. For example, a Capability Type for a database server endpoint can be defined and various Node Types (e.g. a Node Type for a database) can declare to expose (or to “provide”) the capability of serving as a database server endpoint.

A Capability Type defines the structure of observable properties via a Properties Definition, i.e. the names, data types and allowed values the properties defined in Capabilities of Node Templates of a Node Type can have in cases where the Node Type defines a capability of the respective Capability Type.

A Capability Type can inherit properties and semantics from another Capability Type by means of the DerivedFrom element. Capability Types might be declared as abstract, meaning that they cannot be instantiated. The purpose of such abstract Capability Types is to provide common properties for re-use in specialized, derived Capability Types. Capability Types might also be declared as final, meaning that they cannot be derived by other Capability Types.

11.1 XML Syntax

The following pseudo schema defines the XML syntax of Capability Types:

168<CapabilityType name="xs:NCName"

169                targetNamespace="xs:anyURI"?

170                abstract="yes|no"?

171                final="yes|no"?>

172

173  <Tags>

174    <Tag name="xs:string" value="xs:string"/> +

175  </Tags> ?

176 

177  <DerivedFrom typeRef="xs:QName"/> ?

178 

179  <PropertiesDefinition element="xs:QName"? type="xs:QName"?/> ?

180 

181</CapabilityType>

11.2 Properties

The CapabilityType element has the following properties:

11.3 Derivation Rules

The following rules on combining definitions based on DerivedFrom apply:

11.4 Example

The following example defines the Capability Type “DatabaseServerEndpoint” that expresses the capability of a component to serve database connections. It is defined in a Definitions document “MyCapabilities” within the target namespace “http://www.example.com/SampleCapabilities”. Thus, by importing the corresponding namespace into another Definitions document, the “DatabaseServerEndpoint” Capability Type is available for use in the other document.

01  <Definitions id="MyCapabilities" name="My Capabilities"

02    targetNamespace="http://www.example.com/SampleCapabilities"

03    xmlns:bc="http://www.example.com/BaseCapabilityTypes"

04    xmlns:mcp="http://www.example.com/SampleCapabilityProperties>">

05   

06    <Import importType="http://docs.oasis-open.org/tosca/ns/2011/12"

07            namespace="http://www.example.com/BaseCapabilityTypes"/>

08   

09    <Import importType="http://www.w3.org/2001/XMLSchema"

10            namespace="http://www.example.com/SampleCapabilityProperties"/>

11   

12    <CapabilityType name="DatabaseServerEndpoint">

13      <DerivedFrom typeRef="bc:ServerEndpoint"/>

14      <PropertiesDefinition

15        element="mcp:DatabaseServerEndpointProperties"/>

16    </CapabilityType>

17   

18  </Definitions>

The Capability Type “DatabaseServerEndpoint” defined in the example above is derived from another generic “ServerEndpoint” Capability Type defined in a separate file by means of the DerivedFrom element. The definitions in that separate Definitions file are imported by means of the first Import element and the namespace of those imported definitions is assigned the prefix “bc” in the current file.

The “DatabaseServerEndpoint” Capability Type defines a set of properties through an XML schema element definition “DatabaseServerEndpointProperties”. For example, those properties might include the definition of a port number where the server listens for client connections, or credentials to be used by clients. The XML schema definition is stored in a separate XSD file that is imported by means of the second Import element. The namespace of the XML schema definitions is assigned the prefix “mcp” in the current file.

12 Artifact Types

This chapter specifies how Artifact Types are defined. An Artifact Type is a reusable entity that defines the type of one or more Artifact Templates which in turn serve as deployment artifacts for Node Templates or implementation artifacts for Node Type and Relationship Type interface operations. For example, an Artifact Type “WAR File” might be defined for describing web application archive files. Based on this Artifact Type, one or more Artifact Templates representing concrete WAR files can be defined and referenced as deployment or implementation artifacts.

An Artifact Type can define the structure of observable properties via a Properties Definition, i.e. the names, data types and allowed values the properties defined in Artifact Templates using an Artifact Type or instances of such Artifact Templates can have. Note that properties defined by an Artifact Type are assummed to be invariant across the contexts in which corresponding artifacts are used – as opposed to properties that can vary depending on the context. As an example of such an invariant property, an Artifact Type for a WAR file could define a “signature” property that can hold a hash for validating the actual artifact proper. In contrast, the path where the web application contained in the WAR file gets deployed can vary for each place where the WAR file is used.

An Artifact Type can inherit definitions and semantics from another Artifact Type by means of the DerivedFrom element. Artifact Types can be declared as abstract, meaning that they cannot be instantiated. The purpose of such abstract Artifact Types is to provide common properties for re-use in specialized, derived Artifact Types. Artifact Types can also be declared as final, meaning that they cannot be derived by other Artifact Types.

12.1 XML Syntax

The following pseudo schema defines the XML syntax of Artifact Types:

182<ArtifactType name="xs:NCName"

183              targetNamespace="xs:anyURI"?

184              abstract="yes|no"?

185              final="yes|no"?>

186

187  <Tags>

188    <Tag name="xs:string" value="xs:string"/> +

189  </Tags> ?

190 

191  <DerivedFrom typeRef="xs:QName"/> ?

192 

193  <PropertiesDefinition element="xs:QName"? type="xs:QName"?/> ?

194   

195</ArtifactType>

12.2 Properties

The ArtifactType element has the following properties:

12.3 Derivation Rules

The following rules on combining definitions based on DerivedFrom apply:

12.4 Example

The following example defines the Artifact Type “RPMPackage” that can be used for describing RPM packages as deployable artifacts on various Linux distributions. It is defined in a Definitions document “MyArtifacts” within the target namespace “http://www.example.com/SampleArtifacts”. Thus, by importing the corresponding namespace into another Definitions document, the “RPMPackage” Artifact Type is available for use in the other document.

01  <Definitions id="MyArtifacts" name="My Artifacts"

02    targetNamespace="http://www.example.com/SampleArtifacts"

03    xmlns:ba="http://www.example.com/BaseArtifactTypes"

04    xmlns:map="http://www.example.com/SampleArtifactProperties>

05   

06    <Import importType="http://docs.oasis-open.org/tosca/ns/2011/12"

07            namespace="http://www.example.com/BaseArtifactTypes"/>

08   

09    <Import importType="http://www.w3.org/2001/XMLSchema"

10            namespace="http://www.example.com/SampleArtifactProperties"/>

11   

12    <ArtifactType name="RPMPackage">

13      <DerivedFrom typeRef="ba:OSPackage"/>

14      <PropertiesDefinition element="map:RPMPackageProperties"/>

15    </ArtifactType>

16   

17  </Definitions>

The Artifact Type “RPMPackage” defined in the example above is derived from another generic “OSPackage” Artifact Type defined in a separate file by means of the DerivedFrom element. The definitions in that separate Definitions file are imported by means of the first Import element and the namespace of those imported definitions is assigned the prefix “ba” in the current file.

The “RPMPackage” Artifact Type defines a set of properties through an XML schema element definition “RPMPackageProperties”. For example, those properties might include the definition of the name or names of one or more RPM packages. The XML schema definition is stored in a separate XSD file that is imported by means of the second Import element. The namespace of the XML schema definitions is assigned the prefix “map” in the current file.

13 Artifact Templates

This chapter specifies how Artifact Templates are defined. An Artifact Template represents an artifact that can be referenced from other objects in a Service Template as a deployment artifact or implementation artifact. For example, from Node Types or Node Templates, an Artifact Template for some software installable could be referenced as a deployment artifact for materializing a specific software component. As another example, from within interface definitions of Node Types or Relationship Types, an Artifact Template for a WAR file could be referenced as implementation artifact for a REST operation.

An Artifact Template refers to a specific Artifact Type that defines the structure of observable properties (metadata) or the artifact. The Artifact Template then typically defines values for those properties inside the Properties element. Note that properties defined by an Artifact Type are asumed to be invariant across the contexts in which corresponding artifacts are used – as opposed to properties that can vary depending on the context.

Furthermore, an Artifact Template typically provides one or more references to the actual artifact itself that can be contained as a file in the CSAR (see section 3.7 and section 14) containing the overall Service Template or that can be available at a remote location such as an FTP server.

13.1 XML Syntax

The following pseudo schema defines the XML syntax of Artifact Templates:

196<ArtifactTemplate id="xs:ID" name="xs:string"? type="xs:QName">

197 

198  <Properties>

199    XML fragment

200  </Properties> ?

201 

202  <PropertyConstraints>

203    <PropertyConstraint property="xs:string"

204                        constraintType="xs:anyURI"> +

205      constraint ?

206    </PropertyConstraint>

207  </PropertyConstraints> ?

208

209  <ArifactReferences>

210    <ArtifactReference reference="xs:anyURI">

211      (

212       <Include pattern="xs:string"/>

213      |

214       <Exclude pattern="xs:string"/>

215      )*

216    </ArtifactReference> +

217  </ArtifactReferences> ?

218

219</ArtifactTemplate>

13.2 Properties

The ArtifactTemplate element has the following properties:

13.3 Example

The following example defines the Artifact Template “MyInstallable” that points to a zip file containing some software installable. It is defined in a Definitions document “MyArtifacts” within the target namespace “http://www.example.com/SampleArtifacts”. The Artifact Template can be used in the same document, for example as a deployment artifact for some Node Template representing a software component, or it can be used in other Definitions documents by importing the corresponding namespace into another document.

01  <Definitions id="MyArtifacts" name="My Artifacts"

02    targetNamespace="http://www.example.com/SampleArtifacts"

03    xmlns:ba="http://www.example.com/BaseArtifactTypes">

04   

05    <Import importType="http://docs.oasis-open.org/tosca/ns/2011/12"

06            namespace="http://www.example.com/BaseArtifactTypes"/>

07   

08    <ArtifactTemplate id="MyInstallable"

09                      name="My installable"

10                      type="ba:ZipFile">

11      <ArtifactReferences>

12        <ArtifactReference reference="files/MyInstallable.zip"/>

13      </ArtifactReferences>

14    </ArtifactTemplate>

15   

16  </Definitions>

The Artifact Template “MyInstallable” defined in the example above is of type “ZipFile” that is specified in the type attribute of the ArtifactTemplate element. This Artifact Type is defined in a separate file, the definitions of which are imported by means of the Import element and the namespace of those imported definitions is assigned the prefix “ba” in the current file.

The “MyInstallable” Artifact Template provides a reference to a file “MyInstallable.zip” by means of the ArtifactReference element. Since the URI provided in the reference attribute is a relative URI, it is interpreted relative to the root directory of the CSAR containing the Service Template.

14 Policy Types

This chapter specifies how Policy Types are defined. A Policy Type is a reusable entity that describes a kind of non-functional behavior or a kind of quality-of-service (QoS) that a Node Type can declare to expose. For example, a Policy Type can be defined to express high availability for specific Node Types (e.g. a Node Type for an application server).

A Policy Type defines the structure of observable properties via a Properties Definition, i.e. the names, data types and allowed values the properties defined in a corresponding Policy Template can have.

A Policy Type can inherit properties from another Policy Type by means of the DerivedFrom element.

A Policy Type declares the set of Node Types it specifies non-functional behavior for via the AppliesTo element. Note that being “applicable to” does not enforce implementation: i.e. in case a Policy Type expressing high availability is associated with a “Webserver” Node Type, an instance of the Webserver is not necessarily highly available. Whether or not an instance of a Node Type to which a Policy Type is applicable will show the specified non-functional behavior, is determined by a Node Template of the corresponding Node Type.

14.1 XML Syntax

The following pseudo schema defines the XML syntax of Policy Types:

220<PolicyType name="xs:NCName"

221            policyLanguage="xs:anyURI"?

222            abstract="yes|no"?

223            final="yes|no"?

224            targetNamespace="xs:anyURI"?>

225  <Tags>

226    <Tag name="xs:string" value="xs:string"/> +

227  </Tags> ?

228 

229  <DerivedFrom typeRef="xs:QName"/> ?

230 

231  <PropertiesDefinition element="xs:QName"? type="xs:QName"?/> ?

232 

233  <AppliesTo>

234    <NodeTypeReference typeRef="xs:QName"/> +

235  </AppliesTo> ?

236   

237  policy type specific content ?

238 

239</PolicyType>

14.2 Properties

The PolicyType element has the following properties:

14.3 Derivation Rules

The following rules on combining definitions based on DerivedFrom apply:

14.4 Example

The following example defines two Policy Types, the “HighAvailability” Policy Type and the “ContinuousAvailability” Policy Type. They are defined in a Definitions document “MyPolicyTypes” within the target namespace “http://www.example.com/SamplePolicyTypes”. Thus, by importing the corresponding namespace into another Definitions document, both Policy Types are available for use in the other document.

01  <Definitions id="MyPolicyTypes" name="My Policy Types"

02    targetNamespace="http://www.example.com/SamplePolicyTypes"

03    xmlns:bnt="http://www.example.com/BaseNodeTypes">"   

04    xmlns:spp="http://www.example.com/SamplePolicyProperties">

05   

06    <Import importType="http://www.w3.org/2001/XMLSchema"

07            namespace="http://www.example.com/SamplePolicyProperties"/>

08   

09    <Import importType="http://docs.oasis-open.org/tosca/ns/2011/12"

10            namespace="http://www.example.com/BaseNodeTypes"/>

11   

12   

13    <PolicyType name="HighAvailability">

14      <PropertiesDefinition element="spp:HAProperties"/>

15    </PolicyType>

16   

17    <PolicyType name="ContinuousAvailability">

18      <DerivedFrom typeRef="HighAvailability"/>

19      <PropertiesDefinition element="spp:CAProperties"/>

20      <AppliesTo>

21        <NodeTypeReference typeRef="bnt:DBMS"/>

22      </AppliesTo>

23    </PolicyType>

24   

25  </Definitions>

The Policy Type “HighAvailability” defined in the example above has the “HAProperties” properties that are defined in a separate namespace as an XML element. The same namespace contains the “CAProperties” element that defines the properties of the “ContinuousAvailability” Policy Type. This namespace is imported by means of the first Import element and the namespace of those imported definitions is assigned the prefix “spp” in the current file.

The “ContinuousAvailability” Policy Type is derived from the “HighAvailability” Policy Type. Furthermore, it is applicable to the “DBMS” Node Type. This Node Type is defined in a separate namespace, which is imported by means of the second Import element and the namespace of those imported definitions is assigned the prefix “bnt” in the current file.

15 Policy Templates

This chapter specifies how Policy Templates are defined. A Policy Template represents a particular non-functional behavior or quality-of-service that can be referenced by a Node Template. A Policy Template refers to a specific Policy Type that defines the structure of observable properties (metadata) of the non-functional behavior. The Policy Template then typically defines values for those properties inside the Properties element. Note that properties defined by a Policy Template are assumed to be invariant across the contexts in which corresponding behavior is exposed – as opposed to properties defined in Policies of Node Templates that may vary depending on the context.

15.1 XML Syntax

The following pseudo schema defines the XML syntax of Policy Templates:

240<PolicyTemplate id="xs:ID" name="xs:string"? type="xs:QName">

241 

242  <Properties>

243    XML fragment

244  </Properties> ?

245 

246  <PropertyConstraints>

247    <PropertyConstraint property="xs:string"

248                        constraintType="xs:anyURI"> +

249      constraint ?

250    </PropertyConstraint>

251  </PropertyConstraints> ?

252

253  policy type specific content ?

254 

255</PolicyTemplate>

15.2 Properties

The PolicyTemplate element has the following properties:

15.3 Example

The following example defines a Policy Template “MyHAPolicy”. It is defined in a Definitions document “MyPolicies” within the target namespace “http://www.example.com/SamplePolicies”. The Policy Template can be used in the same Definitions document, for example, as a Policy of some Node Template, or it can be used in other document by importing the corresponding namespace into the other document.

01  <Definitions id="MyPolices" name="My Policies"

02    targetNamespace="http://www.example.com/SamplePolicies"

03    xmlns:spt="http://www.example.com/SamplePolicyTypes">

04   

05    <Import importType="http://docs.oasis-open.org/tosca/ns/2011/12"

06            namespace="http://www.example.com/SamplePolicyTypes"/>

07   

08    <PolicyTemplate id="MyHAPolicy"

09                    name="My High Availability Policy"

10                    type="bpt:HighAvailability">

11      <Properties>

12        <HAProperties>

13          <AvailabilityClass>4</AvailabilityClass>

14          <HeartbeatFrequency measuredIn="msec">

15             250

16          </HeartbeatFrequency>

17        </HAProperties>    

18      </Properties>

19    </PolicyTemplate>

20   

21  </Definitions>

The Policy Template “MyHAPolicy” defined in the example above is of type “HighAvailability” that is specified in the type attribute of the PolicyTemplate element. This Policy Type is defined in a separate file, the definitions of which are imported by means of the Import element and the namespace of those imported definitions is assigned the prefix “spt” in the current file.

The “MyHAPolicy” Policy Template provides values for the properties defined by the Properties Definition of the “HighAvailability” Policy Type. The AvailabilityClass property is set to “4”. The value of the HeartbeatFrequency is “250”, measured in “msec”.

16 Cloud Service Archive (CSAR)

This section defines the metadata of a cloud service archive as well as its overall structure.

16.1 Overall Structure of a CSAR

A CSAR is a zip file containing at least two directories, the TOSCA-Metadata directory and the Definitions directory. Beyond that, other directories MAY be contained in a CSAR, i.e. the creator of a CSAR has all freedom to define the content of a CSAR and the structuring of this content as appropriate for the cloud application.

The TOSCA-Metadata directory contains metadata describing the other content of the CSAR. This metadata is referred to as TOSCA meta file. This file is named TOSCA and has the file extension .meta.

The Definitions directory contains one or more TOSCA Definitions documents (file extension .tosca). These Definitions files typically contain definitions related to the cloud application of the CSAR. In addition, CSARs can contain just the definition of elements for re-use in other contexts. For example, a CSAR might be used to package a set of Node Types and Relationship Types with their respective implementations that can then be used by Service Templates provided in other CSARs. In cases where a complete cloud application is packaged in a CSAR, one of the Definitions documents in the Definitions directory MUST contain a Service Template definition that defines the structure and behavior of the cloud application.

16.2 TOSCA Meta File

The TOSCA meta file includes metadata that allows interpreting the various artifacts within the CSAR properly. The TOSCA.meta file is contained in the TOSCA-Metadata directory of the CSAR.

A TOSCA meta file consists of name/value pairs. The name-part of a name/value pair is followed by a colon, followed by a blank, followed by the value-part of the name/value pair. The name MUST NOT contain a colon. Values that represent binary data MUST be base64 encoded. Values that extend beyond one line can be spread over multiple lines if each subsequent line starts with at least one space. Such spaces are then collapsed when the value string is read.

256<name>: <value>

Each name/value pair is in a separate line. A list of related name/value pairs, i.e. a list of consecutive name/value pairs describing a particular file in a CSAR, is called a block. Blocks are separated by an empty line. The first block, called block_0, is metadata about the CSAR itself. All other blocks represent metadata of files in the CSAR.

The structure of block_0 in the TOSCA meta file is as follows:

257TOSCA-Meta-File-Version: digit.digit

258CSAR-Version: digit.digit

259Created-By: string

260Entry-Definitions: string ?

The name/value pairs are as follows:

 

The first line of a block (other than block_0) MUST be a name/value pair that has the name “Name” and the value of which is the path-name of the file described. The second line MUST be a name/value pair that has the name “Content-Type” describing the type of the file described; the format is that of a MIME type with type/subtype structure. The other name/value pairs that consecutively follow are file-type specific.

261Name: <path-name_1>

262Content-Type: type_1/subtype_1

263<name_11>: <value_11>

264<name_12>: <value_12>

265...

266<name_1n>: <value_1n>

267 

268...

269

270Name: <path-name_k>

271Content-Type: type_k/subtype_k

272<name_k1>: <value_k1>

273<name_k2>: <value_k2>

274...

275<name_km>: <value_km>

The name/value pairs are as follows:

 

Note that later directives override earlier directives. This allows for specifying global default directives that can be specialized by later directorives in the TOSCA meta file.

16.3 Example

Figure 7 depicts a sample Definitions file named Payroll.tosca containing a Service Template of an application. The application is a payroll application written in Java that MUST be deployed on a proper application server. The Service Template of the application defines the Node Template Payroll Application, the Node Template Application Server, as well as the Relationship Template deployed_on. The Payroll Application is associated with an EAR file (named Payroll.ear) which is provided as corresponding Deployment Artifact of the Payroll Application Node Template. An Amazon Machine Image (AMI) is the Deployment Artifact of the Application Server Node Template; this Deployment Artifact is a reference to the image in the Amazon EC2 environment. The Implementation Artifacts of some operations of the Node Templates are provided too; for example, the start operation of the Payroll Application is implemented by a Java API supported by the payrolladm.jar file, the installApp operation of the Application Server is realized by the Python script wsadmin.py, while the runInstances operation is a REST API available at Amazon for running instances of an AMI. Note, that the runInstances operation is not related to a particular implementation artifact because it is available as an Amazon Web Service (https://ec2.amazonaws.com/?Action=RunInstances); but the details of this REST API are specified with the operation of the Application Server Node Type.

Figure 7: Sample Service Template

The corresponding Node Types and Relationship Types have been defined in the PayrollTypes.tosca document, which is imported by the Definitions document containing the Payroll Service Template. The following listing provides some of the details:

01  <Definitions id="PayrollDefinitions"

02               targetNamespace="http://www.example.com/tosca"

03               xmlns:pay="http://www.example.com/tosca/Types">

04   

05    <Import namespace="http://www.example.com/tosca/Types"

06            location="http://www.example.com/tosca/Types/PayrollTypes.tosca"

07            importType=" http://docs.oasis-open.org/tosca/ns/2011/12"/>

08   

09    <Types>

10       ...

11    </Types>

12   

13    <ServiceTemplate id="Payroll" name="Payroll Service Template">

14   

15      <TopologyTemplate ID="PayrollTemplate">

16   

17        <NodeTemplate id="Payroll Application"

18                      type="pay:ApplicationNodeType">

19          ...

20   

21          <DeploymentArtifacts>

22            <DeploymentArtifact name="PayrollEAR"

23                                type="http://www.example.com/

24                                      ns/tosca/2011/12/

25                                      DeploymentArtifactTypes/CSARref">

26                  EARs/Payroll.ear

27            </DeploymentArtifact>

28          </DeploymentArtifacts>

29   

30        </NodeTemplate>

31   

32        <NodeTemplate id="Application Server"

33                      type="pay:ApplicationServerNodeType">

34          ...

35   

36          <DeploymentArtifacts>

37            <DeploymentArtifact name="ApplicationServerImage"

38                                type="http://www.example.com/

39                                      ns/tosca/2011/12/

40                                      DeploymentArtifactTypes/AMIref">

41                   ami-edf2cf99

42            </DeploymentArtifact>

43          </DeploymentArtifacts>

44   

45        </NodeTemplate>

46   

47        <RelationshipTemplate id="deployed_on"

48                              type="pay:deployed_on">

49            <SourceElement ref="Payroll Application"/>

50            <TargetElement ref="Application Server"/>

51        </RelationshipTemplate>

52   

53      </TopologyTemplate>

54   

55    </ServiceTemplate>

56   

57  </Definitions>

 

The Payroll Application Node Template specifies the deployment artifact PayrollEAR. It is a reference to the CSAR containing the Payroll.tosca file, which is indicated by the .../CSARref type of the DeploymentArtifact element. The type specific content is a path expression in the directory structure of the CSAR: it points to the Payroll.ear file in the EARs directory of the CSAR (see Figure 8 for the structure of the corresponding CSAR).

The Application Server Node Template has a DeploymentArtifact called ApplicationServerImage that is a reference to an AMI (Amazon Machine Image), indicated by an .../AMIref type.

The corresponding CSAR has the following structure (see Figure 8): The TOSCA.meta file is contained in the TOSCA-Metadata directory. The Payroll.tosca file itself is contained in the Service-Template directory. Also, the PayrollTypes.tosca file is in this directory. The content of the other directories has been sketched before.

Figure 8: Structure of CSAR Sample

The TOSCA.meta file is as follows:

276TOSCA-Meta-Version: 1.0

277CSAR-Version: 1.0

278Created-By: Frank

279 

280Name: Service-Template/Payroll.tosca

281Content-Type: application/vnd.oasis.tosca.definitions

282

283Name: Service-Template/PayrollTypes.tosca

284Content-Type: application/vnd.oasis.tosca.definitions

285

286Name: Plans/AddUser.bpmn

287Content-Type: application/vnd.oasis.bpmn

288

289Name: EARs/Payroll.ear

290Content-Type: application/vnd.oasis.ear

291

292Name: JARs/Payrolladm.jar

293Content-Type: application/vnd.oasis.jar

294

295Name: Python/wsadmin.py

296Content-Type: application/vnd.oasis.py

 

17 Security Considerations

TOSCA does not mandate the use of any specific security mechanism or technology for client authentication. However, a client MUST provide a principal or the principal MUST be obtainable by the infrastructure.

18 Conformance

A TOSCA Definitions document conforms to this specification if it conforms to the TOSCA schema and follows the syntax and semantics defined in the normative portions of this specification. The TOSCA schema takes precedence over the TOSCA grammar (pseudo schema as defined in section 2.5), which in turn takes precedence over normative text, which in turn takes precedence over examples.

An implementation conforms to this specification if it can process a conformant TOSCA Definitions document according to the rules described in chapters 4 through 16 of this specification.

This specification allows extensions. Each implementation SHALL fully support all required functionality of the specification exactly as specified. The use of extensions SHALL NOT contradict nor cause the non-conformance of functionality defined in the specification.

Appendix A. Portability and Interoperability Considerations

This section illustrates the portability and interoperability aspects addressed by Service Templates:

Portability - The ability to take Service Templates created in one vendor's environment and use them in another vendor's environment.

Interoperability - The capability for multiple components (e.g. a task of a plan and the definition of a topology node) to interact using well-defined messages and protocols. This enables combining components from different vendors allowing seamless management of services.

Portability demands support of TOSCA elements.

Appendix B. Acknowledgements

The following individuals have participated in the creation of this specification and are gratefully acknowledged.

Participants:

Aaron Zhang

Huawei Technologies Co., Ltd.

Adolf Hohl

NetApp

Afkham Azeez

WSO2

Al DeLucca

IBM

Alex Heneveld

Cloudsoft Corporation Limited

Allen Bannon

SAP AG

Anthony Rutkowski

Yaana Technologies, LLC

Arvind Srinivasan

IBM

Bryan Haynie

VCE

Bryan Murray

Hewlett-Packard

Chandrasekhar Sundaresh

CA Technologies

Charith Wickramarachchi

WSO2

Colin Hopkinson

3M HIS

Dale Moberg

Axway Software

Debojyoti Dutta

Cisco Systems

Dee Schur

OASIS

Denis Nothern

CenturyLink

Denis Weerasiri

WSO2

Derek Palma

Vnomic

Dhiraj Pathak

PricewaterhouseCoopers LLP:

Diane Mueller

ActiveState Software, Inc.

Doug Davis

IBM

Douglas Neuse

CA Technologies

Duncan Johnston-Watt

Cloudsoft Corporation Limited

Efraim Moscovich

CA Technologies

Frank Leymann

IBM

Gerd Breiter

IBM

James Thomason

Gale Technologies

Jan Ignatius

Nokia Siemens Networks GmbH & Co. KG

Jie Zhu

Huawei Technologies Co., Ltd.

John Wilmes

Individual

Joseph Malek

VCE

Ken Zink

CA Technologies

Kevin Poulter

SAP AG

Kevin Wilson

Hewlett-Packard

Koert Struijk

CA Technologies

Lee Thompson

Morphlabs, Inc.

li peng

Huawei Technologies Co., Ltd.

Marvin Waschke

CA Technologies

Mascot Yu

Huawei Technologies Co., Ltd.

Matthew Dovey

JISC Executive, University of Bristol

Matthew Rutkowski

IBM

Michael Schuster

SAP AG

Mike Edwards

IBM

Naveen Joy

Cisco Systems

Nikki Heron

rPath, Inc.

Paul Fremantle

WSO2

Paul Lipton

CA Technologies

Paul Zhang

Huawei Technologies Co., Ltd.

Rachid Sijelmassi

CA Technologies

Ravi Akireddy

Cisco Systems

Richard Bill

Jericho Systems

Richard Probst

SAP AG

Robert Evans

Zenoss, Inc.

Roland Wartenberg

Citrix Systems

Satoshi Konno

Morphlabs, Inc.

Sean Shen

China Internet Network Information Center(CNNIC)

Selvaratnam Uthaiyashankar

WSO2

Senaka Fernando

WSO2

Sherry Yu

Red Hat

Shumin Cheng

Huawei Technologies Co., Ltd.

Simon Moser

IBM

Srinath Perera

WSO2

Stephen Tyler

CA Technologies

Steve Fanshier

Software AG, Inc.

Steve Jones

Capgemini

Steve Winkler

SAP AG

Tad Deffler

CA Technologies

Ted Streete

VCE

Thilina Buddhika

WSO2

Thomas Spatzier

IBM

Tobias Kunze

Red Hat

Wang Xuan

Primeton Technologies, Inc.

wayne adams

EMC

Wenbo Zhu

Google Inc.

Xiaonan Song

Primeton Technologies, Inc.

YanJiong WANG

Primeton Technologies, Inc.

Zhexuan Song

Huawei Technologies Co., Ltd.

 

Appendix C. Complete TOSCA Grammar

Note: The following is a pseudo EBNF grammar notation meant for documentation purposes only. The grammar is not intended for machine processing.

297<Definitions id="xs:ID"

298             name="xs:string"?

299             targetNamespace="xs:anyURI">

300 

301  <Extensions>

302    <Extension namespace="xs:anyURI"

303               mustUnderstand="yes|no"?/> +  

304  </Extensions> ?

305 

306  <Import namespace="xs:anyURI"?

307          location="xs:anyURI"?

308          importType="xs:anyURI"/> *

309 

310  <Types>

311    <xs:schema .../> *

312  </Types> ?

313 

314  (

315    <ServiceTemplate id="xs:ID"

316                     name="xs:string"?

317                     targetNamespace="xs:anyURI"

318                     substitutableNodeType="xs:QName"?>

319 

320      <Tags>

321        <Tag name="xs:string" value="xs:string"/> +

322      </Tags> ?

323

324      <BoundaryDefinitions>

325        <Properties>

326          XML fragment

327          <PropertyMappings>

328            <PropertyMapping serviceTemplatePropertyRef="xs:string"

329                             targetObjectRef="xs:IDREF"

330                             targetPropertyRef="xs:IDREF"/> +

331          </PropertyMappings/> ?

332        </Properties> ?

333

334        <PropertyConstraints>

335          <PropertyConstraint property="xs:string"

336                              constraintType="xs:anyURI"> +

337            constraint ?

338          </PropertyConstraint>

339        </PropertyConstraints> ?

340

341        <Requirements>

342          <Requirement name="xs:string" ref="xs:IDREF"/> +

343        </Requirements> ?

344

345        <Capabilities>

346          <Capability name="xs:string" ref="xs:IDREF"/> +

347        </Capabilities> ?

348

349        <Policies>

350          <Policy name="xs:string"? policyType="xs:QName"

351                  policyRef="xs:QName"?>

352            policy specific content ?

353          </Policy> +

354        </Policies> ?

355

356        <Interfaces>

357          <Interface name="xs:NCName">

358            <Operation name="xs:NCName">

359              (

360                <NodeOperation nodeRef="xs:IDREF"

361                               interfaceName="xs:anyURI"

362                               operationName="xs:NCName"/>

363              |

364                <RelationshipOperation relationshipRef="xs:IDREF"

365                                       interfaceName="xs:anyURI"

366                                       operationName="xs:NCName"/>

367              |

368                <Plan planRef="xs:IDREF"/>

369              )

370            </Operation> +

371          </Interface> +

372        </Interfaces> ?

373 

374      </BoundaryDefinitions> ?

375 

376      <TopologyTemplate>

377        (

378          <NodeTemplate id="xs:ID" name="xs:string"? type="xs:QName"

379                        minInstances="xs:integer"?

380                        maxInstances="xs:integer | xs:string"?>

381            <Properties>

382              XML fragment

383            </Properties> ?

384 

385            <PropertyConstraints>

386              <PropertyConstraint property="xs:string"

387                                  constraintType="xs:anyURI">

388                constraint ?

389              </PropertyConstraint> +

390            </PropertyConstraints> ?

391

392            <Requirements>

393              <Requirement id="xs:ID" name="xs:string" type="xs:QName"> +

394                <Properties>

395                  XML fragment

396                <Properties> ?

397                <PropertyConstraints>

398                  <PropertyConstraint property="xs:string"

399                                      constraintType="xs:anyURI"> +

400                    constraint ?

401                  </PropertyConstraint>

402                </PropertyConstraints> ?

403              </Requirement>

404            </Requirements> ?

405 

406            <Capabilities>

407              <Capability id="xs:ID" name="xs:string"

408                          type="xs:QName"> +

409                <Properties>

410                  XML fragment

411                <Properties> ?

412                <PropertyConstraints>

413                  <PropertyConstraint property="xs:string"

414                                      constraintType="xs:anyURI">

415                    constraint ?

416                  </PropertyConstraint> +

417                </PropertyConstraints> ?

418              </Capability>

419            </Capabilities> ?

420 

421            <Policies>

422              <Policy name="xs:string"? policyType="xs:QName"

423                      policyRef="xs:QName"?>

424                policy specific content ?

425              </Policy> +

426            </Policies> ?

427 

428            <DeploymentArtifacts>

429              <DeploymentArtifact name="xs:string"

430                                  artifactType="xs:QName"

431                                  artifactRef="xs:QName"?>

432                artifact specific content ?

433              </DeploymentArtifact> +

434            </DeploymentArtifacts> ?

435          </NodeTemplate>

436        |

437          <RelationshipTemplate id="xs:ID" name="xs:string"?

438                                type="xs:QName">

439            <Properties>

440              XML fragment

441            </Properties> ?

442 

443            <PropertyConstraints>

444              <PropertyConstraint property="xs:string"

445                                  constraintType="xs:anyURI">

446                constraint ?

447              </PropertyConstraint> +

448            </PropertyConstraints> ?

449 

450            <SourceElement ref="xs:IDREF"/>

451            <TargetElement ref="xs:IDREF"/>

452 

453            <RelationshipConstraints>

454              <RelationshipConstraint constraintType="xs:anyURI">

455                constraint ?

456              </RelationshipConstraint> +

457            </RelationshipConstraints> ?

458 

459          </RelationshipTemplate>

460        ) +

461      </TopologyTemplate>

462 

463      <Plans>

464        <Plan id="xs:ID"

465              name="xs:string"?

466              planType="xs:anyURI"

467              planLanguage="xs:anyURI">

468 

469           <Precondition expressionLanguage="xs:anyURI">

470             condition

471           </Precondition> ?

472 

473           <InputParameters>

474             <InputParameter name="xs:string" type="xs:string"

475                             required="yes|no"?/> +

476           </InputParameters> ?

477 

478           <OutputParameters>

479             <OutputParameter name="xs:string" type="xs:string"

480                              required="yes|no"?/> +

481           </OutputParameters> ?

482

483          (

484            <PlanModel>

485              actual plan

486            </PlanModel>

487          |

488            <PlanModelReference reference="xs:anyURI"/>

489          )

490 

491        </Plan> +

492      </Plans> ?

493 

494    </ServiceTemplate>

495  |

496    <NodeType name="xs:NCName" targetNamespace="xs:anyURI"?

497              abstract="yes|no"? final="yes|no"?>

498 

499      <DerivedFrom typeRef="xs:QName"/> ?

500 

501      <PropertiesDefinition element="xs:QName"? type="xs:QName"?/> ?

502 

503      <RequirementDefinitions>

504        <RequirementDefinition name="xs:string"

505                               requirementType="xs:QName"

506                               lowerBound="xs:integer"?

507                               upperBound="xs:integer | xs:string"?>

508          <Constraints>

509            <Constraint constraintType="xs:anyURI">

510              constraint type specific content

511            </Constraint> +

512          </Constraints> ?

513        </RequirementDefinition> +

514      </RequirementDefinitions> ?

515 

516      <CapabilityDefinitions>

517        <CapabilityDefinition name="xs:string"

518                              capabilityType="xs:QName"

519                              lowerBound="xs:integer"?

520                              upperBound="xs:integer | xs:string"?>

521          <Constraints>

522            <Constraint constraintType="xs:anyURI">

523              constraint type specific content

524            </Constraint> +

525          </Constraints> ?

526        </CapabilityDefinition> +

527      </CapabilityDefinitions>

528 

529      <InstanceStates>

530        <InstanceState state="xs:anyURI"> +

531      </InstanceStates> ?

532 

533      <Interfaces>

534        <Interface name="xs:NCName | xs:anyURI">

535          <Operation name="xs:NCName">

536            <InputParameters>

537              <InputParameter name="xs:string" type="xs:string"

538                              required="yes|no"?/> +

539            </InputParameters> ?

540            <OutputParameters>

541              <OutputParameter name="xs:string" type="xs:string"

542                               required="yes|no"?/> +

543            </OutputParameters> ?

544          </Operation> +

545        </Interface> +

546      </Interfaces> ?

547 

548    </NodeType>

549  |

550    <NodeTypeImplementation name="xs:NCName"

551                            targetNamespace="xs:anyURI"?

552                            nodeType="xs:QName"

553                            abstract="yes|no"?

554                            final="yes|no"?>

555

556      <DerivedFrom nodeTypeImplementationRef="xs:QName"/> ?

557 

558      <RequiredContainerFeatures>

559        <RequiredContainerFeature feature="xs:anyURI"/> +

560      </RequiredContainerFeatures> ?

561 

562      <ImplementationArtifacts>

563     <ImplementationArtifact interfaceName="xs:NCName | xs:anyURI"?

564                                operationName="xs:NCName"?

565                                artifactType="xs:QName"

566                                artifactRef="xs:QName"?>

567          artifact specific content ?

568        <ImplementationArtifact> +

569      </ImplementationArtifacts> ?

570 

571      <DeploymentArtifacts>

572        <DeploymentArtifact name="xs:string" artifactType="xs:QName"

573                            artifactRef="xs:QName"?>

574          artifact specific content ?

575        <DeploymentArtifact> +

576      </DeploymentArtifacts> ?

577 

578    </NodeTypeImplementation>

579  |

580    <RelationshipType name="xs:NCName"

581                      targetNamespace="xs:anyURI"?

582                      abstract="yes|no"?

583                      final="yes|no"?> +

584 

585      <DerivedFrom typeRef="xs:QName"/> ?

586 

587      <PropertiesDefinition element="xs:QName"? type="xs:QName"?/> ?

588 

589      <InstanceStates>

590        <InstanceState state="xs:anyURI"> +

591      </InstanceStates> ?

592

593      <SourceInterfaces>

594        <Interface name="xs:NCName | xs:anyURI">

595          <Operation name="xs:NCName">

596            <InputParameters>

597              <InputParameter name="xs:string" type="xs:string"

598                              required="yes|no"?/> +

599            </InputParameters> ?

600            <OutputParameters>

601              <OutputParameter name="xs:string" type="xs:string"

602                               required="yes|no"?/> +

603            </OutputParameters> ?

604          </Operation> +

605        </Interface> +

606      </SourceInterfaces> ?

607 

608      <TargetInterfaces>

609        <Interface name="xs:NCName | xs:anyURI">

610          <Operation name="xs:NCName">

611            <InputParameters>

612              <InputParameter name="xs:string" type="xs:string"

613                              required="yes|no"?/> +

614            </InputParameters> ?

615            <OutputParameters>

616              <OutputParameter name="xs:string" type="xs:string"

617                               required="yes|no"?/> +

618            </OutputParameters> ?

619          </Operation> +

620        </Interface> +

621      </TargetInterfaces> ?

622 

623      <ValidSource typeRef="xs:QName"/> ?

624

625      <ValidTarget typeRef="xs:QName"/> ?

626 

627    </RelationshipType>

628  |

629    <RelationshipTypeImplementation name="xs:NCName"

630                                    targetNamespace="xs:anyURI"?

631                                    relationshipType="xs:QName"

632                                    abstract="yes|no"?

633                                    final="yes|no"?>

634

635      <DerivedFrom relationshipTypeImplementationRef="xs:QName"/> ?

636 

637      <RequiredContainerFeatures>

638        <RequiredContainerFeature feature="xs:anyURI"/> +

639      </RequiredContainerFeatures> ?

640 

641      <ImplementationArtifacts>

642     <ImplementationArtifact interfaceName="xs:NCName | xs:anyURI"?

643                                operationName="xs:NCName"?

644                                artifactType="xs:QName"

645                                artifactRef="xs:QName"?>

646          artifact specific content ?

647        <ImplementationArtifact> +

648      </ImplementationArtifacts> ?

649 

650    </RelationshipTypeImplementation>

651  |

652    <RequirementType name="xs:NCName"

653                     targetNamespace="xs:anyURI"?

654                     abstract="yes|no"?

655                     final="yes|no"?

656                     requiredCapabilityType="xs:QName"?>

657 

658      <DerivedFrom typeRef="xs:QName"/> ?

659 

660      <PropertiesDefinition element="xs:QName"? type="xs:QName"?/> ?

661   

662    </RequirementType>

663  |

664    <CapabilityType name="xs:NCName"

665                    targetNamespace="xs:anyURI"?

666                    abstract="yes|no"?

667                    final="yes|no"?>

668 

669      <DerivedFrom typeRef="xs:QName"/> ?

670 

671      <PropertiesDefinition element="xs:QName"? type="xs:QName"?/> ?

672 

673    </CapabilityType>

674  |

675    <ArtifactType name="xs:NCName"

676                  targetNamespace="xs:anyURI"?

677                  abstract="yes|no"?

678                  final="yes|no"?>

679 

680      <DerivedFrom typeRef="xs:QName"/> ?

681 

682      <PropertiesDefinition element="xs:QName"? type="xs:QName"?/> ?

683   

684    </ArtifactType>

685  |

686    <ArtifactTemplate id="xs:ID" name="xs:string"? type="xs:QName">

687 

688      <Properties>

689        XML fragment

690      </Properties> ?

691 

692      <PropertyConstraints>

693        <PropertyConstraint property="xs:string"

694                            constraintType="xs:anyURI"> +

695          constraint ?

696        </PropertyConstraint>

697      </PropertyConstraints> ?

698

699      <ArifactReferences>

700        <ArtifactReference reference="xs:anyURI">

701          (

702           <Include pattern="xs:string"/>

703          |

704           <Exclude pattern="xs:string"/>

705          )*

706        </ArtifactReference> +

707      </ArtifactReferences> ?

708

709    </ArtifactTemplate>

710  |

711    <PolicyType name="xs:NCName"

712                policyLanguage="xs:anyURI"?

713                abstract="yes|no"?

714                final="yes|no"?

715                targetNamespace="xs:anyURI"?>

716      <Tags>

717        <Tag name="xs:string" value="xs:string"/> +

718      </Tags> ?

719 

720      <DerivedFrom typeRef="xs:QName"/> ?

721 

722      <PropertiesDefinition element="xs:QName"? type="xs:QName"?/> ?

723 

724      <AppliesTo>

725        <NodeTypeReference typeRef="xs:QName"/> +

726      </AppliesTo> ?

727   

728      policy type specific content ?

729 

730    </PolicyType>

731  |

732    <PolicyTemplate id="xs:ID" name="xs:string"? type="xs:QName">

733 

734      <Properties>

735        XML fragment

736      </Properties> ?

737 

738      <PropertyConstraints>

739        <PropertyConstraint property="xs:string"

740                            constraintType="xs:anyURI"> +

741          constraint ?

742        </PropertyConstraint>

743      </PropertyConstraints> ?

744

745      policy type specific content ?

746 

747    </PolicyTemplate>

748  ) +

749 

750</Definitions>

Appendix D. TOSCA Schema

TOSCA-v1.0.xsd:

751<?xml version="1.0" encoding="UTF-8"?>

752<xs:schema targetNamespace="http://docs.oasis-open.org/tosca/ns/2011/12"

753 elementFormDefault="qualified" attributeFormDefault="unqualified"

754 xmlns="http://docs.oasis-open.org/tosca/ns/2011/12"

755 xmlns:xs="http://www.w3.org/2001/XMLSchema">

756 

757 <xs:import namespace="http://www.w3.org/XML/1998/namespace"

758  schemaLocation="http://www.w3.org/2001/xml.xsd"/>

759 

760 <xs:element name="documentation" type="tDocumentation"/>

761 <xs:complexType name="tDocumentation" mixed="true">

762  <xs:sequence>

763   <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

764  </xs:sequence>

765  <xs:attribute name="source" type="xs:anyURI"/>

766  <xs:attribute ref="xml:lang"/>

767 </xs:complexType>

768 

769 <xs:complexType name="tExtensibleElements">

770  <xs:sequence>

771   <xs:element ref="documentation" minOccurs="0" maxOccurs="unbounded"/>

772   <xs:any namespace="##other" processContents="lax" minOccurs="0"

773    maxOccurs="unbounded"/>

774  </xs:sequence>

775  <xs:anyAttribute namespace="##other" processContents="lax"/>

776 </xs:complexType>

777 

778 <xs:complexType name="tImport">

779  <xs:complexContent>

780   <xs:extension base="tExtensibleElements">

781    <xs:attribute name="namespace" type="xs:anyURI"/>

782    <xs:attribute name="location" type="xs:anyURI"/>

783    <xs:attribute name="importType" type="importedURI" use="required"/>

784   </xs:extension>

785  </xs:complexContent>

786 </xs:complexType>

787 

788 <xs:element name="Definitions">

789  <xs:complexType>

790   <xs:complexContent>

791    <xs:extension base="tDefinitions"/>

792   </xs:complexContent>

793  </xs:complexType>

794 </xs:element>

795 <xs:complexType name="tDefinitions">

796  <xs:complexContent>

797   <xs:extension base="tExtensibleElements">

798    <xs:sequence>

799     <xs:element name="Extensions" minOccurs="0">

800      <xs:complexType>

801       <xs:sequence>

802        <xs:element name="Extension" type="tExtension"

803         maxOccurs="unbounded"/>

804       </xs:sequence>

805      </xs:complexType>

806     </xs:element>

807     <xs:element name="Import" type="tImport" minOccurs="0"

808      maxOccurs="unbounded"/>

809     <xs:element name="Types" minOccurs="0">

810      <xs:complexType>

811       <xs:sequence>

812        <xs:any namespace="##other" processContents="lax" minOccurs="0"

813         maxOccurs="unbounded"/>

814       </xs:sequence>

815      </xs:complexType>

816     </xs:element>

817     <xs:choice maxOccurs="unbounded">

818      <xs:element name="ServiceTemplate" type="tServiceTemplate"/>

819      <xs:element name="NodeType" type="tNodeType"/>

820      <xs:element name="NodeTypeImplementation"

821       type="tNodeTypeImplementation"/>

822      <xs:element name="RelationshipType" type="tRelationshipType"/>

823      <xs:element name="RelationshipTypeImplementation"

824       type="tRelationshipTypeImplementation"/>

825      <xs:element name="RequirementType" type="tRequirementType"/>

826      <xs:element name="CapabilityType" type="tCapabilityType"/>

827      <xs:element name="ArtifactType" type="tArtifactType"/>

828      <xs:element name="ArtifactTemplate" type="tArtifactTemplate"/>

829      <xs:element name="PolicyType" type="tPolicyType"/>

830      <xs:element name="PolicyTemplate" type="tPolicyTemplate"/>

831     </xs:choice>

832    </xs:sequence>

833    <xs:attribute name="id" type="xs:ID" use="required"/>

834    <xs:attribute name="name" type="xs:string" use="optional"/>

835    <xs:attribute name="targetNamespace" type="xs:anyURI" use="required"/>

836   </xs:extension>

837  </xs:complexContent>

838 </xs:complexType>

839 

840 <xs:complexType name="tServiceTemplate">

841  <xs:complexContent>

842   <xs:extension base="tExtensibleElements">

843    <xs:sequence>

844     <xs:element name="Tags" type="tTags" minOccurs="0"/>

845     <xs:element name="BoundaryDefinitions" type="tBoundaryDefinitions"

846      minOccurs="0"/>

847     <xs:element name="TopologyTemplate" type="tTopologyTemplate"/>

848     <xs:element name="Plans" type="tPlans" minOccurs="0"/>

849    </xs:sequence>

850    <xs:attribute name="id" type="xs:ID" use="required"/>

851    <xs:attribute name="name" type="xs:string" use="optional"/>

852    <xs:attribute name="targetNamespace" type="xs:anyURI"/>

853    <xs:attribute name="substitutableNodeType" type="xs:QName"

854     use="optional"/>

855   </xs:extension>

856  </xs:complexContent>

857 </xs:complexType>

858 

859 <xs:complexType name="tTags">

860  <xs:sequence>

861   <xs:element name="Tag" type="tTag" maxOccurs="unbounded"/>

862  </xs:sequence>

863 </xs:complexType>

864 

865 <xs:complexType name="tTag">

866  <xs:attribute name="name" type="xs:string" use="required"/>

867  <xs:attribute name="value" type="xs:string" use="required"/>

868 </xs:complexType>

869 

870 <xs:complexType name="tBoundaryDefinitions">

871  <xs:sequence>

872   <xs:element name="Properties" minOccurs="0">

873    <xs:complexType>

874     <xs:sequence>

875      <xs:any namespace="##other"/>

876      <xs:element name="PropertyMappings" minOccurs="0">

877       <xs:complexType>

878        <xs:sequence>

879         <xs:element name="PropertyMapping" type="tPropertyMapping"

880          maxOccurs="unbounded"/>

881        </xs:sequence>

882       </xs:complexType>

883      </xs:element>

884     </xs:sequence>

885    </xs:complexType>

886   </xs:element>

887   <xs:element name="PropertyConstraints" minOccurs="0">

888    <xs:complexType>

889     <xs:sequence>

890      <xs:element name="PropertyConstraint" type="tPropertyConstraint"

891       maxOccurs="unbounded"/>

892     </xs:sequence>

893    </xs:complexType>

894   </xs:element>

895   <xs:element name="Requirements" minOccurs="0">

896    <xs:complexType>

897     <xs:sequence>

898      <xs:element name="Requirement" type="tRequirementRef"

899       maxOccurs="unbounded"/>

900     </xs:sequence>

901    </xs:complexType>

902   </xs:element>

903   <xs:element name="Capabilities" minOccurs="0">

904    <xs:complexType>

905     <xs:sequence>

906      <xs:element name="Capability" type="tCapabilityRef"

907       maxOccurs="unbounded"/>

908     </xs:sequence>

909    </xs:complexType>

910   </xs:element>

911   <xs:element name="Policies" minOccurs="0">

912    <xs:complexType>

913     <xs:sequence>

914      <xs:element name="Policy" type="tPolicy" maxOccurs="unbounded"/>

915     </xs:sequence>

916    </xs:complexType>

917   </xs:element>

918   <xs:element name="Interfaces" minOccurs="0">

919    <xs:complexType>

920     <xs:sequence>

921      <xs:element name="Interface" type="tExportedInterface"

922       maxOccurs="unbounded"/>

923     </xs:sequence>

924    </xs:complexType>

925   </xs:element>

926  </xs:sequence>

927 </xs:complexType>

928 

929 <xs:complexType name="tPropertyMapping">

930  <xs:attribute name="serviceTemplatePropertyRef" type="xs:string"

931   use="required"/>

932  <xs:attribute name="targetObjectRef" type="xs:IDREF" use="required"/>

933  <xs:attribute name="targetPropertyRef" type="xs:string"

934   use="required"/>

935 </xs:complexType>

936 

937 <xs:complexType name="tRequirementRef">

938  <xs:attribute name="name" type="xs:string" use="optional"/>

939  <xs:attribute name="ref" type="xs:IDREF" use="required"/>

940 </xs:complexType>

941 

942 <xs:complexType name="tCapabilityRef">

943  <xs:attribute name="name" type="xs:string" use="optional"/>

944  <xs:attribute name="ref" type="xs:IDREF" use="required"/>

945 </xs:complexType>

946 

947 <xs:complexType name="tEntityType" abstract="true">

948  <xs:complexContent>

949   <xs:extension base="tExtensibleElements">

950    <xs:sequence>

951     <xs:element name="Tags" type="tTags" minOccurs="0"/>

952     <xs:element name="DerivedFrom" minOccurs="0">

953      <xs:complexType>

954       <xs:attribute name="typeRef" type="xs:QName" use="required"/>

955      </xs:complexType>

956     </xs:element>

957     <xs:element name="PropertiesDefinition" minOccurs="0">

958      <xs:complexType>

959       <xs:attribute name="element" type="xs:QName"/>

960       <xs:attribute name="type" type="xs:QName"/>

961      </xs:complexType>

962     </xs:element>

963    </xs:sequence>

964    <xs:attribute name="name" type="xs:NCName" use="required"/>

965    <xs:attribute name="abstract" type="tBoolean" default="no"/>

966    <xs:attribute name="final" type="tBoolean" default="no"/>

967    <xs:attribute name="targetNamespace" type="xs:anyURI"

968     use="optional"/>

969   </xs:extension>

970  </xs:complexContent>

971 </xs:complexType>

972 

973 <xs:complexType name="tEntityTemplate" abstract="true">

974  <xs:complexContent>

975   <xs:extension base="tExtensibleElements">

976    <xs:sequence>

977     <xs:element name="Properties" minOccurs="0">

978      <xs:complexType>

979       <xs:sequence>

980        <xs:any namespace="##other" processContents="lax"/>

981       </xs:sequence>

982      </xs:complexType>

983     </xs:element>

984     <xs:element name="PropertyConstraints" minOccurs="0">

985      <xs:complexType>

986       <xs:sequence>

987        <xs:element name="PropertyConstraint"

988         type="tPropertyConstraint" maxOccurs="unbounded"/>

989       </xs:sequence>

990      </xs:complexType>

991     </xs:element>

992    </xs:sequence>

993    <xs:attribute name="id" type="xs:ID" use="required"/>

994    <xs:attribute name="type" type="xs:QName" use="required"/>

995   </xs:extension>

996  </xs:complexContent>

997 </xs:complexType>

998 

999 <xs:complexType name="tNodeTemplate">

1000      <xs:complexContent>

1001       <xs:extension base="tEntityTemplate">

1002        <xs:sequence>

1003         <xs:element name="Requirements" minOccurs="0">

1004          <xs:complexType>

1005           <xs:sequence>

1006            <xs:element name="Requirement" type="tRequirement"

1007             maxOccurs="unbounded"/>

1008           </xs:sequence>

1009          </xs:complexType>

1010         </xs:element>

1011         <xs:element name="Capabilities" minOccurs="0">

1012          <xs:complexType>

1013           <xs:sequence>

1014            <xs:element name="Capability" type="tCapability"

1015             maxOccurs="unbounded"/>

1016           </xs:sequence>

1017          </xs:complexType>

1018         </xs:element>

1019         <xs:element name="Policies" minOccurs="0">

1020          <xs:complexType>

1021           <xs:sequence>

1022            <xs:element name="Policy" type="tPolicy"

1023             maxOccurs="unbounded"/>

1024           </xs:sequence>

1025          </xs:complexType>

1026         </xs:element>

1027         <xs:element name="DeploymentArtifacts" type="tDeploymentArtifacts"

1028          minOccurs="0"/>

1029        </xs:sequence>

1030        <xs:attribute name="name" type="xs:string" use="optional"/>

1031        <xs:attribute name="minInstances" type="xs:int" use="optional"

1032         default="1"/>

1033        <xs:attribute name="maxInstances" use="optional" default="1">

1034         <xs:simpleType>

1035          <xs:union>

1036           <xs:simpleType>

1037            <xs:restriction base="xs:nonNegativeInteger">

1038             <xs:pattern value="([1-9]+[0-9]*)"/>

1039            </xs:restriction>

1040           </xs:simpleType>

1041           <xs:simpleType>

1042            <xs:restriction base="xs:string">

1043             <xs:enumeration value="unbounded"/>

1044            </xs:restriction>

1045           </xs:simpleType>

1046          </xs:union>

1047         </xs:simpleType>

1048        </xs:attribute>

1049       </xs:extension>

1050      </xs:complexContent>

1051     </xs:complexType>

1052     

1053     <xs:complexType name="tTopologyTemplate">

1054      <xs:complexContent>

1055       <xs:extension base="tExtensibleElements">

1056        <xs:choice maxOccurs="unbounded">

1057         <xs:element name="NodeTemplate" type="tNodeTemplate"/>

1058         <xs:element name="RelationshipTemplate"

1059          type="tRelationshipTemplate"/>

1060        </xs:choice>

1061       </xs:extension>

1062      </xs:complexContent>

1063     </xs:complexType>

1064     

1065     <xs:complexType name="tRelationshipType">

1066      <xs:complexContent>

1067       <xs:extension base="tEntityType">

1068        <xs:sequence>

1069         <xs:element name="InstanceStates"

1070          type="tTopologyElementInstanceStates" minOccurs="0"/>

1071         <xs:element name="SourceInterfaces" minOccurs="0">

1072          <xs:complexType>

1073           <xs:sequence>

1074            <xs:element name="Interface" type="tInterface"

1075             maxOccurs="unbounded"/>

1076           </xs:sequence>

1077          </xs:complexType>

1078         </xs:element>

1079         <xs:element name="TargetInterfaces" minOccurs="0">

1080          <xs:complexType>

1081           <xs:sequence>

1082            <xs:element name="Interface" type="tInterface"

1083             maxOccurs="unbounded"/>

1084           </xs:sequence>

1085          </xs:complexType>

1086         </xs:element>

1087         <xs:element name="ValidSource" minOccurs="0">

1088          <xs:complexType>

1089           <xs:attribute name="typeRef" type="xs:QName" use="required"/>

1090          </xs:complexType>

1091         </xs:element>

1092         <xs:element name="ValidTarget" minOccurs="0">

1093          <xs:complexType>

1094           <xs:attribute name="typeRef" type="xs:QName" use="required"/>

1095          </xs:complexType>

1096         </xs:element>

1097        </xs:sequence>

1098       </xs:extension>

1099      </xs:complexContent>

1100     </xs:complexType>

1101     

1102     <xs:complexType name="tRelationshipTypeImplementation">

1103      <xs:complexContent>

1104       <xs:extension base="tExtensibleElements">

1105        <xs:sequence>

1106         <xs:element name="Tags" type="tTags" minOccurs="0"/>

1107         <xs:element name="DerivedFrom" minOccurs="0">

1108          <xs:complexType>

1109           <xs:attribute name="relationshipTypeImplementationRef"

1110            type="xs:QName" use="required"/>

1111          </xs:complexType>

1112         </xs:element>

1113         <xs:element name="RequiredContainerFeatures"

1114          type="tRequiredContainerFeatures" minOccurs="0"/>

1115         <xs:element name="ImplementationArtifacts"

1116          type="tImplementationArtifacts" minOccurs="0"/>

1117        </xs:sequence>

1118        <xs:attribute name="name" type="xs:NCName" use="required"/>

1119        <xs:attribute name="targetNamespace" type="xs:anyURI"

1120         use="optional"/>

1121        <xs:attribute name="relationshipType" type="xs:QName"

1122         use="required"/>

1123        <xs:attribute name="abstract" type="tBoolean" use="optional"

1124         default="no"/>

1125        <xs:attribute name="final" type="tBoolean" use="optional"

1126         default="no"/>

1127       </xs:extension>

1128      </xs:complexContent>

1129     </xs:complexType>

1130     

1131     <xs:complexType name="tRelationshipTemplate">

1132      <xs:complexContent>

1133       <xs:extension base="tEntityTemplate">

1134        <xs:sequence>

1135         <xs:element name="SourceElement">

1136          <xs:complexType>

1137           <xs:attribute name="ref" type="xs:IDREF" use="required"/>

1138          </xs:complexType>

1139         </xs:element>

1140         <xs:element name="TargetElement">

1141          <xs:complexType>

1142           <xs:attribute name="ref" type="xs:IDREF" use="required"/>

1143          </xs:complexType>

1144         </xs:element>

1145         <xs:element name="RelationshipConstraints" minOccurs="0">

1146          <xs:complexType>

1147           <xs:sequence>

1148            <xs:element name="RelationshipConstraint"

1149             maxOccurs="unbounded">

1150             <xs:complexType>

1151              <xs:sequence>

1152               <xs:any namespace="##other" processContents="lax"

1153                minOccurs="0"/>

1154              </xs:sequence>

1155              <xs:attribute name="constraintType" type="xs:anyURI"

1156               use="required"/>

1157             </xs:complexType>

1158            </xs:element>

1159           </xs:sequence>

1160          </xs:complexType>

1161         </xs:element>

1162        </xs:sequence>

1163        <xs:attribute name="name" type="xs:string" use="optional"/>

1164       </xs:extension>

1165      </xs:complexContent>

1166     </xs:complexType>

1167     

1168     <xs:complexType name="tNodeType">

1169      <xs:complexContent>

1170       <xs:extension base="tEntityType">

1171        <xs:sequence>

1172         <xs:element name="RequirementDefinitions" minOccurs="0">

1173          <xs:complexType>

1174           <xs:sequence>

1175            <xs:element name="RequirementDefinition"

1176             type="tRequirementDefinition" maxOccurs="unbounded"/>

1177           </xs:sequence>

1178          </xs:complexType>

1179         </xs:element>

1180         <xs:element name="CapabilityDefinitions" minOccurs="0">

1181          <xs:complexType>

1182           <xs:sequence>

1183            <xs:element name="CapabilityDefinition"

1184             type="tCapabilityDefinition" maxOccurs="unbounded"/>

1185           </xs:sequence>

1186          </xs:complexType>

1187         </xs:element>

1188         <xs:element name="InstanceStates"

1189          type="tTopologyElementInstanceStates" minOccurs="0"/>

1190         <xs:element name="Interfaces" minOccurs="0">

1191          <xs:complexType>

1192           <xs:sequence>

1193            <xs:element name="Interface" type="tInterface"

1194             maxOccurs="unbounded"/>

1195           </xs:sequence>

1196          </xs:complexType>

1197         </xs:element>

1198        </xs:sequence>

1199       </xs:extension>

1200      </xs:complexContent>

1201     </xs:complexType>

1202     

1203     <xs:complexType name="tNodeTypeImplementation">

1204      <xs:complexContent>

1205       <xs:extension base="tExtensibleElements">

1206        <xs:sequence>

1207         <xs:element name="Tags" type="tTags" minOccurs="0"/>

1208         <xs:element name="DerivedFrom" minOccurs="0">

1209          <xs:complexType>

1210           <xs:attribute name="nodeTypeImplementationRef" type="xs:QName"

1211            use="required"/>

1212          </xs:complexType>

1213         </xs:element>

1214         <xs:element name="RequiredContainerFeatures"

1215          type="tRequiredContainerFeatures" minOccurs="0"/>

1216         <xs:element name="ImplementationArtifacts"

1217          type="tImplementationArtifacts" minOccurs="0"/>

1218         <xs:element name="DeploymentArtifacts" type="tDeploymentArtifacts"

1219          minOccurs="0"/>

1220        </xs:sequence>

1221        <xs:attribute name="name" type="xs:NCName" use="required"/>

1222        <xs:attribute name="targetNamespace" type="xs:anyURI"

1223         use="optional"/>

1224        <xs:attribute name="nodeType" type="xs:QName" use="required"/>

1225        <xs:attribute name="abstract" type="tBoolean" use="optional"

1226         default="no"/>

1227        <xs:attribute name="final" type="tBoolean" use="optional"

1228         default="no"/>

1229       </xs:extension>

1230      </xs:complexContent>

1231     </xs:complexType>

1232     

1233     <xs:complexType name="tRequirementType">

1234      <xs:complexContent>

1235       <xs:extension base="tEntityType">

1236        <xs:attribute name="requiredCapabilityType" type="xs:QName"

1237         use="optional"/>

1238       </xs:extension>

1239      </xs:complexContent>

1240     </xs:complexType>

1241     

1242     <xs:complexType name="tRequirementDefinition">

1243      <xs:complexContent>

1244       <xs:extension base="tExtensibleElements">

1245        <xs:sequence>

1246         <xs:element name="Constraints" minOccurs="0">

1247          <xs:complexType>

1248           <xs:sequence>

1249            <xs:element name="Constraint" type="tConstraint"

1250             maxOccurs="unbounded"/>

1251           </xs:sequence>

1252          </xs:complexType>

1253         </xs:element>

1254        </xs:sequence>

1255        <xs:attribute name="name" type="xs:string" use="required"/>

1256        <xs:attribute name="requirementType" type="xs:QName"

1257         use="required"/>

1258        <xs:attribute name="lowerBound" type="xs:int" use="optional"

1259         default="1"/>

1260        <xs:attribute name="upperBound" use="optional" default="1">

1261         <xs:simpleType>

1262          <xs:union>

1263           <xs:simpleType>

1264            <xs:restriction base="xs:nonNegativeInteger">

1265             <xs:pattern value="([1-9]+[0-9]*)"/>

1266            </xs:restriction>

1267           </xs:simpleType>

1268           <xs:simpleType>

1269            <xs:restriction base="xs:string">

1270             <xs:enumeration value="unbounded"/>

1271            </xs:restriction>

1272           </xs:simpleType>

1273          </xs:union>

1274         </xs:simpleType>

1275        </xs:attribute>

1276       </xs:extension>

1277      </xs:complexContent>

1278     </xs:complexType>

1279     

1280     <xs:complexType name="tRequirement">

1281      <xs:complexContent>

1282       <xs:extension base="tEntityTemplate">

1283        <xs:attribute name="name" type="xs:string" use="required"/>

1284       </xs:extension>

1285      </xs:complexContent>

1286     </xs:complexType>

1287     

1288     <xs:complexType name="tCapabilityType">

1289      <xs:complexContent>

1290       <xs:extension base="tEntityType"/>

1291      </xs:complexContent>

1292     </xs:complexType>

1293     

1294     <xs:complexType name="tCapabilityDefinition">

1295      <xs:complexContent>

1296       <xs:extension base="tExtensibleElements">

1297        <xs:sequence>

1298         <xs:element name="Constraints" minOccurs="0">

1299          <xs:complexType>

1300           <xs:sequence>

1301            <xs:element name="Constraint" type="tConstraint"

1302             maxOccurs="unbounded"/>

1303           </xs:sequence>

1304          </xs:complexType>

1305         </xs:element>

1306        </xs:sequence>

1307        <xs:attribute name="name" type="xs:string" use="required"/>

1308        <xs:attribute name="capabilityType" type="xs:QName"

1309         use="required"/>

1310        <xs:attribute name="lowerBound" type="xs:int" use="optional"

1311         default="1"/>

1312        <xs:attribute name="upperBound" use="optional" default="1">

1313         <xs:simpleType>

1314          <xs:union>

1315           <xs:simpleType>

1316            <xs:restriction base="xs:nonNegativeInteger">

1317             <xs:pattern value="([1-9]+[0-9]*)"/>

1318            </xs:restriction>

1319           </xs:simpleType>

1320           <xs:simpleType>

1321            <xs:restriction base="xs:string">

1322             <xs:enumeration value="unbounded"/>

1323            </xs:restriction>

1324           </xs:simpleType>

1325          </xs:union>

1326         </xs:simpleType>

1327        </xs:attribute>

1328       </xs:extension>

1329      </xs:complexContent>

1330     </xs:complexType>

1331     

1332     <xs:complexType name="tCapability">

1333      <xs:complexContent>

1334       <xs:extension base="tEntityTemplate">

1335        <xs:attribute name="name" type="xs:string" use="required"/>

1336       </xs:extension>

1337      </xs:complexContent>

1338     </xs:complexType>

1339     

1340     <xs:complexType name="tArtifactType">

1341      <xs:complexContent>

1342       <xs:extension base="tEntityType"/>

1343      </xs:complexContent>

1344     </xs:complexType>

1345     

1346     <xs:complexType name="tArtifactTemplate">

1347      <xs:complexContent>

1348       <xs:extension base="tEntityTemplate">

1349        <xs:sequence>

1350         <xs:element name="ArtifactReferences" minOccurs="0">

1351          <xs:complexType>

1352           <xs:sequence>

1353            <xs:element name="ArtifactReference" type="tArtifactReference"

1354             maxOccurs="unbounded"/>

1355           </xs:sequence>

1356          </xs:complexType>

1357         </xs:element>

1358        </xs:sequence>

1359        <xs:attribute name="name" type="xs:string" use="optional"/>

1360       </xs:extension>

1361      </xs:complexContent>

1362     </xs:complexType>

1363     

1364     <xs:complexType name="tDeploymentArtifacts">

1365      <xs:sequence>

1366       <xs:element name="DeploymentArtifact" type="tDeploymentArtifact"

1367        maxOccurs="unbounded"/>

1368      </xs:sequence>

1369     </xs:complexType>

1370     

1371     <xs:complexType name="tDeploymentArtifact">

1372      <xs:complexContent>

1373       <xs:extension base="tExtensibleElements">

1374        <xs:attribute name="name" type="xs:string" use="required"/>

1375        <xs:attribute name="artifactType" type="xs:QName" use="required"/>

1376        <xs:attribute name="artifactRef" type="xs:QName" use="optional"/>

1377       </xs:extension>

1378      </xs:complexContent>

1379     </xs:complexType>

1380     

1381     <xs:complexType name="tImplementationArtifacts">

1382      <xs:sequence>

1383       <xs:element name="ImplementationArtifact" maxOccurs="unbounded">

1384        <xs:complexType>

1385         <xs:complexContent>

1386          <xs:extension base="tImplementationArtifact"/>

1387         </xs:complexContent>

1388        </xs:complexType>

1389       </xs:element>

1390      </xs:sequence>

1391     </xs:complexType>

1392     

1393     <xs:complexType name="tImplementationArtifact">

1394      <xs:complexContent>

1395       <xs:extension base="tExtensibleElements">

1396        <xs:attribute name="interfaceName" type="xs:anyURI"

1397         use="optional"/>

1398        <xs:attribute name="operationName" type="xs:NCName"

1399         use="optional"/>

1400        <xs:attribute name="artifactType" type="xs:QName" use="required"/>

1401        <xs:attribute name="artifactRef" type="xs:QName" use="optional"/>

1402       </xs:extension>

1403      </xs:complexContent>

1404     </xs:complexType>

1405     

1406     <xs:complexType name="tPlans">

1407      <xs:sequence>

1408       <xs:element name="Plan" type="tPlan" maxOccurs="unbounded"/>

1409      </xs:sequence>

1410      <xs:attribute name="targetNamespace" type="xs:anyURI"

1411       use="optional"/>

1412     </xs:complexType>

1413     

1414     <xs:complexType name="tPlan">

1415      <xs:complexContent>

1416       <xs:extension base="tExtensibleElements">

1417        <xs:sequence>

1418         <xs:element name="Precondition" type="tCondition" minOccurs="0"/>

1419         <xs:element name="InputParameters" minOccurs="0">

1420          <xs:complexType>

1421           <xs:sequence>

1422            <xs:element name="InputParameter" type="tParameter"

1423             maxOccurs="unbounded"/>

1424           </xs:sequence>

1425          </xs:complexType>

1426         </xs:element>

1427         <xs:element name="OutputParameters" minOccurs="0">

1428          <xs:complexType>

1429           <xs:sequence>

1430            <xs:element name="OutputParameter" type="tParameter"

1431             maxOccurs="unbounded"/>

1432           </xs:sequence>

1433          </xs:complexType>

1434         </xs:element>

1435         <xs:choice>

1436          <xs:element name="PlanModel">

1437           <xs:complexType>

1438            <xs:sequence>

1439             <xs:any namespace="##other" processContents="lax"/>

1440            </xs:sequence>

1441           </xs:complexType>

1442          </xs:element>

1443          <xs:element name="PlanModelReference">

1444           <xs:complexType>

1445            <xs:attribute name="reference" type="xs:anyURI"

1446             use="required"/>

1447           </xs:complexType>

1448          </xs:element>

1449         </xs:choice>

1450        </xs:sequence>

1451        <xs:attribute name="id" type="xs:ID" use="required"/>

1452        <xs:attribute name="name" type="xs:string" use="optional"/>

1453        <xs:attribute name="planType" type="xs:anyURI" use="required"/>

1454        <xs:attribute name="planLanguage" type="xs:anyURI" use="required"/>

1455       </xs:extension>

1456      </xs:complexContent>

1457     </xs:complexType>

1458     

1459     <xs:complexType name="tPolicyType">

1460      <xs:complexContent>

1461       <xs:extension base="tEntityType">

1462        <xs:sequence>

1463         <xs:element name="AppliesTo" type="tAppliesTo" minOccurs="0"/>

1464        </xs:sequence>

1465        <xs:attribute name="policyLanguage" type="xs:anyURI"

1466         use="optional"/>

1467       </xs:extension>

1468      </xs:complexContent>

1469     </xs:complexType>

1470     

1471     <xs:complexType name="tPolicyTemplate">

1472      <xs:complexContent>

1473       <xs:extension base="tEntityTemplate">

1474        <xs:attribute name="name" type="xs:string" use="optional"/>

1475       </xs:extension>

1476      </xs:complexContent>

1477     </xs:complexType>

1478     

1479     <xs:complexType name="tAppliesTo">

1480      <xs:sequence>

1481       <xs:element name="NodeTypeReference" maxOccurs="unbounded">

1482        <xs:complexType>

1483         <xs:attribute name="typeRef" type="xs:QName" use="required"/>

1484        </xs:complexType>

1485       </xs:element>

1486      </xs:sequence>

1487     </xs:complexType>

1488     

1489     <xs:complexType name="tPolicy">

1490      <xs:complexContent>

1491       <xs:extension base="tExtensibleElements">

1492        <xs:attribute name="name" type="xs:string" use="optional"/>

1493        <xs:attribute name="policyType" type="xs:QName" use="required"/>

1494        <xs:attribute name="policyRef" type="xs:QName" use="optional"/>

1495       </xs:extension>

1496      </xs:complexContent>

1497     </xs:complexType>

1498     

1499     <xs:complexType name="tConstraint">

1500      <xs:sequence>

1501       <xs:any namespace="##other" processContents="lax"/>

1502      </xs:sequence>

1503      <xs:attribute name="constraintType" type="xs:anyURI" use="required"/>

1504     </xs:complexType>

1505     

1506     <xs:complexType name="tPropertyConstraint">

1507      <xs:complexContent>

1508       <xs:extension base="tConstraint">

1509        <xs:attribute name="property" type="xs:string" use="required"/>

1510       </xs:extension>

1511      </xs:complexContent>

1512     </xs:complexType>

1513     

1514     <xs:complexType name="tExtensions">

1515      <xs:complexContent>

1516       <xs:extension base="tExtensibleElements">

1517        <xs:sequence>

1518         <xs:element name="Extension" type="tExtension"

1519          maxOccurs="unbounded"/>

1520        </xs:sequence>

1521       </xs:extension>

1522      </xs:complexContent>

1523     </xs:complexType>

1524     

1525     <xs:complexType name="tExtension">

1526      <xs:complexContent>

1527       <xs:extension base="tExtensibleElements">

1528        <xs:attribute name="namespace" type="xs:anyURI" use="required"/>

1529        <xs:attribute name="mustUnderstand" type="tBoolean" use="optional"

1530         default="yes"/>

1531       </xs:extension>

1532      </xs:complexContent>

1533     </xs:complexType>

1534     

1535     <xs:complexType name="tParameter">

1536      <xs:attribute name="name" type="xs:string" use="required"/>

1537      <xs:attribute name="type" type="xs:string" use="required"/>

1538      <xs:attribute name="required" type="tBoolean" use="optional"

1539       default="yes"/>

1540     </xs:complexType>

1541     

1542     <xs:complexType name="tInterface">

1543      <xs:sequence>

1544       <xs:element name="Operation" type="tOperation"

1545        maxOccurs="unbounded"/>

1546      </xs:sequence>

1547      <xs:attribute name="name" type="xs:anyURI" use="required"/>

1548     </xs:complexType>

1549     

1550     <xs:complexType name="tExportedInterface">

1551      <xs:sequence>

1552       <xs:element name="Operation" type="tExportedOperation"

1553        maxOccurs="unbounded"/>

1554      </xs:sequence>

1555      <xs:attribute name="name" type="xs:anyURI" use="required"/>

1556     </xs:complexType>

1557     

1558     <xs:complexType name="tOperation">

1559      <xs:complexContent>

1560       <xs:extension base="tExtensibleElements">

1561        <xs:sequence>

1562         <xs:element name="InputParameters" minOccurs="0">

1563          <xs:complexType>

1564           <xs:sequence>

1565            <xs:element name="InputParameter" type="tParameter"

1566             maxOccurs="unbounded"/>

1567           </xs:sequence>

1568          </xs:complexType>

1569         </xs:element>

1570         <xs:element name="OutputParameters" minOccurs="0">

1571          <xs:complexType>

1572           <xs:sequence>

1573            <xs:element name="OutputParameter" type="tParameter"

1574             maxOccurs="unbounded"/>

1575           </xs:sequence>

1576          </xs:complexType>

1577         </xs:element>

1578        </xs:sequence>

1579        <xs:attribute name="name" type="xs:NCName" use="required"/>

1580       </xs:extension>

1581      </xs:complexContent>

1582     </xs:complexType>

1583     

1584     <xs:complexType name="tExportedOperation">

1585      <xs:choice>

1586       <xs:element name="NodeOperation">

1587        <xs:complexType>

1588         <xs:attribute name="nodeRef" type="xs:IDREF" use="required"/>

1589         <xs:attribute name="interfaceName" type="xs:anyURI"

1590          use="required"/>

1591         <xs:attribute name="operationName" type="xs:NCName"

1592          use="required"/>

1593        </xs:complexType>

1594       </xs:element>

1595       <xs:element name="RelationshipOperation">

1596        <xs:complexType>

1597         <xs:attribute name="relationshipRef" type="xs:IDREF"

1598          use="required"/>

1599         <xs:attribute name="interfaceName" type="xs:anyURI"

1600          use="required"/>

1601         <xs:attribute name="operationName" type="xs:NCName"

1602          use="required"/>

1603        </xs:complexType>

1604       </xs:element>

1605       <xs:element name="Plan">

1606        <xs:complexType>

1607         <xs:attribute name="planRef" type="xs:IDREF" use="required"/>

1608        </xs:complexType>

1609       </xs:element>

1610      </xs:choice>

1611      <xs:attribute name="name" type="xs:NCName" use="required"/>

1612     </xs:complexType>

1613     

1614     <xs:complexType name="tCondition">

1615      <xs:sequence>

1616       <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

1617      </xs:sequence>

1618      <xs:attribute name="expressionLanguage" type="xs:anyURI"

1619       use="required"/>

1620     </xs:complexType>

1621     

1622     <xs:complexType name="tTopologyElementInstanceStates">

1623      <xs:sequence>

1624       <xs:element name="InstanceState" maxOccurs="unbounded">

1625        <xs:complexType>

1626         <xs:attribute name="state" type="xs:anyURI" use="required"/>

1627        </xs:complexType>

1628       </xs:element>

1629      </xs:sequence>

1630     </xs:complexType>

1631     

1632     <xs:complexType name="tArtifactReference">

1633      <xs:choice minOccurs="0" maxOccurs="unbounded">

1634       <xs:element name="Include">

1635        <xs:complexType>

1636         <xs:attribute name="pattern" type="xs:string" use="required"/>

1637        </xs:complexType>

1638       </xs:element>

1639       <xs:element name="Exclude">

1640        <xs:complexType>

1641         <xs:attribute name="pattern" type="xs:string" use="required"/>

1642        </xs:complexType>

1643       </xs:element>

1644      </xs:choice>

1645      <xs:attribute name="reference" type="xs:anyURI" use="required"/>

1646     </xs:complexType>

1647     

1648     <xs:complexType name="tRequiredContainerFeatures">

1649      <xs:sequence>

1650       <xs:element name="RequiredContainerFeature"

1651        type="tRequiredContainerFeature" maxOccurs="unbounded"/>

1652      </xs:sequence>

1653     </xs:complexType>

1654     

1655     <xs:complexType name="tRequiredContainerFeature">

1656      <xs:attribute name="feature" type="xs:anyURI" use="required"/>

1657     </xs:complexType>

1658     

1659     <xs:simpleType name="tBoolean">

1660      <xs:restriction base="xs:string">

1661       <xs:enumeration value="yes"/>

1662       <xs:enumeration value="no"/>

1663      </xs:restriction>

1664     </xs:simpleType>

1665     

1666     <xs:simpleType name="importedURI">

1667      <xs:restriction base="xs:anyURI"/>

1668     </xs:simpleType>

1669     

1670    </xs:schema>

Appendix E.  Sample

This appendix contains the full sample used in this specification.

E.1 Sample Service Topology Definition

01  <Definitions name="MyServiceTemplateDefinition"

02               targetNamespace="http://www.example.com/sample">

03    <Types>      

04      <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

05                 elementFormDefault="qualified"

06                 attributeFormDefault="unqualified">

07        <xs:element name="ApplicationProperties">

08          <xs:complexType>

09            <xs:sequence>

10              <xs:element name="Owner" type="xs:string"/>

11              <xs:element name="InstanceName" type="xs:string"/>

12              <xs:element name="AccountID" type="xs:string"/>

13            </xs:sequence>

14          </xs:complexType>

15        </xs:element>

16        <xs:element name="AppServerProperties">

17          <xs:complexType>

18            <xs:sequence>

19              <element name="HostName" type="xs:string"/>

20              <element name="IPAddress" type="xs:string"/>

21              <element name="HeapSize" type="xs:positiveInteger"/>

22              <element name="SoapPort" type="xs:positiveInteger"/>

23            </xs:sequence>

24          </xs:complexType>

25        </xs:element>

26      </xs:schema>

27    </Types>

28   

29    <ServiceTemplate id="MyServiceTemplate">

30      

31      <Tags>

32        <Tag name=”author” value=”someone@example.com”/>

33      </Tags>

34   

35      <TopologyTemplate id="SampleApplication">

36   

37        <NodeTemplate id="MyApplication"

38                      name="My Application"

39                      nodeType="abc:Application">

40          <Properties>

41            <ApplicationProperties> 

42              <Owner>Frank</Owner>

43              <InstanceName>Thomas’ favorite application</InstanceName>

44            </ApplicationProperties>

45          </Properties>

46        </NodeTemplate>

47   

48        <NodeTemplate id="MyAppServer"

49                      name="My Application Server"

50                      nodeType="abc:ApplicationServer"

51                      minInstances="0"

52                      maxInstances="unbounded"/>

53   

54        <RelationshipTemplate id="MyDeploymentRelationship"

55                              relationshipType="abc:deployedOn">

56          <SourceElement id="MyApplication"/>

57          <TargetElement id="MyAppServer"/>

58        </RelationshipTemplate>

59   

60      </TopologyTemplate>

61   

62      <Plans>

63        <Plan id="DeployApplication"

64              name="Sample Application Build Plan"

65              planType="http://docs.oasis-

66               open.org/tosca/ns/2011/12/PlanTypes/BuildPlan"

67              planLanguage="http://www.omg.org/spec/BPMN/20100524/MODEL">

68   

69          <Precondition expressionLanguage="www.example.com/text"> ?

70            Run only if funding is available

71          </Precondition>

72   

73          <PlanModel>

74            <process name="DeployNewApplication" id="p1">

75              <documentation>This process deploys a new instance of the

76                sample application.

77              </documentation>

78   

79              <task id="t1" name="CreateAccount"/>

80   

81              <task id="t2" name="AcquireNetworkAddresses"

82                    isSequential="false"

83                    loopDataInput="t2Input.LoopCounter"/>

84                <documentation>Assumption: t2 gets data of type “input”

85                  as input and this data has a field names “LoopCounter”

86                  that contains the actual multiplicity of the task.

87                </documentation>

88   

89              <task id="t3" name="DeployApplicationServer"

90                    isSequential="false"

91                    loopDataInput="t3Input.LoopCounter"/>

92   

93              <task id="t4" name="DeployApplication"

94                    isSequential="false"

95                    loopDataInput="t4Input.LoopCounter"/>

96   

97              <sequenceFlow id="s1" targetRef="t2" sourceRef="t1"/>

98              <sequenceFlow id="s2" targetRef="t3" sourceRef="t2"/>

99              <sequenceFlow id="s3" targetRef="t4" sourceRef="t3"/>

100               </process>

101             </PlanModel>

102           </Plan>

103      

104           <Plan id="RemoveApplication"

105                 planType="http://docs.oasis-

106                  open.org/tosca/ns/2011/12/PlanTypes/TerminationPlan"

107                 planLanguage="http://docs.oasis-

108                  open.org/wsbpel/2.0/process/executable">

109             <PlanModelReference reference="prj:RemoveApp"/>

110           </Plan>

111         </Plans>

112      

113       </ServiceTemplate>

114      

115       <NodeType name="Application">

116         <documentation xml:lang="EN">

117           A reusable definition of a node type representing an

118           application that can be deployed on application servers.

119         </documentation>

120         <NodeTypeProperties element="ApplicationProperties"/>  

121         <InstanceStates>

122           <InstanceState state="http://www.example.com/started"/>

123           <InstanceState state="http://www.example.com/stopped"/>

124         </InstanceStates>

125         <Interfaces>

126           <Interface name="DeploymentInterface">

127             <Operation name="DeployApplication">

128               <InputParameters>

129                 <InputParamter name="InstanceName"

130                                type="xs:string"/>

131                 <InputParamter name="AppServerHostname"

132                                type="xs:string"/>

133                 <InputParamter name="ContextRoot"

134                                type="xs:string"/>

135               </InputParameters>

136             </Operation>

137           </Interface>

138         </Interfaces

139       </NodeType>

140      

141       <NodeType name="ApplicationServer"

142                 targetNamespace="http://www.example.com/sample">

143         <NodeTypeProperties element="AppServerProperties"/>

144         <Interfaces>

145           <Interface name="MyAppServerInterface">

146             <Operation name="AcquireNetworkAddress"/>

147             <Operation name="DeployApplicationServer"/>

148           </Interface>

149         </Interfaces>

150       </NodeType>

151      

152       <RelationshipType name="deployedOn">

153         <documentation xml:lang="EN">

154           A reusable definition of relation that expresses deployment of

155           an artifact on a hosting environment.

156         </documentation>

157       </RelationshipType>

158      

159     </Definitions>

Appendix F.  Revision History

 

Revision

Date

Editor

Changes Made

wd-01

2012-01-26

Thomas Spatzier

Changes for JIRA Issue TOSCA-1:

Initial working draft based on input spec delivered to TOSCA TC. Copied all content from input spec and just changed namespace. Added line numbers to whole document.

wd-02

2012-02-23

Thomas Spatzier

Changes for JIRA Issue TOSCA-6:

Reviewed and adapted normative statement keywords according to RFC2119.

wd-03

2012-03-06

Arvind Srinivasan, Thomas Spatzier

Changes for JIRA Issue TOSCA-10:

Marked all occurrences of keywords from the TOSCA language (element and attribute names) in Courier New font.

wd-04

2012-03-22

Thomas Spatzier

Changes for JIRA Issue TOSCA-4:

Changed definition of NodeType Interfaces element; adapted text and examples

wd-05

2012-03-30

Thomas Spatzier

Changes for JIRA Issue TOSCA-5:

Changed definition of NodeTemplate to include ImplementationArtifact element; adapted text

Added Acknowledgements section in Appendix

wd-06

2012-05-03

Thomas Spatzier,

Derek Palma

Changes for JIRA Issue TOSCA-15:

Added clarifying section about artifacts (see section 3.2);

Implemented editorial changes according to OASIS staff recommendations;

updated Acknowledgements section

wd-07

2012-06-15

Thomas Spatzier

Changes for JIRA Issue TOSCA-20:

Added abstract attribute to NodeType for sub-issue 2;

Added final attribute to NodeType for sub-issue 4;

Added explanatory text on Node Type properties for sub-issue 8

wd-08

2012-06-29

Thomas Spatzier, Derek Palma

Changes for JIRA Issue TOSCA-23:

Added interfaces and introduced inheritance for RelationshipType; based on wd-07

Added reference to XML element and attribute naming scheme used in this spec

wd-09

2012-07-16

Thomas Spatzier

Changes for JIRA Issue TOSCA-17:

Specifies the format of a CSAR file;
Explained CSAR concept in the corresponding section.

wd-10

2012-07-30

Thomas Spatzier,
Derek Palma

Changes for JIRA Issue TOSCA-18 and related issues:

Introduced concept of Requirements and Capabilities;

Restructuring of some paragraphs to improve readability

wd-11

2012-08-25

Thomas Spatzier,
Derek Palma

Changes for JIRA Issue TOSCA-13:
Clarifying rewording of introduction

Changes for JIRA Issue TOSCA-38:
Add substituableNodeType attribute and BoundaryDefinitions to Service Template to allow for Service Template composition.

Changes for JIRA Issue TOSCA-41:
Add Tags to Service Template as simple means for Service Template versioning;

Changes for JIRA Issue TOSCA-47:
Use name and targetNamespace for uniquely identifying TOSCA types;

Changes for JIRA Issue TOSCA-48 (partly):
implement notational conventions in pseudo schemas

wd-12

2012-09-29

Thomas Spatzier,
Derek Palma

Editorial changes for TOSCA-10:
Formatting corrections according to OASIS feedback

Changes for JIRA Issue TOSCA-28,29:
Added Node Type Implementation (with deployment artifacts and implementation artifacts) that points to a Node Type it realizes; added Relationship Type Implementation analogously for Relationship Types

Changes for JIRA Issue TOSCA-38:
Added Interfaces to BoundaryDefinitions.

Changes for JIRA Issue TOSCA-52:
Removal of GroupTemplate

Changes for JIRA Issue TOSCA-54:
Clarifying rewording in section 3.5

Changes for JIRA Issue TOSCA-56:

Clarifying rewording in section 2.8.2

Changes for JIRA Issue TOSCA-58:
Clarifying rewording in section 13

Updated roster as of 2012-09-29

wd-13

2012-10-26

Thomas Spatzier,
Derek Palma

Changes for JIRA Issue TOSCA-10:
More fixes to formatting and references in document according to OASIS staff comments

Changes for JIRA Issues TOSCA-36/37:

Added PolicyType and PolicyTemplate elements to allow for re-usable definitions of policies.

Changes for JIRA Issue TOSCA-57:
Restructure TOSCA schema to allow for better modular definitions and separation of concerns.

Changes for JIRA Issue TOSCA-59:
Rewording to clarify overriding of deployment artifacts of Node Templates.

Some additional minor changes in wording.

Changes for JIRA Issue TOSCA-63:
clarifying rewording

wd-14

2012-11-19

Thomas Spatzier

Changes for JIRA Issue TOSCA-76:
Add Entry-Definitions property for TOSCA.meta file.

Multiple general editorial fixes:
Typos, namespaces and MIME types used in examples

Fixed schema problems in tPolicyTemplate and tPolicyType

Added text to Conformance section.

wd-15

2013-02-26

Thomas Spatzier

Changes for JIRA Issue TOSCA-79:

Handle public review comments: fixes of typos  and other non-material changes like inconsistencies between the specification document and the schema in this document and the TOSCA schema

wd-16

2013-04-15

Derek Palma,
Thomas Spatzier

Changes for JIRA Issue TOSCA-82: Non-material change on namespace name use

Changes for JIRA Issue TOSCA-83: fix broken references in document