[occi-wg] Is OCCI the HTTP of Cloud Computing?

[Sam Johnston]

Here's another insightful reply from William Vambenepe:

Speaking of WS-*, I don't think it's a selfish plug for me to point you
> towards the post in which I examine how previous efforts (mainly around
> WS-*) can inform Cloud standards going forward. It is very relevant to what
> you write here. When I read this paragraph:
>
> "Enter the OGF's Open Cloud Computing Interface (OCCI) whose (initial) goal
> it is to provide an extensible interface to Cloud Infrastructure Services
> (IaaS). To do so it needs to allow clients to enumerate and manipulate an
> arbitrary number of server side "resources" (from one to many millions) all
> via a single entry point. These compute, network and storage resources need
> to be able to be created, retrieved, updated and deleted (CRUD) and links
> need to be able to be formed between them (e.g. virtual machines linking to
> storage devices and network interfaces). It is also necessary to manage
> state (start, stop, restart) and retrieve performance and billing
> information, among other things."
>
> ... I am a bit worried because you describe the whole field of IT modeling
> and interoperability as we've tried to capture it for the last decade. So
> when I see that you plan to "deliver an implementable draft this month" I
> get a little worried.
>
> Anyway, here is the "lessons to learn" post, titled "A post-mortem on the
> previous IT management revolution":
> http://stage.vambenepe.com/archives/700Among other things, beware on
> focusing on protocols rather than models, beware of working without clear
> use cases and beware of trying to address broad problems rather than
> constrained problems. BTW, I am not saying that you are doing these things
> and I haven't looked at the working documents on the OCCI site. These are
> just thoughts that come to mind from reading this blog entry.
>

And his blog post:

