Copyright © 2012 the Contributors to the Cloud Computing 1.0 Specification, published by the Cloud Computing Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available.
This specification was published by the 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 Final Specification Agreement (FSA) other conditions apply. Learn more about W3C Community and Business Groups.
The default namespace for in this specification (using the "cloud" prefix in a RIF context) is http://www.w3.org/ns/cloud
The other namespaces used in this specification are given in the following table:
| Prefix | Namespace | Notes | |
|---|---|---|---|
| rif | http://www.w3.org/2007/rif | Rule Interchange Format | |
| xs | http://www.w3.org/2001/XMLSchema | XML Schema | |
| xlink | http://www.w3.org/1999/xlink | used for hyper-links (via "xlink:href") | |
| xml | http://www.w3.org/1998/Namespace | used for element IDs (via "xml:id") |
This specification depends, for the computational content of its nodes, on the algorithmic modelling Reference Model
This specification details a model for location-transparent, distributed computation and storage, collectively and commonly known as "cloud processing"
The model is realised in the form of an XML document
containing both the physical topography and logical
content of the set of "nodes", classified into classes,
collectively providing some "cloud service"
Each of these nodes classes consist of a set of
constituent nodes, each defined in terms of its
membership, when evaluated, in a RIF rule-set
derived from the "rule" grammar production of the
Condition Language of the RIF Basic Logic Dialect
[BLD]
As well as having an ID, classes may also
be referenced by name, using the value of the
"name" attribute
Such predicates may either appear directly,
as the descendant elements of a "class" element,
or may be indirectly referenced through use of
the "xlink:href" attribute of the "class" element
These "class" elements may be nested within
each other, in which case the predicates of
the ancestor class include those of the nested
descendant classes
Although node network addresses assignment
itself is not performed within this specification,
such assigned addresses are, however, used by the
afore-mentioned address-related predicates
The following example illustrates a node class
consisting of less than 9 nodes in the "125.9"
IP sub-net, having an accumulated storage capacity of
100 tera-bytes and each constituent node having an
average load of 0.4 over the previous ten seconds
Note that the former two criteria are included
with the latter two due to the reference to the
class defining the latter two criteria is appears
within a nested class of the class defining the
former two
the parameters to effect the computational model's
execution appear in the form of a "params" element,
the element children of which each represent a
parameter, the value of the "name" attribute of
which names the parameter, and the value of the
"value" attribute of which specifies an opaque
reference to the value of the parameter
value
these parameters, once declared, remain
"in-scope", and therefore useable by the
"param-has-value" predicate, for the
remainder of the document
The following example illustrates a parameter
list containing two parameters named "x" and "y"
Only an owning node may modify an artefact:
attempts to modify artefacts by a node other
than the owning node will engage transactional
semantics
The owning node may then choose the successful node
from among the requesting nodes, after which point
the actual ownership itself transfers
The following example illustrates an ownership
retransfer request for an artefact, using a
certificate located at
"http://www.example.com#x.cert"
the service element may contain one
or more "wsdl" attributes, the value of each of
which contains a reference to a WSDL end-point
[WSDL
] the service provides, the absence of any which
indicates the service does not implement such an
end-point and one or more "sparql" attributes, the
value of each of which contains a reference to a
SPARQL end-point [
SPARQL] the service provides, the absence
of any which also indicates the service does not
implement such an end-point
The following example demonstrates a service
having two WSDL end-points and a SPARQL end-point
Each topological state of a cloud service is
represented by a "topology" element, consisting
of one or more "node" sub-elements, each
representing a node configuration of the cloud,
and one or more "link" sub-elements, representing
a link between two of these configurations
As with the "service" element, the "topology"
element itself may contain one or more "wsdl"
attributes, the value of each of which contains
a reference to a WSDL end-point [WSDL] the topological
state provides, the absence of any which indicates
the state does not implement such an end-point and
one or more sparql" attributes, the value of each
of which contains a reference to a SPARQL end-point
[SPARQL
] the state provides, the absence of any of
which also indicates the state does not implement
such an end-point
The element may also contain a "state"
attribute, the value of which contains the
State Chart state [SCXML] this topological state
represents
The following example demonstrates
a topological state providing a WSDL and
a SPARQL end-point and represents the
State Chart state "state"
Each "node" element appearing in a "topology"
element represents a class of node present in the
cloud. The class may be either referenced by ID
(using the "xlink:href" attribute), by selector
(using the "selector" attribute), or by class
name (using the "class" attribute).
The "storage" attribute references the ID of a
storage object (see below) constituting the storage
the node class uses
The following example demonstrates three node
elements, the first referencing the selector "a, b"
[SELECTORS
] having ID "x", the second referencing a
class named "y" and the third referencing a class
named "h", the first using a storage object with ID
"h" and the second and third sharing a storage
object with ID "c"
The "link" element represents a nested topological
link between two node classes, as embodied in
references to the two "node" elements constituting
the values of the "from" and "to" attributes of
the "link" element
Where the element is nested, the links
present in its ancestor elements provide s
computational context for those located in
the element
The following example demonstrates a link
between two "node" elements having IDs "a"
and "b", respectively
The storage element declares storage that
various "node" elements may then reference and
(when multiple node elements reference the
same storage), possibly share
The content of the storage is constituted
of an XML serialisation of those children
appearing in the element content, along
with the recursive storage content of nested
"storage" elements, and the storage specified
by the "storage" attribute, the value of
which contains an IRI specifying, when
resolved, the (possibly binary) content
of the storage
The following example demonstrates a
storage element consisting of three literal
sub-elements, the content of the first "storage"
element and the binary content resolved from
"http://www.example.com#binary"
The paths through which topological faults
propagate through the cloud, and the actions
this propagation generates, may be specified
by the use of a "fault" element
Each propagation path is specified in the
the form the sequence of direct children of
the "fault" element
The element itself may also possess a "type"
attribute, the value of which specifies XML
Schemas type of the generated fault, and a
"class" attribute, the value of which
identifies the node class generating the
fault
The values of the several
fault-related attributes of each child
describes the behaviour of the fault, once
generated, at the point in the path
corresponding to that child
The "type" attribute, for example,
specifies the XML Schemas type [
SCHEMAS ] of the fault,
as propagated to the child
The value of the "class" attribute
specifies the class of node propagating
to the child
The value of the "action" attribute
specifies the algorithmic model
"process" element representing the action
to be taken by the child on receiving
the fault
The following example demonstrates a
fault of XML Schemas type "#x", generated
by nodes of class "#b", which are propagated
through nodes "a", "b" and "c", over which
the fault transforms through the XML Schema
affecting nodes of class "#m", "#n" and
"#o", and through types "#I", "#j" and "#k",
respectively, causing the execution of model
"process" elements having the IDs, "m", "#n"
and "#o", respectively
Each computational state of a cloud service is
represented by a "content" element, consisting
of one or more "node" sub-elements, each
representing a node class of the cloud,
and one or more possibly transforming "message"
sub-elements, each representing a message
between two node classes
As with the "service" and "topology" elements,
the "content" element may contain one or more "wsdl"
attributes, the value of each of which contain
a reference to a WSDL end-point the topology
provides, the absence of any which indicates the
service does not implement such an end-point, one
or more sparql" attributes, the value of each
of which contains a reference to a SPARQL end-
point the state provides, the absence of any of
which also indicates the state does not implement
such an end-point and one or more "component"
attributes, the value of which contains a
reference to a Web Component the
state implements, the absence of any which again
indicates the state does not implement such a
component
.
The element may also contain a "state"
attribute, the value of which contains the
State Chart state this computational state
represents
The following example demonstrates
a computational state providing WSDL and
SPARQL end-points, implementing a web
component and representing the State
Chart state "state"
Each nested "node" element appearing in a
"content" element represents the computational
characteristics of a class of nodes present
in the cloud. The class may be either referenced
by its ID (using the "xlink:href" attribute), by
selector (using the "selector" attribute), or by
class name (using the "class" attribute)
Where the element is nested, the nodes
present in its ancestor elements provide s
computational context for those carried out by
element's constituent nodes
The "distrib" attribute specifies the load
distribution model the node class uses, which may
be one of (with accompanying definitions):
The "content" attribute references the ID of
an algorithmic model element constituting the
computational content of the node, the value
of the "params" attribute referencing a "params"
element containing the computation's
parameters
The following example demonstrates three node
elements, the first referencing the selector "x, #y",
the second referencing a class named "h" and the
third referencing a class with ID "y", each using,
as content, model elements with IDs "#a", "#b"
and "#c", respectively, using "balanced", "ordered"
and "random" load distribution models, respectively,
the last using computation parameters located at
"#params"
Message elements represent (possibly
nested) messages, of the type given in
the XML Schema type referenced in the
value of the element's "type" attribute,
transmitted from the node class referenced
in the value of the "src" attribute to
the node class referenced in the value of
the "dst" attribute, transforming the cloud,
after the message has been received, from
the computational state referenced in the
value of the "from" attribute to the
computational state referenced in the value
of the "to" attribute, an absence of the
"from" and "to" attributes indicating no
such transformation occurs
The value of the "cond" attribute
specifies an XPath expression indicating, when
evaluating to a non-zero value, the
condition under which the message
should be sent, the absence of which
indicates the message is sent
unconditionally
Where the element is nested, the messages
present in its ancestor elements provide a
messaging context for those present in the
element
The following example demonstrates a
message sent, on condition that its
"x" attribute is equal to its "y"
attribute, of an XML Schemas type with
ID "g", sent from node class element
"x" to node class element "y",
transforming the cloud from a state
with ID "a" to ID "b"
The handling of computational faults within the
cloud are declared identically, and have identical
semantics to those of topological faults
4 Classes
4.1 Predicates
The standard RIF predicate set used to evaluate
class membership is augmented with the following,
cloud-specific, predicates:
cloud:has-addr - holds when the
relevant node has the exact address (explained
below) given in the first argument
cloud:addr-matches - holds when the
relevant node's address matches the
ECMAScript-style regular expression given in
the first argument
cloud:has-number - holds when the
number of nodes in the relevant node's class
is the number given in the first argument
cloud:from-number - holds when the
number of nodes in the relevant node's class
is at least the number given in the first
argument
cloud:to-number - holds when the
number of nodes in the relevant node's class
is at most the number given in the first
argument
cloud:in-number - holds when the
number of nodes in the relevant node's class
is between the numbers given in the first and
second arguments
cloud:has-storage - holds when the
relevant node has at least the amount of storage
(in bytes) given in the first argument
cloud:from-storage - holds when the
relevant node has at least the amount of storage
(in bytes) given in the first argument
cloud:to-storage - holds when the
relevant node has at most the amount of storage
(in bytes) given in the first argument
cloud:has-accumulated-storage - holds
when the accumulated storage capacity of all
nodes in the relevant node's class has the
collective storage capacity (in bytes) given in
the first argument
cloud:from-accumulated-storage - holds
when the accumulated storage capacity of all
nodes in the relevant node's class has at least
the collective storage capacity (in bytes)
given in the first argument
cloud:to-accumulated-storage - holds
when the accumulated storage capacity of all
nodes in the relevant node's class has at most
the collective storage capacity (in bytes)
given in the first argument
cloud:has-load - holds when the
class of the relevant node has had the
average load (explained below) given in the
first argument over the previous number of
seconds given in the second argument
cloud:to-load - holds when the
class of the relevant node has had at most
the average load given in the first parameter
over the previous number of seconds given in
the second argument
cloud:from-load - holds when the
class of the relevant node has had at least
the average load given in the first argument
over the previous number of seconds given in
the second argument
cloud:in-load - holds when the
relevant node class has an average load
between those given the first and second
arguments over the previous number of
seconds given in the third argument
cloud:param-has-value - holds
when the parameter named in the first
argument has the value given in the
second argument
What other predicates should be included,
and what are their semantics?
4.2 Addressing
Should address families be specified and, if so,
what form should they take?
4.3 Loading
Node computational loading, as specified within
predicates, is expressed as a floating-point
number between 0 (indicating no load) to 1
(indicating maximum load) The calculation of
this loading is, however, performed in an
implementation-specific manner
Should loading profiles be considered?
<class xml:id="x">
<rif:And>
<rif:Atom>
<rif:op>cloud:accumulated-storage
</rif:op>
<rif:args rif:ordered="yes">
<rif:const type="xs:integer">
100e12</rif:const>
</rif:args>
</rif:Atom>
<rif:Atom>
<rif:op>cloud:load</rif:op>
<rif:args rif:ordered="yes">
<rif:const type="xs:float">
0.4</rif:const>
<rif:const type="xs:integer">
100</rif:const>
</rif:args>
</rif:Atom>
</rif:And>
</class>
<class>
<rif:And>
<rif:Atom>
<rif:op>cloud:number</rif:op>
<rif:args rif:ordered="yes">
<rif:const type="xs:integer">
9</rif:const>
</rif:args>
</rif:Atom>
<rif:Atom>
<rif:op>cloud:addr-matches</rif:op>
<rif:args rif:ordered="yes">
<rif:const type="xs:string">
125\.9\.\*\.\*</rif:const>
</rif:args>
</rif:Atom>
</rif:And>
<class xlink:href="#x" />
</class>
4.4 Computational parameters
<params>
<a name="x" value="#a">
<b name="y" value="#b">
</params>
Should parameter values have types?
5 Ownership
Each run-time artefact has an associated
"owner" node which is, on creation, set
to the node creating the artefact.
5.l Ownership Transfer
A node requesting ownership of an artefact should send
an "owner_request" to the node owning the
artefact, consisting of an XML document containing a
single element with the tag "owner_request", having
an attribute named "artefact" containing a reference
to the artefact and an attribute named "credentials"
containing a reference resolving to an X509 certificate
representing the credentials of the requesting node
<owner_request artefact="#x"
credentials="http://www.example.com#x.cert" />
How is the success of the ownership transfer to
be communicated?
6 Cloud Model Elements
A cloud service consists of an XML document
containing the following elements:
6.1 The <service>
element
A cloud service is represented by a top-level
"service" element, consisting of a "params"
sub-element containing service parameters, one
or more "class" sub-elements, each representing
a node class, one or more "topology"
sub-elements, each representing a topological
state of the cloud, and one or more "content"
sub-elements each representing a computational
state of the cloud
<service wsdl="http://www.example.com#wsdl1"
wsdl="http://www.example.com#wsdl2"
sparql="http://www.example.com#sparql">
... <!-- content --> ...
</service>
5.2.1 The <topology>
element
<topology wsdl="http://www.example.com#wsdl"
sparql="http://www.example.com#sparql"
state="#state">
<!-- content --> ...
</topology>
5.2.1.1 The <node>
element
<node storage="#h" xml:id="x" selector="a, b" />
<node storage="#c" xml:id="y" class="y" />
<node storage="#c" xml:id="z" xlink:href="#h" />
5.2.1.1 The <link>
element
<link from="#a" to="#b" />
Should the address interfaces
participating in the link be specified?
5.2.1.2 The <storage>
element
<storage>
<a />
<b />
<storage>
<c />
</storage>
<storage storage=
"http://www.example.com#binary" />
</storage>
Should devices of storage objects be addressed?
5.2.1.3 The <fault>
element
<fault type=#x class="#b">
<a type="#u" action="#n" class="#i" />
<b type="#v" action="#m" class="#j" />
<c type="#w" action="#o" class="#k" />
</fault>
4.1.5.2.2 The <content>
element
<content wsdl="http://www.example.com#wsdl"
sparql="http://www.example.com#sparql"
component="http://www.example.com#cmpnt"
state="#state">
<!-- content --> ...
</content>
Which model elements may constitute this computational
content?
5.2.1 The <node>
element
ordered - uses a
predictable, repetitive ordering of
participating nodes
random - uses a (pseudo)
random selection of participating nodes
balanced - attempts an
adaptive, real-time equalisation of
loading amongst each of the
participating nodes
What other load distributions should be
considered?
<node selector="x, #y"
distrib="balanced"
content="#a" />
<node class="h"
distrib="ordered"
content="#b" />
<node xlink:href="#y"
distrib="random"
content="#c"
params="#params" />
Are there any other ways to specify node
classes?
5.2.3 <message>
element
<message type="#g" cond="@x = @y"
src="#x" dst="#y"
from="#a" to="#b" />
Should there be a way to specify
a process to execute to perform the
state transformation?
5.2.4 <fault> element
References