HP has submitted a specification to the DMTF Cloud incubator

When I lamented, in a previous post, that I couldn’t tell you about recent submissions to the DMTF Cloud incubator, one of those I had in mind was a submission from HP. I can now write this, because the author of the specification, Nigel Cook, has recently blogged about it. Unfortunately he is isn’t publishing the specification itself, just an announcement that it was submitted. Hopefully he is currently going through the long approval process to make the submitted document public (been there, done that, I know it takes time).

In the blog, Nigel makes a good argument for the need to go beyond a hypervisor-centric view of Cloud computing. Even at the IaaS layer there are cases of automated-but-not-virtualized deployment that have all the characteristics of Cloud computing and need to be supported by Cloud management APIs. Not to mention OS-level isolation like Solaris Containers.

Nigel also offers a spirited defense of SOAP-based protocols. I don’t necessarily agree with all his points (“one could easily map the web service definition I described to REST if that was important” suggests a “it’s just SOAP without the wrapper” view of REST), but I am glad he is launching this debate. We need to discuss this rather than assume that REST is the obvious answer. Remember, a few years ago SOAP was just as obvious an answer to any protocol question. It may well be that indeed REST comes out ahead of this discussion, but the process will force us to be explicit about what benefits of REST we are trying to achieve and will allow us to be practical in the way we approach it.

4 Comments

Filed under Automation, Cloud Computing, DMTF, Everything, HP, IT Systems Mgmt, Mgmt integration, Specs, Standards, Utility computing, Virtualization

4 Responses to HP has submitted a specification to the DMTF Cloud incubator

  1. Nigel Cook

    Thanks for the comments William. You post really fast!

    I didn’t mean to imply REST is “SOAP without the header”. What I was trying to get at was that you could specify the exposed semantics in a REST stack similar to the dual stack that Amazon offers.

  2. I don’t consider the AWS stack that RESTy.
    * S3 is, though it opted to ignore WebDAV move/copy verbs and instead invent their own header hacks
    * uses their own auth mechanism which relies the client clock to be in sync (and to have its TZ variable correct). Still, at least it is more secure than the reliacloud API for that reason, whose designs haven’t heard of replay attacks. Either way: non-standard auth complicates your clients, stops you using your web browser and forms to submit operations, whereas HTTPS-authed requests do
    * main API is HTTP POST through and through, no real resty conceptual model

  3. Thanks Steve. I was planning to respond to Nigel along the same line, that I understand his point about being able to have 2 APIs side by side but that taking the Amazon example was unfortunate as it’s only RESTful if you use a pretty degenerate definition of the term.

    I am sure one could come up w/ a RESTful version of the HP API. The issue though is that it’s not just a glue/mapping exercise. It would have some intrincly different access patterns from the SOAP one and thus more work to maintain both.

    In general, for most applications I could be convinced to go w/ REST or SOAP. What I really dislike it’s the “we’ll do both” approach. If a standard does this, it puts interop backward. If an implementer does this, it sets up a portion of its customers to be the loosers when the vendor sees which one gets more adoption and cuts the other.

  4. +1. You can do a good RESTy conceptual model with things at the end of meaningful URIs (VMs? the rest of the model?), or hack something together with POST. Just because the latter isn’t SOAP, doesn’t mean it is good.

    One nice thing about SOAP: SOAPFaults; structured and extensible errors. As long as you don’t try and turn them back into a Java exception hierarchy, all will be well. Too bad SOAP doesn’t handle the whole HTTP error code suite like 302 as the same time.