In most containers, can you programmatically create new
users/principals? How about roles? Is this usually done, if it is
possible? If not, why not?
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)?
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
coincidental) correlation between number of principals and number of,
say, person entity beans in the database? Is this correlation something
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}
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?
I've heard from two people now, one of whom says that coupling servlet
authentication methods to EJB is a good thing (in fact the
specifications seem to support each other), and another who says that it
is a bad thing. Stylistic questions aside, is there any reason why I
shouldn't be creating lots of EJB principals and logging in as them on
each client request?
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?
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?
Does anyone from Sun read this list?
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".
