from ebj 2.0 spec 21.2.4:
"The Bean Provider should neither implement security mechanisms nor hard-code
security policies in the enterprise beans� business methods. Rather, the Bean
Provider should rely on the security mechanisms provided by the EJB Container,
and should let the Application Assembler and Deployer define the appropriate
security policies for the application."
You are probably aware that fine-grained security discrimination is typically
done by defining security roles, e.g. ten roles rather than ten ejb deployment
descriptors. Roles could be set at run-time by remapping the principal if
you're adventurous.
On the other hand, I once worked at a bank and I know that access models can
get quite--well, creative, to put it politely.
--
Fred Loney
Enterprise Java Consultant
Spirited Software, Inc.
[EMAIL PROTECTED]
Robert Zhang wrote:
> Hi, all
>
> I have two questions:
>
> 1. For an EJB container, is it easier to manage 100 pooled instances of the
> same stateless session bean class or 100 pooled instances of 10 different
> SLSBs(10 instances for each SLSB)?
>
> 2. Can I specify 10 different EJBs in the xml deployment descriptor with
> different <ejb-name>'s but with the same remote, home interfaces, and the
> EJB class? For example, I want to use ejb1, ejb2, ejb3, ... ejb10 as the
> <ejb-name>'s to specify 10 EJBs in the descriptor. But they all use the
> same remote interface, home interface, and the EJB class.
>
> The reason is that we currently have an application that contain dozens of
> EJB classes that differ only by their class names. Based on arguments
> passed in, they do different things. The people who developed them claim it
> is to provide granularity to control security, transaction, etc. for each
> bean. If a generic EJB was used, it wouldn't be able to take advantage of
> the features an EJB container offers to control security, transaction at a
> bean, or even a method, level. Therefore, if the anser to my second
> question above is yes, it would solve the granularity issue.
===========================================================================
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".
