Laird,
I vote for your oppinion here (Referencing Organization remote interface in the
dependent OrgUnit) and I don't know who is prohibiting that. It is a fully
legal approach, it is right and even works well.
Referencing OrganizationBean into OrgUnit is implicitly prohibited by the EJB
spec, because even dependent classes see beans as clients (no matter whether
they are in or outside the bean code) and a client must not reference a bean
directly. It is also logicaly wrong. Serializing the dependent when sending it
to a client might faill when trying to serialize the bean class, that sometime
will hold non serializable fields ...(the container will not call ejbPassivate
here). It doesn't make sence.
I hope ejbContainer implementations will enforce ejb spec. grabing interbean
calls (parametters and return values) to make sure there is no reference to the
bean (EJB) beeing sent through.
When sending the dependent data to the remote client, one can think of some
kinds of problems, that might occur when reconstructing the remote reference
into the dependent, but any consistent communication mecanism (like RMI-JRMP
oder RMI-IIOP +OBV) deals well with this isue.
Regards.
Laird Nelson wrote:
> All EJB patterns that I've seen so far say something similar, viz. that
> if you have one class (say, an Order) that has a bunch of "dependent
> objects" (the example always given is OrderItem) then in general the
> first class (Order) should be modelled as an EntityBean and the other
> class (OrderItem) should be modeled as a plain-Java serializable object.
>
> It is of course important if you're going to apply this pattern to know
> what is meant by a dependent object or class. Could someone who knows
> such things expound on what is meant here, preferably one of the pattern
> authors?
>
> To spark the discussion, in the following sample code, assuming that any
> OrgUnit instance cannot be shared between two Organizations, is OrgUnit
> a dependent object or not?
>
> Organization orgBean = (Organization)orgHome.findByXYZ(xyz);
> OrgUnit orgUnit = orgBean.getOrgUnit("foobar");
> orgUnit.doSomething();
>
> My original take is that OrgUnit is indeed a dependent object, given
> that it is owned by its parent Organization.
>
> That is, originally I modelled OrgUnit as a serializable object, like
> so:
>
> public class OrgUnit implements Serializable {
> private final Organization parent;
> public OrgUnit(Organization parent) {
> super();
> this.parent = parent; // sets final var once and for all
> }
> }
>
> Note that OrgUnit stores references to the *remote interface* of the
> Organization entity bean. I was under the impression that this was OK,
> and that, furthermore, it was still true, even with the implementation
> above, to refer to OrgUnit as a dependent object; consequently storing a
> reference to the remote interface of Organization was OK, and
> implementing OrgUnit as a plain serializable object was OK.
>
> But I then had it pointed out to me that if OrgUnit is really to be a
> dependent object, it should look like this:
>
> public class OrgUnit implements Serializable {
> private final OrganizationBean parent;
> public OrgUnit(OrganizationBean parent) {
> super();
> this.parent = parent; // sets final var once and for all
> }
> }
>
> ...that is, that if it was TRULY to be a dependent object, then it must
> be activated and passivated with the bean class that is managing it.
> Anything else--like storing the remote interface instead of the bean
> class in the "parent" member variable--would render this class not
> dependent, whatever that means.
>
> Among other implications, this would mean that the client could never
> create an OrgUnit and assign it, once and for all, to an Organization.
> Only an OrganizationBean could create an OrgUnit. Why? Because
> OrganizationBean--the bean class--is available only on the server, and
> is never exposed to the client. I was told that this was a necessary
> condition of something's being a dependent object in an EJB
> environment. That sounds wrong to me. What if I want to support
> something like this:
>
> // client side
> Organization o = // get it from somewhere....
> OrgUnit purchasing = new OrgUnit(o);
>
> ...?
>
> 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".
--
Francis Pouatcha
MATHEMA Software GmbH
http://www.mathema.de
===========================================================================
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".
