[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]