A post-mortem on the previous IT management
revolution<http://stage.vambenepe.com/archives/700> by
> William Vambenepe
>
> Before rushing to standardize “Cloud APIs”, let’s take a look back at the
> previous attempt to tackle the same problem, which is one of IT management
> integration and automation. I am referring to the definition of
> specifications that attempted to use the then-emerging SOAP-based Web
> services framework to easily integrate IT management systems and their
> targets.
>
> Leaving aside the “Cloud” spin of today and the “Web services” frenzy of
> yesterday, the underlying problem remains to provide IT services (mostly
> applications) in a way that offers the best balance of performance,
> availability, security and economy. Concretely, it is about being able to
> deploy whatever IT infrastructure and application bits need to be deployed,
> configure them and take any required ongoing action (patch, update, scale
> up/down, optimize…) to keep them humming so customers don’t notice anything
> bothersome and you don’t break any regulation. Or rather so that any
> disruption a customer sees and any mandate you violate cost you less than it
> would have cost to avoid them.
>
> The realization that IT systems are moving more and more towards
> distributed/connected applications was the primary reason that pushed us
> towards the definition of Web services protocols geared towards management
> interactions. By providing a uniform and network-friendly interface, we
> hoped to make it convenient to integrate management tasks vertically
> (between layers of the IT stack) and horizontally (across distributed
> applications). The latter is why we focused so much on managing new entities
> such as Web services, their execution environments and their conversations.
> I’ll refer you to the WSMF submission<http://xml.coverpages.org/ni2003-07-21-a.html>that my HP colleagues and I made to OASIS in 2003 for the first consistent
> definition of such a management framework. The overview white paper<http://xml.coverpages.org/WSMF-Overview.pdf>even has a use case called “management as a service” if you’re still not
> convinced of the alignment with today’s Cloud-talk.
>
> Of course there are some differences between Web service management
> protocols and Cloud APIs. Virtualization capabilities are more advanced than
> when the WS effort started. The prospect of using hosted resources is more
> realistic (though still unproven as a mainstream business practice). Open
> source component are expected to play a larger role. But none of these
> considerations fundamentally changes the task at hand.
>
> Let’s start with a quick round-up and update on the most relevant efforts
> and their status.
>
> *Protocols*
>
> WSMF <http://xml.coverpages.org/ni2003-07-21-a.html> (Web Services
> Management Framework): an HP-created set of specifications, submitted to the
> OASIS WSDM working group (see below). Was subsumed into WSDM. Not only a
> protocol BTW, it includes a basic model for Web services-related artifacts.
>
> WS-Manageability<http://www.ibm.com/developerworks/library/specification/ws-manage/>:
> An IBM-led alternative to parts of WSDM, also submitted to OASIS WSDM.
>
> WSDM <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm>(Web Services Distributed Management): An OASIS technical committee.
> Produced two standards (a protocol, “Management Using Web Services” and a
> model of Web services, “Management Of Web Services”). Makes use of WSRF (see
> below). Saw a few implementations but never achieved real adoption.
>
> OGSI <http://www.ggf.org/documents/GFD.15.pdf> (Open Grid Services
> Infrastructure): A GGF (the organization now known as OGF) standard to
> provide a service-oriented resource manipulation infrastructure for Grid
> computing. Replaced with WSRF.
>
> WSRF <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf>: An
> OASIS technical committee which produced several standards (the main one is
> WS-ResourceProperties). Started as an attempt to align the GGF/OGSI approach
> to resource access with the IT management approach (represented by WSDM).
> Saw some adoption and is currently quietly in use under the cover in the
> GGF/OGF space. Basically replaced OGSI but didn’t make it in the IT
> management world because its vehicle there, WSDM, didn’t.
>
> WS-Management <http://www.dmtf.org/standards/wsman>: A DMTF standard,
> based on a Microsoft-led submission. Similar to WSDM in many ways. Won the
> adoption battle with it. Based on WS-Transfer and WS-Enumeration.
>
> WS-ResourceTransfer<http://schemas.xmlsoap.org/ws/2006/08/resourceTransfer/WS-ResourceTransfer.pdf>(aka WS-RT): An attempt to
> reconcile <http://xml.coverpages.org/WSM-HarmonizationRoadmap200603.pdf>the underlying foundations of WSDM and WS-Management. Stalled as a private
> effort (IBM, Microsoft, HP, Intel). Was later submitted to the W3C WS-RA
> working group (see below).
>
> WSRA <http://www.w3.org/2002/ws/ra/> (Web Services Resource Access): A W3C
> working group created to standardize the specifications that WS-Management
> is built on (WS-Transfer etc) and to add features to them in the form of
> WS-RT (which was also submitted there, in order to be finalized). This is
> (presumably) the last attempt at standardizing a SOAP-based access framework
> for distributed resources. Whether the window of opportunity to do so is
> still open is unclear. Work is ongoing.
>
> WS-ResourceCatalog<http://schemas.xmlsoap.org/ws/2007/05/ResourceCatalog/WS-ResourceCatalog.pdf>: A discovery helper companion specification to WS-Management. Started as a
> Microsoft document, went through the “WSDM/WS-Management reconciliation”
> effort, emerged as a new specification that was submitted to DMTF<http://stage.vambenepe.com/archives/110>in May 2007. Not heard of since.
>
> CMDBf<http://www.dmtf.org/standards/published_documents/DSP0252_1.0.0c.pdf>(Configuration Management Database Federation): A DMTF working group (and
> soon to be standard) that mainly defines a SOAP-based protocol to query
> repositories of configuration information. Not linked with (or dependent on)
> any of the specifications listed above (it is debatable whether it belongs
> in this list or is part of a new breed).
>
> *Modeling*
>
> DCML <http://www.dcml.org/> (Data Center Markup Language): The first
> comprehensive effort to model key elements of a data center, their
> relationships and their policies. Led by EDS and Opsware. Never managed to
> attract the major management vendors. Transitioned to an OASIS member
> section and died of being ignored.
>
> SDM <http://msdn.microsoft.com/en-us/library/ms181772%28VS.80%29.aspx>(System Definition Model): A Microsoft specification to model an IT system
> in a way that includes constraints and validation, with the goal of
> improving automation and better linking the different phases of the
> application lifecycle. Was the starting point for SML.
>
> SML <http://www.w3.org/XML/SML/> (Service Modeling Language): Currently a
> W3C “proposed recommendation” (soon to be a recommendation, I assume) with
> the same goals as SDM. It was created, starting from SDM, by a consortium of
> companies that eventually submitted it<http://www.w3.org/Submission/2007/01/>to W3C. No known adoption other than the Eclipse
> COSMOS <http://www.eclipse.org/cosmos/resource_modeling/index.php> project
> (Microsoft was supposed to use it, but there hasn’t been any news on that
> front for a while). Technically, it is a combination of XSD and Schematron.
> It appears dead, unless it turns out that Microsoft is indeed using it (I
> don’t know whether System Center is still using SDM, whether they are
> adopting SML, whether they are moving towards M or whether they have given
> up on the model-centric vision).
>
> CML (Common Model Library): An effort by the SML authors to create a set of
> model elements using the SML metamodel. Appears to be dead (no news in a
> long time and the cml-project.org domain name that was used seems
> abandoned).
>
> SDD <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sdd>(Solution Deployment Descriptor): An OASIS standard to define a packaging
> mechanism meant to simplify the deployment and configuration of software
> units. It is to an application archive what OVF is to a virtual disk. Little
> adoption that I know of, but maybe I have a blind spot on this.
>
> OVF <http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf>(Open Virtualization Format): A recently
> released <http://xml.coverpages.org/DMTF-OVFv10-Standard.html> DMTF
> standard. Defines a packaging and descriptor format to distribute virtual
> machines. It does not defined a common virtual machine format, but a wrapper
> around it. Seems to have some momentum. Like CMDBf, it may be best thought
> of as part of a new breed than directly associated with WS-Management and
> friends.
>
> This is not an exhaustive list. I have left aside the eventing aspects
> (WS-Notification, WS-Eventing, WS-EventNotification) because while relevant
> it is larger discussion and this entry to too long already (see here<http://blog.elementallinks.net/2008/09/epts-event-pr-3.html>and
> here<http://travisspencer.com/blog/2008/11/effort-to-converge-ws-eventing.html>for some updates from late last year on the eventing front). It also does
> not cover the Grid work (other than OGSI/WSRF to the extent that they
> intersect with the IT management world), even though a lot of the work that
> took place there is just as relevant to Cloud computing as the IT management
> work listed above. Especially CDDLM/CDL<http://www.ggf.org/documents/GFD.127.pdf>an abandoned effort to port
> SmartFrog <http://smartfrog.org/> to the then-hot XML standards, from
> which there are plenty of relevant lessons to extract.
>
> *The lessons*
>
> What does this inventory tell us that’s relevant to future Cloud API
> standardization work? The first lesson is that protocols are easy and models
> are hard. WS-Management and WSDM technically get the job done. CMDBf will be
> a good query language. But none of the model-related efforts listed above
> seem to have hit the mark of “doing the job”. With the possible exception of
> OVF which is promising (though the current expectations on it<http://news.cnet.com/8301-1001_3-10216049-92.html?part=rss&subj=news&tag=2547-1_3-0-20>are often beyond
> what it really delivers<http://devcentral.f5.com/weblogs/macvittie/archive/2009/04/21/ovf-a-few-layers-short-of-a-full-stack.aspx>).
> In general, the more focused and narrow a modeling effort is, the more
> successful it seems to be (with OVF as the most focused of the list and CML
> as the other extreme). That’s lesson learned number two: models that
> encompass a wide range of systems are attractive, but impossible to deliver.
> Models that focus on a small sub-area are the way to go. The question is
> whether these specialized models can at least share a common metamodel or
> other base building blocks (a type system, a serialization, a relationship
> model, a constraint mechanism, etc), which would make life easier for
> orchestrators. SML tries (tried?) to be all that, with no luck. RDF could be
> all that, but hasn’t managed to get noticed in this context. The OVF and SDD
> examples seems to point out that the best we’ll get is XML as a shared
> foundation (a type system and a serialization). At this point, I am ready to
> throw the towel on achieving more modeling uniformity than XML provides, and
> ready to do the needed transformations in code instead. At least until the
> next window of opportunity arrives.
>
> I wish that rather than being 80% protocols and 20% models, the effort in
> the WS-based wave of IT management standards had been the other way around.
> So we’d have a bit more to show for our work, for example a clear, complete
> and useful way to capture the operational configuration of application
> delivery services (VPN, cache, SSL, compression, DoS protection…). Even if
> the actual specification turns out to not make it, its content should be
> able to inform its successor (in the same way that even if you don’t use CIM
> to model your server it is interesting to see what attributes CIM has for a
> server).
>
> It’s less true with protocols. Either you use them (and they’re very
> valuable) or you don’t (and they’re largely irrelevant). They don’t capture
> domain knowledge that’s intrinsically valuable. What value does WSDM
> provide, for example, now that’s it’s collecting dust? How much will the
> experience inform its successor (other than trying to avoid the
> WS-Addressing disaster)? The trend today seems to be that a more direct use
> of HTTP (”REST”) will replace these protocols. Sure. Fine. But anyone who
> expects this break from the past to be a vaccination against past problems
> is in for a nasty surprise. Because, and I am repeating myself, *it’s the
> model, stupid*. Not the protocol. Something I (hopefully) explained in my
> comments on the Sun Cloud API <http://stage.vambenepe.com/archives/632>(before I knew that caring about this API might actually become part of my
> day job) and something on which I’ll come back in a future post.
>
> Another lesson is the need for clear use cases. Yes, it feels silly to
> utter such an obvious statement. But trust me, standards groups still
> haven’t gotten this. It’s not until years spent on WSDM and then
> WS-Management that I realized that most people were not going after
> management integration, as I was, but rather manageability. Where
> “manageability” is concerned with discovering and monitoring individual
> resources, while “management integration” is concerned with providing a
> systematic view of the environment, with automation as the goal. In other
> words, manageability standards can allow you to get a traditional IT
> management console without the need for agents. Management integration
> standards can allow you to coordinate your management systems and automate
> their orchestration. WS-Management is for manageability. CMDBf is in the
> management integration category. Many of the (very respectful and civilized)
> head-butting sessions I engaged in during the WSDM effort can be traced back
> to the difference between these two sets of use cases. And there is plenty
> of room for such disconnect in the so-loosely-defined “Cloud” world.
>
> We have also learned (or re-learned) that arbitrary non-backward compatible
> versioning, e.g. for political or procedural reasons as with WS-Addressing,
> is a crime. XML namespaces (of the XSD and WSDL types, as well as URIs used
> in similar ways in specifications, e.g. to identify a dialect or profile)
> are tricky, because they don’t have backward compatibility metadata and
> because of the practice to use organizations domain names in the URI (as
> opposed to specification-specific names that can be easily transferred, e.g.
> cmdbf.org versus dmtf.org/cmdbf). In the WS-based management world, we
> inherited these problems at the protocol level from the generic WS stack.
> Our hands are more or less clean, but only because we didn’t have enough
> success/longevity to generate our own versioning problems, at the model
> level. But those would have been there had these models been able to see the
> light of day (CML) or see adoption (DCML).
>
> There are also practical lessons that can be learned about the tactics and
> strategies of the main players. Because it looks like they may not change
> very much, as corporations or even as individuals. Karla Norsworthy speaks
> for IBM on Cloud interoperability standards in this article<http://www.sdtimes.com/CLOUD_PROVIDERS_VOW_INTEROPERABILITY/About_CLOUDCOMPUTING/33410>.
> Andrew Layman represented Microsoft<http://www.eweek.com/c/a/Cloud-Computing/The-Open-Cloud-Manifesto-Debuts-707560/>in the post-Manifestogate Cloud patch-up meeting in New York. Winston Bumpus
> is driving the standards strategy at VMWare. These are all veterans of the
> WS-Management, WSDM and related wars collaborations (and more generally
> the whole WS-* effort for the first two). For the details of what there is
> to learn from the past in that area, you’ll have to corner me in a hotel bar
> and buy me a few drinks though. I am pretty sure you’d get your money’s
> worth (I am not a heavy drinker)…
>
> In summary, here are my recommendations for standardizing Cloud API, based
> on lessons from the Web services management effort. The theme is “focus on
> domain models”. The line items:
>
>    - Have clear goals for each effort. E.g. is your use case to deploy and
>    run an existing application in a Cloud-like automated environment, or is it
>    to create new applications that efficiently take advantage of the added
>    flexibility. Very different problems.
>    - If you want to use OVF, then beef it up to better apply to Cloud
>    situations, but keep it focused on VM packaging: don’t try to grow it into
>    the complete model for the entire data center (e.g. a new DCML).
>    - Complement OVF with similar specifications for other domains, like
>    the application delivery systems listed above. Informally try to keep these
>    different specifications consistent, but don’t over-engineer it by repeating
>    the SML attempt. It is more important to have each specification map well to
>    its domain of application than it is to have perfect consistency between
>    them. Discrepancies can be bridged in code, or in a later incarnation.
>    - As you segment by domain, as suggested in the previous two bullets,
>    don’t segment the models any further within each domain. Handle
>    configuration, installation and monitoring issues as a whole.
>    - Don’t sweat the protocols. HTTP, plain old SOAP (don’t call it POS)
>    or WS-* will meet your need. Pick one. You don’t have a scalability
>    challenge as much as you have a model challenge so don’t get distracted
>    here. If you use REST, do it in the mindset that Tim Bray describes<http://www.tbray.org/ongoing/When/200x/2009/03/16/Sun-Cloud>:
>    “*If you’re going to do bits-on-the-wire, Why not use HTTP?<http://timothyfitz.wordpress.com/2009/02/12/why-http/>And if you’re going to use HTTP, use it right. That’s all.
>    *” Not as something that needs to scale to Web scale or as a rebuff of
>    WS-*.
>    - Beware of versioning. Version for operational changes only, not
>    organizational reasons. Provide metadata to assert and encourage backward
>    compatibility.
>
> This is not a recipe for the ideal result but it is what I see as
> practically achievable. And fault-tolerant, in the sense that the failure of
> one piece would not negate the value of the others. As much as I have constrained
> expectations <http://stage.vambenepe.com/archives/684> for Cloud
> portability, I still want it to improve to the extent possible. If we can’t
> get a consistent RDF-based (or RDF-like in many ways) modeling framework,
> let’s at least apply ourselves to properly understanding and modeling the
> important areas.
>
> In addition to these general lessons, there remains the question of what
> specific specifications will/should transition to the Cloud universe.
> Clearly not all of them, since not all of them even made it in the “regular”
> IT management world for which they were designed. How many then? Not
> surprisingly (since IBM had a big role in most of them), Karla Norsworthy,
> in the interview<http://www.sdtimes.com/CLOUD_PROVIDERS_VOW_INTEROPERABILITY/About_CLOUDCOMPUTING/33410>mentioned above, asserts that
> *“infrastructure as a service, or virtualization as a paradigm for
> deployment, is a situation where a lot of existing interoperability work
> that the industry has done will surely work to allow integration of
> services”*. And just as unsurprisingly Amazon’s Adam Selipsky, who’s
> company has nothing to with the previous wave but finds itself in leadership
> position WRT to Cloud Computing is a lot more circumspect: *“whether
> existing standards can be transferred to this case [of cloud computing] or
> if it’s a new topic is [too] early to say”*. OVF is an obvious candidate.
> WS-Management is by far the most widely implemented of the bunch, so that
> gives it an edge too (it is apparently already in use for Cloud monitoring,
> according to this press release<http://findarticles.com/p/articles/mi_pwwi/is_200903/ai_n31400439/>by an “innovation leader in automated network and systems monitoring
> software” that I had never heard of). Then there is the question of what IBM
> has in mind for WS-RT (and other specifications that the WS-RA working group
> is toiling on). If it’s not used as part of a Cloud API then I really don’t
> know what it will be used for. But selling it as such is going to be an
> uphill battle. CMDBf is a candidate too, as a model-neutral way to manage
> the configuration of a distributed system. But here I am, violating two of
> my own recommendations (”focus on models” and “don’t isolate config from
> other modeling aspects”). I guess it will take another pass to really learn…
>
>
> On Tue, May 5, 2009 at 3:33 AM, Sam Johnston <samj at samj.net> wrote:

> Morning all,
>
> I'm going to break my own rules about reposting blog posts because this is
> very highly relevant, it's 03:30am already and I'm traveling again tomorrow.
> The next step for us is to work out what the protocol itself will look like
> on the wire, which is something I have been spending a good deal of time
> looking at over many months (both analysing existing efforts and thinking of
> "blue sky" possibilities).
>
> I am now 100% convinced that the best results are to be had with a variant
> of XML over HTTP (as is the case with Amazon, Google, Sun and VMware) and
> that while Google's GData is by far the most successful cloud API in terms
> of implementations, users, disparate services, etc. Amazon's APIs are (at
> least for the foreseeable future) a legal minefield. I'm also very
> interested in the direction Sun and VMware are going and have of course been
> paying very close attention to existing public clouds like ElasticHosts and
> GoGrid (with a view to being essentially backwards compatible and sysadmin
> friendly).
>
> I think the best strategy by a country mile is to standardise OCCI core
> protocol following Google's example (e.g. base it on Atom and/or AtomPub
> with additional specs for search, caching, etc.), build IaaS extensions in
> the spirit of Sun/VMware APIs and support alternative formats including
> HTML, JSON and TXT via XML Stylesheets (e.g. occi-to-html.xsl<http://code.google.com/p/occi/source/browse/trunk/xml/occi-to-html.xsl>,
> occi-to-json.xsl<http://code.google.com/p/occi/source/browse/trunk/xml/occi-to-json.xsl>and
> occi-to-text.xsl<http://code.google.com/p/occi/source/browse/trunk/xml/occi-to-text.xsl>).
> You can see the basics in action thanks to my Google App Engine reference
> implementation<http://code.google.com/p/occi/source/browse/#svn/trunk/occitest>at
> http://occitest.appspot.com/ (as well as HTML<http://www.w3.org/2005/08/online_xslt/xslt?xslfile=http%3A%2F%2Focci.googlecode.com%2Fsvn%2Ftrunk%2Fxml%2Focci-to-html.xsl&xmlfile=http%3A%2F%2Foccitest.appspot.com>,
> JSON<http://www.w3.org/2005/08/online_xslt/xslt?xslfile=http%3A%2F%2Focci.googlecode.com%2Fsvn%2Ftrunk%2Fxml%2Focci-to-json.xsl&xmlfile=http%3A%2F%2Foccitest.appspot.com>and
> TXT<http://www.w3.org/2005/08/online_xslt/xslt?xslfile=http%3A%2F%2Focci.googlecode.com%2Fsvn%2Ftrunk%2Fxml%2Focci-to-text.xsl&xmlfile=http%3A%2F%2Foccitest.appspot.com>versions of same), KISS junkies bearing in mind that this weighs in under
> 200 lines of python code! Of particular interest is the ease at which
> arbitrarily complex [X]HTML interfaces can be built directly on top of OCCI
> (optionally rendered from raw XML in the browser itself) and the use of the
> hCard microformat <http://microformats.org/> as a simple demonstration of
> what is possible.
>
> Anyway, without further ado:
>
> Is OCCI the HTTP of Cloud Computing?
> http://samj.net/2009/05/is-occi-http-of-cloud-computing.html
>
> The Web is built on the Hypertext Transfer Protocol (HTTP)<http://en.wikipedia.org/wiki/HTTP>,
> a client-server protocol that simply allows client user agents to retrieve
> and manipulate resources stored on a server. It follows that a single
> protocol could prove similarly critical for Cloud Computing<http://en.wikipedia.org/wiki/Cloud_computing>,
> but what would that protocol look like?
>
> The first place to look for the answer is limitations in HTTP itself. For a
> start the protocol doesn't care about the payload it carries (beyond its Internet
> media type <http://en.wikipedia.org/wiki/Internet_media_type>, such as
> text/html), which doesn't bode well for realising the vision<http://www.w3.org/2001/sw/Activity.html>of the [
> Semantic <http://en.wikipedia.org/wiki/Semantic_Web>] Web<http://en.wikipedia.org/wiki/World_Wide_Web>as a "universal medium for the exchange of data". Surely it should be
> possible to add some structure to that data in the simplest way possible,
> without having to resort to carrying complex, opaque file formats (as is the
> case today)?
>
> Ideally any such scaffolding added would be as light as possible, providing
> key attributes common to all objects (such as updated time) as well as basic
> metadata such as contributors, categories, tags and links to alternative
> versions. The entire web is built on hyperlinks so it follows that the
> ability to link between resources would be key, and these links should be
> flexible such that we can describe relationships in some amount of detail.
> The protocol would also be capable of carrying opaque payloads (as HTTP does
> today) and for bonus points transparent ones that the server can seamlessly
> understand too.
>
> Like HTTP this protocol would not impose restrictions on the type of data
> it could carry but it would be seamlessly (and safely) extensible so as to
> support everything from contacts to contracts, biographies to books (or
> entire libraries!). Messages should be able to be serialised for storage
> and/or queuing as well as signed and/or encrypted to ensure security.
> Furthermore, despite significant performance improvements introduced in HTTP
> 1.1 it would need to be able to stream many (possibly millions) of objects
> as efficiently as possible in a single request too. Already we're asking a
> lot from something that must be extremely simple and easy to understand.
>
> XML
>
> It doesn't take a rocket scientist to work out that this "new" protocol is
> going to be XML based, building on top of HTTP in order to take advantage of
> the extensive existing infrastructure. Those of us who know even a little
> about XML will be ready to point out that the "X" in XML means "eXtensible"
> so we need to be specific as to the schema for this assertion to mean
> anything. This is where things get interesting. We could of course go down
> the WS-* route and try to write our own but surely someone else has crossed
> this bridge before - after all, organising and manipulating objects is one
> of the primary tasks for computers.
>
> Who better to turn to for inspiration than a company whose mission<http://www.google.com/corporate/>it is to "organize the world's information and make it universally
> accessible and useful", Google. They use a single protocol for almost all of
> their APIs, GData <http://code.google.com/apis/gdata/>, and while people
> don't bother to look under the hood (no doubt thanks to the myriad client
> libraries <http://code.google.com/apis/gdata/clientlibs.html> made
> available under the permissive Apache 2.0 license), when you do you may be
> surprised at what you find: everything from contacts to calendar items, and
> pictures to videos is a feed (with some extensions for things like
> searching<http://code.google.com/apis/gdata/docs/2.0/basics.html#Searching>and
> caching<http://code.google.com/apis/gdata/docs/2.0/reference.html#ResourceVersioning>
> ).
>
> OCCI
>
> Enter the OGF's Open Cloud Computing Interface (OCCI)<http://www.occi-wg.org/>whose (initial) goal it is to provide an extensible interface to Cloud
> Infrastructure Services (IaaS). To do so it needs to allow clients to
> enumerate and manipulate an arbitrary number of server side "resources"
> (from one to many millions) all via a single entry point. These compute,
> network and storage resources need to be able to be created, retrieved,
> updated and deleted (CRUD) and links need to be able to be formed between
> them (e.g. virtual machines linking to storage devices and network
> interfaces). It is also necessary to manage state (start, stop, restart) and
> retrieve performance and billing information, among other things.
>
> The OCCI working group basically has two options now in order to deliver an
> implementable draft this month as promised: follow Amazon or follow Google
> (the whole while keeping an eye on other players including Sun and VMware).
> Amazon use a simple but sprawling XML based API with a PHP style flat
> namespace and while there is growing momentum around it, it's not without
> its problems. Not only do I have my doubts about its scalability outside of
> a public cloud environment (calls like 'DescribeImages' would certainly
> choke with anything more than a modest number of objects and we're talking
> about potentially millions) but there are a raft of intellectual property
> issues as well:
>
>    - *Copyrights* (specifically section 3.3 of the Amazon Software License<http://aws.amazon.com/asl/>)
>    prevent the use of Amazon's "open source" clients with anything other than
>    Amazon's own services.
>    - *Patents* pending like #20070156842<http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220070156842%22.PGNR.&OS=DN/20070156842&RS=DN/20070156842>cover the Amazon Web Services APIs and we know that Amazon have been known
>    to use patents offensively<http://en.wikipedia.org/wiki/1-Click#Barnes_.26_Noble>against competitors.
>    - *Trademarks* like #3346899<http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=77054011>prevent us from even referring to the Amazon APIs by name.
>
> While I wish the guys at Eucalyptus <http://open.eucalyptus.com/> and
> Canonical <http://news.zdnet.com/2100-9595_22-292296.html> well and don't
> have a bad word to say about Amazon Web Services, this is something I would
> be bearing in mind while actively seeking alternatives, especially as Amazon
> haven't worked out<http://www.tbray.org/ongoing/When/200x/2009/01/20/Cloud-Interop>whether the interfaces are IP they should protect. Even if these issues were
> resolved via royalty free licensing it would be very hard as a single vendor
> to compete with truly open standards (RFC 4287: Atom Syndication Format<http://tools.ietf.org/html/rfc4287>and RFC
> 5023: Atom Publishing Protocol <http://tools.ietf.org/html/rfc5023>) which
> were developed at IETF by the community based on loose consensus and running
> code.
>
> So what does all this have to do with an API for Cloud Infrastructure
> Services (IaaS)? In order to facilitate future extension my initial designs
> for OCCI have been as modular as possible. In fact the core protocol is
> completely generic, describing how to connect to a single entry point,
> authenticate, search, create, retrieve, update and delete resources, etc.
> all using existing standards including HTTP, TLS, OAuth and Atom. On top of
> this are extensions for compute, network and storage resources as well as
> state control (start, stop, restart), billing, performance, etc. in much the
> same way as Google have extensions for different data types (e.g. contacts
> vs YouTube movies).
>
> Simply by standardising at this level OCCI may well become the HTTP of
> Cloud Computing.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090506/3f24b26c/attachment.html