W3C

Cloud Processing Model

Syntax and Processing of a Model for the Providing of a Computational Cloud Service

Final Community Group Report 22 April 2013

Latest editor's draft:
http://www.sr2u.com/w3c/cloud-mdl-20121211.html

Editor:
Russell Potter


Status of This Document

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.

Table of Contents

1 Namespaces
2 Dependency
3 Introduction
4 Classes
4.1 Predicates
4.2 Addressing
4.3 Loading
4.4 Computational Parameters
5 Ownership
5.1 Ownership Transfer
6 Cloud Model Elements
6.1 The <service> element
6.2.1 The <topology> element
6.2.1.1 The <node> element
6.2.1.2 The <link> element
6.2.1.3 The <storage> element
6.2.1.4 The <fault> element
6.2.2 The <content> element
6.2.2.1 The <node> element
6.2.2.2 The <message> element
6.2.2.3 The <fault> element

1 Namespaces

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:

PrefixNamespaceNotes
rifhttp://www.w3.org/2007/rifRule Interchange Format
xshttp://www.w3.org/2001/XMLSchema XML Schema
xlinkhttp://www.w3.org/1999/xlink used for hyper-links (via "xlink:href")
xmlhttp://www.w3.org/1998/Namespace used for element IDs (via "xml:id")

2 Dependency

This specification depends, for the computational content of its nodes, on the algorithmic modelling Reference Model

3 Introduction

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"

4 Classes

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

4.1 Predicates

The standard RIF predicate set used to evaluate class membership is augmented with the following, cloud-specific, predicates:
What other predicates should be included, and what are their semantics?

4.2 Addressing

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

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?

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


<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

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"


<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.

Only an owning node may modify an artefact: attempts to modify artefacts by a node other than the owning node will engage transactional semantics

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

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"


<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

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


<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

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"


<topology wsdl="http://www.example.com#wsdl"
             sparql="http://www.example.com#sparql"
             state="#state">

    <!-- content --> ...

</topology>

5.2.1.1 The <node> element

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"


<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

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


<link from="#a" to="#b" />

Should the address interfaces participating in the link be specified?

5.2.1.2 The <storage> element

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"


<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

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


<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

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"


<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

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):

What other load distributions should be considered?

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"


<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 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"


<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

The handling of computational faults within the cloud are declared identically, and have identical semantics to those of topological faults

References

[BLD]
Michael Kifer; Harold Boley Basic Logic Dialect. 5 February 2013. W3C Recommendation. URL: http://www.w3.org/TR/rif-bld/
[WSDL]
Erik Christensen; Francisco Curbera; Greg Meredith SPARQL 1.1 Query Language. 15 March 2001. W3C Note. URL: http://www.w3.org/TR/wsdl
[SPARQL]
Steve Harris; Andy Seaborne SPARQL 1.1 Query Language. 21 March 2013. W3C Working Group Note. URL: http://www.w3.org/TR/sparql11-query/
[SCXML]
Michael Kifer; Harold Boley State Chart XML (SCXML): State Machine Notation for Control Abstraction. 23 August 2012. W3C Working Draft. URL: http://www.w3.org/TR/scxml/
[SELECTORS]
Elika J. Etemad Selectors Level 4. 5 February 2013. W3C Working Group Note. URL: http://www.w3.org/TR/selectors4/
[SCHEMAS]
David C. Fallside; Priscilla Walmsley XML Schema Part 0: Primer Second Edition. 28 October 2004. W3C Recommendation. URL: http://www.w3.org/TR/xmlschema-0/