Re: [provision] Groups - 2.0-Relationships.pdf uploaded

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Cohen, Doron wrote:

>Gary,
>
>A significant functional requirement for SPML 2.0 is the ability to express
>attributes/properties for connection/relationships . The current proposed
>interface does not expose that capability while RACF connections are only
>one example of many other real life use cases that require that. The
>approach presented in the document to create a PSO to represent complex
>relationships does not solve the problem since it means that the standard
>SPML 2.0 connections will need to be bypassed by the implementers.
>
>It is my view that addressing the requirement means minor modification to
>the interface, and while optional for implementers, it maintains SPML 2.0
>ability to represent complex relationships .
>
>For example :
>
>*	connect (fromID, toID, connectionType, connectionAttributes)
>*	modifyConnectionDetails (fromID, toID, connectionType,
>connectionAttributes)
>
>Do you see a downside that should prevent us from including this ?
>
>  
>
Well, perhaps.  As we discussed with Rami at the face-to-face in Long 
Island, relationships that stateful and persistent are the most 
expensive kind of relationships.  At the time, our discussion assumed 
that in order to support complex relationships each instance of 
relationship would have to be a PSO.  Jeff Bohren and I explained that 
this imposes a development burden on the implementer and a 
performance/resource burden on the provider. Allowing a relationship 
instance to be modified by ID requires the provider to maintain a 
persistent mapping between PSO ID and the underlying object on the 
target.  Worse, this persistent mapping must scale to the number of 
connections, which is order M*N.

However, I believe that the approach you propose above (i.e., adding 
connectionAttributes to 'connect') avoids these problems.  Since it does 
not represent the relationship instance as an object with an ID,  the 
operation remains stateless.  The operation has only to map the 
combination of fromId, toId and connectionType to the underlying object 
(or API) on the target. To continue our RacfGroupMembership example, the 
operation has only to:
1) map the 'fromId' to a user
2) map the 'toId' to a group
3) map the connectionAttributes to the CONNECT API

The third step concerns me.  If RacfGroupMembership were defined as a 
PSO Type, the schema of the target would define the XML representation 
(i.e., elements and attributes) of RacfGroupMembership.  If 
connectionAttributes are arbitrary, how will the caller know which to 
attributes specify (and in what format)?  Would we need some sort of 
schema for the connectionType?

Gary

ps. BTW, the 'modifyConnectionDetails' operation may not be necessary.  
A RACF CONNECT command either A) creates a new connection with the 
specified attributes or (if a connection already exists) B) modifies 
attributes of the existing connection.  We could follow this example 
(and allow any specified attribute value to overwrite the corresponding 
attribute value of the existing connection).

gary