[Design of JBoss jBPM] - Re: Web Console: Context Menus and Navigation
by david.lloyd＠jboss.com
Ok, maybe I have a solution that works for everyone.
On the left the menu items will look like:
Task: start
Definition View
Instance View
Process: simple
Definition View
Instance View
Main
System View
User "bert"
User View
Log Out
The indented items are menu items, and the other items are headings (they cannot be clicked).
This menu is always the same, nothing moving, disappearing, or reappearing. If no task is available, the corresponding menu items are disabled and the heading reads "No task available".
The views contain all the information and actions for the object it represents. The User View would have the things like the user task list (I heard someone refer to that as the user's "Inbox"; I like that notion) and group task list, and ultimately possibly some identity management stuff.
System View is all of the global information, including searching for processes and any other global maintenance.
Task Definition View can give information about a task definition, as well as statistical information or reports that are specific to a task definition.
Task Instance View would let someone work with a task instance, including updating the task form, reassigning the task, viewing comments, etc.
Process Definition View would give overall information about the process and any reports relevant on a process level.
Process Instance View would allow you to look at the process instance and its constituent tokens, to examine the state of a process and possibly to deliver signals to a token that is blocking on a node.
I modeled it up in the menu and content areas and it looks better, or at least I think so. Does this work for everyone?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988917#3988917
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988917
19 years, 4 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Server side HA and failover
by clebert.suconic＠jboss.com
Tim wrote : Ok, so it looks like good progress is being made on failover :)
|
| What is there left to do?
|
| ...
|
| Load balancing policy for determining which server to initially connect to. (Re-use from remoting).
At this point, there is a HAConnectionFactory, registered in JNDI, that will LoadBalance Connectionso on createConnection.
Tim wrote : Mechanism for propagating changes in the client side server list from the server to the client when a jgroups view change occurs. I.e. when a new node joins / leaves. (Do we re-use from remoting here too?)
|
There is one thing I've done on this direction. If you do a lookup on HAConnectionFactory, you will have the list updated on the new de-serialized HAConnectionFactory. I don't know yet how we could update existent instances.
"Valve" functionality to stall any activity on connections when server failover is occurring.
|
I'm not sure... but I guess we are locking write on failOver. Isn't that enough? We shall test it anyway.
anonymous wrote : Replaying of delivered messages to the ServerConmsumerEndpoint so the delivery list can be recreated.
|
What you mean? I didn't understand.
Tim wrote : Anything else?
- Finish implementing the FailOverPolicy (Next node assumes the previous node)
- Establish a relationship between HAConnectionFactories and specific ConnectionFactories. (In case there is more than one Connection Factory, e.g. HTTP, JMS...)
- Failure on HA at this point is only done when ConnectionListener receives an event, which is pretty much done only at leasing. We should also change interceptors to take actions when Exceptions are occuring and take actions such as retry... retry... failOver
- We should have a MAP of failed nodes. (When a node assumes another node)
- The redirect protocol. Are you ready for this node? (What would be a good method name BTW?)
- Go over the current design on HAConnectionFactories.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988894#3988894
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988894
19 years, 4 months
[Design of JBoss Portal] - Re: LDAP Support expectations
by olivwalt
Hi bdaw,
i think i posted into the wrong forum http://jboss.org/index.html?module=bb&op=viewtopic&t=94631, but i will repeat my ldap expectations here.
In our company only application independent data is stored in LDAP. This means we get the following scenario:
Datastore:
------------
LDAP Store
- Basic user data
- Basic group data
- User -> group assignmrent
Therefor we would need in Portal DB
- User/group -> Role assignment
- Role -> Content assignment
- Portal user data
This leads to 3 problems
1. LDAP doesn`t have portal related attributes, therefor we need Attribute based data partitioning
- Base User data -> LDAP (e.g uid, password, mail, status, a.s.o)
- Portal User data -> Portal DB (theme, lastlogin, a.s.o)
2. LDAP doesn`t know default Portal Users (admin, user, a.s.o), so we need User based data partitioning
- Company user employee -> LDAP
- Portal user "admin" -> Portal DB, this should still work, even if LDAP is configured (e.g. emergency access, initial setup, system users, a.s.o)
3. LDAP doesn`t know default portal Groups, so we need Group based data partitioning (same as user based part.)
Operations in Portal:
------------------------
1. Read,create,update,delete Users
2. Read,create,update,delete Groups
3. Assign/revoke Users to Groups
4. Assign/revoke Users/Groups to Portal Roles
Depending on the user persistence store configuration, this would lead into the following scenarios:
Read-write LDAP configartion
1. Read,create,update,delete Users from LDAP
2. Read,create,update,delete Groups from LDAP
3. Assign/revoke LDAP Users to LDAP Groups
4. Assign/revoke LDAP Users to Portal DB Groups
5. Assign/revoke LDAP Users/Groups to Portal Roles
6. Read,update,delete Users from Portal DB
7. Read,update,delete Groups from Portal DB
8. Assign/revoke Portal DB Users/Groups to Portal Roles
Read-only LDAP configartion
1. Read Users from LDAP
2. Read Groups from LDAP
3. Assign/revoke LDAP Users to Portal DB Groups
4. Assign/revoke LDAP Users/Groups to Portal Roles
5. Read,create,update,delete Users from Portal DB
6. Read,create,update,delete Groups from Portal DB
7. Assign/revoke Portal DB Users/Groups to Portal Roles
For both LDAP configurations, you need to update according Portal DB attributes as well (lastlogin, etc), independend, if it`s read or write.
No LDAP configuration
1. Read,create,update,delete Users
2. Read,create,update,delete Groups
3. Assign/revoke Users to Groups
4. Assign/revoke Users/Groups to Portal Roles
Principals
--------------
I would do a different implementation, then in your post http://jboss.org/index.html?module=bb&op=viewtopic&t=92487
1. MembershipModule makes no sense to me, you always should work with Objects of type principal
2. The missing Group portal functionality mentioned by bvogt is really a pain for larger projects
Here is what would suggest, based on your draft and on SAP`s implemtation of the User Management Engine.
UserModuleUserModule - provides functionality to get User objects by providing required information.
| - instantiate user objects
| - create new users (possibly by copying the data of an existing one)
| - delete users
| - search for users based on different criteria
UserUser -- provides read and write acces to principals of type User.
| - Get and set User attributes
| - Perform Group operations dd and revoke Users to Group
| - Perform Role operations dd and revoke Users to Role
| - Authorization checks isMemberOf Group or Role
GroupModuleGroupModule - provides functionality to get Group objects by providing required information.
| - instantiate group objects
| - create new groups
| - delete groups
| - search for groups based on different criteria
GroupGroup - read and write access to principals of type Group.
| - Perform User operation add and revoke Users to Group
| - Perform Role operations add and revoke Group to Role
| - Get and Set Group attributes
RoleModuleRoleModule - provides functionality to get Role objects by providing required information.
| - instantiate Role objects
| - create new Roles
| - delete Roles
| - search for Roles based on different criteria
RoleRole - read and write access to principals of type Role.
| - Perform User operation add and revoke Users to Role
| - Perform Group operations add and revoke Group to Role
| - Get and Set Group attributes
Persistence configuration
----------------------------
I checked your idendity draft under http://anonsvn.jboss.org/repos/portal/trunk/identity/src/resources/draft/ .
As bvogt already mentioned i would merge the config files into one.
- standardidentity-config.xml -> Maps all information to default Portal DB
- ldapidendity-config.xml -> overwrites configured options to LDAP, not configured attributes/principals are still mapped over the standardidendity-config.xml to Portal DB
Therefor the options section in ldapidendity-config.xml wolud look like<options>
| <module type=UserModule>
| <property>
| <name>portal.user.realEmail</name>
| <type>java.lang.String</type>
| <access-mode>read-write</access-mode> <!-- Why at attribute scope, imho this should be global setting -->
| <usage>optional</usage>
| <display-name xml:lang="EN">Real Email</display-name> <!-- Why here? -->
| <description xml:lang="EN">The real email</description> <!-- Why here? -->
| <mapping>
| <type>attribute</type>
| <value>mail</value>
| </mapping>
| </property>
| </property>
| </option />
As you mentioned earlier in this post, the roadmap for 2.6 is already defined and you won`t change it, so this maybe helpful for release 3.0. Both solutions anonymous wrote : There are few posible scenarios like:
| 1) keep it in LDAP - thats what is planned in current implementation. So this means no user/role data in DB. But still you should be able to keep personalization data in DB like user properties.
| 2) authenticate in LDAP and keep in DB - this is possible at the moment. You just need to configure authentication on the app server side and keep LDAP/DB in sync manually. So here we may consider to make JAAS LoginModule implementation that authenticate against LDAP and update user/role data in DB. would be enough for us to start working, but not to use it productive.
Whereas i personally prefer the first solution, to avoid redundant data and synchronisation delay.
As i understand your implemetation, Roles and User Objects maintained in LDAP, and also the relationship. Roles are used in JBoss Portal to control access rights to portal objects. Please correct me, if i`m worng, but this would mean application dependend data has to be stored in LDAP, that is not usable in larger companies, as you already mentioned, Portal is just another client application, and we have several of it.
Maintaining Users/Groups in LDAP and map to Roles in Portal would also increas the flexibility of LDAP configuration.
What i don`t understand right now is, why do you want to decouple Users and Roles in a MembershipModule, what is the advantage of this?
Regards Oliver
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988893#3988893
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988893
19 years, 4 months