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. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > > >
