Comments on: Toolkits to wrap and bridge Cloud management protocols http://stage.vambenepe.com/archives/951 William Vambenepe's stage Tue, 07 Feb 2012 23:33:47 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: William Vambenepe’s blog » Blog Archive » Thoughts on the “Simple Cloud API” http://stage.vambenepe.com/archives/951#comment-628 William Vambenepe’s blog » Blog Archive » Thoughts on the “Simple Cloud API” Tue, 22 Sep 2009 19:04:54 +0000 http://stage.vambenepe.com/?p=951#comment-628 [...] YACA (yet another Cloud API), as there are interesting differences between this and all the other Cloud toolkits out [...] [...] YACA (yet another Cloud API), as there are interesting differences between this and all the other Cloud toolkits out [...]

]]> By: William Louth http://stage.vambenepe.com/archives/951#comment-627 William Louth Mon, 14 Sep 2009 12:28:46 +0000 http://stage.vambenepe.com/?p=951#comment-627 JDBC has been a very successful API for relational database access. JCR is also another good API for abstracting various back-end repositories. In fact whilst I worked with HP OpenView on future proofing next gen CMDB approaches (that never made it off the drawing before another acquisition was made and another sets architect involved) I recommended this API for extraction of state from both information model and editing of the management model (transition) state. It looks like JBoss crew had (heard more like) similar ideas. http://jboss.org/dna/ I am not sure I like replacing 1 proprietary API with another especially when the replacement is trying to be generic to multiple storage back-ends. Do people honestly change their database management systems that frequently and that easier today. NO. I prefer good export and import tooling for now to cater for such uncommon practices (unless of course you choose vendors unwisely). William JDBC has been a very successful API for relational database access.

JCR is also another good API for abstracting various back-end repositories. In fact whilst I worked with HP OpenView on future proofing next gen CMDB approaches (that never made it off the drawing before another acquisition was made and another sets architect involved) I recommended this API for extraction of state from both information model and editing of the management model (transition) state. It looks like JBoss crew had (heard more like) similar ideas. http://jboss.org/dna/

I am not sure I like replacing 1 proprietary API with another especially when the replacement is trying to be generic to multiple storage back-ends. Do people honestly change their database management systems that frequently and that easier today. NO. I prefer good export and import tooling for now to cater for such uncommon practices (unless of course you choose vendors unwisely).

William

]]>