Comparison of JMX information model and AS7 resource model

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Comparison of JMX information model and AS7 resource model

Jeff Mesnil
While working on adding AS7 notifications[1], I had an extensive look at the JMX information model to see how it modelizes notifications.
I took the opportunity to make a comparison of the whole JMX information model (including the extension for Model MBeans) to the AS7 resource model[2]

Notifications are the main thing missing in the AS7 resource model.

We have additional info (esp. a tree hierarchy) but there are some informations that JMX provides and we do not.
Amon the interesting info that we are missing:
- deprecated => we have deprecated info for attribute and operation but not for the resource as a whole
- since => we have no information on when a resource/attribute/operation has been added
- displayName => we have no human-readable info suitable for display (e.g. "JMS Queue" for jms-queue resource, same for attribute and operation names)
- lastUpdatedTimeStamp => when an attribute has been updated for the last time

Additionally, JMX's ObjectName can define patterns. AS7 PathAddress allows only wildcard for the path element value (e.g. /subsystem=messaging/hornetq-server=*/jms-queue=*) but not for a path element itself (e.g. /subsystem=messaging/* to match child of the subystem).
The only use case where I would like to be able to use such a pattern is to register notifications more simply (i.e., send me any notifications for the messaging subsystem is simpler if I can use something like Ant's file pattern such as /subsystem=messaging/**/* instead of having to iterate on all the resource in the tree).

Some of these infos could be added to AS8 resource model.
If we find that these missing infos are interesting, we could add them to AS8 resource model.

[1] https://issues.jboss.org/browse/AS7-370
[2] https://docs.google.com/spreadsheet/ccc?key=0AgnxDyYwHtqVdE9RaW9IM2lZbzBoclQ4YnNkVmtsWkE&usp=sharing#gid=0 sorry for the color blind :)
[3] http://ant.apache.org/manual/dirtasks.html

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of JMX information model and AS7 resource model

Brian Stansberry
On 3/4/13 10:59 AM, Jeff Mesnil wrote:
> While working on adding AS7 notifications[1], I had an extensive look at the JMX information model to see how it modelizes notifications.
> I took the opportunity to make a comparison of the whole JMX information model (including the extension for Model MBeans) to the AS7 resource model[2]
>
> Notifications are the main thing missing in the AS7 resource model.
>
> We have additional info (esp. a tree hierarchy) but there are some informations that JMX provides and we do not.
> Amon the interesting info that we are missing:
> - deprecated => we have deprecated info for attribute and operation but not for the resource as a whole

We should add this for AS 8.

> - since => we have no information on when a resource/attribute/operation has been added

I dread the effort to add this data for existing attributes. I also fear
it will end up being extremely inconsistently applied unless it can just
fall out of what we do for AS 9+ or be required at build time by the
code generation.

> - displayName => we have no human-readable info suitable for display (e.g. "JMS Queue" for jms-queue resource, same for attribute and operation names)

This would have to have i18n applied. This seems like a good candidate
for inclusion when we determine the complete set of any additional
metadata we want to add to support UIs.

> - lastUpdatedTimeStamp => when an attribute has been updated for the last time
>

I don't think this is really applicable. We also don't have the notion
of 'value' -- the "Current (cached) value for attribute or operation" --
which is what this describes. A resource has a value, but the metadata
description does not.

One of the things in JMX I was never a fan of was some of the mixing of
'data' and 'metadata' that it has.

> Additionally, JMX's ObjectName can define patterns. AS7 PathAddress allows only wildcard for the path element value (e.g. /subsystem=messaging/hornetq-server=*/jms-queue=*) but not for a path element itself (e.g. /subsystem=messaging/* to match child of the subystem).
> The only use case where I would like to be able to use such a pattern is to register notifications more simply (i.e., send me any notifications for the messaging subsystem is simpler if I can use something like Ant's file pattern such as /subsystem=messaging/**/* instead of having to iterate on all the resource in the tree).
>

If we allow that in PathAddress, we'll first have to validate that it
doesn't break other use cases for wildcards. The simple case is using a
wildcard to read attribute 'foo' on a bunch of resources. The child type
is *generally* what defines that 'foo' exists. If you try to read 'foo'
from other child types it's going to fail. And I'm not real inclined to
go to the effort to ignore those failures or figure out which resources
are truly applicable for the request. At least not in AS 8. :)

I said *generally* though. In quite a few cases the resources under
key=A and key=B have different definitions, and using a wildcard won't
work. So perhaps allowing a wilcard in the key wouldn't introduce any
fundamental difference. If a users uses a wildcard for something, they
need to understand the potential impact.

> Some of these infos could be added to AS8 resource model.
> If we find that these missing infos are interesting, we could add them to AS8 resource model.
>
> [1] https://issues.jboss.org/browse/AS7-370
> [2] https://docs.google.com/spreadsheet/ccc?key=0AgnxDyYwHtqVdE9RaW9IM2lZbzBoclQ4YnNkVmtsWkE&usp=sharing#gid=0 sorry for the color blind :)
> [3] http://ant.apache.org/manual/dirtasks.html
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Comparison of JMX information model and AS7 resource model

Dimitris Andreadis
In reply to this post by Jeff Mesnil
Some of the JMX attributes (currencyTimeLimit, lastUpdatedTimeStamp, etc.) really come from
the management world and the idea that the MBean is really the management proxy of a real
resource (e.g. an external printer) so it's not surprising they don't really apply to our case.

We had to write all of this stuff in JBossMX in the days before JMX became part of the JDK.

Nice work, BTW :)

On 04/03/2013 17:59, Jeff Mesnil wrote:

> While working on adding AS7 notifications[1], I had an extensive look at the JMX information model to see how it modelizes notifications.
> I took the opportunity to make a comparison of the whole JMX information model (including the extension for Model MBeans) to the AS7 resource model[2]
>
> Notifications are the main thing missing in the AS7 resource model.
>
> We have additional info (esp. a tree hierarchy) but there are some informations that JMX provides and we do not.
> Amon the interesting info that we are missing:
> - deprecated => we have deprecated info for attribute and operation but not for the resource as a whole
> - since => we have no information on when a resource/attribute/operation has been added
> - displayName => we have no human-readable info suitable for display (e.g. "JMS Queue" for jms-queue resource, same for attribute and operation names)
> - lastUpdatedTimeStamp => when an attribute has been updated for the last time
>
> Additionally, JMX's ObjectName can define patterns. AS7 PathAddress allows only wildcard for the path element value (e.g. /subsystem=messaging/hornetq-server=*/jms-queue=*) but not for a path element itself (e.g. /subsystem=messaging/* to match child of the subystem).
> The only use case where I would like to be able to use such a pattern is to register notifications more simply (i.e., send me any notifications for the messaging subsystem is simpler if I can use something like Ant's file pattern such as /subsystem=messaging/**/* instead of having to iterate on all the resource in the tree).
>
> Some of these infos could be added to AS8 resource model.
> If we find that these missing infos are interesting, we could add them to AS8 resource model.
>
> [1] https://issues.jboss.org/browse/AS7-370
> [2] https://docs.google.com/spreadsheet/ccc?key=0AgnxDyYwHtqVdE9RaW9IM2lZbzBoclQ4YnNkVmtsWkE&usp=sharing#gid=0 sorry for the color blind :)
> [3] http://ant.apache.org/manual/dirtasks.html
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev