[jboss-as7-dev] 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