OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [provision] Groups - 2.0-Relationships.pdf uploaded


Gary ,

To your last comment :

" 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?"


I do not argue that adding group membership as a PSO type is better modeling
the environment , but as you clearly expressed in your response, this is an
approach that we have chosen not to take , yet. This leaves us to two
options - leave it totally out of the SPML spec.  Or , provide a simple way
to address it . I am for the second approach as I suggested. 
As for the schema, the answer is pretty clear, we will need to be able to
let the client application figure out what connection types are supported by
the SPML implementation and what attributes are there. It therefore should
be part of the schema representation .

Doron

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Thursday, July 22, 2004 3:18 AM
To: Cohen, Doron
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] Groups - 2.0-Relationships.pdf uploaded


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]