Hi Marnie, I don't know the project plan exactly but your assumption is right : something needs to be done on Java broker side in order to enhance it with management capabilities.Fortunately, if it will be done in respect of QMF rules then QMan will transaparently integrate with that (because it is not using JMX but AMQP Mmgt extension in order to communicate with broker).
That means, for example, that QMan is not affected by changes on management schema because it is sent & built (on QMan side) at runtime by the connected broker. If some change occur (at runtime) on for example the queue definition (attributes or operations) a schema for that class is requested again by QMan and its definition is updated conseguently. I think that briefly I'll have commit rights so I will be able to update the documentation of QMan in order to explain (from a user and developer point of view) how things are working... Best regards, Andrea 2008/12/22 Marnie McCormack <[email protected]> > Hi Andrea, > > Thanks very much for the speedy response. > > I may have misunderstood (apologies if so) but I'd assumed that some > integration was planned for the existing management objects in the Java > broker (JMX interfaces and underlying MBeans) and the Qman stuff. However, > I'm not very plumbed into the QMan/QMF design so apologies if I'm > incorrect. > > Just wanted to be sure that when we're discussing the management schema, > this doesn't refer to wholesale changes to the existing management objects > in the Java broker - which might then have impact on the functionality of > the existing toolset. > > I'll try to get a better handle on the QMF/QMan designs over the next > couple > of weeks ! > > Thanks & Regards, > Marnie > > On Mon, Dec 22, 2008 at 11:35 AM, Andrea Gazzarini <[email protected] > >wrote: > > > Hi Marnie, from that point of view (backwars compatibility) I think that > > there's no problem at all because > > > > - QMan is not part of JMXConsole or CLI; > > - It is not affecting the communication protocol between those clients > and > > the broker; I think (I don't know exacly) those tools are communicating > > with > > Java broker using JMX while QMan is using AMQP; > > - QMan WS-DM adapter is communicating with QMan using JMX but the managed > > objects are those under QMan domain and not Qpid; When the Java broker > will > > be management enabled its obejcts (connectiosn, queues, exchanges, ) will > > be > > transparently proxied by QMan; > > > > I did some steps ahead on WS-DM Adapter development and I was just trying > > to > > write something about that...I'll send shortly. > > > > Best regards > > Andrea > > > > 2008/12/22 Marnie McCormack <[email protected]> > > > > > Hi Andrea, > > > > > > This is a really interesting thread. > > > > > > On the java side, the challenge will be to make the changes reuqired > > whilst > > > maintaing backwars compatibility with the Eclipse JMX console and the > > CLI, > > > both of which are important tools in use. > > > > > > I know that Robbie & Martin are both working quite a bit in this area > so > > > can > > > probably help/discuss any changes required here. > > > > > > Hth, > > > Marnie > > > > > > On Fri, Dec 19, 2008 at 3:38 PM, Carl Trieloff <[email protected] > > > >wrote: > > > > > > > > > > > Andrea, > > > > > > > > Great, as you know the QMF stuff now, a starting point might be to > help > > > > work out how > > > > to add QMF to the Java Broker. That is the big elephant that needs to > > be > > > > tackled on the Java > > > > management side which will require the mgnt schema cleaned up between > > the > > > > two. > > > > > > > > The second big missing piece is being able to push JMX objects onto > the > > > QMF > > > > bus. > > > > > > > > When you get there, shout, and I will gladly give you pointers. > > > > > > > > regards, > > > > Carl. > > > > > > > > > > > > > > > > Andrea Gazzarini wrote: > > > > > > > >> Ok Carl it's clear and I agree with you. Concerning the area of > > > >> interests, I'd like to be involved (when the work on WSDM adapter > will > > > >> be completed or at least stable) in the implementation of AMQP > > > >> management extension on java broker... :) > > > >> > > > >> Best regards > > > >> Andrea > > > >> > > > >> On 12/19/08, Carl Trieloff <[email protected]> wrote: > > > >> > > > >> > > > >>> Andrea Gazzarini wrote: > > > >>> > > > >>> > > > >>>> Hi all, another piece of ws-dm info concerning notifications & > > events > > > : > > > >>>> While JMX Notification listener is a normal java class running on > a > > > >>>> standalone application, WS-DM event listeners must be a valid web > > > >>>> service > > > >>>> endpoint (not a standalone application) so I think that in order > to > > > >>>> demonstrate the (future) capabilities of the WS-DM adapter we > could > > > >>>> create > > > >>>> a > > > >>>> management console that is a web application able to connect with > > QMan > > > >>>> (and > > > >>>> therefore to a Qpid management enabled) via WS-DM. So the final > > > scenario > > > >>>> will be : > > > >>>> > > > >>>> Mgmt Console / Mgmt client (ex: HP Openview) --(wsdm)--> WS-DM > > Adapter > > > >>>> --(jmx)--> QMan --(amqp)--> Qpid > > > >>>> > > > >>>> What do you think? It should be great for example to develop that > > > >>>> management > > > >>>> console using Ajax in order to have the user interface > > automatically > > > >>>> refreshed after subscribed notifications... > > > >>>> > > > >>>> ...but before of that the WS-DM adapter must be completed :) > > > >>>> > > > >>>> Best Regards, > > > >>>> Andrea > > > >>>> > > > >>>> > > > >>> Andrea, > > > >>> > > > >>> I think the value of the WS-DM Adapter is so that HP Openview, BMC > > > >>> patrol etc can be plugged > > > >>> into a Qpid QMF install. i.e. WS-DM provides the way to integrate > > with > > > >>> the big brand name > > > >>> consoles > > > >>> > > > >>> However, in writing a console specific to Qpid I would not go via > > > WS-DM, > > > >>> but rather directly from > > > >>> the QMFC interfaces. Two examples are such consoles done from QMF > are > > > >>> oVirt (done in Ruby) and > > > >>> the Red Hat MRG console done in Python. Both of these are web based > > > Ajax > > > >>> consoles. > > > >>> > > > >>> I can post some screen shots on the wiki, and if you want to hack > in > > > >>> that area shout. > > > >>> Carl. > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >> > > > >> > > > >> > > > > > > > > > > > > > >
