Comments on: How not to re-use XML technologies http://stage.vambenepe.com/archives/139 IT management in a changing IT world Fri, 29 Aug 2008 05:54:40 +0000 http://wordpress.org/?v=2.6 By: William Vambenepe’s blog » Blog Archive » Microsoft ditches SML, returns to SDM? http://stage.vambenepe.com/archives/139#comment-33390 William Vambenepe’s blog » Blog Archive » Microsoft ditches SML, returns to SDM? Wed, 13 Feb 2008 21:44:23 +0000 http://stage.vambenepe.com/archives/139#comment-33390 [...] rather than a more stand-alone, management-specific approach like SDM. As I’ve argued before (look for the “XSD in SML” paragraph), in retrospect this was the wrong choice. SML was [...] [...] rather than a more stand-alone, management-specific approach like SDM. As I’ve argued before (look for the “XSD in SML” paragraph), in retrospect this was the wrong choice. SML was [...]

]]> By: vbp http://stage.vambenepe.com/archives/139#comment-28168 vbp Thu, 20 Dec 2007 21:44:37 +0000 http://stage.vambenepe.com/archives/139#comment-28168 Hi Tim. I think there is room for CMDB-specific federation technology to be created but I agree with you that efforts around federating CMDBs should also leverage generic query federation capabilities when available. It's a matter of finding the right balance between generic federation technology, like what your company provides and CMDB-specific parts. The reason I believe there is room for CMDB-specific parts is that query federation in the generic sense is a very hard problem to solve, one that requires compromises in either scale, performance, freshness or other such dimensions. Focusing on a specific domain, like IT configuration management allows one to make simplifying assumptions and optimizations that are appropriate for that domain and make the problem more tractable. In that sense, query federation is different from other technologies like encryption which are pretty well addressed by generic technology so there is no need to develop CDMB-specific encryption technology. Hi Tim. I think there is room for CMDB-specific federation technology to be created but I agree with you that efforts around federating CMDBs should also leverage generic query federation capabilities when available. It’s a matter of finding the right balance between generic federation technology, like what your company provides and CMDB-specific parts. The reason I believe there is room for CMDB-specific parts is that query federation in the generic sense is a very hard problem to solve, one that requires compromises in either scale, performance, freshness or other such dimensions. Focusing on a specific domain, like IT configuration management allows one to make simplifying assumptions and optimizations that are appropriate for that domain and make the problem more tractable.
In that sense, query federation is different from other technologies like encryption which are pretty well addressed by generic technology so there is no need to develop CDMB-specific encryption technology.

]]> By: Tim Matthews http://stage.vambenepe.com/archives/139#comment-28162 Tim Matthews Thu, 20 Dec 2007 19:31:09 +0000 http://stage.vambenepe.com/archives/139#comment-28162 William, I have been coming up to speed on CMDBf and have found your blog very helpful. While I am just beginning to understand the spec, your comment "I have good hopes for CMDBf, now in the DTMF, not necessarily as a federation technology but as a useful basis for increased interoperability between configuration repositories" echoes what was going through my head. I work for a database virtualization company that uses query federation as our core enabling technology. While I have a vested interest here, seems to me that query federation could be a useful tool for implementing a federated CMDB, esp. one like ours that speaks SQL and XQuery and can publish results as Web Services. I guess my question is why build a spec for federation when there are already ways to do it; building a schema or transport message format does make sense. Thanks, Tim William,

I have been coming up to speed on CMDBf and have found your blog very helpful. While I am just beginning to understand the spec, your comment “I have good hopes for CMDBf, now in the DTMF, not necessarily as a federation technology but as a useful basis for increased interoperability between configuration repositories” echoes what was going through my head.

I work for a database virtualization company that uses query federation as our core enabling technology. While I have a vested interest here, seems to me that query federation could be a useful tool for implementing a federated CMDB, esp. one like ours that speaks SQL and XQuery and can publish results as Web Services. I guess my question is why build a spec for federation when there are already ways to do it; building a schema or transport message format does make sense.

Thanks,

Tim

]]> By: William Vambenepe’s blog » Blog Archive » Manageability, management integration and WS-Management http://stage.vambenepe.com/archives/139#comment-28159 William Vambenepe’s blog » Blog Archive » Manageability, management integration and WS-Management Thu, 20 Dec 2007 18:13:38 +0000 http://stage.vambenepe.com/archives/139#comment-28159 [...] Leaving the SUV analogy aside, it’s not that WS-Management is perfectly designed for management integration either, not by a long shot. Which takes us to a third reason (and there are more) why WS-Management is not being used in management integration scenarios: it has technical deficiencies as do many of the other specifications recently created for management integration. That’s the topic of the next post. [...] [...] Leaving the SUV analogy aside, it’s not that WS-Management is perfectly designed for management integration either, not by a long shot. Which takes us to a third reason (and there are more) why WS-Management is not being used in management integration scenarios: it has technical deficiencies as do many of the other specifications recently created for management integration. That’s the topic of the next post. [...]

]]>