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?
