On 14/03/2008, Carl Trieloff <[EMAIL PROTECTED]> wrote: > sure, as you know qpid get's included into fedora, this feature has been > picked up to also > transport OS info, CPU, interrupts, network etc. > > Another project that I know that has picked it up is looking to push > data around hypervior info > > And yet another is doing work laying sec alerts, and resource > utilization over the same mechanism. It turns > out it is very easy to create another mgmt object and integrate it.
Interesting. This raises some further questions in my mind: 1) What applications/tools view and process the data? i.e. if a group puts CPU info into the management messages, what do they read it in? 2) For some of these it sounds like the message format is being used as a general format for management info that is pretty much independent of the broker (or Qpid). Is this intended to replace or compete with WS-M? > not yet ... but multiple parties in AMQP Working Group have expressed > support for it, one > of the rabbit users has been working with it also - I am sure hit will > get updated somehow before > making it's way into a release. Discussion so far is in the WG is that > it would be optional to impl as part > of the spec. The advantage of this I suppose is that if multiple broker implementations supported it, users could manage their installations from a single tool. Or, more realistically, if users wrote scripts against the JMX interface, those would be portable across different brokers. I think it would be useful to know how concrete the Rabbit (or other vendor) plans are. > yes agree, thus I was suggesting that it is nice project for someone to > pick up, so the > bridge exists and then makes it valuable for Java broker when it gets to > it. The questions > is -- if we do a bridge as a project would that also be interesting for > the Java broker down the road? I think it would be interesting. Even in the short term, it would be useful for the C++ and Java brokers to share the management verbs and properties. From a user perspective if the bridge supported WS-M and JMX then the C++ (via the bridge) and Java brokers (natively) would in theory support the same set of tools. > yes, there are two places we can map this, at the broker into the > AMQP-mgmt protocol or > at the impl of the bridge. I think the former is the better approach -- > please comment if you > don't agree I think that AMQP-mgmt is a better approach if it gets proper buy-in. RG
