see below
> -----Original Message-----
> From: Dickon Field [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, May 04, 1999 8:36 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Granularity of EJBObjects
>
> 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.
[Chip Wilson]
I have found that it is best for entity beans to be large/coarse
grained components which represent a graph of domain instances. Each entity
bean has a single root domain object, and the entity represents all domain
objects referenced from this root. Each entity bean's graph is disjoint
from every other entity bean's graph, so if your domain model shows
associations between these subsystems, the reference should be implemented
as an EJBObject reference either from the domain class to the relevant
entity bean, or between the entity beans themselves.
The client may request portions or all of an entity bean's graph, in
which case these fine-grained objects, probably implemented as regular
JavaBeans, are serialized and sent to the client for localized processing.
These graphs can be modified and sent back to the entity bean in the context
of a transaction for updates.
There are two common reasons for wanting a collection of domain
objects. One is to iterate over the collection and perform some system
operation on each entity. The other is to present a list of these entities
to the user so that they may select one to work with. In the first case,
you must instantiate each entity bean and reference it. In order to reduce
network traffic, I recommend implementing the iteration in a session bean,
so that all of the lookups and calls to the entity beans occur on the
server. In the second case, it is best to implement a lightweight
representational object which only contains the information that the user
will need to identify the entity s/he is looking for, plus the primary key
of the entity. These representational objects can be retrieved from a
session bean as a serialized array of objects, and don't need a
corresponding entity bean, since they are read-only. When the user selects
the appropriate representational object, the application can instantiate the
entity bean it represents from the primary key contained in the lightweight
object.
> 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.
[Chip Wilson]
This is exactly why entity beans should be coarse grained
components.
> 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".
>
===========================================================================
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".
