Domain manager protocol and relation to QMF

[starksm64]

I'm curious how our domain manager protocol might relat to QMF:

https://cwiki.apache.org/qpid/qpid-management-framework.html

Since we have (or will have) a qpid implementation in hornetq, I'm wondering if there is an advantage to aligning with this protocol since it is what the rhel management tools are being based on.

[brian.stansberry]

I didn't see a specific description of the protocol between the broker and the agent, but I assume it's qpid, which means hornetq running on the agent???

Based on our discussion in Madison, we don't want complex subsystems like HQ running on the domain controller. We'd discussed having it run the native Java protocol and a simple http server for REST. However, we decided to provide a separate server profile intended to run the domain management webapp. Perhaps a hornetq-based QMF agent could be added to that profile?

I know the JON folks prefer a metadata based management API instead of coding directly to a complex set of classes. So if we're going to develop the metadata and we're eventually going to have to support QMF's, we should consider just using it now.

TBH though, this doesn't look really fleshed out to me, and they are apparently looking at changing the protocol:

https://cwiki.apache.org/qpid/qmf-map-message-protocol.html

Trying to target something that is unstable makes me very nervous.

[dmlloyd]

Anything in on or around AMQP seems to get completely respecified periodically, so I'd hold off on counting on anything from that lot.  But yeah the real question is not so much the protocol specifics but if we're going to go to a metadata-based model or stick with our strongly-typed model, or maybe both?

[jason.greene]

It seems like this should just be exposed as a mapping on top of our Apis when the time is right.

[brian.stansberry]

David Lloyd wrote:

Anything in on or around AMQP seems to get completely respecified periodically, so I'd hold off on counting on anything from that lot.  But yeah the real question is not so much the protocol specifics but if we're going to go to a metadata-based model or stick with our strongly-typed model, or maybe both?

My thinking had been both, i.e. via "a mapping on top of our Apis when the time is right."

[pilhuhn]

I think I will take part in the Nov 15th meeting and will be able to present about RHQ and how its model works.

The RHQ model has the huge advantage, that stuff like HornetQ or Infinispan that already has a plugin can just be plugged in without the need to re-code its management functionality.