typed interface of identity api

[tom.baeyens]

after integrating the identity api in jbpm, i have 2 remarks:

1) typed interfaces are nice in oo design, but i believe they are counterproductive in this api. before i can do a query that involves a user and a group, i have to fetch the identity-object and group-object from the api. only then i can supply those objects into the query method.

this means 3 api calls instead of just 1. probably this will lead to 3 times DB access instead of 1.

in the jbpm api, we take primitives (id's) as method parameters in our session facade apis. and we provide typed objects as the return value. in case you would have the typed object and need to invoke a method, then you can always supply the id by doing someObject.getId().

2) i believe there should be no difference between a role and an association. role should be just an optional property of an association. this would make the whole model and the related api managers a lot simpler.

[bdaw]

For the first point I agree it could be improved to avoid unnecessary calls. Like I mentioned in the other post (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209457#4209457) I'm still thinking a bit about how IDs should be handled.

Actually currently in both IdentityStore implementation the IdentityObject name is required to be unique per IdentityObjectType. This makes any IdentityObject uniquely identified by pair of name/type. Translating this into the API language:
- Identity is uniquely identified by its name
- Group is uniquely identified by name/GroupType pair.
Therefore current String ID is mostly only internal IdentityStore information that lets to retrieve such object efficiently (directly - without additional queries). Maybe it would make sense to let use those information in API more directly? Something like:
- associateGroups(GroupType parentType, String, parentName, GroupType childType, String childName)
or use other object to embedd those information (name/type + optionally store internal id) and let construct it without need to fetch anything from the store...

I'm open for suggestions...

For the second issue regarding the role association:
The main problem is to keep in mind that some of IdentityStore implementations won't support roles at all (simple LDAP tree shape is the perfect example). That's why I want to distinguish it in the API. However I'm still thinking about adding switches to RelationshipManager methods to also fetch roles in "findAssociatedXXX()" methods and will probably go this way... need to check if it doesn't make additional complications internally and keeps the API consistent.

[tom.baeyens]

"bdaw" wrote:
Maybe it would make sense to let use those information in API more directly? Something like:
- associateGroups(GroupType parentType, String, parentName, GroupType childType, String childName)

exactly. the default case should be a one-to-one mapping between the api-ID and the phisical identityStore-ID.

only if the user wants to bind to some exotic identity store, then a mapping between the API-ID strings and the identity store IDs might be necessary. the API/SPI architecture would still allow that.

i would even make the groupTypes plain strings in the api.

[bdaw]

"bdaw" wrote:
Maybe it would make sense to let use those information in API more directly? Something like:
- associateGroups(GroupType parentType, String, parentName, GroupType childType, String childName)

exactly. the default case should be a one-to-one mapping between the api-ID and the phisical identityStore-ID.

Here you mean the same like it is now? Not sure if I understand this part correctly

only if the user wants to bind to some exotic identity store, then a mapping between the API-ID strings and the identity store IDs might be necessary. the API/SPI architecture would still allow that.

Open question is how to put changes into the API. So for egz.
Approach A) We make methods duplicates like the one I described above whenever possible to use type/name information. One problem here is that for methods like:

void associateIdentities(Collection<Group> parents, Collection<Identity> members)

it's hard to find handy alternative :)

Approach B) We have Identity.getId() and Group.getId() but the actual content of the returned String is some encoded value like [typeName];[name];[store_internal_id]. Last part could be optional

Then we can utilize String like ID more in methods but main problem is that format can't be final - it shouldn't be allowed to assemble such id manually. It would require some dedicated method. Format can utilize something like basic xml to encode information. Then minimal required ID content would be name/type pair. Other info like realm id, repository id, store id and true object id inside the store is optional and applied by the SPI. Would it make sense? Something like

String PersistenceManager.getIdentityId(String name);
String PersistenceManager.getGroupId(String name, String type);

Then we make another version of methods with String ids like:

void associateGroupsAndIdentities(Collection<String> parentGroupIDs, Collection<String> memberIdentityIDs)

How does it look like? Obviously we could have both A) and B) concept. The main limitation here is to not triple number of methods....

i would even make the groupTypes plain strings in the api.

Indeed. In current shape both GroupType and RoleType could be changed into plain String . Other similar one is CredentialType but because of how Credential is implemented it can be left like this.