Thanks for this, but perhaps I should be more specific. I am thinking
specifically about the relationship between logical domain entities and
EJBObjects which are implemented by EntityBeans.
EJB clearly delivers some benefits by enabling the representation of domain
entities as abstract non-language objects, that is EJBObjects, and by
separating the concept of an EJBObject from the underlying implementation,
the EntityBean. I refer to the, I would have thought, undisputed upside in
terms of enabling caching of implementations and scalable management of
large numbers of abstract domain entities.
But the representation of domain entities as Remote does present a
limitation which you do not necessarily have in, for example, CORBA. Take,
for example a basic 'Person' logical domain entity. To represent this as an
EJBObject mapped to an EntityBean is great from the point of view that you
gain extensive appserver support for transactions, lifecycle and
persistence. It is also good that you retain the abstractness of the domain
definition since it gives you greater flexibility in the integration,
migration and evolution of your underlying implementation.
But you cannot pass a collection of Person to the client as you could with
CORBA. There are instances in many applications where this is desirable
since you may wish to iterate over large numbers of such domain entities
without generating large numbers of calls across the network.
In order to run the deployed EntityBean in the same JVM as the client as you
suggest would require a local instance of the appserver which has the
enormous downside of requiring client-side resources sufficient to run the
appserver, plus all the complexity of installing and maintaining it on
another machine.
There just seems to be an inherent contradiction in the design goals of EJB
with regard to entity beans. They enable scalable representation and
management of thousands of fine-grained instances of domain entities, but in
order to interact with these entities you have to either accept a high
volume of network calls or manually extract the state and identity of each
entity and manage the flow of this data to and from the client.
Is this not so, or am I missing something?
Dickon
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: 01 May 1999 20:46
Subject: Re: Granularity of EJBObjects
>
> 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".
