This specification was published by the W3C Cloud Computing Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA). There is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups
- 1 Namepaces
- 2 Introduction
- 3 The Computational Model
- 3.1 Component Compositing
- 3.2 Event Propagation
- 3.3 General Grouping
- 3.4 Creation of Type Hierarchy
- 3.5 Computational Load Apportioning
- 3.6 State Machine Transitioning
- 3.7 Object Group Stereotyping
- 3.8 Imperative Processing
- 3.9 Inter-process Synchronisation
- 3.10 Object Storing
- 3.11 Message Timing and Sequencing
The default namepace used in this specification is "http://www.w3.org/ns/cloud". The namepace for XML Schemas, used to represent types in the model's type system, is "http://www.w3.org/2001/XMLSchema"
The term "cloud computation" refers to the specification of a model for some form computation that may be implemented without regard to that computation's geographical location or topographical distribution
A "model" refers to a description of the structure and relative dynamic behaviour of tgwhe sub-parts of some system
This specification describes an XML document, itself describing a computational model tailored specifically to implementation in a cloud environment
Elements in such a document may appear, anywhere in the document, having a namespace from other than that defined in this specification
Theterm "cloud element" refers ti an XML element, appearing in a model document whose nsmespace mstches that of the bamespsce defined in this specification, while a "non-cloud element" is an element appearing from any other namespace
The presence of each of these non-cloud elements appearing, verbatim, in a model docuement causes the creation, at run-time, of a corresponding "artefact", operating within the implementation's run-time environment, each of which are then transformed in some way. due to the presence of one of more (possibly nested) cloud elements
While these run-time artefacts are, generally. some type of XML Information Item, but nay also data in other formats may also be referenced through the use of a special attribute named "opaque", whose value contains a URL which will, when resolved , yield the opaque data
Storage and Ownership
Each run-time artefact contains a special attribute named "owner" shich is, on creation, set to the node creating the artefact.
Only the same node as that owning the object may modify that object: attempts at modification by non-owning nodes will engage transactional semantics.
A node requesting ownership of an artefact should send an "ownership change request" to the node urrentlng owning the artefact, consisting of an XML document containng a single elemente ewith the tag "owner_request", an attribute named "artefact" containing a reference to the artefsvt and an attribute named "credentials" cntaining a reference resolving to an X509 certificate representing the credcitals of the requesting node
the owning node may then choose the usccessful node from among the requesting nodes, after which point ownership transfers
There are several attributes common to most (if not all) model elements:
- Where the model describes a conceptual system, any element in that model may possess a "fact" attribute containing a reference to that element's corresponding OWL individual and a "concept" attribute referring to its corresponding OWL class
- Related elements may possess a "constraint" sub-element containing an XPath expression evaluating to a non-zero value when the constraint holds
- Any element may possess an "xml:id" attribute whose value represents the "identity" of the element and which serves as the content of the fragment identifier, when that relenment is referenced, from either another part of the same or a different document, by URL. In the remainder of this specification, references to an elelement's "ID" will refer to this attribute
The Computational Model
Computation within the model may consist of any nested combination of the following: (each item below will be further discussed as are introduced)
- Component compositing
- Event propagation
- General grouping
- Creation of type hierarchy
- Computational load apportioning
- State machine transitioning
- Imperative processing
- Object group stereotyping
- Inter-process synchronisation
- Object storing
- Message timing and sequencing
This aspect of the model refers to the definition of callable interfaces that may be composed onto each other at run-time. This is specified through the use of two attributes: a "provides" attribute, the value of which references the element of the provided component interface and a requires" attribute, the value of which references the element of the required component interface.
Both attributes may appear multiple times to specify multiple provided and required (respectively) interfaces
Event propagation describes how, in a manner similar to that outlined in DOM Events, an "event" element, when "fired" (a process caused by the presence of a "fire" element, whose "type" attribute contains the ID of the interface element constituting the event type in its containing "process" element when that element is processed), that fired event is either re-transmitted ("propagated") or "handled by" (re-routed to) a defined "handler" process at each element in the event's propagation path
Such handlers are defined by a "handler" element, the value of whose "action" attribute contains a reference to the "process" element constituting the handling routine and the value of whose "type" attribute contains a reference to an interface element of the event type to be handled
An event type itself is specified in the form of amn "event" element, consisting of a "derives" attribute, the value of which references the "event" element from which it derives and an "action" attribute, the value of which references the process element implementing the event's "default action"
The "group" element places all elements in the sub-tree of the element in a group, such that the functionality represented in those elements will act as a single "unit" (as seen externally)
Creation of Type Hierarchy
Several elements, namely "class", "interface", "namespace" and "alias", contribute to the a "type-space", All three elements create a type whose name, given in the value of the "name" attribute, is made visible in each's enclosing namespace.
The "class" element declares a "storage template", whose nameable "fields", are formed from the children of the element, the names and types are given in the value of each's "name" and "type" attribute, respectively, where types being taken from XML Schemas.
Callable fields, known as "methods", are identified by the presence of a "returns" attribute whose value contains the method's return type, and a contained "parameters" element, whose children represent teach parameter type. Run-time objects are, themselves, typed from the template specified in one of these "class" elements.
The "interface" element, whose declaration is otherwise identical to the "class" element, is used in two different roles: as the presented interface of an event and as a callable component interface.
The "namespace" element adds a general "grouping" mechanism, also addressable by the value of the "name" attribute, to the type system.
The "alias" element adds a "reference" from the location of the type hierarchy given in the "from" attribute, or to the location represented by the location of the "alias" element by default
Computational Load Apportioning
The load balance between types (or "classes") of nodes may be set via the "loads" element.
The region within the model to which this balancing applies is implicitly restricted to lie within the range represented by the element's location within the model document
This "loads" element contains a "classes" element, itself containing a set of "class" elements, each of which, through each's "name" and "description" attribute, represents an association between the ID and description, respectively, of the a that class
Following the "classes" element is either a "values" element or a "curves" element.
The "values" element represent a a constant proportional (of the total contained in all classes) load, and consists of a comma-separated list of floating-point numbers in the range [0 - 1] representing the load of each class.
The presence of a "curves" element, however, indicates that the load distribution is specified via a set of "curve" elements, each of which consists of a set of "pt" elements, the ctext content of which contains a comma-separated lst of floating-point numbers, the last of thehich is a proportional load.
Yhese numbers represent the co-ordinates in "n"-space (where "n" is the number of classes) specifying the control points of a Bezier curve of the load (as a proportion of the total load on all classes) carried by the class
State Machine Transitioning
The model may specify that objects should transition between different "states" under certain controlled conditions, constituting a so-called "finite state machine" (FSM)
The states of this FSM are each specified by a "state" element, whose ID attribute identifies the state for use by its transitions.
Each transition is represented by a "transition" element, the values of the "from", "to", "test" and "exec" attributes of which specify the IDs of the source and destination, respectively, states of the transition, the value of "test" attribute of which contains sn XPath expression which, when evaluating to non-zero, indicates the transition should be executed and the ID of the process to execute when the transition occurs, respectively
Object Group Stereotyping
The "stereotype" element creates a "template" instantiated by a group of run-time objects matching the selector given in the element's "select" attribute
This element contains one or more "role" elements
Each of these "role" elements translate, when instantiated, to a single run-time object, the identity of which, from amongst these instantiated objects, is set by a reference to that element in the object's "role" attribute
Constraints holding between the "role" element and other elements in the "stereotype" element's sub-tree also hold in the instantiated object group
The term "imperative Processing", refers to a set of "imperative" elements transforming, at run-time, a stream of artefacts, designated the "input stream" of that process . Whenever an artefact arrives on the input, the orces is "tranformed", repeatedly, once for each ekement om throrocess, in a manner dictated ny the type of thst element
This element consists of a "parameters" element, the children of which represent the parametera formal parameters of the process, followed by an element children of which constitute the "statements" of the process.
Each of hese parameters rchobots a "type", as a reference to each's XML Schema type, in the value of its "type" sttribute
Imperative elements ,ay gave any local names and be from any namespaces, each having (possibily) implmentation-specific meanings, but the pre-defined statements are:
- fire - fire an event whose type is referenced in the "type" attribute
- choice - if the XPath expression in the value of the "test" attribute evaluates to non-zero, transfer execution to the location referenced in the "true" attribute, otherwise transfer execution to the location referenced in the "false" attribute
- ''var - declare the local variable whose name is given in the value of the "name" attribute and whose type is given by reference to the XML Schema type given in the value of the "type" attribute
- use - use the component interface referenced in the value of the "interface" attribute
- get - get the value of the oarameter referenced in the value of the "from" attribute
- set - set the value of the oarameter referenced in the value of the "to" attribute
- acc - get the value of the local variable referenced in the value of the "from" attribute
- put - set the value of the local variable referenced in the value of the "to" attribute
- alloc - allocates the object of class referenced in the "class" attribute to in the storage object referenced in the "storage" attribute
- call - call the process referenced in the the "process" attribute, taking input from the output generated from the process whose ID is refenced om th value of the "input" attribute (by default receiving no input) and geberating putput to the process whose ID is referenced in the value of the "output" sttribute (by default generating no output)
- step - call the XProc step referenced in the value of the "step" attribute
This aspect of the model refers to the capability of a process to wait to start until signalled by the process identified by the content of the element's "wait_on" attribute, and to notify when completed, the process identified by the content of the element's "notify" attribute.
A process may also contain a "stores" attribute referencing a storage object the content to which it may have tread/write access which, by virtue of several such processes referencing the same storage object, allows these objects to exhibit multi-threaded behaviour
The element used to create an uninitialised object store is the "storage" element. The size of the store is specified by the value of the "size" attribute, which consists of a floating-point size representing the size of the storage (in bytes) followed by a magnitude prefix: k", "M", "G" and "T" for kilo-, mega-, giga- and tera-, respectively
By default, all run-time objects associated with those elements appearing in the sub-tree of the "storage" element are placed into the storage object created by that "storage" element, although the presence of a "part_of" attribute causes such objects to be instead placed into the storage object identified by the value of that attribute, used in ituations in which the storage contributes to some other, larger storage
These "storage" elements may also be nested (in which case run-time objects are placed into the storage object of the nearest enclosing "storage" element) allowing finer-grained control over such storage
Implementations may choose to provide a mechanism by which such storage objects may also serve as the content of Web Storage objects
Message Timing and Sequencing
The timing of messages between objects and the relative order of these messages may be specified through use of rhe "messaging" element
Within this element are located a "path" element, a set of "object" elements and a set of "message" elements
The "path" element contains an element sub-tree the children of which represent the path of objects, within the model, for which messaging is specified
Each "object" element represents a single "life-time" (the period over ewhich an object may wait on and be responsive to messages) of one the objects in the path
This element may contain an ID, a "creator" attribute the value of which references the message starting the life-time, a "destructor" attribute the value of which references the message ending the life-time, an "after" attribute the value of which references the message that must end before this life-time may start and a "before" attribute the value of which references the message that must start before this life-time may end
Each "message" element represents a single message in the set of message set being examined, he value of the "type" attribute of which references the "interface" element representing the "type" of the messageThis element may also contain an ID, an "after" attribute the value of which references the message that must end before this message may start, a "before" attribute the value of which references the message that must start before this message may end and a "delta" attribute containing the delay (in milliseconds) after receiving a "start" signal (as specified in the "after" attribute) before the message should be sent