I did not mean it from the point of load balancing.
The JMS metadata API (I compare it with the JDBC metadata API) would allow users to obtain information about the object they are working with. The example I gave is queue depth.
Just look to a Q object in for example MQ and see what kind of metadata you can retrieve of it.
I understand that some of them are provider specific, but queue depth is something very universal.
The reason to obtain queue depth could be from a "monitoring" point of view.
It could also be from a debug point of view.
Fact is that such data could be interesting to retrieve via de JMS metadata API, which is now all provider specific. Another one would be to get a list from existing MOM objects.
Which is also possible via the JDBC metadata API, you can also ask the question "why do you want to know which tables are in a db, or which are the columns of a given table?"
It is just handy in some circumstances and imho should be part of the JMS api (as metadata)
Fact is that MOM's are mostly used in asynch systems, any help of getting information about status or processing progress is welcome. This now all needs to be done via provider specific APIs