Robert Greig wrote:
On 14/03/2008, Carl Trieloff <[EMAIL PROTECTED]> wrote:
I like this idea, but I don't want to have to open a WS connection to
each broker, I would
prefer an architecture where the interface to WS-DM could be off-loaded
to anywhere on the network, on the
C++ side I would think we would create a WS-DM to AMQP-mgmt bridge. C++
uses the
following to get info in/out of the broker for mgmt
http://cwiki.apache.org/qpid/management-design-notes.html
OK this makes sense. Of course if you use a tool such as WinRM or HP
Openview or Tivoli then it can present a consolidated view of the
brokers.
I also want to make it possible to payload more than just broker mgmt
info on the mgnt channel.
Can you give some examples?
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.
So having JMX and WS-DM as standard ways to pull the mgmt off the 'bus'
would most likely increase these types
of usage of Qpid infrastructure
Question, go from AMQP-mgmt to WS-DM or to JMX then to WS-DM? I would
think straight to WS-DM but then
how would the Java Broker fit in? would we add the AMQP-mgnt to Java
broker, map JMX to WS-DM on Java side
etc... going to JMX is an easier community project, as many JMX
consoles in open source exist, don't know of any OSS
WS-DM ones exist
I'm not quite sure of the question? JMX provides an adaptor so that
you can expose any MBean as WS-M.
If I understand it, you are suggesting a separate process that speaks
AMQP-Management to brokers but itself is exposed over WS-M. In that
case, you'd implement the separate process in terms of JMX and it
would then be able to support native JMX clients and WS-M clients.
yes, exactly.
Is AMQP management an approved AMQP spec?
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.
I would obviously be interested in the thoughts of other users but in
terms of priority, I am not convinced that implementing
AMQP-Management is particularly pressing for the Java broker - there
are other things our users want that offer more advantages. The reason
is that the third party management tools do not speak AMQP-Management
(and almost certainly never will).
As it stands, by doing some testing with the Sun JMX/WS-M adapter we
can claim out of the box HP OpenView and Microsoft WinRM (and possibly
Tivoli) interoperability.
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?
We should think about the things we expose over WS-M or SNMP which is
what the users will interact with (indirectly). Ideally these should
be consistent across the C++ and Java projects.
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
Also, does apache WS have a WS-DM impl (Rajith..?) do you know?
https://wiseman.dev.java.net/ is one.
Carl.
