[Design of JBoss Portal] - Re: Initiall identity model discussion
by Antoine_h
Hello,
I've been working recently on identity.
For both a portal in a company, and my own portal.
Something that appeared usefull :
****************************
Delegating user and role to a service provider instead of only to a source
****************************
*** Situation ***
The portal is seen as an application among others.
The users/roles comes from "another source" (LDAP or legacy db, or even just customized users in db with added features for business process).
The User and Role class for all the application are much more complex than the User and Role for the portal.
Example :
- the user is linked to the company organisation (subsidiaries, department), and the role depends of that link.
- the user is linked to an account, and/or to services offers, and the application needs that information every where to do their work
The integration of portal, federating all the applications, requiers to provide Users and Roles for all the application. Most of the time, it means build in JBoss AS a service that provides this to all the applications that will run under jboss (EJB3, Struts, other framework above jboss).
*** Problem ***
Small technical problem with the interfaces, when integrating the Portal and other application Users.
The User interface has a method
Object getId()
If the "all other application" works with a UserBP (User for Business Process) that have a
long getId()
(or any other type... String, custom Id class,...)
the portal User cannot be an interface used "in common", by inheritance on the UserBP. (UserBP extends User).
Then, the portal Identity services cannot work directly with an instance of UserBP (slightly modified with adding the portal User interface).
Simply said : the User for portal will often be of a different type than the UserBP for other application. And there will often be a problem for making inheritance.
And can't says : to work in the portal, just reprogram your UserBP class and all the application code that yet use it. Retest all these applications and that's it... ;-)
*** Proposal ***
The portal is not there for solving all the integration problem (of course).
But there is something quiet simple, that would help integration work.
The best way I found for integration is :
- define a UserPortal and use the existing UserBP from the company ("business process..." )
- UserBP is for all the applications : the user, seen by the organisation (legacy)
- UserPortal is kind of a "sub user", just for the needs of the portal ("this application among the others").
- build some jboss IdentityBP services, that manage/provide the UserBP (for all applications)
- IdentityBP services is a JBoss AS service for all the application that want to use it.
- for the portal, customize the Identity services of portal into a IdentityPortal services : to manage and provides the UserPortal
- the IdentityPortal services call the IdentityBP services, as a delegate, and build it's UserPortal from the information of UserBP.
So : Having a delegation of the Identity Services, to some Abstract classes that provides/manage a UserPortal, relying on the UserBP would be great.
The Abstract class would have methods that take an Object (in fact a UserBP), and do the job on it to produce a UserPortal.
The Abstract class could be ReadOnly, or ReadWrite, depending on the possibility of two way conversion of UserBP to UserPortal.
Said differently :
Instead of having a delegation at the source level : DB or LDAP
It could be a delegation to a Custom Identity Service (which deals with DB or LDAP).
Delegation at the java class of User level (and at Service level).
Having the delegation at this level allow to provide a common service for UserBP for all the application that run inside the portlets.
And to use that same service as a delegate for the portal application.
This is a better archictecture for several application that run on JBoss AS, than "each application manage the way it builds it's users, from a common datasource".
Having this delegation to a Custom Identity Service would be an help for integration work : avoid each company to develop it from the Identity Services provided by the portal now.
Hope it is understandable... and it will help.
Feel free to ask questions...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070897#4070897
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070897
18 years, 8 months
[Design of JBoss Portal] - Re: User Portlet Discussion
by Antoine_h
Hello,
********************
Ordering the view of users, or roles.
********************
today, the users are not sorted.
after modify a user, the list show in different order.
quite confusing.
so, usual database / table gui features : sorting on each columns. (easy now with jsf components).
********************
configurable list of user
********************
Ability to chose the columns that show in the list.
The column of the properties of the profile.
when managing quiet a lot of users, one or two profile properties are usefull to see in the list.
- ordering on that property to immidiatly select the user to work on, like adding roles etc....
- view at a glance all the users that are "like this or like that". (no need to enter the user profile screen to see this).
example : see in the list the date of last visit of the portal.
********************
Multi selection screens, with action on the selected list.
********************
example : selection of n users, then adding this role to them.
********************
Logged in users
********************
the feature of seeing "who is logged in now".
I have seen this feature is being developped, and at least feasible with some interceptors of the new API.
This is not part of User profile data, but this info in one column of the user list would be nice, for admin working on a user data.
And it would be a good example on "how to do this" for people that want to make there own feature of this kind.
********************
Packaging the user stuff appart
********************
if not yet done.
a separate packaging for the user/role gui admin
a separate packaging for the identity services (this is not gui, but this is important too).
use case : for customizing, suppress the jboss package, and deploy a new customized one. This is more clean and quick for prod, or even quick installation of a new server for dev (upgrade RC1, RC2, GA, X.X.1 GA...)
********************
RichFaces ?
********************
if RichFaces is ready when this is developped : would be great
and a great example for the one that want to see "how to".
hope that helps
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070889#4070889
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070889
18 years, 8 months
[Design of JBoss ESB] - Specific type of ServiceInvoker
by mark.little＠jboss.com
I notice that we now have a:
| public static synchronized void deliverToDeadLetterChannel(Message message) throws RegistryException, MessageDeliverException {
| if (dlQueueInvoker == null) {
| dlQueueInvoker = new ServiceInvoker(INTERNAL_SERVICE_CATEGORY, DEAD_LETTER_SERVICE_NAME);
| }
| dlQueueInvoker.deliverAsync(message);
| }
|
operation in ServiceInvoker. Although I can understand the necessity for this (make it easier to send specifically to the DLQ), I disagree with the approach. Why not subtype ServiceInvoker and have a specific DLQServiceInvoker? That way we also encourage others to use the SI approach in an extensible and manageable way. Plus, if someone wants to deliver something synchronously to the DLQ we don't have to go back and change the SI interface again.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070842#4070842
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070842
18 years, 8 months
[Design of JBoss jBPM] - Re: Failure handling
by tom.baeyens＠jboss.com
the DLQ think should work also. but it's less portable. since we can't control the retries.
in the approach that i described, we could think about adding the retry count to the job. (decrementing the counter on failed attempt would have to be done in a separate tx, and that's a bit clumsy)
but then we can document the configurations. while with leveraging the JMS configuations, the configurations are JMS implementation specific.
With the DLQ approach, the retry count has to be configured for the whole Queue, right ? If we use the jbpm-retry mechanism, then we can have the retry count defined in the process.
Can you give a pointer as to why my proposed approach doesn't work ? Can it be made to work ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070839#4070839
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070839
18 years, 8 months