Comments on: Getting Giddy with the CMDB: REST, Cheap Spread, and Wet CIs http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/ One foot in the muck, the other in utopia Wed, 03 Dec 2008 21:11:39 +0000 http://wordpress.org/?v=2.6.3 By: People Over Process » An Open Source CMDB http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-103154 People Over Process » An Open Source CMDB Mon, 26 Nov 2007 23:38:54 +0000 http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-103154 [...] (Related, see my short note and the resulting reader comments on the CMDB Federation standard effort.) [...] [...] (Related, see my short note and the resulting reader comments on the CMDB Federation standard effort.) [...]

]]> By: People Over Process » BMC’s Developer Network and Open Source Announcement http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-50424 People Over Process » BMC’s Developer Network and Open Source Announcement Wed, 25 Jul 2007 20:42:31 +0000 http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-50424 [...] And I’ll throw a crazy one out there (crazy based on it’s revenue as I understand it): how about the CMDB? Could one come up with a plan where-in open sourcing it would actually be more profitable than keeping it closed source? It’d certainly be mud in the eye of the rest of the Big 4 and CMDB vendors. In BMC’s case, there’s the AR system, the runtime framework underpinning many of BMC’s highly successful products like Remedy and the CMDB. Less dramatic, I suspect the CMDB Federaton would benefit from an open source project or two. Here’s one idea. [...] [...] And I’ll throw a crazy one out there (crazy based on it’s revenue as I understand it): how about the CMDB? Could one come up with a plan where-in open sourcing it would actually be more profitable than keeping it closed source? It’d certainly be mud in the eye of the rest of the Big 4 and CMDB vendors. In BMC’s case, there’s the AR system, the runtime framework underpinning many of BMC’s highly successful products like Remedy and the CMDB. Less dramatic, I suspect the CMDB Federaton would benefit from an open source project or two. Here’s one idea. [...]

]]> By: cote http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-10621 cote Fri, 02 Mar 2007 00:27:54 +0000 http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-10621 Brendan: thanks for the commentary and pointers. I've been keen to see the open source CMDB(s?) pan out. Mr. Twiggs: indeed. Too bad there isn't more slack time to try out new things ;) Brendan: thanks for the commentary and pointers. I’ve been keen to see the open source CMDB(s?) pan out.

Mr. Twiggs: indeed. Too bad there isn’t more slack time to try out new things ;)

]]> By: Glenn (aka Mr Twiggs) http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-10154 Glenn (aka Mr Twiggs) Tue, 27 Feb 2007 22:04:29 +0000 http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-10154 Yes, I'm giddy! If my upper management were as giddy as me, then shit would start happening. Alas, I don't think it will, but I'll continue to talk it up. Yes, I’m giddy!

If my upper management were as giddy as me, then shit would start happening. Alas, I don’t think it will, but I’ll continue to talk it up.

]]> By: Brendan Martin http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-10007 Brendan Martin Tue, 27 Feb 2007 03:16:07 +0000 http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-10007 Cote, what do I say, its hard to mount an arguement to the contrary, but the vendor community will continue to build the hype and their proprietory interfaces just as long as the debate continues about standards and the maturity of ITIL. Its the utopian view of the world. Having an operations management background the information I require is a little different from the guys at the Ops Centre Flightdeck, and different again from the Change Managers. I need to know costs per device and service levels, etc. Take a quick look at <a href="http://www.cmdb.info" rel="nofollow">CMDB.info</a> for the details of an Open Source Framework for a CMDB. There are lots of functional tools in there, such as Nagios, Nmap, OCS Inventory, Oreon, etc. The only way there will be a set of standards emerge is to take the development of an industry standard within the Open Source Community. The REST and ATOM standards are an interesting debate, but under current capabilities I use Nmap, if something is on my network and its running an IP Stack, it can be found and further interogated in all sorts of ways. To progress on working towards standards, one requires a functional framework. Check out what is included in the stable build specs. BTY Great Blog. Cheers Cote, what do I say, its hard to mount an arguement to the contrary, but the vendor community will continue to build the hype and their proprietory interfaces just as long as the debate continues about standards and the maturity of ITIL. Its the utopian view of the world. Having an operations management background the information I require is a little different from the guys at the Ops Centre Flightdeck, and different again from the Change Managers. I need to know costs per device and service levels, etc. Take a quick look at CMDB.info for the details of an Open Source Framework for a CMDB. There are lots of functional tools in there, such as Nagios, Nmap, OCS Inventory, Oreon, etc. The only way there will be a set of standards emerge is to take the development of an industry standard within the Open Source Community. The REST and ATOM standards are an interesting debate, but under current capabilities I use Nmap, if something is on my network and its running an IP Stack, it can be found and further interogated in all sorts of ways. To progress on working towards standards, one requires a functional framework. Check out what is included in the stable build specs. BTY Great Blog. Cheers

]]> By: cote http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-9408 cote Fri, 23 Feb 2007 15:24:44 +0000 http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-9408 Dunno off the top of my head, Mark. But, obviously, it's something to start to paying attention to. Any findings yourself? I'm glad you've taken such interest in the topic here ;) Dunno off the top of my head, Mark. But, obviously, it’s something to start to paying attention to. Any findings yourself? I’m glad you’ve taken such interest in the topic here ;)

]]> By: Mark Wahl http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-9084 Mark Wahl Fri, 23 Feb 2007 00:18:24 +0000 http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-9084 Do you know if any of the open source CIMOM projects, e.g. http://www.openpegasus.org/manual/CIMOperationsoverHTTP.html http://wbemservices.sourceforge.net/ http://openwbem.sourceforge.net/ or SNIA, have or are adding a REST alternative to their WBEM? There's a recent spec for assigning a URI to each element in the CIM repository, http://www.dmtf.org/standards/published_documents/DSP0207.pdf If this were occuring, would be a possible starting point. Do you know if any of the open source CIMOM projects, e.g.
http://www.openpegasus.org/manual/CIMOperationsoverHTTP.html
http://wbemservices.sourceforge.net/
http://openwbem.sourceforge.net/
or SNIA, have or are adding a REST alternative to their WBEM? There’s a recent spec for assigning a URI to each element in the CIM repository,
http://www.dmtf.org/standards/published_documents/DSP0207.pdf
If this were occuring, would be a possible starting point.

]]> By: cote http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-9064 cote Thu, 22 Feb 2007 21:02:45 +0000 http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-9064 Those are all excellent points, as usual, Mark. There'd definitly be some transactional considerations. And, as you anticipated, the REST camp reply would be the re-orient the requirements to remove two phase commit. Also -- and to be fair to the Federation folks -- as I got to one of the other points, the major interest I have is in creating an open interface for CMDBs that (hopefully) could be used for federation as well. But, if the implementation of federation doesn't work with the less than transactionally perfect nature of REST (at the moment, hopefully), then other stuff would be needed. In that case, I'd hope the idea of having a REST interface on CMDB's could be moved to a more appropriate forum, or just CMDB's in general. I don't know if anyone has looked to map WS-Man and WSDM to REST. I'm guess not. It'd certainly be a fun exercise and, speaking personally, a good excuse to read those specs ;) Those are all excellent points, as usual, Mark. There’d definitly be some transactional considerations. And, as you anticipated, the REST camp reply would be the re-orient the requirements to remove two phase commit.

