[wildfly-dev] Management Model: Squatter Resources

[David M. Lloyd]

On 08/05/2014 10:15 AM, Brian Stansberry wrote:
> On 8/5/14, 9:21 AM, David M. Lloyd wrote:
>> On 08/05/2014 09:00 AM, Brian Stansberry wrote:
>>> On 8/5/14, 8:49 AM, David M. Lloyd wrote:
>>>> On 08/05/2014 02:42 AM, Heiko Braun wrote:
>>>>> TL;DR:  A proposal for improving parts of the management API that deal with static resource definitions
>>>>>
>>>>> Background:
>>>>>
>>>>> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation.
>>>>>
>>>>> Problem:
>>>>>
>>>>> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.:
>>>>>
>>>>> /subsystem=datasources/data-source=ExampleDS
>>>>>
>>>>> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources.
>>>>>
>>>>> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.:
>>>>>
>>>>> /subsystem=ejb3/service=[async | remote | timer-service]
>>>>
>>>> We've solved this a different way in the "next" management model.  We
>>>> introduce the concept of an "attribute group".  In your example we'd
>>>> perhaps have an attribute group for async, one for remote, and one for
>>>> timer-service within the root resource.
>>>>
>>>> An attribute group is something like a composition resource.  They can
>>>> be optional or mandatory, and they can be named or anonymous.
>>>>
>>>> A named attribute group would be separately addressable as a unit, or
>>>> can be accessed using a qualifier syntax e.g. "thegroup.theattribute".
>>>> Also they can be arbitrarily nested.
>>>>
>>>> An anonymous attribute group is just a logical grouping which is only
>>>> relevant to the server Java API itself and is invisible to the so-called
>>>> "DMR" or REST style API.  We can use these groups to retrofit existing
>>>> subsystems without breaking compatibility (this gives certain code reuse
>>>> benefits which are not important to this discussion).
>>>>
>>>> This way we preserve the invariant that all attributes with a given key
>>>> have a related type (we also introduce the concept of type hierarchies
>>>> though, which mitigates this constraint in a different way, but that's
>>>> not related to this).
>>>>
>>>
>>> Is there a notion of null/undefined for the attribute group itself, as
>>> opposed to the individual attributes?
>>
>> Yes, but only for "optional" attribute groups.  IOW the resource author
>> can decide if that's appropriate or not.
>>
>> I have not yet completely worked out how manipulation operations would
>> look for this.  I think it may be closely tied in to what we do for
>> so-called "complex" attributes though.
>>
>>> That's a conceptual distinction -- a resource doesn't exist unless it's
>>> added.
>>
>> Yes, it's a distinct concept.  However (at least for the given example)
>> I think that an attribute group is a better fit.  The problem with
>> "squatters" is that they don't really have a common API, and yet they
>> aren't really independent - it's just a way of addressing the
>> composition of a parent resource.
>
> Where is the boundary for "independent"?
>
> I've concluded that over time we've gone too far toward making resources
> out of things that are not independent, with resources used for things
> that really aren't at all. But is service=remote not semi-independent?
> It adds an entire chunk of functionality, including a requirement for
> the presence of a remoting subsystem.

Yeah that is true, conceptually.  There is possibly a line where 
subsystems might themselves have subsystems.  But in this case, maybe it 
would sometimes make sense to use the existing profile/subsystem 
relationship as a prototype?

Also, if a subsystem is truly in two or more parts, then we should 
consider having separate subsystems for the parts (consider PicketLink 
as a recent example).  This isn't the case for your example, but it does 
clear out some more possible candidate cases.

If there remains a gray area where a subsystem has specific constituent 
functionality *and* there is a large enough degree of independence 
between the enclosing and enclosed resource that an optional attribute 
group seems inappropriate (but not large enough to warrant a separate 
subsystem), *that* would be the remaining case that would support these 
singleton sub-resources.  We just have to identify the qualifying 
criteria for this distinction.

> I see how it could be treated as just another aspect of the parent. I'd
> like to have a clearly explainable boundary line. Maybe a bit fuzzy, but
> something clear for 98% of the cases.

Yeah I agree, clearly delineating the cases is key.  If we have three or 
four mechanisms which are similar, but there's no clear guideline as to 
what is appropriate and when, we're going to end up with a mess.

Going through the existing model again with this in mind might be the 
right next step, and seeing if it's possible to clearly categorize 
existing cases into "should be an attribute group" versus "should be a 
singleton resource", would be a great way to validate the logic of the idea.

If we can do so in a fairly logical and deterministic manner, then I can 
look into seeing if I can make sub-resources work this way in the new 
model.  The main conceptual issue here is the addressing scheme - in 
particular using the value to select resource type instead of the key. 
This introduces a third major way to identify sub-resources in addition 
to the normal map-like structure and the profile/subsystem scheme.  If 
we can avoid this then that makes this more feasible.

-- 
- DML