User in API, User for business process in companies

[antoine_h]

Hello,

Thanks a lot for this huge step (I just see now) on this project !

My questions are about the User class and User Id.
Related to systems integration in companies.

they are related to this post for design issue and proposal here (Design of JBoss Portal forum) :
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=112843
the post : Sat Aug 4, 2007 15:46 PM

First question : User class : bridge between the "UserJBossIDProject" and "UserBPCompany".
usualy, for what I can see in many companies I work for, they have a "UserBPCompany".
It is provided by a source, a JMX service... etc... (internal framework or so). This source may run with JBoss also, or at least with Java.
Those are used in the BusinessProcess applications (most of the time, integrated inside some portal or so).

In the Identity project, there will be a "UserJBossIDProject" (overriden from the Identity interface, if I understood well).

The best way I have found to make the whole thing work (with User in Portal), is to build a kind of bridge beetwen the two classes : so to provide a "UserJBossIDProject" from the "UserBPCompany".
(see the other post for details).

I guess this will be easier with the new Identity Model ?
What about providing a template for this bridge, optional, but ready for integration if the company needs it ?
(forgive if I it is yet in the project, but I missed it).

Second question (related to one) : User Id :
the Id is Object.
What about using the java generics ?
<IDENTITY_ID>
and
public IDENTITY_ID getId();

this would be nice to more strongly type the Id : it can be Integer, Long,... or like in Hibernate, a more complex object.

This would allow to override the interface with IDENTITY_ID defined. And use this specialized interfaces with strong type.

Pros and cons I can see :
Pros :
- Id are very important. Having a strong typing is good for clean programming.

- Id of user are used every where in the business process code. many objects of the business process make some reference to some users (bank account of the user, this and that of the user....). This would avoid to cast it each time the Id is used in another class.

- As an example : Ids are manipulated in many ways. As an example, with some JSF gui, they are sent to the client as String, and converted back when processing the requests. There, making sure that in the java code, it is alwas the exact type that is used, with compilation complaigning... is crucial.

Cons :
- I guess the code would be more heavy. In the Identity project code, there would be the IDENTITY_ID every where, even if it relies only on Object.

- would force the use of Java 5

From my point of view, related to helping integration in many companies, I think that the Pros is more important than the Cons.
For one project, I did the bridge (see the first question) mainly to have this Id strongly type in a "UserBPCompany" class... and reliable code for manipulating this Id.

***********
Globally, after rereading this post, I noticed something.
The project is defined with : "JBoss Identity IDM aims to provide a common identity model for various JBoss projects."

I guess my concern is more : "an identity model that is widely used in various JBoss projects, and that cooperates/interfaces easily and nicely with the other applications of JBoss users and developpers".

the others applications in companies are oftenly developped for JBoss and runs on JBoss server. But their User class is often more specific than the needs of the JBoss projects.

I hope my explaination is easy to understand, and it may help.
feel free to ask question if something is not clear in this post.

[bdaw]

The main problem with the design and ids is that the framework provides something like a federation of the identity stores. So it is not only that you can have two different stores with different objects used to serve as the real ID (eg. Hibernate - Long, LDAP - String DN). When one store is not capable to persist all needed identity attributes (LDAP and limited schema for user profile) then such identity need to be synced into default store (hibernate) to keep the rest of the info. Therefore it can be a bit tricky to handle different ID Object types between API and SPI store repository level in an efficient way.

As you mentioned the intention behind the project is to provide same API/model for different JBoss projects. Before alpha1 was pushed and discussion moved into the forums we had some internal discussion between various projects. Pre alpha ID was pure Object and this was one of the concerns rised by JBPM team. As they store id reference to users using generic IDs would require them to support every store implementation separately. That is the main reason why in the Alpha1 API we have IdentityType ID as String.

As I see now the hardest part for the framework and API design is to address well both basic and complex needs without adding too much unnecessary overhead to the first and too much constraints to the second ones ...

I'm still thinking about how to improve the design for the IDs in the current. One of the issues in the SPI level is that IdentityStoreRepository has no way to recognize to which mapped IdentityStore given ID belongs. Currently ID is just a String representation of id from actual store (so String representation of Long for Hibernate store). I'm thinking about encoding internally more information into String ID like:
- Realm name
- Repository id
- IdentityStore id
- Actual internall store id value

Then it would be decoded on the IdentityStoreRepository level and let to handle IDs in a more efficient way.

[antoine_h]

Thanks for the answer.
I was very busy since then.

as you explain, it is not so simple.

I guess I will continue with my bridge, to go from a user in the business process app, to the user in jboss modules (such as portal, or others...).

I will make an update of all this in my project, using the API, before june (I hope).
so then, if I can, I will try to provide a clean interface and implementation model of this bridge.
hoping this may be interesting for the project.

Thanks again for the project.
I am looking forward to use the api.