Also — and to be fair to the Federation folks — as I got to one of the other points, the major interest I have is in creating an open interface for CMDBs that (hopefully) could be used for federation as well. But, if the implementation of federation doesn’t work with the less than transactionally perfect nature of REST (at the moment, hopefully), then other stuff would be needed.

In that case, I’d hope the idea of having a REST interface on CMDB’s could be moved to a more appropriate forum, or just CMDB’s in general.

I don’t know if anyone has looked to map WS-Man and WSDM to REST. I’m guess not. It’d certainly be a fun exercise and, speaking personally, a good excuse to read those specs ;)

]]> By: Mark Wahl http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-9052 Mark Wahl Thu, 22 Feb 2007 18:24:13 +0000 http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-9052 I'm afraid I see a gap - the CMDBF white paper doesn't spell out what kind of operations are going on between these components. Without this, it's hard for me to evaluate whether a REST/ATOM model would be the best. E.g., if the operations were limited to get properties of a specified configuration object set properties of a specified configuration object get notified of a change of properties then a REST model seems viable, but then so does SNMP. SNMP is widely deployed, easy to implement in everything from a toaster to a data center, etc. But what if the operation is a two-phase-commit? If foo is split across two CMDBs, and an application says "increment foo's counter bar", it might cause causes this federation component to have to negotiate managing separate transactions on the CMDBs. Distributed Transaction Controller advocates would argue that existing protocols for 2PC should be leveraged for this operation; REST advocates might argue that the operations should be changed to avoid the need for 2PC. > Why come up with some horky WS-*/SOAP spec when you > could just define the URL (ok, ok, “URI”…whatever) > addressing of CI’s, how relationships are expressed, > and then slap an ATOM interface on top of it? I would have assumed that a WS-* spec from CMDBF would leverage the already-existing WS-Management and/or WSDM for some of the heavy lifting of data and protocol expression. Has someone analyzed the abstract operations of WS-Management http://www.dmtf.org/standards/published_documents/DSP0226.pdf or WSDM http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm to look at the efficiency and ease of implementation of a REST-encoded equivalent protocol for the same operations? I’m afraid I see a gap - the CMDBF white paper doesn’t spell out what kind of operations are going on between these components. Without this, it’s hard for me to evaluate whether a REST/ATOM model would be the best.

E.g., if the operations were limited to
get properties of a specified configuration object
set properties of a specified configuration object
get notified of a change of properties

then a REST model seems viable, but then so does SNMP.
SNMP is widely deployed, easy to implement in everything from a toaster to a data center, etc.

But what if the operation is a two-phase-commit? If foo is split across two CMDBs, and an application says “increment foo’s counter bar”, it might cause causes this federation component to have to negotiate managing separate transactions on the CMDBs. Distributed Transaction Controller advocates would argue that existing protocols for 2PC should be leveraged for this operation; REST advocates might argue that the operations should be changed to avoid the need for 2PC.

> Why come up with some horky WS-*/SOAP spec when you
> could just define the URL (ok, ok, “URI”…whatever)
> addressing of CI’s, how relationships are expressed,
> and then slap an ATOM interface on top of it?

I would have assumed that a WS-* spec from CMDBF would
leverage the already-existing WS-Management and/or WSDM
for some of the heavy lifting of data and protocol
expression.

Has someone analyzed the abstract operations of
WS-Management
http://www.dmtf.org/standards/published_documents/DSP0226.pdf
or WSDM
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm
to look at the efficiency and ease of implementation of
a REST-encoded equivalent protocol for the same operations?

]]> By: Stefan Tilkov http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-9051 Stefan Tilkov Thu, 22 Feb 2007 17:51:43 +0000 http://www.redmonk.com/cote/2007/02/22/getting-giddy-with-the-cmdb-rest-cheap-spread-and-wet-cis/#comment-9051 You are absolutely correct, but I agree with James - fat chance any big vendor is going to jump on this ... In any case any of them do, count me in as a REST geek available for hire. You are absolutely correct, but I agree with James - fat chance any big vendor is going to jump on this …

In any case any of them do, count me in as a REST geek available for hire.

]]>