Cloud Computing Use Cases

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

Definitions

Computation

Process by which data in some system transforms in some some way over some period of time

Node

Entity performing the computation within some system

Storage

The persistent maintenance of information

Artefact

information forming either a set of one or more Information Items or a reference to da in some other format

Artefact Space

A designation of membership of an artefact to some category or group, identified by IRI

Region

A set of artefacts constituting some sub-set of an artefact space

Balance

The property of one or more Nodes in which the computational or storage load on each is approximately equalised with that of each of the Nodes in the set

Visibility

Phenomenon in which a Node is able to read the data constituting an artefact

Control

Situation in which an artefact is able to be exclusively modified by a Node

Ownership

Relationship of control between a Node or one or more artefacts

Transaction

The durable, atomic (in the view of some Node) and reversible transition between different consistent configurations of the artefacts in some system

Model

A record of the static state and relative dynamic behaviour of the constituent sub-parts of some system

Client

Originator of a visualisation request

Consumer

Entity (either human or user agent) using ("consuming") a cloud service

Visualisation

The process of gathering, from multiple artefact regions, those artefacts of relevance to some visualising Client

Requirements

This specification intends to meet the following requirements:

• A web browser's view (in the Window Object Model) of stored data should be compatible with functionality specified in Web Storage
• The capabilities of computational models should be cased on that given in the Object Management Group's XMI specification
• One or more Nodes should be able, via their various interconnections, to simulate collective ownership of one or more artefacts by progressively relinquishing and taking control of disjoint regions of some artefact space such that the storage load on all Nodes are balanced
• on receiving a "visualise" request from some client within the Region of Control of some Node, that Node should pass the request on to those nodes whose regions of control are deemed to be "neighbouring" (in some artefact space) and "behind" the Node in that client's "visual field", taking a union of each's returned "visualisable" artefacts, adding those artefacts located in the Node's own region of Control and returning that set to the requesting Node, and ewpeating thus proceedure until all artefacts in the client's visual field, irrespective of controlling Node, have been rendered to the client
• constraints in the behaviour of groups of related artefacts should be expressible using the approach taken by the assertions feature of XML Schemas 1.1
• a consumer should begin a request for cloud work by issuing a multi-cast "service query", to which listening cloud supplier will respond with a rule-set describing each's charging regime, from which the consumer will select the most appropriate supplier, to whom the consumer will then issue a "work request" containing a reference to the computational model of the work to be performed and its desired "availability style" (a style-sheet associating model electors associated with a property representing the desired availability level of that part of the model corresponding to the selector) to use for that work
• each Artefact should have one Node designated to be its owner. Modifications to artefacts by owning Nodes should have immediate effect, while attempted modifications by non-owning Nodes will engage transactional semantics conforming to the Distributed Transaction Processing specification
• before ownership is passed between Nodes, the requesting Node must first send a request for ownership chsnge request, passing its credentials in the request, to which the owning Node should respond with an authorisation to the preferred requester, rejecting the others, after which ownership will transfer to the athorised Node
• requests and responses should, as far as possible, use a SOAP representation
• artefacts should contain security credentials ensuring each's integrity
• where a model element represents some type of onfological artefact, that element should reference the IRI of rhe OWL element representing the Artefact

Use Cases

The use cases listed below were created by the Cloud Computing Community Group to illustrate important applications for the features ioof the cloud architecture.

• Use Case 1: A CAD system is equipped with a "physics engine" which performs continuous analyses such as those of - amongst others - acoustic, vibrational and buckling, of its constituent physical structures, to determine properties as the inertia and momentum of each part of the set of structures under analysis so as to determine the dynamic behaviour, forces and stresses within those structures. Since the combined computational requirements of these analyses are quite high, the load is distributed adaptively (since the structures, themselves, may change over time) around the system's computing resources, so as to keep the system as responsive as possible, with the greater part of those resources given over to the geometrically complex parts (which are more difficult to analyse) of those structures

• Use Case 2: An RDF processor manages a vast collection of triples representing (amongst others) ontological information: a collection so large as to overwhelm the RAM capacity of any one machine. The information is therefore "spread" across sufficient machines such that their combined capacity is sufficient to meet the total storage requirement. The information stored in each machine is also approximately "balanced" across all the participating machines
• Use Case 3: a very large XML file Contains elements representing objects (such as a "tree" or "house"). Those objects are represented in multiple levels of detail (such as "trunk", "branch", "leaf", or "roof", "wall", "window" and "roof tile"). An XBL 2 processor Transforms these elements into those constituent visualisable (on a configurable, per-client basis) elements, enabling such clients to "visualise" the artefacts built in this way. These transformed elements may include those of OWL ontologies, holding knowledge and RIF rule-sets able, when fired, to transform the artefacts based on certain factors, including the user’s actions.