All, Just been discussing this and realised that I had (I think!) misunderstodd what Andrea is talking about with these JMX interfaces. So, the existing Java Broker JMX interfaces are not the key input here, rather the AMQP managament interfaces are.
Thus - can someone document (or point me at the docs) the C++ implementation of the AMQP management model as I think we also need this for Rahul's GSoC project. We can then discuss how the existing Java Broker JMX interfaces tie up here, to link into the AMQP management interface i.e. we'll have - client JMX <-> [any broker's] AMQP management interfaces <-> [C++] broker implementation - client JMX <-> [any broker's] AMQP management interfaces <-> [Java] broker implementation Hoping I have the stick by the correct end now .... Marnie On 4/22/08, Gordon Sim <[EMAIL PROTECTED]> wrote: > Andrea Gazzarini wrote: > > > Now, my question is : what level of granuarity should be used in the JMX > > Bridge? Do you think it's better to use an interface like this: > > int getMessageCurrentCount(); int getMessagePendingCount(); int > > getActiveConsumbers(); int getTotalConsumers(); ... > > or using data transfer object like the following: > > Queue getQueue(...); > > where Queue is a DTO and is implementing the interface described above. > > Let me know... > > > > I initially imagined the JMX bridge to be a JMX 'connector' that (a) > exposed the AMQP-based approach to management that the c++ broker uses to > JMX clients and (b) allowed a JMX managed entity (such as the java broker) > to be manipulated using that same AMQP-based approach. > > I.e. the bridge would be very generic and usable for interop between the > AMQP-based management scheme and JMX regardless of the object model exposed > by the managed entity. (The rationalisation/standardisation of the object > models exposed by c++ and java brokers would then be a separate step). > > However, this was just a very vague and very high-level picture in my > mind. Is this actually feasible? If so the bridge itself would not care > about the granularity of the object model to be used. If not, what are the > issues that prevent it? >
