This is (unsurprisingly) really raising the bar. FWIW I&#39;m not one of the people who&#39;s seen the API so it&#39;s interesting to see they too went for OVF over a REST based API... it seems that OVF is in fact at the heart of this protocol (or is it vice versa?). That may or may not be a good thing.<br>
<br>Object model looks like this (courtesy pp59):<br><ul><li>Organisation</li><ul><li>Virtual Data Center (VDC)</li><ul><li>vApp (multiple VMs, &quot;internal&quot; network, n-tier app in a box)</li></ul></ul></ul>Other observations:<br>
<ul><li>Flexible networking (like ours) - multiple tagged networks (&quot;foo&quot;, &quot;bar&quot;, &quot;VDCnet&quot;, &quot;Public&quot;, &quot;Private&quot;)</li><li>Persistent VMs (we want to allow for both)</li><li>
SLA on vApp (to be implemented as an extension)</li><li>Overprovisioning (interesting area, from user PoV means hiding size of storage pools, etc. which most providers will want to do anyway)</li><li>Both serialization and configuration via OVF</li>
<li>Talk about scaling to 10k hosts and 100k VMs</li><li>&quot;HTTP based resource oriented interface&quot; (just like OCCI!)</li><li>&quot;All the characteristics of the WWW <br>• Extensible without breaking client. (like OCCI)<br>
• Client only has to know about what it cares about. (like OCCI)<br>• Can route, proxy, cache &lt;- interesting, useful, can be difficult to achieve<br></li><li>Interestingly uses <a href="http://en.wikipedia.org/wiki/Spring_Framework">Spring Framework</a></li>
<ul><li>Injects dependencies and wires together Spring beans</li><li>Forces programmer into maintainable design pattern; isolates dependencies</li></ul><li>OSGI: Standard dynamic module framework (Global registry of interfaces to instances - Dynamically load, unload, start, stop bundle)... not sure how interesting this is really</li>
<li>JMS publish/subscribe messaging bus isolates end points (message buses will be a key component of most successful cloud architectures IMO - something to consider when we&#39;re talking about formatting)</li><li>Hibernate simplifies DB code &amp; DB independence</li>
</ul>The actual VMware architecture (pp76) I found less interesting because it varies from provider to provider and is the detail that the cloud conceals from end users.<br><br>Sam<br><br><div class="gmail_quote">On Sat, Apr 25, 2009 at 9:49 AM, Alexis Richardson <span dir="ltr">&lt;<a href="mailto:alexis.richardson@gmail.com">alexis.richardson@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Wes,<br>
<br>
Thanks for that.<br>
<br>
Some of us have seen vCloud APIs under NDA.  There is definitely<br>
overlap with OCCI.  VMware are aware of OCCI and I personally hope we<br>
see them contribute at some stage.<br>
<font color="#888888"><br>
alexis<br>
</font><div><div></div><div class="h5"><br>
<br>
On Fri, Apr 24, 2009 at 11:06 PM, Wes Felter &lt;<a href="mailto:wesley@felter.org">wesley@felter.org</a>&gt; wrote:<br>
&gt; VMware has revealed few technical details about vCloud, but I found this<br>
&gt; public presentation containing some interesting diagrams starting on<br>
&gt; pages 50 and 76. Overall, the concepts appear similar to the work going<br>
&gt; on in OCCI.<br>
&gt;<br>
&gt; <a href="http://forum.stanford.edu/events/2009Plenary/Orran%20Kriegar.pdf" target="_blank">http://forum.stanford.edu/events/2009Plenary/Orran%20Kriegar.pdf</a><br>
&gt;<br>
&gt; The bullets &quot;Researchers can replace any part of the service.&quot; and<br>
&gt; &quot;Researchers can replace the entire implementation<br>
&gt; and clone the API&quot; also caught my eye.<br>
&gt;<br>
&gt; Wes Felter - <a href="mailto:wesley@felter.org">wesley@felter.org</a><br>
&gt; _______________________________________________<br>
&gt; occi-wg mailing list<br>
&gt; <a href="mailto:occi-wg@ogf.org">occi-wg@ogf.org</a><br>
&gt; <a href="http://www.ogf.org/mailman/listinfo/occi-wg" target="_blank">http://www.ogf.org/mailman/listinfo/occi-wg</a><br>
&gt;<br>
_______________________________________________<br>
occi-wg mailing list<br>
<a href="mailto:occi-wg@ogf.org">occi-wg@ogf.org</a><br>
<a href="http://www.ogf.org/mailman/listinfo/occi-wg" target="_blank">http://www.ogf.org/mailman/listinfo/occi-wg</a><br>
</div></div></blockquote></div><br>