Cloud Computation

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

Namepaces

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 namespace "xml" (used to specify element IDs) is bound, as per the XML specification, to the namespace "http://www.w3.org/XML/1998/namespace"

Introduction

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.

Ownership Changes

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

Common Attributes

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

Component Compositing

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

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"

General Grouping

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

Imperative Processing

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

Inter-process Synchronisation

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

Object Storing

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 message

This 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