[occi-wg] [occi] 2 new revisions pushed by s... at samj.net on 2010-02-21 15:33 GMT
Sam Johnston
samj at samj.net
Sun Feb 21 09:46:51 CST 2010
Apologies for spamming the list with a one-word
change<http://code.google.com/p/occi/source/diff?spec=svn1df85e1a498cd9cd626ed6685013038104aa5c9a&r=1df85e1a498cd9cd626ed6685013038104aa5c9a&format=side&path=/docs/occi-book.xml>-
didn't realise we'd started posting commits. I've turned off the "
*Include diffs of changed files in the email notification*" as when you
modify the DocBook XML the build system will regenerate one or more HTML and
PDF files... it's best if you just follow the links to the revisions and
inspect the changes to the XML files using the Google Code web interface.
Cheers,
Sam
On Sun, Feb 21, 2010 at 4:34 PM, <occi at googlecode.com> wrote:
> 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
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20100221/0ab64411/attachment.html
More information about the occi-wg
mailing list