An EJB object currently acts as both a fine-grained and coarse-grained
facade to your enterprise beans. The EJB spec does not make a distinction
between a large-grained component (something that client code would use)
and a small-grained component (something that your large-grained component
would use internally). Hopefully a newer version of the EJB spec will
address this.
However, in either scenario, an EJB object is a remotable object that can
be OPTIONALLY called over the network. You have a choice -- if you deploy
your client code in the same JVM as your EJB objects, then you are just
making local, efficient calls. Many EJB servers support this (such as IBM
WebSphere and BEA WebLogic I believe).
Note that there is currently no facility to make a 'local-only' EJB object.
It's up to you to deploy your code in the appropriate tiers so that you
minimize network roundtrips when you call EJB objects. There has been talk
on this interest list a few months back about making a connector/accessor
facility for local-only access to legacy systems and data, but that is
unlikely to emerge as a specification for awhile.
PS: I'm not sure I agree that EJB object references cannot be passed by
value. Remember that an EJB object is a Java RMI remote object. Whenever
you deal with an RMI remote object, you deal with a stub. When you pass an
EJB object reference as a parameter, you're really passing the stub, and
the stub is serializable and is therefore passed by-value. You would never
want to pass the EJB object itself by-value, since an EJB object is part of
your container, and needs the container run-time environment to support it.
If anything, you'd probably want a facility to pass a bean instance
by-value, not an EJB object. I could see a use for this if you want to
marshal a bean's state to client code deployed in another tier, such as
servlets or JSP scripts. However there are issues here: How do you get the
state out of the bean? What if you want only some state, and not other
state? How do you repopulate a bean's state later? Currently there is no
way to do this other than by hand.
-Ed
Dickon Field wrote:
>
> I have seen a couple of references to this, but no answer which I found
helpful:
>
> From an analysis/design point of view, just what should the granularity
of EJBObjects be? Since EJBObject extends
> Remote any class implementing an interface which is an EJBObject cannot
be passed by value. So this suggests that
> EJBObjects should not be fine-grained domain entities since in many
situations this would result in frequent
> inefficient accesses to the server across a network
>
> If they are large grained objects then they begin to fall more naturally
into a class of higher-level 'manager'-like
> abstractions (viz, for example process-entity pattern) which manage many
fine-grained objects in the domain. But you
> then lose the benefit of all of the lifecycle management and caching of
those fine-grained entities which EJB servers
> are supposed to provide.
>
> It seems a shame really, since if there were some way of passing
EJBObjects by value they could still remain abstract > definitions of
domain entities, since the client-side need still only know about the
interface to deserialize objects > into its own VM. This would result in
much greater choice and adaptation of the physical implementation to
different > problems/needs.
>
> So, what is the 'ideal' use of EJBObjects?
>
> Dickon
>
> ECsoft UK Ltd
===========================================================================
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".
