Chris Raber wrote:
> - Bean to dependent object. My opinion is that these are always aggregating
> relationships. If a bean needs to relate to a non-bean object, which is does
> not "own", then the dependent-object should probably be escalated to bean
> status.
I am not quite sure about that. Consider, for example, a Session object in
the sense described by Yoder/Barcalow in their PLoP'97 paper "Architecture
Patterns for Enabling Application Security" (to appear in PLoPD-4 book).
Their "solution" section starts saying:
Create a Session object, which holds all of the
variables that need to be shared by many objects.
Note that we may want persistent session objects which are referenced
by many entity beans to hold shared values during long business scenarios.
Those session objects are typically created once by some kind of
administration utility and then used only by the entity beans that
share the several values hidden in the session object.
Wrapping session beans or clients do not access them in typical
business situations. We think that making them beans adds unnecessary
overhead. We would rather leave the OODBMS handle the access to such
objects here. Adding "EJB access" wouldn't add much value here
(would it?). Using a non-OO DB may be different, though.
Javier Deniz
===========================================================================
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".
