- occi-wg - lists.ogf.org

All please read
by Alexis Richardson 28 May '09

28 May '09

Sam, Thank-you very much for posting this. I agree that Tim's PDF is insightful, and relevant to our situation. ALL - please read Tim's deck linked to at the bottom of Sam's post. alexis On Wed, May 27, 2009 at 8:49 PM, Sam Johnston <samj(a)samj.net> wrote: > Tim's presentation is insightful. > > Highlights (actually it's all good so this is most of the presentation): > > Use plain text if... you possibly can. > JSON issues: Watch out for extensibility. > Use JSON if... The expected lifetime of the data is short. > Use XML if... your data is document flavoured or you're worried about i18n, > extensibility or reusability. > Inventing New XML Languages: > > Time-consuming. > Bureaucratic. > Difficult. > Unpleasant. > Includes complex software development as a sub-task. > Usually fails. > ... so try not to! > > Some Good XML Languages > > XHTML > DocBook > ODF > Atom > XMPP > UBL > RDF > > Design Issue: Model vs. Syntax > > “What matters is getting the data model right. The syntax is ephemeral.” vs > “The bits on the wire are the only reality.” > > Design Issue: Minimalism vs. Completeness > > “Let’s solve the whole problem.” > “Minimum progress required to declare victory.” > > XML Schema Definitions (XSD): > > Hard to understand, hard to implement, hard to interoperate. > One of the reasons why the SOA/WS-* project is sinking. > > XML Extensibility: Three Options > > No changes. > Must-Understand policy (e.g. as in SOAP). > Must-Ignore policy (e.g. as in Atom). > > Morals of the story (IMO): > > Bend over backwards to use plain text (if we can) > JSON is more interesting for RPC than ROA (Resource Oriented Architecture) > Avoid inventing new [XML] languages at all costs > 6 of the 7 "good" XML languages have already come up in the context of OCCI > (NFI what UBL is) > Model and bits-on-the-wire are both important to us > RELAX NG and XPath is a GoodThing™ > For XML extensibility ignore that which you don't understand (ala Atom) > Solve as much of the problem as we need to now but provide for extensibility > later > > Sam > > ---------- Forwarded message ---------- > From: Tim Bray <tbray(a)textuality.com> > Date: 2009/5/27 > Subject: Re: Structured data over TCP? > To: Patrik Fältström <patrik(a)frobbit.se> > Cc: apps-discuss(a)ietf.org > > > 2009/5/26 Patrik Fältström <patrik(a)frobbit.se>: > >> Do Apps Area have any general feeling about this? > > I was going to start typing in a lengthy answer but then I remembered > I gave a tutorial at IETF70 on the choice of data formats for use in > Internet Protocols. It's centered around XML but I think covers many > of the other issues that have come up in this. Available for your > reading pleasure at http://www.tbray.org/tmp/IETF70.pdf > > -Tim > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss(a)ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > occi-wg mailing list > occi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/occi-wg > >

1 0

Fwd: Structured data over TCP?
by Sam Johnston 27 May '09

27 May '09

We're not the only ones discussing XML vs JSON it seems... DJB's netstrings are another interesting (secure/parser friendly) approach and I reckon at least one implementation will appear which talks OCCI to nodes over protocol buffers <http://code.google.com/apis/protocolbuffers/docs/overview.html>before long. With the current proposal it doesn't matter - it's just key-value pairs and there's only so many ways you can render them which can trivially be described in the spec (e.g. "space separated text") Sam ---------- Forwarded message ---------- From: "Martin J. Dürst" <duerst(a)it.aoyama.ac.jp> Date: 2009/5/27 Subject: Re: Structured data over TCP? To: Patrik Fältström <patrik(a)frobbit.se> Cc: apps-discuss(a)ietf.org Hello Patrik, Some points, not necessarily in any particular order: - I haven't been able to figure out what the trailing ',' in netstrings is for. Any idea? - Netstrings don't say what encoding the data is in; that needs to be settled separately. XML can handle many character encodings if necessary, with sensible defaults, and there is no chance character encoding issues get forgotten. Json seems to be UTF-8 only in practice, which in most cases is about the best you can do these days. - Json's data types are closer to the data types available in many (especially dynamic) programming languages when compared with XML. XML has the advantage that it can represent both data as well as (textual) documents. The later would have to be done with a hopeless hack in Json. - Json can be directly interpreted in JavaScript. Some lazy developer may do it. But it would be an extremely bad idea, because it creates great security holes. - Both Json and XML are widely used on the Web, in what's called Ajax. But there are usually no length prefixes in either case. - There is RFC 3470 for the use of XML in the IETF. Please have a look if you haven't already done so. I'm not sure there is something similar for Json. - You say "Now, we need some more protocols here", but to me, it looks more like you want to exchange some more data. Some people might disagree, but I think there is absolutely no need to invent a new protocol every time some data has to be transferred. - Whether you call it "more protocols" or just "more data formats", if I were at either side of the data exchange, I wouldn't so much care about whether XML is easier to implement or Json or what, but I'd really hate to have a ton of different protocols/formats, each with a different technology. So unless the community involved thinks that this EPP Data Unit Format is hopelessly broken, I'd use the same scheme for all the other protocols/formats. Regards, Martin. On 2009/05/27 14:46, Patrik Fältström wrote: > It was many years ago popular to use line breaks as delimiters in data, > and on each line have essentially attribute/value pairs. > > Then we got XML that today seems to be what people want to use (because > there are libraries, and tons of programmers that can (not?) implement > XML parsers). We also have "content-length prefixed" XML data, that make > things sort of simpler. > > Sort of in parallell, we have xmlrpc, that to some degree solve slightly > different problems. > > Personally, I have lately looked at JSON, and after serializing data and > then use Netstrings (http://cr.yp.to/proto/netstrings.txt) I must say I > really like it. > > For those that do not know Netstrings, here is an example from the spec: > > For example, the string "hello world!" is encoded as <31 32 3a 68 65 >> 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The empty >> string is encoded as "0:,". >> > > Implementing is very simple, and you know how many bytes to read. An > example JSON-netstring thing can look like (for a 3-object array with a > hash as the third object, where the hash as one entry): > > 29:[1, "info", {"msg": "Hello"}], > > In the DNS provisioning world we have come up with epp (RFC 3730) that > has a binding to TCP (RFC 3734). The binding is a prefixed-based XML > blob that is passed over the wire: > > EPP Data Unit Format (one tick mark represents one bit position): >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Total Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | EPP XML Instance | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > > Now, we need some more protocols here (between DNS operator and the > registrar), and the question is whether the same mechanism is > recommended, or whether one should use something else? > > > Do Apps Area have any general feeling about this? > > Patrik > > > ------------------------------------------------------------------------ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss(a)ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Apps-Discuss mailing list Apps-Discuss(a)ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss

1 0

Is HTTP the HTTP of cloud computing?
by Sam Johnston 27 May '09

27 May '09

And finally the conclusion: Is HTTP the HTTP of cloud computing?<http://samj.net/2009/05/is-http-http-of-cloud-computing.html>Ok so after asking Is OCCI the HTTP of cloud computing?<http://samj.net/2009/05/is-occi-http-of-cloud-computing.html>I realised that the position may have already been filled and that the question was more Is AtomPub already the HTTP of cloud computing?<http://samj.net/2009/05/is-atompub-already-http-of-cloud.html> After all my strategy for OCCI was to follow Google's example with GData by adding some necessary functionality (a search interface, caching directives, resource-specific attributes, etc.). Most of the heavy lifting was actually being done by AtomPub, thus avoiding a huge amount of tedious and error-prone protocol writing (around 20,000 words of it) - something which OGF and the OCCI working group isn't really geared up for anyway. This is clearly a workable and well-proven approach as it as been adopted strategically by both Microsoft and Google and also tactically by Salesforce and IBM, among others. Best of all adding things like queries<http://code.google.com/apis/gdata/docs/2.0/reference.html#Queries>and versioning<http://code.google.com/apis/gdata/docs/2.0/reference.html#ResourceVersioning>is a manageable workload while starting from scratch is most certainly not. But what if there were an easier way? Recall that the problem we are trying to solve is exposing a flexible interface to an arbitrarily large collection of interconnected compute, storage and network resources. We need to be able to describe and manipulate the resources (CRUD), associate them with each other via rich links (e.g. links with attributes like local identifiers - eth0, sda, etc.) and change their state (start, stop, restart, etc.), among other things. Representational State Transfer (REST) Actually we're not talking about exposing the resources themselves (that would be impossible) but various *representations* of those resources - like Plato's shadows on the cave walls<http://en.wikipedia.org/wiki/Allegory_of_the_cave>- this is the "REpresentational" in "REpresentational State Transfer (REST)". There's an infinite number of possible representations so it's impossible to try to capture them all now, but here's some examples: - An Open Virtualisation Format (OVF) serialisation of a compute resource - A platform-specific descriptor file (e.g. VMX) - A complete archive of the virtual machine with its dependencies (OVA) - A graphical image of the console at a given point in time ('snapshot') - A video stream of the console for archiving/audit purposes (ala Citrix's Project Iris<http://www.brianmadden.com/blogs/brianmadden/archive/2005/06/08/project-iri…> ) - The console itself (e.g. SSH, ICA, RDP, VNC) - Build documentation (e.g. PDF, ODF) - Esoteric enterprise requirements (e.g. NMS configuration) It doesn't take a rocket scientist to spot the correlation between this and HTTP's existing content negotiation functionality (whereby a client can ask for a specific representation of a given resource - e.g. HTML vs PDF) so this is already pretty much solved for us (see HTTP's Accept: header<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html>for the details). For bonus points this information should be exposed in the URI as it's not always possible or convenient to set headers ala: - http://example.com/.atom (using filename extensions) - http://example.com/;content-type=text/html (using the full Internet media type) Web Linking But what about the links? As I explained yesterday<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html>the web is built on links embedded in HTML documents using the A tag. Atom also provides enhanced linking functionality via the LINK element, where it is also possible to specify content types, languages, etc. In this case however we want to allow resources to be arbitrary types and more often than not we won't have the ability to link within the payload itself. This leaves us with two options: put the links in the payload anyway by relying on a meta-model like Atom (or one we roll ourselves) or find some way to represent them within HTTP itself. Enter HTTP headers which are also extensible and, as it turns out, in the process of being extended (or at least refined) to handle this very requirement by fellow down under, Mark Nottingham <http://www.mnot.net/>. See the "Web Linking" IETF Internet-Draft (draft-nottingham-http-link-header<https://datatracker.ietf.org/drafts/draft-nottingham-http-link-header/>, at the time of writing version 05<http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-05.txt>) for the nitty gritty details and the ietf-http-wg list<http://lists.w3.org/Archives/Public/ietf-http-wg/>for some <http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0211.html> current<http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0196.html> discussions<http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0103.html>. Basically it clarifies the existing Link: headers<http://tools.ietf.org/html/rfc2068#section-19.6.2.4>and the result looks something like this: Link: <http://example.com/TheBook/chapter2>; rel="previous"; title="previous chapter" The Link: header itself is also extensible so we can faithfully represent our model by adding e.g. the local device name when linking storage and network resources to compute resources and other requisite attributes. It would be helpful if the content-type were also specified (Atom allows for multiple links of the same relation provided the content-type differs for example) but language is already covered by HTTP (it doesn't seem useful to advertise French links to someone who already asked to speak English). It's also interesting to note that earlier versions of the HTTP RFCs actually [poorly] specified both the Link: headers<http://tools.ietf.org/html/rfc2068#section-19.6.2.4>as well as LINK <http://tools.ietf.org/html/rfc2068#section-19.6.1.2> and UNLINK<http://tools.ietf.org/html/rfc2068#section-19.6.1.3>methods for maintaining links between web resources. John Pritchard had a crack at clarification in the Efficient HyperLink Maintenance for HTTP<http://ftp.ics.uci.edu/pub/ietf/http/draft-pritchard-http-links-00.txt>I-D but like most I-Ds this one seems to have died after 6 months, and with it the methods themselves. It seems to me that adding HTTP methods at this time is a drastic (and almost certainly infeasible) action, especially for something that could just as easily be accomplished via headers ala Set-Cookie: (too bad the I-D doesn't specify how to add/delete/modify links!). In the simplest sense a Link: header appearing in a PUT or POST could replace the existing one(s) but something more elegant for acting on individual links would be nice - probably a discussion worth having on the ietf-http-wg list <http://lists.w3.org/Archives/Public/ietf-http-wg/>. Organisation of Information Looking back to Atom for a second we're still missing some key functionality: - Atom id -> HTTP URL - Atom updated -> HTTP Last-Modified: Header - Atom title and summary -> Atom/HTTP Slug: Header<http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2>or equivalent - Atom link -> HTTP Link: Header - Atom category -> ??? Houston, we have a problem. OCCI use cases range from embedded hypervisors exposing a single resource to a single entry-point for an entire enterprise or the "Great Global Grid" - we need a way to organise, categories and search for the information, likely including: - Free text search via a Google-style "?q=firewall" syntax - Taxonomy <http://en.wikipedia.org/wiki/Taxonomy> via categories (already done <http://www.ibm.com/developerworks/xml/library/x-tipatom4.html> for Atom) for things like "Operating System" and "Data Center" - Folksonomy <http://en.wikipedia.org/wiki/Folksonomy> via [user] tags (already done <http://edward.oconnor.cx/2007/02/representing-tags-in-atom> for Atom and bearing in mind that tag spaces<http://microformats.org/wiki/rel-tag#Tag_Spaces>are cool) for things like "testlab" Fortunately the good work already done in this area for Atom would be realatively easy to port to a Category: HTTP header, following the Link:header example above. In the mean time a standard search interface (including category support) is trivial and thanks to Google, already done<http://code.google.com/apis/gdata/docs/2.0/reference.html#Queries> . Structured Data Formats HTML also resolves another pressing issue - what format to use for submitting key-value pairs (which constitutes a large part of what we need to do with OCCI). It gives us two options: - application/x-www-form-encoded<http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1>which is simple but quickly gets messy with encoding and non-ASCII characters - multipart/form-data<http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2>which is less efficient but will handle pretty much whatever you throw at it (including large files) The advantages of being able to create a resource from a web form simply by POSTing to the collection of resources (e.g. http://example.com/compute) and with HTML 5 by PUTting the resource in place directly (e.g. http://example.com/compute/<uuid>) are immediately obvious. Not only does this help make the human and programmable web one and the same (which in turn makes it much easier for developers/users to kick the tyres and understand the API) but it means that scripting even advanced tasks with curl/wget would be trivial. Plus there's no place for time-wasting religious arguments about angle brackets (XML) over curly braces (JSON). RESTful State Machines Something else which has not sat well with me until I spent the weekend ingesting RESTful Web Services <http://oreilly.com/catalog/9780596529260/>book (by Leonard Richardson <http://www.crummy.com/> and Sam Ruby<http://intertwingly.net/blog/>) was the "actuator" concept we picked up from the Sun Cloud APIs. This breaks away from RESTful principles by exposing an RPC-style API for triggering state changes (e.g. start, stop, restart). Granted it's an improvement on the alternative (GETting a resource and PUTting it back with an updated state) as Tim Bray explains in RESTful Casuistry<http://www.tbray.org/ongoing/When/200x/2009/03/20/Rest-Casuistry>(to which Roy Fielding <http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post> and Bill de hÓra <http://www.dehora.net/journal/2009/02/03/just-use-post/>also responded), but it still "feels funky". Sure it doesn't make any sense to try to "force" a monitored status<http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post#comment-966>to some other value (for example setting a "state" attribute to "running"), especially when we can't be sure that's the state we'll get to (maybe there will be an error or the transition will be dependent on some outcome over which we have no control). Similarly it doesn't make much sense to treat states as nouns, for example adding a "running" state to a collection of states (even if a resource can be "running" and "backing up" concurrently). But is using URLs as "buttons" representing verbs/transitions the best answer? What makes more sense [to me] is to request a transition and check back for updates (e.g. by polling or HTTP server push<http://en.wikipedia.org/wiki/Push_technology>). If it's RESTful to POST comments to an article (which in addition to its own contents acts as a collection of zero or more comments) then POSTing a request to change state to a [sub]resource also makes sense. As a bonus these can be parametrised (for example a "resize" request can be accompanied with a "size" parameter and a "stop" request sent with clarification as to whether an "ACPI Off" or "Pull Cord" is required). Transitions that take a while, like "format" on a storage resource, can simply return HTTP 201 Accepted so we've got support for asynchronous actions as well - indeed some requests (e.g. "backup") may not even be started immediately. We may also want to consider using something like Post Once Exactly (POE)<http://www.mnot.net/drafts/draft-nottingham-http-poe-00.txt>to ensure that requests like "restart" aren't executed repeatedly and that we can cancel requests that the system hasn't had a chance to deal with yet. Exactly how this should look in terms of URL layout I'm not sure (perhaps http://example.com/<resource>/requests) but being able to enumerate the possible actions as well as acceptable parameters (e.g. an enum for variations on "stop" or a range for "resize") would be particularly useful for clients. Collections This is all well and good for individual resources, but collections are still a serious problem. There are many use cases which involve retrieving an arbitrarily large number of resources and making a HTTP request for each (as well as requests for enumeration etc.) doesn't make sense. More importantly, it doesn't scale - particularly in enterprise environments where requests via proxies and filters can suffer from high latency (if not low bandwidth). One potential solution is to strap multiple HTTP message entities together as a multipart document, but that's hardly clean and results in some hairy coding on the client side (e.g. manual manipulation of HTTP messages that would otherwise be fully automated). The best solution we currently have for this problem (as evidenced by widespread deployment) is AtomPub so I'm still fairly sure it's going to have to make an appearance somewhere, even if it doesn't wrap all of the resources by default.

5 4

Atompub: Can we see an example of top level storage and network rendering ?
by Gary Mazz 27 May '09

27 May '09

Hi, Can we see a concrete example of top level storage and network rendering with one layer of decomposition ? I'd like to know what it will look like, especially with links applied. cheers -gary

7 21

Deadline for consensus
by Sam Johnston 27 May '09

27 May '09

All, As you know our already extended deadline for the formats discussion passed on Friday. Thijs is now in the unfortunate position of having to explain why we will miss our first self-assigned deliverable deadline (an implementable draft) on Thursday and I know well how it feels to have to stand in front of an audience with nothing to say, having done so twice last week (it's only with a big "personal vision only" disclaimer that I was able to say anything at the Cloud Computing Expos). Iff we can come to consensus about the format today (or at the very latest tomorrow) then we need not watch another deadline sail by and in doing so risk being declared a failure prematurely. Indeed if we can't achieve even a loose consensus after all the discussion then I may well be the first to say so - my time (and travel!) budget for OCCI has already been well exceeded and the irrelevant RF vs RAND discussion has tested what's left of my patience. Please focus on the task at hand and if you have any specific issues about the latest proposal then raise them sooner rather than later - I've put considerable effort into optimising Atom out for the most common use case (individual resources) over the weekend and by shifting metadata to HTTP headers the resulting descriptor format is far simpler than even I would have thought possible - see APIDesign<http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/APIDesign>for examples. On the subject of rolling our own protocol from scratch, I for one am dismissing the suggestion for reasons previously explained. I don't think this group has (nor needs) what it takes to implement an Internet protocol from the ground up and any attempt to do so would be fraught with danger, not to mention completely unnecessary given the corpus of work done by others at the IETF (who *are* geared up for such tasks). Thanks, Sam

4 5

Announcing new co-chair
by Thijs Metsch 26 May '09

26 May '09

Hi Guys, I would like to introduce our new Co-Chair Andy Edmonds. He will take over the co-chair position from Ignacio Llorente. Ignacio founded this group with me and it has been a great pleasure to work with him. I would like to thank him for his help and great work. He will keep on contributing to the efforts of the group. The reason for this change in the chairing is that Ignacio got the great opportunity to work with the European Union on Cloud Computing! So again thanks for your help and all the best, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

4 4

OCCI Model UML, XSD, XML, Code...
by Edmonds, AndrewX 26 May '09

26 May '09

I've been spent some time on the proposed meta-model [1] and model [1] UML that is up on the wiki along with the inputs of others. Following some discussions with Roger and Andre, I decided to take the model in its UML form and create the corresponding XSD. In fact Roger might have the a RDF version of the XSD sometime. This XSD can be found here [2]. Now I don't class myself as a XSD expert so any comments, updates etc are appreciated. From this XSD I was able to generate an API to create and manipulate an in-memory representation of a model instance. This example code can be found here [3]. It's Java and uses XMLBeans[4], but there are many other libraries out there that will allow the generation of an API in languages such as Python[5], Ruby[6], CSharp[7] (typically any language that has SOAP libraries will have an XSD class generator). After rendering the in-memory model the XML rendering is specific but adheres to the OCCI model schema and can be viewed here[8]. Again how things appear in the XML can be tweaked via iteration of the schema. For those JSON peeps out there there's an already XSLT transform sheets out there that will convert this XML to JSON using different conventions [9][10]. This model is abstract in a sense it does not import any dependencies, such as Atom. @Sam perhaps you could take what I've done and either by way of model inheritance or composition show how Atom would integrate with this model? My view on Atom is that it is useful as a wrapper to renderings of OCCI model instances. If I wanted to publish an OCCI model via Atom then I'd insert a model instance rendering into an atom:entry element (note we could include JSON via CDATA but this is where JSON perhaps gets a little ugly). This would be OCCI using Atom by way of composition and would allow both Atom and OCCI live harmoniously together or separately and not require Atom dependencies should that be the choice of a provider. What's important is that the OCCI model be it via Atom or something else could be understood by a receiving system. Using Atom with OCCI by way of inheritance makes the previous "with or without" approach a little more difficult as there's a hard-dependency on Atom. Atom reminds me somewhat of WS-Agreement, SOAP etc. It doesn't solve your domain-specific model problems (i.e. what you are trying to represent - OCCI==Infrastructure), only provide a means to send this content about and mechanisms supporting this but perhaps not directly to the model contained as content. We still have to understand and represent our noun/verb/attribute triplets. Atom doesn't really help out bar the features it offers by way of sitting on top of HTTP. Now of course you can extend Atom base types (in fact AFAIK they're just xs:complexTypes W3C XSD types) but the point is you have to extend them to _something_. That something is your domain specific model. There is value however in Atom, not from the model point of view - it's a very simple model. The value in Atom is in the directions the specifications gives pertaining to Atom service behaviour. Another way to view Atom is the interoperability glue in between the now almost commonly accepted cloud stack of Infrastructure -> Platform -> Service. This is where OCCI could learn quite an amount but when you consider that the basis of these behaviours are steeply entrenched in REST design principles it's easy to see 1) why Atom is attractive 2) that you don't necessarily need Atom to have correct and/or standard service behaviour - just adopt good, sound REST design principles! On more specifics and related to the attributes of each noun, we are still rather under-specified especially in the Storage and Network nouns. @Richard and @Gary (in separate threads) started a useful discussion on attributes for these nouns. Perhaps you two guys could add your findings and suggestions to the wiki? Andy PS: for those of you wanting to run the code I've exported the eclipse project and can be found here [11]. [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/NounsVerbsAn… [2] http://forge.ogf.org/sf/wiki/do/viewAttachment/projects.occi-wg/wiki/NounsV… [3] http://forge.ogf.org/sf/wiki/do/viewAttachment/projects.occi-wg/wiki/NounsV… [4] http://xmlbeans.apache.org [5] http://www.rexx.com/~dkuhlman/generateDS.html [6] http://dev.ctor.org/soap4r/browser/trunk/bin/xsd2ruby.rb [7] http://xsd2code.codeplex.com/Wiki/View.aspx [8] http://forge.ogf.org/sf/wiki/do/viewAttachment/projects.occi-wg/wiki/NounsV… [9] http://code.google.com/p/xml2json-xslt/ [10] http://www.bramstein.com/projects/xsltjson/ [11] http://forge.ogf.org/sf/wiki/do/viewAttachment/projects.occi-wg/wiki/NounsV… Andy Edmonds skype: andy.edmonds tweets: @dizz tel: +353 (0)1 6069232 IT Research - IT Innovation Centre - Intel Ireland Ltd. Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

3 8

Presentations for our first session at the OGF.
by Thijs Metsch 26 May '09

26 May '09

Hi folks, For our first session there are still some open time slots for presentations. I would love to see some presentations regarding OCCI or presentations which are in the broader field of OCCI. Optimal would be if you got a presentation which describes why OCCI is cool and why you and your team are working on it. On the last concalls I asked some of you if you could send me the presentations. You do not have to be at OGF in person, since I think we'll have a dial-in option in the room. So you can present via the concall while I switch the slides. For those of you, who stated they wanted to present something and want to present something, please send me the slides till Tuesday (next week). All the best, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

2 2

Unlocking the formats deadlock
by Sam Johnston 26 May '09

26 May '09

Afternoon all, As you know I spent last week evangelising OCCI at the Cloud Computing Expo in Prague (Monday/Tuesday) and Cloud Computing Expo in London (Wednesday/Thursday), presenting the Introduction to the Open Cloud Computing Interface<http://docs.google.com/Present?docid=ddqm27m2_298fsf9mqdg>presentation at both. I was only scheduled for Prague but the organisers found a spot on the technical track in London too. I also ended up on the panels at both which was even more opportunities to talk about cloud interop. I'll be in Portugal for Cloud Views from Wednesday and will try to get involved in OGF 26 time permitting as well. By now people certainly know we exist and that we're doing real (hopefully good) work. Unfortunately we're somewhat stuck on the formats decision despite hours of face to face discussion with 1/2 a dozen of the more active working group members (myself, Alexis, Chris & Richard from ElasticHosts and the Fujitsu guys). While this is not at all unusual for technical discussions we do need to fairly urgently find a solution before people (myself included) lose interest and wander off. I can't overstate how important this working group is to the future of cloud computing and both of the alternatives are rather unpalatable: - On one side we have Amazon EC2 APIs which are not only encumbered but inelegant and inflexible (at least in the context of the enterprise use cases I spend most of my time thinking about - no offense intended). Other APIs designed to expose the functionality of a single implementation fall into the same category and while they meet their specific needs well, we need to expose the current and future functionality of all current and future implementations, not just one today. At the extreme end of the simplicity scale you have text-based APIs which we all now agree won't meet our needs. - At the other end of the scale we have VMware's vCloud API which has been injected into the DMTF process, following in the footsteps of OVF. I fully expect the resulting "open API" to be almost word-for-word identical to the new VMware APIs which is something the DIGISTAN<http://www.digistan.org/>guys call "vendor capture <http://www.digistan.org/open-standard:definition>". Unlike the public cloud APIs, this will be well-suited for enterprise and you can be sure that service providers will deploy VMware en masse to provide it as part of their [semi-]private "I can't believe it's not cloud" offerings. Good on them for being first and forcing the rest of the industry to follow their lead. This working group's job is to find the middle ground - something which is simple enough to be useful for public cloud offerings but extensible enough to be useful for more challenging tasks (e.g. enterprise). This is also critical for hybrid clouds (unless you're all happy to implement DMTF's APIs in addition to your own). The business case is easily justified even if only on the basis of getting access to customers who are currently kicking the tyres with tactical deployments but unable to deploy strategically. As you know I have been pushing Atom[Pub] hard, perhaps too hard, and the XML-xenophobes have dug their heels in as a result. It was made painfully obvious in London that blanket application of AtomPub to the problem isn't going to fly with at least one of them and to that end I've spent the weekend working on paring it back where it's not absolutely necessary. I've also purchased and read O'Reilly's RESTful Web Services<http://oreilly.com/catalog/9780596529260/>book by Leonard Richardson <http://www.crummy.com/> and Sam Ruby from cover to cover and am largely sold on their concept of a Resource Oriented Architecture (ROA)<http://www.infoq.com/resource/articles/richardson-ruby-restful-ws/en/resour…>- do read this sample chapter if you have time. Fortunately I think I've found a simple, elegant solution which obviates the need for Atom (at least where collections are not required). I've captured it in a series of 3 blog posts which I'll forward to the list for the sake of convenience and the archives. Cheers, Sam

5 13

Open Cloud Computing Interface Prague Presentation
by samj＠samj.net 25 May '09

25 May '09

I've shared a document with you called "Open Cloud Computing Interface Prague Presentation": http://docs.google.com/Presentation?id=ddqm27m2_298fsf9mqdg&invite=28381391 It's not an attachment -- it's stored online at Google Docs. To open this document, just click the link above. --- Morning all, Apparently there was some trouble accessing the presentation I ran through at the Cloud Computing Expos in Prague and London last week. I believe this was because as I had to work offline I downloaded a PPT, worked on it and uploaded it again as a new presentation: http://docs.google.com/Presentation?id=ddqm27m2_298fsf9mqdg It seems I shared but did not "publish" it - now I have so you should all be able to see it. Cheers, Sam

3 2