I'll answer these from a GS/J perspective:

<vendor>

> -----Original Message-----
> From: Shiv Kumar [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, March 09, 2000 2:03 AM
> To:   [EMAIL PROTECTED]
> Subject:      A few questions
>
> Hi all
>
> Currently I am involved in developing a B2B solution. There are a few
> questions
> for which I would like to have answers. May be you can give me pointers to
> start
> looking for more details.
>
>   1. Does EJB/J2EE spec provide a mechanism to dynamically
> create/delete/modify
>      Groups and Users? I have been reading about access control lists etc
> but
>      they sound more to me as if the users are defined at compile time.
> So,
>      obviously I can not say method foo() of bean BarBean can be accessed
> by
>      users Tom and Harry at deployment time, because these users do not
> exist
>      when the system is in its initial state.
>
How users are managed is not defined by the spec. Obviously you don't want
to use individual principals at the bean ACL level. Use roles/groups.

In GemStone/J we can add users/groups/ACLS on the fly while the server is
running. Also we can re-deploy beans with new ACL settings while the server
is running.

>   2. What is the support for Roles in the spec? In my system, a set of
> Users
>      belong to a single Group, A set of Groups or Users belong to one or
> more
>      Roles. Roles have permissions associated with it. Users or Groups
> belonging
>      to a particular Role have all permissions defined for that Role. How
> do I
>      model this using EJBs? Do I have to write my own Security Subsystem
> or can
>      I rely on JAAS?
>
In GemStone/J Groups/Roles are synonomous. Groups can be arranged into
hierarchies as you have described...

>   3. Is there a way to have a global properties file from which all the
> beans
>      can pick values from? I know that you can specify environment
> variables in
>      the bean's depolyment descriptor. But, if for example, I have the
> mail
>      server IP address, I do not want to duplicate the same property
> across a
>      hundred deployment descriptors I have. Is there a way by which all
> beans
>      can pick up this value from one place?
>
It might require a privilege setting, but your bean should be able to get
properties from other than it's deployment descriptor. My recommendation
would be to put this into a helper class that does propert retrieval.

>   4. Is it best to use JSP/HTML or XML/XSL at the presentation layer? IMO
> both
>      have follow the model view architecture, where the developer is
> responsible
>      for the data to be displayed (model) and the web designer is
> responsible
>      for figuring out how to display it (view). We have been doing JSPs so
> far,
>      but we have not been able to persuade the web designer (an external
>      company) to write the JSP files for us  - because they dont know
> Java. So,
>      finally we end up doing everything. Is the situation any better in
> XML/XSL
>      world?
>
I have no opinion on this. You still have to hook your Java processing into
the server somehow in the XML/XSL case... JSP's provide a standard for this.
Is there such a standard for XML/XSL?

>   5. We are maintaining User relatated information in Netscape Directory
> Server
>      and the rest in a database. Most of the time, a update operation
> results in
>      updating both the directory server and database. What is the best way
> to
>      make sure that all updates happen in a single transaction? Can I use
> EJB's
>      transaction facility to rollback changes made in Directory server?
>
I assume NetScape Directory Server is LDAP? Unfortunately LDAP is not
transactional, so you can't get two phase commit between it and your
database.

One approach would be to have a transaction that updates your database, and
queues a request for update of LDAP. A daemon could then process the
guaranteed delivery queue into LDAP. This is still not perfect since LDAP
isn't transactional, but it should narrow the hole in the 2PC algorithm. Of
course, GemStone/J provides persistent/transactional queues that are perfect
for this ;-)

</vendor>
> Thanks for any help.
> --
> shiv
> [EMAIL PROTECTED]
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com
>
> ==========================================================================
> =
> 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".

Reply via email to