[occi-wg] [occi] 2 new revisions pushed by s... at samj.net on 2010-02-21 15:33 GMT
occi at googlecode.com
occi at googlecode.com
Sun Feb 21 09:34:02 CST 2010
2 new revisions:
Revision: 1df85e1a49
Author: Sam Johnston <samj at samj.net>
Date: Sun Feb 21 07:32:22 2010
Log: Updated affiliation, regenerated.
http://code.google.com/p/occi/source/detail?r=1df85e1a49
Revision: 235906a914
Author: Sam Johnston <samj at samj.net>
Date: Sun Feb 21 07:33:00 2010
Log: merged
http://code.google.com/p/occi/source/detail?r=235906a914
==============================================================================
Revision: 1df85e1a49
Author: Sam Johnston <samj at samj.net>
Date: Sun Feb 21 07:32:22 2010
Log: Updated affiliation, regenerated.
http://code.google.com/p/occi/source/detail?r=1df85e1a49
Modified:
/docs/occi-application.html
/docs/occi-application.pdf
/docs/occi-book.html
/docs/occi-book.pdf
/docs/occi-book.xml
=======================================
--- /docs/occi-application.html Sat Oct 10 07:36:28 2009
+++ /docs/occi-application.html Sun Feb 21 07:32:22 2010
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML
1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><title>OCCI
Application</title><meta name="generator" content="DocBook XSL-NS
Stylesheets V1.75.2"/></head><body><div class="article" title="OCCI
Application"><div class="titlepage"><div><div><h2 class="title"><a
id="id36063441"/>OCCI Application</h2></div></div><hr/></div><p>The OCCI
Application specification defines kinds and extensions
- relating to management of cloud application services (SaaS).</p><div
class="table"><a id="id36063454"/><p class="title"><b>Table 1. Common
Attributes</b></p><div class="table-contents"><table summary="Common
Attributes" border="1"><colgroup><col style="text-align:
center"/><col/><col/></colgroup><thead><tr><th style="text-align:
left">Attribute</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td
style="text-align: left"><code
class="computeroutput">occi.application.version</code></td><td>Float (e.g.
1.0)</td><td>Version of the OCCI Application
specification</td></tr></tbody></table></div></div><br
class="table-break"/><div class="section" title="Kinds"><div
class="titlepage"><div><div><h2 class="title"><a
id="id36063507"/>Kinds</h2></div></div></div><p>Cloud application services
can be modeled using the following
- primary kinds:</p><div class="table"><a id="id36063516"/><p
class="title"><b>Table 2. Kinds</b></p><div class="table-contents"><table
summary="Kinds" border="1"><colgroup><col style="text-align:
center"/><col/><col/></colgroup><thead><tr><th style="text-align:
left">Kind</th><th>URI</th><th>Description</th></tr></thead><tbody><tr><td
style="text-align: left"><code
class="computeroutput">contact</code></td><td><code
class="uri">http://purl.org/occi/kind/contact</code></td><td>A contact; a
person, a venue such as a club or a
- restaurant, or an organisation.</td></tr><tr><td
style="text-align: left"><code
class="computeroutput">document</code></td><td><code
class="uri">http://purl.org/occi/kind/document</code></td><td>A word
processing document</td></tr><tr><td style="text-align: left"><code
class="computeroutput">event</code></td><td><code
class="uri">http://purl.org/occi/kind/event</code></td><td>A calendar
event</td></tr><tr><td style="text-align: left"><code
class="computeroutput">presentation</code></td><td><code
class="uri">http://purl.org/occi/kind/presentation</code></td><td>A visual
representation</td></tr><tr><td style="text-align: left"><code
class="computeroutput">spreadsheet</code></td><td><code
class="uri">http://purl.org/occi/kind/spreadsheet</code></td><td>A
worksheet</td></tr></tbody></table></div></div><br
class="table-break"/><div class="section" title="Contact"><div
class="titlepage"><div><div><h3 class="title"><a
id="id36063640"/>Contact</h3></div></div></div><p>A contact is a person,
venue, organisation, etc.</p></div></div><div class="section"
title="Extensions"><div class="titlepage"><div><div><h2 class="title"><a
id="id36063651"/>Extensions</h2></div></div></div><p>Various extensions
provide for more advanced management
- functionality such as billing, monitoring and reporting.</p></div><div
class="bibliography" title="Bibliography"><div
class="titlepage"><div><div><h2 class="title"><a
id="id36063662"/>Bibliography</h2></div></div></div><div
class="bibliomixed"><a id="id36063664"/><p class="bibliomixed">Normative
References</p></div><div class="bibliomixed"><a id="id36063667"/><p
class="bibliomixed">Informative References</p></div><div
class="biblioentry" title="Google Data Protocol (GData)"><a
id="application-gdata"/><p>[GData] <span class="title"><i>Google Data
Protocol (GData)</i>. </span><span class="address"><code class="uri"><a
class="uri" href="http://en.wikipedia.org/wiki/List_of_device_bandwidths"
target="">http://code.google.com/apis/gdata/</a></code>. </span><span
class="author">. </span></p></div></div></div></body></html>
+<html xmlns="http://www.w3.org/1999/xhtml"><head><title>OCCI
Application</title><meta name="generator" content="DocBook XSL-NS
Stylesheets V1.75.2"/></head><body><div class="article" title="OCCI
Application"><div class="titlepage"><div><div><h2 class="title"><a
id="id36063440"/>OCCI Application</h2></div></div><hr/></div><p>The OCCI
Application specification defines kinds and extensions
+ relating to management of cloud application services (SaaS).</p><div
class="table"><a id="id36063453"/><p class="title"><b>Table 1. Common
Attributes</b></p><div class="table-contents"><table summary="Common
Attributes" border="1"><colgroup><col style="text-align:
center"/><col/><col/></colgroup><thead><tr><th style="text-align:
left">Attribute</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td
style="text-align: left"><code
class="computeroutput">occi.application.version</code></td><td>Float (e.g.
1.0)</td><td>Version of the OCCI Application
specification</td></tr></tbody></table></div></div><br
class="table-break"/><div class="section" title="Kinds"><div
class="titlepage"><div><div><h2 class="title"><a
id="id36063506"/>Kinds</h2></div></div></div><p>Cloud application services
can be modeled using the following
+ primary kinds:</p><div class="table"><a id="id36063515"/><p
class="title"><b>Table 2. Kinds</b></p><div class="table-contents"><table
summary="Kinds" border="1"><colgroup><col style="text-align:
center"/><col/><col/></colgroup><thead><tr><th style="text-align:
left">Kind</th><th>URI</th><th>Description</th></tr></thead><tbody><tr><td
style="text-align: left"><code
class="computeroutput">contact</code></td><td><code
class="uri">http://purl.org/occi/kind/contact</code></td><td>A contact; a
person, a venue such as a club or a
+ restaurant, or an organisation.</td></tr><tr><td
style="text-align: left"><code
class="computeroutput">document</code></td><td><code
class="uri">http://purl.org/occi/kind/document</code></td><td>A word
processing document</td></tr><tr><td style="text-align: left"><code
class="computeroutput">event</code></td><td><code
class="uri">http://purl.org/occi/kind/event</code></td><td>A calendar
event</td></tr><tr><td style="text-align: left"><code
class="computeroutput">presentation</code></td><td><code
class="uri">http://purl.org/occi/kind/presentation</code></td><td>A visual
representation</td></tr><tr><td style="text-align: left"><code
class="computeroutput">spreadsheet</code></td><td><code
class="uri">http://purl.org/occi/kind/spreadsheet</code></td><td>A
worksheet</td></tr></tbody></table></div></div><br
class="table-break"/><div class="section" title="Contact"><div
class="titlepage"><div><div><h3 class="title"><a
id="id36063638"/>Contact</h3></div></div></div><p>A contact is a person,
venue, organisation, etc.</p></div></div><div class="section"
title="Extensions"><div class="titlepage"><div><div><h2 class="title"><a
id="id36063650"/>Extensions</h2></div></div></div><p>Various extensions
provide for more advanced management
+ functionality such as billing, monitoring and reporting.</p></div><div
class="bibliography" title="Bibliography"><div
class="titlepage"><div><div><h2 class="title"><a
id="id36063660"/>Bibliography</h2></div></div></div><div
class="bibliomixed"><a id="id36063662"/><p class="bibliomixed">Normative
References</p></div><div class="bibliomixed"><a id="id36063666"/><p
class="bibliomixed">Informative References</p></div><div
class="biblioentry" title="Google Data Protocol (GData)"><a
id="application-gdata"/><p>[GData] <span class="title"><i>Google Data
Protocol (GData)</i>. </span><span class="address"><code class="uri"><a
class="uri" href="http://en.wikipedia.org/wiki/List_of_device_bandwidths"
target="">http://code.google.com/apis/gdata/</a></code>. </span><span
class="author">. </span></p></div></div></div></body></html>
=======================================
--- /docs/occi-application.pdf Sat Oct 10 07:36:28 2009
+++ /docs/occi-application.pdf Sun Feb 21 07:32:22 2010
Binary file, no diff available.
=======================================
--- /docs/occi-book.html Wed Oct 28 18:16:54 2009
+++ /docs/occi-book.html Sun Feb 21 07:32:22 2010
@@ -1,11 +1,11 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML
1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><title>OGF OCCI-WG
Deliverables</title><meta name="generator" content="DocBook XSL-NS
Stylesheets V1.75.2"/></head><body><div class="book" title="OGF OCCI-WG
Deliverables"><div class="titlepage"><div><div><h1 class="title"><a
id="id36063441"/>OGF OCCI-WG Deliverables</h1></div><div><div
class="author"><h3 class="author"><span class="firstname">Sam</span> <span
class="surname">Johnston</span></h3><span class="contrib">WG
Secretary</span> <span class="contrib">Author</span> <div
class="affiliation"><span class="orgname">Australian Online
Solutions<br/></span></div></div></div><div><div class="author"><h3
class="author"><span class="firstname">Thijs</span> <span
class="surname">Metsch</span></h3><span
class="contrib">Co-Chair</span> <span class="contrib">Author</span> <div
class="affiliation"><span class="orgname">Sun
Microsystems<br/></span></div></div></div><div><div class="author"><h3
class="author"><span class="firstname">Andrew</span> <span
class="surname">Edmonds</span></h3><span
class="contrib">Co-Chair</span> <span class="contrib">Author</span> <div
class="affiliation"><span
class="orgname">Intel<br/></span></div></div></div><div><div
class="author"><h3 class="author"><span class="firstname">Alexis</span>
<span class="surname">Richardson</span></h3><span
class="contrib">Co-Chair</span> <div class="affiliation"><span
class="orgname">Rabbit Technologies<br/></span></div></div></div><div><p
class="pubdate">July 2009</p></div></div><hr/></div><div class="article"
title="OCCI Use Cases"><div class="titlepage"><div><div><h2
class="title"><a id="id36063864"/>OCCI Use
Cases</h2></div></div><hr/></div><p>The following section describes the Use
Cases which were gathered
+<html xmlns="http://www.w3.org/1999/xhtml"><head><title>OGF OCCI-WG
Deliverables</title><meta name="generator" content="DocBook XSL-NS
Stylesheets V1.75.2"/></head><body><div class="book" title="OGF OCCI-WG
Deliverables"><div class="titlepage"><div><div><h1 class="title"><a
id="id36063440"/>OGF OCCI-WG Deliverables</h1></div><div><div
class="author"><h3 class="author"><span class="firstname">Sam</span> <span
class="surname">Johnston</span></h3><span class="contrib">WG
Secretary</span> <span class="contrib">Author</span> <div
class="affiliation"><span
class="orgname">Google<br/></span></div></div></div><div><div
class="author"><h3 class="author"><span class="firstname">Thijs</span>
<span class="surname">Metsch</span></h3><span
class="contrib">Co-Chair</span> <span class="contrib">Author</span> <div
class="affiliation"><span class="orgname">Sun
Microsystems<br/></span></div></div></div><div><div class="author"><h3
class="author"><span class="firstname">Andrew</span> <span
class="surname">Edmonds</span></h3><span
class="contrib">Co-Chair</span> <span class="contrib">Author</span> <div
class="affiliation"><span
class="orgname">Intel<br/></span></div></div></div><div><div
class="author"><h3 class="author"><span class="firstname">Alexis</span>
<span class="surname">Richardson</span></h3><span
class="contrib">Co-Chair</span> <div class="affiliation"><span
class="orgname">Rabbit Technologies<br/></span></div></div></div><div><p
class="pubdate">July 2009</p></div></div><hr/></div><div class="article"
title="OCCI Use Cases"><div class="titlepage"><div><div><h2
class="title"><a id="id36063862"/>OCCI Use
Cases</h2></div></div><hr/></div><p>The following section describes the Use
Cases which were gathered
during the requirements analyses for the OCCI working group. They are
used
to set up the requirements and later on to verify the OCCI
- specification.</p><div class="section" title="SLA-aware cloud
infrastructure using SLA at SOI"><div class="titlepage"><div><div><h2
class="title"><a id="id36065051"/>SLA-aware cloud infrastructure using
SLA at SOI</h2></div></div></div><p>There is a need for a standard interface
for dynamic infrastructure
+ specification.</p><div class="section" title="SLA-aware cloud
infrastructure using SLA at SOI"><div class="titlepage"><div><div><h2
class="title"><a id="id36065047"/>SLA-aware cloud infrastructure using
SLA at SOI</h2></div></div></div><p>There is a need for a standard interface
for dynamic infrastructure
provisioning. While doing so it must be guaranteed and verified that
the
- infrastructure provisioning uses 'machine-readable' SLAs. <span
class="citerefentry"><span
class="refentrytitle">(SLA_SOI)</span></span></p><h3><a
id="id36065067"/>Functional Requirements</h3><div class="itemizedlist"><ul
class="itemizedlist"><li class="listitem"><p>VM Description: request format
important - In this area is where
+ infrastructure provisioning uses 'machine-readable' SLAs. <sup>[<a
id="id36065057" href="#ftn.id36065057"
class="footnote">1</a>]</sup></p><h3><a id="id36065064"/>Functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>VM Description: request format important - In this area
is where
there is least coherency amongst providers.</p></li><li
class="listitem"><p>VM Description: a means to add non-functional
constraints on
functional attributes.</p></li><li class="listitem"><p>VM
Management: all parameters in the request should be
"monitor-able" and verifiable. Full control of resources (VMs)
@@ -14,20 +14,20 @@
defaults of public and private further sub-categorisation could be
allowed e.g. tag of web could be assigned to the public network
group.</p></li><li class="listitem"><p>Storage Management: simple
mount points, reuse storage SaaS
- offerings</p></li></ul></div><h3><a
id="id36065121"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Security: Transport and user level (ACLs? oAuth?)
+ offerings</p></li></ul></div><h3><a
id="id36065118"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Security: Transport and user level (ACLs? oAuth?)
security</p></li><li class="listitem"><p>Quality of Service: Can
be many - Part of service offering from
the infrastructure provider e.g. Security, QoS, geo-location,
isolation levels - NFPs are the basic building blocks of
differentiating IaaS providers.</p></li><li
class="listitem"><p>Scheduling Information: When a particular resource is
to be run.
Also in which order should a collection of resources be ran in the
- case that one resource is dependent on
another.</p></li></ul></div></div><div class="section" title="Service
Manager to control the Life cycle of Services"><div
class="titlepage"><div><div><h2 class="title"><a id="id36065154"/>Service
Manager to control the Life cycle of Services</h2></div></div></div><p>This
Use Case is based in the 'Service Manager' (SM) layer of the
+ case that one resource is dependent on
another.</p></li></ul></div></div><div class="section" title="Service
Manager to control the Life cycle of Services"><div
class="titlepage"><div><div><h2 class="title"><a id="id36065151"/>Service
Manager to control the Life cycle of Services</h2></div></div></div><p>This
Use Case is based in the 'Service Manager' (SM) layer of the
RESERVOIR project architecture. 'Service Providers' (SP) willing to
deploy
their service on the Cloud use this layer to control the service life
cycle. The SM operates over the Cloud infrastructure automatically as
the
service demands. In a way, the SM maps the service configuration and
needs
to calls to the Cloud infrastructure, so many of the requirements
imposed
- by the SM are due to the flexibility that the SM aims to provide to
SPs.
- (<span class="citerefentry"><span
class="refentrytitle">RV</span></span>)</p><h3><a
id="id36065175"/>Functional Requirements</h3><div class="itemizedlist"><ul
class="itemizedlist"><li class="listitem"><p>Network Management: There
should be methods for the Allocation
+ by the SM are due to the flexibility that the SM aims to provide to
+ SPs.<sup>[<a id="id36065164" href="#ftn.id36065164"
class="footnote">2</a>]</sup></p><h3><a id="id36065172"/>Functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Network Management: There should be methods for the
Allocation
of private networks, where VMs can be attached to. A special
network
(e.g. 'Public Network') should be available. When some network
interface is attached to it, the infrastructure must assign a
public
@@ -72,7 +72,7 @@
IDs, (UUIDs, URIs, or the like). It is to be determined whether
components of VMs (disks, memory...) should have an unique ID too.
IDs
are assigned by the Cloud infrastructure when the corresponding
- element is created.</p></li></ul></div><h3><a
id="id36065349"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Both
for hardware configuration and monitoring values there
+ element is created.</p></li></ul></div><h3><a
id="id36065346"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Both
for hardware configuration and monitoring values there
should be a clear, standard way to set which magnitude the value
represents. For example, when setting the memory size to '2', it
must
be clear that we refer to GBs and not to MBs. An option would be
@@ -80,7 +80,7 @@
value and the magnitude: value '2' and magnitude 'GB'.</p></li><li
class="listitem"><p>Protocols: The transport, message format, and state
representation should use open and standard protocols, each one
which
strong software support (i.e. libraries and frameworks available
for
- several programming languages).</p></li></ul></div></div><div
class="section" title="Interoperability across Cloud Infrastructures using
OpenNebula"><div class="titlepage"><div><div><h2 class="title"><a
id="id36065377"/>Interoperability across Cloud Infrastructures using
+ several programming languages).</p></li></ul></div></div><div
class="section" title="Interoperability across Cloud Infrastructures using
OpenNebula"><div class="titlepage"><div><div><h2 class="title"><a
id="id36065373"/>Interoperability across Cloud Infrastructures using
OpenNebula</h2></div></div></div><p>OpenNebula is a Virtual
Infrastructure Engine, being enhanced in the
RESERVOIR project, which allows the management of Virtual Machines on a
pool of physical resources It offers three main functionalities:
backend
@@ -93,7 +93,7 @@
OpenNebula to manage Virtual Machines from different cloud providers.
Currently, there are two set of plugins for OpenNebula to access Amazon
EC2 and ElasticHosts cloud providers that leverage the use of both
cloud
- providers in a transparent fashion for the end user. (<span
class="citerefentry"><span
class="refentrytitle">ONE</span></span>)</p><h3><a
id="id36065405"/>Functional Requirements</h3><div class="itemizedlist"><ul
class="itemizedlist"><li class="listitem"><p>VM Description: Virtual
Machines should be described
+ providers in a transparent fashion for the end user.<sup>[<a
id="id36065393" href="#ftn.id36065393"
class="footnote">3</a>]</sup></p><h3><a id="id36065400"/>Functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>VM Description: Virtual Machines should be described
consistently across cloud providers using a slim set of
indispensable
attributes, such as:</p><div class="itemizedlist"><ul
class="itemizedlist"><li class="listitem"><p>Memory: Amount of RAM needed
by the Virtual Machine</p></li><li class="listitem"><p>CPU: Number of CPUs
needed by the Virtual Machine (this
needs to be normalized)</p></li><li class="listitem"><p>Disk:
Disks that will conform the basic filesystem and
@@ -111,61 +111,61 @@
fundamental to virtual machine management to avoid the need to
reinstall software for each cloud provider. The upload process
should
return an identifier to be used in the Virtual Machine
- Description.</p></li></ul></div><h3><a
id="id36065615"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Security: Security should be handled using X509
certificates for
+ Description.</p></li></ul></div><h3><a
id="id36065610"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Security: Security should be handled using X509
certificates for
authentication. Also, authorization can be based on said
certificates
and ACL lists.</p></li><li class="listitem"><p>Quality of Service:
When used in conjunction with Haizea,
OpenNebula provides advanced reservation functionality. Cloud
providers API should provide similar capabilities to ensure proper
- QoS.</p></li></ul></div></div><div class="section" title="AJAX web
front-end directly calling API"><div class="titlepage"><div><div><h2
class="title"><a id="id36065640"/>AJAX web front-end directly calling
API</h2></div></div></div><p>This Use Case describes the ability to create
web front-ends for
+ QoS.</p></li></ul></div></div><div class="section" title="AJAX web
front-end directly calling API"><div class="titlepage"><div><div><h2
class="title"><a id="id36065635"/>AJAX web front-end directly calling
API</h2></div></div></div><p>This Use Case describes the ability to create
web front-ends for
Clouds. A cloud provider implements their customer web front-end as an
entirely client-side AJAX application calling the OCCI API
- directly.</p><h3><a id="id36065651"/>Functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Completeness: API must be contain complete set of calls
to
+ directly.</p><h3><a id="id36065646"/>Functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Completeness: API must be contain complete set of calls
to
completely specify and control cloud (but this is likely only
~15-20
verbs on ~3-4 nouns!)</p></li><li
class="listitem"><p>Responsiveness: Calls must return swiftly. In
particular, we
should provide a simple and quick call to poll the _list_ of
servers,
drives, etc. that exist without listing all of their properties,
since
this is computationally much cheaper for the cloud to return, and
will
need to be regularly polled to catch any servers, etc. that are
- created outside of the interface.</p></li></ul></div><h3><a
id="id36065677"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Syntax: A simple JSON syntax for the API will make the
AJAX
- interface much simpler to implement</p></li></ul></div></div><div
class="section" title="Single technical integration to support multiple
service providers"><div class="titlepage"><div><div><h2 class="title"><a
id="id36065693"/>Single technical integration to support multiple service
+ created outside of the interface.</p></li></ul></div><h3><a
id="id36065672"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Syntax: A simple JSON syntax for the API will make the
AJAX
+ interface much simpler to implement</p></li></ul></div></div><div
class="section" title="Single technical integration to support multiple
service providers"><div class="titlepage"><div><div><h2 class="title"><a
id="id36065688"/>Single technical integration to support multiple service
providers</h2></div></div></div><p>Today, each cloud provider
(ElasticHosts, GoGrid, Amazon, etc.)
integrates independently with every other player in the cloud ecosystem
(CohesiveFT, RightScale, etc), producing O(n^2) separate technical
integrations. In the future, if all cloud providers and cloud ecosystem
partners use a single standard API, then we have O(n) technical
integrations, and all potential partnerships can immediately
- interoperate.</p><h3><a id="id36065706"/>Non-functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Uptake: Standardized IaaS API needs strong uptake in by
both
- cloud providers and cloud ecosystem.</p></li></ul></div></div><div
class="section" title="Wrapping EC2 in OCCI"><div
class="titlepage"><div><div><h2 class="title"><a id="id36065722"/>Wrapping
EC2 in OCCI</h2></div></div></div><p>At the time of this writing, Amazon
EC2 is popular cloud API for
+ interoperate.</p><h3><a id="id36065701"/>Non-functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Uptake: Standardized IaaS API needs strong uptake in by
both
+ cloud providers and cloud ecosystem.</p></li></ul></div></div><div
class="section" title="Wrapping EC2 in OCCI"><div
class="titlepage"><div><div><h2 class="title"><a id="id36065717"/>Wrapping
EC2 in OCCI</h2></div></div></div><p>At the time of this writing, Amazon
EC2 is popular cloud API for
IaaS. Cloud providers implementing EC2 as well as other proprietary and
open cloud APIs may not implement OCCI. To help ensure that the OCCI
API
would be capable of interfacing to EC2 though gateways, minimizing the
- impact to provider operations. </p><h3><a id="id36065734"/>Functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Semantics: Must include the ability to fully describe
core EC2
- objects and operations</p></li></ul></div><h3><a
id="id36065749"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>A
gateway to support the integration of OCCI and
EC2</p></li></ul></div></div><div class="section" title="Automated Business
Continuity and Disaster Recovery"><div class="titlepage"><div><div><h2
class="title"><a id="id36065764"/>Automated Business Continuity and
Disaster Recovery</h2></div></div></div><p>Maintain a up-to-date remote
shadows of physical and/or virtual
+ impact to provider operations.</p><h3><a id="id36065729"/>Functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Semantics: Must include the ability to fully describe
core EC2
+ objects and operations</p></li></ul></div><h3><a
id="id36065744"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>A
gateway to support the integration of OCCI and
EC2</p></li></ul></div></div><div class="section" title="Automated Business
Continuity and Disaster Recovery"><div class="titlepage"><div><div><h2
class="title"><a id="id36065759"/>Automated Business Continuity and
Disaster Recovery</h2></div></div></div><p>Maintain a up-to-date remote
shadows of physical and/or virtual
machines, such that in the event of a disaster it is possible to start
and
- switch to the remote machines.</p><h3><a id="id36065775"/>Functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>VM Description: Metadata mapping to legacy
systems</p></li><li class="listitem"><p>VM Management: Automated management
in the event of a disaster
+ switch to the remote machines.</p><h3><a id="id36065770"/>Functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>VM Description: Metadata mapping to legacy
systems</p></li><li class="listitem"><p>VM Management: Automated management
in the event of a disaster
(e.g. startup, IP changes).</p></li><li
class="listitem"><p>Network Management: Runtime alteration of
IPs</p></li><li class="listitem"><p>Image Management: Advanced, rsync style
updates to synchronise
machines with physical equivalents (e.g. rsync block devices to
remote
- raw disk files).</p></li></ul></div><h3><a
id="id36065813"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Quality of Service: Reservation of capacity sufficient
for fail
- over</p></li></ul></div></div><div class="section" title="Simple
scripting of cloud from Unix shell"><div class="titlepage"><div><div><h2
class="title"><a id="id36065829"/>Simple scripting of cloud from Unix
shell</h2></div></div></div><p>An end user wishes to script a simple task
(such as starting a
+ raw disk files).</p></li></ul></div><h3><a
id="id36065808"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Quality of Service: Reservation of capacity sufficient
for fail
+ over</p></li></ul></div></div><div class="section" title="Simple
scripting of cloud from Unix shell"><div class="titlepage"><div><div><h2
class="title"><a id="id36065824"/>Simple scripting of cloud from Unix
shell</h2></div></div></div><p>An end user wishes to script a simple task
(such as starting a
server at midnight every night and shutting it down an hour later,
automating fail over, reporting, etc.). They are using a typical
Unix/Linux setup, so would like to write a simple cron job which
carries
- this out.</p><h3><a id="id36065840"/>Non-functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Syntax: This should be as simple as possible to place
minimal
+ this out.</p><h3><a id="id36065836"/>Non-functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Syntax: This should be as simple as possible to place
minimal
barriers to entry on the user. The user should not need any
development tools or libraries. They should be able to write 1-2
lines
of shell script, posting a simple <5 lines of command data using
- curl, wget, etc.</p></li></ul></div></div><div class="section"
title="Typical web hosting cluster"><div class="titlepage"><div><div><h2
class="title"><a id="id36065858"/>Typical web hosting
cluster</h2></div></div></div><p>An end-user runs a typical web hosting
cluster on a cloud, with: n
+ curl, wget, etc.</p></li></ul></div></div><div class="section"
title="Typical web hosting cluster"><div class="titlepage"><div><div><h2
class="title"><a id="id36065853"/>Typical web hosting
cluster</h2></div></div></div><p>An end-user runs a typical web hosting
cluster on a cloud, with: n
database servers, m front-end web server (bursting to x under load)
and a
load balancer (either a specialized virtual machine or provided by the
- cloud like GoGrid).</p><h3><a id="id36065870"/>Functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Completeness: The API should be able to fully express
this
+ cloud like GoGrid).</p><h3><a id="id36065865"/>Functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Completeness: The API should be able to fully express
this
cluster, which will require at least: (n+m+x) virtual machines,
storage for each virtual machine, two networks (a private one
connecting the machines, and the public Internet also connected to
the
load balancer), a fixed static IP for the website on the public
- Internet, possible specification of the load balancer
itself.</p></li></ul></div></div><div class="section" title="Manage cloud
resources from a centralized dashboard"><div
class="titlepage"><div><div><h2 class="title"><a id="id36065888"/>Manage
cloud resources from a centralized dashboard</h2></div></div></div><p>An
end user wishes to view and control all of his cloud-based
+ Internet, possible specification of the load balancer
itself.</p></li></ul></div></div><div class="section" title="Manage cloud
resources from a centralized dashboard"><div
class="titlepage"><div><div><h2 class="title"><a id="id36065883"/>Manage
cloud resources from a centralized dashboard</h2></div></div></div><p>An
end user wishes to view and control all of his cloud-based
resources in a lightweight (perhaps AJAX-based) console, perhaps the
same
web front-end referred to in this Use Case: AJAX web front-end directly
- calling API</p><h3><a id="id36065900"/>Functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Completeness: Every resource provided by the cloud is
+ calling API</p><h3><a id="id36065895"/>Functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Completeness: Every resource provided by the cloud is
discoverable by the API, and every action that can be performed on
all
these resources is also available via the API, together with
actuators
to actually perform those actions, and all the attributes of the
@@ -175,18 +175,17 @@
this is computationally much cheaper for the cloud to return, and
will
need to be regularly polled to catch any servers, etc. that are
created outside of the interface. (text copied from AJAX web
front-end
- directly calling API)</p></li><li
class="listitem"><p>Categorizability: (there's gotta be a better word...)
The client
- must be able to identify what type each resource is in order to
- display like-typed resources together and in order to provide
separate
- UI views that might be specialized for certain resource types. For
- example, the client must be able to differentiate between a compute
- resource that does not represent an actual CPU (perhaps this is a
- compute template) and between a compute resource that actually
- represents a running CPU. The interface for actually-running CPUs
- might display the current IP address of the instance and allow you
to
- SSH into the instance, while a different tab in the interface might
- display all the compute templates and allow you to instantiate
- instances from them.</p></li><li class="listitem"><p>Taggability:
Every resource discoverable by the API must be able
+ directly calling API)</p></li><li
class="listitem"><p>Categorizability: The client must be able to identify
what type
+ each resource is in order to display like-typed resources together
and
+ in order to provide separate UI views that might be specialized for
+ certain resource types. For example, the client must be able to
+ differentiate between a compute resource that does not represent an
+ actual CPU (perhaps this is a compute template) and between a
compute
+ resource that actually represents a running CPU. The interface for
+ actually-running CPUs might display the current IP address of the
+ instance and allow you to SSH into the instance, while a different
tab
+ in the interface might display all the compute templates and allow
you
+ to instantiate instances from them.</p></li><li
class="listitem"><p>Taggability: Every resource discoverable by the API
must be able
to be tagged by the user. This supports the oft-occurring situation
where resources, though they are identified by the
implementation-specific identifier, are easily identified using
@@ -197,43 +196,43 @@
allow an optional filter that can specify a category or tag upon
which
to filter the results. This allows one to further limit their view
to,
for example, resources tagged "productionEnvironment", or
resources of
- the category "storage".</p></li></ul></div><h3><a
id="id36065962"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Usability: This should be a user interface with
context-menus
+ the category "storage".</p></li></ul></div><h3><a
id="id36065957"/>Non-functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Usability: This should be a user interface with
context-menus
and context-aware links that allow the user to easily see what
actions
- can be performed for each resource.</p></li></ul></div></div><div
class="section" title="Compute Cloud"><div class="titlepage"><div><div><h2
class="title"><a id="id36065979"/>Compute Cloud</h2></div></div></div><p>A
cloud provider implements a RESTful API for provisioning,
- executing, and monitoring of tasks.</p><h3><a
id="id36065989"/>Functional Requirements</h3><div class="itemizedlist"><ul
class="itemizedlist"><li class="listitem"><p>Secure: API must be secured to
ensure that only authorized
+ can be performed for each resource.</p></li></ul></div></div><div
class="section" title="Compute Cloud"><div class="titlepage"><div><div><h2
class="title"><a id="id36065973"/>Compute Cloud</h2></div></div></div><p>A
cloud provider implements a RESTful API for provisioning,
+ executing, and monitoring of tasks.</p><h3><a
id="id36065983"/>Functional Requirements</h3><div class="itemizedlist"><ul
class="itemizedlist"><li class="listitem"><p>Secure: API must be secured to
ensure that only authorized
identities are permitted to use the API.</p></li><li
class="listitem"><p>Resource: An endpoint must be created for external
monitoring,
status, and auditing of the task. This endpoint would be
responsive to
RESTful calls supporting AJAX and other clients.</p></li><li
class="listitem"><p>Scripted: The target system needs to understand and
process
directives which would be provided with the task. These directives
would include the ability to pull binaries or data onto the system,
- run executables, and status the system
resources.</p></li></ul></div><h3><a id="id36066021"/>Non-functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Single Compute Method: The resultant service should be
the same
+ run executables, and status the system
resources.</p></li></ul></div><h3><a id="id36066016"/>Non-functional
Requirements</h3><div class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Single Compute Method: The resultant service should be
the same
service that can be used for many other purposes. It could be used
for
monitoring of system health, system life-cycle management, system
patching, and configuration changes. If this was the only service
on
the system initially, it could then be used to build up the other
- services in a plug-in manner.</p></li></ul></div></div><div
class="section" title="Multiple Allocation"><div
class="titlepage"><div><div><h2 class="title"><a id="id36066040"/>Multiple
Allocation</h2></div></div></div><p>Allocate a whole cluster with one
call.</p><h3><a id="id36066049"/>Functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Definition of groups: There should be a way to define
groups of
+ services in a plug-in manner.</p></li></ul></div></div><div
class="section" title="Multiple Allocation"><div
class="titlepage"><div><div><h2 class="title"><a id="id36066034"/>Multiple
Allocation</h2></div></div></div><p>Allocate a whole cluster with one
call.</p><h3><a id="id36066044"/>Functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li
class="listitem"><p>Definition of groups: There should be a way to define
groups of
computers. In the example of a cluster, there would be two groups:
The
Headnode and a couple of Workernodes.</p></li><li
class="listitem"><p>Information: For configuration of the members of the
defined
groups, there should be way (maybe a URL) to find out about all
groups
and their basic configurations. In the example, the Headnode would
want to know IPs or Hostnames of all Workernodes. The workernodes
will
need to know this, as well _and_ they need to know, that the
headnode
- is in a different group.</p></li></ul></div></div><div
class="section" title="Cloud Consumer Discovery of Cloud Provider's VM
Input and Output Format Support"><div class="titlepage"><div><div><h2
class="title"><a id="id36066076"/>Cloud Consumer Discovery of Cloud
Provider's VM Input and Output
+ is in a different group.</p></li></ul></div></div><div
class="section" title="Cloud Consumer Discovery of Cloud Provider's VM
Input and Output Format Support"><div class="titlepage"><div><div><h2
class="title"><a id="id36066071"/>Cloud Consumer Discovery of Cloud
Provider's VM Input and Output
Format Support</h2></div></div></div><p>A cloud consumer would like to
discover the VM input and output
- formats accepted and delivered by the cloud provider.</p><h3><a
id="id36066087"/>Functional Requirements</h3><div class="itemizedlist"><ul
class="itemizedlist"><li class="listitem"><p>The provider supplies an API
which is availed over unsecured
+ formats accepted and delivered by the cloud provider.</p><h3><a
id="id36066082"/>Functional Requirements</h3><div class="itemizedlist"><ul
class="itemizedlist"><li class="listitem"><p>The provider supplies an API
which is availed over unsecured
network connections.</p></li><li class="listitem"><p>The provider
supplies an API which is availed over secured
network connections.</p></li><li class="listitem"><p>The provider
supplied API is availed for all consumer
authentication and authorization levels.</p></li><li
class="listitem"><p>The provider supplied API identifies the supported VM
input
formats API uniquely and commonly across all
providers.</p></li><li class="listitem"><p>The provider supplied API
identifies the supported VM output
formats API uniquely and commonly across all
providers.</p></li><li class="listitem"><p>The provider supplied API
identifies the supported VM formats
- uniquely and commonly across all providers.</p></li><li
class="listitem"><p>The provider API identifies mutliple supported VM input
formats
+ uniquely and commonly across all providers.</p></li><li
class="listitem"><p>The provider API identifies multiple supported VM input
formats
as a list uniquely and commonly across all providers</p></li><li
class="listitem"><p>The provider API identifier is unique and and
consistent across
all API representations.</p></li><li class="listitem"><p>The
provider API VM input and output format identifiers are
unique and and consistent across all providers.</p></li><li
class="listitem"><p>The reported VM input and output formats are not
required to be
- symetrical and equal and in consistent
order.</p></li></ul></div></div><div class="section" title="Cloud Consumer
Discovery of Cloud Provider's Dataset Input and Output Format Support"><div
class="titlepage"><div><div><h2 class="title"><a id="id36066173"/>Cloud
Consumer Discovery of Cloud Provider's Dataset Input and
+ symetrical and equal and in consistent
order.</p></li></ul></div></div><div class="section" title="Cloud Consumer
Discovery of Cloud Provider's Dataset Input and Output Format Support"><div
class="titlepage"><div><div><h2 class="title"><a id="id36066168"/>Cloud
Consumer Discovery of Cloud Provider's Dataset Input and
Output Format Support</h2></div></div></div><p>A cloud consumer would
like to discover the Dataset input and output
formats accepted and delivered by the cloud
- provider.</p><h3><a id="id36066183"/>Functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>The
provider supplies an API which is availed over unsecured
+ provider.</p><h3><a id="id36066178"/>Functional Requirements</h3><div
class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>The
provider supplies an API which is availed over unsecured
network connections.</p></li><li class="listitem"><p>The
provider supplies an API which is availed over secured
network connections.</p></li><li class="listitem"><p>The
provider supplied API is availed for all consumer
authentication and authorization levels.</p></li><li
class="listitem"><p>The provider supplied API identifies the supported
Dataset
@@ -244,8 +243,8 @@
as a list uniquely and commonly across all providers</p></li><li
class="listitem"><p>The provider API identifier is unique and and consistent
across all API representations.</p></li><li
class="listitem"><p>The provider API Dataset input and output format
identifiers
are unique and and consistent across all providers.</p></li><li
class="listitem"><p>The reported Dataset input and output formats are not
required
- to be symetrical and equal and in consistent
order.</p></li></ul></div></div></div><div class="article" title="OCCI
Requirements"><div class="titlepage"><div><div><h2 class="title"><a
id="id36063880"/>OCCI Requirements</h2></div></div><hr/></div><div
class="section" title="Functional Requirements"><div
class="titlepage"><div><div><h2 class="title"><a
id="id36066814"/>Functional Requirements</h2></div></div></div><p>This
section deals with the funtional requirements. The requirments
- have been split up in tables and prioritized.</p><div class="table"><a
id="id36066824"/><p class="title"><b>Table 1. Functional requirements on VM
description</b></p><div class="table-contents"><table summary="Functional
requirements on VM description"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.1.1</td><td>Attributes
to define memory, CPU, disk and network
+ to be symetrical and equal and in consistent
order.</p></li></ul></div></div><div class="footnotes"><br/><hr/><div
class="footnote"><p><sup>[<a id="ftn.id36065057" href="#id36065057"
class="para">1</a>] </sup>SLA at SOI project website -
http://sla-at-soi.eu</p></div><div class="footnote"><p><sup>[<a
id="ftn.id36065164" href="#id36065164" class="para">2</a>] </sup>RESERVOIR
project website - http://www.reservoir-fp7.eu</p></div><div
class="footnote"><p><sup>[<a id="ftn.id36065393" href="#id36065393"
class="para">3</a>] </sup>OpenNebula website -
http://www.opennebula.org</p></div></div></div><div class="article"
title="OCCI Requirements"><div class="titlepage"><div><div><h2
class="title"><a id="id36063879"/>OCCI
Requirements</h2></div></div><hr/></div><div class="section"
title="Functional Requirements"><div class="titlepage"><div><div><h2
class="title"><a id="id36066810"/>Functional
Requirements</h2></div></div></div><p>This section deals with the funtional
requirements. The requirements
+ have been split up in tables and prioritized.</p><div class="table"><a
id="id36066820"/><p class="title"><b>Table 1. Functional requirements on VM
description</b></p><div class="table-contents"><table summary="Functional
requirements on VM description"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.1.1</td><td>Attributes
to define memory, CPU, disk and network
requirements should be available.</td><td>2.2, 2.3,
2.6</td><td>High</td></tr><tr><td>A.1.2.</td><td>Attributes to define
placement constraints, such as
geographical location must be
supported</td><td>2.2</td><td>Medium</td></tr><tr><td>A.1.3.</td><td>A
attributes should demonstrate if migration is supported
by the
infrastructure</td><td>2.2</td><td>Medium</td></tr><tr><td>A.1.4.</td><td>The
API should be able to fully express a cluster (e.g. 5
@@ -257,7 +256,7 @@
provisioned resources to be execute sometime in the future from
the original
request</td><td>2.1</td><td>Medium</td></tr><tr><td>A.1.7.</td><td>Common
operating systems should be
supported</td><td>-</td><td>High</td></tr><tr><td>A.1.8.</td><td>Resources
should be grouped according to provider
policies</td><td>-</td><td>High</td></tr><tr><td>A.1.9.</td><td>Then
requesting new resource(s) the request must be fully
-
complete/describing</td><td>-</td><td>High</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36067066"/><p
class="title"><b>Table 2. Functional requirements on VM
management</b></p><div class="table-contents"><table summary="Functional
requirements on VM management"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.2.1.</td><td>Methods to
start, stop, suspend and resume VMs must be
+
complete/describing</td><td>-</td><td>High</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36067062"/><p
class="title"><b>Table 2. Functional requirements on VM
management</b></p><div class="table-contents"><table summary="Functional
requirements on VM management"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.2.1.</td><td>Methods to
start, stop, suspend and resume VMs must be
available</td><td>2.1, 2.2, 2.3, 2.5, 2.11,
2.10</td><td>High</td></tr><tr><td>A.2.2.</td><td>Automated management in
the event of a disaster should be
supported</td><td>2.1,
2.7</td><td>Low</td></tr><tr><td>A.2.3.</td><td>Provide IDs for each backup
disk and
images</td><td>2.2</td><td>High</td></tr><tr><td>A.2.4.</td><td>Provide
methods to donwload any
backup</td><td>2.2</td><td>Medium</td></tr><tr><td>A.2.5.</td><td>API
should offer functionality to enforce the following
operations: deploy, shutdown, cancel, checkpoint, save,
restore,
@@ -271,153 +270,162 @@
Interoperability)</td><td>-</td><td>Medium</td></tr><tr><td>A.2.11.</td><td>Support
a subset of all functions of today IaaS based
Clouds (e.g. Amaton
EC2)</td><td>2.6</td><td>Medium</td></tr><tr><td>A.2.12.</td><td>A common
interface should be used which can be supported by
many Cloud service providers (regarding Infrastructure and Data
- interfaces).</td><td>2.13,
2.14</td><td>Medium</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36067354"/><p
class="title"><b>Table 3. Functional requirements on Network
management</b></p><div class="table-contents"><table summary="Functional
requirements on Network management"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.3.1.</td><td>Support the
creation of
VPNs</td><td>2.3</td><td>Low</td></tr><tr><td>A.3.2.</td><td>Support
multiple network connection (Public and
+ interfaces).</td><td>2.13,
2.14</td><td>Medium</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36067350"/><p
class="title"><b>Table 3. Functional requirements on Network
management</b></p><div class="table-contents"><table summary="Functional
requirements on Network management"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.3.1.</td><td>Support the
creation of
VPNs</td><td>2.3</td><td>Low</td></tr><tr><td>A.3.2.</td><td>Support
multiple network connection (Public and
Private)</td><td>2.1, 2.2,
2.3</td><td>High</td></tr><tr><td>A.3.3.</td><td>It must be possible to
attach and change IPs at
runtime</td><td>2.3,
2.7</td><td>Medium</td></tr><tr><td>A.3.4.</td><td>Support a tagging
mechanism for a group of network
connections</td><td>2.1, 2.2,
2.3</td><td>Low</td></tr><tr><td>A.3.5.</td><td>Support network setups
which allow an 'Intercloud' setup
- (This relates to
Integration)</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36067513"/><p
class="title"><b>Table 4. Functional requirements on Storage
management</b></p><div class="table-contents"><table summary="Functional
requirements on Storage management"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.4.1.</td><td>Allow the
usage of URIs as mount points - allows reuse of
+ (This relates to
Integration)</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36067509"/><p
class="title"><b>Table 4. Functional requirements on Storage
management</b></p><div class="table-contents"><table summary="Functional
requirements on Storage management"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.4.1.</td><td>Allow the
usage of URIs as mount points - allows reuse of
Storage service
offerings</td><td>2.1</td><td>High</td></tr><tr><td>A.4.2.</td><td>Allow
the attachment of additional storage resources at
-
runtime</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36067619"/><p
class="title"><b>Table 5. Functional requirements on Image
management</b></p><div class="table-contents"><table summary="Functional
requirements on Image management"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.5.1.</td><td>Methods
which are capable to register, upload, update and
+
runtime</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36067615"/><p
class="title"><b>Table 5. Functional requirements on Image
management</b></p><div class="table-contents"><table summary="Functional
requirements on Image management"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.5.1.</td><td>Methods
which are capable to register, upload, update and
download disk images must be
available.</td><td>2.2</td><td>Medium</td></tr><tr><td>A.5.2.</td><td>Updates
based on rsync commands to synchronize machines
with physical equivalents should be
supported</td><td>2.7</td><td>Medium</td></tr><tr><td>A.5.3.</td><td>When
an upload completes successfully, an identifier should
- be
returned</td><td>2.2</td><td>Low</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36067744"/><p
class="title"><b>Table 6. Identifications/References</b></p><div
class="table-contents"><table summary="Identifications/References"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.6.1.</td><td>Unique IDs
for VM images and their components must be
+ be
returned</td><td>2.2</td><td>Low</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36067739"/><p
class="title"><b>Table 6. Identifications/References</b></p><div
class="table-contents"><table summary="Identifications/References"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.6.1.</td><td>Unique IDs
for VM images and their components must be
available</td><td>2.2, 2.13,
2.14</td><td>High</td></tr><tr><td>A.6.2.</td><td>It must be possbile to
tag resources and their
components</td><td>2.10,
2.12</td><td>Medium</td></tr><tr><td>A.6.3.</td><td>It must be possible to
search for resources based on e.g.
- tags.</td><td>2.10,
2.12</td><td>Medium</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36067867"/><p
class="title"><b>Table 7. Monitoring</b></p><div
class="table-contents"><table summary="Monitoring"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.7.1.</td><td>Support
pull-based monitoring that request the status of
+ tags.</td><td>2.10,
2.12</td><td>Medium</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36067863"/><p
class="title"><b>Table 7. Monitoring</b></p><div
class="table-contents"><table summary="Monitoring"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>A.7.1.</td><td>Support
pull-based monitoring that request the status of
the elements such as network , VM ...</td><td>2.1, 2.2,
2.3</td><td>Medium</td></tr><tr><td>A.7.2.</td><td>Support for a
publish/subscribe pattern that request events
which occur in the VM or networks (such as Errors on some
component, changes in the VM state and other periodic
notifications)</td><td>2.2</td><td>Medium</td></tr><tr><td>A.7.3.</td><td>Attributes
that define simple quick call to poll the list
of servers, drives, etc should
monitorable</td><td>2.4</td><td>Low</td></tr><tr><td>A.7.4.</td><td>Attributes
about resource consumption of the VM from the
hypervisor (CPU, memory...) should be monitorable</td><td>2.1,
2.2</td><td>Medium</td></tr><tr><td>A.7.5.</td><td>Management reports
should be generated from in some of the
- following formats XML,
PDF</td><td>-</td><td>Low</td></tr></tbody></table></div></div><br
class="table-break"/></div><div class="section" title="Non-functional
Requirements"><div class="titlepage"><div><div><h2 class="title"><a
id="id36068030"/>Non-functional Requirements</h2></div></div></div><p>This
section deals with all the non-funtional requirements.</p><div
class="table"><a id="id36068040"/><p class="title"><b>Table 8. Security
requirements</b></p><div class="table-contents"><table summary="Security
requirements"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>B.1.1.</td><td>Support the
usage of X509 Certificates</td><td>2.3, 2.13,
2.14</td><td>High</td></tr><tr><td>B.1.2.</td><td>Support the usage of
ACLs</td><td>B.1,
2.1</td><td>High</td></tr><tr><td>B.1.3.</td><td>Attributes to define
Security levels should be available in
- the
descriptions</td><td>2.1</td><td>High</td></tr><tr><td>B.1.4.</td><td>Transport
and user level security should be given</td><td>2.1, 2.13,
2.14</td><td>High</td></tr><tr><td>B.1.5.</td><td>Allow geographical region
to be
specified</td><td>B.4</td><td>High</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36068198"/><p
class="title"><b>Table 9. Quality of Service</b></p><div
class="table-contents"><table summary="Quality of Service"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>B.2.1.</td><td>Support
capacities requirements for recovery / failover
+ following formats XML,
PDF</td><td>-</td><td>Low</td></tr></tbody></table></div></div><br
class="table-break"/></div><div class="section" title="Non-functional
Requirements"><div class="titlepage"><div><div><h2 class="title"><a
id="id36068026"/>Non-functional Requirements</h2></div></div></div><p>This
section deals with all the non-funtional requirements.</p><div
class="table"><a id="id36068035"/><p class="title"><b>Table 8. Security
requirements</b></p><div class="table-contents"><table summary="Security
requirements"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>B.1.1.</td><td>Support the
usage of X509 Certificates</td><td>2.3, 2.13,
2.14</td><td>High</td></tr><tr><td>B.1.2.</td><td>Support the usage of
ACLs</td><td>B.1,
2.1</td><td>High</td></tr><tr><td>B.1.3.</td><td>Attributes to define
Security levels should be available in
+ the
descriptions</td><td>2.1</td><td>High</td></tr><tr><td>B.1.4.</td><td>Transport
and user level security should be given</td><td>2.1, 2.13,
2.14</td><td>High</td></tr><tr><td>B.1.5.</td><td>Allow geographical region
to be
specified</td><td>B.4</td><td>High</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36068194"/><p
class="title"><b>Table 9. Quality of Service</b></p><div
class="table-contents"><table summary="Quality of Service"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>B.2.1.</td><td>Support
capacities requirements for recovery / failover
cases</td><td>2.7</td><td>Low</td></tr><tr><td>B.2.2.</td><td>Support of
attributes in the VM description to define QoS
level (this also includes the reponse
times)</td><td>2.1</td><td>High</td></tr><tr><td>B.2.3.</td><td>Support of
attributes in the VM describing the Isolation
level</td><td>2.1</td><td>Medium</td></tr><tr><td>B.2.4.</td><td>Support of
attributes for an advanced reservation
-
functionality</td><td>2.3</td><td>Low</td></tr><tr><td>B.2.5.</td><td>Allow
VM response times to be
specified</td><td>B.4</td><td>High</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36068357"/><p
class="title"><b>Table 10. Syntax</b></p><div class="table-contents"><table
summary="Syntax"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>B.3.1.</td><td>No
development tools or libraries should be needed by the
+
functionality</td><td>2.3</td><td>Low</td></tr><tr><td>B.2.5.</td><td>Allow
VM response times to be
specified</td><td>B.4</td><td>High</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36068353"/><p
class="title"><b>Table 10. Syntax</b></p><div class="table-contents"><table
summary="Syntax"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>B.3.1.</td><td>No
development tools or libraries should be needed by the
end-user</td><td>2.8</td><td>Medium</td></tr><tr><td>B.3.2.</td><td>Support
simple JSON syntax to suppot Ajax interface</td><td>2.4,
2.10</td><td>Medium</td></tr><tr><td>B.3.3.</td><td>Clear definition of
units (MB, GB etc) should be used in
- the requests (Like those defined by IEC 60027-2
A.2)</td><td>A.2,
2.4</td><td>Medium</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36068481"/><p
class="title"><b>Table 11. Backup/Disaster recovery</b></p><div
class="table-contents"><table summary="Backup/Disaster recovery"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>B.4.1.</td><td>Support a
backup functionality of cloud
resources</td><td>-</td><td>Low</td></tr><tr><td>B.4.2.</td><td>The
interface should reconsider failover, disaster recovery
- and business continuity
plans</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br
class="table-break"/></div></div><div class="article" title="OCCI
Walkthrough"><div class="titlepage"><div><div><h2 class="title"><a
id="id36066277"/>OCCI Walkthrough</h2></div></div><hr/></div><div
class="section" title="Overview"><div class="titlepage"><div><div><h2
class="title"><a id="id36066634"/>Overview</h2></div><div><h3
class="subtitle">THIS WALKTHROUGH DOCUMENT DOES NOT REFLECT THE CURRENT
STATE OF
+ the requests (Like those defined by IEC 60027-2
A.2)</td><td>A.2,
2.4</td><td>Medium</td></tr></tbody></table></div></div><br
class="table-break"/><div class="table"><a id="id36068476"/><p
class="title"><b>Table 11. Backup/Disaster recovery</b></p><div
class="table-contents"><table summary="Backup/Disaster recovery"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align: center">ID</th><th style="text-align:
center">Description</th><th style="text-align: center">Usecases</th><th
style="text-align:
center">Priority</th></tr></thead><tbody><tr><td>B.4.1.</td><td>Support a
backup functionality of cloud
resources</td><td>-</td><td>Low</td></tr><tr><td>B.4.2.</td><td>The
interface should reconsider failover, disaster recovery
+ and business continuity
plans</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br
class="table-break"/></div></div><div class="article" title="OCCI
Walkthrough"><div class="titlepage"><div><div><h2 class="title"><a
id="id36066264"/>OCCI Walkthrough</h2></div></div><hr/></div><div
class="section" title="Overview"><div class="titlepage"><div><div><h2
class="title"><a id="id36066681"/>Overview</h2></div><div><h3
class="subtitle">THIS WALKTHROUGH DOCUMENT DOES NOT REFLECT THE CURRENT
STATE OF
THE SPECIFICATION. IT WILL BE UPDATED ON
PUBLICATION.</h3></div></div></div><p>The Open Cloud Computing Interface
(OCCI) is an API for managing
cloud infrastructure services (also known as Infrastructure as a
Service
- or IaaS) which strictly adheres to REpresentational State Transfer
(REST)
+ or IaaS), which strictly adheres to REpresentational State Transfer
(REST)
principles and is closely tied to HyperText Tranfer Protocol (HTTP).
For
simplicity and scalability reasons it specifically avoids Remote
Procedure
Call (RPC) style interfaces and can essentially be implemented as a
horizontally scalable document repository with which both nodes and
clients interact.</p><p>This document describes a step-by-step
walkthrough of performing
- various tasks as at the time of writing.</p></div><div class="section"
title="Getting Started"><div class="titlepage"><div><div><h2
class="title"><a id="id36066657"/>Getting
Started</h2></div></div></div><h3><a
id="id36066663"/>Connecting</h3><p>Each implementation has a single OCCI
end-point URL (we'll use
- http://example.com/) and everything you need to know is linked from
this
+ various tasks as at the time of writing.</p></div><div class="section"
title="Getting Started"><div class="titlepage"><div><div><h2
class="title"><a id="id36066705"/>Getting
Started</h2></div></div></div><h3><a
id="id36066710"/>Connecting</h3><p>Each implementation has a single OCCI
end-point URL (we'll use
+ http://example.com/) and everything needed to know is linked from this
point - configuring clients is just a case of providing this
parameter. In
- the simplest case the end-point may contain only a single resource or
type
- of resource (e.g. a hypervisor burnt into the BIOS of a motherboard
- exposing compute resources, a network switch/router exposing network
- resources or a SAN exposing storage resources) and at the other end of
the
- spectrum it may provide access to a global cloud infrastructure (e.g.
the
+ the simplest case, the end-point may contain only a single resource,
for
+ example, a hypervisor burnt into the BIOS of a motherboard that exposes
+ compute resources, a network switch/router exposing network resources
or a
+ SAN exposing storage resources. At the other end of the spectrum the
+ end-point may provide access to a global cloud infrastructure (e.g. the
"Great Global Grid" or GGG). You will only ever see those resources to
which you have access to (typically all of them for a private cloud or
a
- small subset for a public cloud) and flexible categorisation and search
- provide fine-grained control which resources are returned, allowing
OCCI
- to handle the largest of installations. You will always connect to this
- end-point over HTTP(S) and given the simplicity of the interface most
- user-agents are suitable, including libraries (e.g. urllib2, LWP),
command
- line tools (e.g. curl, wget) and full blown browsers (e.g.
- Firefox).</p><h3><a id="id36066669"/>Authenticating</h3><p>When you
connect you will normally be challenged to authenticate via
+ small subset for a public cloud) and flexible categorisation. The
search
+ extension provides fine-grained control which resources are returned,
+ allowing OCCI to handle the largest of installations. The end-point is
+ always connected over HTTP(S) and given the simplicity of the interface
+ most user-agents are suitable, including libraries (e.g. urllib2, LWP),
+ command line tools (e.g. curl, wget) and full blown browsers (e.g.
+ Firefox).</p><h3><a id="id36066717"/>Authenticating</h3><p>When you
connect you will normally be challenged to authenticate via
HTTP (this is not always the case - in secure/offline environments it
may
not be necessary) and will need to do so via the specified mechanism.
It
is anticipated that most implementations will require HTTP Basic
- Authentication over SSL/TLS so at the very least you should support
this
- (fortunately almost all user-agents already do), but more advanced
- mechanisms such as NTLM or Kerberos may be deployed. Certain types of
- accesses (such as a compute resource querying OCCI for introspection
and
- configuration) may be possible anonymously (having already been
- authenticated by interface and/or IP address). Should you be
redirected by
- the API to a node, storage device, etc. (for example, to retrieve a
large
- binary representation) then you should either be able to transparently
- authenticate or a signed URL should be provided. That is, a single set
of
- credentials is all that is required to access the entire system from
any
- point.</p><h3><a id="id36066676"/>Representations</h3><p>As the
resource itself (e.g. a physical machine, storage array or
- network switch) cannot be transferred over HTTP (at least not yet!) we
- instead make available one or more representations of that resource.
For
- example, an API modeling a person might return a picture, fingerprints,
- identity document(s) or even a digitised DNA sequence, but not the
person
- themselves. A circle might be represented by SVG drawing primatives or
any
- three distinct points on the curve. For cloud infrastructure there are
- many useful representations, and while OCCI standardises a number of
them
- for interoperability purposes, an implementation is free to implement
- others in order to best serve the specific needs of their users and to
+ Authentication over SSL/TLS so at the very least you should support
this,
+ but more advanced mechanisms such as NTLM or Kerberos may be deployed.
+ Certain types of accesses such as a compute resource querying OCCI for
+ introspection and configuration may be possible anonymously but only
+ having already been authenticated by interface and/or IP address.
Should
+ you be redirected by the API to a node, storage device, etc. (for
example,
+ to retrieve a large binary representation) then the OCCI provider
should
+ provide means to transparently authenticate the currently authenticated
+ user. That is, a single set of credentials and a single sign-on is all
+ that is required to access the entire system from any point.</p><h3><a
id="id36066724"/>Representations</h3><p>As the resource itself (e.g. a
physical machine, storage array or
+ network switch) cannot be transferred over HTTP we instead make
available
+ one or more representations of that resource. For example, an API
modeling
+ a person might return a picture, fingerprints, identity document(s) or
+ even a digitised DNA sequence, but not the person themselves. A circle
+ might be represented by SVG drawing primatives or any three distinct
+ points on the curve. For cloud infrastructure there are many useful
+ representations, and while OCCI recommends a number of them for
+ interoperability purposes, an implementation is free to implement
others
+ in order to best serve the specific needs of their users and to
differentiate from other offerings. Other examples include:</p><div
class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Open
Cloud Computing Interface (OCCI) descriptor format
(application/occi+xml)</p></li><li class="listitem"><p>Open
Virtualisation Format (OVF) file
(application/ovf+xml?)</p></li><li class="listitem"><p>Open
Virtualisation Archive (OVA) file
- (application/x-ova?)</p></li><li class="listitem"><p>Screenshot of
the console (image/png)</p></li><li class="listitem"><p>Access to the
console (application/x-vnc)</p></li></ul></div><p>The client indicates
which representation(s) it desires by way of
- the URL and/or HTTP Accept headers (e.g. HTTP Content Negotiation) and
if
- the server is unable to satisfy the request then it should return HTTP
406
- Not Acceptable.</p><h3><a id="id36066735"/>Descriptors</h3><p>In
addition to the protocol itself, OCCI defines a simple key/value
- based descriptor format for cloud infrastructure resources:</p><div
class="glosslist"><dl><dt>compute</dt><dd><p>Provides computational
services, ranging from dedicated
+ (application/x-ova?)</p></li></ul></div><p>Other, albeit lesser
representations, could include:</p><div class="itemizedlist"><ul
class="itemizedlist"><li class="listitem"><p>Screenshot of the console
(image/png)</p></li><li class="listitem"><p>Access to the console
(application/x-vnc)</p></li></ul></div><p>The client indicates which
representation(s) it desires by way of
+ HTTP Content Negotiation using the HTTP Accept header and if the
server is
+ unable to satisfy the request then it should return HTTP 406 Not
+ Acceptable. The client can also request the rendering via URL
extension,
+ if the server supports this option.</p><h3><a
id="id36066791"/>Descriptors</h3><p>OCCI defines a simple attribute-based
(key/value) descriptor format
+ for cloud infrastructure resources. These infrastructure resources as
+ defined by OCCI are:</p><div class="glosslist"><dl><dt><span
class="bold"><strong>Compute:</strong></span></dt><dd><p>Provides
computational services, ranging from dedicated
physical machines (e.g. Dedibox) to virtual machines (e.g. Amazon
- EC2) to slices/zones/containers (e.g. Mosso Cloud
Servers).</p></dd><dt>network</dt><dd><p>Provides connectivity between
machines and the outside world.
+ EC2) to slices/zones/containers (e.g. Mosso Cloud
Servers).</p></dd><dt><span
class="bold"><strong>Network:</strong></span></dt><dd><p>Provides
connectivity between machines and the outside world.
Usually virtual and may or may not be connected to a physical
- segment.</p></dd><dt>storage</dt><dd><p>Provides storage
services, typically via magnetic mass storage
+ segment.</p></dd><dt><span
class="bold"><strong>Storage:</strong></span></dt><dd><p>Provides storage
services, typically via magnetic mass storage
devices (e.g. hard drives, RAID arrays,
SANs).</p></dd></dl></div><p>Given the simplicity of the format it is
trivial to translate
- between wire formats including plain text, JSON, XML and others. For
+ between wire formats including plain text, JSON, XML and others
+ <em><span class="remark"><--| Insert alternative examples |
--></span></em> . For
example:</p><pre class="screen">occi.compute.cores 2
compute.speed 3200
-compute.memory 2048</pre><h3><a id="id36066800"/>Identifiers</h3><p>Each
resource is identified by its dereferenceable URL which is by
+compute.memory 2048</pre><h3><a id="id36064816"/>Identifiers</h3><p>Each
resource is identified by its dereferenceable URL which is by
definition unique, giving information about the origin and type of the
- resource as well as a local identifier (the combination of which forms
a
- globally unique compound key). The primary drawback is that the more
- information that goes into the key (and therefore the more transparent
it
- is), the more likely it is to change. For example, if you migrate a
- resource from one implementation to another then its identifier will
- change (though in this instance the source should provide a HTTP 301
Moved
- Permanently response along with the new location, assuming it is
known, or
- HTTP 410 Gone otherwise).</p><p>In order to realise the benefit of
transparent, dereferenceable
+ resource as well as a local identifier. The combination of both forms a
+ globally unique compound key.<em><span class="remark"> <--| Is this
necessary
+ here?</span></em> The primary drawback is that the more information
that goes
+ into the key (and therefore the more transparent it is), the more
likely
+ it is to change. For example, if you migrate a resource from one
+ implementation to another then its identifier will change (though in
this
+ instance the source should provide a HTTP 301 Moved Permanently
response
+ along with the new location, assuming it is known, or HTTP 410 Gone
+ otherwise).<em><span class="remark">|--></span></em></p><p>In order
to realise the benefit of transparent, dereferenceable
identifiers while still being able to track resources through their
entire
lifecycle an immutable UUID attribute should be allocated which will
remain with the resource throughout its life. This is particularly
important where the same resource (e.g. a network) appears in multiple
- places.</p><p>New implementations should use type 4 (random) UUIDs
anyway, as
- these can be safely allocated by any node without consulting a
- register/sequence, but where existing identifiers are available they
- should be used instead (e.g.
- http://amazon.com/compute/ami-ef48af86).</p></div><div class="section"
title="Operations"><div class="titlepage"><div><div><h2 class="title"><a
id="id36064772"/>Operations</h2></div></div></div><h3><a
id="id36064777"/>Create</h3><p>To create a resource simply POST it to the
appropropriate collection
- (e.g. /compute, /network or /storage) as an HTML form (supported by
- virtually all user agents) or in another supported format (e.g.
- OVF):</p><pre class="screen">POST /compute HTTP/1.1
+ places.</p><p>New implementations should use type-4 random UUIDs, as
these can be
+ safely allocated by any OCCI-compliant provider without consulting a
+ register/sequence. Where existing identifiers are available they
should be
+ used instead (e.g.
+ http://an.occi.provider.com/compute/ami-ef48af86).</p></div><div
class="section" title="Operations"><div class="titlepage"><div><div><h2
class="title"><a id="id36064848"/>Operations</h2></div></div></div><h3><a
id="id36064854"/>Create</h3><p>To create a resource simply POST the
resource representation to the
+ appropriate collection (e.g. /compute, /network or /storage) using the
+ application/x- www-form-urlencoded format (used by HTML forms) or in
+ another supported format (e.g. OVF):</p><pre class="screen">POST
/compute HTTP/1.1
Host: example.com
Content-Length: 35
Content-Type: application/x-www-form-urlencoded
compute.cores=2&compute.memory=2048</pre><p>Rather than generating the
new resource from scratch you may also be
- given the option to GET a template and POST or PUT it back (for
example,
- where "small", "medium" and "large" instances or pre-configured
appliances
- are offered).</p><h3><a id="id36064797"/>Retrieve</h3><p>The simplest
command is to retrieve a single resource by conducting
+ given the option <em><span class="remark"><--| Templates are not
explained in the
+ walkthrough </span></em>to GET a template <em><span class="remark">|
--> </span></em>and
+ <em><span class="remark"><--| Semantic differences between the 2|
</span></em>POST or PUT
+ <em><span class="remark">|--> </span></em>it back, for example,
where "small", "medium" and
+ "large" templates or pre-configured appliances are offered.</p><h3><a
id="id36064889"/>Retrieve</h3><p>The simplest command is to retrieve a
single resource by conducting
a HTTP GET on its URL (which doubles as its identifier):</p><pre
class="screen">GET /compute/b10fa926-41a6-4125-ae94-bfad2670ca87 HTTP/1.1
Host: example.com</pre><p>This will return <em><span class="remark">a HTTP
300 Multiple Choices response
containing a list of available representations for the resource as
well as
a suggestion in the form of a HTTP Location: header of</span></em> the
default rendering, which should be HTML (thereby allowing standard
browsers to access the API directly). An arbitrary number of
alternatives
- may also be returned by way of HTTP Link: headers.</p><p>If you just
need to know what representations are available you
+ may also be returned by way of HTTP Link: headers. <em><span
class="remark"><--| this
+ requires 2 calls by default |--></span></em></p><p>If you just need
to know what representations are available you
should make a HEAD request instead of a GET - this will return the
- metadata in the headers without the default rendering.</p><p>Some
requests (such as searches) will need to return a collection of
- resources. There are two options:</p><div
class="glosslist"><dl><dt>Pass-by-reference</dt><dd><p>A plain text or HTML
list of links is provided but each needs
- to be retrieved separately, resulting in O(n+1)
performance.</p></dd><dt>Pass-by-value</dt><dd><p>A wrapper format such as
Atom is used to deliver [links to]
+ metadata in the headers without the default rendering.</p><p>Some
requests, such as the collections returned using the search
+ extension, will need to return a collection of resources. There are two
+ concepts that are supported:</p><div
class="glosslist"><dl><dt>Pass-by-reference:</dt><dd><p>A plain text or
HTML list of links is provided but each needs
+ to be retrieved separately, resulting in O(n+1)
performance.</p></dd><dt>Pass-by-value:</dt><dd><p>A wrapper format such as
Atom is used to deliver [links to]
the content as well as the metadata (e.g. links, associations,
- cahching information, etc.), resulting in O(1)
performance.</p></dd></dl></div><h3><a
id="id36064863"/>Update</h3><p>Updating resources is trivial - simply GET
the resource, modify it
- as necessary and PUT it back where you found it.</p><h3><a
id="id36064871"/>Delete</h3><p>Simply <code
class="computeroutput">DELETE</code> the resource:</p><pre
class="screen">DELETE /compute/b10fa926-41a6-4125-ae94-bfad2670ca87 HTTP/1.1
-Host: example.com</pre></div><div class="section" title="Sub-resource
Collections"><div class="titlepage"><div><div><h2 class="title"><a
id="id36064886"/>Sub-resource
Collections</h2></div></div></div><p><em><span class="remark">(For want of
a better name) </span></em></p><p>Each resource may expose collections for
functions such as logging,
+ caching information, etc.), resulting in O(1)
performance.</p></dd></dl></div><h3><a
id="id36064957"/>Update</h3><p>Updating resources is trivial - simply GET
the resource, modify it
+ as necessary and PUT <em><span class="remark"><--| What about
someone using POST?
+ --></span></em> it back where you found it.</p><h3><a
id="id36064969"/>Delete</h3><p>Simply <code
class="computeroutput">DELETE</code> the resource:</p><pre
class="screen">DELETE /compute/b10fa926-41a6-4125-ae94-bfad2670ca87 HTTP/1.1
+Host: example.com</pre></div><div class="section" title="Resource Child
Collections"><div class="titlepage"><div><div><h2 class="title"><a
id="id36064984"/>Resource Child Collections</h2></div></div></div><p>Each
resource may expose collections for functions such as logging,
auditing, change control, documentation and other operations (e.g.
http://example.com/compute/123/log/456) in addition to any required by
OCCI. As usual CRUD operations map to HTTP verbs (as above) and clients
can either PUT entries directly if they know or will generate the
identifiers, or POST them to the collection if this will be handled on
the
- server side (using POST Once Exactly (POE) to ensure
idempotency).</p><h3><a id="id36064904"/>Requests</h3><p>Requests are used
to trigger state changes and other operations such
- as backups, snapshots, migrations and invasive reconfigurations (such
as
- storage resource resizing). Those that do not complete immediately
- (returning HTTP 200 OK or similar) must be handled asynchronously
- (returning HTTP 201 Accepted or similar).</p><pre class="screen">POST
/compute/123/requests HTTP/1.1
+ server side (using POST Once Exactly (POE) to ensure
idempotency).</p><h3><a id="id36064998"/>Requests</h3><p><em><span
class="remark"><--| This section must reference somewhere that lists
+ these </span></em>Requests <em><span class="remark">|
--></span></em>are used to trigger state
+ changes and other operations such as backups, snapshots, migrations and
+ invasive reconfigurations (such as storage resource resizing). Those
that
+ do not complete immediately (returning HTTP 200 OK or similar) must be
+ handled asynchronously (returning HTTP 201 Accepted or
similar).</p><pre class="screen">POST /compute/123/requests HTTP/1.1
Host: example.com
Content-Length: 35
Content-Type: application/x-www-form-urlencoded
@@ -426,7 +434,7 @@
which are only handled daily at midnight) and may take some time to
complete (for example a secure erase which requires multiple passes
over
the disk). Clients can poll for status periodically or use server push
(or
- a non-HTTP technology such as XMPP) to monitor for
events.</p></div></div><div class="article" title="OCCI Frequently Asked
Questions"><div class="titlepage"><div><div><h2 class="title"><a
id="id36066287"/>OCCI Frequently Asked
Questions</h2></div></div><hr/></div><div class="section"
title="General"><div class="titlepage"><div><div><h2 class="title"><a
id="id36066406"/>General</h2></div></div></div><div
class="glosslist"><dl><dt>Who created the Open Cloud Computing Interface
+ a non-HTTP technology such as XMPP) to monitor for
events.</p></div></div><div class="article" title="OCCI Frequently Asked
Questions"><div class="titlepage"><div><div><h2 class="title"><a
id="id36066411"/>OCCI Frequently Asked
Questions</h2></div></div><hr/></div><div class="section"
title="General"><div class="titlepage"><div><div><h2 class="title"><a
id="id36066537"/>General</h2></div></div></div><div
class="glosslist"><dl><dt>Who created the Open Cloud Computing Interface
(OCCI)?</dt><dd><p>The Open Grid Forum (OGF)'s Open Cloud
Computing Interface
Working Group (OCCI-WG) created the Open Cloud Computing
Interface
(OCCI).</p></dd><dt>Who are the Open Cloud Computing Interface
Working Group
@@ -435,42 +443,50 @@
the chairs, and Sam Johnston (Australian Online Solutions) is the
secretary.</p></dd><dt>Who else was involved?</dt><dd><p>Around
200 individuals representing over 100 companies were
involved in the development of the Open Cloud Computing Interface
- (OCCI).</p></dd></dl></div></div><div class="section" title="Use
Cases"><div class="titlepage"><div><div><h2 class="title"><a
id="id36066463"/>Use Cases</h2></div></div></div><div
class="glosslist"><dl><dt>How were the use cases collected?</dt><dd><p>Use
cases were solicited from the working group mailing list
- as well as other external sources.</p></dd></dl></div></div><div
class="section" title="Technical"><div class="titlepage"><div><div><h2
class="title"><a id="id36066488"/>Technical</h2></div></div></div><div
class="glosslist"><dl><dt>Why didn't you invent your own XML
+ (OCCI).</p></dd></dl></div></div><div class="section" title="Use
Cases"><div class="titlepage"><div><div><h2 class="title"><a
id="id36066595"/>Use Cases</h2></div></div></div><div
class="glosslist"><dl><dt>How were the use cases collected?</dt><dd><p>Use
cases were solicited from the working group mailing list
+ as well as other external sources.</p></dd></dl></div></div><div
class="section" title="Technical"><div class="titlepage"><div><div><h2
class="title"><a id="id36066620"/>Technical</h2></div></div></div><div
class="glosslist"><dl><dt>Why didn't you invent your own XML
representation?</dt><dd><p>See Tim Bray's Don’t Invent XML
- Languages post.</p></dd></dl></div></div></div><div
class="article" title="OCCI Core Specification"><div
class="titlepage"><div><div><h2 class="title"><a id="id36068729"/>OCCI Core
Specification</h2></div></div><hr/></div><div class="section"
title="Introduction"><div class="titlepage"><div><div><h2 class="title"><a
id="id36069560"/>Introduction</h2></div></div></div><p>The Open Cloud
Computing Interface (OCCI) is an open protocol for
- all cloud computing services. A RESTful interface, it deviates from the
- underlying HyperText Transfer Protocol (HTTP) only where absolutely
- necessary and can be described as a "Resource Oriented Architecture
+ Languages post.</p></dd></dl></div></div></div><div
class="article" title="OCCI Core Specification & Models"><div
class="titlepage"><div><div><h2 class="title"><a id="id36066417"/>OCCI Core
Specification & Models</h2></div></div><hr/></div><div class="section"
title="Introduction"><div class="titlepage"><div><div><h2 class="title"><a
id="id36069859"/>Introduction</h2></div></div></div><p>The Open Cloud
Computing Interface (OCCI) is an open protocol for
+ cloud computing services. It initially targets the infrastructure
services
+ (IaaS) layer but its modular design which extends this OCCI Core
+ Specification allows for future targeting of the platform services
(PaaS)
+ and application services (SaaS) layers on a future roadmap.</p><p>A
Representational State Transfer (REST) protocol, it deviates from
+ the underlying HyperText Transfer Protocol (HTTP) only where absolutely
+ necessary and could be described as a "Resource Oriented Architecture
(ROA)".<a class="xref" href="#core-rws" title="RESTful Web
Services">RWS</a> Unlike other envelope-based protocols
- which operate in-band, all existing HTTP features are available for
- caching, proxying, gatewaying and other advanced functionality such as
- partial GETs.</p><p>Each resource is identified by URL(s) and has one
or more
- representations which may include a hypertext (e.g. XHTML5) rendering
for
- direct end-user accessibility. As such OCCI can present both a machine
- interface (using native resource renderings) and a user interface
(using
- HTML markup with forms and other web technologies such as
- Javascript/Ajax). HTTP content negotiation is used to select between
- alternative representations and metadata including associations between
- resources is exposed via HTTP headers (e.g. the
- <code class="computeroutput">Link:</code> and
+ such as Atom and SOAP (which describe complex XML-based structures for
+ data transferred within the HTTP payload, essentially duplicating
HTTP's
+ built in header-based metadata functionality), OCCI provides a "clean
+ channel" over which any suitable format can travel without
modification or
+ wrapping, using HTTP to its full extent in the way it was intended.
OCCI
+ also uses various HTTP verbs in transactions rather than tunneling
+ everything over POST, as was the case with SOAP and the various WS-*
+ protocols. As such all existing HTTP features are available for
caching,
+ proxying, gatewaying and other advanced functionality such as partial
+ GETs.</p><p>Each resource (i.e. a compute node) is identified by
URL(s) and has
+ one or more native representations (i.e. Open Virtualisation Format or
+ OVF) as well as a generic XHTML5 rendering. The latter allows for
direct
+ end-user accessibility with well-formed, embedded semantic web markup
for
+ consumption by both human and machine clients. As such OCCI
simultaneously
+ presents both a machine interface (using native resource renderings)
and a
+ user interface (using HTML markup with forms and other web technologies
+ such as Javascript/Ajax) so as to satisfy all common use cases. HTTP
+ content negotiation is used to select between alternative
representations
+ and metadata including associations between resources is exposed via
HTTP
+ headers (e.g. the <code class="computeroutput">Link:</code> and
<code class="computeroutput">Category:</code> headers).</p><p>In this
way OCCI is not responsible for the representations
themselves, rather it enables users to organise and group resources
together to build arbitrarily complex systems of inter-related
resources.
It relies on existing standards for rendering and does not make any
- recommendations of one standard format over any other.</p><div
class="tip" title="Tip" style="margin-left: 0.5in; margin-right:
0.5in;"><h3 class="title">Tip</h3><p>This is the case for the World Wide
Web today where many image,
- video and other supporting formats co-exist. Browsers support a
number
- of the common formats and users choose the most appropriate for the
- task.</p></div><div class="section" title="Example"><div
class="titlepage"><div><div><h3 class="title"><a
id="id36069607"/>Example</h3></div></div></div><pre class="screen">> GET
/us-east/webapp/vm01 HTTP/1.1
-> User-Agent: occi-client/1.0 (linux) libcurl/7.19.4 OCCI/1.0
+ recommendations of one standard format over any other, in the same way
as
+ the Internet has many popular image formats.</p><div class="section"
title="Example"><div class="titlepage"><div><div><h3 class="title"><a
id="id36069910"/>Example</h3></div></div></div><pre class="screen">> GET
/us-east/webapp/vm01 HTTP/1.1
> Host: cloud.example.com
> Accept: */*
>
< HTTP/1.1 200 OK
-< Date: Sat, 10 Oct 2009 12:56:51 GMT
< Content-Type: application/ovf
< Link: </us-east/webapp/vm01;start>;
-< rel="http://purl.org/occi/action/start";
+< rel="http://purl.org/occi/action#start";
< title="Start"
< Link: </us-east/webapp/build.pdf>;
< rel="related";
@@ -478,27 +494,119 @@
< type="application/pdf"
< Category: compute;
< label="Compute Resource";
-< scheme="http://purl.org/occi/kind/"
+< scheme="http://purl.org/occi/kind#"
< Server: occi-server/1.0 (linux) OCCI/1.0
< Connection: close
<
< <?xml version="1.0" encoding="UTF-8"?>
-< <Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-< xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1"
-< xmlns="http://schemas.dmtf.org/ovf/envelope/1"
-< xml:lang="en-US">
-...</pre></div></div><div class="section" title="Basics"><div
class="titlepage"><div><div><h2 class="title"><a
id="id36069626"/>Basics</h2></div></div></div><div class="section"
title="Entry point"><div class="titlepage"><div><div><h3 class="title"><a
id="id36069631"/>Entry point</h3></div></div></div><p>The interface is
defined by a single URL entry point which will
- either be a <em class="glossterm">collection</em>, contain
- <em class="glossterm">link</em>(s) to <em
class="glossterm">collection</em>(s)
- or both.</p></div><div class="section" title="Kinds, Actions &
Attributes"><div class="titlepage"><div><div><h3 class="title"><a
id="id36069653"/>Kinds, Actions &
Attributes</h3></div></div></div><p>An interface exposes "kinds" which
have "attributes" and on which
- "actions" can be performed. The attributes are exposed as key-value
- pairs and applicable actions as links, following the REST hypertext
- constraint (whereby state transitions are defined
- <em class="glossterm">in-band</em> rather than via
rules).</p></div><div class="section" title="HTTP Verbs"><div
class="titlepage"><div><div><h3 class="title"><a id="id36069669"/>HTTP
Verbs</h3></div></div></div><p>Create, Retrieve, Update and Delete (CRUD)
operations map to the
+...</pre></div></div><div class="section" title="Essentials"><div
class="titlepage"><div><div><h2 class="title"><a
id="id36069926"/>Essentials</h2></div></div></div><div class="section"
title="Connection"><div class="titlepage"><div><div><h3 class="title"><a
id="id36069932"/>Connection</h3></div></div></div><div class="section"
title="Authentication"><div class="titlepage"><div><div><h4
class="title"><a
id="id36069938"/>Authentication</h4></div></div></div><p>Servers <span
class="emphasis"><em>may</em></span> require that requests be
+ authenticated using standard HTTP-based authentication mechanisms
+ (including OAuth).<a class="xref" href="#core-oauth"
title="OAuth">OAuth</a> They indicate this
+ requirement by returning <code class="code">HTTP 401</code> with a
+ <code class="code">WWW-Authenticate</code> header and a suitable
challenge (e.g.
+ <code class="code">Basic</code>, <code class="code">Digest</code>,
<code class="code">OAuth</code>). </p><pre class="screen">> GET /
HTTP/1.1
+> Host: cloud.example.com
+>
+< HTTP/1.1 401 Unauthorized
+< WWW-Authenticate: OAuth realm="http://sp.example.com/"</pre><p>The
client then includes appropriate <code class="code">Authorization</code>
+ headers in its responses:<a class="xref" href="#core-rfc2617"
title="RFC 2617 - HTTP Authentication: Basic and Digest Access
Authentication">RFC2617</a></p><pre class="screen">> GET / HTTP/1.1
+> Authorization: OAuth realm="http://sp.example.com/",
+> oauth_consumer_key="0685bd9184jfhq22",
+> oauth_token="ad180jjd733klru7",
+> oauth_signature_method="HMAC-SHA1",
+> oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
+> oauth_timestamp="137131200",
+> oauth_nonce="4572616e48616d6d65724c61686176",
+> oauth_version="1.0"</pre></div><div class="section"
title="Cookies"><div class="titlepage"><div><div><h4 class="title"><a
id="id36069997"/>Cookies</h4></div></div></div><p>Servers <span
class="emphasis"><em>may</em></span> set and clients
+ <span class="emphasis"><em>may</em></span> accept <em
class="glossterm">cookies</em> in
+ order to maintain authentication state between requests:<a
class="xref" href="#core-rfc2109" title="RFC 2109 - HTTP State Management
Mechanism">RFC2109</a></p><pre class="screen">Set-Cookie:
session=4732518c5fe6dbeb8429cdda11d65c3d; domain=.example.com;
path=/</pre><div class="warning" title="Warning" style="margin-left: 0.5in;
margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Such sessions <span
class="emphasis"><em>should not</em></span> be used for
+ other purposes (such as server-side state) in line with RESTful
+ principles.</p></div></div><div class="section"
title="Versioning"><div class="titlepage"><div><div><h4 class="title"><a
id="id36070037"/>Versioning</h4></div></div></div><p>Servers and clients
<span class="emphasis"><em>should</em></span> indicate the
+ latest version of OCCI they support (e.g.
+ <code class="computeroutput">1.0</code>) by way of the
+ <code class="computeroutput">Server:</code> and
+ <code class="computeroutput">User-Agent:</code> headers
respectively,
+ using the token <span class="quote">“<span class="quote"><code
class="computeroutput">OCCI</code></span>”</span>
+ (e.g. <span class="quote">“<span class="quote"><code
class="computeroutput">OCCI/1.0</code></span>”</span>). If
+ none is provided the latest (highest supported version number)
+ available version offered by the server <span
class="emphasis"><em>should</em></span> be
+ used:</p><pre class="screen">> GET / HTTP/1.1
+> Host: cloud.example.com
+> User-Agent: occi-client/1.0 (linux) libcurl/7.19.4 OCCI/1.0
+>
+< HTTP/1.1 200 OK
+< Server: Apache/2.2.13 (Unix) OCCI/1.0</pre></div></div><div
class="section" title="Addressing"><div class="titlepage"><div><div><h3
class="title"><a id="id36070082"/>Addressing</h3></div></div></div><p>A
single entry point is defined by a URL (e.g.
+ <code class="uri">http://cloud.example.com/</code>) which may be a
collection of
+ resources or some other page as defined by the implementor (e.g. a
+ descriptive web page). Therefore OCCI is fully compatible with any
+ existing web presence such as a marketing site or landing
page.</p><p>All resources <span class="emphasis"><em>must</em></span> be
addressible by URLs
+ (whose structure is opaque and at the discretion of the implementor)
and
+ discoverable via search and/or link traversal from the entry point.
+ Clients <span class="emphasis"><em>should not</em></span> rely
on "rules" to construct
+ URLs, rather learning them from URLs previously retrieved, in line
with
+ RESTful principles:</p><pre class="screen">> GET /-/compute/
HTTP/1.1
+> Accept: text/uri-list
+>
+< HTTP/1.1 200 OK
+< Content-type: text/uri-list
+<
+< /us-east/new-york/node17
+< /us-west/san-francisco/node43
+< /europe/paris/node38</pre></div><div class="section"
title="Bootstrapping"><div class="titlepage"><div><div><h3 class="title"><a
id="id36070116"/>Bootstrapping</h3></div></div></div><p>Clients will
typically conduct a
+ <code class="computeroutput">GET</code> or
+ <code class="computeroutput">HEAD</code> request on the root
+ (<span class="quote">“<span class="quote"><code
class="uri">/</code></span>”</span>) and discover the category search
+ interface, from which they can learn the supported categories/kinds
and
+ retrieve some or all of them. If they know the URL for the resource
they
+ wish to interact with (e.g. scripts & cron jobs) then they can
+ bypass the discovery process and manipulate it directly.</p><div
class="example"><a id="id36070140"/><p class="title"><b>Example 1. Example
bootstrap</b></p><div class="example-contents"><p>Retrieve a collection of
desired resources (having already
+ discovered the category search URL and available
categories):</p><pre class="screen"># detect category search interface
+> GET / HTTP/1.1
+> Host: cloud.example.com
+>
+< HTTP/1.1 200 OK
+< Content-type: text/html
+< Link: </-/>; rel="search"; title="Category Search"
+<
+< <html>
+< <head>
+< <...>
+<
+# detect categories
+> GET /-/ HTTP/1.1
+>
+< HTTP/1.1 200 OK
+< Content-length: 0
+<
+< Category: compute; label="Compute Resource";
scheme="http://purl.org/occi/kind#"
+< Category: network; label="Network Resource";
scheme="http://purl.org/occi/kind#"
+< Category: storage; label="Storage Resource";
scheme="http://purl.org/occi/kind#"
+< Category: us-east; label="US East Coast";
scheme="http://example.com/locations"
+< Category: us-west; label="US West Coast";
scheme="http://example.com/locations"
+< Category: demo; label="My Customer Demo";
scheme="http://example.com/~user/"
+<
+# retrieve category
+> GET /-/compute HTTP/1.1
+>
+> HTTP/1.1 200 OK
+> Content-type: text/uri-list
+>
+> /node1
+> /node2
+>
+# retrieve resource
+> GET /node1 HTTP/1.1
+>
+> HTTP/1.1 200 OK
+> Content-type: application/ovf
+> <...></pre></div></div><br
class="example-break"/></div></div><div class="section"
title="Operations"><div class="titlepage"><div><div><h2 class="title"><a
id="id36070165"/>Operations</h2></div></div></div><div class="section"
title="HTTP Verbs"><div class="titlepage"><div><div><h3 class="title"><a
id="id36070171"/>HTTP Verbs</h3></div></div></div><p>Create, Retrieve,
Update and Delete (CRUD) operations map to the
POST, GET, PUT and DELETE HTTP verbs respectively. HEAD and OPTIONS
verbs may be used to retrieve metadata and valid operations without
the
entity body to improve performance. WebDAV definitions are used for
- MKCOL, MOVE and COPY.</p><div class="glosslist"><dl><dt>POST
(Create)</dt><dd><p><span class="quote">“<span class="quote">The POST
method is used to request that the origin
+ MKCOL, MOVE and COPY.</p><div class="warning" title="Warning"
style="margin-left: 0.5in; margin-right: 0.5in;"><h3
class="title">Warning</h3><p>Some providers may implement a subset of these
operations, and
+ those available to you for a given resource (if any) may depend on
+ security policy. Be prepared to handle exceptions if you attempt to
+ call operations that are not available to you.</p></div><div
class="glosslist"><dl><dt>POST (Create)</dt><dd><p><span
class="quote">“<span class="quote">The POST method is used to request that
the origin
server accept the entity enclosed in the request as a new
subordinate of the resource identified by the Request-URI in
the
Request-Line.</span>”</span><a class="xref"
href="#core-rfc2616" title="RFC 2616 - Hypertext Transfer Protocol --
HTTP/1.1">RFC2616</a></p><p>POSTing a representation (e.g. OVF) to a
collection (e.g.
@@ -512,11 +620,16 @@
"406 Not Acceptable" will be returned.</p></dd><dt>PUT (Create
or Update)</dt><dd><p><span class="quote">“<span class="quote">The PUT
method requests that the enclosed entity be
stored under the supplied Request-URI.</span>”</span><a
class="xref" href="#core-rfc2616" title="RFC 2616 - Hypertext Transfer
Protocol -- HTTP/1.1">RFC2616</a></p><p>PUTting a representation (e.g. OVF)
to a URL (e.g.
/compute/123) will result in the resource being created or
- updated. The URL is known or selected by the client (in which
case
- UUIDs should be used), in contrast to POSTs where the URL is
- selected by the server.</p></dd><dt>DELETE
(Delete)</dt><dd><p><span class="quote">“<span class="quote">The DELETE
method requests that the origin server
+ updated. The URL is known or selected by the client, in
contrast
+ to POSTs where the URL is selected by the
server.</p></dd><dt>DELETE (Delete)</dt><dd><p><span class="quote">“<span
class="quote">The DELETE method requests that the origin server
delete the resource identified by the
Request-URI.</span>”</span><a class="xref" href="#core-rfc2616" title="RFC
2616 - Hypertext Transfer Protocol -- HTTP/1.1">RFC2616</a></p><p>DELETE
results in the deletion of the resource (and
- everything "under" it, as
appropriate).</p></dd></dl></div><p>Additionally the following HTTP methods
are used:</p><div class="glosslist"><dl><dt>COPY
(Duplicate)</dt><dd><p><span class="quote">“<span class="quote">The COPY
method creates a duplicate of the source
+ everything "under" it, as
appropriate).</p></dd></dl></div><div class="tip" title="Tip"
style="margin-left: 0.5in; margin-right: 0.5in;"><h3
class="title">Tip</h3><p>It is possible to instruct the server to create a
resource based
+ on a default configuration (without requiring client support) by
doing
+ an empty POST/PUT, specifying <span class="quote">“<span
class="quote"><code class="computeroutput">Content-type:
+ application/occi</code></span>”</span> (such that the web server
+ knows where to route the request) and specifying the appropriate
+ <em class="parameter"><code>kind</code></em> category (such that
OCCI knows what to
+ create).</p></div><p>Additionally the following HTTP methods are
used:</p><div class="glosslist"><dl><dt>COPY (Duplicate)</dt><dd><p><span
class="quote">“<span class="quote">The COPY method creates a duplicate of
the source
resource identified by the Request-URI, in the destination
resource identified by the URI in the Destination
header.</span>”</span><a class="xref" href="#core-rfc4918"
title="RFC 4918 - HTTP Extensions for Web Distributed Authoring and
Versioning (WebDAV)">RFC4918</a></p></dd><dt>HEAD (Retrieve - Metadata
Only)</dt><dd><p><span class="quote">“<span class="quote">The HEAD method
is identical to GET except that the
@@ -528,63 +641,28 @@
all three actions are performed in a single
operation.</span>”</span><a class="xref" href="#core-rfc4918"
title="RFC 4918 - HTTP Extensions for Web Distributed Authoring and
Versioning (WebDAV)">RFC4918</a></p></dd><dt>OPTIONS</dt><dd><p><span
class="quote">“<span class="quote">The OPTIONS method represents a request
for
information about the communication options available on the
- request/response chain identified by the
Request-URI.</span>”</span><a class="xref" href="#core-rfc2616" title="RFC
2616 - Hypertext Transfer Protocol --
HTTP/1.1">RFC2616</a></p></dd></dl></div></div></div><div class="section"
title="Connection"><div class="titlepage"><div><div><h2 class="title"><a
id="id36069890"/>Connection</h2></div></div></div><div class="section"
title="Authentication"><div class="titlepage"><div><div><h3
class="title"><a
id="id36069896"/>Authentication</h3></div></div></div><p>Servers <span
class="emphasis"><em>may</em></span> require that requests be
- authenticated using standard HTTP-based authentication mechanisms
- (including OAuth).<a class="xref" href="#core-oauth"
title="OAuth">OAuth</a> They indicate this
- requirement by returning <code class="code">HTTP 401</code> with a
- <code class="code">WWW-Authenticate</code> header and a suitable
challenge (e.g.
- <code class="code">Basic</code>, <code class="code">Digest</code>,
<code class="code">OAuth</code>). The client
- then includes appropriate <code class="code">Authorization</code>
headers in its
- responses.<a class="xref" href="#core-rfc2617" title="RFC 2617 -
HTTP Authentication: Basic and Digest Access
Authentication">RFC2617</a></p><p>Servers <span
class="emphasis"><em>may</em></span> set and clients
- <span class="emphasis"><em>may</em></span> accept <em
class="glossterm">cookies</em> in order
- to maintain authentication state between requests. Such sessions
- <span class="emphasis"><em>should not</em></span> be used for other
purposes (such as
- server-side state) in line with RESTful principles.<a class="xref"
href="#core-rfc2109" title="RFC 2109 - HTTP State Management
Mechanism">RFC2109</a></p></div><div class="section"
title="Versioning"><div class="titlepage"><div><div><h3 class="title"><a
id="id36069962"/>Versioning</h3></div></div></div><p>Servers and clients
<span class="emphasis"><em>should</em></span> indicate the
- latest version of OCCI they support (e.g.
- <code class="computeroutput">1.0</code>) by way of the
- <code class="computeroutput">Server:</code> and
- <code class="computeroutput">User-Agent:</code> headers
respectively, using
- the token <span class="quote">“<span class="quote"><code
class="computeroutput">OCCI</code></span>”</span> (e.g.
- <span class="quote">“<span class="quote"><code
class="computeroutput">OCCI/1.0</code></span>”</span>). If none is
- provided the latest available version <span
class="emphasis"><em>shall</em></span> be
- used.</p></div></div><div class="section" title="Model"><div
class="titlepage"><div><div><h2 class="title"><a
id="id36070001"/>Model</h2></div></div></div><p>The model defines the
objects themselves without regard to how they
- interrelate.</p><div class="section" title="Kinds"><div
class="titlepage"><div><div><h3 class="title"><a
id="id36070011"/>Kinds</h3></div></div></div><p>Each category of resources
distinguished by some common
- characteristic or quality is called a <em
class="glossterm">kind</em> (e.g.
- <code class="computeroutput">compute</code>,
- <code class="computeroutput">network</code>,
- <code class="computeroutput">storage</code>,
- <code class="computeroutput">queue</code>,
- <code class="computeroutput">application</code>,
- <code class="computeroutput">contact</code>).</p><p>Kinds defined by
this standard live in the
- <code class="uri">http://purl.org/occi/kind/</code> namespace but
anyone can define a
- new kind by allocating a URI they control.</p><div class="warning"
title="Warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3
class="title">Warning</h3><p>Defining your own kinds can lead to
interoperability problems
- and should be a last resort reserved for unique functionality. A
- simple peer review process is available for extending the
registries
- which should be used where possible.</p></div><p>Each resource
<span class="emphasis"><em>must</em></span> specify a kind by way of a
- <em class="glossterm">category</em> within the <em
class="glossterm">scheme</em>
- <span class="quote">“<span class="quote"><code
class="uri">http://purl.org/occi/kind/</code></span>”</span>.</p><div
class="tip" title="Tip" style="margin-left: 0.5in; margin-right:
0.5in;"><h3 class="title">Tip</h3><p>The word <em
class="glossterm">type</em> is not used in this context
- in order to avoid confusion with Internet media
types.</p></div></div><div class="section" title="Attributes"><div
class="titlepage"><div><div><h3 class="title"><a
id="id36070094"/>Attributes</h3></div></div></div><p>An <em
class="glossterm">attribute</em> is a specification that
- defines a property of an object. It is expressed in the form of
- key-value pairs. Attributes are divided into namespaces which are
- separated by the dot character (<span class="quote">“<span
class="quote">.</span>”</span>).</p><div class="tip" title="Tip"
style="margin-left: 0.5in; margin-right: 0.5in;"><h3
class="title">Tip</h3><p>This scalable approach was derived from the
Mozilla Firefox
- <code class="uri">about:config</code> page.</p></div><p>Attributes
defined by this standard reside under the
- <code class="computeroutput">occi</code> namespace (e.g.
- "<code class="computeroutput">occi.abc</code>") but anyone can
define a new
- attribute by allocating a unique namespace based on their reversed
- Internet domain (e.g.
- <span class="quote">“<span class="quote"><code
class="computeroutput">com.cisco.cdp</code></span>”</span>).</p><div
class="warning" title="Warning" style="margin-left: 0.5in; margin-right:
0.5in;"><h3 class="title">Warning</h3><p>Defining your own attributes can
lead to interoperability
- problems and should be a last resort reserved for unique
- functionality. A simple peer review process is available for
extending
- the registries which should be used where possible.</p></div><div
class="section" title="Registry Entries"><div
class="titlepage"><div><div><h4 class="title"><a id="id36070148"/>Registry
Entries</h4></div></div></div><div class="table"><a id="id36070154"/><p
class="title"><b>Table 1. Core Attributes</b></p><div
class="table-contents"><table summary="Core Attributes"
border="1"><colgroup><col style="text-align:
center"/><col/><col/><col/></colgroup><thead><tr><th style="text-align:
left">Attribute</th><th>Description</th><th>Type</th><th>Example</th></tr></thead><tbody><tr><td
style="text-align: left"><code
class="computeroutput">occi.id</code></td><td>Immutable identifier for the
resource</td><td>URI</td><td><code
class="uri">urn:uuid:d0e9f0d0-f62d-4f28-bc90-23b0bd871770</code></td></tr><tr><td
style="text-align: left"><code
class="computeroutput">occi.title</code></td><td>Display name for the
resource</td><td>String</td><td><code class="computeroutput">Compute
Resource
- #123</code></td></tr><tr><td style="text-align:
left"><code class="computeroutput">occi.summary</code></td><td>Description
of the resource</td><td>String</td><td><code class="computeroutput">A
virtual compute
- resource</code></td></tr><tr><td style="text-align:
left"><code
class="computeroutput">occi.version</code></td><td>Specification
version</td><td>Float</td><td><code
class="computeroutput">1.0</code></td></tr></tbody></table></div></div><br
class="table-break"/></div></div><div class="section" title="Actions"><div
class="titlepage"><div><div><h3 class="title"><a
id="id36070289"/>Actions</h3></div></div></div><p>An <em
class="glossterm">action</em> is some process that can be
- carried out on one or more <em
class="glossterm">resource</em>s.</p><p>Each available <em
class="glossterm">action</em> for a given
+ request/response chain identified by the
Request-URI.</span>”</span><a class="xref" href="#core-rfc2616" title="RFC
2616 - Hypertext Transfer Protocol --
HTTP/1.1">RFC2616</a></p></dd></dl></div><div class="tip" title="Tip"
style="margin-left: 0.5in; margin-right: 0.5in;"><h3
class="title">Tip</h3><p>Implementors may offer full WebDAV support in
order to allow
+ clients to enumerate the entire tree, interact with the resources
via
+ standard file managers (e.g. Windows Explorer, Mac OS X Finder),
+ etc.</p></div></div><div class="section" title="Actions"><div
class="titlepage"><div><div><h3 class="title"><a
id="id36070426"/>Actions</h3></div></div></div><p>An <em
class="glossterm">action</em> is some process that can be
+ carried out on one or more <em class="glossterm">resource</em>s,
which may
+ result in a state change and/or the creation of new
resource(s).</p><div class="tip" title="Tip" style="margin-left: 0.5in;
margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Use common sense to
decide what functionality should be exposed
+ by way of actions and consult the list of existing actions and
verbs
+ before creating your own. For example it does not make sense to
resize
+ a storage resource by setting the <span class="quote">“<span
class="quote">size</span>”</span> attribute
+ (indeed there may not be space available or the filesystem may not
+ support resizing and in any case the operation will take some
time),
+ nor to start a machine by changing the state from
+ <span class="quote">“<span class="quote">stopped</span>”</span> to
<span class="quote">“<span
class="quote">running</span>”</span>.</p></div><p>Each available <em
class="glossterm">action</em> for a given
<em class="glossterm">resource</em> is indicated via a
- <em class="glossterm">link</em> with the
- <code class="computeroutput">action</code> class.</p><pre
class="screen">Link: </us-east/webapp/vm01;start>;
- rel="http://purl.org/occi/action/start";
+ <em class="glossterm">link</em> with <em
class="parameter"><code>class</code></em> extension
+ set to <span class="quote">“<span class="quote"><em
class="parameter"><code>action</code></em></span>”</span> (such that clients
+ can identify actions, including those from third-parties, without
+ deriving meaning from the <em
class="parameter"><code>rel</code></em> URI).</p><pre class="screen">Link:
</us-east/webapp/vm01;start>;
+ rel="http://purl.org/occi/action#start";
+ class="action";
title="Start"</pre><p>Actions defined by this standard reside under
the
- <code class="uri">http://purl.org/occi/action/</code> namespace but
anyone can define
+ <code class="uri">http://purl.org/occi/action#</code> namespace but
anyone can define
a new action by allocating a URI they control.</p><div
class="warning" title="Warning" style="margin-left: 0.5in; margin-right:
0.5in;"><h3 class="title">Warning</h3><p>Defining your own actions can lead
to interoperability problems
and should be a last resort reserved for unique functionality. A
simple peer review process is available for extending the
registries
@@ -592,12 +670,12 @@
depending on the action requested (e.g.
<code class="computeroutput">resize</code>), parameters
<span class="emphasis"><em>may</em></span> be provided using HTML
forms (e.g.
- <code class="computeroutput">application/x-www-form-encoded</code>).
In the
- case of HTML-based renderings the actions can therefore be actual
HTML
- forms.</p><div class="tip" title="Tip" style="margin-left: 0.5in;
margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Some resources can be
interacted with but not rendered due to
+ <code
class="computeroutput">application/x-www-form-urlencoded</code>). In
+ the case of HTML-based renderings the actions can therefore be actual
+ HTML forms.</p><div class="tip" title="Tip" style="margin-left:
0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Some resources
can be interacted with but not rendered due to
the nature of the resource or prevailing security policies (for
example, an operator may be able to backup a machine without
knowing
- anything about it).</p></div><div class="section"
title="Asynchronous Actions"><div class="titlepage"><div><div><h4
class="title"><a id="id36070373"/>Asynchronous
Actions</h4></div></div></div><p>Synchronous actions <span
class="emphasis"><em>may</em></span> return
+ anything about it).</p></div><div class="section"
title="Asynchronous Actions"><div class="titlepage"><div><div><h4
class="title"><a id="id36070541"/>Asynchronous
Actions</h4></div></div></div><p>Synchronous actions <span
class="emphasis"><em>may</em></span> return
<code class="computeroutput">200 OK</code> on successful
completion or
<code class="computeroutput">201 Created</code> with a
<code class="computeroutput">Location:</code> header indicating a
new
@@ -608,16 +686,55 @@
<code class="computeroutput">Location:</code> header indicating a
new
resource where status and other pertinent information can be
obtained.</p><div class="tip" title="Tip" style="margin-left:
0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Don't keep
clients waiting - if you're not sure to return
- immediately then give them a resource they can
monitor.</p></div></div><div class="section" title="Advanced Actions"><div
class="titlepage"><div><div><h4 class="title"><a id="id36070433"/>Advanced
Actions</h4></div></div></div><p>The specific parameters required and
allowable values for them
+ immediately then give them a resource they can monitor. For
example
+ by responding with an 202 Accepted return code and include a
+ location: header, as described.</p></div></div><div
class="section" title="Advanced Actions"><div
class="titlepage"><div><div><h4 class="title"><a id="id36070602"/>Advanced
Actions</h4></div></div></div><p>The specific parameters required and
allowable values for them
depend on the action and for advanced actions <span
class="emphasis"><em>may</em></span>
require sending of custom <em class="glossterm">content type</em>s
rather
than
- <code
class="computeroutput">application/x-www-form-encoded</code>.</p></div></div></div><div
class="section" title="Meta-model"><div class="titlepage"><div><div><h2
class="title"><a id="id36070458"/>Meta-model</h2></div></div></div><p>The
meta-model defines how objects interrelate.</p><div class="section"
title="Categories"><div class="titlepage"><div><div><h3 class="title"><a
id="id36070467"/>Categories</h3></div></div></div><p><em
class="glossterm">Category</em> information allows for flexible
+ <code
class="computeroutput">application/x-www-form-encoded</code>.</p></div><div
class="section" title="State Machines"><div class="titlepage"><div><div><h4
class="title"><a id="id36070625"/>State
Machines</h4></div></div></div><p>State machines are maintained on the
server side and possible
+ transitions are advertised to the client by way of action links.
The
+ links offered to a given client may depend on the resource, its
+ current state, security policy, etc.</p><div class="tip"
title="Tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3
class="title">Tip</h3><p>Many state transitions will not be effected
immediately so be
+ prepared to handle asynchronous
responses.</p></div></div></div></div><div class="section"
title="Model"><div class="titlepage"><div><div><h2 class="title"><a
id="id36070647"/>Model</h2></div></div></div><p>The model defines the
objects and how they interrelate. An interface
+ exposes "kinds" which have "attributes" and on which "actions" can be
+ performed. The attributes are exposed as key-value pairs and applicable
+ actions as links, following the REST hypertext constraint (whereby
state
+ transitions are defined <em class="glossterm">in-band</em> rather than
via
+ rules).</p><div class="section" title="Kinds"><div
class="titlepage"><div><div><h3 class="title"><a
id="id36070663"/>Kinds</h3></div></div></div><p>Each category of resources
distinguished by some common
+ characteristic or quality is called a <em
class="glossterm">kind</em> (e.g.
+ <code class="computeroutput">compute</code>,
+ <code class="computeroutput">network</code>,
+ <code class="computeroutput">storage</code>,
+ <code class="computeroutput">queue</code>,
+ <code class="computeroutput">application</code>,
+ <code class="computeroutput">contact</code>).</p><p>Kinds defined by
this standard live in the
+ <code class="uri">http://purl.org/occi/kind/</code> namespace but
anyone can define a
+ new kind by using a URI they control as the term.</p><div
class="warning" title="Warning" style="margin-left: 0.5in; margin-right:
0.5in;"><h3 class="title">Warning</h3><p>Defining your own kinds can lead
to interoperability problems
+ and should be a last resort reserved for unique functionality. A
+ simple peer review process is available for extending the
registries
+ which should be used where possible.</p></div><p>Each resource
<span class="emphasis"><em>must</em></span> specify a kind by way of a
+ <em class="glossterm">category</em> within the <em
class="glossterm">scheme</em>
+ <span class="quote">“<span class="quote"><code
class="uri">http://purl.org/occi/kind#</code></span>”</span>.</p><div
class="tip" title="Tip" style="margin-left: 0.5in; margin-right:
0.5in;"><h3 class="title">Tip</h3><p>The word <em
class="glossterm">type</em> is not used in this context
+ in order to avoid confusion with Internet media
types.</p></div><div class="section" title="Attributes"><div
class="titlepage"><div><div><h4 class="title"><a
id="id36070744"/>Attributes</h4></div></div></div><p>An <em
class="glossterm">attribute</em> is a specification that
+ defines a property of an object. It is expressed in the form of
+ key-value pairs. Attributes are divided into namespaces which are
+ separated by the dot character (<span class="quote">“<span
class="quote">.</span>”</span>).</p><div class="tip" title="Tip"
style="margin-left: 0.5in; margin-right: 0.5in;"><h3
class="title">Tip</h3><p>This scalable approach was derived from the
Mozilla Firefox
+ <code class="uri">about:config</code>
page.</p></div><p>Attributes defined by this standard reside at the root but
+ anyone can define a new attribute by allocating a unique namespace
+ based on their reversed Internet domain (e.g.
+ <span class="quote">“<span class="quote"><code
class="computeroutput">com.example.attribute</code></span>”</span>).</p><div
class="warning" title="Warning" style="margin-left: 0.5in; margin-right:
0.5in;"><h3 class="title">Warning</h3><p>Defining your own attributes can
lead to interoperability
+ problems and should be a last resort reserved for unique
+ functionality. A simple peer review process is available for
+ extending the registries which should be used where
possible.</p></div><div class="section" title="Registry Entries"><div
class="titlepage"><div><div><h5 class="title"><a id="id36070792"/>Registry
Entries</h5></div></div></div><div class="table"><a id="id36070798"/><p
class="title"><b>Table 1. Core Attributes</b></p><div
class="table-contents"><table summary="Core Attributes"
border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th
style="text-align:
left">Attribute</th><th>Description</th><th>Type</th><th>Example</th></tr></thead><tbody><tr><td
style="text-align: left"><code
class="computeroutput">id</code></td><td>Immutable, unique identifier for
the resource</td><td>URI</td><td><code
class="uri">urn:uuid:d0e9f0d0-f62d-4f28-bc90-23b0bd871770</code>
+ or <code
class="uri">urn:aws:ami-123456</code></td></tr><tr><td style="text-align:
left"><code class="computeroutput">title</code></td><td>Display name for
the resource</td><td>String</td><td><code class="computeroutput">Compute
Resource
+ #123</code></td></tr><tr><td style="text-align:
left"><code class="computeroutput">summary</code></td><td>Description of
the resource</td><td>String</td><td><code class="computeroutput">A virtual
compute
+ resource</code></td></tr></tbody></table></div></div><br
class="table-break"/></div></div></div><div class="section"
title="Categories"><div class="titlepage"><div><div><h3 class="title"><a
id="categories"/>Categories</h3></div></div></div><p><em
class="glossterm">Category</em> information allows for flexible
organisation of resources into one or more vocabularies (each of
which
- is referred to as a <em class="glossterm">scheme</em>).</p><p>The
meta-model was derived from Atom, consisting of three
+ is referred to as a <em class="glossterm">scheme</em>).</p><p>The
category model was derived from Atom and consists of three
attributes:</p><div class="glosslist"><dl><dt>term</dt><dd><p>The
term itself (e.g.
<span class="quote">“<span class="quote"><code
class="computeroutput">compute</code></span>”</span>)</p></dd><dt>scheme
(optional)</dt><dd><p>The vocabulary (e.g.
- <span class="quote">“<span class="quote"><code
class="computeroutput">http://purl.org/occi/kind/</code></span>”</span>)</p></dd><dt>label
(optional)</dt><dd><p>A human-friendly display name for the term (e.g.
+ <span class="quote">“<span class="quote"><code
class="computeroutput">http://purl.org/occi/kind#</code></span>”</span>)</p></dd><dt>label
(optional)</dt><dd><p>A human-friendly display name for the term (e.g.
<span class="quote">“<span class="quote"><code
class="computeroutput">Compute
Resource</code></span>”</span>)</p></dd></dl></div><p>Category
schemes and/or terms defined by this standard reside
throughout the <code class="uri">http://purl.org/occi/</code>
namespace but anyone can
@@ -629,37 +746,64 @@
<code class="computeroutput">US-West</code>,
<code class="computeroutput">Europe</code>), operating systems
(e.g.
<code class="computeroutput">Windows</code>,
- <code class="computeroutput">Linux</code>) and patch levels
(e.g.</p></div><div class="section" title="Examples"><div
class="titlepage"><div><div><h4 class="title"><a
id="id36070583"/>Examples</h4></div></div></div><pre
class="screen">Category: compute;
+ <code class="computeroutput">Linux</code>) and patch levels
(e.g.</p></div><div class="example"><a id="id36071201"/><p
class="title"><b>Example 2. Category examples</b></p><div
class="example-contents"><p>OCCI kinds are represented by a
category:</p><pre class="screen">Category: compute;
label="Compute Resource";
- scheme="http://purl.org/occi/kind/"</pre></div><div class="section"
title="Querying"><div class="titlepage"><div><div><h4 class="title"><a
id="id36070594"/>Querying</h4></div></div></div><p class="remark"><i><span
class="remark">TODO: Pull query interface from GData:
-
http://code.google.com/apis/gdata/docs/2.0/reference.html#Queries</span></i></p></div><div
class="section" title="Registry Entries"><div
class="titlepage"><div><div><h4 class="title"><a id="id36070605"/>Registry
Entries</h4></div></div></div><div class="table"><a id="id36070611"/><p
class="title"><b>Table 2. Core Category Schemes</b></p><div
class="table-contents"><table summary="Core Category Schemes"
border="1"><colgroup><col style="text-align:
center"/><col/></colgroup><thead><tr><th style="text-align:
left">Scheme</th><th>Description</th></tr></thead><tbody><tr><td
style="text-align: left"><code
class="computeroutput">http://purl.org/occi/kind/</code></td><td>OCCI
Kinds</td></tr></tbody></table></div></div><br
class="table-break"/></div></div><div class="section"
title="Collections"><div class="titlepage"><div><div><h3 class="title"><a
id="id36070664"/>Collections</h3></div></div></div><p>Where an operation
could return multiple resources (e.g.
+ scheme="http://purl.org/occi/kind#"</pre><p>Implementors and users
can also define their own vocabularies by
+ defining schemes:</p><pre class="screen">Category: cluster1;
+ label="Cluster #1";
+ scheme="http://example.com/clusters#"</pre></div></div><br
class="example-break"/><div class="section" title="Querying"><div
class="titlepage"><div><div><h4 class="title"><a
id="id36071224"/>Querying</h4></div></div></div><p>The category query
interface can be accessed by constructing an
+ URL with the desired categories added to the path. Categories can
be
+ negated by prefixing with <span class="quote">“<span
class="quote">-</span>”</span> and schemes may be
+ specified with braces.</p><div class="example"><a
id="id36071238"/><p class="title"><b>Example 3. Example category
query</b></p><div class="example-contents"><p>Locate the category search
root (which
+ <span class="emphasis"><em>should</em></span> be <code
class="uri">/-/</code>):</p><pre class="screen">> HEAD / HTTP/1.1
+>
+< HTTP/1.1 200 OK
+< Link: </-/>; rel="search"; title="Category
Search"</pre><p>Discover the available categories (which will all be
returned
+ in the same format as they appear in the HTTP headers):</p><pre
class="screen">> GET /-/ HTTP/1.1
+> Accept: */*
+>
+< HTTP/1.1 200 OK
+< Content-type: application/occi
+<
+< Category: compute; label="Compute Resource";
scheme="http://purl.org/occi/kind#"
+< Category: network; label="Network Resource";
scheme="http://purl.org/occi/kind#"
+< Category: storage; label="Storage Resource";
scheme="http://purl.org/occi/kind#"
+< Category: us-east; label="US East Coast";
scheme="http://example.com/locations"
+< Category: us-west; label="US West Coast";
scheme="http://example.com/locations"
+< Category: demo; label="My Customer Demo";
scheme="http://example.com/~user/"</pre><p>Query the category search
interface for the desired
+ category(s):</p><pre class="screen">> GET /-/compute/us-west
HTTP/1.1
+> Accept: text/uri-list
+>
+< HTTP/1.1 200 OK
+< Content-type: text/uri-list
+<
+< /vm01
+< /webapp/web01
+< /webapp/web02
+< /webapp/db01</pre></div></div><br class="example-break"/></div><div
class="section" title="Registry Entries"><div
class="titlepage"><div><div><h4 class="title"><a id="id36071283"/>Registry
Entries</h4></div></div></div><div class="table"><a id="id36071289"/><p
class="title"><b>Table 2. Core Category Schemes</b></p><div
class="table-contents"><table summary="Core Category Schemes"
border="1"><colgroup><col style="text-align:
center"/><col/><col/></colgroup><thead><tr><th style="text-align:
left">Scheme</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td
style="text-align: left"><code
class="computeroutput">http://purl.org/occi/kind#</code></td><td>OCCI
Kinds</td><td><code class="computeroutput">compute</code></td></tr><tr><td
style="text-align: left"><code
class="computeroutput">http://purl.org/occi/category#countries</code></td><td>ISO
Country Codes</td><td><code
class="computeroutput">us</code></td></tr><tr><td style="text-align:
left"><code
class="computeroutput">http://purl.org/occi/category#us-states</code></td><td>US
States</td><td><code class="computeroutput">ca</code></td></tr><tr><td
style="text-align: left"><code
class="computeroutput">http://purl.org/occi/category#operating-systems</code></td><td>Operating
Systems</td><td><code class="computeroutput">linux</code></td></tr><tr><td
style="text-align: left"><code
class="computeroutput">http://purl.org/occi/category#regulations</code></td><td>Regulation
compliance</td><td><code
class="computeroutput">sox</code></td></tr></tbody></table></div></div><br
class="table-break"/><p>Other categories schemes can be added to the
registry.</p></div></div><div class="section" title="Collections"><div
class="titlepage"><div><div><h3 class="title"><a
id="id36071429"/>Collections</h3></div></div></div><p>Where an operation
could return multiple resources (e.g.
categories, searches) this is referred to as a
<em class="glossterm">collection</em>. Collections are returned as a
list of
URLs in <code class="computeroutput">text/uri-list</code> format.<a
class="xref" href="#core-rfc2483" title="RFC 2483 - URI Resolution Services
Necessary for URN Resolution">RFC2483</a></p><div class="tip" title="Tip"
style="margin-left: 0.5in; margin-right: 0.5in;"><h3
class="title">Tip</h3><p>Collections are passed by reference for simplicity
rather than
performance reasons, requiring O(n+1) requests. Including metadata
- (requiring a wrapper format like Atom or SOAP) and/or the data
itself
- would provide O(1) performance, though passing by value should
only be
- considered where the representations are known to be small as such
- encodings add significant overhead.</p></div><div class="section"
title="Examples"><div class="titlepage"><div><div><h4 class="title"><a
id="id36070694"/>Examples</h4></div></div></div><pre class="screen"># OCCI
Example Collection
+ (via a wrapper format like Atom or SOAP) and/or the data itself
would
+ provide O(1) performance, though this "pass by value" approach
should
+ only be considered where the representations are known to be small
as
+ encoding adds significant overhead.</p></div><div
class="example"><a id="id36071460"/><p class="title"><b>Example 4. Example
collection</b></p><div class="example-contents"><pre class="screen"># OCCI
Example Collection
/examples/custom-extension
/examples/lamp-multi-vm
/examples/lamp
-/examples/myservice</pre></div><div class="section"
title="Advertising"><div class="titlepage"><div><div><h4 class="title"><a
id="id36070706"/>Advertising</h4></div></div></div><p>Any given URL can be
a collection and/or advertise
- <em class="glossterm">link</em>s to other
- <em class="glossterm">collection</em>s using the
- <code class="computeroutput">collection</code> class:</p><pre
class="screen">Link: <http://example.com/123/audit>;
- rel="http://purl.org/occi/collection/audit";
- title="Audit Entries"</pre><div class="tip" title="Tip"
style="margin-left: 0.5in; margin-right: 0.5in;"><h3
class="title">Tip</h3><p>The root (<span class="quote">“<span
class="quote">/</span>”</span>) <span
class="emphasis"><em>should</em></span> expose
- collections <em class="glossterm">in-band</em> and/or
- <em class="glossterm">out-of-band</em> in order for clients to
discover
- resources.</p></div></div><div class="section"
title="Paging"><div class="titlepage"><div><div><h4 class="title"><a
id="id36070753"/>Paging</h4></div></div></div><p>Collections <span
class="emphasis"><em>may</em></span> be divided into
+/examples/myservice</pre></div></div><br class="example-break"/><div
class="section" title="Paging"><div class="titlepage"><div><div><h4
class="title"><a
id="id36071472"/>Paging</h4></div></div></div><p>Collections <span
class="emphasis"><em>may</em></span> be divided into
<em class="glossterm">page</em>s, with each linking to the
<span class="quote">“<span class="quote">first</span>”</span>,
<span class="quote">“<span class="quote">last</span>”</span>, <span
class="quote">“<span class="quote">next</span>”</span> and
- <span class="quote">“<span class="quote">previous</span>”</span>
<em class="glossterm">link relation</em>s.</p><pre class="screen">Link:
<http://example.com/xyz;start=0>; rel="first"
-Link: <http://example.com/xyz;start=400>; rel="previous"
-Link: <http://example.com/xyz;start=500>; rel="self"
-Link: <http://example.com/xyz;start=600>; rel="next"
-Link: <http://example.com/xyz;start=900>;
rel="last"</pre></div></div><div class="section" title="Linking"><div
class="titlepage"><div><div><h3 class="title"><a
id="id36070795"/>Linking</h3></div></div></div><p>Web linking standards for
HTTP [<a class="xref" href="#core-link" title="Web Linking">LINK</a>] and
+ <span class="quote">“<span class="quote">previous</span>”</span>
<em class="glossterm">link relation</em>s. The
+ required <em class="parameter"><code>class</code></em> extension,
with the value of
+ <em class="parameter"><code>paging</code></em>, allows clients to
group links together
+ in the user interface and the server to specify e.g. "Next
10", "Next
+ 100", etc.</p><pre class="screen">Link:
<http://example.com/xyz;start=0>; rel="first"; title="First";
class="paging"
+Link: <http://example.com/xyz;start=400>; rel="previous";
title="Previous"; class="paging"
+Link: <http://example.com/xyz;start=500>; rel="self"; title="Self";
class="paging"
+Link: <http://example.com/xyz;start=600>; rel="next"; title="Next";
class="paging"
+Link: <http://example.com/xyz;start=900>; rel="last"; title="Last";
class="paging"</pre></div></div><div class="section" title="Linking"><div
class="titlepage"><div><div><h3 class="title"><a
id="id36071523"/>Linking</h3></div></div></div><p>Web linking standards for
HTTP [<a class="xref" href="#core-link" title="Web Linking">LINK</a>] and
HTML [<a class="xref" href="#core-html5" title="HTML 5">HTML5</a>]
are used to indicate associations
between resources. All formats <span
class="emphasis"><em>must</em></span> support
<em class="glossterm">in-band</em> linking including:</p><div
class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Link
relations (e.g.
@@ -672,12 +816,7 @@
type="application/pdf"</pre><p><em class="glossterm">Link
relation</em>s defined by this standard
reside under the <code class="uri">http://purl.org/occi/rel</code>
namespace but
anyone can define a new <em class="glossterm">link relation</em> by
- allocating a URI they control.</p><div class="section"
title="Registry Entries"><div class="titlepage"><div><div><h4
class="title"><a id="id36071020"/>Registry
Entries</h4></div></div></div><div class="table"><a id="id36071026"/><p
class="title"><b>Table 3. Core Link Relations</b></p><div
class="table-contents"><table summary="Core Link Relations"
border="1"><colgroup><col style="text-align:
center"/><col/></colgroup><thead><tr><th style="text-align:
left">Relation</th><th>Description</th></tr></thead><tbody><tr><td
style="text-align: left"><code class="computeroutput">collection</code>
- (<code
class="uri">http://purl.org/occi/rel#collection</code>)</td><td><p>A
related collection whereby:</p><div class="itemizedlist"><ul
class="itemizedlist"><li class="listitem"><p>The root of the collection is
indicated by the
- <code class="computeroutput">href</code>
attribute.</p></li><li class="listitem"><p>The <em
class="glossterm">kind</em> of the collection
- is indicated by the
- <code class="computeroutput">kind</code> extended
- attribute.</p></li></ul></div></td></tr><tr><td
style="text-align: left"><code
class="computeroutput">first</code></td><td><span class="quote">“<span
class="quote">An IRI that refers to the furthest preceding
+ allocating a URI they control.</p><div class="section"
title="Registry Entries"><div class="titlepage"><div><div><h4
class="title"><a id="id36071613"/>Registry
Entries</h4></div></div></div><div class="table"><a id="id36071619"/><p
class="title"><b>Table 3. Core Link Relations</b></p><div
class="table-contents"><table summary="Core Link Relations"
border="1"><colgroup><col/><col/></colgroup><thead><tr><th
style="text-align:
left">Relation</th><th>Description</th></tr></thead><tbody><tr><td
style="text-align: left"><code
class="computeroutput">first</code></td><td><span class="quote">“<span
class="quote">An IRI that refers to the furthest preceding
resource in a series of resources.</span>”</span> [<a
class="xref" href="#core-link" title="Web
Linking">LINK</a>]</td></tr><tr><td style="text-align: left"><code
class="computeroutput">help</code></td><td><span class="quote">“<span
class="quote">The referenced document provides further help
information for the page as a whole.</span>”</span> [<a
class="xref" href="#core-html5" title="HTML 5">HTML5</a>]</td></tr><tr><td
style="text-align: left"><code
class="computeroutput">icon</code></td><td><span class="quote">“<span
class="quote">The specified resource is an icon representing
the page or site, and should be used by the user agent when
@@ -687,20 +826,20 @@
***The diff for this file has been truncated for email.***
=======================================
--- /docs/occi-book.pdf Wed Oct 28 18:16:54 2009
+++ /docs/occi-book.pdf Sun Feb 21 07:32:22 2010
Binary file, no diff available.
=======================================
--- /docs/occi-book.xml Wed Oct 28 18:16:54 2009
+++ /docs/occi-book.xml Sun Feb 21 07:32:22 2010
@@ -17,7 +17,7 @@
<contrib>Author</contrib>
<affiliation>
- <orgname>Australian Online Solutions</orgname>
+ <orgname>Google</orgname>
</affiliation>
</author>
==============================================================================
Revision: 235906a914
Author: Sam Johnston <samj at samj.net>
Date: Sun Feb 21 07:33:00 2010
Log: merged
http://code.google.com/p/occi/source/detail?r=235906a914
More information about the occi-wg
mailing list