> What kind of uses are principals in EJB usually put to? Is it common
> practice to have just a few general-purpose principals, or are many
> principals typically created and killed off during the lifetime of a
> large, hairy, transactional enterprise application (such as the kind
> we're building)?
Principals typically (not just, but mostly) represent your users. Of
course you can put many users on the same account (e.g. anonymous) or
have multiple accounts for the same user (say, one for EJB, one for
e-mail, etc), but generally a principal == user account.
A role is the right to engage in some sort of operation. For example, a
'teller' vs. 'branch manager', a 'user' vs. 'power user', a 'author' vs.
'editor'.
The number of roles depends on the granularity of your application.
Maybe everybody is just a user, or you might have 'junior user', 'senior
user', 'super user' and 'god-of-all-users' (aka sysadmin :-) )
> Isn't a principal who is accessing an EJB server usually performing work
> on his or her own data in most applications? So isn't there a (perhaps
Yes.
> coincidental) correlation between number of principals and number of,
> say, person entity beans in the database? Is this correlation something
Typically.
> to be avoided? Is it indicative of bad design? If it is, what "types"
> of principals should be used instead? That is, if a principal is not a
> standin for a username, then what is it?
>
> {muted sounds of frustration}
I can sympathize :-)
>
> Argh; I can't say any of this articulately.
>
> {pause}
>
> Why would you ever have more than one or two principals set up in an EJB
> server? Do principals represent new dynamic users that are created as
> part of business processes, or do they represent system/operations-level
> users?
Because you would want to grant different roles (or permissions) to
'smith' from R&D and 'betty' from accounting, or else, smith will be
moving money around and betty will be fixing bugs :-)
> Are examples of principal names more like "normalUser", "superUser",
> "administrator" or are they more like "john smith", "betty ford" :-),
> "ghandi"? I have always assumed the latter, because roles are then
> assigned to them, and the roles sound more like administrator,
> normalUser, etc. Am I wrong?
No, you are right.
> All source code examples I've ever seen for EJB interaction assume that
> the client is like a terminal bolted onto the back of the EJB server.
> Consequently, they all feature a one-time login, where the client calls
> new InitialContext() once, passing it--once--the username and password
> of the one-time user. The client then does 4390920 things involving
> session beans and logs out. These examples have absolutely nothing in
> common it seems to me with...uh, what do I call them...stateless
> clients--you know, like when a servlet's doGet() method gets invoked and
> it does a new InitialContext() call, hits the EJB server, and then
> exits. A new hit comes along and the servlet's doGet() method fires
> again, doing another new InitialContext() call, etc. Is there any
> source code out there that shows the "proper" way--or at least good
> practice, coding patterns, etc.--of writing stateless clients that run
> on behalf of authenticated and non-authenticated users?
Sadly this is a deficiency of the Servlet specification more than the
EJB specification. The EJB tutorials don't want to talk about Servlets,
and the Servlets tutorials are not up to speed.
>
> Does anyone from Sun read this list?
They are aware of these issues.
arkin
>
> Cheers,
> Laird
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
